[OpenTRV-dev] Very basic backhaul thoughts

[Damon Hart-Davis]

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