This article describes the layers of protection used to protect Trezor from potential security threats. Scroll through the article or see the contents to search for a specific threat.
- 1 Phishing
- 2 Brute forcing the Trezor PIN
- 3 Reflashing the Trezor with malicious firmware
- 4 Evil maid attack - replacing Trezor with a fake
- 5 Stealing the user's computer
- 6 Hacking SatoshiLabs servers
- 7 SatoshiLabs shutting down
- 8 Running the recovery process on an infected computer
- 9 Side channel attacks
If you wish to make a payment to someone on the internet, you need to know their receiving address. Unlike Trezor, computers are not necessarily secure, and it is possible that the address displayed on your screen is maliciously modified.
To be sure, always check the receiving address on your Trezor device screen as well (see Receiving payments). To be extra safe, we recommend confirming the recipient's address using an additional second channel, such as SMS, phone call, or a face-to-face meeting.
Brute forcing the Trezor PIN
Trezor is protected by a PIN code, which can be up to nine digits long. If a good PIN is selected, it would take hundreds of thousands of attempts to get it right. Every time a wrong PIN is entered, the waiting time between the attempts increases by a power of two. The device automatically wipes itself after 16 unsuccessful attempts.
In case you lost your PIN, see You have forgotten or lost your PIN.
Reflashing the Trezor with malicious firmware
Official Trezor firmware is signed by the SatoshiLabs master key. Installing unofficial firmware on the Trezor is possible, but doing so will wipe the device storage, and Trezor will show a warning every time it starts.
Evil maid attack - replacing Trezor with a fake
It might be possible for a malicious third party to steal your Trezor and replace it with a fake one. If embedded with a wireless transmitter, the fake Trezor could transmit any PIN it received. The attacker would then have full access to your funds.
If you are concerned about such an attack, it is a good idea to sign the back of your Trezor with a permanent pen. Do not forget to check the signature before each use. You can also set a custom home screen (see Homescreen) with a unique picture that would be hard to copy or fake.
The Trezor chassis is sealed using ultrasound. Opening Trezor without destroying the case is nearly impossible.
Stealing the user's computer
If the user's computer gets stolen, it does not affect the safety of his or her funds. The Trezor device can be used with a different computer. It is not possible to access the user's funds from the stolen computer without the Trezor device itself.
Hacking SatoshiLabs servers
SatoshiLabs takes security very seriously, so this option is extremely improbable. However, you do not need to rely on SatoshiLabs servers at all. For more information see Running a local instance of Trezor Wallet and Running a local instance of Trezor Wallet backend (Blockbook).
SatoshiLabs shutting down
There are no such plans because we love cryptocurrencies, but even if we had to close down, there is nothing to worry about. Trezor is compatible with other BIP32, BIP39 and BIP44 compatible wallets. Since our code is publicly available, developers from around the world can maintain it and add new functionalities. In extreme cases (although this is not recommended), it is possible to use the recovery seed to recover your funds in a different wallet as well.
Running the recovery process on an infected computer
Even if your computer has a key-logger installed on it and the randomly ordered words are stolen, it would take many many years to crack the order of the actual seed even with the most powerful computer.
Moreover, on Trezor Model T, the seed words are entered on the Trezor device itself, so there is no danger of key-logging by an infected computer. With Trezor One, you can always use the Advanced recovery to avoid malicious computers.
Side channel attacks
Side channel attacks described by Jochen Hoenicke were fixed by rewriting all crypto functions to use constant time. Jochen did almost all of the fixing, and we have been collaborating ever since on various security and non-security related improvements. Furthermore, we ask for the user's PIN before every operation involving a private key (e.g., generating the public key), so even if there were some side channel attacks left, the attacker would still need to know the PIN to trigger it.