Our Response to the Read Protection Downgrade Attack

Spread the love

This article addresses the Read Protection (RDP) Downgrade attack discovered in both Trezor One and Trezor Model T by the Kraken Security Labs researchers on 30 October 2019. Here you can find information about how this physical attack works and how you can protect yourself against it if you’re concerned that you might be affected. In the second part of the article, we explain our threat model and say a few things about physical security.

We assume this attack might be similar to previously publicized Seed Extraction Attack by the Donjon Team. We are unable to confirm this with any certainty because the Donjon Team has not, to this day, shared the full details of the attack with us.

A closer look at the attack

The RDP Downgrade attack is a precise attack that targets the hardware vulnerability of STM32 microchips used in the Trezor One and Trezor Model T hardware wallets and their derivatives such as KeepKey.

The RDP Downgrade involves the voltage glitching of the STM32 microchip, which allows the attacker with specialized hardware, knowledge, and physical access to bypass the protection put in place by the manufacturer and extract the contents of the microcontroller’s flash memory. This way, the attacker can obtain the encrypted recovery seed from the device.

It’s important to note that this attack is viable only if the Passphrase feature does not protect the device. A strong passphrase fully mitigates the possibilities of a successful attack. If sophisticated physical attacks on your device are in your threat model, we recommend learning how to create and effectively use the passphrase protection to secure your accounts.

Step by step overview

To perform this attack, the perpetrator has to obtain your hardware wallet and physically open the casing of the device. The attack is performed directly on the STM32 microchip, which means that any affected device will show visible signs of tamper as the case sealing has to be broken.

Once the casing is open, and the microchip directly accessible, the perpetrator needs to remove the microchip of your Trezor from the original board and connect it to a specially designed hardware, let’s call it a black box, which attempts to extract the encrypted recovery seed by sending precisely timed glitches. In addition to the black box, the attacker also needs to have a computer available during the hack, as the black boxes we have seen are relatively simple and cannot be controlled directly without an external control unit. This way, the perpetrator can obtain the PIN-encrypted recovery seed, which can be afterwards decrypted with a series of brute force attacks.

If you’re interested in the full technical details of the attack, please read the latest blog post from Kraken.

The Trezor hardware wallet threat model

When we first started playing around with the idea of creating a hardware wallet, hundreds and thousands of bitcoins were disappearing from wallets regularly. The main threat for Bitcoin users were online attacks. This remains true to this day, and remote attacks are still the most significant concern of our users. Over the six years of existence of SatoshiLabs, we have dedicated a majority of our resources into mitigating remote attacks, and we have designed devices that are fully resistant to all online threats.

We always knew that all hardware is hackable and the question about physical attacks is not if they will happen, but when they will happen. Even though only a small portion of cryptocurrency users are concerned about physical attacks (<6%), we treat physical vulnerabilities with the same urgency as any remote vulnerability.

Results of Binance Security survey, December 2018. Sample of 14 471 respondents.

Probably the most significant obstacle in the development of safe hardware is the slowly evolving existing market. We built Trezor on the principles of transparency and open-source access to all parts of our products, including hardware, but there are only very few microchip manufacturers who follow the same principles. A significant portion of hardware security comes from the secrecy surrounding the processes used in the development of the microchips. These are often safeguarded by complex legal agreements requiring anyone who wants to build on these microchips to sign non-disclosure agreements and other documents protecting the “secret”.

So to protect our devices against physical attacks without compromising our principles, we invented and implemented the Passphrase feature. The passphrase itself is not stored anywhere in hardware, SatoshiLabs doesn’t possess a backup, and therefore cannot be exposed or in any way “hacked” by a third party. When it comes to the passphrase, the user is the most crucial part of the whole process as it’s up to you to decide how complex your passphrase will be, how will you store it, protect it, or whether you should use one at all.

Should I use the Passphrase feature?

The Passphrase feature is an exceptionally secure layer of active protection and an impenetrable solution against physical attacks if used properly. However, it would be best if you asked yourself a few questions before you start using the passphrase. Are you able to create a strong and memorable passphrase? Does anyone know how many bitcoins do you have? Do you possess enough bitcoins to become a worthy target? These are the questions we cannot answer for you, but if you consider physical attacks a possibility, then passphrase is something you should use.

The passphrase is by many considered an advanced feature, and it could certainly lead to loss of your coins if you don’t follow the recommended practices. The main benefit of the passphrase is that it’s not stored anywhere in the device and therefore cannot be extracted by a third-party. At the same time this brings a risk that if you lose or forget your passphrase, there’s no one to help you recover it.

Still concerned about this attack? Our friendly technical support is ready to answer all of your questions.


Our Response to the Read Protection Downgrade Attack was originally published in Trezor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read original at

Related Articles