9 Essential Improvements for a More Secure Hardware Wallet

Numbers from late 2019 say that the number of bitcoin owners in the US went up 81% compared to 2018. There are now 36.5 million people in the US who own some form of crypto asset. With this big increase in usage, security has clearly become a problem for users.

When talking about security, the most common advice you get is to use a hardware wallet. 

The security of a hardware wallet can be broken down into 2 aspects:

1. First is technical security, which the Bitcoin community has discussed a lot. This includes how to prevent man-in-the-middle attacks, side-channel (physical) attacks, supply chain attacks, and so on from a technical point of view.
2. The second big aspect of security we can’t ignore is human error. Estimations say at least 4 million bitcoins have already been lost forever because of human error. If we take a close look at Bitcoin’s development history, we can see some means of avoiding human error. For example, HD wallets are making an effort to avoid managing hundreds of private keys and the recovery phrase to reduce the likelihood of people making mistakes when writing down a random string for their private key. 

This article will first propose improvements for technical security then share some thoughts on human error avoidance. 

Completely Air-Gapped

We all know that the basic logic of a hardware wallet is that it isolates your private keys from the internet. How the hardware wallet connects to the companion application/device is the key here. It determines how “air-gapped” your hardware wallet is and how costly it is for a hacker to steal your assets.

Strictly speaking, “air-gapped” is a relative concept. It measures how interactive your hardware wallet is with the companion app. Nowadays there are 4 main solutions - USB port, Bluetooth, Micro SD card, or QR codes. USB or Bluetooth connects interactively, which brings a larger attack surface. Micro SD cards or QR codes are more air-gapped solutions. With these data transmission methods, you can even easily verify what messages the app is sending into your hardware wallet and what is being sent out. 

Another big advantage of Micro SD card or QR code data transmission is that the connection is so “physical” that it’s much easier to integrate the hardware wallet with a 3rd party companion app. Also, neither have the compatibility/connectivity problems of Bluetooth or USB. The hardware wallet can just function as a “signer” which only does the signing job.

Secure Element

There's been a lot of controversy about whether a hardware wallet should use a Secure Element. Some people are saying that Secure Elements are verified by the government. The bitcoin community does not trust the governments, so why should it trust Secure Elements?

You don’t need to trust the government's verification to trust a Secure Element. You can actually verify the legitimacy of the Secure Element yourself.

How to Verify a Secure Element Operations？

I know the community seems to have come to a consensus that a Secure Element (SE) can’t be open source. But the truth is - it depends. Mostly it depends on your bargaining power with the Secure Element manufacturer. While we can’t open source the design and base code of the Secure Element because it's the IP of the SE manufacturer (general purpose MCUs can’t open source these either), what we can do is open source the firmware of the SE.

With open source SE firmware, you can easily verify:

1. How the recovery phrase and master private key are generated from entropy
2. How child private keys and public keys are derived/generated
3. That the signing procedure happens entirely within the SE
4. Your private keys never leave the SE

But there are still 3 functions that can’t be open sourced. These functions are realized by the original “design” of the SE: 

1. Random number generation - TRNG
2. Cryptographic algorithms like ECDSA
3. How it prevents physical attacks (side-channel attacks)

TRNG can be verified by running a test like FIPS 140-2. Check out Trezor's results of running a FIPS 140-2 test for STM32’s TRNG (note: the SE must be able to give raw analog entropy to perform this test). You could also allow user supplied entropy in the form of dice rolls.

For cryptographic algorithms like ECDSA, you can easily run a test on the SE cryptographic algorithm to see whether you get the right results.

In terms of physical attacks, it’s easy to tell from hardware wallet attack history that an SE significantly raises attack cost when compared to a general purpose MCU. Security is a relative rather than absolute concept.

Above all, if the firmware of an SE is open source, all key operations can be proven or verified.

PSBT Multisig Support

Without deeply diving into BIP 174 which defines PSBT, from this we can tell that there are 2 main PSBT scenarios for PSBT. 

1. Coinjoin, which helps people better protect their privacy from being tracked by on-chain transaction analysis. 
2. PSBT aligns the “protocol” between different wallets, which makes it possible to process multisig transactions between different wallets. This avoids single point failure on a single wallet and exponentially raises the cost of breaking someone’s multisig system to steal the assets.

For future hardware wallets, PSBT support is a must. 

Build Your Own Hardware (BYOH)

BYOH is a great way to minimize your trust of hardware wallet vendors. 

A common way of letting people BYOH is to open sourcing the whole product including the schematic (circuit diagram). However there are 2 problems with doing this:

1. It lowers the cost for hackers to make fake devices to steal people’s bitcoin. And this is indeed what has happened.
2. Very few people have developed the enough skills set to build hardware wallets from a schematic level. It requires both hardware skills and software skills.

So a better solution for letting people build their own hardware wallets is to sell the Secure Element development board to the user. As the Secure Element is the most important component in the hardware wallet, with the SE development board, software engineers may be capable of turning the device into their own hardware wallet.

The above 4 improvements are on the technical security side. We applaud ColdCard for taking some big steps along technical security lines with Micro SD card air-gapping and PSBT support. 

The pity is, for the past few years, most of hardware wallet vendors’ work has focused on technical security. For example, the latest controversy on social media about hardware wallets is whether to use a Secure Element, but few people are talking about hardware wallet security from a user experience perspective, which can help avoid human error. This is extremely important as hardware wallets are no longer made for just advanced users but also for a mass market.

Before diving into human error avoidance, I want to emphasize that “human error” is a relative concept that can’t be applied to mass users and advanced users at the same time. This means that some improvements that avoid human error for mass users may also reduce flexibility for mature users.

Big Touch Screen

Users have been suffering from the tiny buttons and screens of a variety of kinds of hardware wallets for a while. These inconveniences may lead to human error over the long-term. Take Passphrase as an example. Because the typing experience is so bad, most hardware wallet vendors only ask users to input their Passphrase once without asking for a second input to check the integrity of the Passphrase. However, typing a faulty passphrase may cause your bitcoin to be sent to a wrong address. Obviously, adding a big touch screen not only vastly improves the typing experience, but also enables more prompts that can guide the user to avoid human error. 

More importantly, a big screen can also close some attack surfaces. For example, you can  show a QR code on your hardware wallet to receive bitcoin rather than using the companion app, which is more vulnerable to remote attacks.

This may sound not that valuable for mature users. But as I said, as Bitcoin adoption increases, we must take newbie users into consideration.

Protection Against Malicious Firmware

Open source is very important in this decentralised world. But from a human error perspective, open source may also open new attack surfaces.

We know that open source hardware wallets all allow users to customize the code and upload it to the device for their own purposes.

Even though users are given clear warning when they attempt to install unofficial updates, there are still attackers who figure out a way to get past, sometimes even by tricking people who ask hardware wallet questions on Reddit or Telegram into installing malicious firmware. Some people may find this hard to believe, but as hardware wallets play a more and more of an important role in this community, they are no longer only creating for mature users, but also newbies.

Protecting normal users from malicious 3rd party firmware doesn’t have to mean sacrificing geek users’ flexibility to customize code. A better solution is that hardware wallet vendors sell a separate version for geek users who want to modify the code and upload it themselves.

There should be strong warnings at purchase points so that most users do not buy it. Furthermore, the device should be delivered without any workable firmware so that the user has to compile a special version, which would be signed with another key and uploaded to the device.

This can be taken a step further so that people can change the key pair to their own so that only they can sign their own firmware and upload it to their device.

Modular Battery

As with all electronic products, the battery is THE most vulnerable part. Nowadays mobile phones are like FMCG products. This is in contrast to hardware wallets, which are something you may keep around for decades or even pass on to your heirs. If a hardware wallet stores your life savings, you might only touch it every 6-12 months.

Now more and more hardware wallets support Bluetooth, causing a transition from USB-powered to device batteries. If Bluetooth data transmissions are used, hardware walles should support power banks for additional battery supply or AAA or AA batteries.

Some people may say, “it’s OK if my hardware wallet no longer works because of battery failure, I’ll just buy a new one and recover it with my recovery phrase.” Be careful, the best situation for your recovery phrase is once you hide it you never need to take it out. Every time you take it out, you are adding extra risk from exposure or theft.

Mobile Companion App

Now most hardware wallet companion apps (like Ledger Live or Trezor’s web app) are desktop or web apps. Because desktop devices and operating systems are more customizable, desktop and web apps have benefits like enabling Tor networks. You also can easily manually verify the signature of a desktop app. These benefits definitely meet some premium needs for advanced users. For normal hodlers, however, a mobile companion app has a smaller attack surface because:

1. Applications run on mobile phones are isolated by sandbox. They can only access their own data.
2. Full file system encryption is enabled by default.
3. User permissions are highly limited for mobile compared to desktop apps.

Normal users are not good at protecting themselves from malicious links, which are huge sources of human error. Because of the above 3 characteristics, mobile apps are much less likely to make users suffer from phishing and other attacks.

Mastering Bitcoin author Andreas Antonopolous also favors using mobile devices.

Available for Offline Purchase

Most people are not good at protecting their online privacy. If we take online purchasing behaviour as an attack surface, it would be good for hardware wallet vendors to open offline purchasing channels. If payment in cash or bitcoin is accepted rather than just credit cards, that would be even better!

Final Words

Building a hardware wallet is not easy. There is no 100% secure product on the earth. What we do is build up the attack cost for hackers to steal your assets. 

As for what comes after these improvements, two things I am really looking forward to in the future of hardware wallets are: 

1. Bypassing any general purpose MCU or ARM chip, the Secure Element controls and communicates with all the I/O, which would close the biggest attack surface on a hardware wallet. This is realizing “trust minimization” of the Secure Element.
2. Fully open source Secure Element, which would bring to a whole new level of “trust minimization”. Happy to see Google is working on that.

Special thanks to Matt Odell and Lazy Ninja for their feedback.

(Disclaimer: The Author is the Founder at Cobo Vault)