Actually, I realized that a call to FIPS_drbg_reseed() is pointless if FIPS_drbg_instantiate() had failed. Instead, the call would need to redo FIPS_drbg_instantiate() after ensuring the default DRBG is properly seeded.
On Fri, May 30, 2014 at 12:02 PM, Kevin Fowler <kevpfow...@gmail.com> wrote: > 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 >
