Trezor One and Model T Crackable in 15 Minutes via $75 Glitch Attack

Kraken Security Labs disclosed a hardware-level vulnerability affecting both the Trezor One and Trezor Model T that allows a physical attacker to extract an encrypted seed in as little as 15 minutes – and the research team estimates the necessary glitching equipment could eventually be mass-produced and sold for roughly $75.

The Mechanics of the Attack

The exploit is built on a two-stage voltage glitch attack targeting the STM32F205 and STM32F427 microcontrollers used in Trezor’s devices. In the first stage, a precisely timed voltage fault applied at approximately 170 microseconds into the chip’s BootROM execution downgrades the device’s Read Protection level from RDP Level 2 – which blocks all debug interfaces – to RDP Level 1, re-enabling the JTAG and SWD debugging channels. A second glitch, timed to coincide with the BootROM bootloader’s RDP check at roughly 180 microseconds, bypasses the RDP level check so the read-memory command succeeds, allowing arbitrary flash reads of up to 256 bytes per command.

The underlying problem is structural: the STM32 family stores all non-volatile data, including cryptographic seeds, in flash memory, and the RDP mechanism is itself stored in flash. That design means voltage faulting the boot sequence can corrupt the protection-level value before application code ever runs, leaving no firmware-level countermeasure that can reliably block the attack. Kraken Security Labs noted explicitly that the STM32F2 and STM32F4 families were not designed for secret storage, and that any wallet relying solely on them for seed security is operating on a flawed assumption.

Once flash contents are dumped, the PIN protection offers little resistance. Kraken Security Labs developed a brute-force script using Python’s pycryptodome library that, running on a single-core CPU, achieves roughly 85 hashes per second – enough to crack any 4-digit PIN in under two minutes. The encrypted seed is protected by a 1-to-9 digit PIN, but is trivial to brute force once the flash contents have been extracted, because the salt, Encrypted Data Encryption Key, Encrypted Storage Authentication Key, and PIN verification code are all recoverable from two successful flash reads.

Hardware Design Cannot Be Patched

The disclosure, which Kraken Security Labs says was communicated to the Trezor team on October 30, 2019, carries a qualifier that matters for retail self-custody holders: the flaw is in the microcontroller silicon, not the firmware. Trezor cannot push an update that resolves this. A full hardware redesign using a chip architected for secret storage – such as a dedicated secure element – would be required to close the attack surface.

The same vulnerability extends to KeepKey and other derivatives of the Trezor One, because those devices use the same STM32F205. Prior research, including the Wallet.Fail presentation at the 35th Chaos Communication Congress and subsequent work by Ledger Donjon, had demonstrated related glitching techniques, but the full details had not been made public before this disclosure. This marks the first time the detailed steps for a current attack against these devices has been publicly disclosed, a distinction that raises the threat’s effective risk level for any device already in circulation.

Pavol Rusnak, CTO of SatoshiLabs, the company behind Trezor, expressed appreciation for the coordinated research, saying the company was happy that Kraken Security Labs was investing resources in improving the security of the whole Bitcoin ecosystem and that it valued this kind of responsible disclosure and cooperation. Kraken coordinated the release with the Trezor team so that the crypto community could protect themselves before a fix is released.

What Self-Custody Holders Should Do Now

The attack requires physical access to the device – an attacker needs roughly 15 minutes of hands-on time, the ability to solder or use a socket setup for the microcontroller, and either custom glitching hardware or an off-the-shelf FPGA development board such as the Digilent Arty A7 used in the Kraken lab setup. That physical access requirement is a meaningful barrier in most threat models, but it is not a complete defence for high-value holdings or for devices that travel frequently.

Kraken suggested two immediate steps to protect yourself. First, do not allow anyone physical access to your Trezor wallet, as you could permanently lose your crypto. Second, enable a BIP39 passphrase via the Trezor client. The passphrase is never stored on the device and is therefore a protection that prevents this attack. Because the passphrase is not stored on the device, an attacker who extracts the encrypted seed and cracks the PIN still cannot access funds without it. The BIP39 passphrase workflow adds friction to routine use, but for holdings where physical theft is a plausible scenario, it is the recommended protection layer available until a hardware redesign ships.

The Kraken finding reinforces a structural point that hardware wallet manufacturers and security teams have been slow to operationalise: chips selected for cost, peripheral support, and development toolchain compatibility – criteria that describe the entire STM32 family – carry security trade-offs that can be exploited when an attacker has controlled physical access and modest hardware investment. The gap between a device that handles cryptographic operations and a device built around a certified secure element is not academic; it determines whether a glitch attack that takes 15 minutes and $75 of equipment is inside or outside a realistic adversary’s capability envelope.

What Comes Next

The immediate watch item is whether Trezor accelerates a hardware revision that migrates away from the STM32 family. A hardware fix resolves the chip-level flaw; a firmware update cannot. In the interim, enabling a BIP39 passphrase with the Trezor client is a recommended mitigation for current device holders, and Trezor has confirmed that a strong passphrase fully mitigates the possibilities of a successful attack.

The second follow-on worth tracking is whether the disclosure accelerates independent certification requirements for hardware wallet microcontrollers – a gap that security researchers and affected firms have increasingly framed as a software supply-chain and QA failure rather than a one-off defect. The market will be forced to price the difference between devices built on certified secure elements and those relying on general-purpose microcontrollers once the number and severity of these disclosures reaches a threshold that retail buyers can no longer absorb as edge cases.