Ledger, the security and infrastructure solution company for cryptocurrency and blockchain responded today to claims made at the 35th Computer Chaos Congress event by Dmitry Nedospasov, Thomas Roth and Josh Datko in their presentation called wallet.fail, where they tried to demonstrate that bitcoin and cryptocurrency hardware wallets are vulnerable to several types of attacks.
Concerning Ledger, they presented 3 attack paths which could give the impression that critical vulnerabilities were uncovered on Ledger devices…
Ledger stated: This is not the case.
See their full response below:
In particular, they did not succeed to extract any seed nor PIN on a stolen device. Every sensitive asset stored on the Secure Element remain secure.
Don’t worry, your crypto assets are still secure on your Ledger device.
Security research
As security professionals, we are more than happy to see people trying to challenge the security of our products. This is the way to improve security. But, in the security world, the usual way to proceed is responsible disclosure. This is the model in which vulnerabilities are disclosed only after a reasonable period of time that allows for the vulnerability to be patched as well as to mitigate risks for users. In this spirit, we have a bug bounty program rewarding the security researchers for their findings. We regret that the researchers did not follow the standard security principles outlined in Ledger’s Bounty program.
“We equally feel that the findings did not provide practical vulnerabilities, as we will discuss underneath.”
What has been presented on Ledger Nano S
In short, they demonstrated that physically modifying the Ledger Nano S and installing malware on the victim’s PC could allow a nearby attacker to sign a transaction after the PIN is entered and the Bitcoin app is launched. It would prove quite unpractical, and a motivated hacker would definitely use more efficient tricks (such as installing a camera to spy on the PIN entry).
In more details, here is what has been presented:
Hardware Implants
This is a mix of software attacks, supply chain/evil maid attacks, and social engineering. In this scenario, the attacker gets the device of his victim, opens the box and adds a hardware implant. This piece of electronics is in charge of pushing the confirmation button (electronically) when triggered by radio frequency from the attacker.
Then, the scenario is the following: the attacker modifies the device as explained, puts malware on the victim’s PC which will trigger a transaction and waits for the victim to enter his PIN and launch the Bitcoin app. At this very moment, the malware on the PC triggers the transaction. The attacker, who is in a side room, will push the confirmation button with his remote control.
This scenario requires:
- Physical access to the device to modify it
- Installing malware on the victim’s computer
- Physically waiting in a side room with an antenna for the victim to enter his PIN and launch the Bitcoin app.
It is quite an unpractical scenario, whereas it might be easier for a motivated attacker to install a camera in the room to look for the PIN entry.
We have designed the Nano S to be easily openable, so you can check the integrity of the device yourself. More information can be found here: https://support.ledger.com/hc/en-us/articles/115005321449-Check-hardware-integrity
MCU Check
In this scenario, they tried to perform a supply chain attack by bypassing the MCU check, but they did not succeed. The MCU manages the screen but doesn’t have any access to the PIN nor the seed, which are stored on the Secure Element.
- They succeeded to install custom firmware on the MCU. This is actually a feature: the JTAG (debug interface) is still active on this chip, so it’s possible to load the MCU using JTAG and run it in bootloader mode. However, they loaded it using software which was not featured. They used a bug in the firmware update function to perform this. This bug has been solved in the next firmware version. Nevertheless, this bug does not allow anything more than the JTAG.
- Their firmware runs snake on the MCU in Bootloader mode. This means that you have to push the left button at boot and the Secure Element does not even boot. There is actually a version of snake which runs on the SE available on our nanos-app-snake GitHub repository.
- They mentioned they found a way to bypass the MCU check, but were unable to demonstrate the exploit.
What has been presented on Ledger Blue
Side Channel on the PIN of the Ledger Blue
During the demonstration, a proof of concept side channel attack on the Ledger Blue was presented. This attack is a bit unrealistic and not practical.
They conducted a Supervised Machine Learning Attack on the PIN entry. When the user enters their PIN, they measure the radio emanation and try to guess which digit has been entered on the screen.
To do so, they first create a dictionary of the 10 different types of emanations for each digit. They performed this phase on a fixed setup where a robot simulates the PIN entry and measures the emanation for each digit.
When the user enters his PIN, they measure this emanation and compare it with the dictionary.
To actually perform this attack, one has to:
- Measure the signal at a very close distance
- Have a high reproducibility. It means that the position of the receiver and attacked device must be exactly the same – the position of the USB cable is also paramount (as it acts as an antenna). If the conditions are not exactly the same, the machine learning classifier won’t work properly.
This attack is definitely interesting, but does not allow to guess someone’s PIN in real conditions (it requires that you never move your device at all).
For such a scenario, we already implemented a randomized keyboard for the PIN on the Ledger Nano S, and the same improvement is scheduled in the next Ledger Blue Firmware update.
Once again, a better side channel would be to put a camera in the room and record the user entering his/her PIN.
Ledger values all attempts to compromise our hardware wallets. We strongly believe that our Bounty program is the way towards continuous security improvements. We are, however, also convinced that responsible disclosure is the best practice to follow in order to protect the end users while improving our products’ security.
