CWE-1431: Driving Intermediate Cryptographic State/Results to Hardware Module Outputs
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).
How it's found
Driving Intermediate Cryptographic State/Results to Hardware Module Outputs is typically found by tracing untrusted input from where it enters the system to the point where it is used without the check or neutralization this weakness describes, combining manual code review with dynamic testing.
Vulnerable vs. safe
03 | input clk,04 | input rst,05 | input [127:0] data_i,06 | output [127:0] data_o,07 | output valid
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)
27 | data_state_q <= 0;28 | key_state_q <= 0;29 | round_id_q <= 0;
34 | data_state_q <= 0;35 | key_state_q <= 0;36 | round_id_q <= 0;
40 | data_state_q <= data_state_d;41 | key_state_q <= key_state_d;42 | round_id_q <= round_id_q + 1;33 | total_rounds: begin37 | end38 |39 | default: begin43 | end32 | case (round_id_q)44 | endcase26 | if (rst) begin30 | end31 | else begin45 | end01 | module crypto_core_with_leakage02 | (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 (23 | );24 |25 | always @(posedge clk) begin46 | end47 |48 | assign valid = (round_id_q == total_rounds) ? 1'b1 : 1'b0;49 |50 | assign data_o = data_state_q;51 |52 | endmodule03 | input clk,04 | input rst,05 | input [127:0] data_i,06 | output [127:0] data_o,07 | output valid08 | );
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)
27 | data_state_q <= 0;28 | key_state_q <= 0;29 | round_id_q <= 0;
34 | data_state_q <= 0;35 | key_state_q <= 0;36 | round_id_q <= 0;
40 | data_state_q <= data_state_d;41 | key_state_q <= key_state_d;42 | round_id_q <= round_id_q + 1;33 | total_rounds: begin37 | end38 |39 | default: begin43 | end32 | case (round_id_q)44 | endcase26 | if (rst) begin30 | end31 | else begin45 | end01 | module crypto_core_without_leakage02 | (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 (23 | );24 |25 | always @(posedge clk) begin46 | end47 |48 | assign valid = (round_id_q == total_rounds) ? 1'b1 : 1'b0;49 |50 | assign data_o = (valid) ? data_state_q : 0;51 |52 | endmoduleConsequences
- Read Memory, Read Application Data: Mathematically sound cryptographic algorithms rely on their correct implementation for security. These assumptions might break when a hardware crypto module leaks intermediate encryption states or results such that they can be observed by an adversary. If intermediate state is observed, it might be possible for an attacker to identify the secrets used in the cryptographic operation.
Mitigations
- Architecture and Design: 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 final result for a cryptographic operation has been generated). When the appropriate conditions are not satisfied (i.e., before or during a cryptographic operation), the control flow logic should drive a safe default value to "sinks".
- Implementation: 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 final result for a cryptographic operation has been generated). When the appropriate conditions are not satisfied (i.e., before or during a cryptographic operation), the control flow logic should drive a safe default value to "sinks".
Where this fits in a TurboPentest engagement
This weakness is not covered by the automated black-box pentest. IntegSec pentesters cover it in a manual engagement.
Frequently asked questions
What is CWE-1431?
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).
How do you find Driving Intermediate Cryptographic State/Results to Hardware Module Outputs?
Driving Intermediate Cryptographic State/Results to Hardware Module Outputs is typically found by tracing untrusted input from where it enters the system to the point where it is used without the check or neutralization this weakness describes, combining manual code review with dynamic testing.
What is the impact of CWE-1431?
Read Memory, Read Application Data: Mathematically sound cryptographic algorithms rely on their correct implementation for security. These assumptions might break when a hardware crypto module leaks intermediate encryption states or results such that they can be observed by an adversary. If intermediate state is observed, it might be possible for an attacker to identify the secrets used in the cryptographic operation.
Does TurboPentest test for Driving Intermediate Cryptographic State/Results to Hardware Module Outputs?
This weakness is not covered by the automated black-box pentest. IntegSec pentesters cover it in a manual engagement.
Related CWEs
Written and reviewed by
Michel Chamberland - Founder & CEO, IntegSec
CISSP, OSCP, OSCE, CEH, GIAC, CCSK · 20+ years in offensive security
Michel has spent 20+ years on offensive security teams including IBM X-Force Red and Trustwave SpiderLabs, leading penetration tests, red team engagements, and breach response for Fortune 500 customers. He is the founder of IntegSec and the architect of TurboPentest.
Find these issues before an attacker does
TurboPentest runs an agentic AI pentest against your target and reports findings with proof, from $99 per target.
Start a pentest