<div dir="ltr">Hi,<div><br></div><div>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'.</div><div><br></div><div>So for example your list of message types is;</div><div><span style="font-size:12.8000001907349px"> * NONE: none (sent with no checksum, etc, as clear text): may be OK for underlying reliable/secure medium and/or non-critical data.</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px"> * CHECK: simple frame check value applied and verified, eg typically 7--16 bit check sum or CRC.</span><br style="font-size:12.8000001907349px"><span class="im" style="font-size:12.8000001907349px"> * SEQ: above plus small frame sequence number.<br> * AUTH: above plus crypto-based authentication.<br></span><span style="font-size:12.8000001907349px"> * ENC: above plus encryption (eg AES-GCM or EAX).</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px"> * ENCHIGH: above with enhanced security (eg longer keys and/or IVs etc) at cost of frame size and CPU.</span><br style="font-size:12.8000001907349px"></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I would ask the questions;</span></div><div><span style="font-size:12.8000001907349px">- Does NONE really save you that much when compared to CHECK?</span></div><div><span style="font-size:12.8000001907349px">- 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?</span></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 3 April 2015 at 21:03, 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">Update…<br>
<span class=""><br>
<br>
DHD20150403: messaging thoughts including integrity.<br>
<br>
</span>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>
<span class="">Assume that some of the data carried may be sensitive, eg privacy related or for driving actuators.<br>
<br>
</span>Assume that some implementations can/will not run below a specific integrity level, eg with data checksums/CRCs.<br>
<span class=""><br>
Assume that the raw messaging transport is by default:<br>
* one way<br>
* lossy<br>
* noisy<br>
</span> * 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>
<span class=""> * overhearable, eg over ISM radio or similar.<br>
<br>
</span>(Some variants like TinyHAN allow two-way flows, and others may be radically different such as tunneled in HTTPS over a LAN.)<br>
<span class=""><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>
</span> * JSON object {...} (compact ASCII7 subset, only printable chars 32--126 ie with no linebreaks or other control).<br>
<span class=""> * 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>
</span> * Ability to mark some frames as 'important' (bool), eg containing critical or changed values, with extra delivery effort (eg double TX or FEC).<br>
<span class=""><br>
* Maximum data integrity protection available from the channel (enum / small int):<br>
</span> * 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>
<span class=""> * SEQ: above plus small frame sequence number.<br>
* AUTH: above plus crypto-based authentication.<br>
</span> * 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>
<span class=""> (Data receiver should usually check data for semantic/syntactic integrity etc also, especially if a low level is used here.)<br>
<br>
</span>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>
<span class=""><br>
At run time (and possibly at compile time) it must be possible to discover the maximum data frame size possible<br>
</span>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>
<span class="">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>
</span>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>
<div class="HOEnZb"><div class="h5"><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>