Account recovery method and device, equipment and storage medium

Abstract

The invention is applicable to the technical field of block chains, and provides an account recovery method, device and equipment and a storage medium, the method is applied to block chain node equipment, the method comprises the following steps: obtaining authentication data, the authentication data being generated according to preset identity information of a user; for the authentication data, obtaining user data and account recovery parameters for account recovery, the account recovery parameters comprising a user address; performing signature processing on the user data and the authentication data by adopting a pass key to obtain a digital signature; verifying the digital signature by using an intelligent contract; and if the digital signature verification is passed, determining a user address in the account recovery parameter as a target user address. According to the scheme, the account is recovered in a Passkey mode, the operation is simple, and the security is high.

Description

Technical Field

[0001] The present application relates to the field of blockchain security technology, and in particular to an account recovery method, device, equipment and storage medium. Background Art

[0002] In the blockchain, each account has a pair of public and private keys. The public key can be made public, and anyone can see and use it to interact with the account; the private key must be kept strictly confidential, and the person holding the private key can control the assets or contracts associated with the public key. When a smart contract is deployed on the blockchain, an "owner" address is usually set, and the private key corresponding to this address is used to control the permissions and functions of the contract. Once a smart contract is deployed, the owner's private key becomes crucial. If the private key is lost, the owner will no longer be able to access and control the contract. If the user forgets the private key, account recovery is required.

[0003] The existing technology mainly recovers smart contract accounts through multi-signature or MPC (Multi-Party Computation). The multi-signature method mainly requires the user to set the addresses of multiple other users as guardians, and set the account owner of the contract to a new address by verifying multiple guardians. The MPC method requires the user to set an address as the guardian of the contract account, and the private key corresponding to the address needs to be recovered by multiple users off-chain through the MPC algorithm and signed and sent to the chain, thereby recovering the private key corresponding to the guardian address.

[0004] However, these methods require the participation of multiple users to recover. For ordinary users, the operation is complicated, the verification process is cumbersome, and the applicability is poor. Summary of the invention

[0005] The embodiments of the present application provide an account recovery method, apparatus, device and storage medium, which can solve the technical problem of how to enable users who have forgotten their private keys to simply and efficiently recover their accounts.

[0006] In a first aspect, an embodiment of the present application provides an account recovery method, which is applied to a blockchain node device, including:

[0007] Obtaining authentication data, where the authentication data is generated based on the user's preset identity information;

[0008] For the authentication data, obtain user data and account recovery parameters for account recovery, where the account recovery parameters include the user address;

[0009] The user data and authentication data are signed using the passkey to obtain a digital signature;

[0010] Use smart contracts to verify digital signatures;

[0011] If the digital signature verification is successful, the user address in the account recovery parameter is determined as the target user address.

[0012] In one implementation, before obtaining the authentication data, the method further includes:

[0013] Obtain and record the pass key information, which includes the public key information of the pass key, the preset verification signature algorithm and the random value; bind the pass key in the smart contract according to the pass key information.

[0014] In one implementation, using a smart contract to verify a digital signature includes:

[0015] Performing hash calculation on the account recovery parameter according to a preset hash algorithm to obtain a first hash value;

[0016] The first hash value is compared with the random challenge value in the user data. When the first hash value is equal to the random challenge value, the verification is deemed to be successful. The random challenge value is obtained by performing off-chain hash calculation on the account recovery parameters.

[0017] In one implementation, verifying a digital signature using a smart contract also includes:

[0018] Performing hash processing on the user data and the authentication data using a preset hash algorithm to obtain a second hash value;

[0019] The digital signature is verified based on the public key information of the pass key and the second hash value.

[0020] In one implementation, performing hash processing on user data and authentication data using a preset hash algorithm to obtain a second hash value includes:

[0021] Perform hash calculation on user data according to a preset hash algorithm to obtain a hash value of the user data;

[0022] The user data hash value and the authentication data are concatenated to obtain concatenated data;

[0023] A hash calculation is performed on the spliced ​​data according to a preset hash algorithm to obtain a second hash value.

[0024] In one implementation, verifying the digital signature according to the public key information of the pass key and the second hash value includes:

[0025] Decrypt the digital signature according to the public key information of the passkey to obtain the original signature data;

[0026] The original signature data is compared with the second hash value. When the value of the original signature data is equal to the second hash value, the verification is deemed to be successful.

[0027] In one implementation, after the verification is completed, the random value in the account recovery parameter is numerically increased to obtain an increased random value; and the increased random value is assigned to the random value.

[0028] In one implementation, the method further includes: obtaining the user address recorded in the smart contract and the address corresponding to the caller of the smart contract; comparing the user address recorded in the smart contract and the address corresponding to the caller, and when the user address recorded in the smart contract and the address corresponding to the caller are equal, allowing the caller to call the smart contract; after the caller calls the smart contract, using the smart contract to record the pass key information and performing numerical increment processing on the random value.

[0029] In a second aspect, an embodiment of the present application provides an account recovery device, which has the function of implementing the method in the first aspect or any possible implementation thereof. Specifically, the device includes a unit that implements the method in the first aspect or any possible implementation thereof.

[0030] In one embodiment, the device comprises:

[0031] An acquisition unit, used to acquire authentication data, the authentication data being generated according to preset identity identification information of the user;

[0032] A processing unit, configured to obtain, based on the authentication data, user data and account recovery parameters for account recovery, wherein the account recovery parameters include a user address;

[0033] The processing unit is also used to use the pass key to sign the user data and the authentication data to obtain a digital signature;

[0034] The processing unit is also used to verify the digital signature using the smart contract;

[0035] The processing unit is also used to determine the user address in the account recovery parameter as the target user address if the digital signature verification passes.

[0036] In a third aspect, an embodiment of the present application provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the computer device implements a method according to any one of the implementation modes of the first aspect.

[0037] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a computer device, the computer device implements the method of any one of the implementation methods of the first aspect above.

[0038] In a fifth aspect, an embodiment of the present application provides a computer program product. When the computer program product is run on a computer device, the computer device executes a method of any one of the implementation modes of the first aspect above.

[0039] Compared with the prior art, the embodiments of the present application have the following beneficial effects: generating authentication data based on the preset identity information of the user, the source of the request can be accurately identified during the recovery process and the identity of the user can be verified, ensuring the legitimacy and uniqueness of the request; obtaining information for account recovery based on the authentication data, namely user data and account recovery parameters (including new user address), ensuring that the new user address matches the preset identity information of the user, preventing malicious impersonation by attackers; using a pass key to sign the acquired user data and authentication data to generate a digital signature, ensuring that the data has not been tampered with during transmission; using a smart contract to further verify the digital signature, the smart contract will check the authenticity of the digital signature to ensure that the account recovery request is indeed made by the user himself and that the data has not been tampered with. After all verifications are successful, the user address in the account recovery parameters is determined to be the new target user address. If the verification fails, the system will reject the recovery request to prevent unauthorized access. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 This is a comparison diagram of application scenarios of a smart contract provided in an embodiment of the present application.

[0041] Figure 2 It is a flowchart of an account recovery method provided in an embodiment of the present application.

[0042] Figure 3 This is a schematic diagram of a scenario for binding a pass key provided in an embodiment of the present application.

[0043] Figure 4 It is a schematic diagram of a scenario for calling an account recovery method provided in an embodiment of the present application.

[0044] Figure 5 It is a structural diagram of an account recovery device provided in an embodiment of the present application.

[0045] Figure 6 It is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] Blockchain is a decentralized distributed ledger technology that connects data in blocks and ensures the security and immutability of data through cryptography. Smart contracts are automated contracts executed on blockchains. They are protocols or rules specified by programming code. Smart contracts run on blockchains and can automatically execute contract content when specific conditions are met.

[0047] The person or entity that creates a smart contract is the owner of the smart contract, and the owner is responsible for managing the contract code and related logic, including modifying the contract, upgrading the contract, etc. In the blockchain, the owner of the contract can perform certain privileged operations, such as revoking the contract, modifying contract parameters, etc.

[0048] Usually, the owner of a smart contract is identified by its owner address, which can be the address of an individual user or an organization. In blockchain transactions, the address is unique and can ensure that the owner of the contract has control over the contract. It is understandable that when the owner forgets the corresponding private key, he will lose control of the smart contract account.

[0049] Combine the following Figure 1 Let me introduce it in detail.

[0050] Figure 1 This is a comparison diagram of application scenarios of a smart contract provided in an embodiment of the present application.

[0051] like Figure 1 As shown, Figure 1 Part A in the diagram represents an existing smart contract, which records the owner's address.

[0052] Figure 1 Part B represents a smart contract provided in this application, to which Passkey public key information and random value (Nonce) information are added.

[0053] In order to further illustrate the technical solution of the present application, specific embodiments are provided below.

[0054] Figure 2 It is a flowchart of an account recovery method provided in an embodiment of the present application.

[0055] like Figure 2 As shown, the above account recovery method is applied to a blockchain node device, including the following steps S201 to S205.

[0056] S201. Acquire authentication data, where the authentication data is generated according to preset identity information of the user.

[0057] The preset identity identification information includes but is not limited to fingerprint information, face information, iris information, palm print information, voice information and other unique information that can be used for identity recognition.

[0058] Authentication data (authData) can be understood as data generated by an authenticator (such as a security key, a smart phone, etc.) during the identity authentication process when inputting preset identity information (such as fingerprint information or face information).

[0059] Obtaining authentication data can confirm the identity of the user requesting account recovery. If the user forgets their private key, using authentication data can provide an alternative way to confirm identity.

[0060] S202. Obtain user data and account recovery parameters for account recovery based on the authentication data. The account recovery parameters include a user address.

[0061] User data (clientData) is data set by the user. ClientData contains fields such as data type (type), random challenge value (challenge), and request domain name (origin).

[0062] The data type (type) is used to indicate the type of clientData. In WebAuthn, the value of this field is usually "Webauthn.create" (for the registration process) or "Webauthn.get" (for the authentication process).

[0063] The challenge value is a random challenge value generated by the server and used in the authentication process. When the client (such as a browser) initiates an authentication request, it will include this challenge value in the clientData and send it to the server. The server will use this challenge value to ensure the validity of the request during the verification process. In this application, it is mainly used to verify the correctness of the signature on the chain.

[0064] The origin field in clientData ensures that only requests from a specific domain are accepted.

[0065] The account recovery parameters (args) include: user address (newOwner), which can also be understood as the new owner address; random value (Nonce), the value of Nonce can be obtained by calling the contract.

[0066] S203: Use the pass key to sign the user data and authentication data to obtain a digital signature.

[0067] Passkey is part of Web Authentication (or WebAuthn), a new web standard developed by the FIDO Alliance. WebAuthn does not use usernames and passwords, but uses public key cryptography to verify the user's identity.

[0068] It can be understood that when the owner (user) enters preset identity information such as fingerprint or face in the local device, the passkey will sign the clientData and authData to generate a digital signature.

[0069] S204. Use smart contracts to verify the digital signature.

[0070] In one implementation, an Externally Owned Account (EOA) is generated locally. It can be understood that an EOA is a personal account, or a wallet address. An EOA is controlled by a private key, which is like the key to an account. Only with this key can an EOA be operated, such as sending transactions, receiving funds, etc.

[0071] Then, send a request transaction to restore the account to the chain, call the restore account method, pass in the parameters clientData, authData, args and signature, and verify the passkey signature in the smart contract.

[0072] Smart contracts handle this verification process on the blockchain, ensuring the immutability of all operations. When the smart contract verifies the digital signature, it confirms that the user requesting the recovery is legitimate and that their request has not been tampered with, thereby enhancing security and preventing fraud.

[0073] S205: If the digital signature verification passes, the user address in the account recovery parameter is determined as the target user address.

[0074] It can be understood that when the digital signature verification is passed, the user address (newOwner) in the account recovery parameter can be identified as the owner of the smart contract, and then the account owner is reset, and the owner address of the smart contract is changed to newOwner to complete the recovery of the contract account. After the recovery, the owner can use the new private key to call the contract account normally, and even if the user forgets the private key, they can re-access their assets.

[0075] By using Passkey to restore the account, it supports biometric methods such as fingerprint recognition and facial recognition. The smart contract account can be reset by simply pressing the fingerprint or recognizing the face. The operation is simple. After the reset, the account owner of the smart contract is the address corresponding to the reset private key. The user will not lose control of the smart contract even if he forgets or loses the private key, which ensures the security of users' use of smart contracts and improves ease of use.

[0076] This method supports existing smart contracts and has high compatibility. It can keep the way users use the smart contract unchanged, greatly improving the user experience without reducing security. It is also compatible with existing smart contract usage methods, so users do not need to change their original usage methods and it has high versatility.

[0077] In one implementation, before obtaining the authentication data, the above method also includes: obtaining and recording pass key information, the pass key information including the public key information of the pass key, a preset verification signature algorithm and a random value; binding the pass key in the smart contract according to the pass key information.

[0078] Combine the following Figure 3 Let me introduce it in detail.

[0079] Figure 3 This is a schematic diagram of a scenario for binding a pass key provided in an embodiment of the present application.

[0080] like Figure 3 As shown, when the owner calls the Register Passkey method, he can enter the passkey information, that is, parameters: public key information, algorithm type information, etc. to bind the passkey.

[0081] It is understood that a smart contract usually includes the owner's address, and the owner can control the smart contract. The smart contract adds the public key information of the passkey, and the smart contract records the public key information of the passkey (including the public key corresponding to the passkey and the type of verification signature algorithm used) and the random value (Nonce) information (the existing Nonce of the smart contract can be reused, and if there is no need to add the Nonce field).

[0082] It can be understood that the public key information of the passkey is the basis for signature verification. Recording this public key information is the key to ensuring that signature verification of user data and authentication data can be performed in subsequent steps. This ensures that only users holding the corresponding private key can generate valid signatures, thereby verifying their identities.

[0083] As an example and not a limitation, the verification signature algorithm type can be RSA (Rivest-Shamir-Adleman), ECDSA (Elliptic Curve Digital Signature Algorithm), HMAC (Hash-based Message Authentication Code), etc. The specific algorithm used can be set according to the actual application scenario. Defining and recording the algorithm type used for signature verification (such as RSA, ECDSA, etc.) can ensure that both parties use the same algorithm when signing and verifying. This helps to improve the compatibility and security of the system. If there is no determined algorithm, the signature may not be verified correctly, causing the account recovery process to fail.

[0084] The random value (or random number) is used to avoid replay attacks and enhance the security of the signing process. The random value requested each time is unique, so that even the same signature data can generate a different signature value, preventing attackers from reusing old signature data for malicious operations.

[0085] In one implementation, the method further includes: obtaining the user address recorded in the smart contract and the address corresponding to the caller of the smart contract; comparing the user address recorded in the smart contract and the address corresponding to the caller, and when the user address recorded in the smart contract and the address corresponding to the caller are equal, allowing the caller to call the smart contract; after the caller calls the smart contract, using the smart contract to record the pass key information and performing numerical increment processing on the random value.

[0086] In one implementation, when the owner of a smart contract needs to bind a Passkey, the smart contract adds a method to register a Passkey. The input parameters of this method are the Passkey public key and the verification signature algorithm type. When called, it will determine whether the call is initiated by the owner. If so, the call will succeed, otherwise the call will fail. After the owner successfully calls, the smart contract will record the Passkey information for subsequent verification, and the Nonce will also increase by 1.

[0087] As an example and not a limitation, a smart contract will record the owner information of the contract, such as the user address, and compare the recorded contract owner address with the caller address obtained from the transaction when the transaction was initiated. If the two are equal, the call is deemed successful.

[0088] By obtaining and recording the pass key information, the entire account recovery process will become more reliable and secure, allowing the account to be safely restored even if the user forgets the private key.

[0089] In one implementation, a smart contract is used to verify a digital signature, including: performing a hash calculation on an account recovery parameter according to a preset hash algorithm to obtain a first hash value; comparing the first hash value with a random challenge value in the user data, and when the first hash value is equal to the random challenge value, the verification is deemed to be successful, and the random challenge value is obtained by performing an off-chain hash calculation on the account recovery parameter.

[0090] It can be understood that the preset hash algorithm here can be MD5 (Message Digest Algorithm 5), SHA-1 algorithm (Secure Hash Algorithm 1), SHA-2 (Secure Hash Algorithm 2), SHA-3 (Secure Hash Algorithm 3), etc. The specific hash algorithm used can be set according to the actual application scenario and is not limited here.

[0091] On the one hand, after the client sends a transaction request for restoring an account, a hash calculation is performed on the args parameter according to a preset hash algorithm to generate a first hash value (hash1).

[0092] On the other hand, before the client sends a transaction request to restore the account, the args parameter is hashed to obtain the args hash (which can also be understood as hashing off-chain), and then the challenge field is set to the args hash. It can be understood that clientData is a byte array in json format, and the native data can be obtained by parsing json, thereby reading the challenge field.

[0093] In other words, args hash is generated by the client before sending a transaction request to restore the account. The random challenge value calculated by the off-chain hash of the account recovery parameters can prevent replay attacks and unfounded requests. Hash1 is calculated by the on-chain smart contract because the chain needs to verify the correctness of the hash to prevent tampering.

[0094] Then determine whether hash1 is equal to the challenge in clientData. If they are equal, the verification is considered to be successful, otherwise the verification fails.

[0095] By comparing the first hash value with the random challenge value, it can be effectively confirmed that the operation is indeed based on the latest user input information and random number generation. This process reduces the potential risk of fraud and prevents attackers from forging valid recovery requests. For example, even if an attacker can obtain certain user data, it is difficult to regenerate the same hash value. When the first hash value and the random challenge value are equal, it indicates the authenticity and validity of the recovery request, further improving security.

[0096] In one implementation, verifying a digital signature using a smart contract also includes: hashing user data and authentication data using a preset hash algorithm to obtain a second hash value; and verifying the digital signature based on the public key information of the pass key and the second hash value.

[0097] Similarly, the preset hash algorithm here is the same as the preset hash algorithm used above.

[0098] The user data (clientData) and the authentication data (authData) are hashed using a preset hash algorithm to obtain a second hash value (data hash).

[0099] Read the public key and verification signature algorithm type registered when binding Passkey from the contract. According to the verification signature algorithm type, select the corresponding verification algorithm for verification, enter the public key, data hash, signature, and enter the account owner reset process if the verification is successful, otherwise the verification fails.

[0100] It can be understood that different signature algorithm types will have different signature verification algorithms, and the signature verification algorithm type corresponds to the algorithm type used during registration.

[0101] Through this verification method, it can be confirmed that the digital signature is indeed generated by the holder of the passkey using the corresponding private key, thereby ensuring the authenticity of the user who initiated the request. This mechanism effectively prevents impersonation or forgery of requests.

[0102] In one implementation, when a digital signature is verified using a smart contract, the account recovery parameters are first hashed according to a preset hash algorithm to obtain a first hash value; the first hash value is compared with a random challenge value in the user data, and when the first hash value is equal to the random challenge value, the verification is deemed to be successful; then the user data and authentication data are hashed using a preset hash algorithm to obtain a second hash value; the digital signature is verified based on the public key information of the pass key and the second hash value.

[0103] Combined with the explanatory content above, it can be understood that the verification of these two parts has a certain order.

[0104] First, generate hash1 for the args parameter and compare it with the challenge in clientData to ensure the validity and integrity of the request. If hash1 and challenge are not equal, it means that the request parameters may have been tampered with or forged, that is, there is a risk in the first step of verification. In this case, it will fail directly at this stage without the need to proceed to subsequent steps, which can more effectively intercept the attack at the initial stage.

[0105] If this phase is verified, that is, after the validity of the account recovery parameters is confirmed, the next step is to hash the user data and authentication data to obtain a second hash value. This step ensures that the information used when verifying the digital signature is the latest and most reliable. Finally, the digital signature is verified using the public key information of the passkey and the second hash value. This process ensures that the generated digital signature is indeed generated by the user who owns the corresponding private key and is consistent with the current user data and authentication data.

[0106] That is to say, only when both the first and second steps are successful will the process of resetting the account owner begin. This sequence ensures that the account owner is not allowed to reset until all security mechanisms are confirmed to be correct, preventing unauthorized users from performing malicious operations.

[0107] In one implementation, user data and authentication data are hashed using a preset hash algorithm to obtain a second hash value, including: performing hash calculation on the user data according to the preset hash algorithm to obtain a user data hash value; concatenating the user data hash value and the authentication data to obtain concatenated data; and performing hash calculation on the concatenated data according to the preset hash algorithm to obtain a second hash value.

[0108] Similarly, the preset hash algorithm here is the same as the preset hash algorithm used above.

[0109] It can be understood that the preset hash algorithm is used to calculate the hash of clientData to obtain the user data hash value (clientDataHash). Then authData and clientDataHash are concatenated into a new byte array to obtain concatenated data, and then the preset hash algorithm is used to calculate the hash of the concatenated data to obtain a second hash value (data hash).

[0110] By combining the hash values ​​of user data and authentication data together and performing hash calculations, the complexity and security of the overall data are increased. This makes it more difficult to directly tamper with the hash value and provides higher anti-tampering capabilities.

[0111] In one implementation, the digital signature is verified based on the public key information of the pass key and the second hash value, including: decrypting the digital signature based on the public key information of the pass key to obtain the original signature data; comparing the original signature data with the second hash value, and when the value of the original signature data is equal to the second hash value, the verification is deemed to be successful.

[0112] It can be understood that the parameters required to verify the signature are the public key registered when binding Passkey, the second hash value (data hash), and the signature.

[0113] The signature is decrypted with the public key to obtain the original signature data, and the original signature data is compared with the second hash value (data hash). If the two are equal, the verification is deemed to be successful, otherwise the verification fails.

[0114] Comparing the decrypted original signature data with the second hash value can effectively verify whether the data has not been tampered with during transmission or storage. If the two are equal, it means that the original data has not been modified since it was generated, and the integrity of the data is protected.

[0115] In one implementation, after the verification is completed, the random value in the account recovery parameter is numerically increased to obtain an increased random value; and the increased random value is assigned to the random value.

[0116] As an example and not a limitation, the random value (Nonce) is incremented (e.g., +1) each time after the Passkey signature is verified to obtain an increased random value, and then the increased random value is assigned to the random value. The specific increment value can be freely set and is not limited here.

[0117] Doing so can prevent malicious actors from recovering accounts after signature verification. Due to the change in random values, even if an attacker captures information from a session, they cannot use that information again to simulate the operations of legitimate users, thus preventing the "double-spending" problem in the blockchain.

[0118] Combine the following Figure 4 Let’s give an overall introduction to the account recovery method mentioned above.

[0119] Figure 4 It is a schematic diagram of a scenario for calling an account recovery method provided in an embodiment of the present application.

[0120] like Figure 4 As shown, when any user calls the above account recovery method in a smart contract on the blockchain, by executing the above method, the method parameters include user data, authentication data, account recovery parameters and digital signature, and verification is performed in the smart contract according to the method parameters. When the verification passes, the new user address is modified to the owner address of the smart contract.

[0121] The above mainly introduces the method of the embodiment of the present application in conjunction with the accompanying drawings. It should be understood that although the various steps in the flowcharts involved in the embodiments described above are shown in sequence, these steps are not necessarily performed in sequence in the order shown in the figure. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and these steps can be performed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the embodiments described above may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times, and the execution order of these steps or stages is not necessarily performed in sequence, but can be performed in turn or alternately with other steps or at least a part of the steps or stages in other steps. A device of an embodiment of the present application is introduced below in conjunction with the accompanying drawings. For simplicity, when introducing the device below, it will be appropriately omitted, and the relevant content can refer to the relevant description in the method above, and will not be repeated.

[0122] Figure 5 It is a structural diagram of an account recovery device provided in an embodiment of the present application.

[0123] like Figure 5 As shown, the device 1000 includes the following units.

[0124] The acquisition unit 1001 is used to acquire authentication data, where the authentication data is generated according to preset identity information of the user.

[0125] The processing unit 1002 is used to obtain user data and account recovery parameters for account recovery based on the authentication data, where the account recovery parameters include a user address.

[0126] The processing unit 1002 is also used to use the pass key to sign the user data and authentication data to obtain a digital signature.

[0127] The processing unit 1002 is also used to verify the digital signature using the smart contract.

[0128] The processing unit 1002 is further configured to, if the digital signature verification is successful, determine the user address in the account recovery parameter as the target user address.

[0129] It can be understood that when the digital signature verification is passed, the user address (newOwner) in the account recovery parameter can be identified as the owner of the smart contract, and then the account owner is reset, and the owner address of the smart contract is changed to newOwner to complete the recovery of the contract account. After the recovery, the owner can use the new private key to call the contract account normally, and even if the user forgets the private key, they can re-access their assets.

[0130] By using Passkey to restore the account, it supports biometric methods such as fingerprint recognition and facial recognition. The smart contract account can be reset by simply pressing the fingerprint or recognizing the face. The operation is simple. After the reset, the account owner of the smart contract is the address corresponding to the reset private key. The user will not lose control of the smart contract even if he forgets or loses the private key, which ensures the security of users' use of smart contracts and improves ease of use.

[0131] In one implementation, the device 1000 further includes a storage unit 1003, which can be used to store instructions and / or data, so as to implement the method in the above embodiment.

[0132] In one implementation, the acquisition unit 1001 is also used to acquire and record the pass key information, where the pass key information includes the public key information of the pass key, a preset verification signature algorithm, and a random value; the processing unit 1002 is also used to bind the pass key in the smart contract according to the pass key information.

[0133] By obtaining and recording the pass key information, the entire account recovery process will become more reliable and secure, allowing the account to be safely restored even if the user forgets the private key.

[0134] In one implementation, the processing unit 1002 is also used to verify the digital signature using a smart contract, including: performing hash calculation on the account recovery parameters according to a preset hash algorithm to obtain a first hash value; comparing the first hash value with a random challenge value in the user data, and when the first hash value is equal to the random challenge value, it is determined that the verification is passed, and the random challenge value is obtained by performing an off-chain hash calculation on the account recovery parameters.

[0135] By comparing the first hash value with the random challenge value, it can be effectively confirmed that the operation is indeed based on the latest user input information and random number generation. This process reduces the potential risk of fraud and prevents attackers from forging valid recovery requests. For example, even if an attacker can obtain certain user data, it is difficult to regenerate the same hash value. When the first hash value and the random challenge value are equal, it indicates the authenticity and validity of the recovery request, further improving security.

[0136] In one implementation, the processing unit 1002 is also used to verify the digital signature using a smart contract, and also includes: using a preset hash algorithm to hash the user data and authentication data to obtain a second hash value; and verifying the digital signature based on the public key information of the pass key and the second hash value.

[0137] Through this verification method, it can be confirmed that the digital signature is indeed generated by the holder of the passkey using the corresponding private key, thereby ensuring the authenticity of the user who initiated the request. This mechanism effectively prevents impersonation or forgery of requests.

[0138] In one implementation, the processing unit 1002 is also used to perform hash processing on the user data and the authentication data using a preset hash algorithm to obtain a second hash value, including: performing hash calculation on the user data according to the preset hash algorithm to obtain a user data hash value; concatenating the user data hash value and the authentication data to obtain concatenated data; and performing hash calculation on the concatenated data according to the preset hash algorithm to obtain a second hash value.

[0139] By combining the hash values ​​of user data and authentication data together and performing hash calculations, the complexity and security of the overall data are increased. This makes it more difficult to directly tamper with the hash value and provides higher anti-tampering capabilities.

[0140] In one implementation, the processing unit 1002 is also used to verify the digital signature based on the public key information of the pass key and the second hash value, including: decrypting the digital signature based on the public key information of the pass key to obtain the original signature data; comparing the original signature data with the second hash value, and when the value of the original signature data is equal to the second hash value, the verification is deemed to be successful.

[0141] Comparing the decrypted original signature data with the second hash value can effectively verify whether the data has not been tampered with during transmission or storage. If the two are equal, it means that the original data has not been modified since it was generated, and the integrity of the data is protected.

[0142] In one implementation, the processing unit 1002 is further used to, after the verification is completed, perform numerical increase processing on the random value in the account recovery parameter to obtain an increased random value; and assign the increased random value to the random value.

[0143] Increasing the random value can prevent replay attacks or other potential security threats. Even if a hacker obtains a specific random value, if the random value has been modified in subsequent use, the hacker will no longer be able to use the previously obtained information to attack.

[0144] By increasing the value of the random value, the unpredictability of the random value is enhanced. This makes the result generated each time the random value is used different, further improving the security of the system.

[0145] The processing of random values ​​provides the system with status updates indicating the progress or status of the account recovery process. This update mechanism helps the system track and manage the account recovery process and ensure the continuity of operations.

[0146] In one implementation, the acquisition unit 1001 is also used to obtain the user address recorded in the smart contract and the address corresponding to the caller who calls the smart contract; the processing unit 1002 is also used to compare the user address recorded in the smart contract with the address corresponding to the caller, and when the user address recorded in the smart contract and the address corresponding to the caller are equal, the caller is allowed to call the smart contract; after the caller calls the smart contract, the smart contract is used to record the pass key information and the random value is numerically increased.

[0147] It should be noted that the information interaction, execution process and other contents between the above-mentioned units are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0148] Figure 6 Schematic diagram of the structure of the computer device provided in the embodiment of the present application. Figure 6 As shown, the computer device 3000 of this embodiment includes: at least one processor 3100 ( Figure 6 Only one) processor, memory 3200, and a computer program 3210 stored in the memory 3200 and executable on at least one processor 3100 are shown. When the processor 3100 executes the computer program 3210, the computer device implements the steps in the above embodiments.

[0149] The processor 3100 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0150] The memory 3200 may be an internal storage unit of the computer device 3000 in some embodiments, such as a hard disk or memory of the computer device 3000. The memory 3200 may also be an external storage device of the computer device 3000 in other embodiments, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the computer device 3000. Further, the memory 3200 may also include both an internal storage unit of the computer device 3000 and an external storage device. The memory 3200 is used to store an operating system, an application program, a boot loader (Boot Loader) data, and other programs, such as a program code of a computer program, etc. The memory 3200 may also be used to temporarily store data that has been output or is to be output.

[0151] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, only the division of the above-mentioned functional units is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units in the embodiment can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0152] The embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a computer device, the computer device can implement the steps in the above-mentioned method embodiments.

[0153] The embodiment of the present application provides a computer program product. When the computer program product is executed on a computer device, the computer device can implement the above-mentioned methods.

[0154] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, the computer device can implement the steps of the above-mentioned various method embodiments. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may at least include: any entity or device that can carry the computer program code to the camera / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electric carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electric carrier signals and telecommunication signals.

[0155] It should be understood that the size of the sequence number of each step in the above-described embodiment does not mean the order of execution, and the order of execution of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiment of the present application. In the description, for the purpose of explanation rather than for limitation, specific details such as specific system structure, technology and the like are proposed, so as to thoroughly understand the embodiment of the present application. However, it should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details. In other cases, the detailed description of well-known systems, devices, circuits and methods is omitted to prevent unnecessary details from hindering the description of the present application.

[0156] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0157] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0158] Additionally, in the specification of the present application and the description of the appended claims, the terms “include,” “comprise,” “have,” and their variations all mean “including but not limited to,” unless otherwise specifically emphasized.

[0159] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0160] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0161] In the embodiments provided in the present application, it should be understood that the disclosed devices, computer equipment and methods can be implemented in other ways. For example, the device and computer equipment embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0162] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. An account recovery method, characterized in that: Applied to a blockchain node device, the method comprises: Acquire authentication data, where the authentication data is generated according to preset identity information of the user; For the authentication data, obtaining user data and account recovery parameters for account recovery, wherein the account recovery parameters include a user address; The user data and the authentication data are signed using a pass key to obtain a digital signature; Verifying the digital signature using a smart contract; If the digital signature verification passes, the user address in the account recovery parameter is determined as the target user address.

2. The method according to claim 1, characterized in that Before obtaining the authentication data, the method further includes: Obtaining and recording pass key information, the pass key information including public key information of the pass key, a preset verification signature algorithm, and a random value; The pass key is bound in the smart contract according to the pass key information.

3. The method according to claim 2, characterized in that The verifying the digital signature by using a smart contract includes: Performing hash calculation on the account recovery parameter according to a preset hash algorithm to obtain a first hash value; The first hash value is compared with the random challenge value in the user data. When the first hash value is equal to the random challenge value, the verification is deemed to be successful. The random challenge value is obtained by performing off-chain hash calculation on the account recovery parameter.

4. The method according to claim 3, characterized in that The verifying the digital signature by using a smart contract also includes: Performing hash processing on the user data and the authentication data using a preset hash algorithm to obtain a second hash value; The digital signature is verified according to the public key information of the pass key and the second hash value.

5. The method according to claim 4, characterized in that The using a preset hash algorithm to perform hash processing on the user data and the authentication data to obtain a second hash value includes: Performing hash calculation on the user data according to the preset hash algorithm to obtain a hash value of the user data; Concatenate the user data hash value and the authentication data to obtain concatenated data; Perform hash calculation on the spliced ​​data according to the preset hash algorithm to obtain a second hash value.

6. The method according to claim 5, characterized in that The verifying the digital signature according to the public key information of the pass key and the second hash value includes: Decrypting the digital signature according to the public key information of the pass key to obtain the original signature data; The original signature data is compared with the second hash value, and when the value of the original signature data is equal to the second hash value, the verification is deemed to be successful.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: After the verification is completed, the random value in the account recovery parameter is numerically increased to obtain an increased random value; The added random value is assigned to the random value.

8. The method according to any one of claims 2 to 6, characterized in that: The method further comprises: Obtain the user address recorded in the smart contract and the address corresponding to the caller of the smart contract; Compare the user address recorded in the smart contract with the address corresponding to the caller. When the user address recorded in the smart contract and the address corresponding to the caller are equal, allow the caller to call the smart contract; After the caller calls the smart contract, the smart contract is used to record the pass key information and increase the random value.

9. An account recovery device, characterized in that: include: An acquiring unit, used to acquire authentication data, wherein the authentication data is generated according to preset identity identification information of the user; A processing unit, configured to obtain, based on the authentication data, user data and account recovery parameters for account recovery, wherein the account recovery parameters include a user address; The processing unit is further used to use the pass key to sign the user data and the authentication data to obtain a digital signature; The processing unit is further used to verify the digital signature using a smart contract; The processing unit is further configured to, if the digital signature verification passes, determine the user address in the account recovery parameter as the target user address.

10. A computer device, characterized in that: The computer device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the computer device implements the method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a computer device, the method according to any one of claims 1 to 8 is implemented.

Images