CWE-1431 Base Incomplet

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…

Définition

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.

Impact réel

Real-world CVEs caused by CWE-1431

Aucune référence CVE publique n'est liée à ce CWE dans le catalogue MITRE pour le moment.

Comment les attaquants l'exploitent

Parcours de l'attaquant étape par étape

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].

Exemple de code vulnérable

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].

Vulnérable Verilog

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

Exemple de code sécurisé

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].

Sécurisé Verilog

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.

Liste de contrôle de prévention

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".

Signaux de détection

How to detect CWE-1431

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 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.

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 desired or undesired behavior. Analysis can be improved by using simulation-based information flow tracking (IFT) to more precisely detect unexpected results.

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. 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 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" (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.

Correction automatique Plexicus

Plexicus détecte automatiquement CWE-1431 et ouvre une PR de correction en moins de 60 secondes.

Codex Remedium analyse chaque commit, identifie cette faiblesse précise et livre une pull request prête à être relue avec le correctif. Pas de tickets. Pas de transferts.

Obtenir une démo Essayer Plexicus gratuitement

Questions fréquentes

Frequently asked questions

Qu'est-ce que CWE-1431 ?

Quelle est la gravité de CWE-1431 ?

MITRE n'a pas publié de note de probabilité d'exploitation pour cette faiblesse. Traitez-la comme un impact moyen jusqu'à ce que votre modèle de menace prouve le contraire.

Quels langages ou plateformes sont affectés par CWE-1431 ?

MITRE lists the following affected platforms: Not Architecture-Specific, System on Chip.

Comment puis-je prévenir 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…

Comment Plexicus détecte et corrige CWE-1431 ?

Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-1431 à chaque commit. Lorsqu'une correspondance est trouvée, notre agent Codex Remedium ouvre une PR de correction avec le code corrigé, les tests et un résumé d'une ligne pour le relecteur.

Où puis-je en savoir plus sur CWE-1431 ?

MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/1431.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.

Faiblesses associées

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 Frère

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 Frère

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 Frère

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 Frère

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 Frère

Observable Discrepancy

This vulnerability occurs when an application responds differently to unauthorized users based on internal conditions. Attackers can…

CWE-209 Frère

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 Frère

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 Frère

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…

Ressources

Arrêtez de payer par développeur.
Commencez à fermer la boucle.

Plexicus est l'ASPM natif IA qui scanne, filtre, corrige, penteste et explique — de façon autonome. Développeurs illimités, dépôts illimités, actions IA à usage équitable. Vrai niveau gratuit, €269/mo annuel quand vous êtes prêt.

Commencer gratuitement Réserver une démo