Method and system for key recovery using group structure

Abstract

A method includes a user device generating a key recovery message that includes a public key or an identifier thereof associated with an account. The public key corresponds to a first private key associated with the user device. The user device can provide the key recovery message to a smart contract on a blockchain. The user device can receive, from a server computer that monitors the smart contract, that the recovery message has been detected. The user device can generate a new private key to replace the first private key after providing the key recovery message to the smart contract.

Description

[0001] Cross-reference to related applications

[0002] Pursuant to Section 119(a) of Title 35 of the United States Code, this application claims the benefit of Greek Patent Application No. 20240100205, filed on March 20, 2024, which is incorporated herein by reference in its entirety for all purposes. Background Technology

[0003] Private key management is crucial for the security, availability, and recoverability of digital wallets. A digital wallet's private key is used to create digital signatures that prove ownership and rights to the wallet's contents. If the private key is lost or compromised, the content under the control of the digital wallet may be at risk of loss or theft.

[0004] Previous approaches to mitigating the problem of private key loss have involved using multi-party computation (MPC), standard multi-signature strategies, physical backups, smart contract rules, and digital clouds. However, current implementations of these technologies are insufficient for a wide range of potential real-world scenarios.

[0005] For example, some previous methods utilized a third party that could store a copy of the user's password key. If the user lost the device storing the password key, they could retrieve it from the third party. However, if the third party was compromised, the user's account would also be compromised.

[0006] As another example, some previous methods are vulnerable to preemptive attacks, where a malicious party can recognize that a user has lost their private key (e.g., the malicious party steals the user's phone that stores their private key) and request its recovery before the user notices the loss. In this scenario, the malicious party can "preempt" and obtain the recovery key before the user.

[0007] The embodiments of this disclosure address this problem and other problems individually or collectively. Summary of the Invention

[0008] The embodiments relate to methods and systems for private key management that enable digital wallets or other applications to remain secure in the event of loss of user devices, key shares, or the complete private key, while also providing a means for digital wallet owners to regain ownership of their digital wallet contents.

[0009] One embodiment relates to a method comprising: generating a key recovery message by a user device, the key recovery message including a public key or its identifier associated with an account, the public key corresponding to a first private key associated with the user device; providing the key recovery message to a smart contract on a blockchain by the user device; receiving a detected recovery message from a server computer monitoring the smart contract by the user device; and generating a new private key to replace the first private key after providing the key recovery message to the smart contract.

[0010] Another embodiment relates to a user device comprising: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor for implementing a method comprising: generating a key recovery message including a public key or an identifier thereof associated with an account, the public key corresponding to a first private key associated with the user device; providing the key recovery message to a smart contract on a blockchain; receiving a detected recovery message from a server computer monitoring the smart contract; and, after providing the key recovery message to the smart contract, generating a new private key to replace the first private key.

[0011] Another embodiment relates to a method comprising: detecting a change in a smart contract on a blockchain by a server computer, wherein the change is the inclusion of a key recovery message from a user device requesting the recovery of a first private key; determining by the server computer whether to cancel key recovery; generating a detected recovery message by the server computer based on the determination; and providing the detected recovery message to the user device by the server computer, wherein the user device generates a new private key to replace the first private key.

[0012] Further details regarding embodiments of this disclosure can be found in the detailed description and the accompanying drawings. Attached Figure Description

[0013] Figure 1 A block diagram of a key recovery system according to an embodiment is shown.

[0014] Figure 2 A block diagram of the components of a user device according to an embodiment is shown.

[0015] Figure 3 A block diagram illustrating a key share according to an embodiment is shown.

[0016] Figure 4 A block diagram of a blockchain according to an embodiment of the present invention is shown. Detailed Implementation

[0017] Before discussing the embodiments of this disclosure, some terms may be described in further detail.

[0018] A “user device” can be a device operated by a user. Examples of user devices can include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptops, desktop computers, server computers, vehicles (e.g., automobiles), simplified client devices, tablet PCs, and so on. Additionally, a user device can be any type of wearable technology device, such as a watch, headphones, glasses, etc. A user device can include one or more processors capable of processing user input. A user device can also include one or more input sensors for receiving user input. As is known in the art, there are various input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. User input obtained by input sensors can come from various data input types, including but not limited to audio data, visual data, or biometric data. A user device can include any electronic device that can be operated by a user, and said electronic device can also provide remote communication capabilities with a network. Examples of remote communication capabilities include using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network (e.g., the Internet or a private network).

[0019] "User" can include an individual. In some embodiments, a user can be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user can also be referred to as a cardholder, account holder, or consumer.

[0020] A "user identifier" may include any data that can identify a user. A user identifier may include any suitable alphanumeric string. In some embodiments, the user identifier may be derived from user identification information. In some embodiments, the user identifier may include an account identifier associated with the user.

[0021] A "blockchain" can be a distributed database that maintains a constantly growing list of records to prevent tampering and revision. A blockchain can include multiple blocks of interaction records. Each block in a blockchain can also include a timestamp and a link to previous blocks. In other words, interaction records in a blockchain can be stored as a series of "blocks" or a persistent file containing records of multiple interactions that occurred within a given time period. Blocks can be appended to the blockchain by appropriate nodes after they have been completed and verified. Each block can be associated with a block header. In embodiments of the invention, the blockchain can be distributed, and a copy of the blockchain can be maintained at each full node in the verification network. Any node within the verification network can then use the blockchain to verify interactions.

[0022] A "block header" can be a header that includes information about a block. A block header can be used to identify a specific block in a blockchain. A block header can include any suitable information, such as the previous hash, Merkle root, timestamp, and temporary number. In some embodiments, the block header may also include a difficulty value.

[0023] A "smart contract" can include distributed computer-executable program code. A smart contract can contain a set of rules that the parties to the smart contract agree to interact with each other according to. The program code is executed if and when predefined rules are met, and the protocols implemented in the program code are executed automatically. Smart contract code can execute in a blockchain network to provide a decentralized, automated mechanism for facilitating, verifying, and executing the negotiation or execution of agreements or transactions.

[0024] A "key" can be a piece of information used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms the original data into an alternative representation, or a decryption algorithm that transforms encrypted information back into the original data. Examples of cryptographic algorithms can include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), etc.

[0025] A "public key" can include an encryption key that can be openly and publicly shared. A public key can be designed to be shared and can be configured such that any information encrypted with the public key can only be decrypted using the private key associated with the public key (i.e., a public key / private key pair).

[0026] A "private key" can include any encryption key that can be protected and secure. The private key can be securely stored at the entity's location and can be used to decrypt any information encrypted using the associated public key of the public / private key pair associated with the private key.

[0027] A "public / private key pair" can include a linked pair of cryptographic keys generated by an entity. The public key can be used for public functions, such as encrypting messages to be sent to the entity, or for verifying digital signatures that should be made by the entity. The private key, on the other hand, can be used for private functions, such as decrypting received messages or applying digital signatures. In some embodiments, the public key may be authorized by a subject called a Certificate Authority (CA), which stores the public key in a database and distributes it to any other entity that requests it. The private key may typically be kept in a secure storage medium and will generally be known only to the entity in question. The public and private keys can be in any suitable format, including formats based on Rivest-Shamir-Adleman (RSA) or Elliptic Curve Cryptography (ECC).

[0028] A "key share" can include a portion of a key. A key can be divided into multiple key shares. Multiple key shares can be used to construct a key. Key shares can be used for cryptographic purposes. For example, a private key share can be used to digitally sign data.

[0029] A “commitment” can include cryptographic primitives that allow people to commit to a chosen value (or a chosen statement) while keeping it hidden from others and having the ability to reveal the committed value later. A commitment scheme is designed so that a party cannot change the value or statement after making a commitment: that is, a commitment scheme is binding.

[0030] A "secure element" can include components capable of performing functions securely. A secure element can be a memory that securely stores data, making its access protected. An example of a secure element is a Trusted Execution Environment (TEE), a secure area of ​​a processor. Another example of a secure element is a Universal Integrated Circuit Card (UICC), a secure smart card. Yet another example of a secure element is an embedded secure element, which is an embedded hardware component within a larger mechanical or electrical system. Another example of a secure element is a Hardware Security Module (HSM), a physical computing device that can protect and manage cryptographic keys used for authentication and provide cryptographic processing functions.

[0031] A “processor” can include means for processing things. In some embodiments, a processor can include any suitable one or more data computing means. A processor can include one or more microprocessors that work together to perform a desired function. A processor can include a CPU that includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor such as AMD’s Athlon, Duron and / or Opteron; IBM and / or Motorola’s PowerPC; IBM and Sony’s Cell processor; Intel’s Celeron, Itanium, Pentium, Xeon and / or XScale; and / or similar processors.

[0032] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory may include non-transitory computer-readable media whose storage can be executed by a processor to implement a desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0033] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers operating as a single unit. In one example, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0034] Embodiments of the present invention allow for private key management that enables digital wallets (or other applications) to remain secure in the event of loss of user devices, key shares, or the complete private key, while also providing a means for digital wallet owners to regain ownership of their digital wallet contents.

[0035] Users and user devices can be associated with user accounts. User accounts can be associated with private cryptographic keys. A first private key can be stored in the user device (e.g., within the secure element of the user's mobile phone). A second private key can be provided to the user separately from the first private key. The second private key can be securely written down, stored on a different device, or stored in cold storage, etc. A third private key can be stored by a server computer associated with the user account.

[0036] In some embodiments, each private key may be formed from a private key share, wherein the private key is associated with a user account. The user device may use the private key share to perform interactions (e.g., transactions, access requests, etc.) with smart contracts stored in the blockchain during a 3-key signature process. Each interaction may dynamically have a threshold of the number of key shares required to digitally sign the data used by the smart contract to complete the interaction (e.g., 1 private key share signature).

[0037] If a user loses access to the first or second private key, the user device can perform a key recovery process to obtain a replacement private key.

[0038] For example, a user device can generate a key recovery message. The key recovery message may include a public key associated with the user account or its identifier. The public key may correspond to a first private key. The user device can then provide the key recovery message to a smart contract on the blockchain.

[0039] The server computer can monitor updates to smart contracts. The server computer can identify user devices that provide key recovery messages to smart contracts. The server computer can generate a detected recovery message and provide it to the user device.

[0040] After providing a key recovery message to the smart contract and / or after receiving a detected recovery message, the user device can generate a new private key to replace the first private key.

[0041] In embodiments of the present invention, the user device can use the key generation algorithm used in the group signature scheme to generate a new private key to replace the lost private key, while maintaining the same corresponding public key.

[0042] A group signature scheme is a signature scheme associated with a group of participants called a group. Members of the group (individually or based on a certain group structure) can generate signatures for messages using a key called the group public key or group verification key, which can be verified as being generated by the group. Members generate signatures using their own group member signature key or group secret key (gsk). In embodiments of the invention, a user device's user can access two group secret keys (e.g., a first private key and a second private key). A server computer can access the group secret keys (e.g., a third private key). The group secret keys can be used to sign data for members of the group, while smart contracts on the blockchain network can hold the group verification key to verify signatures generated by devices within the group.

[0043] In one example, a user registers their user devices with a smart contract, including a mobile device and a smartwatch. The user device can use a cryptographic key generation protocol to generate a first private key sk1 for the mobile device and a second private key sk2 for the smartwatch. Both the first private key sk1 and the second private key sk2 can be generated so that they can be authenticated by the group verification key gvk. The user device that generates or obtains the private key can securely store the private key and ensure that the private key does not leave the user device.

[0044] Embodiments of the present invention include a dynamic group signature scheme that allows the group structure to change over time. In embodiments of the present invention, new members can be added to the group without the need for smart contract actions, and the signing permissions and membership of a user device or user (individually or as part of the group structure) can be revoked. Further details regarding group signatures can be found in PCT Publication WO 2023 / 003582, published on January 26, 2023, which is incorporated herein by reference.

[0045] Embodiments of the present invention can utilize the concept of an extended signature key space. Embodiments of the present invention can include many functionally equivalent signature keys for any given verification key. Embodiments of the present invention can also have the property that, given any signature key corresponding to a verification key, another random, functionally equivalent signature key can be generated. For this purpose, a re-randomization function can be described with reference to the following pseudocode. The following are the general ideal functions in [the context].

[0046]

[0047] Device A has a signature scheme of .

[0048] Device B requires a random signature key sk corresponding to vk. B .

[0049] enter: , ,

[0050] Output: Uniformly distributed under the following constraints: for all m , r : .

[0051] This pseudocode illustrates a scenario where device A generates a new key for device B. Device A already possesses a verification key (vk) and a unique secret key (sk). A The verification key and unique secret key may have been generated using a key generation protocol (KeyGen). Device A will use its first secret key (sk). A The device B generates a random signature key or secret key (sk) corresponding to the verification key (vk). B ).

[0052] Embodiments of the present invention may include a modified key generation process. and These processes can be based on the Schnorr and El Gamal signature schemes, respectively. For more details, see C. Schnorr, “Efficient identification and signatures for smart cards,” published in [Journal Name]. Advances in Cryptology - CRYPTO '89, 9th Annual International Cryptology Conference Figure 1 Santa Barbara, California, USA, August 20-24, 1989, Proceedings of the Conference, Lecture Notes in Computer Science Series, edited by G. Brassard, Springer, Vol. 435, 1989, pp. 239–252, and WO2023 / 003582, all cited herein.

[0053] the following The protocol can be used to utilize the secret key (sk) of device A. A Generate a secret key (sk) for the new device B. B The input can include the following: (group), q (prime order), M (scaling parameter), and vk (verification key).

[0054]

[0055] A has a key pair

[0056] B requires a random signing key sk corresponding to vk. B .

[0057] enter: , ,

[0058] protocol: 1) A calculation And send it to B.

[0059] 2) B Random Sampling .

[0060] 3) Output B .

[0061] Output: ,

[0062] The second user device (B) submits a request to the first user device (A), which is part of the group (G), to join the group (G). The first user device (A) stores the first secret key (sk). A ).

[0063] Upon receiving the request from the second user unit B, the first user unit A uses equation sk A mod q Form a value (x). The value (x) can be represented as the first secret key value (sk). A The value of (x) is changed. Then, the value (x) is sent to the second user device (B).

[0064] Upon receiving a value (x) from the first user device A, the second user device (B) generates a temporary number (y) based on a scaling parameter (M). The second user device (B) uses this temporary number (y), along with the modulus value (q) and the value (x), to perform an equation... Generate a second secret key (sk) B ).

[0065] The second user unit (B) stores the second secret key (sk). B Then, the second user device (B) is added as a member of the group. First secret key (sk) A ) and the second secret key (sk B The signatures are different, but the same data can be signed and verified by the same group verification key (vk).

[0066] The following key generation function Based on the El Gamal process, and using the first secret key (sk) of the first user device A. A Generate a new second secret key (sk) for the new second user device B. B ).

[0067]

[0068] A has a key pair

[0069] B requires a random signing key sk corresponding to vk. B .

[0070] enter: ,

[0071] protocol: 1) A calculation And send it to B.

[0072] 2) B Random Sampling .

[0073] 3) Output B .

[0074] Output: ,

[0075] The pseudocode above illustrates the use of the first secret key (sk) of the first user device A. A Add a new second secret key (sk) to the second user device B. B The process of ).

[0076] Figure 1 A system 100 according to an embodiment of the present disclosure is illustrated. System 100 includes a user device 102, a server computer 106, and a blockchain network 110. User device 102 includes a secure element 104. Server computer 106 includes memory 108. Blockchain network 110 includes smart contracts 112. User device 102 can operatively communicate with server computer 106 and blockchain network 110. Server computer 106 can operatively communicate with user device 102 and blockchain network 110.

[0077] To simplify the explanation, Figure 1 A specific number of components are shown. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include more than one of each component. Figure 1The components shown are fewer or more components.

[0078] Figure 2 Messages between devices included in the system 100 shown can be transmitted using secure communication protocols, such as, but not limited to: File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); SSL; ISO (e.g., ISO 8583) and / or similar protocols. The communication network can include any and / or a combination of: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an Operational Mission as a Node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.); and so on. The communication network can use any suitable communication protocol to generate one or more secure communication channels. In some cases, the communication channels may include secure communication channels that can be established in any known manner, such as by using mutual authentication and session keys, and by establishing a Secure Sockets Layer (SSL) session.

[0079] User device 102 may include a device operated by a user. Examples of user devices may include mobile phones, smartphones, laptops, desktop computers, etc. User device 102 can handle interactions and can digitally sign data in smart contracts 112 within the blockchain network 110.

[0080] User device 102 may include a secure element 104. The secure element 104 may securely store data. The secure element 104 may store a cryptographic key, such as a first private key. The first private key may be associated with a user account.

[0081] Embodiments of the present invention may include a number of protocols, including management functions. Such functions may include key generation (KeyGen), adding members (AddMember), signing (Sign), signing open (SigOpen), revoking members (RevokeMember), and verification (Ver). It is assumed that only members of the management group (e.g., devices and / or authenticators) can use these protocols. These functions may be executed by user device 102, server computer 106, or smart contract 112. Further details regarding these functions can be found in PCT Publication WO 2023 / 003582, published on January 26, 2023, which is incorporated herein by reference.

[0082] When a device is added for the first time, a registration process is performed. The registration process can be the process of registering an authentication protocol provided by smart contract 112 and introducing (multiple) first authenticators or (multiple) first user devices (e.g., user device 102). For example, a (gsk) signature can be generated on user device 102 using the group signature KeyGen protocol. i The user device 102 securely stores the gsk key pair. i The gvk is then transferred to the smart contract. A table is created on the smart contract, and the user device nickname of user device 112 is added to the list. At the end of this stage, an authentication process can be performed to verify the registration. The authentication process can be similar to registering for the FIDO (Fast Online Authentication) authentication service.

[0083] In some embodiments, KeyGen is a key generation protocol that determines a public group authentication key (gvk), a public identity ledger, and a private key for each individual group member. It can be used when one or more devices first register to the group or when generating a new private key. The key generation method is as follows: sample , , and .

[0084] Sample random values and commitment .set up ,in .

[0085] For each , o Use input run (Playing the roles of both parties) to obtain .

[0086] o Use randomness Calculate commitment , . ( "in (This indicates that running the KeyGen routine does not necessarily require a random value.)

[0087] o Use randomness Calculate ciphertext .

[0088] o set

[0089] o set .

[0090] o will , , and Add to .

[0091] First, the user devices in the user device group can run To obtain the public key ek and the secret key dk. This can be a CCA2-secure public-key encryption scheme. Then, run a re-randomized signature scheme. To obtain the verification key (vk) and signing key (sk). Then use... Generate a public reference string `crs`, where NIZK is a non-interactive zero-knowledge proof, such as those described in: ZKProof, “ZKProof Community Reference”, version 0.2, edited by D. Benarroch, LTAN Brandão, and E. Tromer, published by zkproof.org, December 2019. Then, use... Sample the common parameters (pp).

[0092] Then, select a random value. and use Generate a commitment com. Then, the value... Form a group verification key (gvk), where (This indicates that the table is empty).

[0093] The protocol iterates through each member device in the group (G) to register each device (e.g., user device 102 and server computer 106 can register to the group). The KeyGen protocol (which can be presented as software on user devices) in... Use the secret key (sk) previously generated along with the verification key (vk) to obtain a unique random secret key (sk). i ).

[0094] After obtaining this unique random secret key (sk i After that, use a random value. Computational Commitment (com) i,1 and .com i,2 ).

[0095] In calculating commitment (com) i,1 and .com i,2 ) and the unique secret key (sk i After that, the user device uses the encryption key (ek) and a random value ( ) compute ciphertext (ct) i ).

[0096] In calculating ciphertext (ct) i After that, as mentioned above, four private keys can be generated: the group signature key (gsk) i ), issuance key (ik) i ), Open key (ok) i ) and revocation key (rk) i ).

[0097] The four private keys can have the following characteristics. Group signature key (GSK) i ) can be used to generate signatures on data (e.g., challenges). Issuance key (ik) i This can be used to add new members to the group. Open key (ok) i The revocation key (rk) can be used to identify the member or user device that generated the signature. i This can be used to remove a member from a group.

[0098] In generating ciphertext (ct) i After that, the member registers in the system and, along with the ciphertext (ct) i Together, they are included in the table on smart contract 112. When user device 102 is added to the group structure ( Registration is complete when adding, signing, opening, and undoing actions are performed.

[0099] AddMember is a protocol that adds new members to a group and generates private keys for the new members. This method can be used to add new devices to a device group after the first group of devices has been registered.

[0100] To add an additional user device to a group, the user first runs a setup process to establish a connection between a first user device already in the group and a new second user device that is not part of the group. On any previously registered user device, the user selects the services the new device should register for and runs the AddMember protocol to add the new group member. The system can update the device list (Table) on the server computer during the first authentication attempt from the new second user device.

[0101] In some embodiments, a user may possess a first private key and a second private key. If the first private key is lost, the user can use the second private key to help generate a new private key to replace the lost first private key. The user can add the second private key to user device 102, where the second private key can be used to generate a new private key to add user device 102 as a new member. In some cases, server computer 106 may store a third private key, which is a member of the group. User device 102 can communicate with server computer 106 to add a user device with the new private key to the group.

[0102] The pseudocode for an example of the AddMember protocol is as follows: : Participants and use As Input to run ,at the same time get Participants will also Passed to the participants .

[0103] Participants Use random values Calculate commitment .

[0104] Participants Use random values Calculate commitment .

[0105] Participants and Then exchange and .

[0106] Participants Using randomness Calculate ciphertext .Will Send to the participants .

[0107] Participants calculate ,in And this relationship is defined as follows: : o

[0108] o

[0109] and set .

[0110] o Participants Will Add to and will , , and Add to .

[0111] Participants set up

[0112] o

[0113] o

[0114] o

[0115] o

[0116] Server computer 106 can assist user device 102 in digitally signing data in smart contract 112. Server computer 106 may store another private key (e.g., a second private key) associated with the user account. In some embodiments, server computer 106 may work in conjunction with user device 102 to digitally sign data in smart contract 112.

[0117] The AddMember protocol allows members of a user device group to add new user devices to the group. This eliminates the need for a server computer to generate new private keys for new user devices to be added to the group. This has technical advantages, including reduced computational workload on dependent computers and reduced online requirements for dependent computers when adding new devices to the group. Furthermore, because key generation for new devices is managed by different user devices in different groups, higher system security is achieved. A compromised dependent computer does not lead to a compromised entire system.

[0118] Server computer 106 and user device 102 can sign data using the following signature protocol. Sign is a protocol for generating signatures for group members. This signature is used to authenticate the user device during verification by a smart contract. The algorithm for the signature protocol can be as follows: : Generate signature .

[0119] Using randomness Calculate ciphertext .

[0120] Calculation proof ,in And the relationship is... definition: o

[0121] o

[0122] o (“ (This can represent a value that is not needed for the execution of the signature subroutine.) set up .

[0123] in, It is a message containing data to be signed. ) is the group private key, ( ) is the device's private key, ( ) indicates randomness, ( ) is a promise, ( ) is a random value, ( ) is ciphertext, ( ) is proof, ( ) is a random value, ( ) is an index, and ( ) is the verification key.

[0124] Use secret key (sk) i The device (i) (e.g., a user device) signs the message m, thereby generating a temporary signature ( This temporary signature ( The signature is encrypted using a cryptographic key (ek) and randomness (r), which can conceal the identity of the device that created the signature. Cryptographic Signature ( ) generates ciphertext (ct).

[0125] Verify statements containing ciphertext (ct) using zero-knowledge proofs (NIZK). Then, upon successful verification, the device generates an official signature containing the ciphertext (ct) and proof (π). ).

[0126] Server computer 106 can monitor smart contracts on blockchain network 110. Server computer 106 can generate a detected recovery message indicating that server computer 106 has detected a recovery attempt on a user account associated with a user device. The detected recovery message may include a user account identifier. Server computer 106 can provide the detected recovery message to user device 102 to notify the user of the recovery attempt.

[0127] In some embodiments, user device 102 may not have initiated a recovery attempt. In such cases, user device 102 may respond to a detected recovery message to notify server computer 106 that the recovery attempt is fraudulent.

[0128] Blockchain network 110 may include multiple devices capable of storing blockchain data. Blockchain network 110 may include, for example, multiple full nodes, each storing the entire blockchain. Multiple full nodes can generate and store blocks on the blockchain. Each full node can be configured to store the blockchain in any suitable storage device or database.

[0129] The blockchain, maintained by blockchain network 110, can store smart contracts 112. Smart contracts 112 can include coded actions to be executed when predetermined conditions are met. When the predetermined conditions are met and verified, computers in the blockchain network can execute these actions. These actions can include releasing funds to appropriate participants, registering vehicles, sending notifications, issuing tickets or passes, etc. The blockchain is then updated when the transaction is completed. Therefore, the transaction cannot be altered. In some embodiments, a licensed device can see the result of smart contract 112.

[0130] In some embodiments, smart contract 112 may use the following exemplary verification protocol or other verification protocols to verify the received signature: : Output .

[0131] This verification protocol uses signatures ( ), the message that the signature targets ( m The signature is input along with the group verification key (gvk). It verifies the proof (π) to determine if the signature is valid. The smart contract 112 can maintain a group structure that indicates a list of private keys corresponding to the group verification key.

[0132] SigOpen is a protocol for determining the members of a group that generates signatures. The algorithm for the SigOpen protocol is as follows: : if Then output Otherwise, calculate the plaintext. and output .

[0133] The method can use the Ver protocol to determine the signature by using proof (π). Is the signature valid or invalid? (This is related to verifying the signature.) Afterwards, the SigOpen protocol uses the open key (ok) (which is also the decryption key (dk)) to decrypt the ciphertext (ct). By decrypting the ciphertext (ct), the protocol can identify the signature created. (i) the device or participant.

[0134] In some embodiments, during an interaction (e.g., a transaction, an access request, etc.), smart contract 112 may require a certain number of signatures on the interaction data provided to smart contract 112. These signatures may need to be verified by a group verification key gvk corresponding to multiple group private keys. The required number of signatures may be a threshold k that is dynamically determined based on factors such as the interaction amount, interaction volume, interaction speed, and user settings.

[0135] Figure 3 A block diagram of a user device 102 according to an embodiment is shown. The exemplary user device 102 may include a processor 204. The processor 204 may be coupled to a memory 202, a secure element 104, a network interface 206, a computer-readable medium 208, an input element 210, and an output element 212. The computer-readable medium 208 may include a signature module 208A, a recovery request module 208B, and a password key generation module 208C.

[0136] Memory 202 can be used to store data and code. For example, memory 202 can store cryptographic keys, identifiers, messages, and / or other data. Memory 202 can be coupled internally or externally to processor 204 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory (such as RAM, DRAM, ROM, flash memory, or any other suitable memory device).

[0137] Computer-readable medium 208 may include code executable by processor 204 for performing a method comprising: generating a key recovery message by a user device, the key recovery message including a public key or an identifier thereof associated with an account, the public key corresponding to a first private key associated with the user device; providing the key recovery message by the user device to a smart contract on a blockchain; receiving a detected recovery message by the user device from a server computer monitoring the smart contract; and, after providing the key recovery message to the smart contract, generating a third private key to replace the first private key.

[0138] The signature module 208A may include code or software executable by the processor 204 for signing data using a cryptographic key. The signature module 208A, in conjunction with the processor 204, may sign interactive data using a private key stored in the secure element 104. In some embodiments, the signature module 208A may be located within the secure element 104.

[0139] The recovery request module 208B may include code or software executable by the processor 204 for creating a key recovery message. The recovery request module 208B, in conjunction with the processor 204, can generate a key recovery message that includes an account identifier for the account.

[0140] The password key generation module 208 may include code or software executable by the processor 204 for generating password keys. The password key generation module 208, in conjunction with the processor 204, can generate a private key corresponding to the public key of an account. For example, the password key generation module 208, in conjunction with the processor 204, can use the AddMember function or other key generation functions described above to generate the private key.

[0141] In some embodiments, the password key generation module 208C may be located within the security element 104.

[0142] Network interface 206 may include an interface that allows user device 102 to communicate with an external computer. Network interface 206 enables user device 102 to transmit data to another device (e.g., server computer 106, blockchain network 110, etc.) and to transmit data from said other device. Some examples of network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot, and a card, etc. Wireless protocols enabled by network interface 206 may include Wi-Fi. TMData transferred through network interface 206 may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals that can be received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may contain data or instructions, may be provided between network interface 206 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0143] Input element 210 may include any suitable device(s) capable of inputting data into user device 102. Examples of input devices include buttons, touchscreens, touchpads, microphones, etc.

[0144] One or more output elements 212 may include any suitable plurality of devices capable of outputting data. Examples of output elements 212 may include a display screen, a speaker, a data transmission device, etc.

[0145] Figure 3 A flowchart illustrating the method according to an embodiment is shown. The description will be given in the context that the user has lost access to the first private key associated with the user account. Figure 3 The method shown.

[0146] Figure 4 The method shown provides private cryptographic key recovery without involving a third party generating a new private key. Instead, user device 102 itself can generate a new private key.

[0147] In some embodiments, the method can utilize a required security deposit to suppress unauthorized account recovery requests. For example, a user can initiate an account recovery process that invokes a time lock. If the recovery request is unauthorized, this time lock provides time for an authorized user to dispute the request (as notified by server computer 106). If the dispute is successful, the security deposited by the initiator (if malicious) is forfeited.

[0148] The system can utilize a group signature cryptographic scheme that creates multiple private keys. A first private key (sk1) is securely stored on user device 102. A second private key (sk2) is stored externally to the user device (e.g., in cold storage, on a second user device, or in a secure cloud backup service), and a third private key (sk3) is stored on server computer 106. These three private keys are used in the group signature cryptographic scheme to create a single public key pk and a group structure Π.

[0149] The group structure Π may include information about the group verification key gvk, which is a public key capable of verifying signatures created by private keys added to the group structure. Therefore, the group verification key gvk can verify signatures created by a first private key, a second private key, and a third private key, all of which are added to the group structure.

[0150] In some embodiments, the group structure Π includes a static threshold parameter t (which is a value between a given number and the maximum number of keys or key shares). Therefore, the group structure Π can be replicated within smart contract 112 as Π1, Π2, and Π3, where Πt corresponds to different thresholds t. The logic of smart contract 112 dynamically selects the group structure Πt (and thus t) based on the conditions of the on-chain interaction (e.g., interaction speed, spending limits, etc.) to determine how many signatures from different private keys are needed to process the interaction.

[0151] At step 302, after losing access to the first private key (sk1), user device 102 may generate a key recovery message. The key recovery message may indicate that the private key needs to be recovered for a specific account associated with the user. The key recovery message may include the public key associated with that account or its identifier. The public key may correspond to the first private key (which has been lost).

[0152] In some embodiments, the key recovery message may also include the amount of a security deposit used for the recovery process. The key recovery message may include a reference to the source of funds for the security deposit. For example, the key recovery message may include a reference to a second account associated with the user of user device 102, and authorization from the user to transfer a certain amount of funds from the second account to smart contract 112 as a security deposit.

[0153] At step 304, after generating the key recovery message, user device 102 can provide the key recovery message to blockchain network 110. Specifically, user device 102 can provide the key recovery message to smart contract 112 maintained by blockchain network 110 in the blockchain.

[0154] At step 306, after receiving the key recovery message, blockchain network 110 can provide the key recovery message to smart contract 112 maintained by blockchain network 110. Smart contract 112 can store the indication of the attempted recovery process along with the key recovery message in the smart contract. Smart contract 112 can also obtain the amount of margin funds from the funding source indicated in the key recovery message.

[0155] At step 308, server computer 106 can continuously monitor updates to smart contract 112 on blockchain network 110. For example, server computer 106 can check updates to smart contract 112 every second, minute, five minutes, etc. Server computer 106 can identify changes to the contract by viewing interactions / transactions with smart contract 112, indicating that a recovery attempt has been initiated. Server computer 106 can also identify whether any password key recovery attempts have been made for the account.

[0156] Server computer 106 may have certain permissions to a user's account. For example, server computer 106 may have issued the account or be able to maintain the account. Server computer 106 may store the private key associated with the account. Server computer 106 may store a third private key for the account, while the user can access the first private key.

[0157] At step 310, server computer 106 may generate a detected recovery message. The detected recovery message may indicate that server computer 106 has detected a key recovery attempt for a specific account. The detected recovery message may include an account identifier of the account associated with the key recovery attempt.

[0158] At step 312, after generating the detected recovery message, server computer 106 can provide the detected recovery message to user device 102. Server computer 106 can also provide the detected recovery message to the device associated with the account. If the user has lost their original user device and original private key, the user can use server computer 106 to update the user profile with the identifier of the new user device (e.g., user device 102). Therefore, server computer 106 can provide the detected recovery message and any other messages to the device associated with the account, or to a server acting as a payment guardian / monitoring service.

[0159] At step 314, after receiving the detected recovery message, user device 102 can determine whether user device 102 has initiated a key recovery process. If user device 102 has indeed initiated a key recovery process (e.g., at step 302), user device 102 can proceed to step 316.

[0160] If user device 102 has not initiated a key recovery process, user device 102 may prompt its user for input. User device 102 may prompt the user to enter whether they initiated a key recovery process. For example, user device 102 may prompt the user to enter a choice for dispute recovery, cancel recovery, or accept recovery. If the user selects that they did indeed initiate a key recovery process (e.g., accept recovery), user device 102 may proceed to step 316. If the user selects that they did not initiate a key recovery process (e.g., dispute recovery), user device 102 may respond to server computer 106 with an indication that the recovery request is fraudulent.

[0161] In some embodiments, if the user does not recognize the recovery request, the user device 102 can generate an interactive dispute message, which can be signed using a first private key (which can still be the original private key). The user device 102 can provide the interactive dispute message directly or via server computer 106 to smart contract 112 in blockchain network 110. In this case, the margin amount can be deposited into the user's account.

[0162] In some embodiments, if the key recovery request is legitimate, user device 102 may wait for a predetermined period of time (e.g., 5 minutes, 10 minutes, 1 hour, etc.) after which smart contract 112 of the blockchain network executes the key replacement as described in step 318. If the key recovery request is fraudulent, the recovery may time out and will not be processed after the predetermined period of time.

[0163] If the user finds the lost private key during this period, the user can invoke a cancellation operation (e.g., cancel recovery) using user device 102. This cancellation operation can stop the recovery process and return the margin to the user. For example, user device 102 can respond to a detected recovery message with a cancellation recovery instruction. Server computer 106 can instruct smart contract 112 to return the margin to the funding source.

[0164] At step 316, user device 102 may generate a new private key (e.g., a third private key) to replace the original private key (e.g., the first private key). User device 102 may generate the new private key as described above. Therefore, the new private key can be generated through a cryptographic keying process that allows the new private key to be used with the public key.

[0165] At step 318, user device 102 may generate a key update message. The key update message may include instructions to update the group structure to revoke the first private key (e.g., a lost private key) with a new private key. The key update message may include a public key corresponding to the private key. The key update message may be signed using a second private key known to the user and previously added to user device 102. For example, the key update message m may be "1) Revoke key sk1, 2) Add key sk1'", where key sk1 is the first private key and key sk1' is the new private key. User device 102 may generate a digital signature on the key update message m using the second private key sk2. ,For example .

[0166] In some embodiments, a key update message may require two or other suitable numbers of signatures to be accepted by the smart contract 112. The user device 102 can sign the key update message m and store the signatures... The key update message m is provided to the server computer 106 so that the server computer 106 can sign the key update message m using the third private key sk3. Therefore, the signature... It can be formed using the second private key sk2 and the third private key sk3. For example, a signature. It can be formed as .

[0167] At step 320, user device 102 may provide a key update message to smart contract 112.

[0168] At step 322, smart contract 112 of blockchain network 110 can verify the signature of the key update message. If the signature is valid and the key update message is signed by the required number of private keys, smart contract 112 can update the stored group structure to add new private keys and remove the original first private key. Therefore, smart contract 112 can revoke private key members (e.g., the original private key) and can add new private key members (e.g., the new private key) to the group structure.

[0169] In other embodiments, user device 102 may generate a new private key before providing a key recovery message to smart contract 112. For example, the user device may perform step 316 before step 302. Then, user device 102 may include the new private key and digital signature in the key recovery message sent to smart contract 112. In this case, the data contained in the key update message during the initial communication with the smart contract can instead be included in the key recovery message. Doing so reduces the total number of messages sent between devices.

[0170] Figure 4 A diagram of a blockchain according to an embodiment of the present invention is shown.Advances in Cryptology - 2015 The blockchain includes a blockchain 400, which includes a first block 410 and a second block 440. The blockchain 400 may include any suitable number of blocks (e.g., 10, 500, 2000, 500000, etc.).

[0171] Current blockchain technologies, such as Bitcoin and Ethereum, maintain an append-only ledger within the network. The ledger comprises a list of blocks of transaction data, cryptographically linked together. Blocks are created through a computationally intensive process called proof-of-work, where valid blocks must demonstrate sufficient "difficulty" (i.e., enough computing power to create them on average). If more than one blockchain exists, network participants (i.e., nodes) can download all blocks from all chains and follow the chain with the highest overall difficulty. This mechanism guarantees that, eventually, the network will agree on a single, valid chain; see [Garay et al., Bitcoin Backbone Protocol: Analysis and Applications]. Advances in Cryptology - EUROCRYPT 2015 Advances in Cryptology - [In, pp. 281–310, 2015], [Bitcoin website. bitcoin.org], and [Rafael Pass, Lior Seeman, and Abhi Shelat. Analysis of blockchain protocols in asynchronous networks. Edited by Jean-Sébastien Coron and Jesper Buus Nielsen] Advances in Cryptology - EUROCRYPT 2017 ​ [Cham, 2017. Springer International Publishing, pp. 643-673.] All of the above references are incorporated herein by reference for all purposes.

[0172] Blockchain 400 can create a history of data deposits, messages, or entries across a series of blocks, where each block contains a mathematical summary (called a hash) of the previous block. This creates a chain in which any change made to a block alters the hash of that block, which must be recalculated and stored in the next block. This changes the hash of the next block, which must also be recalculated, and so on, until the end of the chain.

[0173] While hashes may be computationally simple, rules can be imposed requiring hash values ​​to be below a certain threshold (i.e., a difficulty value). Furthermore, hashes are based on a class of irreversible mathematical functions. It's impossible to predict what inputs will produce the desired output. Valid hashes can be found by repeatedly adjusting the variable values ​​in a block and recalculating the hash until it meets the validity requirements. The freely changeable values ​​can be temporary numbers. The unpredictability of hashes greatly increases the difficulty of finding temporary numbers that produce valid hashes for blocks.

[0174] As an example, the first block 410 may include a block header 420 and a block entry 430. The block header 420 of the first block 410 may include a previous hash 412, a timestamp 414, a Merkle root 416, and a temporary number 418.

[0175] The previous hash 412 can be a hash of the header of the previous block. The previous hash 412 can be the result of an irreversible mathematical computation using data from the previous block as input. According to some embodiments, the computation used may include the SHA256 hash function. Those skilled in the art will recognize that any suitable hash function can be used without departing from the spirit and scope of the invention. The hash function can be designed such that any change to the data in the previous block causes an unpredictable change to the hash of said block. The previous hash 412 can be a link between blocks that connects the blockchains to form blockchain 400.

[0176] When calculating the previous hash 412 for the previous block, a node can determine whether the previous hash 412 meets a specific criterion defined by a difficulty value. In some embodiments, the difficulty value may include a number that the calculated hash must be less than. However, because the output of a hash function is unpredictable, it is impossible to determine which input will result in an output less than the difficulty value before the hash is calculated. A temporary number 418 can be used to modify the data content of a block, allowing the hash function to produce a large number of different outputs in pursuit of an output that meets the difficulty value. This can make producing a valid block with a temporary number 418 that produces a hash value that meets the difficulty value criterion.

[0177] The hashing algorithm used for the previous hash 412 can include MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512 / 224, SHA-512 / 256, SHA-3, or any suitable hash function. It is not required that the hash be computed only once. The result of a hash function can be reused multiple times as input to another or the same hash function to produce the final result. Those skilled in the art will recognize that any hash function can be used to compute the desired hash without departing from the spirit and scope of the invention.

[0178] Merkle root 416 can be the root of a Merkle tree, which can include a tree in which each leaf node is labeled with a hash of a data block (e.g., an entry). Each leaf of the Merkle tree can represent one of the entries. Each entry can be hashed together with its sibling nodes (i.e., entries) in the Merkle tree. Successive hashing of sibling nodes in the Merkle tree can produce Merkle root 416.

[0179] Block entry 430 may include interaction data and / or smart contracts. Block entry 430 may include any suitable number of entries. Example entries may include the data described above, such as witnesses, signed witnesses, digital signatures, interaction messages, unconditional payment data, proof of inclusion, and other data related to the processing of offline interactions between two user devices. In some embodiments, entries may be null, for example, in the case where the Merkle tree is a sparse Merkle tree.

[0180] In some embodiments, the number of entries in block entry 430 may be limited by the overall size of the block (e.g., the first block 410). For example, blocks on a blockchain may be limited by a certain amount of data (e.g., 1 / 2 MB, 1 MB, 2 MB, 5 MB, 10 MB, etc.). In other embodiments, the number of entries in block entry 430 may be a predetermined number of entries. For example, nodes in the verification network may determine that block entry 430 may include 1, 10, 150, 500, 1000 entries, etc.

[0181] Timestamp 414 may include the time when the block was created within a certain margin of error. According to some embodiments of the invention, full nodes of the verification network can check timestamp 414 against their own known times and can reject any block that appears to have an incorrect timestamp 414.

[0182] As described in this article, the temporary number 418 can be a value adjusted by the full node during the proof-of-work process. The temporary number can be input into the hash function along with the block data to determine the output hash value. A correct temporary number (also known as a golden temporary number) yields an output hash value that meets predetermined criteria, such as being less than the difficulty value.

[0183] The second block 440 may be similar to the first block 410. For example, the second block 440 may include a block header 450 and a block entry 460. The block header 450 of the second block 440 may include a previous hash 452, a timestamp 454, a Merkle root hash 456, and a temporary number 458. The block entry 460 may include image data, interaction data, smart contracts, etc., and may be similar to block entry 430.

[0184] The embodiments disclosed herein offer several advantages. For example, the embodiments eliminate the technical problem of preemptive attacks. The embodiments are less susceptible to such attacks because the threshold signature system empowers legitimate users to immediately challenge any attacker by proving ownership of the second private key. Furthermore, the server computer monitors the smart contract and notifies the user of any detected recovery attempts. This makes the system and method according to the embodiments more efficient and secure than previous cryptographic private key recovery systems.

[0185] Although the steps in the flowcharts and process flows described above are shown or described in a specific order, it should be understood that embodiments of the invention may include methods with steps in a different order. Furthermore, steps may be omitted or added, and these steps may still be within the scope of embodiments of the invention.

[0186] Any software component or function described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing techniques such as conventional or object-oriented methods. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as optical discs (CDs) or digital versatile discs (DVDs), flash memory, and the like. The computer-readable medium may be any combination of such storage or transmission means.

[0187] Such programs can also be encoded and transmitted using carrier signals adapted for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, computer-readable media according to embodiments of the invention can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable media can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0188] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the above description, but rather by reference to the pending claims and their full scope or equivalents.

[0189] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0190] As used herein, unless explicitly indicated otherwise, the terms “a,” “an,” or “the” are intended to mean “at least one.”

Claims

1. A method comprising: A key recovery message is generated by the user device, the key recovery message including a public key or its identifier associated with the account, the public key corresponding to a first private key associated with the user device; The user device provides the key recovery message to the smart contract on the blockchain; The user device receives a detected recovery message from the server computer monitoring the smart contract; as well as After the key recovery message is provided to the smart contract, the user device generates a new private key to replace the first private key.

2. The method according to claim 1, further comprising: The user device provides the security deposit along with the key recovery message to the smart contract.

3. The method of claim 1, wherein the new private key is generated by a cryptographic keying process that allows the new private key to be used with the public key.

4. The method according to claim 1, further comprising: After receiving the detected recovery message, the user device prompts the user to enter a choice for disputed recovery, cancel recovery, or accept recovery.

5. The method of claim 1, wherein the server computer determines whether to cancel key recovery.

6. The method according to claim 1, wherein the first private key is a first private key share, and the second private key is a second private key share, wherein the first private key share and the second private key share are shares of the private key corresponding to the public key.

7. The method of claim 6, wherein the new private key is a new private key share used to replace the first private key share.

8. The method of claim 1, wherein after generating the new private key, the method further comprises: The user device generates a key update message, which includes the new private key and a request to revoke the first private key; The user device generates a digital signature for the key update message using a third private key obtained before generating the key recovery message; as well as The user device provides a key update message containing the digital signature to the smart contract.

9. The method of claim 8, wherein the smart contract verifies the digital signature using a group public key, revokes the first private key, and adds the new private key.

10. The method of claim 1, wherein after generating the new private key, the method further comprises: The user device generates a key update message, which includes the new private key and a request to revoke the first private key; The user device generates a digital signature for the key update message using a third private key obtained before generating the key recovery message; as well as The user device provides a key update message containing the digital signature to the server computer.

11. The method of claim 10, wherein the server computer verifies the digital signature using a group public key and signs the key update message using the second private key.

12. The method of claim 11, wherein the server computer provides the user device with a key update message having the digital signature and further signed by the server computer using the second private key, wherein the method further comprises: The user device provides a key update message, which has the digital signature and is further signed by the server computer, to the smart contract.

13. A user equipment, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to perform a method comprising: Generate a key recovery message, the key recovery message including a public key or its identifier associated with the account, the public key corresponding to a first private key associated with the user device; Provide the key recovery message to the smart contract on the blockchain; Receive a detected recovery message from the server computer monitoring the smart contract; and After the key recovery message is provided to the smart contract, a new private key is generated to replace the first private key.

14. The user device of claim 13, wherein the smart contract maintains a group structure, the group structure indicating a list of private keys corresponding to the group verification key, wherein the server computer stores a second private key, and wherein transactions performed using the blockchain require at least the second private key to be valid.

15. The user equipment of claim 13, wherein before generating the key recovery message, the method further comprises: Obtain a third private key associated with the account, wherein the third private key is obtained from a device outside the user device and operated by the user.

16. The user device of claim 15, wherein after generating the new private key, the method further comprises: Generate a key update message, the key update message including the new private key and a request to revoke the first private key; Use the third private key to generate a digital signature for the key update message; as well as A key update message containing the digital signature is provided to the smart contract, wherein the smart contract verifies the digital signature using the group public key, revokes the first private key, and adds the new private key.

17. A method comprising: The server computer detects changes to smart contracts on the blockchain, wherein the changes are included in a key recovery message from a user device requesting the recovery of the first private key; The server computer determines whether to cancel key recovery; The server computer generates a detected recovery message based on the determination. as well as The server computer provides the detected recovery message to the user device, wherein the user device generates a new private key to replace the first private key.

18. The method of claim 17, further comprising: The server computer receives a key update message from the user device, wherein the key update message includes the new private key and a digital signature formed by the user device using a third private key; The digital signature is verified by the server computer using a group verification key; as well as The server computer signs the key update message using the second private key.

19. The method of claim 18, further comprising: The server computer provides a key update message, which is signed by both the server computer using the second private key and the user device using the third private key, to the smart contract.

20. The method of claim 18, further comprising: The server computer provides a key update message, which is signed by both the server computer using the second private key and the user device using the third private key, to the user device, wherein the user device provides the key update message to the smart contract.

Images