Dominic Rizzo (OpenTitan) and Jason Oberg (Cycuity)
OpenTitan is the leading open source silicon root of trust project. It was also the industry’s first open source silicon root of trust, designed from scratch as a transparent, trustworthy and secure implementation for enterprises, platform providers and chip manufacturers.
What Is a Hardware Root of Trust (RoT)?
While visitors to the Cycuity site may well have ample familiarity with the root of trust concept, it’s perhaps worth a quick step back to say that running software with confidence that it hasn’t been corrupted or compromised requires that a chain of trust be established. Each successive layer of software is verified as correct by the preceding layer before its launched. You trust the most recent piece because you trust the authenticity and correctness of the piece before it, and so on down through the entire chain of software in the call stack.
At the first link in that chain, the initial operations of the boot cycle of a computer establish that secure starting point.
But establishing that starting point during system boots is tricky and requires a method of ensuring that the very first bytes of code that run at power on haven’t been compromised already. If BIOS is the first thing to run, who verifies that no one’s rewritten BIOS maliciously?
To make sure BIOS hasn’t been tampered with, modern systems use a hardware chip that’s been built to house one or more secrets (think encryption keys) and the code needed to perform a check on BIOS before it runs.
This root of trust chip is typically hardened against physical tampering. Even if that physical protection is unassailable, there is still always the possibility that a logical error has been made in the chip’s burned-in software, so it’s critical that designers who rely on this root of trust hardware also have full confidence in the logical system implemented by the chip. This has been difficult in the past in part because such chips were proprietary and their inner workings weren’t necessarily entirely known by third parties.
While there have been a number of these sort of chips on the market over the past decade, OpenTitan is the first that is designed as an open source project.
The open source development model allows OpenTitan to serve as a vehicle for innovation in academia, but also as an effective commercial platform as well. And the project implements several important advanced features such as remote attestation and secure storage of private user data.
OpenTitan and security
Cycuity is involved with OpenTitan because of tools created by Cycuity that help detect and prevent design weaknesses and security vulnerabilities throughout the semiconductor design process. Targeted at all types of silicon devices, Cycuity’s Radix product line helps companies that build or rely on semiconductors achieve security sign-off more systematically and predictably.
One great aspect of OpenTitan’s freely available and permissively licensed approach is precisely that it’s open. It gives Cycuity an ideal opportunity to show the full process of Radix-supported, security-focused design, while providing greater assurances of OpenTitan’s design in the process.
While open source approaches are already well established, an openly sourced root of trust chip is new. Because it’s unfamiliar territory and because roots of trust are foundational elements of secure systems, it’s clearly vital that the project must offer transparency for the project and must create confidence in the correctness of its implementation.
Cycuity was able to use the OpenTitan design to demonstrate how security verification effectively demonstrates the trustworthiness of open source hardware. Collaborating with Professor Ryan Kastner and his lab at UC San Diego, Cycuity’s Radix technology was successfully applied to OpenTitan’s OTP controller, validating some challenging security requirements.
Security Verification
OpenTitan’s security features enable it to serve well as a root of trust for systems adopting it. Systematically specifying security requirements and then building a security verification plan for those requirements helps achieve the highest levels of assurance for a design.
This low-level verification, though, can be hard to pull off because expressing specific security requirements as concise verification rules can be a complex undertaking. Security requirements are often vague or poorly specified, and the specifics of functional implementation are often glossed over in a way that leaves ambiguity and potential vulnerabilities.
Even with a good set of verification rules established, those rules are of no use unless they can be executed within the existing design verification environments.
Cycuity’s Radix products use information flow, an innovative approach that encourages and enables concise, accurate verification rules. Further, Radix easily identifies rule violations, then offering security analysis capabilities so that problems caused by ambiguities in the design can lead to quick refinements and clearer rules.
Example: Security Requirements for OpenTitan’s OTP Controller
Radix builds security requirements by basing them on design assets. To do so effectively, several components of the security requirement should be identified, including:
- Assets: Resources in the design that should be protected from an adversary
- Security Objectives: Confidentiality, Integrity, or Availability for the Assets
- Protections and Protection Boundaries for the design assets under the security objective
Using this framework creates succinct and verifiable security requirements that can be easily executed within the Radix software.
As you’d expect, many assets used within OpenTitan require protection from malicious adversaries. For example, there’s a random netlist key stored within OpenTitan’s one-time programmable (OTP) memory controller that is used to scramble user keys in order to protect them against physical attacks, such as those from fault injection. By using the approach described above, we created a concise security requirement for this random netlist key asset below:
“RndCnstKey should not be read on the OTP outputs”
Stating the requirement this way clearly identifies the asset as the RndCnstKey, the security objective as Confidentiality, and the protection boundary as the OTP outputs. We could thus easily create a Radix security rule and execute it within Radix in order to analyze any security violations.
Hardware Security Violations
A critical component of the security verification process is security analysis. This is crucial to ensure that the security requirements are correctly specified. It has the natural follow-on benefit that it assists in identifying unknown design weaknesses. Using Radix, we were able to validate that the random constant key never makes it to the output of the OTP controller in an unscrambled form, which is a good thing.
While applying Radix to the OTP controller, we did in fact identify intermediate values of the random constant key appearing on the output of the scrambler. This is interesting and surprising, but was determined to be a low risk since the intermediate values are protected at the boundary of the OTP output. While the risk was low, OpenTitan nevertheless opted to issue a patch to mitigate this leakage out of an abundance of caution.
This analysis enabled us to provide strong assurance that an adversary is unlikely to recover the random constant key and subvert the mitigations within the OTP controller, since the only way it can get access to key information externally is when the key is in a scrambled form. We will continue to work on several other design assets and security requirements to verify other important security features within OpenTitan in a similar manner. We will also share the security requirements and findings with the community to help advance OpenTitan’s secure development lifecycle.
Along with other best practices, defining concise security requirements and performing systematic security verification helps ensure these features are integrated and configured securely effectively hardens products through the entire design lifecycle.