Identifying Denial-of-Service Attacks

Abstract

This provides a method for identifying denial-of-service attacks during threshold signature schemes. [Solution] A computer implementation method for identifying a denial-of-service attack between threshold signature schemes, wherein each participant has respective shares of a first and a second shared secret, and the method is performed by a first participant of the group and comprises: calculating a first target share; calculating a target value based on the first target share and a first predetermined amount of other target shares; calculating a target public key corresponding to the target value; calculating a first verification share based on a first share of the first shared secret and the public keys corresponding to the second shared secret; calculating a verification public key based on at least a first verification share and a second predetermined amount of other verification shares; and determining whether at least one other participant is attempting a denial-of-service attack based on whether the verification public key matches the target public key.

Description

[Technical Field]

[0001] This disclosure relates to a method for identifying denial-of-service attacks during threshold signing. [Background technology]

[0002] Public-key cryptography is a type of cryptographic system that uses a key pair: a private key known only to the owner of the private key, and a public key generated based on the corresponding private key and which can be distributed without compromising the security of the private key.

[0003] Public-key cryptography allows a sender to encrypt a message using the recipient's public key (i.e., a public key corresponding to a private key known only to the recipient). The encrypted message can then be decrypted using only the recipient's private key.

[0004] Similarly, a sender may sign a message using their own private key, for example, to prove that the message is being sent by the sender and / or to indicate that the sender agrees to the message. A signer (i.e., the party generating the signature) creates a digital signature on the message using their private key. Anyone with the signer's corresponding public key can use the same message and the digital signature in the message to verify whether the signature was validly made, i.e., whether the signature was indeed made using the signer's private key.

[0005] A digital signature scheme typically involves three steps, or algorithms. A key generation algorithm is used to generate a random private key and its corresponding public key. A signature algorithm is used to generate a signature based on the message and the private key. A verification algorithm is used, given the public key and the message, to verify whether the signature was generated according to the signature algorithm using the corresponding private key.

[0006] A threshold signature scheme allows a threshold number of participants in a group to create a digital signature for (or of) a message using their individual shares of a shared secret key. Here, the digital signature is the signature generated based on the message to be signed. In such a scheme, a signature can only be created if a threshold number of participants agree to generate a signature for the message. Any attempt to generate a signature using fewer participants will not produce a valid signature. Therefore, a valid signature by a group (i.e., a signature generated using the message and the shared secret key) has been provably agreed upon by a threshold number of people to generate the signature. This also implies that any attacker would need to obtain a threshold number of shares of the secret key in order to forge a signature using that secret key.

[0007] A common characteristic of threshold signature shares is that if any of the private key shares are lost, the private key may still be recoverable, provided that a threshold number of shares remain available.

[0008] One specific digital signature algorithm is the Elliptic Curve Digital Signature Algorithm (ECDSA). There are two common threshold schemes for ECDSA signatures. One threshold ECDSA scheme is suboptimal, where a group collectively possesses a shared secret key with a threshold of t+1, but creating a signature requires a much larger threshold of 2t+1. For a detailed explanation, see Gennaro, R et al., "Robust threshold DSS signatures," International Conference on the Theory and Applications of Cryptographic Techniques, Springer, Berlin, Heidelberg, 1996. This scheme will be referred to below as the "suboptimal Gennaro scheme."

[0009] The other general threshold ECDSA scheme is the optimal scheme, where optimal means that the threshold for creating a signature is the same as the threshold for the shared secret key. For a detailed explanation, see Gennaro, R and Goldfeder, S, "Fast multiparty threshold ECDSA with fast trustless setup," Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018. This scheme will be referred to below as the "optimal Gennaro scheme." [Prior art documents] [Patent Documents]

[0010] [Patent Document 1] GB2005953.1 [Patent Document 2] WO2017145010A1 [Non-patent literature]

[0011] [Non-Patent Document 1] Gennaro, R et al., "Robust threshold DSS signatures," International Conference on the Theory and Applications of Cryptographic Techniques, Springer, Berlin, Heidelberg, 1996. [Non-Patent Document 2] Gennaro, R and Goldfeder, S, "Fast multiparty threshold ECDSA with fast trustless setup," Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018. [Overview of the project] [Problems that the invention aims to solve]

[0012] A third threshold ECDSA scheme has been developed by M. Pettit and is described in GB2005953.1. It is a critically optimal threshold scheme like the Gennaro scheme, while possessing the computational, memory capacity, and communication advantages of the non-optimal Gennaro scheme. Details of this scheme are provided below.

[0013] Each of the three threshold signature schemes described above (and threshold signature schemes in general) relies on the participation of at least a number of participants from a group of participants. A valid signature can only be generated if at least a number of participants (i.e., the threshold number) provide valid signature shares. If one or more participants provide invalid (i.e., incorrectly calculated) signature shares, the resulting signature is also invalid. A signature can be invalid in that it cannot be verified using the public key corresponding to the shared secret key.

[0014] As part of calculating each participant's signature share, each participant must use data provided by other participants. Therefore, a malicious participant in a group could choose to provide false data to prevent one or more participants from calculating their respective valid signature shares. Specifically, the malicious participant could correctly set up a shared secret (e.g., a shared secret key) and then send false data that results in the wrong value used in the signature. Previously, the false data would only be captured when a false signature is calculated.

[0015] Depending on the use case, invalid signatures can have severe and detrimental consequences. Generally, invalid signatures cannot be verified, and therefore, the verifying party cannot verify that the party generating the signature is indeed the party that generated it. In the context of blockchain, a valid signature is typically required to allocate (e.g., consume) an unconsumed transaction output (UTXO) of a blockchain transaction. Therefore, UTXOs cannot be allocated without a valid signature. Another example is when a valid signature is required to carry out a vote or similar event that requires a certain number of participants to take action. Therefore, a malicious party may prevent a vote from taking place by refusing to compute a valid signature.

[0016] Generally, malicious actors can carry out denial-of-service attacks by preventing the generation of valid signatures. Therefore, it is desirable to be able to identify such denial-of-service attacks that generate invalid signatures. [Means for solving the problem]

[0017] According to one aspect disclosed herein, a computer implementation method for identifying a denial-of-service attack during a threshold signature scheme is provided, wherein each participant in a group of participants has a respective share of a first shared secret and a respective share of a second shared secret, and the method is performed by the first participant of the group, and comprises calculating a first target share based on at least a first share of the first shared secret and a first share of the second shared secret, wherein the first target share is used to calculate a first signature share of the threshold signature, and calculating a target value based on the first target share and a first predetermined amount of other target shares. The method comprises: calculating, where each other target share is calculated by the respective participant; calculating a target public key corresponding to a target value; calculating a first verification share based on a first share of a first shared secret and a public key corresponding to a second shared secret; calculating a verification public key based on at least a first verification share and a second predetermined amount of other verification shares, where each other verification share is calculated by the respective participant; and determining whether at least one other participant is attempting a denial-of-service attack based on whether the verification public key matches the target public key.

[0018] If all participants are honest and correctly calculate their respective target shares, the verified public key should match (i.e., be equal to) the target public key. If at least one participant is dishonest and calculates an incorrect target share, the verified public key and the target public key will not match. Thus, honest participants can identify the attempted denial-of-service attack and choose not to continue the signature calculation using the target shares. This means that no invalid signatures are calculated, which prevents negative consequences, such as those described above.

[0019] In another aspect disclosed herein, a computer implementation method is provided for identifying a denial-of-service attack during a threshold signature scheme, wherein each participant in a group of participants has a respective share of the shared secret key, a respective share of the ephemeral secret key, a respective share of the first blinding key, and a respective share of the second blinding key, and the method is performed by the first participant in the group to compute a first public key corresponding to a first inverse ephemeral secret key share, the first public key being computed based on i) the inverse of the product of the ephemeral secret key and the first blinding key, and ii) the public key corresponding to the first share of the first blinding key, and corresponding to the pre-signed share Computing a second public key, wherein the second public key is calculated based on i) a public key corresponding to an intermediate value and ii) a public key corresponding to a first share of a second blinding key, the intermediate value being calculated based on i) the inverse of an ephemeral private key, ii) a private key, and iii) a second blinding key; and sending the first public key and the second public key to a cooperating party, the cooperating party having access to a first signature share calculated by the first participant, the first signature share being calculated based on i) a first share of an ephemeral private key, ii) a message, iii) a public key corresponding to a shared private key, and iv) a first share of a second blinding key.

[0020] In another aspect disclosed herein, a computer implementation method for identifying a denial-of-service attack is provided, wherein each participant in a group of participants has a respective share of a private key, a respective share of an ephemeral private key, a respective share of a first blinding key, and a respective share of a second blinding key, and the method is performed by cooperating parties configured to generate signatures based on a threshold number of signature shares, and comprises: receiving a first public key from a first participant, receiving a second public key from a first participant, receiving a first signature share from a first participant, computing a public key corresponding to a first candidate signature share based on i) the first public key, ii) a message, iii) a public key corresponding to a shared ephemeral private key, and iv) the second public key, and determining whether a first participant is attempting a denial-of-service attack based on whether the public key corresponding to the first signature share is consistent with the public key corresponding to the first candidate signature share.

[0021] In another aspect disclosed herein, a computer implementation method for identifying a denial-of-service attack is provided, wherein each participant in a group of participants has a respective share of a private key, a respective share of an ephemeral private key, a respective share of a first blinding key, and a respective share of a second blinding key, and the method is performed by cooperating parties configured to generate signatures based on a threshold number of signature shares, and comprises: computing a first public key corresponding to a first reverse ephemeral private key share of a first participant; computing a second public key corresponding to a pre-signed share of a first participant; receiving a first signature share from a first participant; computing a public key corresponding to a first candidate signature share based on i) the first public key, ii) a message, iii) a public key corresponding to a shared ephemeral private key, and iv) the second public key; and determining whether a first participant is attempting a denial-of-service attack based on whether the public key corresponding to the first signature share is consistent with the public key corresponding to the first candidate signature share.

[0022] References to the accompanying drawings are made merely as examples to aid in understanding the embodiments of this disclosure and to show how such embodiments may be carried out. [Brief explanation of the drawing]

[0023] [Figure 1] This figure schematically illustrates an exemplary system for generating a message signature according to an embodiment of the present invention. [Figure 2] This figure schematically illustrates an exemplary method for generating a message signature share according to an embodiment of the present invention. [Figure 3] This diagram schematically illustrates an exemplary blockchain transaction protocol. [Modes for carrying out the invention]

[0024] Preface to the Cipher Elliptic curves The elliptic curve E is given by the equation y 2 =x 3 +ax+b mod p Satisfying the following conditions, however,

number

number

number

[0025] This group operation can be used to define another operation on the element, called point multiplication, indicated by ·.

number

number

[0026] In elliptic curve cryptography, scalar

number

number

[0027] Elliptic curve digital signature algorithm The following steps are taken to create a signature for message msg using private key a.

[0028] 1. Compute the message digest e = hash(msg) using any hash function. For example, in some cases hash(msg) = SHA256(SHA256(msg)), where SHA256(■) is the SHA-256 hash function. Alternatively, note that the message may be hashed only once, or more than twice using the same or different hash functions.

[0029] 2. Select a random integer k ∈ {1, ..., n - 1}, where n is the order of an elliptic curve, e.g., the secp256k1 curve. Hereinafter, k is called an ephemeral secret key.

[0030] 3. Compute the ephemeral public key corresponding to this ephemeral secret key, k·G = (R x , R y ).

[0031] 4. Compute r = R x mod n. If r = 0, go back to step 2.

[0032] 5. Compute the multiplicative inverse of the ephemeral key, k -1 mod n.

[0033] 6. Compute s = k -1 (e + ar) mod n. If s = 0, go back to step 2.

[0034] 7. The signature for the message msg is (r, s).

[0035] The ephemeral key must be kept secret; otherwise, given the message and the signature, the secret key can be computed. Additionally, a different ephemeral key must be used each time a signature is generated. If this is not the case, given two different signatures and their corresponding messages, it is possible to derive the secret key a.

[0036] Given the message msg, the public key P = a·G, and the corresponding signature (r, s), then the signature can be verified by completing the following steps. 1. Compute the message digest e = hash(msg), e.g., e = SHA256(SHA256(msg)). 2. Compute the multiplicative inverse of s modulo n, s -1 . 3.j1=es -1 mod n and j2=rs -1 Calculate modulo n. 4. Calculate point Q = j1·G + j2·P. 5.

number

number

[0037] In threshold signature schemes, this private key 'a' is divided into key shares that are distributed among the participants in the threshold scheme group.

[0038] Jointly verifiable random secret sharing This scheme assumes that N participants wish to create a shared secret that can only be regenerated by at least (t+1) of the participants. The following steps are taken to create the shared secret.

[0039] 1. Participants agree on a unique label i for each participant. Each participant i is assigned (t+1) random numbers.

number

number

number

[0040] 2. Each participant i uses a secure communication channel with only participant j, for example, to communicate the value f i Send (j) to participant j.

[0041] 3. Each participant i shares their own personal secret of the shared secret polynomial.

number

[0042] The shared secret is in the form (i,a i The point is that it has, where i is the participant label in this scheme. The method for creating a secret share of a as described in Steps 1-3 is used herein to give a to participant i. i =JVRSS(i) is shown. Note that "JVRSS" usually stands for "Joint Verification Random Secret Sharing" and also includes steps 4 and 5. However, throughout this specification, JVRSS is understood to mean performing at least steps 1-3, where steps 4 and 5 are optional.

[0043] Since the participants have generated a shared polynomial, each participant can verify that other participants share accurate information about all participants, and that all participants possess the same shared polynomial. This is done in the following way.

[0044] 4. For each participant i, the obfuscation coefficient is set for k=0,...,t. a ik ·G Broadcast this to all participants.

[0045] 5. Each participant i is f j (i) Calculate G, and

number

[0046] If all participants find that this equation holds true for each polynomial, then the group can collectively be confident that all participants are creating the same shared polynomial.

[0047] Reconstructing the shared secret It is assumed that the participants wish to reconstruct a shared secret a, which is a zero-degree polynomial. (1, a1), ..., ((t+1), a t+1 ) Given (t+1) points on this polynomial, then to find the shared secret a, we derive from a general formula called "Lagrange interpolation".

number

[0048] Public key calculation The public keys a of N zero-degree secret polynomial coefficients for i=1,...,N, shared in step 4 of JVRSS. i0 Given G, each participant corresponds to the shared secret a.

number

[0049] Addition of shared secrets Without any entity knowing the individual secrets, the following steps are taken to calculate the sum of two shared secrets shared among a group of N participants, each secret polynomial having degree t.

[0050] 1. Generate a first shared secret a, where the share of participant i is a for i=1,...,N using a threshold (t+1). i = Given by JVRSS(i).

[0051] 2. Generate a second shared secret b, where participant i's share is calculated using a threshold of (t+1) as b. i = Given by JVRSS(i).

[0052] 3. Each participant i shall have their own additive share ν i =a i +b i mod n Calculate.

[0053] 4. All participants shall share their additive share i Broadcast this to all other participants.

[0054] 5. Each participant will share ν i Interpolate over at least (t+1) of these, ν=interpolate(ν1,...,ν t+1 ) = a + b Calculate.

[0055] This method for adding shared secrets is shown by ADDSS(i) for participant i, resulting in each participant i knowing ν=(a+b).

[0056] Product of shared secrets To compute the product of two shared secrets, both of which are shared among a group of N participants, each secret polynomial having degree t, the group performs the following steps:

[0057] 1. Generate a first shared secret a, where the share of participant i is a for i=1,...,N. i = Given by JVRSS(i). The shared secret polynomial has degree t, meaning that (t+1) participants are required to recreate it.

[0058] 2. Generate a second shared secret b, where participant i's share is b. i = Given by JVRSS(i), the shared secret polynomial again has degree t.

[0059] 3. Each participant, μ i =a i b i Using its own multiplicative share μ i Calculate.

[0060] 4. All participants have their own multiplicative share μ i Broadcast this to all other participants.

[0061] 5. Each participant shares μ in 0. i Interpolate over at least (2t+1) of these, μ = interpolate(μ1, ..., μ 2t+1 )=ab Calculate.

[0062] This method for calculating the product of two shared secrets is shown herein by μ = ab = PROSS(i) for participant i.

[0063] Inverse of a shared secret To compute the inverse of the shared secret a, the following steps are taken.

[0064] 1. All participants calculate the shared secret product PROSS(i), and the result is μ = ab mod n.

[0065] 2. Each participant calculates the remainder inverse of μ, which is, μ -1 =(ab) -1 mod n This is the result.

[0066] 3. Each participant i is:

number

[0067] This method for calculating the inverse of a shared secret is, for participant i,

number

[0068] Generation and verification of shared secret keys To compute a shared secret key a among N≧2t+1 participants, t+1 of them are needed to create a signature, and the participants perform JVRSS with a threshold of t+1 and public key computation as described above. The result is that all participants i=1,...,N share the secret key a. i and possess the corresponding shared public key P=(a·G).

[0069] Ephemeral key share generation To generate the ephemeral key share and corresponding r required for signing, a group of size N having a shared secret key a of threshold (t+1) performs the following steps:

[0070] 1. Reverse sharing of shared secrets

number

[0071] 2. Each participant, ki Using the obfuscation coefficient shared in the verification

number

[0072] 3. Each participant i is:

number

[0073] Identifying Denial-of-Service Attacks Embodiments of the present invention enable the identification of denial-of-service attacks in the context of threshold signatures. Figure 1 shows an exemplary system 100 for generating threshold signatures. A complete description of one exemplary signature scheme is provided below under the heading "Threshold Optimal Signature". While embodiments of the present invention are described with reference to Figure 1, it will be understood that these embodiments are equally applicable to other signature schemes, such as the Gennaro scheme described above.

[0074] Generally, each participant 102 in the group has a share of the shared secret key used to generate their respective shares of signatures. Each participant also has a share of one or more further shared secrets. For example, each participant 102 has a share of the ephemeral secret key and a share of the blinding secret key. The blinding secret key is used to obfuscate various secret keys. In some examples, each participant 102 may also have a share of a second blinding secret key.

[0075] As part of a threshold signature scheme, each participant 102 is generally required to share data with other participants in the group and to retrieve data from other participants in the group for further calculation. Embodiments of the present invention may be used to determine whether the retrieved data is correctly calculated and therefore whether the retrieved data can be used to calculate signature shares.

[0076] The shared data required as part of the calculation of each signature share is called the "target share." That is, each participant 102 that generates a signature share needs the target share from each of the other participants.

[0077] Embodiments of the present invention may be used to determine whether one or more participants have provided incorrect versions of several types of incorrect target shares, i.e., target shares that are not correctly calculated and therefore result in incorrectly signed shares and invalid signatures.

[0078] One type of target share is called a multiplicative share. A multiplicative share is the product of two secret shares, that is, the product of each share of one shared secret and each share of another shared secret. For example, one of the shared secrets may be an ephemeral secret key, and the other may be a blinding key used to blind (obfuscate) the ephemeral secret key.

[0079] Another type of target share is called the intermediate share. The intermediate share is the sum of the secret share and the product of two secret shares, i.e., the sum of the product of i) each share of a given shared secret and ii) each share of two different shared secrets. For example, the three shared secrets may be an ephemeral secret key, a secret key, and a blinding key. Note that the intermediate share can be calculated based on the reverse ephemeral secret key share. Note that the blinding key used to calculate the intermediate share may be a different blinding key than the one used to calculate the multiplicative share, but this is not required.

[0080] The embodiments will be described from the perspective of a first participant 102a, but it will be understood that the same method can be performed by any of the participants 102. The first participant 102a has a first share of the first shared secret and a first share of the second shared secret. The first participant 102a also has a public key corresponding to the first shared secret and a public key corresponding to the second shared secret. The first participant 102a may also have a first share of the third shared secret and a public key corresponding to the third shared secret. Note that "first" is used merely as a distinguishing label and does not necessarily mean the first in a sequence.

[0081] Each other participant also has a share of the first and second shared secrets, and optionally a third shared secret. Each other participant also has a public key corresponding to the shared secret.

[0082] In some examples, part or all of the shared secret may be computed using JVRSS as described above. Other secret-sharing schemes may be used instead. The public key corresponding to the shared secret may be computed using an obfuscation factor shared during JVRSS, i.e., using an obfuscation factor shared during step 4 of the JVRSS method described in the preface. Typically, the obfuscation factor a jk·G is communicated between JVRSS to verify each participant's own share. Here, in this invention, each participant verifies the respective shares of each other participant. Note that the steps of JVRSS are not modified; rather, verification of other participants' shares is added to JVRSS.

[0083] The first participant 102a generates a first target share. The first target share may be generated based on (i.e., a function of) the first share of the first shared secret and the first share of the second shared secret. The target share may also be a function of the first share of the third shared secret. Each other participant generates their respective target share in the same manner using their respective shares.

[0084] The first participant 102a generates the first target value. Note that the first target value is simply an integer. The first target value is generated based on (i.e., a function of) the first target share and a set of target shares generated by other participants. The set of target shares consists of a predetermined number of target shares. The predetermined number is based on the degree of the shared secret, i.e., the degree of the shared secret polynomial. In other words, the first target value requires a predetermined minimum number of each target share to be generated correctly. The first target value may be generated by interpolation over the first target share and the set of target shares.

[0085] Each participant 102 may have its own index, for example, 1, 2, 3, etc. The first participant 102a may generate a first target value using the first target share and the respective target shares from participants that have indices that follow the first participant 102a's index. That is, if the first participant 102a has index 1, the first participant 102a may use the target shares from participants that have indices 2, 3, etc., until it reaches the required number of target shares.

[0086] Each other participant generates their respective target value based on their own target share and a predetermined number of target shares. Depending on the size of the group, one or more participants may generate their own target value based on different sets of target shares.

[0087] The first participant 102a may obtain other target shares directly from each participant, or other participants may broadcast their own shares, or one or more participants may collect target shares and forward them to the first participant 102a. Similarly, the first participant 102a may broadcast the first target share to other participants, or send the first target share directly to individual participants. In general, any communication between participants may take place over a secure communication channel.

[0088] The first participant 102a generates a target public key. The target public key is generated based on (i.e., a function of) the first target value and origin point. Each other participant also generates a target public key based on their respective target value and origin point.

[0089] The first participant 102a generates the first verification share. The first verification share may be generated based on (i.e., a function thereof) the first share of the first shared secret and the public key corresponding to the second shared secret. Each other participant generates their own verification share in the same manner using their respective shares.

[0090] The first participant 102a generates a verifiable public key. The verifiable public key is generated based on (i.e., a function of) the first verifiable share and the set of verifiable shares generated by each participant. The set of verifiable shares consists of a predetermined number of verifiable shares. This predetermined number is based on the degree of the shared secret, i.e., the degree of the shared secret polynomial. In other words, the verifiable key requires a predetermined minimum number of each verifiable share to be generated correctly. The verifiable key may be generated by interpolation over the first verifiable share and the set of verifiable shares. In some examples, the interpolation may be elliptic curve interpolation, i.e., the sum is elliptic curve point addition.

[0091] The first participant 102a may generate a verification public key using the first verification share and the respective verification shares from participants that have indexes following the first participant 102a's index, in a manner similar to how the target value may be generated.

[0092] Each other participant generates their own verification key based on their respective verification share and a predetermined number of verification shares. Depending on the size of the group, one or more participants may generate their own verification key based on different sets of verification shares.

[0093] The first participant 102a may directly obtain other verification shares from other participants. Alternatively, other participants may broadcast their own shares. Alternatively, one or more participants may collect verification shares and forward them to the first participant 102a. Similarly, the first participant 102a may broadcast the first verification share to other participants, or send the first verification share directly to individual participants.

[0094] The first participant 102a then compares the target public key with the verification public key. If the two public keys are not the same, the first participant 102a can be confident that at least one of the target shares has been miscalculated. In some cases, the first participant 102a obtains confirmation from all the other participants that the target public key and verification public key calculated by those participants are the same. In that case, the first participant 102a can be confident that the target shares have been correctly calculated.

[0095] Therefore, the target value can be used to compute the first signature, which is then sent to the coordinator 101. On the other hand, if the target public key is not the same as the verification public key, the first participant 102a knows that at least one of the target shares has been computed incorrectly. The first participant 102a then refrains from using the target value in further computations, thus preventing the computation of an invalid signature.

[0096] Similarly, other participants perform the same comparison.

[0097] The group may have a size of N ≥ 2t+1. The thresholds for the shared secret and threshold signature may be t+1, where t is the degree of the shared secret polynomial. In this example, the first predetermined quantity (i.e., the number of other target shares required to generate the first target value) is 2t, and the second predetermined quantity (i.e., the number of other verification shares required to generate the verification public key) is t.

[0098] If the group has a size of N > 2t + 1, the first participant 102a can identify the participant who provided the wrong target share. To do so, the first participant 102a generates multiple verification public keys. Each of the multiple verification public keys is generated using a different set of verification shares from the first participant and from other participants (still using the required number of verification shares). The first participant 102a then compares the multiple verification public keys. Any verification public key that does not match the majority of the verification public keys has been computed using verification shares provided by a dishonest (i.e., malicious) participant. Thus, the first participant 102a can infer which of the participants is dishonest and therefore provided the wrong target share.

[0099] As described above, the first shared secret may be the first blinding key, and the second shared secret may be the ephemeral secret key. The target value may be a multiplicative key, for example, the product of the first blinding key and the ephemeral secret key (or its inverse).

[0100] In other examples, the first shared secret may be an ephemeral secret key (or its inverse), the second shared secret may be a shared secret key, and the third shared secret may be a second blinding key. The target value may be an intermediate key.

[0101] It is also possible to identify whether participant 102 provided the correct signature share, rather than using the target share or target value to calculate the signature share. In other words, participant 102 can calculate the signature share and provide data that can be used by the coordinator to verify whether the signature share has been calculated correctly. As with the example given above, this method is described from the perspective of the first participant 102a, but it will be understood that any participant can perform the same method.

[0102] The first participant 102a has a share of each of the shared secret keys, the shared ephemeral key, the shared first blinding key, and the shared second blinding key. The shares of the shared keys may be calculated using JVRSS as described elsewhere in this specification. An alternative secret sharing scheme may be used instead.

[0103] Signature shares may be based on each share of the shared ephemeral key (or its inverse), the message, each share of the shared blinding key, the shared secret key, and the public key corresponding to the shared ephemeral secret key. Signature shares may be based on the whole key (rather than key shares), but it should be noted that this does not necessarily mean that participants have access to the whole key, such as the shared secret key.

[0104] Generally, signature share may be calculated as the sum of at least two terms. Each term is calculated based on data that may be publicly known (or at least known to other participants and / or the coordinator), such as the message. Each term is also calculated based on data that should remain private to a given participant, such as each participant's share of the shared key.

[0105] The first participant 102a provides the coordinator 101 with a public key for each signature share item. The public keys correspond to data for each item that is not generally known to the public. Note that the information shared to compute these public keys may be shared among the JVRSS participants. That is, this information is not excluded even though it does not need to be shared separately again by each participant.

[0106] The first participant 102a computes the first public key corresponding to the first inverse ephemeral private key share, i.e., the public key corresponding to the inverse of the first share of the ephemeral private key. The first public key is computed based on (i.e., a function of) the inverse of the ephemeral private key obfuscated using the first blinding key, i.e., the inverse of the ephemeral private key multiplied by the first blinding key. The first public key is also based on the public key corresponding to the first share of the first blinding key. The first participant 102a sends the first public key to the coordinator 101.

[0107] The inverse of the ephemeral secret key, multiplied by the first blinding key, may be calculated based on the respective multiplicative shares provided by each participant. The multiplicative shares are described above. In summary, each participant may calculate a multiplicative share based on the first ephemeral secret key share and the first blinding key share, for example, the first participant 102a calculates the first multiplicative share. The first participant 102a may then calculate a multiplicative key based on the first multiplicative share and the respective multiplicative shares from the other participants. The first participant 102a may then calculate the inverse of the multiplicative key. The first public key is then based on the public key corresponding to the inverse of the multiplicative key.

[0108] The first participant 102a also computes a second public key. The second public key corresponds to the pre-signed share. The second public key is based on (i.e., a function of) the third and fourth public keys. The third public key is the public key corresponding to the intermediate value. The intermediate value is computed based on the inverse of the ephemeral secret key, the shared secret key, and the second blinding key. The fourth public key is the public key corresponding to the first share of the second blinding key. The first participant 102a sends the second public key to the coordinator 101.

[0109] One method for calculating the median value is described above. In summary, the median value may be calculated based on a first median share calculated by a first participant 102a and each median share calculated by the other participants. The first participant 102a may calculate the first median share, which may be calculated based on the inverse of the first ephemeral secret key share, the first secret key share, and the first share of the second blinding key.

[0110] The coordinator may already have access to the signature share calculated by the first participant 102a. Alternatively, the first participant 102a may provide the coordinator with the first and second public keys at the same time as or before providing the first signature share.

[0111] The first signature share is calculated based on the first share of the ephemeral private key, the message, the public key corresponding to the shared ephemeral private key, and the first share of the second blinding key. Coordinator 101 has access to the message and the public key corresponding to the shared ephemeral private key. Coordinator 101 may then use the first and second public keys obtained from the participants, together with the message and the public key corresponding to the shared ephemeral private key, to calculate the public key corresponding to the first candidate signature share, i.e., the obfuscated first candidate signature share (a candidate in the sense that Coordinator 101 does not know at this point whether the public key corresponds to the same first signature share). Coordinator 101 also calculates the public key corresponding to the first signature share, i.e., the signature share provided by the first participant 102a. If the public key corresponding to the first candidate signature share is consistent with the public key corresponding to the first signature share, the coordinator can be confident that the first participant 102a has calculated the correct signature share. The coordinator 101 may then use the first signature share to calculate a signature based on the first signature and one or more additional signature shares from each participant. If the public key corresponding to the first candidate signature share is not consistent with the public key corresponding to the first signature share, the coordinator 101 knows that the first participant 102a has not calculated the correct signature share and may therefore be attempting a denial-of-service attack.

[0112] In some examples, the coordinator may perform this verification check before generating the signature. That is, before the coordinator generates a complete signature based on the participants' signature shares, the coordinator may verify that each participant has correctly calculated their respective signature share. In other examples, the coordinator may perform this verification check after generating the signature. That is, after the coordinator has generated a complete signature, the coordinator may verify that the signature is valid. If the signature is invalid, the coordinator can use the verification check to identify which participant provided an incorrect signature share.

[0113] Note that in some examples, instead of the first participant 102a calculating the first and second public keys and sending them to the coordinator, the coordinator may calculate the first and second public keys on their behalf. This prevents the first participant 102a from sending incorrect values ​​for the first and second public keys. The coordinator 101 may then use the calculated first and second public keys to calculate the public keys corresponding to the candidate signature shares. In this example, the coordinator 101 is one of the participants and calculates the first and second public keys using information shared between each participant's generation of their respective signature shares. For example, the coordinator may use the obfuscation factor shared during step 4 of JVRSS

number

[0114] Further exemplary examples of some embodiments of the present invention are provided herein.

[0115] In both the optimal threshold signature scheme and the non-optimal threshold signature scheme described above (and in more detail below), there are two intermediate calculations before the calculation of signature shares. Currently, there are no steps taken to ensure that participants share the correct values, and therefore, an attacker may contribute incorrect values ​​that could prevent the calculation of a correct signature. The following describes a method for proving that calculations using shares are performed correctly.

[0116] Each participant verifying the calculation must calculate the obfuscated share corresponding to the secret shares of other participants for each shared secret. That is, all participants must use the obfuscation coefficient shared in JVRSS to calculate the share for each participant i.

number

[0117] False multiplicative share capture It is possible to verify that the multiplication of the shared secret is correct. If this cannot be verified, the calculation of the reverse ephemeral key may be incorrect. First, at this point, each participant i has two shares a i and b i Please note that participants are also expected to have knowledge of the corresponding public keys aG and bG. To verify that the multiplication of the two shared secrets is correct, participants will take the following steps.

[0118] 1. Each participant has their own multiplicative share μ i =a i b i and verification share a i The second is to calculate bG and the public key bG corresponding to the shared secret b. i It is a multiplication.

[0119] 2. Each participant i broadcasts these values.

[0120] 3. Participant i is μ = interpolate(μ i ,...,μ i' ) is calculated, where i' is i+2t. That is, each participant calculates the result μ using only themselves and the next 2t shares. If each participant reaches the end of the list of participants in the group and does not yet have 2t+1 shares, they return to the first share in the list and continue from there.

[0121] 4. Each participant uses this result μ to calculate μG.

[0122] 5. Each participant also has abG=ECinterpolate(a i bG,...,a i' Calculate bG), where in this case i' is i+t. That is, each participant calculates the result using themselves and the next t shares. Note that ECinterpolate is the same as interpolate except that the sum is elliptic curve point addition instead of ordinary arithmetic addition.

[0123] 6. Finally, each participant compares abG with μG. If they are the same, each participant knows that μ is equal to ab, and this can be used in the calculation.

[0124] This section explains why it is impossible to successfully deceive using this verification method.

[0125] If participant k wants to deceive, multiply their share by a k b k Send a share that is not correct. If participant k sends an incorrect share, participant k can, without losing generality, k b k +δ k This will result in sending a share that says: Share a i b i If interpolation is performed over a certain range, the following will be calculated:

number

[0126] As shown above, the incorrect result can be written as (ab+δ1)G without loss of generality. From the above equation

number

number

number

number

[0127] In other words, step 3 of the above method is performed using 2t+1 shares. When the group size is 2t+1, there is only one value to calculate abG. However, when the group size is greater than 2t+1, each participant has two or more values ​​to calculate abG. Thus, participants can compare values ​​and see which are the same. The subtlety of revealing any wrong shares lies in the interpolation in step 5. This step only spans t+1 shares, and therefore this reveals whether any wrong shares exist—there are 2t+1 different sets being interpolated over them. And, as motivated above, all that is needed to show whether wrong shares exist is to interpolate two different sets.

[0128] Note that if the group size is 2t+1 and the number of attackers is t, it is not possible to definitively determine the attacker. This is because the correct value can only come from one subset of values, but this subset cannot be determined.

[0129] In threshold signature schemes, a i =α i and b i =k i This verification can be used for multiplication of blinding key shares and ephemeral key shares.

[0130] The capture of the wrong middleman share In the threshold optimization method, there is another value calculated using the share before signing. This is the intermediate share.

number

[0131] 1. Each participant computes their intermediate share λ i = a i b i + c i and the verification share a i bG. The second is the multiplication of a with the public key bG corresponding to the shared secret b. i

[0132] 2. Each participant i broadcasts these values.

[0133] 3. Participant i computes λ = interpolate(λ i ,..., λ i' ), where i' = i + 2t. That is, each participant computes the result λ using only themselves and the next 2t shares. If a participant reaches the end of the list of participants in the group and does not yet have 2t + 1 shares, they return to the first share in the list and continue from there.

[0134] 4. Each participant uses this result λ to compute λG.

[0135] 5. Each participant also computes (ab + c)G = ECinterpolate(a i bG,..., a i' bG) + cG, where i' = i + t, and in this case, i' = i + t. That is, each participant computes the result using themselves and the next t shares. Note that ECinterpolate is the same as interpolate except that the sum is elliptic curve point addition instead of ordinary arithmetic addition.

[0136] 6. Finally, each participant compares (ab + c)G and λG. If they are the same, each participant knows that λ is equal to ab + c and this can be used in the calculation.

[0137] The discussion on why the attacker does not succeed is the same as in the previous section.

[0138] Capture of Incorrect Signature Shares Using the information obtained in JVRSS, if the signature fails verification, it is possible to find an incorrect signature share. This can be done for both the non - optimal and optimal schemes.

[0139] In the case of the non - optimal threshold signature scheme, the following is done.

Number

[0140] In the optimal threshold scheme as described below,

Number

Number

Number

number

number

[0141] Threshold Optimal Signature The following first provides a description of the threshold-optimized ECDSA scheme, which is detailed in GB2005953.1. Embodiments of the present invention may be used to identify denial-of-service attacks when calculating signature shares according to this scheme.

[0142] Figure 1 shows an exemplary system 100 for implementing a threshold-optimized signature scheme, such as a threshold-optimized ECDSA scheme. As shown in the figure, system 100 comprises multiple parties, including a coordinator 101 and a group of participants 102. Although only three participants 102 are shown in Figure 1, it will be understood that the system may generally have any number of participants. Furthermore, although the coordinator 101 is shown as distinct from the participants 102 in Figure 1, in some embodiments the coordinator 101 may also be one of the participants 102, for example, a first participant 102a. Each of the coordinator 101 and participants 102 operates their respective computing equipment.

[0143] Each computing device of each party to System 100 (i.e., Coordinator 101 and Participant 102) comprises its own processing unit, each comprising one or more processors, for example, one or more central processing units (CPUs), accelerator processors (GPUs), application-specific processors, and / or field-programmable gate arrays (FPGAs). Each computing device may also comprise memory, i.e., computer-readable storage in the form of one or more non-temporary computer-readable media. The memory may comprise one or more memory units employing one or more memory media, for example, magnetic media such as hard disks, solid-state drives (SSDs), electronic media such as flash memory or EEPROM, and / or optical media such as optical disc drives. Each computing device may comprise at least one user terminal, for example, a desktop or laptop computer, a tablet, a smartphone, or a wearable device such as a smartwatch. Alternatively or additionally, each computing device may comprise one or more other networked resources, such as cloud computing resources (cloud computing resources comprising resources of one or more physical server devices implemented at one or more sites) accessed via the user terminal. It will be understood that any action described as being performed by a party to System 100 may be performed by each computing device operated by that party.

[0144] Coordinator 101 is the party that initiates the signing process using a threshold number of signature shares generated by each participant in the group of participants 102. That is, Coordinator 101 generates a signature for the message to be signed. Again, it should be noted that generating a signature for a message means that the signature depends on the message to be signed, or in other words, that the signature is a function of the message to be signed. Coordinator 101 may also be the party that signs and optionally sends the message to a third party 103, or otherwise outputs the signature. For example, the third party 103 may be a certificate authority, or other form of authority, or another user. In other examples, the signature may be recorded, for example, in a database or other document. In some examples, the signature may be made available to the public, for example, recorded on a website or other publicly accessible medium.

[0145] Coordinator 101 may send a message to be signed to participant 102. The message may be sent to all participants 102, or to a subset of participants, for example, to a threshold number of participants. In the example in Figure 1, the group of participants consists of three participants 102a, 102b, and 102c. Coordinator 101 may send a message to one participant, who then forwards the message to one, several, or all of the other participants.

[0146] Messages may be transmitted over the Internet using a LAN or WAN connection, or via alternative wired or wireless communication means. Messages may be sent individually to each participant 102, for example, via a secure communication channel between the coordinator 101 and each participant 102, or they may be broadcast to the group as a whole, for example, via email or other means. Messages may be transmitted in raw form or in encrypted form. For example, messages may be hashed once or multiple times.

[0147] One or more of the participants 102 may obtain the message through an alternative means, i.e., not from the coordinator 101. For example, the message may be generated by one of the participants 102, or otherwise, it may be made publicly available, for example. One or more participants 102 may receive the message from a third party 103. A participant 102 that obtains the message may send the message (in raw or encrypted form) to one or more other participants 102. For example, a first participant 102 may send the message to a second participant 102b and / or a third participant 102c.

[0148] Coordinator 101 acquires (for example, receives) a threshold number of signature shares. In the example in Figure 1, the threshold is 2, and only the first participant 102a and the second participant 102b decide to generate their respective signature shares. For example, one or more of the participants 102 that generate signature shares may send their respective shares directly to Coordinator 101, for example, over a secure communication channel. Alternatively, one or more of the participants 102 may broadcast their respective shares and / or make their shares publicly available. As mentioned above, Coordinator 101 may also be a participant. In those embodiments, Coordinator 101 may also generate its own signature shares. In that sense, acquiring at least one of the threshold number of signature shares means generating at least one signature share, and therefore Coordinator 101 does not need to receive more than the threshold number of signature shares.

[0149] To obtain signature shares, Coordinator 101 may send requests for signature shares on the message. For example, Coordinator 101 may send requests for signature shares to one, several, or all of the group of participants 102.

[0150] When the coordinator 101 has obtained at least a threshold number of signature shares, it generates a signature using the obtained shares. The coordinator 101 may then broadcast or transmit the signature to one or more other entities. Additionally or alternatively, the coordinator may store the signature and / or record the signature as part of a digital record, for example, in an email or other document.

[0151] Signature share s i A method for generating is described herein. The method is described from the perspective of a first participant 102a, but it will be understood that each other participant 102 that generates a signature share does so using an equivalent method, even if such other participants 102 use some data specific to themselves.

[0152] Each participant 102 has access to the following data items, namely, their respective secret key share a i (i.e., shares of the same secret key), their respective ephemeral secret key shares k i and a shared common value r generated based on a common ephemeral public key k·G. The common ephemeral public key corresponds to the ephemeral secret key, i.e., is generated based on the ephemeral secret key. Here, a value or key may be common in the sense that each participant has access to the same value or key. Note that, unless otherwise specified, generating a second key based on a first key does not necessarily imply that the first key itself is known. Examples of how these data items may be generated are provided below.

[0153] The first participant 102a either obtains the message to be signed or already has access to the message to be signed. The message may be in its raw form (e.g., plaintext) or in an encrypted or otherwise encoded form (e.g., ciphertext). The first participant 102a may obtain the message (in either form) from the coordinator and / or from another participant 102. Alternatively, the first participant 102a may generate the message to be signed.

[0154] The first participant 102a generates the first signature share s1. In this context, "first" is merely used as an arbitrary label to distinguish a particular participant and a particular signature share from other participants and signature shares, respectively, and the first participant 102a generates the signature share s i Being the first participant to generate, or the first signature share s1 is the signature share s i Note that this does not necessarily imply that it is the first in the ordered list.

[0155] In some embodiments, the first signature share s1 may be generated based on a first message-independent component (MIC) and a first message-dependent component (MDC), i.e., a function of them, where again "first" is used merely as a label. The MIC is generated independently of the message; that is, the MIC is not a function of the message to be signed (i.e., the MIC is not generated based on the message), and no knowledge of the message is required to generate the MIC. In contrast, the MDC is a function of the message to be signed, and knowledge of the message is required to generate the MDC.

[0156] In other embodiments, the first signature does not have to be a function of the first message-independent component (MIC). In these embodiments, the first message-independent component is generated and made available to the coordinator 101, and is, for example, sent to the coordinator 101 or broadcast to one or more participants 102. The first message-independent component (MIC) may be shared with the coordinator prior to and separately from the first signature share.

[0157] The coordinator 101 may obtain each message-independent component (MIC) from at least a threshold number of participants and generate a signature based on each signature share (which is a function of each message-dependent component (MDC)) and each message-independent component (MIC). Further details are provided below.

[0158] Since the MIC does not require knowledge of the message, the MIC can be pre-computed. In other words, the MIC can be generated before the message is received. Thus, multiple different MICs can be pre-computed for use when generating different signature shares s1' for signing different messages, each with a prime symbol (') indicating that it is a different instance of the first signature share.

[0159] If a first signature share s1 is being generated, the first participant 102a makes the first signature share s1 available to the coordinator 101 for generating a signature s for the message. If the first participant 102a is the coordinator 101, making the first signature share s1 available to the coordinator 101 may simply mean outputting the first signature share s1 to a function for generating a signature s. Otherwise, the first participant 102a may send the first signature share s1 to the coordinator 101, or to one or more other participants 102 to forward it to the coordinator 101, or broadcast the first signature share s1, or use a combination of these options.

[0160] As stated above, the first signature share s1 can be generated based on the first MIC and the first MDC. Regardless of whether the first signature share is a function of the first MIC, the first MIC is generated based on (i.e., a function of) the first private key share a1 (i.e., a share of private key a known to the first participant 102a). The first MIC may also be based on the first ephemeral private key share k1 (i.e., a share of ephemeral private key k known to the first participant 102a) and a shared value r generated based on the ephemeral public key k·G corresponding to the ephemeral private key k. The first MDC is generated based on (i.e., a function of) the message (in raw or encrypted form) and can also be generated based on the first ephemeral private key share k1. Variations of the MIC and MDC are provided below.

[0161] Preferably, the first secret key share a1 may be computed using a joint secret sharing scheme, for example, using the JVRSS technique described above. For example, the first participant 102a may have an index of 1, and may generate the first secret key share for participant 1 using a1 = JVRSS(1), where the secret key is denoted by a. Each participant has their own secret key share a i It is permissible to generate a second private key share. For example, the second participant 102b may generate a second private key share for participant 2 using a2=JVRSS(2), and so on.

[0162] Generating the first secret key share a1 using a joint secret sharing scheme is a set of numbers.

number

[0163] The first participant may calculate the corresponding public key a·G based on the set of obfuscation coefficients, where the coefficient is the private key share a of each participant 102. i Used to generate the ephemeral secret key share k. i When generating, each participant 102 has an obfuscation coefficient a ij• G may be shared with each other participant 102. The coefficients are obfuscated by a common generator point G on a selected elliptic curve. These obfuscated coefficients may be transmitted directly among the participants 102 or broadcast to the group. For example, the first participant 102a may send the obfuscated coefficient a 10 ·G, a 11 ·G, a 12 You may broadcast G, etc. The public key corresponding to the private key will then be:

number

[0164] Share private key a i However, please note that it may be generated using an alternative method, i.e., without using the JVRSS method described above. Each participant shall have their own signature shares i A share of private key a is required to generate a private key share, but the specific method for generating the private key share may be chosen to suit a particular scenario, for example, whether some of the participants can be trusted, whether all of the participants can be trusted, or whether none of the participants can be trusted, or whether a trusted dealer is available to deliver the key share. Methods for generating a private key share are essentially known in the art. Similarly, methods for delivering a share of a private key (or other such data) are essentially known in the art. That said, private key share a i It can be generated in several ways. For example, using Shamir's secret sharing scheme, for example, a secret key share a i A dealer (e.g., a coordinator) may be used to generate and deliver one, some, or all of the following: private key share a i One such method that could be used to generate and deliver is described in WO2017145010A1.

[0165] Similarly, the private key share described below, for example, the ephemeral private key share k i, the first blinding value key share α i , and / or second blinding value key share β i When generating some or all of these, alternative forms of JVRSS may be used.

[0166] The first ephemeral secret key share k1 can be computed using a joint secret sharing scheme, for example, using the JVRSS technique described above. For example, the first participant 102a may have an index of 1, and the first ephemeral secret key share may be generated for participant 1 using k1 = JVRSS(1), where the ephemeral secret key is denoted by k. Each participant 102 has their respective ephemeral secret key share k i This can generate a second ephemeral secret key share for participant 2 using k2=JVRSS(2), and so on.

[0167] Generating a first ephemeral secret key share k1 using a joint secret sharing scheme involves the same steps described above for generating a first secret key share a1, except that the random number used to generate the ephemeral secret key share k1 is different from the random number used to generate the secret key share a1.

[0168] The same private key a, and private key share a i This is used for each signature, but the ephemeral secret key k and the ephemeral secret key share k i Please note that this changes with each signature.

[0169] The shared value r is generated based on the ephemeral public key k·G corresponding to the ephemeral private key k. The ephemeral public key (x,y) typically has two components, called the x component and the y component. The shared value r may be a function of the x component of the ephemeral public key, for example, r = x mod n.

[0170] The ephemeral public key k·G may be generated based on a set of obfuscation coefficients, where the coefficients are the respective ephemeral private key shares of each participant 102 k i It was used to generate the ephemeral secret key share k. i When generating, each participant 102 has an obfuscation coefficient k ij • Share G with each other participant 102. The coefficients are obfuscated by a common generator point G on a chosen elliptic curve. These obfuscated coefficients may be transmitted directly among the participants 102 or broadcast to the group. For example, the first participant 102a may share the obfuscated coefficient k 10 G, k 11 G, k 12 You may broadcast G, etc. The ephemeral public key will then be,

number

[0171] In some embodiments, the first MIC is a first inverse share corresponding to the first ephemeral secret key share k1.

number

number

[0172] The first reverse share

number

number

[0173] This means that each participant 102 has a multiplicative share μ i =k i α i This may involve generating α i α is the share of the first blinding key α. Each participant 102 uses a joint secret sharing scheme, for example, using the JVRSS technique described above, to share their respective share of the first blinding key α. i You may calculate the following. For example, the first participant 102a may have an index of 1 and generate a share of the first blinding key for participant 1 using α1 = JVRSS(1). Each participant has their own respective multiplicative share μ (e.g., by sending or broadcasting directly). i Share, and then, for example, by interpolation, multiplicative share μ i An intermediate value μ is generated based on each of the following. First inverse share

number

[0174] The first participant 102a then, for example,

number

number

[0175] Blinding Key Share α i Please note that its use is optional and may be omitted from the steps above.

[0176] Optionally, the MIC can be generated based on (i.e., a function of) a share of the second blinding key β. That is, the MIC is also based on a first share β1 of the second blinding key β, in addition to the data items previously described. The first share of the second blinding key can be computed using a joint secret sharing scheme, for example, using the JVRSS technique described above. For example, a first participant 102a may have an index of 1, and a first share of the second blinding key can be generated for participant 1 using β1 = JVRSS(1), where the second blinding key is denoted by β.

[0177] The MIC may be generated based on a first pre-signed share σ1, the first pre-signed share σ1 being a first intermediate share λ1, and each intermediate share λ obtained from at least a threshold number of participants 102 i It is a function of λ. That is, each of the 102 participants has their own intermediate share λ. i It is possible to generate and their intermediate share λ i The first participant 102a may send and / or broadcast this to other participants 102. The first participant 102a has an intermediate share λ i Collect, for example, the middle share λ i Interpolation can generate a common intermediate value λ. The first participant 102a (and optionally, other participants 102) can each generate multiple pre-signed shares σ1' for use in generating different signed shares s1'.

[0178] The first intermediate share λ1 is the first secret key share a1 and the first inverse share

number

number

[0179] Alternatively, the first intermediate share λ1 may be a function of the first private key share a1 and the first share of the first blinding key α1. In that case, each of at least a threshold number of participants 102 has their own respective private key share a i and each intermediate share λ is a function of each of its own shares of the first blinding key α1. i Generate and share.

[0180] In some embodiments, the first pre-signature share σ1 may also be generated based on the first share of the second blinding key β1. For example, the first intermediate share λ1 may be a function of the first share of the second blinding key β1. In additional or alternative embodiments, the first intermediate share λ1 may also be a function of a common value r.

[0181] Figure 2 shows an exemplary method 200 for generating a signature for a message according to an embodiment of the present invention. Steps S201 to S208 are performed in this example by each of the threshold number of participants 102 (including the first participant 102a). Step S209 is performed by the coordinator 101, which may also be one of the participants performing steps S201 to S208. It will be understood that some of the steps may be omitted or performed in a different order.

[0182] The exemplary method 200 allows for the creation of a shared secret with a threshold of (t+1) in a group of N ≥ 2t+1 participants, where the threshold to be signed is also (t+1).

[0183] set up In step S201, each participant 102 calculates the shared secret key share and the corresponding public key. For example, each participant 102 may calculate the shared secret key and the corresponding public key using the public key calculation given in JVRSS and the preamble. In this regard, each participant i calculates the secret key share and the public key (a i The shared secret key has a threshold value of (t+1).

[0184] Pre-calculation In step S202, each participant 102 calculates the shared ephemeral key share and the corresponding public key. For example, each participant 102 may calculate the shared ephemeral key using the public key calculation given in JVRSS and the preamble. Each participant 102 may then calculate the inverse share based on the ephemeral private key. This means that each participant calculates the inverse share using a threshold of (t+1).

number

[0185] In step S203, each participant 102 creates two different blinding key shares to be shared. For example, each participant 102 creates a blinding key share that participant i shares α i =JVRSS(i) and β i Two shared secrets may be created such that =JVRSS(i), and each shared secret has a threshold (t+1). Note that in some examples, not all shared secrets need to have the same threshold.

[0186] In step S204, each participant 102 calculates their median share and broadcasts their median share to the other participants. For example, each participant i calculates their median share

number

[0187] In step S205, each participant 102 calculates the median based on at least the median share. For example, each participant 102 interpolates over (2t+1) shares λ = interpolate(λ1,...,λ 2t+1 )=k -1 You may use a + β to calculate the intermediate value.

[0188] In step S206, each participant 102 calculates their pre-signature share. For example, each participant i calculates their own pre-signature share σ i =λ-β i =(k -1 a+β)-β i You may calculate this. Each participant 102 is

number

[0189] It should be noted that since a different ephemeral key is used for each signature, multiple ephemeral keys can be set up at once; that is, steps S202-S206 can be iterated through to create multiple ephemeral keys during the pre-computation and stored for later use. These can be performed concurrently without any additional rounds of communication. It should be noted that, preferably, different values ​​of α and β should be used for each signature.

[0190] signature generation To sign the message msg, at least (t+1) participants must perform steps S207 and S208.

[0191] In step S207, at least a threshold number of participants 102 receive the message to be signed and compute the message digest. For example, the coordinator 101 may send requests to (t+1) participants to create a signature share for the message msg. Each participant i may compute the message digest e = hash(msg). In some examples, this hash function is a double SHA-256 hash function. An alternative hash function may be used.

[0192] In step S208, at least a threshold number of participants 102 calculate their signature share and send it to the coordinator 101. For example, each participant i calculates their signature share

number

[0193] In step S209, the coordinator 101 calculates the signature. For example, the coordinator 101 calculates s = interpolate(s1,...,s t+1 )=k -1(e+ar) may be calculated, and the signature (r,s) may be calculated last.

[0194] There are several alternative forms for pre-computing the message-independent component of the signature share. These are two sets of variations, namely, when r should be included in the computation and (kα) -1 It can be broadly divided into cases where it should be included and cases where it should be included. These can be selected independently of each other, and thus there are eight variations of the above method 200.

[0195] One modification is performed during step S206,

number

[0196] Another modification is that the multiplication with r can also come earlier in the calculation of the intermediate share. In step S204,

number

number

[0197] Another form of modification is, λ i =α i a i +β i This involves calculating instead, and as a result, λ=(kα) -1 (αa+β) and σ i =λ-(kα) -1 β iThis is the result. Two variant forms that include r at the alternative point can be performed in combination with this. Each participant has knowledge of kα such that it is calculated in step S202 of the pre-computation. In addition, all participants 102 have their own λ i The shares are broadcast. Therefore, each participant 102 has knowledge of (at least) 2t+1 shares and values ​​kα. The participants then, λ=(kα) -1 ×interpolate(λ1,...,λ 2t+1 ) It is possible to calculate this.

[0198] Another form of modification is the intermediate value and σ as λ=(αa+β). i =λ-β i The pre-signature share is calculated instead. Finally, the signature share is then,

number

number

[0199] In summary, each participant 102 has four secret shares, namely, a i , k i , α i , β i This can generate the product of two values, namely kα and k for use in the signature. In exemplary method 200, the product of two values ​​is obtained, namely kα and kα for use in the signature. -1 a needs to be calculated, and kα is then,

number

number

number

[0200] One version of the above method can be summarized by saying that the signature is computed using a share consisting of a message-independent component (MIC) and a message-dependent component (MDC), where MIC is the pre-signature share σ i Based on this, MDC is based on message e.

[0201] The equality scheme, for example, involves interpolating the signature share, which is made from MDC alone, then calculating the MIC as described above, and then incorporating it into the signature together with the signature share. Clearly, this scheme may be the same up to step S206 of the pre-computation, where the intermediate share includes the r value, i.e.,

number

[0202] At this stage, participants will

number

[0203] Next, in order to generate their own signature share for a given message m, which is then hashed to create a message digest e = hash(m), the participants...

number

[0204] The following variations can be implemented to calculate the message-independent component.

[0205] i) Calculate as follows: λ=k -1 a+β Next, the signature share is as follows:

number

[0206] ii) Calculate as follows: λ = αar + β Next, the signature share is as follows: s i =α i e-β i Then, the signature is generated as follows: s=(kα) -1 (int(s1,...,st+1 )+λ)

[0207] iii) Calculate as follows: λ = αa + β Next, the signature share is as follows:

number

[0208] iv) Calculate as follows: λ = αar + β Next, the signature share is as follows:

number

[0209] v) Calculate as follows: λ = αa + β Next, the signature share is as follows:

number

[0210] One difference between Method 200 and the previous method is the k in the signature. -1 The calculation of term a can be moved into the pre-computation stage. The result of this is that signature generation has the same threshold as private key calculation, and is therefore now threshold-optimal. To understand how the exact signature is found, interpolation over signature shares is performed. s=k-1 e+r(k -1 a+β-β) =k -1 e+r(k -1 a) =k -1 (e+ar) This is the result, and it should be noted that this is a signature that is strictly required.

[0211] It should be noted that the thresholds for secrets can be different. That is, the thresholds for a, k, α, and β themselves do not necessarily need to be the same in order to execute the signature generation scheme. For example, if there is a group of six people and three are needed to create a signature and / or secret key, the threshold for k may be 4 and the thresholds for the other shared secrets may be 3, and they can technically perform the calculation, and they still have a threshold-optimal scheme.

[0212] Note that if blinding secret β is not used, it may be possible to compute the ephemeral key, and therefore the shared secret key, in the following way: Participants simply (k -1 a) is used, and it is assumed that the participants are also aware of r, e, and s. Anyone in the scheme, (s-(k -1 a)r)e -1 =k -1 It is possible to calculate this.

[0213] This result then led to, (k -1 ) -1 (k -1 a)=a It can be used to calculate a shared secret key.

[0214] This calculation cannot be performed by including β in the calculation. Value (k -1 a+β) also contains information about individual secrets, and the result k -1Not a will be leaked. To obtain any information that would reveal the secret key a, at least (t+1) participants, the same number as the secret key threshold, must cooperate, and therefore, calculating this intermediate value λ does not reduce security.

[0215] The problem to be solved using the previous threshold-optimal signature computation is that we must calculate the product of two shared secrets, where the secret is the sum of the individual secrets of all participants in the group.

number

[0216] In a signature, if the private key a is a shared secret, then k must also be a shared secret (otherwise, a can be computed by anyone who knows k). The second term in the signature is then the multiplication of the two shared secrets, which is the part that makes achieving optimality difficult. In the non-optimal scheme by Gennaro et al., and in the exemplary method 200 described above, these secrets are each degree 0 polynomials of degree t, and multiplying the polynomials together results in a threshold share of 2t+1 being required to compute the result of the multiplication. To ensure fairness in this scheme, most communications can be broadcast and simple equivalence can be checked. Additionally, if one participant withdraws from the signature computation, it is easy for another participant to contribute.

[0217] In the threshold optimization method by Gennaro et al., this threshold of 2t+1 is avoided by individually calculating each term in the secret product. That is, for each pair of participants i, j, each individual term a i0 k j0The results are calculated and summed. An ephemeral key k is created during the signing process, and then the product of these individual secret contributions is calculated using Pallier cryptography. This requires that each participant must communicate individually with all other signers. To ensure fairness in this case, several zero-knowledge proofs must be performed. In this case, if a participant withdraws from the signature calculation, the signing algorithm must be restarted.

[0218] In other words, each secret is the sum of individual secrets, and the multiplication of two secrets is, a 10 b 10 +a 20 b 10 +...b n0 a n0 It is a multiplication of the sums of two individual terms, which can be extended and expanded as follows.

[0219] The Gennaro method calculates these terms individually. That is, participant 1 calculates a together with participant 2. 20 b 10 We must calculate a, and together with participant 3 30 b 10 This must be calculated, and so on. These are then all summed up together. Each of these individual calculations involves a computationally expensive zero-knowledge proof. Therefore, as soon as there are many people in this scheme, it becomes inefficient. This is also because everything is done at the signing stage, and therefore it is a computationally expensive way to calculate the signature.

[0220] In a simple example involving three participants, the number of communication rounds is roughly equivalent between the two methods (i.e., the optimal threshold method by Gennaro et al., and exemplary method 200), but the Gennaro method has more, and this is not where the main efficiency savings lie. The savings lie in the volume of data computed and communicated. Gennaro's method must include multiple zero-knowledge proofs (ZKPs) that are not present in exemplary method 200.

[0221] The following compares the two-of-three method implemented using the optimal thresholding scheme by Gennaro et al. with exemplary method 200. In Gennaro's method, there are additional encryption keys to be created for JVRSS and Pallier's encryption before signing. Then there are seven ZKPs to be created and seven ZKPs to be verified in the signature calculation. These ZKPs cannot be sent simultaneously, and therefore there are multiple rounds of communication in the signing stage. In addition, in several steps, each participant must communicate individually with all the other participants in the signing stage, which is inefficient. This means that all of those participants must be online at the same time. In contrast, the present invention allows a given participant to calculate signature shares without requiring other participants to be online.

[0222] On the other hand, in the method described above, there are four JVRSS calculations at the pre-signing stage, and there is no ZKP in any respect. The JVRSS calculations can be performed simultaneously, and therefore the communication is the same as a single JVRSS. At the signing stage, there is only request-response type communication, and all information can be broadcast to the group.

[0223] To compare the storage capacities of the two methods, note that in the above method, the ephemeral key is computed along with the setup stage. This means that more storage capacity is required compared to Gennaro's method. In the method described above, for example, 32 bytes of storage space are required for each of the three additional values ​​that need to be stored, corresponding to creating the signature. This is minimal considering efficiency savings in computation and communication, as well as achieving optimality.

[0224] In summary, Gennaro's scheme reduces the memory capacity required after setup and pre-computation, but increases the computation and communication during signature computation. This is because, in Gennaro's scheme, it is inefficient to move more of the computation to pre-signing. In particular, when the inequality N≧2t+1 is acceptable, the scheme of the present invention is more efficient than Gennaro's optimal scheme.

[0225] Example use cases of threshold signatures In general, the present invention can be used to generate a signature for any message. In a particular exemplary use case, the message may be part or all of a blockchain transaction. That is, the signature can be used to sign one or more inputs and / or one or more outputs of a blockchain transaction.

[0226] Figure 3 shows an exemplary transaction protocol for use as part of a blockchain protocol. While exemplary blockchain protocols are well documented in the literature, here, for completeness, is a description of an exemplary protocol transaction. This is an example of a UTXO-based protocol. A transaction 152 (abbreviated as "Tx") is the fundamental data structure of the blockchain (each block of the blockchain contains one or more transactions 152). The following is described by reference to output-based or "UTXO"-based protocols; however, this is not limiting to all possible embodiments.

[0227] In a UTXO-based model, each transaction ("Tx") 152 comprises a data structure having one or more inputs 202 and one or more outputs 203. Each output 203 may have an unspent transaction output (UTXO) which can be used as a source for the input 202 of another new transaction (if the UTXO has not already been redeemed). The UTXO contains a value that specifies the amount of digital tokens, for example, representing the amount of a digital asset. This represents the number of sets of tokens on the ledger (to be delivered). The UTXO may also contain, among other information, the transaction ID of the transaction from which the UTXO originated. The transaction data structure may also comprise a header 201 which may contain an indicator of the size of the input fields 202 and the output fields 203. The header 201 may also contain the ID of the transaction. In an embodiment, the transaction ID is a hash of the transaction data (excluding the transaction ID itself) and is stored in the header 201 of the raw transaction 152 submitted to the miner.

[0228] A first user, for example, Alice, wishes to create transaction 152j to transfer a certain amount of digital tokens to a second user, for example, Bob. In Figure 3, Alice's new transaction 152j is labeled "Tx1". It removes the amount of digital tokens locked against Alice in the output 203 of the preceding transaction 152i in the sequence and transfers at least some of these to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 3. Tx0 and Tx1 are merely arbitrary labels. They do not necessarily mean that Tx0 is the first transaction in the blockchain, nor that Tx1 is the next transaction in the pool. Tx1 could point backward to any preceding (i.e., an antecedent) transaction that still has unspent output 203 locked against Alice.

[0229] By the time Alice creates her new transaction Tx1, or at least by the time she sends it to network 106, the preceding transaction Tx0 may already be valid and contained within the blockchain. It may already be contained within one of the blocks at that time, or it may still be waiting in pool 154, in which case it will soon be contained within a new block. Alternatively, Tx0 and Tx1 may be created together and sent to the blockchain network, or Tx0 may even be sent after Tx1 if the node protocol allows buffering of “orphan” transactions. As used herein in the context of transaction sequences, the terms “preceding” and “following” refer to the order of transactions in a sequence (e.g., which transaction points to which other transactions behind it), as defined by the transaction pointers specified within the transactions. These can be replaced with "predecessor" and "successor," or "ancestor" and "descendant," "parent" and "child," or equivalent. This does not necessarily imply the order in which they are created, sent to the network, or arrive at any given node. However, a subsequent transaction (descendant transaction or "child") pointing to a preceding transaction (ancestor transaction or "parent") will not be valid until the parent transaction is valid, and unless the parent transaction is valid. A child that arrives at a node before its parent is considered an orphan. Orphans may be discarded or buffered for some time to wait for a parent, depending on the node protocol and / or miner behavior.

[0230] One of the one or more outputs 203 of the preceding transaction Tx0 contains a specific UTXO, here labeled UTXO0. Each UTXO contains a value specifying the amount of the digital tokens represented by the UTXO, and a lock script defining the conditions that must be met by the unlock script in the subsequent transaction's input 202 for the subsequent transaction to be valid and therefore for the UTXO to be successfully redeemed. Typically, the lock script locks its amount for a specific party (the beneficiary of the transaction in which the lock script is contained). That is, the lock script typically defines unlock conditions, which include the condition that the unlock script in the subsequent transaction's input contains the cryptographic signature of the party to whom the preceding transaction is locked.

[0231] A lock script (also known as scriptPubKey) is a snippet of code written in a domain-specific language recognized by the Node protocol. A specific example of such a language is called "Script" (uppercase S). The lock script specifies what information is needed to consume transaction output 203, for example, the requirements for Alice's signature. The unlock script appears in the transaction output. The unlock script (also known as scriptSig) is a snippet of code written in a domain-specific language that provides the information needed to satisfy the lock script criteria. For example, it may include Bob's signature. The unlock script appears in transaction input 202.

[0232] Therefore, in the illustrated example, UTXO0 in output 203 of Tx0 is the lock script [Checksig P A ] equipped with lock script [Checksig P A ] is for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be valid) Alice's signature Sig P A [Checksig PA ] is the public key P from Alice's public-private key pair. A The input 202 of Tx1 includes a pointer that points backward to Tx1 (by its transaction ID, i.e., TxID0, which is, for example, the hash of the entire transaction Tx0 in the embodiment). The input 202 of Tx1 includes an index that identifies UTXO0 within Tx0 for identifying it among any other possible outputs of Tx0. The input 202 of Tx1 includes the unlock script <Sig P A >Furthermore, it includes an unlock script <Sig P A > features Alice's cryptographic signature, created by Alice applying her private key from a key pair to a default portion of the data (sometimes called the "message" in cryptography). What data (or "message") needs to be signed by Alice to provide a valid signature can be defined by a lock script, a node protocol, or a combination of these.

[0233] When a new transaction Tx1 arrives at a node, the node applies the node protocol. This involves executing a lock script and an unlock script together and checking whether the unlock script satisfies a condition defined in the lock script (where this condition may consist of one or more criteria). In embodiments, this means concatenating the two scripts, i.e., <Sig P A > <P A > || [Checksig P A ] This is accompanied by, where "||" represents concatenation, "<...>" means the location of the data on the stack, and "[...]" is a function provided by the unlock script (in this example, a stack-based language). Equivalently, the scripts may be executed one after another using a common stack rather than concatenating them. In either case, when executed together, the scripts contain Alice's public key P, which is included in the lock script in the output of Tx0.A This is used to authenticate that the lock script in the input of Tx1 contains Alice's signature, which signs the expected portion of the data. The expected portion of the data itself ("message") must also be contained within Tx0 in order to perform this authentication. In the embodiment, the signed data comprises the entirety of Tx0 (and therefore must contain a separate element that specifies the signed portion of the data in the plain text, which already essentially exists).

[0234] The details of authentication using public-secret cryptography will be familiar to those skilled in the art. Essentially, if Alice signs a message by encrypting it using her private key, then given Alice's public key and the message in plain text (the unencrypted message), another entity, such as a node on a blockchain network, can authenticate that the encrypted version of the message must have been signed by Alice. Signing typically involves hashing the message, signing the hash, and tagging it as a signature on the plain text version of the message, thus enabling any holder of the public key to authenticate the signature. Therefore, it should be noted that any reference herein to signing a particular piece of data or part of a transaction or such may, in embodiments, mean signing a hash of such a piece of data or part of a transaction.

[0235] A blockchain node considers Tx1 valid if the unlock script in Tx1 satisfies one or more conditions specified in the lock script of Tx0 (for example, in the illustrated example, Alice's signature is provided and authenticated in Tx1). If it is a mining node, this means that the mining node adds Tx1 to the pool of transactions awaiting proof of work. If it is a transfer node, the transfer node transfers transaction Tx1 to one or more other nodes in the blockchain network, and as a result, transaction Tx1 is propagated throughout the network. Once Tx1 is valid and included in the blockchain, this defines UTXO0 from Tx0 as consumed. Note that Tx1 can only be valid if it consumes an unconsumed transaction output 203. If it attempts to consume an output that has already been consumed by another transaction, Tx1 is invalid, even if all other conditions are met. Therefore, node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been consumed (i.e., has already formed a valid input to another valid transaction). This is one reason why enforcing a predefined order on transactions is important for blockchain 150. In practice, a given node 104 could maintain a separate database marking which UTXO 203 has been consumed in which transaction, but ultimately, what defines whether a UTXO has been consumed is whether it has already formed a valid input to another valid transaction in the blockchain.

[0236] If the total amount specified in all outputs 203 of a given transaction is greater than the total amount indicated by all inputs 202, this is another criterion for invalidity in most transaction models. Therefore, such a transaction is not propagated and is not mined into a block.

[0237] Please note that script code is often expressed in a general way (i.e., not in an exact language). For example, [Checksig P A ] = OP_DUP OP_HASH160 <H(P A )> OP_EQUALVERIFY OP_CHECKSIG means [Checksig P A You can write ]. "OP_..." refers to a specific opcode in the Script language. OP_CHECKSIG (also called "Checksig") is a Script opcode that takes two inputs (signature and public key) and verifies the validity of the signature using the Elliptic Curve Digital Signature Algorithm (ECDSA). At runtime, any occurrence of the signature ("sig") is removed from the script, but additional requirements such as a hash puzzle remain in the transaction that are verified by the "sig" input. As another example, OP_RETURN is a Script language opcode for creating an immutable output of a transaction that can store metadata within the transaction, thereby immutably recording the metadata in the blockchain. For example, the metadata could consist of documents that you would like to be stored in the blockchain.

[0238] signature P A This is a digital signature. In embodiments, this is based on ECDSA using the elliptic curve secp256k1. A digital signature signs a specific fragment of data. In embodiments, for a given transaction, the signature signs a portion of the transaction input and all or part of the transaction output. The specific portion of the output it signs depends on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature for selecting which output is signed (and therefore fixed at the time of signing).

[0239] A lock script is sometimes called a "scriptPubKey" when referring to the fact that each transaction contains the public key of the party being locked for that person. An unlock script is sometimes called a "scriptSig" when referring to the fact that an unlock script supplies the corresponding signature. However, more generally, it is not always necessary in all blockchain applications that the condition for a UTXO to be redeemed includes authenticating a signature. More generally, a scripting language can be used to define any one or more conditions. Thus, the more general terms "lock script" and "unlock script" may be preferred.

[0240] According to some embodiments of the present invention, a signature generated by the coordinator 101 may be used to sign a blockchain transaction. For example, the generated signature may be used, at least in part, to unlock the output of a blockchain transaction. In a particular example, the output of a previous transaction may be a pay-to-public-key-hash (P2PKH) output that is locked against the hash of the public key. In order to be unlocked, the input of a later transaction that references the P2PKH output must include the (unhashed) public key and a signature generated based on the private key corresponding to the public key.

[0241] When expressed within a script, the "lock script" and "unlock script" may take the following forms: Locking script = OP_DUP OP_HASH160<Public KeyHash> OP_EQUAL OP_CHECKSIG Unlocking script = <signature><Public Key>

[0242] Referring to the above-described embodiment,<Public Key> This can be considered equivalent to P=a·G, <signature>This has a threshold signature s, where the previous transaction is the message to be signed. Note that, as mentioned above, the ECDSA signature takes the form (r,s).

[0243] It should be noted that the signature generation method described is not limited to any specific use case and may generally be used to generate signatures based on any message. Signing all or part of a blockchain transaction is just one example. The method described may be used, for example, to sign and / or authenticate legal documents (e.g., wills, seals, or other contracts), letters between one or more parties, digital certificates (e.g., issued by a certificate authority), medical prescriptions, bank transfers or financial instruments, mortgage or loan applications, etc.

[0244] As a specific example, a group of participants (for example, a total of five participants) may form a company's board of directors. The company's voting decisions may require the agreement of a majority of the board members (i.e., at least three participants) on a particular vote. The board may use the signature generation method described to prove that at least three board members have agreed to vote in favor of a particular outcome. In this example, the threshold for the signature generation method is 3; that is, at least three of the board members must provide their respective signature shares for the coordinator to successfully generate the signatures. If the signatures are successfully generated, then at least the threshold number (i.e., three) of board members must have agreed to vote in favor of that outcome. Thus, the successful generation of signatures serves as a record of the vote, proving in a specific way that a majority of the board members voted.

[0245] Another use case for the present invention lies in the field of digital certificates, such as those issued under the X.509 standard. A digital certificate contains a signature that signs over several pieces of data. The data can generally be arbitrary, but one example of specific data to be included in a digital certificate is a public key. The public key in a digital certificate is often called a “certified public key.” The issuer of a digital certificate (a “certificate authority”) may perform one or more checks on the owner of the public key (for example, a “know-your-customer” check), and if the checks are successful, the certificate authority issues a digital certificate containing the certified public key. A user can use a certified public key to prove that they are who they say they are, for example, by signing a message with the private key that corresponds to the certified public key.

[0246] One specific use for a Certificate Authority (CA) is signing certificates used in HTTPS for secure browsing on the internet. Another common use is when a central government issues identity certificates for use in electronically signing documents. A CA uses a private key to sign a public key (or any other data to be certified). This introduces a single point of failure: if a malicious party can gain access to the private key used by the CA to issue a digital certificate, the malicious party can then issue a fraudulent certificate. A specific example of a CA being targeted is DigiNotar, a Dutch CA. The private key used by DigiNotar was compromised in 2011 and used to issue fraudulent certificates. This attack was possible because the attacker only needed to obtain a single piece of data, namely the private key. However, if the CA (DigiNotar) had used the threshold signing scheme according to the present invention, this attack would no longer be possible (or at least much more difficult). In order to issue a certificate, an attacker must acquire a threshold number of key shares (or signature shares) required to generate a signature.

[0247] It should be understood that the embodiments described above are merely illustrative. More generally, methods, apparatus, or programs may be provided by any one or more of the following statements.

[0248] Statement 1. A computer implementation method for identifying a denial-of-service attack during a threshold signature scheme, wherein each participant in a group of participants has a respective share of a first shared secret and a respective share of a second shared secret, and the method is performed by the first participant in the group, and comprises: calculating a first target share based on at least a first share of the first shared secret and a first share of the second shared secret, the first target share being used to calculate a first signature share of a threshold signature, and calculating a target value based on the first target share and a first predetermined amount of other target shares. This comprises calculating each other target share, which is calculated by each participant; calculating a target public key corresponding to a target value; calculating a first verification share based on a first share of a first shared secret and a public key corresponding to a second shared secret; and calculating a verification public key based on at least a first verification share and a second predetermined amount of other verification shares, wherein each other verification share is calculated by each participant; and determining whether at least one other participant is attempting a denial-of-service attack based on whether the verification public key matches the target public key.

[0249] To generate a digital signature, a different threshold number of signature shares is required from each participant in the group of participants.

[0250] The target value may be calculated by interpolating over a first target share and a first predetermined amount of other target shares. The verification public key may be calculated by performing elliptic curve interpolation over a first verification share and a second predetermined amount of other verification shares.

[0251] Statement 2. The method of Statement 1, comprising sharing the first target share and the first verification share with other participants in the group.

[0252] Statement 3. The method of Statement 2, wherein the sharing comprises broadcasting the first target share and / or the first verification share to other participants in the group.

[0253] Alternatively, the first target share and / or the first verification share may be sent directly to each other participant, for example, via their respective secure communication channels.

[0254] Statement 4. A method of any of the statements described above, comprising obtaining a first predetermined amount of other target shares from each participant and obtaining a second predetermined amount of other verification shares from each participant.

[0255] Statement 5. The first share of the first shared secret is calculated by the method of any of the statements above, by performing a first instance of the Jointly Verified Random Secret Sharing Scheme (JVRSS) with the group of participants.

[0256] Statement 6. The first share of the second shared secret is calculated by performing a second instance of JVRSS with the group of participants, using the method of any of the statements described above.

[0257] Statement 7. The method of Statement 6, wherein the public key corresponding to the second shared secret is calculated based on the obfuscation coefficient shared by each participant when the second instance of JVRSS is executed.

[0258] Statement 8. A method of any of the statements described above, wherein each participant is associated with the respective index of the sequence, a first predetermined amount of other target shares is calculated by those other participants having their respective indices following the index of the first participant, and a second predetermined amount of other verification shares is calculated by those other participants having their respective indices following the index of the first participant.

[0259] Statement 9. The method of any of the statements above, wherein the group has size N ≥ 2t+1, the threshold of the first shared secret and threshold signature is t+1, and t is the degree of the first shared secret, where t is the degree of the shared secret polynomial.

[0260] In some examples, the first and second shared secrets may have different thresholds. In some examples, the first shared secret and the threshold signature may have different thresholds. For example, the threshold of the threshold signature may be greater than the threshold of the first shared secret. For example, the threshold of the signature may be t+2, and the threshold of the first shared secret may be t+1.

[0261] Statement 10. The method of Statement 9, wherein the first predetermined amount is 2t and the second predetermined amount is t.

[0262] Statement 11. A method of Statement 9 or Statement 10, wherein the group has size N > 2t + 1, and the calculation of a verifiable public key comprises calculating a plurality of verifiable public keys, each verifiable public key calculated on a first verifiable share and a different second predetermined amount of other verifiable shares, and the method comprises comparing each of the plurality of verifiable public keys and identifying at least one participant attempting a denial-of-service attack, such that the verifiable public key that does not match at least one of the other verifiable public keys is the participant whose respective verifiable share brings.

[0263] Statement 12. In any of the above-mentioned methods of statement, the first shared secret is the first blinding key, the second shared secret is the ephemeral key, and the first target share is the multiplicative share.

[0264] Statement 13. In any of the methods of Statements 1 to 11, each participant in the group of participants has their respective share of the third shared secret, the first target share is calculated based on the first share of the first shared secret, and the verification public key is calculated based on the public key corresponding to the third shared secret.

[0265] Statement 14. The method of Statement 13, wherein the first shared secret is the reverse ephemeral key, the second shared secret is the secret key, the third shared secret is the second blinding key, and the first target share is the first intermediate share.

[0266] Statement 15. The first share of the third shared secret is calculated by the method of Statement 13 or Statement 14, by performing a third instance of JVRSS with the group of participants.

[0267] Statement 16. The method of Statement 6, wherein the public key corresponding to the third shared secret is calculated based on the obfuscation coefficient shared by each participant when the third instance of JVRSS is executed.

[0268] Statement 17. A method of any of the statements described above, comprising using only the first target share and / or target value to compute the first signature share, provided that the verified public key matches the target public key.

[0269] For example, a multiplicative share may be used to calculate the inverse ephemeral key share.

[0270] Statement 18. Computer equipment, A memory comprising one or more memory units, The system comprises a processing unit having one or more processing units, and the memory stores code configured to run on the processing unit, and the code is configured to execute one of the methods of statements 1 to 17 when run on the processing unit.

[0271] Statement 19. A computer program that is implemented on computer-readable storage and is configured to perform any of the methods described in Statements 1 to 17 when executed on a computer device.

[0272] Statement 20. A computer implementation method for identifying a denial-of-service attack between threshold signature schemes, wherein each participant in a group of participants has a respective share of a shared secret key, a respective share of an ephemeral secret key, a respective share of a first blinding key, and a respective share of a second blinding key, and the method is performed by the first participant in the group, and comprises computing a first public key corresponding to a first inverse ephemeral secret key share, the first public key being computed based on i) the inverse of the product of the ephemeral secret key and the first blinding key, and ii) the public key corresponding to the first share of the first blinding key, and the second public key corresponding to the pre-signed share. Computing a key, wherein a second public key is calculated based on i) a public key corresponding to an intermediate value, and ii) a public key corresponding to a first share of a second blinding key, wherein the intermediate value is calculated based on i) the inverse of an ephemeral private key, ii) a private key, and iii) a second blinding key; and sending the first public key and the second public key to a cooperating party, wherein the cooperating party has access to a first signature share calculated by the first participant, wherein the first signature share is calculated based on i) a first share of an ephemeral private key, ii) a message, iii) a public key corresponding to a shared private key, and iv) a first share of a second blinding key.

[0273] Statement 21. The method of Statement 20, wherein part or all of each share is calculated using the respective instance of the Jointly Verifiable Random Secret Sharing (JVRSS) scheme.

[0274] Statement 22. The method of Statement 21 or Statement 22, comprising computing the inverse of the product of the ephemeral secret key and the first blinding key.

[0275] Statement 23. A method of any of the statements described above, comprising calculating a median value based on the first median share and the respective median shares from each of the other participants.

[0276] Statement 24. The method of Statement 23, comprising computing a public key corresponding to an intermediate value.

[0277] Statement 25. A method of any of the preceding statements, comprising computing a public key corresponding to a first share of a first blinding key.

[0278] Statement 26. A method of any of the preceding statements, comprising computing a public key corresponding to a first share of a second blinding key.

[0279] Statement 27. A method of any of the statements described above, comprising calculating a first signature share and sending the first signature share to the cooperating parties.

[0280] Statement 28. Any of the aforementioned methods of making a statement, comprising obtaining a message from the coordinating parties.

[0281] Statement 29. A method comprising generating a message using any of the methods described in Statements 20 to 28.

[0282] Statement 30. A method of any of the statements described above, comprising computing a public key corresponding to a shared ephemeral private key, wherein the first signature share is based on a first coordinate, e.g., the x-coordinate, of the public key corresponding to the shared ephemeral private key.

[0283] Statement 31. A computer implementation method for identifying a denial-of-service attack, wherein each participant in a group of participants has a respective share of a private key, a respective share of an ephemeral private key, a respective share of a first blinding key, and a respective share of a second blinding key, and the method is performed by cooperating parties configured to generate signatures based on a threshold number of signature shares, and comprises: receiving a first public key from a first participant, receiving a second public key from a first participant, receiving a first signature share from a first participant, computing a public key corresponding to a first candidate signature share based on i) the first public key, ii) a message, iii) a public key corresponding to a shared ephemeral private key, and iv) the second public key, and determining whether a first participant is attempting a denial-of-service attack based on whether the public key corresponding to the first signature share is consistent with the public key corresponding to the first candidate signature share.

[0284] For example, the public key corresponding to the first candidate signature share is generated by obfuscating the first candidate signature share using the source point G.

[0285] Statement 32. A computer implementation method for identifying a denial-of-service attack, wherein each participant in a group of participants has a respective share of a private key, a respective share of an ephemeral private key, a respective share of a first blinding key, and a respective share of a second blinding key, and the method is performed by cooperating parties configured to generate signatures based on a threshold number of signature shares, and comprises: computing a first public key corresponding to a first reverse ephemeral private key share of a first participant; computing a second public key corresponding to a first pre-signed share of a first participant; receiving a first signature share from a first participant; computing a public key corresponding to a first candidate signature share based on i) the first public key, ii) a message, iii) a public key corresponding to a shared ephemeral private key, and iv) the second public key; and determining whether a first participant is attempting a denial-of-service attack based on whether the public key corresponding to the first signature share is consistent with the public key corresponding to the first candidate signature share.

[0286] The coordinator may compute the first public key and the second public key for some or all of the other participants. This allows the coordinator to determine whether those other participants are attempting a denial-of-service attack.

[0287] Those who cooperate can be participants in the group.

[0288] Statement 33. The method of Statement 31 or Statement 32, comprising using the first signature share to compute a signature based on the first signature and one or more additional signature shares computed by each participant in the group, provided that the public key corresponding to the first signature is consistent with the public key corresponding to the first candidate signature share.

[0289] Statement 34. The method of Statement 33, comprising using a first signature share to compute a signature based on a first signature share and one or more additional signature shares computed by each participant of the group, wherein the first signature share is received prior to the reception or computation of the first public key and the second public key, and comprising determining whether the signature is an invalid signature, and in response to the determination that the signature is an invalid signature, performing the determination whether the first participant is attempting a denial-of-service attack.

[0290] Statement 35. The method of Statement 34, wherein the determination of whether a signature is an invalid signature comprises verifying the signature against the public key corresponding to the shared private key.

[0291] Statement 36. A computer device comprising a memory having one or more memory units and a processing unit having one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code is configured to execute any of the methods in Statements 20 to 35 when executed on the processing unit.

[0292] Statement 37. A computer program that is implemented on computer-readable storage and is configured to perform any of the methods described in Statements 20 to 35 when executed on a computer device.

[0293] Another aspect disclosed herein may provide a method comprising the actions of a first participant, some or all of the other participants, and some or all of the coordinators.

[0294] In other embodiments disclosed herein, a system may be provided comprising computer equipment of the first participant, some or all of the other participants, and some or all of the coordinators.

[0295] As the disclosures herein are given, other variations or uses of the techniques disclosed may become apparent to those skilled in the art. The scope of this disclosure is limited only to the appended claims and not to the embodiments described herein. [Explanation of Symbols]

[0296] 100 Systems 101 Coordinator 102 participants 103 Third party 152 transactions 201 Header 202 Input, Input Field 203 Output, Output Fields< / signature> < / signature>

Claims

1. A computer implementation method for identifying a denial-of-service attack during a threshold signature scheme, wherein each participant in a group of participants has a share of a first shared secret and a share of a second shared secret, and the method is performed by the first participant in the group. A step of calculating a first target share based on at least a first share of the first shared secret and a first share of the second shared secret, wherein the first target share is used to calculate a first signature share of a threshold signature. A step of calculating a target value based on the first target share and a first predetermined amount of other target shares, wherein each of the other target shares is calculated by the respective participant. The steps include: calculating the target public key corresponding to the aforementioned target value, A step of calculating a first verification share based on the first share of the first shared secret and the public key corresponding to the second shared secret, A step of calculating a verified public key based on at least the first verification share and a second predetermined amount of other verification shares, wherein each of the other verification shares is calculated by the respective participant, The process includes the step of determining whether at least one other participant is attempting a denial-of-service attack, based on whether the verification public key matches the target public key. Computer implementation method.

2. The method according to claim 1, further comprising the step of sharing the first target share and the first verification share with the other participants in the group.

3. The method according to claim 2, wherein the sharing comprises the step of broadcasting the first target share and / or the first verification share to the other participants in the group.

4. The steps include obtaining the first predetermined amount of other target shares from each of the aforementioned participants, The steps include obtaining a second predetermined amount of other verification shares from each of the aforementioned participants, The method according to any one of claims 1 to 3, comprising:

5. The method according to any one of claims 1 to 4, wherein the first share of the first shared secret is calculated by performing a first instance of a Jointly Verified Random Secret Sharing Scheme (JVRSS) with the group of participants.

6. The method according to any one of claims 1 to 5, wherein the first share of the second shared secret is calculated by performing a second instance of JVRSS with the group of participants.

7. The method according to claim 6, wherein the public key corresponding to the second shared secret is calculated based on an obfuscation coefficient shared by each participant when the second instance of JVRSS is executed.

8. The method according to any one of claims 1 to 7, wherein each participant is associated with a respective index of the sequence, and the first predetermined amount of other target shares is calculated by those other participants having their respective indices that follow the first participant's index, and the second predetermined amount of other verification shares is calculated by those other participants having their respective indices that follow the first participant's index.

9. The method according to any one of claims 1 to 8, wherein the group has a size N ≥ 2t+1, the threshold of the first shared secret and the threshold signature is t+1, and t is the degree of the first shared secret.

10. The method according to claim 9, wherein the first predetermined amount is 2t and the second predetermined amount is t.

11. The group has a size N > 2t + 1, and the calculation of the verified public key comprises the step of calculating a plurality of verified public keys, each verified public key being calculated based on the first verified share and a different second predetermined amount of other verified shares, and the method is The steps include comparing each of the aforementioned multiple verification public keys, The method comprises the step of identifying at least one participant attempting a denial-of-service attack, where each of the verification shares of a verification public key is inconsistent with at least one other verification public key, The method according to claim 9 or 10.

12. The method according to any one of claims 1 to 11, wherein the first shared secret is a first blinding key, the second shared secret is an ephemeral key, and the first target share is a multiplicative share.

13. The method according to any one of claims 1 to 11, wherein each participant in the group of participants has a share of the third shared secret, the first target share is calculated based on the first share of the first shared secret, and the verification public key is calculated based on the public key corresponding to the third shared secret.

14. The method according to claim 13, wherein the first shared secret is a reverse ephemeral key, the second shared secret is a secret key, the third shared secret is a second blinding key, and the first target share is a first intermediate share.

15. The method according to claim 13 or 14, wherein the first share of the third shared secret is calculated by performing a third instance of JVRSS with the group of participants.

16. The method according to claim 6, wherein the public key corresponding to the third shared secret is calculated based on an obfuscation coefficient shared by each participant when the third instance of JVRSS is executed.

17. The method according to any one of claims 1 to 16, comprising the step of using only the first target share and / or the target value to calculate the first signature share, provided that the verification public key matches the target public key.

18. Computer equipment, A memory comprising one or more memory units, A processing unit comprising one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code is configured to perform the method according to any one of claims 1 to 17 when executed on the processing unit, Computer equipment.

19. A computer program that is implemented on computer-readable storage and configured to perform the method described in any one of claims 1 to 17 when executed on a computer device.

20. A computer implementation method for identifying a denial-of-service attack during a threshold signature scheme, wherein each participant in a group of participants has a share of the shared secret key, a share of the ephemeral secret key, a share of the first blinding key, and a share of the second blinding key, and the method is performed by the first participant of the group. A step of computing a first public key corresponding to a first inverse ephemeral private key share, wherein the first public key is computed based on i) the inverse of the product of the ephemeral private key and the first blinding key, and ii) the public key corresponding to a first share of the first blinding key. A step of calculating a second public key corresponding to a pre-signed share, wherein the second public key is calculated based on i) a public key corresponding to an intermediate value, and ii) a public key corresponding to a first share of the second blinding key, wherein the intermediate value is based on i) the inverse of the ephemeral private key, ii) the private key, and iii) the second blinding key. A step of sending the first public key and the second public key to a cooperating party, wherein the cooperating party has access to a first signature share calculated by the first participant, the first signature share being calculated based on i) a first share of the ephemeral private key, ii) a message, iii) a public key corresponding to the shared private key, and iv) a first share of the second blinding key, Computer implementation method.

21. The method according to claim 20, wherein some or all of the aforementioned shares are calculated using each instance of the Jointly Verifiable Random Secret Sharing (JVRSS) scheme.

22. The method according to claim 20 or 21, further comprising the step of calculating the inverse of the product of the ephemeral secret key and the first blinding key.

23. The method according to any one of claims 1 to 22, comprising the step of calculating the median value based on a first median share and each median share from the other participants.

24. The method according to claim 23, further comprising the step of calculating the public key corresponding to the intermediate value.

25. The method according to any one of claims 1 to 24, comprising the step of calculating the public key corresponding to the first share of the first blinding key.

26. The method according to any one of claims 1 to 25, comprising the step of calculating the public key corresponding to the first share of the second blinding key.

27. The first step of calculating the signature share, The step of sending the first signature share to the aforementioned cooperating parties, The method according to any one of claims 1 to 26, comprising:

28. The method according to any one of claims 1 to 27, further comprising the step of obtaining the message from the cooperating party.

29. The method according to any one of claims 20 to 28, further comprising the step of generating the message.

30. The method according to any one of claims 1 to 29, comprising the step of calculating the public key corresponding to the shared ephemeral private key, wherein the first signature share is based on the first coordinates of the public key corresponding to the shared ephemeral private key.

31. A computer implementation method for identifying a denial-of-service attack, wherein each participant in a group of participants has a share of a private key, a share of an ephemeral private key, a share of a first blinding key, and a share of a second blinding key, and the method is performed by cooperating parties and is configured to generate signatures based on a threshold number of signature shares. The steps include receiving the first public key from the first participant, The steps include receiving a second public key from the first participant, The steps include receiving a first signature share from the first participant, i) the first public key, ii) the message, iii) the public key corresponding to the shared ephemeral private key, and iv) the steps of calculating a public key corresponding to a first candidate signature share based on the second public key, The method includes the step of determining whether the first participant is attempting a denial-of-service attack based on whether the public key corresponding to the first signature share is consistent with the public key corresponding to the first candidate signature share. Computer implementation method.

32. A computer implementation method for identifying a denial-of-service attack, wherein each participant in a group of participants has a share of a private key, a share of an ephemeral private key, a share of a first blinding key, and a share of a second blinding key, and the method is performed by cooperating parties and is configured to generate signatures based on a threshold number of signature shares. A step of calculating a first public key corresponding to the first reverse ephemeral private key share of the first participant, The steps include: calculating a second public key corresponding to the pre-signed share of the first participant; The steps include receiving a first signature share from the first participant, i) the first public key, ii) the message, iii) the public key corresponding to the shared ephemeral private key, and iv) the steps of calculating a public key corresponding to a first candidate signature share based on the second public key, The method includes the step of determining whether the first participant is attempting a denial-of-service attack based on whether the public key corresponding to the first signature share is consistent with the public key corresponding to the first candidate signature share. Computer implementation method.

33. The method according to claim 31 or 32, further comprising the step of using the first signature share to compute a signature based on the first signature and one or more additional signature shares computed by each participant in the group, provided that the public key corresponding to the first signature is consistent with the public key corresponding to the first candidate signature share.

34. A step of using the first signature share to calculate a signature based on the first signature share and one or more additional signature shares calculated by each participant in the group, wherein the first signature share is received before the receipt or calculation of the first public key and the second public key. A step of determining whether the aforementioned signature is an invalid signature, In response to the determination that the signature is an invalid signature, the step of making the determination of whether the first participant is attempting a denial-of-service attack: The method according to claim 33, comprising:

35. The method according to claim 34, wherein the determination of whether the signature is an invalid signature comprises the step of verifying the signature against the public key corresponding to the shared secret key.

36. Computer equipment, A memory comprising one or more memory units, A processing unit comprising one or more processing units, wherein the memory stores code configured to be executed on the processing unit, and the code is configured to perform the method according to any one of claims 20 to 35 when executed on the processing unit, Computer equipment.

37. A computer program that is implemented on computer-readable storage and configured to perform the method described in any one of claims 20 to 35 when executed on a computer device.

Images