[OpenTRV-dev] Significant additonal definition of counters in nonce/IV construction section

[Damon Hart-Davis]

With a view specifically to avoiding IV reuse.

http://www.earth.org.uk/OpenTRV/stds/network/20151203-DRAFT-SecureBasicFrame.txt




Note on nonce/IV construction and counter use:

The nonce is 6 (six) leading bytes of ID,
then 3 (three) bytes of restart counter,
then 3 (three) bytes of message counter.

The main complication in terms of what goes over the wire is:
  * at least the first six (6) bytes of the ID are pre-shared
    and forming the leading part of the IV/nonce,
    with that part sent in the header a prefix into the remainder,
    preferably unique else all candidates have to be tried,
  * the rest of the nonce has to be assembled from (or dispersed to)
    parts of the header and trailer.

The restart/reboot count must be incremented by at least 1 on each restart
of the system generating the frames*, and also whenever the message
counter overflows/wraps.  The restart/reboot counter at least should
be persisted in a non-volatile memory at sender and recipient and any
intermediate authenticating stages such as a lightweight concentrator or
relay.  All messages received with a number no higher than the last
authenticated frame received should be rejected to prevent replay attacks.
The least significant bytes of the restart/reboot and message counters
may be initialised to a random seed (with real entropy) rather than zero,
eg of the message counter on each restart, but the most significant byte
of the restart count at least  must be initialised with zero to avoid
sacrificing too much of the key lifetime.  Once the maximum value of the
the concatenation of restart/reboot and message counters is reached no
more messages can be authenticated/sent with the associated key and a
new key must be created and shared if data needs to be sent.

*Note: if one or more of the most significant bytes of the message count
can be persisted by the sender in non-volatile store, and the sender
needs to be restarted frequently and to send more than 2^24 messages on
the associated key, eg for a device driven by harvested energy and sending
one authenticated frame per restart, then the those more significant bytes
logically become part of the reset count, transparently to the recipient.
At all times the aim is to ensure that no IV/nonce is ever reused with a
new plaintext (other than an exact immediate retransmission of a frame to
overcome transmission losses where repeats may be and should be dropped).