A device's real time power consumption may be monitored during security token evaluation and the information gleaned may be used to determine the value of the reference token.

The power consumed by a device may be instrumented and monitored in real time. If the algorithm for evaluating security tokens is not sufficiently robust, the power consumption may vary by token entry comparison against the reference value. Further, if retries are unlimited, the power difference between a "good" entry and a "bad" entry may be observed and used to determine whether each entry itself is correct thereby allowing unauthorized parties to calculate the reference value.

Primary

Resultant

Architecture and Design
The design of the algorithm itself may intrinsically allow the power side channel attack to be effective.

Implementation
This weakness may be introduced during implementation despite a robust design that otherwise prevents exploitation.

Confidentiality
Integrity
Availability
Access Control
Accountability
Authentication
Authorization
Non-Repudiation
Modify Memory
Read Memory
Read Files or Directories
Modify Files or Directories
Execute Unauthorized Code or Commands
Gain Privileges or Assume Identity
Bypass Protection Mechanism
Read Application Data
Modify Application Data
Hide Activities
As compromising a security token may result in complete system control, the impacts are relatively universal.

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.

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.

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.

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.

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.

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.

static nonvolatile password_tries = NUM_RETRIES;
do

while (password_tries == 0) ; // Hang here if no more password tries
password_ok = 0;
for (i = 0; i < NUM_PW_DIGITS; i++)

if (GetPasswordByte() == stored_password([i])

password_ok |= 1; // Power consumption is different here

else

password_ok |= 0; // than from here

end
if (password_ok > 0)

password_tries = NUM_RETRIES;
break_to_Ok_to_proceed

password_tries--;

while (true)
// Password OK

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.

static nonvolatile password_tries = NUM_RETRIES;
do

while (password_tries == 0) ; // Hang here if no more password tries
password_tries--; // Put retry code here to catch partial retries
password_ok = 0;
for (i = 0; i < NUM_PW_DIGITS; i++)

if (GetPasswordByte() == stored_password([i])

password_ok |= 0x10; // Power consumption here

else

password_ok |= 0x01; // is now the same here

end
if ((password_ok & 1) == 0)

password_tries = NUM_RETRIES;
break_to_Ok_to_proceed

while (true)
// Password OK

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.

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

input a;
input clk,rst;
output q;
reg q;

always@(posedge clk,posedge rst)
begin

if(rst==1'b1)

q<1'b0;

else

q<a;

end

endmodule

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.

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

input clk,rst;
input[3:0]a;
output[3:0]q;
reg[3:0]q;

always@(posedge clk,posedge rst)
begin

if (rst==1'b1)

q<4'b0000;

else

q<a;

end

endmodule

CVE-2020-12788
CMAC verification vulnerable to timing and power attacks.
https://www.cve.org/CVERecord?id=CVE-2020-12788

Power

Allowed
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

CWE Content Team
MITRE
2020-05-29
4.2
2020-08-20

CWE Content Team
MITRE
2021-03-15
updated Functional_Areas, Maintenance_Notes, Relationships

CWE Content Team
MITRE
2021-07-20
updated Demonstrative_Examples, Modes_of_Introduction, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns

CWE Content Team
MITRE
2021-10-28
updated Maintenance_Notes, References, Relationships, Type

CWE Content Team
MITRE
2022-06-28
updated Relationships

CWE Content Team
MITRE
2022-10-13
updated Demonstrative_Examples

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2024-02-29
4.14
2024-02-29
updated Demonstrative_Examples

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities

Accellera IP Security Assurance (IPSA) Working Group
Accellera Systems Initiative
2020-09-09
Submitted new material that could be added to already-existing entry CWE-1255. Added new Potential Mitigations, a new example, an observed example, and an additional reference.