In line with our transparency policy, we are publishing a comprehensive list of all the past security incidents 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.
Incidents 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.
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
In June 2017, we were contacted by 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. The author then offered to sell the exploit to anyone who was willing to pay for it. We evaluated his allegations and found out that the supposed attack vector was closed by the firmware update 1.5.2. The author also referenced Datko and Quarier’s DEFCON presentation, in order for the article to gain credibility, further fueling speculation. Nonetheless, there are currently no known vulnerabilities affecting the Trezor.
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.