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].
CWE-1300 Base Stable
Improper Protection of Physical Side Channels
This vulnerability occurs when a hardware device lacks adequate safeguards against physical side-channel attacks. Attackers can exploit measurable patterns in power usage, electromagnetic radiation,…
Definition
What is CWE-1300?
This vulnerability occurs when a hardware device lacks adequate safeguards against physical side-channel attacks. Attackers can exploit measurable patterns in power usage, electromagnetic radiation, or even sound emissions to uncover sensitive information like encryption keys.
Physical side-channel attacks work by monitoring the subtle, analog side effects of a device's operation. Even when digital data is perfectly secured, an attacker with physical access or nearby equipment can analyze fluctuations in power consumption, electromagnetic leaks, or acoustic noise. By correlating these physical patterns with the device's processing activity, secrets can be inferred without ever breaking the digital security directly.
These attacks are a well-established threat, particularly against cryptographic operations. Protecting against them requires deliberate hardware and software design choices that obscure or eliminate the relationship between secret data processing and its physical manifestations. Without such countermeasures, devices remain vulnerable to key extraction and data theft from seemingly innocuous physical signals.
Real-world impact
Real-world CVEs caused by CWE-1300
-
Power side-channels leak secret information from processor
-
electromagnetic-wave side-channel in security-related microcontrollers allows extraction of private key
-
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
-
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.
-
message encryption software uses certain instruction sequences that allows RSA key extraction using a chosen-ciphertext attack and acoustic cryptanalysis
-
virtualization product allows recovery of AES keys from the guest OS using a side channel attack against a power/energy monitoring interface.
-
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
How attackers exploit it
Step-by-step attacker path
- 1
Consider a device that checks a passcode to unlock the screen.
- 2
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.
- 3
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.
- 4
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.
- 5
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.
Vulnerable code example
Vulnerable Other
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. Secure code example
Secure Other
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. What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-1300
- 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.
Detection signals
How to detect CWE-1300
Post-silicon, perform full side-channel attacks (penetration testing) covering as many known leakage models as possible against test code.
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].
Plexicus auto-detects CWE-1300 and opens a fix PR in under 60 seconds.
Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.
Frequently asked questions What is CWE-1300?
How serious is CWE-1300?
What languages or platforms are affected by CWE-1300?
How can I prevent CWE-1300?
How does Plexicus detect and fix CWE-1300?
Where can I learn more about CWE-1300?
Frequently asked questions
What is CWE-1300?
This vulnerability occurs when a hardware device lacks adequate safeguards against physical side-channel attacks. Attackers can exploit measurable patterns in power usage, electromagnetic radiation, or even sound emissions to uncover sensitive information like encryption keys.
How serious is CWE-1300?
MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.
What languages or platforms are affected by CWE-1300?
MITRE lists the following affected platforms: Not OS-Specific, Not Architecture-Specific, Not Technology-Specific.
How can I prevent CWE-1300?
Apply blinding or masking techniques to implementations of cryptographic algorithms. Add shielding or tamper-resistant protections to the device to increase the difficulty of obtaining measurements of the side-channel.
How does Plexicus detect and fix CWE-1300?
Plexicus's SAST engine matches the data-flow signature for CWE-1300 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-1300?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/1300.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-1300
CWE-203 Parent
Observable Discrepancy
This vulnerability occurs when an application responds differently to unauthorized users based on internal conditions. Attackers can…
CWE-1303 Sibling
Non-Transparent Sharing of Microarchitectural Resources
This vulnerability occurs when a processor's internal performance features, like caches and branch predictors, are unintentionally shared…
CWE-204 Sibling
Observable Response Discrepancy
This vulnerability occurs when an application responds differently to similar requests, unintentionally leaking details about its internal…
CWE-205 Sibling
Observable Behavioral Discrepancy
This vulnerability occurs when an application behaves differently in ways that unauthorized users can detect. These observable differences…
CWE-208 Sibling
Observable Timing Discrepancy
This vulnerability occurs when an application takes measurably different amounts of time to perform different operations, such as checking…
CWE-1255 Child
Comparison Logic is Vulnerable to Power Side-Channel Attacks
This vulnerability occurs when a device's power consumption is monitored during security checks, allowing attackers to deduce secret…
Resources
Further reading
- MITRE — official CWE-1300 https://cwe.mitre.org/data/definitions/1300.html
- Introduction to differential power analysis and related attacks https://www.rambus.com/wp-content/uploads/2015/08/DPATechInfo.pdf
- The EM Side-Channel(s) https://link.springer.com/content/pdf/10.1007/3-540-36400-5_4.pdf
- RSA key extraction via low-bandwidth acoustic cryptanalysis https://www.iacr.org/archive/crypto2014/86160149/86160149.pdf
- Power Analysis for Cheapskates https://media.blackhat.com/eu-13/briefings/OFlynn/bh-eu-13-for-cheapstakes-oflynn-wp.pdf
- Data Remanence in Semiconductor Devices https://www.usenix.org/legacy/events/sec01/full_papers/gutmann/gutmann.pdf
- This Black Box Can Brute Force Crack iPhone PIN Passcodes https://www.intego.com/mac-security-blog/iphone-pin-pass-code/
Ready when you are
Don't Let Security
Weigh You Down.
Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.