Hardware Security Verification Example: CWE-325 Missing Cryptographic Step

Common Weakness Enumeration (CWE) is a community-developed list of software and hardware weakness types which may cause Security issues. The list is maintained by the MITRE organization and can be found here: cwe.mitre.org

In my previous post, “Better Hardware Security Verification through CWE and Information Flow Checking” I introduced Information Flow Checking as a way to verify that you don’t have the weaknesses listed in the CWE database in your design.

Here, let’s look at a more detailed example of how you can translate a Hardware CWE to a security rule which you can include in your simulation regression runs.

“The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.”

Radix will detect missing steps in established algorithms so long as the transitions between steps are framed as information flow properties. Radix will not detect whether the cryptography itself is secure or implemented correctly. This should be part of the functional verification plan.

Depending on the actual design implementation there may be several vulnerabilities related to this CWE to verify. Here, we consider the case where cipher data is available before all AES rounds are complete. This case can be modeled as an information flow verification problem.

In this example, consider the hypothetical SoC below:

The SoC has a configurable AES cipher which supports 128-, 192- and 256-bit keys. It goes through different number of rounds depending on the size of the key. For example, for a 128-bit key, it goes through 10 rounds. The cipher text or plain text must not be output until all rounds are completed.

Threat Model

A mistake in the implementation of the AES algorithm allows a malicious actor to access the cipher text before all rounds have completed

Security Requirement

No information about the data in the cipher should flow to the output until all rounds are completed

Radix Security Rules

The requirement can be expressed as an information flow verification problem i.e.:

• Information from a previous round must not flow to the output unless all rounds are completed

Using the Tortuga Logic Radix no-flow operator “=/=>” we can write the following security rule. Note: The NUM_ROUNDS parameter needs to be set depending on the key length configuration.

Verification

Using the security rules above, the Tortuga Radix tool will build a security model which when simulated together with the design will flag any violation of the rules. Using information flow security rules, over 80% of the MITRE Hardware CWEs can be verified by Radix.

To learn more about how to write security rule checks based on the Hardware CWE list, see this white paper.