Computer implemented method and system for transferring access to digital asset

Abstract

To provide a method and system for efficiently replacing a secure wallet service system by a scheme based on threshold signatures employing polynomial secret sharing.SOLUTION: In a system 2, a first participant 6 has a first private key of a first private-public key pair of a cryptography system and each participant 6, 8, 10 has a respective first share of a second private key of a second private-public key pair of the cryptography system. Each of the plurality of second participants 8, 10 receives a first blockchain transaction 4 signed with the first private key from the first participant, verifies signature of the first blockchain transaction, and applies respective first share to the first blockchain transaction to generate a respective second share of a second blockchain transaction. The first threshold number of second shares from the first participant and a plurality of the second participants are combined to generate signature of the second blockchain transaction.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates generally to security of data and computer-based resources. More specifically, the present invention relates to cryptocurrencies and cryptography, as well as Elliptic Curve Cryptography, Elliptic Curve Digital Signature Algorithm (ECDSA) and threshold cryptography. The present invention may be advantageously used in connection with blockchain-implemented cryptocurrencies such as Bitcoin (for example), but is not limited in this respect and may have broader applicability. The present invention may be described in one embodiment as providing a threshold digital signature scheme. [Background technology]

[0002] In this application, the term "blockchain" is used to encompass all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. Although reference may be made herein to Bitcoin merely for convenience and illustrative purposes, it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized system composed of blocks, where each block is composed of transactions. Each transaction is a data structure encoding a transfer of control of digital assets among participants in the blockchain system and includes at least one input and at least one output. Each block includes the hash of the previous block, and as a result, the blocks are chained together, creating a permanent and immutable record of all transactions written to the blockchain from its inception.

[0004] The concept of decentralization is fundamental to the Bitcoin approach. Decentralized systems, unlike distributed or centralized systems, offer the advantage of having no single point of failure. Thus, they present an enhanced level of security and fault tolerance. This security is further enhanced by the use of known cryptographic techniques such as elliptic curve cryptography and ECDSA.

[0005] Multi-signature systems are generally used in the Bitcoin blockchain to enhance security by requiring the signatures of two or more parties to provide access to digital assets.

[0006] The ECDSA threshold signature scheme can replace the "multi-signature" system for protecting Bitcoin wallets and can provide improved security and privacy, as well as smaller (and thus less costly) transactions. Non-Patent Document 1 and Non-Patent Document 2 present variations of the threshold-optimal ECDSA signature scheme such that for all 1 < t ≦ n, any t + 1 of the n key-sharing holders can cooperate to interactively generate a complete signature.

[0007] However, these schemes suffer from at least two limitations. First, they rely on new cryptography and related assumptions that have not yet stood the test of time, e.g., fully homomorphic cryptographic schemes. Second, due to their complexity and the involvement of zero-knowledge proofs - e.g., the generation and verification of zero-knowledge proofs alone at write time takes about 10 seconds per participant - they are computationally expensive and therefore slow. As a result, these systems should not be trusted to secure large deposits and are not suitable for certain applications that require rapid signing (such as exchange operations).

[0008] For example, these schemes cannot be used in high-frequency payment channel-based systems, such as those disclosed in [3]. Cryptocurrency exchanges are one application for two-way payment channels, one in which fast signing is particularly desirable.

[0009] While faster, lower-complexity, and more secure schemes exist for the generation of ECDSA threshold signatures, such schemes have certain limitations. In particular, they exclude certain combinations of t and n, including common choices such as the "2 of 3" scheme. Furthermore, in these schemes, it is possible to reconstruct the private key with fewer key shares than are required to generate the signature through the combination of partial signatures. Thus, there is a need for improvements to the secure wallet service systems employed by Bitcoin exchanges that employ the "2 of 3" multi-signature technique.

[0010] Bidirectional payment channels, such as those disclosed in Non-Patent Document 3, can allow assets to be traded while significantly reducing the trust that clients must place in the exchange. In a traditional model, clients may hold deposits of bitcoin and fiat currency with an exchange. As clients trade, the ratio of bitcoin and fiat they own changes. However, these ratios depend on the transactions recorded by the exchange, so clients must trust the exchange to maintain accurate records. In other words, while bitcoin (and fiat, if tokenized) deposits can be protected (to some extent) from theft by employing escrow services, clients can still lose those deposits if the exchange is compromised and records of transactions are lost or altered.

[0011] Bidirectional payment channels suffer from several further drawbacks. Consider a standard implementation of a bidirectional payment channel: Alice and Bob want to send cryptographic tokens between them. They each provide a “2 of 2” multi-signature with an agreed upon number of tokens, and then the tokens are sent by exchanging commitment transactions (the channel is updated) along with a “value” that effectively invalidates the previous state of the channel. If an old commitment transaction is broadcast by one party, the other party can respond with a “breach remedy transaction” containing the appropriate “value”, thereby claiming the entire balance in the channel.

[0012] When either Alice or Bob want to settle the channel, they can each agree to sign a transaction that distributes their balances according to the latest channel state (a so-called "soft resolution"). In this way, the commitment transaction does not need to be broadcast as long as both parties cooperate.

[0013] However, as described in [3], payment channels have a major unresolved vulnerability in that there exists a so-called "failure mode" that can occur if parties with many open channels exhibit unresponsiveness for a long period of time. This can cause other parties connected to them to try to broadcast commitment transactions, which can overwhelm the blockchain network if the number of parties is large. Such a situation is particularly dangerous in the context of payment channels, since a malicious party can try to steal funds by broadcasting old commitment channels, hoping that the connected parties will not be able to respond in time with a breach remedy transaction. Another limitation of the configuration described in [3] is the complexity of needing a Segregated Witness (to avoid the possibility that one of the parties is unwilling or unable to provide the first commitment transaction after the channel has been funded).

[0014] background Latest Exchange Security Many cryptocurrency exchange platforms now employ secure wallet systems based on the multi-signature feature of the Bitcoin script, often via third-party services such as those provided by BitGo. These systems place client or exchange funds under an output that can be redeemed with a "2-of-3" multi-signature script (i.e., by providing a valid signature corresponding to any 2 of 3 public key). The three corresponding private keys will be distributed to the exchange, the client, and a trusted third party / escrow (BitGo). The transfer of funds (via a signed valid transaction) can then be authorized by either i) the client and the exchange, or ii) the exchange and BitGo (if the client has been uncooperative or has lost its keys). The BitGo service will execute the signing operation via an authenticated API request from the exchange.

[0015] This protection system, in addition to the security operations and policies of BitGo itself and its application programming interface (API), has several major drawbacks. First, the use of 2-of-3 multi-signature (multisig) outputs compromises the privacy of both clients and exchanges. The number of 2-of-3 multi-signature transaction outputs is a small fraction of the total number of outputs, and as a result, this reduction in anonymity makes it easier for blockchain observers to identify funds and exchange wallets associated with BitGo. In addition, the use of 2-of-3 multi-signature outputs also reveals internal exchange operations on the blockchain. An external observer can determine which of the three keys was used to authorize a particular transaction based on their position in the script. For example, in the 2016 $60m Bitfinex hack (which employed the 2-of-3 multi-signature BitGo wallet system), Bitcoin blockchain observers were able to determine that keys 1 and 3 were used to steal funds. Furthermore, the use of 2-of-3 multi-signatures results in significantly larger transaction sizes and therefore requires larger transaction (minor) fees to be reliably and quickly confirmed on the blockchain. Also, since 2-of-3 multi-signature scripts are considered "non-standard" in Bitcoin clients, they must be implemented as redeem scripts in the pay-to-script-hash (P2SH) format. P2SH transaction output types are fundamentally less secure than standard pay-to-public-key-hash (P2PKH) outputs, as they can be subject to collision attacks (or so-called "birthday attacks"). P2SH outputs have 160 bits of security in Bitcoin, which means that collision attacks are prevented with only 80 bits of security. This level of security is currently not computationally feasible to attack, but it is not guaranteed to remain so indefinitely.Collision attacks are not possible on the P2PKH output (which uses only a single public key), so it retains 160 bits of security (in the case of a pre-image attack).

[0016] Threshold Signature Scheme Threshold signature protocols allow a group of parties (or nodes) to collaboratively sign transactions using a threshold m of n key shares without reconstructing the private keys at any point in time or without any participant learning anything about any other party's key shares. The use of such a scheme prevents single points of failure in systems that require multiple separate parties to authorize a transaction.

[0017] A threshold signature scheme can be combined with a dealer-free (or dealerless) protocol for establishing secret shares, in which the shared secret (the private key) is not known to any of the parties (indeed, it does not need to be explicitly present in memory at any point). However, it is possible for a group to determine an elliptic curve public key (which corresponds to the not yet known, but implied, shared private key). This means that Bitcoin outputs can be placed under control of the shared group public key (and corresponding address) in a completely trustless manner, and signatures for transactions can be generated only when a threshold number of parties work together, without any of the individual parties learning the private key.

[0018] The mathematical formal properties of the Elliptic Curve Digital Signature Algorithm (ECDSA) mean that it is not common to construct a secure threshold scheme for this type of signature. In particular, it has been proven 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 Non-Patent Document 1, but this scheme has significant drawbacks. First, it is very inefficient: signature generation requires both the implementation of Paillier's (and further homomorphic) encryption and the creation and verification of a series of zero-knowledge proofs: for a 2-of-2 signature, 6 communications and a maximum calculation time of 10 seconds (per party) are required. Second, the private key is shared multiplicatively: this allows only n-of-n key sharing, and implementing an m-of-n scheme with m < n requires a combinatorial key sharing structure where each party needs to hold multiple key shares (each party needs n m key shares). In addition, sharing the private key multiplicatively without a trusted dealer is more complex and computationally expensive than when the key is shared polynomially (such as in Shamir's secret key sharing scheme).

[0019] More recently, improved (but still relatively low-efficiency) threshold optimal ECDSA schemes have been proposed in Non-Patent Document 2 and Non-Patent Document 4 which employ fully homomorphic encryption systems. This cryptographic primitive has high complexity and relies on relatively un-tested assumptions. It should also be noted that other recent fully homomorphic encryption schemes have been the subject of successful cryptanalysis and are effectively broken, as described in Non-Patent Document 5 and Non-Patent Document 6.

Prior Art Documents

[0020] [Non-Patent Document 1] S. Goldfeder, R. Gennaro, H. Kalodner, J. Bonneau, JA Kroll, EW Felten, and A. Narayanan - Securing Bitcoin wallets via a new DSA / ECDSA threshold signature scheme (2015) [Non-Patent Document 2] R. Gennaro et al.. Threshold-optimal DSA / ECDSA signatures and an application to Bitcoin wallet security (2016), International Conference on Applied Cryptography and Network Security. ACNS 2016: Applied Cryptography and Network Security pp 156-174 [Non-Patent Document 3] J Poon; T Dryja; The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments (2016) [Non-Patent Document 4] Boneh, Dan, Rosario Gennaro, and Steven Goldfeder. "Using Level-1 Homomorphic Encryption To Improve Threshold DSA Signatures For Bitcoin Wallet Security." [Non-Patent Document 5] Bogos, Sonia, John Gaspoz, and Serge Vaudenay. "Cryptanalysis of a homomorphic encryption scheme." ArcticCrypt 2016. No. EPFL-CONF-220692. 2016 [Non-Patent Document 6] Hu, Yupu, and Fenghe Wang. "An Attack on a Fully Homomorphic Encryption Scheme." IACR Cryptology ePrint Archive 2012 (2012): 561 Summary of the Invention [Problem to be solved by the invention]

[0021] Preferred embodiments of the present invention seek to overcome one or more of the above-mentioned drawbacks of known schemes. [Means for solving the problem]

[0022] The present invention provides methods and systems as defined in the accompanying claims.

[0023] A method for transferring access to a digital asset may be provided, the method comprising: receiving, by each of a plurality of second participants, a first blockchain transaction from the first participant, the first participant having a first private key of a first private-public key pair of the cryptosystem and each participant having a respective share of a second private key of a second private-public key pair of the cryptosystem, the first blockchain transaction being signed with the first private key; verifying, by a plurality of second participants, that the first blockchain transaction is signed with the first private key; applying respective shares of the second private key to the first blockchain transaction to generate respective shares of a first secret value, the first secret value being the second blockchain transaction signed with the second private key, the first secret value being accessible to a first threshold number of shares of the first secret value and being inaccessible to less than the first threshold number of shares of the first secret value; combining at least a first threshold number of shares of the first secret value from the first participant and a plurality of second participants to generate a first secret value; Includes.

[0024] By applying respective shares of the second private key to the first blockchain transaction to generate respective shares of the second blockchain transaction signed with the second private key, the signed second blockchain transaction having access to a first threshold number of shares of the first secret value and no shares less than the first threshold number, 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 of allowing signing of a transaction should one of the second participants become inactive or uncooperative, thereby improving the security and reliability of the system. Also, by generating shares of the first secret value in response to receiving the first blockchain transaction from the first participant, this provides the further advantage of allowing the shares of the first secret value to be automatically generated such that at least three shares of the first secret value are generated, thereby enabling emulation of a 2 of 3 signature scheme.

[0025] Each of the multiple second participants may have a respective private key of the cryptosystem.

[0026] This provides the advantage of allowing verification of a signature made with a private key by its corresponding public key, thereby enhancing the security of the system.

[0027] The method may further include distributing a shared share of the second private key between the first participant and at least one second participant in possession of the first participant.

[0028] This provides the advantage of additional security.

[0029] The method may further include transferring access to the digital assets to a third private key of the cryptosystem if the second participant becomes unresponsive.

[0030] The digital assets may remain under the control of the third private key for a predetermined amount of time.

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

[0032] A method for transferring access to a digital asset may be provided, the method comprising: sending a first blockchain transaction from a first participant to a plurality of second participants, where the first participant has a first private key of a first private-public key pair of the cryptosystem and each participant has a respective share of a second private key of a second private-public key pair of the cryptosystem, the first blockchain transaction being signed with the first private key; receiving respective shares of a first secret value from a plurality of second participants, the first secret value being a second blockchain transaction signed with a second private key, the first secret value having access to a first threshold number of shares of the first secret value and no shares of the first secret value less than the first threshold number being accessible, each share of the second private key being applied to the second blockchain transaction after verifying by the corresponding second participant that the first blockchain transaction was signed with the first private key; combining at least a first threshold number of shares of the first secret value from the first participant and a plurality of second participants to generate a first secret value; Includes.

[0033] A method for digitally signing a message may be provided, the method comprising: distributing first shares of a first secret value among a plurality of participants, the first secret value being a private key of a public-private key pair of the cryptosystem, the private key being accessible by a first threshold number of the first shares and inaccessible to less than the first threshold number of the first shares; distributing second shares of a second secret value among the multiple participants, the second secret value being an ephemeral key for use in generating digital signatures, the ephemeral key being accessible by a first threshold number of the second shares and not accessible to less than the first threshold number of the second shares; distributing third shares of a third secret value among a plurality of participants, each third share adapted to be applied to a message to generate a respective fourth share of a fourth secret value, the fourth secret value being a message signed with the private key using the short-term key, the fourth secret value being accessible by a second threshold number of the fourth shares and not accessible to less than the second threshold number of the fourth shares; Includes.

[0034] By distributing third shares of a third secret value among a plurality of participants, each third share adapted to be applied to a message to generate a respective fourth share of a fourth secret value, the message being signed with a private key and an ephemeral key, and the fourth secret value being accessible by a second threshold number of the fourth shares and not accessible to less than the second threshold number of the fourth shares, this provides the advantage of allowing a substantial proportion of the digital signature shares to be pre-generated and applied to messages when a fast signing is required. This allows for fast non-interactive signing of transactions and is therefore suitable for use in exchanges.

[0035] The shares distributed to each participant may not be accessible to each other participant.

[0036] The step of distributing the shares to each participant may include providing a respective encrypted communication channel with the or each participant.

[0037] The first and / or second shares may be created according to respective Shamir secret sharing schemes.

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

[0039] At least one of the first and / or second secret values ​​may be shared among multiple participants by joint random secret sharing (JRSS).

[0040] Sharing at least the third secret value may include sharing masking shares generated by joint zero secret sharing (JZSS).

[0041] The cryptosystem may be an elliptic curve cryptosystem, where the public key of each public-private key pair is related to the corresponding private key by multiplication of the private key with an elliptic curve generator point.

[0042] According to a further aspect of the present invention there is provided a computer implemented system for carrying out the method defined above. [Brief description of the drawings]

[0043] Embodiments of the present invention will now be described, by way of example only and not of limitation, with reference to the accompanying drawings, in which: [Figure 1] FIG. 1 illustrates a digital signature system embodying the present invention. [Figure 2A] 2 illustrates a system for generating shares of digital signatures for use in the process of FIG. 1. [Figure 2B] 2 illustrates a system for generating shares of digital signatures for use in the process of FIG. 1. [Diagram 3] FIG. 3 illustrates a process for generating digital signatures from the shares generated by the process of FIG. 2. [Figure 4] FIG. 2 illustrates a process for splitting shares of a private key. [Diagram 5] FIG. 1 illustrates a system for implementing digital signatures in the case of non-responsive or malicious participants. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0044] System Overview Referring to Figure 1, a system 2 embodying the present invention for performing fast signing of blockchain transactions 4 has four parties in a threshold signature scheme: a client 6, an exchange 8, a trusted third party (TTP) 10, and an escrow 12. Each party has a respective elliptic curve public / private key pair (y c ,x c ), (y Ex ,x Ex ), (y T ,x T ), (y Es ,x Es ). Compared to the typical "2 of 3" escrow configuration of the prior art, the present invention features an additional party, the TTP 10. As will be explained in more detail below, the TTP 10 is required to participate in the generation of all signatures that do not involve the escrow 12 (in case of fault resolution).

[0045] The TTP 10 is required to have a high speed (low latency) and reliable connection to the exchange 8, and the TTP 10 should be physically separate from all other parties.

[0046] Secure communication channels enabling both encryption and authentication are established between the client 6 and the exchange 8, between the exchange 8 and the TTP 10, between the client 6 and the TTP 10, and between the exchange 8 and the escrow 12. These communication channels establish shared secrets that can be updated periodically without further communication using methods described in International Patent Application WO2017 / 145016.

[0047] The parties shall share the secret key x n (n=1,2,3,4 for threshold private key x); the shares are generated decentrally (i.e., without a trusted dealer) according to methods described in more detail below, so that the complete private key never exists in a single place. These shares are (along with signature initialization) generated as partial signatures (or signature shares) sign (n=1,2,3,4 in message m) may be used to generate the Bitcoin transaction hash. The TTP would provide a partial signature for any transaction in response to an authenticated request from the exchange. The “3 of 4” threshold scheme would, in effect, emulate a “2 of 3” multi-signature. Another possibility is that there are restrictions on the types of transactions that the TTP will partially sign. For example, the TTP 10 should only sign transactions that it sends to a specific address. This configuration has the advantage that the TTP 10 does not need to know anything about the transaction and can therefore “sign it blind”. This scheme also best mimics BitGo’s “2 of 3” structure.

[0048] Parties 2, 3 and 4 are assumed to use trusted hardware so that their shares in the threshold private key are generated within a protected "enclave". Messages can be sent to the enclave and (partial) signatures on the messages may be output if certain conditions are met, but the private key shares never leave the enclave. In this scheme, given the two private key shares, the threshold private key can be reconstructed. However, with the use of trusted hardware, an attack would require long-term physical access to the two sets of hardware when both hardware pieces contain key shares of the same generation. Thus, such an attack would be very difficult to realize in practice.

[0049] Basic operations of the exchange Referring to Figure 1, the high level functionality of a threshold wallet related to exchange operations is as follows: 1. Client 6 deposits Bitcoin B into an account associated with a (dealerless) public key generated by the threshold scheme. 2. Various transactions are executed, leaving a proportion of B belonging to client 6. 3. Settlement is requested (either by client 6 or by exchange 8). Assume that it is exchange 8 that is requesting settlement, and that the correct distribution of funds has been encoded in transaction T. 4. T and Sig(T, x Ex ) is sent by exchange 8 to TTP 10. 5. Sig(T, x Ex ) verifies, the TTPs 10 send their partial signature on T (denoted as sig3) to the exchange 8. The TTPs 10 do not need to know the information contained within T, and in fact it would be better from a security standpoint if they did not. This can be achieved via a partial blind signing operation. 6. On the other hand, if the request is deemed genuine (Sig(T,x Ex ) is verified) and if they agree on the contents of T, client 6 sends Sig(T,x C ), sig1, Sig(sig1,x C ) to exchange 8. 7. If the signature is verified, exchange 8 concatenates sig2, sig1, and sig3 and checks that the signature Sig(T,x) is verified, and if verified, T, Sig(T,x) is broadcast to the blockchain network.

[0050] Secure Wallet Protocol This section describes the protocol for the creation of a secure wallet and subsequent threshold signature operations. The protocol is described in terms of high-level primitives detailed in "Robust threshold DSS signatures" by R. Gennaro, S. Jarecki, H. Krawczyk and T. Rabin, In International Conference on the Theory and Applications of Cryptographic Techniques, 354-371 (1996).

[0051] Dealer Free Key Generation The creation of a secure wallet begins with the re-initialization of secure communication channels between the four participants in the scheme (as described in International Patent Application WO2017 / 145016).

[0052] Exchange 8 then coordinates the dealer-free generation of shared elliptic curve public keys, where each of the four participants holds a share of the corresponding private key (in a polynomial of degree 1). Two of these four shares are sufficient to reconstruct the private key, but collusion of two of these participants makes this operation impossible if the key shares are protected in a trusted execution environment. The only possible way to authorize a transaction is through the generation of a threshold signature involving three of the four parties.

[0053] Key generation involves running the Joint Verifiable Random Secret Sharing (JVRSS) protocol to create a shared polynomial and a corresponding shared public key y via the Exp-Interpolate procedure, where each party shares (x i ). The Exp-Interpolate procedure is the recovery of the shared secret multiplied by the elliptic curve generator points from at least a threshold number of shares multiplied by the elliptic curve generator points, i.e., using a similar technique used to recover the shared secret from a threshold number of shares (i.e., Lagrange interpolation). Unconditionally secure verification of the secret shares is ensured by running Pedersen's protocol [Pedersen 1991]. This process is illustrated in Figure 2. Once the key generation has been verifiably performed, the client (or exchange) pays funds to the shared public key (y, corresponding Bitcoin address), which is then verified by the exchange (or client). Note that the parameter r is calculated from the x coordinate of w0.

[0054] short-term key sharing To enable fast, non-interactive signature generation for a given transaction, the short-term key (k) shares and secret share multiplications needed to build the signature can be generated prior to the signing procedure. This means that when a signature is requested, each party only needs to compute their signature shares (given a particular transaction hash m), which can then be broadcast and interpolated by anyone to generate the full signature.

[0055] Figure 2 illustrates this "pre-signing" procedure for the Joint Random Secret Sharing (JRSS) protocol (where unknown random values ​​are shared) and the Joint Zero Secret Sharing (JZSS) protocol (where zeros are shared in the random shares used for masking). The operations shown in Figure 2 are performed to jointly compute the value of r from the short-term key shares, without either party learning the complete short-term key.

[0056] The shared key generation and "pre-sign" constructions described herein can be performed simultaneously in parallel, which can result in significant savings in communication latency.

[0057] signature generation As shown in Figure 3, the generation of a valid signature (for a shared public key y) requires the agreement of three parties (the signature is interpolated from three points in a degree-2 (t=2) signature sharing polynomial). In normal operation, shares are generated by the client 6, the exchange 8 and the TTP 10. The full signature interpolation (Lagrangian) can be performed by any party, but in this embodiment it is performed by the exchange 8 (or the client 6) which will compile the final transaction and broadcast it to the network. Figure 3 shows that each party computes a signature share and then broadcasts it. This share can be public - it can be information about the private key or ephemeral key shares or (zero) masking shares c i A more detailed description of the key agreement scheme used to distribute the keys and signature shares shown in FIG.

[0058] Client Key Management In addition to the security benefits from the dealer-free shared key to secure funds, security for the client can be further enhanced by splitting the client key share. This process is illustrated in Figure 4. Once established from the Joint Verifiable Random Secret Sharing (JVRSS) protocol, the client key share (x1) itself can be split into two or three sub-shares. The splitting is performed according to the protocol described in International Patent Application WO2017 / 145010. Once the key shares have been split, they are securely deleted. The sub-shares are then sent to a different device, allowing two-factor authentication (2FA) to allow transaction signing. Further security enhancements can be achieved by the exchange storing one of the client's sub-shares - thus requiring both the client and the exchange (via 2FA) to agree to provide a partial signature for the client.

[0059] Solutions in Case of Malicious / Non-Responsive Parties Unresponsive Clients With reference to FIG. 5, in this case, the exchange 8 must require the escrow 12 to construct a threshold signature on T. The situation is the same as what happens with BitGo. The procedure of convincing the escrow 12 to participate is relatively slow and may involve multiple checks (e.g. to prevent the possibility that the security of the exchange 8 has been compromised). For additional security, the escrow 12 may be configured to provide (initially) only a partial signature for transactions that move funds to a special "holding account" (recovery address, rec) protected under a threshold signature, where the funds must be held for a certain period of time. The importance of this account may only be known to the parties to the threshold scheme. This precaution gives the client 6 time to intervene if it is mistakenly deemed unresponsive.

[0060] Malicious Client Referring also to FIG. 5, a malicious client 6 acts to prevent the generation of a valid threshold signature (and thus the transfer of funds) by providing an invalid signature share (i.e., s1). When the three signature shares are combined to form a full signature, it will be immediately apparent that the signature is incorrect (by failure to verify with 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 8, TTP 10, and escrow 12 can attempt to sign a transaction to the recovery address, and if this fails, signatures can be generated from the client 6, TTP 10, and escrow 12 (i.e., the exchange 8 share is malicious). Alternatively, a signature share verification scheme can be used.

[0061] The present invention allows the Secure Wallet Service system used by Bitcoin exchanges, which uses the "2 of 3" multi-signature technique, to be efficiently replaced (and improved) by a scheme based on threshold signatures with polynomial secret sharing. The present invention also allows for high-frequency signing (as opposed to e.g. Non-Patent Documents 1 and 2), making it compatible with transactions via payment channels.

[0062] The present invention can also be made robust to the possibility of unresponsive exchanges: since the TTP sees (and provides partial signatures for) all commitment transactions, it always knows the current channel state, which allows the TTP, in cooperation with the escrow and the client, to provide an orderly sequence of soft solutions in case an exchange becomes unresponsive, thus avoiding the "failure mode" mentioned above.

[0063] The present invention also avoids the need for a Segregated Witness by replacing the first commitment transaction by incorporating it within the on-chain transaction. The escrow monitors the blockchain for these transactions and cooperates with appropriate parties to provide refunds if the relevant transaction is not observed before a timeout.

[0064] Note that the availability and security of any of the parties (and therefore the system as a whole) can be enhanced by further sharing private keys and / or shares of a threshold private key among members of a (private) "Congress". For example, an escrow may initiate a refund if the required ECT is not observed on the blockchain. In this case, the block difficulty can be checked within a TEE belonging to a member of the Congress, and a Ghostchain may be instantiated to build a (partial) signature for the refund transaction if and only if a commitment transaction is not observed within a certain number of blocks after the channel has been funded.

[0065] It should be noted that the above-described embodiments are illustrative rather than limiting of the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs placed in parentheses shall not be interpreted as limiting the scope of 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 the specification as a whole. In this specification, "comprising" means "including or consisting of" and "comprising" means "including or consisting of". A singular reference of an element does not exclude a plural reference of such element and vice versa. The invention may be implemented by means of hardware comprising several distinct elements and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0066] Appendix 1 - Detailed description of key agreement and key agreement generation Algorithm 1 – Key Generation Domain parameters (CURVE, cardinality n, generator G) Input: NA Output: Public key Q A private key sharing d A(1) ,d A(2) ,...,d A(j) (j) for a threshold of k slices from the participant, a construction key segment d associated with the (j-1) participant designated as participant (i) and participant (h) who is the other party with whom participant (i) exchanges secrets in order to sign keys (and thus Bitcoin transactions); A(i) is constructed. In the scheme, j is the total number of participants, where k≦j, so h=j-1. · Hence, there exists a (k,j)-threshold sharing scheme. The method for Algorithm 1 is as follows: 1) Each participant P in (j) (i) (where 1≦i≦j) exchanges ECC public keys with all other participants. This address is the group identification address and does not need to be used for any other purpose. 2) Each participant P (i) is a polynomial f of degree (k-1) with random coefficients, in a manner secret to all other parties. i Select (x). This function is chosen as a polynomial free term,

number

number

number

number

number

number

number

number

number

number

number

[0067] Algorithm 2 - Private Key Update Input: d A(i) The private key d is denoted as A Participant P i Share of Output: Participant P i New secret key share d A(i) Algorithm 2 can be used to update the private key and add randomness to the protocol. 1) Each participant chooses a random polynomial of degree (k-1) conditional on zero as its free term. This is similar to the algorithm, except that participants must verify that every other participant's chosen secret is zero. Generate a zero share:

number

[0068] Algorithm 3 - Signature Generation Domain parameters: CURVE, cardinality n, generator G) Input: Message to be signed e=H(m) secret key sharing

number

number

number

number

number

number

number

number

number

[0069] References [Table 1]

Claims

1. 1. A method of digitally signing a message, the method comprising: distributing first shares of a first secret value among a plurality of computer systems, the first secret value being a private key of a public-private key pair of a cryptosystem, the private key being accessible by a first threshold number of the first shares and inaccessible to less than the first threshold number of the first shares; distributing second shares of a second secret value among the plurality of computer systems, the second secret value being a short-term key for use in generating digital signatures, the short-term key being accessible by the first threshold number of the second shares and inaccessible to less than the first threshold number of the second shares; distributing third shares of a third secret value among the plurality of computer systems, each of the third shares adapted to be applied to a message to generate a respective fourth share of a fourth secret value, the fourth secret value being the message signed with the private key using the short-term key, the fourth secret value being accessible by a second threshold number of the fourth shares and not accessible to less than the second threshold number of the fourth shares; A method comprising:

2. The shares distributed to each computer system are not accessible to each other computer system; The method of claim 1.

3. the step of distributing shares to each computer system includes providing a respective encrypted communication channel with the or each computer system; The method according to claim 1 or 2.

4. the first share and / or the second share are generated according to a respective Shamir secret sharing scheme; 4. The method according to any one of claims 1 to 3.

5. the first and / or second shares are respective values ​​of a first polynomial function, and a corresponding secret value may be determined by deriving the polynomial function from the first threshold number of shares.

5. The method according to any one of claims 1 to 4.

6. At least one of the first secret value and / or the second secret value is shared among the plurality of computer systems by joint random secret sharing (JRSS).

6. The method according to any one of claims 1 to 5.

7. Sharing at least one of the third secret values ​​includes sharing masking shares generated by joint zero secret sharing (JZSS).

7. The method according to any one of claims 1 to 6.

8. the cryptosystem is an elliptic curve cryptosystem, and the public key of each public-private key pair is related to the corresponding private key by multiplication of the private key with an elliptic curve generator point; 8. The method according to any one of claims 1 to 7.

9. A computer implemented system for performing the method of any one of claims 1 to 8.

Images