U2F Zero key derivation algorithm could be explained in more detail

[vojnovski]

Currently, without doing a full analysis of the code, the key derivation algorithm used is not evident.

Something akin to https://developers.yubico.com/U2F/Protocol_details/Key_generation.html might be a good addition to the documentation.

Furthermore, it might be good to explain that the u2f fob programming should be done on a secure environment as the master key is generated there and then subsequently copied to the EFM8 and the ATECC.

#38 and #66 talk about this as well, and resources from there can be reused for documentation.

[vojnovski]

While here, couldn't the master key generation have been done on-device? RMASK/WMASK could then have been also calculated on-device and sent back to the client script, in order to be incorporated in the final firmware.

[gdamjan]

or alternativly, just left in a know place on the flash memory to be reused by the firmware which could then be generic.

[conorpp]

I remember using that diagram as a reference when I did the key derivation. The algorithm is very similar, doing a HMAC using a device secret, AppID, and random number.

I agree with your point about having a secure environment for key generation.

I'm planning to update the documentation later this weekend.

[conorpp]

@vojnovski yes key generation could be done on the device instead. The hardware number generator on the ATECC508 is cryptographically based on a tamper resistant seed. So if how Atmel set that seed up was to get compromised somehow, than at least key generation would still be secure since other RNG numbers were mixed in at the start. At least, that was what I was initially thinking. A user's computer getting compromised during programming might be more likely :)

[szszszsz]

Hi! Here is our work-in-progress attempt to document the process: security_architecture.md. Any feedback appreciated!

(except some of the source code references, it should be the same with U2F-Zero)

Edit: merged to master