Creator of Cobo Vault
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:
This article will first propose improvements for technical security then share some thoughts on human error avoidance.
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.
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:
But there are still 3 functions that can’t be open sourced. These functions are realized by the original “design” of the SE:
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.
Without deeply diving into BIP 174 which defines PSBT, from this we can tell that there are 2 main PSBT scenarios for PSBT.
For future hardware wallets, PSBT support is a must.
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:
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.
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.
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.
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.
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:
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.
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!
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:
(Disclaimer: The Author is the Founder at Cobo Vault)