[Opendnssec-user] entropy source for SoftHSM

[Klaus Darilion]

I do not know about TRNG. We use haveged which feeds its entropy into
the Linux kernel (necessary on virtual servers to get entropy)

regards
Klaus

On 14.05.2014 14:05, Alex Omgovitskij wrote:
> 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
> 
> 
> 
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
>