We’ve come a long way toward making our product as open source as possible since we last published this article describing why we thought closed source was a safer option for hardware wallets. We are now convinced that an open source product is what will bring the most value to the Bitcoin community, and while no hardware wallet can ever be 100% open source or completely trustless, the highest possible degree of transparency is what is called for in a decentralized world. This article provides a full description of everything we have open sourced, what you can know about Cobo Vault from it, and our philosophy on open source going forward.
What Is Open Source and What Can You Know from It?
When we first published our thoughts on open source just over half a year ago, only the Secure Element firmware was available. Since then, we have moved to open source the hardware design (circuit diagram and BOM), hardware wallet application layer, parts of the hardware wallet operating system layer, and have also just released a third-party code audit report, the first ever made public by a hardware wallet company.
The hardware design, which includes the device schematic (circuit diagram) and bill of materials (BOM), was released this May and can be found here. It provides a way for those interested in building their own hardware (BYOH) to reconstruct the Cobo Vault from scratch as a way of verifying and observing the inner workings of the device.
We are the first hardware wallet company (and perhaps the first hardware manufacturer in any industry) to have open source Secure Element firmware. The datasheet is also open source, but as with other hardware wallets, we aren’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). However, with the open source Secure Element firmware, you can verify the following important cryptographic operations:
- 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
- That private keys never leave the Secure Element
While the Secure Element firmware can’t tell you how random numbers are generated (TRNG), you don’t actually need to trust the Secure Element’s TRNG because we now support using the input from dice rolls to generate a recovery phrase. You can find instructions for how to do that with Cobo Vault here. For any testers out there who may want to further verify the operations of the Secure Element, we are able to send out the development board under NDA.
Cobo Vault uses Android as its operating system because it provides a mature toolchain for critical applications such as the camera (QR code scanning), touchscreen (usability and error prevention), and other aspects of a user-friendly experience. An Android-Secure Element structure is commonly found in many payment and banking terminals today. We built a wallet application layer on top of the Android operating system, which is completely open source. However, because parts of the operating system layer belong to the IP of various vendors, it can’t be completely open source. From what is open source, you can see that we limit the Android attack surface by:
- Closing adb and removing the adb daemon
- Removing unrelated system processes and apps
- Preventing installation of third-party apps
- Patching Linux kernel vulnerabilities
In order to introduce further transparency, we have undergone a code audit from a credible third party and just released it on Github. We chose one of the best code auditing vendors in China with experience in both blockchain-related products and Android hacking, an auditing entity led by the former head of 360 C0RE and 360 Super ROOT. We fixed all problems they brought our attention, with the exception two issues that ran contrary to our product philosophy:
- PVE010: Would preclude our aim of allowing users to authorize transactions by TEE-stored fingerprint. This fix is non-critical because there are several other ways the recovery phrase is protected. One is that data in the Secure Element is encrypted by default, the other is that the only way to access the recovery phrase is to upgrade the Secure Element with malicious firmware, but we currently only allow firmware upgrades signed by us. In addition, each upgrade needs to be authorized by verifying the user’s password.
- PVE011: Would negate our product principle of implementing a self-destruct mechanism capable of thwarting physical attacks by overriding everything to delete the recovery phrase. An air-gapped hardware wallet with a very high deterrent against physical attacks is a potent combination. Requiring a password for the self-destruct mechanism to wipe the recovery phrase would negate its effect.
What’s Next?
Currently, we only allow firmware upgrades that are signed by us to prevent phishing attacks. Ledger, Trezor, and Keepkey users have all recently been victims of phishing attacks. Warnings to caution users about installing third-party firmware aren’t sufficient to counter the threat because not all users have the background knowledge necessary to understand how they could lose all their bitcoin to a compromised firmware upgrade.
The disadvantage in transparency of having firmware upgrades signed only by us is that users have to trust our firmware upgrades as they are released. In order to reduce this trust burden and accommodate experienced users who want to customize their own firmware, we will release a Cyberpunk version of Cobo Vault. The Cyberpunk version will be produced without any workable firmware so that the user has to compile their own firmware, which would be signed using a public key available on Github. This can be taken a step further so that users can change the key pair to their own so that only firmware signed by their own keys can be uploaded.
We are trying to replace parts of the Android operating system that belong to the IP of vendors with our own code so that the whole Android operating system can be open source. If we are able to release the whole operating system layer, we will have brought our product as closely as possible to approximating “100% open source.”
One of the most effective ways of minimizing trust dependency is to support PSBT multisignature. As Michael Flaxman suggests in this podcast, each additional signature required to spend from a multisig PSBT wallet increases security by “orders of magnitude,” even if the additional signature is done by a hardware wallet that is not open source or considered particularly trustworthy. This is because all hardware wallets needed to sign would have to be compromised simultaneously in order for an attacker to steal the funds, which would be extremely hard to do if you use hardware wallets from different vendors.
Currently, multisig with hardware wallets is quite difficult to implement, but even when it does become easily accessible to basic users, open source will remain critical for building trust in a number of hardware wallet options. Multisig wallets need to have at least one hardware wallet that can be depended on as a strong basis of trust which can then be augmented by requiring additional signatures from other hardware wallets. We plan to be PSBT multisig compatible with a number of software wallets including Electrum, Specter, and BTCPay Server by the dates set in our product roadmap. There is still plenty of infrastructure that needs to be laid down both in terms for hardware and software for it to be a viable reality to most users, but hardware wallet multisig will doubtlessly change Bitcoin forever once it becomes readily available.
Why it Can’t All Be Done At Once
There are several reasons why releasing information has to be done gradually rather than all at once. First, we have a responsibility to protect our users from the increased threat of hacking that is inevitably part of exposing the source code and making it easier to find vulnerabilities. Hence the saying, “security through obscurity.” Our decision to make the second-generation products open source led to completely new threat modeling. Higher demands on our standard of engineering and a reconception of vulnerabilities meant that it took some time to go back and rewrite certain parts of code before they could be released.
We don’t live in a world of absolutes and no electronic product will ever be completely transparent, but open source remains incredibly important to the bitcoin community. Not only does open source code make the insertion of a backdoor by a rogue engineer much more difficult, but it also makes integration with other products such as software wallets a much smoother process. We are very optimistic about our growing compatibility with some of the best products and services the Bitcoin community has to offer, which will also help reduce trust dependencies on our product in the future.
