Hardware Internal or Debug Modes Allow Override of Locks

Description

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

For example, consider the example Locked_override_register example. This register module supports a lock mode that blocks any writes after lock is set to 1.

However, it also allows override of the lock protection when scan_mode or debug_unlocked modes are active.

module Locked_register_example
(
input [15:0] Data_in,
input Clk,
input resetn,
input write,
input Lock,
input scan_mode,
input debug_unlocked,
output reg [15:0] Data_out
);

reg lock_status;

always @(posedge Clk or negedge resetn)

  if (~resetn) // Register is reset resetn
  begin

    lock_status <= 1'b0;

  end
  else if (Lock)
  begin

    lock_status <= 1'b1;

  end
  else if (~Lock)
  begin

    lock_status <= lock_status

  end

always @(posedge Clk or negedge resetn)

  if (~resetn) // Register is reset resetn
  begin

    Data_out <= 16'h0000;

  end
  else if (write & (~lock_status | scan_mode | debug_unlocked) ) // Register protected by Lock bit input, overrides supported for scan_mode & debug_unlocked
  begin

    Data_out <= Data_in;

  end
  else if (~write)
  begin

    Data_out <= Data_out;

  end

endmodule

If either the scan_mode or the debug_unlocked modes can be triggered by software, then the lock protection may be bypassed.

Either remove the debug and scan mode overrides or protect enabling of these modes so that only trusted and authorized users may enable these modes.

Example Two

The following example code [REF-1375] is taken from the register lock security peripheral of the HACK@DAC'21 buggy OpenPiton SoC. It demonstrates how to lock read or write access to security-critical hardware registers (e.g., crypto keys, system integrity code, etc.). The configuration to lock all the sensitive registers in the SoC is managed through the reglk_mem registers. These reglk_mem registers are reset when the hardware powers up and configured during boot up. Malicious users, even with kernel-level software privilege, do not get access to the sensitive contents that are locked down. Hence, the security of the entire system can potentially be compromised if the register lock configurations are corrupted or if the register locks are disabled.

...
always @(posedge clk_i)

  begin

    if(~(rst_ni && ~jtag_unlock && ~rst_9))

      begin

        for (j=0; j < 6; j=j+1) begin

          reglk_mem[j] <= 'h0;

        end

      end



...

The example code [REF-1375] illustrates an instance of a vulnerable implementation of register locks in the SoC. In this flawed implementation [REF-1375], the reglk_mem registers are also being reset when the system enters debug mode (indicated by the jtag_unlock signal). Consequently, users can simply put the processor in debug mode to access sensitive contents that are supposed to be protected by the register lock feature.

This can be mitigated by excluding debug mode signals from the reset logic of security-critical register locks as demonstrated in the following code snippet [REF-1376].

...
always @(posedge clk_i)

  begin

    if(~(rst_ni && ~rst_9))

      begin

        for (j=0; j < 6; j=j+1) begin

          reglk_mem[j] <= 'h0;

        end

      end



...

See Also