This article describes an information leak discovered in the OLED display used by hardware wallets, including Trezor One. We want to explain how this side-channel attack works and what measurements we took to mitigate the threat. This attack affects only the Trezor One; Trezor Model T is immune to this attack thanks to its entirely different display.

Christian Reitter, an independent security researcher working closely with SatoshiLabs, discovered this vulnerability and reported it to SatoshiLabs in early April of this year. The MITRE organization assigned this vulnerability of Trezor One with the ID CVE-2019–14353.

After the initial discovery in April, Christian found that the hardware vulnerability also affects multiple other embedded security devices that feature a similar OLED display, including many hardware wallets. Consequently, Christian organized a responsible disclosure process with a common release date among the impacted vendors to ensure that they had the opportunity to assess and mitigate this issue.

The attack requires device owners to use USB equipment that has been physically manipulated by an attacker. In other situations, users are not impacted.

There is no evidence that any malicious actors ever exploited this vulnerability.

The latest firmware v1.8.2, now available for Trezor One, mitigates the issue.

Details of the OLED side-channel attack

The underlying problem

The vulnerability works with the fact that the common SSD13XX OLED screen type used in the Trezor One and other embedded security devices displays information only one-pixel row at a time instead of all at once (as is, e.g., typical for TFT screens) and requires a relatively large amount of energy to do so. While we expected that displaying screen contents with many bright pixels increases the power consumption of an OLED screen, Christian found that there is a direct correlation between the number of illuminated pixels on each row and the total power consumption of the device in a particular moment.

In computer security, we commonly refer to these unwanted effects as a side-channel, and we dedicate a lot of effort to avoiding them.

Proof of concept for the Trezor One

The following oscilloscope graph illustrates the general behavior of the side-channel. As shown in the area marked in red, the yellow trace of the current OLED display capture of the seed word “weird” visibly differs from a previously taken and overlaid orange trace of the seed word “cram.” This result highlights the usability of the side-channel for an attack via categorization of seed words.

Image credit: Christian Reitter

Impact

An attacker with the ability to perform a power consumption analysis of the device while it is displaying secrets on the screen can conceivably use this partial information of the pixel distribution of each row to recover confidential information via statistical analysis. In particular, this is relevant for the seed words or PIN combination.

Notably, the contents of the display cannot be changed through this effect, so the integrity of the displayed information is not affected. This means that you can still trust the display of your Trezor.

Attack scenario

For practical analysis of this side-channel, we have to capture the power consumption of the target device in sufficient detail over a few milliseconds. This attack is possible without any modifications to the hardware wallet itself, but requires unique components that are typically not present in USB circuitry. For example, we could sample the voltage drop over a shunt resistor in the USB supply line (which powers the target device) with an analog-to-digital converter at a high rate.

Under laboratory conditions, the capture is done via bulky external measurement equipment such as an oscilloscope or a software-defined radio to achieve high-quality results. However, the electrical properties of this side-channel make it plausible that the required measurement equipment could be reduced so far in size that it would fit directly inside hollow sections of a malicious USB cable or another USB periphery.

Plausibility of the attack

As with many other physical attacks on embedded hardware systems, assessing the actual security impact for the average device owner depends on many assumptions which are hard to support with empirical data. Therefore, we want to present a few of the relevant in-depth considerations in this section.

As described in the previous section, an attacker has to trick the targeted device owner into performing sensitive device actions with some sort of malicious USB equipment connecting the Trezor One and the computer.

We are not aware of any existing benign measurement circuitry in conventional USB equipment or USB hosts that could be misused to perform the required signal analysis without physical modifications. Therefore, an attacker would have to insert this special circuitry by replacing the original cable at some point in the purchase/shipping process (-> supply chain attack) or via direct physical access to the target device (-> evil maid attack).

We could argue that less complicated attacks are possible with the described level of access, which consequently lowers the relevant severity assessment. At the same time, the described hardware represents a novel attack vector that may remain undetected even after in-depth inspection by cautious users.

(Some techniques could be used to obscure the presence of the additional circuitry further and make it harder to detect, e.g., to pass basic electrical tests.)

Depending on the construction and the exact attack scenario, a sophisticated version of the cable could also separately attack the host computer via other USB-based attacks such as HID emulation, or capture device traffic on the USB bus to work around specific limitations of the attack. This might also increase its “versatility” against multiple affected products.

Publicly documented examples of other hardware implants show that USB cable modifications can include active components such as microcontrollers and even wireless connectivity through WIFI & GSM. This covers a significant part of the hardware feature set that is required here. Overall, building a reliable and stealthy implant for this side-channel is not judged to be trivial, but it might be possible.

For these reasons, we have decided to implement active firmware-based countermeasures that make the side-channel unusable for the recovery of secrets even if malicious equipment is present.

How we mitigated the issue

In-depth research into the signal behavior has shown that the difference in the number of illuminated pixels on a row-by-row basis fundamentally influences the side-channel. The exact horizontal position of individual pixels does not appear to be necessary. We used this to our advantage to implement appropriate countermeasures in the firmware.

In the following display examples, a calculated number of white decoy pixels is added to each row of the word display to mask its side-channel signature. This technique effectively removes the word-dependent signal in side-channel behavior. Below are examples of the decoy pixels used in the firmware update 1.8.2 to protect screens containing secret information.

This first round of mitigation is part of the latest stable firmware 1.8.2. We are looking into additional countermeasures that we could implement in a future version.

Recommended security measures

Users of Trezor One are highly advised to update to firmware version 1.8.2.

Users of Trezor Model T are not affected by this vulnerability in any way. Trezor Model T uses an entirely different display that is fully immune to this attack.

As always, we strongly recommend keeping all Trezor devices updated with the latest firmware to maintain the maximum level of security and ensure the latest functionality.

How to update the firmware?

At the time of writing this, the new firmware 1.8.2 is optional and available from our beta wallet. We encourage you to update, as this brings you the latest security fixes. For firmware 1.6.2 or newer, the update process is straightforward.

If you use older firmware (1.6.1 and before), you need to update to firmware 1.6.3. We have added a function to our web wallet which updates your Trezor in two steps if required.

Please note that if your Trezor One device is currently running firmware version 1.6.1 (bootloader version 1.4.0), the update to firmware 1.6.3 wipes the device memory. Please make sure you have the correct recovery seed with you, as it is required to recover your Trezor device from seed backup.

We recommend testing your recovery seed before you update device firmware.

We want to thank Christian Reitter for his responsible disclosure, extensive research, and associated documentation of this vulnerability. It is also important to note that the process of information sharing between individual vendors significantly contributed to the mitigation of the attack.

— Pavol “Stick” Rusnak, CTO at SatoshiLabs

Frequently Asked Questions

Is the Trezor Model T affected?

The Trezor Model T uses a different display technology (TFT), so it is not affected by this vulnerability.

I am about to buy a new Trezor One. Will it be affected?

We ship the Trezor devices without preloaded firmware. Therefore the latest available firmware with the latest patches is always installed during the device initialization.

Is this relevant if my Trezor One gets stolen?

This side-channel does not help an attacker in any way to recover information from a stolen device.

Are other hardware wallets affected?

Yes. As described previously, the vulnerability exists in a common OLED display component that is used by many other embedded security devices. The practical level of impact depends on several factors, such as their use of the display for confidential data.

Timeline

2019–04–08 — OLED information leak is discovered and disclosed to SatoshiLabs

2019–05–02 to 2019–05–12 — Disclosure to five other vendors

2019–05–29 — The planned public disclosure date falls on 2019–08–07

2019–06–04 — Disclosure to another vendor

2019–07–23 — CVE assignment requested

2019–07–28 — CVE assigned by MITRE

2019–08–07 — Common public disclosure date

2019–08–07 — First release of this disclosure post + firmware 1.8.2 release

Revisions to this document