OpenTitan makes the root of trust an inspectable build artifact

An Earl Grey production-silicon sample sits beneath Fraunhofer AISEC's laser fault-injection apparatus. The exposed package, optical objective, and drilled laboratory table turn a claim about physical attack resistance into a testable object.[7]

OpenTitan is the rare open-source project whose build artifact can become impossible to patch. Its SystemVerilog, firmware, tests, and documentation ultimately resolve into masks and silicon; an error discovered after fabrication may demand a workaround, a new metal layer, or another chip revision rather than a quick release. That makes the project's 2026 transition unusually consequential. In March, the Earl Grey design began shipping as the security chip in Chromebooks. In July, work on its successor, Earl Grey 2, was moving into the open with post-quantum cryptography and memory-safety changes on the roadmap.[2][9]

This is the right moment to meet OpenTitan as a project rather than as a slogan about “open chips.” It is a complete, inspectable root-of-trust design: processor and cryptographic hardware, immutable boot code, mutable firmware, chip life-cycle controls, validation software, and a governance process intended to carry them together. The interesting achievement is not that every layer is open—some cannot be. It is that many of the assumptions normally buried inside a security chip have names, interfaces, tests, and review history before the design reaches a foundry.

Begin with the first decision a machine trusts

A root of trust does not make the whole computer trustworthy. It supplies the first small set of mechanisms from which later claims can be checked. On power-up, a machine needs some basis for deciding which firmware may execute, which device identity is genuine, and which measurements can be reported to an owner. If that basis is compromised, every verification layered above it can be internally consistent and still start from a lie.

OpenTitan makes that starting point explicit. Its security model covers provisioning, chip identity, owner credentials, secure boot, attestation, firmware update, ownership transfer, and the one-way life-cycle transitions that govern what a device is allowed to do. Earl Grey's ROM holds public keys used to authenticate the first stage in flash; each stage verifies the next and can lock hardware that later code no longer needs. Two flash partitions permit an update to be written into an inactive slot and verified before activation.[4]

That sequence is more important than any one encryption engine. The chip has to know whether it is being manufactured, tested, deployed, or returned for analysis. It has to distinguish the silicon creator from the eventual silicon owner. It must derive secrets without exposing root material to ordinary firmware, and it must fail in a controlled way when a sensor or integrity check raises an alert. “Trust” here is a chain of state transitions, key policy, and shrinking privilege—not a magic property stamped onto a package.

The repository contains a product, not merely an instruction set

RISC-V is one ingredient, not the project. OpenTitan's monorepo places hardware RTL, firmware, host utilities, build rules, verification environments, and their documentation under an Apache 2.0 license.[5] Earl Grey uses a 32-bit Ibex RISC-V core in dual-core lockstep, but the root-of-trust work sits around it: scrambled ROM, flash, SRAM, and one-time-programmable memory; a key manager; an entropy source and cryptographically secure random-number generator; AES, HMAC, KMAC, and the programmable OpenTitan Big Number Accelerator; plus a life-cycle controller and alert handler.[3]

The divisions are deliberate. The Ibex cores execute policy. The key manager derives secrets bound to the boot state. OTP stores manufacturing configuration, root secrets, and life-cycle state. The entropy complex feeds cryptographic consumers. The alert handler gathers security faults and can escalate them. OTBN runs big-number operations in a separately designed accelerator rather than asking general firmware to improvise sensitive arithmetic. Peripheral register interfaces and low-level Device Interface Functions give verification and early-silicon code a shared way to exercise each block, while the project warns that those functions are references and test artifacts, not a ready-made production operating-system driver stack.[3][5]

This is what “open silicon” adds beyond an open instruction-set architecture. An ISA tells a processor what instructions mean. OpenTitan exposes a particular security system: the RTL implementing blocks, the register contracts that connect them, the firmware that boots them, and the verification evidence used to decide whether they are ready. A reviewer can inspect why a boot stage accepts an image, trace an alert from its source, or compare the implementation of an accelerator with its specification. Openness does not prove those things correct. It makes disagreement specific.

The photograph puts the claim under an objective

The cover photograph is a security argument stripped of abstraction. An Earl Grey sample sits on a purple circuit board beneath the optical assembly of Fraunhofer AISEC's laser fault-injection apparatus. The laboratory reports chemically etching and precision-milling samples so that light, electromagnetic energy, timing, and power measurements could be used to probe the fabricated device.[7] Between source code and that experiment lie synthesis, physical design, fabrication, packaging, board design, provisioning, and lab work. A public repository does not erase any of them.

lowRISC states the boundary plainly. Building a secure SoC around OpenTitan still requires analog IP such as entropy sources and sensors, foundry-specific memories and power structures, vendor software, specialized security knowledge, and substantial certification work. Some of that material remains proprietary. Production Earl Grey parts used by Google are not general open-market components; for most outsiders, the accessible targets are simulation or supported FPGA boards.[1]

That is not a gotcha that makes the project “not really open.” It is the useful boundary an evaluator must preserve. The logical design can be inspected while a fabricated instance still depends on a particular process, supply chain, package, board, provisioning ceremony, and owner configuration. A downstream vendor can also alter an open design badly. The security claim belongs to a reviewed implementation and its evidence, not automatically to anything carrying similar RTL.

You can run the contract before you can buy the chip

OpenTitan's most practical contribution for a newcomer may be that its hardware/software seam can run before physical silicon is available. The getting-started flow builds the RTL into a cycle-accurate Verilator model, builds device software with Bazel, supplies images for ROM, flash, and OTP, and then runs tests through opentitantool. The official UART smoke test ends by showing the test ROM hand off to flash. Because the OTP image contains life-cycle state and secrets rather than executable code, even the simulator preserves a distinction that a software-only mock could easily flatten.[6]

The entry cost is real. The documentation calls for at least 7 GiB of available memory to build the Verilator simulation and recommends 32 GiB of physical RAM plus 512 GiB of storage for a machine intended for full top-level work. A first smoke-test build can take about an hour on a laptop. FPGA work adds supported boards, vendor tools, bitstreams, and a debug interface.[6] This is not a library to add during a sprint.

A useful first encounter is therefore narrow: reproduce one pinned smoke test, retain the exact repository revision and generated artifacts, then follow one signal across boundaries. For example, trace how the simulated ROM authenticates flash, or how a UART test moves from a DIF call to a register write and an observable pin-level interface. The goal is not to claim expertise after one PASS!; it is to learn where the executable evidence lives and which assumptions the test does not cover.

Shipping silicon turns transparency into a testable claim

For years, OpenTitan's hardest question was whether a collaborative RTL project could survive the irreversible parts of commercial hardware development. IEEE Spectrum's 2024 account treated validated Earl Grey silicon as a milestone precisely because the work extended beyond an open ISA into design verification and a functional chip. It also emphasized the asymmetry with software: hardware bugs cannot always be repaired after release, so interface discipline and verification have to arrive earlier.[8]

Production does not settle the security question. It changes what can be tested. In 2026, Fraunhofer AISEC reported evaluating engineering and production Earl Grey silicon with side-channel analysis, laser and electromagnetic fault injection, optical emission analysis, and physical sample preparation. The work targeted components including Ibex, OTBN, memories, crypto accelerators, and security-critical control logic. Just as important, OpenTitan includes an open test catalog for side-channel and fault-injection experiments, allowing other teams to reproduce or extend parts of the evaluation rather than receiving only a certification claim.[7]

The careful conclusion is not “open means secure.” Public RTL can contain subtle flaws; public tests can miss the wrong threat; a correctly designed block can be integrated or provisioned incorrectly. OpenTitan's stronger proposition is procedural: more of the security argument can be connected to reviewable artifacts, and real silicon gives researchers something capable of falsifying that argument.

Know which project you are approaching

OpenTitan is a good fit for a silicon or platform-security team that needs a discrete root of trust, reusable security IP, or an integrated secure subsystem and can support hardware verification, firmware, provisioning, and certification. It is equally valuable to researchers studying fault attacks, secure boot, or open verification methods. A systems team can learn from its specifications even without planning a tapeout.

It is a poor fit for an application team merely searching for a drop-in TPM, a purchasable hobby module, or a faster general-purpose RISC-V computer. The production chips are not retail parts, the reference DIFs are not production drivers, and the public RTL cannot supply the foundry and analog dependencies needed to manufacture a secure device.[1] Treating the roadmap as released capability is another failure mode: Earl Grey 2's CHERI, ML-KEM and ML-DSA acceleration, I3C, and power changes have staged 2026–2027 maturity targets, and the project explicitly labels roadmap dates as proposals rather than commitments.[9]

The best way to understand OpenTitan is to notice what it refuses to compress into one word. A root of trust is a boot sequence, a device state, a key hierarchy, a physical attack surface, and a manufacturing history. Open source is a license, a review process, a test corpus, and a boundary around material that remains closed. A chip is an artifact that must agree with all of them after the easy edits are over.

OpenTitan matters because those statements can now be checked against both a repository and shipped silicon. The sample beneath the laboratory objective is not the end of the trust story. It is the moment the written argument finally meets the object that can prove it wrong.

cronfeed.work