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 flow, then searching for potentially-vulnerable patterns that connect "sources" (signals with intermediate cryptographic state/results) with "sinks" (hardware module outputs and other signals outside of trusted cryptographic zone) without any control flow.
CWE-1431 Base Incomplete
Driving Intermediate Cryptographic State/Results to Hardware Module Outputs
This vulnerability occurs when a hardware cryptographic module leaks sensitive internal data through its output channels. Instead of only providing the final encrypted or decrypted result, the…
Definition
What is CWE-1431?
This vulnerability occurs when a hardware cryptographic module leaks sensitive internal data through its output channels. Instead of only providing the final encrypted or decrypted result, the module inadvertently exposes intermediate calculation states or partial results via its output wires or ports.
Hardware cryptographic modules are designed to perform operations like encryption or hashing in discrete steps. During normal operation, they generate temporary, sensitive data as part of these calculations—such as partial cipher states, round keys, or intermediate hash values. When a module is poorly designed or configured, these internal values can be mistakenly routed to the same physical output pins or interfaces intended for the final result, creating a direct information leak.
For developers and security architects, this means that even if the cryptographic algorithm itself is sound, the hardware implementation can undermine security. Attackers monitoring the output port can capture these intermediate values, which often contain enough information to reconstruct secret keys or bypass cryptographic protections. This flaw highlights the critical need to validate that hardware modules only expose finalized, intended outputs and that all internal computational states remain physically isolated within the chip's secure boundaries.
Real-world impact
Real-world CVEs caused by CWE-1431
No public CVE references are linked to this CWE in MITRE's catalog yet.
How attackers exploit it
Step-by-step attacker path
- 1
The following SystemVerilog code is a crypto module that takes input data and encrypts it by processing the data through multiple encryption rounds. Note: this example is derived from [REF-1469].
- 2
In line 50 above, data_state_q is assigned to data_o. Since data_state_q contains intermediate state/results, this allows an attacker to obtain these results through data_o.
- 3
In line 50 of the fixed logic below, while "data_state_q" does not contain the final result, a "sanitizing" mechanism drives a safe default value (i.e., 0) to "data_o" instead of the value of "data_state_q". In doing so, the mechanism prevents the exposure of intermediate state/results which could be used to break soundness of the cryptographic operation being performed. A real-world example of this weakness and mitigation can be seen in a pull request that was submitted to the OpenTitan Github repository [REF-1469].
Vulnerable code example
Vulnerable Verilog
The following SystemVerilog code is a crypto module that takes input data and encrypts it by processing the data through multiple encryption rounds. Note: this example is derived from [REF-1469].
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 | endmodule Secure code example
Secure Verilog
In line 50 of the fixed logic below, while "data_state_q" does not contain the final result, a "sanitizing" mechanism drives a safe default value (i.e., 0) to "data_o" instead of the value of "data_state_q". In doing so, the mechanism prevents the exposure of intermediate state/results which could be used to break soundness of the cryptographic operation being performed. A real-world example of this weakness and mitigation can be seen in a pull request that was submitted to the OpenTitan Github repository [REF-1469].
01 | 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 | endmodule What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-1431
- 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".
Detection signals
How to detect CWE-1431
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 desired or undesired behavior. Analysis can be improved by using simulation-based information flow tracking (IFT) to more precisely detect unexpected results.
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. For this weakness, an assertion should check for undesired behavior in which one output is a signal that captures when a cryptographic algorithm has completely finished; another output is a signal with intermediate cryptographic state/results; and there is an assignment to a hardware module output or other signal outside of a trusted cryptographic zone. Alternatively, when using a formal IFT verification, the same undesired behavior can be detected by checking if computation results can ever leak to an output when the cryptographic result is not copmlete.
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" (signals with intermediate cryptographic state/results) with "sinks" (hardware module outputs and other signals outside of trusted cryptographic zone). If this sequence of assignments is missing adequate control flow, then the weakness is likely to exist.
Plexicus auto-detects CWE-1431 and opens a fix PR in under 60 seconds.
Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.
Frequently asked questions What is CWE-1431?
How serious is CWE-1431?
What languages or platforms are affected by CWE-1431?
How can I prevent CWE-1431?
How does Plexicus detect and fix CWE-1431?
Where can I learn more about CWE-1431?
Frequently asked questions
What is CWE-1431?
This vulnerability occurs when a hardware cryptographic module leaks sensitive internal data through its output channels. Instead of only providing the final encrypted or decrypted result, the module inadvertently exposes intermediate calculation states or partial results via its output wires or ports.
How serious is CWE-1431?
MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.
What languages or platforms are affected by CWE-1431?
MITRE lists the following affected platforms: Not Architecture-Specific, System on Chip.
How can I prevent CWE-1431?
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…
How does Plexicus detect and fix CWE-1431?
Plexicus's SAST engine matches the data-flow signature for CWE-1431 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-1431?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/1431.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-1431
CWE-200 Parent
Exposure of Sensitive Information to an Unauthorized Actor
This weakness occurs when an application unintentionally reveals sensitive data to someone who shouldn't have access to it.
CWE-1258 Sibling
Exposure of Sensitive System Information Due to Uncleared Debug Information
This vulnerability occurs when hardware fails to erase sensitive data like cryptographic keys and intermediate values before entering…
CWE-1273 Sibling
Device Unlock Credential Sharing
This vulnerability occurs when the secret keys or passwords required to unlock a device's hidden features are shared between multiple…
CWE-1295 Sibling
Debug Messages Revealing Unnecessary Information
The product's debug messages or logs expose excessive internal system details, potentially revealing sensitive information that could aid…
CWE-201 Sibling
Insertion of Sensitive Information Into Sent Data
This vulnerability occurs when an application sends data to an external party, but accidentally includes sensitive information—like…
CWE-203 Sibling
Observable Discrepancy
This vulnerability occurs when an application responds differently to unauthorized users based on internal conditions. Attackers can…
CWE-209 Sibling
Generation of Error Message Containing Sensitive Information
This vulnerability occurs when an application reveals sensitive details about its internal systems, user data, or environment within error…
CWE-213 Sibling
Exposure of Sensitive Information Due to Incompatible Policies
This vulnerability occurs when a system's data handling aligns with the developer's security rules but accidentally reveals information…
CWE-215 Sibling
Insertion of Sensitive Information Into Debugging Code
This vulnerability occurs when developers embed sensitive data, such as passwords or API keys, within debugging statements like logs or…
Resources
Further reading
- MITRE — official CWE-1431 https://cwe.mitre.org/data/definitions/1431.html
- OpenTitan issue: [otp_ctrl] Prevent broadcast of scrambler's input/intermediate values #13043 https://github.com/lowRISC/opentitan/pull/13043
- Security Verification of the OpenTitan Hardware Root of Trust https://ieeexplore.ieee.org/document/10106105
- Security Verification of an Open Source Hardware Root of Trust https://cycuity.com/type/blog/security-verification-of-an-open-source-hardware-root-of-trust/
- Complete reverse-engineering of AES-like block ciphers by SCARE and FIRE attacks https://doi.org/10.1007/s12095-014-0112-7
- Practical Reverse Engineering of Secret Sboxes by Side-Channel Analysis https://doi.org/10.1109/ISCAS45731.2020.9180848
Ready when you are
Don't Let Security
Weigh You Down.
Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.