Details of Security Updates for Trezor One (Firmware 1.8.0) and Trezor Model T (Firmware 2.1.0)
Last week we released the firmware update 1.8.0 for Trezor One devices, followed by this week’s release of firmware update 2.1.0 for Trezor Model T devices. This post describes three notable vulnerabilities which we fixed in these updates. Meanwhile, our internal security research has also continued. We’ve fixed multiple issues including those found via our fuzzing efforts performed by Christian Reitter. We’ll explain more about these efforts and relevant findings in an upcoming post.
Patching security issues is always a challenging but positive experience, and we truly appreciate the knowledge brought to this conversation by everyone who was involved. We worked with some of the best-known experts in the field of embedded hardware security demonstrating Trezor is an essential part of both the open source hardware and Bitcoin communities, and we aim to remain the innovation leaders in these two areas. Communication with all involved parties was very professional and focused on a common goal: improving the overall security of the solutions we provide to our users.
Side-channel analysis (SCA) of PIN comparison
Reported via the Trezor Responsible Disclosure program by Charles Guillemet and the Ledger Donjon team.
The initial report informed us about the code analysis of our PIN comparison function used in the PIN protection mechanism. The conclusions were:
- the code is functionally correct.
- the PIN failure counter is pre-incremented before the comparison, which is a good practice.
- the PIN verification correctly depends solely on the input size to avoid timing attacks.
- the code might be vulnerable to other side-channel analysis (SCA) methods such as power consumption and electromagnetic trace.
Further write-up revealed that Charles and his team built a side-channel analysis bench (see below) where they collected power consumption and electromagnetic traces of Trezor’s behavior while comparing different combinations of PINs entered and PINs stored in the device memory.
Using this custom built database of traces it was possible to perform the following attacks:
- try 10 particular PINs and measure the behaviour of the device using the SCA bench
- use 10 traces to identify the top 6 most probable PINs from the database
- try these 6 PINs
Luckily, Trezor devices wipe after 16 incorrect PIN attempts and there is also exponential delay between the attempts, so it takes almost a day to try all 16 PINs (10 measurements + 6 guesses).
How was the vulnerability fixed?
We decided to completely rework the way that we store data in our Trezor devices. Our developers Andrew Kozlík, Ondřej Vejpustek and Tomáš Sušánka designed an encrypted and authenticated key-value storage suitable for use with microcontrollers, which led to development of a new project called trezor-storage. As with any of our projects, this one is again open-source, so any embedded hardware project can use and benefit from using our implementation. There are two types of values — public and protected. Public ones (such as device label) can be read without the PIN, but most of the values are protected and the PIN is required to access them. Protected values are encrypted (and authenticated) using a key that is derived from the entered PIN and other sources of entropy such as device ID. Once this key is obtained, the storage tries to decrypt the value using that key. The decryption fails during the authentication phase if the PIN entered was incorrect.
The side-channel analysis is no longer possible, because all entered PINs are treated equal. If an incorrect PIN is used, the whole algorithm follows the same logic as if it was the correct PIN. The only difference is, that at the end, the incorrect data are obtained. This is detected and a failure is reported.
Only Trezor One was directly affected by this vulnerability. However, we applied the same changes to Trezor Model T to mitigate possible future attacks on this device too. Updates 1.8.0 (for Trezor One) and 2.1.0 (for Trezor Model T) use the newly implemented trezor-storage to close this attack vector.
SRAM dump during the firmware update
Publicly disclosed at 35c3 aka Chaos Communication Congress 2018 by Wallet.Fail team (Dmitry Nedospasov, Josh Datko, Thomas Roth).
The talk at 35c3 contained a segment which described a way to glitch the firmware update process in the bootloader using a specially created FPGA device (see below) during the exact moment when a copy of the data storage is temporarily in the device SRAM. Their glitcher tool can perform a Read Protection (RDP) downgrade to level 1 which allows SRAM access and thus permits dumping the data from memory. It took several months of probing the microcontroller to find the correct details which lead to a successful attack. This attack likely affects the complete ARM Cortex-M3 series chips from all vendors, so this is a problem for more than just Trezor.
Before loading new firmware, Trezor used to move the contents of the flash memory, i.e., the seed and PIN, and place it temporarily into the device’s RAM where it waited for the validation of the newly loaded firmware. If everything goes well, this data is moved back to flash memory and cleared from the RAM. If anything goes wrong, the RAM gets erased. Because the wallet.fail team found a way to access the contents of the RAM during the update process, this method is no longer a viable option. Trezor Model T was not affected by this vulnerability, because things are done differently during a firmware update.
How was the vulnerability fixed?
Firmware 1.8.0 introduces a different process of loading the firmware into Trezor One and checking its validity. This process is essentially the same as what is already done in Trezor Model T. The firmware image is cut into smaller blocks, each of them is hashed, and the hashes are contained in the firmware header, which is signed. During an update the process loads individual blocks into RAM one by one and verifies that their hashes match the values stored in the firmware header. They are written into the flash memory only if they do. At all times, the sensitive data stays stored in the flash memory and is not copied to RAM. This removes the attack vector.
Secret information leak via USB Descriptors
Reported via the Trezor Responsible Disclosure program by Colin O’Flynn of NewAE Technology Inc. (makers of ChipWhisperer — a security and research platform for embedded hardware)
The report described a fault injection which makes the leak of secret information via USB descriptors possible. The USB stack we use contains the check which is supposed to limit the size of the data send out via USB packets to the descriptor length. However, these checks could be circumvented using EMFI (electromagnetic fault injection — injected via ChipShouter hardware, see below) and a different, higher value than intended could be used. This causes the USB stack to send not only the expected data, but also some extra data following the expected data. Colin noticed that WinUSB/WebUSB descriptors of the bootloader are stored in the flash before the storage area, and thus actively glitching the process of sending WinUSB/WebUSB descriptors can reveal the stored data in the storage, disclosing the secrets stored in the device.
How was the vulnerability fixed?
Colin also suggested methods by which these findings should be mitigated, and these are exactly what we implemented. We modified the USB stack, so it uses bitwise AND operation to limit the size of the outgoing packets, making the glitching much more difficult. The second mitigation was that we introduced a new rule to the memory protection unit, which creates a non-readable block just before the storage sectors. This means that even if an attacker were still able to glitch the USB stack, it would hit the MPU rule causing the device to halt, before any data have the chance to be sent.
Although only the Trezor One was affected directly by this vulnerability, we implemented the same protection mechanisms in the Trezor Model T firmware, so both 1.8.0 and 2.1.0 updates contain these new measures which close this attack vector.
Edit: Colin wrote a blog post where he describes the issue in bigger detail.
Summary and the key takeaway
Exploiting either of these vulnerabilities requires physical access to the device. An attacker also needs a specialized hardware connected to Trezor device to perform the attack. Those who use passphrases to protect their wallets are unaffected unless they disclosed their passphrase to the perpetrator. At the time of writing this article, there is no evidence that any of these vulnerabilities have ever been exploited outside of the lab to extract any data. As always, we strongly recommend keeping all Trezor devices updated with the latest firmware to maintain the maximum level of security.
Timeline
2018–10–31 — “Side-channel analysis (SCA) of PIN comparison” submitted via the responsible disclosure
2018–12–27 — “SRAM Dump during the firmware update” report publicly disclosed
2019–01–02 — “Secret information leak via USB Descriptors” submitted via the responsible disclosure
2019–02–27 — firmware update 1.8.0 for Trezor One released
2019–03–06 — firmware update 2.1.0 for Trezor Model T released + revision 1 of this disclosure post released
About Us
Created by SatoshiLabs in 2014, the Trezor One is the original and most trusted hardware wallet in the world. It offers unmatched security for cryptocurrencies, password management, and serves as the second factor in Two-Factor Authentication. These features combine with an interface that is easy to use whether you are a security expert or a brand new user.
Trezor Model T is the next-generation hardware wallet, designed with the benefits of the original Trezor in mind, combined with a modern and intuitive interface for improved user experience and security. It features a touchscreen, faster processor, and advanced coin support, as well as all the features of the Trezor One.
