[cabfpub] CA key generation, storage, and FIPS

[Jos Purvis (jopurvis)]

This is something I've wondered about for a while, and I would hope we see some updates to FIPS to encompass longer key lengths rather than just "hold with what we've got until we figure out post-quantum".
> Is the correct interpretation that you need the cryptographic module to have been certified as meeting FIPS 140 Level 3 but the CA can operate it in non-FIPS mode?  

My understanding of the BRs is yes, that would fly. That would necessarily involve doing the due diligence to ensure that FIPS validation remains current even when not in use directly, and that operating in non-FIPS mode doesn't meaningfully compromise the security of the key material and HSM, something a good auditor should review.
	It would probably help to clarify that specifically in the BRs, but carefully: we don't want to open the door to just using any device that passed FIPS validation at some point in its lifecycle so long as you feel you've done sufficient risk analysis. Maybe a second sentence in 6.2.7 like this:
'For the purposes of BR compliance, a device currently validated as meeting FIPS 140 level 3 or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher) but not operating with those strictures enabled (e.g. a FIPS-validated HSM operating without FIPS mode enabled) shall be considered a Validated Device, so long as the CA has reviewed the device to ensure its validation is current and that running in non-compliant mode does not compromise the protections around the key material.'
Would that clear up the question, or just muddy the waters further?

> Can the CA use the cryptographic module to encrypt the private key, using AES-256 or another FIPS approved algorithm, for storage but unwrap/decrypt to do the generation and signature creation in a non-validated device (as implied in 6.2)?

> And what does it mean to protect a private key _in_ a validated system or device, anyway?  Some HSMs are not designed to store keys, just wrap/unwrap and use keys.

It sounds like you're wondering whether a non-validated system[0] (e.g. a software CA) could pass a validated device the encrypted key-blob and the validated device would hand back the decrypted key for the non-validated system to do generation and signing with in system memory, so long as the HSM re-encrypts the key prior to storing it on physical media. That is, the HSM is used as a passthrough to encrypt/decrypt the key between the storage media and the software CA in memory. Am I understanding that right?
	If I'm getting that right, my understanding of the BRs says that wouldn't fly: 6.2.7 requires protecting the private key for the CA, and the software CA's system memory is presumably not a "validated device or system". 6.2.7 to me says the key in unwrapped form should only exist inside the Validated Device, and if the key then is to be exported outside the Validated Device boundary it must be encrypted. However, 6.2 would then permit that the wrapped key can then be stored on a non-validated device, provided the combination of wrapping encryption and physical security meet the 6.2 and 5.2.2 requirements. This would mean that a CA could, for instance, store offline key material in wrapped form on USB sticks or backup tapes protected in a safe, so long as the key was only ever unwrapped and used inside the validated HSM's secure memory.

	--Jos

[0] Where "non-validated" here means "is not certified under FIPS140L3 at all", not "meets FIPS140L3 but is not operating in FIPS mode".

-- 
Jos Purvis (jopurvis at cisco.com <mailto:jopurvis at cisco.com>)
Cryptographic Services | cisco systems
PGP: 0x89a3b545 / 0x07d19105 | +1 919.991.9114 (desk)

> On 29 Sep, 2016, at 19:39, Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
> 
> In reviewing the Baseline Requirements and certain trust store requirements, I ran into a set of questions I’m hoping someone can answer.
> 
> The BRs have several sections that address CA key protection.  The ones I think are relevant are below:
> 
> "The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140 level 3 or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats.” (6.2.7)
> 
> "Protection of the CA Private Key outside the validated system or device specified above MUST consist of physical security, encryption, or a combination of both, implemented in a manner that prevents disclosure of the CA Private Key. The CA SHALL encrypt its Private Key with an algorithm and key-length that, according to the state of the art, are capable of withstanding cryptanalytic attacks for the residual life of the encrypted key or key part.” (6.2)
> 
> "The CA Private Key SHALL be backed up, stored, and recovered only by personnel in trusted roles using, at least, dual control in a physically secured environment.” (5.2.2)
> 
> The challenge I’ve run into is that the US NIST, which publishes the FIPS series, has specified that only only lengths of 512, 1024, and 1536 bits shall be used for p and q in RSA private keys.  This results in public key sizes of 1024, 2048, and 3072 bits.  Due to this, no FIPS 140 validations are being issued which include RSA with 4096-bit public keys.  
> 
> However, 4096-bits is the minimum size required for certain cases by trust stores and, as far as I know, it accepted by all trust stores.
> 
> How do we rationalize this with 6.2.7, given that no module certified more recently than Jan 2014 can generate 4096-bit RSA keys or sign using 4096-bit RSA keys in FIPS mode?
> 
> Is the correct interpretation that you need the cryptographic module to have been certified as meeting FIPS 140 Level 3 but the CA can operate it in non-FIPS mode?  
> 
> Can the CA use the cryptographic module to encrypt the private key, using AES-256 or another FIPS approved algorithm, for storage but unwrap/decrypt to do the generation and signature creation in a non-validated device (as implied in 6.2)?
> 
> And what does it mean to protect a private key _in_ a validated system or device, anyway?  Some HSMs are not designed to store keys, just wrap/unwrap and use keys.
> 
> Thanks,
> Peter
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161010/14464859/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3368 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161010/14464859/attachment.p7s>