Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dc v6 patch3 #2371

Merged
merged 12 commits into from
Nov 19, 2024
Merged

Dc v6 patch3 #2371

Show file tree
Hide file tree
Changes from 6 commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
903f618
Added content for #2314
danielcuthbert Nov 11, 2024
ed62e2a
typo in rfc
danielcuthbert Nov 11, 2024
30d6e32
removed cto ref
danielcuthbert Nov 12, 2024
abff3c7
amdned 6.9.1 to be more reflective of PQC status quo
danielcuthbert Nov 12, 2024
4485d7e
fixed linting issues
danielcuthbert Nov 13, 2024
9860e9c
tag fixes
elarlang Nov 13, 2024
26d5b8b
addressing PR comments
danielcuthbert Nov 14, 2024
169cb12
added keywrapping explanation to appendix
danielcuthbert Nov 18, 2024
feddb50
added NIST PQC FIPS guidelines to appendix
danielcuthbert Nov 18, 2024
be79516
ficed 6.6.5 to read more clearly
danielcuthbert Nov 19, 2024
58446f4
Minor tweak
tghosth Nov 19, 2024
3d0d929
linting
tghosth Nov 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 13 additions & 13 deletions 5.0/en/0x14-V6-Cryptography.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ Although this section is not easily penetration tested, developers should consid
| **6.2.1** | [MODIFIED] Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks. | ✓ | ✓ | ✓ | 310 |
| **6.2.2** | Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. | | ✓ | ✓ | 327 |
| **6.2.3** | [DELETED, DUPLICATE OF 6.2.5] | | | | |
| **6.2.4** | Verify that the application is designed with crypto agility such that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This should allow for seamless upgrades to post-quantum cryptography (PQC), once PQC standards are fully established. | | ✓ | ✓ | 320 |
| **6.2.4** | [MODIFIED] Verify that the application is designed with crypto agility such that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This should allow for seamless upgrades to post-quantum cryptography (PQC), once PQC standards are fully established. | | ✓ | ✓ | 320 |
| **6.2.5** | [SPLIT TO 6.5.1, 6.5.2, 6.6.3] | | | | |
| **6.2.6** | [MOVED TO 6.5.3] | | | | |
| **6.2.7** | [MOVED TO 6.5.4] | | | | |
Expand Down Expand Up @@ -84,8 +84,8 @@ Cipher algorithms such as AES and CHACHA20 form the backbone of modern cryptogra
| :---: | :--- | :---: | :---: | :---: | :---: |
| **6.5.1** | [ADDED, SPLIT FROM 6.2.5] Verify that insecure block modes (e.g., ECB) and weak padding schemes (e.g., PKCS#1 v1.5) are not used. | | ✓ | ✓ | 326 |
| **6.5.2** | [ADDED, SPLIT FROM 6.2.5, LEVEL L2 > L1] Verify that insecure ciphers, including Triple-DES and Blowfish, are not used but secure ciphers and modes** such as AES with GCM are. | ✓ | ✓ | ✓ | 326 |
| **6.5.3** | [MOVED FROM 6.2.6, LEVEL L2 > L3] Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key/data-element pair. The method of generation must be appropriate for the algorithm being used. | | | ✓ | 326 |
| **6.5.4** | [MOVED FROM 6.2.7] Verify that encrypted data is authenticated via signatures, including unencrypted tokens being used for secure access control, as well as through authenticated cipher modes or HMAC for protection against unauthorized modification. | | | ✓ | 326 |
| **6.5.3** | [MODIFIED, MOVED FROM 6.2.6, LEVEL L2 > L3] Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key/data-element pair. The method of generation must be appropriate for the algorithm being used. | | | ✓ | 326 |
| **6.5.4** | [MODIFIED, MOVED FROM 6.2.7] Verify that encrypted data is authenticated via signatures, including unencrypted tokens being used for secure access control, as well as through authenticated cipher modes or HMAC for protection against unauthorized modification. | | | ✓ | 326 |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"HMAC" → This should be "or a MAC"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any need to talk about encrypt-then-mac vs mac-then-encrypt vs mac-and-encrypt?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To answer your questions:

  • HMAC can become MAC, but HMAC is usually preferred.
  • Yes, there is a need to talk about this - since RFC7366 and with developments in ISO19772 and its revisions, it has been common practice to promote Authenticated Encryption with Associated Data (AEAD). EtH (Encrypt then Hash) or EtM (Encrypt then MAC) are common ways to achieve AEAD. However, in systems like SSH they have the choice between ciphers with and without etm in the name, hence it MUST be explicitly stated.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to add this to the Appendix once this patch is in.

| **6.5.5** | [ADDED] Verify that any authenticated signatures are operating in encrypt-then-MAC or encrypt-then-hash modes as required. | | | ✓ | 326 |

## V6.6 Hashing and Hash-based Functions
Expand All @@ -94,37 +94,37 @@ Cryptographic hashes are used in a wide variety of cryptographic protocols, such

| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---: | :---: | :---: |
| **6.6.1** | [ADDED] Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. | | ✓ | ✓ | 916 |
| **6.6.2** | [MODIFIED, MOVED FROM 2.4.1, MERGED FROM 2.4.3, 2.4.4] Verify that passwords are stored using an approved, computationally intensive, hashing algorithm with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks more challenging. | | ✓ | ✓ | 916 |
| **6.6.3** | [ADDED, SPLIT FROM 6.2.5] Verify that cryptographic systems avoid the use of disallowed hash functions, such as MD5, SHA-1, or any other insecure hash functions, for any cryptographic purpose. | ✓ | ✓ | ✓ | 327 |
| **6.6.4** | [ADDED] Verify that hash functions used in digital signatures are collision resistant and have appropriate bit-lengths to avoid attacks, such as collision or pre-image attacks. | ✓ | ✓ | ✓ | 916 |
| **6.6.5** | [ADDED] Verify that hash functions used in HMAC, KDF, and random bit generation are derived from those with proper entropy seeding for random bit generation. | | ✓ | ✓ | 916 |
| **6.6.1** | [ADDED] Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. | | ✓ | ✓ | |
| **6.6.2** | [MODIFIED, MOVED FROM 2.4.1, MERGED FROM 2.4.3, 2.4.4] Verify that passwords are stored using an approved, computationally intensive, hashing algorithm with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks more challenging. | | ✓ | ✓ | |
| **6.6.3** | [ADDED, SPLIT FROM 6.2.5] Verify that cryptographic systems avoid the use of disallowed hash functions, such as MD5, SHA-1, or any other insecure hash functions, for any cryptographic purpose. | ✓ | ✓ | ✓ | |
| **6.6.4** | [ADDED] Verify that hash functions used in digital signatures are collision resistant and have appropriate bit-lengths to avoid attacks, such as collision or pre-image attacks. | ✓ | ✓ | ✓ | |
| **6.6.5** | [ADDED] Verify that hash functions used in HMAC, KDF, and random bit generation are derived from those with proper entropy seeding for random bit generation. | | ✓ | ✓ | |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really understand (can't parse the meaning) of this one.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you be more specific?

Copy link
Contributor

@randomstuff randomstuff Nov 14, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verify that hash functions used in HMAC, KDF, and random bit generation are derived from those with proper entropy seeding for random bit generation.

I find it difficult to understand the last part ("are derived from those with proper entropy seeding for random bit generation") but after checking the appendix I understand that the correct column from the appendix must be checked :)

Can we reword it somehow like:

Verify that all hash function used in HMAC, KDF, and random bit generation are suitable for these usages.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reworded


## V6.7 Key Exchange Mechanisms

There exists a need for approved key exchange mechanisms, such as Diffie-Hellman and Elliptic Curve Diffie-Hellman (ECDH) to ensure that the cryptosystem remains secure against modern threats.

| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---: | :---: | :---: |
| **6.7.1** | [ADDED] Verify that industry-proven cryptographic algorithms, such as Diffie-Hellman groups, with a focus on ensuring that key exchange mechanisms use secure parameters to prevent man-in-the-middle attacks or cryptographic breaks, are used for key exchanges to prevent attacks on the key establishment process. | | ✓ | ✓ | 798 |
| **6.7.1** | [ADDED] Verify that industry-proven cryptographic algorithms, such as Diffie-Hellman groups, with a focus on ensuring that key exchange mechanisms use secure parameters to prevent man-in-the-middle attacks or cryptographic breaks, are used for key exchanges to prevent attacks on the key establishment process. | | ✓ | ✓ | |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"cryptographic algorithms, such as Diffie-Hellman groups" → I think it should read "cryptographic algorithms, such as Diffie-Hellman" because a DH group is not really an algorithm but only a group (i.e. a mathematical construct).

May we reword as

Verify that industry-proven cryptographic key exchanges, such as Diffie-Hellman, are used in order to prevent attacks on the key establishment process. The key exchange mechanisms must use secure parameters to prevent man-in-the-middle attacks or cryptographic breaks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to prevent man-in-the-middle attacks or cryptographic breaks.

Should we mention the notion of "authenticated key exchange" (i.e. anonymous Diffie-Hellman is usually not so great).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we can reword it like that, and yes, we can mention it for the same reasons we should mention AEAD/EtM above. :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how does this resonate?

| 6.7.1 | [ADDED] Verify that industry-proven cryptographic algorithms are used for key exchanges with secure parameters to prevent man-in-the-middle attacks or cryptographic breaks. Ensure that key exchange mechanisms employ authenticated key exchange protocols to verify the identities of communicating parties and mitigate attacks on the key establishment process. | | ✓ | ✓ | |

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"… and provides forward secrecy" 😉 #2215

(Actually I think it would be better to include forward secrecy as a separate requirement … ?)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to add this to the Appendix once this patch is in.


## V6.8 In-Use Data Cryptography

Protecting data while it is being processed is paramount. Techniques such as full memory encryption, encryption of data in transit, and ensuring data is encrypted as quickly as possible after use is recommended.

| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---: | :---: | :---: |
| **6.8.1** | [ADDED] Verify that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes. | | | ✓ | 798 |
| **6.8.2** | [ADDED] Verify that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as soon as feasible. | | ✓ | ✓ | 798 |
| **6.8.1** | [ADDED] Verify that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes. | | | ✓ | |
| **6.8.2** | [ADDED] Verify that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as soon as feasible. | | ✓ | ✓ | |

## V6.9 Post-Quantum Cryptography (PQC)

The need to future-proof cryptographic systems in preparation for the eventual rise of quantum computing is critical. Post-Quantum Cryptography (PQC) focuses on developing cryptographic systems that are resistant to quantum attacks, which could break current encryption methods such as RSA and ECC.

| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---: | :---: | :---: |
| **6.9.1** | [ADDED] Verify, if the application needs to support post-quantum cryptography, that quantum-safe algorithms, or quantum-resistant algorithms, such as lattice-based (ML-KEM), hash-based, code-based, or multivariate cryptographic schemes, are used as replacements for vulnerable classical algorithms like RSA and ECC. | | ✓ | ✓ | 798 |
| **6.9.2** | [ADDED] Verify that advancements in the field of post-quantum cryptography are being monitored in order to ensure that the application is aligned with emerging industry standards, and remains prepared for quantum threats. | | ✓ | ✓ | 798 |
| 6.9.1 | [ADDED] Verify that a cryptographic inventory is maintained and includes a documented transformation plan or mapping that outlines the migration path from current cryptographic algorithms and systems to those that are post-quantum cryptography/quantum-safe.| | ✓ | ✓ | |
danielcuthbert marked this conversation as resolved.
Show resolved Hide resolved
| **6.9.2** | [ADDED] Verify that advancements in the field of post-quantum cryptography are being monitored in order to ensure that the application is aligned with emerging industry standards, and remains prepared for quantum threats. | | ✓ | ✓ | |
danielcuthbert marked this conversation as resolved.
Show resolved Hide resolved

## References

Expand Down
78 changes: 71 additions & 7 deletions 5.0/en/0x97-Appendix-V_Cryptography.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,8 +86,6 @@ Implementations MUST choose from the following block modes, in order of preferen

* All encrypted messages must be authenticated. Given this, for ANY use of CBC mode there MUST be an associated hashing function or MAC to validate the message. This MUST be applied in the 'Encrypt-Then-Hash' or 'ETH' method. If this cannot be guaranteed, then CBC MUST NOT be used.

\*\*CCM-8 is included in regard to TLS cipher suites (see [TLS](https://github.com/santander-group-cyber-cto/CryptographyStandard/blob/main/Implementations/TLS/README.md) section).

#### Recommendations for Approved Cipher Modes for General Use Cases

Out of the given approved block modes, implementations SHOULD use the ciphers in this list, in order of preference:
Expand Down Expand Up @@ -135,7 +133,7 @@ AES-192 and AES-128 MAY be used if the use case demands it, but its motivation M

The following hash functions are approved for use in general cryptographic use cases such as digital signatures, HMAC, key derivation functions (KDF), and random bit generation (RBG). These functions provide strong collision resistance and are suitable for high-security applications. Some of these algorithms offer strong resistance to attacks when used with proper cryptographic key management, and so are additionally approved for HMAC, KDF, and RBG functions.

| Hash functions | Suitable for<br>HMAC/KDF/RBG? |Reference | L1 | L2 | L3 |
| Hash functions | Suitable for HMAC/KDF/RBG? | Reference | L1 | L2 | L3 |
| -------------- | ----------------------------- |-------------------------------------------------------------- |--|--|--|
| SHA3-512 | Y |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | | ✓ | ✓ |
| SHA-512 | Y |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | | ✓ | ✓ |
Expand Down Expand Up @@ -190,8 +188,8 @@ A security strength of 112 bits or above MUST be ensured for all Key Exchange sc
| Scheme | Domain Parameters |
|--|--|
| RSA | k >= 2048 |
| Diffie-Hellman (DH) | (L, N) parameters: <br>L >= 2048 & N >= 224 |
| Elliptic Curve <br>Diffie-Hellman (ECDH) | f >= 224 |
| Diffie-Hellman (DH) | L >= 2048 & N >= 224 |
| Elliptic Curve Diffie-Hellman (ECDH) | f >= 224 |

Where the following parameters are:

Expand All @@ -216,10 +214,76 @@ The following groups are approved and MUST be used for implementations of Diffie
| 15 | MODP | 3072-bit MODP Group | 128 | ✓ | ✓ | ✓ |
| 14 | MODP | 2048-bit MODP Group | 112 | ✓ | ✓ | ✓ |

A complete list of IKE Groups is available by [IANA](https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml) under "Transform Type 4 - Key Exchange Method Transform IDs". Further recommendations on IKE specifically can be found on the [IPSec](https://github.com/santander-group-cyber-cto/CryptographyStandard/blob/main/Implementations/IPSec/README.md) section.

### Disallowed KEX Schemes

Any new implementation MUST NOT use any scheme that is NOT compliant with [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final) & [B](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final) and [NIST SP 800-77](https://csrc.nist.gov/pubs/sp/800/77/r1/final).

Specifically, IKEv1 MUST NOT be used in production.

## Message Authentication Codes (MAC)

Message Authentication Codes (MACs) are cryptographic constructs used to verify the integrity and authenticity of a message. A MAC takes a message and a secret key as inputs and produces a fixed-size tag (the MAC value). MACs are widely used in secure communication protocols (e.g., TLS/SSL) to ensure that messages exchanged between parties are authentic and intact.

### Approved MAC Algorithms

The following MAC algorithms are approved for use in securing messages by providing integrity and authenticity guarantees. Implementations MUST use only authenticated encryption modes or separately applied HMAC to ensure the security of messages:

| MAC Algorithm | Reference | Suitable for General Use? | L1 | L2 | L3 |
| ----------------- | ----------------------------------------------------------------------------------------- | ------------------------- |----|----|----|
| HMAC-SHA-256 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | ✓ | ✓ | ✓ | ✓ |
| HMAC-SHA-384 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | ✓ | | ✓ | ✓ |
| HMAC-SHA-512 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | ✓ | | ✓ | ✓ |
| KMAC128 | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final) | ✓ | ✓ | ✓ | ✓ |
| KMAC256 | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final) | ✓ | ✓ | ✓ | ✓ |

### Disallowed MAC Algorithms

The following algorithms are explicitly banned and MUST NOT be used due to known vulnerabilities or insufficient security strength:

| MAC Algorithm | Reference |
| ---------------- | ---------------------------------------------------------------------------------- |
| MD5-based HMAC | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) |
| SHA-1-based HMAC | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) |

## Digital Signatures

### Approved Digital Signature Algorithms

The following digital signature algorithms are approved for use in ensuring data authenticity and integrity. Signature schemes MUST use approved key sizes and parameters per [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final):

| Signature Algorithm | Reference | Suitable for General Use? | L1 | L2 | L3 |
| -------------------------- | ---------------------------------------------------------------------------------- | ------------------------- |----|----|----|
| EdDSA (Ed25519, Ed448) | [RFC 8032](https://www.rfc-editor.org/info/rfc8032) | ✓ | ✓ | ✓ | ✓ |
| ECDSA (P-256, P-384, P-521)| [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-5/final) | ✓ | ✓ | ✓ | ✓ |
| RSA-PSS | [RFC 8017](https://www.rfc-editor.org/info/rfc8017) | ✓ | ✓ | ✓ | ✓ |

### Disallowed Digital Signature Algorithms

The following digital signature algorithms MUST NOT be used due to known weaknesses or insufficient security strength:

| Signature Algorithm | Reference |
| ------------------- | ---------------------------------------------------------------------------------- |
| RSA PKCS#1 v1.5 | [RFC 8017](https://www.rfc-editor.org/info/rfc8017) |
| DSA (any key size) | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-4/final) |

## Key Derivation Functions (KDFs)

### Approved KDFs

Key derivation functions transform a keying material into keys suitable for specific cryptographic operations. The following KDFs are approved and MUST be used based on the application’s needs and security context:

| KDF | Reference | Suitable for General Use? | L1 | L2 | L3 |
| ----------- | --------------------------------------------------------------------------------------------- | ------------------------- |----|----|----|
| argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | ✓ | | ✓ | ✓ |
| scrypt | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | ✓ | | ✓ | ✓ |
| PBKDF2 | [RFC 8018](https://www.rfc-editor.org/info/rfc8018) & [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final) | ✓ | ✓ | ✓ | ✓ |
| HKDF | [RFC 5869](https://www.rfc-editor.org/info/rfc5869) | ✓ | ✓ | ✓ | ✓ |

### Disallowed KDFs

The following KDFs are explicitly banned and MUST NOT be used due to insufficient security properties or known weaknesses:

| KDF | Reference |
| -------------- | ---------------------------------------------------------------------------------- |
| MD5-based KDFs | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) |
| SHA-1-based KDFs | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) |
Loading