For most of the past year, I have been working at ConsenSys on energy projects which culminated in a spoke aimed at becoming the world’s first blockchain based electric utility called Grid+. One of our focuses is on creating a new system architecture that will allow naive users to safely store and use cryptocurrencies. Through my work I have also had the opportunity to interact with a number of individuals and large organizations that are entering the crypto-space who inevitably arrive at the same question: How should I store my cryptocurrency? What is the safest convenient method for handling crypto? The best answer that currently exists seems to be a hardware wallet. The most popular wallets on the market presently are the Trezor and the Ledger Nano S. There are other wallets, such as the KeepKey, but they are essentially variants of the Trezor. I performed a teardown of both the Ledger Nano S and Trezor wallets, and would like to share those teardowns, as well as the high-level takeaways regarding security. This includes my opinion outlining areas where I see large attack surfaces, but I don’t necessarily know of or purport to have a specific exploit. Also, I did not look at any devices without on device screens because of the dramatically increased vulnerability to MIM attacks.
Hardware
The Trezor
The Trezor is a relatively simple device that is powered by a micro-usb connector. It has a very simple injection molded plastic case with two plastic buttons and an LCD screen. Interestingly, the plastic case is joined together with what appears to be cyanoacrylate or super glue.
The Trezor uses a standard STM32F205 as the only microcontroller which creates a large hardware-based attack surface. This is a very common standard ARM Cortex M3 32-bit processor. This is not considered one of ST’s secure MCUs nor is it any sort of secure enclave. This general purpose MCU is where the private keys are generated and stored. Due to these reasons, the Trezor does not have a common criteria security certification.
The Ledger Nano S
The Ledger Nano S is also powered by a micro-usb, has two user input buttons, and an on-board screen. The biggest difference between the Trezor and the Ledger is the Ledger has two microcontrollers instead of just one. The first microcontroller is the STM32F042K and the second microcontroller is the ST31H320. The STM32F042K is very similar to the STM32F205 used in the Trezor with the notable exception that it has an internal rather than external clock. More interestingly, the Ledger has a proper bank grade ST31H320 secure enclave where the wallet’s private keys are stored. The ST31H320 finds itself already used in many other applications including banking, identification, and pay TV. Further, it meets EAL6+ common criteria security standards. The combined ST31/STM32 architecture has a lower but commendable EAL5+ certification. In addition to securely storing private keys, the secure enclave is able to store a device key which provides a high degree of assurance that the ledger device is not counterfeit and has not been compromised in the supply chain.
Comparison
Potential Vulnerabilities
As I start to go through what I perceive to be the relative vulnerabilities of each system, I will outline some basic assumptions about what is possible. The first assumption is that whatever computer the hardware wallet is connected to can or has been compromised in one or more ways. I will not look specifically at what mechanism or malware is used to compromise the device, but rather just assume that it is possible. Second, I will also consider ways of compromising the funds under the assumption that an attacker can come into possession of the device either before or after it is initialized by the user. I believe that the above assumptions are a good starting point, because the purpose of the hardware wallets, at least as I see them, is to help mitigate security vulnerabilities assuming these assumptions are true. Furthermore, if we reject the assumption that a wallet is connected to a compromised computer, the need for the hardware wallet is obviated because the computer could be used instead.
The $800 Man-in-the-Middle Attack
Now although the ledger Nano S has an on device screen, it is still vulnerable to MIM attacks. The reason for this is that it only displays 8 digits of the recipient address. This 8-digit transaction confirmation can be defeated for a relatively small economic cost. Also, note that the display of 8 digits of the recipient address is not only true for Ethereum, but also for Bitcoin and Litecoin as of MCU.
Correction: In the most recent firmware 1.3.1 full Bitcoin addresses are shown, so this does not apply to devices with current firmware and the current Ledger Bitcoin Wallet app performing Bitcoin transactions. However, with firmware 1.3.1 and Ledger Ethereum Wallet 1.0.19 only partial (8-digit) Ethereum addresses are still displayed and this vulnerability still exists.
The current cost of generating an 8 position specific case sensitive address using the vanity address generator vante.me is approximately $800. Now vante.me is designed to create addresses which have human readable text at the beginning to make the address more recognizable, but the computational cost for splitting the string to 4 deterministic characters at the beginning and 4 deterministic characters at the end is the same.
Therefore, if you connect you Ledger Nano S to a compromised computer and use it to move large amounts of money between one or more accounts on a regular basis, you are vulnerable to this attack. For example, let’s say that you have an exchange account that you move money to on a regular basis. If your machine is compromised the malicious party will know which addresses you typically send funds to as well as amounts. The attacker could then spend the computational power necessary to create addresses that are apparently identical (8 matched characters, $800 per address) or nearly apparently identical (7 characters instead of 8, $30 per address) and then wait for you to create your next large transactions. At that point instead of asking your connected ledger to sign the transaction using your account, they can substitute it for their account, and you will be none the wiser when you confirm the transaction on the device.
Interestingly, the Trezor does not suffer from this attack because it displays the entire recipient address on the device screen before signing a transaction. This also elucidates an interesting point that at least 10 digits (~$3.1M attack) of an address (preferably the whole address) need to be verified before sending a large transaction. Also, I would mention here that if you practice using single use addresses when sending money from your Ledger, this MIM can be prevented. The above assertion made assuming an attacker would not have sufficient time to generate a spoofed address between learning the receiving address and the user sending funds.
USB Device Firmware Upgrade
Both the Ledger and the Trezor are upgradable using something similar to ST micro’s USB Device Firmware Upgrade (DFU). The USB DFU allows the firmware of the device to be upgraded via the USB port and a device manager on the connected computer. Unfortunately, there are potentially a number of attack vectors that are opened up by being able to remotely flash the firmware via the USB.
There have been a number of successful attempt to use just the DFU to remotely dump the memory of the STM32F family of microcontrollers. So what does this mean? For the Trezor, it is a big deal because it would potentially allow a hacker to pull private keys from the device remotely. For the Ledger it is less of a problem because the private keys are not stored on the STM32 but rather the ST31 secure enclave. Therefore, even if the memory of the STM32 is copied remotely, the private keys would still be safe on the ST31.
In addition to potentially enabling a remote memory dump of the STM32, the USB DFU could potentially allow a malicious actor to re-flash the device with malicious code during an upgrade. Although, both the Ledger and Trezor provide a check-sum to verify on the device screen during the upgrade, this could easily be spoofed by malicious code. For this to potentially work, your computer would have to be compromised at the same time that you are upgrading the firmware on your wallet. If the Trezor was upgraded with malicious code, the attacker could effectively gain control of the funds. In the case of the Trezor, this could be through simply exposing the private keys. In the case of the Ledger, the private key would still not be divulged nor would the attacker be able to create malformed transactions because of the secure enclave.
Bypassing PINs
The next set of vulnerabilities I would like to address is what would happen if the hardware device actually fell into the hands of a malicious party. Both the Trezor and the Ledger implement a reset feature if an incorrect pin is entered 3-times. This prevents a thief from getting possession of the wallet and using a brute-force based attack to determine a pin.
The funds would be safe because they are protected by the pin, right?
There was a presentation at DEF CON 25 were Cryptotronix demonstrated that the Trezor STM32F205 can be glitched by using both Vcc and clock glitching attacks. This leads to vulnerabilities with the Trezor that would allow a hacker to obtain private keys without needing to know a pin. There is actually a blog that gives step-by-step instructions on how to do this without any sort of specialized equipment, that also promises to release source code in the future.
What about the Ledger? The Ledger is less vulnerable to this type of attack because it has an internal clock as well as a secure enclave. Assuming that Ledger was smart, the device pin is required by the secure enclave prior to the device signing a message. This would prevent the Ledger from having funds compromised even if the STM32F042K was successfully attacked.
Supply Chain
Physical mechanisms of device “security” appear to be a theme with the trezor due to potential attack vectors associated with device tampering in the supply chain. In addition to the super glue holding the housing together, the box of the Trezor came “sealed” with holographic stickers which also appeared to be an attempt at an anti-tamper mechanism. The efforts that Trezor is going through to ensure the Trezor is not tampered with prior to receipt by the end user should already throw up some red flags. The reason that Trezor adds these “security” features is due to the fact they aren’t able to ensure that when a new device queries there website that it is actually a device they created and programmed.
If the Trezor were intercepted by a malicious party prior to being delivered to the end-user, the malicious party could open the Trezor and use the conveniently provided programming header to flash a malicious version of the Trezor software. This is further facilitated by the fact that all of the Trezor’s firmware is open sourced. Additionally, since the Trezor device key is stored on the STM32, it is also possible that the malicious actor could re-insert the key when they re-flash the device. This would make it impossible, even for Trezor, to ever know if the device was tampered with or even if it is genuine.
The Ledger doesn’t suffer from these issues because the secure enclave is able to secure a device key that is used by Ledger to confirm the authenticity of the device. This vastly decreases the ability of successfully infiltrate the the supply chain with knock-off or tampered-with devices.
Recovery Phrase
The most vulnerable piece of the security puzzle is likely the recovery phrase. The recovery phrase being the 12–24 word series that allows the reconstitution of private keys using BIP39. Unlike the hardware wallets that provide some barrier to malicious use or hacking, the recovery phrase exists in plain text. At Grid+ we like to describe this vulnerability as the sock drawer attack owing to the fact that many people have likely stored their recovery phrase in a sock drawer at one point.
This is likely the most vulnerable piece of the hardware wallet story. It is also especially ironic, that if a person wants to secure the recovery phrase it may likely end up in a safety deposit box at a bank. After almost a decade of working to create distributed peer-to-peer money, the recovery phrase brings us right back to where we started with our money in a bank. This really just highlights the fact that cryptocurrencies are bearer assets. Much like gold, their security, at least currently, depends upon the user’s ability to physically secure them or obfuscate their location.
There are ways to increase the security of the recovery phrase such as breaking it up and storying with multiple trusted counterparties. Or the recovery phrase can also be encrypted, or used in conjunction with a pass phrase.
Surveillance
The last piece to cover at least briefly is the idea of surveillance. If a malicious actor can obtain your PIN for your hardware wallet, all bets are off. There are remote mechanisms of surveillance were the webcam of a computer can be turned on and monitored without the knowledge or permission of the user. There are also more direct ways of surveillance in that the environment in which you live or worked could be compromised by a hidden camera. Edward Snowden was clearly paranoid about on premise surveillance, demonstrated by his use of a blanket to conceal entering his password. It may not seem like the most likely threat, but if there is a large enough incentive and a known target, this is likely the simplest attack vector.
Summary
What conclusion do we draw from the above? The following is a summary of the potential vulnerabilities of both the Trezor and the Ledger. If it wasn’t for the MIM vulnerability, the Ledger would be the clear winner. However, this issue complicates any decision. If Ledger were to listen to community feedback and include the full recipient address, or at least 10–11 characters, rather than only 8 characters, I would be much more comfortable proclaiming their device superior.
Update: Prompted by this article BTChip (Ledger) has indicated that they will be making an update to their wallet app to display full addresses. Once this is done, I would recommend the Ledger over the Trezor.
Is there anything else that we can do to increase the security of storing cryptocurrencies? Yes. Multi-signature wallets. Multi-signature wallets make it so that n-of-m keys must sign a transaction before moving funds. In its simplest form it is 2-of-3 keys. For Bitcoin and bitcoin variants (e.g. Litecoin), this is absolutely how I would recommend to store institutional funds. The technology is developed, has a long history of successful usage, and both Trezor and Ledger offer some form of multi-signature support. Furthermore, having multiple individuals needing to sign transactions before moving funds creates internal controls that are normally desirable in a company.
Unfortunately Ethereum doesn’t yet natively support multi-signature wallets. Any multi-signature wallet on Ethereum is based on a smart contract and that smart contract could have vulnerabilities such as what recently happened in the parity hack. Therefore, in terms of Ethereum, I would recommend waiting until the implementation of EIP86 prior to using multi-sig to securely store ethereum or ERC20 assets.
Hopefully, once the Grid+ agent device hits the market, we will enable individuals to store cryptocurrencies in an always online, secure manner. Until then, practice constant vigilance and realize that we work and exist in a byzantine environment. There are no perfect solutions, and we encourage all users to be educated on the benefits and potential detriments of all solutions that currently exist.
