As an alternative to #22121 it is possible to implement software DRBG which will be used to separate in time preparation of DRBG for key generation and actually using it.
Viable implementations of sw DRBG would be either CTR_DRBG or HASH DRBG
(since HW HMAC SHA256 is not SCA hardened, and KMAC/cSHAKE are not yet approved for DRBG construction by NIST and we are looking forward for FIPS certification, and HMAC-SHA3 seems to be not supportedl).
DRBG shall have a property to be seeded in hw-bound mode. It is impossible to use hw_backed keys directly for instantiation (both CTR_DRBG & HMAC_DRBG use fixed key for instantiation, so hw_backed mode will probably be achieved by mixing some derivation of hw_backed key as an entropy input (e.g. kmac(hw_backed key, diversification string) ). Since we want FIPS, we need to ensure that entropy part qualifies for being called entropy and it should come from either properly seeded DRBG or key derivation:
NIST 800-90A, 8.6.3: The entropy input shall have entropy that is equal to or greater than the security strength of the
instantiation
NIST 800-90A, 8.6.5: An approved randomness source is an entropy source that conforms to [SP 800-90B], or an
RBG that conforms to [SP 800-90C] − either a DRBG or an NRBG.
Practically it means we need an API to:
a. Get raw entropy for instantiation of SW DRBG in random mode (should be added).
b. API to seed CSRNG from SW DRBG (exists, but need a new call for convenience)
To support deterministic key gen for hw-bound keys we will need to store entropy on flash after first generation and used it later. While doable it doesn't seem to be very reasonable. Using anything produced by key manager seems to not satisfy NIST requirements on entropy.
Solution that will construct seed for:
entropy, generated once and stored on flash
derivation of hw_baked key
personalization string with additional data
Will need careful management of entropy stored on flash, potentially moving its creation to some early stage.
Description
As an alternative to #22121 it is possible to implement software DRBG which will be used to separate in time preparation of DRBG for key generation and actually using it. Viable implementations of sw DRBG would be either CTR_DRBG or HASH DRBG (since HW HMAC SHA256 is not SCA hardened, and KMAC/cSHAKE are not yet approved for DRBG construction by NIST and we are looking forward for FIPS certification, and HMAC-SHA3 seems to be not supportedl).
DRBG shall have a property to be seeded in hw-bound mode. It is impossible to use hw_backed keys directly for instantiation (both CTR_DRBG & HMAC_DRBG use fixed key for instantiation, so hw_backed mode will probably be achieved by mixing some derivation of hw_backed key as an entropy input (e.g. kmac(hw_backed key, diversification string) ). Since we want FIPS, we need to ensure that
entropy
part qualifies for being calledentropy
and it should come from either properly seeded DRBG or key derivation: NIST 800-90A, 8.6.3: The entropy input shall have entropy that is equal to or greater than the security strength of the instantiation NIST 800-90A, 8.6.5: An approved randomness source is an entropy source that conforms to [SP 800-90B], or an RBG that conforms to [SP 800-90C] − either a DRBG or an NRBG.Practically it means we need an API to: a. Get raw entropy for instantiation of SW DRBG in random mode (should be added). b. API to seed CSRNG from SW DRBG (exists, but need a new call for convenience)
To support deterministic key gen for hw-bound keys we will need to store entropy on flash after first generation and used it later. While doable it doesn't seem to be very reasonable. Using anything produced by key manager seems to not satisfy NIST requirements on entropy.
Solution that will construct seed for:
Will need careful management of entropy stored on flash, potentially moving its creation to some early stage.