Détail du 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).

Modes d'introduction

Implementation :

This can occur when intermediate cryptographic states are directly assigned to output wires or ports.

Plateformes applicables

Langue

Class: Not Language-Specific (Undetermined)

Architectures

Class: Not Architecture-Specific (Undetermined)

Technologies

Class: System on Chip (Undetermined)

Conséquences courantes

Mesures d’atténuation potentielles

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

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

Méthodes de détection

Automated Static Analysis - Source Code

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.

Efficacité : High

Simulation / Emulation

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.

Efficacité : High

Formal Verification

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.

Efficacité : High

Manual Analysis

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.

Efficacité : Opportunistic

Notes de cartographie des vulnérabilités

Justification : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Commentaire : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Références

REF-1469

OpenTitan issue: [otp_ctrl] Prevent broadcast of scrambler's input/intermediate values #13043
Andres Meza.
https://github.com/lowRISC/opentitan/pull/13043

REF-1470

Security Verification of the OpenTitan Hardware Root of Trust
Andres Meza, Francesco Restuccia, Jason Oberg, Dominic Rizzo, Ryan Kastner.
https://ieeexplore.ieee.org/document/10106105

REF-1471

Security Verification of an Open Source Hardware Root of Trust
Jason Oberg.
https://cycuity.com/type/blog/security-verification-of-an-open-source-hardware-root-of-trust/

REF-1472

Complete reverse-engineering of AES-like block ciphers by SCARE and FIRE attacks
Christophe Clavier, Quentin Isorez, Damien Marion, Antoine Wurcker.
https://doi.org/10.1007/s12095-014-0112-7

REF-1473

Practical Reverse Engineering of Secret Sboxes by Side-Channel Analysis
Dirmanto Jap, Shivam Bhasin.
https://doi.org/10.1109/ISCAS45731.2020.9180848

Soumission