[cabfpub] CA key generation, storage, and FIPS
philliph at comodo.com
philliph at comodo.com
Tue Oct 11 18:05:56 UTC 2016
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> 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>
> https://cabforum.org/mailman/listinfo/public <https://cabforum.org/mailman/listinfo/public>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public