[manuf] Handling of attestation seed values is not FIPS 186-5 compliant

[RyanTorok]

Description

The procedure to derive the ECDSA private key used for attestation at each of the three Key Manager boot stages (Creator Identity, Owner Intermediate, Owner Identity) includes a seed value from CSRNG in addition to the secret that is sideloaded from the Key Manager. As described here, this additional seed is not intended to add any additional security on top of what Key Manager provides, but is primarily used for compliance with FIPS 186-5, which prohibits key derivation for asymmetric keys unless the derivation input is XORed with a random string generated by a DRBG initialized with manufacturing-time entropy.

In order to remain in compliance, this random seed from CSRNG must be re-generated every time the attestation private key is derived. In order to enable this, the doc linked above outlines the following rough procedure:

1. At provisioning-time, use the onboard entropy source to generate 256 bits of entropy (the "factory entropy") and store it in a flash info page (bank 0, type 0, page 4 is currently used by the provisioning firmware).
2. Each time the attestation key is derived, read the factory entropy from the flash info page and use it to re-initialize the CSRNG HWIP block, and instruct it to not accept any additional seed data from the entropy source, so its output will be deterministic.
3. Have CSRNG generate the seed value and store it in OTBN DMEM.
4. The seed is later used together with the sideloaded secret from Key Manager to derive the attestation key.

However, the current provisioning firmware does not follow the above procedure. Instead of storing the factory entropy in flash at step 1, it immediately re-initializes CSRNG with the factory entropy, generates the seed, and then stores the seed in flash instead of the factory entropy. Likewise, the current ROM_EXT reads the seed from flash and stores it directly in OTBN without invoking the CSRNG block at all. This method of handling the seed is not compliant with FIPS 186-5 because the use of entropy that is "pre-loaded within the module at factory" as described in FIPS 140-3 applies only the entropy used as input to the DRBG used for randomly generating asymmetric keys in FIPS 186-5, not to the output of the DRBG.

The provisioning firmware and ROM_EXT should be updated to store the factory entropy (pre-CSRNG), not the seed (post-CSRNG) in flash. This means the CSRNG seed generation should occur in ROM_EXT every time an attestation private key is generated.

Relevant code blocks:

Provisioning firmware ROM_EXT

Adding @jadephilipoom and @timothytrippel for visibility