> > We have a similar situation, on a small hardware device with little > own entropy > > but with a smartcard reader. > > Yes, but in most cases you cannot count on the smartcard (or smartcard-like > device) being in the reader. > Which is why in my opinion this is an ideal case for “additional input” > source, but rather poor as the > “main” entropy source. > > ... > > > We implemented a get_entropy() call which fetches the entropy via > PKCS#11, and > > modified the rand_method such that RAND_DRBG_generate() is always > called with > > prediction_resistance=1. So every generate() triggers a reseed(), the > entropy is fetched > > from the smartcard and it is immediately postprocessed by the AES-CTR > DRBG. > > The /dev/urandom device was only used as additional input. > > So we didn't feel the need for an extra API call. > > I would do exactly the opposite. “Normal” entropy is fetched from the default > sources (/dev/urandom). But > when a sensitive (aka long-term) keys are generated, a (portable :) hardware > RNG is plugged in and used with > RAND_add() equivalent. Reason – in my setup reliable trusted hardware RNG is > not always on. If it were, I’d > use it as the main entropy source and be done with it.
In general, I would agree with you. In our case, it was a requirement of the government to trust only the SmartCard RNG. Since we use it for VPN connections with SmartCard authentication this was no problem, because the SmartCard must be present in order to initiate the IKEv2 exchange. The only tricky part was to deal with temporary failures of the entropy source. Matthias
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
