Hardware Security Verification Example: CWE-441 Unintended Proxy or Intermediary (‘Confused Deputy’)

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.

The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor

Depending on the actual design implementation there may be several vulnerabilities related to this CWE to verify. Here, we consider the case where secure data reaches an unsecure destination through the use of an agent with higher access privileges. This case can be modeled as an information flow verification problem.

In this example, consider the hypothetical SoC below:

The Core0 processor is running software at the lowest privilege level and the security access policy in the interconnect prevents it from reading or writing any data in the HRoT.SRAM memory. The access policy allows the DMA to read and write data in the HRoT.SRAM memory. All the Core{0-N} processors may program the DMA to do IO or Memory data transfers as long as the access policy for the DMA allows it.

Threat Model

An untrusted agent running code on the Core0 processor can access data in the Hardware Root of Trust (HRoT) SRAM by programming the DMA to transfer data to a location it can access, so that it appears that the DMA is the source of the transaction.

Security Requirement

The untrusted processor must not be able to access data in the HRoT SRAM regardless if it is done directly or through another agent (the confused deputy).

Radix Security Rules

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

• Information from Core0 must not flow to the SRAM in the HW Root of Trust
• Information from the SRAM in the HRoT must not flow to the Core0 processor

Using the Tortuga Logic Radix no-flow operator “=/=>” we can write the following security rule. It is not necessary to include DMA signals in the rules as the path information may take is not known. The rules will identify a violation if data flows through an intermediate storage location or if it includes transactions initiated by another agent.

Verification

Using the security rules above, the Tortuga Logic 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.