C3Subtitles: 35c3: wallet.fail
back

wallet.fail

Hacking the most popular cryptocurrency hardware wallets

If you suspend your transcription on amara.org, please add a timestamp below to indicate how far you progressed! This will help others to resume your work!

Please do not press “publish” on amara.org to save your progress, use “save draft” instead. Only press “publish” when you're done with quality control.

Video duration
01:01:57
Language
English
Abstract
In this presentation we will take a look at how to break the most popular cryptocurrency hardware wallets. We will uncover architectural, physical, hardware, software and firmware vulnerabilities we found including issues that could allow a malicious attacker to gain access to the funds of the wallet. The attacks that we perform against the hardware wallets range from breaking the proprietary bootloader protection, to breaking the web interfaces used to interact with wallets, up to physical attacks including glitching to bypass the security implemented in the IC of the wallet. Our broad look into several wallets demonstrates systemic and recurring issues. We provide some insight into what needs to change to build more resilient hardware wallets.

Hardware wallets are becoming increasingly popular and are used to store a significant percentage of the world’s cryptocurrency. Many traders, hedge funds, ICOs and blockchain projects store the entirety of their cryptocurrency on one or very few wallets. This means that users of hardware wallets store tens of millions of euros of cryptocurrency on small USB peripherals that costs only a few euros to manufacture. Moreover, many users that trade and speculate in cryptocurrency interact, update, and generate transactions using their hardware wallets on a daily basis.

In this talk we look at the good, the bad and the ugly of hardware wallet security: We will walk through the different architectures of the wallets, look at the different attack vectors and talk about the challenges of building secure hardware before diving in deep finding vulnerabilities in the different wallets.

The vulnerabilities we will present range from vulnerabilities that can be fixed in a firmware upgrade, to bugs that will require a new hardware revision, up to attacks on the microcontrollers themselves, requiring new silicon to be fixed.

Some of the (most entertaining) vulnerabilities will be demonstrated live on stage.

<h2>Classes of Vulnerabilities we will look at</h2>
<b>Firmware Vulnerabilities</b>
Firmware vulnerabilities are vulnerabilities affecting the software that runs on the hardware wallet. Since most wallets provide update mechanisms this class of bug can be patched in a future firmware release.

<b>Software Vulnerabilities</b>
Software vulnerabilities are vulnerabilities affecting the host software that runs on the PC or smartphone and communicates with the hardware wallet. Since most wallets provide update mechanisms this class of bug can be patched in a future release of the host software

<b>Hardware Vulnerabilities</b>
Hardware vulnerabilities are vulnerabilities affecting the device hardware of the hardware wallet. Hardware vulnerabilities are generally incorrectly set configurations of the hardware either during manufacturing or by the firmware. If the configuration is set by firmware these vulnerabilities can be patched in a future firmware release. Otherwise, they are unlikely to be fixed by the vendor.

<b>Physical Vulnerabilities</b>
Physical vulnerabilities are vulnerabilities affecting the hardware design of the hardware wallet. Once the device has been manufactured, hardware vulnerabilities cannot be mitigated and can only be fixed in a future hardware revision of the device. This class of vulnerabilities is unlikely to be fixed by the vendor.

<b>Architectural Vulnerabilities</b>
Architectural vulnerabilities are vulnerabilities affecting the overall architecture of the hardware wallet. These are inherent design flaws in the device and can only be fixed in a major hardware revision, i.e. a new version of the device. This class of vulnerabilities is unlikely to be fixed by the vendor.

Talk ID
9563
Event:
35c3
Day
1
Room
Borg
Start
5:30 p.m.
Duration
01:00:00
Track
Security
Type of
lecture
Speaker
Josh Datko
Dmitry Nedospasov
Thomas Roth

Talk & Speaker speed statistics

Very rough underestimation:
166.2 wpm
886.7 spm
19.4% Checking done19.4%
80.6% Syncing done80.6%
0.0% Transcribing done0.0%
0.0% Nothing done yet0.0%

English: Quality control done until

Last revision: 4 months, 1 week ago

Talk & Speaker speed statistics with word clouds

Whole talk:
166.2 wpm
886.7 spm