[Security] CWE-1239 - Failure to Clear Sensitive Information from Hardware Registers

[m2kar]

Security Issue: CWE-1239 - Failure to Clear Sensitive Information from Hardware Registers

Issue Description

A security vulnerability has been identified in the SystemVerilog SHA256 implementation. The hardware design fails to properly clear sensitive information from built-in registers when the user of the hardware block changes, which corresponds to CWE-1239.

Technical Details

The SHA256 hardware implementation stores sensitive cryptographic information in various registers during operation, including:

1. Intermediate hash values in registers a through h in sha_mainloop.sv
2. Final hash state registers h1 through h8 in sha_mainloop.sv
3. Temporary calculation values in t1 and t2
4. Hash results in first_hash and secnd_hash in miner.sv

The current implementation has the following security weaknesses:

• Incomplete Register Clearing: While the reset signal (rst) initializes hash state registers (h1 to h8), it does not clear all intermediate state registers (a to h, t1, t2).
• No User Context Switching Mechanism: The design lacks a mechanism to detect user changes and clear registers accordingly.
• No Post-Computation Clearing: After computation is complete (done signal asserted), sensitive data remains in registers indefinitely.
• Lack of Secure Context Switching: No secure context switching mechanism exists to ensure register contents are cleared between different users.

Security Impact

This vulnerability could lead to:

1. Information Leakage: If multiple users or processes share this hardware accelerator, cryptographic keys or hash intermediate values from one user could leak to subsequent users.
2. Side-Channel Attacks: Residual data in registers could facilitate side-channel attacks against the cryptographic implementation.
3. Key Extraction: In security-sensitive applications like cryptocurrency mining, this could potentially lead to private key extraction.
4. Physical Attack Vector: In scenarios where physical access is possible, attackers might extract sensitive information from these uncleared registers.

Reproduction Steps

The vulnerability is inherent in the design and can be observed by:

1. Running a hash operation with sensitive data
2. Switching to a different user context without resetting the hardware
3. Examining register contents to find residual data from the previous operation

Simulation Verification

To verify this vulnerability, we modified the testbench (miner_tb.sv) to continue running for additional clock cycles after the hash computation is complete. This allows us to observe the state of internal registers after the done signal is asserted.

// Modified testbench to continue running after computation is complete
initial begin
    $dumpfile("miner_tb.vcd");
    $dumpvars;
    assign message = 640'h0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c;
    assign clk = 0;
    assign rst = 1; #5
    assign rst = 0;
    while(done !== 1'b1) begin
        assign clk = ~clk;
        #5;
    end

    // Continue running for additional clock cycles after computation is done
    $display("Hash computation completed. Running for additional clock cycles...");
    $display("Hash: %h", hashed);

    // Run for 20 more clock cycles (10 full clock periods)
    repeat(20) begin
        assign clk = ~clk;
        #5;
    end

    $display("FINISHED miner_tb after additional clock cycles");
    $finish;
end

The simulation results confirm that sensitive data remains in registers after computation is complete:

As shown in the simulation waveform, the following issues were observed:

1. After the done signal is asserted, all intermediate registers (a through h, t1, t2) retain their values
2. The hash result registers (first_hash, secnd_hash) continue to hold sensitive cryptographic data
3. No automatic clearing of registers occurs during the additional clock cycles
4. The system remains in a state where sensitive information could be extracted by a subsequent user

Recommended Fixes

To address this vulnerability, the following changes are recommended:

1. Implement Complete Register Clearing:

   • Modify the reset logic in sha_mainloop.sv to explicitly clear all registers, including intermediate state registers
   • Add zero-initialization for registers a through h, t1, and t2 in the reset block

2. Add User Context Management:

   • Implement a user ID or context ID mechanism
   • Add logic to detect user changes and trigger a complete register clearing operation

3. Post-Computation Clearing:

   • Add logic to automatically clear all registers after the done signal is asserted
   • Implement a secure zeroization function that overwrites register contents with zeros or random values

4. Add Security Assertions:

   • Implement formal verification assertions to ensure all sensitive registers are cleared during context switches
   • Add runtime checks to verify register clearing operations

Code Example for Fix

// Example fix for sha_mainloop.sv - complete register clearing on reset
always @(posedge clk or posedge rst) begin
    if(rst) begin
        // Clear all state registers
        i     <= 1'b0;
        j     <= 1'bX;
        h1    <= 32'h6a09e667;
        h2    <= 32'hbb67ae85;
        h3    <= 32'h3c6ef372;
        h4    <= 32'ha54ff53a;
        h5    <= 32'h510e527f;
        h6    <= 32'h9b05688c;
        h7    <= 32'h1f83d9ab;
        h8    <= 32'h5be0cd19;

        // Clear intermediate registers - ADDED
        a     <= 32'h0;
        b     <= 32'h0;
        c     <= 32'h0;
        d     <= 32'h0;
        e     <= 32'h0;
        f     <= 32'h0;
        g     <= 32'h0;
        h     <= 32'h0;
        t1    <= 32'h0;
        t2    <= 32'h0;
        done  <= 1'b0;
    end
    // Rest of the logic remains unchanged
end

// Example addition - auto-clear after computation completes
always @(posedge clk) begin
    if (done) begin
        // Clear all sensitive registers after computation
        a     <= 32'h0;
        b     <= 32'h0;
        c     <= 32'h0;
        d     <= 32'h0;
        e     <= 32'h0;
        f     <= 32'h0;
        g     <= 32'h0;
        h     <= 32'h0;
        t1    <= 32'h0;
        t2    <= 32'h0;
    end
end

Simulation Results

The simulation was conducted using Icarus Verilog with the following steps:

1. Compilation: iverilog -g2012 -o miner_tb miner_tb.sv miner.sv sha_256.sv sha_mainloop.sv sha_padder.sv
2. Execution: vvp miner_tb
3. Output:

VCD info: dumpfile miner_tb.vcd opened for output.
VCD warning: $dumpvars: Package ($unit) is not dumpable with VCD.
Hash computation completed. Running for additional clock cycles...
Hash: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
FINISHED miner_tb after additional clock cycles
miner_tb.sv:34: $finish called at 209000 (10ps)

The simulation successfully generated the correct hash value for the Bitcoin genesis block, but critically demonstrated that sensitive register values remain accessible after computation is complete. The waveform visualization (sim.png) clearly shows that register values containing sensitive cryptographic state are not cleared after the done signal is asserted.

This confirms the CWE-1239 vulnerability in the design, as sensitive information remains in hardware registers after the computation is complete and would be accessible to any subsequent user of the hardware.

References

1. CWE-1239: Failure to Clear Sensitive Information from Hardware Registers
2. FIPS 140-2: Security Requirements for Cryptographic Modules
3. NIST SP 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators
4. Hardware Security Best Practices for FPGA Designs

[unixb0y]

Wow, I'm impressed. 😄 This was honestly mostly a simulation exercise for me when I was learning Verilog. I'm not sure that I want to sink time into this old project, but I'm now super curious how you got this nerdsniped by my project specifically!

[monkins1010]

I got an E-Mail about your comment 🙃 . now your dragging everyone into it lolol.