[riot-notifications] [RIOT-OS/RIOT] ieee802154_security: Nonce is reused after reboot (#16844)

chrysn notifications at github.com
Tue Sep 14 11:35:27 CEST 2021


I don't see a full story from it, but maybe ...

If we went for an entropy approach, its nose component could help to make sure there's enough of it. (At least in cold starts; do we have something to carry over in warm starts?). But no matter how good our source of randomness after a million messages with many reboots inbetween (5 byte = 40 bit ~= 1000**4, at sqrt(n) we have good birthday chances) it still becomes likely. No standard says that these *can* be random, but outside 6TiSCH I don't think any implementation has hard requirements on the numbers being ascending either (I'm unaware of any monotony based replay protection, but then again I don't know many 6lo implementations in the first place).

The PUF itself, as I understand it, would only give us more data that doesn't change across reboots (like the key and the LL address already do).

Hm ... I wouldn't see random initialization at startup as a solution to the whole problem, but given that the full solution will need long-term work, it might be a band-aid worth putting on.

(Also, running the numbers made me look into flash cycles -- on nrf52 with a 2-page persistence area we get 20k erase cycles * 256 writable words ~= 4 million reboots; I hope to optimize soft reboots so that only hard reboots need flashing. So the randomness approach is probably even practical, but still I wouldn't want to declare it as "just use it that way").

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/issues/16844#issuecomment-918984215
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210914/380ca2c4/attachment-0001.htm>


More information about the notifications mailing list