In line with our transparency policy, we are publishing a comprehensive list of all the past security issues of Trezor and our related services.
The bootloader verifies the firmware signature. The device only runs if the firmware is correctly signed by SatoshiLabs. Otherwise, the Trezor warns you.
Trezor hardware case is ultrasonically welded, making it difficult to be restored after breakage.
Operations with private and public keys are only allowed after user authentication via PIN.
The bootloader erases memory on firmware update and restores it only if the firmware signature is valid. Downgrade wipes the memory.
Trezor supports BIP39 passphrases, which are never stored or remembered on the device.
The bootloader is write protected, as the JTAG is disabled. MCU is safeguarded by the Memory Protection Unit.
Your recovery seed protects you against theft, loss or destruction of your device. Simply restore the recovery seed, and your wallet is back.
Issues not listed below are most likely not real, or they are a misrepresentation with factual inaccuracies.
Malicious ScriptSig in transaction
A specially crafted transaction could extract the private key. Knowledge of PIN and passphrase was required.
SpendMultisig malicious change in transaction
A specially crafted multisig transaction could contain a change output of an attacker, which wasn't confirmed by the user.
Possible key extraction with oscilloscope
With physical access to the device and an oscilloscope, the private key could have been extracted from the device.
SRAM memory access
The SRAM was not cleared on soft reset, allowing extraction using special firmware and direct access to the device board.
Platform reset attack
STM32F205 chip issue
The bootloader memory write-protection is not working as intended in the STM32F205, which is used in the Trezor One. The issue was solved by activating the Memory Protection Unit, keeping the bootloader safe from unauthorized write-access.
Supply chain attack
Race condition in recovery
Specially crafted USB communication could trigger a stack overflow in recovery which could lead to code execution.
Message processing error
Specially crafted USB packet could trigger a buffer overflow which could lead to code execution on older firmwares.
MPU circumvention via SYSCFG registers
Security fix deployed via the 1.6.1 firmware update could be circumvented via clever use of the SYSCFG registers. This was fixed by completely disabling the SYSCFG registers via the MPU.
Supply chain attack
Buffer overflow in bech32_decode
The C reference implementation for bech32 has an unsigned integer overflow that can lead to a buffer overflow. The bug was fixed by preventing the out-of-bounds accesses in the code.
Buffer overflow in cash_decode
The cash_decode function in the trezor-crypto library allowed an out-of-bounds write. The bug was fixed by preventing the out-of-bounds accesses in the code.
Side-channel analysis (SCA) of PIN comparison
Using a SCA bench an attacker could create the database of power consumption and electromagnetic traces of a device. This database could later be used to unlock a locked device using the same SCA bench. The issue was fixed by rewriting the device storage to not compare PINs directly, but rather compare random data stretched by the PIN.
Information leak via U2F
The C/C++ reference implementation for U2F by Yubico contains broken definition of a struct which can leak bytes from RAM via USB. The bug was fixed by updating the structure definition to a new correct one.
SRAM Dump during the firmware update
Using a special glitching hardware an attacker could trick the device processor into Read Protection level 1 which allows readout of RAM. The issue was fixed by not storing sensitive data in RAM during the firmware update.
Secret information leak via USB Descriptors
The attack used specialized hardware to inject a fault into the comparison function in the USB stack. When timed properly, an attacker could trick USB stack into returning sensitive data via USB in the USB descriptor.
Information leak via OLED display
The attack uses power analysis to read the information shown on the OLED display.
Malicious change in a mixed transaction
An attacker could create a specially crafted multisig transaction which would hide the multisig change address.
Marko Bencun, benma
In June 2017, we were contacted by security researchers Josh Datko and Chris Quartier, regarding a theoretical fault attack vector, by glitching the clock or VCC of the device. Josh and Chris presented their findings at DEFCON, and we incorporated their recommendations in the firmware version 1.5.1. As their disclosure did not reveal any provably exploitable vulnerabilities, we are not categorizing it as an issue, but we are mentioning it for the sake of completeness.
In September 2017, after the release of firmware 1.5.2, the security update fixing the SRAM memory access, a Medium article surfaced, claiming Trezor has been hacked. We evaluated this allegations and found out that the supposed attack vector was closed by the just released firmware update.
In August 2018, we were contacted by Filedescriptor, a security researcher, who reported CSRF issues in our Dropbox integration. The issues were fixed and deployed to production shortly after.
People that helped us with security.
We want to keep all our products and services safe for everyone. If you have discovered a security vulnerability, we appreciate your help in disclosing it to us in a responsible manner. We provide a bug bounty program to better engage with security researchers and hackers.
The idea is simple — you find and report vulnerabilities through responsible disclosure process. After they are confirmed, we recognize your effort by putting your name/nick and link in the table above and reward you a bounty paid in bitcoins!
Good faith and best effort not to leak or destroy any user or our data.
A reasonable amount of time to fix the issue before you publish it.
Do not defraud our users or us in the process of discovery.
We promise not to bring legal action against researchers who point out a problem provided they do their best to follow the above guidelines. We reserve the right to decide if the bug is real and severe enough to receive the bounty. We will also change our software to preemptively close possible security holes, even though we know they are not vulnerabilities at present. This means we may change our code in response to a report, even though the issue cannot be used as an attack. In other words, we do not pay bounties for unproven, theoretical issues, but we reserve the right to patch them anyway. Show us a working exploit if you want to prove it is a real vulnerability.
You can disclose a vulnerability by directly contacting our Security Team.
Code which reproduces the issue as a proof of concept.
Thorough explanation and the potential impact of the bug.
Your name/nick and link for attribution on this page (optional).
Address for your bounty.