TL;DR: This article gives an overview of the physical security testing framework that the OpenTitan® project uses for the security validation of its design.
For high-assurance silicon, “open source” must be synonymous with “verifiable.” While OpenTitan provides transparent hardware designs, true resilience is only proven when subjected to rigorous physical security testing. This article introduces our Physical Security Testing Framework—the collaborative, industrial-grade tooling we use to bridge the gap between architectural design and certified resistance against side-channel and fault injection attacks.

Physical Attacks
OpenTitan’s security threat model assumes an adversary with physical access to the chip. Consequently, OpenTitan must be resilient against physical attacks, which are categorized into active (invasive) and passive (non-invasive) methodologies.
Active Physical Attacks: Fault Injection
Active attacks involve the intentional manipulation of the chip’s operational environment to induce computational errors. Primary mechanisms for inducing faults include Laser Fault Injection (LFI), Electromagnetic Fault Injection (EMFI), and voltage/clock glitching. The effect of an injected fault is modelled in hardware as transient bit-flips or permanent stuck-at faults. This fault effect manifests itself at a higher level, i.e., software, and can be exploited by an adversary. Examples for fault injection exploits are to bypass conditional branches in secure boot sequences or disrupt cryptographic primitives to facilitate the recovery of secret keys through differential fault analysis.
Passive Physical Attacks: Side-Channel Analysis
Passive attacks involve the observation of unintended physical emanations without disrupting the chip’s execution. Examples include monitoring the power consumption or electromagnetic (EM) emissions of the chip being attacked. These attacks exploit the fact that hardware power consumption is data-dependent; the energy required for a computation varies based on the values being processed. Based on this observation, statistical methods, including Differential Power Analysis (DPA) and Correlation Power Analysis (CPA), are utilized to extract secret keys by correlating physical measurements with known cryptographic operations.
Security Certification
OpenTitan aims to achieve high-assurance security certifications, specifically targeting AVA_VAN.5 (Advanced Vulnerability Analysis) and compliance with Protection Profiles such as PP-0084 and PP-0117. To achieve this level of certification, hardening the chip against physical attacks is needed.
Mitigating these sophisticated physical attack vectors requires a rigorous, multi-layered defence strategy. This necessitates a complex interplay between hardware-level countermeasures (e.g., masking, redundancy, sensors, and others) and hardened software implementations.
The need for a Physical Security Testing Framework
To satisfy high-assurance security certification requirements, the OpenTitan project follows a rigorous pre- and post-silicon security testing and validation strategy:
- Pre-silicon FI and SCA security evaluation, such as formal masking verification and simulation-based leakage assessment as well as fault analysis using both research and commercial tools. More on that in an upcoming article!
- Pre- and post-silicon FI and SCA empirical security validation.
To conduct empirical security validation, lowRISC® together with other OpenTitan partners has developed the OpenTitan Physical Security Testing Framework.
Pre- and Post-Silicon
This framework enables the OpenTitan project to conduct security assessments during the entire lifecycle of the project, from pre-silicon RTL development to post-silicon security certification.
Pre-silicon analysis, which is conducted on FPGAs, allows for the evaluation of security IPs and RTL-level countermeasures early in the development phase. This enables the identification and remediation of vulnerabilities before tape-out, significantly reducing the cost and complexity of design iterations.
Post-silicon analysis, which is conducted on the taped out chip, is the definitive step in the security development cycle. Unlike FPGA simulations, post-silicon testing accounts for real-world environmental factors, including higher noise floors and the efficacy of analog countermeasures such as clock jitter. Furthermore, it allows for analysis of the whole chip integration rather than isolated IP blocks.
Collaborative Platform and Certification
The OpenTitan project operates as a highly collaborative partnership, leveraging the specialized expertise and laboratory resources of multiple organizations to achieve a common security goal. This model allows internal and external OpenTitan partners to complement each other:
- lowRISC maintains internal laboratory facilities equipped for power side-channel analysis and advanced electromagnetic fault injection (EMFI) equipment like the ChipWhisperer Husky and ChipShouter, respectively.
- Other partners contribute specialized knowledge and experimental setups for high-precision EM SCA and Laser Fault Injection (LFI), as well as other equipment.
The security testing framework acts as the primary enabler for this synergy, providing a unified interface that allows partners to share test vectors, analysis scripts, and initial evaluation results. Beyond the partnership, the framework is a critical tool for independent validation. It provides certification bodies and external laboratories with a standardized, reproducible methodology to conduct the rigorous vulnerability assessments required for high-assurance silicon certification.
OpenTitan’s Physical Security Testing Framework
To address these needs, lowRISC and its partners developed the OpenTitan Security Testing Framework—an open-source, collaborative platform designed for the rigorous evaluation of OpenTitan’s resilience against side-channel and fault injection attacks.

The block diagram above highlights the modular architecture consisting of the ot-sca host (marked in red), the penetration testing device framework (marked in purple), and the SCA/FI equipment (marked in green). While the host framework runs on the lab computer, the pentest framework is executed on OpenTitan.
Host Framework
The host framework, which is available in the open-source ot-sca repository, serves as the centralized orchestration layer for coordinating SCA and FI evaluations. Its core responsibilites are:
Attack Gear Drivers
ot-sca provides a rich set of drivers for the security analysis equipment we use for our side-channel and fault injection evaluations. Out of the box, ot-sca supports the NewAE Technology Inc. ChipWhisperer Husky for power SCA and voltage glitching as well as the ChipShover XYZ table and the ChipShouter EMFI station. Moreover, ot-sca offers support for high-end oscilloscopes (for power SCA and high-precision EM SCA) using the VX-11 protocol.

Due to the object oriented programming approach of ot-sca, security evaluators can easily extend the base driver to add support for other evaluation gear.
Target and Attack Gear Configuration
ot-sca is responsible for the automated setup of both the evaluation equipment and the target device (whether the FPGA or the final silicon). On the target, this configuration contains which piece of software we want to evaluate on the device as well as the input for the test, e.g., the fixed vs. random data set for a test vector leakage assessment (TVLA). For the attack gear, the configuration consists of the oscilloscope settings or the FI parameters, e.g., the shape of the injected electromagnetic pulse as well as the trigger offset.
Communication
The host maintains an active communication link with the target’s pentest framework to transmit configuration commands and monitor real-time execution status. Its standalone communication API is designed to allow seamless integration into existing laboratory infrastructures.
In addition to pure communication, ot-sca is also able to program FPGA bitstreams, flash software binaries, and reset the target if necessary.
Data Aggregation and Analysis
Upon test completion, the framework collects and archives evaluation results into a structured database. This backend enables engineers to perform post-processing tasks, including trace alignment, result visualization, and statistical leakage assessments such as TVLA.
Device Framework
The pentesting device framework, which is publicly available, is the specialized firmware resident on the OpenTitan target that enables us to test each part of OpenTitan. It awaits configuration commands from the ot-sca host to initialize and trigger specific test sequences.
Functional Flow
The firmware executes the following flow enabling us to achieve reproducible results:
- Configuration: The device receives test-specific parameters (e.g., keys, plaintexts, or register initializations) from ot-sca via the host interface.
- Test Preparation: The target state is stabilized (e.g., the register file is put into a known state), and internal monitors (such as alert handlers) are reset to prepare for the trigger window.
- Trigger Window: The framework toggles a dedicated hardware pin to signal the external SCA/FI gear to begin capture or injection precisely as the target enters the security-critical operation.
- Evaluation and Reporting: Post-execution, the device analyses the resulting state—checking for register corruption or alert triggers—and transmits the result back to the host.
Test Categorization
With over 230 tests exercising the entirety of the OpenTitan design, the suite is divided into two primary categories:
1. Characterization Tests
These are fine-grained, low-level tests designed to evaluate an isolated sub-part, e.g., a single IP or a specific implementation detail of an IP block of OpenTitan. For SCA analysis, this could be, for example, a trigger around an individual KMAC operation. For FI, those tests are usually written in assembly.
The following code snippet is used to test whether injecting faults into conditional branch instructions enables an adversary to redirect the control-flow of the executed program:

2. Production Tests
These evaluations focus on production-grade software stacks rather than isolated hardware or software primitives. The primary target is our cryptolib, which is hardened against SCA and FI based on the characterization tests, where we verify the efficacy of algorithmic countermeasures like masking and redundancy during standard operations such as AES or HMAC.
The standardization of these tests is critical for the OpenTitan ecosystem. Because the Device Framework provides a reproducible and transparent environment, it is utilized by Common Criteria labs and certification bodies during the independent assessment phase of the certification process. This ensures that the same rigorous metrics used during internal development are applied during formal high-assurance evaluations.
Continuous Integration and Regression Testing
To maintain the reliability of a framework utilized by various OpenTitan partners, external labs and built through multi-organizational contributions, a robust verification strategy is required. It is essential that the pentesting infrastructure itself remains functional as the underlying hardware and software evolve.
To address this, the security testing framework is fully integrated into the OpenTitan repository’s Continuous Integration (CI) pipeline. This integration ensures that the framework is validated on every pull request, preventing regressions that could compromise security evaluations. During CI execution, automated routines compare pentesting results against established test vectors on FPGAs. This automated validation covers a wide array of security-critical modules—including AES, HMAC, and the Ibex core—ensuring that the collaborative codebase remains stable and accurate for all stakeholders.
Summary
By open-sourcing our security testing framework, OpenTitan moves physical security from a “black box” lab into a transparent, collaborative ecosystem. This infrastructure allows us to quantify resilience at every stage—from the first line of RTL to final certification—ensuring that our Root of Trust is as robust in the physical world as it is in the digital one.
Get Involved
The OpenTitan project is stewarded by lowRISC C.I.C. a not-for-profit engineering company that creates and maintains commercial-grade open source silicon designs through its collaborative Silicon Commons® approach. As the post-quantum world comes ever closer the OpenTitan partnership and lowRISC are committed to a roadmap that addresses these challenges head on.
If you would like to find out more about OpenTitan and its approach to physical security testing then contact us at get-involved@opentitan.org.