Potential Bypass of Firmware Verification by Laser Fault Injection

Jun 3, 2026

security@tropicsquare.com

Abstract

In this post, we describe the TROPIC01 vulnerability enabled by laser fault injection (LFI), which can be used to bypass EdDSA (Ed25519) signature verification during authenticated FW updates and secure boot. The vulnerability enables adversary firmware execution: we describe the context, the attack vector, mitigations and we assess the related risk. The vulnerability has been responsibly disclosed to Tropic Square by the Ledger Donjon in an exemplary manner.

All production versions of TROPIC01 in the field are affected. Tropic Square business partners were contacted in advance, in line with the Coordinated Vulnerability Disclosure procedure to allow them to take appropriate measures.

‍

Intro

TROPIC01 comes with two programmable processor cores: the main RISC-V CPU is responsible for orchestrating TROPIC01 functionality and communication (L2/L3 command API), while the SPECT coprocessor (ECC engine) assists the main CPU with Elliptic Curve Cryptography. Firmware (FW) for both cores is stored in nonvolatile memory (ROM or Flash/R-Memory), but it is executed from RAM and ROM, not directly from flash memory.

TROPIC01 is equipped with three types of firmware:

The immutable FW (bootloader) stored in ROM runs primarily on the RISC-V CPU after power-up and is responsible for updating or booting the mutable firmware. It contains a small portion of the SPECT coprocessor code that supports signature verification in the bootloader.
The mutable RISC-V FW (CPU FW) is updatable firmware stored in flash memory and executed on the RISC-V CPU from RAM.
The mutable SPECT coprocessor (ECC engine) FW is updatable firmware stored in flash memory and executed on the SPECT coprocessor from RAM.

The attack demonstrated by Ledger Donjon exploits a weakness in the immutable FW (bootloader) allowing an attacker to load and execute arbitrary (mutable) RISC-V and/or SPECT FW in a laboratory environment.

‍

The Secure Boot Trust Chain

A bootloader public key burned into the TROPIC01 ROM, together with the bootloader private key, forms an immutable Root of Trust for the boot chain. The TROPIC01 bootloader private key is in the possession of Tropic Square and is stored in an offline perimeter [ODN_TR01_app_007_fw_update_1v5].

TROPIC01’s irreversible memory (antifuse I-memory) contains a vendor public key signed by the bootloader private key. On each power-up, the bootloader first verifies the signature of the vendor public key. The TROPIC01 vendor private key is in the possession of Tropic Square (for standard TROPIC01 batches) and is stored in the offline perimeter [ODN_TR01_app_007_fw_update_1v5].

TROPIC01 FW (both the CPU and SPECT FW) is authenticated and checked for integrity via digital signatures. The FW is signed by the vendor private key.

‍

The FW Update Process

The FW update process for TROPIC01 is initiated from Maintenance Mode and involves several steps to ensure the authenticity and integrity of the firmware. The FW images for both the RISC-V CPU and SPECT coprocessor are split into chunks, which are chained into a signed chain. The chain’s authenticity and integrity are assured by a SHA-256 hash chain signed by thehe EdDSA vendor private key. To check the authenticity and integrity of the whole FW image, the EdDSA signature of the first chunk (with its hash) is verified. Subsequent chunks are compared against the trusted SHA-256 value stored in the previous chunks - see the figure below.

The TROPIC01 FW update process is also guarded by standard measures like downgrade protection, a dual-bank mechanism, and RISC-V/SPECT FW version matching. For details, see [ODN_TR01_app_007_fw_update_1v5]. It is recommended to keep both banks updated and disable maintenance mode by default [ODN_TR01_app_007_fw_update_1v5, ODR_TR01_SA_2026012900].

‍

The FW Boot Process

During regular start-up, the TROPIC01 bootloader verifies the mutable FW in both banks by loading the FW header and signature for both the RISC-V and SPECT cores. Verifying of the EdDSA signature of the FW header corresponding to the vendor key pair ensures the authenticity and integrity of the FW in each bank [ODN_TR01_app_007_fw_update_1v5]. If any check fails, the corresponding FW bank is considered invalid.

If at least one bank is valid, the bootloader selects it and proceeds to boot the mutable FW. It copies the FW binary from the selected bank to RAM and calculates the SHA-256 hash of the binary to cross-check its integrity. At the end of this process, TROPIC01 is running the mutable FW.

For a description of the boot process details, please refer to [ODN_TR01_app_007_fw_update_1v5].

‍

The Vulnerability Identification and Exploitation

TROPIC01 comes equipped with built-in measures on multiple levels, from software through hardware down to the silicon, forming a solid defense-in-depth. The vulnerability demonstrated by the Ledger Donjon is enabled by a coincidence of multiple weaknesses across multiple layers, namely: insufficient FW hardening in critical code segment and the ability to escape built-in laser detectors.

The vulnerability is enabled by the ability to inject a fault into the handshake between the RISC-V core and the SPECT coprocessor during the EdDSA computation, delivering a “valid EdDSA signature” result to the RISC-V for an invalid EdDSA signature. This requires temporal targeting, precise spatial targeting, and advanced laboratory setup tuning to both inject a fault and escape the laser sensors. This can only be performed by an advanced adversary in an equipped lab on a decapsulated chip.

The FW Update Process

To exploit the FW update process, an adversary FW must first be prepared and split into correctly SHA-256-interlinked chunks.

During the update, a fault must be injected into the first chunk's EdDSA signature verification to compromise the authenticity check of the first FW update chunk. As long as the integrity of the update chunk chain is correct, the update can successfully complete.

This process is the same for both banks and for both the RISC-V and SPECT FW. At the end of the process, the adversary FW is stored in the TROPIC01 flash memory.

The FW Boot Process

By uploading an adversary FW to the TROPIC01 flash memory, semi-persistence is gained. Although the malicious FW is present in the TROPIC01 non-volatile memory, it will never boot without further attacker intervention; thus, the attacker never gains full persistence.

During every boot, the adversary must inject a fault into the EdDSA signature verification steps of the adversary RISC-V and/or SPECT FW to allow it to boot.

‍

Assets at Risk from the Adversary Firmware

User data stored in non-volatile memory can be read out by the adversary firmware. The security boundary for user data storage is in the RISC-V firmware.

ECC keys stored in the protected flash region can be read out by the adversary SPECT FW. The security boundary for private ECC keys is in the SPECT firmware.

Ledger Donjon’s analysis deduced that the security boundary for MAC-and-Destroy slots is in hardware, as an advanced laboratory was unable to break MAC-and-Destroy protection after multiple weeks of testing. The follow-up internal analysis executed by Tropic Square has shown that the real security boundary for MAC-and-Destroy is not in hardware, disclosing a potentially exploitable architectural weakness. A deep understanding of the TROPIC01 architecture is required to exploit the MAC-and-Destroy vulnerability.

We then shared the existence of this hardware-level bypass with Ledger Donjon. Prompted by this, their team conducted further independent testing and successfully discovered a vulnerability path to compromise the hardware security boundary as well.

To protect our customers and TROPIC01 users, we are disclosing the existence of this vulnerability. While the attack vector is complex, the issue remains exploitable, so we are withholding technical details for now to temporarily reduce the risk of misuse. Full details will be published in the spring of 2027. Expected availability of the hardened TROPIC01 is scheduled for the end of 2026.

‍

The Risk Assessment

Based on the CVSS base score (version 3.1), the vulnerability is assessed as MEDIUM 5.7. However, since exploitation requires full physical access to the TROPIC01 device, along with expert knowledge, specialized equipment, and specific conditions, the overall risk is expected to be significantly lower for most applications, depending on the threat model. For details, see [ODR_TR01_SA_2026012900].

‍

Attack Mitigation

For current devices in the field, Tropic Square recommends applying the FW update protection procedure described in security advisory [ODR_TR01_SA_2026012900]. The recommended mitigation is based on disabling maintenance mode, which prevents direct access to the firmware update mechanism. The recommended mitigation does not avoid the attack vector completely, but it increases the attack complexity.

In future revisions of TROPIC01 devices (expected to be available by late 2026), additional measures aimed at preventing FW fault injection and improving sensor data handling have been implemented. Additionally, a fix for the MAC-and-Destroy vulnerability has also been implemented. These hardware updates will mitigate the exploitation of the reported vulnerability.

‍