Can I recover my private key? Five minutes to understand V's secret multi-signature recovery scheme

Written in front: Losing wallet passwords or private keys is a common problem for cryptocurrency users. Is there a way to recover lost keys while minimizing trust? This is exactly the direction that Ethereum co-founder vitalik and others are exploring, and they have written a new EIP ( Ethereum Improvement Proposal) and named it the Secret Multisig Recovery scheme.

Yesterday, Peter Schiff, a well-known gold enthusiast and crypto skeptic, claimed on Twitter that his wallet had lost his password and was unable to access his bitcoin.

Schiff went on to add:

"So now my Bitcoin is essentially worthless and it has no market value. I know that owning Bitcoin is a bad idea, but I never realized it was so bad!"

• South Korean officials: Government considers 20% tax on cryptocurrency transactions
• Counting mining 2019 | Difficulty of mining increased by 97.67% throughout the year. Which mining pool is on the right pace?
• Cryptocurrency fights for freedom in India's Supreme Court, but opponents see too much risk

After Schiff announced his losses on Twitter, the cryptocurrency community quickly began discussions. For example, Anthony Pompliano, co-founder and partner of Morgan Creek Digital, asked if he had forgotten his password, and Schiff responded by saying: "It was my wallet that forgot the password."

The unsightly Pompliano had to explain patiently:

"The software just executes commands issued by humans. It can't 'forget' anything. Just email me and I will do my best to help you recover the lost Bitcoin."

However, according to Schiff's answer, his bitcoin is basically hopeless, and he mentioned:

"It was Eric Voorhees (Note: CEO of ShapeShift) that helped me prepare the wallet, and even he felt I could do nothing. If you have any ideas, welcome to try."

Seeing this, readers may think this is a very sad story. A cryptocurrency skeptic managed to try Bitcoin, but lost them because he forgot his password. And if he backs up the private key in multiple places, even if he forgets the wallet password, he can access his wallet through the private key.

Of course, some people may think that this is a profound lesson, which reminds us to develop related technologies to provide security for similar people.

For example, vitalik co-founder vitalik commented:

"I am disappointed that people use 'cryptocurrency is cryptocurrency, and your job is to be very careful to write backup seeds in three places' to answer this question. We can and should create better wallet technology, Security becomes easier to implement.

For example, here is a social recovery proposal: https://t.co/tuSbHhXKgd?amp=1 ” So what exactly is the social restoration proposal mentioned by God V?

Let's take a brief look below.

EIP 2429: Secret Multisignature Recovery

Author: Ricardo Guilherme Schmidt ([email protected]), Miguel Mota (@Miguel Mota), Vitalik Buterin (@vbuterin), naxe (@ngmachado)

Status: Draft

Category: ERC

Created: 2019-12-07

Requirements: EIP (137, 191, 831, 1271, 1344, 2470)

Summary

In general, a bad experience with cryptocurrencies is the loss or exposure of private keys, which can lead to irreversible situations.

Social recovery is considered as an option for decentralized recovery of account contracts. However, the use of social recovery brings human factors, which are usually the main reason for the vulnerability of security systems.

The main risks of social recovery are:

1. Collusion: If some users know that they are part of a recovery, they may be interested in the execution of a recovery attack;
2. Targeted attack: An external agent may know the owner of the recovery and target the weakest point needed to perform a recovery attack;
3. General exposure: If an attacker manages to infect large user infrastructure dependencies and gain access to multiple identities, it may also have side effects on unaffected users by restoring them;
4. Simulated attack: A targeted attack can understand a user's situation and simulate that user to their social peers to perform a recovery attack. This becomes even more interesting as AI research is able to "deeply fake" other people's voices and facial movements.

Although there is no perfect solution to all of these issues, our goal is to implement a "trust minimization" controller contract and enable interoperability for different wallets that users may use.

It is reported that the standard proposes a method of defining a list of addresses stored in the Melkle tree. These addresses, together with their weights and the user's personal secrets, will form a secret set, which can be used without directly endangering the user. Public because it still requires manual verification of the total threshold in the address list.

This secret set can be saved, for example, stored in web2 cloud storage without seriously affecting security, which is very useful for users who do not trust themselves but do not want to trust certain specific entities.

The user secret will never be displayed in the chain, only a nonce hash is displayed, and it will increase every time it is restored. The recovery setting obtains a hash of a hash of this hash secret nonce. This double hash method is used to mathematically prove that the person requesting recovery knows the secret without revealing it.

According to the proposal, users can configure recovery by providing a secret ( user_secret_data ) and a weighted address list ( address_list ).

user_secret_data can be semi-private information that users can guess. The user_secret_type is an optional random large integer, and it is exported with the address_list as private_hash .

The total weight of the address list must be greater than the threshold, and the threshold is a constant: THRESHOLD = 100 * 10^18 .

The standard defines several methods for generating predictable user secrets.

Biometrics (such as fingerprints, faces, and pupils) should be used when they are available. This is the simplest method.

In the absence of biometrics, a standard set of questions that are usually only known to users can be used to generate users' secret data. All optional default fields are: Full Name , Birth Date , Mother Name , Mother Birthdate , Nationality , First Love's Name , First Pet's Name , Childhood Nickname .

The password derivation method is similar to the detailed form method, but it requires the user to enter only a few things: Full Name and Password .

Address list

The user will define a list of guardian accounts, which will be populated from the user's contact list. It should be convenient to import the options and enter an address, as shown in the figure:

After selecting a guardian, the user will be prompted to define the weight of each guardian:

These addresses are stored in a standard merkle tree, but each cotyledon must be hashed with hash_to_peer .

merkle_root is hashed into a standard merkle tree, which consists of address_list cotyledons of the form keccak256(bytes32(hash_to_peer), uint256(weight), boolean(is_ens), bytes32(ethereum_address)) .

The solution supports the ENS domain name. When a guardian owns an ENS domain name, the ENS domain name should be used. According to EIP-137, if ENS domain name is used, is_ens must be "true".

The address in the list can be an account contract. If it is an account contract, you can directly call the approval function or provide an EIP-1271 signature. If they have external accounts, the ecrecover logic is applied, but they can also directly call the approve function.

weight sets the degree of approval of this address value relative to the THRESHOLD constant.

User secret data hash

1. For multiple users, recovery_contract may be the same, which is the shared secret multi-signature contract address that the user is using;
2. user_secret_data is pure format byte data of user data, it is never exposed and will not be saved. When private_hash is unknown, a request should be made to the user;
3. private_hash is keccak256(user_secret_data) , it is never exposed and can be derived using a secret set. This can be reused in all restores;
4. merkle_root is obtained by hashing an ordinary merkle tree, and it will be exposed when it is executed;
5. weight_multipler defines how many individual weights need to be multiplied to reach THRESHOLD ;
6. hash_to_execute is keccak256(private_hash, address(recovery_contract), recovery_contract.nonce(user_address)) , it is only exposed at execution time, and each recovery is unique, also known as "display hash". Nonce and recovery contract addresses are used to allow reuse of private_hash ;
7. hash_to_peer is keccak256（hash_to_execute） , which is exposed when the authorization request is restored. It is used to prove that the user knows hash_to_execute and merkle_root by exposing the public_hash seed. This is also called "partial leaking hash";
8. public_hash is keccak256（hash_to_peer，merkle_root，weight_multiplier） . It is public after configuration and can only be used once. This is also used to prevent replay of execution. After successful execution, you must use setup(bytes32,uint256) for reconfiguration;

Recover secret set URL

All the information needed for recovery will be stored in the url type standard:

recovery = erc831_part account_contract ["@" chain_id] "/" recovery_contract "/" private_hash | secret_type "/" address_list / weight_multipler ["?" parameters] ["#" notes] erc831_part = "ethereum: recovery-" account_contract = ADDRESS chain_id = 1 * DIGIT recovery_contract = ADDRESS private_hash = "0x" 64 * HEXDIG secret_type = UINT address_list = ethereum_address * (";" ethereum_address) weight_multipler = UINT ethereum_address = ADDRESS / ENS_NAME "*" weight weight = UINT ADDRESS = "0x" 40 * HEXDIG parameters = parameter * ("&" parameter) parameter = key "=" value key = STRING value = STRING notes = STRING

1. account_contract refers to the account contract to be restored. Any account contract can be used because the restoration contract can be executed to any interface or address (such as conventional multi-signature);
2. chain_id defines the chain_id for all addresses. If it does not exist, it defaults to 1 (main network);
3. recovery_contract executes the logic of the recovery contract and must support the ABI specified in this document;
4. secret_type selects the standard used when generating user_secret_data , which is required when no private_hash is given;
5. private_hash is a hash of user_secret_data . If it does not exist, recovery will require the standard selected by secret_type to be used to obtain user_secret_data ;
6. weight_multipler is the value that each weight will be multiplied to reach the THRESHOLD constant;
7. address_list is a list of addresses with personal weights, preferably another account contract, indicating that they can be used for recovery requests, but any address can help recovery. You can use the ENS domain name and resolve it during the recovery process. The total weight should be higher than the THRESHOLD constant;
8. weight is Math.ceil(THRESHOLD / address_list.length) by default, which is set by the user;
9. parameters may require a specific secret_type ;
10. notes can be used for password hints if needed;

Recovery procedure

When recovery is required, users need to load their Recovery Secret Set URL into an e-wallet that supports this standard. Depending on the configuration, when private_hash not available, it must be generated from user_secret_data , which poses a challenge to the user.

When a valid key set is loaded, it will prompt which users ask for help. Some wallets may be able to send requests automatically, while others allow users to share this Help Recover Request URL .

The EIP encourages the use of pre-signed messages EIP-191 whenever possible, which is important because gas cost is a common obstacle. If the address chosen by the guardian is an account contract, it must be EIP-1271 to use the pre-signed information. The suggested normal sequence is as follows:

In special cases, if the account contract cannot sign the information, or the user's wallet cannot sign the information in the format specified on this EIP, you can also use the msg.sender method to perform general operations.

In this case, the guardian will have to pay a small gas fee.

Theoretical basis

user_secret_data never made public. After hashing it once with the keccak256 algorithm, it becomes private_hash that is never made public. In theory, biometric technology should be used because users are less likely to lose their biometrics. And biometrics are usually not secure because they are not really secrets. Most high-resolution cameras can actually read most biometrics, and this information is usually known to governments.

When biometrics are not available, the user data form still provides fairly good security, because the hash stored in the contract is a salted hash that is very far from the source data, and even if only the name is used as user_secret_data , it is difficult found. The more unpredictable this data is, the more it can withstand targeted attacks, which still need to discover the user list and receive sufficient authorization.

在成功执行之后，需要重新配置以实现安全性保障。在经历一次恢复后，恢复合约必须禁用自身，并等待新的配置。

Possible attacks

It should be noted that wallets supporting this EIP should consider that users may be requested to help restore other accounts, and the request may come from anyone who knows secret_set , including legal owners or attackers who have obtained secret_set in some way.

therefore:

1. The wallet must ask the user for the legitimacy of the request, and ask whether the request was made after personal verification;
2. Users must know that they are responsible for their on-chain operations (ethical and legal in some countries) and must verify the legitimacy of the recovery request;
3. Video calls may be faked by AI, but the attacker needs images and voice samples, such as public speech content on the Internet;
4. Users who restore for celebrities should never trust video calls and should try to contact the people around them directly to check the legitimacy of the request;

Comment: This solution is designed for groups such as Peter Schiff who easily forget the wallet password or private key, but it also has security risks, and it is very important for the social scalability of cryptocurrencies Because most people will be similar to Peter Schiff when they first encounter cryptocurrencies. This article has omitted a lot of technical details, and interested readers can read the original proposal content: https://gitlab.com/status-im/docs/EIPs/blob/secret-multisig-recovery/EIPS/eip-2429.md

We will continue to update Blocking; if you have any questions or suggestions, please contact us!