INTRODUCTION
Modern electronic systems are complex, and economics dictate that the design, manufacturing, testing, integration and deployment of Application Specific Integrated Circuits (ASICs), System on Chips (SoCs) and Field Programmable Gate Arrays (FPGAs) span companies and countries. Security and trust in this diverse landscape of 3rd party IP providers, processor vendors, SoC integrators and fabrication facilities, is both challenging and introduces security risks. There are numerous obstacles in building secure systems including but not limited to complex supply chains, reverse engineering, counterfeiting, physical tampering and side-channel attacks.
Security vulnerabilities can be introduced throughout the design lifecycle starting at the architectural level, where fundamental flaws in the security architecture, such as storing implicitly trusted boot code in unprotected writable SPI Flash [1] can open systems to attack. A flawed microarchitectural design decision can also open hardware to vulnerabilities (e.g., Meltdown [2] and Foreshadow [3]). Vulnerabilities can also be introduced during RTL design, such as unintentional backdoors in test and debug circuitry [4], as well as errors in configuration and usage of hardware by low-level firmware and software [5-7].
Commonly employed security verification techniques, which include manual design and code review, formal verification, and simulation-based functional verification are important as part of a larger verification strategy but do not provide a unified scalable methodology which can be applied during all stages of the pre-silicon design life cycle.
An effective pre-silicon ASIC, SoC and FPGA security verification methodology must span system specification, architecture exploration, block and subsystem-level design, integration, firmware and low-level software executables.
Tortuga Logic’s Radix™ delivers a unified scalable methodology and environment to enable efficient specification, detection and prevention of security vulnerabilities centered around the concepts of confidentiality and integrity and integrates into existing simulation, such as Mentor's Questa® functional verification, and emulation-based verification flows.
COMMON SECURITY PITFALLS IN SOC IMPLEMENTATIONS
Hardware security vulnerabilities can be introduced at all stages of the design lifecycle, and fall into the following three major categories:
- Block-Level Hardware Vulnerabilities: Security bugs which exist even when the IP is analyzed in isolation from the rest of the system.
- System Integration Security Issues: Vulnerabilities can arise due to complex interaction between different IP even if the individual IP are vulnerability-free. Many IP blocks are highly parametrizable and configurable during hardware integration leading to an exponential number of configuration combinations, where a subset are insecure.
- Software Configuration and Usage Errors: The effectiveness of many hardware security features relies on correct software programming. For example, Memory Protection Units (MPU) are a common hardware feature in embedded systems which protect specific regions of memory based on the policy programmed by privileged software. Mistakes in programming the MPU can lead to sensitive information being disclosed or modified.
Given a typical SoC contains a mixture of 3rd party IP (3PIP) and custom IP blocks developed in-house, incorrect assumptions about the end environment and system the IP will be operating in are inevitable. What follows is an example of RISC-V® SoC design that illustrates how the combination of Radix™ and Questa® detects and prevents common security pitfalls.
HACK@DAC CONTEST AND DESIGN OVERVIEW
In conjunction with the 2019 Design Automation Conference (DAC) in Las Vegas, NV the conference hosted HACK@DAC. The annual event is a hardware security hacking competition where teams compete to detect, and report security bugs inserted by the organizers in the Register Transfer Level (RTL) implementation of a RISC-V® based SoC. The recent contest consisted of 2 phases:
- Alpha-Phase whose duration was 2 months
- Beta-Phase which was a live 33-hr hacking contest taking place at the DAC
The team consisting of Tortuga Logic and Texas A&M University won first place in both phases.
Figure 1 shows the block diagram of the SoC design Beta-Phase which is a superset of the Alpha-Phase. The design is based on the an open-source RISC-V® core “Ariane” [9], along with other open-source IP & peripherals.
 |
Figure 1 - Block diagram of Beta-Phase SoC [8]
The Alpha-Phase security features included crypto-graphic accelerators, a password protected test and debug interface, register locks, an on-chip bus access control table, processor privilege levels (machine, supervisor, and user), and immutable boot ROM and Fuse configuration memory. The Beta-Phase SoC was an extension of the Alpha-Phase SoC, with some additional features. Most significantly, firmware code was added which ran in Machine Mode during boot-up to confirm the correct functioning of the crypto engines, and if not correct then disabling them.
SYSTEMATIC HARDWARE SECURITY VERIFICATION USING RADIX™ AND MENTOR's QUESTA® VERIFICATION SOLUTION
Systematic and scalable security verification methodologies are necessary for the development of secure FPGA, ASIC and SoC-based systems. Security verification is a challenging problem because security vulnerabilities can exploit unspecified behavior or involve complex sequences of events unlikely to occur under normal operating conditions. System designers must ensure the chip is free from all vulnerabilities while attackers only need to find and exploit one.
Radix™ employs patented technology to detect and prevent security vulnerabilities in FPGAs, ASICs and SoCs by leveraging Mentor’s existing verification environments. Its advanced analysis helps security and verification teams identify and isolate security vulnerabilities before the device is manufactured saving costly design re-spins or catastrophic system failure due to an attack.
Radix™ incorporates three unique core technologies to enable pre-silicon security specification and verification at the block, subsystem, and chip level.
- Radix™ enables security objectives centered around information flow concepts (e.g., confidentiality and integrity) to be efficiently captured.
- Automated Security Model Design (SMD) generation: automatically generated patented information flow in synthesizable Verilog RTL capable of checking if rules hold during simulation or emulation of the design using existing verification infrastructure.
- Analysis Views: The Radix™ Analysis Views displays both signal values and leakage information to identify the source of the vulnerability and the signal values that caused it.
The first step involves creating security rules. These rules capture security objectives resulting from the process of threat modeling and are created with the following questions in mind: “what information in my design needs to be protected?” and “where does that information flow and how is it accessed?” The generic structure of a Radix™ security rule is:
{source signal set} =/=> {destination signal set} |
The main components of a rule are the source signal set, the “no-flow” operator, =/=>, and the destination signal set. The Radix™ rules are created to easily express security requirements, such as confidentiality and integrity, that are independent of value and time.
The rule will fail if information from any signal in the source signal set flows to any signal in the destination signal set. In addition to the no-flow operator, several keywords are provided to increase the expressiveness of the rules. For example, the “when” keyword can be used to specify conditions that must be held before information flows from the source are tracked.
After the security rules have been created, Radix™ generates the security model (SMD), which is synthesizable Verilog capable of determining if the security rules hold during design simulation or emulation.
Radix™ then leverages commercial simulation (Questa® Verification Solution) and emulation platforms, as shown in Figure 2. With Radix™, verification teams re-use existing infrastructure developed for functional verification as well as any software or firmware typically run using an emulator. This makes security verification scalable to the SoC level providing the capability of verifying hardware security properties during software execution.
 |
Figure 2 - Radix™ fits seamlessly into Mentor's Questa® verification flow
The HACK@DAC SoC designs were simulated using Mentor's Questa® simulator and the test stimulus included C code written by the contestants and privileged firmware provided by the organizers.
SECURITY VULNERABILITIES DISCOVERED
The following two sections provide details on how Radix™ was used to discover vulnerabilities in the HACK@DAC SoC, while the third section briefly lists additional vulnerabilities found during the contest.
A. Detecting AES Key Leakage
Cryptographic keys are critical assets to protect, as these keys are used to encrypt and decrypt sensitive data and provide authentication and attestation services for the device. Verifying the confidentiality of symmetric keys is one important but challenging task for systems using symmetric ciphers such as AES. If an attacker can learn a symmetric key, they are able to decrypt any data encrypted with that key.
In a hardware design, key material can originate from many sources including fuse memory, a random number generator, ROM, or user input. Key material will propagate throughout the design, undergoing simple transformations such as bit shifting, endianness swapping, and pipelining in addition to the transformations required by the cipher.
Detecting illegal key leakage using SystemVerilog assertions or functional tests is difficult because key recovery is possible even after the key undergoes transformations such as bit shifting or an exclusive-or with plaintext data. Accounting for all possible transformations while developing checkers or assertions requires an extremely detailed knowledge of the design micro architecture.
Radix™ employs technology capable of tracking both direct and indirect information flows meaning leakage of key material can be identified without requiring prior knowledge of all possible logic that the key passes through. In the HACK@DAC Alpha-Phase design the register containing the secret key was directly readable by software at any privilege level through the memory-mapped register interface for the AES core. No access control mechanisms were in place to protect the key register.
Radix™ was able to identify this direct key leakage using a simple rule, which can be read as “The secret key provided as an input to the AES core should not flow to any AES core output signals except as fully encrypted ciphertext:”
aes.key_in =/=> aes.$all_outputs ignoring { aes.ct } |
In this rule, “aes” is a module name, and “key_in” and “ct” are signals inside the “aes” module corresponding to the buses containing the encryption key and ciphertext respectively. $all_outputs is a shorthand for listing all output signals at the current level of hierarchy specified by the path name (in this case the “aes” module instance). The “ignoring” keyword provides a mechanism to whitelist allowed information flows through specific signals. For cryptographic algorithms the ciphertext is always based on information from the key. This is expected and should not result in rule failure.
This rule would also detect leakage at the output of the AES module even if the key had undergone logic transformations before leaking.
B. Analyzing Assets During Boot Flow
One of the most interesting additions to the SoC in the Beta-Phase was firmware responsible for configur-ing the device during boot time. The operations performed by this firmware included copying cryptographic keys from secure non-volatile storage (eFuse memory) to registers within the AES core.
Ideally even though software is initiating this copy operation the data being copied should never be manipulated by software itself. However, because this functionality is not provided in hardware, the firmware accomplishes the data copy by first reading the eFuse keys using a load operation, which means the key data reaches CPU registers and the data memory subsystem, then issues a store operation to the relevant register inside AES.
Any hardware buffers containing sensitive assets need to be adequately cleared or zeroized before the firmware releases the processor to less privileged software. Radix™ provides an easy way to explore the movement of sensitive hardware assets while low-level system software executes.
The security rule below tracks the flow of data read from the fuse memory to the write data signal on the DRAM interface. The rule constrains the tracking of information to when the read data originates from an address range containing key material.
fuse_mem.rdata_o when ( fuse_mem.addr < 6’h11 ) =/=> dram.w_data |
This security rule failed while the boot software executed, indicating that at some point key material was copied into main memory. RadixTM provides two unique analysis views to visualize rule failures: Waveform View, shown in the top of Figure 3, and Path View, shown in the bottom.
 |
Figure 3 - Radix™ analysis views for visualizing information flows in the design and debugging security rule violations
The Waveform View annotates the simulation trace with data about information flows. If a signal is shaded red, this indicates that the signal is currently carrying information derived from the keys stored in fuse memory. Design signals can be added interactively by users to provide a mechanism to easily identify all locations key material reaches during the simulation. The Path View provides a more direct mechanism for determining how the source information travels through the design hierarchy to the destination. Path View simplifies the analysis information by abstracting away signal values and focusing only on a single path leading to rule failure.
C. Additional Vulnerabilities Found During the Contest
Block-level Vulnerabilities
- JTAG Password Protection: The password only protects against reading scan chain contents but loading information into the scan chain can be done without the password. Additionally, the lock status bit indicating if the JTAG interface is currently locked/unlocked is not set to a known value by the reset logic.
- AES (Counter Mode): AES is used in counter mode, but in the implementation the Initialization Vector (IV) and counter value are fixed effectively making the encrypted information recoverable by an attacker who can gather several examples of encrypted ciphertext.
- Platform Level Interrupt Controller (PLIC): A multiple drivers issue routing SPI and UART interrupts was discovered. An attacker capable of sending data to the SoC using these interfaces can potentially physically damage the chip.
System Integration Security Issues
- JTAG Password Storage: The password is stored in a location that unprivileged software can read and write.
- Boot Code Storage: The boot code, according to the specification, is stored in a dedicated “Read-Only Memory” (ROM), however in the implementation the code can be overwritten by unprivileged software.
- Register Locks: Register locks are designed to be unlocked on reset and then set/locked by privileged software. After the registers are locked even privileged software can’t modify the contents until a system reset. The vulnerability is that dur-ing system integration the wrong reset is routed to the register lock logic. A reset controllable by a software debug command, which doesn’t reset the entire SoC, is used instead of the global hardware reset.
- Direct Memory Access (DMA): DMA is used to transfer data between memory-mapped addresses without tying up processor resources. The DMA controller is a separate bus master from the processor, and if care is not taken the access control polices applied to the CPU are not consistent with the restrictions placed on the DMA. In the HACK@DAC design, assets such as system timers could be accessed by unprivileged software via the DMA unit.
Software Configuration and Usage Vulnerabilities
- Access Control Polices: The AXI-4 Crossbar implemented a programmable “firewall” allowing privileged software to designate allowed and disallowed access to every peripheral on the bus from each combination of processor privilege level and bus master. The vulnerability was that the settings programmed by firmware during boot allowed unprivileged access to almost all peripherals.
- Privileged Code Integrity: The memory region where trap handler code resides during opera-tion is not protected and can be overwritten by unprivileged software allowing arbitrary code execution in machine mode.
- System Calls: In the Beta-Phase several privileg-ed software APIs for usage of the SHA and AES accelerators were provided, however these functions did not validate input pointers. An unprivileged attacker could exploit this to achieve writes to arbitrary memory locations.
KEY TAKEAWAYS
Failure to address security can be a costly mistake, including the impact they may have on consumer confidence, personal privacy, and brand reputation. The existence and exploitation of hardware vulnerabilities can also increase time-to-market, reduce vendor trust, and lead to costly lawsuits, chip recalls or even loss of life.
Whether it’s a hacking contest or a real-world design project, an in-depth knowledge and understanding of the design is an essential pre-requisite to finding any hardware security vulnerability. While RTL designers and verification engineers fulfill this pre-requisite, these engineers are not necessarily security experts. Adding verification of security requirements to the already long list of functional verification requirements without providing tools tailored to security verification puts a significant burden on the verification teams. Manual code, design reviews and functional simulation are just not sufficient or scalable. Systematic and specification-driven security verification is necessary to achieve the needed higher coverage of the complete design space. Automated security verification tools and methodologies such as Tortuga Logic’s Radix™ with Mentor's Questa® is necessary for enabling the creation of trusted and assured microelectronics.
ABOUT TORTUGA LOGIC
Tortuga Logic is a cybersecurity company that provides hardware security verification solutions and services that enable ASIC, SoC and FPGA design and security teams to detect and prevent security vulnerabilities. Unlike software and firmware security solutions that do not find underlying hardware flaws or manual penetration testing that finds issues after the device is manufactured, RadixTM detects and prevents hardware security issues, early in the design process, leveraging your existing design and verification tools and methodologies. For more information please visit tortugalogic.com.
REFERENCES
- Cisco Secure Boot Hardware Tampering Vulnerability
- Lipp, Moritz, et al. "Meltdown: Reading kernel memory from user space." 27th USENIX Security Symposium, 2018.
- Van Bulck, Jo, et al. "Foreshadow: Extracting the keys to the intel SGX kingdom with transient out-of-order execution." 27th USENIX, 2018.
- Skorobogatov, Sergei, and Christopher Woods. "Breakthrough silicon scanning discovers backdoor in military chip." International Workshop on Cryptographic Hardware and Embedded Systems, 2012.
- The Register, UK: BMC Pantsdown Bug
- Armis discloses two critical chip-level vulnerabilities to BLEEDINGBIT
- Android Alert: Users Urged to Patch Critical Flaw in Latest Qualcomm Chips
- Hack@DAC19/Hard CTF
- github.com/pulp-platform/ariane
Back to Top
