On Friday (28 December 2018), cryptocurrency security firm Ledger, the maker of the very popular Ledger Nano S cryptocurrency hardware wallet, explained via a blog post that the “wallet.fail” presentation at the 35th Chaos Communication Congress (35C3) had not managed to demonstrate any “practical vulnerabilities” and that cryptoassets protected by Ledger devices “are still secure.”

At the 35C3, a four-day annual hackers’ conference (held 27–30 December 2018 in Leipzig, Germany) organized by the Chaos Computer Club (CCC), a team of security researchers—Dmitry NedospasovThomas Roth, and Josh Datko—gave a presentation titled “Wallet.Fail: Hacking the Most Popular Cryptocurrency Hardware Wallets” that looked at “architectural, physical, hardware, software and firmware vulnerabilities” they had found while trying to hack devices from popular cryptocurrency hardware wallet vendors such as Ledger and SatoshiLabs (the maker of the Trezor wallet).

During this presentation, the researchers explained that their goal was to demonstrate four types of attacks against popular cryptocurrency hardware wallets:

  • Supply Chain Attack (where you try to manipulate the device before it reaches the customer)
  • Firmware Vulnerability 
  • Side-Channel Attack
  • Chip-Level Vulnerability

Ledger’s blog post starts by saying that no “critical vulnerabilities” had been found on Ledger devices:

“Concerning Ledger, they presented 3 attack paths which could give the impression that critical vulnerabilities were uncovered on Ledger devices. This is not the case.

In particular they did not succeed to extract any seed nor PIN on a stolen device. Every sensitive assets stored on the Secure Element remain secure.

Don’t worry, your crypto assets are still secure on your Ledger device.”

Next, Ledger says that it has two problems with the work of these researchers:

  • Lack of Responsible Disclosure: “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 a vulnerability is 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.” It is important to note that the CTO of SatoshiLabs, Pavol Rusnak, has also confirmed via Twitter that his firm was not informed via its Responsible Disclosure program:
  • None of their findings concerning Ledger devices are practical or realistic vulnerabilities.

Attempted Attacks on the Ledger Nano S Hardware Wallet

“In short, they demonstrated that physically modifying the Ledger Nano S and installing a 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). “

Hardware Implant

  • Ledger says this was “a mix of software attacks, supply chain/evil maid attacks, and social engineering.” 
  • Attack 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…. the attacker puts a 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.”

Ledger says this attack scenario is impractical since it requires

  • “Physical access to the device to modify it”
  • “Installing a 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”

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.”
  • Although they “succeeded to install a custom firmware on the MCU.” They did so using “a bug in the firmware update function,” which has been fixed “in the next firmware version.” The firmware they installed “runs snake on the MCU in Bootloader mode.” However, “the Secure Element does not even boot.”
  • A way to “bypass the MCU check” was mentioned, but the exploit was not demonstrated.

Attempted Attacks on the Ledger Blue Hardware Wallet

  • “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.”
  • “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.”

 

Featured Image Courtesy of Ledger