[Opendnssec-user] entropy source for SoftHSM

[Alex Omgovitskij]

Hi,

The reason I'm looking into SoftHSM - it's free :). and SoftHSM in
connection with TRNG is cheaper, then real HSM.
Also according to
http://www.opendnssec.org/wp-content/uploads/2011/01/A-Review-of-Hardware-Security-Modules-Fall-2010.pdf
HSM key storage capacity is not large:
AEP Keyper: 8000 1024-bit RSA keys
Safenet Luna: 1200 2048-bit RSA keys
Thales nShield: Very limited on board NVRAM storage, only recommended if
legally required. Unlimited software key storage in the Security
World/Remote File System.
Utimaco CryptoServer: 5000 1024-bit key pairs per HSM, 1500 key pairs per
PKCS#11 token.

I'm not sure how many zones we will sign by the same keys (let's say we
have 100.000 zones to sign) - there are a lot of questions to answer still.
by the way - any recommendations?

Thus SoftHSM or SoftHSM + TRNG is a good choice for now, we can add TRNG
later or even add HSM later if required.
So the question still actual (to foresee future changes in hardware): is it
possible to use SoftHSM + TRNG?



Regards,
Alex


On 13 May 2014 19:09, Rick van Rein <rick at openfortress.nl> wrote:

> Hello,
>
> > This source:
> http://www.enisa.europa.eu/activities/Resilience-and-CIIP/networks-and-services-resilience/dnssec/gpgdnssec/at_download/fullReportsays:
> >        >The random number generator for the system should pass the NIST
> SP 800-22rev15 test
>
> Adding a bit more context that is:
>
> "A means for creating a secure backup of the keys used by the system must
> be provided, together with the option for key generation in a separate
> environment. Depending on the security requirements of the domain holder, a
> hardware security module (HSM) could be required for the signing system. In
> addition, requirements might be set to conform to the specified Security
> Requirements for Cryptographic Modules, Federal Information Processing
> Standards 140 (FIPS) level4. The random number generator for the system
> should pass the NIST SP 800-22rev15 test."
>
> Although ambiguously formulated, I read the last sentence as par of the
> “In addition" to the “depending on” constraint of a Hardware Security
> Module, just as I said ;-) and it is considered optional.  I would first
> consider replacing SoftHSM with an HSM before worrying about random number
> generations.
>
> Come to think of it, SoftHSM is a bit of a misnomer — it might have been
> better to call it SoftSM :) but nobody would have understood it then.
>
> -Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20140514/4df5560a/attachment.htm>