[cabf_netsec] draft ballot proposal re: HSM firmware updates

[Fotis Loukos]

Hello Josh,

On 09/11/2017 06:09 μμ, Josh Aas via Netsec wrote:
> NetSec Folks,
> 
> I've been putting together a ballot intended to resolve a conflict
> between the Baseline Requirements and the Network Security
> Requirements while introducing clear guidance on what firmware may run
> on HSMs.
> 
> My draft ballot email is below my signature. The introduction contains
> more background on the problem.
> 
> While I believe the NetSec requirements are essentially correct (you
> should update if you need to do so to address a vulnerability), and
> the BRs need to be fixed, it was recommended to me that I run this by
> the NetSec group for feedback.
> 
> Thanks,
> 
> --
> Josh Aas
> Executive Director
> Internet Security Research Group
> Let's Encrypt: A Free, Automated, and Open CA
>
>
> Ballot ??? - Cryptographic Module Validation Clarification
>
> This ballot is intended to resolve a conflict between the Baseline
> Requirements and the Network Security Requirements while introducing
> clear guidance on what firmware may run on HSMs. The following motion
> has been proposed by Josh Aas of ISRG / Let’s Encrypt and endorsed by
> ??? of ??? and ??? of ???.
>
> Currently, the Baseline Requirements state the following in Section
> 6.2.7 Private Key Storage on Cryptographic Module:
>
> “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.”
>
> This states that HSMs must be running FIPS 140 level 3 or an
> appropriate Common Criteria Protection Profile or Security Target, EAL
> 4 (or higher) certified firmware. For the remainder of this
> explanation I will simply say FIPS when I mean “FIPS 140 level 3 or an
> appropriate Common Criteria Protection Profile or Security Target, EAL
> 4 (or higher) certified firmware.”
>
> However, the Network Security Requirements state the following in
> Section 1 Letter l:
>
> “Apply recommended security patches to Certificate Systems within six
> (6) months of the security patch’s availability, unless the CA
> documents that the security patch would introduce additional
> vulnerabilities or instabilities that outweigh the benefits of
> applying the security patch.”
>
> The concept that vulnerabilities must be addressed is expanded upon in
> Network Security Requirements Section 4 Letter f.
>
> It is possible for vulnerabilities to be discovered in FIPS certified
> HSM firmware. When that happens, updated firmware is often made
> available by HSM vendors. However, due to the extreme time and expense
> required for FIPS certification, such updates are often not FIPS
> certified. This puts CAs in a position where they have to decide
> whether to run FIPS certified firmware per the Baseline Requirements
> or address vulnerabilities in critical systems in a timely manner per
> the Network Security Requirements (and common sense). It also puts CAs
> in a position where they are non-compliant with one requirement or the
> other no matter what they do.
>
> -- MOTION BEGINS --
> 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.

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

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

Regards,
Fotis

> 4) The device is running with updated firmware which does not meet the
> Cryptographic Module Validation Requirements but addresses the
> aforementioned vulnerability.
> 5) The CA documents the vulnerability, the assessed risks, and the
> decision to update firmware to a version that doesn't meet the
> Cryptographic Module Validation Requirements.
>
> The decision to patch a Cryptographic Module in such a way that it
> meets the above listed requirements but no longer meets Cryptographic
> Module Validation Requirements shall be at the discretion of the CA,
> taking into account the CA’s threat model and relevant mitigations.
>
> Cryptographic Modules SHALL be configured to run in a relevant
> compliance mode at all times (e.g. "FIPS mode") if such a mode is
> available, whether or not the current firmware version itself has been
> validated to meet Cryptographic Module Validation Requirements.
> -- MOTION ENDS --

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