[OpenTRV-interest] Final fiddling with secureable frame format

[Damon Hart-Davis]

Hi,

In trying to make it easier to reject grossly mangled frames before expensive crypto (or even CRC) computations, I’ve changed the trailer spec slightly to guarantee that the final trailer byte, which is also the final frame byte, is neither 0x00 nor 0xff.  Note that for non-secure frames the CRC spec already guarantees that, so I’m getting more value from that lack of redundancy.

Obviously mangled frames, eg from drop-out with an OOK carrier, should now be somewhat easier to spot quickly.

(Note that I assumed that malicious manging of secure frames cannot be reliably spotted without crypto.)

For the ‘O’ basic frame type, when secure, because the AES IV and tag are binary and all bytes can have all values, this necessitates moving the trailer type byte from the beginning to the end instead, which can be defined never to be 0x00 nor 0xff, which means I’ll have to rework Matthew W’s test cases!

Also, I’ve relaxed the requirement for a minimum number of ID bytes for secure frames, specifying that if less than 6 are transmitted in the header then the rest have to be pre-shared, eg along with the key.  If there is ambiguity given the length of ID prefix sent, ie multiple IDs match whatever ID prefix is transmitted, potentially all keys for IDs matched by that prefix could be tried, which also allows anonymous (zero-length) secure transmissions in some scenarios which could be useful, eg like no-SSID WiFi access points).  However, this clearly may place a heavy burden on the receiver, and may allow easier DoS attacks, so its use would generally be constrained.

Happy New (adjusted) protocol!  B^>

Rgds

Damon