Exploring Web3 Wallet Security Issues: What recovery system does the Ethereum community need?
Original title: "DAOrayaki｜What kind of social recovery system does the Ethereum community need?"
One of the biggest challenges in making cryptocurrencies and blockchain applications usable to the average user is security: how do we prevent users from losing or having their funds lost or stolen? Lost and stolen coins are a serious problem, often costing innocent blockchain users thousands of dollars, and in some cases, most of their net worth.
Many solutions have been proposed over the years: paper wallets, hardware wallets and my ever-favorite multi-signature wallets. In fact, they have led to dramatic improvements in security. However, these solutions all have various flaws - sometimes providing far less additional protection against coin theft and loss than is actually needed, sometimes being cumbersome to use resulting in little adoption, and sometimes both There are.
At the beginning of 2021, V God proposed an alternative plan and emphasized it again in the article "Decentralized Society: Finding the Soul of Web3" in May this year: a newer The smart contract wallet is called a "social recovery wallet". Compared with previous options, these wallets have the potential to provide a high level of security and better usability. When the Ethereum ecosystem migrates to the rollup layer-2 solution on a large scale, it can effectively solve the two major problems currently facing social recovery wallets: (1) Rely on centralized relayers, (2) High transaction fees. The DAOrayaki community combed through a series of proposals for social recovery systems and compiled them into this article. This post will discuss what social recovery wallets are, alternative use cases for social recovery systems, and user feedback.
1. Social Recovery Wallet
The social recovery system works as follows:
Only one "Signing Key" can be used to approve transactions
At least 3 (or more ) "guardians", most of whom can cooperate to change an account's signing key.
Signing keys have the ability to add or remove guardians, but after a period of time (usually 1-3 days) before they do so.
In all normal cases, users can Wallets simply use their social recovery wallets to sign messages with their signing keys so that each transaction signed can be done quickly with a single confirmation, just like in "traditional" wallets (such as Metamask).
If a user loses their signing key, then social recovery kicks in. Users simply need to contact their guardians and have them sign a special transaction that changes the signing public key registered in the wallet contract to a new signature. It's easy: they can simply visit a web page, say security.loopring. Review and sign the recovery request. It's as easy as trading Uniswap for each guardian.
There are many possible options for you to choose who will be your guardian. The three most common options are:
- Other devices (or paper seed phrases) owned by the wallet holder themselves
- Friends and Family
- The agency will sign the resume upon receipt of confirmation from your phone number or email, or in critical cases, verify your identity in person via video call
< p>Guardians are easy to add: you can simply enter their ENS name or ETH address to add a guardian, although most social recovery wallets will ask the guardian to sign a transaction on the recovery web page to agree Add to. In any properly designed social recovery wallet, there is no need to download and use the same wallet; they can simply use their existing Ethereum wallet, no matter what type of wallet it is. Given the high level of convenience of adding guardians, if you're lucky enough that your social circle is already made up of Ethereum users, I'd personally lean towards a higher number of guardians (ideally 7+) for added security.
If you already have a wallet, then no constant effort is required from guardians: any recovery operations you do will be done through your existing wallet . If you don't know many other active Ethereum users, you trust a small number of technically competent guardians to be the best.
To reduce the risk of guardian attacks and collusion, your guardians don't have to be public: in fact, they don't need to know each other's identities. This can be achieved in two ways. First, rather than storing the guardian's address directly on-chain, a hash of the list of addresses is stored on-chain, and the wallet owner simply publishes the full list when restored.
Secondly, each guardian can be required to deterministically generate a new single-purpose address, which they will only use for a specific recovery; unless recovery is actually required, otherwise They don't need to actually send any transactions using that address. To complement these technical protections, it is recommended to select a diverse set of guardians from different social circles (ideally including an institutional guardian); these recommendations taken together will make it difficult for guardians to be simultaneously attacked or complicit.
In the event of your death or permanent incapacity, the Guardian can publicly announce their identity so they can find each other and recover your funds.
Social Recovery Wallet is not a betrayal, but an expression of "cryptographic value".
A common response to the suggestion to use any form of multisig, social recovery or otherwise, is that the solution goes back to "trusting people , which is a betrayal of the value of the blockchain and cryptocurrency industry. While I understand why people think so at first glance, I would say that this criticism stems from a fundamental misunderstanding of encryption.
For me, the goal of cryptocurrencies has never been to remove the need for all trust. Instead, the purpose of encryption is to give people access to encryption and the bedrock of the economy, to give people more choice in who to trust, and to allow people to build a more constrained form of trust: giving someone the power to do something on your behalf without giving They have power to do whatever they want. Viewed in this light, multisig and social recovery are a perfect expression of this principle: each participant has some influence over the ability to accept or reject transactions, but no one can unilaterally move funds. This more complex logic allows for a mechanism that is far more secure than unilateral control of funds by a single person or key.
The basic idea that human input should be used sparingly and not discarded entirely is very powerful because it meshes well with the strengths and weaknesses of the human brain in Together. The human brain is poorly adapted to memorizing passwords and tracking paper wallets, but it is a specialized chip for tracking relationships with other people. This effect is stronger for non-technical users: they may struggle with wallets and passwords, but they are equally good at social tasks like "choose 7 people who won't team up against me".
If we could at least extract some information from human input to make it a mechanism instead of turning those inputs into a vector of attack and exploitation, Then we should figure out how to do this. Social recovery is very strong: for a wallet with 7 guardians to be compromised, 4 of those 7 guardians would need to somehow discover each other and agree to steal funds, none of which would give all Bring a tip. Of course, this is a tougher challenge than attacking a wallet purely protected by one person.
II. Alternative Use Cases for Social Recovery Wallets
v God in January 2021 In the article, the principle and characteristics of the social recovery wallet (that is, the smart contract wallet) are briefly introduced through two examples of Argent and Loopring. and presenting "Alternative Mechanisms for Social Recovery Use Cases" on ethresear.ch [1] in July 2021. Our paper focuses on: this alternative mechanism.
Dark Crystal Web3 is a term derived from a proposal by Vitalik Buterin in 2021 after the original post[2], which suggested a system where recovery partners There is no need to install software or store any other data other than having a personal Ethereum wallet.
Magma Collective is currently working on developing it into an MVP (Minimum Viable Product). This is a social recovery protocol for which we identified three main important functions.
The app doesn't require restorers to remember anything except the access password of their Ethereum master wallet;
< /p>
The app is supposed to be confidential, meaning it can back up any kind of secret, including but not limited to Ethereum private keys;
The application should ideally allow for anonymity of the secret owner and recovery partner.
Since this application deals with secrets, perhaps with high value, it is critical to verify the security assumptions and trust requirements in our project.
The system consists of two parts:
A web-based dAPP for Used by the recovery partner, it calls the Web3 API to generate an encryption key pair to derive the signature and retrieve and decrypt the share from the contract during recovery.
Offline-first software component for backup personnel. Given a list of secret and public keys, a set of encrypted shares is generated and published to the blockchain. As an offline punch, the program does not actually post, but generates dapp links that contain encrypted payloads. This can then be transmitted to any browser with a Web3 extension (e.g. via a QR code).
The basic process of its operation can refer to here.
3. What kind of social recovery system does the Ethereum society need?
Build on Ethereum Based on the social recovery system, the focus is on usability.
As part of the initial phase of MVP development, Dark Crystal Web3 conducted user research on the core tools and protocols of the Web3 and Ethereum communities, interviewing WalletConnect, 3Box, Representatives of Metamask, Gnosis Safe, Rainbow, and Tally, and distributed an anonymous questionnaire on Twitter and Discord. This goal is to take into account not only the usability of the Dark Crystal Web3 project, but also social recovery, an important protocol currently envisioned, and the potential need for instrumentation.
- The role of cold storage
- How skilled is the user?
- What kind of "identity" is already used on the chain, and the preference for anonymity
- The role of on-chain storage and centralized storage
- The most important roadmap consideration
The role of cold storage
Availability Prioritized, which is an important consensus, our most important finding is that cold storage use cases are rare. Cold storage refers to keeping keys in a way that is never connected to the internet — this could be a paper wallet, or a hard drive connected only to an offline computer. It is widely regarded as the most secure way of storing keys. However, conducting transactions with cold-storage keys presents a significant usability hurdle: a wallet program must typically be downloaded and set up on an offline computer, which packages and signs the transaction, which is then transferred to another device and exported to the public. broadcast. Since our application deals with privacy, we wonder how likely users are to accept this process?
Perhaps a little surprised we find this security practice uncommon. Or more precisely, the subset of overlap between the cold storage keys and the keys users will back up with our application is very small. In all of our sync conversations, we've learned that while supporting a cold storage path is important, users won't use it. From those respondents who did have cold storage keys, we learned that they would only use a system like ours for less valuable hot wallet keys.
Respondents were somewhat more inclined towards cold storage - 33% said they would keep their keys in cold storage at all times. As the research lengthened, we also received feedback that the most security-conscious users tended to have their own backup systems rather than trust ours. Consider that those most in need of social recovery are often not tech-savvy: "Anyone who can use the command line doesn't need social recovery".
What is the technical level of the user?
In fact, what kind of technical literacy we can ask users to have is another area of discussion-what kind of tools, wallets, etc. are our potential users Familiar or need?
Architecturally, Dark Crystal Web3 involves a browser-based hosted application, and a Rust web frontend that can be served locally Command-line components. Our survey respondents and respondents were technical, with 80% saying they would be happy to use a command-line application if necessary. The current architecture plan is motivated by a desire to support cold storage, but based on feedback we suspect that if we had a fully managed version of our application, only a small percentage of clearly motivated users would use it in other ways use it. These feedbacks are so strong that even though we have worked from cold storage to colocation, including design and execution, it is not impossible to go the other way.
Although we discussed browser-based dapps as the main entry point, we received strong feedback from 2 out of 6 respondents, Consider downloadable apps to be a more trustworthy and preferable design pattern due to the frequency of phishing attacks. Overwhelmingly, tools like Metamask, Walletconnect, mobile wallets, and block explorers presented no problems for respondents or respondents.
While we have tried to make the protocol agnostic about whether secrets are backed up or not, we believe that all potential secret owners have already joined Ethereum. We have heard clearly many times that non-Ethereum users will be less likely to choose our social recovery protocol. In other words, they hope that recovery partners can cover technical novices, those who don't even have wallets. We need to account for this unique requirement.
What kind of "identity" is already being used on-chain, and the preference for anonymity
However, we would like to know whether user usage patterns would support this practice. Do people keep one persistent wallet, or are they constantly switching between different wallets forked from the same seed? Do they generate new seeds? All in-person interviews confirm that our typical user will have a "master Ethereum address" that they cannot possibly forget under any circumstances. Interestingly, however, half of the respondents said that it is possible or true that users have forgotten this, or never have. The frequency of "master Ethereum addresses" as an identity concept is a potential area of future research.
In general, the feedback is very supportive of anonymity, but we hear repeatedly that once a significant number of users become part of the application, the "needle in the haystack" style The degree of anonymity is sufficient in many cases. But it wasn't clear how this would get off the ground, or exactly what threshold would be reached to make this happen. We discussed with several interviewees whether there is a public protocol that could be used to map Ethereum addresses to public cryptographic keys, thus providing a starter package for this anonymity, but did not find an existing project that could fill this Role. We also found that the anonymity of the recovery partner was more agreed upon than the anonymity of the secret owner, as shown in the figure below.
Three respondents raised concerns that they might forget who their recovery partner was , we have also received feature requests to be able to change the recovery partner multiple times.
On-chain storage vs. centralized storage
We have received criticism for storing encrypted secrets on-chain in two cases, one from a cost perspective and one from concerns about quantum threats to cryptography. Yes, if we use Any cryptography that is broken one day will affect all the secrets stored in our protocol.In terms of cost, respondents and respondents agree that around $200 is the upper limit of transaction costs for applications, and lower costs are more welcome .
We've heard that for our use case, there is no advantage to being on mainnet compared to being on another ethereum-like network like polygon or gnosischain .
Finally, it has been suggested to consider a centralized approach for applications where users can choose not to store on-chain, which of course brings other potential problems (continuous maintenance, potential leaks), but still could meaningfully increase accessibility. 37% of respondents said they would be more comfortable with off-chain storage. Also, long-term maintenance of the protocol was listed as a concern several times Point: How would a potential user trust the recovery process to still work after a potential dissolution or major change in our team? And, is there any way for the secret owner to verify that the secret is recoverable without going through the whole process ?
The most important considerations for the roadmap
So far, through the most Simplifying product thinking, we get an important aspect of secret recovery that needs to be able to communicate between the secret owner and the recovery partner. Initial setup information, as well as recovery data, need to be sent between the two parties. This is likely the system Biggest security weakness. 100% of respondents believe that it is possible to leak some secret fragment sets through insecure out-of-band transmission, and our in-person interviews strongly echo this sentiment.
Because many of our respondents were protocol developers, we asked them about crypto wallet-to-wallet messaging, as well as existing roadmap features that might help communicate. A close group A related feature has to do with notifications to secret owners and recovery partners at various stages of the recovery process. Many wallet developers we interviewed did have this feature on their roadmap, although no release date was confirmed. In this direction Further work looks important to the ecosystem, and integration with one of these solutions is likely to be at the heart of future work on Dark Crystal Web3.
Original Link
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
