Should Cryptography reqs be Level 1

[tghosth]

We currently have an explanation of the thinking around L1 which can be found here.

There are a few major areas where we have differing opinions about whether a particular type of control falls into the category of L1 for version 5.0.

This issue is to discuss cryptography requirements from the current chapter 6.

The only requirements being considered for L1 are below (ignore the level marking below). It is agreed (between Josh and Elar for now) that the others in this chapter are not L1.

#	Description	L1	L2	L3	CWE
6.3.1	[GRAMMAR, LEVEL L2 > L1] Verify that all random numbers and strings which are intended to be non-guessable must be generated using a cryptographically-secure pseudo-random number generator (CSPRNG) and have at least 128 bits of entropy. Note that UUIDs do not respect this condition.	✓	✓	✓	338
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.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.	✓	✓	✓

I personally believe that these requirements do belong in L1 for the following reasons:

• Many controls (session identifiers, unique file identifiers, one time passwords, etc) rely on random numbers if random numbers are not being created securely then that potentially makes these controls ineffective.
• Similarly many controls (signed tokens, encrypted storage, file integrity checking) rely on cryptography for encryption, signatures and hash generation and use of insecure algorithms potentially makes these controls ineffective.
• Bad cryptography is something that is very hard to fix after the fact. The effort to implement at an earlier stage will be far less than the effort to fix this at a later date.
• Given the importance of cryptography in cyber security in general, the idea that not a single requirement from this chapter would be L1 does not seem reasonable.

[elarlang]

6.3.1 - if it is not practically easily guessable in some time-frame, but if it is not CSPRNG?

For others, I would like to see a high likelihood and/or impact attack scenario that only relies on given requirements.

In another issue (#2476) you used arguments:

• In general, it violates the idea that L1 should have a low barrier to entry.
• If I am honest, I am not sure how exactly this would be verified anyway? Certainly it would be problematic to verify "black box" style.

Why not here?

[tghosth]

In general, it violates the idea that L1 should have a low barrier to entry.

I don't believe that using good crypto algorithms has a high barrier to entry. This is a pretty low bar and these requirements involve using very standard and well supported algorithms.

If I am honest, I am not sure how exactly this would be verified anyway? Certainly it would be problematic to verify "black box" style.

Makes up for it by being quite easy to verify white box (unlike input validation) and in many cases there will be ways of doing this black box as well, e.g. burp sequencer for insufficient random, https://hashes.com/en/tools/hash_identifier.

[elarlang]

One this is for sure, we have quite a different view on this. You have you beliefs but I have not seen arguments on attack scenarios.

[randomstuff]

I would include these in L1 as well:

6.2.2 Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography.

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

Reasons:

• 6.2.2 → it's not that difficult to check that you are not including some custom coded cryptography;
• 6.5.3 → reusing nonces can completely screw your encryption (especially with CTR and CFB) (and signatures as well).

For this requirements and some others, having an simple L1 application which complies with the requirement is not very difficult: don't use crypto in your application code, let the frameworks do the stuff for me and you should be fine. Using custom crypto code without make these verification might lead you to make dangerous design choices (when used with broken crypto) and you would better use a different design which avoids cryptography.

Typical examples I have seen in the wild:

• the usage of weak (unauthenticated) encryption (think static encryption key in application code with DES) to "protect" some HTTP request parameters and grant (non-revocable ever-lasting) access to some file (leading to arbitrary file read) where some simple user authorization would have been fine;
• custom-coded encryption based on "let's scramble those bits around";
• browser-side encryption of requests, presumably intended to prevent the user from messing up with the requests (probably because the backend lacks proper authorization).

I would even claim that this type of pattern is probably prevalent in L1-level applications and that having these requirements might force the authors of L1 applications to remove dubious cryptography and implement a proper design (such as fixing the lack of correct authorization).

[elarlang]

Let's be clear - do we talk about 1st or 2nd layer of defense here?

Important - I don't say we don't need those requirements, I want to understand, are those worth the L1 spotlight. Is the likelihood/impact close to SQL injection, trivial authentication or authorization bypass?

6.2.2 → it's not that difficult to check that you are not including some custom coded cryptography;

There are many things that are not difficult to check, (e.g. cookie attributes), but it does not make it L1. We move away from "testability".

6.5.3 → reusing nonces can completely screw your encryption (especially with CTR and CFB) (and signatures as well).

Can you provide me a "L1 worth" attack scenario using this?

First example is more like authorization problem to solve? Is it better solution, when used some other crypto-algorithm instead of where some simple user authorization would have been fine?

Second example - to be not required in L1 does not mean you need to make your own crypto. If we could use that view, we shoul put a lot of things into L1. The question here is, how critical is this problem to be solved as a first things to do.

[randomstuff]

First example is more like authorization problem to solve? Is it better solution, when used some other crypto-algorithm instead of where some simple user authorization would have been fine?

Yes, I agree that these examples might be more a problem of something else is not quite right in the design of the application (such as the authorization should be fixed).

So there are two cases to consider for the broken/fake crypto usage:

• broken/fake crypto is used as a misguided stop-gap measure to fix/hide another real problem in the implementation/design of the application and this problem should already be covered by another requirement anyway;
• or there is a real reason for using crypto in the first place and reusing nonces could be very bad.

Can you provide me a "L1 worth" attack scenario using this?

A simple case would be for digital signature (which not covered in the requirement but probably should). If the application is generating tokens using ECDSA and reuses nonces, the private key can be recovered and the token can be forged.

I think we could come up with interesting attacks when some state is stored in encrypted token in cookies. I'll try to expand on this.

If 6.5.1 is L1, it would probably make sense to have 6.5.3 and probably 6.2.2 as well.

[jmanico]

+1 @randomstuff I back this general direction as well. Nice example, thank you.