Comparison Logic is Vulnerable to Power Side-Channel Attacks

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.


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.

Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

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

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.

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 Two

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

See Also

Comprehensive Categorization: Sensitive Information Exposure

Weaknesses in this category are related to sensitive information exposure.

Physical Access Issues and Concerns

Weaknesses in this category are related to concerns of physical access.

Power, Clock, Thermal, and Reset Concerns

Weaknesses in this category are related to system power, voltage, current, temperature, clocks, system state saving/restoring, and resets at the platform and SoC level.

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weaknesses Introduced During Implementation

This view (slice) lists weaknesses that can be introduced during implementation.


Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.