Our Shared Security: Responsibly Disclosing Competitor Vulnerabilities

Security is at the forefront of everything we do at Ledger — it’s embedded in every product we sell and in every decision we make. Each and everyday we challenge ourselves to create technology and products that are better and more secure.
Our first priority is providing our customers with state-of-the-art security through Ledger’s hardware wallets, IoT and institutional investment offerings. However, as the global leader in blockchain security solutions, we believe that our commitment to security extends beyond just ourselves. With some of the most innovative technology in the world and an unparalleled team, we have a responsibility to enhance security throughout the entire blockchain ecosystem whenever possible. A shared commitment to security not only helps to better protect assets for individuals and institutions, but also to foster much needed trust throughout the crypto landscape.
[minti_blockquote]“we have a responsibility to enhance security throughout the entire blockchain ecosystem whenever possible”[/minti_blockquote]
As detailed in our previous blog, Ledger’s world-class security team, Ledger Donjon, has an Attack Lab in our Paris HQ where we hack into our own, as well as competitors’ devices, to expose security vulnerabilities.
With the interest of security for the entire community in mind, we also share the tools and best practices that we deploy, such as our side-channel analysis library Lascar and simulation tool Rainbow.
We are constantly attempting to hack into our own devices to ensure that we maintain the highest standards of security, and get in front of new methods from increasingly sophisticated attackers. We deploy these same methods to our competitor’s device because we have a shared responsibility in guaranteeing a high level of security for the entire industry.
Critically, when addressing the security of competing products, we always follow the principles of responsible disclosure, informing the impacted party of any vulnerability of their products that our Attack Lab might find, and giving them time to find a fix. It is important to follow responsible disclosure protocols before going public with any information to ensure that the vulnerability is not exploited by hackers before the issue can be resolved.
[minti_blockquote]“we have a shared responsibility in guaranteeing a high level of security for the entire industry.”[/minti_blockquote]
Notably, about four months ago we contacted Trezor to share five vulnerabilities our Attack Lab uncovered. As always, we gave Trezor a responsible disclosure period to work on these vulnerabilities, even granting them two extensions.
The analysis encompassed both of Trezor’s hardware wallets (Trezor One, Trezor T), focusing on the Trezor One. It also applies to clones of Trezor wallets. We responsibly disclosed these vulnerabilities to the vendor, allowing them to take appropriate measures for protecting their users. Now that the responsible disclosure period, including the two extensions, has expired, we wanted to share details with you in the spirit of full awareness and transparency. A full recap of the results can be found below.

Trezor Security Analysis

Vulnerability 1: Genuineness of the device

Removing Trezor’s security seal with a warm scalpel.

Overview
The genuineness of the device is a paramount property to ensure that the device is authentic.
Findings
Our analysis found that the genuineness of a Trezor device can be imitated. We were able to manufacture fake devices which are exact clones of a genuine one (same components, same hardware architecture, same look & feel). We were also able to open the box of a device, backdoor the device and re-seal the box (even with the “tamper-proof sticker” aimed at protecting against such attacks).
In this case, an attacker has complete control over the code running on the rogue device. For instance, it’s possible to:

• Pre-seed the device
• Backdoor it with a malware which sends the crypto assets to another address
• Insert cryptographic flaws to get access to the crypto assets
• Backdoor it with a malware which extracts the seed

A pre-seeded Trezor – looks exactly the same as a genuine one. 

Even if the user buys their Trezor device directly online from Trezor’s website, he/she can not be sure. An attacker could buy several devices, backdoor them, and then send them back asking for reimbursement (using withdrawal period).
Result: This vulnerability was reported to Trezor, who stated that it is out of their security model, citing that users won’t be exposed to this issue if they purchase their products directly from the Trezor website (as Trezor recommends). In our view, this vulnerability can only be patched by overhauling the design of the Trezor One, and replacing one of its core components to incorporate a Secure Element chip, as opposed to the general purpose chip currently used. To our knowledge, this vulnerability is still active as of this publication.

Vulnerability 2: Secure PIN protection

Guessing the PIN code.

Overview
The PIN gives access to the device and thus to the funds protected by the device. The current implementation gives 15 tries to the user with an exponential waiting time. This function should be tamper resistant.
Findings
Our security analysis found that, on a found or stolen device, it is possible to guess the value of the PIN using a Side Channel Attack. This Side Channel Attack consists of presenting a random PIN and then measuring the power consumption of the device when it compares the presented PIN with the actual value of the PIN. This measurement allows an attacker to retrieve the correct value of the PIN within only a few tries (less than 5 in our case). We found that the PIN does not protect the funds against an attacker with a physical access to the device.
Result: Reported to Trezor on 2018-11-20 . This vulnerability has been patched by Trezor in firmware update 1.8.0

Vulnerability 3 & 4: Confidentiality of data inside the device (Applies to Trezor One AND Trezor T)
Overview
The confidentiality of the data inside the device is paramount since it contains all the private information giving access to the user’s funds: private key, seed. The Hardware Wallet must act as a security enclave for this data.
Findings
Our analysis found that an attacker with a physical access to the device can extract all the data stored within the flash memory (and therefore deplete all accounts from their assets). Our attack applies on Trezor One and Trezor T as well.
Result: Reported to Trezor. In our view, this vulnerability can not be patched, it can only be circumvented by overhauling the design of the Trezor One / Trezor T, and replacing one of its core components to incorporate a Secure Element chip, as opposed to the general purpose chip currently used. This vulnerability can not be patched – for this reason, we have elected not to disclose its technical details. It could also be mitigated by users adding a strong passphrase to their device.

Vulnerability 5: Analysis of the cryptographic stack

Overview
We analyzed the implementation of the crypto library of the Trezor One. While we found that this library does not contain proper countermeasures against Hardware Attacks except for the Scalar Multiplication function (which could be a cause for concern in its own right), we focused on the aforementioned Scalar Multiplication. This function is the main cryptographic operation for cryptocurrencies, as it is the one used for most critical operations involving secret keys. In its code, this function is claimed to be  protected against Side Channel Attack, which we wanted to evaluate.
Findings
Our security analysis found that an attacker with a physical access to the device can extract the secret key using Side Channel Attacks when this key is used by the Scalar Multiplication. Scalar Multiplication is one of the core function for cryptography in cryptocurrency. In particular, this is the core function for signing Transaction. We proved that with a digital oscilloscope, and a few measurements, it’s possible to extract the key of a transaction using Side Channel analysis.
Result:  This vulnerability was reported to Trezor. This vulnerability can be patched, but also does not directly affect Trezor’s security model since this operation cannot be triggered without knowing the device’s PIN beforehand. It was, however, claimed to be secure against side channel attacks, which unfortunately proved incorrect.
Here is the status.

For the full presentation, as presented by our CSO Charles Guillemet, you can watch the video underneath: