[Cscwg-public] Ian's presentation from June 18 CS call

[Tomas Gustavsson]

Hi,

I like the improvement a lot over the old text.

I have one comment.

I don't like the wording "Common Criteria EAL 4+". It's a common
misconception that CCs EAL level would somehow be similar to FIPS
levels, but they are not. CC certifications exist with and without EAL
levels. The EAL levels in turn is to quite some extent mouthwash and
there is nothing to say that "no EAL, EAL 2 or EAL 4+" has any
difference in security features or testing. While FIPS Level 2 vs 3 etc
have specific features required and tested.

CC certification is most often done against a protection profile, if it
is not (which is fully possible), it's mostly bogus.

Relating to the text:
FIPS 140-2 Level 2, has some specific meaning in that NIST specifies
tests for cryptographic modules.
Common Criteria EAL 4+ has absolutely no meaning in this case and can
mean just about anything or nothing.

My assumption is that with CC EAL4+ we think about the eIDAS Protection
Profile, EN 419 221-5. If this is the desired requirement, this need to
be states so instead if the CC EAL4+ generic text it should say:

"conforming to at least FIPS 140 Level 2, EN 419 221-5, or equivalent"

Just some additional remarks:
If NIAP creates a CC Protection Profile for cryptographic modules it
will have no EAL levels defined, so that would fail the CC EAL4+
requirement, while likely being a vastly superior testing and evaluation
compared to current CC EAL4+ certifications for cryptographic modules.

As an example there are currently two protection profiles for CA software.
- One ancient, from 2011, having an EAL4+ level (or lower but EAL4+ is
the commonly claimed level.
https://www.commoncriteriaportal.org/files/ppfiles/cert-issu-v15-sec-eng.pdf
- One modern, from 2018, with no EAL level.
https://www.niap-ccevs.org/Profile/Info.cfm?PPID=420&id=420

I will not get into details why the modern one is the better one, but I
have a lengthy document describing the differences...

Regards,
Tomas


On 2020-06-25 20:38, Dean Coclin via Cscwg-public wrote:
> Ian McMillan (Microsoft) presented this at the last meeting regarding
> cloud private key protection. This is still in discussion:
> 
>  
> 
> *Current CS BR’s in v2.0:*
> 
> * *
> 
> *16.3 Subscriber Private Key Protection*
> 
> For Non-EV Code Signing Certificates, the CA MUST obtain a
> representation from the Subscriber that the Subscriber will use one of
> the following options to generate and protect their Code Signing
> Certificate private keys:
> 
>  
> 
>  1. A Trusted Platform Module (TPM) that generates and secures a key
>     pair and that can
> 
> document the Subscriber’s private key protection through a TPM key
> attestation.
> 
>  
> 
>  2. A hardware crypto module with a unit design form factor certified as
>     conforming to at
> 
> least FIPS 140 Level 2, Common Criteria EAL 4+, or equivalent.
> 
>  
> 
>  3. Another type of hardware storage token with a unit design form
>     factor of SD Card or
> 
> USB token (not necessarily certified as conformant with FIPS 140 Level 2
> or Common
> 
> Criteria EAL 4+). The Subscriber MUST also warrant that it will keep the
> token
> 
> physically separate from the device that hosts the code signing function
> until a signing
> 
> session is begun.
> 
>  
> 
> For Non-EV Code Signing Certificates, a CA MUST recommend that the
> Subscriber protect Private Keys using the method described in Section
> 16.3(1) or 16.3(2) over the method described in Section 16.3(3) and
> obligate the Subscriber to protect Private Keys in accordance with
> 10.3.2(2).
> 
>  
> 
>  1. For EV Code Signing Certificates, CAs SHALL ensure that the
>     Subscriber’s private key is
> 
> generated, stored and used in a crypto module that meets or exceeds the
> requirements
> 
> of FIPS 140-2 level 2. Acceptable methods of satisfying this requirement
> include (but
> 
> are not limited to) the following: The CA ships a suitable hardware
> crypto module, with
> 
> a preinstalled key pair, in the form of a smartcard or USB device or
> similar;
> 
>  
> 
>  2. The Subscriber counter-signs certificate requests that can be
>     verified by using a
> 
> manufacturer’s certificate indicating that the key is managed in a
> suitable hardware
> 
> module;
> 
>  
> 
>  3. The Subscriber provides a suitable IT audit indicating that its
>     operating environment
> 
> achieves a level of security at least equivalent to that of FIPS 140-2
> level 2.
> 
>  
> 
>  
> 
> *My draft proposal:*
> 
>  
> 
> *16.3 Subscriber Private Key Protection*
> 
> For Code Signing Certificates, the CA MUST obtain a representation from
> the Subscriber that the Subscriber will use one of the following options
> to generate and protect their Code Signing Certificate private keys:
> 
>  
> 
>  1. A hardware crypto module with a unit design form factor certified as
>     conforming to at
> 
> least FIPS 140 Level 2, Common Criteria EAL 4+, or equivalent;
> 
>  
> 
>  2. /A Cloud-based key protection solution with the following
>     requirements enabled on the subscription, and a usage pattern as
>     follows:/
> 
>      1. /A hardware crypto module with a unit design form factor
>         certified as conforming to at least FIPS 140 Level 2, Common
>         Criteria EAL 4+, or equivalent;/
>      2. /Key creation, storage, and usage of private key must remain
>         within the security boundaries of the cloud solutions hardware
>         crypto module;/
>      3. /Subscription must be configured to log all access, operations,
>         and configuration changes on the key. The configuration change
>         log is available for audits./
> 
>  
> 
> For Code Signing Certificates, CAs SHALL ensure that the Subscriber’s
> private key is generated, stored and used in a crypto module that meets
> or exceeds the requirements of FIPS 140-2 level 2. Acceptable methods of
> satisfying this requirement include (but are not limited to) the following:
> 
>  
> 
>  1. The Subscriber counter-signs certificate requests that can be
>     verified by using a//
> 
> manufacturer’s certificate indicating that the key is managed in a
> suitable hardware
> 
> module;
> 
>  
> 
>  2. The Subscriber provides a suitable IT audit indicating that its
>     operating environment//
> 
> achieves a level of security at least equivalent to that of FIPS 140-2
> level 2;
> 
>  
> 
>  3. The Subscriber provides a suitable report of the cloud key
>     protection solution subscription configuration protecting the key in
>     hardware crypto model with a unit design form factor certified as
>     conforming to at least FIPS 140 Level 2, Common Criteria EAL 4+, or
>     equivalent.
> 
>  
> 
>  
> 
> 
> _______________________________________________
> Cscwg-public mailing list
> Cscwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/cscwg-public
>