Description
The product uses a hardware module implementing a cryptographic algorithm that writes sensitive information about the intermediate state or results of its cryptographic operations via one of its output wires (typically the output port containing the final result).
Potential Impact
Confidentiality
Read Memory, Read Application Data
Demonstrative Examples
01 | module crypto_core_with_leakage
02 | (
03 | input clk,
04 | input rst,
05 | input [127:0] data_i,
06 | output [127:0] data_o,
07 | output valid
08 | );
09 |
10 | localparam int total_rounds = 10;
11 | logic [3:0] round_id_q;
12 | logic [127:0] data_state_q, data_state_d;
13 | logic [127:0] key_state_q, key_state_d;
14 |
15 | crypto_algo_round u_algo_round (
16 | .clk (clk),
17 | .rst (rst),
18 | .round_i (round_id_q ),
19 | .key_i (key_state_q ),
20 | .data_i (data_state_q),
21 | .key_o (key_state_d ),
22 | .data_o (data_state_d)
23 | );
24 |
25 | always @(posedge clk) begin
26 | if (rst) begin
27 | data_state_q <= 0;
28 | key_state_q <= 0;
29 | round_id_q <= 0;
30 | end
31 | else begin
32 | case (round_id_q)
33 | total_rounds: begin
34 | data_state_q <= 0;
35 | key_state_q <= 0;
36 | round_id_q <= 0;
37 | end
38 |
39 | default: begin
40 | data_state_q <= data_state_d;
41 | key_state_q <= key_state_d;
42 | round_id_q <= round_id_q + 1;
43 | end
44 | endcase
45 | end
46 | end
47 |
48 | assign valid = (round_id_q == total_rounds) ? 1'b1 : 1'b0;
49 |
50 | assign data_o = data_state_q;
51 |
52 | endmodule01 | module crypto_core_without_leakage
02 | (
03 | input clk,
04 | input rst,
05 | input [127:0] data_i,
06 | output [127:0] data_o,
07 | output valid
08 | );
09 |
10 | localparam int total_rounds = 10;
11 | logic [3:0] round_id_q;
12 | logic [127:0] data_state_q, data_state_d;
13 | logic [127:0] key_state_q, key_state_d;
14 |
15 | crypto_algo_round u_algo_round (
16 | .clk (clk),
17 | .rst (rst),
18 | .round_i (round_id_q ),
19 | .key_i (key_state_q ),
20 | .data_i (data_state_q),
21 | .key_o (key_state_d ),
22 | .data_o (data_state_d)
23 | );
24 |
25 | always @(posedge clk) begin
26 | if (rst) begin
27 | data_state_q <= 0;
28 | key_state_q <= 0;
29 | round_id_q <= 0;
30 | end
31 | else begin
32 | case (round_id_q)
33 | total_rounds: begin
34 | data_state_q <= 0;
35 | key_state_q <= 0;
36 | round_id_q <= 0;
37 | end
38 |
39 | default: begin
40 | data_state_q <= data_state_d;
41 | key_state_q <= key_state_d;
42 | round_id_q <= round_id_q + 1;
43 | end
44 | endcase
45 | end
46 | end
47 |
48 | assign valid = (round_id_q == total_rounds) ? 1'b1 : 1'b0;
49 |
50 | assign data_o = (valid) ? data_state_q : 0;
51 |
52 | endmoduleMitigations & Prevention
Designers/developers should add or modify existing control flow logic along any data flow paths that connect "sources" (signals with intermediate cryptographic state/results) with "sinks" (hardware module outputs and other signals outside of trusted cryptographic zone). The control flow logic should only allow cryptographic results to be driven to "sinks" when appropriate conditions are satisfied (typically when the fin
Designers/developers should add or modify existing control flow logic along any data flow paths that connect "sources" (signals with intermediate cryptographic state/results) with "sinks" (hardware module outputs and other signals outside of trusted cryptographic zone). The control flow logic should only allow cryptographic results to be driven to "sinks" when appropriate conditions are satisfied (typically when the fin
Detection Methods
- Automated Static Analysis - Source Code High — Automated static analysis can find some instances of this weakness by analyzing source register-transfer level (RTL) code without having to simulate it or analyze it with a formal verification engine. Typically, this is done by building a model of data flow and control fl
- Simulation / Emulation High — Simulation/emulation based analysis can find some instances of this weakness by simulating source register-transfer level (RTL) code along with a set of assertions that incorporate the simulated values of relevant design signals. Typically, these assertions will capture d
- Formal Verification High — Formal verification can find some instances of this weakness by exhaustively analyzing whether a given assertion holds true for a given hardware design specified in register-transfer level (RTL) code. Typically, these assertions will capture desired or undesired behavior.
- Manual Analysis Opportunistic — Manual analysis can find some instances of this weakness by manually reviewing relevant lines of source register-transfer level (RTL) code to detect potentially-vulnerable patterns. Typically, the reviewer will trace the sequence of assignments that connect "sources" (sig
Related Weaknesses
Frequently Asked Questions
What is CWE-1431?
CWE-1431 (Driving Intermediate Cryptographic State/Results to Hardware Module Outputs) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product uses a hardware module implementing a cryptographic algorithm that writes sensitive information about the intermediate state or results of its cryptographic operations via one of i...
How can CWE-1431 be exploited?
Attackers can exploit CWE-1431 (Driving Intermediate Cryptographic State/Results to Hardware Module Outputs) to read memory, read application data. This weakness is typically introduced during the Implementation phase of software development.
How do I prevent CWE-1431?
Key mitigations include: Designers/developers should add or modify existing control flow logic along any data flow paths that connect "sources" (signals with intermediate cryptographic state/result
What is the severity of CWE-1431?
CWE-1431 is classified as a Base-level weakness (Medium abstraction). Its actual severity depends on the specific context and how the weakness manifests in your application.