Home
Visit GitHub
Home
Home
Home
Home

TL;DR: Building on our previous article about the OpenTitan Physical Security Testing Framework, this follow-up article explores our approach to pre-silicon security evaluation. Rather than relying solely on empirical measurements, we focus here on how we utilize advanced simulation and verification-based tools to assess our design against fault injection (FI) and side-channel analysis (SCA) threats long before tape-out. This proactive strategy incorporates a mix of commercial solutions and open-source research tools, including but not limited to novel evaluation methodologies lowRISC®’s Security Team has collaboratively developed and published together with researchers at top hardware security conferences.

Side-Channel and Fault Injection Attacks

OpenTitan® aims to achieve high-assurance security certifications, such as Common Criteria. This means our threat model fundamentally assumes that an adversary has direct physical access to the device. Hence, OpenTitan incorporates dedicated countermeasures to deter physical attacks which can be classified into two groups. 

  • Fault Injection (FI): Active attacks intentionally manipulate the chip’s operational environment – using voltage glitching, electromagnetic, or laser pulses – to induce computational errors. Adversaries exploit these induced faults to bypass secure boot or disrupt cryptographic primitives to extract secret keys.
  • Side-Channel Analysis (SCA): Passive attacks observe unintended physical emanations, such as power consumption or electromagnetic emissions (EM), without disrupting execution. Because hardware power consumption is inherently data-dependent, attackers use statistical methods like Differential Power Analysis (DPA) to correlate physical measurements with known cryptographic operations and recover secrets.

The design of such attacks, the design of suitable security countermeasures as well as the verification of these countermeasures against those attacks are both very active research areas in academia and industry.

In OpenTitan, we are following our Secure Hardware Design Guidelines and we rely on mature and robust security countermeasures that are well understood by the research community whenever possible. While FI and SCA attacks are fundamentally different, the robust countermeasures we use in OpenTitan to deter these two attack classes are typically based on some form of redundancy:

  • FI countermeasures: These typically involve storing and transmitting integrity bits alongside data and using error correcting codes (ECC) to detect mismatches, as well as verifying operations by doubling them either spatially or temporally.
  • Power-SCA and EM-SCA countermeasures: At a high level, masking countermeasures rely on adding one or multiple random numbers to the input of a critical operation to mask the secret, i.e., to split it into multiple random shares: one share consisting of the sum of the input and all random numbers, and one share per random number. Then, the shares are processed as much as possible in separation. This separation can happen either spatially or temporally. For operations that do not allow processing the shares independently, the individual logical operations involving multiple shares have to follow a strict order. As the input shares are random, all intermediate results are random and the power and EM side channels correlate with these random intermediate results instead of with the secret. At the very end, the shares are again summed up to obtain the actual result.

This redundancy can lead to notable overheads in silicon area, power and/or run time. For that reason, security countermeasures are prime targets for automated design optimizations of modern IC design flows targeting maximum area efficiency and minimal power consumption. Pre- and post-silicon verification of security countermeasures is thus a hard requirement when targeting high-assurance certifications and key steps in our secure development lifecycle.

OpenTitan’s Secure Development Lifecycle

To satisfy our high-assurance requirements, OpenTitan adheres to a rigorous secure development lifecycle encompassing both pre- and post-silicon security analysis.

Pre-silicon evaluation is a critical first step. By identifying and remediating vulnerabilities early at the RTL level, we avoid the significant costs and delays associated with iterating a physical chip tape-out.

However, pre-silicon evaluation alone is insufficient. Our partners conduct extensive post-silicon analysis on the final taped-out chip to assess the complete integration under real-world conditions, accounting for environmental variables like higher noise floors and the efficacy of analog sensors.

The Need for Pre-Silicon Analysis Tools

As highlighted in the previous article, the OpenTitan project, including lowRISC, uses the Physical Security Testing Framework to conduct pre-silicon security assessments on our FPGAs. However, while empirical pre-silicon evaluation is a necessary step in our development lifecycle, it comes with several inherent drawbacks:

  • Limited FI applicability: We do not conduct fault injection evaluation on pre-silicon FPGAs. Mapping physical fault behaviors from an FPGA to the final ASIC is not straightforward, and the results are often neither accurate nor directly translatable.
  • Time and reproducibility challenges: Empirical pre-silicon evaluations on FPGAs are highly time-consuming. The physical laboratory setups are difficult to master, meaning results are not always 100% reproducible. In this context, we have observed that slight variations in FPGA bitstreams can introduce inconsistencies. Hence, iterating over security improvements is challenging.
  • Complex root-cause analysis: When taking physical measurements, we are observing the behavior of the entire FPGA. This macroscopic view makes pinpointing the exact root cause of a vulnerability within the underlying RTL exceedingly difficult.

Hence, to address these limitations and complement OpenTitan’s physical testing framework, we also rely heavily on pre-silicon simulation and verification tools to precisely assess our design against FI and SCA attacks before tape-out.

Pre-Silicon Security Simulation and Verification

For the OpenTitan project, we have developed a robust suite of simulation and verification tools to evaluate the resilience of our designs against physical attacks. This approach helps to increase the likelihood of identifying and mitigating vulnerabilities directly during the development of the hardware as recommended by Fraunhofer AISEC and Germany’s BSI1.

Our methodology leverages a powerful combination of state-of-the-art commercial solutions and cutting-edge open-source academic tools. Beyond simply using existing software, lowRISC actively contributes to the advancement of this field. In close collaboration with academic researchers, lowRISC’s security team conducts original research on pre-silicon security methodologies and has developed and published several of these novel evaluation tools at top hardware security conferences.

By deeply integrating these simulation and formal verification techniques into our secure development lifecycle, we can not only shorten the development lifecycle but also rigorously validate our countermeasures. Ultimately, this multi-layered analysis gives us high confidence that our security countermeasures are right first-time long before our commercial partners commit to a costly tape-out.

Side-Channel Analysis Tools

To harden our designs against SCA attacks, we typically leverage a combination of different techniques with a robust masking countermeasure such as Domain-Oriented Masking (DOM) at the basis2. What all robust masking countermeasures share in common besides substantially increasing design complexity is 1) that their security guarantees rely on the strict ordering of logical operations and 2) that they are oblivious to modern IC design tool flows. For example, even if implemented correctly at the RTL level, logic synthesis typically heavily optimizes these parts by reordering, combining and reducing logic operations to the bare minimum for achieving functional correctness measured by logical equivalence at functional block boundaries, thereby potentially fundamentally breaking masking countermeasures.

To address these challenges, the OpenTitan project has 1) developed a robust flow for encapsulating logic synthesis constraints in logic gate wrappers (so called primitives or prims) to allow the placement of firm synthesis optimization barriers directly in the RTL which reliably translate across ASIC technologies and IC design tool flows. To verify the correct placement of these barriers and further the implementation of the masking countermeasure and its translation to the netlist (2), we rely on a multi-pillar open-source verification methodology. This methodology consists of using formal and simulation based tools as well as FPGA evaluations: 

Formal Masking Verification using CocoAlma

The hardware masking countermeasures implemented in OpenTitan are provably secure, meaning their security guarantees can be formally proven for a specific netlist implementation including circuit-level effects such as transients and glitches. One such tool and the tool we use in the OpenTitan project is CocoAlma3 4 developed by the Institute of Information Security (ISEC) at TU Graz. In a nutshell, CocoAlma verifies that the different random shares of a secret cannot get combined anywhere in the circuit during processing. As a result, all intermediate results inside the circuit are random and side-channel measurements are uncorrelated to the actual secret.

We started using CocoAlma and its predecessor in OpenTitan back in 2020 and over the years have regularly collaborated with the tool developers and researchers at ISEC to share results and advice, as well as to implement minor tool modifications. Like the CocoAlma tool itself, the verification flows we have developed are open-source, too. The following CocoAlma flows are available as part of the main OpenTitan codebase (together with open-source Yosys synthesis flows that can be used to generate the behavioral netlists CocoAlma verifies).

Today, CocoAlma is the default tool for verifying masking countermeasures in new OpenTitan designs and for re-validating designs before tapeout. The main benefits of the tool in our view are the reasonable run times and memory requirements, that the tool precisely pinpoints issues in the spatial and temporal dimension, and most importantly, that the tool reliably detects issues if they exist – Our experience with CocoAlma throughout the development of the designs that went into the first production OpenTitan silicon is very positive and subsequent pentesting campaigns on the actual silicon, performed by our partners, helped validate our methodology.

The main limitation we see is that CocoAlma cannot be used to verify the interplay of masking countermeasures and the pseudo-random number generators (PRNGs) used to provide the masking countermeasures with fresh randomness. But as CocoAlma is a formal tool and because those random number generators only provide pseudo-random numbers, this is to be expected. Luckily, there are other analysis methods to close this particular gap.

Simulation-Based Leakage Assessment using PROLEAD

Unlike CocoAlma which is a formal masking verifier, the PROLEAD6 tool, developed by the Ruhr University of Bochum (RUB) and the Horst Görtz Institute for IT Security, allows the experimental analysis of the statistical independence of simulated intermediate values in gate-level netlists. Or in other words, while CocoAlma verifies that the shares of a secret cannot get combined anywhere in a circuit, PROLEAD analyzes whether the intermediate values of all nodes in the circuit remain uncorrelated with the actual secret throughout processing. To this end, PROLEAD performs a fixed-vs-random analysis, i.e., it simulates all netlist node values when processing fixed and random data sets, and then does a statistical test on the node values of these data sets. If the two data sets can be differentiated based on the simulated node values, the masking countermeasure is likely not working as intended.

We started using PROLEAD in 2023 after researchers from RUB, UCLouvain and KU Leuven working on an academic publication on PRNGs for masking countermeasures7 approached us regarding analyzing the masked OpenTitan AES core including its PRNG with PROLEAD8. After helping the researchers to debug a tooling issue in the open-source synthesis flow, they helped us setting up PROLEAD and analyzing the design. While our masked AES design passed the analysis with PROLEAD, the researchers pointed out a potential SCA vulnerability in our original PRNG architecture itself. We then switched to a Trivium-based PRNG implementation as recommended by the researchers and re-ran all experiments before the tapeout of the first production OpenTitan silicon.

Since then, we use PROLEAD whenever possible to analyze our designs. And just like for CocoAlma, we also share our PROLEAD setups as part of the main OpenTitan codebase.

FPGA-based Pre-Silicon SCA Evaluation

While our experience with both CocoAlma and PROLEAD is very positive and we heavily use these tools during the development of new designs, we always perform an FPGA-based SCA evaluation campaign before closing the design and again before tapeout to maximize the confidence in our countermeasures. The advantage of having all three flows available is that by focusing on CocoAlma and PROLEAD during development, we can notably reduce the number of iterations from the more time consuming FPGA evaluation campaigns. To find out more about our FPGA-based pre-silicon SCA flow, please refer to our previous article. 

Fault Injection Analysis Tools

When evaluating a design against fault injection attacks before silicon is manufactured, we need tools capable of mathematically proving our countermeasures or accurately simulating the propagation of errors through our RTL. To achieve this, we rely on a combination of custom research tools and commercial simulation software:

SYNFI: Published at CHES 2022, SYNFI9 is a formal verification tool developed in a joint research effort between lowRISC, Google, and Graz University of Technology. SYNFI performs formal fault injection verification directly at the gate-level netlist. Internally, it translates the hardware circuit into a Boolean satisfiability (SAT) formula. The tool then mathematically evaluates whether an injected fault can manipulate the circuit’s output without triggering the dedicated fault injection countermeasures. SYNFI has been used to analyze fault injection resilient building blocks, such as multi-rail finite state machines.

Fault-Resistant Partitioning: Published at CHES 202410, this methodology was developed in collaboration with CEA List, Université Paris-Saclay, Graz University of Technology, Université Grenoble Alpes, Thales DIS, and Sorbonne University. We utilized this formal tool to verify the dual-core lockstep countermeasures of our Ibex® RISC-V core using a rigorous, two-fold approach. First, it performs formal verification at the hardware level using a novel “k-fault-resistant partitioning” notion to pinpoint structural weaknesses. Second, it analyzes software exploitability: by simulating Ibex in Verilator, the tool injects the precise hardware faults identified in the formal step to check if they cause an exploitable software implication. This highly targeted approach successfully allowed us to identify and fix an FI vulnerability in the lockstep architecture before tape-out.

Commercial EDA FI Simulation: In addition to academic research tools, we utilize the commercially available Synopsys VC Z01X Fault Simulator to perform fault simulation directly on the RTL or the gate-level netlist. The primary advantage of this commercial tooling is its seamless integration into our existing Design Verification (DV) infrastructure. This setup allows us to inject simulated faults during routine testing to check if an error can affect the circuit’s output undetected. Because it runs directly alongside our normal DV suites, this tool is exceptionally helpful for continuous security evaluation during the day-to-day development of new IP blocks.

Access to Tooling: While we actively publish our research and methodologies, please note that access to some of this specialized fault injection tooling is currently only available for OpenTitan Silver members and above.

Conclusion: A Multi-Layered Defense Before Tape-Out

Securing high-assurance silicon requires a proactive and comprehensive defense strategy. For the OpenTitan project, this means employing a rigorous, multi-layered approach to pre-silicon security assessment. By combining the hands-on empirical validation of our physical testing framework with advanced formal verification and simulation tools analyzing the RTL design directly, we establish a robust security posture long before manufacturing.

This dual methodology ensures that we uncover and mitigate vulnerabilities at the earliest possible stages. It allows us to pinpoint the root causes of weaknesses that physical measurements might miss, avoiding costly tape-out iterations while building the highest level of confidence in our side-channel and fault injection countermeasures. Ultimately, this comprehensive pre-silicon evaluation paves the way for building OpenTitan designs that are fundamentally resilient against physical attacks.

Acknowledgements

We would like to thank all authors of the cited publications as well as additional people involved in the mentioned collaborations for using OpenTitan as a research vehicle, for feeding back results and for the fruitful discussions.

Our long standing commercial OpenTitan partners, we would like to thank for making pre-silicon security simulation and verification a priority and for funding these efforts in the first place.

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. To ensure high-assurance security, the OpenTitan partnership and lowRISC are committed to a rigorous, multi-layered approach to pre-silicon security assessment. By developing and employing advanced formal verification and simulation tools, we address physical threats—such as side-channel and fault injection attacks—head-on long before manufacturing.

If you would like to find out more about OpenTitan and its approach to pre-silicon security assessment then contact us at get-involved@opentitan.org.

  1.  Federal Office for Information Security (BSI): “Security Evaluation of Hardware Design Synthesis”, 2024, https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Hardware-Attacks/Security-Evaluation_Hardwaredesign-Synthesis.pdf
  2. Gross, Hannes, Stefan Mangard, and Thomas Korak, “Domain-Oriented Masking: Compact Masked Hardware Implementations with Arbitrary Protection Order”, Cryptology ePrint Archive, Paper 2016/486, 2016
  3. Hadžić, Vedad, and Roderick Bloem. “COCOALMA: A versatile masking verifier.” In 2021 Formal Methods in Computer Aided Design (FMCAD), pp. 14-23. IEEE, 2021
  4. Gigerl, Barbara, Vedad Hadzic, Robert Primas, Stefan Mangard, and Roderick Bloem. “Coco:{Co-Design} and {Co-Verification} of masked software implementations on {CPUs}.” In 30th USENIX security symposium (USENIX security 21), pp. 1469-1468. 2021
  5. By default, CocoAlma works on behavioral Yosys netlists. For the AES DOM S-Box, OpenTitan partners have developed an extended flow operating on actual post-synthesis gate-level netlists
  6. Müller, Nicolai, and Amir Moradi. “Prolead: A probing-based hardware leakage detection tool.” IACR Transactions on Cryptographic Hardware and Embedded Systems (2022): 311-348
  7. Cassiers, Gaëtan, Loïc Masure, Charles Momin, Thorben Moos, Amir Moradi, and François-Xavier Standaert. “Randomness Generation for Secure Hardware Masking – Unrolled Trivium to the Rescue”, Cryptology ePrint Archive, Paper 2023/1134
  8. https://github.com/lowRISC/opentitan/issues/19091
  9. Nasahl, Pascal, Miguel Osorio, Pirmin Vogel, Michael Schaffner, Timothy Trippel, Dominic Rizzo, and Stefan Mangard. “SYNFI: Pre-Silicon Fault Analysis of an Open-Source Secure Element.” IACR Transactions on Cryptographic Hardware and Embedded Systems (2022): 56-87
  10. Tollec, Simon, Vedad Hadžic, Pascal Nasahl, Mihail Asavoae, Roderick Bloem, Damien Couroussé, Karine Heydemann, Mathieu Jan, and Stefan Mangard. “Fault-Resistant Partitioning of Secure CPUs for System Co-Verification against Faults.” IACR Transactions on Cryptographic Hardware and Embedded Systems 2024, no. 4 (2024): 179-204