Open Source Products and Asset Security for Coin Holders
In recent years, cryptocurrencies, led by Bitcoin, have flourished, giving rise to a wide variety of new products and forming a unique cryptocurrency ecosystem. Developers who selflessly share their development code undoubtedly play a vital role in this. It can be said that the entire cryptocurrency ecosystem can now present a hundred flowers of product form, all cannot be separated from the contribution of open source software.
In the “decentralized” world of cryptocurrencies, open source software seems to be the only suitable product form. Open source code can firstly “prove itself” to ensure the security of the product, and secondly an open-source product could obtain a large community support to keep it alive.
However, just like a coin will always have two sides, open source would also face some unsolvable problems, and that’s when closed source comes into play.
There are many reasons why a product chooses open or closed source, but in the financial field of cryptocurrency, “security” is undoubtedly the primary one.
Open Source: Trust system without endorsement
Open source usually occurs when the user does not trust the developer. The developer would publish all the code and the user could check them with unlimited access to prove that the product actually does what it says it does. Ideally, this would build a trusting relationship between developers and users without endorsement, as developers will be easily spotted if they release a malicious code.
At the same time, however, the most glaring flaw of open source product is that it also facilitates attackers. The vulnerability attack that just occurred on the Lendf Me lending protocol is another example of a string of attacks on cryptocurrency decentralized finance (DeFi). The incident not only cost users about $25 million in lost assets, but also dealt a serious blow to the security and user trust of open source smart contracts.
Closed Source: Trust system with authoritative endorsement
It’s obviously much more difficult for an attacker to find vulnerabilities from a black box system with closed-source code than from a fully open and transparent open source product. This makes closed-source products more suitable for use in potentially threatening environments, and it’s only natural that they be used to protect users’ sensitive private data.
The question then arises: how can a closed-source product, in which user keeps such important and sensitive privacy data in it, prove that it is not a rogue product?
It is then necessary to rely on an authoritative third party that is trusted by users. A closed-source product must present all code to an authoritative third party for inspection and endorsement. The certification authority, through the means of test it uses, the size of the authority itself and the reputation it has accumulated over time, ensures that it makes an accurate and authoritative judgment about the product. It is also unlikely that a third party will allow a closed-source product to malign or leave a vulnerability in its code in order to maintain its credibility. This is the widespread relationship of trust that exists in reality through third-party endorsements, for which all standards, laboratories and certification authorities are created.
After the above analysis, we can see: the so-called “security” actually encompasses two completely different perspectives.
1. The security of open source is aimed at developers, making it difficult for developers to “do evil”.
2. The closed-source product is more likely to ensure security against hackers, so that hackers have a hard time to “do evil”.
At this point, we have been able to conclude that the difference between open-source and closed-source product is just a matter of preference depending on different use cases. It is not an either/or, black or white debate, but can be combined according to the actual situation.
That’s exactly what JuBiter hardware wallet was developed for. Jubiter divides the internal code of the hardware wallet into two parts, one called “sensitive data” and the other called “business logic”.
“Sensitive data” mainly contains the user’s password, private key, transaction display, etc.
“Business logic” mainly includes cryptocurrency protocols, wallet SDKs, blockchain network access, etc.
Obviously, the “sensitive data” part is more vulnerable to targeted attacks by hackers, so JuBiter chose a closed-source solution for this part of the code, with a CC EAL6+ certified secure element. The chip ensures that even if the hardware wallet falls into the hands of a hacker, no matter what code or physical means the hacker uses to crack the hardware wallet, there is no way to obtain the user’s private key.
At the same time, the “business logic” part is more likely to be attacked by developers. Of course, JuBiter would never release a rogue firmware update, for what we have to gain would be much less than what we have to lose. Besides, open source can prove its own innocence as well as make some modest contributions to the open source community, so why not make “business logic” code all open source?
While JuBiter can’t disclose all of its code, we’ll be happy to share and discuss all aspects of the JuBiter hardware wallet and software wallet in the next series of posts, “open-sourcing” our thoughts and ideas.
