Details about the security update

In February 2018, Saleem Rashid, an independent security researcher and TREZOR contributor discovered a security vulnerability in the memory write-protection operations of the STM32F205 processor, which the TREZOR One uses, and disclosed the issue through our Responsible Disclosure program. Saleem communicated with us professionally, as usual, and assisted where possible. We worked together with him and STMicroelectronics to develop a fix that closes this vulnerability. The update released today contains this fix.

“I am thankful to Saleem for his contributions to Trezor project. His out-of-the-box thinking and creative approach help us to make an even more secure product. This experience only proves that community-oriented and open-source development is the correct path to take.” — Marek Palatinus, CEO SatoshiLabs

What was the issue?

This vulnerability does not enable private key extraction.

The STMicroelectronics chip STM32F205 used in the TREZOR One device contains a flaw, which effectively disables the write-protection employed to protect the bootloader of the device. This is an unexpected and undocumented behavior of the chip. Once the issue was disclosed and replicated, we immediately reached out to the chip manufacturer, STMicroelectronics. After several meetings, the manufacturer confirmed the observed behavior and added that not only the whole F2 family is affected, but also the earlier models of the F4 family, such as STM32F405, are susceptible. (The newer F4 family models, such as STM32F427, are not affected.)

Detailed explanation: Settings for write-protection are stored in the so-called OPTION BYTES. These settings are persistent across reboots and are set via register called FLASH_OPTCR (option byte config register). When you want to change the OPTION BYTES, then you need to set a new configuration into the FLASH_OPTCR register and then call a commit. If the OPTION BYTES are unlocked (rewritable), these new settings are then copied from FLASH_OPTCR to OPTION BYTES, where they survive a restart. Once we in TREZOR do not want to allow any change to the OPTION BYTES, we can lock them forever using the read-protection, which is configured in the same setting area. However, these chips, more specifically the flash memory controller, do not look for write-protection configuration in the OPTION BYTES, where they should, but they look into the FLASH_OPTCR register instead. There, the value can be changed, of course, even when the OPTION BYTES are adequately locked, effectively rendering the write-protection useless on these chips.

Since the issue is not planned to be fixed in hardware by the manufacturer, we have opted to engineer a software solution closing this vulnerability in its entirety. We are open-sourcing this method as a part of the TREZOR One project. The code is available on GitHub. Details are available further below in this article.

“I am very impressed by the incredibly rapid response from TREZOR. While it’s unfortunate the chip had this issue, SatoshiLabs has implemented an excellent fix that not only fixes the issue but also helps prevent other potential attacks.” — Saleem Rashid, independent security researcher

How does this affect TREZOR One?

This flaw in the chip allows an attacker to modify and replace the bootloader via a malicious firmware update. It is important to note that this vulnerability cannot be exploited remotely. As this security issue requires the attacker to install custom firmware on the device, it does not affect already initialized devices; the device memory would be erased during this process. Therefore, this issue only affects devices before the delivery to a customer.

The chance that your device has been modified during transport is, however, very meager. First of all, the device packaging features tamper-evident seals. The packaging of TREZOR One is also glued together with an industrial-grade solution. When purchasing from TREZOR Shop or any of our resellers, if your package arrived unscathed, your TREZOR One is safe.

If you do suspect your device was tampered with during the transport, please contact our Support Team.

How was the issue fixed?

TREZOR already comes with several physical and software precautions in mind:

The device comes with tamper-evident seals on the packaging. The packaging itself is glued together with an industrial-grade solution.

We always recommend purchasing the device via a trusted channel: TREZOR Shop or authorized resellers.

Today’s security update brings about additional enhancements to the software solution for the TREZOR One device, which is applied on two levels:

Firstly, the firmware update released today contains new code, which checks the authenticity of the bootloader of your device. The firmware will update your device’s bootloader to the latest version.

Secondly, as the bootloader write-protection by STMicroelectronics is flawed, we supplemented it with write-protection enforced by the MPU (Memory Protection Unit): Only a firmware signed by SatoshiLabs is allowed to modify sensitive parts of the memory. As the bootloader already checks the firmware signature, this was relatively easy to implement.

Detailed explanation: The solution is to supplement the flawed OPTION BYTES write-protection, using another available protection system, called MPU — the Memory Protection Unit (different part of the chip). Using this unit in the bootloader, we can specify which areas of memory can be accessed or not, effectively reaching the intended level of protection (the MPU restricts access to sensitive parts of the memory including the bootloader area and the FLASH_OPTCR register). STMicroelectronics confirmed that by using the MPU, the issue is resolved.

The activated MPU also prevents code execution from memory.

How to update firmware?

First of all, please make sure you have your recovery seed with you when you perform the update. (Link to manual)

Go to TREZOR Wallet and follow the update instructions shown on the screen. When prompted, replug your TREZOR One device with both buttons plugged to start it in bootloader mode. Confirm the update procedure, and you will have a new firmware on your device.

On boot of the new firmware 1.6.1, the system will check the hash of the bootloader, to verify its integrity. During the first boot of the firmware 1.6.1, the firmware will also update the bootloader to the latest version. At the end of this process, the device will ask you to reconnect. Therefore, you will reconnect twice during this update: once after firmware update and once after the bootloader update by firmware. Please follow the instructions on the device screen.