This paper is accepted for publication at the International Conference on Computer Aided Design (ICCAD 2026) November 08–12, 2026, San Jose, CA
arXiv:2607.23218v1 [cs.CR] 25 Jul 2026
SPARC: Automated Root-Cause Analysis of Pre-Silicon Power Side-Channel Leakage in the Processor Design Flow Andrija Nešković
Christian Ewert
[email protected] Institute of Computer Engineering, Universität zu Lübeck Lübeck, Germany
[email protected] Institute of Computer Engineering, Universität zu Lübeck Lübeck, Germany
Mladen Berekovic
Saleh Mulhem
[email protected] Institute of Computer Engineering, Universität zu Lübeck Lübeck, Germany
[email protected] Institute of Computer Engineering, Universität zu Lübeck Lübeck, Germany
Abstract
Keywords
Power-Side-Channel Leakage (PSCL) originates from architectural and micro-architectural artifacts in a processor and poses a severe threat to the confidentiality of cryptographic software. Consequently, pre-silicon PSCL evaluation is indispensable for secure hardware design. Existing frameworks are either limited by poor simulation scalability or fail to attribute leakage to the correct hardware signals and software instructions, thereby impeding a comprehensive root-cause analysis. This paper presents SPARC, an automated framework for pre-silicon PSCL evaluation and root-cause analysis. SPARC leverages macro-cell-level Information Flow Tracking (IFT) augmented with enhanced shadow logic that tags switching activity originating from secret-dependent data. By isolating this activity, SPARC applies statistical leakage tests to detect PSCL, while simultaneously attributing the leakage to specific hardware signals and mapping those signals to the corresponding software instructions. This approach thus delivers a full end-to-end leakage evaluation and root-cause analysis for both hardware and software. To demonstrate and validate SPARC, PSCL of multiple open-source RISC-V CPUs, encompassing 32-bit and 64-bit cores with both in-order and out-of-order pipelines, is evaluated across a range of cryptographic workloads, including masked and unmasked AES and ML-KEM (CRYSTALS-Kyber-512). SPARC recovers known leakage sources as a sanity check and identifies specific microarchitectural leakage sources, achieving an 8x per-trace simulation speedup over previously shown approaches on comparable designs. By enabling precise and scalable root-cause analysis at the pre-silicon stage, this work provides a practical framework to mitigate PSCL early in the design flow, thereby strengthening the security of future processors.
Power side-channel analysis, Information flow tracking, Pre-silicon evaluation, Root-cause analysis, RISC-V
CCS Concepts • Security and privacy → Side-channel analysis and countermeasures.
This work is licensed under a Creative Commons Attribution 4.0 International License. ICCAD ’26, San Jose, CA, USA © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2873-0/2026/11 https://doi.org/10.1145/3831252.3834007
ACM Reference Format: Andrija Nešković, Christian Ewert, Mladen Berekovic, and Saleh Mulhem. 2026. SPARC: Automated Root-Cause Analysis of Pre-Silicon Power SideChannel Leakage in the Processor Design Flow. In IEEE/ACM International Conference on Computer-Aided Design (ICCAD ’26), November 08–12, 2026, San Jose, CA, USA. ACM, New York, NY, USA, 9 pages. https://doi.org/10. 1145/3831252.3834007
1
Introduction
Since the introduction of Power Side-Channel Attacks (PSCA) [9, 17], the notion of secure implementation has expanded beyond algorithmic cryptographic security to include implementation-specific vulnerabilities, such as Power Side-Channel Leakage (PSCL). Although software and hardware countermeasures like masking [13] can mitigate PSCL, vulnerabilities at the architectural and microarchitectural levels of CPUs may compromise these protections [1, 10]. Consequently, a precise pre-silicon root-cause analysis is essential to identify the exact hardware signals and software instructions that leak secret data, thereby enabling targeted countermeasure deployment. Current hardware-level root-cause analysis techniques suffer from fundamental limitations. Their reliance on complete gate-level netlists often results in runtimes exceeding 60 hours for designs with roughly 100k cells, rendering them impractical for most designs [29]. Recent software-level approaches either ignore a large portion of switching activity, limiting scalability to complex CPU pipelines [18], or focus solely on software behavior, leaving the underlying hardware unexplored [2]. To the best of our knowledge, no framework simultaneously offers scalability, secret-sensitivity awareness, and joint hardware-and-software root-cause attribution in a pre-silicon context. To bridge this gap, a novel root-cause analysis methodology is essential to rigorously address three fundamental questions: RQ1 : At which simulation cycles does the design leak? RQ2 : Which signals contribute to the leakage? RQ3 : Which software instructions cause the leakage? Collectively, these features enable efficient pre-silicon root-cause analysis that is scalable, secret-sensitive, and actionable for both hardware designers and software developers.
ICCAD ’26, November 08–12, 2026, San Jose, CA, USA
RTL
Macrocell / Cell-level A
y = a+b; if (cond) {...}
B Cin
=1
=1 &
Gate-level Netlist A B Cin
y
≥1
Nešković et al.
burden of gate-level correlation analysis while delivering finer attribution than typical RTL-level approaches. • Empirical validation: We evaluate both masked and unmasked implementations of AES 128 and ML-KEM (CRYSTALS Kyber-512) on a spectrum of open-source RISC-V cores (32-bit and 64-bit, in-order and out-of-order pipelines). The results demonstrate SPARC’s effectiveness in detecting and pinpointing side-channel leakage across diverse processor architectures.
y
Cout
Cout
&
High-level behavioral representation with rich semantics but high analysis complexity.
Structured intermediate representation using functional primitives, balancing scalability and precision
Low-level Boolean representation with full completeness but poor scalability.
Technology Independent
Technology Independent
Technology Dependent
Abstraction
Detail
2 Figure 1: Comparison of hardware abstraction levels
1.1
Contribution
In this paper, we present SPARC 1 , an automated framework for presilicon PSCL evaluation and root-cause analysis of cryptographic software executing on CPUs. The primary innovation is to deploy Information Flow Tracking (IFT) at the macro-cell level for PSCL evaluation. This enables scalable identification of leakage sources across both hardware signals and software instructions. The macrocell abstraction level serves as an intermediate representation between RTL and gate-level netlists, as illustrated in Fig. 1. In this abstraction, the targeted design is represented as graphs of parameterized functional primitives such as adders, multiplexers, and comparators. This abstraction preserves the semantic structure of the design while avoiding the complexity of HDL constructs and the scalability challenges of full gate-level representations. As previously demonstrated in [24], instrumenting designs at this level with IFT logic enables tracking of secret propagation in complex CPUs and full SoCs. Building upon this, SPARC monitors the flow of secret data through the hardware during cryptographic software execution, tracking only activity that is demonstrably secret-dependent. This focus on secret-sensitive switching directly mitigates the scalability limitations that have plagued previous PSCL evaluation methods. The key contributions of SPARC are as follows: • Cycle-accurate simulation environment: A dedicated transformation pass (realized as Yosys pass [28]) that instruments RTL designs with macro-cell level IFT and PSCL estimation logic. This pass is integrated into Verilator [23] for executing cryptographic software and collecting secretdependent leakage traces. • Automated dual root-cause analysis: Our leakage evaluation pipeline applies statistical tests to detect leaking cycles, then performs a two-phase attribution: – Pinpointing leaky hardware signals within the design. – Mapping those signals back to the executing software instructions. The proposed leakage-estimation logic extends the IFT instrumentation to model both value-based and transitionbased leakage, quantified with Hamming-Weight (HW) and Hamming -Distance (HD) metrics. This yields a fast, scalable pre-silicon evaluation flow that circumvents the runtime 1 Source code available: https://github.com/iti-luebeck/sparc-sca
Background and Related Work
Addressing PSC attacks [9, 17] in modern processors requires understanding three fundamental challenges. First, precisely characterizing how and where PSCL arises in hardware and software. Second, tracking the propagation of secrets through complex digital designs in a scalable manner. Third, attributing leakage sources to both specific hardware signals and the software instructions that trigger them, enabling feedback for designers and developers. In this section, we establish the necessary background across these three dimensions and identify the research gap that motivates our proposed approach.
2.1
Power Side Channel Leakage
Cryptographic implementations are susceptible to side-channel attacks, in which sensitive data can be extracted by examining a device’s physical characteristics during operation. Exploitable power characteristics arising from input-dependent switching in CMOS technology enable adversarial side-channel attacks [25], rendering mathematically secure algorithms vulnerable in practice. The amount of current that a CMOS circuit draws at any given moment is greatly influenced by how often its transistors turn on and off. This activity level is determined by the data being handled within the circuit, and is referred to as dynamic power consumption. Attackers exploit the relationship between dynamic power consumption and data values to reveal secret keys with PSC attacks. Each time a gate switches, its load capacitance is charged or discharged. In general, we can model this dynamic power consumption as: 2 𝑃dyn = 𝛼 × 𝐶𝐿 × 𝑉𝑑𝑑 ×𝑓
(1)
where 𝛼 is the activity factor (data-dependent), 𝐶𝐿 is the load capacitance, 𝑉𝑑𝑑 is the supply voltage, and 𝑓 is the clock frequency. Because 𝛼 depends on the processed data, the power drawn by a circuit reflects the data values [22], providing the basis for PSC attacks. To reason about PSCL analytically, the data-dependent activity factor 𝛼 must be instantiated as a concrete leakage model that approximates how a circuit’s power consumption relates to the data it processes. Two leakage models are well established in the literature. First, the Hamming Weight (HW) model assumes that power consumption is proportional to the number of ones in the data word being processed. This model is appropriate when the dominant contribution to switching activity comes from the absolute value of a signal: for instance, when a register is written from a constant or zero state. Second, the Hamming Distance (HD) model instead captures transitionbased leakage, where power consumption depends on how many
SPARC: Automated Root-Cause Analysis of Pre-Silicon Power Side-Channel Leakage in the Processor Design Flow
bits change between two consecutive states. This model is more appropriate for sequential elements such as registers and flip-flops, where each clock cycle causes a transition from a previous state to a new one, and the switching activity is determined by the difference between them. Both models serve as the basis for the leakage estimation logic introduced in this work. Detecting whether a device’s power consumption leaks secret-dependent information is framed as a statistical hypothesis test that relies on one of the previous leakage models. The standard methodology is Test Vector Leakage Assessment (TVLA) [14], which uses Welch’s 𝑡-test. When |𝑡 | value exceeds a threshold (conventionally 4.5 [14]), it indicates that the device leaks information about the processed data.
2.2
Information Flow Tracking
Hardware Information Flow tracking enables the tracking of information propagation through an integrated circuit [16]. Static IFT is performed by analyzing all possible inputs to provide formal security guarantees without running a simulation. In practice, this scales poorly with growing design sizes, making the approach impractical for large designs [16]. Dynamic IFT instead propagates taint labels during simulation with chosen inputs, delivering a more scalable approach but offering no guarantees about unexercised paths. IFT can be performed at various abstraction levels, ranging from the software and architecture level down to the RTL [5], macro-cell level [24], and gate-level netlist (referred to as Gate Level Information Flow Tracking (GLIFT) [26]). Lower abstraction levels capture more precise information flows, with more detailed signal interactions and timing accuracy at the cost of complexity. Among these, CellIFT [24] operates at the macro-cell level by replacing each functional primitive in the RTL netlist with a taint-propagating counterpart, propagating taint labels through parameterized cells such as adders, multiplexers, and comparators without decomposing them into individual gates. This retains semantic structure while keeping the shadow logic overhead manageable, making it well-suited as the foundation for scalable IFT in complex designs such as CPUs. IFT was designed to track explicit and implicit information flows through the functional logic of a design, which manifests through data- and control-flow dependencies. Most of the existing work, therefore, covers classical security assertions and microarchitectural side channels, making no claims about PSCL evaluation [5, 24, 26]. To bridge this gap, Hamming Distance and Hamming Weight have been deployed to model the PSCL. In [30], an automated approach to model PSCL at RTL using IFT was introduced. It built an RTL IFT engine using commercial EDA tools to trace taint propagation from key and plaintext inputs through cryptographic engines. Employing both formal assertions based on HW and HD, as well as t-test analysis (for masked designs), this approach evaluates the PSCL of AES, Simon, and Present block cipher hardware engines. However, it has been validated only on relatively small cryptographic cores and incurs substantial simulation overhead, indicating a runtime of 27 hours for the bit-serialized Simon t-test evaluation [30]. Consequently, this approach may not scale well to larger designs with longer simulation run time (such as CPUs or whole SoCs). Security evaluations targeting PSC were also deployed using GLIFT [27]. It deploys Shannon entropy as a quantitative leakage metric to model the relation between taint label distributions
ICCAD ’26, November 08–12, 2026, San Jose, CA, USA
and power consumption characteristics. While GLIFT evaluation strategy reduces the number of required simulations compared to exhaustive approaches, it still suffers from overall scalability issues. Being implemented using GLIFT, the shadow logic doubles the design size, and the number of required simulations per key segment grows exponentially with the key segment size (8 bits in their experiments with cipher hardware engines) [27]. Therefore, this approach is not practical for CPU or SoC evaluations.
2.3
PSCL Root Cause Analysis
Several pre-silicon PSCL evaluation techniques have been proposed [2, 13, 15, 18, 20, 21]. These approaches simulate the design at the ISA, RTL, or gate level, extract switching activity, or estimate dynamic power to generate execution traces that can be evaluated using well-known post-silicon techniques. Frameworks such as RTL-PSC [15], SCRIPT [20], and PSC-TG [30] demonstrated the feasibility of PSCL assessment in pre-silicon. However, they offer little insight into which specific design elements are responsible for the leakage occurring. The need to explain leakage motivated the development of root-cause analysis techniques for PSCL. To evaluate cryptographic software implementations on RISC-V processors, Archer [2] went beyond leakage detection to identify and explain instruction-level sources of leakage. This enables the evaluation of the impact of compiler decisions, such as instruction scheduling and register allocation, on PSCL in cryptographic software implementations. However, Archer operates at the ISAsimulation level and does not extend its analysis to the underlying hardware design, leaving the hardware sources of leakage unattributed. Extending the root-cause analysis to hardware designs requires localizing leakage sources within a netlist. Architecture Correlation Analysis (ACA) was proposed in [29]. It ranks every cell in a gate-level netlist by its contribution using the Leakage Impact Factor (LIF), derived from the correlation between each cell’s switching activity and a leakage model. In their experiments targeting an AES engine and an SoC with a Leon3 processor (approx. 100k cells), the authors show that only a small subset of gates contributes to leakage. While accurate, the 60-hour runtime for the relatively small design highlights the practical constraints of gatelevel evaluation. Additionally, this approach provides no insight into the root cause analysis of software instructions. In [18], the authors proposed Telescope, a top-down hierarchical framework for PSCL evaluation at the architecture, microarchitecture, and gate levels, using toggle-count-based power estimation with TVLA. The root cause analysis in this framework can trace the PSCL back to individual software instructions. Nevertheless, its use of static timing analysis for signal path tracing, combined with the absence of information-flow tracking, requires considering all switching activity in the design rather than only secret-dependent signals, limiting scalability for complex CPU pipelines. An orthogonal line of work formally verifies the absence of leakage: CoCo [12] co-verifies masked software on a concrete CPU netlist, and Power Contracts [7] establish provably complete leakage models. Both offer guarantees SPARC does not target, at high cost (up to 35 h per contract for Ibex, repeated after every hardware change); they suit certification of finalized designs, whereas SPARC targets fast assess–modify–reassess iterations during design.
ICCAD ’26, November 08–12, 2026, San Jose, CA, USA
2.4
Nešković et al.
Motivation Processor Design (RTL)
The highlighted state-of-the-art techniques suffer from a steep simulation cost as their run-time grows exponentially, and they do not provide a mechanism for precise root-cause attribution that spans both hardware signals and software instructions. Combining dynamic information-flow tracking with activitybased leakage estimation at the macro-cell level could overcome these shortcomings. Isolating secret-dependent switching activity through taint propagation enables scalable pre-silicon evaluation of complex CPU designs while supporting precise root-cause attribution across both hardware signals and software instructions, a capability no existing framework provides jointly. Therefore, we propose SPARC to overcome the scalability and precision limitations of previous approaches to root-cause analysis of PSCL. It proposes a new, dedicated leakage-estimation logic based on HW and HD models, alongside macro-cell-level IFT. This solution enables scalable, secret-sensitive PSCL evaluation and root-cause analysis directly on CPU designs.
3
3.1
Yosys Pass
A signal in a synchronous design 𝐷 exhibits key-dependent power leakage if its switching activity differs statistically depending on computations with distinct keys 𝐾0 and 𝐾1 for the same plaintext. The signal 𝑠 leaks information depending on the dynamic power consumption 𝑃𝑑 𝑦𝑛 if: 𝑃 (transitions(𝑠, 𝑡) | 𝐾0 ) ≠ 𝑃 (transitions(𝑠, 𝑡) | 𝐾1 )
(2)
Two conditions must be satisfied: the signal must be tainted, meaning it is transitively influenced by 𝐾, and it must transition in a key-dependent way. A tainted signal that holds the same value across keys does not dissipate differential power, whereas an untainted transition carries no secret information. To detect signals that satisfy both conditions simultaneously, celllevel IFT pass adds per-signal taint shadows 𝑠𝑡 0 to track reachability from a designated secret input, along with a third signal layer, the leakage shadow 𝑠𝑙𝑒𝑎𝑘0 , defined as: 𝑠 leak0 [𝑖] [𝑡] = (𝑠 [𝑖] [𝑡] ⊕ 𝑠 [𝑖] [𝑡 − 1]) ∧ 𝑠𝑡 0 [𝑖] [𝑡]
(3)
The XOR term identifies a transition since the previous clock cycle, while the AND operation with the taint shadow enforces key dependency. The result is a per-bit wire that is high precisely when bit 𝑖 of signal 𝑠 both transitions and is tainted in the current cycle.
Compiled Binary
Verilator
2
Key Taint
Executable Leakage Tracking Simulator Taint Path Leakage Activity Data
3
TVLA-based Leakage Estimation
1 Instrumentation
Instrumentation
Compiler Toolchain
1
Annotated Design (Leakage Tracking)
SPARC: Macro Cell Information Flow Tracking for PSCL
SPARC combines dynamic IFT with quantitative power modeling, aiming to enable pre-silicon side-channel leakage detection and root-cause analysis directly from simulation. SPARC is structured in four distinct phases (illustrated in Fig. 2: (1) Instrumentation: Adapt a cell-level IFT pass to generate leakage indicators for each signal. (2) Quantification: Aggregate switching activity into scalar measurements representing leakage per cycle during simulation. (3) Evaluation: Analyze the collected data using statistical hypothesis testing and detailed attribution analysis to identify the cycles during which leakage occurs. (4) Root-cause analysis: Provide both hardware and software root-cause analysis.
Cryptographic Software
Hardware RootCause Analysis
2
Quantification 3
4 Software RootCause Analysis
Leakage Analysis
4
Root-Cause Attribution
Figure 2: SPARC: Automated Framework Overview
For combinatorial nodes, where transitions occur within rather than across clock cycles, a conservative model 𝑠 leak0 = 𝑠𝑡 0 is applied. Any input change observable at the output is considered as leakage propagation.
3.2
Macro Cell-Level Leakage Quantification
The instrumentation stage produces a leakage shadow for every tainted signal in the design. It generates logic to aggregate persignal leakage indicators into two scalar counters per simulation cycle, thereby modeling dynamic power consumption. The Hamming Weight (HW) counter measures how many tainted bits hold a logic-1 value in the current cycle, modeling charge-dependent power on tainted nodes. The Hamming Distance (HD) counter measures how many tainted bits transitioned since the previous cycle. For example, if five flip-flops of a tainted 32-bit register toggle in a cycle, the HD counter accumulates 5, while the HW counter reflects the register’s post-transition population count; summed over all tainted signals in scope, these counters form a cycle-accurate proxy for key-dependent dynamic power. The configurable aggregation scope allows counters to target a single module or to be instantiated across multiple sub-modules simultaneously, enabling comparison of leakage contributions from different pipeline stages, memory interfaces, or bus controllers within a single simulation run.
3.3
Overall Leakage Evaluation
The aggregation counters produce a single HW and HD value per simulation cycle per trace. To determine whether these values carry key-dependent information, we require a statistical test that can distinguish genuine leakage from random variation across multiple simulation runs. We deploy TVLA [14], which applies Welch’s t-test
SPARC: Automated Root-Cause Analysis of Pre-Silicon Power Side-Channel Leakage in the Processor Design Flow
ICCAD ’26, November 08–12, 2026, San Jose, CA, USA
on a per-cycle basis across two groups of traces that differ only in the secret key used.
filters for taint reachability, this ranking operates only over signals that are transitively influenced by the secret.
3.3.1 Trace Generation. For each evaluation, we generate 𝑁 matched pairs of simulation traces. Group 𝐴 executes under key 𝐾0 ; group 𝐵 executes under key 𝐾1 . Within each pair, the plaintext is randomly sampled but held identical across both groups, and masking randomness (if applicable) is similarly re-sampled per trace but matched between groups. This matched-pair design eliminates plaintextdependent artifacts and ensures that any statistical difference between groups is attributable exclusively to the key.
3.4.2 Instruction-level Attribution. Concurrently, a second analysis maps each leakage interval to the software instruction executing at that point. The program counter value is recorded at every simulation cycle, along with the leakage counters. For each cycle within a leakage interval, the corresponding program counter is resolved to a source-level function and line number. Consecutive leaky cycles are grouped into contiguous intervals of the t-statistic time series. Each interval is characterized by its peak |𝑡 | value, the dominant leaking signal, and the associated instruction. This process yields a direct mapping from each leakage peak to the executed software instruction. The signal-level and instruction-level results are combined to produce a complete diagnostic for each leakage interval: the hardware signal carrying the key-dependent information, the software instruction that triggered it, and the statistical strength of the leakage. This combined output delivers an automated root-cause analysis and provides actionable information for both hardware designers (which pipeline register, bus, or memory structure to protect) and software developers (which cryptographic operation or memory access pattern to restructure).
3.3.2 Per-Cycle Hypothesis Testing. For each simulation cycle 𝑡, the HW (or HD) counter values across all traces in each group form two distributions. We apply Welch’s t-test to these distributions: 𝑥¯0 [𝑡] − 𝑥¯1 [𝑡] 𝑡 [𝑡] = √︄ 𝑠 02 [𝑡] 𝑠 12 [𝑡] + 𝑁0 𝑁1
(4)
where 𝑥¯𝑖 [𝑡], 𝑠𝑖2 [𝑡], and 𝑁𝑖 denote the sample mean, variance, and trace count for group 𝑖 at cycle 𝑡. 3.3.3 Decision Criterion. A cycle is classified as leaking if |𝑡 | > 4.5, the threshold specified by the TVLA methodology [14]. The outcome is a t-statistic time series {𝑡 [𝑛]}𝑇𝑛=0 that provides both a binary pass/fail verdict and temporal localization of leakage occurrences within the execution. Cycles exceeding the threshold are grouped into contiguous leakage intervals, each characterized by its peak |𝑡 | value and the corresponding simulation cycle. These intervals serve as entry points for the root-cause analysis stage, which identifies the specific signals and instructions responsible for the detected leakage.
3.4
4
Implementation & Evaluation
This section details the experimental environment established to evaluate the proposed leakage analysis methodology. To promote reproducibility, the entire implementation pipeline is outlined. Comprehensive descriptions of SPARC’s toolchain for automated hardware instrumentation are included, together with specifications of the three RISC-V processor targets and definitions of the execution parameters for the cryptographic workloads. RQ1 through RQ3, defined in Section 1, are addressed in Section 4.2.
Root-Cause Analysis
The TVLA evaluation identifies when leakage occurs but not what causes it. A t-statistic exceeding the threshold at a given cycle indicates that the aggregate taint-filtered switching activity is keydependent, but does not reveal which specific signals carry the leaking information or which software instructions are executing at that moment. The root-cause analysis stage addresses this by attributing each detected leakage interval to specific hardware signals and software locations through two complementary analyses. 3.4.1 Signal-Level Attribution. For each leakage interval identified by the TVLA stage, we perform a targeted comparison of simulation waveforms between the two key groups. Rather than examining the aggregate counters, this step inspects individual leakage shadow wires to determine which signals exhibit the largest key-dependent divergence. For each signal 𝑠 within a leakage window 𝑊 , we compute the cumulative key-dependent Hamming weight difference: ∑︁ Δ𝑠 = HW 𝑠𝐾0 [𝑡] ⊕ 𝑠𝐾1 [𝑡] (5) 𝑡 ∈𝑊
where 𝑠𝐾0 [𝑡] and 𝑠𝐾1 [𝑡] denote the value of signal 𝑠 at cycle 𝑡 under keys 𝐾0 and 𝐾1 respectively. Signals are ranked by Δ𝑠 , with the highest-ranked signal identified as the dominant leakage carrier for that interval. Because the leakage shadow instrumentation already
4.1
Experimental Setup
In the following, we describe the practical implementation of the previously outlined methodology, including details on the toolchain and implementation, an introduction to the three RISC-V processors selected for evaluation, and an outline of the cryptographic workload and scenario generation strategy. 4.1.1 Toolchain and Implementation. SPARC implements dedicated leakage-estimation logic based on HW and HD models, along with macro-cell IFT, to enable automated leakage tracking and quantification. The instrumentation operates as a synthesis pass within the open-source Yosys [28] synthesis suite. Given a processor and its configuration, the pass processes an RTL design in a bottom-up topological order, instrumenting each module with taint shadows, leakage shadows, and aggregation counters as specified in the Section 3.2. The workflow extends the CellIFT methodology [24] to include leakage instrumentation for sequential cells, combinatorial cell handling, and counter insertion. Following instrumentation, the design is compiled into a cycleaccurate simulation using Verilator [23]. The HW and HD counters inserted by the Yosys pass are exposed as standard output ports in the simulation model, allowing sampling at every clock edge with minimal runtime overhead. This process produces a lightweight
ICCAD ’26, November 08–12, 2026, San Jose, CA, USA
Nešković et al.
Welch |t| (stochastic)
Ibex
|t| > 4.5
unmasked AES128
45
Threshold |t| = 4.5
Ibex
135
max |t| = 54
masked AES128 max |t| = 120
|t| 4.5
4.5
0
0
Rocket
405 135 45
unmasked AES128
Rocket max |t| = 397
|t|
|t|
|t|
45
4.5
Proteus
unmasked AES128
405 135 45
max |t| = 607
|t|
|t|
max |t| = 748
4.5 0
0
Proteus
405 135 45
masked AES128 max |t| = 493
4.5
4.5 0
masked AES128
405 135 45
0
5000
10000
15000
Simulation cycle
20000
25000
0
0
5000
10000
15000
Simulation cycle
20000
25000
Figure 3: TVLA results for all processors running AES128 activity trace CSV file that records signal switching on leaky paths. For root-cause attribution, Verilator is configured to generate a single waveform in FST or VCD format for the entire workload. Although this waveform is comparatively large, only one simulation run is necessary to map the signals from the lightweight CSV trace and deduce the corresponding software instructions. Welch’s t-test is computed per cycle across trace groups, and leakage intervals are identified by episode detection on the resulting t-statistic series. Instruction-level attribution maps program counter values recorded during simulation to source-level locations using the standard addr2line utility from the RISC-V GNU toolchain. The entire pipeline operates as a reproducible workflow, requiring no manual intervention beyond the initial configuration of the target processor and workload. 4.1.2 Processors Under Evaluation . The methodology is evaluated on three RISC-V processors spanning a wide range of microarchitectural complexity, from a minimal embedded core to a full Linux-capable system. This selection enables assessment of the approach’s generalizability across fundamentally different pipeline structures, memory hierarchies, and instruction-level parallelism strategies. (i) Ibex is a 2-stage in-order processor implementing the RV32IMC instruction set [19]. Its minimal pipeline makes it representative of embedded cores, commonly used in security-critical applications, such as hardware roots of trust. (ii) Proteus is a design-time configurable RISC-V processor implemented in SpinalHDL, supporting the RV32IM instruction set [8]. It can be configured as either a classic five-stage in-order pipeline
or a superscalar out-of-order processor with a configurable number of reorder-buffer entries and execution units. For this evaluation, Proteus is configured in out-of-order superscalar mode with eight arithmetic logic units (ALUs). This configuration of Proteus represents the high-performance end of the design spectrum. (iii) Rocket is a 5-stage in-order scalar processor implementing the RV64G instruction set, generated using the Chipyard SoC framework [4, 6]. Rocket has branch prediction logic and a multi-level memory hierarchy, which introduces significantly more microarchitectural state and longer data propagation paths. All processors are analyzed using bare-metal software binaries to ensure traceability and deterministic execution throughout the evaluation. 4.1.3 Cryptographic Software Algorithms Under Evaluation. Three software workloads are evaluated, each compiled to target the supported processor’s ISA and executed in bare-metal mode. For Ibex, a 32-bit march=rv32imc -mabi=ilp32 configuration is used, while for Proteus, a march=rv32im -mabi=ilp32 configuration is applied; both utilize the -O2 compiler flag. For Rocket (RV64G), the algorithms are compiled for the 64-bit datapath using the -march=rv64g -mabi=lp64 configuration and the -O2 compiler flag. All software is compiled with the RISC-V GNU toolchain version 12.2.0. (i) AES-128 (Unmasked) implementation follows a standard byteoriented AES-128 [11] structure, comprising AddRoundKey, SubBytes (table-based S-box lookup), ShiftRows, and MixColumns operations executed over ten rounds, with a key schedule that expands a 128-bit secret key into eleven round keys. No countermeasures are applied.
SPARC: Automated Root-Cause Analysis of Pre-Silicon Power Side-Channel Leakage in the Processor Design Flow
4.1.4 Trace counts and simulation lengths. TVLA is applied per simulation cycle using Welch’s t-test on matched-pair traces, where plaintext, ciphertext, and masking randomness are held constant across pairs and only the key differs, making the test sensitive exclusively to key-dependent leakage. For AES-128, 20 traces per group are used for the unmasked variant; this is increased to 100 traces per group for the masked variant to compensate for the reduced signal-to-noise ratio under masking. For Kyber-512, 20 traces per group are collected. The AES and Kyber workloads differ substantially in computational demand. AES encryption completes in tens of thousands of cycles, whereas Kyber decapsulation requires millions of cycles. To enable a fair runtime comparison in SPARC, all AES simulations are executed for 30,000 cycles and all Kyber simulations for 2,000,000 cycles, irrespective of the processor. Raw cycle counts do not directly reflect real-world performance. Proteus and Rocket feature multi-level cache hierarchies, while Ibex is connected directly to an SRAM model as main memory. This configuration does not represent realistic memory access behavior. However, since absolute performance is not the focus of these experiments, this distinction does not affect the validity of the results.
4.2
Evaluation
The evaluation addresses three research questions: the simulation cycles at which leakage occurs (RQ1), the signals contributing to leakage (RQ2), and the responsible software instructions (RQ3). Each question is examined across all three processors and both cryptographic workloads described in the experimental setup. For AES-128, both unmasked and first-order Boolean-masked variants
Proteus 405
Welch |t| |t| > 4.5
135
|t|
(ii) AES-128 (Masked) implementation applies a first-order Boolean masking scheme to the AES-128 algorithm [11]. Each secret-derived intermediate value is split into two shares 𝑣 = 𝑣 data ⊕ 𝑣 mask , where 𝑣 mask is drawn from a fresh random source at the start of each encryption to prevent mask reuse across invocations. The S-box is replaced with a masked variant that operates directly on shares, and MixColumns is computed over the masked representation, with mask propagation maintained through all linear operations (ShiftRows, AddRoundKey). This countermeasure is theoretically sound at first order. Consequently, any leakage detected by the methodology indicates either an implementation flaw or a microarchitectural interaction that violates masking assumptions. (iii) ML-KEM CRYSTALS-Kyber-512 (Unmasked) is a decapsulation operation under the Kyber-512 parameter set, derived from CRYSTALS-Kyber, a quantum-resistant key encapsulation mechanism standardized by NIST [3]. Only the unmasked variant is evaluated, providing a baseline for future masked Kyber studies. Kyber’s polynomial arithmetic results in a structurally distinct leakage profile compared to AES: secrets appear in Number Theoretic Transform (NTT) coefficient arrays, with dominant operations such as integer multiplication, XOR, and shift replacing AES’s byte-oriented S-box. Evaluation of both AES and Kyber demonstrates the methodology’s applicability across modern and post-quantum cryptographic algorithms. Assessment of both masked and unmasked AES further characterizes hardware implementation issues and the impact of CPU microarchitecture.
ICCAD ’26, November 08–12, 2026, San Jose, CA, USA
Masked AES-128 · TVLA |t|-statistic and signal attribution Threshold = 4.5 Attribution region
45 4.5 0
2500
2600
2700
2800
Simulation cycle
2900
3000
55
toplevel_soc_ibusAxi_decoder_io_input_r_rData_data_leak0
31 31 31 31
entries_7_pc_t0 entries_7_target_t0 Scheduler_rob_ssbPredictorEntries_2_t0 Scheduler_rob_ssbPredictorEntries_3_t0
0
10
20
30
3100
ROB / Scheduler Br. Target Predictor AXI bus 40
50
max | HW| in attribution region (cycles 2751 2810)
60
Figure 4: Signal Attribution for Proteus running masked AES128 are analyzed, enabling the methodology to characterize not only the presence of leakage but also the influence of masking on its onset and statistical strength. Kyber-512 is evaluated only in its unmasked form, offering a structurally distinct workload to assess generalization beyond block-cipher cryptography. Leakage is assessed per simulation cycle using TVLA with both HW and HD counters, applying a detection threshold of |𝑡 | > 4.5. 4.2.1 RQ1 - Leakage Detection: At Which Cycles Does the Design Leak? The first research question examines whether the taintfiltered TVLA methodology reliably detects key-dependent leakage and localizes it to specific simulation cycles. All nine processor–algorithm combinations exceed the Welch’s t-test threshold at clock-cycle granularity, confirming that the instrumentation produces statistically significant leakage signals across all evaluated configurations. Figure 3 presents the per-cycle t-statistic time series for all processors executing AES, with the t-statistic threshold |𝑡 | > 4.5 indicated as a dashed line. Cycles exceeding this threshold are classified as leaky and are highlighted in the figure. The t-statistic trace reveals distinct leakage intervals corresponding to specific phases of the cryptographic computation. Leaky intervals are further investigated by signal and instruction attribution. 4.2.2 RQ2 - Signal Attribution: Which Signals Contribute to the Leakage? While RQ1 identifies when leakage occurs, it does not indicate which signals contribute to the key-dependent switching. RQ2 addresses this by ranking individual leakage shadow signals within each detected leakage interval. As an example, we show Figure 4, which displays the dominant attributed signals for Proteus running masked AES during the peak leakage interval identified in RQ1. For instance, we can observe that secret-dependent activity is exposed through the AXI bus signals, the reorder buffer, and the branch target predictor. This confirms the lack of a proper keyloading mechanism and indicates potential leakage due to microarchitectural artifacts in Proteus when running a software-masked AES-128. 4.2.3 RQ3 - Instruction Attribution: Which Instructions Cause the Leakage? RQ3 completes the root-cause analysis by linking the
ICCAD ’26, November 08–12, 2026, San Jose, CA, USA
Proteus bne
a5,s9,8000040c
sb
a4,0(a2)
(:70)
sb
a4,-1(a5)
(:62)
bne
a5,s5,800003bc
Nešković et al.
Masked AES-128 · instruction attribution (cycles 2751 2810)
(:139)
add_round_key xor memcpy
(:61)
0
1
Attributed leaking cycles
Figure 5: Instruction Attribution for Proteus running masked AES128 Table 1: Per-trace simulation time and total evaluation time across processors and workloads Core
Workload
Cycles
Instrumentation
Single CSV Trace
Total Time
Ibex Rocket Proteus Ibex Rocket Proteus
AES∗ AES∗ AES∗ Kyber-512 Kyber-512 Kyber-512
30k 30k 30k 2M 2M 2M
9s 3m 12s 8m 40s 9s 3m 12s 8m 40s
0.9s 17.1s 18.2s 1m 6s 18m 49s 22m 14s
1m 25s 13m 45s 24m 34s 13m 34s 4h 14m 10h 4m
For Ibex, approximately 31% of all design signals are located on a tainted path, and only about 16% both reside on a leaky path and switch during execution. In contrast, approaches that do not use IFT must process the switching activity of every signal. The runtime scales well with larger processors and enables practical evaluation of workloads that span millions of cycles, such as Kyber. The total evaluation time encompasses several steps: building all simulation targets, including the VCD/FST dump simulator required for the root-cause analysis; Running all the defined test-patterns with the CSV trace simulator; Running a single simulation with the complete VCD/FST dump; Performing TVLA based on the obtained traces and attributing the hardware signals and software instructions in leaky intervals based on the complete VCD/FST simulation dump. The full evaluation and root-cause analysis of AES (both masked and unmasked) take less than 25 minutes on the most complex processor, while Kyber can be evaluated in just over 10 hours. Similar to other dynamic analyses, paths that are not activated by the selected inputs and keys remain unassessed. Additionally, effects occurring below the macro-cell abstraction, such as glitches resulting from technology mapping, are intentionally excluded from the model.
∗ Total time includes both masked and unmasked evaluation.
5 hardware leakage identified in RQ2 to the corresponding software instructions. In this step, SPARC identifies the dominant software instructions in the attribution region. Furthermore, the assembler instructions are mapped to the source core functions for a complete root-cause analysis. Figure 5 presents the instruction-level attribution for Proteus running masked AES. Here, we can observe which exact load/store and branching instructions correspond to the attributed leaky hardware signals. During this interval, SPARC attributes multiple leaky signals to the four instructions shown in Fig. 5. Because a single instruction may excite several signals and out-of-order interleaving precludes a strict one-to-one correspondence, the complete active set is reported. Lastly, SPARC maps assembler instructions to functions in the original source code, such as add_round_key, xor, and memcpy.
4.3
Framework Performance and Scalability
A key practical concern for any pre-silicon assessment methodology is whether it scales to realistic design sizes without huge runtime costs. We evaluate this by reporting instrumentation overhead, simulation time, and trace storage requirements across all three processors in Table 1. All experiments are performed using an AMD Ryzen 7 7800X3D CPU with 64GB of DDR5 RAM. The instrumentation overhead covers the cost of performing the Yosys pass and building the executable Verilator simulations with compact CSV tracing. Inserting the HW/HD counters enlarges the instrumented design by ∼11-12% over pure cell-level IFT; counters and shadow logic exist only in the evaluation model. Even for more complex processors like Rocket and Proteus, the overhead remains reasonable, requiring less than 4 and 9 minutes, respectively. The compact CSV trace simulator, which produces quantified leakage traces, is very fast, achieving an 8x speedup in per-trace simulation time on Ibex AES relative to Telescopes’ [18] reported simulation cost for a comparable design. This scalability is a direct result of taint filtering.
Conclusion
This work presents SPARC, an automated framework for pre-silicon PSCL evaluation and root cause analysis in the processor design flow. By testing three diverse RISC-V processors: Ibex (2-stage inorder, 32-bit), Proteus (out-of-order superscalar, 32-bit), and Rocket (5-stage in-order, 64-bit) and evaluating two distinct cryptographic algorithms (AES-128 and CRYSTALS-Kyber-512), including a firstorder Boolean-masked AES-128 implementation, we demonstrate the efficacy and scalability of SPARC. Our experiments confirm the well-known power side-channel leakage points in unmasked implementations and, critically, detect micro-architectural leakage artifacts in Proteus’s out-of-order pipeline that violate the masking assumptions and expose key-dependent information despite firstorder protection. Furthermore, SPARC goes beyond mere detection: it pinpoints the exact root cause, identifying the specific hardware signals, micro-architectural artifacts, and executing software functions responsible for the leak. Our trace generation outperforms previously reported solutions by a factor of 8. With a total evaluation runtime of less than 25 minutes for AES-128 and around 10 hours for Kyber-512 for Proteus, SPARC delivers an effective and scalable framework for pre-silicon PSCL evaluation and root cause analysis. Guided by the root-cause output, designers can revise the RTL, such as by implementing a dedicated key-loading path or clearing secret-holding states, and then immediately re-evaluate the design. Alternatively, the ranked signals may be flagged as hardware-masking candidates for subsequent design stages. Future work includes gate-level cross-validation of attribution accuracy, implementation of masked ML-KEM, and exploration of multi-core SoCs.
Acknowledgments This work was partially funded by the German Federal Ministry of Research, Technology, and Space (BMFTR) through the project DI-OSVISE (16ME0958).
SPARC: Automated Root-Cause Analysis of Pre-Silicon Power Side-Channel Leakage in the Processor Design Flow
References [1] Asmita Adhikary, Abraham Basurto-Becerra, Lejla Batina, Ileana Buhan, and Durba Chatterjee. 2026. Root-Cause Analysis of Power Side-Channel Leaks in RISC-V Cryptographic Implementations. Cryptology ePrint Archive (2026). [2] Asmita Adhikary, Abraham Basurto-Becerra, Lejla Batina, Ileana Buhan, Durba Chatterjee, Senna van Hoek, and Eloi Sanfelix Gonzalez. 2025. Archer: Architecture-level simulator for side-channel analysis in risc-v processors. In International Workshop on Lightweight Cryptography for Security and Privacy. Springer, 157–177. [3] Gorjan Alagic, Quynh Dang, Dustin Moody, Angela Robinson, Hamilton Silberg, and Daniel Smith-Tone. 2024. Module-Lattice-Based Key-Encapsulation Mechanism Standard. Federal Information Processing Standards Publication FIPS 203. National Institute of Standards and Technology. Effective August 14, 2024. doi:10.6028/NIST.FIPS.203 [4] Alon Amid, David Biancolin, Abraham Gonzalez, Daniel Grubb, Sagar Karandikar, Harrison Liew, Albert Magyar, Howard Mao, Albert Ou, Nathan Pemberton, et al. 2020. Chipyard: Integrated design, simulation, and implementation framework for custom socs. Ieee Micro 40, 4 (2020), 10–21. [5] Armaiti Ardeshiricham, Wei Hu, Joshua Marxen, and Ryan Kastner. 2017. Register transfer level information flow tracking for provably secure hardware design. In Design, Automation & Test in Europe Conference & Exhibition (DATE), 2017. IEEE, 1691–1696. [6] Krste Asanovic, Rimas Avizienis, Jonathan Bachrach, Scott Beamer, David Biancolin, Christopher Celio, Henry Cook, Daniel Dabbelt, John Hauser, Adam Izraelevitz, et al. 2016. The rocket chip generator. EECS Department, University of California, Berkeley, Tech. Rep. UCB/EECS-2016-17 4 (2016), 6–2. [7] Roderick Bloem, Barbara Gigerl, Marc Gourjon, Vedad Hadzic, Stefan Mangard, and Robert Primas. 2022. Power contracts: Provably complete power leakage models for processors. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. 381–395. [8] Marton Bognar, Job Noorman, and Frank Piessens. 2023. Proteus: an extensible risc-v core for hardware extensions. In RISC-V Summit Europe, Date: 2023/06/052023/06/09, Location: Barcelona, Spain. [9] Eric Brier, Christophe Clavier, and Francis Olivier. 2004. Correlation power analysis with a leakage model. In International workshop on cryptographic hardware and embedded systems. Springer, 16–29. [10] Eden Desmet, Suparna Kundu, and Ingrid Verbauwhede. 2026. Masking Out of Order: Side-Channel Leaks from Software-Masked Cryptography on Out-ofOrder Processors. Cryptology ePrint Archive (2026). [11] Morris Dworkin, Elaine Barker, James Nechvatal, James Foti, Lawrence Bassham, Edward Roback, and James Dray. 2001. Advanced Encryption Standard (AES). Federal Information Processing Standards Publication FIPS 197. National Institute of Standards and Technology. doi:10.6028/NIST.FIPS.197 [12] Barbara Gigerl, Vedad Hadzic, Robert Primas, Stefan Mangard, and Roderick Bloem. 2021. Coco: { Co-Design } and { Co-Verification } of masked software implementations on { CPUs } . In 30th USENIX security symposium (USENIX security 21). 1469–1468. [13] Barbara Gigerl, Robert Primas, and Stefan Mangard. 2021. Secure and efficient software masking on superscalar pipelined processors. In International Conference on the Theory and Application of Cryptology and Information Security. Springer, 3–32. [14] Benjamin Jun Gilbert Goodwill, Josh Jaffe, Pankaj Rohatgi, et al. 2011. A testing methodology for side-channel resistance validation. In NIST non-invasive attack testing workshop, Vol. 7. 115–136. [15] Miao He, Jungmin Park, Adib Nahiyan, Apostol Vassilev, Yier Jin, and Mark Tehranipoor. 2019. RTL-PSC: Automated power side-channel leakage assessment at register-transfer level. In 2019 IEEE 37th VLSI Test Symposium (VTS). IEEE, 1–6. [16] Wei Hu, Armaiti Ardeshiricham, and Ryan Kastner. 2021. Hardware information flow tracking. ACM Computing Surveys (CSUR) 54, 4 (2021), 1–39. [17] Paul Kocher, Joshua Jaffe, and Benjamin Jun. 1999. Differential power analysis. In Annual international cryptology conference. Springer, 388–397. [18] Zhenyuan Liu, Andrew Malnicof, Arna Roy, and Patrick Schaumont. 2025. Telescope: Top-Down Hierarchical Pre-silicon Side-channel Leakage Assessment in System-on-Chip Design. In Proceedings of the 20th ACM Asia Conference on Computer and Communications Security. 1280–1293. [19] lowRISC contributors. 2024. Ibex: A Small 32-bit RISC-V CPU Core. https: //github.com/lowRISC/ibex. [20] Adib Nahiyan, Jungmin Park, Miao He, Yousef Iskander, Farimah Farahmandi, Domenic Forte, and Mark Tehranipoor. 2020. Script: A cad framework for power side-channel vulnerability assessment using information flow tracking and pattern generation. ACM Transactions on Design Automation of Electronic Systems (TODAES) 25, 3 (2020), 1–27. [21] Andrija Nešković, Ahmad Kabour, Mohamed Eltantawi, Mladen Berekovic, Rolf Meyer, and Saleh Mulhem. 2025. SCA-WAL: An Open-Source Framework for Power Side Channel Assessment at RTL and Netlist Level. IEEE Embedded Systems Letters (2025).
ICCAD ’26, November 08–12, 2026, San Jose, CA, USA
[22] Jan M.. Rabaey, Anantha P Chandrakasan, and Borivoje Nikolić. 2003. Digital integrated circuits: a design perspective. Pearson Education, Incorporated. [23] Wilson Snyder and contributors. 2024. Verilator: Open-Source SystemVerilog Simulator and Lint System. https://www.veripool.org/verilator/. Accessed: April 2026. [24] Flavien Solt, Ben Gras, and Kaveh Razavi. 2022. { CellIFT } : Leveraging cells for scalable and precise dynamic information flow tracking in { RTL } . In 31st USENIX Security Symposium (USENIX Security 22). 2549–2566. [25] François-Xavier Standaert. 2010. Introduction to side-channel attacks. Secure integrated circuits and systems (2010), 27–42. [26] Mohit Tiwari, Hassan MG Wassel, Bita Mazloom, Shashidhar Mysore, Frederic T Chong, and Timothy Sherwood. 2009. Complete information flow tracking from the gates up. In Proceedings of the 14th international conference on Architectural support for programming languages and operating systems. 109–120. [27] Xingxin Wang, Huisi Zhou, Jiacheng Zhu, Weihao Fan, and Wei Hu. 2025. PreSilicon Power Side-Channel Leakage Assessment Through Quantitative Information Flow Analysis. In 2025 International Symposium of Electronics Design Automation (ISEDA). IEEE, 305–310. [28] Clifford Wolf, Johann Glaser, and Johannes Kepler. 2013. Yosys-a free verilog synthesis suite. In Proceedings of the 21st Austrian Workshop on Microelectronics (Austrochip), Vol. 97. 1–6. [29] Yuan Yao, Tarun Kathuria, Baris Ege, and Patrick Schaumont. 2020. Architecture correlation analysis (ACA): Identifying the source of side-channel leakage at gate-level. In 2020 IEEE International Symposium on Hardware Oriented Security and Trust (HOST). IEEE, 188–196. [30] Tao Zhang, Jungmin Park, Mark M Tehranipoor, and Farimah Farahmandi. 2021. PSC-TG: RTL Power Side-Channel Leakage Assessment with Test Pattern Generation.. In DAC. 709–714.