Hacking the ultra-secure hardware cryptowallet

Almost every security research has a question often left unanswered: what would be the financial consequence, if a discovered vulnerability is maliciously exploited? The security community almost never knows, unless a real attack takes place and the damage becomes known to the public. But now we have cryptocurrencies: a concept of digital money that is basically protected by a single private key, which, when stolen, leads to a measurable financial loss. Multiple breaches of private wallets and public currency exchange services are well-known, and to address the issue a few companies have come up with secure hardware storage devices to preserve the precious wallet access credentials at all costs.

But how secure are they? Riscure’s security researcher Sergei Volokitin looked into the Ledger Nano S – the multi-cryptocurrency hardware wallet that supports, among others, Bitcoin, Ethereum and Monero. This research was presented at BlackHat USA 2018 conference.

Ledger Nano S can also serve as a universal U2F device for multi-factor authentication to protect a variety of online services that support the FIDO protocol. In other words, it’s a device designed to protect your digital money and your digital identity at the same time – something that you want out of hands of an adversary at all costs. During the research seven vulnerabilities were identified that can be combined in three distinct groups. Two sets of vulnerabilities could lead to theft of secrets if an attacker has physical access to a device, or is able to compromise a supply chain. Additional group of vulnerabilities does not lead to an immediate compromise of protected data, but reveals weaknesses in the device’s security design that can potentially be exploited further. Ledger, the maker of the cryptowallet, was informed about the findings and addressed the vulnerabilities. Therefore, this is also the story of a successful cooperation between vendors and security communities.

The specifics of Ledger Nano S

The hardware wallet is based on a dual-chip design which includes the STM32 micro-controller unit and the ST31 secure element. The MCU is used as a “non-secure” part controlling USB communication, control buttons, device’s screen and communicating with the Secure Element. The secure element is the protected part of the device with a certified IC designed to be resistant to physical attacks. The secure element has 320KB of flash memory which is used by the BOLOS TEE (trusted execution environment) and the wallets (user applications) to store the code and data including most critical assets like private keys. Most of the code running on the device is open-source except the TEE OS code. The device is protected with a PIN code setup by a user on the first boot and in case the user PIN entered three times incorrectly the device will be wiped. After the wipe it will be reconfigured with a new PIN.

Insufficient checks

The first four vulnerabilities discovered in the Ledger Nano S refer to errors in the device operation that can be used to reveal certain portion of the device’s firmware and user data, that was meant to be protected. The vulnerabilities do not lead to an immediate compromise of secrets meant to be protected. For example, vulnerability V1 allows to dump 8 kilobytes of firmware via an attack known as dereferencing the null pointer.

Vulnerabilities V2, V3 and V4 lead to partial disclosure of a device’s memory, including ROM, flash and RAM memory, via certain system calls. The vulnerabilities can be used in order to learn more about memory of other wallet applications and the operating system and reduce entropy of the secret key. The vulnerable system calls could be used as oracles which given an arbitrary address would return different exceptions depending on the content of the memory at the address. In case an attacker knows the location of a secret key of another wallet application’s secret key he can reduce the entropy of the key by using the system call to get knowledge about the key byte values. Again, this does not cause immediate loss of secrets, but could be analyzed further and, perhaps in combination with other attack methods, help defeat the security mechanism. In a device that is positioned as a secure storage for highly valuable data, even these (arguably) small code errors have to be eliminated.

Breaking application isolation

Ledger Nano S implements a Trusted Execution Environment (TEE) on the secure element which includes the operating system itself and wallet applications sharing flash memory of the secure element. The operating system has higher privilege level than the wallet applications and the code and data of the operating system has to be isolated from the installed wallet application. The wallet designed in such a way that third parties can easily create wallet applications for new cryptocurrencies and share the application with users to install the applications on their hardware wallets which makes the device more versatile and at the same time more vulnerable since an attacker can create a malicious wallet application which accesses other wallet applications or the OS and steals their secrets. To ensure this is not possible wallet applications have to be isolated from each other and the operating system.

Vulnerability V5 (this time the one with direct potential damage) breaks the TEE security by installing a special application for debug purposes. When a debug flag is set, seemingly because of misconfigured memory protection unit this application can read data from other secure containers. Unlike errors V1-V4, this one is a real vulnerability. When exploited by an attacker – for example an adversary that has gained physical access to a device – it leads to a full compromise of certain apps. Fortunately, not all of them: the way some applications were designed makes some of them less affected by the vulnerability, for instance the private key of the BitCoin wallet application remained safe, but a key from a Monero digital wallet as well as U2F application secret key could be stolen.

In fact, this vulnerability can be utilized not only in a device theft scenario. It was discovered that resetting the wallet does not clear the secure user data (vulnerability V6). On a Ledger Nano S the wallet is reset or locked when a wrong access PIN is entered three times. The vendor assumes that resetting a device by entering the wrong PIN allows a user to dispose of or resell a digital wallet. In fact, the reset procedure erases the BIP39 passphrase used to derive private key. In some cases (Bitcoin storage app) it is enough to protect the private key even if it is preserved in an encrypted form after a reset. But a combination of V5 and V6 allows an attacker to steal a user’s Monero wallet or U2F key after the device was reset.

Compromising the supply chain

The final discovery (V7) allows an attacker to install a rogue application on a Ledger Nano S before a device reaches its owner. Once secrets have been uploaded to a digital wallet, the rogue application can potentially be used to steal sensitive information, even without a physical access to a device. The rogue app could be a modified Bitcoin app with malicious functionality. In a normal situation modifying the code of an application leads to a clear warning displayed on a screen of a digital wallet.

What we have found is that Ledger allowed enrollment of CustomCA keys to simplify the development process. Self-signed app therefore does not display a warning, which enables the installation of a rogue app before sending a device to a customer (either by reselling a used digital wallet online or attacking the retail supply chain in another way).

Is this digital wallet secure?

First, we would like to praise Ledger’s active communication and support when the findings were reported earlier this year. This research does not try to replace a full security audit of a device. The issues were found when a routine TEE evaluation procedure was applied to the device, something that Riscure does for many customers on a regular basis. We are used to finding serious problems during the first round of such evaluations, although the goal here is not to break a device, but to help a vendor to fix or mitigate the issues. This research was conducted during free time and does not aim to replace a full review. The aspects of hardware security were not even considered, and for a secure storage of sensitive information it is highly recommended.

The slides

This research was presented on August 8, 2018 at BlackHat USA by Alyssa Milburn. Below you can find the slides from this presentation, with additional technical details. You can download the slides in PDF format here.