[cabf_netsec] draft ballot proposal re: HSM firmware updates

[Fotis Loukos]

On 14/11/2017 06:32 πμ, Josh Aas wrote:
> Thanks for the feedback. Responses inline.
> 
> On Fri, Nov 10, 2017 at 2:45 AM, Fotis Loukos <fotisl at ssl.com> wrote:
>> On 09/11/2017 06:09 μμ, Josh Aas via Netsec wrote:
> 
>>> In the Baseline Requirements, ADD the following definition to Section
>> 1.6.1:
>>>
>>> Cryptographic Module Validation Requirements: FIPS 140 level 3 or an
>>> appropriate Common Criteria Protection Profile or Security Target, EAL
>>> 4 (or higher)
>>
>> I think that the name is a little bit misleading, since NIST already has
>> the Cryptographic Module Validation Program whose requirements are the
>> whole FIPS 140-2. Someone who will just read the text without getting to
>> the definitions may think that any FIPS 140-2 validated HSM can be used,
>> no matter what level.
> 
> This doesn't seem very misleading. They're different phrases made up
> of standard words. If someone is making decisions like buying HSMs
> based on a casual reading of the BRs they're going to have a lot of
> problems besides what HSMs they end up with.

I would totally agree with you, if CAs and browsers were the only target
audience of the BRs :)
This was just a recommendation, for me it's pretty clear the way it is.

> 
>>> In the Baseline Requirements, REPLACE the entire text of Section 6.2.7
>>> with the following:
>>>
>>> The CA SHALL protect its Private Key in a system or device meeting the
>>> Cryptographic Module Validation Requirements, or a device that meets
>>> all of the following criteria:
>>>
>>> 1) The physical device (excluding firmware) meets the Cryptographic
>>> Module Validation Requirements.
>>
>> You could use FIPS 140-2 language here and also add EMI/EMC. I think
>> that "The system or device meets the Cryptographic Module Validation
>> Requirements in the areas of physical security and electromagnetic
>> interference/electromagnetic compatibility" is better. And I do not
>> think that you have to exclude the firmware since it is not included in
>> these two areas per FIPS 140-2.
> 
> Your language would probably work but I think my original language is
> more clear. Seems easiest to say that you should have a FIPS 140-3
> physical device (firmware aside, since we're talking about loading
> non-validated firmware) in order to make sure all bases are covered.

According to FIPS 140-2, there are eleven different areas of validation.
If you check the certificate of any cryptographic module, you will see
that there is a different level in every area. How do you define
'Physical device (excluding firmware)'? Is the example of EMI/EMC
included in the 'physical device (excluding firmware)'? If you have an
HSM which conforms to level 3 in physical security (as defined in FIPS
140-2) and to level 2 in EMI/EMC, are you allowed to use it? That's why
I argue that it's best to use FIPS 140-2 areas, somebody can just get
the certificate and check the areas that interest him.

> Also, I don't know what FIPS 140-2 has to do with anything, did you
> mean FIPS 140-3?

I am talking about FIPS publication 140-2 by NIST, the latest version in
the 140 publication series. As far as I know FIPS 140-3 was a big fail,
so NIST is going to issue FIPS 140-4. Are you confusing the version of
the publication with the level of security?

Regards,
Fotis

> 
>>> 2) There is firmware available for the device that meets the
>>> Cryptographic Module Validation Requirements.
>>> 3) There is at least one known vulnerability, which the CA feels the
>>> need to address, in the latest firmware for the device.
>>
>> Should this be "in the latest firmware for the device that meets the
>> Cryptographic Module Validation Requirements" ? Otherwise I don't think
>> that you will be able to use this as is, since once the vulnerability
>> becomes known the HSM vendor creates an updated firmware (which is the
>> latest firmware) that patches it. I don't think that any vendor would
>> have a known vulnerability at his latest firmware.
> 
> You're right, good catch. I've fixed it in my draft.
> 


-- 
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fotisl at ssl.com
w: https://www.ssl.com