Further integration of HMAC DRBG

[andrewkozlik]

We would like to use the HMAC DRBG as a source of random numbers in more places than just generating random delays. Eventually we would like to use it for everything, assuming the DRBG would be reseeded before generating security-critical values.

1. Determine where the DRBG can be used safely as is without reseeding, e.g. generating nonces, and make the replacements.
2. Ensure periodic reseeding of the DRBG from the TRNG.
3. Add more sources of randomness. These could be the value of the system clock at certain moments, e.g. user interaction.

As for 1., below is some preliminary research on where we could replace the TRNG with the DRBG right away:

random32():

• storage mask NO
• u2f keypath YES

random_buffer():

• storage salt YES
• storage keys NO
• storage IVs YES
• crypto bip39 NO
• crypto monero random_scalar ?
• modtrezorcrypto generating private keys in secp256k1 etc. NO
• legacy UUID YES
• legacy fsm_msgGetEntropy NO
• legacy nem salt and IV YES
• legacy reset int_entropy NO
• legacy OTP hardware entropy NO

random_uniform():

• storage guard key NO
• legacy recovery YES

random_permute():

• legacy pinmatrix YES
• legacy recovery YES

random.uniform():

• u2f channel ID YES
• u2f keypath YES
• reset_device check YES

random.bytes():

• reset_device internal_ent NO
• slip39 master secret and shares NO
• slip39 identifier YES
• get_entropy NO
• passphrase cache salt YES
• storage.py device_id YES
• nem/monero salt, IV and nonce YES

[keepkeyjon]

Why is it preferable to use the DRBG over using the TRNG in as many places as possible?

[andrewkozlik]

There are two reasons:

1. There is the recent freezing bug, which was apparently caused by reading from the TRNG before USB operations. It has something to do with I2C, I am not familiar with the details. To avoid this reocurring, it would be best to limit use of the TRNG especially when generating things like IVs, which do not require secrecy.
2. The advantage of the DRBG is that you can feed it multiple sources of entropy including the random data from the TRNG. This is a precaution in case the TRNG produces random numbers with lower entropy than it should or if it becomes biased as the hardware ages. It also makes things more difficult for attackers who are aiming to control the random numbers generated by the device. If entropy is taken from a single source such as the TRNG, then the attacker needs to disable only that one source.

[keepkeyjon]

Ah, great points. Thanks for explaining!

[alex-jerechinsky]

ping @onvej-sl