System and method for deterministic signing of a message using a multi-party computation (MPC) process

Abstract

A method for signing a message, comprising performing a first Multi-Party Computation (MPC) process by multiple parties to compute a pseudorandom function, an input of the first MPC process comprises shares of a private signing key, each share is held by each party, the message is an input value to the pseudorandom function. The output of the first MPC process comprises multiple pairs of shares, each party holding a pair of shares, wherein each pair comprises a first value used for the MPC signing process and a second verifying value used for verifying correctness of the values provided by the multiple parties for the MPC signing process, and computing the signature on the message by performing an MPC signing protocol on the message, the MPC signing protocol receives as input shares of the output of the pseudorandom function from the multiple parties, and the message to be signed.

Claims

1. A method for signing a message, comprising: receiving a request to sign the message; performing a first Multi-Party Computation (MPC) process by multiple parties to compute a pseudorandom function, an input of the first MPC process comprises shares of a private signing key, each share is held by a party of the multiple parties, wherein the message to be signed is an input value to the pseudorandom function, wherein an output of the first MPC process to compute the pseudorandom function comprises producing multiple pairs of shares of the output of the pseudorandom function, each party of the multiple parties holding a pair of shares, wherein each pair of the multiple pairs comprises a first value used for the MPC signing process and a second verifying value used for verifying correctness of the values provided by the multiple parties for the MPC signing process, and wherein each party of the multiple parties provides one of the values in the pair of shares based on a random mechanism executed multiple times, to verify that at least once the value used for the MPC signing process is provided by the multiple parties and at least once the second verifying value is provided by the multiple parties; computing the signature on the message by performing an MPC signing protocol on the message, wherein the MPC signing protocol receives as input shares of the output of the pseudorandom function from the multiple parties for the signature randomness, and the message to be signed; and sending the signature to the entity from which the request was sent after performing the MPC signing protocol on the message.

2. The method of claim 1, wherein the key to the pseudorandom function is the private signing key.

3. The method of claim 1, wherein the shares of the private signing key are used as part of the signing process.

4. The method of claim 1, wherein encrypting the pair of shares using an elliptic curve.

5. The method of claim 1, further comprising verifying correctness of the shares of the private signing key inputted by the multiple parties to the MPC signing process using the verifying values.

6. The method of claim 5, wherein verifying correctness of the shares of the private signing key comprises performing an arithmetic manipulation on the verifying values.

7. The method of claim 5, wherein the values provided by the multiple parties to the MPC signing process are used after verifying correctness of the shares of the private signing key.

8. The method of claim 1, further comprising: the multiple parties creating a commitment on an encryption of the pair of shares of the private signing key, at least one party of the multiple parties sending the commitment to another party of the multiple parties; and the parties receiving the commitment opening the commitments and verifying that the values provided by the multiple parties to the MPC signing process are correct.

9. The method of claim 1, wherein the pseudorandom function is a key-derivation function.

10. A method for signing a message, comprising: performing a first Multi-Party Computation (MPC) process by multiple parties to compute a pseudorandom function, an input of the first MPC process comprises shares of a private signing key, each share is held by a party of the multiple parties, wherein the message to be signed is an input value to the pseudorandom function, wherein an output of the first MPC process to compute the pseudorandom function comprises producing multiple pairs of shares of the output of the pseudorandom function, each party of the multiple parties holding a pair of shares, and wherein each pair of the multiple pairs comprises a first value used for the MPC signing process and a second verifying value used for verifying correctness of the values provided by the multiple parties for the MPC signing process; verifying correctness of the shares of the private signing key inputted by the multiple parties to the MPC signing process using the verifying values, wherein verifying correctness of the shares of the private signing key comprises performing an arithmetic manipulation on the verifying values, and wherein each party of the multiple parties provides one of the values in the pair of shares based on a random mechanism executed multiple times, to verify that at least once the value used for the MPC signing process is provided by the multiple parties and at least once the second verifying value is provided by the multiple parties; and computing the signature on the message by performing an MPC signing protocol on the message, wherein the MPC signing protocol receives as input shares of the output of the pseudorandom function from the multiple parties for the signature randomness, and the message to be signed.

11. The method of claim 10, wherein the key to the pseudorandom function is the private signing key.

12. The method of claim 10, wherein the shares of the private signing key are used as part of the signing process.

13. The method of claim 10, further comprising receiving a request to sign the message.

14. The method of claim 13, further comprising sending the signature to the entity from which the request was sent after performing the MPC signing protocol on the message.

15. The method of claim 10, wherein encrypting the pair of shares using an elliptic curve.

16. The method of claim 10, further comprising: the multiple parties creating a commitment on an encryption of the pair of shares of the private signing key; at least one party of the multiple parties sending the commitment to another party of the multiple parties; and the parties receiving the commitment opening the commitments and verifying that the values provided by the multiple parties to the MPC signing process are correct.

17. A method for signing a message, comprising: performing a first Multi-Party Computation (MPC) process by multiple parties to compute a pseudorandom function, an input of the first MPC process comprises shares of a private signing key, each share is held by a party of the multiple parties, wherein the message to be signed is an input value to the pseudorandom function, wherein an output of the first MPC process to compute the pseudorandom function comprises producing multiple pairs of shares of the output of the pseudorandom function, each party of the multiple parties holding a pair of shares, and wherein each pair of the multiple pairs comprises a first value used for the MPC signing process and a second verifying value used for verifying correctness of the values provided by the multiple parties for the MPC signing process; verifying correctness of the shares of the private signing key inputted by the multiple parties to the MPC signing process using the verifying values, wherein the values provided by the multiple parties to the MPC signing process are used after verifying correctness of the shares of the private signing key, wherein each party of the multiple parties provides one of the values in the pair of shares based on a random mechanism executed multiple times, to verify that at least once the value used for the MPC signing process is provided by the multiple parties and at least once the second verifying value is provided by the multiple parties; and computing the signature on the message by performing an MPC signing protocol on the message, wherein the MPC signing protocol receives as input shares of the output of the pseudorandom function from the multiple parties for the signature randomness, and the message to be signed.

18. The method of claim 17, wherein the shares of the private signing key are used as part of the signing process.

19. The method of claim 17, further comprising receiving a request to sign the message.

20. The method of claim 19, further comprising sending the signature to the entity from which the request was sent after performing the MPC signing protocol on the message.

21. The method of claim 17, further comprising encrypting the pair of shares using an elliptic curve.

22. The method of claim 17, further comprising: the multiple parties creating a commitment on an encryption of the pair of shares of the private signing key; at least one party of the multiple parties sending the commitment to another party of the multiple parties; and the parties receiving the commitment opening the commitments and verifying that the values provided by the multiple parties to the MPC signing process are correct.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The invention may be more clearly understood upon reading of the following detailed description of non-limiting exemplary embodiments thereof, with reference to the following drawings, in which:

(2) FIG. 1 discloses a method of deriving a key, according to exemplary embodiments of the invention;

(3) FIG. 2 discloses a method for enforcing correctness of key shares during a key derivation process, according to exemplary embodiments of the invention; and,

(4) FIG. 3 discloses a method for computing and encrypting the output of the selected function to verify correctness of the key shares, according to exemplary embodiments of the invention;

(5) FIG. 4 discloses a method for method for signing a message, according to exemplary embodiments of the invention;

(6) FIG. 5 discloses a method for performing a commitment process on a separate pair of shares, according to exemplary embodiments of the invention.

(7) The following detailed description of embodiments of the invention refers to the accompanying drawings referred to above. Dimensions of components and features shown in the figures are chosen for convenience or clarity of presentation and are not necessarily shown to scale. Wherever possible, the same reference numbers will be used throughout the drawings and the following description to refer to the same and like parts.

DETAILED DESCRIPTION

(8) Illustrative embodiments of the invention are described below. In the interest of clarity, not all features/components of an actual implementation are necessarily described.

(9) The invention in embodiments thereof discloses a system and method for managing derivation of a cryptographic key, also referred herein as key. The method is performed by multiple computerized nodes used to store shares of the key. The key may be used in the context of money transfer, for example a Blockchain-related transfer, when a cryptographic key is required to transfer the funds. The key may be used for any other purpose selected by a person skilled in the art. The method is configured to verify, with a very high probability, that the key shares inputted by all the nodes are correct and can be used to create a valid derivation key. The method is performed multiple times, for example in the range of 16-128, and each time the inputted shares to the derivation key are considered valid, reduces the probability that the node actual input is false.

(10) Each of the multiple computerized nodes stores a share of the key used to derive a derivation key. The key shares may be generated using a multi-party computation (MPC) process. The nodes also store a set of instructions that are detailed below. Each node comprises a communication module configured to exchange messages with the multiple computerized nodes. The communication module may exchange signals via wireless or wired channels, for example via the internet, on cables, via a cellular network or any communication technique desired by a person skilled in the art. The nodes also comprise a memory unit configured to store a set of instructions to be executed by the nodes and to store the messages received from the multiple computerized nodes. The messages received from the multiple computerized nodes may be associated with an identifier of the specific node of the multiple computerized nodes that sent the message.

(11) FIG. 1 discloses a method of deriving a key, according to exemplary embodiments of the invention.

(12) Step 110 discloses the multiple computerized nodes receive a request to generate a derivation key based on a key shared between multiple nodes. The request may be sent before transferring funds associated with the key. The nodes may be computers, servers, mobile electronic devices, cellular phones, and any electronic devices having a memory, communication module and memory for storing the key share and performing the instructions disclosed herein. Each node of the multiple computerized nodes performs the method below multiple times, as the logic output in each time is that there is 50% that the node provides a false value as the key share without being caught. Thus, performing the method 20 times and outputting that the value received from the nodes are correct implies that the likelihood of a false value received from the node is less than 1 to million. The number of times a value is requested from the node may be defined by a person skilled in the art.

(13) Step 120 discloses the multiple nodes compute the derivation key using an MPC process. The MPC process is performed in a manner in which the entire key and the derivation key are never accessible to a single entity. The MPC process receives as input a derivation string which is public to all the nodes, and key shares provided by the nodes. The output of the MPC process is shares of the derivation key and authentication information. Each node receives a share of the derivation key. In typical embodiments of the invention, such a derivation key can be computed by computing the HMAC function with the key and public derivation string via MPC, so that the input and output key shares of a node are not revealed to any other node. The authentication information may be used to finalize the verifying correctness of the key shares. The MPC process is performed multiple times, as desired by the person skilled in the art, for example 20 times, 64 times, 144 times and the like. In some cases, in each time the output of the MPC process may be the authentication information or the derivation key shares. At the end of the MPC process, the nodes receive both the authentication information and the derivation key shares in a very high probability.

(14) Step 130 discloses verifying correctness of the key shares inputted by the nodes for the key derivation process. The correctness of the key shares is performed by exchanging messages between the multiple computerized nodes, as detailed below. At least some of the messages contain outputs of cryptographic operations. In the end of the verifying correctness phase, the nodes can verify in a very high probability whether or not the other node inputted the correct share for the key derivation process.

(15) Step 140 discloses the nodes assigning the values received in step 120 as shares of the derivation key, if the verification performed in step 130 succeeds.

(16) FIG. 2 discloses a method for performing an MPC process configured to output shares of the derivation key and authentication information, according to exemplary embodiments of the invention. The MPC process is performed multiple times, each time the MPC process outputs either the shares of the derivation key or authentication information. The number of multiple times may be predefined, or the MPC process may terminate in response to a predefined event, for example after all the optional options elaborated in steps 230, 233 and 235. Thus, for example, in the first and second time, the coins indicate that the key derivation option is selected. In occurrences number 3, 7 and 9-11, the shares are created according to step 233 and in occurrences number 4-6, 8 and 12, the shares are created according to step 235.

(17) Step 210 discloses computing x.sub.in=x.sub.in.sup.1+x.sub.in.sup.2 mod q. It should be noted that none of the nodes that perform the MPC process hold or have access to both x.sub.in.sup.1 and x.sub.in.sup.2 during any of the processes described in the invention. x.sub.in.sup.1 is the share stored in node 1 and x.sub.in.sup.2 is the share stored in node 2. x.sub.in denotes the random string used as part of the signing process.

(18) Step 220 discloses Flip two coins b.sub.1 and b.sub.2. The two coins represent 4 options having substantially the same probability to take place. As the next steps are performed multiple times, the MPC process performed by the nodes requires that all 4 options are randomly selected in a very high likelihood, for example a probability of at least 99.99%. Flipping the coins may be performed using a Bernouli process implemented on a computer software running on an MPC process between the nodes. The outcome of the coins is not revealed to any of the nodes. For simplicity, the coins may have a value of 0 or 1. The flip coin is a representation of a random selection of one option from multiple options disclosed in steps 230, 233 and 235. The options may be selected in equal or unequal probabilities.

(19) After flipping the coins, the MPC process sets two values, each value is configured to be outputted to another node. In case the first coin has a value 0, as disclosed in step 230, the MPC process sets both shares x.sub.1, x.sub.2 to be the same random value. In case the first coin has a value 1 and the second coin has a value 0, as disclosed in step 233, the MPC process sets both shares x.sub.1, x.sub.2 to be random shares of x.sub.in (that is, x.sub.1+x.sub.2=x.sub.in mod q). In case the first coin has a value 1 and the second coin has a value 1, as disclosed in step 235, the MPC process computes x.sub.out=H(x.sub.in, s) and prepare random shares x.sub.1, x.sub.2 of x.sub.out. It should be noted that the mathematical computations disclosed in steps 233 and 235 are exemplary only, and represent any selection of random values that can be used to verify the correctness in the method described in FIG. 3. The nodes are not aware at any stage of the option selected by the coin flip.

(20) Then, in step 240, the share x.sub.1 is outputted to node P.sub.1 and the share x.sub.2 is outputted to node P.sub.2. Again, also when outputting the shares x.sub.1 and x.sub.2, none of the nodes has access to the shares. In some cases, the process is repeated after step 240, as shown in FIG. 2. In some other cases, coin flip is performed multiple times, for example 64 times, each time is assigned an identifier, then, the selected option is performed, according to the value of the identifier. For example, value 00 indicates that both coin flips were assigned 0. Then, all the 64 outputs are outputted to each node using the MPC process, and each node has 64 occurrences of outputs, for example, 20 key derivation shares, 20 random shares and 24 random additive shares.

(21) FIG. 3 discloses a method for computing and encrypting the output of the selected function to verify correctness of the key shares, according to exemplary embodiments of the invention.

(22) In step 310, each node P.sub.i (for i=1, 2) receives function output x.sub.i. For example, node P1 receives X1 and P2 receives X2.

(23) In step 320, each node P.sub.i computes Q.sub.i=x.sub.i.Math.G. G is the generator (or base point) of the Elliptic curve being used. It should be noted that x.sub.i cannot be extracted from Q.sub.i, as G is an irreversible function.

(24) In step 330, each node P.sub.i sends the other node a cryptographic commitment of Q.sub.i. The commitment is defined as a value that bounds the node to the value but does not reveal it. The commitment may be computed, for example, by choosing a random r.sub.i of length 128 bits and computing c.sub.i=SHA256(Q.sub.i, r.sub.i). Then, the nodes exchange the value c.sub.i.

(25) In step 340, each node P.sub.i receives the cryptographic commitment from the other node. exchange of the commitments, commitment openings and additional messages between the nodes may be performed via a wired or wireless channel. In some exemplary cases, the nodes are different and distinct entities located nearby, even in the same building or server farm/cluster.

(26) In step 345, the nodes exchange commitment openings. The commitment openings may be the commitment message before the hash function is applied thereto. For example, the commitment opening is (Q.sub.i, r.sub.i) while the commitment message is c.sub.i=SHA256(Q.sub.i, r.sub.i).

(27) In step 345, the nodes check the result of the commitments. Checking may be performed by applying the hash function on the commitment opening and comparing the output of the hash function to the commitment message.

(28) In step 360, if the commitment is correct multiple times and if Q.sub.1=Q.sub.2 or Q.sub.1+Q.sub.2=Q.sub.in, and the multiple Q1 and Q2 values received in each node are the same in all iterations, define Q.sub.1 and Q.sub.2 as public key shares, x.sub.i as private key share for each node, and Q=Q.sub.1+Q.sub.2 as the derived public key. The method may define one or more functions that can be verifiable by the nodes without revealing the outputs X1 and X2. As noted above, one optional verifiable function outputs two random and equal values. Thus, the nodes can check whether Q1 equals Q2 and thus X1 equals X2. Otherwise, the nodes conclude that the selected function is the function that computes the derivation key. In such a case, the outputted values X1 and X2 are stored in the nodes as the shares of the derivation key. Another verifiable function is outputting two additive shares of Xin.

(29) In case the selected function outputs equal random values, no node can modify the Q.sub.i value that it sends in the commitment, or the node will be detected cheating, as all the nodes should have the same value, and this will be different. The malicious node may send a different value and hope that this will fall into the case another verifiable function selected or being the same value as stored in other executions, but since Q.sub.j is just a random value, the chance of it falling into another case is extremely small.

(30) Assume that a node inputs an incorrect share into the computation and the selected function outputs two values such that X1+X2 equals Xin mod q. In this case, the malicious node needs to make the result equal Q.sub.in. This requires it changing its Q.sub.j value since the input share was incorrect and Q.sub.in is publicly known. However, by what we have just explained, it cannot change Q.sub.j if b_1=0 or it will be detected. Thus, such a strategy is doomed to fail and have the cheating be detected.

(31) Finally, assume that both nodes input correct shares, but an attacker wishes to make the resulting key be incorrect. In order to do so, the attacker has to change the Q.sub.j value it received. Again, this strategy is doomed to fail as the attacker must input its correct share and cannot change its output; else, it will be detected with a very high probability.

(32) FIG. 4 discloses a method for method for signing a message, according to exemplary embodiments of the invention. The signing process enables deterministic signing, in which each message is associated with a unique signature, and this is cryptographically enforced. The method utilizes a Key-derivation function (KDF), which receives as input a key and a value, and outputs a pseudorandom value (or a key and multiple values, and outputs multiple pseudorandom values). The KDF function may also be known as a pseudorandom function.

(33) Step 410 discloses receiving a request to sign a message. The request may be received from a third party entity, such as a web server, laptop, cellular phone and the like. The request may be received via an email message, or a request automatically sent to a communication unit of a computer managing the signing process of the message.

(34) Step 420 discloses storing shares of a private signing key in multiple parties. The shares are stored in memory modules of the server, for example in a specific memory address in the memory of the parties. The shares are stored in a manner that one party lacks access to the shares stored in the other parties during the entire signing process.

(35) Step 430 discloses performing a first Multi-Party Computation (MPC) process to compute a first function that receives as input the message and the shares of the private signing key, and outputs shares of a derived random string together with verifying values to the multiple parties. The verifying values are outputted in order to prevent corruption of values in the signing process, thereby enforcing the parties to use the correct derived random string.

(36) Thus, the output of the first MPC process is a pair of values provided to each of the multiple partiesa verifying value and a share of the derived random string. Both values are provided by the parties during a verifying process disclosed below.

(37) Step 440 discloses the parties verifying correctness of the values provided by other parties. The correctness may be verified by performing a commitment process as detailed in FIG. 5, in which each party generates a commitment and sends the commitment to the other parties.

(38) During the verifying process, each party of the multiple parties provides one of the values based on a random mechanism, such as a computerized coin toss. This random mechanism is executed multiple times, for example in the range of 20-50 times, to verify that at least once the share of the pseudo random string is provided by the multiple parties and at least once the verifying value is provided by the multiple parties. This way, in case the party wishes to provide a corrupted value, the verifying value is revealed, and the signing process stops. For example, in case the random value is 0, the key derivation is generated and in case the random value is 1, the values provided by the parties are checked, for example in a manner disclosed in FIG. 2. This way, if one of the parties provides an incorrect value, the corrupted party is revealed, and the corrupted pseudo random string is not used.

(39) Step 450 discloses computing the signature by performing an MPC signing process that receives as input shares of the derived random string resulting from the first MPC process of step 430. The MPC signing process receives as input shares of the derived random string from the multiple parties. The shares of the derived random string used during the signing process are new as prior art solutions use independent random values, chosen locally by each party.

(40) FIG. 5 discloses a method for performing a commitment process on a separate pair of shares, according to exemplary embodiments of the invention. A commitment may be defined as a commitment value that bounds the party to a value but does not reveal the value. A commitment is used in two stepsfirst a party binds itself to the value and in the second step the party reveals the value that he bounded itself to and proves that this was indeed the value that he bounded itself too. The commitment value may be an output of a hash function of the value.

(41) Step 510 discloses each party obtaining a random value and a message on which the commitment process is performed. The random value and the message are stored in the memory of each party and cannot be accessed by other parties.

(42) Step 520 discloses each party performing a hash function on the random value and the message. Step 530 discloses each party sending the output of the hash function to another party. Such transmission may be performed via the internet, a cable or any other technique. The parties may have communication details of the other parties in the memory module of each party.

(43) Step 540 discloses each party sending the random value and the message to the other party.

(44) Step 550 discloses the parties verifying correctness of the message and the random value. Such correctness may be performed by the parties receiving the message and the random value performing a hash function on the received message and random value and verify that the output of the hash function is the value received from the other parties in step 530.

(45) While the disclosure has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes may be made, and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings without departing from the essential scope thereof. Therefore, it is intended that the disclosed invention not be limited to the particular embodiment disclosed as the best mode contemplated for carrying out this invention, but only by the claims that follow.