Trezor One / Model T RDP-downgrade voltage-glitch seed extraction (Kraken Security Labs disclosure) — hardware wallets — 2020-01-31

Summary

Trezor (developed by SatoshiLabs, Czech Republic) is one of the two market-dominant hardware-wallet families along with Ledger. The Trezor One (released 2014) and Trezor Model T (released 2018) both use general-purpose STM32 microcontrollers (STM32F205 in the Trezor One; STM32F427 in the Trezor Model T) for cryptographic operations and seed storage; unlike Ledger devices, which use a dedicated Common-Criteria-certified secure element (CC EAL5+ in early Nano models; EAL6+ in later models), Trezor's design philosophy through 2014–2022 was that an open-source firmware on a general-purpose microcontroller was preferable to a closed-source secure element, even at the cost of vulnerability to certain physical-access attack classes. This trade-off is documented in Trezor's product literature and was the centerpiece of the SatoshiLabs / Kraken vulnerability disclosure exchange.

In October 2019, Kraken Security Labs (Kraken digital-asset exchange's internal hardware-security research team) discovered that the STM32 microcontroller's Read Protection (RDP) feature could be downgraded from RDP2 (full read protection — flash and SRAM contents inaccessible via debugging interfaces) to RDP1 (partial protection — flash protected but SRAM accessible via the ARM SWD debugging protocol) by voltage glitching the microcontroller during the boot-up sequence. With the device at RDP1, the SRAM contents — including the encrypted seed phrase loaded into SRAM at PIN-entry time — could be read out over the debugging interface. The full attack required approximately 15 minutes of physical access to the device and modest hardware-hacking equipment (a voltage-glitching apparatus consisting of a programmable power supply, an oscilloscope, and the ARM SWD debugging cable).

Kraken Security Labs responsibly disclosed the vulnerability to SatoshiLabs on 2019-10-30. The coordinated-disclosure window allowed Trezor time to assess the structural nature of the vulnerability and draft a public response. The vulnerability was public-disclosed on 2020-01-31 alongside Trezor's response blog post titled "Our Response to the Read Protection Downgrade Attack."

Trezor's response acknowledged the vulnerability and characterised it as structural rather than patchable — the underlying STM32 microcontroller flaw is in the silicon, not in the firmware, and there is no firmware-update path that closes the RDP-downgrade attack class. Trezor's response emphasised three points:

• The realised threat model is bounded by physical-access requirements (15 minutes of hands-on time + voltage-glitching equipment) — only a small fraction of crypto users (Trezor cited "<6%" at the time) considered physical-access attacks within their threat model.
• The BIP39 passphrase feature — an optional 25th-word equivalent that the user enters at wallet-unlock time, which is not stored on the device's flash memory but is required to derive the working wallet — provides structural mitigation: an attacker who extracts the seed via the RDP-downgrade attack obtains a seed that, without the passphrase, opens an empty decoy wallet; the actual holdings live behind the passphrase-derived wallet and are not extractable from the device.
• Future Trezor products would ship with a dedicated secure element addressing the underlying hardware vulnerability — this commitment was realised in the Trezor Safe 3 (2023) and Trezor Safe 5 (2024) which use EAL6+ certified secure elements alongside the open-source application processor in a hybrid architecture.

For OAK's purposes the case is the cleanest capability anchor in the public record for the physical-access hardware-side seed-extraction threat class. No public-record victim has been forensically attributed to in-the-wild exploitation of the RDP-downgrade attack class — the threat-model concentration on hardware-hacking-equipped attackers with 15 minutes of hands-on access is operationally narrow. But the case is a load-bearing defender-side capability anchor: it documents that the physical-access threat model is real, it documents the BIP39 passphrase as the structural mitigation, and it documents the vendor's acknowledgment of the structural-versus-patchable distinction. The case is the canonical worked example for the capability dimension of the proposed T11.x hardware-wallet-supply-chain / physical-access compromise sub-class; deployed-attack worked examples in the same sub-class (counterfeit-Ledger-Nano-S-Plus 2025, pre-seeded recovery-card scams) cover the deployed-attack dimension.

Timeline (UTC)

When	Event	OAK ref
2014	Trezor One released; STM32F205 microcontroller; open-source firmware design philosophy	(latent surface — pre-disclosure baseline)
2018	Trezor Model T released; STM32F427 microcontroller; same open-source-firmware-on-general-purpose-microcontroller architecture	(latent surface — pre-disclosure baseline continues)
2019-10-30	Kraken Security Labs responsibly discloses the RDP-downgrade voltage-glitch attack to SatoshiLabs	(research disclosure to vendor — coordinated-vulnerability-disclosure window opens)
2019-11 to 2020-01	Coordinated-vulnerability-disclosure window; SatoshiLabs assesses structural nature of vulnerability; drafts response	(vendor-side response preparation)
2020-01-31	Public disclosure: Kraken Security Labs publishes attack details; Trezor / SatoshiLabs publishes response blog post; both parties' content lands concurrently	T11.x capability anchor — public record
2020-01-31 onward	Trezor recommends BIP39 passphrase feature as the structural mitigation for users with physical-access threat models	(defender-side mitigation surface published)
2020 onward	The Trezor One and Model T install base remains vulnerable to the RDP-downgrade attack class — the underlying STM32 microcontroller flaw is structural, not patchable	(open vulnerability state)
2023	Trezor Safe 3 released; EAL6+ secure element addresses the underlying hardware vulnerability	(vendor-side hardware-revision mitigation)
2024	Trezor Safe 5 released; same EAL6+ secure element architecture	(vendor-side hardware-revision mitigation continues)
Continuing	Trezor One / Model T at v0.1 reporting horizon (May 2026) remain vulnerable to the RDP-downgrade attack class; BIP39 passphrase remains the structural mitigation; no public-record in-the-wild exploitation of the attack class	(open capability surface)

What defenders observed

• The physical-access threat model is operationally distinct from the software-attack threat model and must be evaluated independently. The RDP-downgrade attack requires 15 minutes of physical access plus modest hardware-hacking equipment — a threat profile that is operationally narrow but is not zero for users with non-trivial holdings (border crossings, lost or stolen devices, household-member access, repair-shop access, hotel-room access). Defender practice for any user with non-trivial holdings on Trezor One / Model T should treat the BIP39 passphrase as mandatory rather than optional. The structural lesson is that hardware-wallet selection must be evaluated against both threat models independently — software-attack-resistance does not imply physical-access-resistance and vice versa.
• The BIP39 passphrase converts seed-extraction capability into empty-decoy-wallet outcome. The defender-side primitive that mitigates the RDP-downgrade attack is the BIP39 passphrase: a user-supplied 25th-word equivalent that is not stored on the device's flash memory and is required at wallet-unlock time to derive the working wallet. An attacker who extracts the seed via the RDP-downgrade attack obtains a seed that, without the passphrase, opens an empty decoy wallet; the actual holdings live behind the passphrase-derived wallet and are not extractable from the device. This is the cleanest example in the OAK corpus of a defender-side primitive that does not prevent the attack but bounds the realised loss to the strength of an additional secret. The structural OAK lesson generalises: defender-side primitives that bound realised loss to the strength of an additional secret (BIP39 passphrase, multisig threshold, time-locked withdrawal) are operationally distinct from primitives that prevent the attack outright (secure element, network isolation), and a layered mitigation strategy uses both classes.
• The structural-versus-patchable distinction is a recurring T11 vendor-disclosure pattern. Trezor's January 2020 response acknowledged that the underlying STM32 microcontroller flaw is in the silicon, not the firmware, and that there is no firmware-update path that closes the attack class — only a hardware revision with a different secure-element architecture would close it. This is the cleanest example in the OAK corpus of a vendor publicly acknowledging that a vulnerability is structural rather than patchable; the defender / contributor lesson is that vendor-side disclosure should be evaluated against this dimension explicitly. A vulnerability that is patchable produces a "fix shipped, install the update" defender response; a vulnerability that is structural produces a "this product class is residually vulnerable, here is the workaround / consider migration" defender response. The two responses produce different operational follow-up costs and should be reported separately.
• The capability-versus-deployed-attack distinction matters for the T11 cohort. The RDP-downgrade attack is a capability anchor — a documented attack technique with no public-record in-the-wild exploitation. Other T11 worked examples (Atomic Wallet, Bybit, WazirX) are deployed-attack anchors — documented incidents with on-chain extraction events. The two anchor classes serve different purposes: capability anchors document the threat surface and the defender mitigation; deployed-attack anchors document the realised loss and the operator-cluster attribution. The OAK convention should preserve the distinction explicitly and should treat both anchor classes as legitimate worked-example contributions to the framework.
• The vendor-side hardware-revision response is the structural long-term mitigation. Trezor's Safe 3 (2023) and Safe 5 (2024) both ship with EAL6+ secure elements addressing the underlying hardware vulnerability. The defender / Mitigations-layer lesson is that product-level migration is a real T11 mitigation surface, distinct from the firmware-update / secure-coding mitigations that dominate the software-side T11 surface. Contributors writing the OAK Mitigations layer should pre-position product-level migration as a first-class T11 control for users whose threat model includes physical-access attacks.

What this example tells contributors writing future Technique pages

• The proposed T11.x hardware-wallet-supply-chain / physical-access compromise sub-Technique needs both capability anchors and deployed-attack anchors. The Trezor RDP-downgrade case anchors the capability dimension of the proposed sub-class; deployed-attack worked examples (counterfeit-Ledger-Nano-S-Plus 2025, pre-seeded recovery-card scams) anchor the deployed-attack dimension. Contributors writing the proposed sub-Technique page should preserve the dual-anchor structure explicitly and should not collapse capability and deployed-attack anchors into a single category.
• Vendor-acknowledged research-disclosure cases are first-class OAK worked examples. The Trezor case is the cleanest v0.1 example of a vendor-acknowledged research-disclosure that produces a defender-side mitigation surface (BIP39 passphrase) and a long-term vendor-side hardware-revision response (Trezor Safe 3 / 5). Contributors writing future T11 / T9 / T13 worked examples should treat vendor-acknowledged research-disclosure cases as first-class anchors when (a) the vulnerability is structural, (b) the defender-side mitigation is documented, and (c) the vendor-side response is publicly disclosed. The OAK convention should not under-weight research-disclosure cases relative to deployed-attack cases — both are load-bearing for the framework's coverage.
• The structural-versus-patchable distinction is a load-bearing dimension of T-series worked examples. Contributors writing future worked examples should evaluate vendor-side disclosure against this dimension explicitly. A patchable vulnerability produces a defender response of "install the update"; a structural vulnerability produces a defender response of "the product class is residually vulnerable, here is the workaround / consider migration." The two responses are operationally distinct and should be reported separately.
• Defender-side primitives that bound realised loss to the strength of an additional secret are a distinct mitigation class. The BIP39 passphrase is the cleanest example. Contributors writing the OAK Mitigations layer should preserve the distinction between primitives-that-prevent-the-attack and primitives-that-bound-the-realised-loss, and should not collapse the two classes into a single "defence-in-depth" category.
• Hardware-wallet product-line evolution is a first-class T11 mitigation surface. Contributors writing future T11 worked examples involving hardware wallets should report the affected device model, the underlying microcontroller / secure-element architecture, and the vendor's product-line evolution explicitly. The Trezor One → Safe 5 evolution is the cleanest example in the OAK corpus of vendor-side hardware-revision response to a research-disclosed structural vulnerability.

Public references

• [krakentrezorrdp2020] — Kraken Security Labs, "Kraken Identifies Critical Flaw in Trezor Hardware Wallets" (January 2020); primary research-disclosure source documenting the RDP-downgrade voltage-glitch attack.
• [trezorrdpresponse2020] — Trezor / SatoshiLabs, "Our Response to the Read Protection Downgrade Attack" (January 31, 2020); primary vendor-side acknowledgment and BIP39-passphrase-mitigation reference.
• [theblocktrezorrdp2020] — The Block, "Kraken Security Labs: Hackers can exploit Trezor hardware wallets with only 15 minutes of physical access to the device" (January 2020); primary press-coverage source.
• [hacksterkrakenttrezor2020] — Hackster.io, "Kraken Security Labs Can Now Voltage Glitch Trezor Wallet Cryptocurrency Away"; secondary technical-press coverage.
• [hackadaytrezor2021] — Hackaday, "Hacking Hardware Bitcoin Wallets: Extracting The Cryptographic Seed From A Trezor"; technical write-up on the voltage-glitch hardware methodology.

Citations

Existing citation keys reused: none — this is the first OAK example in the hardware-wallet-physical-access-capability sub-class.

Proposed new BibTeX entries (added to citations.bib as part of this batch):

• [krakentrezorrdp2020] — Kraken Security Labs primary research-disclosure source.
• [trezorrdpresponse2020] — Trezor / SatoshiLabs primary vendor-acknowledgment source.
• [theblocktrezorrdp2020] — The Block primary press-coverage source.
• [hacksterkrakenttrezor2020] — Hackster.io secondary technical-press source.
• [hackadaytrezor2021] — Hackaday technical write-up.

Discussion

The Trezor RDP-downgrade voltage-glitch attack (Kraken Security Labs disclosure, 2020-01-31) is OAK's canonical v0.1 capability anchor for the physical-access hardware-side seed-extraction threat class within the proposed T11.x hardware-wallet-supply-chain / physical-access compromise sub-class. The case is operationally instructive in three distinct dimensions: (a) it cleanly separates the physical-access threat model from the software-attack threat model and demonstrates that hardware-wallet selection must be evaluated against both independently; (b) it demonstrates the BIP39 passphrase as the structural defender-side primitive that converts seed-extraction capability into empty-decoy-wallet outcome; (c) it provides the cleanest v0.1 example of vendor-acknowledged structural-versus-patchable vulnerability disclosure with a long-term hardware-revision mitigation surface.

The structural significance for the T11 framework is the empirical demonstration that the physical-access threat model is a first-class T11 surface that the v0.1 T11.001 / T11.002 / T11.003 sub-Techniques do not currently cover. The dominant v0.1 T11 surface is software / network attacks against signing-vendor UI (T11.001), wallet-software distribution (T11.002), and in-use multisig contracts (T11.003); the physical-access surface — represented at v0.1 by the Trezor RDP-downgrade case (capability anchor), the counterfeit-Ledger-Nano-S-Plus 2025 case (deployed-attack anchor), and the pre-seeded-recovery-card-scam cohort (deployed-attack anchor) — is structurally distinct and warrants explicit T11.x sub-Technique coverage.

The capability-versus-deployed-attack distinction is the cleanest analytical contribution of this case. Many crypto-security threat classes are well-characterised in research / vendor-advisory literature without a corresponding deployed-attack incident. The OAK convention should preserve the distinction explicitly: capability anchors document the threat surface and the defender mitigation; deployed-attack anchors document the realised loss and the operator-cluster attribution. The Trezor RDP-downgrade case is OAK's cleanest v0.1 capability anchor; future OAK worked examples in the same sub-class (or in adjacent sub-classes — e.g., side-channel attacks on secure elements; SRAM remanence; cold-boot attacks) should follow the capability-anchor structure where the vulnerability is research-disclosed without deployed-attack data.

The BIP39 passphrase as a defender-side primitive deserves special attention as a Mitigations-layer-class example. The primitive does not prevent the RDP-downgrade attack — the seed is still extractable — but it bounds the realised loss to the strength of an additional user-supplied secret. The structural OAK lesson generalises: defender-side primitives that bound realised loss to the strength of an additional secret (BIP39 passphrase, multisig threshold, time-locked withdrawal, second-factor authentication on signing) are operationally distinct from primitives that prevent the attack outright (secure element, network isolation). A layered mitigation strategy uses both classes, and the OAK Mitigations layer should preserve the distinction.

The Trezor One / Model T install base at v0.1 reporting horizon (May 2026) remains residually vulnerable to the RDP-downgrade attack class — the underlying STM32 microcontroller flaw is structural and there is no firmware-update path that closes it. The defender-side workaround (BIP39 passphrase) remains in place; the long-term vendor-side mitigation (migration to Trezor Safe 3 / Safe 5 with EAL6+ secure elements) is available but optional for users who do not actively migrate. Contributors maintaining this worked example post-v0.1 should treat the residual-vulnerability state as live and should report any further deployed-attack cases that may emerge in the in-the-wild exploitation history of the attack class.

For OAK's broader credibility, including the Trezor RDP-downgrade case in v0.1 closes a structural gap: the physical-access hardware-side threat surface is otherwise represented in the v0.1 T11 corpus only by deployed-attack cases (counterfeit hardware, pre-seeded recovery cards) without a clean capability anchor. This case operationalises the capability-anchor structure into a live empirical reference, anchors the architectural distinction between physical-access and software-attack threat models, and provides contributors writing future T11.x physical-access worked examples with a tone-and-structure precedent for capability-anchor framing.