Secret key back-up and recovery using multiple concurrent encryption techniques

Abstract

A device, system, and method for back-up and recovery of a private cryptocurrency key at a remote crypto vault. Once-encrypting an unencrypted private cryptocurrency key, at a client, with a non-homomorphic encryption key, transmitting the once-encrypted cryptocurrency key to the remote crypto vault to be double-encrypted with a homomorphic encryption key to generate a backup of the private cryptocurrency key stored at the remote crypto vault. Retrieving from n distinct remote crypto vault devices, n respective homomorphic private key shares sk 1 ,...,sk n , to generate n respective partial homomorphic decryptions p 1 ,...,p n of the double-encrypted backup of the private cryptocurrency key. Combining, at the remote crypto vault, up to n partial homomorphic decryptions p 1 ,...,p n to generate a full homomorphic decryption of the double-encrypted key to restore the once-encrypted key, transmitting the once-encrypted key to the client, which decrypts it to recover the unencrypted private cryptocurrency key.

Description

Secret Key Back-up and Recovery Using Multiple Concurrent Encryption TechniquesCross Reference to Related Application

[0001] This application claims priority to and the benefit of U.S. Provisional Application No. 63 / 518,761, filed on August 10, 2023, the entirety of which is incorporated herein by reference.Field of the Invention

[0002] Embodiments of the invention provide a device, system and method for secure transmission, storage and retrieval of particular sensitive information. In particular, embodiments of the invention provide private keys and other information for cryptocurrency wallets. This capability may be referred to as 'key back-up and recovery' (KBR). This provides a user the ability to securely store their private cryptocurrency keys in a cloud-based infrastructure, for example, utilizing encryption technologies (such as, Advanced Encryption Standard (AES)), along with lattice-based threshold fully homomorphic encryption (FHE).Background of the Invention

[0003] A private key may be a secret code that allows a user to access and control their cryptocurrency. It is usually generated by a cryptocurrency wallet and is meant to be kept secret. A user's private key may be used to sign transactions, and it should be kept secure as anyone who has access to it can move or spend the associated cryptocurrency.

[0004] On the other hand, a public key may be a code that is derived from the private key and is used to receive cryptocurrency transactions. It is intended to be shared publicly, as it is used to generate the user's cryptocurrency wallet address. The wallet address may be a string of characters that identifies the user's wallet on the blockchain network, allowing other users to send cryptocurrency to that wallet.

[0005] A cryptocurrency wallet address may be a public key that is generated from the user's private key. When someone wants to send cryptocurrency to a user's wallet, they may use thewallet address, which is e.g., a hash of the user's public key. The sender's cryptocurrency may then be transferred to that address on the blockchain network, and the user can access it using their private key.

[0006] Maintaining and securing a user's keys is essential to holding and controlling crypto assets. There is a maxim in the cryptocurrency community, "not your keys, not your crypto." That is to say, whoever has access to a cryptocurrency account's private keys has access to that cryptocurrency asset. Whether a private commercial holder, an institutional investor, or a government / law enforcement agency, the ability to securely store and recover private keys is critical.

[0007] There are a number of existing solutions to store cryptocurrency keys, including:• Paper wallet: A paper wallet is a printed copy of your public and private keys. This is considered to be one of the safest options for storing your cryptocurrency keys. However, it's important to keep the paper wallet in a secure location as anyone with access to the paper can potentially steal your funds.• Hardware wallet: A hardware wallet is a physical device that stores your cryptocurrency keys offline. Hardware wallets are generally considered to be one of the safest options for storing cryptocurrency keys, as they are not connected to the internet and therefore are less vulnerable to hacking.• Software wallet: A software wallet is a program that you can install on your computer or mobile device. Software wallets can be either hot wallets (connected to the internet) or cold wallets (offline). Cold wallets are generally considered to be safer than hot wallets.• Multisignature wallet: A multisignature wallet requires multiple parties to sign off on a transaction before it can be completed. This adds an extra layer of security as it prevents any single party from having complete control over the funds.• Key splitting: Key splitting involves breaking up your private key into multiple pieces and storing them in different locations. This makes it more difficult for anyone to steal your funds as they would need to access all of the different locations where the keyfragments are stored. This includes wallets which use Multi-Party Computation (MPC) schemes.• Cryptocurrency insurance: Some companies offer insurance policies that cover the loss of cryptocurrency due to theft or other events. This can provide additional peace of mind for cryptocurrency holders.

[0008] Conventional state-of-the-art KBR solutions include solutions based on storing private keys in securely-held physical storage. Examples include storing private keys on air-gapped computer hardware that are stored in Cold War-era bunkers in the Swiss Alps (e.g., Xapo, acquired by Coinbase); sharing private keys via a secret sharing protocol and storing those shards in air-gapped computer hardware in separate secure locations (e.g., CoinCover, Nemean). Maintaining secure physical storage facilities is typically unnecessarily expensive. Moreover, many services which utilize threshold signature or key splitting schemes may be vulnerable to key composition attacks, where keys are exposed after recomposition or decryption.

[0009] Accordingly, there is a need in the art for improved key back-up and recovery technology that overcomes the limitations of these conventional solutions.Summary of the Invention

[0010] The aforementioned need in the art may be solved by new private cryptocurrency key back-up and recovery systems and methods with sufficient security to store key back-ups in the cloud, thereby avoiding physically accessing vault facilities housing air-gapped infrastructure, which is inefficient and subject to inherent security risk by the human required to bridge the air-gapped interface. Embodiments of the invention provide sufficient security for the private cryptocurrency key back-up and recovery by: 1. double-encrypting (or any integer number of M-times encrypting) the key adding multiple layers of data obfuscation, where 2. each encryption layer uses a different encryption protocol with sufficient relative diversity toimprove or maximize obfuscation, and 3. using a layer of homomorphic encryption to decentralize and distribute secret key shares among multiple devices reducing the risk that a data breach of any one (or below threshold number) of those devices will expose the full decryption key and thus the unencrypted private cryptocurrency key.

[0011] In accordance with an embodiment of the invention, a device, system, and method is provided for backing-up a private cryptocurrency key at a remote crypto vault storage system. A ciphertext may be received from a client device, where the ciphertext is an unencrypted (e.g., original plaintext or encoded) form of a private cryptocurrency key CryptoKeypiain configured to control cryptocurrency assets non-homomorphically encrypted with a non-homomorphic encryption key Enc(CryptoKeyPiain,EncKey)=CryptoKeyenc- The once-encrypted received ciphertext CryptoKeyenc may be homomorphically encrypted with a homomorphic encryption key pk to generate a backup of the private cryptocurrency key that is a double-encryption thereof under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk). The double-encryption of the private cryptocurrency key may be stored at the remote crypto vault storage system. An above-threshold number of up to n respective homomorphic private key shares ski,...,sknmay be stored at n distinct storage vault devices of the remote crypto vault storage system, wherein the n homomorphic private key shares are configured to generate n respective partial homomorphic decryptions pi,...,pnof the double-encryption of the private cryptocurrency keyHE_ENC(Enc(CryptoKeypiain,EncKey),pk). A combination (e.g., reconstruction using a, sum, union, etc.) of an above-threshold number of the n partial homomorphic decryptions pi,...,pnmay generate a full homomorphic decryption of the homomorphic encryption of the doubleencryption of the private cryptocurrency key to restore the received ciphertext CryptoKeyenc that is the non-homomorphic encryption of the private cryptocurrency key.

[0012] In accordance with an embodiment of the invention, a device, system, and method is provided for backing-up a private cryptocurrency key using a client device. An unencrypted form of a private cryptocurrency key CryptoKeypiainmay be locally stored that is configured tocontrol cryptocurrency assets and a non-homomorphic encryption key Enc. The unencrypted form of a private cryptocurrency key CryptoKeypiain may be non-homomorphically encrypted with the non-homomorphic encryption key Enc(CryptoKeypiain,EncKey)=CryptoKeyenc to generate a once-encrypted ciphertext. The once-encrypted ciphertext may be transmitted to a remote crypto vault storage system to be homomorphically encrypted with a homomorphic encryption key pk to generate a backup of the private cryptocurrency key that is a double-encryption thereof under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk). n respective homomorphic private key shares ski,...,sknmay be stored, at n distinct storage vault devices of the remote crypto vault storage system, wherein the n homomorphic private key shares are configured to generate n respective partial homomorphic decryptions pi,...,pnof the double-encryption of the private cryptocurrency key HE_ENC(Enc(CryptoKeypiain,EncKey),pk). The combination of an above-threshold number of the n partial homomorphic decryptions pi,...,pnmay generates a full homomorphic decryption of the homomorphic encryption of the double-encryption of the private cryptocurrency key to restore the received ciphertext CryptoKeyenc that is the non-homomorphic encryption of the private cryptocurrency key.

[0013] In accordance with an embodiment of the invention, a device, system, and method is provided for recovering a private cryptocurrency key at a remote crypto vault storage system. The device, system, and method may request from n distinct storage vault devices of the remote crypto vault storage system, n respective partial homomorphic decryptions pi,...,pnof a double-encrypted backup of the private cryptocurrency key encrypted under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk) decrypted by n respective homomorphic private key shares ski,...,skn. An above threshold number of the n partial homomorphic decryptions pi,...,pnmay be combined to generate a full homomorphic decryption of the homomorphic encryption of the double-encrypted backup of the private cryptocurrency key to restore the non-homomorphic encryption of the private cryptocurrency key CryptoKeyenc. The non-homomorphic encryption of the private cryptocurrency key CryptoKeyenc may be transmitted to a client device storing a non-homomorphic decryption key DecKey configured to decrypt the non-homomorphic encryption of the private cryptocurrency key Dec(CryptoKeyenc,DecKey)=CryptoKeypiain to recover an unencrypted form of the private cryptocurrency key CryptoKeypiain configured to control cryptocurrency assets.

[0014] In accordance with an embodiment of the invention, a device, system, and method is provided for recovering a private cryptocurrency key at a client device. A full homomorphic decryption may be received from the remote crypto vault storage system of a homomorphic encryption of a double-encrypted backup of the private cryptocurrency key encrypted under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk) to restore the non-homomorphic encryption of the private cryptocurrency key CryptoKeyenc. The full homomorphic decryption may be generated by combining an above threshold number of n partial homomorphic decryptions pi,...,pno the double-encrypted backup of the private cryptocurrency key. The n partial homomorphic decryptions pi,...,pnmay be decrypted by n respective homomorphic private key shares ski,...,sknstored in n distinct storage vault devices of the remote crypto vault storage system. A non-homomorphic decryption key DecKey may be stored. The non-homomorphic encryption of the private cryptocurrency key may be non- homomorphically decrypted with the non-homomorphic decryption key DecKey Dec(CryptoKeyenc,DecKey)=CryptoKeypiain to recover an unencrypted form of the private cryptocurrency key CryptoKeypiain configured to control cryptocurrency assets.

[0015] The threshold minimum number of vaults, private key shares ski,...,skn, and / or combined partial homomorphic decryptions pi,...,pn, may be i < n for integers i and n when using an 'i-of-n' protocol, in which any of a predetermined number i (or more) of the n partial homomorphic decryptions combine to generate the full homomorphic decryption. The threshold minimum number may be n when using a 'n-of-n' protocol, in which all of the n partial homomorphic decryptions are needed to combine to generate the full homomorphic decryption.

[0016] Whereas double-encryption provides two layers of data obfuscation, embodiment of the invention may add additional encryption layers up to any number of M layers to generate a backup and recovery of the private cryptocurrency key that is secured behind a M-times encryption thereof using M different encryption protocols. The collective set of M encryption protocols may be cumulatively diverse to ensure each encryption layer provides significant, and non-redundant, obfuscation.Brief Description of the Drawings

[0017] The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which:

[0018] Fig. 1 schematically illustrates a system for private cryptocurrency key back-up and recovery using multiple concurrent encryption techniques, according to an embodiment of the invention;

[0019] Fig. 2 schematically illustrates data structures that are encrypted under Fully Homomorphic Encryption for performing computation on the encrypted data, according to an embodiment of the invention;

[0020] Fig. 3 schematically illustrates a system for private cryptocurrency key back-up and recovery using multiple concurrent encryption techniques, according to an embodiment of the invention;

[0021] Fig. 4 is a flowchart of a method for private cryptocurrency key back-up, according to an embodiment of the invention; and

[0022] Fig. 5 is a flowchart of a method for private cryptocurrency key recovery, according to an embodiment of the invention.

[0023] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.Detailed Description of the Invention

[0024] Embodiments of the invention overcome the aforementioned limitations by providing a device, system and method for a cloud-based KBR solution for recovering private cryptocurrency keys at a remote cloud-based crypto vault (e.g., using cloud services such as Amazon® Web Services, Microsoft® Azure). To securely pass a private cryptocurrency key to the cloud, a user interfaces with a client-facing device that initially once-encrypts the private cryptocurrency key, which is then passed to the cloud that then twice-encrypts the private cryptocurrency key. This 'double-encrypted' private cryptocurrency key is thus securely stored in the cloud using multiple overlaid forms of encryption, the decryption of which requires not only its own decryption key but also the inaccessible decryption key of the client-facing device, rendering it impossible or impractical to decrypt the private cryptocurrency key at the cloud. To further secure the double-encrypted private cryptocurrency key, the decryption key for decrypting the second-encryption layer encrypted at the cloud may be divided into multiple n secret key shares distributed among multiple n different respective cloud-based crypto vault devices (e.g., Vault 1, 2, ..., n of Figs. 1 and 2). Whereas each secret key share only partially (but not fully) decrypts the key, the combination of an above threshold number / < n of multiple partial decryptions by the / < n respective secret key shares (e.g., / < n shares in a 'i-of-n' protocol and all n shares in a 'n-of-n' protocol) cumulatively fully decrypts the second-encryption layer revealing the once-encrypted key. Distributed storage of secret key shares reduces the risk of exposing the once-encrypted key since a data breach of one or more vault devices only reveals their one or more secret key shares respectively stored therein. As long as the number of hacked vaults is less than the number / of secret key shares (and partial decryptions) needed to fully decrypt, the double-encrypted private cryptocurrency key is safely maintained and cannot be decrypted. To collaboratively decrypt at the cloud using multiple i secret key shares, the second encryption at the cloud may be a homomorphic encryption, which allows its partial decryptions to be combined to yield a full decryption. To further bolster security, since diversity in encryption types generally increases encryption efficacy, embodiments of the invention may use different encryption types at the client layer (first encryption) and cloud layer (second layer), for example, a non-homomorphic encryption (e.g., Advanced Encryption Standard (AES)) at the client-facing device and a homomorphic encryption (e.g., lattice-based threshold fully homomorphic encryption (FHE)) at the cloud. This cloudbased KBR solution thus preserves the integrity of the double-encrypted private cryptocurrency key against attacks and data breaches of up to any number less than the number of / vaults exposing up to any number less than the number of i total secret key shares needed to collaboratively decrypt. Embodiments of the invention thus improve the security of the private cryptocurrency key by 1. double-encrypting the key, 2. double-encrypting the key using diverse encryption types - both homomorphic and non-homomorphic encryption, and 3. decentralizing decryption by collaboration among multiple crypto vault devices (e.g., Vault 1, 2, ..., n) each partially decrypting with its unique secret key share. This improvement to security makes possible backup and recovery of private cryptocurrency keys at a remote cloud-based crypto vault, rather than air-gapped infrastructure housed in remote physical facilities, which improves KBR solution accessibility (e.g., clients can access the KBR service from any remote location without anyone having to physically access the facility housing the air-gapped infrastructure) and efficiency (e.g., key recovery may be fast or nearly instantaneous, taking the time of collaborative decryption and transmission, eliminating time for physically accessing data off of an air-gapped device).

[0025] Reference is made to Fig. 1, which schematically illustrates a system for secret key backup and recovery, according to an embodiment of the invention. The system may include clientside devices - secure client storage 100 and / or client-side device 102 - that may be "trusted" (or more trusted compared to the remote-side), e.g., such that they are intended to be accessible and controlled by only one or more trusted clients. Client-side device 102 may contain, or may be operably and / or physically connected to and separate from, secure client storage 100. The system may also include remote devices (physically separated from client-side devices and remotely connected over a network) - remote crypto vault 104 including, or operably connected to, a plurality of n vaults 112a-z - that may be "untrusted" or "semi-trusted" (or less trusted compared to the client-side), e.g., such that they are accessible to non-client entities and thus more vulnerable to hacking or other cyberattacks.

[0026] Client storage 100 may be a secure storage device (e.g., an encryption drive, hardware wallet, software wallet, etc.) configured to locally store a private cryptocurrency key 101 CryptoKeypiain in an unencrypted or plaintext form. The private cryptocurrency key 101 may control cryptocurrency (e.g., cryptocurrency assets, cryptocurrency wallets, cryptocurrency devices, etc.) and is thus considered sensitive information. Secure client storage 100 may also store and / or retrieve a pair of an encryption key 103 and a decryption key 105 EncKey;DecKey configured for encryption and its corresponding decryption, respectively. The client-side encryption-decryption key pair 103, 105 may use a type of encryption that is non- homomorphic, for example, to differentiate from and increase security in combination with the homomorphic encryption key 106 used at the remote-side 104. The combination of multiple different types or protocols of encryption, in particular homomorphic combined with non- homomorphic, improves the effective obfuscation of the combined encryptions compared with that using multiple of the same or similar type(s) or protocol(s) of encryption.

[0027] Remote crypto vault 104 may store a homomorphic encryption key 106 pk remotely from client storage 100 and client-side device 102. The plurality of n vaults 112a-z may store n private key shares ski,...,sknto generate n partial homomorphic decryptions, respectively, ofhomomorphic encryption key 106 pk. In some embodiments using an 7-of-n' protocol, any of a predetermined number / (or more) of the n partial decryptions may be combined to generate the full homomorphic decryption of encryption key 106 pk, where / < n for integers / and n. In some embodiments using an 'n-of-n' protocol, all n partial homomorphic decryptions are combined to generate the full homomorphic decryption of encryption key 106 pk.

[0028] A key back-up procedure (e.g., described in reference to Fig. 4) may include a two-stage two-location encryption as follows:

[0029] In a first encryption stage (in the trusted client-side environment), client-side device 102 may encrypt the unencrypted plaintext form of the private cryptocurrency key 101 CryptoKeypiain with non-homomorphic encryption key 103 Enc to generate a once-encrypted ciphertext 108 Enc(CryptoKeypiain,EncKey)=CryptoKeyenc- Client-side device 102 may transmit once-encrypted ciphertext 108 to remote crypto vault 104 for the next encryption stage.

[0030] In a second encryption stage (in the remote-side environment), remote crypto vault 104 may homomorphically encrypt the once-encrypted received ciphertext 108 CryptoKeyenc with the homomorphic encryption key 106 pk to generate a double-encrypted ciphertext 110 of the private cryptocurrency key encrypted under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk)=HE_ENC(CryptoKeyenc,pk). This doubleencrypted ciphertext 110 is secured at remote crypto vault 104 under two layers of encryption (by keys Enc 103 and pk 106), one of which - non-homomorphic encryption key 103 Enc - is inaccessible to remote crypto vault 104 because it is securely stored at the separate location in secure client storage 100.

[0031] A key recovery procedure (e.g., described in reference to Fig. 5) may include two-stage two-location decryption as follows:

[0032] In a first decryption stage (to decrypt the second stage encryption), remote crypto vault104 may retrieve from an above-threshold number of the n vaults 112a-z, an above-threshold number of the homomorphic private key shares ski,...,sknconfigured to collectively fully decrypt homomorphic encryption key 106 pk (e.g., the above-threshold number may be at least / in an ' / -of-n' protocol or n in an 'n-of-n' protocol). Remote crypto vault 104 (or the respective vaults 112a-z) may partially decrypt the second encryption layer of the double-encrypted ciphertext 110 with each of the above-threshold number of the homomorphic private key shares ski,...,sknto generate an above-threshold number of n partial homomorphic decryptions pi,...,pnof the double-encryption of the private cryptocurrency key HE_Dec(HE_Enc(CryptoKeyenc,pk),ski,...,skn). Remote crypto vault 104 may combine (e.g., sum) the above-threshold number of the n partial homomorphic decryptions pi,...,pnto generate a full homomorphic decryption of the second stage encryption homomorphic encryption key 106 pk. This collaborative homomorphic decryption generates a ciphertext 114 that is CryptoKeyenc - a once-encrypted version of the private cryptocurrency key by non-homomorphic encryption key 103 Enc (a copy of once-encrypted ciphertext 108). Distributing the private key shares ski,...,skndecentralizing decryption across the n vaults 112a-z to improve security so no one device stores a full private decryption key. Remote crypto vault 104 may transmit ciphertext 114 to client-side device 102 for the next decryption stage.

[0033] In a second decryption stage (to decrypt the first stage encryption), client-side device 102 may receive ciphertext 114 CryptoKeyenc and retrieve non-homomorphic decryption key105 DecKey from client storage 100. Client-side device 102 may non-homomorphically decrypt ciphertext 114 with non-homomorphic decryption key 105 DEC(CryptoKeyenc, DecKey) to expose the plaintext private cryptocurrency key 116 CryptoKeypiain in the trusted client-side environment. This plaintext private cryptocurrency key 116 is a copy of the original (e.g., lost, damaged or destroyed) plaintext private cryptocurrency key 101. Client-side device 102 may securely store the recovered private cryptocurrency key 116 in secure client storage 100 (e.g., in plaintext or encrypted form). Recovered Private cryptocurrency key 116 CryptoKeypiain may be used (as original private cryptocurrency key 101) to control associated cryptocurrency.

[0034] While Fig. 1 shows two encryption stages (using 1. Non-HE key Enc and 2. HE key pk), the description thereof may be generalized to support any number of encryption stages. A third, fourth, ...., up to any integer M of encryption layers, devices, encryption keys, and n(M- 1)+1 decryption key shares may be used, each stage adding an additional layer of security under a different encryption protocol to further obfuscate the underlying crypto currency key 101.

[0035] Client-side encryption key 103 Enc and remote-side encryption key 106 pk may use different encryption protocols to improve data obfuscation. In one embodiment, encryption keys 103 Enc may be non-homomorphic, while encryption key 106 pk is homomorphic.Alternatively, the foregoing description may be modified such that both encryption keys 103 Enc and 106 pk may be homomorphic, but use different homomorphic encryption protocols.

[0036] Any of the devices described in reference to Fig. 1 may be subdivided or combined. In some embodiments, the devices of Fig. 1 may be organized according to the system infrastructure described in reference to Fig. 2.

[0037] Reference is made to Fig. 2, which schematically illustrates a system for secret key backup and recovery using multiple concurrent encryption techniques, according to an embodiment of the invention. The system of Fig. 2 may have a Client-Server architecture comprising an end user-facing frontend - the Client Management Service (e.g., secure client storage 100 and / or client-side device 102 of Fig. 1) and a backend Crypto Vault Service (e.g., remote crypto vault 104 and / or vaults 112a-z of Fig. 1).

[0038] Client Management Service 200: A user-facing Client Management Service (CMS) 200 may provide a client interface to the system including, in some embodiments, a graphical user interface (GUI) 204, identity management engine 206, a client API 208, a client management engine 210, a cryptography processing engine 212, a crypto key manager 214 and / or a key store 216.

[0039] CMS 200 may provide a system for the user to submit their unencrypted plaintext wallet address(es), public, and / or private cryptocurrency keys for storage via GUI 204. Private cryptocurrency keys uploaded through CMS 200 may be immediately encrypted by cryptography processing engine 212 using an encryption algorithm, such as, a well-established, standard data-at-rest encryption algorithm (e.g., AES-256). Key store 216 may store an encryption and decryption key pair, EncKey, DecKey. CMS 200 may interface with the Crypto Vault Service 202 to send the already encrypted cryptocurrency wallet address(es), public cryptocurrency key(s), and / or private cryptocurrency key(s) to the Crypto Vault Service 202. Once the Crypto Vault Service 202 receives the transferred data, a confirmation may be sent to CMS 200, and then CMS 200 may erase all caches where the cryptocurrency key information had been recorded.

[0040] CMS 200 may comprise the following components:• Client Management Engine 210 may coordinate all client-side operations, including e.g., standard encryption / decryption operations, communication between CMS 200 and Crypto Vault Service 202, and / or client identity management 206.• Client API 208 may define all services available through CMS 200.• Client Management Graphical User Interface (GUI) 204 may provide a user-friendly interface for the end user to interact with the system to perform key backup and / or recovery.• CMS 200 may include a recovery function within its API 208 that enables the end user to recover private cryptocurrency keys from the Crypto Vault Service 202. This recovery function may be initiated by client identity management 206 verifying the identity of the requesting end user to ensure that the request is legitimate. The criteria for client identity management 206 to validate a user identity for recovery functions may be situation dependent (e.g., the verification requirements may likely be different for law enforcement agents custodying crypto keys for an investigation, rather than a privateuser using this service to store their crypto keys). Identity validation may be performed by client identity management 206 according to known available validation services.

[0041] Crypto Vault Service 202: A Crypto Vault Service (CVS) 202 may provide the mechanisms that enable a cloud-based service to securely store the cryptocurrency wallet and / or key information transferred from CMS 200, along with homomorphic encryption operations. The already encrypted private key may be doubly-encrypted by CVS 202, e.g., using lattice-based Fully Homomorphic Encryption (FHE); specifically, a multi-party variant known as Threshold Fully Homomorphic Encryption (TFHE). TFHE is an asymmetric encryption protocol where there is a public key pk and n secret share keys sko,ski,...,skn-i. Each secret key ski can compute a partial decryption p,, and a set of partial decryptions {p},es for a set of parties S in an access structure d can compute a complete decryption.

[0042] CVS 202 may comprise the following components:• The Receiver and Threshold Encryption Server 222 may handle all remote-side operations, e.g., except for the actual storage of secret key shares at vaults 220a-z: o A Cloud Storage Engine 226 may coordinate all operations within CVS 202. This includes, e.g., receiving encrypted cryptocurrency keys from CMS 200, validating the identity of the requesting party sent via CMS 202, triggering TFHE operations, and / or sending and receiving secret key shares from vaults 220a-z. o An Identity Validation 224 component may verify the identity of the requesting party sent via CMS 200. o A TFHE Key Manager 228, Public Key Store 230, and Secret Shared Key Store 232 may handle all TFHE operations.• Vaults 1, 2, ..., n 220a-z may each be distinct servers, storage units or other physical devices (e.g., one or more server(s) 110 of Fig. 3) located in different locations (e.g., data centers). They may receive and hold Secret Share Keys until the keys are requested by the Receiver and Threshold Encryption Server 222.

[0043] Operational Overview: The system of Fig. 2 may execute the following operations:

[0044] Key Back-up:1. System Initialization: Upon first using the system, the user may submit identity information and send a request to the Client Management Engine 210 to generate a cryptographic key. The Client Management Engine 210 may then send a request to the Crypto Key Manager 214 to generate a key according to the client-side encryption (e.g., an AES key) < / D user, EncKey,DecKey>).2. The user may initiate a request to store their cryptocurrency key(s) (CryptoKeypiain) in the Crypto Vault Service 202.3. The Client Management Engine 210 may submit a request to encrypt the CryptoKeypiain to get the ciphertext (Enc(CryptoKeypiain,EncKey)=CryptoKeyenc)-4. The Client Management Engine 210 may submit a request to the Crypto Vault Service 202 to store the id / CryptoKey pair (<IDUSer, IDdata, CryptoKeyenc>).5. The Cloud Storage Engine 226 may receive the storage request and calls on the TFHE Key Manager 228 to generate a public TFHE encryption key pk and n Secret Share Keys ski,...,skn.6. The Identity Validation module 224 may receive and store IDUSer-7. (<IDdata, Crypto Keyenc>) may be encrypted using TFHE and pk (TFHE_ENC(pk, <IDdata, Crypto Key enc>)) with Secret Share Keys ski...,skndistributed among server, Vaulti,...,Vaultn220a-z.

[0045] Key Recovery:1. The user may submit a recovery request <RequestcryPtoKey> to the Client Management Engine 210. The user may sufficiently verify their identity to match the Identity Management module 206 and produce a User Identity Token <IDrequest>-2. The Client Management Engine 210 may send (<IDrequest, RequestcryPtoKey>) to the Cloud Storage Engine 226.3. The Cloud Storage Engine 226 may call the Identity Validation module 224 to validate IDrequest to ensure that RequestayptoKey is authorized (e.g., if HammingDistance(IDUser,I DRequest)=O then the request is authorized.)4. The Cloud Storage Engine 226 may request partial decryption keys p, from each respective Vault, 220i for a complete decryption, e.g., TFHE_DEC({ski,...,ski}, TFHE_ENC(pk, clDdata, CryptoKeyenc>)) = CryptoKeyenc.5. The Cloud Storage Engine 226 may send CryptoKeyenc to the Client Management Service 200.6. The Client Management Engine 210 may request the decryption key DecKey from the Crypto Key Manager 214. If the client is using symmetric encryption, then the client-side encryption and decryption keys are typically the same.7. The Client Management Engine 210 may queue the Crypto Processing Engine 212 to decrypt CryptoKeyenc to get the plaintext cryptocurrency key via a decryption function DECfDecKey, CryptoKeyenc) = CryptoKeypiain.

[0046] Reference is made to Fig. 3, which schematically illustrates a system 300 for private cryptographic key back-up and / or recovery using multiple concurrent encryption techniques, according to some embodiments of the invention. Embodiments described herein may be executed using any single or combination of devices and / or components of system 300 of Fig. 3. System 300 may be operated by one or more client-side devices 340 and / or 350 (e.g., trusted / secure parties or services) and / or one or more remote-side devices 310 and / or 312a-z (e.g., untrusted / insecure, semi-trusted / semi-secure, trusted / secure parties or services and / or parties or services of unknown trust / security), such as, those described in reference to Figs. 1 and 2. Secure parties (e.g., at the client-side) may operate on unencrypted data (e.g., homomorphically encrypting the data), while insecure, semi-secure or unknown security parties (e.g., at the remote-side, such as, in a cloud-based infrastructure) operate only on encrypted (but not unencrypted) data.

[0047] System 300 may include one or more remote crypto vault storage system 310, n storage vault devices 312a-z, and / or client device(s) 340, 350, ..., any of which may operate as a secure or insecure service or party. Any or all of system 300 devices may be connected via one or more network(s) 320. Secure services or parties may each securely store their own unencrypted (or encrypted) private cryptocurrency key. Insecure services or parties may not access another party's unencrypted private cryptocurrency key.

[0048] Remote crypto vault storage system 310 may include a network-connected interface for communicating with client device(s) 340, 350 over network 320 (e.g., in a cloud service infrastructure) and may include, or be operatively connected (over network 320) to a plurality of n distinct storage vault devices 312a-z. Remote crypto vault storage system 310 may include a secure storage 315 having software processes or applications for storing and retrieving a double-encrypted ciphertext 317 that is a back-up of the private cryptocurrency key (e.g., double-encrypted ciphertext 110 of Fig. 1), computations, and / or encryption keys (e.g., encryption key 106 pk of Fig. 1). Secure storage 315 and / or memory unit(s) 318 may also include code (e.g., software code) or logic, e.g., to enable the secret key back-up and recovery using multiple concurrent encryption techniques according to embodiments of the invention. Secure storage 315 may be internal or external to one or more of server(s) 310 and may be connected thereto by a local or remote and a wired or wireless connection. In alternate embodiments, double-encrypted ciphertext 317 may be stored in an alternate location separate from secure storage 315, e.g., memory unit(s) 318, 348, and / or 358.

[0049] n storage vault devices 312a-z may each include software processes or applications for storing and retrieving n respective homomorphic private key shares ski,...,sknsuch as devices 112a-z and 220a-z depicted in Fig. 1-2. n storage vault devices 312a-z may be internal or external to remote crypto vault storage system 310 and may be connected thereto by a local or remote and a wired or wireless connection. In alternate embodiments, private key shares ski,...,sknmay be stored in an alternate location separate from devices 312a-z, e.g., secure storage 315 or memory unit(s) 318, 348, and / or 358.

[0050] Client devices 340 and 350 may include a network-connected interface for communicating with a remote crypto vault storage system 310 over network 320 (e.g., in a cloud service infrastructure). Client devices 340 and 350 may be servers, personal computers, desktop computers, mobile computers, laptop computers, and notebook computers or any other suitable device such as a cellular telephone, personal digital assistant (PDA), video game console, etc., and may include wired or wireless connections or modems. Client devices 340 and 350 may include one or more input devices 342 and 352, respectively, for receiving input from a user (e.g., an unencrypted plaintext form of a private cryptocurrency key). Client devices 340 and 350 may include one or more output devices 344 and 354 (e.g., a monitor or screen) for displaying data to a user, such as a recovered private cryptocurrency key, provided by remote crypto vault storage system 310.

[0051] Network 320, which connects remote crypto vault storage system 310, storage vault devices 312a-z and / or client devices 340 and 350, may be any public or private network such as the Internet. Access to network 320 may be through wire line, terrestrial wireless, satellite or other systems well known in the art.

[0052] Remote crypto vault storage system 310, client device(s) 340 and 350, and n storage vault devices 312a-z may each include one or more controller(s) or processor(s) 316, 346, 356, and 313 respectively, for executing operations according to embodiments of the invention and one or more memory unit(s) 318, 348, 358, and 315 respectively, for storing data (e.g., encryption and / or decryption keys, and encrypted and / or decrypted data) and / or instructions (e.g., software for applying computations or calculations, keys to encrypt or decrypt data according to embodiments of the invention) executable by the processor(s). Processor(s) 316, 346, 356, and / or 313 may include, for example, a central processing unit (CPU), a digital signal processor (DSP), a microprocessor, a controller, a chip, a microchip, an integrated circuit (IC), or any other suitable multi-purpose or specific processor or controller. Memory unit(s) 318, 348, 358, and / or 315 may include, for example, a random access memory (RAM), a dynamic RAM (DRAM), a flash memory, a volatile memory, a non-volatile memory, acache memory, a buffer, a short term memory unit, a long term memory unit, or other suitable memory units or storage units.

[0053] Embodiments of the invention may include an article such as a computer or processor readable non-transitory storage medium, such as for example a memory, a disk drive, or a USB flash memory device (e.g., memory unit(s) 318, 348, 358, and / or 315 of Fig. 3) encoding, including or storing instructions, e.g., computer-executable instructions, which when executed by a processor or controller (e.g., controller(s) or processor(s) 316, 346, 356, and / or 313 of Fig. 3), cause the processor or controller to carry out methods disclosed herein.

[0054] Operations described below in reference to Figs. 4 and 5 may be executed using devices described in reference to Figs. 1-3. The methods of Figs. 4 and 5 may be executed using a clientside device (e.g., secure client storage 100 and / or client-side device 102 of Fig. 1, client management service 200 of Fig. 2, and / or client-side devices 340 and / or 350 of Fig. 3) and / or a remote-side device, such as, remote crypto vault storage system (e.g., 104 of Fig. 1, 202 of Fig. 2, and / or 310 of Fig. 3) and / or n storage vault devices (112a-z of Fig. 1, 220a-z of Fig. 2, and / or 312a-z of Fig. 3).

[0055] Reference is made to Fig. 4, which is a flowchart of a method for backing-up a private cryptocurrency key, according to an embodiment of the invention.

[0056] In operation 400, one or more processor(s) at a client-side device may locally store an unencrypted (e.g., plaintext or encoded) form of a private cryptocurrency key CryptoKeypiain configured to control cryptocurrency assets and a non-homomorphic encryption key Enc.

[0057] In operation 410, one or more processor(s) at a client-side device may non- homomorphically encrypt the unencrypted form of a private cryptocurrency key CryptoKeypiain with the non-homomorphic encryption key Enc(CryptoKeypiain,EncKey)=CryptoKeyenc to generate a once-encrypted ciphertext.

[0058] In operation 420, one or more processor(s) at a client-side device may transmit, and one or more processor(s) at a remote-side device may receive, the once-encrypted ciphertext.

[0059] In operation 430, one or more processor(s) at a remote-side device may homomorphically encrypt the once-encrypted received ciphertext CryptoKeyenc with a homomorphic encryption key pk to generate a backup of the private cryptocurrency key that is a double-encryption thereof under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk). The one or more processor(s) at a remote-side device may store the double-encryption backup of the private cryptocurrency key. Upon storing the double-encryption backup of the private cryptocurrency key at the remote-side device, one or more processor(s) at the remote-side device may transmit a command to the client device, or the client device may receive the command to trigger the client device to delete the once- encrypted ciphertext of the private cryptocurrency key stored at the client device.

[0060] In operation 440, one or more processor(s) at a remote-side device may store, at up to n distinct storage vault devices of the remote crypto vault storage system, up to n respective homomorphic private key shares ski,...,sknconfigured to generate up to n respective partial homomorphic decryptions pi,...,pnof the double-encryption of the private cryptocurrency key HE_ENC(Enc(CryptoKeypiain,EncKey),pk). The combination of an above-threshold number of the n partial homomorphic decryptions pi,...,pnmay generate a full homomorphic decryption of the homomorphic encryption of the double-encryption of the private cryptocurrency key to restore the received ciphertext CryptoKeyenc that is the non-homomorphic encryption of the private cryptocurrency key. This restored once-encrypted ciphertext may be used for recovering the original unencrypted form of a private cryptocurrency key as described in reference to Fig. 5.

[0061] Reference is made to Fig. 5, which is a flowchart of a method for recovering a back-up copy of a private cryptocurrency key stored in a remote crypto vault storage system, according to an embodiment of the invention.

[0062] In operation 500, one or more processor(s) at a remote-side device may request from up to n distinct storage vault devices of the remote crypto vault storage system, up to n respective partial homomorphic decryptions pi,...,pnof a double-encrypted backup of the private cryptocurrency key encrypted under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk) decrypted by up to n respective homomorphic private key shares ski,...,skn.

[0063] In operation 510, one or more processor(s) at a remote-side device may combine an above threshold number of the n partial homomorphic decryptions pi,...,pnto generate a full homomorphic decryption of the homomorphic encryption of the double-encrypted backup of the private cryptocurrency key to restore the non-homomorphic encryption of the private cryptocurrency key CryptoKeyenc- In an 'i-of-n' protocol, any number equal to or above the predetermined threshold i of the n partial homomorphic decryptions may be combined to generate the full homomorphic decryption where i < n for integers i and n. In a 'n-of-n' protocol, all of the n partial homomorphic decryptions may be needed to be combined to generate the full homomorphic decryption.

[0064] In operation 520, one or more processor(s) at a remote-side device may transmit, and one or more processor(s) at a client-side device may receive, the restored non-homomorphic encryption of the private cryptocurrency key CryptoKeyenc-

[0065] In operation 530, one or more processor(s) at a client-side device may locally store a non-homomorphic decryption key DecKey.

[0066] In operation 540, one or more processor(s) at a client-side device may non- homomorphically decrypt the non-homomorphic encryption of the private cryptocurrency key with the non-homomorphic decryption key DecKey Dec(CryptoKeyenc,DecKey)=CryptoKeypiain torecover an unencrypted form of the private cryptocurrency key CryptoKeypiain configured to control cryptocurrency assets.

[0067] Additional or different operations may be used, operations may be excluded, operations may be separated or combined, and different orders of operations may be used in the methods of Figs. 4 and 5. For example, operation 430 may repeat any number of times to add additional encryption layers up to M total layers to generate a backup of the private cryptocurrency key that is a M-times encryption thereof using M different encryption protocols.

[0068] Description of Terms:

[0069] Homomorphism: A homomorphism may be a mapping between two algebraic structures (e.g., of the same class, such as, two fields) which preserves the underlying structure of the input structure. In one example, for a map F: A^ B, with x,yeA, and an operation •, then F(x-y) = F(x)-F(y).

[0070] Fully Homomorphic Encryption: Homomorphic Encryption (HE) may refer to a class of cryptographic primitives which allow for computation on encrypted data, for example, combining (e.g., summing) multiple partial homomorphic decryptions to generate a full homomorphic decryption as described in reference to Fig. 1. 'Partially' Homomorphic Encryption schemes may allow for a single class of computation operations (e.g., addition). 'Somewhat' Homomorphic Encryption may enable two classes of computation operations (e.g., addition and multiplication), with an arbitrary number of computations under one operation and a very limited number of computations in the other. Fully Homomorphic Encryption (FHE) may allow for an arbitrary number of supported computation operations.

[0071] According to various embodiments of the invention, the original and / or restored private cryptocurrency key may be used to control cryptocurrency assets by, for example, automatically entering the recovered unencrypted form of the private cryptocurrency key intoa cryptocurrency wallet to gain control of the cryptocurrency assets therein; executing cryptocurrency transactions of cryptocurrency assets associated with the restored private cryptocurrency key, cancelling cryptocurrency transactions of cryptocurrency assets associated with the restored private cryptocurrency key, controlling a cryptocurrency wallet associated with the restored private cryptocurrency key, copying a cryptocurrency wallet associated with the restored private cryptocurrency key, controlling a cryptocurrency device associated with the restored private cryptocurrency key, and / or transferring cryptocurrency or digital assets to a new wallet or device with new private keys. In an embodiment where blockchain technology is used for access and authentication controls, private keys like cryptocurrency keys could be used to gain access to IT / OT systems in this scenario.

[0072] Alternate or additional Uses: The systems of Figs. 1-3 and methods of Figs. 4-5 can be adapted to numerous key backup use cases beyond cryptocurrency. For instance, the systems and methods could be substantially equivalently used for backup and recovery of any key or secret data, e.g., a private key in any enterprise PKI infrastructure.

[0073] One skilled in the art will realize the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The embodiments described herein are therefore to be considered in all respects illustrative rather than limiting. In detailed description, numerous specific details are set forth in order to provide an understanding of the invention. However, it will be understood by those skilled in the art that the invention can be practiced without these specific details. In other instances, well-known methods, procedures, and components, modules, units and / or circuits have not been described in detail so as not to obscure the invention.

[0074] Embodiments may include different combinations of features noted in the described embodiments, and features or elements described with respect to one embodiment or flowchart can be combined with or used with features or elements described with respect to other embodiments.

[0075] Although embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, "processing," "computing," "calculating," "determining," "establishing", "analyzing", "checking", or the like, can refer to operation(s) and / or process(es) of a computer, or other electronic computing device, that manipulates and / or transforms data represented as physical (e.g., electronic) quantities within the computer's registers and / or memories into other data similarly represented as physical quantities within the computer's registers and / or memories or other information non-transitory storage medium that can store instructions to perform operations and / or processes.

[0076] The term set when used herein can include one or more items. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.

Claims

CLAIMS1. A method for securely storing a back-up copy of a private cryptocurrency key at a remote crypto vault storage system, the method comprising: receiving from a client device, a ciphertext of an unencrypted form of a private cryptocurrency key CryptoKeypiain configured to control cryptocurrency assets non- homomorphically encrypted with a non-homomorphic encryption key Enc(Crypto Key plan, EncKey) =Cryp toKeyenc; homomorphically encrypting the once-encrypted received ciphertext CryptoKeyenc with a homomorphic encryption key pk to generate a backup of the private cryptocurrency key that is a double-encryption thereof under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain, EncKey), pk); storing the double-encryption of the private cryptocurrency key at the remote crypto vault storage system; and storing, at n distinct storage vault devices of the remote crypto vault storage system, n respective homomorphic private key shares ski,...,sknconfigured to generate n respective partial homomorphic decryptions pi,...,pnof the double-encryption of the private cryptocurrency key HE_ENC(Enc(CryptoKeypiam, EncKey), pk), wherein the combination of an above-threshold number of the n partial homomorphic decryptions pi,...,pngenerates a full homomorphic decryption of the homomorphic encryption of the double-encryption of the private cryptocurrency key to restore the received ciphertext CryptoKeyenc that is the non- homomorphic encryption of the private cryptocurrency key.

2. A method for a client-device generating a back-up copy of a private cryptocurrency key, the method comprising: locally storing an unencrypted form of a private cryptocurrency key CryptoKeypiain configured to control cryptocurrency assets and a non-homomorphic encryption key Enc; non-homomorphically encrypting the unencrypted form of a private cryptocurrency key CryptoKeypiain with the non-homomorphic encryption key Enc(CryptoKeypiain,EncKey)=CryptoKeyenc to generate a once-encrypted ciphertext;transmitting the once-encrypted ciphertext to a remote crypto vault storage system to be homomorphically encrypted with a homomorphic encryption key pk to generate and store a backup of the private cryptocurrency key that is a double-encryption thereof under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk) and store, at n distinct storage vault devices of the remote crypto vault storage system, n respective homomorphic private key shares ski,...,sknconfigured to generate n respective partial homomorphic decryptions pi,...,pnof the double-encryption of the private cryptocurrency key HE_ENC(Enc(CryptoKeypiain,EncKey),pk), wherein the combination of an above-threshold number of the n partial homomorphic decryptions pi,...,p generates a full homomorphic decryption of the homomorphic encryption of the double-encryption of the private cryptocurrency key to restore the received ciphertext CryptoKeyenc that is the non- homomorphic encryption of the private cryptocurrency key.

3. A method for recovering a back-up copy of a private cryptocurrency key stored in a remote crypto vault storage system, the method comprising: requesting from up to n distinct storage vault devices of the remote crypto vault storage system, up to n respective partial homomorphic decryptions pi,...,pnof a double-encrypted backup of the private cryptocurrency key encrypted under both homomorphic and non- homomorphic encryption HE ENCfEncfCryptoKeypiain EncKey^pk) decrypted by up to n respective homomorphic private key shares ski,...,skn; combining an above threshold number of the n partial homomorphic decryptions pi,...,pnto generate a full homomorphic decryption of the homomorphic encryption of the double-encrypted backup of the private cryptocurrency key to restore the non-homomorphic encryption of the private cryptocurrency key CryptoKeyenc, and transmitting the non-homomorphic encryption of the private cryptocurrency key CryptoKeyenc to a client device storing a non-homomorphic decryption key DecKey configured to decrypt the non-homomorphic encryption of the private cryptocurrency keyDec(CryptoKeyenc,DecKey)=CryptoKeypiain to recover an unencrypted form of the private cryptocurrency key CryptoKeypiain configured to control cryptocurrency assets.

4. A method for a client-device to recover a back-up copy of a private cryptocurrency key stored in a remote crypto vault storage system, the method comprising: receiving from the remote crypto vault storage system a full homomorphic decryption of a homomorphic encryption of a double-encrypted backup of the private cryptocurrency key encrypted under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk) to restore the non-homomorphic encryption of the private cryptocurrency key CryptoKeyenc, wherein the full homomorphic decryption is generated by combining an above threshold number of n partial homomorphic decryptions pi,...,pnof the double-encrypted backup of the private cryptocurrency key, wherein the n partial homomorphic decryptions pi,...,pnare decrypted by n respective homomorphic private key shares ski,...,sknstored in n distinct storage vault devices of the remote crypto vault storage system; storing a non-homomorphic decryption key DecKey; non-homomorphically decrypting the non-homomorphic encryption of the private cryptocurrency key with the non-homomorphic decryption key DecKey Dec(CryptoKeyenc,DecKey)=CryptoKeypiain to recover an unencrypted form of the private cryptocurrency key CryptoKeypiain configured to control cryptocurrency assets.

5. The method of any of the preceding claims comprising adding additional encryption layers up to M layers to generate a backup of the private cryptocurrency key that is a M-times encryption thereof using M different encryption protocols.

6. The method of any of the preceding claims comprising upon storing the doubleencryption backup of the private cryptocurrency key at the remote crypto vault storage system, transmitting a command to the client device or receiving a command at the client device totrigger the client device to delete the once-encrypted received ciphertext of the private cryptocurrency key stored at the client device.

7. The method of any of the preceding claims, wherein, using an 'i-of-n' protocol, any of a predetermined number i (or more) of the n partial homomorphic decryptions are combined to generate the full homomorphic decryption where i < n for integers i and n.

8. The method of any of the preceding claims, wherein, using a 'n-of-n' protocol, all of the n partial homomorphic decryptions are combined to generate the full homomorphic decryption.

9. The method of any of the preceding claims, wherein the restored private cryptocurrency key is used to control cryptocurrency assets selected from the group consisting of: automatically entering the recovered unencrypted form of the private cryptocurrency key into a cryptocurrency wallet to gain control of the cryptocurrency assets therein; executing cryptocurrency transactions of cryptocurrency assets associated with the restored private cryptocurrency key, cancelling cryptocurrency transactions of cryptocurrency assets associated with the restored private cryptocurrency key, controlling a cryptocurrency wallet associated with the restored private cryptocurrency key, copying a cryptocurrency wallet associated with the restored private cryptocurrency key, controlling a cryptocurrency device associated with the restored private cryptocurrency key, and transferring cryptocurrency or digital assets to a new wallet or device with new private keys.

10. A remote crypto vault storage system comprising: a network-connected interface for communicating with a client device; a storage comprising one or more memories; a plurality of n distinct storage vault devices; and one or more processors configured to: at the network-connected interface, receive from the client device, a ciphertext of an unencrypted form of a private cryptocurrency key CryptoKeypiain configured tocontrol cryptocurrency assets non-homomorphically encrypted with a non- homomorphic encryption key Enc(CryptoKeypiain,EncKey)=CryptoKeyenc, homomorphically encrypt the once-encrypted received ciphertext CryptoKeyencwith a homomorphic encryption key pk to generate a backup of the private cryptocurrency key that is a double-encryption thereof under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk), at the storage, store the double-encryption of the private cryptocurrency key at the remote crypto vault storage system, and at the plurality of n distinct storage vault devices, store n respective homomorphic private key shares ski,...,sknconfigured to generate n respective partial homomorphic decryptions pi,...,pnof the double-encryption of the private cryptocurrency key HE_ENC(Enc(CryptoKeypiain,EncKey),pk), wherein the combination of an above-threshold number of the n partial homomorphic decryptions pi,...,pngenerates a full homomorphic decryption of the homomorphic encryption of the double-encryption of the private cryptocurrency key to restore the received ciphertext CryptoKeyenc that is the non-homomorphic encryption of the private cryptocurrency key.

11. A client device for generating a back-up copy of a private cryptocurrency key, the client device comprising: a network-connected interface for communicating with a remote crypto vault storage system; a storage comprising one or more memories; and one or more processors configured to: at the storage, locally store an unencrypted form of a private cryptocurrency key Crypto Key plain configured to control cryptocurrency assets and a non-homomorphic encryption key Enc, non-homomorphically encrypt the unencrypted form of a private cryptocurrency key CryptoKeypiain with the non-homomorphic encryption key Enc(CryptoKeypiain,EncKey)=CryptoKeyenc to generate a once-encrypted ciphertext,transmit the once-encrypted ciphertext via the network-connected interface to the remote crypto vault storage system to be homomorphically encrypted with a homomorphic encryption key pk to generate and store a backup of the private cryptocurrency key that is a double-encryption thereof under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk) and store, at n distinct storage vault devices of the remote crypto vault storage system, n respective homomorphic private key shares ski,...,sknconfigured to generate n respective partial homomorphic decryptions pi,...,pnof the double-encryption of the private cryptocurrency key HE_ENC(Enc(CryptoKeypiajn,EncKey),pk), wherein the combination of an above-threshold number of the n partial homomorphic decryptions pi,...,pngenerates a full homomorphic decryption of the homomorphic encryption of the double-encryption of the private cryptocurrency key to restore the received ciphertext CryptoKeyencthat is the non-homomorphic encryption of the private cryptocurrency key.

12. A remote crypto vault storage system comprising: a network-connected interface for communicating with a client device; a storage comprising one or more memories; a plurality of n distinct storage vault devices; and one or more processors configured to recover a back-up copy of a private cryptocurrency key by: retrieving from the storage a double-encrypted backup of the private cryptocurrency key, requesting from up to n distinct storage vault devices of the remote crypto vault storage system, up to n respective partial homomorphic decryptions pi,...,pnof the double-encrypted backup of the private cryptocurrency key encrypted under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk) decrypted by up to n respective homomorphic private key shares ski,...,skn, combining an above threshold number of the n partial homomorphic decryptions pi,...,pnto generate a full homomorphic decryption of the homomorphic encryption ofthe double-encrypted backup of the private cryptocurrency key to restore the non- homomorphic encryption of the private cryptocurrency key CryptoKeyenc, and transmitting the non-homomorphic encryption of the private cryptocurrency key CryptoKeyenc to a client device storing a non-homomorphic decryption key DecKey configured to decrypt the non-homomorphic encryption of the private cryptocurrency key Dec(CryptoKeyenc,DecKey)=CryptoKeypiain to recover an unencrypted form of the private cryptocurrency key CryptoKeypiainconfigured to control cryptocurrency assets.

13. A client device for generating a back-up copy of a private cryptocurrency key, the client device comprising: a network-connected interface for communicating with a remote crypto vault storage system; a storage comprising one or more memories; and one or more processors configured to recover a back-up copy of a private cryptocurrency key by: receiving from the remote crypto vault storage system a full homomorphic decryption of a homomorphic encryption of a double-encrypted backup of the private cryptocurrency key encrypted under both homomorphic and non-homomorphic encryption HE_ENC(Enc(CryptoKeypiain,EncKey),pk) to restore the non-homomorphic encryption of the private cryptocurrency key CryptoKeyenc, wherein the full homomorphic decryption is generated by combining an above threshold number of n partial homomorphic decryptions pi,...,pnof the double-encrypted backup of the private cryptocurrency key, wherein the n partial homomorphic decryptions pi,...,pnare decrypted by n respective homomorphic private key shares ski,...,sknstored in n distinct storage vault devices of the remote crypto vault storage system, storing, at the storage, a non-homomorphic decryption key DecKey, and non-homomorphically decrypting the non-homomorphic encryption of the private cryptocurrency key with the non-homomorphic decryption key DecKeyDec(CryptoKeyenc,DecKey)=CryptoKeypiain to recover an unencrypted form of the private cryptocurrency key CryptoKeypiain configured to control cryptocurrency assets.

14. The method of claims 10-13, wherein the network-connected interface connects the client device to the remote crypto vault storage system over a cloud service infrastructure.

Images