Side-channel attacks have become cheaper and faster. A new attack framework recovered cryptographic secrets from an ARM Cortex-M4 device in just 15 minutes with a single power trace. This isn't a theoretical issue anymore.
You're likely already protecting keys at rest by encrypting them, controlling access, and rotating them regularly. But what about when those keys are in memory, actively signing transactions or decrypting cardholder data? That's when side-channel attacks are effective. They don't break the cryptography itself; they exploit power consumption, electromagnetic emissions, or timing variations during cryptographic operations.
The question is: Should you invest in runtime protections that add latency and complexity, or accept that physical access to your hardware security modules and payment terminals poses inherent risks?
The Case for Protecting Keys in Use
Your threat model includes physical access. Payment terminals are in retail environments, ATMs are in public spaces, and even your data center has contractors and cleaning crews who know the layout.
GRWP-SASCA (Greedy Region-Wise Pruning Soft Analytical Side-Channel Attacks) shows how an attacker with physical access can extract secrets from unprotected implementations. This framework reduces memory requirements for side-channel analysis by up to 151 times and speeds up attacks by 68 times compared to previous methods. Real-device experiments demonstrate secret recovery within 15 minutes using a single power trace from an unprotected ML-DSA implementation on ARM Cortex-M4.
Here's what runtime protection looks like:
Masking splits sensitive variables into random shares during computation. Instead of processing a key directly, the device operates on multiple masked values that reveal nothing individually. First-order masking forces attackers to capture and correlate multiple traces. Research shows that even with masking, secrets can be recovered within 3.2 hours using 8 traces, with peak memory usage of about 8.1 GB. This raises the bar significantly for attackers.
Constant-time implementations eliminate timing variations that leak information about secret-dependent branches. You're already doing this if you follow FIPS 140-3 guidance for cryptographic modules.
Physical countermeasures include shielding, noise generation, and randomized clock frequencies. These increase hardware costs but make signal extraction harder. Payment terminals certified to PCI PTS requirements include these protections because the standard assumes physical access.
The argument: If your compliance obligations or threat model include physical access scenarios, runtime protections are necessary. They're the only defense when an attacker has the device in hand.
The Case for Accepting Runtime Risk
Runtime protections cost you performance, complexity, and money. Masking can double or triple execution time for cryptographic operations. This matters when processing authorization requests with sub-second latency requirements or signing thousands of transactions per second in a card management system.
Here's the counterargument: Physical access is already a significant risk in most architectures. If an attacker can extract power traces from your hardware security module, they can also:
- Image the device's firmware
- Exploit physical debug interfaces
- Replace components with modified versions
- Extract keys from adjacent systems through network access
You don't solve physical security with software countermeasures. You solve it with physical controls: locked cabinets, tamper-evident seals, video monitoring, and access logs. PCI DSS Requirement 9 exists for this reason. Your cardholder data environment already requires physical access controls, and your cryptographic devices should be in the most restricted zones.
The operational reality: Most breaches don't involve sophisticated side-channel attacks. They involve:
- Misconfigured access controls (Requirement 7)
- Unpatched vulnerabilities (Requirement 6)
- Weak authentication (Requirement 8)
- Missing network segmentation (Requirement 1)
Your risk-adjusted investment should focus on controls that address common attack patterns, not edge cases requiring physical access, specialized equipment, and expertise.
Where Practitioners Actually Land
Most organizations protect keys at rest and rely on physical controls for runtime security. You encrypt key material in storage, enforce Role-Based Access Control (RBAC) for key management systems, and restrict physical access to cryptographic devices.
The exception: Devices deployed in uncontrolled environments. Payment terminals, ATMs, and point-of-sale systems require runtime protections because you can't guarantee physical security. That's why PCI PTS 6.x requires protection against side-channel attacks for approved devices.
For data center environments, practitioners segment the decision by device type:
- Hardware security modules: Physical controls only. These devices sit in locked cages with 24/7 monitoring.
- Payment HSMs: Runtime protections if the device handles PIN processing or key injection in less-controlled facilities.
- General-purpose servers: Accept the risk. If an attacker has physical access to your application servers, side-channel attacks are the least of your problems.
Our Take
Protect keys in use when physical access is part of your threat model. Don't protect them when physical controls are sufficient.
The GRWP-SASCA research shows that side-channel attacks are becoming more practical. What once required 122 GB of memory now runs in under 1 GB and completes in minutes. That trend will continue. Attacks will get cheaper and easier to execute.
But that doesn't mean every cryptographic operation needs masking. It means you need to be precise about where physical access is realistic:
- Payment terminals in retail environments: Yes, protect in use
- ATMs and self-service kiosks: Yes, protect in use
- HSMs in your data center cage: Physical controls sufficient
- Cloud-hosted key management: Not your hardware; verify provider's certifications
The tradeoff isn't theoretical. Masking adds 2-3x latency to cryptographic operations. That's acceptable for a payment terminal processing one transaction at a time. It's prohibitive for a transaction signing service handling 10,000 operations per second.
Make the decision based on realistic physical access scenarios, not worst-case what-ifs. Your compliance obligations already tell you where runtime protections matter. PCI PTS requires them for payment acceptance devices. FIPS 140-3 Level 3 and above require physical tamper protections. If you're not operating in those contexts, your money is better spent on controls that address how breaches actually happen.
