<div dir="ltr"><div>Hi,<br></div><div><br></div><div>The reason I'm looking into SoftHSM - it's free :). and SoftHSM in connection with TRNG is cheaper, then real HSM.</div><div>Also according to <a href="http://www.opendnssec.org/wp-content/uploads/2011/01/A-Review-of-Hardware-Security-Modules-Fall-2010.pdf">http://www.opendnssec.org/wp-content/uploads/2011/01/A-Review-of-Hardware-Security-Modules-Fall-2010.pdf</a>  HSM key storage capacity is not large:</div>

<div>AEP Keyper: 8000 1024-bit RSA keys </div><div>Safenet Luna: 1200 2048-bit RSA keys </div><div>Thales nShield: Very limited on board NVRAM storage, only recommended if legally required. Unlimited software key storage in the Security World/Remote File System. </div>

<div>Utimaco CryptoServer: 5000 1024-bit key pairs per HSM, 1500 key pairs per PKCS#11 token.</div><div><br></div><div>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?</div>

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

<div><br></div><div><br></div><div><br></div><div>Regards,</div><div>Alex</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 13 May 2014 19:09, Rick van Rein <span dir="ltr"><<a href="mailto:rick@openfortress.nl" target="_blank">rick@openfortress.nl</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<div class=""><br>
> This source: <a href="http://www.enisa.europa.eu/activities/Resilience-and-CIIP/networks-and-services-resilience/dnssec/gpgdnssec/at_download/fullReport" target="_blank">http://www.enisa.europa.eu/activities/Resilience-and-CIIP/networks-and-services-resilience/dnssec/gpgdnssec/at_download/fullReport</a> says:<br>


>        >The random number generator for the system should pass the NIST SP 800-22rev15 test<br>
<br>
</div>Adding a bit more context that is:<br>
<br>
"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."<br>


<br>
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.<br>


<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Rick</font></span></blockquote></div><br></div>