NewsFlash Articles Data Fundraising BlockBeats Pro

Thinking about BitKeep security incident: Problems with self-hosted wallets and potential changes

Read this article in 8 Minutes

This article adopts an objective and popular scientific attitude to discuss the current problems in the self-hosted wallet track and potential changes in the future.

Original author: Haotian

I never expected that a hacker attack on BitKeep would shake the "consensus" of the oldest industry track, the crypto wallet? Is the wallet safe or not? Is it the responsibility of the platform or the user to be hacked? Is developing a crypto wallet a good business? In the following Thread, in an objective and popular scientific manner, let's talk about the problems existing in the current self-hosted wallet track and potential changes in the future.

As we all know, the crypto industry cannot be separated from exchanges and self-hosted wallets. Exchanges (CEX) are generally managed by platforms. Users download and register in the traditional way of mobile phone email + password + secondary dynamic verification code, and the assets are fully managed by the exchange. Therefore, users tend to think that they will settle accounts with the platform, and hacker attacks and other external forces are tacitly responsible for the exchange platform.

However, self-hosted wallets do not follow the operating logic of traditional debit cards that are familiar to newbies (registration, reporting loss, reissue, etc.). The wallet platform only provides a front-end entrance for generating private key tools and managing assets. The user's private key is stored locally on the mobile phone. For each on-chain transaction, the user needs to call the local private key signature and then upload it to the chain. The wallet platform only plays the role of generating private key tools + asset management front-end + on-chain DApp entrance.

Under the narrative logic of the self-hosted wallet developer, the private key is kept locally on the user's hardware terminal, and the user has full custody of the private key, and the user can import a string of private keys into multiple different platforms at the same time. Therefore, a disclaimer is tacitly agreed: the asset loss caused by the loss of the private key shall be borne by the user. Although this makes sense technically, the wallet is close to the user's assets after all, and it does not conform to the inertial thinking of Xiaobai to find the platform when there is a problem.

In fact, in addition to the private key custody problem, there are many other possibilities of loss that are not caused by the user's subjective resistance:

1) The user's mobile terminal is rooted, and the hacker obtains advanced permissions through the Trojan virus;

2) The user downloads or updates the App, and the software APK package is hijacked by the hacker Trojan;

3) The target CDN network for the user to download the APP is hijacked by the hacker;

4) The supply chain of the wallet private key generation tool is hacked, etc. Therefore, wallets will argue whenever there is a problem with the security of user assets.

The key is that wallets are also involuted. In order to improve the experience, new versions are constantly released, in order to grab the market, covering various links such as browser plug-ins and mobile apps, and in order to make money, flash exchange, swap, cross-chain and other businesses that require Approve authorization are developed, resulting in more and more security vulnerabilities. This undoubtedly increases the difficulty for users to keep their private keys safe. Under this premise, if there is a security problem, the responsible party must be identified and defined.

However, for issues like APK hijacking, the subject of responsibility is often unclear. Under the framework of users being protected as the weak, the platform naturally becomes the party that has to take the initiative to take responsibility. However, unlike exchanges, self-hosted wallets do not directly contact user assets, and their profitability is too weak. In addition to the income from flash cross-chain handling fees, their business prospects as a DApp traffic entrance have not been opened. Small problems can still be covered, but if there is a large-scale attack, it is difficult to compensate.

Even so, the self-hosted wallet track has always been a high ground for developers to compete for. After all, the success story of Metamask and the business prospects of wallets as the entrance to everything on the chain are so fascinating that most developers want to go all in even though they know that they may cause trouble. Moreover, the wallet track is still evolving. The original narrative that wallets are purely for private key generation and traffic entrances is changing.

Where are the opportunities? Simply put, it is the differentiation of scenarios and the differentiation of people. For ordinary novices, exchanges are the best solution; for those with slightly higher knowledge and high assets: hardware wallets and self-custodial wallets, one cold and one hot; for those who value security, use the MPC wallet custody solution with a higher security level. If you want to optimize the functional experience, use smart contract wallets with more flexible scenarios, as well as other solutions around account abstraction, legal currency entry, and mass adoption, etc.

Whether MPC or CA wallets are doing the work of reshaping the "private key", private key custody seems simple, but there are too many loopholes that breed security risks between users, hardware, software, blockchain and other levels due to differences in individual security awareness. In a word, the entire market users and ecological developers Builder still need to further improve their security awareness and strengthen security construction. The internal friction of the industry that accuses each other when something happens is meaningless.