<div dir="ltr">Hi,<div><br></div><div>> <span style="font-size:12.8000001907349px">Thanks for that thought, and I was already trying to prune options, but maybe did not try hard enough!</span></div><br style="font-size:12.8000001907349px"><div>Always happy to provide my 2p worth ;-)</div><div><br></div><div>> <span style="font-size:12.8000001907349px">ENC generally does NOT imply authentication and allows all sorts of unpleasant attacks in my understanding.</span></div><br style="font-size:12.8000001907349px"><div>I think it largely depends on what type of keys you are using and what entities have those keys, for example if two (and only two) devices have negotiate a shared key then any message sent with that key must have come from the other device, hence the authentication is implied and this may be a better architecture for devices with limited resources for encryption.</div><div><br></div><div>> <span style="font-size:12.8000001907349px">If the underlying comms medium is secure though I think that NONE may be handy but maybe not enough to justify a separate option.</span></div><br style="font-size:12.8000001907349px"><div>What you might want to do is group some of the requirements together, eg if it is an unsecured, unreliable comms then SEQ and ENC must be used. If you are using a reliable, secure comms channel then NONE must be used?</div><div><br></div><div>Cheers,</div><div><br></div><div>Jeremy</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 April 2015 at 19:42, Damon Hart-Davis <span dir="ltr"><<a href="mailto:dhd@exnet.com" target="_blank">dhd@exnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Thanks for that thought, and I was already trying to prune options, but maybe did not try hard enough!<br>
<br>
ENC generally does NOT imply authentication and allows all sorts of unpleasant attacks in my understanding.<br>
<br>
I agree that NONE and SEQ could probably be killed if need be, but currently seem useful to me.<br>
<br>
If the underlying comms medium is secure though I think that NONE may be handy but maybe not enough to justify a separate option.<br>
<br>
SEQ is intended to help notice lost messages.<br>
<br>
Currently all the data I am flinging around with OpenTRV counts as ‘CHECK’.<br>
<br>
I may go and kill off NONE and adjust CHECK appropriately.<br>
<br>
Thanks again...<br>
<br>
Rgds<br>
<span class="HOEnZb"><font color="#888888"><br>
Damon<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On 9 Apr 2015, at 16:17, Jeremy Poulter <<a href="mailto:jeremy@bigjungle.net">jeremy@bigjungle.net</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Just one general comment; you are proposing a lot of options which while it allows for a lot of flexibility can really hurt interoperability, especially if you want to allow ports to other platforms or indeed implementation from scratch based on a specification. The other thing to consider is that if you want to run a certification program (and I believe this was one of your goals) each option will increase the complexity of that program. I would highly recommend that you keep the number of options to a minimum and each option should have a really good reason behind it not just 'it would be nice'.<br>
><br>
> So for example your list of message types is;<br>
> * NONE: none (sent with no checksum, etc, as clear text): may be OK for underlying reliable/secure medium and/or non-critical data.<br>
> * CHECK: simple frame check value applied and verified, eg typically 7--16 bit check sum or CRC.<br>
> * SEQ: above plus small frame sequence number.<br>
> * AUTH: above plus crypto-based authentication.<br>
> * ENC: above plus encryption (eg AES-GCM or EAX).<br>
> * ENCHIGH: above with enhanced security (eg longer keys and/or IVs etc) at cost of frame size and CPU.<br>
><br>
> I would ask the questions;<br>
> - Does NONE really save you that much when compared to CHECK?<br>
> - Does AUTH actually add any value, given that this is typically associated with public/private key encryption and certificate chains and these are fairly heavy in terms of CPU requirements. Does ENC actually give you an implied authentication due to the pre-shared key?<br>
><br>
> Cheers,<br>
><br>
> Jeremy<br>
><br>
><br>
> On 3 April 2015 at 21:03, Damon Hart-Davis <<a href="mailto:dhd@exnet.com">dhd@exnet.com</a>> wrote:<br>
> Update…<br>
><br>
><br>
> DHD20150403: messaging thoughts including integrity.<br>
><br>
> The design aim is to allow tramission of (optionally secure) telemetry from low-power sensor nodes<br>
> over a number of alternate backhaul media such as one-way packet-based ISM radios.<br>
><br>
> Assume that the leaf end is a low-powered CPU and so the code interface and implementation has to be simple,<br>
> and with minimal support from some hardware for features such as encryption.<br>
><br>
> Assume that the messaging maximum possible frame size will generally be 64 bytes or less,<br>
> and may vary significantly with the options chosen below, especially if encrytion is added.<br>
> Assume that some of the data carried may be sensitive, eg privacy related or for driving actuators.<br>
><br>
> Assume that some implementations can/will not run below a specific integrity level, eg with data checksums/CRCs.<br>
><br>
> Assume that the raw messaging transport is by default:<br>
> * one way<br>
> * lossy<br>
> * noisy<br>
> * bandwidth limited (low bit rate and/or (say) frames/day capped) and/or expensive per bit or frame<br>
> * real-time but possibly with significant latency<br>
> * overhearable, eg over ISM radio or similar.<br>
><br>
> (Some variants like TinyHAN allow two-way flows, and others may be radically different such as tunneled in HTTPS over a LAN.)<br>
><br>
> Have one or more backhaul layers available at run-time leaf (with superset at concentrator)<br>
> with some constant capabilities, ie that can be checked/selected at pref at compile time, such as:<br>
><br>
> * Frame formats that can be carried on this channel (1 or more):<br>
> * JSON object {...} (compact ASCII7 subset, only printable chars 32--126 ie with no linebreaks or other control).<br>
> * Whitened binary (with no 0x00 or 0xff bytes), so limited-length runs of either bit, and both values possible as delimiters.<br>
> * Structured binary (as interpretted by underlying channel eg with TinyHAN).<br>
> * Pure binary.<br>
><br>
> * Ability to mark some frames as 'important' (bool), eg containing critical or changed values, with extra delivery effort (eg double TX or FEC).<br>
><br>
> * Maximum data integrity protection available from the channel (enum / small int):<br>
> * NONE: none (sent with no checksum, etc, as clear text): may be OK for underlying reliable/secure medium and/or non-critical data.<br>
> * CHECK: simple frame check value applied and verified, eg typically 7--16 bit check sum or CRC.<br>
> * SEQ: above plus small frame sequence number.<br>
> * AUTH: above plus crypto-based authentication.<br>
> * ENC: above plus encryption (eg AES-GCM or EAX).<br>
> * ENCHIGH: above with enhanced security (eg longer keys and/or IVs etc) at cost of frame size and CPU.<br>
> (Data receiver should usually check data for semantic/syntactic integrity etc also, especially if a low level is used here.)<br>
><br>
> All systems should support at least JSON object and whitened binary formats with a simple (CHECK) integrity check.<br>
> (Note that JSON formats are assumed NOT optimal in bandwidth terms,<br>
> and should generally not be used for prolonged production deployments (use a binary format),<br>
> but the underlying medium may be able to make some optimisations such as simple compression on the wire.)<br>
><br>
> All systems with privacy-related data must support encyption (ENC),<br>
> and/or have the ability selectively not to send sensitive data,<br>
> and/or the underlying backhaul must be able to guarantee ENC-level integrity itself (eg tunelling over HTTPS or VPN).<br>
><br>
> At run time (and possibly at compile time) it must be possible to discover the maximum data frame size possible<br>
> with the selected transmission parameters.<br>
><br>
> Note that for higher integrity levels suitably-sized keys may have to have been pre-shared for example,<br>
> and any modes not supported by the concentrator may have to be removed to the 'available' list.<br>
><br>
> At run time it should be possible to specify above parameters with each frame to send from leaf,<br>
> and those parameters plus some associated values (eg sequence numbers/range) should be recoverable.<br>
> Data that fails integrity checks is in normal circumstances not available nor are crypto keys used,<br>
> though parameters such as algorithm and strength may be).<br>
><br>
> Note that key, IV, etc lengths that are acceptable in 2015 may prove inadequate to future;<br>
> to some extent that is implicitly dealt with outside this definition by the key-sharing mechanism,<br>
> but frame size limits may ultimately limit available security.<br>
><br>
> See also:<br>
> <a href="http://blog.cryptographyengineering.com/2011/11/how-not-to-use-symmetric-encryption.html" target="_blank">http://blog.cryptographyengineering.com/2011/11/how-not-to-use-symmetric-encryption.html</a><br>
> <a href="http://crypto.stackexchange.com/questions/7951/aesctrhmac-encryption-and-authentication-on-an-arduino" target="_blank">http://crypto.stackexchange.com/questions/7951/aesctrhmac-encryption-and-authentication-on-an-arduino</a><br>
> <a href="http://www.cs.berkeley.edu/~jaein/papers/cs294_9_paper_fec.pdf" target="_blank">http://www.cs.berkeley.edu/~jaein/papers/cs294_9_paper_fec.pdf</a><br>
> <a href="http://packetpushers.net/ipsec-bandwidth-overhead-using-aes/" target="_blank">http://packetpushers.net/ipsec-bandwidth-overhead-using-aes/</a><br>
> <a href="http://nordsecmob.aalto.fi/en/publications/theses_2008/thesis_gabrielalimon_tkk.pdf" target="_blank">http://nordsecmob.aalto.fi/en/publications/theses_2008/thesis_gabrielalimon_tkk.pdf</a><br>
> <a href="http://www.iacr.org/workshops/fse2010/content/slide/Fast%20Software%20AES%20Encryption.pdf" target="_blank">http://www.iacr.org/workshops/fse2010/content/slide/Fast%20Software%20AES%20Encryption.pdf</a><br>
> <a href="http://tools.ietf.org/html/rfc4106" target="_blank">http://tools.ietf.org/html/rfc4106</a><br>
> Public domain uNaCl crypto for AtMega: <a href="http://munacl.cryptojedi.org/" target="_blank">http://munacl.cryptojedi.org/</a> and <a href="https://cryptojedi.org/papers/avrnacl-20130514.pdf" target="_blank">https://cryptojedi.org/papers/avrnacl-20130514.pdf</a><br>
> <a href="https://github.com/kokke/tiny-AES128-C" target="_blank">https://github.com/kokke/tiny-AES128-C</a> (public domain)<br>
> <a href="http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-38A.pdf" target="_blank">http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-38A.pdf</a><br>
><br>
> _______________________________________________<br>
> OpenTRV-dev mailing list<br>
> <a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
> <a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
><br>
> _______________________________________________<br>
> OpenTRV-dev mailing list<br>
> <a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
> <a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
<br>
_______________________________________________<br>
OpenTRV-dev mailing list<br>
<a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
<a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
</div></div></blockquote></div><br></div>