[go: up one dir, main page]

WO2024150009A1 - Système et procédé de clé privée - Google Patents

Système et procédé de clé privée Download PDF

Info

Publication number
WO2024150009A1
WO2024150009A1 PCT/GB2024/050070 GB2024050070W WO2024150009A1 WO 2024150009 A1 WO2024150009 A1 WO 2024150009A1 GB 2024050070 W GB2024050070 W GB 2024050070W WO 2024150009 A1 WO2024150009 A1 WO 2024150009A1
Authority
WO
WIPO (PCT)
Prior art keywords
private key
central
enclave
custodian
shares
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/GB2024/050070
Other languages
English (en)
Inventor
Zakwan JAROUCHEH
Bill BUCHANAN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Edinburgh Napier University
Original Assignee
Edinburgh Napier University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Edinburgh Napier University filed Critical Edinburgh Napier University
Publication of WO2024150009A1 publication Critical patent/WO2024150009A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the present disclosure relates to a private key system and method. More particularly, the present disclosure may provide a system and/or method for generating a private key comprising one or more shares, and a system and/or method for signing a transaction using the private key comprising one or more shares.
  • Crypto assets such as cryptocurrencies, NFTs, and security tokens may require custodians to maintain the safekeeping of these assets on behalf of users.
  • Custodians store private keys and approve and sign transactions. They are important to organisations acquiring and holding crypto assets.
  • HSMs hardware security modules
  • HSMs act as trust anchors that protect the cryptographic infrastructure by securely managing, processing, and storing cryptographic keys inside a hardened, tamper-resistant device.
  • the price of one HSM is high (a single device can costs thousands of dollars currently), and a plurality of HSMs may be required for testing and backup.
  • using expensive HSMs may lead to higher fees to be paid by the user.
  • HSMs may be hacked.
  • the use of HSM devices to generate and store a private key may create a central point of failure and may introduce a security risk.
  • MPC multi-party computation
  • MPC techniques involve different parties (e.g., machines) jointly generating and using the private key.
  • MPC techniques may also have drawbacks.
  • MPC techniques may be difficult for non-experts to understand.
  • MPC techniques may require a high level of monitoring and/or auditing to establish trustworthiness.
  • poor implementations of MPC techniques may risk replicating the same problems associated with cold storage and hot wallets, which may leave assets exposed to the threat of hacks and corruption.
  • Another main drawback is accountability.
  • MPC based signatures it is impossible to distinguish which of the key parts were used to sign the transaction. Accountability is vital in monetary systems. The inability to determine the input data may foster suspicion in the computation result.
  • MPC techniques may also struggle with scalability.
  • MPC techniques may suffer from high overhead for cryptographic operations.
  • Even a two-party secure computation may be impractical for most real-time online computations.
  • Defenses against malicious or adaptive adversaries and resource constraints further degrade performance.
  • a further problem with MPC techniques is associated with key ownership.
  • Two options are available to a user to store a wallet. Firstly, a non-custodial option where the user can manage their private keys and have full control over them. This is not a preferred option for parties who want to delegate the private key management tasks to a third-party.
  • a second option is a custodial option, where the private key is managed by the custodian.
  • the custodian manages the full private key (using for example HSMs), which means the custodian has full control over the key
  • the custodian divides the key into shares (for example, by using a Shamir secret sharing algorithm, or MPC). If the key is divided into shares, the user will have to manage at least one share. In other words, the custodian and the user share the responsibility of managing the key.
  • a problem with dividing the key into shares is that it may put an additional burden on the user because they have to store the share themselves, which may cause issues if the share storage device (e.g., a smartphone) has been damaged or lost, and may prevent the user from easily switching between devices.
  • the share storage device e.g., a smartphone
  • the private key cannot be downloaded by the user, and the only way to change custodian is to create new wallets and move the assets to the new wallets, which may add complexity and cost to the user when they want to switch to another custodian.
  • a private key generation and distribution method comprising: generating, using a user enclave of a user computing device or a first central enclave of a central network, a wallet key pair comprising a wallet public key and a wallet private key; dividing, using the user enclave or the first central enclave, the wallet private key into a plurality of private key shares; wherein the plurality of private key shares comprises: a first private key share; and one or more second private key shares; processing, across the central network, at least the one or more second private key shares; and distributively transmitting, by the central network, at least the one or more second private key shares to one or more custodian networks.
  • the ‘custodian network’ may be understood as a network responsible for storing a private key share.
  • Each custodian network may have a set of custodian nodes and a load balancer to balance the load on these custodian nodes.
  • Each custodian node may be a machine containing a custodian enclave.
  • An API server may be deployed on these custodian nodes.
  • the ‘central network’ may be understood as a network responsible for the execution of different steps of the method.
  • the central network may also comprise a set of network nodes and a load balancer to balance the load on these central nodes.
  • Each central node may be a machine containing a central node.
  • An API server may be deployed on these central nodes.
  • the step ‘processing across the central network’ may be understood as a step in which an operation is applied to the one or more second private key shares by the central network, without the second private key shares being stored. This step may put the second private key shares in a form suitable for distribution to the one or more second private key shares.
  • the step ‘distributively transmitting by the central network’ may be understood as a transmission of each of the one or more second private key shares to a respective custodian network, such that the second private key shares are distributed across one or more custodian networks.
  • more than one second private key share may be transmitted to a single custodian network, although it is preferable that only one second private share is transmitted to a single custodian network to avoid multiple second private key shares being at risk if a single custodian network is compromised.
  • the present disclosure may provide a private key generation and distribution method wherein a private key is never stored in one central location. Additionally, the present disclosure may provide a flexible solution wherein there is no limit to the number of keys that can be stored. The present disclosure may provide a custody solution with a lower operational cost and a comparable security level to solutions that may rely solely on hardware security modules (HSMs).
  • HSMs hardware security modules
  • the wallet key pair is generated and divided by a user computing device.
  • processing at least the one or more second private key shares comprises: storing, on a user datastore of the user computing device, the first private key share; and processing, by the central network, the one or more second private key shares.
  • An ‘enclave’ may be understood as a type of trusted execution environment (TEE).
  • the enclave may be configured to create an isolated execution environment.
  • the use of enclaves may provide an execution space in the respective central computing device that may provide a higher level of security for trusted applications running on the central computing device than a rich operating system (OS) and more functionality than a 'secure element' (SE) scheme or system.
  • OS rich operating system
  • SE 'secure element'
  • processing the one or more second private key shares comprises: receiving, at the user computing device, one or more central enclave public keys, each central enclave public key being associated with a respective central enclave of the central network; encrypting, by the user computing device, each of the one or more second private key shares according to the one or more central enclave public keys; transmitting, by the user enclave, the one or more encrypted private key shares and the wallet public key to the central network; allocating, by the central network, the one or more encrypted private key shares to one or more respective central enclaves; decrypting, by the central network, the allocated encrypted private key shares; and re-encrypting, by the central network, the decrypted private key shares using one or more custodian public keys.
  • each of the one or more encrypted private key shares are allocated to the respective central enclave associated with the central enclave public key used to encrypt the private key share.
  • each of the one or more second private key shares are encrypted using all of the central enclave public keys.
  • one or more central enclaves of the central network decrypt allocated encrypted private key shares using associated central enclave private keys.
  • the private key generation and distribution method further comprises: notifying, by the central network, the user computing device that the one or more second private keys have been stored; and deleting, by the user computing device, the one or more second private key shares.
  • distributively transmitting at least the one or more second private key shares comprises: transmitting, by the central network, the respective re-encrypted private key shares and the wallet public key to a respective custodian network.
  • the plurality of private key shares may advantageously be stored in different distributed databases, which may advantageously increase resiliency and redundancy. This may ensure that backup shares are always available in case one or more databases are damaged or compromised.
  • the shares are encrypted with encryption keys accessible only to the enclaves.
  • the attacker must compromise an access control mechanism in order to retrieve the shares. Even if the attacker manages to compromise all databases and the access control mechanism, they may not be able to recover the full private key because they need to access the key share stored on the user enclave of the user computing device.
  • re-encrypting the respective decrypted private key shares comprises: re-encrypting, by the central network, the one or more respective decrypted private key shares using all custodian enclave public keys of a respective custodian network.
  • the wallet key pair is generated and divided by a central enclave of the central network.
  • processing at least the one or more second private key shares comprises: processing, on the central enclave, the first private key share; and processing, on the central enclave, the one or more second private key shares.
  • processing the first private key share and the one or more second private key shares comprises: encrypting, by the first central enclave, the first private key share and the one or more second private key shares; wherein the first private key share and the one or more second private key shares are encrypted according to one or more respective central enclave public keys associated with one or more respective second central enclaves.
  • the private key generation and distribution method further comprises: receiving, at the central network, a custodian enclave identifier from each custodian network; and deleting, by each central enclave, a respective decrypted private key share.
  • the one or more custodian networks are geographically distributed. That is, each of the custodian enclaves may be geographically distributed.
  • This geographic distribution may have the following advantages. Firstly, it may add another layer of security and make it harder for any attackers who are trying to get access to the key shares to assemble the final private key, because the attack would be required to compromise a set of machines available in different locations. Secondly, it may provide redundancy and resiliency in case a disaster happened in one geographic location.
  • a transaction signing method comprising: receiving, at the central network, a transaction request from a user computing device; transmitting, by the first central enclave, a key retrieval request to the one or more custodian enclaves storing one or more second private key shares; retrieving, decrypting, and re-encrypting, by the one or more custodian networks, the respective one or more second private key shares; transmitting, by the one or more custodian networks, the respective one or more encrypted second private key shares to the central network; allocating, at the central network, the one or more encrypted second private key shares to a central enclave; decrypting, re-encrypting, and transmitting, by the central enclave, the one or more second private key shares to the user computing device; decrypting, by the user computing device, the one or more encrypted second private key shares; reconstructing, by the user computing device, a wallet private key using a first private key share and the
  • the key retrieval request comprises: a temporal central private key; a central enclave public key; and a wallet public key.
  • each custodian network is configured to: allocate the transaction request to any of its custodian enclaves; identify the second private key share using the wallet public key; decrypt the second private key share using the private key of the custodian enclave; and re-encrypt the second private key share using the temporal central private key.
  • the transaction request comprises: a temporal user private key; a temporal user public key; and a wallet public key.
  • the central enclave is configured to: decrypt the one or more encrypted second private key shares using a temporal central private key; and re-encrypt the one or more decrypted second private key shares using the temporal user public key.
  • the user computing device decrypts the one or more encrypted second private key shares using the temporal user private key.
  • This disclosure may provide a means for creating a custom business and securely deploying it to a set of approved enclaves. No additional hardware may be required for scaling the system up. The system can accommodate an infinite number of private keys (unlike HSMs which are able to store a couple of thousands of keys). Additionally, unlike the MPC solutions, all transactions can be signed inside the enclave by one entity which makes the solution scalable in terms of the computation complexity.
  • the present system may not rely on expensive HSM devices, nor on multi-signature algorithms which are applicable to specific crypto asset types. Instead, unlike other custodial solutions, the present system may be built using the trusted execution environment which may allow the authenticated users to commit their transactions and access their private keys at any point of time. That way, the users may not be stuck in one platform, and they can switch to any other custodial or non-custodial solution.
  • Figure 1 shows a systematic view of a private key generation and distribution system in accordance with a first aspect of the present disclosure
  • Figure 2A shows a flow diagram of a private key generation and distribution method using the private key generation and distribution system of Figure 1 , in accordance with a first aspect of the present disclosure
  • Figure 2B shows a flow diagram of a transient storage method according to a first embodiment of the private key generation and distribution method
  • Figure 3 shows a flow diagram of a transaction signing method using the private key generation and distribution system of Figure 1 , in accordance with a second aspect of the present disclosure.
  • Figure 1 shows a systematic view of a private key generation and distribution system 100.
  • the system 100 comprises a user computing device 102; a central network 104 in communication with the first user computing device 102; and one or more custodian networks 106 in communication with the central network 104.
  • the user computing device 102 is a computing device associated with a user.
  • the user computing device is a smartphone.
  • the user computing device 102 comprises a user enclave.
  • the user enclave comprises an associated user public key and user private key pair.
  • the user public key and user private key pair are generated in response to a successful registration to a service.
  • the user computing device 102 further comprises a user datastore configured to store a first private key share.
  • the central network 104 comprises one or more central nodes or computing devices, each comprising a respective central enclave (not shown) having an associated central public key and central private key pair.
  • the central network 104 further comprises a central database storing one or more custodian enclave identifiers.
  • the central network 104 comprises an API server (not shown) deployed across the one or more central computing devices, for facilitating communication with the first user computing device 102 and the custodian network 106.
  • the central network 104 also comprises a load balancing means (not shown) configured to equally distribute processing tasks amongst the central computing devices.
  • the one or more central computing devices comprises: a first central computing device comprising a first central enclave, a second central computing device comprising a second central enclave, and a third central computing device comprising a third central enclave. It will be appreciated that there may be any number of central devices.
  • Each custodian network of the one or more custodian networks 106 comprises one or more custodian computing devices, each comprising a respective custodian enclave (not shown) having an associated custodian public key and custodian private key pair.
  • Each custodian network of the one or more custodian networks 106 further comprises a custodian network database configured to store an encrypted second private key share.
  • the custodian computing devices 106 are geographically distributed.
  • the custodian networks 106 comprise an API server (not shown) deployed on the one or more third computing devices.
  • the custodian networks 106 also comprise a load balancing means (not shown) configured to equally distribute network traffic amongst the custodian computing devices.
  • Each custodian network may comprise any number of custodian computing devices.
  • the one or more custodian networks 106 comprise a first custodian network, a second custodian network, and a third custodian network, such that there are three custodian networks. It will be appreciated that there may be any number of custodian networks, and it is preferable that the number of custodian networks is equal to the number of second private key shares, as discussed below.
  • the first custodian network comprises: one or more first custodian computing devices, each comprising a respective first custodian enclave having a first custodian enclave public key and private key pair; and a first custodian database.
  • the second custodian network comprises: one or more second custodian computing devices, each comprising a respective second custodian enclave having a second custodian enclave public key and private key pair; and a second custodian database.
  • the third custodian network comprises one or more third custodian computing devices, each comprising a respective third custodian enclave having a third custodian enclave public key and private key pair; and a third custodian database.
  • the one or more custodian networks 106 are in communication with a distributed ledger (not shown) deploying a smart contract, wherein the smart contract comprises a list of approved image hashes and a list of trusted custodian enclave public keys.
  • Each custodian enclave of the one or more custodian networks 106 is configured to invoke or interact with the smart contract so as to add a respective custodian enclave public key to the list of custodian enclave public keys.
  • the custodian enclave adds the custodian enclave public key by submitting a request, the request comprising: an attestation document; the custodian enclave public key; an image hash, and metadata.
  • the smart contract determines whether the image hash matches an approved image hash. If the image hash matches an approved image hash, the smart contract adds the custodian enclave public key to the list of trusted custodian enclave public keys.
  • the smart contract may also be configured to execute an approved image hash upload function that is callable by a specific multi-signature wallet.
  • the multi-signature wallet comprises a list of private keys associated with a group of approved individuals, such as stakeholders or administrators.
  • the function is configured to add a new image hash to the list of approved image hashes when called. In this way, the group of approved individuals can ‘collectively’ approve adding a new image hash to the list of approved image hashes by calling the function. Accordingly, the list of approved images cannot be changed by a malicious entity and all the relevant approved individuals are involved in the approval process.
  • the central network 104 is also in communication with the distributed ledger (not shown) comprising the smart contract.
  • the central network 104 is configured to invoke the smart contract so as to receive the list of custodian enclave public keys.
  • Figure 2A shows a flow diagram of a private key generation and distribution method 200 using the private key generation and distribution system 100 of Figure 1 , in accordance with a first aspect of the present disclosure.
  • a user authentication may occur.
  • the user may authenticate themselves via one or more authentication methods.
  • an authentication method may be a two-factor authentication.
  • the method 200 may be executed.
  • the system 100 generates a wallet key pair comprising a wallet public key and a wallet private key. It will be noted that the wallet public key and wallet private key are distinct to the user public key and the user private key.
  • the user enclave of the user computing device 102 generates the wallet key pair.
  • any central enclave, such as a first central enclave, of the central network 104 generates the wallet key pair.
  • the system 100 divides the wallet private key into a plurality of private key shares.
  • the plurality of private key shares comprise: a first private key share; and one or more second private key shares.
  • the system 100 may divide the wallet private key using any suitable algorithm, such as the Shamir secret algorithm.
  • the one or more second private key shares comprises: a second private key share; a third private key share; and a fourth private key share.
  • the wallet private key comprises four distinct private key shares (one first private key share and three second private key shares). It will be appreciated that there may be any number of first private key shares, as long as at least one second private key share is generated and provided to the central network 104 such that if the user device 102 is compromised, the entire wallet private key cannot be constructed.
  • the user enclave of the user computing device 102 divides the wallet private key into the plurality of private key shares.
  • any central enclave, such as the first central enclave, of the central network 104 divides the wallet private key into the plurality of private key shares.
  • the system 100 processes at least the one or more second private key shares using the central network 104.
  • Figure 2B shows a flow diagram of a processing method 206’ according to the first embodiment of the method 200.
  • the user computing device 102 stores the first private key share in the user datastore, and the central network 104 processes the one or more second private key shares.
  • the user enclave of the user computing device 102 stores the first private key share in the user datastore.
  • one or more central enclaves of the central network 104 process the one or more second private key shares.
  • the user computing device 102 receives, from the central network 104, one or more central enclave public keys, each central enclave public key being associated with a respective central enclave of the central network 104.
  • the user computer device 102 may receive the one or more central enclave public keys in response to a wallet generation request transmitted to the central network 104 from the user computing device 102. It will be appreciated that the user computing device 102 may receive the one or more central enclave public keys at any time prior to step 206.
  • the one or more central enclave public keys comprise: a first central enclave public key, a second central enclave public key, and a third central enclave public key. The first central enclave public key is associated with the first central enclave, the second central enclave public key is associated with the second central enclave, and the third central enclave public key is associated with the third central enclave.
  • the user enclave encrypts the one or more second private key shares according to the one or more central enclave public keys received in step 202.
  • the user enclave encrypts each second private key share according to all of the received central enclave public keys. In this way, an encrypted second private key share is generated for each of the one or more second private key shares.
  • the user enclave encrypts the second private key share with all of the received central enclave public keys.
  • the user enclave encrypts the third private key share with all of the received central enclave public keys.
  • the user enclave encrypts the fourth private key share with all of the received central enclave public keys. Therefore, a first encrypted private key share, a second encrypted private key share, and a third encrypted private key share are generated for the second private key share, the third private key share, and the fourth private key share, respectively. In this way, any central enclave of the central network 104 can decrypt the encrypted private key shares using an associated central private key.
  • the user enclave transmits the one or more encrypted private key shares to the central network 104.
  • the user enclave also transmits the wallet public key to the central network 104.
  • the user enclave transmits: the first encrypted private key share; the second encrypted private key share; and the third encrypted private key share to the central network 104.
  • the central network 104 allocates the one or more encrypted private key shares to one or more central enclaves. That is, the encrypted private key shares are allocated to one or more central enclaves of the central network 104 by the load balancing means. In some embodiments, all of the encrypted private key shares are allocated to a single central enclave, such as the first central enclave. In other embodiments, the encrypted private key shares are allocated to more than one central enclave.
  • the central network 104 allocates: the first encrypted private key share to the first central enclave; the second encrypted private key share to the second central enclave; and the third encrypted private key share to the third central enclave.
  • the central network 104 decrypts the allocated encrypted private key shares. That is, one or more central enclaves decrypt respective allocated encrypted private key shares using associated central enclave private keys.
  • the first central enclave decrypts the first encrypted private key share using the first central enclave private key.
  • the second central enclave decrypts the second encrypted private key share using the second central enclave private key.
  • the third central enclave decrypts the third encrypted private key share using the third central enclave private key.
  • the central network 104 re-encrypts the decrypted private key shares using one or more custodian enclave public keys.
  • one or more central enclaves re-encrypt respective decrypted private key shares using all custodian enclave public keys of a respective custodian network.
  • each private key share is allocated to a respective custodian network, such that only a single private key share is stored in any one custodian network. Accordingly, each of the decrypted private key shares are re-encrypted using all custodian enclave public keys of a respective custodian network.
  • the first central enclave re-encrypts the first decrypted private key share using all first custodian enclave public keys of the first custodian network.
  • the second central enclave re-encrypts the second decrypted private key share using all second custodian enclave public keys of the second custodian network.
  • the third central enclave re-encrypts the third decrypted private key share using all third custodian enclave public keys of the third custodian network.
  • the wallet private key is not created by the central network 104. Therefore, even in the case the central network 104 is compromised in a worstcase scenario, an attacker cannot reconstruct the whole wallet private key. To construct the wallet private key, the attacker will need to access all shares including the one stored on the user datastore of the first user computing device 102.
  • the central network 104 processes the first private key share and the one or more second private key shares.
  • any central enclave of the central network 104 processes the first private key share and the one or more second private key shares.
  • any one or more central enclaves such as the first central enclave, processes the first private key share and the one or more second private key shares.
  • the first central enclave encrypts the first private key share and the one or more second private key shares, wherein the first private key share and the one or more second private key shares are encrypted using one or more custodian enclave public keys of respective custodian networks.
  • the first central enclave encrypts the respective first private key share and second private key shares using all custodian enclave public keys of a respective custodian network.
  • the central network 104 may distribute the one or more second private key shares amongst the other central enclaves for further encrypted.
  • the first central enclave encrypts the first private key share using all fourth custodian enclave public keys of a fourth custodian network.
  • the first central enclave encrypts the second private key share using all first custodian enclave public keys of the first custodian network.
  • the first central enclave encrypts the third private key share using all second custodian enclave public keys of the third custodian network.
  • the first central enclave encrypts the fourth private key share using all third custodian enclave public keys of the third custodian network.
  • the central network 104 can store the first private key share on the central database.
  • the user has a choice of where the private key shares are stored.
  • the first private key share is stored in the user enclave of the user computing device 102.
  • the wallet private key does not exist in its full form in the user computing device 102.
  • the user may have full power of the signature process because the central network 104 cannot sign any transaction without the first private key share.
  • a transaction request may be sent to the central network 104 to retrieve the one or more second private key shares.
  • the user device may reconstruct the wallet private key based on the one or more second private key shares along with the first private key share and commits the transaction inside the user enclave of the user computing device 102.
  • the first private key share may be stored in the central database of the central network 104, and the central network 104 may reconstruct the wallet private key.
  • the second embodiment may be useful for users who have low value transactions or those who prefer usability over security, and they fully trust a custodian. Additionally, the second embodiment may advantageously allow the user to login from any device.
  • the system 100 distributively transmits at least the one or more second private key shares to one or more custodian networks of the plurality of custodian networks 106.
  • the central network 104 transmits the re-encrypted private key shares to the respective custodian networks of the one or more custodian networks 106.
  • the central network 104 transmits the re-encrypted private key shares to the custodian networks associated with the custodian enclave public keys used to encrypt the decrypted private key shares.
  • the central network 104 also transmits the wallet public key to the one or more custodian networks 106.
  • the wallet public key is used by the custodian networks during a transaction signing process, such as the method 300, to identify which of the stored private key shares are associated with the wallet public key.
  • any central enclave such as the first central enclave, transmits the first re-encrypted private key share to the first custodian network.
  • Any central enclave such as the second central enclave, transmits the second re-encrypted private key share to the second custodian network.
  • Any central enclave such as the third central enclave, transmits the third re-encrypted private key share to the third custodian network.
  • a single central enclave can transmit one or more of the re-encrypted private key shares. In this way, the central network 104 works as a set of load-balanced enclaves.
  • Each custodian network of the one or more custodian networks 106 allocates the received reencrypted private key share to a respective custodian enclave of the one or more custodian enclaves of the respective custodian network.
  • Each custodian network of the one or more custodian networks 106 also stores the received wallet public key in the custodian network database, and associated it with the received private key share.
  • the first custodian network allocates the first re-encrypted private key share to any first custodian enclave.
  • the second custodian network allocates the second reencrypted private key share to any second custodian enclave.
  • the third custodian network allocates the third re-encrypted private key share to any third custodian enclave.
  • Each receiving custodian enclave stores the allocated re-encrypted private key share in a corresponding custodian database.
  • the first custodian enclave stores the first re-encrypted private key share in the first custodian database.
  • the second custodian enclave stores the second reencrypted private key share in the second custodian database.
  • the third custodian enclave stores the third re-encrypted private key share in the third custodian database. Since the re-encrypted private key shares were re-encrypted using all public keys of a respective custodian network, any custodian enclave of that custodian network can decrypt the re-encrypted private key share.
  • the central network 104 notifies the user computing device 102 and the user computing device 102 deletes the one or more second private key shares. In this way, if the user computing device 102 is compromised, an attacker cannot reconstruct the whole wallet private key. To construct the wallet private key, the attacker will need to access all shares.
  • the first private key share is stored in the user datastore of the user computing device 102
  • the second private key share is stored in the first custodian database of the first custodian network
  • the third private key share is stored in the second custodian database of the second custodian network
  • the fourth private key share is stored in the third custodian database of the third custodian network.
  • the first private key share is accessible inside the user datastore, and humans are not able to access the first private key share.
  • the one or more second private key shares are accessible inside the custodian network databases, and humans are not able to access the one or more second private key shares.
  • the second embodiment is substantially similar to the first embodiment, except the first private key share is also distributively stored on a respective custodian database of a custodian network, such as a fourth custodian database of a fourth custodian network.
  • any central enclave encrypts one or more of the respective private key share using one or more custodian enclave public keys.
  • Each private key share is encrypted using all custodian enclave public keys of a respective custodian network.
  • the first central enclave encrypts the first private key share using all first custodian enclave public keys of the first custodian network.
  • the second central enclave encrypts the second private key share using all second custodian enclave public keys of the second custodian network.
  • the third central enclave encrypts the third private key share using all third custodian enclave public keys of the third custodian network.
  • the fourth central enclave encrypts the fourth private key share using all fourth custodian enclave public keys of the fourth custodian network.
  • the wallet private key is therefore advantageously divided into private key shares distributed across different geographical locations. Accordingly, it very difficult for an attacker to compromise these private key shares. Even if the attacker managed to access all private key shares stored on the custodian enclaves, there is still one private key share stored on the user enclave of the user computing device 102. Furthermore, even if an attacker manages to access each custodian network database of each custodian network, the private key shares are encrypted, and no one can decrypt the private key shares except the custodian enclaves.
  • FIG. 3 shows a flow diagram of a transaction signing method 300 using the system 100, in accordance with a second aspect of the present disclosure. The following discussion will be a continuation of the example used in the method 200.
  • a user authentication may occur.
  • the user may authenticate themselves via one or more authentication methods.
  • an authentication method may be a two-factor authentication. However, it will be understood that any suitable authentication method may be used.
  • the method 300 may be executed.
  • the central network 104 receives a transaction request from the user computing device 102.
  • the transaction request is generated by the user computing device 102 and comprises a temporal user key pair comprising a temporal user private key and a temporal user public key; and the wallet public key.
  • the temporal user key pair is generated by the user computing device 102, and is a key pair that is to be used for the present transaction.
  • the transaction request may be associated with a transaction for, for example, transferring an amounts of coins to a wallet address.
  • the wallet public key is the public key associated with the wallet.
  • the central network 104 transmits a key retrieval request to the one or more custodian networks storing the one or more second private key shares.
  • the key retrieval request comprises a temporal central public key and a central enclave public key associated with a central enclave of the central network 104; and the wallet public key.
  • the central network 104 allocates the transaction request of step 302 to any of the central enclaves.
  • the central network 104 allocates the transaction request to the first central enclave.
  • the allocated central enclave i.e. , the first central enclave in the present example
  • generates a temporal central key pair comprising a temporal central private key and the temporal central public key.
  • the first central enclave transmits the key retrieval request comprising the temporal central public key and the first central enclave public key associated with the first central enclave.
  • the key retrieval request also comprises metadata signed by a certificate authority.
  • the first central enclave transmits the key retrieval request to the first custodian network, the second custodian network, and the third custodian network, because these are the custodian networks storing the one or more second private key shares. It will be appreciated that, if the first private key share is also stored in a custodian network, the key retrieval request is also sent to that custodian network.
  • each of the one or more custodian networks retrieves, decrypts, and re-encrypts the respective one or more second private key shares.
  • Each custodian network identifies the second private key share using the wallet public key associated with the second private key shares.
  • Each custodian network allocates the tasks to any of its custodian enclaves, and the second private key share is decrypted using the private key of that custodian enclave.
  • the second private key shares are re-encrypted using the temporal central enclave public key.
  • any first custodian enclave retrieves the encrypted second private key share from the first custodian database, decrypts it using the associated custodian enclave private key, and re-encrypts the second private key share using the temporal central public key.
  • Any second custodian enclave retrieves the encrypted third private key share from the second custodian database, decrypts it using the associated custodian enclave private key, and re-encrypts the third private key share using the temporal central public key.
  • Any third custodian retrieves the encrypted fourth private key share from the third custodian database, decrypts it using the associated custodian enclave private key, and re-encrypts the fourth private key share using the temporal central public key.
  • each of the one or more custodian networks transmit the respective one or more encrypted second private key shares to the central network 104.
  • any first custodian enclave transmits the encrypted second private key share to the central network 104
  • any second custodian enclave transmits the encrypted third private key share to the central network 104
  • any third custodian enclave transmits the encrypted fourth private key share to the central network 104.
  • each of the one or more custodian enclaves verifies the key retrieval request based on the certificate authority and signature before transmitting the respective one or more second private key shares.
  • the central network 104 allocates the one or more encrypted second private key shares to the central enclave associated with the temporal central public key.
  • the central network 104 allocates the second, third, and fourth encrypted private key shares to the first central enclave.
  • the central enclave decrypts, re-encrypts and transmits the one or more second private key shares to the user computing device 102.
  • the central enclave decrypts the one or more encrypted second private key shares using the temporal central private key.
  • the central enclave re-encrypts the one or more decrypted more private key shares using the temporal user public key.
  • the first central enclave decrypts the second, third, and fourth encrypted private key shares using the temporal central private key, re-encrypts the second, third, and fourth decrypted private key shares using the temporal user public key, and transmits the second, third, and fourth re-encrypted private key shares to the user computing device 102.
  • the user computing device 102 decrypts the one or more encrypted second private key shares using the temporal user private key.
  • the user enclave decrypts the second, third, and fourth re-encrypted private key shares using the temporal user private key.
  • the user computing device 102 reconstructs the wallet private key.
  • the user enclave reconstructs the wallet private key using the first private key share and the one or more second private key shares.
  • the user enclave reconstructs the wallet private key share using the first private key share, the second private key share, the third private key share, and the fourth private key share.
  • a signature is executed at the user computing device 102.
  • the signature is executed on the user-side.
  • the system 100 executes the signature at the user computing device 102.
  • the user may advantageously be in full control of the signature process. However, this may also create more overhead at the user side.
  • the signature is executed on the central network side.
  • the system 100 executes the signature at the central network 104.
  • the wallet private key shares are assembled at the central network, which reduces the overhead at the user side, but security is reduced.
  • the user may full trust the custodian and may intend for the wallet private key to be reconstructed at the central network 104.
  • the method 300 proceeds with steps 302 to 310.
  • the user computing device 102 also encrypts, and transmits, the first private key share to the central network 104.
  • the user computing device 102 encrypts the first private key share according to all central enclave public keys. In this way, any central enclave of the central network 104 can decrypt the encrypted first private key share.
  • the central network 104 also stores the encrypted first private key share in the central database.
  • the central enclave decrypts the encrypted first private key share stored on the central database using its central enclave private key, and decrypts the one or more encrypted second private key shares using the temporal central private key. Furthermore, in the second embodiment of the method 300, the central enclave also reconstructs the wallet private key. In particular, the central enclave reconstructs the wallet private key using the first private key share and the one or more second private key shares. In the present example, the central enclave reconstructs the wallet private key share using the first private key share, the second private key share, the third private key share, and the fourth private key share. Finally, in the second embodiment of the method 300, the signature is executed at the central network 104. In this way, overhead may be reduced at the user side.
  • the user computing device 102 and the central network 104 delete the one or more second private key shares.
  • the central enclave public keys are stored in a public immutable distributed ledger, such as Ethereum.
  • a central enclave can create a key pair comprising a central enclave public key and a central enclave private key in, for example, Amazon Key Management System (KMS), which will be accessible only to that central enclave.
  • KMS Amazon Key Management System
  • a smart contract is deployed on the distributed ledger (e.g., Ethereum) to allow central enclaves to register respective central enclave public keys.
  • a mechanism is used for the central enclave to prove to the smart contract that a deployed software image is one of the approved images (i.e., not a malicious image).
  • the user public key and user private key pair are generated in the user enclave of the user computing device 102. This key pair is used later in the governance policy of the wallet. This policy determines a list of second users who are eligible to approve specific transactions.
  • the issue here is that the user should backup this personal key in paper format, or in their personal cloud for example, which negatively affects the user experience.
  • a mechanism by which the user can recover the original user key pair is provided in case the original user computing device 102 has been lost or damaged. This can be achieved by using one or more backup user computing devices (not shown).
  • a new user key pair is created for that user and stored in the backup user computing device.
  • the resultant public key is sent to the central network 104, which in turn, sends it to the original user computing device 102.
  • the user can confirm that the backup device is legitimate. This is to ensure that even if an attacker compromises the user authentication credentials, they cannot setup a backup device to restore the original user key pair without the approval from the user.
  • the original user computing device 102 encrypts the user private key of the user key pair using a new user public key of the newly created user key pair in the backup user computing device and sends it to the central network 104 to be stored in a database.
  • the user When the user wants to recover the original user key pair, they can use the backup user computing device and request the encrypted version of the user private key from the central network 104.
  • the backup user computing device will be able to decrypt it using the new user private key.
  • the user can create as many backup user computing devices as they want. The result is a much better experience than storing the keys in the personal cloud or paper format.
  • a substantially similar mechanism can be applied when the user wants to have a backup for the wallet key share they hold on their devices for each wallet.
  • first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element. The first element and the second element are both elements, respectively, but they are not to be considered the same element.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé de génération et de distribution de clé privée. Le procédé consiste à : générer, à l'aide d'une enclave d'utilisateur d'un dispositif informatique d'utilisateur ou d'une première enclave centrale d'un réseau central, une paire de clés de portefeuille comprenant une clé publique de portefeuille et une clé privée de portefeuille ; diviser, à l'aide de l'enclave d'utilisateur ou de la première enclave centrale, la clé privée de portefeuille en une pluralité de parts de clé privée ; la pluralité de parts de clé privée comprenant : une première part de clé privée ; et une ou plusieurs secondes parts de clé privée ; traiter, à l'aide du réseau central, au moins la ou les secondes parts de clé privée ; et transmettre de manière distributive, par le réseau central, au moins la ou les secondes parts de clé privée à un ou plusieurs réseaux de garde.
PCT/GB2024/050070 2023-01-13 2024-01-11 Système et procédé de clé privée Ceased WO2024150009A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB2300569.7 2023-01-13
GB2300569.7A GB2626187A (en) 2023-01-13 2023-01-13 Private key system and method

Publications (1)

Publication Number Publication Date
WO2024150009A1 true WO2024150009A1 (fr) 2024-07-18

Family

ID=85284173

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2024/050070 Ceased WO2024150009A1 (fr) 2023-01-13 2024-01-11 Système et procédé de clé privée

Country Status (2)

Country Link
GB (1) GB2626187A (fr)
WO (1) WO2024150009A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020046786A1 (fr) * 2018-08-27 2020-03-05 Fireblocks Ltd. Système et procédé permettant de sécuriser des transactions de crypto-actifs
US10742422B1 (en) * 2019-08-14 2020-08-11 OX Labs Inc. Digital transaction signing for multiple client devices using secured encrypted private keys

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210319436A1 (en) * 2018-04-24 2021-10-14 Duvon Corporation Autonomous exchange via entrusted ledger wallet administration tool
CN110086612B (zh) * 2019-04-26 2022-03-04 山大地纬软件股份有限公司 一种区块链公私钥备份及丢失找回方法和系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020046786A1 (fr) * 2018-08-27 2020-03-05 Fireblocks Ltd. Système et procédé permettant de sécuriser des transactions de crypto-actifs
US10742422B1 (en) * 2019-08-14 2020-08-11 OX Labs Inc. Digital transaction signing for multiple client devices using secured encrypted private keys

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KHURANA H ET AL: "Reasoning about joint administration of access policies for coalition resources", PROCEEDINGS OF THE 22ND. INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS. ICDCS 2002. VIENNA, AUSTRIA, JULY 2 - 5, 2002; [INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS], LOS ALAMITOS, CA : IEEE COMP. SOC, US, vol. CONF. 22, 2 July 2002 (2002-07-02), pages 390 - 399, XP010595555, ISBN: 978-0-7695-1585-4 *

Also Published As

Publication number Publication date
GB2626187A (en) 2024-07-17
GB202300569D0 (en) 2023-03-01

Similar Documents

Publication Publication Date Title
Seth et al. Integrating encryption techniques for secure data storage in the cloud
US10805072B2 (en) System and method for autonomous dynamic person management
US11893577B2 (en) Cryptographic key storage system and method
JP6321049B2 (ja) 秘密計算方法、秘密計算システム
JP2020528224A (ja) 信頼できる実行環境におけるスマート契約動作のセキュアな実行
JP2013524352A (ja) 移動中のデータをセキュア化するためのシステムおよび方法
Srisakthi et al. Towards the design of a secure and fault tolerant cloud storage in a multi-cloud environment
Agarkhed et al. Security and privacy for data storage service scheme in cloud computing
Kaviani et al. Flock: A Framework for Deploying {On-Demand} Distributed Trust
Singh et al. Secure shared data in the private cloud with an EA algorithm
WO2024150009A1 (fr) Système et procédé de clé privée
KR102400455B1 (ko) 분산 서비스 환경에서의 사용자 개인키 백업 및 복원 프레임워크
Bobde et al. An approach for securing data on Cloud using data slicing and cryptography
He et al. EnShare: Sharing Files Securely and Efficiently in the Cloud using Enclave
Shah et al. Third party public auditing scheme for security in cloud storage
US12438700B1 (en) Threshold encryption and decryption using a key management service in a provider network
Banerjee et al. A nobel cryptosystem for group data sharing in cloud storage
Marwan et al. Towards a secure cloud database using Paillier's homomorphic cryptosystem
Lenin et al. A secured storage scheme for cloud environment using ECC-IRNS based deduplication approach
Contiu Applied Cryptographic Access Control for Untrusted Cloud Storage
Singhal et al. Security in cloud computing-hash function
Pawar et al. Performance analysis of privacy preservation-based authentication scheme and cryptographic-based data protocols for DSaC in cloud
Prakash et al. Data security Algorithms for Cloud storage system using Cryptographic Method
Edwin et al. Fragmentation and Dynamic Replication Model in Multicloud by Data Hosting with Secured Data Sharing
Dhole et al. Ensuring Data Storage Security using Cloud Computing

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24701275

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 24701275

Country of ref document: EP

Kind code of ref document: A1