- Structural Dependency Analysis (SDA) enables scalable pre-silicon side-channel verification of masked Number Theoretic Transform (NTT) hardware — the computational core of Kyber, Dilithium, and Falcon.
- Traditional statistical leakage tests require millions of post-silicon traces; SDA catches first-order masking flaws at RTL, weeks before tape-out.
- For CISOs deploying PQC hardware in HSMs, smartcards, or TLS accelerators, unverified masking is a procurement-grade risk — not a theoretical concern.
[IMAGE: Macro photograph of a post-quantum cryptographic accelerator die with visible NTT butterfly units, illuminated by probing laser beams against a black substrate]
The $2.4M Question Hiding in Your PQC Roadmap
You’ve budgeted for the migration. NIST finalized ML-KEM (FIPS 203) and ML-DSA (FIPS 204) in August 2024. Your vendors are shipping silicon. One question determines whether that silicon actually protects your keys: was the NTT unit verified against side-channel leakage before tape-out, or are you trusting post-fabrication statistical tests?
The distinction matters because ML-KEM and ML-DSA both depend on polynomial multiplication over Z_q, and every production implementation accelerates that multiplication using the NTT. An unmasked NTT leaks secret polynomial coefficients through power consumption, electromagnetic emanation, or timing. A poorly masked NTT leaks the same coefficients while giving your compliance team false confidence.
Researchers from the April 2026 paper Structural Dependency Analysis for Masked NTT Hardware document a category of masking bugs that evade traditional TVLA (Test Vector Leakage Assessment) until attackers with 10⁶+ traces exploit them in the field. For HSMs with 7–10 year deployment lifetimes, that’s an unacceptable window.
Why the NTT Is the Attack Surface
Defining the Primitive
The Number Theoretic Transform is a finite-field analog of the FFT. It converts polynomial multiplication in Z_q[X]/(X^n + 1) from O(n²) to O(n log n) using butterfly operations over a prime modulus q. In ML-KEM, q = 3329 and n = 256. Every encapsulation and decapsulation runs the NTT multiple times on secret vectors.
That concentration of secret-dependent arithmetic in a small, repeatedly-invoked hardware block makes the NTT the highest-value target on a PQC chip. A single leaking butterfly, repeated across 128 layers per operation, gives an attacker exponentially more leverage than a leak in a one-shot routine.
What Masking Must Accomplish
Masking splits each secret value s into d+1 random shares (s₀, s₁, …, s_d) such that s = s₀ ⊕ s₁ ⊕ … ⊕ s_d. A d-th order masked design should resist any adversary observing d or fewer intermediate values. The catch: arithmetic operations (addition, multiplication mod q) require gadgets that preserve this independence. A single combinational path that recombines shares — even transiently, even through a glitch — collapses the entire security argument.
The hard problem isn’t designing masking gadgets. It’s proving that 50,000 lines of synthesized Verilog don’t accidentally recombine shares through glitches, fan-out, or shared registers that a human reviewer can’t track.
Structural Dependency Analysis: The Technical Core
SDA treats the netlist as a directed graph where nodes are gates and edges are signals carrying either a share, a random mask, or a public value. The verifier propagates labels forward and flags any gate whose output depends on shares from multiple masking domains of the same secret.
SDA vs. Traditional Verification
| Approach | Input | Detection Latency | Scalability | False Negatives |
|---|---|---|---|---|
| TVLA (post-silicon) | Power traces, 10⁶–10⁸ samples | Weeks after tape-out | Limited by acquisition time | High for higher-order leaks |
| Formal SMT-based (e.g., maskVerif) | Gate-level netlist | Hours–days | Breaks above ~10k gates | Low |
| Simulation-based leakage | RTL + stimulus | Hours | Moderate | Depends on coverage |
| Structural Dependency Analysis | Synthesized netlist + mask annotations | Minutes–hours | Scales to full NTT (>50k gates) | Low for first-order; bounded for higher-order |
The critical engineering trade-off: SDA accepts some conservativeness (occasionally flagging secure constructions) in exchange for completing verification on NTT-scale designs where SMT solvers time out.
Glitch Modeling
First-generation masked hardware was broken by glitch attacks — transient signal values during clock transitions that briefly expose unmasked intermediates. SDA incorporates a glitch-extended adversary model: any input to a combinational cloud can transiently take the value of any other input in that cloud. This matches the threat model validated by real laboratory attacks on ASIC and FPGA targets.
A masking scheme proven secure under the probing model but not the glitch model is worth approximately zero in deployed hardware. Demand vendor attestation to the glitch-extended model specifically.
Regulatory and Procurement Implications
The NIST Timeline Compresses Everything
- FIPS 203/204/205: Finalized August 13, 2024
- CNSA 2.0 mandate: National-security systems must support PQC by 2027, exclusively PQC by 2033
- FIPS 140-3 updates: Draft guidance for PQC module validation expected through 2026
A hardware module claiming FIPS 140-3 Level 3 or 4 protection against side-channel attacks must demonstrate — not assert — that its PQC primitives meet the non-invasive attack requirements in ISO/IEC 17825. SDA-style verification evidence is increasingly what lab evaluators ask for during validation.
The Cost of Getting This Wrong
A post-deployment side-channel break on a PQC HSM triggers: certificate re-issuance, firmware recall where possible, hardware replacement where not, and a CVE that enterprise procurement teams will cite for the next decade. Vendors who invested in pre-silicon verification ship once. Vendors who didn’t ship twice — and the second shipment arrives after the breach disclosure.
The BeQuantum Perspective
Our IceCase hardware pipeline treats masked-NTT verification as a gating artifact, not a post-hoc checkbox. Before any PQC accelerator reaches fabrication, the synthesized netlist passes through structural dependency analysis against the glitch-extended probing model, and the resulting proof obligations are anchored on-chain via our Digital Notary service. The blockchain record pins the exact netlist hash, the verifier version, and the mask order claimed — so three years from now, when a regulator or customer asks “what did you verify, and when,” the answer is a cryptographic receipt, not a marketing deck.
The PQC Layer then enforces that only firmware signed against notarized hardware revisions executes in production. This chains pre-silicon verification evidence to runtime attestation, closing the gap where most vendors hand off responsibility between design and deployment teams.
What You Should Do Next
- Within 30 days: Request from every PQC hardware vendor their side-channel verification methodology, the specific adversary model (probing, glitch-extended, or transition-based), and the masking order claimed. Accept no answer that omits the adversary model.
- Within 90 days: Audit your HSM inventory for devices claiming PQC support without published side-channel evaluation. Flag these for replacement planning — they will not survive the next round of FIPS 140-3 revalidation.
- Before 2027: Require contractual warranty that PQC accelerators shipped to you were verified at the netlist level, not merely the algorithmic level. The two are not equivalent.
FAQ
Q: Is software-only PQC (e.g., liboqs) vulnerable to these same NTT side-channel issues? A: Yes, but the threat model differs. Software implementations face cache-timing and microarchitectural side channels rather than power analysis. Masked software NTT implementations exist but incur 3–8× performance overhead, which is why hardware acceleration with proper masking is the preferred long-term path.
Q: Can I retrofit masking onto an existing unmasked PQC accelerator through firmware? A: No. Masking is a hardware-level property that must be designed into the data path, randomness generation, and gadget composition. Firmware mitigations like blinding add noise but do not provide provable security against a determined lab-equipped attacker.
Q: How do I know if my vendor’s “side-channel resistant” claim is meaningful? A: Ask three questions. First, what adversary model — probing, glitch-extended, or transition-extended? Second, what verification tool produced the proof, and on what artifact (RTL, gate-level, or post-layout)? Third, what masking order, and does it hold end-to-end through the NTT or only within isolated gadgets? Vague answers to any of these indicate unverified claims.
Last updated: 2026-04-18
