CWE-1300: Improper Protection of Physical Side Channels

Description

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.

Submission Date :

May 29, 2020, midnight

Modification Date :

2023-10-26 00:00:00+00:00

Organization :

Tortuga Logic
Extended Description

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.

Example Vulnerable Codes

Example - 1

Consider a device that checks apasscode to unlock the screen.

As each character ofthe PIN number is entered, a correct characterexhibits one current pulse shape while anincorrect character exhibits a different currentpulse shape.

PIN numbers used to unlock a cell phoneshould not exhibit any characteristics aboutthemselves. This creates a side channel. Anattacker could monitor the pulses using anoscilloscope or other method. Once the firstcharacter is correctly guessed (based on theoscilloscope readings), they can then move to thenext character, which is much more efficient thanthe brute force method of guessing every possiblesequence of characters.

Rather than comparingeach character to the correct PIN value as it isentered, the device could accumulate the PIN in aregister, and do the comparison all at once at theend. Alternatively, the components for thecomparison could be modified so that the currentpulse shape is the same regardless of thecorrectness of the enteredcharacter.

Example - 2

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 or a combination of these techniques.

Example - 3

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.




<xhtml_b>if (exponent_reg[0])</xhtml_b>
<xhtml_b>result_reg <= result_next;</xhtml_b>

base_reg <= base_next;exponent_reg <= exponent_next;state <= `UPDATE;if (exponent_reg != 'd0) begin
...`UPDATE: begin...
...module mod_expendmodule

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].




<xhtml_b>if (exponent_reg[0]) begin</xhtml_b>
<xhtml_b>result_reg <= result_next;</xhtml_b>
<xhtml_b>end else begin</xhtml_b>
<xhtml_b>mask_reg <= result_next;</xhtml_b>
<xhtml_b>end</xhtml_b>
base_reg <= base_next;exponent_reg <= exponent_next;state <= `UPDATE;if (exponent_reg != 'd0) begin
...`UPDATE: begin...
...module mod_expendmodule

Related Weaknesses

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined to give an overview of the different insight to similar items that may exist at higher and lower levels of abstraction.

Visit http://cwe.mitre.org/ for more details.

© cvefeed.io
Latest DB Update: Nov. 17, 2024 18:48