CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE- Individual Dictionary Definition (4.5)  
ID

CWE-1255: Comparison Logic is Vulnerable to Power Side-Channel Attacks

Weakness ID: 1255
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
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.
+ Extended Description

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.

+ Relationships
Section HelpThis table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.205Observable Behavioral Discrepancy
Section HelpThis table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1206Power, Clock, and Reset Concerns
PeerOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.1259Improper Restriction of Security Token Assignment
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and DesignThe design of the algorithm itself may intrinsically allow the power side channel attack to be effective
ImplementationThis weakness may be introduced during implementation despite a robust design that otherwise prevents exploitation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Architecture-Independent (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality
Integrity
Availability
Access Control
Accountability
Authentication
Authorization
Non-Repudiation

Technical Impact: 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
+ Demonstrative Examples

Example 1

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.

(bad code)
Example Language: Other 

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.

(good code)
 


Among various options for mitigating the string comparison is obscuring the power comsumption 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

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.

(good code)
 

An alternative to the previous example is simply comparing the whole password simultaneously.

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
  for (i = 0; i < NUM_PW_DIGITS; i++)
    stored_password([i] = GetPasswordByte();
  end
  if (stored_password == saved_password)
    password_tries = NUM_RETRIES;
    break_to_Ok_to_proceed
while (true)
// Password OK

Since comparison is done atomically, there is no indication which bytes fail forcing the attacker to brute force the whole password at once. Note that other mitigations may exist such as masking - causing a large current draw to mask individual bit flips.

Example 2

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.

(bad code)
Example Language: Other 

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.

(good code)
Example Language: Other 

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
+ Observed Examples
ReferenceDescription
CMAC verification vulnerable to timing and power attacks.
+ Potential Mitigations

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.
+ Functional Areas
  • Power
+ Notes

Maintenance

As of CWE 4.3, CWE-1300 and CWE-1255 are being investigated for potential duplication or overlap, since they are both related to physical side channels but have different ChildOf/MemberOf relationships in views 1000 and 1194.
+ References
[REF-1184] Community. "Power Analysis". <https://en.wikipedia.org/wiki/Power_analysis>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2020-05-29CWE Content TeamMITRE
+ Contributions
Contribution DateContributorOrganization
2020-09-09Accellera IP Security Assurance (IPSA) Working GroupAccellera Systems Initiative
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.
+ Modifications
Modification DateModifierOrganization
2021-03-15CWE Content TeamMITRE
updated Functional_Areas, Maintenance_Notes, Relationships
2021-07-20CWE Content TeamMITRE
updated Demonstrative_Examples, Modes_of_Introduction, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns
More information is available — Please select a different filter.
Page Last Updated: July 20, 2021