Emergency recovery transaction of funds from a cryptocurrency wallet

Abstract

A method is disclosed for performing an emergency recovery transaction of funds in a cryptocurrency wallet. A distributed cryptographic key is provided, the cryptographic key being shared among two or more nodes, each node holding a share of the cryptographic key, and no node holding the entire cryptographic key. The cryptographic key provides access to funds in the cryptocurrency wallet. Recovery information regarding the cryptographic key, e.g., the shares of the cryptographic key, is stored in a storage separate from the two or more nodes. In the event that the cryptographic key and / or the wallet becomes inoperable, a user retrieves the recovery information from the storage and provides at least a portion of the retrieved recovery information to an emergency recovery service. The emergency recovery service and the user cooperate to perform an emergency recovery transaction of funds from the cryptocurrency wallet to a new cryptocurrency wallet based on the recovery information.

Description

[Technical field]

[0001] The present invention relates to a method for performing emergency recovery transactions of funds in a cryptocurrency wallet. More specifically, the method of the present invention allows a user to access cryptocurrency funds in the event that the cryptocurrency wallet and / or the cryptographic keys providing access to the cryptocurrency wallet become inoperable. [Background technology]

[0002] Cryptocurrencies such as Bitcoin are typically stored in a digital "wallet" in the form of one or more digital addresses. When performing a cryptocurrency transaction, the funds are moved to a new address using blockchain technology. To perform a transaction, a user must apply a personal encryption key.

[0003] A personal encryption key may be stored on one or more devices under the direct control of the owner of the personal encryption key, such as a personal computer, tablet, mobile phone, dongle, etc. Alternatively, the personal encryption key may be managed by a trusted key management service, in which case the personal encryption key is stored on one or more servers or one or more nodes under the control of the trusted key management service. In either case, the personal encryption key may be stored entirely in a single location or in a distributed or shared form across two or more nodes.

[0004] If a cryptocurrency wallet and / or a personal cryptographic key becomes inoperable, the cryptocurrency owner will be unable to access the funds in the cryptocurrency wallet. A cryptocurrency wallet and / or a personal cryptographic key may become inoperable, for example, if the device, server, node, etc. on which the wallet and / or personal cryptographic key is stored is stolen or physically destroyed or damaged.

[0005] US Patent Application Publication No. 2019 / 0007205 discloses a system and method for persona management in an online environment. An identity proxy with a trusted party holds a portion of a consumer's private encryption key and may regenerate or recover the consumer's private encryption key if the consumer-held private encryption key is lost or corrupted. The owner of the lost wallet may obtain a share of the private key from the trusted party after their identity is verified using a new wallet. Once the new wallet is created, a key recovery engine is used to initiate private key recovery from the obtained key share. Thus, the entire key is recovered on the device held by the consumer. Summary of the Invention

[0006] It is an object of embodiments of the present invention to provide a method that allows emergency recovery of funds from a cryptocurrency wallet in a secure and reliable manner.

[0007] The present invention relates to a method for performing an emergency recovery transaction of funds from a cryptocurrency wallet, comprising: providing a distributed cryptographic key shared among two or more nodes, where each node holds a share of the cryptographic key but no node holds the entire cryptographic key, the cryptographic key providing access to the funds in the cryptocurrency wallet; storing recovery information for the encryption key in a storage separate from the two or more nodes; When the encryption key and / or the wallet becomes inoperable, a user retrieves the recovery information from the storage and provides at least a portion of the retrieved recovery information to an emergency recovery service; and said emergency recovery service and said user collaboratively executing an emergency recovery transaction of funds from said cryptocurrency wallet to a new cryptocurrency wallet based on said recovery information; Including, A method is provided.

[0008] The present invention therefore relates to a method for performing an emergency transaction of funds from a cryptocurrency wallet. In the present context, the term "cryptocurrency wallet" is taken to mean a system associated with a user and cryptocurrency funds belonging to that user, comprising one or more digital addresses and associated private keys.

[0009] In this context, the term "emergency recovery transaction" should generally be interpreted to mean a transaction that allows a user to access the funds in a cryptocurrency wallet one time, for example to move the funds to a new wallet, such as one or more new digital addresses, in the event that the wallet providing access to the cryptocurrency wallet and / or the user's private cryptographic keys become inoperable.

[0010] In the method according to the invention, a distributed cryptographic key is first provided, which provides access to funds in a cryptocurrency wallet, i.e., the cryptographic key is associated with a cryptocurrency wallet and forms the private key of a user who owns the funds in the cryptocurrency wallet. The distributed cryptographic key is shared between two or more nodes, each node holding a share of the cryptographic key, and no node holds the entire cryptographic key. Thus, access to the cryptocurrency wallet requires information or knowledge held by two or more nodes, possibly all nodes, and the funds in the cryptocurrency wallet cannot be compromised by compromising only one node.

[0011] Thus, the cryptographic keys applied in carrying out the methods of the present invention are of the type that are distributed or shared among two or more nodes, providing a higher level of security than cryptographic keys stored in a single node or device, since there is no single point of trust.

[0012] In this context, the term "node" is taken to mean a digital location with storage capabilities separate from other nodes. A node may be in the form of, for example, a server, a separate part of a server, or various devices such as a mobile phone, a personal computer, a dongle, etc., or any combination of these.

[0013] Second, the recovery information for the encryption keys is stored in a storage separate from the two or more nodes. Thus, even if one or more nodes are compromised, physically destroyed, damaged, or otherwise inoperable, the recovery information for the encryption keys remains available. Furthermore, a malicious actor who can gain access to a particular node and corrupt the shares held by that node does not have access to the corresponding recovery information, and therefore the recovery information cannot be corrupted.

[0014] The separate storage may be an offline storage or a so-called "cold storage", in which case it is not possible to access the storage via an online communication channel (such as the Internet) to access the recovery information, minimizing the risk of unauthorized access to the recovery information.

[0015] In this context, the term "recovery information" should be interpreted as meaning information that allows at least partial recovery of the cryptographic key, at least to the extent that access to the funds in the cryptocurrency wallet is possible. This is explained in more detail below. The recovery information may provide individual information about the shares held by each node. Alternatively, the recovery information may be in the form of a multi-party encrypted version of the cryptographic key, generated by the nodes cooperatively, for example by a multi-party encryption process such as Secure Multi-Party Computation (MPC).

[0016] In the event that the encryption key and / or wallet becomes inoperable, the user retrieves recovery information from the storage and provides at least a portion of the retrieved recovery information to an emergency recovery service.

[0017] In this context, the term "in-operational" should be interpreted to encompass a situation in which the funds in a cryptocurrency wallet cannot be accessed because the cryptographic key or wallet has been compromised or damaged, because one or more devices holding a share of a cryptographic key have been stolen or lost, or because one or more nodes holding a share of a cryptographic key have been physically destroyed or damaged, such as by fire or explosion.

[0018] In this context, the term "emergency recovery service" should be interpreted to mean a service provider that is able to at least partially recover representations of distributed encryption keys, such as encryption keys or shares of encryption keys, based in part on relevant recovery information provided by a user, possibly applying additional information provided by and / or in cooperation with the user.

[0019] Thus, the emergency recovery service and the user ultimately cooperate to execute an emergency recovery transaction of funds from the cryptocurrency wallet to the new cryptocurrency wallet based on the recovery information.

[0020] This ensures that funds in the cryptocurrency wallet that were previously inaccessible to the user due to an inoperable cryptographic key and / or wallet are accessible to the user again in the new cryptocurrency wallet. Furthermore, since the emergency recovery transaction is performed based on the recovery information retrieved from the storage and provided to the emergency recovery service by the user, it ensures that only users with appropriate access to the storage and thus the associated recovery information can initiate the emergency recovery transaction. This minimizes the risk of unauthorized access to the recovered funds in the cryptocurrency wallet.

[0021] The emergency recovery transaction may be performed solely by the emergency recovery service, but based on information provided by the user. This information may simply be the recovery information, but may instead include additional information, such as information verifying the identity of the user, information relating to or identifying the cryptocurrency wallet, etc. Alternatively, the emergency recovery transaction may require an interaction between the emergency recovery service and the user. For example, the user and the emergency recovery service may perform a secure multi-party computation to perform the emergency recovery transaction. As another alternative, the emergency recovery transaction may be performed by the user based on an output generated by the emergency recovery service based on the recovery information. Such an output may include, for example, a recovered version of the cryptographic key.

[0022] In any case, the emergency recovery transaction is performed in cooperation with the emergency recovery service and the user, so that neither the emergency recovery service nor the user can perform the emergency recovery transaction alone, i.e., without the participation of the other party. Thus, neither the emergency recovery service nor the user constitutes a single point of trust, which greatly improves the security and reliability of the system and method. In particular, during the emergency recovery transaction, neither the emergency recovery service nor the user knows the entire encryption key.

[0023] For example, a recovery transaction protocol applied to execute an emergency recovery transaction may include a user and an emergency recovery service jointly executing an interactive secure multi-party computation (MPC) protocol. Executing the MPC protocol may result in the following: (1) The user uses recovery information, possibly encrypted, as input to the protocol, and the emergency recovery service uses a decryption key as input to the protocol, which can be used to decrypt the recovery information in order to regenerate the encryption key. (2) In the MPC protocol, the recovery information is then decrypted using the decryption key. (3) In the MPC protocol, the emergency transaction is signed using the decrypted / regenerated cryptographic key. (4) The output of the MPC protocol is the emergent transaction, now signed with a cryptographic key.

[0024] By using secure multi-party computation to decrypt the encrypted recovery information, obtain the encryption key, and sign the emergency transaction with that encryption key, neither the user nor the emergency recovery service knows the decrypted encryption key at any point in time, eliminating a single point of trust. For example, corruption of either the user or the emergency recovery service during the recovery operation is not enough to control the destination of the emergency transaction and steal the funds. As long as at least one of the two parties is honest, secure multi-party computation ensures that the emergency transaction correctly transfers the funds to the new destination wallet.

[0025] The step of executing the emergency recovery transaction in cooperation with the emergency recovery service and the user may include the following steps: generating, by the emergency recovery service, a one-time cryptographic transaction key based on the received recovery information; and The emergency recovery service executes an emergency recovery transaction of the funds from the cryptocurrency wallet to the new cryptocurrency wallet using the one-time cryptographic transaction key.

[0026] According to this embodiment, the emergency recovery service applies the recovery information received via the user to generate a one-time cryptographic transaction key that can be used to access the contents of the cryptocurrency wallet, at least to the extent that an emergency transaction can be performed to a new cryptocurrency wallet. After the emergency transaction is performed, the one-time cryptographic transaction key can no longer be used, including to access the new cryptocurrency wallet and thereby access the wallet funds. Thus, if the one-time cryptographic transaction key is compromised after the emergency transaction, it does not pose a problem.

[0027] The one-time cryptographic transaction key may be, for example, a recovered version of a cryptographic key. In this case, once the funds are transferred to a new cryptocurrency wallet, a new distributed cryptographic key needs to be generated. Note that moving funds to a new cryptocurrency wallet usually requires generating a new key pair (public and private key), and the new public key is linked to the address of the new wallet.

[0028] Alternatively, the emergency recovery service may generate information based on the recovery information that allows the user to recover the encryption key or the one-time encryption transaction key. In this case, the user may subsequently perform the emergency transaction based on the information provided by the emergency recovery service. According to this embodiment, the emergency recovery service does not own the encryption key.

[0029] As another alternative, the emergency recovery service and the user may cooperate in performing the emergency recovery transaction, such as by using secure multi-party computation (MPC), in which case neither the emergency recovery service nor the user can perform the emergency transaction alone, and furthermore, neither the emergency recovery service nor the user owns the cryptographic keys.

[0030] The recovery information may be in the form of a pre-signature generated by the node based on a share of a cryptographic key held by the node. According to this embodiment, the node generates pre-signatures using its share of the cryptographic key, and these pre-signatures are exported and stored in a separate storage. If an emergency transaction is required, a signature is generated based on the pre-signature, and this signature is applied to execute the emergency transaction. The calculations performed in computing the digital signature are often split into two steps, where data generated in the first step is required in the last step, which generates the final digital signature. In this context, the term "pre-signature" should be interpreted to mean the data generated in the first step.

[0031] For example, the cryptographic key x is the private signing key of the ECDSA digital signature scheme, and the pre-signature is the value of a random nonce k (gk,k,x k -1 ). Possession of such a pre-signature reduces the amount of computation required to generate the final signature. For example, a node may generate a secret share of the pre-signature using secure multi-party computation based on the secret sharing of x, and the recovery information may consist of an encrypted share of the pre-signature.

[0032] Providing at least a portion of the recovery information obtained by the user to the emergency recovery service may include verifying the identity of the user to the emergency recovery service.

[0033] According to this embodiment, the emergency recovery service will only participate in the emergency recovery transaction if it can verify that the user who provided the obtained recovery information to the emergency recovery service is in fact the legitimate owner of the recovery information and thus the cryptographic key, thereby reducing the risk that a malicious party who gains access to the recovery information will also gain access to funds in the cryptocurrency wallet.

[0034] The recovery information may include information regarding the user's unique identity, and verifying the user's identity for the emergency recovery service may include the user verifying possession of the unique identity.

[0035] According to this embodiment, when generating the recovery information, information about the unique identity of the user is added to or integrated into the recovery information, so that the emergency recovery service can easily verify whether the unique identity presented by the user providing the recovery information matches the unique identity that forms part of the recovery information.

[0036] The unique identity may be cryptographically linked to the recovery information. According to this embodiment, the unique identity, for example in the form of a user identity string (UID), forms an integral part of the recovery information.

[0037] For example, the recovery information may include a zero-knowledge proof that includes the user's unique identity. The zero-knowledge proof may be made non-interactive, for example, using the Fiat-Shamir Transform, and the user's unique identity, UID, may be included in the challenge that is hashed. According to this embodiment, the emergency recovery service may be able to verify that the user's identity is the same as the identity used when the node generated the zero-knowledge proof. This ensures that emergency transactions are only performed based on recovery data belonging to the user.

[0038] Alternatively, the user's identity may be linked to the recovery information using a digital signature. For example, nodes may perform a multi-party process to agree on an entity s. If there are three nodes, s may be defined as follows:

[0039]

number

[0040] Here, c1, c2, and c3 are the recovery information generated by the three nodes, UID is the unique identity of the user, and || is the concatenation of strings. Then, the nodes use a threshold signature scheme to sign σ = sign with a shared cryptographic signing key (sk). sk The node generates (s) where s and σ are then provided to the user and / or the emergency recovery service. The emergency recovery service can then, given the public verification key vk of the threshold signature scheme, verify that the signature σ is valid and that the user's identity matches the value UID contained in s. This allows it to prove to the emergency recovery service that the recovery data was generated by a node holding the private key sk and that the recovery information belongs to the user.

[0041] The method may further include the steps of: two or more nodes providing each other encrypted versions of their respective shares of an encryption key; and Two or more nodes verifying the encrypted shares of the encryption key. Storing recovery information regarding the encryption key in the storage may include, if the zero-knowledge proof is valid, each of the nodes providing an encrypted version of their respective share of the encryption key to the storage.

[0042] According to this embodiment, the nodes perform a multi-party verification process to verify the encrypted version of each share of the encryption key, for example by zero-knowledge proofs, so that no node has knowledge or ownership of the shares held by other nodes, but users can guarantee that the encrypted shares of the encryption key are correct and uncorrupted before they are provided to storage as recovery information.

[0043] An example of this embodiment is as follows: Assume that each node holds a public encryption key ek, and that the emergency recovery service holds a corresponding private decryption key dk of a public key cryptosystem. Assume also that the encryption key is a private ECDSA or EdDSA signing key. Each node encrypts its share xi of the encryption key x with ek, and expresses the encrypted key share as a cryptographic Feldman commitment to the share g. xi The node sends the cryptography and commitments to all other nodes along with a non-interactive zero-knowledge proof that the commitments are commitments to the same encrypted value. When the node receives the commitments and cryptography from another node, it verifies the zero-knowledge proof. Once the node has received the encrypted values ​​and commitments from all other nodes and determined that they are all valid, it sends all encrypted values ​​and commitments to the user, including its own cryptography and commitments. The user then verifies all received cryptography and commitments by comparing each commitment and cryptography received from the node with the corresponding commitments and cryptography received from other nodes. Finally, the user converts the commitments into a cryptographic key commitment, Y=g x1 ·g x2…g xn where n is the number of nodes. The user then verifies that Y is indeed the correct public key corresponding to the private encryption key x.

[0044] The advantage of this embodiment is that all zero-knowledge proofs are generated and verified by the node (i.e., before any encrypted shares are sent from the node). Users can verify the recovery information by simply comparing values ​​and multiplying the Feldman commitment, which is an ordinary point on the ECDSA or EdDSA elliptic curve.

[0045] Alternatively, the method may further include two or more nodes creating an encrypted version of the encryption key based on their shares of the encryption key and using a multi-party encryption process, and storing recovery information related to the encryption key in the storage may include storing the encrypted version of the encryption key in the storage.

[0046] According to this embodiment, the stored recovery information is an encrypted version of the entire encryption key, rather than information relating to individual key shares. The encrypted version of the encryption key is created by a multi-party encryption process, such as Secure Multi-Party Computation (MPC), performed by the nodes.

[0047] The cryptographic key may, for example, be encrypted by another public key cryptographic key available to the node. A corresponding decryption key is available to the emergency recovery service so that if the cryptographic key and / or wallet become inoperable and an emergency recovery transaction of funds from the cryptocurrency wallet is required, the emergency recovery service can decrypt the encrypted version of the cryptographic key. This may expose the cryptographic key to the emergency recovery service; however, this may be considered acceptable since the transaction is an emergency transaction and a new cryptographic key can be generated for a new cryptocurrency wallet.

[0048] The encrypted version of the encryption key may include a zero-knowledge proof, and storing recovery information for the encryption key in storage may include verifying the zero-knowledge proof prior to storing the encrypted version of the encryption key.

[0049] According to this embodiment, it is guaranteed that the encrypted version of the encryption key and the recovery information stored thereby are accurate and uncorrupted before being stored, which ensures that if an emergency transaction is required, it can actually be performed based on the stored recovery information. Since the verification is performed by zero-knowledge proofs, any information about the encryption key or individual shares of the encryption key is prevented from being leaked.

[0050] For example, if the encrypted version of the encryption key was generated incorrectly, e.g., if there was malicious activity in generating the encrypted version, then the owner of the lost wallet may not be able to recover the original encryption key (e.g., because some or all of the encrypted portion was corrupted prior to encryption). In contrast, some embodiments of the present invention ensure that the wallet user (or anyone else) can always verify that the encrypted version of the encryption key is correct, and therefore can recover the encryption key at a later time. Thus, the use of cryptographic zero-knowledge techniques ensures that this verification can be performed by anyone, even parties who cannot decrypt the encrypted portion.

[0051] The method may further include providing a master chain code and storing the master chain code in two or more nodes. Storing recovery information for the cryptographic key in storage may include storing an encrypted version of the master chain code as part of the recovery information.

[0052] In some cryptocurrency standards, such as BIP-32, a cryptographic master key and a master chaincode are derived from a master seed, and the cryptographic master key and the master chaincode may be used in combination to derive subsequent cryptographic keys used in cryptocurrency transactions. In this case, it may be important to store recovery information related to the cryptographic master key and the master chaincode, which can be used to recover the information needed to generate cryptographic transaction keys and perform emergency transactions of funds in the cryptocurrency wallet.

[0053] Each node may hold the entire master chaincode, or alternatively, the master chaincode may be distributed among the nodes, with secrets shared among the nodes in a manner similar to distributed encryption keys.

[0054] As described above, the distributed encryption keys and the master chaincode may be derived from a common master seed. Storing the recovery information may include storing an encrypted version of the common master seed. According to this embodiment, the master encryption key and the master chaincode may be derived from the recovery information.

[0055] The method may further include a step of the user verifying the obtained recovery information by verifying the correspondence between the cryptographic key and the master chaincode.

[0056] According to this embodiment, the user verifies that the recovery information retrieved from the storage is indeed accurate and uncorrupted before it is provided to the emergency recovery service. This verification can be performed, for example, by zero-knowledge proofs.

[0057] For example, if the recovery information includes information about a cryptographic key and a master chaincode, a zero-knowledge proof can verify that a key derivation using the cryptographic key and the master chaincode corresponds to two public keys provided by the user. Alternatively, or in addition, a zero-knowledge proof can verify that applying the correct key derivation to a common master seed produces cryptographic keys that correspond to the public keys provided by the user. [Brief description of the drawings]

[0058] The invention will now be explained in more detail with reference to the accompanying drawings, in which:

[0059] [Figure 1] FIG. 1 illustrates a method according to an embodiment of the invention. [Diagram 2] FIG. 2 is a block diagram illustrating a system for storing recovery information as part of performing a method according to an embodiment of the present invention. [Diagram 3] FIG. 3 is a block diagram illustrating a system for performing emergency recovery transactions based on recovery information as part of performing a method according to an embodiment of the present invention. [Figure 4] FIG. 4 illustrates storing recovery information as part of performing a method according to an embodiment of the invention. [Diagram 5] FIG. 5 illustrates an emergency recovery transaction according to a method according to an embodiment of the present invention. [Figure 6] FIG. 6 illustrates storing recovery information as part of performing a method according to an alternative embodiment of the present invention. [Figure 7] FIG. 7 illustrates an emergency recovery transaction according to a method according to an alternative embodiment of the present invention. [Figure 8] FIG. 8 illustrates recovery data generation using secure multi-party computation (MPC) according to an embodiment of the invention.

[0060] Detailed Description of the Drawings Figure 1 illustrates a method according to one embodiment of the present invention. A distributed cryptographic key that provides access to funds in a cryptocurrency wallet is shared among multiple nodes 1. Thus, each of the nodes 1 holds a share of the cryptographic key, but no node 1 owns or has knowledge of the entire cryptographic key. It is noted that although two nodes 1 are shown in Figure 1, it is within the scope of the present invention to apply more than two nodes 1.

[0061] User agent 2 requests recovery information D regarding the shares of the cryptographic key from node 1, and node 1 applies protocol 3 to provide the requested recovery information D to user agent 2. The protocol may be iterative and may require multiple communications between node 1 and user agent 2. The recovery information D may be in the form of information about each share held by node 1, or it may be in the form of an encrypted version of a multi-party generated secret or distributed cryptographic key.

[0062] The user agent 2 ensures that the recovery information D is stored in a storage 4 separate from the node 1. The storage 4 can for example be a cold storage, i.e. a storage that is not accessible via a communication network such as the Internet. In this case, the user agent 2 can physically bring to the storage 4 an offline storage medium, such as a USB stick, containing the recovery information.

[0063] In the event that the cryptographic key and / or wallet become inoperable, the user agent 2 initiates an emergency recovery procedure, which includes retrieving recovery information D from the storage 4 and applying the recovery transaction protocol 5. This includes providing a version D' of the recovery information to the transaction protocol 5. The version D' of the recovery information provided to the transaction protocol 5 may simply be the recovery information D stored in the storage 4 (i.e., D=D'). Alternatively, it could be a modified version of the stored recovery information D, e.g. an encrypted version, a version including additional information provided by the user agent 2, or only a portion of the recovery information D.

[0064] The emergency recovery procedure involves providing the recovery information D' to an emergency recovery service 6. The user agent 2 and the emergency recovery service 6 then cooperate by performing an emergency transaction of funds from the cryptocurrency wallet to a new cryptocurrency wallet 7 via a recovery transaction protocol 5 and posting the transaction to the blockchain network 8.

[0065] The emergency transaction may be performed in several ways. For example, the emergency recovery service 6 or user agent 2 may receive a signed recovery transaction as an output of the recovery transaction protocol 5, after which the emergency recovery service 6 or user agent 2 posts the signed recovery transaction to the blockchain network 8. This posting may occur by the emergency recovery service 6 or user agent 2 running a blockchain node themselves, or via a third party to which the transaction is distributed. Alternatively, the recovery transaction protocol 5 may result in the user agent 2 and the emergency recovery service 6, respectively, possessing only an encrypted or secret-shared version of the recovered transaction, and a more advanced protocol may be required to post the transaction to the blockchain network 8.

[0066] The new cryptocurrency wallet 7 may be a standard cryptocurrency wallet or a threshold wallet that includes multiple wallet nodes.

[0067] The emergency recovery procedure may involve recovering the original encryption key, i.e. the encryption key that was distributed among the nodes 1. In this case, the user agent 2 and / or the emergency recovery service 6 may temporarily learn or gain knowledge of the original encryption key as part of the recovery transaction protocol 5, such that a new encryption key is required to access the new cryptocurrency wallet 7. Alternatively, the recovery transaction protocol 5 may ensure that the original encryption key is not exposed in plaintext, but only in encrypted or secret sharing form.

[0068] According to the embodiment shown in FIG. 1, the new cryptocurrency wallet obtains a new cryptographic key x' as a result of the recovery transaction protocol. Key x' may be generated by the user or by the emergency recovery service and sent to the new cryptocurrency wallet. Alternatively, x' may be generated by the new cryptocurrency wallet and only the corresponding public key Y is published to the user and / or emergency recovery service. Alternatively, x' may be generated using a multi-party process between the user, the emergency recovery service, and / or the new cryptocurrency wallet. In either case, the emergency recovery results in a new cryptographic key x' being stored by the new cryptocurrency wallet.

[0069] The generation of the recovery information D and the emergency recovery procedure may be separated in time, i.e. the emergency recovery procedure may be performed long after the recovery information D is generated and stored in storage 4. Furthermore, the user agent 2 that receives the recovery information D from node 1 and stores it in storage 4 does not need to be the same user agent 2 that retrieves the recovery information D from storage 4 and initiates the emergency recovery procedure. For example, the two processes may be performed from two different devices.

[0070] Figure 2 is a block diagram illustrating a system 9 that may be used to perform parts of a method according to an embodiment of the present invention. More specifically, the system 9 illustrated in Figure 2 may be used to generate and store recovery information regarding shares of a distributed encryption key.

[0071] The system 9 includes a cryptocurrency wallet 10. A distributed cryptographic key x is stored in the wallet 10. The i-th node 1 receives a share x of cryptographic key x. i 2 shows three nodes 1. However, it should be noted that the case where the system 9 includes two nodes 1 or four or more nodes 1 is also within the scope of protection of the present invention.

[0072] User agent 2 receives share x of encryption key x from node 1. i and stores the recovery information D in a storage 4 separate from the node 1. This may be done, for example, in the manner described above with reference to FIG.

[0073] Figure 3 is a block diagram illustrating a system 11 that may be used to perform parts of a method according to an embodiment of the present invention. More specifically, the system 11 of Figure 3 may be used to perform emergency recovery transactions of funds in a cryptocurrency wallet.

[0074] The user agent 2 retrieves recovery information D from storage 4, where it has been previously stored, such as by the method described above with reference to Figures 1 and 2. The user agent 2 provides a version D' of the retrieved recovery information to the emergency recovery service 6. As described above with reference to Figure 1, the version D' of the recovery information provided to the emergency recovery service 6 may be identical to the recovery information D stored in storage 4 and subsequently retrieved by the user agent 2, or it may be a modified version.

[0075] The user agent 2 and the emergency recovery service 6 cooperate to execute an emergency recovery transaction, which results in the funds in the cryptocurrency wallet being transferred to a new cryptocurrency wallet 7, by posting the transaction to a blockchain network 8. This may be performed, for example, in the manner described above with reference to FIG. 1.

[0076] Figure 4 illustrates storing recovery information as part of performing a method according to an embodiment of the present invention. More specifically, Figure 4 illustrates interactions between one node 1 and a user agent 2 to generate and store in storage 4 recovery information for a share of an encryption key held by node 1, although it should be understood that user agent 2 interacts in a similar manner with other nodes 1 holding other shares of the encryption key.

[0077] In the embodiment shown in Figure 4, it is assumed that node 1 possesses additive secret sharing of a cryptographic key x, for example in the form of a secret Elliptic Curve Digital Signal Algorithm (ECDSA) signing key. Each node 1 and user agent 2 further possesses a corresponding public verification key Y=g x Furthermore, it is assumed that the user who owns the cryptocurrency wallet funds and cryptographic key x has a user identity UID.

[0078] Furthermore, it is assumed that all parties involved agree on all public parameters, including the parameters of the threshold wallet, in particular the number of nodes 1, the public parameters of the ECDSA scheme including the elliptic curve group and generator description g, the public key Y, etc., as well as the public parameters a of the applied public key encryption scheme including the encryption key ek, and the parameters b of the applied zero-knowledge scheme.

[0079] To ensure that user agent 2 has the correct public parameters, each node 1 may send these parameters to user agent 2 and have user agent 2 abort if it finds that not all of the nodes 1 agree on the parameters. This ensures that user agent 2 has the correct parameters unless all nodes 1 are corrupted. Alternatively or in addition, user agent 2 may obtain the parameters from an external trusted source, such as a blockchain.

[0080] In the embodiment shown in Figure 4, the user agent 2 sends a recovery information request to each node 1. As mentioned before, only one node 1, namely node N1, is shown in Figure 4. The recovery information request includes the user's identity UID.

[0081] In response to the recovery information request, a node with index i and a secret share x i Each node 1 that has a UID calculates MSG=UID||Y, where || means string concatenation. Then, node 1 calculates (Y i ,C i ,ZK i )=EncryptWithProof(x i , ek, MSG), where EncryptWithProof takes as input x i , ek, and MSG, and executes the following procedure: where Enc is a standard public key encryption scheme such as RSA-OAEP. 1. f(0)=x i Generate a random polynomial f of degree a such that 2. For j∈{1,2,…,b}, v j = f(j). 3.e j =Enc k (v j ,r j ) where r j is the randomness used in the encryption. 4. For j∈{1,2,…,a}, commitment y j =g vj Calculate. 5. g xi , e1, …, e b , y1, …, y a ,Hash MSG into a subset F ⊂ {1, 2, …, b} of size a. 6. Y i =g xi , C i =(e1,e2,…,e b ), and ZK i ={(j,v j,r j ):j∈F;y1,…,y a} is output.

[0082] Each node 1 stores the recovery information D i =(Y i ,C i ,ZK i ) to user agent 2. User agent 2 then returns MSG=UID||Y and V for each node 1 to verify the validity of the received recovery information. i =IsProofValid(D i ,ek,MSG) is calculated. i If is false, user agent 2 aborts. i D i It is computed using the algorithm IsProofValid, which takes MSG,ek as input and true / false as output. This algorithm is i The ZK proof contained in i And, D i The value Y contained in i If the public key ek and the value MSG are valid, it returns "true"; otherwise, it returns "false" and performs the following procedure. 1. e1, …, e b , y1, …, y a D i and Z.K. i Let Y, e1, …, e be the encryption and commitments contained in b , y1, …, y a , and hash MSG to a subset F ⊂ {1, 2, …, b} of size a. 2. Use exponential interpolation to find all b commitments y1, …, y b This is calculated by dividing a+1 commitments Y i =g xi =g f(0) and y i =g f(i) This is possible because (1≦i≦a). 3. For all j ∈ F, ZK does not have a value (j, , ), and for all j ∈ F, ZK does have a value (j, vj ,r j ), and e j =E ek (v j , r j ) and y j =g vj If so, return true; otherwise, return false.

[0083] User agent 2 receives messages D1, D2, …, D from all nodes 1 greater than or equal to 2. n Upon receiving this, User Agent 2 performs the following operation: Y = RecombineInExp(Y1, Y2, …, Y n ), where RecombineInExp is g x1 , g x2 , …, g xn With input Y=g x This is an algorithm that has as output , and uses the homomorphic properties of the exponent to recombine the secret shares of the exponent. The algorithm performs the following steps: 1. In the case of Shamir sharing, each share is multiplied by the public Lagrangian coefficients to convert it to an additive variance. 2. Y=Y1Y2…Y n =g x1 g x2 …g xn =g x1+x2+…+xn Calculate and output.

[0084] Finally, unless the process is aborted, user agent 2 will send recovery information D=(D1,D2,…,D n ) is stored in storage 4.

[0085] Figure 5 illustrates an emergency recovery transaction according to a method according to one embodiment of the present invention. More specifically, Figure 5 illustrates the interaction between a user agent 2 and an emergency recovery service 6 to perform an emergency transaction of funds from a cryptocurrency wallet to a new cryptocurrency wallet 7 in the event that the cryptocurrency wallet and / or corresponding cryptographic key becomes inoperable.

[0086] In the embodiment shown in Fig. 5, the assumptions explained above with reference to Fig. 4 also apply. It is further assumed that the emergency recovery service 6 holds a private decryption key dk of the applied public key cryptography scheme and that the user agent 2 holds a corresponding encryption key ek. It is further assumed that the emergency recovery service 6 is able to verify the user's identity UID via an external authentication mechanism. This may involve, for example, using an external identity provider, or the user may be able to physically contact the emergency recovery service 6 and present a suitable ID, such as a passport. It is further assumed that the emergency recovery service 6 stores the decryption key dk in a Hardware Security Module (HSM) 12, which supports only standard cryptography, such as RSA-OAEP.

[0087] In the embodiment shown in Figure 5, the user agent 2 retrieves the recovery information D for the encryption key x from the storage 4 where the recovery information D was previously stored, for example in the manner described above with reference to Figure 4. The user agent 2 then authenticates with the emergency recovery service 6 using the user's identity UID and via an external mechanism, so that the emergency recovery service 6 can verify that the user agent 2 has the correct UID. The user agent 2 then uses the authenticated channel to exchange the recovery information D and Y=g x to provide emergency recovery services6.

[0088] The emergency recovery service 6 is responsible for recovering individual messages D of the recovery information D. i For each, MSG=UID||Y and V i =IsProofValid(D i , ek, MSG) and V i = False then abort. The algorithm IsProofValid was described above with reference to FIG.

[0089] All D's i Upon receiving the data, the emergency recovery service 6 calculates x=Recover(Y,D,dk), where Recover is Y, D=(D1,D2,…,D n), and dk as input, and a cryptographic secret x as output. The algorithm performs the following steps: 1.Each D i About For aj=1…b, where TIFF2025502962000003.tif6150, iv j =Dec dk (D i .C[j]), where C[j] is D i is the jth C value of ii. Now that we have a+1 v values, we use Lagrange interpolation to find x i '=f(0) can be obtained. iii.D i .Y=g x’ If so, proceed to step b. bx i ' is found, D i .Y=g xi’ If so, then x i =x', otherwise abort. 2. x=x1+x2+…+x n Calculate Y=g x If so, print x; otherwise, abort.

[0090] Note that while the recovery algorithm is running, dk remains within the HSM 12 and is only used to compute some standard RSA-OAEP decryptions.

[0091] The new cryptocurrency wallet 7 then generates a new key pair (x',Y'=g x’ ) The new public key Y′ is provided to the emergency recovery service 6, for example, via an authenticated channel.

[0092] The Emergency Recovery Service 6 computes a signed blockchain transaction T based on the original private key x and the new public key Y', and using standard algorithms. Blockchain transaction T moves all funds from the original cryptocurrency wallet to the new cryptocurrency wallet 7, i.e. from the address defined in x to the address defined in Y'. Blockchain transaction T is posted to the blockchain 8.

[0093] The emergency recovery service 6 waits until T is successfully confirmed on the blockchain 8, and then returns the new public key Y' to the user agent 2. The user agent 2 acknowledges receipt of the new public key Y', after which the emergency recovery service 6 erases the private key x.

[0094] The embodiment shown in Figures 4 and 5 has the following advantages:

[0095] Other than the initial setup of the system where ek and dk are distributed, the Emergency Recovery Service 6 does not participate in the process before recovery is necessary.

[0096] The emergency recovery service 6 only needs to apply standard public key decryption operations such as RSA-OAEP. This is an advantage because in many cases the emergency recovery service 6 will store dk in a service or hardware security module (HSM) 12 that only offers standard operations.

[0097] Assuming that user agent 2 has the correct Y and ek, it can use zero-knowledge proofs to verify that the recovery information is correct when it receives it from node 1. In particular, if user agent 2 has the correct version of the public key Y=g x and the encryption key ek, user agent 2 can verify that the recovery information it received contains the correct encryption of the value ek that can actually be used to recover funds from the cryptocurrency wallet.

[0098] If user agent 2 has the correct y and ek, it can verify the recovery data non-interactively, i.e. without any assistance from node 1, and it can do this as frequently as needed, for example once a month, to check if the recovery information stored in storage 4 is valid.

[0099] If y and ek are correct, their validity can be verified by user agent 2 even if all nodes 1 are corrupted. This is stronger than the threshold guarantees that typically assume that at least one of nodes 1 is honest.

[0100] The user does not need to keep the recovery information D secret. Even if a malicious party steals the recovery information D, the malicious party cannot misuse the recovery information D, since only the emergency recovery service 6 possesses the decryption key dk and the malicious party cannot authenticate as the user to the emergency recovery service 6 using the same UID as the user. Non-secret data is often easier to handle and its availability in terms of backups, replication, etc. is easier to ensure.

[0101] Zero-knowledge proofs are non-interactive, so each node 1 only needs to send one message to the user agent 2, and the nodes 1 do not need to communicate with each other any further.

[0102] Figure 6 illustrates storing recovery information as part of performing a method according to an alternative embodiment of the present invention. The method illustrated in Figure 6 is very similar to the method illustrated in Figure 4 and will not be described in detail here.

[0103] However, in the embodiment of Figure 6, the recovery information is generated by secure multi-party computation between the wallet node 1 and the user agent 2. This is done as follows.

[0104] Initially, node 1 possesses a secret share [x] of the encryption key. Then, node 1 generates a random secret share [r] using secure multiparty computation, and calculates and publishes [m]=[x]-[r], so that each node 1 receives m without revealing x or r to any particular node 1. Then, node 1 generates recovery information as in Figure 4, except that it uses a share of r instead of a share of x as input. Each node i also sends m to user agent 2, who verifies each zero-knowledge proof it receives as in Figure 4. Then, upon receiving all messages Di, user agent 2 checks that it has received the same m from all nodes 1, and calculates R using "intra-exponential" recombination, yielding Y=R·g m These steps prove to the user agent 2 that the combined recovery information D contains the value m and the encryption of a share of the value r under the key ek such that the encryption key x is equal to m+r. Finally, the user agent 1 stores D in the user storage 4.

[0105] Figure 7 illustrates an emergency recovery transaction according to a method according to an alternative embodiment of the present invention. The method illustrated in Figure 7 is very similar to the method illustrated in Figure 5 and will not be described in detail here.

[0106] However, in the embodiment shown in FIG. 7, the emergency transaction is carried out by secure multi-party computation between the user agent 2 and the emergency recovery service 6 .

[0107] In Fig. 7, we assume that the recovery data D is generated according to the method described in Fig. 6. If an emergency transaction is required, user agent 2 does not provide m to emergency recovery service 6. Thus, user agent 2 holds m and emergency recovery service 6 holds r, which is the additive variance of x, i.e., x=m+r. Furthermore, given Y, user agent 2 and emergency recovery service 6 can each compute a commitment to the other's share (e.g., Feldman commitment). More specifically, user agent 2 can provide R=R1·R2…Rn =g r1+r2+…+rn =g r Calculate the emergency recovery service 6 as M=Y / R=g x / g r =g x-r =g m can be calculated.

[0108] Such shares with commitments to the shares of others are suitable as input to Secure Multi-Party Computation 13. The Multi-Party Computation 13 can, for example, compute a new ECDSA key pair (x', Y') and transfer the new private key x' to the new cryptocurrency wallet 7, for example by wrapping it with the public key pk-rec obtained from the new cryptocurrency wallet 7.

[0109] Furthermore, the user agent 2 and the emergency recovery service 6 can now perform multi-party computation to sign a transaction T that recovers funds from the cryptocurrency wallet. Computing T using multi-party computation 13 allows both the user agent 2 and the emergency recovery service 6 to verify that the amount in T is correct, that the destination address is correct, etc.

[0110] User agent 2 receives the new public key Y', and emergency recovery service 6 receives F and T, where F is the new private key x' wrapped with public key pk-rec, and T is the transaction. The emergency recovery service 6 provides F to the new cryptocurrency wallet 7, which decrypts the new private key x' using dk-new. The emergency recovery service 6 posts transaction T to the blockchain 8, thereby moving the funds to the new cryptocurrency wallet 7.

[0111] By applying multi-party computation 13 in the emergency recovery process, it is guaranteed that neither the user agent 2 nor the emergency recovery service 6 learns x or x' during recovery, and as long as at least one of the user agent 2 and the emergency recovery service 6 is honest, multi-party computation ensures that the signed transaction T contains the correct amount and destination address.

[0112] Figure 8 illustrates recovery data generation using secure multi-party computation (MPC) between nodes 1 of a cryptocurrency wallet according to an embodiment of the present invention. Three nodes 1 are shown in Figure 8. However, it should be noted that two nodes 1 or four or more nodes 1 are applicable.

[0113] Node 1 performs secure multiparty computation. As input, each node receives a share x of cryptographic key x. i , the public encryption key ek of an emergency recovery service (not shown), and the public signing key Y. The output of the computation is a cipher C = Encek(x) and a non-interactive zero-knowledge proof ZK that proves that C and Y are consistent, i.e., C is a correct encryption of x using ek, and Y = g x Prove that. Secure multiparty computation may involve multiple communications between nodes 1.

[0114] One of the nodes 1 provides (C, ZK) to the user agent 2, which verifies the proof. Finally, the user agent 2 stores the recovery information in the form of C and ZK in the storage 4.

[0115] Then, if an emergency transaction is needed, it can be done in the following way: User Agent 2 retrieves D=(C,ZK) from Storage 4 and provides D to the Emergency Recovery Service. The Emergency Recovery Service decrypts C using dk to obtain x, computes (x',Y') and a transaction T that moves funds from x to Y', posts T to the blockchain, imports x' into a new cryptocurrency wallet, and finally deletes x.

[0116] One advantage of the embodiment shown in Figure 8 is that the user agent 2 only needs to receive data (C and ZK) from a single node 1 and does not need to transmit this data over a secure channel. Another advantage is that the recovery information consists of only a single encryption of the value x, rather than an encryption of each share of x.

Claims

1. 1. A method for executing an emergency recovery transaction of funds from a cryptocurrency wallet, comprising: providing a distributed cryptographic key shared among two or more nodes, where each node holds a share of the cryptographic key but no node holds the entire cryptographic key, the cryptographic key providing access to the funds in the cryptocurrency wallet; storing recovery information for the encryption key in a storage separate from the two or more nodes; When the encryption key and / or the wallet becomes inoperable, a user retrieves the recovery information from the storage and provides at least a portion of the retrieved recovery information to an emergency recovery service; and said emergency recovery service and said user cooperatively execute an emergency recovery transaction of funds from said cryptocurrency wallet to a new cryptocurrency wallet based on said recovery information; Including, method.

2. The step of the emergency recovery service and the user cooperatively executing an emergency recovery transaction includes: generating a one-time cryptographic transaction key based on the received recovery information by the emergency recovery service; and the emergency recovery service executing an emergency recovery transaction of funds from the cryptocurrency wallet to a new cryptocurrency wallet using the one-time cryptocurrency transaction key; Including, 2. The method of claim 1.

3. the recovery information is in the form of a pre-signature generated by the node based on a share of the cryptographic key held by the node; The method of claim 1 or 2.

4. providing at least a portion of the recovery information obtained by the user to the emergency recovery service includes verifying the identity of the user to the emergency recovery service; 13. A method according to any of the preceding claims.

5. the recovery information includes information regarding the unique identity of the user; and verifying the identity of the user for the emergency recovery service includes verifying possession of the unique identity by the user. The method of claim 4.

6. the unique identity is cryptographically linked to the recovery information; The method of claim 5.

7. the recovery information includes a zero-knowledge proof containing the unique identity of the user; The method of claim 6.

8. the user's identity is linked to the recovery information using a digital signature; The method of claim 6.

9. the two or more nodes providing each other encrypted versions of their respective shares of the encryption key; said two or more nodes verifying the encrypted shares of said encryption key; Further comprising: storing recovery information for the encryption key in the storage includes each of the nodes providing to the storage the encrypted version of a respective share of the encryption key if the zero-knowledge proof is valid.

13. A method according to any of the preceding claims.

10. the two or more nodes generating an encrypted version of the encryption key based on the shares of the encryption key and using a multi-party encryption process; storing recovery information for the encryption key in the storage includes storing the encrypted version of the encryption key in the storage. The method of any one of claims 1 to 8.

11. the encrypted version of the encryption key includes a zero-knowledge proof; storing recovery information for the encryption key in the storage includes verifying the zero-knowledge proof before storing the encrypted version of the encryption key. The method of claim 10.

12. providing a master chaincode and storing the master chaincode in the two or more nodes; storing recovery information for the encryption key in the storage includes storing an encrypted version of the master chaincode as part of the recovery information.

13. A method according to any of the preceding claims.

13. the distributed cryptographic keys and the master chain code are derived from a common master seed; storing the recovery information includes storing an encrypted version of the common master seed.

13. The method of claim 12.

14. and the user verifying the obtained recovery information by verifying the correspondence between the encryption key and the master chaincode.

14. The method of claim 12 or 13.

Images