When you implement cryptographic operations in payment systems, you might assume masking protects your secret keys from side-channel attacks. However, a recent power analysis attack on Falcon's masked preimage computation challenges that assumption. The attack achieved a 98.3% success rate with 4,000 traces by exploiting leakage during share recombination, even with masking in place.
This checklist helps you evaluate whether your cryptographic implementations are vulnerable to similar attacks and guides you through practical countermeasures that don't require computationally prohibitive full masking.
Prerequisites
Before using this checklist, confirm:
- You operate cryptographic functions in hardware that processes cardholder data or cryptographic keys (HSMs, payment terminals, secure elements).
- Your implementation uses masking as a side-channel defense.
- You have access to your cryptographic library's source code or detailed implementation documentation.
- You can test or simulate power consumption patterns in your target architecture.
Cryptographic Side-Channel Defense Checklist
1. Map Every Point Where Masked Shares Recombine
Action: Document each location in your code where masked shares of secret values combine back into unmasked form.
Why it matters: The Falcon attack succeeded specifically during share recombination. Attackers exploit the moment when your system temporarily exposes unmasked values.
What good looks like: You have a complete list of recombination points with file names, line numbers, and the specific values being unmasked. Each entry notes whether that recombination happens inside or outside your secure boundary.
2. Identify Input-Dependent Computation Paths
Action: Trace whether attacker-controlled inputs (message content, transaction data, nonces) can influence which code paths execute during cryptographic operations.
Why it matters: Chosen-message attacks work by forcing your system into states where coefficient ratios or intermediate values create exploitable power patterns. Masking alone won't protect you if an attacker can submit crafted transaction data that steers your code toward vulnerable states.
What good looks like: You can answer: "Can an external party control any input that affects branching, loop counts, or memory access patterns during key operations?" If yes, those paths are documented with mitigation plans.
3. Assess Your Architecture's Leakage Profile
Action: Determine whether your target hardware (ARM Cortex-M series, other embedded processors) has known power leakage characteristics during arithmetic operations.
Why it matters: The attack used ELMO leakage simulation for ARM Cortex-M0 architecture. Different processors leak different amounts of information through power consumption. Your threat model depends on your hardware.
What good looks like: You have test results or simulation data showing power consumption variance during cryptographic operations on your actual hardware, not just theoretical analysis.
4. Implement Rejection Sampling for Vulnerable Operations
Action: Add rejection sampling to operations where attackers could force extreme intermediate values (very large or very small coefficients, skewed ratios between components).
Why it matters: A fully masked implementation of Falcon prevents the attack but is computationally prohibitive. Rejection sampling offers a middle ground: reject inputs that would create exploitable conditions without the overhead of masking every operation.
What good looks like: Your implementation checks input characteristics before processing and rejects values outside acceptable bounds. You've documented the rejection criteria and tested that legitimate transactions don't trigger false rejections at rates above 0.1%.
5. Validate That Masking Extends Through All Dependent Operations
Action: Verify that operations using masked values maintain masking through the entire computation chain, not just the initial operation.
Why it matters: Partial masking creates false confidence. If you mask the Gaussian sampler but not the operations that consume its output, you've protected the wrong layer.
What good looks like: Your security review confirms that every operation touching secret material maintains constant-time execution and consistent power consumption, or you've explicitly accepted the risk for specific operations with documented justification.
6. Test With Trace Collection Under Realistic Conditions
Action: Collect power traces from your actual hardware running real transaction workloads, not just isolated test cases.
Why it matters: Lab conditions differ from production. Noise, concurrent processes, and varying workloads all affect whether attacks succeed in practice.
What good looks like: You've collected at least 5,000 traces under production-like conditions and verified that correlation analysis doesn't reveal secret-dependent patterns. Document the collection methodology so auditors can reproduce your tests.
7. Establish a Side-Channel Vulnerability Response Plan
Action: Define who gets notified when new side-channel attacks are published, how you assess applicability to your systems, and what your patching timeline looks like.
Why it matters: Side-channel research moves quickly. The gap between academic publication and weaponized exploits is shrinking.
What good looks like: You have a documented process that includes: monitoring sources (ePrint, academic conferences), initial triage within 48 hours, impact assessment within one week, and mitigation deployment timelines based on exploitability.
Common Mistakes
Assuming masking is binary: Teams treat masking as "on" or "off" without examining where and how it's applied. Masking the wrong operation wastes resources while leaving vulnerabilities open.
Ignoring architecture-specific leakage: Generic side-channel defenses don't account for how your specific processor leaks information. ARM Cortex-M0 has different characteristics than M4 or Intel architectures.
Skipping chosen-input analysis: You test with random inputs but never consider whether an attacker could craft inputs that maximize leakage. Payment systems often let external parties control message content, nonces, or transaction metadata.
Over-relying on physical security: You assume attackers can't get close enough to measure power consumption. Payment terminals, ATMs, and point-of-sale devices are physically accessible to attackers who can install measurement equipment.
Next Steps
If you found gaps in items 1-3, prioritize mapping your recombination points and input-dependent paths before implementing new defenses. You can't protect what you haven't identified.
If you passed items 1-3 but failed 4-6, focus on rejection sampling and trace collection. These are your practical, deployable countermeasures that don't require architectural changes.
For payment HSMs and secure elements processing cardholder data, schedule annual side-channel assessments with specialists who have power analysis equipment. Self-assessment catches obvious problems; expert review catches subtle ones.
Finally, if your cryptographic library comes from a third-party vendor, ask them directly about their side-channel testing methodology and whether they've evaluated share recombination leakage. Their answer tells you whether to trust their implementation or plan your own validation.
