[OpenTRV-dev] Very basic backhaul thoughts
Jeremy Poulter
EMAIL ADDRESS HIDDEN
Thu Apr 9 16:17:07 BST 2015
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20150409/f5426391/attachment.html>
More information about the OpenTRV-dev
mailing list