Trezor Security.
In line with our transparency policy, we are publishing a comprehensive list of all the past security issues of Trezor and our related services.
Security measures of Trezor.
Firmware verification.
The bootloader verifies the firmware signature. The device only runs if the firmware is correctly signed by SatoshiLabs. Otherwise, the Trezor warns you.
Ultrasound hardware seal.
Trezor hardware case is ultrasonically welded, making it difficult to be restored after breakage.
Protected key operations.
Operations with private and public keys are only allowed after user authentication via PIN.
Secure update procedure.
The bootloader erases memory on firmware update and restores it only if the firmware signature is valid. Downgrade wipes the memory.
Additional passphrase support.
Trezor supports BIP39 passphrases, which are never stored or remembered on the device.
Write-protected bootloader.
The bootloader is write protected, as the JTAG is disabled. MCU is safeguarded by the Memory Protection Unit.
Reliable backup & recovery.
Your recovery seed protects you against theft, loss or destruction of your device. Simply restore the recovery seed, and your wallet is back.
Past issues.
Issues not listed below are most likely not real, or they are a misrepresentation with factual inaccuracies.
Fixed in 4 hours
01
Issue
Malicious ScriptSig in transaction
Detail
A specially crafted transaction could extract the private key. Knowledge of PIN and passphrase was required.
Type
Buffer overflow
Remote
*still requires physical confirmation
Fixed in 1 day
02
Issue
SpendMultisig malicious change in transaction
Detail
A specially crafted multisig transaction could contain a change output of an attacker, which wasn't confirmed by the user.
Fixed in 4 days
03
Issue
Possible key extraction with oscilloscope
Detail
With physical access to the device and an oscilloscope, the private key could have been extracted from the device.
Type
Power analysis
Needs physical access
Fixed in firmware
1.3.3
Reported by
Jochen Hoenicke
Date reported
2015-03-26
More info
Fixed in 8 days
04
Issue
SRAM memory access
Detail
The SRAM was not cleared on soft reset, allowing extraction using special firmware and direct access to the device board.
Type
Platform reset attack
Needs physical access
Fixed in firmware
1.5.2
Reported by
Sunny
Date reported
2017-08-01
Fixed in 35 days
05
Issue
STM32F205 chip issue
Detail
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.
Type
Supply chain attack
Needs physical access
Fixed in firmware
1.6.1
Reported by
Saleem Rashid
Date reported
2018-02-12
Fixed in 30 days
06
Issue
Message processing error
Detail
Specially crafted USB packets could trigger buffer and stack overflows which could lead to code execution on older firmwares.
Type
Buffer/stack overflow
Remote
*still requires physical confirmation
Fixed in firmware
1.6.2
Reported by
Christian Reitter
Date reported
2018-06-25
Fixed in 23 days
07
Issue
MPU circumvention via SYSCFG registers
Detail
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.
Type
Supply chain attack
Needs physical access
Fixed in firmware
1.6.3
Reported by
Sunny
Date reported
2018-08-07
Fixed in 29 days
08
Issue
Buffer overflow in bech32_decode and cash_decode
Detail
The C reference implementation for bech32 has an unsigned integer overflow that can lead to a buffer overflow. The cash_decode function in the trezor-crypto library allowed an out-of-bounds write. Both bugs were fixed by preventing the out-of-bounds accesses in the code.
Type
Buffer/stack overflow
Remote DoS
Fixed in firmware
1.7.1
Reported by
Christian Reitter
Date reported
2018-09-26
Notes
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.
Leaderboard.
People that helped us with security.
1
Sunny
50.000 points
5
Christian Reitter
10.000 points
6
Filedescriptor
1.000 points
7
Luke Jahnke
1.000 points
Responsible disclosure.
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!
Requirements.
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.
Relevant topics.
01
Private key extraction from Trezor.
02
Tricking Trezor into confirming an action without user interaction.
03
Bypassing PIN/passphrase protections of Trezor.
04
Tricking Trezor into running unsigned firmware without warning.
05
XSS or CSRF on wallet.trezor.io
06
Obtaining user information from the Trezor Wallet backends.
Please, do not report.
- vulnerabilities on sites hosted by third parties (MailChimp, Medium, Twitter, Facebook, CloudFlare, etc.)
- denial of service attacks
How to disclose an issue.
You can disclose a vulnerability by directly contacting our Security Team.
Important information to include
1 of 3
Code
Code which reproduces the issue as a proof of concept.
Detailed description
Thorough explanation and the potential impact of the bug.
Your info
Your name/nick and link for attribution on this page (optional).
Bitcoin address
Address for your bounty.
Important information to include
2 of 3
Use both of the following PGP keys when submitting sensitive information
Stick, PGP key.Important information to include
3 of 3