💻 computer science

SPARC: Automated Root-Cause Analysis of Pre-Silicon Power Side-Channel Leakage in the Processor Design Flow

This paper presents SPARC, an automated pre-silicon framework that leverages macro-cell-level Information Flow Tracking to efficiently detect, evaluate, and pinpoint the specific hardware and software root causes of power side-channel leakage in processor designs, achieving significant simulation speedups over existing methods.

Original authors: Andrija Nešković, Christian Ewert, Mladen Berekovic, Saleh Mulhem

Published 2026-07-28

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Andrija Nešković, Christian Ewert, Mladen Berekovic, Saleh Mulhem

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a super-secret recipe for a delicious cake. You write it down, lock it in a safe, and tell a robot to bake it. You think you're safe because the robot can't read your notes. But what if the robot's oven makes a different hum when it's mixing sugar versus when it's mixing flour? Or what if the robot's power meter flickers slightly brighter when it handles the secret ingredient? A sneaky thief standing nearby could listen to those hums or watch the power meter to figure out your recipe, even without ever seeing the notes. This is the scary reality of "power side-channel attacks" in the world of computer chips. Modern computers are like these robots; they process secret data (like your passwords or encryption keys) using electricity. Every time a tiny switch inside the chip flips on or off, it uses a tiny bit of power. If the pattern of these power flips depends on the secret data, a clever attacker can listen to the power usage and steal the secrets.

To stop this, engineers need to check their chip designs before they are physically built (a stage called "pre-silicon"). They need to find exactly where and when the chip is accidentally whispering secrets through its power usage. The problem is that modern chips are incredibly complex, with billions of tiny parts. Trying to check every single part is like trying to find a specific needle in a haystack by looking at every single piece of hay one by one—it takes forever and is often impossible. Existing tools are either too slow to handle big designs or they can't tell you which specific instruction in the software or which wire in the hardware is causing the leak. They just say, "Hey, there's a leak somewhere," but they don't give you the map to fix it.

Enter SPARC, a new automated detective tool introduced by researchers Andrija Nešković and his team. Think of SPARC as a super-smart, high-speed security guard that doesn't just look at the whole building; it wears special "tinted glasses" that only let it see the parts of the chip that are touching the secret data. Instead of checking every single wire in the processor, SPARC uses a technique called "Information Flow Tracking" to tag the secret data as it moves through the chip. It then builds a special "shadow" version of the chip that only pays attention to the wires carrying these tagged secrets.

Here is how SPARC solves the mystery:

The Tagging: When the chip runs a secret program (like an encryption algorithm), SPARC tags the data. It's like putting a glowing sticker on every piece of secret information.
The Shadow: SPARC creates a simplified, fast-running version of the chip that only tracks the glowing stickers. It ignores everything else. This makes the simulation incredibly fast—about 8 times faster than previous methods for similar designs.
The Listening: As the chip runs, SPARC measures the "power" of the glowing stickers. It uses a statistical test (a fancy math way of saying "is this pattern different by chance or by design?") to spot exactly which moments in time the chip is leaking secrets.
The Root Cause: This is the magic part. Once SPARC finds a leak, it doesn't just stop there. It traces the glowing sticker back to the exact wire in the hardware that is flickering and the exact line of code in the software that caused it. It tells the engineers, "Hey, the secret is leaking because of this specific instruction in the program interacting with this specific register in the chip."

The researchers tested SPARC on three different types of computer processors (small ones for simple tasks, and big, fast ones for complex jobs) and two different types of secret math (a classic code called AES and a new, quantum-resistant code called ML-KEM). They found that SPARC could successfully spot known leaks and even discover new, sneaky leaks in the "out-of-order" processors (chips that do things in a different order to be faster) that were hiding even when the software tried to hide the secrets.

For example, on one of the processors, SPARC found that even though the software was using a "masking" technique (a way of scrambling the secret so it looks random), the chip's internal "reorder buffer" (a waiting room for instructions) was accidentally leaking the secret's shape through its power usage. SPARC pinpointed the exact hardware signals and the specific software instructions responsible.

The results are promising: SPARC can analyze a complex processor running a massive encryption task in just a few hours (or even minutes for simpler tasks), whereas older methods might take days or fail entirely. By giving engineers a clear map of what is leaking and why, SPARC helps them fix the design before the chip is ever built, making future computers much harder to hack. It's like giving the chef a list of exactly which ingredients are making the oven hum, so they can change the recipe or the oven design before anyone steals the secret.

Technical Summary: SPARC – Automated Root-Cause Analysis of Pre-Silicon Power Side-Channel Leakage

1. Problem Statement

Power Side-Channel Leakage (PSCL) poses a severe threat to the confidentiality of cryptographic software, originating from architectural and micro-architectural artifacts in processor designs. While software and hardware countermeasures (e.g., masking) exist, vulnerabilities at the CPU level can compromise these protections. A critical gap exists in pre-silicon evaluation: current frameworks lack the ability to simultaneously provide scalability, secret-sensitivity, and joint hardware-and-software root-cause attribution.

Existing approaches suffer from fundamental limitations:

Gate-level analysis: Reliance on complete gate-level netlists results in impractical runtimes (e.g., exceeding 60 hours for designs with ~100k cells).
Software/ISA-level analysis: Often ignores large portions of switching activity or fails to attribute leakage to underlying hardware signals.
Scalability vs. Precision: No existing framework offers a scalable method to identify when leakage occurs, which hardware signals contribute, and which software instructions trigger them within a pre-silicon context.

2. Methodology: SPARC Framework

SPARC is an automated framework designed to evaluate PSCL and perform root-cause analysis directly from simulation. It operates at the macro-cell level, serving as an intermediate abstraction between high-level RTL and low-level gate-level netlists. This level represents the design as graphs of parameterized functional primitives (adders, multiplexers, comparators), preserving semantic structure while avoiding HDL complexity and gate-level scalability issues.

The framework operates in four distinct phases:

2.1 Instrumentation (Macro-Cell IFT)

SPARC utilizes a dedicated transformation pass (implemented as a Yosys pass) to instrument RTL designs with Information Flow Tracking (IFT) and leakage estimation logic.

Taint Propagation: It tracks the reachability of secret data (e.g., cryptographic keys) through the hardware.
Leakage Shadows: For each signal $s$ $s$ , a leakage shadow $s_{leak}$ $s_{l e ak}$ is generated. A signal is considered leaking if it is both tainted (influenced by the secret) and transitions (switches state).
- For sequential elements: $s_{leak}[i][t] = (s[i][t] \oplus s[i][t-1]) \land s_{t0}[i][t]$ , where the XOR detects transitions and the AND enforces key dependency.
- For combinatorial nodes: A conservative model ( $s_{leak} = s_{t0}$ ) is applied, assuming any output change is leakage propagation.

2.2 Quantification

The instrumentation aggregates per-signal leakage indicators into scalar counters per simulation cycle to model dynamic power consumption:

Hamming Weight (HW) Counter: Counts the number of tainted bits holding a logic-1 value (modeling charge-dependent power).
Hamming Distance (HD) Counter: Counts the number of tainted bits that transitioned since the previous cycle (modeling transition-based power).
These counters provide a cycle-accurate proxy for key-dependent dynamic power, configurable to target specific modules or the entire design.

2.3 Leakage Evaluation (TVLA)

To detect leakage, SPARC employs Test Vector Leakage Assessment (TVLA) using Welch's $t$ -test.

Trace Generation: Matched pairs of simulation traces are generated where the plaintext and masking randomness are identical, but the secret key differs ( $K_0$ vs. $K_1$ ).
Hypothesis Testing: For each simulation cycle, the HW/HD counter values across trace groups are compared.
Decision Criterion: A cycle is classified as leaking if $|t| > 4.5$ . This identifies specific time intervals where the aggregate taint-filtered switching activity is statistically dependent on the key.

2.4 Root-Cause Attribution

Once leakage intervals are identified, SPARC performs a two-phase attribution:

Signal-Level Attribution: Within a leakage window, individual leakage shadow wires are compared between key groups. Signals are ranked by the cumulative key-dependent Hamming weight difference ( $\Delta_s$ ) to identify the dominant hardware carriers of the leakage.
Instruction-Level Attribution: The program counter (PC) values recorded during simulation are mapped to source-level functions and line numbers. This links the specific hardware signals to the executing software instructions (e.g., specific load/store or branching operations).

3. Key Contributions

Macro-Cell Level IFT: The deployment of IFT at the macro-cell level enables scalable identification of leakage sources across both hardware signals and software instructions, bridging the gap between RTL and gate-level analysis.
Automated Dual Root-Cause Analysis: The framework uniquely provides a pipeline that detects leaking cycles, pinpoints specific hardware signals, and maps them back to executing software instructions.
Scalable Simulation Environment: A dedicated transformation pass integrated into Verilator allows for the execution of cryptographic software and collection of secret-dependent leakage traces with significantly reduced runtime overhead compared to gate-level approaches.
Quantitative Leakage Modeling: The extension of IFT to model both value-based (HW) and transition-based (HD) leakage provides a fast, scalable pre-silicon evaluation flow.

4. Experimental Results

The framework was validated on three open-source RISC-V processors with varying micro-architectural complexities:

Ibex: 2-stage in-order, 32-bit (RV32IMC).
Proteus: Configurable out-of-order superscalar, 32-bit (RV32IM).
Rocket: 5-stage in-order, 64-bit (RV64G).

Workloads:

AES-128 (Unmasked and First-order Boolean Masked).
ML-KEM (CRYSTALS-Kyber-512, Unmasked).

Findings:

Leakage Detection: SPARC successfully detected key-dependent leakage across all processor-algorithm combinations, localizing leakage to specific simulation cycles.
Micro-architectural Leakage: In the masked AES-128 implementation on the Proteus processor, SPARC identified micro-architectural leakage artifacts (specifically in the reorder buffer, branch target predictor, and AXI bus) that violated masking assumptions, exposing key-dependent information despite first-order software protection.
Root-Cause Precision: The framework successfully mapped leakage peaks to specific hardware signals (e.g., Scheduler_rob_ssbPredictorEntries) and software instructions (e.g., add_round_key, memcpy).
Performance: SPARC achieved an 8x per-trace simulation speedup over previous approaches (e.g., Telescope) on comparable designs.
- Total evaluation time for AES (masked and unmasked) on the complex Proteus core was < 25 minutes.
- Total evaluation time for Kyber-512 on Proteus was ~10 hours.
- Instrumentation overhead was reasonable (< 9 minutes for complex processors), and the design size increased by only ~11-12%.

5. Significance and Claims

The paper claims that SPARC provides a practical framework to mitigate PSCL early in the design flow. By enabling precise and scalable root-cause analysis at the pre-silicon stage, it allows hardware designers to revise RTL (e.g., implementing dedicated key-loading paths or clearing secret-holding states) and software developers to restructure cryptographic operations immediately.

The authors emphasize that SPARC addresses the "three fundamental questions" of root-cause analysis:

RQ1: At which simulation cycles does the design leak?
RQ2: Which signals contribute to the leakage?
RQ3: Which software instructions cause the leakage?

The work positions itself as a tool for fast assess–modify–reassess iterations during the design phase, distinct from formal verification tools that offer guarantees for finalized designs but at high computational costs. The framework is intended to strengthen the security of future processors by identifying and remediating leakage sources before silicon fabrication.