logo

Comparison Logic is Vulnerable to Power Side-Channel Attacks

Draft Variant
Structure: Simple
Description

This vulnerability occurs when a device's power consumption is monitored during security checks, allowing attackers to deduce secret reference values by analyzing subtle differences in energy usage during comparison operations.

Extended Description

Attackers can exploit this weakness by measuring a device's real-time power draw while it validates security tokens, like passwords or cryptographic keys. If the comparison logic isn't designed to consume consistent power regardless of the input, each guess creates a unique power signature. Observing these tiny variations allows an attacker to distinguish correct from incorrect character guesses, effectively turning power consumption into a data leak. Unlimited retry mechanisms dramatically worsen this issue, giving attackers repeated opportunities to measure and compare power traces. To prevent this, developers must implement constant-time comparison algorithms that execute identical operations and power patterns for all inputs, alongside strict rate-limiting on authentication attempts to block the gradual reconstruction of secrets through side-channel analysis.
Common Consequences 1
Scope: ConfidentialityIntegrityAvailabilityAccess ControlAccountabilityAuthenticationAuthorizationNon-Repudiation

Impact: Modify MemoryRead MemoryRead Files or DirectoriesModify Files or DirectoriesExecute Unauthorized Code or CommandsGain Privileges or Assume IdentityBypass Protection MechanismRead Application DataModify Application DataHide Activities

As compromising a security token may result in complete system control, the impacts are relatively universal.
Potential Mitigations 5
Phase: Architecture and Design
The design phase must consider each check of a security token against a standard and the amount of power consumed during the check of a good token versus a bad token. The alternative is an all at once check where a retry counter is incremented PRIOR to the check.
Phase: Architecture and Design
Another potential mitigation is to parallelize shifting of secret data (see example 2 below). Note that the wider the bus the more effective the result.
Phase: Architecture and Design
An additional potential mitigation is to add random data to each crypto operation then subtract it out afterwards. This is highly effective but costly in performance, area, and power consumption. It also requires a random number generator.
Phase: Implementation
If the architecture is unable to prevent the attack, using filtering components may reduce the ability to implement an attack, however, consideration must be given to the physical removal of the filter elements.
Phase: Integration
During integration, avoid use of a single secret for an extended period (e.g. frequent key updates). This limits the amount of data compromised but at the cost of complexity of use.
Demonstrative Examples 2
Consider an example hardware module that checks a user-provided password (or PIN) to grant access to a user. The user-provided password is compared against a stored value byte-by-byte.

Code Example:

Bad
C

static nonvolatile password_tries = NUM_RETRIES; do

c
Since the algorithm uses a different number of 1's and 0's for password validation, a different amount of power is consumed for the good byte versus the bad byte comparison. Using this information, an attacker may be able to guess the correct password for that byte-by-byte iteration with several repeated attempts by stopping the password evaluation before it completes.
Among various options for mitigating the string comparison is obscuring the power consumption by having opposing bit flips during bit operations. Note that in this example, the initial change of the bit values could still provide power indication depending upon the hardware itself. This possibility needs to be measured for verification.

Code Example:

Good
C

static nonvolatile password_tries = NUM_RETRIES; do

c
This code demonstrates the transfer of a secret key using Serial-In/Serial-Out shift. It's easy to extract the secret using simple power analysis as each shift gives data on a single bit of the key.

Code Example:

Bad
Verilog

module siso(clk,rst,a,q);

verilog
This code demonstrates the transfer of a secret key using a Parallel-In/Parallel-Out shift. In a parallel shift, data confounded by multiple bits of the key, not just one.

Code Example:

Good
Verilog

module pipo(clk,rst,a,q);

verilog
Observed Examples 1
CVE-2020-12788CMAC verification vulnerable to timing and power attacks.
References 1
Power Analysis
Wikipedia
https://en.wikipedia.org/wiki/Power_analysis
ID: REF-1184
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
Not Technology-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Related Attack Patterns
Functional Areas
  1. Power
Related Weaknesses
ChildOf: Improper Protection of Physical Side Channels (CWE-1300)
PeerOf: Improper Restriction of Security Token Assignment (CWE-1259)