Computer-implemented method and system for transferring access to digital assets

Abstract

A method of transferring access to a digital asset is disclosed. The method comprises: receiving, by each of a plurality of second participants (8), (10), a first blockchain transaction (4) from a first participant (6), the first participant (6) having a first private key of a first private key-public key pair of the cryptographic system, and each participant (6), (8), (10) having a respective first share of a second private key of a second private key-public key pair of the cryptographic system, the first block chain transaction is signed with a first private key; verifying, by each second participant (8), (10), that the first blockchain transaction has been signed with the first private key; applying the respective first share to the first blockchain transaction to generate a respective second share of the second blockchain transaction signed with a second private key, the signing with the second private key being possible by means of a first threshold number of second shares and inaccessible to second shares less than the first threshold number; and combining together the first threshold number of second shares from the first participant (6) and the plurality of second participants (8), (10) to generate a signature.

Description

[0001] This application is a divisional application of a patent application with Chinese application number 201980024832.8, filing date March 26, 2019, and titled “Computer-implemented method and system for transferring access to digital assets”. Technical Field

[0002] The present invention generally relates to the security of data and computer-based resources. More specifically, the present invention relates to cryptography, and also to elliptic curve cryptography, elliptic curve digital signature algorithm (ECDSA) and threshold cryptography. The present invention can have a wide range of applicability. In one embodiment, the present invention can be described as providing a threshold digital signature scheme. Background Art

[0003] In this document, we use the term "blockchain" to include all forms of computer-based electronic distributed ledgers. These ledgers include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. It should be noted that the present invention is not limited to use with a specific blockchain, and alternative blockchain implementations and protocols also fall within the scope of the present invention.

[0004] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized computer-based system consisting of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, so blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since its creation.

[0005] Unlike distributed or centralized systems, decentralized systems have the following advantages: There is no single point of failure. Therefore, they provide a higher level of security and resilience. Security is further enhanced by using known cryptographic techniques such as elliptic curve cryptography and ECDSA.

[0006] Since signatures from more than one party are required to provide access to digital assets, multi-signature systems are often used in blockchains to enhance security.

[0007] The ECDSA threshold signature scheme can replace the "multi-signature" system for securing wallets and provides higher security and privacy with fewer transactions (thus, lower fees). S. Goldfeder, R. Gennaro, H. Kalodner, J. Bonneau, J. A. K. Roll, E. W. Felten, and A. Narayanan, Securing Wallets via a New DSA / ECDSA Threshold Signature Scheme (2015) and R. Gennaro et al., Threshold-Optimal DSA / ECDSA Signatures with Applications to Wallet Security (2016), International Conference on Applied Cryptography and Network Security ACNS 2016: Applied Cryptography and Network Security, pp. 156-174, provide a variation of the threshold-optimal ECDSA signature scheme so that any t+1 of the n key share holders can collaborate to interactively produce a complete signature, where 1 <t≤n。

[0008] However, these schemes are subject to at least two limitations. First, they rely on new cryptography and related assumptions, such as fully homomorphic encryption schemes that have not been tested in time. Second, due to their complexity and the involvement of zero-knowledge proofs - for example, it takes each participant about 10 seconds to write, generate and verify a zero-knowledge proof individually - they are computationally intensive and therefore slow. Therefore, these systems should not be trusted to ensure the security of large deposits and are not suitable for certain applications that require fast signatures (e.g., exchange operations).

[0009] For example, these schemes cannot be used in systems based on high-frequency payment channels, e.g. as disclosed in J Poon; T Dryja; The Lightning Network: Scalable Off-Chain Instant Payments (2016).

[0010] There are faster, simpler, and more secure schemes for generating ECDSA threshold signatures, but with some limitations. Specifically, certain combinations of t and n are excluded, including popular choices such as the "2 of 3" scheme. Furthermore, in these schemes, the private key can be reconstructed with fewer key shares than are required to generate the signature through a combination of partial signatures. Therefore, there is a need for improvements in secure wallet service systems employed by exchanges that employ "2 of 3" multi-signature technology.

[0011] Bidirectional payment channels, such as those described in J Poon; T Dryja; The Lightning Network: Scalable Off-Chain Instant Payments (2016), can allow assets to be traded while greatly reducing the trust that customers must place in the exchange. In the traditional model, customers can hold, for example, a deposit of fiat currency at the exchange. Customers must trust the exchange to keep accurate records. In other words, while deposits of fiat currency can be protected from theft (to a certain extent) by using escrow services, customers can still lose their deposits if the exchange is compromised and trade records are lost or altered.

[0012] Bidirectional payment channels have several other disadvantages. Consider a standard implementation of a bidirectional payment channel. Alice and Bob want to send cryptographic tokens back and forth between each other. They each fund a 2 / 2 multisig with an agreed-upon amount of tokens, and then exchange commitment transactions to send the tokens (updating the channel) along with a "value" that effectively invalidates the previous state of the channel. If one party were to broadcast an expired commitment transaction, the other party could respond with a "breach remedy transaction" containing the appropriate "value", thereby claiming the entire balance in the channel.

[0013] When Alice or Bob wants to settle the channel, they can each agree to sign a transaction that distributes the balances according to the latest channel state (so-called "soft resolution"). In this way, as long as both parties cooperate, there is no need to broadcast the commitment transaction.

[0014] However, payment channels as described in J Poon; T Dryja; The Lightning Network: Scalable Off-Chain Instant Payments (2016) have a major unresolved vulnerability due to a so-called "failure mode" that can occur when a party with a large number of channels is left unresponsive for a long period of time. This can cause other parties connected to it to broadcast commitment transactions, and if the number of parties is large, the blockchain network can become overwhelmed. This situation is particularly dangerous for payment channels, as a malicious party may try to steal funds by broadcasting outdated commitment transactions in the hope that the party connected to it will not respond in time with a breach of contract transaction. Another limitation of the configuration described in J Poon; T Dryja; The Lightning Network: Scalable Off-Chain Instant Payments (2016) is the additional complication that it requires Segregated Witness (to avoid the possibility that one of the two parties is unwilling or unable to provide the first commitment transaction after funding the channel).

[0015] The latest technology in exchange security

[0016] Currently, many exchange platforms employ secure wallet systems, often through script-based multi-signature functionality via third-party services. These systems place customer or exchanger funds under outputs that can be redeemed using a 2 / 3 multi-signature script (i.e., by providing valid signatures corresponding to any 2 of the 3 public keys). The three corresponding private keys will be distributed to the exchanger, the customer, and a trusted third party / custodian. The movement of funds can then be authorized (via a signed valid transaction) by either: i) the customer and the exchanger, or ii) the exchanger and the third party (in the event that the customer does not cooperate or loses their keys). The third-party service will perform the signing operation through a verified API request from the exchanger.

[0017] In addition to the security practices and policies of the third parties themselves and their application programming interfaces (APIs), this escrow system has several major disadvantages. First, the use of 2 / 3 multisig outputs compromises the privacy of both customers and exchange parties. The number of 2 / 3 multisig transaction outputs is only a small fraction of the total number of outputs, so the loss of anonymity makes it easier for observers of the blockchain to identify funds associated with third parties and exchange wallets. In addition, the use of 2 / 3 multisig outputs also reveals internal exchange operations on the blockchain. An external observer can determine which of the three keys has been used to authorize a specific transaction based on the position in the script. For example, in the $60 million Bitfinex hack that occurred in 2016, blockchain observers were able to determine that keys 1 and 3 were used to steal funds. In addition, the use of 2 / 3 multisig results in larger transaction sizes, and therefore requires larger transaction fees to be reliably and quickly confirmed on the blockchain. In addition, because 2 / 3 multisig scripts are considered "non-standard" scripts, they must be implemented as redemption scripts in the pay-to-script-hash (P2SH) format. Because the P2SH transaction output type can be subject to collision attacks (or so-called "birthday attacks"), it is fundamentally less secure than a standard Pay to Public Key Hash (P2PKH) output. P2SH outputs have 160 bits of security, which means that only 80 bits of security are provided to prevent collision attacks. Currently, this level of security is computationally unattackable, but it may not be possible to maintain this condition indefinitely. Collision attacks are impossible on P2PKH outputs (which only use a single public key), so the 160 bits of security are maintained (in the case of a pre-image attack).

[0018] Threshold Signature Scheme

[0019] A threshold signature protocol enables a group of participants (or nodes) to jointly sign a transaction using a threshold m of n key shares without being able to reconstruct the private key at any time or any participant knowing any information about the key shares of any other party. Using such a scheme can prevent single points of failure in systems where multiple individual parties are required to authorize transactions.

[0020] Threshold signature schemes can be combined with dealer-free or dealer-less protocols to establish secret shares where no party knows the shared secret (private key) (in fact, it need not exist explicitly in memory at any time). However, the group can determine the elliptic curve public key (corresponding to the shared secret key that is not yet known but is implicit). This means that the output can be placed under the control of the shared group public key (and corresponding address) in a completely trustless manner, and a signature on a transaction can only be generated when the parties at the threshold collaborate, without any individual party learning the private key.

[0021] The properties of the mathematical form of the Elliptic Curve Digital Signature Algorithm (ECDSA) mean that constructing a secure threshold scheme for this type of signature is not easy. Specifically, it has been proven that it is impossible to create an efficient and secure threshold optimal scheme - where the number of key shares required to generate a valid signature is the same as the number of shares required to reconstruct the complete private key. The first method for constructing a threshold optimal ECDSA scheme was described in Secure Wallets via New DSA / ECDSA Threshold Signature Schemes (2015) by S. Goldfeder, R. Gennaro, H. Kalodner, J. Bonneau, J. A. Kroll, E. W. Felten, and A. Narayanan, but this scheme has significant drawbacks. First, it is very inefficient: signature generation requires both calling Paillier (additive homomorphic) encryption and creating and verifying a series of zero-knowledge proofs: for a 2 / 2 signature, it requires 6 rounds of communication and a computation time of approximately 10 seconds (per party). Second, the private key is shared multiplicatively: this means that only n / n (n-of-n) key sharing has the potential to implement an m / n (m-of-n) scheme, where m < n requires each party to hold a combination key sharing structure of multiple key shares (each party requires n m key shares). Additionally, sharing the private key multiplicatively is much more complex and computationally intensive without a trusted dealer compared to sharing the key over a polynomial (as in Shamir's secret sharing scheme).

[0022] In recent years, a threshold-optimal ECDSA scheme with improved efficiency (but still relatively slow) has been proposed by R. Gennaro et al., Threshold-Optimal DSA / ECDSA Signatures and Their Application to Wallet Security (2016), International Conference on Applied Cryptography and Network Security ACNS2016: Applied Cryptography and Network Security, pp. 156-174 and Boneh, Dan, Rosario Gennaro, and Steven Goldfeder, "Improved Threshold DSA Signatures for Wallet Security Using Level-1 Homomorphic Encryption", which employs a fully homomorphic cryptographic system. This cryptographic primitive has a high complexity and relies on relatively untested assumptions. It should also be noted that other recent fully homomorphic encryption schemes have also been successfully cryptanalyzed and efficiently broken, for example, as described in Bogos, Sonia, John Gaspoz, and Serge Vaudenay, “Cryptanalysis of Homomorphic Encryption Schemes,” ArcticCrypt 2016, No. EPFL-CONF-220692.2016, and Hu, Yupu, and Fenghe Wang, “Attacks on Fully Homomorphic Encryption Schemes,” International Cryptologic Association Electronic Library of Cryptography 2012 (2012): 561. Summary of the invention

[0023] Preferred embodiments of the present invention seek to overcome one or more of the above-mentioned disadvantages of known solutions.

[0024] The present invention provides methods and systems.

[0025] A method of transferring access to a digital asset may be provided, the method comprising:

[0026] receiving, by each of a plurality of second participants, a first blockchain transaction from a first participant, wherein the first participant has a first private key of a first private key-public key pair of a cryptographic system and each of the participants has a respective share of a second private key of a second private key-public key pair of the cryptographic system, wherein the first blockchain transaction is signed with the first private key;

[0027] Verifying, by a plurality of the second participants, that the first blockchain transaction has been signed with the first private key;

[0028] applying the respective shares of the second private key to the first blockchain transaction to generate respective shares of a first secret value, wherein the first secret value is a second blockchain transaction signed with the second private key, wherein the first secret value is accessible for a first threshold number of the shares of the first secret value and is inaccessible for less than the first threshold number of shares of the first secret value; and

[0029] At least said first threshold number of said shares of said first secret value from said first participant and a plurality of said second participants are combined together to generate said first secret value.

[0030] By applying the respective shares of the second private key to the first blockchain transaction to generate the respective shares of the second blockchain transaction signed with the second private key, wherein the signed second blockchain transaction is accessible to a first threshold number of shares of the first secret value and inaccessible to less than the first threshold number of shares, and combining at least the first threshold number of shares of the first secret value from the first participant and a plurality of second participants to generate the signed second blockchain transaction, this provides the advantage that if one of the second participants is inactive or uncooperative, the transaction can be signed, thereby improving the security and reliability of the system. Moreover, by generating the shares of the first secret value in response to receiving the first blockchain transaction from the first participant, this provides another advantage that the shares of the first secret value can be automatically generated, thereby generating at least three shares of the first secret value, thereby enabling emulation of a 2 / 3 (2 of 3) signature scheme.

[0031] Each of the plurality of said second participants may have a respective private key of said cryptographic system.

[0032] This provides the advantage that a signature made with a private key can be verified by means of a public key corresponding to the private key, thereby enhancing the security of the system.

[0033] The method may further include distributing a said share having said second private key owned by said first participant between said first participant and at least one of said second participants.

[0034] This offers the following advantages: Security is further enhanced.

[0035] The method may further include transferring access to the digital asset to a third private key of the cryptographic system in the event that the second participant becomes unresponsive.

[0036] The digital asset may remain under the control of the third private key for a predetermined period of time.

[0037] The method may further include distributing the shares of the second private key among a plurality of the participants.

[0038] A method of transferring access to a digital asset may be provided, the method comprising:

[0039] sending a first blockchain transaction from a first participant to a plurality of second participants, wherein the first participant has a first private key of a first private key-public key pair of a cryptographic system and each of the participants has a respective share of a second private key of a second private key-public key pair of the cryptographic system, wherein the first blockchain transaction is signed with the first private key;

[0040] receiving respective shares of a first secret value from a plurality of said second participants, wherein said first secret value is a second blockchain transaction signed with said second private key, wherein said first secret value is accessible for a first threshold number of said shares of said first secret value and inaccessible for less than said first threshold number of shares of said first secret value, wherein after verifying by said corresponding second participant that said first blockchain transaction has been signed with said first private key, applying each said share of said second private key to said second blockchain transaction; and

[0041] At least said first threshold number of said shares of said first secret value from said first participant and a plurality of said second participants are combined together to generate said first secret value.

[0042] A method of digitally signing a message may be provided, the method comprising:

[0043] distributing first shares of a first secret value among a plurality of participants, wherein the first secret value is a private key of a public-private key pair of a cryptographic system, the private key being accessible with the aid of a first threshold number of the first shares and being inaccessible for less than the first threshold number of the first shares;

[0044] distributing second shares of a second secret value among the plurality of participants, wherein the second secret value is a temporary key for generating a digital signature, wherein the temporary key is accessible with the aid of the first threshold number of the second shares and is inaccessible to less than the first threshold number of the second shares; and

[0045] Third shares of a third secret value are distributed among the multiple participants, wherein each of the third shares is suitable for being applied to a message to generate a corresponding fourth share of a fourth secret value, wherein the fourth secret value is a message signed with the private key and using the temporary key, and wherein the fourth secret value is accessible with the aid of a second threshold number of the fourth shares and is inaccessible for a number of the fourth shares that is less than the second threshold number.

[0046] By distributing third shares of the third secret value among the plurality of participants, wherein each third share is suitable for application to a message to generate a corresponding fourth share of a fourth secret value, the message being signed with the private key and the temporary key, wherein the fourth secret value is accessible with the aid of a second threshold number of fourth shares, and is inaccessible for fourth shares less than the second threshold number, this provides the advantage of enabling a large portion of digital signature shares to be generated in advance and applied to messages when fast signing is required. This in turn enables transactions to be signed quickly and non-interactively, and is therefore suitable for use in exchanges.

[0047] The share allocated to each of the participants may be inaccessible to each of the other participants.

[0048] The step of allocating said share to each said participant may comprise providing the or each said participant with a respective encrypted communication channel.

[0049] The first and / or second share may be created with the aid of a corresponding Shamir secret sharing scheme.

[0050] A plurality of said first and / or second shares may be respective values ​​of a first polynomial function, and a corresponding secret value may be determined by deriving said polynomial function from said first threshold number of said shares.

[0051] At least one of said first and / or second secret values ​​may be shared between a plurality of said participants by means of Joint Random Secret Sharing (JRSS).

[0052] Sharing at least one of the third secret values ​​may include sharing a masking share generated by Joint Zero Secret Sharing (JZSS).

[0053] The cryptographic system may be an elliptic curve cryptographic system, wherein the public key in each of the public-private key pairs is related to a corresponding private key by multiplying an elliptic curve generator point by the private key.

[0054] A method for performing a signature of a blockchain transaction may be provided, the method being implemented in a network including a first node, a second node, a third node, and a fourth node, each node having a corresponding public-private key pair in a cryptographic system, and the third node being physically separate from the other three nodes, the method comprising the following steps:

[0055] Distributively generating a plurality of first shares in a first threshold private key so that each node holds a corresponding share;

[0056] creating a first transaction; and,

[0057] Using the share, generating a signature on the first transaction, specifically comprising:

[0058] At the second node, using its corresponding private key and the first transaction to generate a second signature, and sending it to the first node and the third node;

[0059] In the first node:

[0060] verifying the second signature, and,

[0061] In response to successful verification, generate a first partial signature on the first transaction using its corresponding first share, generate a first signature using its corresponding private key and the first transaction, generate a third signature using its corresponding private key and the first partial signature, and send the first partial signature, the first signature, and the third signature to the second node;

[0062] In the third node:

[0063] verifying the second signature, and,

[0064] In response to successful verification, generating a third partial signature on the first transaction using its corresponding first share and sending it to the second node; and,

[0065] At the second node, in response to receiving the signature from the first node:

[0066] verifying the first signature and the third signature, and,

[0067] In response to successful verification, generating a second partial signature on the first transaction using its corresponding first share, and combining the first partial signature, the second partial signature and the third partial signature to generate a signature on the first transaction.

[0068] Optionally, the second signature is a partially blind signature so that certain information included in the first transaction is not provided to the third node.

[0069] Optionally, the method comprises the further step of identifying a first condition in which a signature has not been received from the first node.

[0070] Optionally, the method comprises the further steps of: at the second node: verifying the signature generated on the first transaction using a first threshold public key associated with the first threshold private key, and, in response to a failed verification, identifying a second condition under which the first partial signature may be invalid.

[0071] Optionally, the method includes the following further steps: in response to identifying one of the first condition or the second condition, performing the following steps: at the fourth node, using its corresponding first share to generate a fourth partial signature of the first transaction, and sending it to the second node; and, at the second node, using its corresponding share to generate a second partial signature of the first transaction, and combining the second partial signature, the third partial signature and the fourth partial signature to generate a signature on the first transaction.

[0072] Optionally, the method also includes the following steps: distributively generating multiple second shares of a second threshold private key so that each node holds a corresponding second share, wherein a second threshold public key associated with the second threshold private key is the address of a holding account; creating a second transaction for transferring funds to the holding account; at the second, third and fourth nodes, using the corresponding second shares to generate a partial signature on the second transaction; and, combining the partial signatures to generate a signature on the second transaction.

[0073] Optionally, the method further comprises the following steps: establishing a secure communication channel between the first node and the second node, between the first node and the third node, between the second node and the third node, and between the second node and a fourth node.

[0074] Optionally, the first share is created by means of a corresponding Shamir secret sharing scheme.

[0075] Optionally, a plurality of said first shares are respective values ​​of a first polynomial function, and said first threshold private key may be determined by deriving said polynomial function from a first threshold number of said shares.

[0076] Optionally, the first threshold private key is shared among a plurality of said nodes by means of Joint Random Secret Sharing (JRSS).

[0077] Optionally, the cryptographic system is an elliptic curve cryptographic system, wherein the public key in each of the public-private key pairs is related to the corresponding private key by multiplying an elliptic curve generator point by the private key.

[0078] According to another aspect of the invention, there is provided a computer implemented system for performing the method defined above. BRIEF DESCRIPTION OF THE DRAWINGS

[0079] Embodiments of the present invention will now be described, by way of example only and not in any limiting manner, with reference to the accompanying drawings, in which:

[0080] Figure 1 is a digital signature system embodying the present invention;

[0081] Figure 2 is used to generate Figure 1 The process of digitally signing a share of the process;

[0082] Figure 3 It is caused by Figure 2 The process of generating a digital signature from the shares generated in the process;

[0083] Figure 4 The process of splitting the private key shares is shown;

[0084] Figure 5 The process of performing digital signing in the presence of unresponsive or malicious actors is shown. DETAILED DESCRIPTION

[0085] System Overview

[0086] Reference Figure 1 The system 2 for executing fast signature of blockchain transaction 4 embodying the present invention has four parties in the threshold signature scheme, namely, client 6, exchange party 8, trusted third party (TTP) 10, and custodian 12. Each party has a corresponding elliptic curve public / private key pair (y C ,x C )、(y Ex ,x Ex )、(y T ,x T )、(yEs,x Es ). Compared to the typical "2 of 3" escrow configuration of the prior art, the present invention features an additional party, namely the TTP 10. As explained in more detail below, the TTP 10 is required to participate in the generation of each signature that does not involve the escrow party 12 (in the case of troubleshooting).

[0087] The TTP 10 is required to have a fast (low latency) and reliable connection with the switching parties 8, and the TTP 10 should be physically separate from all other parties.

[0088] Then, secure communication channels capable of encryption and authentication are established between the client 6 and the exchanger 8, the exchanger 8 and the TTP 10, the client 6 and the TTP 10, and the exchanger 8 and the custodian 12. These communication channels establish shared secrets that can be periodically updated without additional communications using the method described in the international patent application WO 2017 / 145016.

[0089] Each party holds a secret key share x of the threshold private key x n; n = 1, 2, 3, 4; According to the method described in more detail below, the shares are generated in a distributed manner (i.e. without a trusted dealer), so the full private key does not exist in a single location. These shares (along with the signature initialization) can be used to generate a partial signature (or signature share) sig on the message m (transaction hash) n ; n = 1,2,3,4. The TTP will provide a partial signature on any transaction in response to a verified request from the exchange party 8. Therefore, the "3 / 4" threshold scheme actually simulates a "2 / 3" multi-signature. Another possibility is to restrict the types of transactions that the TTP 10 will partially sign. For example, the TTP 10 should only sign transactions sent to certain addresses. The advantage of this configuration is that the TTP 10 does not need to know anything about the transaction and can therefore "blindly sign it". In addition, this scheme also most closely mimics the "2 / 3" structure of the third party.

[0090] Assume that parties 2, 3, and 4 employ trusted hardware such that their shares of a threshold private key are generated within a protected "enclave". Messages can be sent to the enclave, and if certain conditions are met, a (partial) signature on the message can be output, but the private key shares never leave the enclave. In this scheme, the threshold private key can be reconstructed given two private key shares. However, when using trusted hardware, such an attack would require long-term physical access to both sets of hardware each time when both hardware contain the same generated key shares. Therefore, such an attack is difficult to implement in practice.

[0091] Basic operations of exchange

[0092] Reference Figure 1 , the high-level functions of Threshold Wallet related to exchange operations are as follows:

[0093] 1. Client 6 deposits some digital asset B into the account associated with the (dealer-less) public key generated by the threshold scheme.

[0094] 2. Perform various trades so that part f of B belongs to customer 6.

[0095] 3. Settlement is requested (either by the client 6 or by the exchanger 8). It can be said that the exchanger 8 requests the settlement and encodes the correct allocation of funds in the transaction T.

[0096] 4.T and Sig(T, x Ex ) is sent by the switching party 8 to the TTP 10.

[0097] 5. If Sig(T, x Ex) is verified, then TTP 10 sends its partial signature on T (denoted as sig3) to the exchange party 8. TTP 10 does not need to know the information contained in T. In fact, from a security point of view, it is better not to know. This can be achieved through a partial blind signature operation.

[0098] 6. At the same time, if the request is considered to be credible (Sig (T, x E ) is verified), and they agree with the content of T, then client 6 will Sig(T, x C )、sig1、Sig(sig1,x C ) is sent to the exchange party 8.

[0099] 7. If the signature is verified, the exchange party 8 combines sig2, sig1, sig3 together and checks whether the signature Sig(T, x) is verified; if so, T, Sig(T, x) is broadcast to the blockchain network.

[0100] Secure Wallet Protocol

[0101] This section describes the protocol for creating a secure wallet and subsequent threshold signature operations. The protocol is described in terms of high-level primitives that are described in detail in R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin, Robust Threshold DSS Signatures, International Conference on Theory and Applications of Cryptographic Techniques, pp. 354-371 (1996).

[0102] Key generation without a dealer

[0103] Creation of a secure wallet is initiated by reinitializing a secure communication channel between the four participants in the scheme (as described in international patent application WO 2017 / 145016).

[0104] The exchange party 8 then coordinates the trader-free generation of a shared elliptic curve public key, where each of the four participants will hold a share of the corresponding secret key (based on a 1st degree polynomial). Two of these four shares are sufficient to reconstruct the private key, but if the key shares are protected in a trusted execution environment, this operation is impossible even if two of the participants collude. The only possible way to authorize the transaction is to generate a threshold signature involving three of the four parties.

[0105] Key generation involves running the Jointly Verifiable Random Secret Sharing (JVRSS) protocol to obtain a key when each party has a share of the polynomial (x i) is created by an exponential interpolation procedure, and the corresponding shared public key y. The exponential interpolation procedure is to recover the shared secret multiplied by at least a threshold number of shares of the elliptic curve generator points, that is, using a similar technique to that used to recover the shared secret from the threshold number of shares (i.e., Lagrange interpolation). By executing Pedersen's protocol [Pedersen 1991], unconditional security verification of the secret shares can be ensured. This process is as follows Figure 2 As shown. Once the key generation has been verifiably performed, the client (or exchange) pays the funds to the shared public key (the corresponding address of y), which is then confirmed by the exchange (or client). It should be noted that the parameter r is calculated from the x coordinate of w0.

[0106] Temporary key sharing

[0107] In order to be able to generate fast and non-interactive signatures for a given transaction, the temporary key (k) share and the secret share necessary to construct the signature can be generated before the signing process. This means that once a signature is required, each party only needs to calculate its signature share (given a specific transaction hash m), and then anyone can broadcast and interpolate said shares to generate the complete signature.

[0108] Figure 2 This "pre-signing" procedure is shown for both the Joint Random Secret Sharing (JRSS) protocol (sharing an unknown random value) and the Joint Zero Secret Sharing (JZSS) protocol (sharing zero with a random share - for masking). Figure 2 The operations shown in are used to jointly calculate the value of r from the temporary key shares without either party knowing the complete temporary key.

[0109] The shared key generation and "pre-signing" configuration described here can be performed in parallel at the same time, thereby significantly saving communication latency.

[0110] Signature generation

[0111] like Figure 3 As shown, the generation of a valid signature (for a shared public key y) requires the agreement of 3 parties (the signature will be interpolated from 3 points on the 2nd degree (t=2) signature share polynomial). In normal operation, the shares will be generated by the client 6, the exchange 8, and the TTP 10. The full signature interpolation method (Lagrangian) can be performed by either party, but in this embodiment is performed by the exchange 8 (or client 6) who will compile the final transaction and broadcast it to the network. Figure 3 Each party is shown to compute a signature share and then broadcast it. This share can be public - containing no information about private or ephemeral key shares, or masked (zero) shares.i Any other identifying information that may arise from this. Appendix 1 describes this in more detail Figure 2 The key sharing scheme for distributing keys and signature shares shown in .

[0112] Customer Key Management

[0113] In addition to the security benefits that come from a no-dealer shared key for protected funds, customer security can be further enhanced by splitting customer key shares. Figure 4 As shown. After the Joint Verifiable Random Secret Sharing (JVRSS) protocol is established, the customer key share (x1) itself can be split into two or three sub-shares. The split is performed according to the protocol described in the international patent application WO 2017 / 145010. After the key share is split, it will be securely deleted. The sub-key shares are then sent to different devices for two-factor authentication (2FA) in order to authorize the transaction signature. Further security enhancements can be achieved by the exchange party storing one of the customer's sub-key shares - therefore, both the customer (via 2FA) and the exchange party need to agree to provide the customer's partial signature.

[0114] Solution in case of malicious / non-responsive party

[0115] Unresponsive customers

[0116] Reference Figure 5 , in which case the exchange party 8 must involve the custodian 12 in order to construct a threshold signature for T. The situation is the same as it would be for a third party. The procedure for convincing the custodian 12 to participate may be relatively slow and involve multiple checks (e.g., to prevent the possibility that the security of the exchange party 8 has been compromised). To increase security, the custodian 12 can be configured to (initially) only provide partial signatures for transactions that move funds to a special "holding account" (recovery address: rec), which must also be protected by a threshold signature, in which case the funds must be held for a period of time. The importance of this account may be known only to the parties to the threshold scheme. For example, if a client is mistakenly considered unresponsive, this precaution will give the client 6 time to intervene.

[0117] Malicious Clients

[0118] Also refer to Figure 5, the malicious client 6 prevents the generation of a valid threshold signature (and therefore the transfer of funds) by providing an invalid signature share (i.e., s1). When the three signature shares are combined together to form the complete signature, it is clear that the signature is incorrect (verification failed using the shared public key). In this case, the first step is to identify which of the three signature shares (s1, s2, or s3) is invalid. This can be done iteratively: the exchange party 8, TTP 10, and custodian 12 can attempt to sign the transaction to the recovery address, and if this fails, a signature share can be generated by the client 6, TTP 10, and custodian 12 (i.e., the exchange party 8 share is malicious). Alternatively, a signature share verification scheme can be adopted.

[0119] The present invention implements a secure wallet service system employed by exchanges that employs a '2 / 3' multi-signature technique to effectively replace (and improve upon) a scheme based on threshold signatures employing polynomial secret sharing. The present invention is also compatible with trade conducted through payment channels because it allows signing at high frequencies (compare, for example, S. Goldfeder, R. Gennaro, H. Kalodner, J. Bonneau, J. A. Kroll, E. W. Felten, and A. Narayanan, Secure Wallets via a New DSA / ECDSA Threshold Signature Scheme (2015) and R. Gennaro et al., Threshold Optimal DSA / ECDSA Signatures and Their Application to Wallet Security (2016), International Conference on Applied Cryptography and Network Security ACNS 2016: Applied Cryptography and Network Security, pp. 156-174).

[0120] The present invention is also robust in the presence of potentially unresponsive exchanges. Because the TTP sees every commitment transaction (and provides its partial signature), the TTP always knows the current channel state; this means that the TTP can collaborate with the custodian and client to provide an ordered soft-parse sequence in the event of an unresponsive exchange, thereby avoiding the "failure mode" described above.

[0121] The present invention also avoids the need for segregated witness by embedding the first commitment transaction in an on-chain transaction to exchange the first commitment transaction. The custodian monitors the blockchain for these transactions and collaborates with the appropriate parties to provide a refund if no relevant transaction is observed before a timeout.

[0122] It should be noted that the availability and security of any of the parties (and therefore, the entire system) can be enhanced by further sharing their private keys and / or shares of threshold private keys among (private) "Congress" members. For example, the custodian can initiate a refund if the required ECT is not observed on the blockchain. In this case, the difficulty of the block can be checked inside the TEE belonging to the conference member, and a ghostchain can be instantiated to construct a (partial) signature of the refund transaction if and only if the commitment transaction has not been observed within a certain number of blocks after funding the channel.

[0123] It should be noted that the above embodiments illustrate rather than limit the present invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention. In the claims, any reference numerals in parentheses shall not be construed as limiting the claims. The words "comprising" and "comprises" and the like do not exclude the presence of elements or steps other than those listed in any claim or in the specification as a whole. In this specification, "comprises" means "includes or consists of", and "comprising" means "includes or consists of". The singular form of an element does not exclude the plural form of such elements, and vice versa. The present invention may be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by the same hardware. The fact that certain measures are cited in mutually different dependent claims does not mean that a combination of these measures cannot be used to advantage.

[0124] Appendix 1 - Detailed description of key share and signature share generation

[0125] Algorithm 1-Key Generation

[0126] Domain parameters (curve, cardinality n, generator points G)

[0127] Input: NA

[0128] Output: Public key Q A

[0129] Private key share d A(1) ,d A(2) ,...,d A(j)

[0130] For a threshold k slices from (j) participants, a constructed key segment d associated with participant (i) and the (j-1) participants designated as participant (h) is constructed A(i), the (j-1) participants are the other parties with whom participant (i) exchanges secrets to sign the keys (and therefore, the transaction).

[0131] In the scenario, j is the total number of participants, where k≤j, and therefore, h=j-1

[0132] Therefore, there exists a (k,j)-threshold sharing scheme.

[0133] The method of Algorithm 1 is as follows:

[0134] 1)(j) Each participant p (i) The ECC public key is exchanged with all other participants, where 1≤i≤j. This address is the group identification address and does not need to be used for any other purpose.

[0135] 2) Each participant p (i) A polynomial f of degree (k-1) with random coefficients is chosen in a way that is confidential to all other parties. i (x).

[0136] This function is subject to the participant's secret The first secret value of the form , which is chosen as the free term of the polynomial. This value is not shared.

[0137] f i (h) is defined as the result of the function, where participant p (i) Select the point (x = h) where f (x) , and participant p (i) The basic equation of is defined as the following function:

[0138]

[0139] In this equation, a0 is the (i) secret and will not be shared.

[0140] Therefore, each participant p (i) There is a secret function f i (x), this function is expressed as a (k-1)th degree polynomial, and its free term is defined as a participant's secret such that:

[0141]

[0142] 3) Each participant p (i) Use P as described above (h) The public key of the participant is used to encrypt The first share f i (h), and exchange P (h) The value of is used for decryption. Each participant Pi , for example, through the international patent application WO

[0143] The method disclosed in 2017 / 145010 is the same as that of each other participant P j Establish corresponding secure encrypted communication channels.

[0144] 4) Each participant P (i ) broadcasts the following value to all participants.

[0145] a)

[0146] b)

[0147] 5) Each participant P (h≠i) Verify the consistency of the received shares with those received from every other participant.

[0148] That is:∑h κ a κ (i) G=f i (h)G and f i (h) G is consistent with the participants' shares.

[0149] 6) Each participant P (h≠i) Confirmed participants (P (h≠i) ) and the received shares are consistent with the other received shares:

[0150]

[0151] In fact, this step consists of i The elliptic curve encryption version of (h) (i.e. f i (h)G) is operated on. If f i If we perform this operation on the unencrypted version of (h), we will recover the secret value a0 (i) , thereby recovering Ga0 (i) Therefore, in the case of the Shamir secret sharing scheme, the coefficient b h represents the Lagrangian interpolation coefficients necessary to recover the secret from the corresponding shares of the secret.

[0152] If not, the participant rejects the protocol and starts over. In addition, since each participant P j Through its own encrypted communication channel with participant P i Communication is performed so that it is possible to identify which participant Pj is associated with any inconsistent shares.

[0153] 7) Participant p (i) Now share itA(i) Calculated as:

[0154]

[0155] in is from each participant P (h≠i) The second share of the corresponding second secret value a0 received

[0156] And among them: SHARE(p (i) )∈Z n and A(j)

[0157] in:

[0158] And wherein the operation Exp-Interpolate() is defined as an operation for recovering an elliptic curve encryption secret from an elliptic curve encryption share.

[0159] return (d A(i) ,Q A )

[0160] Participant (i ) now uses the share to calculate the signature. This role can be taken by any participant or by a party acting as a coordinator in the process of collecting signatures. (c) Participants (c) Each attempt to collect enough shares to sign a transaction can change and does not have to be the same party.

[0161] Therefore, the private key share is created without knowing the shares of other participants

[0162] Algorithm 2-Update private key

[0163] Input: Participant P i The private key d A The share of A(i) .

[0164] Output: Participant P i New private key share d A(i) .

[0165] Algorithm 2 can be used to update private keys and can also be used to add randomness to the protocol.

[0166] 1) Each participant chooses a random polynomial of degree (k-1) with zero as a free term. This is similar to Algorithm 1, but the participant must verify that the selected secret of all other participants is zero.

[0167] Generate zero shares:

[0168] 2)d A(i) ′=d A(i) +z i

[0169] 3) Return: d A(i) '

[0170] The result of this algorithm is a new key share associated with the original private key. Variations on this algorithm can increase the randomness of the first algorithm, or perform a re-sharing operation, thereby generating new key slices without changing the possible addresses. In this way, the present invention allows groups to additionally mask private key shares without changing the underlying private key. This process can be used to minimize any potential key leakage associated with the continued use and deployment of individual key shares without changing the underlying addresses and private keys.

[0171] Algorithm 3-Signature Generation

[0172] Domain parameters: curve, cardinality n, generating point G

[0173] Input: message to be signed e = H(m)

[0174] Private key share

[0175] Output: Signature

[0176] For e = H(m)

[0177] A) Distributed private key generation

[0178] 1) Generate a temporary key share using Algorithm 1:

[0179]

[0180] 2) Generate masked shares using Algorithm 1:

[0181] α i ←Z n

[0182] 3) Generate the masking share using Algorithm 2:

[0183]

[0184] Shares b and c are then kept secret by the participants.

[0185] B) Signature Generation

[0186] 4) e = H(m) confirms the hash of message m

[0187] 5) Broadcast

[0188]

[0189] and

[0190] ω i =G×α i

[0191] 6)

[0192]

[0193] The operation μ=Interpolate(υ1,…,υ j ) mod n is defined as the operation to recover the secret from the shares.

[0194] 7)θ=Exp-Interpolate(ω1,...,ω n )

[0195]

[0196] 8) Calculate (R x ,R y ), where r x,y =(R x ,R y )=θ×μ -1

[0197]

[0198] 9) r=r x =R x modn

[0199] If r=0, restart (i.e. restart from the initial allocation)

[0200] 10) Broadcast S i =D k(i) (e+D A(i) r)+C i mod n

[0201] 11) S = Interpolate(s i ,...,s n )mod n

[0202] If s=0, then Algorithm 3 is repeated from the beginning (A.1).

[0203] 12) Return (r, s)

[0204] 13) Reconstruct the transaction through the (r,s) pair to form a standard transaction.

[0205] References

Claims

1. A method for performing a signature of a blockchain transaction, the method being implemented in a network comprising a first node, a second node, a third node and a fourth node, each node having a corresponding public key-private key pair in a cryptographic system, and the third node being physically separate from the other three nodes, the method comprising the following steps: Distributively generating a plurality of first shares in a first threshold private key so that each node holds a corresponding share; Create the first transaction; as well as Using the share, generate a signature on the first transaction by following the steps below: At the second node, using its corresponding private key and the first transaction to generate a second signature, and sending it to the first node and the third node; In the first node: verifying the second signature, and In response to successful verification, generate a first partial signature on the first transaction using its corresponding first share, generate a first signature using its corresponding private key and the first transaction, generate a third signature using its corresponding private key and the first partial signature, and send the first partial signature, the first signature, and the third signature to the second node; In the third node: verifying the second signature, and In response to successful verification, generating a third partial signature on the first transaction using its corresponding first share and sending it to the second node; as well as At the second node, in response to receiving the signature from the first node: verifying the first signature and the third signature, and In response to successful verification, generating a second partial signature on the first transaction using its corresponding first share, and combining the first, second and third partial signatures to generate a signature on the first transaction.

2. The method of claim 1 , wherein the second signature is a partially blind signature such that the third node is not provided with certain information included in the first transaction.

3. The method according to claim 1, further comprising the steps of: A first condition is identified, the first condition being that a signature has not been received from the first node.

4. The method according to claim 1, further comprising the steps of: At the second node: verifying the signature generated on the first transaction using a first threshold public key associated with the first threshold private key, and In response to the failed verification, a second condition is identified, the second condition being that the first partial signature may be invalid.

5. The method according to claim 1, further comprising the steps of: In response to identifying one of the first condition or the second condition: At the fourth node, using its corresponding first share to generate a fourth partial signature of the first transaction, and sending it to the second node; as well as At the second node, using its corresponding share to generate a second partial signature for the first transaction, and combining the second, third, and fourth partial signatures to generate a signature on the first transaction.

6. The method according to claim 5, further comprising the steps of: generating a plurality of second shares in a second threshold private key in a distributed manner so that each node holds a corresponding second share, wherein a second threshold public key associated with the second threshold private key is an address of a holding account; creating a second transaction for transferring funds to the holding account; At the second, third, and fourth nodes, using corresponding second shares to generate a partial signature on the second transaction; as well as The partial signatures are combined to generate a signature on the second transaction.

7. The method according to claim 1, further comprising the steps of: A secure communication channel is created between the first node and the second node, between the first node and the third node, between the second node and the third node, and between the second node and a fourth node.

8. The method according to claim 1, wherein the first share is created by means of a corresponding Shamir secret sharing scheme.

9. The method of claim 1, wherein a plurality of the first shares are respective values ​​of a first polynomial function, and the first threshold private key can be determined by deriving the polynomial function from a first threshold number of the shares.

10. The method of claim 1, wherein the first threshold private key is shared among the nodes by means of Joint Random Secret Sharing (JRSS).

11. The method of claim 1, wherein the cryptographic system is an elliptic curve cryptographic system, wherein the public key in each of the public-private key pairs is related to a corresponding private key by multiplying an elliptic curve generator point by the private key.

12. A computer implemented system for performing the method according to any preceding claim.

Images