Is 2.9.1 a duplicate of 14.8.1 (secrets management)

[tghosth]

Chapter text for 2.9:

Cryptographic authentication mechanism include smart cards or FIDO keys, where the user has to plug in or pair the cryptographic device to the computer to complete authentication. The authenticatoin server will send a challenge nonce to the cryptographic device or software, and the device or software calculates a response based upon a securely stored cryptographic key.

The requirements for single-factor cryptographic devices and software, and multi-factor cryptographic devices and software are the same, as verification of the cryptographic device proves possession of the authentication factor.

Relevant requirements for this issue:

#	Description	Level	CWE
2.9.1	[MODIFIED, LEVEL L2 > L3] Verify that the authentication verifier stores the cryptographic keys used in verification such that they are protected against modification (and for symmetric keys, against disclosure). This could involve using a Trusted Platform Module (TPM), a Hardware Security Module (HSM), or an OS service that can provide this secure storage.	3	320
14.8.1	[MODIFIED, MOVED FROM 6.4.1, MERGED FROM 1.6.2, 2.10.4, COVERS 2.10.3] Verify that a secrets management solution such as a key vault is used to securely create, store, control access to, and destroy back-end secrets. These could include passwords, key material, integrations with databases and third-party systems, seeds and internal secrets, and API keys. Secrets must not be included in application source code or included in build artifacts. For a L3 application, this should involve a hardware-backed solution such as an HSM.	2	798

Should 2.9.1 be merged into 14.8.1? Feels like it is covered there. Is this something that absolutely needs its own separate requirement.

@elarlang @jmanico @randomstuff

[elarlang]

Seems so, pretty much the same situation as #2576

[jmanico]

Agree that merging is the way to go.

[randomstuff]

Cryptographic authentication mechanism include smart cards or FIDO keys

2.9.1 Verify that the authentication verifier stores the cryptographic keys used in verification such that they are protected against modification (and for symmetric keys, against disclosure). […]

This is typically a per-user public key (smartcard, FIDO). In the case of smart card, the public key would often come from a X509 certificate issues by a PKI. In this case, the only thing stored on the server would be the Distinguished Name associated with the user. (Hence, there is not so much to protect anyway.)

For FIDO keys, the server would (I think) typically store the public key of the user's FIDO device. Protection against modification is relevant but I don't think this would be covered by a TPM or HSM, would it?

---

On the other hand, 14.8.1 is about:

passwords, key material, integrations with databases and third-party systems, seeds and internal secrets, and API keys

I don't think that the things we are talking about in 14.8.1 and 2.9.1 are similar, have similar security requirements and would usually be handled using similar solutions.

So I'm not sure it really makes sense to merge them.

[tghosth]

For smartcards, surely there is still a signed certificate that needs to be stored and not modified to assure the security of the system?

For FIDO keys, sounds like this is a public key where modification needs to be avoided.

However, I accept that this is not really a "secret" as such.

What if we reword the requirement to:

"[MODIFIED, LEVEL L2 > L3] Verify that the certificates used to verify cryptographic authentication assertions are stored in a way protects them from modification."

I would also add a note to the section text which says:

'Where shared or secret keys are used for cryptographic authentication, these should be stored using the same mechanisms as other system secrets, as documented in the "Secret Management" section.'

What do you think @randomstuff ?