NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
TD0796:  Removal of SHA-1 from Various Selections

Publication Date
2023.11.13

Protection Profiles
PP_CA_V2.1

Other References
FCS_COP.1.1(3), FCS_COP.1.1(4), FCS_COP.1.1(5), FCS_TLSC_EXT.2.1, FCS_TLSS_EXT.1.1

Issue Description

All uses of SHA-1 in signatures should be prohibited.

Resolution

This TD further refines changes made to FCS_TLSC_EXT.2.1 and FCS_TLSS_EXT.1.1 made in TD0294.

 

FCS_COP.1.1(3) and its Application Note in PP_CA_V2.1 are modified as follows, with green-highlighted underlines indicating additions and red-highlighted strikethroughs indicating deletions:

FCS_COP.1.1(3)

Refinement: The TSF shall [selection: perform, invoke interfaces in the operational environment to perform] [cryptographic hashing services] in accordance with a specified cryptographic algorithm [selection: SHA-1, SHA-256, SHA-384, SHA-512] and message digest sizes [selection: 160, 256, 384, 512] bits that meet the following: [FIPS Pub 180-4, “Secure Hash Standard”].

Application Note:

In future versions of this document, SHA-1 may be removed as an option. SHA-1 for generating digital signatures was disallowed after December 2013, and SHA-1 for verification of digital signatures is strongly discouraged as there may be risk in accepting these signatures.

The selection of the hashing algorithm must correspond to the selection of the message digest size; for example, if SHA-1256 is chosen, then the only valid message digest size selection would be 160256 bits.

The TSF hashing functions can be implemented in one of two modes. The first mode is the byte-oriented mode. In this mode the TSF only hashes messages that are an integral number of bytes in length; i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the bit-oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bit-oriented vs. the byte-oriented test modes.

 

FCS_COP.1.1(5) in PP_CA_V2.1 is modified as follows, with red-highlighted strikethroughs indicating deletions:

FCS_COP.1.1(5)

Refinement: The TSF shall [selection: perform, invoke interfaces in the Operational Environment to perform] [Password-based Key Derivation Functions] in accordance with a specified cryptographic algorithm [HMAC- [selection: SHA-1, SHA-256, SHA-384, SHA-512]] and output cryptographic key sizes [selection: 128-bit, 256-bit] that meet the following: [NIST SP 800-132].

 

FCS_COP.1.1(4) and its Application Note in PP_CA_V2.1 are modified as follows, with red-highlighted strikethroughs indicating deletions:

FCS_COP.1.1(4)

Refinement: The TSF shall [selection: perform, invoke interfaces in the operational environment to perform] [keyed hash message authentication] in accordance with a specified cryptographic algorithm HMAC-[selection: SHA-1, SHA-256, SHA-384, SHA-512], key size [assignment: key size (in bits) used in HMAC], and message digest sizes [selection: 160, 256, 384, 512] bits that meet the following: [FIPS Pub 198-1,“The Keyed Hash Message Authentication Code”; FIPS Pub 180-4, “Secure Hash Standard”].

Application Note:

The intent of this requirement is to specify the keyed hash message authentication function used when used for key establishment purposes for the various cryptographic protocols used by the TOE (e.g., trusted channel). The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used for FCS_COP.1(1).

In future versions of this document, SHA-1 may be removed as an option. SHA-1 for generating digital signatures was disallowed after December 2013, and SHA-1 for verification of digital signatures is strongly discouraged as there may be risk in accepting these signatures.

 

FCS_TLSC_EXT.1.1 and its Application Note in PP_CA_V2.1 are modified as follows, with red-highlighted strikethroughs indicating deletions:

FCS_TLSC_EXT.2.1

 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following ciphersuites: [selection:

·         TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289

].

Application Note:

The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The ST author should select the ciphersuites that are supported. It is necessary to limit the ciphersuites that can be used in an evaluated configuration administratively on the server in the test environment. The Suite B algorithms listed above (RFC 6460) are the preferred algorithms for implementation.

These requirements will be revisited as new TLS versions are standardized by the IETF.

It is recognized that RFC 5246 mandates the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA, but use of SHA-1 for digital signature generation is no longer recommended (see NIST SP 800-131A rev-1 and SP 800-78-4). Subsequent revisions of the PP will not include SHA-1.

 

FCS_TLSS_EXT.1.1 and its Application Note in PP_CA_V2.1 are modified as follows, with red-highlighted strikethroughs indicating deletions:

FCS_TLSS_EXT.1.1

The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting the following ciphersuites: [selection:

·         TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268

·         TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492

·         TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246

·         TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246

·         TLS_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

·         TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

·         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289

·         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289]

and no other ciphersuite.

Application Note:

The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The ST author should select the ciphersuites that are supported. It is necessary to limit the ciphersuites that can be used in an evaluated configuration administratively on the server in the test environment. The Suite B algorithms listed above (RFC 6460) are the preferred algorithms for implementation.

These requirements will be revisited as new TLS versions are standardized by the IETF.

It is recognized that RFC 5246 mandates the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA, but use of SHA-1 for digital signature generation is no longer recommended (see NIST SP 800-131A rev-1 and SP 800-78-4). Subsequent revisions of the PP will not include SHA-1.

Justification

SHA-1 has known vulnerabilities and the Crypto TC has recommended prohibiting its use.

 
 
Site Map              Contact Us              Home