Driving Intermediate Cryptographic State/Results to Hardware Module Outputs

Description

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.

Extended Description

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.

Common Consequences 1

Scope: Confidentiality

Impact: Read MemoryRead 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.

Detection Methods 4

Automated Static Analysis - Source CodeHigh

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 / EmulationHigh

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 VerificationHigh

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 AnalysisOpportunistic

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.

Potential Mitigations 2

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

Effectiveness: High

Phase: Implementation

Effectiveness: High

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

Code Example:

Bad

Verilog

01 | module crypto_core_with_leakage 02 | (

verilog

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.

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

Code Example:

Good

Verilog

01 | module crypto_core_without_leakage 02 | (

verilog

References 5

OpenTitan issue: [otp_ctrl] Prevent broadcast of scrambler's input/intermediate values #13043

Andres Meza

03-06-2022

https://github.com/lowRISC/opentitan/pull/13043(2025-04-02)

ID: REF-1469

Security Verification of the OpenTitan Hardware Root of Trust

Andres Meza, Francesco Restuccia, Jason Oberg, Dominic Rizzo, and Ryan Kastner

20-04-2023

https://ieeexplore.ieee.org/document/10106105(2025-04-02)

ID: REF-1470

Security Verification of an Open Source Hardware Root of Trust

Jason Oberg

03-08-2022

https://cycuity.com/type/blog/security-verification-of-an-open-source-hardware-root-of-trust/(2025-04-02)

ID: REF-1471

Complete reverse-engineering of AES-like block ciphers by SCARE and FIRE attacks

Christophe Clavier, Quentin Isorez, Damien Marion, and Antoine Wurcker

23-10-2014

https://doi.org/10.1007/s12095-014-0112-7(2025-04-02)

ID: REF-1472

Practical Reverse Engineering of Secret Sboxes by Side-Channel Analysis

Dirmanto Jap and Shivam Bhasin

10-2020

https://doi.org/10.1109/ISCAS45731.2020.9180848(2025-04-02)

ID: REF-1473