Hardware Security Verification Example: CWE-1246 Improper Write Handling in Limited-write Non-Volatile Memories

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 to ensure the weakness is not present in your design.

The product does not implement or incorrectly implements wear leveling operations in limited-write non-volatile memories such as NAND Flash, EEPROM, etc. They have individually erasable segments, each of which can be put through a limited number of program/erase or write cycles. For example, the device can only endure a limited number of writes, after which the device becomes unreliable. To wear out the cells in a uniform manner, non-volatile memory and storage products based on the above-mentioned technologies implement a technique called wear leveling. Once a set threshold is reached, wear leveling maps writes of a logical block to a different physical block. This prevents a single physical block from prematurely failing due to a high concentration of writes. If wear leveling is improperly implemented, attackers may be able to programmatically cause the storage to become unreliable within a much shorter time than would normally be expected

Depending on the actual design implementation there may be several vulnerabilities related to this CWE to verify. Here, we consider the case where the write leveling control is bypassed. This case can be modeled as an information flow verification problem.

Note: Functional verification should ensure that write leveling is implemented correctly as this is part of the device's defined functionality. Information flow tracking can ensure it is not bypassed or misused.

In this example, consider the hypothetical SoC below:

The tnvm flash memory implements write leveling to prevent premature failures of the memory. The tnvm has a register that defines the maximum number of writes per location. This register is only readable and writable by the secure tmcu processor.

Threat Model

A malicious actor may be able to bypass the write leveling logic and perform a large number of writes to the same location thus making part of the flash unreliable. This may lead to undefined states in the system where security policies are not enforced or may enable a denial-of-service attack.

Security Requirement

Non-volatile memory locations should not be writable by un-trusted agents when the maximum number of writes for the location has been reached. Un-trusted agents must not be able to write to the write limit control register.

 Radix Security Rules

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

• Information must not flow to a non-volatile memory location if the number of writes exceed the maximum allowed unless the write is done by the trusted processor.
• Information (write data) from outside the Hardware Root of Trust module must not flow to the write limit register.

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.