WO2023036408A1

WO2023036408A1 - Method and system of computing hash based message authentication code

Info

Publication number: WO2023036408A1
Application number: PCT/EP2021/074657
Authority: WO
Inventors: Yong Li
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-09-08
Filing date: 2021-09-08
Publication date: 2023-03-16
Also published as: EP4268411A1

Abstract

A method of computing a hash-based message authentication code (HMAC). The method includes dividing a HMAC key into three random key shares, each random key share is stored by one of three parties. The method further includes computing a HMAC value for a message by the three parties performing a circuit based multi-party protocol that includes steps of cooperative hash function computation, where an input of each party into each step includes the random key share stored by the party. The method provides an efficient software key protection with an enhanced security.

Description

METHOD AND SYSTEM OF COMPUTING HASH BASED MESSAGE AUTHENTICATION CODE

TECHNICAL FIELD

The present disclosure relates generally to the field of network security systems and more specifically, to a method and a system of computing a hash-based message authentication code (HMAC) using multi party computation techniques in order to maintain integrity of a message transmitted over a network security system.

BACKGROUND

Generally, a software key protection provides a basic security to a typical network security system. Typically, a physical hardware security module (HSM) is used for the software key protection. The physical HSM is secure up to a certain extent and can reach a federal information processing standard (FIPS) 140 level 3. However, there are certain limitations associated with the physical HSM, such as the physical HSM is too much expensive (e.g., a high-end Thales HSM costs about 100,000 $ USD) and difficult to deploy, especially in a cloud environment. Moreover, the physical HSM is not agile because it takes several years usually, to add a new function and also, requires an export control by a third party. Moreover, the dependence on a trusted third party makes the physical HSM unsuitable for the network security system. Further, the non-interoperability of the physical HSM(s) by different vendors makes difficult to use the physical HSM(s) for the software key protection because huge number of keys cannot be managed by one vendor and very difficult to be managed in physical HSM(s) of other vendors. Thus, an enhanced security for the software key protection without the physical HSM is desirable because the physical HSM is cost intensive and difficult to deploy. Thereafter, the key protection is performed without any physical HSM. Alternatively stated, if a high-security key is stored and used without any physical HSM (e.g., trusted platform module, TPM, trusted execution environment, TEE, and the like) which may lead either a loss of the key or stealing of the key by an attacker. Currently, certain attempts have been made for the software key protection without using any physical HSM, such as a conventional secret sharing method which is used to protect the software keys between different devices. In the conventional secret sharing method, the software key (K) is split into two random keys, kland k2 (e.g., K = kl XOR fc2) and shared with different devices. After splitting and sharing, the random keys are merged as K = f (fcl, fc2) in a memory and computation is done using a plain text (P) as C = F(K, P). After computation, the software key K appears in the memory, which may cause key leakage and result in memory-based attacks by attackers (or hackers). Thus, there exists a technical problem of inefficient software key protection resulting in a loss or stealing of the software key of the typical network security system. After which, the typical network security system become more prone to memory-based attacks leading to data breach also.

Therefore, in light of the foregoing discussion, there exists a need to overcome the aforementioned drawbacks associated with the conventional methods used for the software key protection of the typical network security system.

SUMMARY

The present disclosure provides a method and a system of computing a hash-based message authentication code (HMAC) using multi party computation techniques in order to maintain integrity and confidentiality of a message transmitted over a network security system. The present disclosure provides a solution to the existing problem of inefficient software key protection resulting in a loss or stealing of the key of the typical network security system. After which, the typical network security system become more prone to memory-based attacks leading to data breach also. An objective of the present disclosure is to provide a solution that overcomes at least partially the problems encountered in the prior art and provides an improved method and a system of computing a hash-based authentication code (HMAC) that provides an enhanced security for the software key protection without using any third party and any additional physical hardware security module.

One or more objectives of the present disclosure is achieved by the solutions provided in the enclosed independent claims. Advantageous implementations of the present disclosure are further defined in the dependent claims. In one aspect, the present disclosure provides a method of computing a hash-based message authentication code (HMAC). The method comprises dividing an HMAC key into three random key shares, each random key share is stored by one of three parties. The method further comprises computing an HMAC value for a message by the three parties performing a circuit based multi-party protocol that comprises steps of cooperative hash function computation, where an input of each party into each step comprises the random key share stored by the party.

The disclosed method provides an efficient software key protection with an enhanced security. The method is used for computation of the hash-based message authentication code (HMAC) using multi-party computation technique for software key protection with an enhanced security. Additionally, the method supports the HMAC value (i.e., original HMAC) computation and provides software multi-party key protection with high security. For computation of the HMAC value, the HMAC key is never used in a plain text. In spite of using the HMAC key directly, the three random key shares of the HMAC key are used in computation of the HMAC value, hence, security of the HMAC key is not affected even when one party is attacked by an attacker (or a hacker). Alternatively stated, the division of the HMAC key into the three random key shares ensures a dynamic security of the HMAC key. Furthermore, the method computes the HMAC value without any hardware security module thus, reducing overall cost of computation of the HMAC value and easy to deploy in a system, especially in a cloud environment. Moreover, the method requires no additional trusted third party therefore, it become easy to manage the HMAC key.

In an implementation form, the circuit based multi-party protocol comprises three steps of cooperative hash function computation.

The circuit based multi-party protocol comprises three steps of cooperative hash function computation in order to maintain confidentiality of the HMAC key.

In a further implementation form, the first step comprises the three parties cooperatively computing a first preliminary hash code being a result of a hash function of the HMAC key exclusive or, XOR, an input padding, where the input padding is provided by the first party and the first preliminary hash code is stored by the first party. Beneficially, the hash function is performed on the HMAC key that is combined with the input padding using XOR hence, the HMAC key is not used in a plain text and therefore, security of the HMAC key is ensured using the boolean gate (XOR).

In a further implementation form, the second step comprises the three parties cooperatively computing a second preliminary hash code being a result of the hash function of the HMAC key XOR an output padding, where the output padding is provided by the third party and the second preliminary hash code is stored by the third party.

Beneficially, the hash function is performed on the HMAC key that is combined with the output padding using XOR hence, the HMAC key is not used in a plain text and therefore, security of the HMAC key is not affected.

In a further implementation form, the hash function includes the Secure Hash Algorithm Version 2, SHA-2, and the Secure Hash Algorithm Version 3, SHA-3, functions, and the hash function is computed by means of circuits including a garbled circuit, GC, and a secret sharing based circuit.

By virtue of using the hash function as the secure hash algorithm, collision resistance property is added to the HMAC key.

In a further implementation form, the third step comprises the three parties cooperatively computing the HMAC value being a result of an HMAC function of the HMAC key and the message.

The computation of the HMAC value as the result of HMAC function of the HMAC key and the message requires no additional trusted third party.

In a further implementation form, the third step comprises the first party computing a first hash code by means of the hash function based on a first block of the message and the first preliminary hash code, the second party computing a second hash code by means of the hash function based on the rest blocks of the message and the first hash code, and the third party computing the HMAC value by means of the hash function based on the second hash code and the second preliminary hash code. The computation of the HMAC value using the hash function adds security to the HMAC key as well as provides cost effective implementation in a system, for example, in a cloud environment.

In a further implementation form, the second party computing the second hash code comprises the second party iteratively computing the hash function using a next block of the message and an output of a previous iteration as an input of each iteration, where a second block of the message and the first hash code are used as an input of the first iteration, if the message comprises more than one block, and the second party setting the second hash code equal to the first hash code, if the message comprises one block, where a message block length is defined by a hash block length.

By virtue of computing the second hash code iteratively, one more layer of security is added to the HMAC key.

In another aspect, the present disclosure provides a system for computing a hash-based message authentication code (HMAC). The system comprises three parties, each party storing a random key share of an HMAC key, where the three parties are configured for computing an HMAC value for a message by performing a circuit based multi-party protocol comprising steps of cooperative hash function computation, where an input of each party into each step comprises the random key share stored by the party.

The disclosed system achieves all the advantages and technical features of the method of the present disclosure after executing the method.

In an implementation form, the parties are configured for implementing the method.

Each of the three parties is configured to execute the method hence, each party achieves all the advantages and technical features of the method.

It is to be appreciated that all the aforementioned implementation forms can be combined. It has to be noted that all devices, elements, circuitry, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. It will be appreciated that features of the present disclosure are susceptible to being combined in various combinations without departing from the scope of the present disclosure as defined by the appended claims.

Additional aspects, advantages, features and objects of the present disclosure would be made apparent from the drawings and the detailed description of the illustrative implementations construed in conjunction with the appended claims that follow.

BRIEF DESCRIPTION OF THE DRAWINGS

The summary above, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the present disclosure, exemplary constructions of the disclosure are shown in the drawings. However, the present disclosure is not limited to specific methods and instrumentalities disclosed herein. Moreover, those in the art will understand that the drawings are not to scale. Wherever possible, like elements have been indicated by identical numbers.

Embodiments of the present disclosure will now be described, by way of example only, with reference to the following diagrams wherein:

FIG. l is a flowchart of a method of computing a hash-based message authentication code, (HMAC), in accordance with an embodiment of the present disclosure;

FIG. 2 is a block diagram that illustrates various exemplary components of a system, in accordance with an embodiment of the present disclosure;

FIG. 3 illustrates a process diagram of a first pre-computation performed by the three parties, in accordance with an embodiment of the present disclosure;

FIG. 4 illustrates a process diagram of a second pre-computation performed by three parties, in accordance with an embodiment of the present disclosure; FIG. 5 illustrates a relationship between three parties for online computation of a HMAC value, in accordance with an embodiment of the present disclosure;

FIG. 6 illustrates a process diagram of online multi-party HMAC computation, in accordance with an embodiment of the present disclosure; and

FIG. 7 illustrates a process diagram of online multi-party HMAC computation using boolean gates, in accordance with an embodiment of the present disclosure.

In the accompanying drawings, an underlined number is employed to represent an item over which the underlined number is positioned or an item to which the underlined number is adjacent. A non-underlined number relates to an item identified by a line linking the nonunderlined number to the item. When a number is non-underlined and accompanied by an associated arrow, the non-underlined number is used to identify a general item at which the arrow is pointing.

DETAILED DESCRIPTION OF EMBODIMENTS

The following detailed description illustrates embodiments of the present disclosure and ways in which they can be implemented. Although some modes of carrying out the present disclosure have been disclosed, those skilled in the art would recognize that other embodiments for carrying out or practicing the present disclosure are also possible.

FIG. 1 is a flowchart of a method of computing a hash-based message authentication code (HMAC), in accordance with an embodiment of the present disclosure. With reference to FIG. 1, there is shown a method 100 for computing a HMAC value. The method 100 includes steps 102 and 104. The method 100 is executed by a system, described in detail, for example, in FIG. 2.

The present disclosure provides a method 100 of computing a hash-based message authentication code, HMAC, the method 100 comprising: dividing an HMAC key into three random key shares, each random key share being stored by one of three parties; computing an HMAC value for a message by the three parties performing a circuit based multi-party protocol comprising steps of cooperative hash function computation, where an input of each party into each step comprises the random key share stored by the party. The method 100 is used for computation of a hash-based message authentication code (HMAC) using multi-party computation (MPC) technique for software key protection with an enhanced security.

At step 102, the method 100 comprises dividing an HMAC key into three random keys shares. Each random key share is stored by one of the three parties. For example, the HMAC key (also represented as K) is divided into three random key shares, such as a first random key share (also represented as K’ l), a second random key share (also represented as K’2) and a third random key share (also represented as K’3) in such a way that the HMAC key is obtained using K = K'I XOR K'2 XOR K'3. Further, each of the first random key share (K’ 1), the second random key share (K’2) and the third random key share (K’3) is stored by one of the three parties, such as a first party, a second party and a third party, respectively. In this way, the first party stores the first random key share (K’ l), the second party stores the second random key share (K’2) and the third party stores the third random key share (K’3). Moreover, as the HMAC key (K) is distributed to the three parties, therefore, security of the HMAC key (K) is not affected even when one of the three parties is attacked by an attacker (or a hacker).

At step 104, the method 100 further comprises computing an HMAC value for a message by the three parties performing a circuit based multi-party protocol comprising steps of cooperative hash function computation, where an input of each party into each step comprises the random key share stored by the party. In an implementation, the HMAC value for the message is computed by the three parties, such as the first party, the second party and the third party. The computation of the HMAC value is performed using the circuit based multi-party protocol. The multi-party protocol includes computation of cooperative hash function by the three parties such as the first party, the second party and the third party. The computation of the cooperative hash function includes the input from each party which is provided in terms of the random key share stored by each of the three parties. Thus, during the computation of the HMAC value for the message, the HMAC key (K) is not reconstructed, hence, the HMAC key (K) does not appear in a memory that further ensures the security of the HMAC key. This may also be termed as a software multi-party key protection with high security. In accordance with an embodiment, the circuit based multi-party protocol comprises three steps of cooperative hash function computation. The HMAC value for the message is calculated together by the three parties such as the first party, the second party and the third party using the circuit based multi-party protocol. The circuit based multi-party protocol includes use of the cooperative hash function that is computed in three steps, described in detail, for example, in FIGs. 3, 4, and 5.

In accordance with an embodiment, the first step comprises the three parties cooperatively computing a first preliminary hash code being a result of a hash function of the HMAC key exclusive or, XOR, an input padding, where the input padding is provided by the first party and the first preliminary hash code is stored by the first party. The first step of computing the cooperative hash function includes the three parties, such as the first party, the second party and the third party, to cooperatively compute the first preliminary hash code. The first preliminary hash code is generated by use of the hash function on the HMAC key (K) that is combined with the input padding by using a boolean function, such as exclusive or (also represented as XOR). The input padding is provided by the first party and the generated first preliminary hash code is stored by the first party. The computation of the first preliminary hash code is described in detail, for example, in FIG. 3.

In accordance with an embodiment, the second step comprises the three parties cooperatively computing a second preliminary hash code being a result of the hash function of the HMAC key XOR an output padding, where the output padding is provided by the third party and the second preliminary hash code is stored by the third party. The second step of computing the cooperative hash function also includes the three parties, such as the first party, the second party and the third party, to cooperatively compute the second preliminary hash code. The second preliminary hash code is generated by using the boolean function, such as exclusive or (i.e., XOR) of the HMAC key and the output padding followed by the hash function applied on the HMAC key and the output padding. The output padding is provided by the third party and the generated second preliminary hash code is stored by the third party as well. The computation of the second preliminary hash code is described in detail, for example, in FIG. 4.

In accordance with an embodiment, the hash function includes the Secure Hash Algorithm Version 2 (SHA-2), and the Secure Hash Algorithm Version 3 (SHA-3) functions, and the hash function is computed by means of circuits including a garbled circuit (GC) and a secret sharing (SS) based circuit. The multi-party protocol used for computation of the HMAC value includes computation of the cooperative hash function. Generally, the hash function is used to map data of an arbitrary size to a fixed-size data. The hash function includes the Secure Hash Algorithm Version 2 (SHA-2), and the Secure Hash Algorithm Version 3 (SHA-3) functions. The hash function is computed by using the garbled circuit (GC) and secret sharing (SS) based circuit. The garbled circuit encrypts a computation and reveals a final output without disclosing any input value or intermediate value(s). Therefore, use of the garbled circuit (GC) for the HMAC key protection provides an added security. The secret sharing (SS) based circuit divides an original data to multiple parties and hence, the original data is not affected if any one of the multiple parties is attacked by a hacker. Therefore, computation of the hash function using the garbled circuit (GC) and the secret sharing (SS) based circuit generates a highly secure HMAC value without requiring any third-party dependence and any additional hardware (e.g., hardware security modules).

In accordance with an embodiment, the third step comprises the three parties cooperatively computing the HMAC value being a result of an HMAC function of the HMAC key and the message. The third step of computing the cooperative hash function includes the three parties to cooperatively compute the HMAC value. The HMAC value for the message is obtained as the result of applying the HMAC function on the HMAC key and the message. The computation of the HMAC value in the third step may also be referred to as an online computation of the HMAC value, described in detail, for example, in FIGs. 5, 6, and 7.

In accordance with an embodiment, the third step comprises the first party computing a first hash code by means of the hash function based on a first block of the message and the first preliminary hash code. The third step further comprises the second party computing a second hash code by means of the hash function based on the rest blocks of the message and the first hash code. The third step further comprises the third party computing the HMAC value by means of the hash function based on the second hash code and the second preliminary hash code. The third step of the cooperative hash function computation comprises that the first party generates the first hash code using the hash function based on the first message block and the first preliminary hash code stored by the first party. The third step further comprises that the second party computes the second hash code using the hash function based on the first hash code and rest blocks of the message. For computation of the second hash code, the first hash code as well as rest blocks of the message are provided as an input to the second party. Additionally, the third step further comprises that the third party computes the HMAC value using the hash function based on the second hash code and the second preliminary hash code. The HMAC value is provided as an output by the third party.

In accordance with an embodiment, the second party computing the second hash code comprises the second party iteratively computing the hash function using a next block of the message and an output of a previous iteration as an input of each iteration. A second block of the message and the first hash code are used as an input of the first iteration, if the message comprises more than one block. The second party setting the second hash code equal to the first hash code, if the message comprises one block, where a message block length is defined by a hash block length. The computation of second hash code by the second party depends on message block length or the hash block length (M). If the message comprises more than one block then in the first iteration of computing the second hash code, the second block of the message and the first hash code are used as input to the first iteration. Thereafter, the output of the first iteration and the next message block (e.g., a third message block) are considered as an input to the next iteration (e.g., a second iteration) and so on. In other words, the second party computes the second hash code by iteratively computing the hash function using the next block of the message and the output from the previous iteration. In an implementation, if the message is of one block length, then the first hash code and the second hash code are considered same. The process of iteratively computing the second hash code is described in detail, for example, in FIGs. 6, and 7.

Thus, the method 100 provides an efficient software key protection with an enhanced security as well. The method 100 is used for computation of the hash-based message authentication code (HMAC) using multi-party computation (MPC) technique for software key protection with an enhanced security. Additionally, the method 100 supports original HMAC (i.e., the HMAC value) computation and provides software multi-party key protection with high security. For computation of the HMAC value, the HMAC key is used never in a plain text. In spite of using the HMAC key, the three random key shares of the HMAC key are used in computation of the HMAC value, hence, security of the HMAC key is not affected even when one party is attacked by an attacker (or a hacker). Furthermore, the method 100 computes the HMAC value without any hardware (HSM) thus, reducing overall cost of computation of the HMAC value and easy to deploy in a system, especially in a cloud environment. Moreover, the method 100 requires no additional trusted third party therefore, it become easy to manage the HMAC key. Furthermore, the method 100 employs use of boolean functions, such as exclusive or (XOR) for computing the HMAC key and the first preliminary hash code.

The steps 102 and 104 are only illustrative and other alternatives can also be provided where one or more steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.

FIG. 2 is a block diagram that illustrates various exemplary components of a system, in accordance with an embodiment of the present disclosure. FIG. 2 is described in conjunction with elements from FIG. 1. With reference to FIG. 2, there is shown a block diagram 200 of a system 202. The system 202 includes three parties 203, such as a first party 204, a second party 206, and a third party 208. The system 202 further includes a memory 210, a network interface 212 and a processor 214. The system 202 is configured to execute the method 100 (of FIG. 1).

The system 202 may include suitable logic, circuitry, interfaces, or code that is configured to compute a hash-based message authentication code (HMAC) value for a message using a HMAC key. For computation of the HMAC value, the HMAC key is not used in plain text. However, the HMAC key is divided into three random key shares, each random key share is stored by each of the three parties 203. Examples of the system 202 includes, but are not limited to, a network security system, a server, a cloud server, a web server, an application server, or a combination thereof.

Each of the first party 204, the second party 206 and the third party 208 includes suitable logic, circuitry, interfaces, or code that is configured to store their respective random key share of the HMAC key. Examples of each of the first party 204, the second party 206 and the third party 208 include but are not limited to, a client device, a user device and the like.

The memory 210 includes suitable logic, circuitry, interfaces, or code that is configured to store data and the instructions executable by the processor 214. Examples of implementation of the memory 210 may include, but are not limited to, an Electrically Erasable Programmable Read-Only Memory (EEPROM), Random Access Memory (RAM), Read Only Memory (ROM), Hard Disk Drive (HDD), Flash memory, Solid-State Drive (SSD), or CPU cache memory. The memory 210 may store an operating system or other program products (including one or more operation algorithms) to operate the system 202.

The network interface 212 includes suitable logic, circuitry, interfaces, or code that is configured to communicate with each of the first party 204, the second party 206 and the third party 208. In an implementation, the network interface 212 is configured to receive a first hash code generated by the first party 204 and transmit the first hash code to the second party 206 for computation of a second hash code. The network interface 212 is further configured to receive the second hash code from the second party 206 and transmit the second hash code to the third party 208 for computation of the HMAC value at the third party 208. Examples of the network interface 212 include, but are not limited to, a data terminal, a transceiver, a facsimile machine, a virtual server, and the like.

The processor 214 includes suitable logic, circuitry, interfaces, or code that is configured to execute the instructions stored in the memory 210. In an example, the processor 214 may be a general-purpose processor. Other examples of the processor 214 may include, but is not limited to a hash controller, a central processing unit (CPU), a digital signal processor (DSP), a microprocessor, a microcontroller, a complex instruction set computing (CISC) processor, an application-specific integrated circuit (ASIC) processor, a reduced instruction set (RISC) processor, a very long instruction word (VLIW) processor, a central processing unit (CPU), a state machine, a data processing unit, and other processors or control circuitry.

In another aspect, the present disclosure provides a system 202 for computing a hash-based message authentication code (HMAC). The system 202 comprises three parties 203, such as the first party 204, the second party 206 and the third party 208, each party storing a random key share of an HMAC key, where the three parties 203 are configured for computing an HMAC value for a message by performing a circuit based multi-party protocol comprising steps of cooperative hash function computation, where an input of each party into each step comprises the random key share stored by the party. Each of the three parties 203, such as the first party 204, the second party 206 and the third party 208 is configured to store the random key share of the HMAC key. Thereafter, each of the three parties 203 is configured to cooperatively compute the HMAC value for the message using the circuit based multiparty protocol. The circuit based multi-party protocol includes computation of cooperative hash function by the three parties 203 in three steps. For computation of cooperative hash function in three steps, the random key share stored by each of the three parties 203 is used as the input into each step.

In operation, the system 202 is configured to divide the HMAC key (K) into three random key shares, such as a first random key share (K’ 1), a second random key share (K’2) and a third random key share (K’3) such that K = K'l XOR K'2 XOR K'3. Thereafter, the system 202 is further configured to compute the HMAC value for the message by virtue of the three parties 203. Each of the three parties 203, such as the first party 204, the second party 206 and the third party 208 is configured to perform the circuit based multi-party protocol. The circuit based multi-party protocol includes computation of cooperative hash function in three steps. For computation of cooperative hash function in three steps, the random key share stored by each of the three parties 203 is used as the input into each step. In a first step, the three parties 203 cooperatively compute a first preliminary hash code by applying a hash function on an exclusive or (XOR) of the HMAC key (K) and an input padding (iPad). The input padding (iPad) is provided by the first party 204 and also, the computed first preliminary hash code is stored by the first party 204. The hash function includes a SHA-2 function, SHA-3 function, which have been described earlier, for example, in FIG. 1. The hash function is applied by use of a garbled circuit (GC) and secret sharing (SS) based circuit, have been described in detail, for example, in FIG. 1. The first step of computing the cooperative hash function is described in detail, for example, in FIG. 3. In a second step, the three parties 203 cooperatively compute a second preliminary hash code by applying a hash function on an exclusive or (XOR) of the HMAC key (K) and an output padding (oPad). The output padding (oPad) is provided by the third party 208 and also, the computed second preliminary hash code is stored by the third party 208. The second step of computing the cooperative hash function is described in detail, for example, in FIG. 4. In a third step, the three parties 203 cooperatively compute a HMAC value by applying a HMAC function on the HMAC key and the message. The third step of computing the cooperative hash function is described in detail, for example, in FIGs. 6 and 7. In accordance with an embodiment, the parties are configured for implementing the method 100. Each of the three parties 203 of the system 202, such as the first party 204, the second party 206 and the third party 208 is configured to execute the method 100 (of FIG. 1).

Thus, the system 202 provides an efficient software multi-party key protection with an enhanced security. The system 202 is used for computation of the hash-based message authentication code (HMAC) value using multi-party computation (MPC) technique. Additionally, the system 202 supports original HMAC (i.e., the HMAC value) computation and provides software multi-party key protection with high security. For computation of the HMAC value, the HMAC key is never used in a plain text. In spite of using the HMAC key in the plain text, the three random key shares (i.e., K’ 1, K’2 and K’3) of the HMAC key are used in computation of the HMAC value, hence, security of the HMAC key is not affected even when one party is attacked by an attacker (or a hacker). Furthermore, the system 202 computes the HMAC value without any hardware (i.e., hardware security module) thus, reducing overall cost of computation of the HMAC value and easy to deploy in a cloud environment. Moreover, the system 202 requires no additional trusted third party therefore, it become easy to manage the HMAC key as well.

FIG. 3 illustrates a process diagram of a first pre-computation performed by three parties, in accordance with an embodiment of the present disclosure. FIG. 3 is described in conjunction with elements from FIG. 2. With reference to FIG. 3, there is shown a process diagram 300 of a first pre-computation 302 that is cooperatively performed by the three parties 203 (i.e., the first party 204, the second party 206, and the third party 208) of the system 202 (of FIG. 2). There is further shown an input padding 304, a garbled circuit (GC) 306A, a secret sharing based circuit 306B, a hash function 308 and an output 310.

The first pre-computation 302 corresponds to a first step of cooperative hash function computation comprised by a circuit based multi-party protocol. Generally, a first precomputation (or the first pre-computation 302) is performed in the field of security and privacy such as in cryptography, symmetric cryptography with a hash function, security in hardware devices, tamper proof and tamper resistant devices, and the like.

The input padding 304 (also represented as iPad) represents an input to the garbled circuit 306A and the secret sharing based circuit 306B. The input padding 304 (i.e., iPad) is provided by the first party 204. Examples of input padding 304 include, but are not limited to, a binary input of either 256 bits, or 512 bits and the like.

The garbled circuit 306A and the secret sharing based circuit 306B is configured to execute the circuit based multi-party protocol. The garbled circuit 306A applies a cryptographic protocol that enables secure computation of two mistrusting parties that jointly evaluate a function, such as the hash function 308, over their private inputs without the presence of a trusted third party. The secret sharing based circuit 306B enables parties to securely compute a function on their secret inputs and receive the secret outputs, without leaking any information to other parties. Examples of the circuit based multi-party protocol include, but are not limited to, a sharemind and speedz (SPDZ) protocol, and the like.

The hash function 308 is a mathematical function that maps data of an arbitrary size to a bit array of fixed size. The hash function 308 is performed on XOR of the HMAC key (K) and the input padding 304 (i.e., iPad). Examples of the hash function include, but are not limited to, a SHA-2 (e.g., SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256), SHA-3 (e.g., SHA3-224, SHA3-256, SHA3-384, SHA3-512), and the like. The output 310 (also represented as Fl) corresponds to a first preliminary hash code. Examples of the output 310 (i.e., Fl) include, but are not limited to a binary output.

Initially, each of the first party 204, the second party 206 and the third party 208 is configured to provide their respective random key share to the garbled circuit 306A and the secret sharing based circuit 306B. The three random key shares of the HMAC key, such as the first random key share (K’ 1), the second random key share (K’2) and the third random key share (K’3) are combined using boolean function (e.g., exclusive or, XOR) in such a way that the HMAC key is obtained using K = K'l XOR K'2 XOR K'3. Thereafter, the input padding 304 (iPad) is provided by the first party 204 to the garbled circuit 306A and the secret sharing based circuit 306B, for computation of the output 310 (or the first preliminary hash code, Fl). After receiving the three random key shares of the HMAC key from the first party 204, the second party 206 and the third party 208, respectively, and the input padding 304 (iPad) from the first party 204, the garbled circuit 306A and the secret sharing based circuit 306B is configured to compute the hash function 308 according to equation (1)

Fl = Hash (K XOR iPad) (1) After computing the hash function 308, the output 310 (or the first preliminary hash code, Fl) is generated which is stored by the first party 204. In an implementation, the garbled circuit 306A and the secret sharing based circuit 306B may be stored in the memory 210 of the system 202 (of FIG. 2).

In accordance with the embodiment, the first step comprises the three parties 203 cooperatively computing the first preliminary hash code being a result of the hash function 308 of the HMAC key exclusive or, XOR, the input padding 304. The input padding 304 is provided by the first party 204 and the first preliminary hash code is stored by the first party 204. In the first step of cooperative hash function, the first party 204, the second party 206 and the third party 208 is configured to cooperatively compute the first preliminary hash code (i.e., the output 310, Fl). The first preliminary hash code (i.e., the output 310, Fl) is obtained as a result of computing the hash function 308 on the HMAC key which is combined with the input padding 304 (iPad) using exclusive or, XOR, (boolean function). Moreover, the input padding 304 (iPad) for computation of the first preliminary hash code (i.e., the output 310, Fl) is provided by the first party 204. The first preliminary hash code (i.e., the output 310, Fl) is stored by the first party 204 as well.

FIG. 4 illustrates a process diagram of a second pre-computation performed by three parties, in accordance with an embodiment of the present disclosure. FIG. 4 is described in conjunction with elements from FIGs. 2, and 3. With reference to FIG. 4, there is shown a process diagram 400 of a second pre-computation 402 that is cooperatively performed by the three parties 203 (i.e., the first party 204, the second party 206, and the third party 208) of the system 202 (of FIG. 2). There is further shown an output padding 404, a hash function 406 and an output 408.

The second pre-computation 402 corresponds to a second step of cooperative hash function computation comprised by a circuit based multi-party protocol. Alternatively stated, the second pre-computation 402 corresponds to a process of computing a second preliminary hash code using the hash function 406. Similar to the first pre-computation 302, the second pre-computation 402 is generally performed in the field of security and privacy such as in cryptography, symmetric cryptography with a hash function, security in hardware devices, tamper proof and tamper resistant devices, and the like. The output padding 404 (also represented as oPad) represents a binary input provided by the third party 208 to the garbled circuit 306A and the secret sharing based circuit 306B, for computation of the output 408 (or the second preliminary hash code, F2). Examples of output padding 404 include, but are not limited to, a binary input of either 256 bits, or 512 bits and the like.

The hash function 406 corresponds to the hash function 308 (of FIG. 3). The hash function 406 is performed on XOR of the HMAC key (K) and the output padding 404 (i.e., oPad).

The output 408 (also represented as F2) corresponds to a second preliminary hash code. Examples of the output 408 (i.e., F2) include, but are not limited to a binary output.

Initially, each of the first party 204, the second party 206 and the third party 208 is configured to provide their respective random key share to the garbled circuit 306A and the secret sharing based circuit 306B. The three random key shares of the HMAC key, such as the first random key share (K’ 1), the second random key share (K’2) and the third random key share (K’3) are combined using a boolean function (e.g., exclusive or, XOR) in such a way that the HMAC key is obtained using K = K'l XOR K'2 XOR K'3. Thereafter, the output padding 404 (oPad) is provided by the third party 208 to the garbled circuit 306A and the secret sharing based circuit 306B, for computation of the output 408 (or the second preliminary hash code, F2). After receiving the three random key shares of the HMAC key from the first party 204, the second party 206 and the third party 208, respectively, and the output padding 404 (oPad) from the third party 208, the garbled circuit 306A and the secret sharing based circuit 306B is configured to compute the hash function 406 according to equation (2)

F2 = Hash (K XOR oPad) (2)

After computing the hash function 406, the output 408 (or the second preliminary hash code, F2) is generated which is stored by the third party 208.

In accordance with the embodiment, the second step comprises the three parties 203 cooperatively computing the second preliminary hash code being a result of the hash function 406 of the HMAC key exclusive or, XOR, the output padding 404. The output padding 404 is provided by the third party 208 and the second preliminary hash code (i.e., the output 408) is stored by the third party 208. In the second step of cooperative hash function, the first party 204, the second party 206 and the third party 208 is configured to cooperatively compute the second preliminary hash code (i.e., the output 408, F2). The second preliminary hash code (i.e., the output 408, F2) is obtained as a result of computing the hash function 406 on the HMAC key which is combined with the output padding 404 (oPad) using exclusive or, XOR, (i.e., a boolean function). Moreover, the output padding 404 (oPad) for computation of the second preliminary hash code (i.e., the output 408, F2) is provided by the third party 208. The second preliminary hash code (i.e., the output 408, F2) is stored by the third party 208.

FIG. 5 illustrates a relationship between three parties for online computation of a HMAC value, in accordance with an embodiment of the present disclosure. FIG. 5 is described in conjunction with elements from FIGs. 2, 3 and 4. With reference to FIG. 5, there is shown a process diagram 500 that illustrates an online computation 502 of a HMAC value by the three parties 203 (of FIG. 2). There is further shown a first hash code 504, a second hash code 506 and an output 508. The online computation 502 of the HMAC value corresponds to three party based HMAC computation. Alternatively stated, each of the first party 204, the second party 206 and the third party 208 is configured to cooperatively perform the online computation 502 of the HMAC value according to equation (3)

Output = HMAC K, M') (3) where, M is a message and K is the HMAC key. After performing the online computation 502 of the HMAC value, the third party 208 obtains the output 508 of HMAC function of the message (M). The message (M) includes a fixed number of message blocks, such as a first message block, a second message block and so on, described in detail, for example, in FIG. 6.

The online computation 502 of the HMAC value is performed in three steps. In first step, the first party 204 is configured to compute the first hash code 504 (also represented as tl) by means of the hash function 308 on the first block of the message (M) and the first preliminary hash code (i.e., the output 310, Fl, of FIG. 3). Thereafter, the network interface 212 of the system 202 (of FIG. 2) is configured to communicate the first hash code 504 (i.e., tl) to the second party 206 for further computation. In second step, the second party 206 is configured to compute the second hash code 506 (also represented as t2) by means of the hash function 406 based on rest blocks of the message (M) and the first hash code 504 (tl). Thereafter, the network interface 212 of the system 202 (of FIG. 2) is configured to communicate the second hash code 506 (i.e., t2) to the third party 208 for further computation. In third step, the third party 208 is configured to compute the output 508 (i.e., HMAC value) for the message (M) by means of the hash function based on the second hash code 506 (t2) and the second preliminary hash code (i.e., the output 408, F2, of FIG. 4). In this way, the output 508 (i.e., HMAC value) for the message (M) is computed as a result of the HMAC function of the HMAC key (K) and the message (M). The computation of the output 508 (i.e., HMAC value) for the message (M) is described in more detail, for example, in FIG. 6.

FIG. 6 illustrates a process diagram of online multi-party HMAC computation, in accordance with an embodiment of the present disclosure. FIG. 6 is described in conjunction with elements from FIGs. 3, 4, and 5. With reference to FIG. 6, there is shown a process diagram 600 that illustrates an online computation 602 of a HMAC function by the three parties 203 (of FIG. 2). There is further shown various blocks of a message, such as a first block 604A of the message (M), a second block 604B of the message (M) up to an ith block 6041 of the message (M) and a hash function 606.

The hash function 606 corresponds to the hash function 308 (of FIG. 3) and the hash function 406 (of FIG. 4). The hash function 606 is a cryptographic hash function and hence, manifests the features of collision resistance, pre-image resistance and second pre-image resistance. Typically, a cryptographic hash function combines the message passing capability of a hash function with security properties. Therefore, the hash function 606 (or the cryptographic hash function) is used in message authentication codes (MAC), digital signatures, information security analysis and the like.

The online computation 602 of the HMAC value corresponds to the online computation 502 (of FIG. 5). The online computation 602 of the HMAC value is performed in three steps. Each step is represented by a dashed box, such as a first step is represented by a first dashed box 608, a second step is represented by a second dashed box 610 and a third step is represented by a third dashed box 612. In the first step, the first party 204 is configured to provide the output 310 (or the first preliminary hash code, Fl) to the hash function 606 in the first dashed box 608. The output 310 (or the first preliminary hash code, Fl) is generated cooperatively by the three parties 203 using their respective random key shares and the input padding 304 (iPad) that is provided by the first party 204. The generation of the output 310 (or the first preliminary hash code, Fl) is described earlier, for example, in FIG. 3. In addition to the output 310 (or the first preliminary hash code, Fl), another input to the hash function 606 is the first block 604A (also represented as ml) of the message (M). Thereafter, the first party 204 is further configured to compute the first hash code 504 (tl) by means of the hash function 606 based on the first block 604A (ml) of the message (M) and the output 310 (or the first preliminary hash code, Fl). The first hash code 504 (tl) is provided as an input to the second step for further computation. In the second step, the second party 206 is configured to compute the second hash code 506 (t2) by means of the hash function 606 based on rest blocks of the message (M), such as the second block 604B (also represented as m2) of the message (M) up to the ith block 6041 (also represented as mi) of the message (M), and the first hash code 504 (tl). In the second step, the second party 206 is configured to iteratively compute the hash function 606 using a next block of the message (M) and an output of a previous iteration as an input to a next iteration. For example, in a first iteration, the second block 604B (m2) of the message (M) and the first hash code 504 (tl) are used as an input to compute an output which is used as input to a second iteration. Therefore, in the second iteration, a third block of the message and the output of the first iteration are used as an input for further computation and this is repeated up to the ith block 6041 (mi) of the message in order to compute the second hash code 506 (t2). There may be two cases for computation of the second hash code 506 (t2). In a first case, if the message (M) comprises more than one block, then, in such a case, the second party 206 is configured to compute the second hash code 506 (t2), iteratively. In a second case, if the message (M) comprises only one message block, then, in such a case, the second party 206 is configured to set the second hash code 506 (t2) equal to the first hash code 504 (tl). Indeed, the message block length is defined by the hash block length. The second hash code 506 (t2) is used as an input in the third step for computation of the HMAC value for the message. In the third step, the third party 208 is configured to compute the output 508 (i.e., HMAC value) for the message (M) by means of the hash function 606 based on the second hash code 506 (t2) and the output 408 (or the second preliminary hash code, F2). The output 408 (or the second preliminary hash code, F2) is generated cooperatively by the three parties 203 using their respective random key shares and the output padding 404 (oPad) that is provided by the third party 208. The generation of the output 408 (or the second preliminary hash code, F2) is described earlier, for example, in FIG. 4. In this way, the output 508 (i.e., HMAC value) for the message (M) is computed as a result of the HMAC function of the HMAC key (K) and the message (M). During the computation of the HMAC value for the message, the HMAC key (K) is not used in a plain text hence, the HMAC key manifests an enhanced security, confidentiality and integrity as well. It is assumed that an attacker can’t attack and control the three parties 203 simultaneously. However, the attacker can get only tl or t2, where tl = Hash (Fl, ml) and t2 = Hash (m2, . . . , mi). The hash function 606 is the cryptographic hash function which has one-way and collision resistance properties therefore, the attacker can’t extract the plain text of the random key shares without a negligible probability. In a case, if the attacker breaks the confidentiality of the HMAC key (K) then, in such a case, a reduction to break the security of the cryptographic hash function (i.e., the hash function 606) can be build. However, the hash function 606 is a secure cryptographic hash function for probabilistic polynomial time turing (PPT), therefore, the attacker can’t break the confidentiality of the HMAC key (K).

FIG. 7 illustrates a process diagram of online multi-party HMAC computation using Boolean gates, in accordance with an embodiment of the present disclosure. FIG. 7 is described in conjunction with elements from FIGs. 3, 4, 5, and 6. With reference to FIG. 7, there is shown a process diagram 700 that illustrates an online computation 602 of a HMAC function by the three parties 203 (of FIG. 2) using boolean gates. There is further shown a HMAC key 702 and an exclusive or (XOR) gate 704.

The HMAC key 702 is divided into three random key shares, each random key share is stored by the first party 204, the second party 206 and the third party 208. After division, the HMAC key is obtained from the three random key shares using a boolean gate, such as the XOR gate 704, as K = K'I XOR K'2 XOR K'3. The XOR gate 704 operates on binary input(s) and provide binary output(s).

As described in FIG. 6, that the online computation 602 of the HMAC value is performed in three steps. In the first step, the first party 204 is configured to provide the output 310 (or the first preliminary hash code, Fl) to the hash function 606. The output 310 (or the first preliminary hash code, Fl) is generated cooperatively by the three parties 203 using their respective random key shares and the input padding 304 (iPad) that is provided by the first party 204. The three parties 203 cooperatively compute the output 310 (or the first preliminary hash code, Fl) by means of the hash function 308 of the HMAC key 702 that is combined with the input padding 304 (iPad) using the XOR gate 704. Similar to the first step, in the third step, the third party 208 is configured to provide the output 408 (or the second preliminary hash code, F2) to the hash function 606. The output 408 (or the second preliminary hash code, F2) is generated cooperatively by the three parties 203 using their respective random key shares and the output padding 404 (oPad) that is provided by the third party 208. The three parties 203 cooperatively compute the output 408 (or the second preliminary hash code, F2) by means of the hash function 406 of the HMAC key 702 that is combined with the output padding 404 (oPad) using the XOR gate 704. In this way, the online computation 602 of the HMAC function is performed using the boolean gates which provides an enhanced security to the HMAC key 702.

Modifications to embodiments of the present disclosure described in the foregoing are possible without departing from the scope of the present disclosure as defined by the accompanying claims. Expressions such as "including", "comprising", "incorporating", "have", "is" used to describe and claim the present disclosure are intended to be construed in a non-exclusive manner, namely allowing for items, components or elements not explicitly described also to be present. Reference to the singular is also to be construed to relate to the plural. The word "exemplary" is used herein to mean "serving as an example, instance or illustration". Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or to exclude the incorporation of features from other embodiments. The word "optionally" is used herein to mean "is provided in some embodiments and not provided in other embodiments". It is appreciated that certain features of the present disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable combination or as suitable in any other described embodiment of the disclosure.

Claims

1. A method (100) of computing a hash-based message authentication code, HMAC, the method (100) comprising: dividing a HMAC key (702) into three random key shares, each random key share being stored by one of three parties (203), computing an HMAC value for a message by the three parties (203) performing a circuit based multi-party protocol comprising steps of cooperative hash function computation, wherein an input of each party into each step comprises the random key share stored by the party.

2. The method (100) of claim 1, wherein the circuit based multi-party protocol comprises three steps of cooperative hash function computation.

3. The method (100) of claim 2, wherein the first step comprises the three parties (203) cooperatively computing a first preliminary hash code (310) being a result of a hash function (308, 406, 606) of the HMAC key (702) exclusive or, XOR (704), an input padding (304), wherein the input padding (304) is provided by the first party (204) and the first preliminary hash code (310) is stored by the first party (204).

4. The method (100) of claim 3, wherein the second step comprises the three parties (203) cooperatively computing a second preliminary hash code (408) being a result of the hash function (308, 406, 606) of the HMAC key (702), XOR (704) an output padding (404), wherein the output padding (404) is provided by the third party (208) and the second preliminary hash code (408) is stored by the third party (208).

5. The method (100) of claim 3 or 4, wherein the hash function (308, 406, 606) includes the Secure Hash Algorithm Version 2, SHA-2, and the Secure Hash Algorithm Version 3, SHA- 3, functions, and the hash function (308, 406, 606) is computed by means of circuits including a garbled circuit, GC (306 A), and a secret sharing based circuit (306B).

24

6. The method (100) of claim 4 or 5, wherein the third step comprises the three parties (203) cooperatively computing the HMAC value being a result of an HMAC function of the HMAC key (702) and the message.

7. The method (100) of claim 6, wherein the third step comprises: the first party (204) computing a first hash code (504) by means of the hash function (308, 406, 606) based on a first block (604A) of the message and the first preliminary hash code (310), the second party (206) computing a second hash code (506) by means of the hash function (308, 406, 606) based on the rest blocks of the message and the first hash code (504), and the third party (208) computing the HMAC value by means of the hash function (308, 406, 606) based on the second hash code (506) and the second preliminary hash code (408).

8. The method (100) of claim 7, wherein the second party (206) computing the second hash code (506) comprises: the second party (206) iteratively computing the hash function (308, 406, 606) using a next block of the message and an output of a previous iteration as an input of each iteration, wherein a second block (604B) of the message and the first hash code (504) are used as an input of the first iteration, if the message comprises more than one block, and the second party (206) setting the second hash code (506) equal to the first hash code (504), if the message comprises one block, wherein a message block length is defined by a hash block length.

9. A system (202) for computing a hash-based message authentication code, HMAC, the system (202) comprising three parties (203), each party storing a random key share of a HMAC key (702), wherein the three parties (203) are configured for computing a HMAC value for a message by performing a circuit based multi-party protocol comprising steps of cooperative hash function computation, wherein an input of each party into each step comprises the random key share stored by the party.

10. The system (202) of claim 9, wherein the parties (203) are configured for implementing the method (100) of any one of claims 1 to 8.