Hardware Security Verification Example CWE-1243: Sensitive Non-Volatile Information Not Protected During Debug

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 CWE to a security rule you can include in your simulation regression runs.

The product exposes security-sensitive values stored in fuses during debug. Several security-sensitive values are blown as fuses in a chip to be used during early-boot flows or later at runtime. Examples of these security-sensitive values include root keys, encryption keys, manufacturing-specific information, chip-manufacturer-specific information, and original-equipment-manufacturer (OEM) data. After the chip is powered on, these values are sensed from fuses and stored in temporary locations such as registers and local memories. These locations are typically access-control protected from untrusted agents capable of accessing them. Even to trusted agents, only read-access is provided. However, these locations are not blocked during debug flows, allowing an untrusted debugger to access these assets and compromise system security.

Depending on the actual design implementation there may be several vulnerabilities to verify. Here let’s consider when debug mode is enabled since an adversary have easy access to JTAG pins. In debug mode there should be no access to security sensitive fuse values. This can be modelled as information flow verification.

In this example, consider the hypothetical SoC below:

Security sensitive information is stored in blown fuses in the otp block and in a section of the rom.mem memory. During normal operation mode, access control methods prevent un-trusted system components from reading this data.

Threat Model

In this example, we assume that the threat is from a malicious actor running an un-trusted debugger connected to the JTAG pins of the debug module. Data in rom.mem memory and otp fuses may be visible through the debug interface when the device is in debug mode and normal access control may not be set up yet. This would give access to sensitive data through an untrusted debugger. 

Security Requirement

Data in rom and otp must not be readable through the debug interface

Radix Security Rules

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

• Information must not flow from the rom memory or the otp fuses to any of the debug outputs when the device is in debug mode

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

Verification

If the security rule from OTP is violated when simulating the design, the violation is debugged in the Radix GUI. In this example, the rule is violated at time 2900ns. Viewing the violation in the Radix GUI path view we see how information flows through the hierarchy of the design from the otp instance through the tbus interconnect to the dbg_data_o output in the debug instance.

To understand 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.

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 white paper below.