The device does not contain sufficient protection
mechanisms to prevent physical side channels from exposing
sensitive information due to patterns in physically observable
phenomena such as variations in power consumption,
electromagnetic emissions (EME), or acoustic emissions.

An adversary could monitor and measure physical
phenomena to detect patterns and make inferences, even if it
is not possible to extract the information in the digital
domain.
Physical side channels have been well-studied for
decades in the context of breaking implementations of
cryptographic algorithms or other attacks against security
features. These side channels may be easily observed by an
adversary with physical access to the device, or using a
tool that is in close proximity. If the adversary can
monitor hardware operation and correlate its data processing
with power, EME, and acoustic measurements, the adversary
might be able to recover of secret keys and data.

Primary

Resultant

Implementation

Confidentiality
Read Memory
Read Application Data

Manual Analysis
Perform a set of leakage detection tests such as the procedure outlined in the Test Vector Leakage Assessment (TVLA) test requirements for AES [REF-1230]. TVLA is the basis for the ISO standard 17825 [REF-1229]. A separate methodology is provided by [REF-1228]. Note that sole reliance on this method might not yield expected results [REF-1239] [REF-1240].
Moderate

Manual Analysis

Post-silicon, perform full side-channel attacks (penetration testing) covering as many known leakage models as possible against test code.
Moderate

Manual Analysis

Pre-silicon - while the aforementioned TVLA methods can be performed post-silicon, models of device power consumption or other physical emanations can be built from information present at various stages of the hardware design process before fabrication. TVLA or known side-channel attacks can be applied to these simulated traces and countermeasures applied before tape-out. Academic research in this field includes [REF-1231] [REF-1232] [REF-1233].
Moderate

Architecture and Design
Apply blinding or masking techniques to implementations of cryptographic algorithms.

Implementation
Add shielding or tamper-resistant protections to the device to increase the difficulty of obtaining measurements of the side-channel.

Consider a device that checks a
passcode to unlock the screen.
As each character of
the PIN number is entered, a correct character
exhibits one current pulse shape while an
incorrect character exhibits a different current
pulse shape.
PIN numbers used to unlock a cell phone
should not exhibit any characteristics about
themselves. This creates a side channel. An
attacker could monitor the pulses using an
oscilloscope or other method. Once the first
character is correctly guessed (based on the
oscilloscope readings), they can then move to the
next character, which is much more efficient than
the brute force method of guessing every possible
sequence of characters.
Rather than comparing
each character to the correct PIN value as it is
entered, the device could accumulate the PIN in a
register, and do the comparison all at once at the
end. Alternatively, the components for the
comparison could be modified so that the current
pulse shape is the same regardless of the
correctness of the entered
character.

Consider the device vulnerability CVE-2021-3011, which affects certain microcontrollers [REF-1221]. The Google Titan Security Key is used for two-factor authentication using cryptographic algorithms. The device uses an internal secret key for this purpose and exchanges information based on this key for the authentication. If this internal secret key and the encryption algorithm were known to an adversary, the key function could be duplicated, allowing the adversary to masquerade as the legitimate user.
The local method of extracting the secret key consists of plugging the key into a USB port and using electromagnetic (EM) sniffing tools and computers.
Several solutions could have been considered by the manufacturer. For example, the manufacturer could shield the circuitry in the key or add randomized delays, indirect calculations with random values involved, or randomly ordered calculations to make extraction much more difficult. The manufacturer could use a combination of these techniques.

The code snippet provided here is part of the modular exponentiation module found in the HACK@DAC'21 Openpiton System-on-Chip (SoC), specifically within the RSA peripheral [REF-1368]. Modular exponentiation, denoted as "a^b mod n," is a crucial operation in the RSA public/private key encryption. In RSA encryption, where 'c' represents ciphertext, 'm' stands for a message, and 'd' corresponds to the private key, the decryption process is carried out using this modular exponentiation as follows: m = c^d mod n, where 'n' is the result of multiplying two large prime numbers.

...
module mod_exp

...
`UPDATE: begin

if (exponent_reg != 'd0) begin

if (exponent_reg[0])

result_reg <= result_next;

base_reg <= base_next;
exponent_reg <= exponent_next;
state <= `UPDATE;

...

endmodule

The vulnerable code shows a buggy implementation of binary exponentiation where it updates the result register (result_reg) only when the corresponding exponent bit (exponent_reg[0]) is set to 1. However, when this exponent bit is 0, the output register is not updated. It's important to note that this implementation introduces a physical power side-channel vulnerability within the RSA core. This vulnerability could expose the private exponent to a determined physical attacker. Such exposure of the private exponent could lead to a complete compromise of the private key.
To address mitigation requirements, the developer can develop the module by minimizing dependency on conditions, particularly those reliant on secret keys. In situations where branching is unavoidable, developers can implement masking mechanisms to obfuscate the power consumption patterns exhibited by the module (see good code example). Additionally, certain algorithms, such as the Karatsuba algorithm, can be implemented as illustrative examples of side-channel resistant algorithms, as they necessitate only a limited number of branch conditions [REF-1369].

...
module mod_exp

...
`UPDATE: begin

if (exponent_reg != 'd0) begin

if (exponent_reg[0]) begin

result_reg <= result_next;

end else begin

mask_reg <= result_next;

end
base_reg <= base_next;
exponent_reg <= exponent_next;
state <= `UPDATE;

...

endmodule

CVE-2022-35888
Power side-channels leak secret information from processor
https://www.cve.org/CVERecord?id=CVE-2022-35888

CVE-2021-3011
electromagnetic-wave side-channel in security-related microcontrollers allows extraction of private key
https://www.cve.org/CVERecord?id=CVE-2021-3011

CVE-2019-14353
Crypto hardware wallet's power consumption relates to total number of pixels illuminated, creating a side channel in the USB connection that allows attackers to determine secrets displayed such as PIN numbers and passwords
https://www.cve.org/CVERecord?id=CVE-2019-14353

CVE-2020-27211
Chain: microcontroller system-on-chip contains uses a register value stored in flash to set product protection state on the memory bus but does not contain protection against fault injection (CWE-1319), which leads to an incorrect initialization of the memory bus (CWE-1419) leading the product to be in an unprotected state.
https://www.cve.org/CVERecord?id=CVE-2020-27211

CVE-2013-4576
message encryption software uses certain instruction sequences that allows RSA key extraction using a chosen-ciphertext attack and acoustic cryptanalysis
https://www.cve.org/CVERecord?id=CVE-2013-4576

CVE-2020-28368
virtualization product allows recovery of AES keys from the guest OS using a side channel attack against a power/energy monitoring interface.
https://www.cve.org/CVERecord?id=CVE-2020-28368

CVE-2019-18673
power consumption varies based on number of pixels being illuminated in a display, allowing reading of secrets such as the PIN by using the USB interface to measure power consumption
https://www.cve.org/CVERecord?id=CVE-2019-18673

Power

Allowed
This CWE entry is at the Base 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.

Nicole Fern
Cycuity (originally submitted as Tortuga Logic)
2020-05-29
4.2
2020-08-20

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

CWE Content Team
MITRE
2021-07-20
updated Related_Attack_Patterns

CWE Content Team
MITRE
2021-10-28
updated Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Name, Observed_Examples, References, Relationships, Weakness_Ordinalities

CWE Content Team
MITRE
2022-06-28
updated Relationships

CWE Content Team
MITRE
2022-10-13
updated References, Relationships

CWE Content Team
MITRE
2023-01-31
updated Related_Attack_Patterns

CWE Content Team
MITRE
2023-04-27
updated References, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2023-10-26
updated Demonstrative_Examples, Observed_Examples, References

CWE Content Team
MITRE
2025-04-03
4.17
2025-04-03
updated Demonstrative_Examples

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated References, Relationships

Anders Nordstrom, Alric Althoff
Cycuity (originally submitted as Tortuga Logic)
2021-10-11
Provided detection methods, observed examples, and references

Nicole Fern
Riscure
2021-10-13
Provided detection methods, observed examples, and references

Chen Chen, Rahul Kande, Jeyavijayan Rajendran
Texas A&M University
2023-06-21
suggested demonstrative example

Shaza Zeitouni, Mohamadreza Rostami, Ahmad-Reza Sadeghi
Technical University of Darmstadt
2023-06-21
suggested demonstrative example

Improper Protection Against Physical Side Channels