Hardware Security Verification Example: CWE-440 Expected Behavior Violation

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.

A feature, API, or function does not perform according to its specification.

Depending on the actual design implementation there may be several vulnerabilities related to this CWE to verify. Here, we consider the case where an FSM incorrectly goes to an error state This case can be modeled as an information flow verification problem.

In this example, consider the hypothetical SoC below:

The Core0 CPU implements an error handler using the programmable interrupt controller module core0.pic. The module contains an FSM that that may transition into a state that is intended to triple fault the core0 CPU and reset the device. The FSM must only go to the error state if the CPU is running privileged code. User code may be running on Core1 – 3. If an attacker can force this FSM into the state that triggers the triple fault, then they may be able to lock the device into a reset loop and cause a denial-of-service attack.

Threat Model

We assume that the attacker can send arbitrary commands to the core0.pic hardware via software or hardware running at the user privilege level.

Security Requirement

core0.pic.fsm must not enter the triple fault-triggering state unless authorization flags associated with the privilege level are set, i.e., Core0 is running privileged code.

Radix Security Rules

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

• Information (next state in FSM is the error state) must not flow to the current state of the FSM unless the core is running in privileged mode.

Using the Tortuga Logic Radix no-flow operator “=/=>” we can write the following security rule. This will ensure the FSM will not enter the error state (4’b1011) when user level (privilege “1”) code is running on the CPU. It doesn’t matter how the state change is triggered.

Verification

Using the security rules above, the Tortuga Radix tool will build a security monitor which when simulated or emulated 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.