Hardware Security Verification Example: CWE-1351 Improper Handling of Hardware Behavior in Exceptionally Cold Environments

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 or emulation regression runs.

A hardware device, or the firmware running on it, is missing or has incorrect protection features to maintain goals of security primitives when the device is cooled below standard operating temperatures

Depending on the actual design implementation there may be several vulnerabilities related to this CWE to verify. Detecting security violations for this CWE assumes that the entropy of the Random Number Generator (RNG) is tested at power up and boot will be disabled if the test fails. Here, we consider the case where the entropy source may be used even if it fails an entropy test. This case can be modeled as an information flow verification problem.

In this example, consider the hypothetical SoC below:

The RNG used by the AES encryption module is using the output from a Physically Unclonable Function (PUF) as its entropy source. The SRAM based PUF needs to operate at a certain temperature to ensure sufficient entropy. An on-chip temperature sensor measures the temperature of the PUF and if it is too low, it won't allow the PUF to be used and the SoC won't boot.

Threat Model

An attacker may try to write the temperature sensor control register with a much lower threshold temperature allowing it to work in a colder environment, making the PUF output depend on previous data instead of manufacturing inconsistencies. An attacker may also try to boot the SoC even if the PUF entropy test is failing.

Security Requirement

The temperature sensor control register should not be writable by any agent outside the Hardware Root of Trust (HRoT) module. The PUF output should not be used by the AES unless the temperature is above a threshold and the entropy test of the PUF is passing.

Radix Security Rules

The requirements can be expressed as information flow verification problems i.e.:

• Information from the hrot_iface must not flow to the temp_limit register
• Information from the PUF must not flow to the AES unless the temperature is above the threshold and the entropy test passed

Using the Tortuga Logic Radix no-flow operator “=/=>” we can write the following security rules.

Verification

Using the security rules above, the Tortuga Radix tool will build a security monitor 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 the “Radix Coverage for HW CWE Guide” white paper.