[OpenTRV-dev] Very basic backhaul thoughts
Jeremy Poulter
EMAIL ADDRESS HIDDEN
Thu Apr 16 12:12:10 BST 2015
Hi,
> Thanks for that thought, and I was already trying to prune options, but
maybe did not try hard enough!
Always happy to provide my 2p worth ;-)
> ENC generally does NOT imply authentication and allows all sorts of
unpleasant attacks in my understanding.
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.
> If the underlying comms medium is secure though I think that NONE may be
handy but maybe not enough to justify a separate option.
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?
Cheers,
Jeremy
On 9 April 2015 at 19:42, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
> 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
>
> _______________________________________________
> 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/20150416/34371e5a/attachment.html>
More information about the OpenTRV-dev
mailing list