[cabfpub] CA key generation, storage, and FIPS

Myers, Kenneth (10421) kenneth.myers at protiviti.com
Tue Oct 11 11:20:58 MST 2016

Afternoon everyone,

Unofficial response from a POC at NIST.

One option would be to try to find a FIPS 140 validated module that has been validated for 4096-bit RSA signature generation. As noted, it would have to be an older module. However, according to http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__csrc.nist.gov_groups_STM_cavp_documents_dss_rsanewval.html&d=DQMD-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=KN8HhW0WEBuvSMiTkEnQZSLpF-Ub76Wqwy5C7PGeRkk&s=6jgA5x5mNPj0RQY3Li5BIWyswn_uOennnasUUOWbzK4&e=>, implementations of FIPS 186-2 key and signature generation are being allowed in algorithm implementation of some modules undergoing revalidation. In the future, this will be less of an issue, as NIST is planning to allow the use of longer RSA key sizes again at some point in the future. Unfortunately, I don't have a time line for when the change will be made to allow CAVP to start validating 4096-bit RSA key generation and signature generation again.

A cryptographic module may implement 4096-bit key generation and signature generation even if its implementation cannot be validated at those key lengths. So, given that the Baseline Requirements do not have to conform to FIPS, using a FIPS 140 Level 3 module that implements 4096-bit RSA, but has not been validated for that key length may be an option. If the module has an RSA algorithm certificate for shorter key lengths, and uses the same code for key generation and for signature generation for 4096-bit keys as for the validated key lengths, then there is some confidence in the implementation.

Also, Section 6.2.7 is about key protection, and those requirements are independent of the lengths of the keys used. FIPS 140 Level 3 validated modules are required to have both physical and logical protections for the keys that are stored within them. While an HSM may not store private keys long-term, it would need to protect the private key while in use. In addition, the HSM may have a long-term symmetric key that it uses to wrap/unwrap the private keys, and this symmetric key would need to be well protected as anyone obtaining that key along with a copy of the encrypted private key could obtain the plaintext private key.


From: philliph at comodo.com [mailto:philliph at comodo.com]
Sent: Tuesday, October 11, 2016 14:06
To: Robin Alden <robin at comodo.com>
Cc: Peter Bowen <pzb at amzn.com>; CABFPub <public at cabforum.org>
Subject: Re: [cabfpub] CA key generation, storage, and FIPS

This likely dates from the time that NIST had decided to EOL the RSA algorithm and push everyone towards Elliptic Curves. Now that Quantum is looming as a more likely threat than a new factoring technique they are rowing back in the opposite direction.

FIPS can be changed. I suggest that CABForum make an official request for such a change.

In the longer term, what we really need is to decouple from the FIPS. WebPKI is a much bigger use case than US Government crypto these days and it is likely to be moving in different directions.

On Oct 11, 2016, at 8:12 AM, Robin Alden via Public <public at cabforum.org<mailto:public at cabforum.org>> wrote:

Hi Peter,

-----Original Message-----
Peter Bowen said on 30 September 2016
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 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?

That would certainly be a very convenient interpretation, but I don't think it can be correct.
If an HSM has a FIPS mode and a non-FIPS mode, I think we should use the FIPS mode to be compliant.
Presumably if it is operated in non-FIPS mode all bets concerning the security of the HSM are off.

I can see Jos's point that it should be possible to do "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", but that sounds a 'Hard Thing', and not something that a common-or-garden WebTrust (or ETSI) auditor would be keen to opine upon, let alone for a humble CA to do so.

Perhaps we should be talking with HSM vendors about how they achieve recent FIPS 140-2 validation whilst supporting RSA 4096.
Do NIST check for 4096 bit RSA implementations and reject them where they find them, or do they merely not test key sizes > 3072?

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)?

I don't think it should.
If the non-validated device has the key available to it in order for it to create a signature then I think you have to demonstrate to your auditor how the key is protected while in that non-validated device.
The AES-256 encryption while the key is in motion sounds good, but only if the KEK is itself protected in accordance with 6.2 - which I don't think would be the case if it is available to an online non-validated device.

We had discussions in past years about using CA keys outside validated devices, i.e. other than in HSMs that meet 6.2.7.
It is probably possible to do it securely, but it's not something we can codify in a few paragraphs without reference to reasonably widely accepted standards such as FIPS 140-2.

I agree with Jos that it would be good to see something from FIPS that extends 180-2 to longer key lengths.

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.

There isn't a requirement to store CA keys _in_ an HSM.
My understanding is that the 'validated system' reasonably includes storage of CA keys in a 'Security World' on disk or elsewhere encrypted to comply with 6.2 provided that decryption of that Security World, or the extraction of the CA keys in any form, is not possible other than through the HSM as designed and using its FIPS-validated capabilities .
I'm aware that the term 'Security World' is used by one HSM maker in particular, but the concept of an encrypted store being logically 'within' the validated system is common across a number of HSMs.

Robin Alden

Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>

NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20161011/c6fcc0dc/attachment-0001.html>

More information about the Public mailing list