Power Analysis Attacks
Parent: EXF-0002
Description
The attacker infers secrets by measuring instantaneous power consumption of target devices, often crypto engines or controllers, and correlating traces with hypothesized internal operations. Simple power analysis (SPA) extracts structure (operation sequences, key-dependent branches); differential/correlation power analysis (DPA/CPA) uses many traces and statistics to recover key bits from tiny data-dependent variations. Practically, measurements may come from instrumented rails during I&T, from a compromised payload monitoring local supplies, or from co-located hardware that senses current/voltage fluctuations. With sufficient traces and alignment (triggering on command/crypto invocation), internal values become observable through their power signatures.
Mappings
EU regulation articles
Power-analysis recovery of key bits defeats the confidentiality (2)(e) requires; the 'state-of-the-art mechanisms' clause directly contemplates DPA/CPA-resistant implementations.
Masking, randomization, and power-balanced crypto cores are exactly the exploitation-mitigation mechanisms (2)(k) places on the manufacturer at design time.
Power-analysis attacks (primary mapping: Annex I, Part I, (2)(k)) require regular DPA/CPA testing under (3) — masking and randomization countermeasures lose effectiveness if not validated under realistic measurement scenarios.
DPA/CPA-resistant crypto implementations (masking, randomization, power-balanced cores) are part of the cryptographic concept 85(1) requires the operator to define.
Power-analysis attacks (primary: Art. 85(1)) cascade to 85(2) — key rotation cadence limits how many traces an attacker can amass against a single key.
Art. 21(2)(h) crypto policy does not interdict power-analysis key recovery; side-channel-resistant implementation (power masking, hiding) is hardware/implementation hardening, not use-of-cryptography policy. Addresses (domain relevance).
Power-analysis attacks exploit instantaneous power consumption; the protection-against-physical-and-environmental-threats obligation covers power-rail conditioning, balanced-logic design and other physical-layer controls that resist SPA/DPA.
Secure-development implementations (masking, blinding, randomized scheduling) reduce the data-dependent leakage measurable through power analysis.
ENISA controls
Hardware-level power-consumption noise injection directly counters SPA/DPA/CPA attacks correlating power traces with internal operations.
Power masking obfuscates the relationship between internal variables and observable power-consumption side channels.
Cross-reference controls
Referenced in: sparta-data
Mapped by SPARTA, not curated by SafeMode Space.
Referenced in: sparta-data
Mapped by SPARTA, not curated by SafeMode Space.
Referenced in: sparta-data
Mapped by SPARTA, not curated by SafeMode Space.
Referenced in: sparta-data
Mapped by SPARTA, not curated by SafeMode Space.
SA-15 addresses development-process governance for power-side-channel-resistant implementations.
Referenced in: sparta-data
Mapped by SPARTA, not curated by SafeMode Space.
Referenced in: sparta-data
Mapped by SPARTA, not curated by SafeMode Space.
Referenced in: sparta-data
Mapped by SPARTA, not curated by SafeMode Space.
Referenced in: sparta-data
Mapped by SPARTA, not curated by SafeMode Space.
SC-13 addresses cryptographic-protection governance that should mandate masking/blinding mitigations against power analysis.
Referenced in: sparta-data
Mapped by SPARTA, not curated by SafeMode Space.
T2035 'Side-channel exfiltration' parent covers all side-channel exfiltration mechanisms — addresses EXF-0002.01 Power Analysis Attacks (instantaneous power consumption as a side channel). SPACE-SHIELD has no power-analysis-specific sub-technique.
SPARTA countermeasures
Mapped by SPARTA, not curated by SafeMode Space.
Mapped by SPARTA, not curated by SafeMode Space.
Mapped by SPARTA, not curated by SafeMode Space.
Cite as SafeMode Space, EXF-0002.01 (SPARTA v3.2).