[OpenTRV-dev] Very basic backhaul thoughts

Thu Apr 9 18:42:32 BST 2015

Hi,

Thanks for that thought, and I was already trying to prune options, but maybe did not try hard enough!

ENC generally does NOT imply authentication and allows all sorts of unpleasant attacks in my understanding.

I agree that NONE and SEQ could probably be killed if need be, but currently seem useful to me.

If the underlying comms medium is secure though I think that NONE may be handy but maybe not enough to justify a separate option.

SEQ is intended to help notice lost messages.

Currently all the data I am flinging around with OpenTRV counts as ‘CHECK’.

I may go and kill off NONE and adjust CHECK appropriately.

Thanks again...

Rgds

Damon

> On 9 Apr 2015, at 16:17, Jeremy Poulter <EMAIL ADDRESS HIDDEN> wrote:
> 
> Hi,
> 
> 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'.
> 
> So for example your list of message types is;
>       * NONE: none (sent with no checksum, etc, as clear text): may be OK for underlying reliable/secure medium and/or non-critical data.
>       * CHECK: simple frame check value applied and verified, eg typically 7--16 bit check sum or CRC.
>       * SEQ: above plus small frame sequence number.
>       * AUTH: above plus crypto-based authentication.
>       * ENC: above plus encryption (eg AES-GCM or EAX).
>       * ENCHIGH: above with enhanced security (eg longer keys and/or IVs etc) at cost of frame size and CPU.
> 
> I would ask the questions;
> - Does NONE really save you that much when compared to CHECK?
> - 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?
> 
> Cheers,
> 
> Jeremy
> 
> 
> On 3 April 2015 at 21:03, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
> Update…
> 
> 
> DHD20150403: messaging thoughts including integrity.
> 
> The design aim is to allow tramission of (optionally secure) telemetry from low-power sensor nodes
> over a number of alternate backhaul media such as one-way packet-based ISM radios.
> 
> Assume that the leaf end is a low-powered CPU and so the code interface and implementation has to be simple,
> and with minimal support from some hardware for features such as encryption.
> 
> Assume that the messaging maximum possible frame size will generally be 64 bytes or less,
> and may vary significantly with the options chosen below, especially if encrytion is added.
> Assume that some of the data carried may be sensitive, eg privacy related or for driving actuators.
> 
> Assume that some implementations can/will not run below a specific integrity level, eg with data checksums/CRCs.
> 
> Assume that the raw messaging transport is by default:
>   * one way
>   * lossy
>   * noisy
>   * bandwidth limited (low bit rate and/or (say) frames/day capped) and/or expensive per bit or frame
>   * real-time but possibly with significant latency
>   * overhearable, eg over ISM radio or similar.
> 
> (Some variants like TinyHAN allow two-way flows, and others may be radically different such as tunneled in HTTPS over a LAN.)
> 
> Have one or more backhaul layers available at run-time leaf (with superset at concentrator)
> with some constant capabilities, ie that can be checked/selected at pref at compile time, such as:
> 
>   * Frame formats that can be carried on this channel (1 or more):
>       * JSON object {...} (compact ASCII7 subset, only printable chars 32--126 ie with no linebreaks or other control).
>       * Whitened binary (with no 0x00 or 0xff bytes), so limited-length runs of either bit, and both values possible as delimiters.
>       * Structured binary (as interpretted by underlying channel eg with TinyHAN).
>       * Pure binary.
> 
>   * Ability to mark some frames as 'important' (bool), eg containing critical or changed values, with extra delivery effort (eg double TX or FEC).
> 
>   * Maximum data integrity protection available from the channel (enum / small int):
>       * NONE: none (sent with no checksum, etc, as clear text): may be OK for underlying reliable/secure medium and/or non-critical data.
>       * CHECK: simple frame check value applied and verified, eg typically 7--16 bit check sum or CRC.
>       * SEQ: above plus small frame sequence number.
>       * AUTH: above plus crypto-based authentication.
>       * ENC: above plus encryption (eg AES-GCM or EAX).
>       * ENCHIGH: above with enhanced security (eg longer keys and/or IVs etc) at cost of frame size and CPU.
>     (Data receiver should usually check data for semantic/syntactic integrity etc also, especially if a low level is used here.)
> 
> All systems should support at least JSON object and whitened binary formats with a simple (CHECK) integrity check.
> (Note that JSON formats are assumed NOT optimal in bandwidth terms,
> and should generally not be used for prolonged production deployments (use a binary format),
> but the underlying medium may be able to make some optimisations such as simple compression on the wire.)
> 
> All systems with privacy-related data must support encyption (ENC),
> and/or have the ability selectively not to send sensitive data,
> and/or the underlying backhaul must be able to guarantee ENC-level integrity itself (eg tunelling over HTTPS or VPN).
> 
> At run time (and possibly at compile time) it must be possible to discover the maximum data frame size possible
> with the selected transmission parameters.
> 
> Note that for higher integrity levels suitably-sized keys may have to have been pre-shared for example,
> and any modes not supported by the concentrator may have to be removed to the 'available' list.
> 
> At run time it should be possible to specify above parameters with each frame to send from leaf,
> and those parameters plus some associated values (eg sequence numbers/range) should be recoverable.
> Data that fails integrity checks is in normal circumstances not available nor are crypto keys used,
> though parameters such as algorithm and strength may be).
> 
> Note that key, IV, etc lengths that are acceptable in 2015 may prove inadequate to future;
> to some extent that is implicitly dealt with outside this definition by the key-sharing mechanism,
> but frame size limits may ultimately limit available security.
> 
> See also:
> http://blog.cryptographyengineering.com/2011/11/how-not-to-use-symmetric-encryption.html
> http://crypto.stackexchange.com/questions/7951/aesctrhmac-encryption-and-authentication-on-an-arduino
> http://www.cs.berkeley.edu/~jaein/papers/cs294_9_paper_fec.pdf
> http://packetpushers.net/ipsec-bandwidth-overhead-using-aes/
> http://nordsecmob.aalto.fi/en/publications/theses_2008/thesis_gabrielalimon_tkk.pdf
> http://www.iacr.org/workshops/fse2010/content/slide/Fast%20Software%20AES%20Encryption.pdf
> http://tools.ietf.org/html/rfc4106
> Public domain uNaCl crypto for AtMega: http://munacl.cryptojedi.org/ and https://cryptojedi.org/papers/avrnacl-20130514.pdf
> https://github.com/kokke/tiny-AES128-C (public domain)
> http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-38A.pdf
> 
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
> 
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev