Attorney Docket: P-637007-PC SECURE AND EFFICIENT SIGNING OF CRYPTOCURRENCY TRANSACTIONS UNDER FULLY HOMOMORPHIC ENCRYPTION CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims the benefit of U.S. Provisional Application No. 63/640,953, filed on May 1, 2024, and entitled “SYSTEM AND METHOD FOR SECURELY SIGNING CRYPTOCURRENCY TRANSACTIONS UTILIZING FULLY HOMOMORPHIC ENCRYPTION”, which is incorporated by reference herein in its entirety. FIELD OF THE INVENTION [0002] Embodiments of the invention relate to securing cryptocurrency using private cryptographic keys. In particular, embodiments of the invention relate to using private cryptographic keys to generate cryptographic signatures of cryptocurrency and their transactions in a computationally efficient manner. BACKGROUND OF THE INVENTION [0003] Cryptographic digital signature schemes utilize public key cryptography algorithms to ensure data integrity. A computer may execute a digital signature algorithm on cryptocurrency using a private cryptocurrency key to verify that the signed cryptocurrency originated from the signing entity in sole or restricted possession of the private cryptocurrency key, and has not been altered after the signature. In cryptographers’ parlance, a first entity, denoted “Alice,” sends a signed message to a second entity, denoted “Bob,” using her private cryptocurrency key, and Bob verifies the message authenticity using Alice’s public cryptocurrency key. [0004] Cryptocurrency is conventionally signed locally at the private cryptocurrency key owner (Alice)’s device to keep the private cryptocurrency key secret (from Bob or a third party). However, local devices are often insecure and targeted by attacks causing system-wide vulnerabilities.. Offloading these operations to specialized or hardware-accelerated systems, however, may be prohibited, as it requires sharing and therefore exposing the private cryptocurrency key. Applying additional encryption layers at the specialized or hardware- accelerated systems will not secure their signing schemes as private cryptocurrency keys may be inadvertently exposed during the signature process–even in cryptographically sophisticated
Attorney Docket: P-637007-PC cryptocurrency wallets. For example, these additional encryption layers typically introduce significant additional intermediate computations generating an accumulation of cryptographic artifacts generated during the signature process, which may be compiled and pattern-recognized to expose those additional encryption layers and keys. [0005] Accordingly, there is a pressing need in the art for robust security measures to ensure that private cryptocurrency keys (such as, those used for signing cryptocurrency transactions) remain securely protected, as their exposure could lead to serious threats including surveillance or data breaches. SUMMARY OF THE INVENTION [0006] In an embodiment of the invention, a system and method is provided for securing and efficiently signing cryptocurrency transactions using fully homomorphic encryption (FHE). A server may be used for: receiving, from a first computer device, a first encryption of a private cryptocurrency key obfuscated by a first layer of encryption. FHE encrypting or proxy re- encrypting may be used to re-encrypt or swap the first encryption of the private cryptocurrency key to generate a second encryption of the private cryptocurrency key obfuscated by a FHE layer, without unencrypting the private cryptocurrency key. The second encryption of the private cryptocurrency key may be transmitted (directly or indirectly) to one or more untrusted third parties (e.g., specialized or hardware-accelerated systems, cloud blockchain networks, or other computationally robust devices) to efficiently generate a cryptographic signature of a cryptocurrency transaction encrypted under the second encryption of the private cryptocurrency key (e.g., the FHE layer). [0007] In some embodiments, the first encryption of the private cryptocurrency key received from the first computer device may not be used in generating the cryptographic signature. [0008] In some embodiments, the server may delete the first encryption of the private cryptocurrency key after the second encryption of the private cryptocurrency key is generated. BRIEF DESCRIPTION OF THE DRAWINGS [0009] Non-limiting examples of embodiments of the disclosure are described below with reference to figures attached hereto. Dimensions of features shown in the figures are chosen for
Attorney Docket: P-637007-PC convenience and clarity of presentation and are not necessarily shown to scale. 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, can be understood by reference to the following detailed description when read with the accompanied drawings. Embodiments are illustrated without limitation in the figures, in which reference numerals may indicate corresponding, analogous, or similar elements, and in which: [0010] Fig. 1 is a high-level block diagram of an example system for secure management of cryptographic keys according to some embodiments of the invention; [0011] Fig.2 shows an example proxy re-encryption process according to some embodiments of the invention; [0012] Fig. 3 shows an example process for generating a cryptographic signature according to some embodiments of the invention; [0013] Fig. 4 shows an example process for homomorphic signing according to some embodiments of the invention; [0014] Fig.5 shows an example system for signing cryptocurrency transactions according to some embodiments of the invention; [0015] Fig. 6 shows an example process for generating a cryptographic signature according to some embodiments of the invention; [0016] Fig. 7 shows an example process for generating a homomorphically encrypted cryptographic signature according to some embodiments of the invention; [0017] Fig.8 schematically illustrates an example system for secret key management according to some embodiments of the invention; [0018] Fig. 9 illustrates example features of fully homomorphic encryption (FHE) according to some embodiments of the invention;
Attorney Docket: P-637007-PC [0019] Fig. 10 schematically illustrates an example system for securely managing cryptographic keys, according to some embodiments of the invention; and [0020] Fig. 11 shows an example process for securing and efficiently signing cryptocurrency transactions using proxy re-encryption according to some embodiments of the invention. [0021] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn accurately or to scale. For example, the dimensions of some of the elements can be exaggerated relative to other elements for clarity, or several physical components can be included in one functional block or element. DETAILED DESCRIPTION OF THE INVENTION [0022] Embodiment of the invention improve security for cryptocurrency signatures by offloading signatures from the cryptocurrency owner’s (Alice’s) to a more secure environment, e.g., to minimize the threat of local compromised devices and more efficient environment, e.g., to improve processing speed. The cryptocurrency owner, however, cannot share its private cryptocurrency key to offload those computations without exposing its private cryptocurrency key or introducing additional security vulnerabilities, for example, under additional encryption layers. Embodiments of the invention reconcile the need for improved signing efficiency while maintaining the secrecy of private cryptocurrency keys essential to secure cryptocurrency signature protocols. According to some embodiments, there is provided a system and method for securely and efficiently signing cryptocurrency transactions. [0023] The cryptocurrency owner (Alice) in sole, restricted or limited possession of the private cryptocurrency key may execute a first encryption of the private cryptocurrency key using a first (public or private) cryptographic key to generate a first-encrypted private cryptocurrency key. The cryptocurrency owner (Alice) may send the first-encrypted private cryptocurrency key to a proxy re-encryption or fully homomorphic encryption (FHE) server. [0024] The server may use proxy re-encryption or FHE to replace, transform or re-encrypt the cryptographic private key from the first encryption to a second encryption using a second (public or private) cryptographic key to generate a second-encrypted private cryptocurrency key under fully homomorphic encryption (FHE). Proxy-re-encryption switches the cryptographic key
Attorney Docket: P-637007-PC without exposing the underlying private cryptocurrency key so its secrecy is not compromised (e.g., as shown in Fig. 1). Fully homomorphic encryption (FHE) can decrypt and re-encrypt all under an encrypted layer to replace encryption keys (e.g., as shown in Figs. 2-3). Accordingly, proxy re-encryption or FHE server may be trusted, semi-trusted, untrusted, or of unknown trust without exposing the private cryptocurrency data. Once re-encrypted (secure) under FHE (operable without any of the cryptographic keys), this second FHE-encrypted private cryptocurrency key is transmitted to a specialized or hardware-accelerated system to efficiently execute the secure cryptocurrency signature protocol. [0025] Such embodiments benefit from both uncompromised security (proxy-re-encryption never exposing the private cryptocurrency key) and improved efficiency of the specialized or hardware- accelerated system to increase the speed of signing cryptocurrency transactions by the secure cryptocurrency signature protocol. The specialized or hardware-accelerated system operates under FHE and so does not expose any keys. In some embodiments, to further obfuscate the cryptocurrency signature protocol, intermediate artifacts accumulated by FHE computations may be reduced by only executing FHE computations on the first or several initial computations, after which standard computations may be used. [0026] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention can be practiced without these specific details. In other instances, well-known methods, procedures, components, modules, units and/or circuits have not been described in detail so as not to obscure the invention. [0027] Fig.1 shows an example system for secure management of cryptographic keys using proxy re-encryption according to some embodiments of the invention. [0028] A system according to some embodiments may include the following, example components: ^ A crypto vault service 10, which may provide a cloud-based storage system for private keys and/or other cryptographic artifacts, and which may be utilizing, e.g., quantum- resistant encryption;
Attorney Docket: P-637007-PC ^ A proxy re-encryption service 20 or, alternatively an FHE server – which may support, e.g., a secure transmission, key switching, and storage of private keys and other cryptographic artifacts, for example by applying FHE techniques to produce twice- encrypted, or FHE encrypted keys; and ^ A user-facing client or platform 30, which may enable an end user to interact with the system. This client may allow the user to send and/or request keys (and/or) other artifacts to/from the crypto vault service 10 and/or from proxy re-encryption service 20. User-facing client or platform 30 may include or may be used to interact with a cryptocurrency wallet – for example in order to participate in cryptocurrency transactions. A cryptocurrency wallet according to some embodiments may be a software or hardware wallet, or a wallet system bridging between or connecting/integrating the two types of wallets. In some embodiments, user-facing client or platform 30 may be executed on a computer device such as for example a sender device, or a “first computing device” signing a message or cryptocurrency using a private key – which may then be validated by a receiver device or “second computing device” using a public key of the sender device. Some embodiments of the invention may perform FHE encryption and/or related operations using an FHE server. In certain embodiments, FHE encryption may be performed not as a proxy re- encryption (by a proxy re-encryption service 20), but as a standalone encryption process – where, for example, data is encrypted directly under a fully homomorphic encryption scheme without relying on additional intermediary keys and/or key transformations. Some processes/operations described herein with reference to a proxy re-encryption server or service 20 may be performed by a FHE independently from any use of proxy re-encryption techniques or severs/services performing proxy re-encryption. Additional or alternative components may be included in different embodiments. [0029] In some embodiments, crypto vault service 10 and proxy re-encryption service 20 may be considered trusted, semi-trusted, untrusted, or of unknown trust, and user-facing client or platform 30 may be considered as the sole trusted execution environment (TEE) – or as the only environment in which an unencrypted private key may be exposed.
Attorney Docket: P-637007-PC [0030] In some embodiments, a user-facing client (such as for example client 30, which may also be referred to as a client management service or platform) may be running on any type of device (e.g., a laptop or desktop PC, a smartphone or other mobile device, or an example computer system such as system 100) with sufficient computational resources (including e.g., processing capability, power supply, etc.). According to some embodiments, the client may interface or be integrated with software and hardware wallets (such as, e.g., a Trezor digital wallet). In some embodiments, the client or platform may encrypt the user’s private cryptocurrency key using encryption methods such as, for example, using AES (Advanced Encryption Standard) and/or RSA (Rivest–Shamir– Adleman) techniques, for example, in order to transfer the key to proxy re-encryption and storage components. [0031] Fig.2 shows an example system for secure management of cryptographic keys using FHE according to some embodiments of the invention. [0032] In some embodiments, cryptographic private key 202 of a user or first computing device may be switched and/or obfuscated by a first layer of encryption. For example, private key 202 may be encrypted (e.g., using a first, fast encryption or cipher 204) to produce a “once-encrypted” private key, or a first encryption of the private key 206. [0033] In some embodiments, the first encryption or cipher 204 may be applied on the user’s- or client’s-side – and for example on the first computing device and/or on a sever or computer system different from the server. One produced, the first encryption of the private key 206 may be transmitted to the server. [0034] A FHE server may receive the first encryption of the private key 206, and may switch and/or re-encrypt the first encryption 206 – for example using FHE 208, by an appropriate FHE encryption key 216. A second encryption of the cryptographic private key 210 (or “twice- encrypted” private key) may be generated, and the private key already obfuscated by a first layer of encryption may accordingly be switched or further obfuscated by a second, fully homomorphic encryption (FHE) layer. The re-encryption process may be performed without unencrypting the cryptographic private key, or without stripping the first layer of encryption (produced, e.g., using fast encryption or cipher 204) from the private key or the first encryption 206 received at the server.
Attorney Docket: P-637007-PC [0035] Fully homomorphic encryption operations 212 may be applied to or performed on the twice-encrypted private key or second encryption of the private key 210 – for example to strip or remove the first layer of encryption, (e.g., fast encryption or cipher 204) in FHE cipherspace. Some embodiments may thus “switch” and/or re-encrypt a cryptographic private key using a single layer of FHE encryption: a “once-FHE-encrypted private key” 214 may switch, be used instead of, or be used as the second encryption of the private key 210. The FHE-encrypted private key may fully replace the private key used prior to FHE encryption (e.g., private key 206 encrypted using a fast cipher), such that encryptions/decryptions performed prior to FHE 208 may never be used after FHE-encrypted private key 214 is produced. [0036] In some embodiments, the second encryption of the private key 210 may be transmitted to third parties – which may include, e.g., untrusted parties, or parties of unknown trust, such as for example server farms or computer systems – to generate a cryptographic signature of a cryptocurrency transaction. [0037] A signing process according to some embodiments may be performed under the second encryption of the cryptographic private key, or under the second encryption layer (which may be achieved, e.g., using FHE encryption 208) by which the private key is obfuscated. Accordingly, private key 210 may not only be protected by a first encryption layer, or by fast encryption or cipher 204 – but by a second encryption layer, or an FHE encryption 208 performed on top of once-encrypted key 206 (encryptions performed prior to FHE 208 may then be stripped from a twice encrypted key 210 to produce FHE-encrypted private key 214, such that FHE 208 “replaces” such preceding encryptions. In other words, some embodiments may “switch” a cryptographic key or encrypted key with an FHE encrypted key). [0038] Nesting encryptions according to some embodiments – such as for example applying a second layer of encryption (e.g., FHE encryption 208) to an already encrypted private key – may improve data and cryptocurrency security and encryption technologies, since each layer of encryption is dependent on the previous layer, unlike two independent encryptions which can be attacked separately. This makes nested or layered encryption more resistant to compromise. [0039] In some embodiments, the once-encrypted key, or first encryption of the cryptographic private key 206, may be deleted from the server after an FHE encrypted key, or second encryption
Attorney Docket: P-637007-PC of the cryptographic private key 210, is generated. This may further prevent exposure of the private key or first encryption layer to adversaries – which may result, for example, from attacks on, or information leaks from, the server. [0040] Fig. 3 shows an example process for generating a cryptographic signature according to some embodiments of the invention. [0041] Some embodiments may use an FHE encrypted private key 302 (of a sender entity “Alice”, sending a message to receiver entity “Bob”) and an FHE encrypted public key 304 (sent by Alice to a Bob for verifying the message sent by Alice) for signing messages or cryptocurrency transactions. In some embodiments, the first encryption of the private key 206, or a private key once-encrypted using, e.g., a first, fast encryption or cipher 204, may not be used to generate the cryptographic signature. A sender (e.g., Alice, or the first computing device, owning private key 302) may use an FHE encrypted private key 214 to derive FHE encrypted public key 304. FHE encrypted public key 304 may be transmitted to a receiver (e.g., Bob, or a second computing device receiving a message or cryptocurrency signed using FHE encrypted private key 302 of Alice) – which may validate Alice’s signature using FHE encrypted public key 304, without ever being exposed to the first encryption of the private key 206. [0042] A cryptographic signature according to some embodiments may thus be generated in FHE cipherspace 306; An FHE encrypted cryptographic signature 308 (which may be, e.g., a cryptographic signature encrypted under the second encryption 214 of the private key obfuscated by the FHE layer 208) may then be FHE decrypted 316 (for example at the server) using an appropriate FHE decryption key 318 to produce a decrypted digital signature 320. The decrypted signature 320 may then be submitted to the relevant cryptocurrency or blockchain network, server farm, or cloud 322, e.g., to validate a cryptocurrency transaction. [0043] Some embodiments of the invention may provide a system for securely managing, storing, and recovering cryptographic artifacts (such as, e.g., private cryptographic or cryptocurrency keys) by enabling on-device cryptographic signatures (such as, e.g., the Elliptic Curve Digital Signature Algorithm (ECDSA)) via a homomorphically encrypted signature algorithm. Some embodiments may be used for securely managing/storing/recovering private keys for signing cryptocurrency transactions. This may be particularly useful, for example, in cryptocurrency transactions where
Attorney Docket: P-637007-PC private cryptocurrency keys are used for transaction signatures, but where those keys may be inadvertently exposed during the signature process (which may constitute a risk, for example, even in cryptographically sophisticated cryptocurrency wallets). [0044] In a nonlimiting example elliptic curve according to some embodiments, a curve may be defined by equation 1: (eq.1) y2 = x3 + ax + b (mod p) Where: ^ a, b are constants which define the slope and properties of the curve. ^ p is a prime modulus which defines the finite field over which the elliptic curve exists. In addition, and as referred to herein: • G is the elliptic curve’s generator point (x, y) on the curve which is used to generate all other points on the curve. • n is the order of the subgroup–that is, the number of points until the generator generates itself. This point defines the number of possible private keys and can be automatically found, for example, using Shoof’s Algorithm or similar algorithms. Eq. 1 may be represented, e.g., using a Weierstrass form, such as for example used in the secp256k1 standard for the ECDSA for Bitcoin, Ethereum, and other cryptocurrencies. Additional or alternative representations for elliptic curves may be used in different embodiments. [0045] A digital signature algorithm may be used to authenticate the integrity of signed data, as well as the identity of the signer, and may ensure that the signed data has not been tampered with. At a high level, elements for the ECDSA may include, e.g.: • z = hash(m) (mod n), or a SHA-256 hash of a message m which has been trimmed to the size of n. • Pick an ephemeral key (a random nonce) k such that 1 < k < n - 1. • Calculate kG = (x, y) where G may be, e.g., the subgroup generator for the secp256k1 standard. Note that scalar multiplication kG is calculated using mod p. • Find a value r = x (mod n). If r = 0, then pick a new nonce value k.
Attorney Docket: P-637007-PC • Calculate s = k-1 · (z + r · sk) (mod n) where sk is the signer’s private key and k-1 is the modular inverse of k such that k · k-1 = 1 (mod n). If s = 0 then choose new nonce value k. • The ordered pair (r, s) may be used as the signature. Additional or alternative operations may be used in different embodiments. [0046] Finite field operations may be performed, e.g., as part of the ECDSA according to some embodiments of the invention. For example, modular reduction must be used constantly during the signature process, e.g., because operations take place over a finite field. All operations and values must undergo modular reduction by p or n. [0047] Example modular addition and multiplication operations according to some embodiments may include: ^ Modular inversion of a number x, x-1 such that x-1 is the multiplicative inverse of x (mod n), and thus x · x-1 = 1 (mod n). ^ Some embodiments may use affine coordinate representations (x, y). However, different representations may be used in different embodiments. For example, a Projective Jacobian which includes a z component with coordinates presented as (x, y, z). A Jacobian triple (x, y, z) represents affine points (x/z2 , y/z3 ) and affine points represent the Jacobian triple as (x, y, 1).
^ Group addition, or adding points to the elliptic curve, may be calculated and/or visualized as drawing a secant line through two points, finding the third intersection on the curve, and reflecting it about the x-axis. Point calculations for point addition using affine coordinates may be performed by calculating the gradient λ between two points (x1, y1) and (x2, y2) such that λ = ((y1 – y2)/(x1 – x2))(mod p). The coordinates for a final point (x3, y3) may be calculated according to eq.2: (eq.2) – x3 = λ2 - x1 - x2 – y3 = λ · (x1 - x2) - y1
refer to adding a point to itself, and may be calculated and/or visualized as using a tangent, rather than secant, line.
Attorney Docket: P-637007-PC ^ Group scalar multiplication operations may take a scalar value k with a generator point G to compute points in the group. Some embodiments of the invention may utilize, e.g., a pre-computed look up table including computed points. Additional or alternative modular operations may be used in different embodiments. In some embodiments, various elliptic curve based transformations, and/or additional or alternative operations or protocols, may be performed or executed on FHE-encrypted or reencrypted keys – namely, performed in FHE cipherspace. [0048] A nonlimiting example workflow for a cryptographic signature process according to some embodiments of the invention may include some or all of the operations provided in Table 1: Workflow – Signature Process Components: • Cryptocurrency Wallet – Stores private key, generates transactions • trusted execution environment (TEE) – Generates ephemeral key, performs EC operations, encrypts values • CPU/GPU – Performs homomorphic modular arithmetic for signature computation • TEE or External System – Decrypts signature (r, s) for blockchain verification 1 Setup Phase (One-time Initialization) 1.1 Wallet-Based Private Key Setup • The private key or secret key sk is stored within the cryptocurrency wallet, which can be either a software or hardware wallet. • The corresponding public key pk = sk · G is computed and stored on-chain or in the wallet. • Define the elliptic curve parameters: Generator point G, Curve order p, Subgroup order n. 1.2 Homomorphic Encryption Key Setup
Attorney Docket: P-637007-PC • Generate FHE keys for a modular arithmetic scheme (e.g., using the Brakerski- Gentry-Vaikuntanathan (BGV), or Brakerski-Fan-Vercauteren (BFV) cryptographic frameworks): – Private key skFHE remains inside the TEE. – Public key pkFHE (or pk) is exported for encrypting inputs. – Evaluation key evkFHE is exported for CPU/GPU computation. 2 Message Preparation and Homomorphic Input Encryption 2.1 Precompute Values in the TEE • Generate the ephemeral key (or nonce) k securely inside the TEE. • Compute the EC multiplication: (x, y) = k · G. • Compute the modular inverse of k (mod n): k-1 (mod n). • Compute r = x (mod n). 2.2 Homomorphically Encrypt Signature Inputs Encrypt the following values homomorphically (modular arithmetic FHE, e.g., BGV) before exporting them: • Private key sk → ENC(sk) • Ephemeral key inverse k-1 → ENC(k-1) • Signature component
• Hash of message z → ENC(z) These encrypted values are sent to the CPU/GPU for homomorphic computation. Some embodiments may keep the ephemeral key inverse k-1, signature component r, or message hash z in plaintext, with the signature computed using plaintext-on-ciphertext computation. 3 Homomorphic ECDSA Signature Computation (using, e.g., CPU/GPU using Modular Arithmetic FHE) 3.1 Compute s Homomorphically
Attorney Docket: P-637007-PC Perform the homomorphic modular arithmetic computations using a modular arithmetic FHE scheme (e.g., BGV, BFV, etc.): • Compute the intermediate value: ENC(z + r · sk) = ENC(z) + ENC(r) · ENC(sk) (mod q) • Using plaintext-on-ciphertext operations, the intermediate value may be computed: ENC(z + r · sk) = z + r · ENC(sk) (mod q) • Compute s using homomorphic multiplication and modular reduction: ENC(s) = ENC(k-1) · ENC(z + r · sk) (mod q) • Using plaintext-on-ciphertext operations, the value s would be computed: ENC(s) = k-1 · ENC(z + r · sk) (mod q)
e.g., based on Boolean circuit-based FHE, this approach directly operates over modular arithmetic, significantly improving efficiency. 4 Post-processing and Decryption 4.1 Export Homomorphic Signature (r, s) The encrypted signature (r, s) may be decrypted (e.g., at the TEE or the client-device), and the decrypted signature (r, s) is sent out for verification. 4.2 Signature Verification • The final ECDSA signature (r, s) is verified against the public key pk in plaintext. • The transaction is broadcasted to the blockchain if valid. Table 1. Additional or alternative operations may be used in a cryptographic signature process according to different embodiments. [0049] In some embodiments, cryptocurrency transactions may be signed using a wallet extension that enables a Homomorphically Encrypted Elliptic Curve Digital Signature Algorithm (HEECDSA) to be run. This may provide added assurance that the private key used for the transaction signature will not be exposed, a risk even with cryptographically sophisticated wallets.
Attorney Docket: P-637007-PC This approach may provide an additional layer of security for dissidents utilizing cryptocurrency to avoid private information being compromised (e.g., by adversaries such as, e.g., oppressive regimes). [0050] Some embodiments of the invention may use operations and protocols from PCT application PCT/US24/41213, filed on August 7, 2024, and entitled “SECRET KEY BACK-UP AND RECOVERY USING MULTIPLE CONCURRENT ENCRYPTION TECHNIQUES” which is incorporated by reference herein in its entirety. [0051] A secure cryptographic signing and/or management process or workflow according to some embodiments may include, for example, a plurality of distinct phases, processes, or subprocesses: (i) a Key Backup Phase, (ii) a Homomorphically Signed Transaction Phase, and (iii) a Key Recovery Phase (although other operations or phases may be used in different embodiments). [0052] According to some embodiments, as part of an example key backup process, the proxy re- encryption server may receive a once-encrypted private key, or a first encryption of a private key 206 from a client device (or first computer device). The proxy re-encryption server may then apply a further layer of encryption to the once-encrypted key, or further proxy re-encrypt the already encrypted cryptographic private key. In some embodiments, the private key may thus be obfuscated by a third layer of encryption (or by an encryption layer different from, e.g., the first encryption layer generated on the client’s device or first computer system, and/or the FHE encryption layer generated by the proxy re-encryption server) to generate a backup of the cryptographic private key without unencrypting the cryptographic private key. [0053] According to an example notation used for some nonlimiting examples herein, (<IDuser, EncKey, DecKey>) may refer to a tuple containing a user's identifier, as well as encryption/decryption keys; CryptoKeyenc = ENC(EncKey, Cryptokeyplain) may represent a first or “fast” encryption of, e.g., a plaintext cryptographic key using the key EncKey; ProxENCpub and ProxENCpriv may refer to proxy-encryption-generated public and private encryption keys, respectively (where the proxy encryption is different from the first or “fast” encryption); and DEC(ProxENCpriv, <CryptoKeyenc, EncKey>) may represent a decryption operation performed using the proxy-encryption-generated private key to recover the first encryption of a cryptographic key.
Attorney Docket: P-637007-PC [0054] A nonlimiting example Key Backup Phase process or phase is described in Table 2: • (In some embodiments the Key Backup Phase may be initiated by an end user requesting, e.g., to send a private cryptocurrency key to the vault for backup.) Upon first using the system, a user may submit identity information and may send a request to a Client Management Engine (which may be, e.g., a software module or component executing on client device or on a computer device interacting with a digital wallet) to generate a cryptographic key. The Client Management Engine may request a Crypto Key Manager to generate a key according to the client-side encryption (e.g., an AES key)(<IDuser,EncKey,DecKey>). (in some embodiments using symmetric cryptographic protocols, e.g., AES, EncKey and DecKey are the same.) • The Client Management Engine may encrypt CryptoKeyplain with a client-side encryption algorithm to produce a ciphertext CryptoKeyenc = ENC(EncKey, Cryptokeyplain). • The Client Management Engine may send a request to the Proxy Re-encryption Service to transmit the private cryptocurrency key(s) for backup. • The Proxy Re-encryption Service may generate a private asymmetric encryption key (“ProxENCpriv”) and a public asymmetric encryption key (“ProxENCpub”) and may send the generated encryption keys to the client. • The Client may encrypt the tuple <CryptoKeyplain, EncKey> using ProxENCpub, or the encryption generated by the proxy re-encryption server – to produce the ciphertext ENC(ProxENCpub,<CryptoKeyenc, EncKey>). • The Client may send or transmit (IDuser, ENC(ProxENCpub, <CryptoKeyenc, EncKey>)) to the Proxy Re-encryption service. • The Proxy Re-encryption service may receive (IDuser, ENC(ProxENCpub, <CryptoKeyenc, EncKey>)) from the client, and may run the decryption algorithm DEC(ProxENCpriv, <CryptoKeyenc, EncKey>)) to get the tuple <CryptoKeyenc, EncKey>.
Attorney Docket: P-637007-PC • The Proxy Re-encryption service may send or transmit <IDuser, CryptoKeyenc> to a remote Crypto Vault Service or storage system for backup. • The Proxy Re-encryption service may run or execute a simultaneous decryption-re- encryption algorithm which may decrypt CryptoKeyenc into CryptoKeyplain, and may homomorphically encrypt CryptoKeyplain into CryptoKeyFHE. • The Proxy Re-encryption service may send or transmit CryptoKeyFHE to the client or Client Management Engine or platform; the client engine/platform may use the homomorphically encrypted key for transaction signatures. • The Proxy Re-encryption service may clear all cache, maintaining no record of cryptographic artifacts used in the various steps of this process. Table 2. Additional or alternative steps or operations may be included in key backup processes according to different embodiments. [0055] Fig. 4 shows an example process for homomorphic signing according to some embodiments of the invention. [0056] A nonlimiting example process, subprocess or phase for homomorphically signing a transaction is described in Table 3: 1. According to some embodiments, a user may initiate a cryptocurrency transaction 402 with their wallet, connecting a hardware wallet if/when prompted to do so 404. 2. The Client Management Engine may recognize that the wallet is connected or attached and that a transaction has been initiated 406. 3. The Client Management Engine, interfacing with the attached wallet, may confirm with the user that the transaction is authorized 408. 3.1. If the user aborts, or otherwise fails to confirm the transaction 410, then the transaction may be canceled 412.
Attorney Docket: P-637007-PC 4. Once the transaction has been confirmed 414, the Client Management Engine may use or may invoke FHE software or module or to confirm or verify the private key with the wallet 416 (e.g., in an offline process), and the FHE software or module may sign and broadcast/transmit the transaction 418 with the FHE key or CryptoKeyFHE. Table 3. Additional or alternative steps or operations may be included in a homomorphic signing process according to different embodiments. [0057] Fig.5 shows an example system for signing cryptocurrency transactions according to some embodiments of the invention. [0058] Client or computer system 502 may be used or operated by a cryptocurrency user or owner. A hardware wallet or cryptowallet 504 (which may be or may include, e.g., a hardware storage device, disk, and the like) may be physically connected to computer 502, for example using a USB cable 506. According to some embodiments, a dedicated FHE signing extension or module 508 may interact with a firmware element 510 to control secure element 512 which may protect a private or secret key 514 inside cryptowallet wallet 504. In some embodiments, FHE signing extension 508 may perform or execute the various operations, protocols, and procedures described herein, and may sign and broadcast a cryptocurrency transaction to a relevant blockchain server 516, server farm, and the like. [0059] Fig. 6 shows an example process for generating a cryptographic signature according to some embodiments of the invention. [0060] Private key 602 may be associated with a cryptocurrency sender or owner and may be used to generate a digital signature that authorizes a cryptocurrency transaction. Public key 604 may be associated with a recipient or receiving party and may serve as the destination address for the transaction. In some embodiments, public key 604 may be known or provided to the sender to validate the transaction and facilitate the generation of the corresponding digital signature using private key 606. The transaction signature 608 may be computed using private key 602 and public key 604, and the resulting signature 608 may then be broadcasted or transmitted to a blockchain
Attorney Docket: P-637007-PC network 610, a server, a server farm, or similar computing infrastructure for verification and inclusion, e.g., in a distributed ledger. [0061] Fig. 7 shows an example process for generating a homomorphically encrypted cryptographic signature according to some embodiments of the invention. [0062] In some embodiments, elliptic curve operations (being computationally demanding in FHE and so improved by execution on plaintext in TEE) may be performed in a TEE 702, e.g., on a client device. For instance, a private key or number 704 may be encrypted using elliptic curve techniques 706, resulting in an encrypted key or different number 708. Homomorphic encryption 710 or FHE operations may be performed or executed on the encrypted key 708, for example, using a proxy reencryption server, and a FHE encrypted key (such as for example twice-encrypted key 210) may be returned to TEE 702. FHE encrypted key may then be used by the client or TEE to generate a cryptographic signature (e.g., according to the process illustrated in Fig. 3) and/or perform additional operations in FHE cipherspace 712. A signature or artifact 714 produced in FHE cipherspace may then be FHE-decrypted using a decryption key generated as part of the FHE encryption process, e.g., by the proxy reencryption server. [0063] Some embodiments of the invention may perform secret key backup and recovery processes, for example using multiple concurrent encryption techniques. Some embodiments may provide a device, system and method for secure transmission, storage and retrieval of sensitive information. Some embodiments may provide private keys and/other information for cryptocurrency wallets. This capability may be referred to as ‘key back-up and recovery’ (KBR), and may include an ability to securely store private cryptocurrency keys in a cloud-based infrastructure, for example, utilizing encryption technologies (such as, e.g., Advanced Encryption Standard (AES)), along with lattice-based threshold fully homomorphic encryption (FHE). Additional or alternative encryption techniques may be used in different embodiments. [0064] According to some embodiments, a private key may be or may refer to a secret data object or item, such as for example a number or code that allows a user to access and control their cryptocurrency. It may be generated, for example, by a cryptocurrency wallet and is meant to be kept secret. A private key may be used to sign transactions, and it is to be kept secure as anyone (e.g., an adversary) who has access to it may move or spend the associated cryptocurrency.
Attorney Docket: P-637007-PC [0065] A public key according to some embodiments may be or may refer to a code that may be derived from the private key and that may be used to receive cryptocurrency transactions. It may be shared publicly (e.g., among entities or parties different from the owner of the cryptocurrency), and may be used to generate a given user's (e.g., the owner) cryptocurrency wallet address. The wallet address may be, for example, a string of characters that may identify the user's wallet on the blockchain network, allowing other users to send cryptocurrency to that wallet. [0066] According to some embodiments, a cryptocurrency wallet address may be, for example, a public key that may be generated from the user's private key. When a cryptocurrency is to be sent to a user's wallet, the wallet address may be used. In some embodiments, the wallet address may be e.g., a hash of the user's public key. A sender's cryptocurrency may then be sent, transmitted, or transferred to that address on the blockchain network, and the wallet owner or user may then access the received cryptocurrency using their private key. [0067] Maintaining and securing keys may be essential to holding and controlling cryptocurrencies and other 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 may have access to that cryptocurrency asset. Whether a private owner/holder, an institutional one, or a government/law enforcement agency, the ability to securely store and recover private keys may be critical for maintaining the privacy and security of cryptocurrencies and crypto assets. [0068] Some protocols and procedures to securely store cryptocurrency keys according to some embodiments include, for example: ^ Paper wallet: a paper wallet may be a printed copy of your public and private keys kept in a secure location. ^ Hardware wallet: a hardware wallet may be a physical device (e.g., a storage or memory unit) storing cryptocurrency keys offline. Hardware wallets may represent safer options for storing cryptocurrency keys, as they may be disconnected from communication networks such as, e.g., the internet, and therefore are less vulnerable to hacking. ^ Software wallet: a software wallet may be a software program installed on a computer or mobile device. Software wallets may be or may include “hot wallets” (which may be
Attorney Docket: P-637007-PC connected to the internet) or cold wallets (which may be kept offline). Cold wallets may accordingly be safer options than hot wallets. ^ Multisignature wallet: a multisignature wallet may require multiple parties to sign off on a transaction before it can be completed. This may add an extra layer of security as it prevents any single party from having complete control over the funds. ^ Key splitting: key splitting may involve breaking up a private key into multiple pieces or shares, and storing them in different locations. This may make it more difficult for anyone (e.g., an adversary) to steal cryptocurrencies or crypto assets, as they may need to access all the different locations where key fragments are stored. This may include, e.g., wallets using multi-party computation (MPC) schemes. Additional or alternative techniques for storing cryptocurrency keys may be used in different embodiments. [0069] Some embodiments may include storing private keys in securely held physical storage. Nonlimiting examples may include, for example, storing private keys on air-gapped computer hardware that may themselves be stored in secluded geographic locations (e.g., as done by Xapo virtual asset bank); sharing private keys via a secret sharing protocol and storing those shards in air-gapped computer hardware in separate secure locations (as done by, e.g., virtual asset banks such as CoinCover, Nemean). However, maintaining secure physical storage facilities may prove undesirably expensive. Moreover, techniques utilizing threshold signature or key splitting schemes may be vulnerable to key composition attacks, where keys may be exposed after recomposition or decryption. [0070] Some embodiments of the invention may provide additional features and capabilities to overcome or mitigate limitations of such techniques. [0071] Some embodiments may provide a device, system and method for a cloud-based key backup and recovery (KBR) solution that may utilize multiple forms of encryption, which enables the secure storage of private keys, along with key recovery that may be compatible with commercially available cloud service infrastructure (such as for example the Amazon Web Services or Microsoft Azure environments). This ‘double encryption’ may provide, according to
Attorney Docket: P-637007-PC some embodiment, a backup solution that may not expose unencrypted private keys in the clear; only the client-facing component may have the ability to see plaintext keys. The ability to securely backup and recover private cryptocurrency keys in a way compatible commercial cloud service infrastructure, rather than, e.g., by using air-gapped infrastructure housed in remote physical facilities, presents considerable accessibility, efficiency and cost saving benefits and improvements to cryptocurrency technology provided by some embodiments of the invention. [0072] Reference is made to Fig.8, which schematically illustrates am example system for secret key management according to some embodiments of the invention. [0073] According to some embodiments, the system may have a standard Client-Server architecture comprising an end user-facing frontend, the Client Management Service 802, and a backend Crypto Vault Service 804 – each including a plurality of specialized components or modules for performing different tasks or functions. [0074] A user-facing Client Management Service (CMS) 802 may provide an interface to the system, including client management, a graphical user interface 806, and/or a cryptography engine service 808. The CMS 802 may provide a system for the user to submit their wallet address(es), public, and/or private cryptocurrency keys for storage. Private cryptocurrency keys uploaded through the CMS 802 may be immediately encrypted using an encryption algorithm, such as, for example, the data-at-rest encryption algorithm (e.g., AES-256). The CMS 802 may interface with the Crypto Vault Service 804 to send cryptocurrency wallet address(es), public cryptocurrency key(s), and/or private cryptocurrency key(s) to the Crypto Vault Service 804. Once the Crypto Vault Service 804 receives the transferred data, a confirmation may be sent to the CMS 802, and then the CMS 802 may for example erase all caches where the cryptocurrency key information had been previously recorded. [0075] According to some embodiments, the CMS 802 may include a plurality of components such as for example: ^ Client Management Engine 810 may coordinate all client-side operations, including e.g., standard encryption/decryption operations, communication between the client and the Crypto Vault Service 804, and/or client identity management.
Attorney Docket: P-637007-PC ^ Client API 812 may define all services available through the CMS. ^ Client Management Graphical User Interface (GUI) 806 may provide a user-friendly interface for the end user to interact with the system. ^ CMS 802 may also include a recovery function within its API that enables the end user to recover keys from the Crypto Vault Service 804. This recovery function may verify the identity of the requesting end user to ensure that the request is legitimate. The criteria for identity validation for recovery functions may be situation dependent (e.g., the verification requirements may be different for law enforcement agents custodying crypto keys for an investigation, rather than a private user/owner using this service to store their crypto keys). Identity validation 814 may be performed according to known available validation services. [0076] Crypto Vault Service (CVS) 804 may provide mechanisms for a cloud-based service that securely stores the cryptocurrency wallet and key information that was transferred from the CMS 802, along with or using homomorphic encryption operations. According to some embodiments, the already encrypted private key may be doubly-encrypted, e.g., using lattice-based FHE; specifically, a multi-party variant that may be referred to as Threshold Fully Homomorphic Encryption (TFHE) may be used in some embodiments. TFHE may be or may include an asymmetric encryption protocol where there is a public key pk and n secret share keys sk0, sk1, ..., skn-1. A secret key ski may be used to compute a partial decryption pi, and a set of partial decryptions {p}i∈S for a set of parties S in an access structure A may be used to compute a complete decryption. [0077] According to some embodiments, the CVS 804 may include a plurality of components such as for example: ^ Receiver and Threshold Encryption Server 816 may for example handle all back end operations, except for the actual storage of Secret Share Keys: ^ Cloud Storage Engine 818 may for example coordinate all operations within the CVS 804. This includes, e.g., receiving encrypted cryptocurrency keys from the CMS 802, validating
Attorney Docket: P-637007-PC the identity of the requesting party sent via the CMS 802, triggering TFHE operations, and/or sending and receiving/storing public keys and/or Secret Share Keys from vaults 820. ^ An Identity Validation component 822 may verify the identity of the requesting party sent via the CMS. ^ The TFHE Key Manager 824, Public Key Store 826, and Secret Shared Key Store 828 may handle all TFHE operations. ^ Vaults 820 may be, for example, distinct servers (e.g., one or more server(s) 110 of Fig. 10) which may, e.g., be located in different geographic locations (e.g., data centers). They may receive and hold Secret Share Keys until the keys are requested, e.g., by the Receiver and/or Threshold Encryption Server. Additional or alternative components may be included or used in a system for secret key back-up and recovery according to different embodiments of the invention. [0078] An example key recovery processes according to some embodiments may include a plurality of operations such as for example described in Table 4. An Example Key Recovery Process: ^ A user may submit a recovery request <RequestCryptoKey> to Client Management Engine 810. The user may sufficiently verify their identity to match the Identity Management module 814 and produce a User Identity Token <IDrequest>. ^ Client Management Engine 810 may send (<IDrequest, RequestCryptoKey>) to the Cloud Storage Engine 818. ^ Cloud Storage Engine 818 may call the Identity Validation module 822 to validate IDrequest to ensure that RequestCryptoKey is authorized. (A possible example validation condition may be, e.g., if HammingDistance(IDuser, IDRequest)=0 then the request is authorized.)
Attorney Docket: P-637007-PC ^ Cloud Storage Engine 818 may request partial decryptions pi from each respective Vaulti 820 for a complete decryption, e.g., TFHE_DEC({p1,...,pi }, TFHE_ENC(pk, <IDdata, CryptoKeyenc>)) = CryptoKeyenc. ^ Cloud Storage Engine 818 may send CryptoKeyenc to Client Management Service 802. ^ Client Management Engine 810 may request the decryption key DecKey from Crypto Key Manager 830. (If the client is using symmetric encryption, then the client-side encryption and decryption keys may be the same, or identical keys.) ^ Client Management Engine 810 may queue a Crypto Processing Engine 832 to decrypt CryptoKeyenc to get a plaintext via a decryption function DEC(DecKey, CryptoKeyenc) = CryptoKeyplain. Table 4. Additional or alternative operations, performed by different components, may be included in different key backup and recovery processes according to different embodiments. [0079] Some embodiments of the invention may be used in cases unlimited to cryptocurrency key backup. For instance, some embodiments may be used for private key backup in public key infrastructures (PKIs). Different embodiments may be applied to additional or alternative use cases. [0080] Some embodiments of the invention may apply multiple layers of encryption to secure cryptographic keys, which may include, e.g., nesting computationally costly fully homomorphic encryptions (which may, as a practical matter, be executed only on dedicated or specialized servers within realistic time periods) on top of computationally less-costly encryptions or fast ciphers (which may be executed, e.g., on non-specialized hardware systems such as for example personal computers or client systems). [0081] Users, owners, entities, clients, or parties as used herein may be or may refer to computer systems or platforms performing exchanges of computerized data (which may be or may include,
Attorney Docket: P-637007-PC for example, personal computer systems lacking specialized hardware designed for high- performance computing). [0082] A server or server farm as used herein may refer to a computer system or a collection of interconnected systems with computing capabilities far exceeding that of user or client devices (which may be, e.g., personal computers). Servers and server farms may be designed to handle high-volume processing tasks, large-scale data storage, and intensive computational operations, and may include specialized hardware such as multi-core processors, large memory banks, dedicated GPUs, and high-speed network interfaces, enabling them to efficiently perform complex computerized encryption tasks that would be impractical or inefficient to execute on less capable client devices. [0083] Computerized parties or entities such as client devices, servers, proxies, crypto vaults or storage providers, and more, may be categorized as untrusted, semi-trusted, or of unknown trust according to the level of confidence in their behavior and access to sensitive data. An untrusted third party may be or may refer to an adversary assumed to potentially act maliciously, attempting to access, alter, or leak data, and must not be given any opportunity to view plaintext or sensitive keys. A semi-trusted (or “honest-but-curious”) party may be expected to follow protocols correctly but may still attempt to learn private or confidential information if possible. Entities of unknown trust may have an uncertain or unverifiable security posture, which may require cautious design assumptions. [0084] Some nonlimiting example descriptions of technical terms used herein is provided in Table 5: Homomorphism: a homomorphism as used herein may be or may refer to 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,y∊A, and an operation ⋅, then F(x⋅y) = F(x)⋅F(y) may define a homomorphism. Fully Homomorphic Encryption: homomorphic encryption (HE) may refer to a class of cryptographic primitives which allow for computation on encrypted data, e.g., as shown in Fig. 9 – which is a schematic illustration of an example encryption process according to
Attorney Docket: P-637007-PC some embodiments of the invention. ‘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. Table 5. [0085] Some advanced cryptographic techniques, such as for example, Fully Homomorphic Encryption (FHE) may allow computations to be performed directly on encrypted data without requiring decryption. This means that data can remain confidential while still being processed, which may enable providing sensitive data or information to be processed even in untrusted or semi-trusted environments (such as, e.g., general purpose cloud servers and platform). The results of processing or computations performed on FHE encrypted data – once decrypted by the data owner – may match exactly what would have been obtained had the operations been performed on the original data prior to FHE encryption. FHE may support arbitrary computations, or perform processing operations on sensitive data, making it uniquely powerful for privacy-preserving applications such as secure data analysis, encrypted search, confidential machine learning, and more. [0086] FHE includes complex mathematical operations on ciphertexts, requires significant processing time and memory usage compared to alternative encryption techniques (involving, e.g., operations on plaintext). Executing FHE operations, or other tasks involving computationally intensive encryption techniques, on client devices may be prohibitively slow or resource- demanding, rendering the use of FHE impractical for many cryptographic applications. Offloading FHE encryption/decryptions and associated computations to a proxy server according to some embodiments of the invention may thus spare heavy workloads from the client devices (e.g., from key owners or message senders), enabling practical use of FHE in real-world applications without compromising data privacy. Some embodiments of the invention may improve data security and encryption technology by offloading the computationally intensive FHE encryption and computation tasks to a dedicated server (also referred to as proxy server, or proxy re-encryption
Attorney Docket: P-637007-PC server), thereby enabling practical deployment of FHE while preserving privacy and reducing the burden on client devices. [0087] Fig. 9 illustrates example features of fully homomorphic encryption (FHE) according to some embodiments of the invention. [0088] As used herein, an encrypted space such as, e.g., FHE space may refer to the domain, field, set of numbers, and the like, in which encrypted data (e.g., ciphertexts) exists and may be manipulated—supporting operations like addition or multiplication without revealing the underlying, pre-encrypted data (e.g., plaintext). The pre-encrypted or unencrypted space (e.g., plaintext space) may refer to the domain, field, set of numbers, and the like, where data exists in its original, readable form, and where final results may be revealed after decryption. In some embodiments, the encrypted space and the unencrypted space may be orthogonal, such that no data point or number is included in both encrypted unencrypted spaces. [0089] Inputs or data points x1, …, xi 902 may be FHE encrypted 904 and then processed in FHE space through a series of operations 906 —such as addition, subtraction, or multiplication— applied to the encrypted data. These operations may be applied or computed without ever decrypting the data, preserving its confidentiality throughout the process. A processed, encrypted data point may then be decrypted 908 to yield an output Y 910 – which may be a data point or number in the unencrypted space, or in the domain or space of x1, …, xi. This illustrates the features and principles of FHE which enable secure, privacy-preserving computation on encrypted data, even in untrusted environments. [0090] Some embodiments of the invention may perform “fast”, or computationally less-costly encryption/decryption operations on client devices (e.g., sender/receiver devices) or within trusted execution environments (TEEs). “Slow”, or computationally costly encryption/decryption operations (which may, e.g., prove formidable for client devices) – such as for example FHE encryption and decryption – may be performed by a dedicated proxy re-encryption or FHE server, and not by client devices (such as for example the sender/receiver). In such manner, the computational burden associated with computationally costly encryptions/decryptions may be fully offloaded from the client devices, and the client devices may be fully agnostic to these
Attorney Docket: P-637007-PC operations. Some embodiments of the invention may therefore generate FHE-based cryptographic signature in a computationally efficient manner. [0091] According to some embodiments, a proxy re-encryption service according to some embodiments (executed, e.g., by proxy re-encryption server 20) may receive an already encrypted private cryptocurrency key, or other encrypted artifacts, from the client or platform – and may re- encrypt it, for example, using lattice-based fully homomorphic encryption for transfer back to the client, and then to transfer the twice-encrypted, or the second encryption of the private cryptocurrency key to the crypto vault service. Once the re-encryption and transfer have been completed, the proxy-re-encryption service may delete the cache and keep no memory of the process. [0092] While some embodiments of the invention may include applying FHE by a proxy re- encryption server, different encryption techniques (which may be, e.g., computationally too costly to perform using client devices) may be used in different embodiments. [0093] Cryptocurrency transactions as used herein may be or may refer to exchanges of computerized data between a plurality of nodes or parties (e.g., sender computing device(s) and receiver computing device(s)) using a cryptocurrency network. Nonlimiting example cryptocurrency transactions according to some embodiments include the transfer of digital cryptocurrency tokens, cryptographic messages or cryptocurrency coins, such as, from one wallet address to another, the execution of smart contracts, staking or delegation activities, or the recording of cryptocurrency transaction metadata on a blockchain or other ledger. Cryptocurrency transactions or exchanges of data may involve various types of cryptocurrency protocols and infrastructures, including but not limited to Bitcoin, Ethereum, or other blockchain-based systems that utilize consensus mechanisms such as proof-of-work or proof-of-stake. The data exchanged may also include cryptographic proofs, digital signatures, transaction timestamps, or other verification elements necessary to validate and record the transaction securely within a decentralized cryptocurrency network. Additional or alternative cryptocurrency transactions may be used in different embodiments. [0094] A cryptocurrency network may be or may include, e.g., a decentralized peer-to-peer network that utilizes cryptocurrency technology (such as for example blockchain technology) to
Attorney Docket: P-637007-PC enable secure communication and data storage. In a cryptocurrency system or network according to some embodiments, transactions and data may for example be grouped into blocks – which may, for example, be cryptographically linked together to form a continuous chain. Through various consensus mechanisms, such as for example proof of work and/or proof of stake, agreement regarding the state of the blockchain ledger may be achieved across all network nodes, users, or parties. This decentralized architecture may ensure immutability, transparency, and security, as transactions or exchanges of data may be immutable once confirmed, visible to all participants (referred to herein as “users”, “owners”, “entities”, “clients”, or “parties”), and secured using cryptographic techniques. [0095] Example cryptocurrency networks according to some embodiments of the invention may be implemented using one or more computers, servers, or server farms, and through various methods or combination of methods, including but not limited to, e.g., building/coding from scratch and/or forking existing cryptocurrencies and/or using cryptocurrency development platforms and/or deploying private or consortium blockchains, and the like (see nonlimiting examples herein). In some embodiments, using standards such as for example the RESTful APIs, JSON-RPC, or WebSocket protocols may facilitate interactions between cryptocurrency networks and web-based applications. Additional or alternative implementations of cryptocurrency networks may be used in different embodiments. [0096] A cryptocurrency wallet, digital wallet, or a smart wallet as used herein (also known as an e-wallet or electronic wallet), may be for example a computerized tool or technique that may allow users to securely store, manage, update, or transact with various types of digital assets, including, for example, cryptocurrencies, fiat currencies, loyalty points, and other digital tokens. Digital wallets may offer a convenient and efficient way to store, access and manage digital data and/or assets. In some embodiments, digital wallets may be or may include a blockchain unit or plurality of blockchain units, and/or cryptocurrencies and/or smart contracts, which may for example be maintained or stored by a plurality of computerized systems. Cryptocurrency wallets as used herein may refer to key management devices which may track holding values, and broadcast transactions. Software wallets may be or may include programs on a computer or mobile devices, while a hardware wallet may be or may include a separate device which gives an added layer of security.
Attorney Docket: P-637007-PC [0097] It should be noted that digital wallets and/or cryptocurrency transactions, and that signing transactions according to some embodiments may be used in contexts unrelated to, e.g., finance and/or monetary transactions. Some embodiments of the invention may be used for performing computerized exchanges of data (which may also be referred to as cryptocurrency “transactions” and may be for example be performed over a communication or data network) in various contexts – such for example ones relating to authentication, access privileges, access control, and secure document sharing. For instance, some embodiments may be used for securely signing, storing, managing, and/or updating sensitive or confidential data and/or information – such as, e.g., securely storing and managing healthcare data and personal medical records; travel-related documents and identification credentials (such as for example passports, driver's licenses, boarding passes, and travel insurance policies); educational credentials (such as for example certificates, diplomas, and transcripts); and the like. [0098] Cryptographic keys or key shares according to some embodiments may for example refer to computerized data objects in various formats. Example keys or shares according to some embodiments may be generated and/or stored and/or transmitted as binary data, and/or using hexadecimal notation, Base64 encoding, JavaScript object notation (JSON) objects, abstract syntax notation one (ASN.1), as well as using custom, protocol specific data objects which may for example be defined using relevant cryptocurrency development or application programming interface tools. Additional or alternative data structures or objects may be used in different embodiments. [0099] It should be understood, for example, that a key of a computerized party P1 may refer to a computerized data object stored by P1, which may not be available to separate parties, e.g., P2, …, Pn. The latter entities may not be exposed to data or information items stored, withheld, or kept “secret” or “private” in P1. Accordingly, “private” or “secret” as used herein may describe for example a data object or information accessible or known to a specific entity, such as for example P1 (which may store the relevant private item or key, e.g., in computer storage or memory) – while not being accessible or known to separate entities P2, …, Pn (unless “disclosed”, or provided, sent, or transmitted to them by P1). “Public” as used herein may refer to data object or information available for all relevant entities, such as for example information “broadcasted” or shared with all entities using a “bulletin board” or public component of the cryptocurrency network or system.
Attorney Docket: P-637007-PC [00100] Reference is made to Fig. 10 which schematically illustrates an example system for securely managing cryptographic keys, according to some embodiments of the invention. [00101] Different embodiments of the invention may be executed using any single or combination of devices and/or components of system 100 of Fig.1. The devices of system 100 may be used to operate one or more devices, data structures, parties or services, such as, those described herein. [00102] System 100 may include one or more server(s) 110, database(s) 115, and/or computer(s) 140, 150, …, any of which may operate to generate, trade and track digital data, cryptocurrency and/or cryptocurrency artifacts. Any or all of system 100 devices may be connected via one or more network(s) 120. [00103] Database 115 may include software processes or applications for storing and retrieving digital data, cryptocurrency, and/or cryptocurrency artifacts 117 such as data structures used by and in Figures 1-2. Data 117 may also include code (e.g., software code) or logic, e.g., to enable securely signing cryptocurrency transactions utilizing fully homomorphic encryption according to embodiments of the invention. Database 115 may be internal or external to one or more of server(s) 110 and/or computer(s) 140 and/or 150 (not shown) and may be connected thereto by a local or remote and a wired or wireless connection. In alternate embodiments, data 117 may be stored in an alternate location separate from database 115, e.g., memory unit(s) 118, 148, and/or 158. [00104] Computers 140 and 150 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. Computers 140 and 150 may include one or more input devices 142 and 152, respectively, for operating user interfaces and receiving input from a user (e.g., via a pointing device, click-wheel or mouse, keys, touch screen, recorder/microphone, other input components). Computers 140 and 150 may include one or more output devices 144 and 154 (e.g., a monitor or screen) for displaying data, e.g., via user interfaces, to a user provided by or for server(s) 110. [00105] Network 120, which connects server(s) 110 and computers 140 and 150, may be any public or private network such as the Internet. Access to network 120 may be through wire line, terrestrial wireless, satellite, or other systems well known in the art.
Attorney Docket: P-637007-PC [00106] Server(s) 110 and computers 140 and 150, may include one or more controller(s) or processor(s) 116, 146, and 156, respectively, for executing operations according to embodiments of the invention and one or more memory unit(s) 118, 148, and 158, respectively, for storing data (e.g., digital data, cryptocurrency and/or cryptocurrency artifacts) and/or instructions (e.g., software for applying computations or calculations for securely signing cryptocurrency transactions utilizing fully homomorphic encryption according to embodiments of the invention) executable by the processor(s). Processor(s) 116, 146, and/or 156 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) 118, 148, and/or 158 may include, for example, a random access memory (RAM), a dynamic RAM (DRAM), a flash memory, a volatile memory, a non- volatile memory, a cache memory, a buffer, a short term memory unit, a long term memory unit, or other suitable memory units or storage units. [00107] 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) 118, 148, and/or 158) 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) 108, 110, and/or 112), cause the processor or controller to carry out methods disclosed herein. [00108] In some embodiments, computers 140 and 150 may be or may refer to a sender device (or a “first computing device” owning of a private cryptographic key), and to a receiver device (or a “second computing device” receiving a public cryptographic key from the sender device – which may assumed, for example, to be an untrusted party, or a party of unknown trust), respectively. Server(s) 110 may be or may refer to a proxy re-encryption server and/or to a crypto vault or vaults according to some embodiments of the invention (which may be assumed, for example, to be semi- trusted parties). Proxy re-encryption server may be a computer system or server separate and distinct from a crypto vault or vaults. Different computer systems and/or servers may be remotely connected over communication or data network(s). [00109] Fig. 11 shows an example process for securing and efficiently signing cryptocurrency transactions using proxy re-encryption according to some embodiments of the invention.
Attorney Docket: P-637007-PC [00110] Some embodiments may receive, at a proxy re-encryption serve, a first encryption of a cryptographic private key obfuscated by a first layer of encryption – or a private key once- encrypted using a “fast” encryption or cipher – from a first computer device, such as for example a sender device transmitting a message or cryptocurrency to be signed (operation 1110). Some embodiments may proxy re-encrypt the first encryption of the cryptographic private key (or the once-encrypted key) to generate a twice-encrypted key – or a second encryption of the cryptographic private key obfuscated by an FHE layer – without unencrypting or exposing the cryptographic private key (some embodiments may thus apply a second “slow” encryption layer, to the private key on which a first, “fast” encryption layer was applied; operation 1120). Some embodiments may transmit the second encryption of the cryptographic private key (or the twice- encrypted or FHE encrypted private key) to one or more untrusted third parties (such as for example a second computing device or receiver computer and/or to server farms of, e.g., a crypto vault and/or a blockchain network or cloud, and the like) to efficiently generate a cryptographic signature of a cryptocurrency transaction – which may be FHE encrypted, or encrypted under the second encryption of the cryptographic private key obfuscated by the FHE layer (operation 1130). Additional or alternative operations may be used in different embodiments. [00111] According to some embodiments, a cryptographic signature may be generated in an efficient manner by offloading computationally intensive FHE operations from client devices or other computerized entities or devices (e.g., the first computer device or sender device, and/or the receiver device, and/or devices taking part in the relevant blockchain network and/or key backup) to a dedicated proxy re-encryption or FHE server – while requiring client devices to perform only fast and computationally less-intensive cryptographic operations. [00112] 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.
Attorney Docket: P-637007-PC [00113] 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. [00114] 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. [00115] 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.