Using FIPS-capable OpenSSL on an embedded system with low entropy collection rates. Several processes startup during system startup, each loading libcrypto. Per latest IGs, modified to run self-tests on library load, requiring OPENSSL_init() call and, hence, DRBG instantiation. It is possible that insufficient entropy has been collected by the kernel as the last few of these processes startup, causing the seeding of the FIPS DRBG to fail during FIPS_drbg_instantiation().
The FIPS DRBG is seeded with calls to ssleay_rand_bytes(), so the problem is really that the default DRBG (rand_ssleay_meth) did not collect enough entropy from /dev/random. The default DRBG can be seeded "later" with additional entropy using RAND_add/RAND_seed, but I have not seen an existing method for then seeding the FIPS DRBG with good (read: properly seeded default DRBG bytes) "entropy". It seems that some additional code is needed to call directly the FIPS_drbg_reseed(). The problem, I suppose, is knowing when to do this reseed. If, at some later time, a RAND_status() call indicates a bad DRBG (whether it is calling the rand_ssleay_meth or the rand_drbg_meth status() version), then that caller could try to read sufficient bytes from /dev/random; if successful, add that to the default DRBG with RAND_add(); and, then call FIPS_drbg_reseed() to properly seed the FIPS DRBG. This depends of course on enough entropy being collected to read enough (32 bytes) from /dev/random to successfully seed the default DRBG. The easiest answer, and one I see in multiple places here, is to boost the initial entropy collection rate so there is sure to be enough to seed every instance of the default DRBG at the first try. Alternatively (or concurrently), to reduce the drain on collected entropy during startup by ensuring only essential processes are consuming /dev/[u]random bytes. Interested in whether anyone has experienced situations where the rate-boost and/or drain-limit approach was still not enough to dependably get all DRBGs seeded, and how that was worked around to re-seed after more entropy had time to collect. Or if the consensus is "don't do that - FIPS_drbg_reseed() is only there for the self-tests to use...". Thanks, Kevin
