[keymgr] `RootKey` from OTP shall be a FIPS-key

[vsukhoml]

Description

This is less technical, but more a manufacturing/owner transfer requirement, require supporting documentation for evaluation.

If we want to rely on keymgr's sideloading, we need to be able to prove that whatever we provision as RootKey can be considered a FIPS key, and so all its derivations using KMAC.

NIST SP 800-133 in 3.1-3.2 says:

Key generation includes the generation of a key using the output of a random bit generator (RBG),
the derivation of a key from another key, the derivation of a key from a password, and key
agreement performed by two entities using an approved key-agreement scheme. All keys shall be
based directly or indirectly on the output of an approved RBG. For the purposes of this
Recommendation, keys that are derived during a key-agreement transaction (see SP 800-56A and
SP 800-56B), derived from another key using a key derivation function (see SP 800-108), or
derived from a password for storage applications (see SP 800-132 and Section 6.5) are
considered to be indirectly generated from an RBG since an ancestor key or random value (e.g.,
the random value used to generate a key-agreement key pair) was obtained directly from the output
of an approved RBG.

Cryptographic keys shall be generated within FIPS 140-validated cryptographic modules. For
explanatory purposes, consider the cryptographic module in which a key is generated to be the
key-generating module. Any random value required by the key-generating module shall be
generated within that module; that is, the RBG (or portion of the RBG) that generates the random
value shall be implemented within the FIPS 140 cryptographic module that generates the key. The
generated keys shall be transported (when transportation is necessary) using secure channels and
shall be used by their associated cryptographic algorithm within FIPS 140-validated cryptographic
modules.

So, when relying for keymgr output we would need to be able to prove that the requirements above are met, and that keys in OTP indeed came from FIPS DRBG, which was seeded with FIPS entropy.

Alternatively, we shall not use keymgr output as a key directly, and instead mix it output into DRBG used for keygen as personalization string without any security claims.

[vsukhoml]

@timothytrippel , this practically means following things shall be done during personalization:

1. Run KAT for KMAC with same parameters used by key manager (#22297)
2. Run KAT for CSRNG to make sure it is a DRBG
3. Run KAT for conditioning function in entropy source #22323
4. Configure health checks for entropy source in accordance with measured entropy (#22320), also #2111, #19392.
5. Generate key from CSRNG

[timothytrippel]

Thanks for the summary @vsukhoml . I added the "Manufacturing" label and the "OpenTitan" project so it will show up in the manufacturing task board where we are tracking provisioning-related tasks.