Geopolitics have put enterprise data centers in the crosshairs of international espionage. From all corners of the globe, hackers of all sorts, including those aligned with national spy agencies, are zeroing in on hardware roots of trust.
For any computing platform, the root of trust is the ultimate line of defense against cybersecurity attacks. No matter how secure your operating system and applications appear to be, they are acutely vulnerable if running on a hardware platform whose root of trust has been compromised by an unauthorized party.
Trust is everything. If you breach a hardware platform’s root of trust, you can gain persistent—and often, stealthy—access to all data, processes, and other assets on that platform and to connected systems that trust it. Even so-called “zero-trust security,” which is fundamental to edge, mesh, and other distributed deployments, depends on ensuring that each hardware node can indeed trust that its firmware has not been surreptitiously compromised by a hacker.
For that reason, the hardware-level root of trust should at the very least perform these critical functions:
- securely store the server’s or device’s unique keys, credentials, and other security modules and actively mediate access to the first-stage boot firmware.
- create a trusted execution environment that enables secure identification and authentication of the hardware platform during boot-up.
- provide code protection, data protection, application isolation, firmware integrity assurance, tamper-proofing, and other services upon which all application-level security depends.
- verify that a server or a device boots only with the correct, untampered firmware code.
- enable users to verify that a server or a device is legitimate by using a cryptographically unique machine identity.
- cryptographically prove that machines can be trusted, haven’t added vulnerabilities, and aren’t surreptitiously under an adversary’s control.
- protect secrets such as encryption keys in a tamper-resistant way even for people with physical access, such as when a server or a device is being shipped.
- provide authoritative, tamper-evident audit records and other runtime security services.
- verify the exact sequence of everything that happens before the first instruction gets executed.
Traditionally, roots of trust have been highly proprietary and specific to each hardware platform. They have also been secret intellectual property that is safeguarded closely by chip fabricators.
At first glance, one might think that secrecy is essential for keeping a hardware root of trust secure, but there’s an even stronger case to be made for the opposite: greater transparency. One of the chief problems with heterogeneous, nonstandard, secret roots of trust is that they make it next to impossible—or at least highly infeasible—for a user to directly inspect that they have not been compromised by hackers.
Transparency and standardization are a better approach where roots of trust are concerned. If users can inspect, understand, and trust their machine at the lowest levels of firmware code, and compare the current setup against some standard open source template, they can more readily determine when it’s been breached by an unauthorized party.
Transparency can also mitigate the risks of supply chain attacks, which refers to having untrustworthy or compromised hardware suppliers, or hardware suppliers in nations that are not averse to planting surveillance back doors in systems designed for export. Having an open reference standard for hardware roots of trust can help determine whether a hardware platform’s security has been compromised at the source, perhaps by some secret agent masquerading as a factory worker.
Supply chain attacks are no small concern, especially in a world where a technologically advanced nation such as China is using its autocratic sway to gain a geopolitical advantage. In that regard, Google took an important step recently with the announcement of OpenTitan.
The project builds on security principles that were used to create Google’s Titan chips, which are installed in its data centers worldwide. Under the OpenTitan project, anyone can contribute to more transparent, trustworthy root of trust silicon design and integration guidelines.
The project is being developed by engineers and researchers from Google, ETH Zürich, G+D Mobile Security, lowRISC, Nuvoton Technology, and Western Digital. It includes reference firmware, verification collateral, and technical documentation. It incorporates an open-source lowRISC Ibex microprocessor, cryptographic processors, a hardware random number generator, key and memory hierarchies, and other silicon-level components into the design. It is being designed to integrate into data center servers, storage devices, peripherals, motherboards, IoT devices, and other hardware.
The resulting deliverables will be freely available, vendor agnostic, and platform agnostic. Project stewardship is with lowRISC, a U.K.-based nonprofit that uses collaborative engineering to develop and maintain open source silicon designs and tools for the long term. The OpenTitan repository is now available on GitHub; interested implementation partners need to undergo a certification process.
To be truly effective at code verification, OpenTitan would need to align its secure root of trust design with other industry open source initiatives that are building complementary capabilities at the application layer. One of the most noteworthy efforts in this regard is CodeQL, a recently announced semantic code analysis engine and query tool for finding security vulnerabilities across a codebase. GitHub recently made this distribution free for anyone to use in research or to analyze open source code. In addition, the Linux Foundation’s recently launched Confidential Computing Consortium is developing an open framework for enforcing application security at the hardware layer using trusted execution environments running in protected enclaves.
Whether the OpenTitan project succeeds in gaining support and adoption is too early to say. We should expect that the initiative will produce a reference design and guidelines by this time next year. It might take two or three more years to see the resultant design incorporated in a wide range of commercial hardware.
It might take even longer if some supplier nations refuse to implement the design, fearing (but not saying in so many words) that it could jeopardize their ability to continue planting secret backdoors in hardware exported from their shores.