Timing is of the Essence in Hardware Security

What is a Timing Side Channel?

Timing side channels are a form of information leakage that occur when an attacker can gain insights into a system through variations in execution time. By measuring the time taken to perform certain operations, an attacker may infer information about secure assets such as cryptographic keys. Detecting and mitigating timing side channels is crucial in security-critical systems to prevent unauthorized access or data exposure.

Methods to mitigate software timing side channels have been described by various sources, for example by Intel in "Guidelines for Mitigating Timing Side Channels Against Cryptographic Implementations ". Hardware timing side channels refer to information leakage through variations in execution time at the hardware level. Well known examples includes Spectre and Meltdown which utilize access time differences when data is present in a cache or not, but timing side channels are not limited to processors. Any time sensitive information is processed in hardware and the processing time depends on the information value, there may be a timing side channel that can leak the information.

One example of a HW timing side channel is described in CWE-1254: Incorrect Comparison Logic Granularity.

Hardware comparison logic is used to compare a supplied value to a secret reference value for example passwords, Message Authentication Codes (MACs) and responses to verification challenges. If the compare is performed at a lower granularity than the entire value at once, it may be easy to guess the secret reference value based on how fast the compare pass or fail.

How do you Detect Hardware Timing Side Channels?

Detecting timing side channels in a hardware implementation is difficult using functional verification tools such as simulation, SystemVerilog Assertions or Formal Property Verification because the logic is functionally correct even if it has a timing side channel. Detection requires Information Flow Analysis tools.

The first step is to identify the secure asset that must not be disclosed. Second, determine relevant outputs such as "ready" or "data valid" that may be accessible to an attacker. Next, use a tool such as Cycuity's Radix to determine if the secret asset has any influence on the time the operation takes.

Timing Side Channel Example

The following SystemVerilog module compares a supplied password with a hardcoded golden value. It is implemented as a simple FSM which compares one byte per clock cycle when the "start" input is asserted. When the compare is completed, the "done" output is asserted and the "grant_access" output indicate if the two values match.

The secret asset in this example is the "golden_pass" register.

module timing_channel (input wire clk, reset, start,
		       input wire [31:0] entered_pass,
		       output logic grant_access, done);

  typedef enum logic [2:0] {IDLE, C0, C1, C2, C3} state_t;
  state_t cs, ns;
   logic [31:0] golden_pass = 32'hdead_beef;
   
  always_ff @(posedge clk or posedge reset)
    if (reset) cs <= IDLE;
    else       cs <= ns;
   
  always @(*) begin
     ns = cs;
     done = 0;
     grant_access = 0;
     case (cs)     
       IDLE: if (start) ns = C0;
       C0:   if (entered_pass[7:0] != golden_pass[7:0]) begin
	  ns = IDLE;
	  done = 1;
       end
       else ns = C1;
       C1:   if (entered_pass[15:8] != golden_pass[15:8]) begin
	  ns = IDLE;
	  done = 1;
       end
       else ns = C2;
       C2:   if (entered_pass[23:16] != golden_pass[23:16]) begin
	  ns = IDLE;
	  done = 1;
       end
       else ns = C3;
       C3:   if (entered_pass[31:24] != golden_pass[31:24]) begin
	  ns = IDLE;
	  done = 1;
       end
       else begin
	  ns = IDLE;
	  done = 1;
	  grant_access = 1;
       end
     endcase
  end

endmodule        

If we track where information from the "golden_pass" asset flows, indicated by red shading, we see that it influence all outputs of the module.

It is expected that the "grant_access" output depends on the "golden_pass" value but it does not reveal any information beyond pass and fail of the compare function. The information flow to the "done" signal is however showing a timing side channel. The "done" output is asserted as soon as the first compare failure is detected. By measuring the time between "start" and "done" we can determine which byte failed. Trying all values for the first byte is easy and when the time to "done" increase, the guess is correct. Guessing a password or other secret key byte by byte is much easier than guessing the entire value at once.

The timing side channel is caused by the return to the IDLE state and assertion of "done" if the byte wise compare fails.

To avoid the timing side channel, re-code the FSM so it return to the IDLE state after all four bytes have been compared and assert "done" after the last compare is done regardless if the individual byte compare fails or not.

module no_timing_channel (input wire clk, reset, start,
	  	          input wire [31:0] entered_pass,
		          output logic grant_access, done);

typedef enum logic [2:0] {IDLE, C0, C1, C2, C3, C4} state_t;
state_t cs, ns;
logic [31:0] golden_pass = 32'hdead_beef;
logic 	fail, failbyte;
   
always_ff @(posedge clk or posedge reset)
  if (reset) begin
     cs <= IDLE;
     fail <= 0;
     end
  else begin
     cs <= ns;
     fail <= failbyte;
     end
   
always @(*) begin
   ns = cs;
   done = 0;
   grant_access = 0;
   failbyte = 0;
   case (cs)     
     IDLE: if (start) ns = C0;
     C0: begin
        if (entered_pass[7:0] != golden_pass[7:0]) failbyte = 1;
        ns = C1;
     end
     C1: begin
	if (entered_pass[15:8] != golden_pass[15:8]) failbyte = 1;
	ns = C2;
     end
     C2: begin
	if (entered_pass[23:16] != golden_pass[23:16]) failbyte = 1;
	ns = C3;
     end
     C3: begin
	if (entered_pass[31:24] != golden_pass[31:24]) failbyte = 1;
	ns = C4;
     end
     C4: begin
	ns = IDLE;
	done = 1;
	if (!fail) grant_access = 1;
     end
   endcase
end
endmodule        

Now we see that there is no information flow from the "golden_pass" register to the "done" output.

The time between "start" asserted and "done" asserted is constant regardless of the pass / fail status of each byte compare, thus eliminating the timing side channel. Implementing a timing constant function is required in this example but in general the goal is to implement timing that is independent of the secret assets even if it is not constant.