💻 computer science

Controller Datapath Aware Verification of Masked Hardware Generated via High Level Synthesis

This paper presents MaskedHLSVerif, a state-wise formal verification toolflow designed to accurately validate the power side-channel security of masked hardware generated by High-Level Synthesis, effectively eliminating false positives caused by resource-shared controller datapath architectures that plague existing verification tools.

Original authors: Nilotpola Sarma, Vaishali Ghanshyam Chaudhuri, Chandan Karfa

Published 2026-03-20

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Nilotpola Sarma, Vaishali Ghanshyam Chaudhuri, Chandan Karfa

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

The Big Picture: Building a Secret Vault

Imagine you are building a high-security vault to store a secret recipe (the cryptographic algorithm). You want to make sure no one can steal the recipe by watching how much electricity the vault uses while it's working. This is called a Power Side-Channel Attack.

To stop this, you use a technique called Masking.

The Analogy: Instead of keeping the whole recipe in one place, you chop it into three random pieces (shares). You give one piece to Person A, one to Person B, and one to Person C.
The Rule: As long as no one sees more than one piece at a time, the secret remains safe. Even if a spy watches Person A's hands, they only see a random piece of paper, not the recipe.

The Problem: The "Fast-Forward" Builder

Traditionally, building these masked vaults is done by hand by expert engineers. It's slow, tedious, and easy to make a mistake.

To speed things up, engineers started using High-Level Synthesis (HLS).

The Analogy: Think of HLS as a super-fast, automated construction robot. You give it a blueprint (software code), and it instantly builds the physical vault (hardware) for you. It's great because it saves time and lets you try out different designs quickly.

But here's the catch: This robot was built to build fast and cheap, not secure.
To save space and time, the robot often reuses the same tools (like a single hammer) for different jobs at different times. It creates a design where the "secret pieces" are shuffled around on a conveyor belt that only moves in specific patterns.

The False Alarm: The Over-Paranoid Inspector

After the robot builds the vault, you need an inspector to check if the masking is still working.

The Old Inspector (Tools like REBECCA): This inspector is very thorough but a bit naive. They look at the blueprints and say, "Hey, this hammer could theoretically hit any piece of wood at any time."
The Mistake: Because the robot (HLS) reuses the hammer, the inspector checks every possible combination of hammer hits, even the ones that are physically impossible in the actual machine.
The Result: The inspector screams, "DANGER! The secret is leaking!" when, in reality, the machine is perfectly safe. These are called False Positives. It's like a smoke detector going off because you burned toast, not because the house is on fire.

The Solution: The "State-Aware" Detective

The authors of this paper created a new tool called MaskedHLSVerif.

The Analogy: Instead of a paranoid inspector who imagines every impossible scenario, this new tool is a smart detective who understands the machine's schedule.
How it works:
1. The detective knows the machine works in States (like steps in a dance routine).
2. In Step 1, the hammer only hits Piece A.
3. In Step 2, the hammer only hits Piece B.
4. The detective checks the security only for the specific pieces being hit in that specific step. They ignore the impossible combinations (like the hammer hitting Piece A and Piece B at the exact same time, which the machine physically cannot do).

Why This Matters

It Stops the False Alarms: By understanding the machine's schedule (the Finite State Machine), the tool stops crying wolf. It correctly verifies that the vault is secure, even though the robot reused tools to build it.
It Catches Real Bugs: The robot isn't perfect. Sometimes, in its rush to be efficient, it accidentally rearranges the secret pieces in a way that breaks the security (like re-associating math operations). The old tools missed these because they were too busy looking at impossible scenarios. The new tool, by looking at the actual steps, can spot these real mistakes.

Summary in a Nutshell

The Goal: Securely build crypto hardware automatically.
The Problem: Automated builders (HLS) reuse parts to save space, confusing old security checkers who think everything is possible, leading to false alarms.
The Fix: A new checker that understands the "schedule" of the machine. It only checks the parts that are actually active at any given moment.
The Outcome: We can now trust that hardware built by automated robots is actually secure, saving time and money while keeping secrets safe.

1. Problem Statement

Context:
Power Side-Channel Attacks (PSCAs) threaten cryptographic implementations. Masking is a standard countermeasure that splits secret data into random shares. While manual hardware masking is error-prone and time-consuming, High-Level Synthesis (HLS) tools offer a way to automatically generate masked Register-Transfer Level (RTL) hardware from verified masked software specifications.

The Core Issue:
Existing formal verification tools for masked hardware (e.g., REBECCA) are designed for fixed datapaths. However, HLS tools optimize designs by sharing resources (e.g., using a single multiplier for multiple operations across different clock cycles). This creates a Controller-Datapath architecture driven by a Finite State Machine (FSM) and multiplexers (MUXes).

The Limitation of Current Tools:

False Positives: Tools like REBECCA perform a "naive" combinational analysis. They assume all syntactically possible input combinations to a MUX are reachable.
Reality: In an HLS-generated design, the FSM controls MUX select lines, ensuring that only specific, valid input combinations occur in specific states. Many theoretically possible combinations (e.g., mixing shares from different time slots) are never executed.
Consequence: Existing tools check these unreachable combinations, detect "leakages" that do not exist in the actual hardware, and incorrectly report the design as insecure (False Positives). This prevents the adoption of HLS for secure hardware design.

2. Methodology: MaskedHLSVerif

The authors propose MaskedHLSVerif, a verification toolflow that performs state-wise formal verification to eliminate false positives caused by resource sharing.

Key Steps in the Flow:

HLS Generation: Generate the masked RTL design from a masked C/C++ specification using an HLS tool (e.g., Vitis HLS).
FSM Extraction: Extract the Finite State Machine (FSM) states from the generated RTL.
State-wise Splitting (Unrolling):
- Instead of verifying the entire design at once, the tool splits the design into smaller sub-designs ( $D_0, D_1, \dots, D_n$ ), one for each FSM state.
- Recursive Dependency: Crucially, each state-wise design $D_x$ includes not only the operations active in state $x$ but also all recursively dependent operations from previous states. This ensures that intermediate signals are correctly labeled based on the original inputs.
Label Propagation:
- Input signals are labeled as Shares, Masks, or Public values.
- These labels are propagated through the state-wise sub-designs. Because the sub-designs include the full dependency chain, the labels for intermediate signals are derived directly from the original inputs, avoiding the complexity of re-calculating labels for intermediate nodes.
Formal Verification:
- Each state-wise sub-design ( $D_x$ ) is fed into REBECCA (the underlying verification engine) along with its specific label file.
- REBECCA verifies the security of the active datapath for that specific state, ignoring unreachable MUX combinations.
Aggregation:
- If all state-wise designs pass verification, the original HLS-generated design is deemed secure.
- If a specific state fails, the tool identifies the exact state and location of the masking flaw.

Theoretical Soundness:
The authors prove that this approach is sound. Since every valid execution trace of the original design corresponds to a sequence of operations captured in at least one state-wise sub-design, verifying all sub-designs guarantees the security of the whole.

3. Key Contributions

Identification of Limitations: The paper formally identifies that State-of-the-Art (SOTA) tools fail on HLS-generated designs due to their inability to distinguish between reachable and unreachable datapath states in resource-shared architectures.
Impact Analysis: It discusses how specific HLS optimizations (e.g., Reassociation, Expression Balancing) can inadvertently break masking security by altering the order of operations or removing necessary re-masking steps.
Novel Toolflow (MaskedHLSVerif): The first framework to verify HLS-generated masked hardware by abstracting the active datapath per FSM state, thereby eliminating false positives.
Flaw Detection: The method is capable of detecting not only structural issues but also security flaws induced by HLS optimizations (e.g., reassociation errors).

4. Experimental Results

The authors evaluated the tool on six cryptographic benchmarks generated by Vitis HLS, including:

Cascaded masked multipliers using DOM, HPC1, HPC2, and COMAR masking schemes.
PRESENT S-box implementations masked with DOM and HPC1.

Experiment 1: Verification of Standard Benchmarks

Setup: Verified the six benchmarks using both REBECCA (directly) and MaskedHLSVerif.
Result:
- REBECCA: Reported False Positives for all six designs (incorrectly flagging them as insecure due to unreachable MUX combinations).
- MaskedHLSVerif: Correctly verified all designs as Secure.
- Validation: The authors confirmed the security of the RTL using TVLA (Test Vector Leakage Assessment) on gate-level simulations, proving the designs were indeed secure and the REBECCA results were false positives.

Experiment 2: Detecting Optimization-Induced Flaws

Setup: The authors intentionally enabled an HLS optimization (#pragma HLS EXPRESSION_BALANCE) on a cascaded DOM multiplier. This optimization caused a reassociation of masking operations, creating a genuine first-order masking flaw.
Result:
- MaskedHLSVerif correctly identified the design as Insecure in the second state.
- It pinpointed the specific leakage (unmasked secret values in the label set) caused by the reassociation, demonstrating its ability to catch HLS-induced security violations.

5. Significance

Enabling Automated Secure Design: This work bridges the gap between High-Level Synthesis and Side-Channel Security. It allows designers to use HLS for rapid prototyping and Design Space Exploration (DSE) of masked hardware without fear of false security reports.
Reliability: By removing false positives, the tool provides a trustworthy metric for security, which is critical for the deployment of cryptographic hardware.
Optimization Awareness: It highlights that HLS optimizations are not just performance tweaks but can fundamentally alter security properties, necessitating a verification strategy that is aware of the controller-datapath interaction.
Future Direction: This is the first work to address the verification of HLS-generated masked hardware, opening the door for further research into optimizing HLS tools specifically for security constraints.