Building a hardware wallet to protect your assets is very much like making a wooden bucket to hold water. Wooden Bucket Theory states that bucket capacity is determined by a bucket’s shortest stave. The same is true of a hardware wallet, where focusing on several aspects to the neglect of others leaves you with vulnerabilities that negate the effectiveness of the entire device. In security, this is known as avoiding a single point of failure — it only takes one thing to go wrong for you to lose all your coins. In providing the community with solutions that allow them to achieve financial sovereignty, it’s also important to view the user experience holistically and account for all aspects of the storage process, including the potential for human error which new users may be more prone to.
Maximizing Attack Cost
Nothing on this planet is unhackable — to a hacker, it’s just a matter of cost vs profit. What hardware wallets do is implement mechanisms that effectively build up the attack cost without significantly raising costs for the consumer.
Hardware wallets isolate your private keys from the internet because physical attacks cost significantly more than remote attacks. In terms of how air-gapped your hardware wallet is and how costly it is for a hacker to steal your assets, it’s crucial how the hardware wallet connects to a companion app. Using QR codes or microSD cards for data transmission has significant advantages for air-gapping your keys compared to USB and Bluetooth, which have larger attack surfaces because they are interactive connections.
Supply chain attacks are dangerous partly because the only protection most hardware wallets have tamper-proof packaging, which does not drive the cost of attack up prohibitively for a sophisticated attacker. Cobo Vault has implemented similar packaging measures to other hardware wallets, but has also introduced a Web Authentication process, which is much more meaningful in raising costs for an attacker.
Physical attacks are frequently disclosed in the hardware wallet industry. We adopted a Secure Element, the standard defense mechanism against physical attacks, but also implemented another security mainstay of the traditional banking industry — a self-destruct mechanism that triggers upon disassembly. We applied this mechanism commonly found in ATMs and credit card terminals so that all the sensitive information like private keys is erased if someone tries to open the device up (be aware that the device will be bricked if you do this yourself).
Centralized systems are mostly built on trust, which is a model of security that is continually threatening collapse. This is apparent with incidences like the fall of Arthur Anderson during the Enron scandal and everywhere today in the disasters of the coronavirus pandemic.
Satoshi Nakamoto raised the flag of decentralization and started a movement to build a trustless system for the ultimate safe asset. In order to provide a product that provides people with true financial sovereignty, it’s necessary to make it as trustless as possible.
While it may be sobering, it should be said that achieving completely trustless hardware is almost impossible if we look at the manufacturing process from the bottom up: silicon — chip & circuit board — chip base code — chip firmware — wallet application. One way to minimize trust is to use QR code data transmission to allow users to easily verify all the information that goes in and out of the hardware wallet.
Another major step we took was to release the hardware wallet industry’s first open source Secure Element’s firmware. While weren’t able to open source the design and base code of the Secure Element because it belongs to the IP of the manufacturer (general purpose MCUs can’t open source these either), the firmware code does allow you to verify all important cryptographic operations. We chose a Secure Element vendor that would allow us to release the firmware code, which we hope will help end the controversy over whether Secure Elements are ultimately beneficial to security.
With open source Secure Element firmware, you can easily verify:
- How the recovery phrase and master private key are generated from entropy
- How child private keys and public keys are generated/derived
- That the signing procedure happens entirely within the Secure Element
- Your private keys never leave the Secure Element
There are still three functions that can’t be verified because they are realized by the base code and chip design:
- Random number generation (TRNG)
- Cryptographic algorithms like ECDSA
- 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 Secure Element must be able to give raw analog entropy to perform this test). We also allow user-supplied entropy in the form of dice rolls. Users can easily bypass the TRNG when generating their wallet. Cryptographic algorithms like ECDSA can be verified by running diagnostic tests.
In terms of physical attacks, hardware wallet attack history clearly demonstrates that a Secure Element significantly raises attack costs when compared to a general purpose MCU. Again, security is a relative rather than absolute concept.
Open sourcing is not a one-time thing but a long-term project. Our latest milestone was open sourcing the device schematic (circuit diagram) and operating system layer code.
We are also embracing PSBT (under development now) so you can build up multisig with other hardware wallet brands to minimize your trust of any single brand and avoid having a single point of failure.
Taking Human Error into Consideration
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. More and more newbie users are getting into this area, which will inevitably amplify the damage done by human error, already estimated to be at least 4 million bitcoins that have been lost forever.
The pity is that for the past few years, most hardware wallet vendors have invested in technical security. While we debate whether hardware wallets should use Secure Elements, we tend to forget to think about hardware wallet security from the perspective of a basic user’s experience. But as hardware wallets are no longer made for just advanced users, we can no longer ignore the mass market.
When we designed Cobo Vault, human error was taken seriously and influenced the following decisions:
- Mobile-only companion app: The majority of people are not alert to the threat of phishing attacks, and may be tricked into downloading malicious companion apps if they are on desktop. Tradeoff here is that Tor network is not easy to implement on mobile devices, which are in general not as flexible and customizable as desktops. However, we will make Cobo Vault compatible with Electrum, Wasabi, and other third-party wallets that advanced users can use as their watch-only wallets instead of our mobile companion app.
- A 4-inch touchscreen: Enables more effective prompts and a better typing experience. For example, by providing space for a second input field, a large touchscreen can significantly lower the risk of typing in the wrong passphrase. A big screen also allows you the versatility to receive funds and directly storing them without ever touching the internet — all you have to do is present a freshly generated QR code to the sender in person.
- Firmware upgrades exclusively signed by us: Counters the potential for social engineering attacks to trick users into installing malicious third-party firmware. Warnings to caution users about third-party firmware won’t cut it because not all users are educated or cautious enough to understand the threat. To accommodate advanced users who want to customize their own firmware, we will later release a cypherpunk version of Cobo Vault. The device would be delivered without any workable firmware so that the user has to compile their own version, which would be signed with another key and uploaded to the device. This can be taken a step further so that users can change the key pair to their own so that only they can sign firmware and upload it to their device.
The value of a decentralized system is in avoiding collapse due to any single point of failure. This same core principle applies to the design of hardware wallets, which are only as strong as their weakest vulnerability. When designing Cobo Vault, we try to address this issue meaningfully from as many angles as possible:
- As an essential functioning part of an ecosystem, a hardware wallet should be compatible with as many third-party wallets as possible. Cobo Vault works seamlessly with Specter (BTC), BlueWallet(BCT), MetaMask (ETH), Polkadot.js (DOT) and other software wallets, thanks in part to the interoperability of QR codes. Compatibility with these wallets not only allows you to take advantage of a variety of premium features like multisig, DeFi, Staking, Tor network, and even connecting to your own node, but also gives you the option to choose not to rely on our companion app.
- Cobo Vault allows you to split your recovery phrase into three shares, any two of which can be used to reconstitute the whole phrase. We divide your recovery phrase according to the SLIP39 Shamir’s Secret Sharing backup standard provided by SatoshiLabs, and advise that you store the shares in three separate locations to reduce the likelihood of loss occurring from a single point of failure.
- We use detachable batteries and provide AAA support because most users don’t think about how to properly store device batteries. While the majority of electronic products are not designed for long-term storage, hardware wallets are likely to be used on a different timescale, possibly even that of a lifetime. Hardware wallets should not rely on a single type of power supply as one day it may prove vital to be able to use AAA batteries if the rechargeable lithium battery fails.
- Multisig is the ultimate counter to single points of failure, and we are proud to have embraced it in a big way. For those who are unfamiliar with how pivotal multisig is for security, we strongly recommend you check out his podcast.
Two things we are looking forward to in developing hardware wallets:
- 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 will realize greater trust minimization of the Secure Element.
- Fully open source Secure Element brings a whole new level of trust minimization. Google is working on this.
If we apply the wooden bucket analogy to the entire cold storage process, hardware wallets become just one stave of a larger wooden bucket. Other staves include storing your recovery phrase, protecting your online privacy, choosing a wallet system whose structure balances security and efficiency, and other junctures where things could go wrong. Education on these and other topics is part of our responsibility as a hardware wallet vendor to provide solutions for the community to further their financial sovereignty.
Security is important to look at from all angles, and we appreciate your input on our product. Please feel free to reach out to us on Twitter @CoboVault with your thoughts and questions.