Threshold key exchange

Abstract

A computer-implemented method for generating a shared encryption key based on at least one shared secret, wherein each participant in a first group has a respective share of a first secret, the first secret having a first threshold and a corresponding first public key, and a second coordinator has a second public key corresponding to the second secret, and the second coordinator is configured to generate an identical shared encryption key.

Description

Technical Field

[0001] This disclosure relates to a method for generating a shared encryption key.

Background Art

[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 that can be disseminated without compromising the security of the private key.

[0003] Public-key cryptography enables a sender to encrypt a message using the recipient's public key (i.e., the public key corresponding to the recipient's private key known only to the recipient). The encrypted message can then be decrypted only using the recipient's private key. This type of encryption is known as asymmetric encryption.

[0004] An alternative to asymmetric encryption is symmetric encryption. Here, only one key (a secret key) is used for both encrypting and decrypting a message (any data). Entities communicating via symmetric encryption must exchange the key so that it can be used in the decryption process.

[0005] Returning to public-key cryptography, a sender can sign a message, for example, to prove that the message was sent by the same sender and / or to indicate that the same sender agrees to the message, using their own private key. The signer (i.e., the party generating the signature) uses their private key to create a digital signature for the message. Anyone having the signer's corresponding public key can use the same message and the digital signature for the message to verify whether the signature was validly created, i.e., whether the signature was indeed made using the signer's private key.

[0006] Digital signature schemes typically involve three procedures, namely, algorithms. A key generation algorithm is used to generate a random secret key and a corresponding public key. A signature algorithm is used to generate a signature based on the message and the secret key. A verification algorithm is used to verify whether a signature was generated using the corresponding secret key and in accordance with the signature algorithm, assuming the public key and the message.

[0007] Threshold cryptography refers to a cryptographic system that distributes shares (sometimes called slices) of a secret key among multiple participants. A threshold (i.e., minimum) number of those shares is required to recreate the secret key. Depending on the particular system used, the secret key can be first generated and then split into shares, or the shares of the secret key can be generated without an existing secret key. A message can be encrypted with the corresponding public key. A threshold number of participants must cooperate to decrypt the message.

[0008] A threshold signature scheme enables a threshold number of participants within a group to create a digital signature for a message (i.e., of the message) using their individual shares of a shared secret key. Here, the digital signature is a signature generated based on the message to be signed. In such a scheme, a signature can be created only 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. Thus, a valid signature by the group (i.e., one generated using the message and the shared secret key) implies that a threshold number of people agreed to generate the signature. This also implicitly indicates that any adversary would need to obtain a threshold number of shares of the secret key to forge a signature with that secret key. A common feature of threshold signature shares is that the secret key can still be restored, provided that any one of the secret key shares is lost and a threshold number of shares are still available.

[0009] Diffie-Hellman key exchange refers to a protocol for generating a shared cryptographic key. The protocol can be summarized as follows: The first party and the second party each have their own private-public key pair. The public keys are known to each party. The first party can compute the shared key based on the elliptic curve multiplication of the first party's private key and the second party's public key. The second party can compute the same shared key based on the elliptic curve multiplication of the second party's private key and the first party's public key. This allows both parties to compute the same shared key without disclosing personal information. Only two parties can compute the shared key because only they know their respective private keys. [Prior art documents] [Patent Documents]

[0010] [Patent Document 1] WO2017145010A1 [Overview of the project] [Problems that the invention aims to solve]

[0011] A problem with existing Diffie-Hellman (DH) key exchange methods is that they introduce a single point of failure. That is, if one party's private key is compromised by an attacker (or even accidentally revealed), the shared key can be obtained (assuming the public keys of the other parties are known, which is usually the case). Therefore, any message encrypted with the shared key can be decrypted by the attacker. This is particularly problematic if the message contains sensitive data, such as personally identifiable information, financial data, or medical data. [Means for solving the problem]

[0012] Therefore, it is desirable to enhance the security of the DH key exchange method, or other similar methods that involve key generation based on a secret (e.g., a private key).

[0013] In one aspect disclosed herein, there is a computer implementation method for generating a shared cryptographic key based on at least one shared secret, wherein each participant belonging to a first group has a respective share of the first secret, the first secret has a first threshold and a corresponding first public key, and a second coordinator has a second public key corresponding to the second secret, and the method is performed by a first coordinator of the first group and includes the steps of: obtaining each share of the shared cryptographic key from at least a first threshold number of participants in the first group, wherein each respective share of the shared cryptographic key is based on i) the respective zero-order coefficients of each private polynomial used to calculate each share of the first secret or each respective share of the first secret, and ii) the second public key; and generating a shared cryptographic key based on each obtained share of the cryptographic key, wherein the second coordinator is configured to generate the same shared cryptographic key.

[0014] Embodiments of the present invention enhance the security of a shared key (shared in the sense that it is known to two different parties). Instead of generating a shared key based on a perfect secret (e.g., a private key), the shared key is instead generated based on a shared secret (e.g., a shared private key). The shared secret is shared in the sense that each participant in the group has a share of the shared secret (e.g., a share of the shared private key). This shared secret is unknown to the two different parties. Furthermore, the shared secret cannot exist as a whole secret (e.g., the key) in the sense that no individual knows the key. The shared secret will be referred to below as a shared Diffie-Hellman (DH) key to more easily distinguish it from a group's shared secret. However, it should be recognized that this is merely a convenient label. The shared secret may also be referred to as a common secret, i.e., a secret that is common (known) to more than one party. Shares of a private key can be generated in such a way that the private key does not exist. Those skilled in the art are familiar with such techniques. Thus, no single party has access to the shared secret. A shared secret has a threshold, meaning that at least a threshold number of shares of the shared secret are required to reconstruct it.

[0015] This invention generates a shared DH key based on at least a threshold number of shares of a party's (or entity's) public key and shared secret. A fully shared DH key can only be constructed if enough different shares of the shared DH key are available. Here, assuming the shared secret does not exist (i.e., is not memorized by any one participant), it cannot be compromised, making it more difficult for an attacker to obtain the shared DH key. Furthermore, in an event where an attacker compromises a participant's share of the shared secret, that share does not relinquish enough information to reconstruct either the shared secret or the shared DH key. An attacker would need to compromise a threshold number of shares, which is a far more difficult task than compromising a single private key.

[0016] To further enhance the security of the shared DH key, both parties may use a shared secret. That is, one group of participants may have a share of the first shared secret, and another group of participants may have a share of the second shared secret. Each group generates its own share of the shared DH key using the public keys of the other groups and their respective groups' shares of the shared secret.

[0017] In some embodiments, each participant in a group, and indeed every participant, may be required to compute their share of a shared DH key in order for the group to construct the shared DH key. This is particularly useful for use cases where coordination among all participants is required.

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

[0019] [Figure 1] A schematic example of a system for generating a shared key according to some embodiments of the present invention is provided below. [Figure 2] A schematic example of a system for generating a shared key, according to some embodiments of the present invention, is provided below. [Figure 3] The following describes an embodiment of the method for generating a shared key according to several embodiments of the present invention. [Figure 4] A schematic example of the blockchain transaction protocol in this embodiment is provided. [Modes for carrying out the invention]

[0020] Cryptography preparation Elliptic curve group The elliptic curve E is given by equation: y 2 =x 3 Satisfying the equation +ax+b mod p,

number

number

number

[0021] This group operation can be used to define another operation on elements, called point multiplication, denoted by ·.

number

number

[0022] In elliptic curve cryptography, the secret key is a scalar.

number

number

[0023] Elliptic curve digital signature algorithm The following steps are taken to create a signature for message msg using private key a: 1. Calculate the message digest e = hash(msg) using one of the following hash functions. For example, in some embodiments, hash(msg) = SHA256(SHA256(msg)), where SHA256(■) is the SHA-256 hash function. Note that a message can be hashed once or more than once using the same or different hash functions. 2. Choose a random integer k ∈ {1, ..., n-1} where n is the degree of an elliptic curve, for example, the secp256k1 curve. Hereafter, k will be referred to as the temporary secret key. 3. This temporary secret key k·G=(R x ,R y Calculate the temporary public key corresponding to ). 4. r = R x Calculate modulo n. If r=0, return to step 2. 5. Calculate the multiplicative inverse \(k^{-1}\) of the ephemeral key -1 modulo \(n\). 6. \(s = k\) -1 Calculate \((e + ar)\bmod n\). If \(s = 0\), return to step 2. 7. The signature for the message \(msg\) is \((r, s)\).

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

[0025] Given a message \(msg\), a public key \(P = a\cdot G\), and a corresponding signature \((r, s)\), the signature can be verified by completing the following steps: 1. Calculate the message digest \(e=\text{hash}(msg)\), e.g., \(e = \text{SHA256}(\text{SHA256}(msg))\). 2. Calculate the multiplicative inverse \(s^{-1}\) of \(s\) modulo \(n\) -1 . 3. Calculate \(j1 = es\) -1 \(\bmod n\) and \(j2 = rs\) -1 \(\bmod n\). 4. Calculate the point \(Q = j1\cdot G + j2\cdot P\). 5.

Number

Number

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

[0027] Joint verifiable random secret sharing Assume that N participants want to create a joint secret that can only be regenerated by at least (t+1) participants in the scheme. To create the shared secret, the following steps are taken: 1. Participants agree on a unique label i for each participant. Each participant i is a (t+1) random number.

number

number

number

number

[0028] The shared secret share is in form (i,a i The point is that i is the participant label in the scheme. As explained in steps 1-3, this method of creating a secret share of a is a i =JVRSS(i) is represented herein. It should be noted that “JVRSS” typically supports “Joint verification random secret sharing” and also includes steps 4 and 5. However, throughout this specification, JVRSS is considered to mean performing at least steps 1-3, with steps 4 and 5 being optional steps.

[0029] Here, the participants generate a shared polynomial, and each of these can be used to verify that all participants share accurate information about all other participants and that all participants have the same shared polynomial. This is done as follows: 4. Each participant i assigns an obfuscation coefficient a to all participants for k=0, ..., t. ik • Report G. 5. Each participant i, each participant j, f j (i) Calculate G,

number

[0030] If all participants discover that this formula is preserved for each polynomial, the group can collectively be confident that they have all created the same shared polynomial.

[0031] Rebuilding shared secrets Assume that participants want to reconstruct a shared secret a, which is the zero-degree polynomial of the shared polynomial. To discover the shared secret a, form (1, a1), ..., ((t+1), at+1 Assuming a point (t+1) on this polynomial, the following can be derived from the whole equation, known as "Lagrangian interpolation":

number

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

number

[0033] Addition of shared secrets To calculate the sum of two shared secrets within a group of N participants, where no entity knows the individual secrets, and each secret polynomial has degree t, the following steps are taken: 1. Generate a first shared secret a, and the share of participant i is given by a threshold (t+1) for i=1,...,N, a i = Given by JVRSS(i). 2. Generate a second shared secret b, and participant i's share is calculated by the threshold of b at (t+1). i = Given by JVRSS(i). 3. Each participant i has their own additive share v i = a i + b i Calculate modulo n. 4. All participants share their combined share with all other participants. i To report. 5. Each participant shares i Interpolate over at least (t+1) and v = interpolate(v1,…,v t+1Calculate ) = a + b.

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

[0035] Product of shared secrets To calculate the product of two shared secrets that are shared by both participants in a group of N people, if each secret polynomial has degree t, the group takes the following steps: 1. Generate a first shared secret a, and the share of participant i is a for i=1, ..., N. i = Given by JVRSS(i). The shared secret polynomial has degree t and means that (t+1) participants are needed to recreate it. 2. Generate a second shared secret b, and participant i's share is b i = Given by JVRSS(i), the shared secret polynomial again has degree t. 3. Each participant, μ i =a i b i Using their multiplication share μ i Calculate. 4. All participants share their multipliers μ with all other participants. i To report. 5. Each participant's share μ in 0 i Interpolate over at least (2t+1) and μ = interpolate(μ1,…,μ 2t+1 Calculate ) = ab.

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

[0037] The reciprocal of a shared secret To calculate the reciprocal of the shared secret a, the following steps are taken: 1. All participants calculate the product of the shared secret PROSS(i), and the result is μ = ab mod n. 2. Each participant calculates the modular reciprocal of μ, which is μ -1 =(ab) -1 This results in modulo n. 3. Each participant i,

number

[0038] This method of calculating the reciprocal of the shared secret is for participant i.

number

[0039] Shared secret key generation and verification To compute a shared private key a among N>=2t+1 participants, each participant performs JVRSS and public key computation as described above, with a threshold of t+1. The result is that every participant i=1,…,N has a private key share a i and possess the corresponding shared public key P=(a·G).

[0040] Temporary key share generation To generate a temporary key share and the corresponding r as required in the signature, a group of size N with a shared secret key a of threshold (t+1) performs the following steps: 1. Shared Secret

number

number

number

[0041] Generating a shared key Embodiments of the present invention enable two parties to generate a shared cryptographic key, wherein at least one of those parties includes a group of participants (e.g., users or machines). Figure 1 illustrates a system 100 of an embodiment that generates a shared key. As shown, system 100 includes a first party including a first coordinator 101 and a first group of participants 102. Although only three participants 102 are shown in Figure 1, it will be recognized that, overall, the first group can include any number of participants. Furthermore, although the first coordinator 101 is shown as separate from the participants 102, in some embodiments the first coordinator 101 may also be one of the participants 102, e.g., the first participant 102a. Also shown in Figure 1 is a second party including a second coordinator 103.

[0042] As shown in Figure 2, in some embodiments, the second party may also include a second group of participants 104. Similar to the first group of participants, the second group may generally include any number of participants 104.

[0043] The first coordinator 101, the second coordinator 103, each of the first group of participants, and each of the second group of participants operate their respective computing devices. Each of the computing devices includes its respective processing unit, which may include one or more processors, for example, one or more central processing units (CPUs), accelerator processors (GPUs), application processors, and / or field-programmable gate arrays (FPGAs). Each computing device may also include memory, i.e., computer-readable storage devices in the form of non-temporary computer-readable media (may include multiple). The memory may include one or more memory units employing one or more memory media, for example, magnetic media such as hard disks; electronic media such as solid-state drives (SSDs), flash memory, or EEPROMs; and / or optical media such as optical disc drives. Each computing device may include 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 in addition, each computing device may include one or more other networked resources, such as one or more cloud computing resources (cloud computing resources including resources from one or more physical server devices implemented at one or more sites) accessed via a user terminal. It should be recognized that any action described as being performed by a party (e.g., a coordinator, participant, etc.) may be performed by each computing device operated by that party.

[0044] Referring again to Figure 1, the first coordinator 101 (on behalf of the first group of participants) and the second coordinator 103 wish to generate a shared key. This key will be referred to as the shared Diffie-Hellman (DH) key. This label is used for convenience only and does not impose any limitations on keys other than those imposed by this description.

[0045] In the embodiment of Figure 1, the second coordinator 103 has a public key corresponding to a private key. To "have" a key means that the key can be stored in memory, or otherwise, that it is possible to access and retrieve the key. For example, the key can be written on paper and then entered into the device, for example, via a user interface. In this embodiment, the private key is a complete (i.e., all, whole, etc.) key. A private key can be said to be a complete key if it maps directly to the corresponding public key via a generator point.

[0046] Each participant 102 in the first group has a share of a private key ("private key share"). This private key is referred to as the first private key. The private key associated with the second coordinator 103 is referred to as the second private key. The first private key and the second private key are different keys (e.g., different integers). In some embodiments, the first coordinator 101 also has a share of the first private key.

[0047] The first secret key is a threshold secret key. This means that at least a threshold number of first secret key shares are required to reconstruct the first secret key. The techniques for generating threshold secret key shares are familiar to those skilled in the art. One such technique is known as Joint Verifiable Random Secret Sharing (JVRSS), which is described above. Each of the first groups of participants may use JVRSS to generate their respective shares of the first secret key. Another technique is known as Shamir's secret sharing scheme (SSSS). Each of the first groups of participants may use SSSS to obtain their respective shares of the first secret key. It will be noted that SSSS requires a coordinator, whereas JVRSS does not. Another technique for generating and distributing secret key shares is described in WO2017145010A1.

[0048] The first private key has a corresponding public key—the first public key. The first public key may be known to one, several, or all of the first coordinators 101 and / or participants 102.

[0049] In this embodiment, the first coordinator 101 may obtain a public key (second public key) corresponding to the second private key. For example, the second coordinator 103 may send the second public key to the first coordinator 101. Alternatively, the second public key may be obtained from a publicly accessible source such as a website or blockchain. Alternatively, the first coordinator 101 may already have access to the second public key, for example, it may be stored in memory.

[0050] The first coordinator 101 may send the second public key to some or all of the participants 102 of the first group. The first coordinator 101 may send the second public key to each participant 102 separately, or the first coordinator 101 may inform the first group of the second public key. Furthermore, some or all of the participants 102 may already have access to the second public key, in which case the first coordinator 101 does not need to send the second public key to those participants 102, but this does not preclude the first coordinator 101 from still choosing to do so.

[0051] The first coordinator 101 obtains each share of the shared DH key, at least a threshold number of shares. For example, the first coordinator 101 may send (notify) a request for each share of the shared DH key to participant 102. As shown in Figure 1, in some embodiments, not all participants are required to generate a share of the shared DH key. This depends on the threshold of the first private key. Each share of the shared DH key is generated based on (i.e., a function of) each different share of the first private key, i.e., each share of the shared DH key is generated by a different participant 102. Each share of the shared DH key is also generated based on the second public key. It will be recalled from the above that each participant either already possesses the second public key or it can be obtained from the first coordinator 101. In some embodiments, one of the shares is generated by the first coordinator 101.

[0052] Each share of a shared DH key can be generated by performing an elliptic curve multiplication of the respective first private key share and second public key share. It is not ruled out that the shares of the shared DH key may be calculated using alternative mathematical operations.

[0053] Each participant 102 that generates a share of the shared DH key may transmit their share directly to the first coordinator 101 or through one or more other participants. The share may be transmitted over a secure communication channel.

[0054] By obtaining the required number of different shares of the shared DH key, the first coordinator 101 generates the complete shared DH key. The shared DH key is a function of the obtained shares. For example, the shared DH key can be obtained by performing elliptic curve interpolation of the shares of the shared DH key.

[0055] The second coordinator 103 is configured to generate the same shared DH key. In some embodiments, the second coordinator 103 generates the shared DH key based on the first public key and the second private key. In this case, the second coordinator has access to the entire second private key, i.e., not just a share of the second private key. The second coordinator 101 may already have access to the first public key, for example, it may be obtained from a publicly accessible source such as a blockchain. Alternatively, the first coordinator 101 may send the first public key to the second coordinator 103. In some embodiments, each participant 102 may have a share of the first public key corresponding to their respective shares of the first private key. The first coordinator 101 may need a threshold number of shares of the first public key to generate the first public key before sending it to the second coordinator 103.

[0056] As mentioned above, the first private key share can be generated using JVRSS or an equivalent scheme. In those embodiments, each participant in the first group has their respective zeroth coefficients of the private polynomial (see step 1 of the JVRSS method described above). Here, instead of calculating their respective shares of the shared DH key based on their respective shares of the first private key, each participant generates their respective shares based on their respective zeroth coefficients. Each share of the shared DH key is also based on the second public key. In those embodiments, each share of the shared DH key must be obtained from each participant 102.

[0057] Referring to Figure 2, the second private key may be a threshold private key, and each participant 104 of the second group may have a share of the second private key. In those embodiments, the second coordinator 103 may perform an equivalent operation on the first coordinator to generate a shared DH key based on each share of the shared DH key generated by the participants 104 of the second group. For example, participants in the second group may generate a share of the shared DH key based on the first public key and either their respective shares of the second private key or their respective zero-order coefficients of their respective private polynomials.

[0058] Regardless of the method chosen by the second coordinator 103, both the first coordinator 101 and the second coordinator 103 have the same shared DH key. The shared DH key can then be used to encrypt messages, i.e., any type of data. For example, the first coordinator 101 may encrypt a message and send the encrypted message to the second coordinator 103, or vice versa. Messages may include personal and / or confidential information, such as financial data, medical data, prescription data, etc. Messages may include contracts or other types of documents.

[0059] A shared DH key can be used as a symmetric encryption key, in which case it can be used for both encrypting and decrypting messages. Any suitable symmetric encryption scheme, such as Data Encryption Standard (DES), Triple DES, Blowfish, Advanced Encryption Standard (AES), Rivest Cipher 4 (RC4), RC5, or RC6, can be used. For example, a first coordinator 101 may receive an encrypted message from a second coordinator 103, encrypted with the shared DH key. The first coordinator 101 may then use the shared DH key to decrypt the message (i.e., decrypt the ciphertext to obtain a plaintext message).

[0060] In some embodiments, the shared DH key may be used as an asymmetric key, such as a public key. In this case, a message may be encrypted with the shared DH key and, as a result, can only be decrypted with the corresponding private key. Neither the first coordinator 101 nor the second coordinator 103 has enough information to calculate the corresponding private key.

[0061] To do this, the first coordinator 101 and the second coordinator 103 may perform threshold calculation (e.g., interpolation across the private key share) to calculate the private key corresponding to the shared DH key.

[0062] In some embodiments, a first coordinator 101 may obtain a private key corresponding to a shared DH key and generate a digital signature based on the message to be signed and the private key. A second coordinator 103 may also generate a digital signature using the private key. In some embodiments, a blockchain transaction may be created (e.g., by the first coordinator 101 or the second coordinator) that includes an output locked to a shared DH key. The first coordinator 101 or the second coordinator 102 may unlock the output by generating a blockchain transaction, which includes an input that references the output of a previous blockchain transaction, a digital signature generated using the private key, and a message that includes at least a portion of the transaction.

[0063] The first coordinator 101 may generate one or more additional cryptographic keys based on the shared DH key. For example, the shared DH key may be input to a hash function (e.g., SHA256, SHA512, etc.). The hash digest may be used as an additional cryptographic key. The shared DH key may be hashed multiple times to generate multiple additional cryptographic keys. Additional cryptographic keys may be generated in alternative ways. For example, the shared DH key may be combined with a different key (e.g., a different public key) using point addition. The second coordinator 103 may generate the same additional cryptographic keys by performing the same operation(s) as the first coordinator. This allows, for example, many keys to be generated from the same shared DH key to prevent key reuse.

[0064] Figure 3 shows Method 300 of an embodiment for generating a shared DH key. It will be noted that some of the steps are optional. In step S301, the first coordinator 101 obtains a second public key from, for example, the second coordinator 103. In step S302, the first coordinator sends a request to the first group participant 102 requesting a share of the shared DH key (common secret). In step S303, the first coordinator 101 obtains at least a threshold number of shared DH key shares. In step S304, the first coordinator 101 calculates the shared DH key. The shared DH key can then be used, among other things, to encrypt messages.

[0065] The following provides further embodiments of the described embodiments. In the following embodiments, Bob is equivalent to the first coordinator 101, and Alice is equivalent to the second coordinator 103.

[0066] To compute a shared DH key, where at least one of the keys is a shared secret among a group of N participants, the following steps may be taken. Assume Alice wants to create a secret channel by Bob's threshold group. That is, Bob's group has N participants, each of whom has a share of the secret key b. i It is assumed that these (t+1) individuals have a private key and that they need to collaborate to compute it. The corresponding public key for Alice and Bob's group is assumed to be made public.

[0067] To compute a shared DH key that requires the cooperation of the group's (t+1) members, the following steps may be taken: 1. Alice103 receives Bob's group public key b·G and calculates a(b·G) using point multiplication. 2. Bob101, the coordinator of Bob's group, requests at least (t+1) shares of the shared DH key using a·G. 3. At least (t+1) participants in Bob's group use Alice's public key to b i Calculate (a·G). 4. (t+1) participants send their shares to Bob101 using a secure communication channel. 5. Bob101 is b(a·G)=ECinterpolate(b1(a·G),…,b t+1 Using (a·G), the shared DH key is computed, and ECinterpolate uses point addition instead of the usual addition over natural numbers, but the formula is identical to that for standard interpolation.

[0068] Here, both Alice103 and Bob's groups possess a shared key ab·G that they can use to encrypt messages. The shared key can be used for symmetric or asymmetric encryption. If used for the latter, the corresponding secret key ab can be calculated using threshold calculation.

[0069] If Alice's private key is also a shared secret, Alice's group will also perform the same steps as in steps 2-5.

[0070] There are alternative methods for calculating the shared DH key that avoid elliptic curve interpolation, but each participant must contribute. Participants can take the following steps: 1. Alice103 receives Bob's group public key b·G and calculates a(b·G). 2. Bob101, the group coordinator of Bob's group, asks all N participants to calculate the DH key share using a·G. 3. N participants in Bob's group use Alice's public key to b i0 Calculate (a·G), b i0 This is the zero-degree private polynomial of participant i. 4. N participants send their shares to Bob101 using a secure communication channel, or notify only the scheme participants. 5. Bob101,

number

[0071] In this formula, the sum is the sum of points.

[0072] If Alice101 is also part of the threshold scheme, then Alice's group also performs steps 2-5.

[0073] In step 4 of both schemes, participants should preferably send their shares via a secure communication channel with Bob101. If they send their shares over a public network and they are received, it could be possible for anyone to compute the shared DH key. This contradicts the fact that the shared DH key should be a shared secret between Alice103 and Bob's group.

[0074] The two methods can be combined. For example, Bob's group may use the first method to compute the shared DH key, while Alice's group may use the second method, or vice versa. The first method is slightly slower than the second, but allows the shared DH key to be recovered if it is lost. Conversely, the second method is faster than the first, but if the participants in Bob's group lose their respective shares of the shared secret key, the shared DH key cannot be recovered. Of course, the shared DH key can still be computed by Alice. The second method is preferable when the use case benefits from the contributions of all participants.

[0075] Examples and Usage Cases Embodiments of the present invention can be used for various use cases, particularly for one use case where it is desirable to eliminate a single point of failure associated with a private key. For example, if all private keys are lost, the shared key generated based on the private keys is irrecoverable. Furthermore, if the shared key is generated based on all private keys, and those private keys are stolen or otherwise compromised, any message encrypted with the shared key may be decryptable (depending on how the shared key is generated). Embodiments of the present invention are also particularly advantageous when enhanced security of a message is important, such as ensuring that the message is not easily decryptable. For example, it is important to maintain sensitive data such as a patient's medical history, safety, and security.

[0076] A shared DH key can be used to encrypt and share a patient's medical data. For example, a patient may choose to share their medical data with a third-party service provider or data company. For example, a patient may sell their data to a data analytics company. In this embodiment, the patient (equivalent to the second coordinator 103) may have a private-public key pair. The service provider, the patient, and the patient's doctor (equivalent to the first group of participants 102, and the service provider is also the first coordinator 101) may each have a share of the shared private key. At least two of the three parties in this embodiment are required to construct the shared DH key. The patient and the service provider use embodiments of the present invention to construct the shared DH key. If the patient and / or the patient's doctor provides the service provider with a share of the shared DH key, the service provider is only capable of constructing the same shared DH key. The patient may then encrypt their medical data using the shared DH key and transmit the encrypted data to the service provider. The service provider may then use the shared DH key to decrypt the patient's medical data and gain access to it.

[0077] In another embodiment, a shared DH key may be used to share media content, for example, as part of a streaming service. For example, a content provider (second coordinator 103) may want to stream a video to a user. The content provider has a private key-public key pair. The content provider and the user have a share of the shared private key. In this embodiment, the user is equivalent to the first coordinator 101. The content provider generates a shared DH key using its private key and the public key corresponding to the shared private key. The content provider encrypts part or all of the video and sends the encrypted data to the user. The user may generate a share of the shared DH key using their share of the private key and the content provider's public key. In this embodiment, all owners of the private key share are required to participate in generating the shared DH key. Therefore, if the content provider also provides a share of the shared DH key, the user is only able to generate all of the shared DH keys. The content provider may choose to provide a share of the shared DH key in exchange for payment from the user.

[0078] In general, the present invention can be used to encrypt any message. In a particular embodiment, the message may be part of or all of a blockchain transaction. In addition, or instead, the encrypted message may be included in the blockchain transaction.

[0079] Threshold signature schemes have been briefly discussed above. Embodiments of the present invention may be used in such a scheme to store encrypted shares of a shared secret, i.e., shares of the secret key used to generate shares of threshold signatures. If shares of the shared secret are lost, the shares can be restored by a threshold number of participants who agree to decrypt the shares for the participants who have lost those shares.

[0080] Figure 4 illustrates an example transaction protocol for use as part of a blockchain protocol. While the example blockchain protocol is well documented in the literature, for completeness, a description of the example protocol transaction is provided here. This is an example of a UTXO-based protocol. Transaction 152 (abbreviated as "Tx") is the fundamental data structure of the blockchain (each block of the blockchain contains one or more Transaction 152). By reference to an output-based protocol or a "UTXO"-based protocol, the following is described. However, this does not limit all possible embodiments.

[0081] In a UTXO-based model, each transaction ("Tx") 152 includes a data structure containing one or more inputs 202 and one or more outputs 203. Each output 203 may contain 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 yet been redeemed). The UTXO contains a value that specifies the amount of digital tokens, for example, a value representing the amount of digital assets. This represents a set number of tokens on the (distributed) ledger. The UTXO may also contain, among other information, the transaction ID of the transaction from which it originated. The transaction data structure may also contain a header 201, which may contain an indicator of the size of the input field(s) 202 and the output field(s) 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 unprocessed transaction 152 submitted to the miner.

[0082] For example, a first user, e.g., Alice, wants to create transaction 152j to transfer a certain amount of digital tokens to a second user, e.g., Bob. In Figure 4, Alice's new transaction 152j is labeled "Tx1". It requires a certain amount of digital tokens locked to Alice in the output 203 of a preceding transaction 152i in the sequence, and transfers at least a portion of this to Bob. The preceding transaction 152i is labeled "Tx0" in Figure 4. 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 intermediate transaction in the pool. Tx1 could again point to any preceding (i.e., earlier) transaction that still has unused output 203 locked to Alice.

[0083] When Alice creates a new transaction Tx1 for Alice, or at least until Alice sends it to network 106, the preceding transaction Tx0 may already be validated and included in the blockchain. It may already be included in one of the blocks at that time, or it may still be waiting in pool 154, in which case it will be immediately included in the new block. Alternatively, if the node protocol allows buffering of “orphan” transactions, Tx0 and Tx1 may both be created and sent to the blockchain network, or Tx0 may even be sent after Tx1. The terms “preceding” and “successor,” as used herein in the context of a sequence of transactions, refer to the order of transactions in a sequence, as defined by transaction pointers specified within the transaction (e.g., which transaction points to which other transaction). They may be replaced with “predessor” and “successor,” or “antisedent” and “descendent,” “parent” and “child,” or similar. This does not necessarily implicitly mean the order in which they are created, sent to the network, or reach any given node. Nevertheless, a subsequent transaction (descendant transaction, or "child") pointing to a preceding transaction (antisedent transaction, or "parent") will not be validated until the parent transaction is validated, and will not be validated until the parent transaction is validated. A child that reaches a node before its parent is considered an orphan. It may be discarded or buffered during a certain time while waiting for the parent, depending on the node protocol and / or the behavior of the miner.

[0084] 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 that specifies the amount of digital tokens represented by the UTXO, and a locking script that defines the conditions that must be met by the unlocking script in the subsequent transaction's input 202 for the subsequent transaction to be validated and thus the UTXO to be successfully redeemed. Typically, the locking script locks an amount to a specific party (the beneficiary of the transaction it contains). In other words, the locking script defines an unlocking condition, typically including the condition that the unlocking script in the subsequent transaction's input contains the cryptographic signature of the party to which the preceding transaction is locked.

[0085] A locking script (aka scriptPubKey) is a piece 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 locking script specifies what information is needed to exhaust the requirements for transaction output 203, for example, Alice's signature. The unlocking script appears within the transaction output. The unlocking script (aka scriptSig) is a piece of code written in a domain-specific language that provides the information needed to satisfy the locking script criteria. For example, it may contain Bob's signature. The unlocking script appears within transaction input 202.

[0086] Therefore, in the illustrated embodiment, the UTXO0 in output 203 of Tx0 is signed by Alice Sig P in order for the UTXO0 to be redeemed (more precisely, for subsequent transactions attempting to redeem the UTXO0 to be validated). A Locking script that requires [Checksig P A ] includes. [Checksig P A] is the public key P from Alice's public key-private key pair. A It includes. Input 202 of Tx1 includes a pointer that again points to Tx1 (for example, by means of its transaction ID, TxID0, which is the hash of the whole transaction Tx0 in the embodiment). Input 202 of Tx1 includes an index that identifies the UTXO0 in Tx0, which identifies it among any other possible outputs of Tx0. Input 202 of Tx1 further includes the unlocking script <Sig P A > includes the unlock script <Sig P A > contains Alice's cryptographic signature, created by Alice, which applies Alice's private key from the key pair to a predefined portion of data (sometimes called a "message" in cryptography). Which data (or "message") needs to be signed by Alice to provide a valid signature can be defined by the locking script, the node protocol, or a combination thereof.

[0087] When a new transaction Tx1 reaches a node, the node applies the node protocol. This involves running both a locking script and an unlocking script together to check whether the unlocking script satisfies the conditions defined in the locking script (these conditions may include one or more criteria). In an embodiment, this involves two scripts: <Sig P A > <P A >||[Checksig P A], which involves concatenation. "||" represents concatenation, "<...>" means to place data on the stack, and "[...]" is a function included by the unlocking script (in this embodiment, a stack-based language). Equivalently, scripts can work with each other rather than concatenate with the common stack. In either case, when working together, the scripts include Alice's public key P, such as the locking script in the output of Tx0, to authenticate that the locking script in the input of Tx1 includes Alice's signature to sign the expected portion of the data. A The expected portion of the data itself ("message") must also be included in Tx0 to perform this authentication. In the embodiment, the signed data includes the entire Tx0 (and therefore must include separate elements that explicitly define the signed portion of the data, so that it already exists in its essence).

[0088] The details of authentication using public-secret cryptography are familiar to those skilled in the art. Essentially, if Alice signs a message by encrypting it with Alice's private key, then, explicitly assuming Alice's public key and the message (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 with a clear version of the message as a signature, thus enabling any holder of a public key to authenticate the signature. Therefore, any reference herein to signing a particular piece of data or part of a transaction, or similar, may, in embodiments, mean signing a hash of that piece of data or part of a transaction.

[0089] A blockchain node considers Tx1 valid if the unlocking script in Tx1 satisfies one or more conditions specified in the locking script of Tx0 (i.e., in the given embodiment, Alice's signature is provided and authenticated in Tx1). If it is a mining node, this means adding it to the pool of transactions awaiting proof of work. If it is a forwarding node, it forwards transaction Tx1 to one or more other nodes in the blockchain network, and as a result, it propagates throughout the network. Once Tx1 is verified and included in the blockchain, this is defined as having exhausted the UTXO0 from Tx0. It will be noted that Tx1 can only be valid if it exhausts the unused transaction output 203. If it attempts to exhaust an output that has already been exhausted by another transaction, Tx1 is invalid, even if all other conditions are met. Thus, node 104 also needs to check whether the referenced UTXO in the preceding transaction Tx0 has already been exhausted (i.e., whether it has already formed a valid input to another valid transaction). This is one reason why it is important for blockchain 150 to impose a defined order on transactions. In fact, a given node 104 could maintain a separate database marking which UTXOs 203 were exhausted in which transactions, but ultimately, what defines whether a UTXO is exhausted is whether it has already formed a valid input to another valid transaction within the blockchain.

[0090] If the total amount specified in all outputs 203 of a given transaction is greater than the total amount indicated by all its inputs 202, this is another ground for invalidity in most transaction models. Therefore, such a transaction is neither propagated to nor mined into a block.

[0091] It should be noted 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 It can be written as ]. "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, the generation of either 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. In another example, OP_RETURN is a Script language opcode that creates an unused output of a transaction that can store metadata within the transaction, thereby recording data immutably within the blockchain. For example, metadata may include documents that are desirable to be stored on the blockchain.

[0092] signature P A This is a digital signature. In embodiments, this is based on ECDSA using elliptic curve secp256k1. A digital signature signs a specific piece of data. In embodiments, for a given transaction, the signature signs some of the transaction inputs and all or some of the transaction outputs. The specific parts of the output it signs depend on the SIGHASH flag. The SIGHASH flag is a 4-byte code included at the end of the signature to select which outputs are signed (and thus fixed at the time of signing).

[0093] A locking script is sometimes called a "scriptPubKey," referring to the fact that it contains the public key of the party to which each transaction is locked. An unlocking script is sometimes called a "scriptSig," referring to the fact that it supplies the corresponding signature. However, more generally, it is not mandatory in all applications of blockchain where the condition for redemption of a UTXO involves authenticating a signature. More generally, a scripting language can be used to define any one or more of these conditions. Thus, the more general terms "locking script" and "unlocking script" may be preferred.

[0094] In some embodiments of the present invention, a transaction may be a pay-to-public-key-hash (P2PKH) output that is locked to a hash of a shared DH key. To be unlocked, the input of a subsequent transaction referencing the P2PKH output must include the (unhashed) shared DH key and a signature generated based on the private key corresponding to the shared DH key. Represented in scripts, the "locking script" and "unlocking script" may take the following forms: Locking script = OP_DUP OP_HASH160<Public KeyHash> OP_EQUAL OP_CHECKSIG Unlocking script = <signature><Public Key>

[0095] You will recognize that the embodiments described above have been explained only as examples. More generally, methods, apparatus, or programs relating to one or more of the following statements may be provided.

[0096] Statement 1 A computer implementation method for generating a shared cryptographic key based on at least one shared secret, wherein each participant belonging to a first group has a share of the first secret, the first secret has a first threshold and a corresponding first public key, a second coordinator has a second public key corresponding to the second secret, and the computer implementation method is executed by the first coordinator of the first group. A step of obtaining each share of a shared encryption key from at least a first threshold number of participants in a first group, wherein each share of the shared encryption key is based on i) each share of a first secret or each zero-order coefficient of each private polynomial used to calculate each share of a first secret, and ii) a second public key. A step of generating a shared encryption key based on each share obtained of the encryption key, wherein a second coordinator is configured to generate the same shared encryption key, Computer implementation methods, including those mentioned above.

[0097] Statement 2 The coordinator is one of the participants belonging to the first group, as described in Statement 1.

[0098] Statement 3 The steps to obtain the second public key, The steps include sending the second public key to each participant in the first group, A computer implementation method as described in statement 1 or statement 2, including the method described in statement 1 or statement 2.

[0099] Statement 4 A computer implementation method described in any one of statements 1 through 3, including the step of sending the first public key to a second coordinator.

[0100] Statement 5 The computer implementation method described in Statement 4, comprising the step of obtaining each share of a first public key from at least a first threshold number of participants in a first group, wherein each share of the first public key is based on each share of the first secret and a public key generator.

[0101] Statement 6 The computer implementation method described in statement 3 or any statement subordinate thereto, wherein the step of obtaining a second public key includes the step of receiving a second public key from a second coordinator.

[0102] Statement 7 A computer implementation method according to any one of statements 1 to 6, wherein each of the aforementioned shares of the shared DH key is generated based on each of the respective shares of the first secret, and the step of generating the shared cryptographic key includes performing elliptic curve interpolation over each of the obtained shares of the shared cryptographic key.

[0103] Statement 8 A computer implementation method according to any one of statements 1 to 6, wherein each of the aforementioned shares of the shared encryption key is generated based on the respective zero-order coefficients of the respective private polynomials used to compute each of the respective shares of the first secret, the step of obtaining each of the respective shares of the shared encryption key includes the step of obtaining each of the respective shares of the shared encryption key from each of the first group of participants, and the step of generating the shared encryption key includes the step of performing a point sum of the respective obtained shares of the shared encryption key.

[0104] Statement 9 A computer implementation method according to any one of statements 1 through 8, comprising the step of encrypting a first message using a shared encryption key.

[0105] Statement 10 A computer implementation method as described in Statement 9, comprising the step of sending an encrypted first message to a second coordinator and / or a different party.

[0106] Statement 11 A step of generating a blockchain transaction, wherein the blockchain transaction includes an encrypted message, Steps to make blockchain transactions available to one or more nodes in the blockchain network, A computer implementation method as described in statement 9 or statement 10, including the computer implementation method described in statement 9 or statement 10.

[0107] Statement 12 The shared encryption key is a symmetric key, the second message is encrypted by the shared encryption key, and the computer implementation method is one of the computer implementation methods described in any one of statements 1 to 11, the computer implementation method comprising the step of decrypting the second message using the shared encryption key.

[0108] Statement 13 The steps include obtaining a private key corresponding to a shared encryption key, The steps include generating a digital signature using the corresponding private key and / or using the corresponding private key to decrypt a third message encrypted with a shared encryption key, A computer implementation method described in any one of statements 1 through 12, including the above.

[0109] Statement 14 The computer implementation method described in Statement 13, wherein the first blockchain transaction includes an output that is locked to a shared cryptographic key, and the computer implementation method includes the step of generating a second blockchain transaction having an input that references the output of the first blockchain transaction and includes a digital signature for unlocking the output.

[0110] Statement 15 A computer implementation method described in any one of statements 1 through 14, comprising the step of generating one or more additional cryptographic keys based on a shared cryptographic key.

[0111] Statement 16 The computer implementation method described in statement 15, wherein the step of generating one or more additional cryptographic keys includes the step of applying a hash function to the shared cryptographic key.

[0112] Statement 17 A computer implementation method according to any one of statements 1 to 16, wherein the second secret is a shared secret, the second group includes multiple participants, each participant in the second group has their respective share of the second secret, and the second secret has a second threshold.

[0113] Statement 18 The computer implementation method described in Statement 17, wherein each participant in the second group has the respective zero-order coefficient of the respective private polynomial used to calculate their respective share of the second secret.

[0114] Statement 19 Computer equipment, Memory containing one or more memory units, A processing unit comprising one or more processing units, wherein memory stores code configured to run on the processing unit, and the code is configured to execute one of the computer implementation methods of statements 1 to 18 when it is on the processing unit. Computer equipment.

[0115] Statement 20 A computer program that is materialized on a computer-readable storage device and configured to perform one of the computer implementation methods of statements 1 through 18 when it is running on a computer device.

[0116] Another aspect disclosed herein may provide a method including actions of a first participant and a key generator.

[0117] In other embodiments disclosed herein, a system including a first participant and a computer device for a key generator may be provided.

[0118] With the disclosures provided herein, other variations or uses of the disclosed technology may become obvious to those skilled in the art. The scope of the disclosure is not limited by the embodiments described, but is limited only by the appended claims. [Explanation of symbols]

[0119] 101 Coordinator 102a Participants 102b Participants 102c participants 103 Coordinator 104a Participants 104b Participants 104c participants< / signature>

Claims

1. A computer implementation method for generating a shared cryptographic key based on at least one shared secret, wherein each participant belonging to a first group has a share of the first secret, the first secret has a first threshold and a corresponding first public key, a second coordinator has a second public key corresponding to the second secret, and the computer implementation method is executed by the computer equipment of the first coordinator of the first group. A step of obtaining each share of the shared cryptographic key from at least a first threshold number of participants in the first group, wherein each share of the shared cryptographic key is based on i) the respective zero-order coefficients of the respective private polynomials used to calculate each share of the first secret, and ii) the second public key. A step of generating a shared encryption key based on the respective shares of the encryption key obtained, wherein the second coordinator is configured to generate the same shared encryption key. Computer implementation methods, including those mentioned above.

2. The computer implementation method according to claim 1, wherein the coordinator is one of the participants belonging to the first group.

3. The steps include obtaining the second public key and The steps include sending the second public key to each participant of the first group, A computer implementation method according to claim 1 or claim 2, including the above.

4. A computer implementation method according to any one of claims 1 to 3, comprising the step of transmitting the first public key to a second coordinator.

5. The computer implementation method according to claim 4, comprising the step of obtaining each share of the first public key from at least a first threshold number of participants in the first group, wherein each share of the first public key is based on each share of the first secret and a public key generator.

6. The computer implementation method according to claim 3, or claim 4 or 5, referencing claim 3, wherein the step of obtaining the second public key includes the step of receiving the second public key from the second coordinator.

7. Each of the shares of the shared cryptographic key is generated based on the respective zero-order coefficients of the respective private polynomials used to calculate each of the shares of the first secret, The step of obtaining each of the respective shares of the shared encryption key includes the step of obtaining each of the respective shares of the shared encryption key from each of the first group of participants, The computer implementation method according to any one of claims 1 to 6, wherein the step of generating the shared cryptographic key includes the step of performing point summing of the respective acquired shares of the shared cryptographic key.

8. A computer implementation method according to any one of claims 1 to 7, comprising the step of encrypting a first message using the shared encryption key.

9. The computer implementation method according to claim 8, comprising the step of transmitting the encrypted first message to the second coordinator and / or a different party.

10. A step of generating a blockchain transaction, wherein the blockchain transaction includes the encrypted message, The steps include making the blockchain transaction available to one or more nodes of the blockchain network, A computer implementation method according to claim 8 or 9, including the method described in claim 8 or 9.

11. The computer implementation method according to any one of claims 1 to 10, wherein the shared encryption key is a symmetric key, the second message is encrypted by the shared encryption key, and the computer implementation method includes the step of decrypting the second message using the shared encryption key.

12. The steps include obtaining a private key corresponding to the shared encryption key, The steps include generating a digital signature using the corresponding private key and / or using the corresponding private key to decrypt a third message encrypted with the shared encryption key, A computer implementation method according to any one of claims 1 to 10, including the method described in any one of claims 1 to 10.

13. The computer implementation method according to claim 12, wherein the first blockchain transaction includes an output locked to the shared cryptographic key, and the computer implementation method includes the step of generating a second blockchain transaction having an input, wherein the input refers to the output of the first blockchain transaction and includes the digital signature for unlocking the output.

14. A computer implementation method according to any one of claims 1 to 13, comprising the step of generating one or more additional cryptographic keys based on the shared cryptographic key.

15. The computer implementation method according to claim 14, wherein the step of generating one or more additional cryptographic keys includes the step of applying a hash function to the shared cryptographic key.

16. The computer implementation method according to any one of claims 1 to 15, wherein the second secret is a shared secret, the second group comprises multiple participants, each participant in the second group has a respective share of the second secret, and the second secret has a second threshold.

17. The computer implementation method according to claim 16, wherein each participant in the second group has the respective zero-order coefficient of the respective private polynomial used to calculate the respective share of the second secret.

18. Computer equipment, Memory including one or more memory units, A processing apparatus including one or more processing units, The memory stores code configured to run on the processing unit, and the code is configured to execute the computer implementation method of any one of claims 1 to 17 in the processing unit. Computer equipment.

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

Images