As passionate advocates of open source software, we have deep respect for pioneering developers who made their work available to the world, and it goes without saying that we in the cryptocurrency field owe much to the originators of blockchain technology. It is because Satoshi Nakamoto and other great trailblazers made their work open source that we are all able to share in the benefits brought by amazing innovations such as Linux, Bitcoin, and the booming cryptocurrency market.

However, when it comes to the question of whether making source code available is beneficial for the security of hardware wallets, we enter into a wholly new discussion. This article explains our reasons why we believe the nature of open source does not represent an upgrade for hardware wallets, but rather a significant security compromise.

Understanding Open Source Benefits in Context

In traditional fields of computing, supporters of open source have consistently emphasized one point — open source is safer because it enables the public to inspect source code and contribute to security by helping fix potential loopholes. Linus’s law (“given enough eyeballs, all bugs are shallow”) is clearly illustrated by the statistic that a zero-day attack on Safari, a closed source, takes an average 9 days to fix, while a zero-day attack on Firefox, an open source, on average only takes a single day to fix.

However, Linus’s law must be understood in context, namely that of traditional computing fields. When discussing the advantages of open source software in terms of hardware wallets, we must be mindful of the fact that the traditional computing development community is immense compared to that of hardware wallets.

GitHub, the world’s largest host of source code, indicates that there are only around 180 contributors to the open source code of the oldest hardware wallet brand, Trezor. This statistic stands in sharp contrast with the communities of other hardware products such as the Raspberry Pi, whose contributors to its open source firmware number around 9,500.

No project, no matter how big, is entirely immune to the potential dangers of exposing its code. Take for example Linux Mint, which was hacked in 2016. Although that backdoor issue was fixed within a day, the rapid response time was in no small part due to the size of the Linux open source community.

In the context of our relatively small development community, we need to be especially wary of the fact that sharing source code is a double-edged sword. For hardware wallets, the unfortunate truth is that releasing source code makes it easier for hackers to detect loopholes and carry out attacks. Open source code can even open the door for cybercriminals to produce counterfeit hardware wallets capable of deceiving consumers — a security threat Trezor has already been the victim of.

Heightened Risk From Zero-Day Attacks

An aspect of security hardware wallet owners need to be keenly aware of is zero-day attacks. In zero-day attacks, the period of time between when a previously unknown vulnerability is exposed or announced and when it is fixed presents a perfect window of opportunity for a hacker to carry out an attack. Because vulnerabilities in hardware wallets are often resolved through firmware upgrades, it usually takes a while after official security patches have been released for users to actually install them and fix the issue. With some users who, after having set up their hardware wallet, don’t open it for months or even years, exposure to zero-day attacks is dramatically increased. Perhaps counterintuitively for those experienced with open source software development, a black box, or device with a closed source code, is more secure than a white box with an open source code.

Hardware wallet users aren’t safe from zero-day attacks until they have updated their firmware.

Psychological Comfort or Actual Benefit?

While it is tempting to fall back on our knowledge and appreciation of Bitcoin as a prime example of the security offered by open source code, to assume that all blockchain projects should follow suit and become open source is a logical leap. The security Bitcoin enjoys from its open source development community is a direct result of the scale of its community involvement. Whether it is source code or mining functions, the Bitcoin community has gotten involved in maintaining and protecting the project, with larger numbers of involvement correlating to more secure functionality. However, because there are comparatively so few developers currently involved in hardware wallet security, we can make no assumptions about the benefits of sharing source code carrying over to this space.

Apart from vastly increasing the number of reviewers inspecting code, another benefit of open source development in traditional computing fields is enabling anyone to download, install, burn, debug, or even remove certain aspects of the source code themselves.

The security that comes with this level of autonomy is reliant on a foundation of specific technologies. However, even with a solid technological base, there is always the potential for security measures to be outdone. Those in computing fields will be familiar with how the Ken Thompson Hack (KTH) created a backdoor in the C compiler than can conceivably monitor or place controls on any software program in the world. You would have to write your own compiler using binary code or use tools compiled before KTH was installed in order to overcome this security compromise. KTH demonstrates that any system compiled from a source code is always going to be vulnerable to attack.

What OGs like Ken Thompson teach us is that unless you are able to write your own compiler (which excludes all but a very small minority of developers), you’re going to have to put your trust in a third-party. In-depth issues such as having to write your own compiler aside, the majority of hardware wallet users won’t even get their feet wet burning or debugging source code. For this cohort of users, knowing their hardware wallet is open source is more of a psychological comfort than a condition that actually amounts to a measurable improvement in their wallet’s security.

For this cohort of users, knowing their hardware wallet is open source is more of a psychological comfort than a condition that actually amounts to a measurable improvement in their wallet’s security.

The “Auditability” of QR Code Signature Outputs

In traditional fields of computing, it helps to think of the security brought by open source software as enabling a kind of “audit” on the source code. While the same is not yet true of cold storage cryptocurrency security, what can instead be substituted as a reliable source of “audit” for hardware wallets?

Fortunately, signed transaction outputs are not nearly as complicated as the outputs of other types of software. If making source code available is not the most secure option of providing ways to audit hardware wallets, we can instead consider scrutinizing their transaction signing outputs.

People purchase hardware wallets because they know the most secure way to store their private keys is to take them offline into cold storage. All hardware wallet services need a means of communicating between offline storage and online terminals. While the cold end (offline storage) is responsible for storing private keys and signing transactions, a hot end (online terminals) is needed to obtain data from the blockchain, construct transactions for the cold storage end to sign, and broadcast signed transactions to the blockchain.

In transmitting signature outputs, the majority of cold storage hardware uses data cables, Bluetooth, or even NFC. Because of the opacity of their data transmission, these methods make signature outputs extremely difficult to audit. An overlooked means of cold storage hardware communication is the QR code, a “what you see is what you get” solution. We believe the QR code is the ideal means of data transmission between cold ends and hot ends because data output by QR codes is transparent. This enables users to easily ensure each unsigned transaction that is transmitted to the cold storage device is valid, as well as ensure signature outputs from the cold end do not reveal private keys or sensitive information in any way.

Our article on Cobo Vault inputs and outputs offers detailed instructions on how QR code transmissions can be “audited.”

Cobo Vault’s Secure Element IS Open Source

While Cobo Vault believes that open source does not have much meaning for enhancing the security of hardware wallets, we have still released the firmware code for the Cobo Vault’s secure element. In doing so, we enable our users to see how random numbers are generated by the true random number generator (TRNG) and not by a pseudorandom number generator (PRNG). In the near future, we’ll publish an article explaining in detail the function of the secure element, importance of random numbers, and the difference between true random numbers and pseudorandom numbers.