SYSTEMS AND METHODS FOR MESSAGE AUTHENTICATION USING EFFICIENT SIGNATURES AND SECRET SHARING

Abstract

A method for message authentication includes computing a first secret data and a second secret data using a signing key associated with a first communication message. The method includes splitting the first secret data and the second secret data into shares among a plurality of key holders n for storage at the plurality of key holders n. The method includes receiving a reconstruction request to compute a hash-based message authentication code (HMAC) signature for the first communication message employing the shares from at least t≤n of the plurality of key holders n to compute the signature with a Secure Multi-party Computation (SMC) protocol. Further the method includes computing the signature using the shares from the at least t≤n of the plurality of key holders n as inputs to the SMC protocol in place of the signing key.

Claims

1. A computer-implemented method for message authentication, comprising: computing a first secret data and a second secret data using a signing key associated with a first communication message; splitting the first secret data and the second secret data into shares among a plurality of key holders n for storage at the plurality of key holders n; receiving a reconstruction request to compute a hash-based message authentication code (HMAC) signature for the first communication message employing the shares from at least t≤n of the plurality of key holders n to compute the signature with a Secure Multi-party Computation (SMC) protocol; and computing the signature using the shares from the at least t≤n of the plurality of key holders n as inputs to the SMC protocol in place of the signing key.

2. The computer-implemented method of claim 1, wherein computing the first secret data and the second secret data is independent from the first communication message being signed.

3. The computer-implemented method of claim 1, wherein splitting the first secret data and the second secret data includes distributing a share of the first secret data and a share of the second secrete data to the plurality of key holders n.

4. The computer-implemented method of claim 1, further including upon determining that each of the plurality of key holders n received the shares, deleting the signing key.

5. The computer-implemented method of claim 1, further including reconstructing the first secret data and the second secret data based on the shares.

6. The computer-implemented method of claim 5, wherein computing the signature includes using the first secret data and the second secret data from the at least t≤n of the key holders n as inputs to the SMC protocol in place of the signing key.

7. The computer-implemented method of claim 1, wherein the plurality of key holders n locally generates ephemeral shares of the shares.

8. The computer-implemented method of claim 7, wherein computing the signature includes using the ephemeral shares from the at least t≤n of the plurality of key holders n as the inputs in place of the signing key using the SMC protocol.

9. A system for message authentication, comprising: a key owner; a plurality of key holders n; a requester; and a processor operatively connected for computer communication to the key owner, the plurality of key holders n, and the requester, wherein the processor: computes a first secret data and a second secret data using a signing key from the key owner and associated with a first communication message; splits the first secret data and the second secret data into shares among the plurality of key holders n for storage at the plurality of key holders n; receives, from the requester, a reconstruction request to compute a hash-based message authentication code (HMAC) signature for the first communication message employing the shares from at least t≤n of the plurality of key holders n to compute the signature with a Secure Multi-party Computation (SMC) protocol; and computes the signature using the shares from the at least t≤n of the plurality of key holders n as inputs to the SMC protocol in place of the signing key.

10. The system of claim 9, wherein the processor computes the first secret data and the second secret data independently from the first communication message being signed.

11. The system of claim 9, wherein the processor distributes a share of the first secret data and a share of the second secret data to the plurality of key holders n.

12. The system of claim 9, wherein the processor deletes the signing key upon determining that each of the plurality of key holders received the shares.

13. The system of claim 9, wherein the processor reconstructs the first secret data and the second secret data based on the shares and computes the signature using the first secret data and the second secret data from the at least t≤n of the plurality of key holders n as the inputs to the SMC protocol in place of the signing key.

14. The system of claim 9, wherein the plurality of key holders n locally generates ephemeral shares of the shares, and the processor computes the signature using the ephemeral shares from the at least t≤n of the plurality of key holders n as the inputs in place of the signing key using the SMC protocol.

15. A non-transitory computer-readable storage medium including instructions that when executed by a processor, causes the processor to: compute a first secret data and a second secret data using a signing key associated with a first communication message; split the first secret data and the second secret data into shares among a plurality of key holders n for storage at the plurality of key holders n; receive a reconstruction request to compute a hash-based message authentication code (HMAC) signature for the first communication message employing the shares from at least t≤n of the plurality of key holders n to compute the signature with a Secure Multi-party Computation (SMC) protocol; and compute the signature using the shares from the at least t≤n of the key holders n as inputs to the SMC protocol in place of the signing key.

16. The non-transitory computer-readable storage medium of claim 15, wherein the processor computes the first secret data and the second secret data independently from the first communication message being signed

17. The non-transitory computer-readable storage medium of claim 15, further causing the processor to distribute a share of the first secret data and a share of the second secrete data to the plurality of key holders n.

18. The non-transitory computer-readable storage medium of claim 15, further causing the processor delete the signing key upon determining that each of the plurality of key holders n received the shares.

19. The non-transitory computer-readable storage medium of claim 15, further causing the processor to locally generate at each of the plurality of key holders n ephemeral shares of the shares.

20. The non-transitory computer-readable storage medium of claim 19, wherein computing the signature further includes causing the processor to use the ephemeral shares from the at least t≤n of the plurality of key holders n as the inputs to the SMC protocol in place of the signing key.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate various systems, methods, devices, and other embodiments of the disclosure. It will be appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, directional lines, or other shapes) in the figures represent one embodiment of the boundaries. In some embodiments one element may be designed as multiple elements or that multiple elements may be designed as one element. In some embodiments, an element shown as an internal component of another element may be implemented as an external component and vice versa. Furthermore, elements may not be drawn to scale.

[0011] FIG. 1A is a block diagram of a system for message authentication according to one exemplary embodiment;

[0012] FIG. 1B is a block diagram of an exemplary computing device (e.g., computing nodes) operatively connected for computer communication with the system of FIG. 1A.

[0013] FIG. 2 is a block diagram of a Boolean circuit according to an exemplary embodiment;

[0014] FIG. 3 is a flow diagram of a method for message authentication during a setup phase according to an exemplary embodiment;

[0015] FIG. 4 is a block diagram of an exemplary circuit for computation of HMAC for a message according to one exemplary embodiment;

[0016] FIG. 5 is a flow diagram of a method for message authentication during a signing phase according to an exemplary embodiment; and

[0017] FIG. 6 is a block diagram of a Boolean circuit according to one exemplary embodiment.

DETAILED DESCRIPTION

[0018] The systems and methods described herein are directed to authentication techniques computing threshold Hash-Based Message Authentication Codes (HMAC). Generally, the systems and methods employ n≥2 entities, called key holders, which collaboratively store the signing key K received from another entity, called a key owner. Two phases are described herein: a setup phase, where the signing key K for the HMAC is distributed by the key owner to the key holders; and a signing phase, where HMAC signatures can be collaboratively computed by any subset with at least t≤n key holders, where t is a parameter called threshold. Having multiple entities involved in the computation of an HMAC signature reduces the risks of key theft, since the key is split among multiple key holders, and reduces the risks of key misuse, as the message being signed can be validated by multiple key holders, preventing a single rogue key holder from obtaining a signature for a message arbitrarily chosen by itself.

[0019] In the setup phase, the key owner, holding the signing key K, derives from K two secret data, referred to as K.sub.ipad and K.sub.opad, which can be employed as inputs to the HMAC computation in place of the signing key K; then, the key owner splits both K.sub.ipad and K.sub.opad in n shares with t-out-of-n secret sharing scheme (e.g., Shamir Secret Sharing), following a secret splitting strategy proposed in this invention that allows to reconstruct the secret information with a negligible number of bitwise operations which can be efficiently evaluated with an SMC protocol employing Boolean circuits as a representation for the function being computed.

[0020] In the signing phase, any subset T of at least t key holders can collaboratively compute an HMAC signature for a message M. Specifically, the key holders belonging to T jointly execute a SMC protocol to securely evaluate a function F that, given as input the message M and the shares of both K.sub.ipad and K.sub.opad hold by the key holders in subset T, first reconstructs both K.sub.ipad and K.sub.opad and then it computes the HMAC signature of the message M with signing key K. Each of the key holders in subset T provides as its private input to the SMC protocol a share of K.sub.ipad and a share of K.sub.opad, which were obtained during the setup phase; the secret splitting strategy proposed in this invention to compute such shares allows to employ a simple Boolean circuit to reconstruct K.sub.ipad and K.sub.opad from the secret shares provided by the key holders, which can be efficiently evaluated by the jointly run SMC protocol. Remarkably, such Boolean circuit for secret reconstruction is composed only by XOR operations, which can be evaluated with a minimal overhead in a SMC protocol.

[0021] The message M to be signed with HMAC, which is assumed to be known by all the key holders, must be jointly provided by all the key holders as input to the SMC protocol, in order to avoid that a single party may arbitrarily change the message being signed. Therefore, a secure solution for threshold HMAC signatures must hinge upon a SMC protocol that allows to guarantee that a valid signature is obtained only if all the key holders involved in the computation provide the same message M as input to the protocol at hand. Unfortunately, not all SMC protocols can provide this guarantee. In the embodiments described herein, a specific SMC protocol proposed in X. Wang, S. Ranellucci and J. Katz, Global-Scale Secure Multiparty Computation. Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS 2017, 2017 is described however, it is understood that other SMC protocols may be employed.

I. System Overview

[0022] Referring now to the drawings, wherein the showings are for purposes of illustrating one or more exemplary embodiments and not for purposes of limiting same, FIG. 1 is a block diagram of a system 100 for message authentication according to one exemplary embodiment. The system 100 includes a key owner 102 and multiple key holders 104, namely, a key holder 104A, a key holder 104B, a key holder 104C, and a key holder 104N. The system 100 also includes a requester 106 and a network 108. Each of the key owner 102, the key holders 104, and the requester 106 may be operatively connected for computer communication, for example, via the network 108. It is understood that the components of the system 100, as well as the components of other systems, hardware architectures, and software architectures discussed herein, can be combined, omitted, or organized into different architectures for various embodiments.

[0023] Generally, the key owner 102, the key holders 104, and/or the requester 106 can be any type of computing device and/or computing node (e.g., servers, PCs, mobile phones). In some embodiments, these computing nodes belong to either the same organization or to multiple organizations, as well as hybrid scenarios where multiple organizations may control multiple key holders. Referring now to FIG. 1B a block diagram of and exemplary computing device 110 (e.g., a computing node) is shown. In general, the computing device 110 includes a processor 112, a memory 114, a data store 116, an input/output (I/O) device 118, and communication interface 120 each operatively connected for computer communication via a bus (not shown) and/or other wired and wireless technologies defined herein. It is understood that one or more of the components of the system 100 in FIG. 1A can include one or more of the components and/or execute one or more of the functionalities of the components shown in FIG. 1B.

[0024] The processor 112 may include logic circuitry with hardware, firmware, and software architecture frameworks for facilitating the methods, functions, and components as described herein. In some embodiments, the processor may store circuits, application frameworks, kernels, libraries, drivers, application program interfaces, among others, to execute and control hardware and functions discussed herein. In some embodiments, the memory 114 and/or the data store 116 may store similar components as the processor 112 for execution by the processor. The I/O device 118 may include one or more input-output devices for providing visual, audio, and/or tactile input and/or output from and/or to another entity (e.g., an operator). The I/O device 118 may be a monitor, display, keyboards, touch screens, speakers, among other devices.

[0025] The communication interface 118 can include software and hardware to facilitate data input and output between the components of the computing device 110 and other components of the system 100. Specifically, the communication interface 118 can include network interface controllers (not shown) and other hardware and software that manages and/or monitors connections and controls bi-directional data transfer between the communication interface 118 and other components of the computing device 110 and the system 200 using, for example, the network 108. The systems and methods for message authentication will now be described in more detail with reference to the above described components of FIGS. 1A and 1B.

II. Setup Phase

[0026] As mentioned above, the systems and methods described herein include a setup phase, where the key owner 102, which holds the signing key K, computes secret data K.sub.ipad and secret data K.sub.opad derived from the signing key K. The key owner 102 securely splits such data among the n key holders 104 with a Shamir Secret Sharing scheme. Once, the key owner 102 has acknowledged that all the key holders 104 have received their share of the secret data, the key owner 102 can safely erase the signing key K to prevent key theft threats. In some embodiments, instead of deleting the signing key K, it can be stored offline (e.g., cold storage solution). The setup phase will now be described in more detail with reference to the method 300 of FIG. 3.

[0027] At block 302, the method 300 includes computing a first secret data and a second secret data using a signing key associated with a first communication message. The secret data K.sub.ipad and K.sub.opad represent intermediate values obtained during the computation of an HMAC signature that depend only on the signing key K (i.e., independent from the message being signed): therefore, these intermediate values can be computed once during the setup phase and employed in place of the signing key K for all the HMAC signatures that must be computed with such key. Said differently, the first secret data and the second secret data are computed independently and/or are not derived from the first communication message M being signed.

[0028] More specifically, the computation of K.sub.ipad and K.sub.opad will now be described in more detail. HMAC relies on a collision-resistant hash function H, such as SHA-2 or SHA-3, which is employed as a building block. For an underlying hash function H with input blocks of B bytes, the HMAC computation for a signing key K and a message M is defined as:

HMAC(K,M)=H((K⊕opad)∥H((K⊕ipad)∥M))  (1)

where ∥ denotes the concatenation of two bit-strings, opad is the outer padding, given by B bytes with value 0x5c, ipad is the inner padding, given by B bytes with value 0x36, and the signing key K is padded to B bytes adding trailing bytes with value 0x00

[0029] If the input of the hash function is larger than the block size B, then such payload is split in chunks of B bytes, and each chunk is sequentially processed by the hash function through a compression function. Such function takes as input a chunk of B bytes of the message to be hashed and the inner state of the hash function H, which is initialized to a constant value IV and it is overwritten after each execution of the compression function with the output of such function. FIG. 4 illustrates an HMAC computation circuit 400 which shows the computation of HMAC(K,M) for a message M with m chunks, employing the compression function h of the hash function H. From such construction, it is clear that the compression of both the inner padding 402 and the outer padding 404 are independent from the message M.

[0030] Accordingly, in order to avoid the re-computation of both k_ipad=h(IV,K⊕ipad) and k_opad=h(IV,K⊕opad) in every HMAC computation with the same signing key, the systems and methods described herein employ K.sub.ipad and K.sub.opad as inputs to the HMAC in place of the signing key K. This optimization, although applicable to any HMAC computation employing the same key, is particularly efficient when the HMAC is computed through a SMC protocol, given the higher overhead of evaluating the compression function h with a SMC protocol.

[0031] Once K.sub.ipad and K.sub.opad are computed by the key owner, each of them must be split in n≥2 shares and distributed among the key holders 104 n. Accordingly, with reference again to FIG. 3, at block 304 the method 300 includes splitting the first secret data and the second secret data into shares among a plurality of key holders n for storage at the plurality of key holders n. In one embodiment, at block 306, the method 300 can include distributing a share of the first secret data and a share of the second secrete data to the plurality of key holders n. In particular, both K.sub.ipad and K.sub.opad are split based on t-out-of-n secret sharing scheme (e.g., Shamir Secret Sharing). As will be discussed in further detail herein, this allows any subset of at least t key holders 104 n to efficiently reconstruct the signing key with a SMC protocol evaluating Boolean circuits during the signing phase.

[0032] Splitting the shares according to Shamir Secret Sharing will now be described in more detail. The elements are of a finite field as the Galois field with order 2.sup.L (i.e., GF(2.sup.L)) for an integer L such that 2.sup.L≥n. The choice of this finite field is based on the following properties. First, there is a one-to-one mapping φ between elements in GF(2.sup.L) and bit-strings of L bits. Elements in GF(2.sup.L) are polynomials of degree at most L−1 with binary coefficients, which can be mapped to a bit-string of L bits by concatenating the L binary coefficients of the polynomial. Also, the addition between elements in GF(2.sup.L) is equivalent to the XOR between the corresponding bit-strings of L bits. This can be expressed mathematically as:

∀ve_1,e_2∈GF(2{circumflex over ( )}L):φ(e_1+e_2)=φ(e_1)⊕φ(e_2)  (2)

[0033] Accordingly, all the addition and multiplication operations reported represent additions and multiplications in the chosen finite field GF(2.sup.L). Considering a secret information S of k bits, which may represent either the signing key K, K.sub.ipad or K.sub.opad, such secret is split by the key owner in n shares as follows. First, partition the secret S in

[00002]$.Math.\frac{k}{L}.Math.$

chunks of L bits. For each chunk Sj, compute n shares with Shamir secret sharing over GF(2.sup.L). Specifically, choose a random polynomial Pj of degree t−1 such that P.sub.j(0)=s.sub.j where s.sub.j is the element in GF(2.sup.L) corresponding to the L-bit chunk Sj according to mapping φ (i.e., s.sub.j=φ.sup.−1(S.sub.j)). The i-th share is y.sub.j.sup.i=P.sub.j(e.sub.i), where e.sub.i is a generic element of GF(2.sup.L) bounded only to the i-th key holder and known by all the key holders. The i-th party gets the share y.sub.j.sup.i for each chunk.

[0034] The setup phase ends when all the secret data (i.e., both K.sub.ipad and K.sub.opad) are shared among the key holders. However, the key owner can erase the secret S once all the n shares have been received by the key holders. Accordingly, at block 310, the method 300 includes determining if each of the key holders 104 n have received the shares. If YES, the method 300 proceeds to block 312, wherein the signing key K is deleted. If NO, the method 300 ends. It is understood that in some embodiments, at block 312, instead of deleting the signing key K, a cold storage solution can be implemented. For example, the signing key K can be stored offline in a data store by the key owner 102.

III. Signing Phase

[0035] Once the setup phase is over, the set of key holders 104 are ready to compute signatures with the signing key K. Referring now to FIG. 5, a method 500 illustrating the signing phase will now be described in more detail. At block 502, the method 500 includes receiving a reconstruction request for a message M to compute a hash-based message authentication code (HMAC) signature for the first communication message employing the shares from at least t≤n of the plurality of key holders n to compute the signature with a Secure Multi-party Computation (SMC) protocol. In some embodiments, the request to compute a signature for a given message M may come from a third party or by any of the key holders 104. In the embodiments described herein, and as shown in FIG. 1A, the requester 106 transmits a reconstruction request to compute a signature for the first communication message M. Such request, which encompasses the message M to be signed, is sent by the requester 106 to all the key holders 104. As will be discussed herein, any subset with m≥t key holders 104 can jointly compute the HMAC signature. The m key holders 104 involved in the collaborative signature computation may also be referred to as signing parties. The signature is computed by hinging upon any SMC protocol that allows to evaluate an arbitrary Boolean circuit. In particular, the present invention mandates that the m signing parties should jointly evaluate with a SMC protocol the Boolean circuit 200 in FIG. 2. The Boolean circuit 200 is obtained as a composition between a Boolean circuit 204 that computes the HMAC signature from the secret data K.sub.ipad, K.sub.opad and the message M, with a Boolean circuit 202 that reconstructs the secret data K.sub.ipad and K.sub.opad from the shares provided by each of the signing parties, connecting the output wires 210 of the latter circuit to the input wires 206 of the former circuit. The security properties of the SMC protocol guarantee that no information about the reconstructed secret data can be learned by any party involved in the SMC protocol evaluating the composed Boolean circuit 200.

[0036] Accordingly, at block 504, the method 500 includes receiving the shares from at least t≤n of the key holders 104 n. In one embodiment, at block 506, the method 500 includes reconstructing the first secret data and the second secret data based on the shares. For example, the Boolean circuit 202 reconstructs the secret data K.sub.ipad and K.sub.opad from the shares obtained by each of the signing parties during the setup phase. In one embodiment, instead of employing such shares directly as inputs to the Boolean circuit 202, all the signing parties provide as their secret inputs to the Boolean circuit 202 ephemeral shares, which are one-time shares locally computed by each party from the original shares obtained from the setup phase. More specifically, considering a set T with at least t signing parties, given a share y.sub.j.sup.i of the j-th chunk of a secret S hold by the i-th party in T, the ephemeral share S.sub.j.sup.i is computed as

[00003]$S_j^i=y_j^i{\Pi }_{k\in T,k\ne i}\left(\frac{e_k}{e_k-e_i}\right),$

where {e.sub.k|k∈T} are the elements of GF(2.sup.L) bound to each of the signing parties and publicly known by all the parties. All the arithmetic operations are performed over the finite field GF(2.sup.L) employed in the setup phase when computing the shares.

[0037] By employing ephemeral shares instead of original ones, the j-th chunk S.sub.j of a secret S can then be easily reconstructed as the sum over GF(2.sup.L) of the ephemeral shares provided by all parties for that chunk, that is S.sub.j=ΣF.sub.i∈T S.sub.j.sup.i. Because of the second property stated earlier for the field GF(2.sup.L), this summation can be equivalently performed as the bitwise XOR of all the ephemeral shares, therefore the present invention proposes as the Boolean circuit 202 to reconstruct a secret S a simple circuit made by a set of XOR gates combining together the corresponding bits of all the ephemeral shares. An example of this is shown in FIG. 6 by Boolean circuit 600 as reconstructing a 3-bit chunk S.sub.j from m=4 ephemeral shares over GF(2.sup.3). The benefit of the Boolean circuit 600 is that the XOR gates can be efficiently evaluated with a SMC protocol evaluating Boolean circuits, therefore the reconstruction of the secret data K.sub.ipad and K.sub.opad preceding the actual signature computation exhibits a negligible overhead.

[0038] Accordingly, in the signing phase a set of m≥t signing parties (e.g., the key holders 104) evaluates with a SMC protocol the composed Boolean circuit 200, providing as input the message M to be signed and the ephemeral shares of both the secret data K.sub.ipad and K.sub.opad locally computed by each of the m signing parties from the original shares obtained during the setup phase, obtaining at the end of the SMC computation the HMAC(K,M). Thus, at block 508, the method 500 includes computing the signature using the shares from the at least t≤n of the key holders n as inputs to the SMC protocol in place of the signing key.

[0039] In some embodiments, it is important to ensure that each signing party can check the message being signed, in turn implying that the message M must be necessarily provided as input to the SMC protocol jointly by all the signing parties. If the message M was provided as an input to the SMC protocol by a single party, then such party may arbitrarily change such message, as each party has full control over its own inputs. Accordingly, the method described herein which allows all the parties involved in a SMC protocol to jointly provide a common input is specific to the SMC protocol. The described method can be employed by the signing parties to jointly provide the message M as a common input to the SMC protocol (as discussed in X. Wang, S. Ranellucci and J. Katz, “Global-Scale Secure Multiparty Computation”, Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS 2017, 2017). The methods described herein modifies the Input Processing phase of the specific SMC protocol.

[0040] With reference to the Boolean circuit 200 of FIG. 2, the input message wires 206 correspond to a set of wires I.sub.w. Then, for each wire w∈I.sub.w, each party broadcasts its authenticated random bit r.sub.w.sup.i to all other parties, who can check the integrity of such bit as for any authenticated bit employed; each party locally computes λ.sub.w=r.sub.4.sup.1⊕ . . . ⊕r.sub.w.sup.m employing the authenticated random bits received from other parties and its own authenticated random bit; given the input bit M.sub.w of the message M corresponding to wire w, which is known by all parties, each party computes the masked input bit x.sub.w=λ.sub.w⊕M.sub.w; each party P.sub.i, i≠1, sends to party P.sub.1 the label L.sub.w,x.sub.w.sup.i corresponding to the masked input x.sub.w for the wire w; and party P.sub.1 will employ the received labels {L.sub.w,x.sub.w.sup.i}.sub.i≠1 altogether with its locally computed masked input x.sub.w for the wire w to evaluate the Boolean circuit.

[0041] By following these steps, a correct signature can be obtained only if all the m parties employ the same input bit M.sub.w for all the wires w∈I.sub.w to compute the labels {L.sub.w,x.sub.w.sup.i}.sub.i≠1 and the masked input bit x.sub.w. Indeed, if all the parties P.sub.i, i≠1, provide labels for a masked input bit x′.sub.w≠x.sub.w, then the integrity checks performed by P.sub.1 during the evaluation of the circuit will fail, hence allowing P.sub.1 to detect the misbehavior of the other parties. If the parties P.sub.i, i≠1, provide labels corresponding to different masked input bits, that is there are at least two labels L.sub.w,x.sub.w.sup.i, L.sub.w,x.sub.w.sup.j with x′.sub.w≠x.sub.w for the same wire w, then P.sub.1 will not be able to compute the correct output of the circuit, which means that it is not possible to obtain a valid signature for a message M′≠M. Based on the above, all parties must agree on the message M to be signed in order to obtain a valid signature, which is crucial to prevent misuses of a threshold HMAC signature solution.

IV. Use Cases and Advantages

[0042] The methods and systems describe herein a solution to securely and reliably employ a signing key K to perform HMAC signatures. Consider a scenario where a signing key K must be employed by an application to compute HMAC signatures. The signing key K represents a valuable asset for attackers, hence to decrease the likelihood of both key theft and key misuses, the key is split among n≥2 different machines, employing an SMC protocol to compute the HMAC signature. Without a threshold HMAC signature, the unavailability of a single machine is sufficient to prevent the computation of a signature, hence making the system poorly reliable. Conversely, by employing the methods and systems described herein, it is possible to configure a threshold t guaranteeing that the application can tolerate up to n−t simultaneously unavailable machines without preventing HMAC signature computation, hence achieving a better trade-off between security and reliability.

[0043] Furthermore, since ephemeral shares can be used to reconstruct the keys via simple XOR operations, it is possible to combine a t-out-of-n secret sharing scheme with a trivial XOR-based n-out-of-n secret sharing scheme to achieve more complex access structures to compute HMAC signatures. For instance, consider an embodiment where a software company must authorize a code release by signing it with an HMAC signature, with the security requirement that at least t.sub.1 members of the software development teams, at least t.sub.2 members of the operations team and the CTO must authorize the operation. To ensure that this requirement is fulfilled, the secret S can be split among members of the organization. For example, the secret data S (i.e., K.sub.ipad and K.sub.opad) is split in 3 shares S.sub.1, S.sub.2, S.sub.3 such that S.sub.1⊕S.sub.2⊕S.sub.3=S. With such secret sharing scheme, all the 3 shares are necessary to reconstruct S. The share S.sub.1 is then further split, employing the process described in the present invention, with a t.sub.1-out-of-n.sub.1 Shamir secret sharing, where n.sub.1 is the size of the software development team. Each member receives one share. The share S.sub.2 is similarly split with a t.sub.2-out-of-n.sub.2 Shamir secret sharing, where n.sub.2 is the size of the operations team. Each member receives one share. Share S.sub.3 is given to the CTO.

[0044] To authorize a critical operation, the parties need to compute an HMAC signature with signing key K. With such a splitting scheme, the HMAC signature can be computed by evaluating with a SMC protocol the Boolean circuit 200 described herein, which reconstructs the secret input as the XOR of all the shares provided by the parties involved in the computation and then computes the HMAC signature for the input message. At least t.sub.1+t.sub.2+1 parties must be involved in the SMC protocol: the secret S is correctly reconstructed only if at least t.sub.1 parties are members of the development team (i.e., they own shares of S.sub.1), at least t.sub.2 parties are members of the operations team (i.e., they own shares of S.sub.2) and the last party is the CTO holding the share S.sub.3. The XOR of all the shares provided by members of the development team is equal to S1, the XOR of all the shares provided by members of the operations team is equal to S2, and thus the XOR of all these shares with S3 yields the secret S. Therefore, the desired security requirement on the parties required for signature computation is fulfilled, since a correct signature is obtained only if the secret is properly reconstructed with the SMC protocol, which happens only if such requirement is satisfied. It is understood that the methods and systems described herein can be applicable to other examples and use cases.

V. Definitions

[0045] The following includes definitions of selected terms employed herein. The definitions include various examples and/or forms of components that fall within the scope of a term and that may be used for implementation. The examples are not intended to be limiting. Further, the components discussed herein, may be combined, omitted or organized with other components or into different architectures.

[0046] “Bus,” as used herein, refers to an interconnected architecture that is operably connected to other computer components inside a computer or between computers. The bus may transfer data between the computer components. The bus may be a memory bus, a memory processor, a peripheral bus, an external bus, a crossbar switch, and/or a local bus, among others. The bus may also be a vehicle bus that interconnects components inside a vehicle using protocols such as Media Oriented Systems Transport (MOST), Controller Area network (CAN), Local Interconnect network (LIN), among others.

[0047] “Component,” as used herein, refers to a computer-related entity (e.g., hardware, firmware, instructions in execution, combinations thereof). Computer components may include, for example, a process running on a processor, a processor, an object, an executable, a thread of execution, and a computer. A computer component(s) may reside within a process and/or thread. A computer component may be localized on one computer and/or may be distributed between multiple computers.

[0048] “Computer communication,” as used herein, refers to a communication between two or more computing devices (e.g., computer, personal digital assistant, cellular telephone, network device, vehicle, vehicle computing device, infrastructure device, roadside device) and may be, for example, a network transfer, a data transfer, a file transfer, an applet transfer, an email, a hypertext transfer protocol (HTTP) transfer, and so on. A computer communication may occur across any type of wired or wireless system and/or network having any type of configuration, for example, a local area network (LAN), a personal area network (PAN), a wireless personal area network (WPAN), a wireless area network (WAN), a wide area network (WAN), a metropolitan area network (MAN), a virtual private network (VPN), a cellular network, a token ring network, a point-to-point network, an ad hoc network, a mobile ad hoc network, among others. Computer communication may utilize any type of wired, wireless, or network communication protocol including, but not limited to, Ethernet (e.g., IEEE 802.3), WiFi (e.g., IEEE 802.11), communications access for land mobiles (CALM), WiMax, Bluetooth, Zigbee, ultra-wideband (UWAB), multiple-input and multiple-output (MIMO), telecommunications and/or cellular network communication (e.g., SMS, MMS, 3G, 4G, LTE, 5G, GSM, CDMA, WAVE), satellite, dedicated short range communication (DSRC), among others.

[0049] “Computer-readable medium,” as used herein, refers to a non-transitory medium that stores instructions and/or data. A computer-readable medium may take forms, including, but not limited to, non-volatile media, and volatile media. Non-volatile media may include, for example, optical disks, magnetic disks, and so on. Volatile media may include, for example, semiconductor memories, dynamic memory, and so on. Common forms of a computer-readable medium may include, but are not limited to, a floppy disk, a flexible disk, a hard disk, a magnetic tape, other magnetic medium, an ASIC, a CD, other optical medium, a RAM, a ROM, a memory chip or card, a memory stick, and other media from which a computer, a processor or other electronic device may read.

[0050] “Database,” as used herein, is used to refer to a table. In other examples, “database” may be used to refer to a set of tables. In still other examples, “database” may refer to a set of data stores and methods for accessing and/or manipulating those data stores. A database may be stored, for example, at a disk and/or a memory.

[0051] “Disk,” as used herein may be, for example, a magnetic disk drive, a solid-state disk drive, a floppy disk drive, a tape drive, a Zip drive, a flash memory card, and/or a memory stick. Furthermore, the disk may be a CD-ROM (compact disk ROM), a CD recordable drive (CD-R drive), a CD rewritable drive (CD-RW drive), and/or a digital video ROM drive (DVD ROM). The disk may store an operating system that controls or allocates resources of a computing device.

[0052] “Logic circuitry,” as used herein, includes, but is not limited to, hardware, firmware, a non-transitory computer readable medium that stores instructions, instructions in execution on a machine, and/or to cause (e.g., execute) an action(s) from another logic circuitry, module, method and/or system. Logic circuitry may include and/or be a part of a processor controlled by an algorithm, a discrete logic (e.g., ASIC), an analog circuit, a digital circuit, a programmed logic device, a memory device containing instructions, and so on. Logic may include one or more gates, combinations of gates, or other circuit components. Where multiple logics are described, it may be possible to incorporate the multiple logics into one physical logic. Similarly, where a single logic is described, it may be possible to distribute that single logic between multiple physical logics.

[0053] “Memory,” as used herein may include volatile memory and/or nonvolatile memory. Non-volatile memory may include, for example, ROM (read only memory), PROM (programmable read only memory), EPROM (erasable PROM), and EEPROM (electrically erasable PROM). Volatile memory may include, for example, RAM (random access memory), synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), and direct RAM bus RAM (DRRAM). The memory may store an operating system that controls or allocates resources of a computing device.

[0054] “Operable connection,” or a connection by which entities are “operably connected,” is one in which signals, physical communications, and/or logical communications may be sent and/or received. An operable connection may include a wireless interface, a physical interface, a data interface, and/or an electrical interface.

[0055] “Processor,” as used herein, processes signals and performs general computing and arithmetic functions. Signals processed by the processor may include digital signals, data signals, computer instructions, processor instructions, messages, a bit, a bit stream, that may be received, transmitted and/or detected. Generally, the processor may be a variety of various processors including multiple single and multicore processors and co-processors and other multiple single and multicore processor and co-processor architectures. The processor may include logic circuitry to execute actions and/or algorithms.

[0056] The embodiments discussed herein can also be described and implemented in the context of “computer-readable medium” or “computer storage medium.” As used herein, “computer-readable medium” or “computer storage medium refers to a non-transitory medium that stores instructions, algorithms, and/or data configured to perform one or more of the disclosed functions when executed. Computer-readable medium can be non-volatile, volatile, removable, and non-removable, media implemented in any method or technology for storage of information such as computer readable instructions, data structures, modules or other data. Computer-readable medium can include, but is not limited to, a floppy disk, a flexible disk, a hard disk, a magnetic tape, other magnetic medium, an application specific integrated circuit (ASIC), a programmable logic device, a compact disk (CD), other optical medium, a random access memory (RAM), a read only memory (ROM), a memory chip or card, a memory stick, solid state storage device (SSD), flash drive, and other media from which a computer, a processor or other electronic device can interface with. Computer-readable medium excludes non-transitory tangible media and propagated data signals.

[0057] It will be appreciated that various embodiments of the above-disclosed and other features and functions, or alternatives or varieties thereof, may be desirably combined into many other different systems or applications. Also, that various presently unforeseen or unanticipated alternatives, modifications, variations or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.