Fixing physical memory access issue in TREZOR
On Wednesday, SatoshiLabs released a security update to all TREZOR devices, fixing a possible physical security issue. Originally, we wanted to leave some time for users to update their devices before announcing the details about the vulnerability and thus limit exploitation. Another reason was to give vendor of other hardware wallets based on TREZOR design enough time to study and apply our fixes and release updates to their products. However, as there was a large degree of misinformation spreading after the release of the update, exaggerating the claims about hacking TRZOR, to which we have already responded, we have to publish this report earlier than intended.
After the release of firmware update 1.5.2, the security update fixing the SRAM memory access (explained in this article), an anonymous 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.
It is also understandable that you are worried. We can assure you that we are doing everything to keep your coins safe. We hope that by transparently informing about the issue and its remedy, we can retain your confidence in our product.
Important: Firmware 1.5.2 fixes all known attack vectors.
While this is not a remote execution attack, and to exploit this issue an attacker needs physical access to a disassembled TREZOR, we are strongly recommending all TREZOR users to update their devices to firmware 1.5.2.
What was the main purpose of this security update?
The update eliminates a potential vector of attack that allows an attacker with physical access to a device with uncovered electronics to extract the seed from the device RAM. While physical access is required for this attack vector, we treat this as a serious vulnerability and recommend every user to install the update.
How does the attack work?
The seed is saved in the flash memory (storage that does survive restart) of the device, but when it is used, it is copied to its RAM (Random Access Memory, memory that does not survive restart). This vulnerability affects the latter — an attacker with physical access to a TREZOR device could have created a custom firmware which extracts the seed from the the RAM of the device.
Under normal circumstances, when you update TREZOR’s firmware, you need to first restart the device into bootloader mode. To do this, you are instructed to unplug and replug the device, thus clearing the device RAM. These two restarts via unplug (from old firmware to bootloader and from bootloader to new firmware) could be, unfortunately, replaced by soft restarts by connecting the RESET pin to GND pin on the device board. As it is a soft restart, the device will not erase its RAM. If an attacker created a special firmware and installed it with this method, they could have read the old firmware’s memory contents.
Note that by installing unofficial firmware, the device’s flash memory was erased. The attacker needs to access the RAM of the device. If anything goes wrong during this process, all information is lost.
How did we fix the vulnerability?
An obvious fix was to modify the bootloader in a way that it clears the whole RAM on start and also before it is going to load the firmware. This fix has been implemented in bootloader source code and the change will be implemented in the new batch of devices.
What about the already sold devices?
The misinformation article claims that this vulnerability cannot be fixed without replacing devices. This is, however, not true.
We came up with a clever way how to fix this issue for devices with older bootloader versions (as bootloader cannot be updated). In embedded programming, you can be very explicit where in the device memory should a variable be placed. We went through the entire code of TREZOR and marked all potentially confidential variables with a special mark. During the final assembly of the firmware, also called linking, we instructed a tool called linker to collect all variables with the mark and place them at the beginning of the device RAM. This way, we can assure that the bootloader will always overwrite all critical data from firmware with its own variables.
In other words, with the new firmware 1.5.2, even if the attacker performs a soft reset and launches the old bootloader to install their exploit, the RAM is already overwritten at this stage and thus no confidential data remain in the memory.
Why is the device memory not encrypted?
There are claims saying that this vulnerability would not be a problem if the device storage was encrypted in the first place. Well, it is not that straightforward.
If you want to encrypt something, you will need an encryption key. This could be something that the TREZOR knows (e.g. processor serial number) or something that the user knows (e.g. PIN) or ideally a combination of both. Usually, these factors are combined by something called the key derivation function (KDF). You want this KDF to take some time to make brute-forcing as difficult as possible. On the other hand, this cannot take too much time, as users want to use TREZOR immediately, instead of waiting for it to unlock.
Let’s suppose a user is willing to wait 10 seconds after the PIN is entered, before being able to use the TREZOR. If the PIN is 4 digits long, this means 10 000 possibilities, yielding 100 000 second required for brute-forcing. But this is the time required on the device! Surely, an attacker could write a tool that will perform the same task, KDF, on a desktop computer, which is around 400 times faster. The time required shortens to 250 seconds, slightly more than 4 minutes to get the encryption key.
If your PIN is 6 digits long, this translates to around 7 hours on a desktop computer. This is still not a long time, as police can detain you for a longer time than that, in most countries. Moreover, if an attacker gains access to the device memory, they can get the processor serial number too, making PIN cracking the only necessary task. Therefore, such method of encryption is not really effective as a means of protection.
On the other hand, there is an effective way, which the TREZOR already offers. We are talking about the passphrase feature, which is defined as a part of BIP39 standard. It uses the same logic, but rather than combining the serial number of TREZOR and your PIN, it mixes the seed stored in the device with the passphrase that you have to remember. And this passphrase is stored nowhere! Moreover, it is not limited to numbers, making it much harder to brute-force. Every passphrase is valid, and each, in combination with the seed, creates a completely different wallet. Also, an attacker would need to look into the blockchain for each passphrase guess, to see whether he has the correct one or not, rendering the whole brute-force attack lengthy.
We welcome responsible disclosure
As a community-oriented open-source product, we welcome responsible disclosure. Any white-hat hacker can take part in it, analyze our source code, talk to our developers, contribute to our code, or disclose security issues responsibly. Please check out the Responsible Disclosure details, available here
FAQ
What if an attacker downgrades the firmware to versions lower than 1.5.2?
TREZOR storage will be wiped.
I bought a TREZOR yesterday, is it also affected?
If you initialize your TREZOR for the first time after the new firmware was released, your TREZOR will have the newest firmware, and therefore it will not be affected. If you have an up-to-date firmware, no notification will be shown in TREZOR Wallet.
Do I need to update?
Go to TREZOR Wallet. If the Wallet tells you your firmware is outdated, please do update your device.
Are other hardware wallets affected?
All devices using TREZOR’s design are potentially vulnerable to this attack vector. We have reached out to other producers of hardware wallets and informed them about the issue.
I read that 1.5.2 is susceptible to the attack too?
This is a misinformation. The described vulnerability was fixed in 1.5.2.
Can you dump the RAM/storage contents by connecting two pins?
No, this is also a misinformation. There are no special pins which would trigger such an action. The debug JTAG connector is completely disabled on the device. In order to dump memory/storage, the attacker would have to flash custom-programmed firmware like described above. Since 1.5.2 TREZOR will correctly erase the storage and will not leave confidential information in RAM.
Responsible Disclosure Timeline
- 1-Aug-2017: Vulnerability discovered and reported
- 16-Aug-2017: Firmware 1.5.2 released
- 17-Aug-2017: Addressed concerns and misinformation about 1.5.2
- 18-Aug-2017: Report on the vulnerability published
Resources
Saleem’s technical description of the vulnerability and the fix.
