2036
Example Language: Other (Bad)
All microarchitectural registers in this chip can be accessed through the debug interface. As a result, even an untrusted
debugger can access this data and retrieve sensitive manufacturing data.
Example Language: (Good)
Registers used to store sensitive values read from fuses should be blocked during debug. These registers should be
disconnected from the debug interface.
Example 2:
The example code below is taken from one of the AES cryptographic accelerators of the
HACK@DAC'21 buggy OpenPiton SoC [REF-1366]. The operating system (OS) uses three AES
keys to encrypt and decrypt sensitive data using this accelerator. These keys are sensitive data
stored in fuses. The security of the OS will be compromised if any of these AES keys are leaked.
During system bootup, these AES keys are sensed from fuses and stored in temporary hardware
registers of the AES peripheral. Access to these temporary registers is disconnected during
the debug state to prevent them from leaking through debug access. In this example (see the
vulnerable code source), the registers key0, key1, and key2 are used to store the three AES keys
(which are accessed through key_big0, key_big1, and key_big2 signals). The OS selects one of
these three keys through the key_big signal, which is used by the AES engine.
Example Language: Verilog (Bad)
...
assign key_big0 = debug_mode_i ? 192'b0 : {key0[0],
key0[1], key0[2], key0[3], key0[4], key0[5]};
assign key_big1 = debug_mode_i ? 192'b0 : {key1[0],
key1[1], key1[2], key1[3], key1[4], key1[5]};
assign key_big2 = {key2[0], key2[1], key2[2],
key2[3], key2[4], key2[5]};
...
assign key_big = key_sel[1] ? key_big2 : ( key_sel[0] ?
key_big1 : key_big0 );
...
The above code illustrates an instance of a vulnerable implementation for blocking AES key
mechanism when the system is in debug mode (i.e., when debug_mode_i is asserted). During
debug mode, key accesses through key_big0 and key_big1 are effectively disconnected, as their
values are set to zero. However, the key accessed via the key_big2 signal remains accessible,
creating a potential pathway for sensitive fuse data leakage, specifically AES key2, during debug
mode. Furthermore, even though it is not strictly necessary to disconnect the key_big signal
when entering debug mode (since disconnecting key_big0, key_big1, and key_big2 will inherently
disconnect key_big), it is advisable, in line with the defense-in-depth strategy, to also sever the
connection to key_big. This additional security measure adds an extra layer of protection and
safeguards the AES keys against potential future modifications to the key_big logic.
To mitigate this, disconnect access through key_big2 and key_big during debug mode [REF-1367].
Example Language: Verilog (Good)
...
assign key_big0 = debug_mode_i ? 192'b0 : {key0[0],
key0[1], key0[2], key0[3], key0[4], key0[5]};
assign key_big1 = debug_mode_i ? 192'b0 : {key1[0],
key1[1], key1[2], key1[3], key1[4], key1[5]};
assign key_big2 = debug_mode_i ? 192'b0 : {key2[0],
key2[1], key2[2], key2[3], key2[4], key2[5]};
...
assign key_big = debug_mode_i ? 192'b0 : ( key_sel[1] ?
key_big2 : ( key_sel[0] ? key_big1 : key_big0 ) );
...
CWE Version 4.14
CWE-1244: Internal Asset Exposed to Unsafe Debug Access Level or State
CWE-1244: Internal Asset Exposed to Unsafe Debug Access Level or State