Hardware Security Verification Example: CWE-1280 Access Control Check Implemented After Asset is Accessed

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 product's hardware-based access control check occurs after the asset has been accessed. The asset should be accessible only after the check is successful. If, however, this operation is not atomic and the asset is accessed before the check is complete, the security of the system may be compromised

Depending on the actual design implementation there may be several vulnerabilities related to this CWE to verify. Here, we consider the case where access control is not completed before the data is driven on the bus. This case can be modeled as an information flow verification problem.

In this example, consider the hypothetical SoC below:

Read access to the sram.csr.configuration register is only allowed for the trusted processor (tmcu). Hardware access control checks that the bus master doing the read is valid before the register value is driven to the output.

Threat Model

If the register value is driven on the bus before the access control check is complete, an untrusted agent may get access to privileged information.

Security Requirement

Information in access-controlled registers must not be available before the access control check is complete and successful.

Radix Security Rules

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

• Information from the configuration registers must not flow to the tbus unless the access is done by the tmcu and access control is completed.

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

Verification

If the security rule is violated when simulating the design, the violation is debugged in the Radix GUI. In this example, the rule is violated at time 2800. Viewing the violation in the Radix GUI Path View we see how information flows through the hierarchy from the sram csr instance to the sram instance.

To see which signals are involved in the unexpected information flow and what values they have, we can analyze the waveform.

The red shading makes it easy to focus on only the signals involved in the violation. The additional signals show control signal values that enables the information flow violation.

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.