Next Article in Journal
A New Method for Erosion Prediction of 90° Elbow Based on Non-Axisymmetric Ultrasonic-Guided Wave and the PSO–LSSVM Algorithm
Previous Article in Journal
An Improved Pig Counting Algorithm Based on YOLOv5 and DeepSORT Model
 
 
Search for Articles:
Title / Keyword
Author / Affiliation / Email
Journal
Article Type
 
 
Advanced Search
 
Section
Special Issue
Volume
Issue
Number
Page
 
Journals
Sensors
Volume 23
Issue 14
10.3390/s23146307
sensors-logo
Submit to this Journal Review for this Journal Propose a Special Issue
► Article Menu

Article Menu

share Share announcement Help format_quote Cite question_answer Discuss in SciProfiles thumb_up
...
Endorse textsms
...
Comment
first_page
settings
Order Article Reprints
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Hash and Physical Unclonable Function (PUF)-Based Mutual Authentication Mechanism

by
Kavita Bhatia
1,
Santosh K. Pandey
2,
Vivek K. Singh
1 and
Deena Nath Gupta
3,*
1
Department of Computer Science, Banaras Hindu University, Varanasi 221005, India
2
Ministry of Electronics and IT, Government of India, New Delhi 110003, India
3
Center for Development of Advanced Computing, Mumbai 400049, India
*
Author to whom correspondence should be addressed.
Sensors 2023, 23(14), 6307; https://doi.org/10.3390/s23146307
Submission received: 4 June 2023 / Revised: 26 June 2023 / Accepted: 1 July 2023 / Published: 11 July 2023
(This article belongs to the Section Sensor Networks)
Browse Figures
Review Reports Versions Notes

Abstract

:
The security of web applications in an enterprise is of paramount importance. To strengthen the security of applications, the identification and mitigation of vulnerabilities through appropriate countermeasures becomes imperative. The Open Web Application Security Project (OWASP) Top 10 API Security Risks, 2023 Edition, indicates the prominent vulnerabilities of API security risks. Broken authentication, however, is placed in second position with level-3 exploitability, level-2 prevalence, level-3 detectability, and level-3 technical impact. To mitigate this vulnerability, many mitigation strategies have been proposed by using the cryptographic primitives wherein two techniques, namely hashing and PUF, are used. Some of the proposals have integrated the concepts of hashing and PUF. However, the unnecessarily lengthy and complex mathematics used in these proposals makes them unsuitable for current API-based application scenarios. Therefore, in this paper, the authors propose a privacy-preserving authentication protocol that incorporates the capability of both mechanisms in an easy and low-complexity manner. In addition to overcoming existing limitations, the proposed protocol is tested to provide more security properties over existing schemes. Analysis of their performance has demonstrated that the proposed solutions are secure, efficient, practical, and effective for API-based web applications in an enterprise environment.

1. Introduction

The ultimate goal of security providers is to make their enterprises free from all types of vulnerabilities. To achieve this goal, security providers are working continuously to identify the current threats to the security systems [1,2]. One such identified threat is unauthorized authentication to the system. In this, unauthorized users can get access to restricted resources of the enterprise. The security flaws identified for this type of attack are termed “Broken Authentication” vulnerabilities, which basically result in weak authentication and authorization. These allow attackers to gain access to sensitive data of the enterprise by circumventing security procedures [3]. Broken authentication vulnerabilities can be exploited in many ways, including injection flaws, cross-site scripting (XSS), authentication problems, and session management problems. In one case of broken authentication, a regular user might get the rights to add new users. This will pose a serious security threat to the system because the authority to add new users must be limited to the administrator only [4,5]. Seeing the current scenario of broken authentication vulnerabilities, it is crucial to implement security measures such as input validation, session management, and authorization controls [6].
Hashing and random nonce values can be used to strengthen the security mechanisms for such systems. Additionally, they must be revisited before their use in current broken authentication vulnerability scenarios. Hashing has now advanced to sponge construction. The sponge-based hash constructions are claimed to be resistant up to second-preimage attacks. Sponge construction is used to create a hash function that maps variable-length input to variable-length output through a fixed-length permutation (or transformation) and padding rules. The function accepts arbitrary binary strings or elements of Z2 as input and returns a binary string or element of (Z2)n based on the value of n entered by the user. In the construction of a sponge, there are three phases: the initialization, absorption, and squeezing phases. It utilizes the states of b = r + c bits in its construction [7].
The bitrate, b, is the sum of the rate, r, and the capacity, c. The input string is padded with a reversible padding rule after being divided into blocks of r bits. A sponge is then constructed in two stages, using a state whose b bits have been set to zero. It is first necessary to XOR the input blocks’ r bits into the initial r bits of the state, with f applications interspersed between them during the absorption phase. Following the processing of each input block, the sponge architecture enters the squeezing phase. In the second step, the first r bits of the state are output blocks that are separated by the function, f, during the squeezing phase. There is no restriction on how many chunks of output should be generated. When the squeezing is performed, the final c bits of the state are not emitted and are not directly affected by the input blocks [8].
In addition to hashing, PUFs are also becoming increasingly popular as a security primitive for communicating devices. This is a function that produces its output on the basis of a random nonce and the hardware details of the device. A PUF is produced during the manufacturing process of an integrated circuit (IC); its uniqueness is a result of arbitrary physical verification of the IC microstructure [9]. The PUF is basically an integrated circuit (IC) that provides a one-way function that cannot be duplicated, due to its internal structure. It is easy to make the PUFs with a few gates; they are difficult to predict, but again it is easy to evaluate their outputs. These characteristics make them suitable for use as security primitives for communication devices. The intrinsic random physical nature of PUFs and their uncontrollability, as well as their inherent random behavior (the challenge–response pair or CRP), makes it hard to predict and replicate their behavior [10,11].
In global manufacturing chains, PUF can be used to track, identify, and authenticate hardware with low overhead. It has been more than a decade since the first PUF was introduced [12]. The silicon PUF has been implemented in many ways since then, including the Arbiter PUF [10], Ring Oscillator (RO) PUF [13], static random access memory (SRAM) PUF [14], and many others. A silicon PUF designer must address two of the most challenging design tasks a PUF designer will encounter, based on the fact that all current silicon PUF implementations use parametric manufacturing variations: What are the best ways to make the PUF extremely stable and unique, even when exposed to extreme conditions, without high implementation costs? Given the uniqueness and stability measurements of a PUF, how can security be evaluated?
Although many works have already been proposed using these mechanisms, utilizing both simultaneously for API-based web applications has not been seen anywhere. In the presented paper, the authors propose a novel concept of mutual authentication. The simplest form of mutual authentication involves handshakes and information exchange between sender and receiver. Through this process, both entities are confirmed to be trustworthy and to be who they claim to be. As a result of mutual authentication, there is less risk that a network user might inadvertently reveal sensitive information to a malicious or insecure website. Considering the zero-trust approach towards transmission security, the authors in this paper propose a shield handshake between the client and the server by hashing the credentials.

2. Related Work

In recent years, many interesting anonymous authentication schemes have been proposed that preserve privacy. They can be divided into three categories: (1) public key cryptosystems (PKC), (2) error correction systems (EC), and (3) symmetric key cryptosystems. In most PKC-based schemes [15,16,17,18,19,20], the cryptosystems are elliptic curves, which have an extremely high hardware cost, making them unfeasible to implement for most clients. The error rate of EC-based schemes [21,22,23,24,25] has to be below a certain threshold value in order for them to prove secure. Moreover, these schemes are not scalable, as they are only capable of supporting a limited number of clients. In general, NPKC schemes fall into two categories: schemes based on hashes [26,27,28,29] and schemes based on PUFs [30,31,32,33,34,35]. Any physical or cloning attacks cannot be prevented using hash-based schemes. This has led to the growing popularity of PUF-based schemes. Mutual authentication systems have been implemented using PUFs in a number of studies.
A tree-based authentication scheme using PUFs was proposed by Bringer et al. in 2008 [30]. This protocol, however, does not provide protection against DoS attacks and impersonation attacks [31]. Subsequently, Sadeghi et al. [31] proposed an additional PUF-based scheme, but Kardas et al. discovered that it is vulnerable to cold boot attacks [33]. Once the scheme has been compromised, an attacker will be able to impersonate it easily and even trace its past and future communications. Another tree-based authentication protocol based on PUFs was presented by Akgun and Caglayan [32]. Their protocol, however, is also susceptible to the cold boot attack presented in [33], which means that they are unable to guarantee the desired security properties. A new PUF-based authentication protocol was also proposed by Kardas et al. [34] in 2012, but the scheme cannot guarantee forward secrecy and is not resilient to DDoS attacks. The authorization scheme proposed by Jung et al. uses PUF for HMAC-based authentication, yet it is also susceptible to DoS attacks.
An additional PUF-based authentication scheme for communicating systems was recently proposed by Akgun and Caglayan [35]. Investigation of the scheme, however, revealed that forward secrecy is not supported, which is a necessary security requirement for communicating systems. Additionally, the authors found that some PUF-based schemes were impractical, which resulted in servers performing exhaustive searches in order to identify clients, negatively affecting performance. A hash function is used, for example, to encode the identity of the client in [35]. As a result, the backend server would need to try all possible combinations of secrets to determine the client. Other PUF-based authentication schemes also exhibit a similar scenario. The secret keys must also be stored in the client’s memory in all the existing schemes. Once the client is compromised, aside from the storage costs, the attacker has access to those secrets and can perform several attacks.
Assertions of noise-resilient or ideal PUFs have been used in all the aforementioned schemes [36,37]. For this proposal, as well, the authors are assuming that the PUFs are ideal and noise-resilient. In this paper, the authors propose an improved mutual authentication mechanism based on hashing and PUF. Similar work has already been published by Bendavid et al. [38], Xu et al. [39], and Kulseng et al. [40]. However, Bendavid and Xu’s works are largely based on the proposal made by Kulseng. So, the authors in this paper studied the mechanism proposed by Kulseng and identified some of the gaps that could be used by an attacker to get access to the system. A detailed analysis of Kulseng’s proposal is explained in the next section.

3. Kulseng’s Mutual Authentication Protocol

Lars Skaar Kulseng proposed a lightweight mutual authentication, an owner transfer, and a secure search protocol in 2009 [40]. The mechanism starts with the sending of a search request from the server to the client. The client will respond with its IDS (index of the client in the database (DB)). The server will find the ID of the client from its DB with the help of the IDS sent by the client. The server then computes the ID⊕Gn and sends it to the client. The client, by using its ID, can find the Gn of the server by calculating ID⊕Gn⊕ID. On the basis of this Gn, the client calculates four variables, namely, Gn+1, Gn+2, Kn, and Kn+1. The client sends two different values to the server, namely (Kn⊕Gn+1) and (Kn+1⊕Gn+2). The values of Gn+1 and Gn+2 will be calculated on the basis of the PUF, whereas Kn and Kn+1 will be calculated on the simple function, F. Also, the client updates its IDS by the following operation: IDS = F(IDS⊕Gn), and the value of Gn+1 will be stored in place of Gn. The server will do a cross-check of the values. After a successful match, it will update the values by the following operations: Gn+1 = (Kn⊕Gn+1)⊕F(Gn), Gn+2 = (Kn+1⊕Gn+2)⊕F(F(Gn)), and IDS = F(IDS⊕Gn). The value of Gn+1 will be stored in place of Gn, and the value of Gn+2 will be stored in place of Gn+1. The server can only use the simple function, F, for all its operations because the PUF is associated with the client only.
The above-mentioned procedure provides three things: client verification, server verification, and mutual authentication between the client and the server. Also, the calculated values of different functions, namely IDS, Gn+1, and Gn+2, are in line for both the client and the server to be used in the next communication between the same client and the server. However, in 2018, Xu et al. [39] found some serious security loopholes in the mutual authentication process of Kulseng’s design. The claims raised in [39] are as follows. From the communication channel, the interceptor will steal (ID⊕Gn), (Kn⊕Gn+1), and (Kn+1⊕Gn+2) in the first communication setup and the IDS from the next communication setup. Because the IDS used in subsequent communication is calculated by IDS = F(IDS⊕Gn), Xu et al. claim that the Gn of the server can be found by just XORing the new IDS with the F(IDS⊕Gn). However, this seems not to be true. Two questions arise from here. First, when the update process of the IDS is happening inside the client and server individually, then how can an intruder get it? Second, when the new IDS is a function of (IDS⊕Gn), and not just (IDS⊕Gn), then how can an intruder find the value of Gn by just XORing it with the old IDS? Also, the authors in [39] claim that the seeds of an LFSR can be predicted by using the polynomial used and the last output value generated by this LFSR. If this really happens, then the optimal proposal of security may advocate the use of NLFSR in place of LFSR.
In the second claim, the authors in [39] state that the intruder will receive the information sent by the client, and it will never reach the server. The authors in [39] try to convince the readers that, in this way, the DB will not be updated and the verification of the client will fail the next time. If this happens, the optimal solution should enable a negative acknowledgment in communication between the client and the server. The server must send a negative acknowledgment after a specific amount of time to the client about its non-receipt of the information. Also, the client should wait for a specific amount of time for the acknowledgment from the server. The proposed solutions from [39] do not contain any of the above-mentioned techniques; rather, they propose a very complex procedure for client verification, server verification, and mutual authentication between client and server. Their proposed solution not only forfeits the requirement of the devices under a constrained environment but also is subject to mathematical verifications. The authors of [39] also accept the drawback related to storage in their design. The database needs to store nine different values about a single Tag all the time. Also, these values keep changing after every communication. This shows the non-suitability of the proposal made by [39] in current communicating environments.
In the client verification phase, the authors in [39] stated that the client will use r1 and FIDnew for verification, if not intercepted, and r1 and FIDold if intercepted. The obvious question here is: Do the clients know whether they have been intercepted or not? Another security loophole is: Can one not intercept the r1 and FIDnew in between to extract the value of FIDnew or r1 and FIDold to extract the value of FIDold, whichever is applicable? In the mutual verification phase, the calculated value of the client’s r2′ is Pn+1⊕r2⊕D. D is calculated by the client as PUF(Pn). Now, it cannot be proven that PUF(Pn) is equal to Pn+1. Hence, B = B′ also cannot be proven. The process of server verification is suspicious. Again, in the client verification phase, a doubtful calculation is shown. The server is calculating the value of F′ on the basis of the received value of F from the client. This will always produce F′ = F. Hence, it cannot be used in the verification process. This means that H = H′ cannot be proven. Another obvious question arises from this point: when the client has been verified at the very first step, then why does the protocol verify the client again at the later stage? Also, the authors of [39] do not provide the area and power required for their algorithm to run.

4. Proposed Mutual Authentication Mechanism

The proposed mechanism consists of three phases: server verification, client verification, and mutual authentication. The definitions of different symbols used in the proposed protocol are given in Table 1.

4.1. Server Verification

Each client, at the time registration, is provided a hashed identification of their corresponding server. On every new entry to the environment, the server broadcasts a search request. It sends an encrypted message to the client. The client, before responding to that message, runs the server verification code. The client responds to the server only after a successful verification of the server. The protocol for server verification goes as follows:
Algo: Server verification
  • The server performs hashing over its identity H(SID) and attaches the current timestamp, T1, to it. Then, it encrypts all the data with a symmetric key shared with the client at the time of registration.
  • The server then sends the first message to the client: M1 = E[H(SID)||T1].
  • The client then decrypts the whole message, M1, by using the symmetric key given to it at the time of registration. It gets the hashed identification of the server by dropping the timestamp part of the received message.
  • The client compares the received H(SID) with the one it already has.
  • If it is a match, the server is verified; otherwise, it is not verified.

4.2. Client Verification

After the successful server verification, the client performs the XOR operation on its own identification, i.e., CID, with the server’s hashed identification, i.e., H(SID). The client then appends a new timestamp, T2, to the entire message. It then encrypts the whole message with the server’s public key. This encrypted message is then sent to the server. The protocol for client verification goes as follows:
Algo: Client verification
  • The client performs the XOR operation on its own identity, CID, along with the hashed identity of the server, H(SID). It then attaches a new timestamp, T2, to this message. The client encrypts the whole message with the server’s public key, which is broadcast to all the clients on a regular basis.
  • The client then sends a second message to the server: M2 = E[(H(SID)⊕CID)||T2].
  • At the server end, the first check is on the timestamp. It will check if the current timestamp is greater than the one the server sent to the client earlier: T2 > T1.
  • The server then decrypts the whole message by using its private key.
  • It drops the timestamp part of M2 to get the message part. The server then extracts the client identification, CID, from (CID⊕H(SID)) by XORing it with its own hashed identity, H(SID).
  • The server asks the DB about CID. If there is a match, the client is verified; otherwise, it is not verified.

4.3. Mutual Authentication

After the successful verification of the server and the client, a PRNG unit will be activated to generate a secret value, Gn, at the server end. The server then applies a simple function over the generated value to get F(Gn). It again repeats the process to get another value, F(F(Gn)). In a separate computation, the server XORs the client’s identity, CID, with the generated value, Gn, and then attaches a new timestamp, T3, to it. The server encrypts the entire message with the client’s public key. The server then sends the third message, M3: E[(CID⊕Gn)||T3], to the client. At the client end, the first check will be on the timestamp. If the current timestamp will be greater than the old timestamp, (T3 > T2), then only the client will decrypt the whole message using its own private key. It then drops the timestamp part to get the remaining message. By XORing the received message with its own identity, the client will receive the value of Gn.
After receiving the value of Gn, the client will also apply a simple function over it to get the value for F(Gn). The client repeats the process to get another value, F(F(Gn)). The client also updates the value of Gn to Gn+1 by applying a special PUF function to Gn and then to Gn+2 by applying the same PUF function to Gn+1. The client then performs two separate XORs over two different sets of values; in the first set, it performs XOR over Gn+1, Kn, and CID, and, in the second set, it performs XOR over Gn+2, Kn+1, and CID. The client then appends a new timestamp, T4, to both values and encrypts both messages with the server’s public key. The client sends messages M4 and M5 to the server: M4: E[(Gn+1⊕Kn⊕CID)||T4] and M5: E[(Gn+2⊕Kn+1⊕CID)||T4]. The server first checks the value of the received timestamp. If the current timestamp, T4, is greater than the previous timestamp, T3, only then will it proceed further.
The server will decrypt both messages by applying its private key. It drops the timestamp field to get the original message. The server then performs XOR with the customer identification, CID, over the received message, and then performs a second XOR with Kn and Kn+1 separately to get the values of Gn+1 and Gn+2. After successful mutual authentication, both parties update the client identification and generator values for future communication. The client updates its identification by XORing its old identification with the generator value and applying a simple function over it: C′ID: F(CID⊕Gn). The same is done at the server end. Both the client and the server save the updated set of values [Gn+1, Gn+2, and C′ID]. In this set, the value of Gn+1 will act as Gn, and the value of Gn+2 will act as Gn+1 for further communication.
Algo: Mutual authentication
  • The server activates the PRNG unit to generate the value, Gn.
  • The server performs an XOR between CID and Gn, then appends a new timestamp, T3, and encrypts the entire message with the client’s public key.
  • It sends message M3 to the client: M3: E[(CID⊕Gn)||T3].
  • The client first checks the timestamp. If T3 > T2 only then does it decrypt the entire message using its own private key.
  • The client drops the timestamp field to get the original message. It then extracts the value of Gn by performing (CID⊕Gn)⊕CID.
  • The server computes F(Gn) and F(F(Gn)), while the client simultaneously computes Gn+1 = PUF(Gn), Gn+2 = PUF(Gn+1), Kn = F(Gn), and Kn+1 = F(F(Gn)).
  • The client performs the XOR operation between Gn+1 and Kn and CID: Gn+1⊕Kn⊕CID.
  • The client performs a second XOR operation between Gn+2 and Kn+1 and CID: Gn+2⊕Kn+1⊕CID.
  • The client then appends a new timestamp, T4, to both messages.
  • It then encrypts them with the server’s public key: E[(Gn+1⊕Kn⊕CID)||T4], E[(Gn+2⊕Kn+1⊕CID)||T4].
  • The client sends M4 and M5 to the server.
  • The server first checks the new timestamp. If T4 > T3, only then will the server decrypt both messages. It then drops the timestamp part to get the original message. The server extracts the values of Gn+1 and Gn+2 by the following operations: (Gn+1⊕Kn⊕CID)⊕F(Gn⊕CID) and (Gn+2⊕Kn+1⊕CID)⊕F(F(Gn)⊕CID).
  • The client and server simultaneously update the client identification, C′ID, by F(CID⊕Gn).
  • They both store the set of new parameters as: Gn+1, Gn+2, and C′ID.
The time-sequence diagram for the entire mechanism is presented in Figure 1.

5. System Model

A distributed information system, in particular a client-server architecture, has been developed as a result of modern advances in information technology and high-load computing systems. An “information system with client-server architecture” refers to one where functional components interact in a “request–response” manner [41,42]. In such systems, servers usually contain the database and software, while the client components usually include corresponding hardware and software parts, as well as client interfaces. It is most common for data processing to be shared between client and server components. Requests are initiated by the client, and responses are generated by the server. There is an important need for developing models of distributed information systems in stationary conditions and under the influence of external factors that increase the failure rate of component systems [43,44].

6. Security Evaluation of the Proposed Mechanism

Formal and informal evaluations of the security of the proposed mechanism are presented in this section. The discussion focused on an active adversary, who can eavesdrop on any messages transferred over a public channel at different stages of the process, such as during the authentication phase of the protocol, by modifying/blocking messages, or by initiating a session to impersonate a server/client. Nevertheless, the authors specify that the adversary cannot access or influence transmitted messages over a secured channel, such as the registration phase. Random behavior is also assumed for the embedded PUF when different inputs are used.

6.1. Informal Analysis

6.1.1. Traceability Attack

It is necessary for an adversary to link a client’s identity or previous messages transferred to a server to trace a client and compromise the protocol’s anonymity. In the proposed mechanism, the hashed identities (H(SID)) are shared on the communication channel. Hence, it is almost impossible for an adversary to get back the original identity of the client/server if it manages to discover the hashed identity of the client/server. Messages M1 and M2 can be seen for this reference. Additionally, after each run of the protocol, the value of the client identity is updated to C’D. So, it is not possible to trace the identity of a client from its previous communication. Hence, the authors conclude that the proposed mechanism is free from traceability attacks.

6.1.2. Secret Disclosure Attack

In the proposed mechanism, the client is sharing only three messages (M2, M4, and M5) with the server. M2 is an encryption over XOR between H(SID) and CID attached with a timestamp, M4 is an encryption over XOR between Gn+1, Kn, and CID attached with a timestamp, and M5 is an encryption over XOR between Gn+2, Kn+1, and CID. An adversary cannot invert the value of (H(SID)), and, hence, it cannot discover the value of either SID or CID from M2. In the same way, the values of Kn and Kn+1 cannot be extracted from the messages M4 and M5. Hence, the authors conclude that the proposed mechanism is free from a secret disclosure attack.

6.1.3. Impersonation Attack

To impersonate a client on the server without determining CID and SID, the adversary must generate at least a valid M3. For the adversary to produce M3, the knowledge of CID, however, is essential, since the eavesdropped messages cannot be utilized because each new session generates a fresh Gn, making this attack inefficient. Similar arguments apply to client impersonation attacks on the server.

6.1.4. DDoS Attack

It is not possible to apply a DDoS attack against the proposed mechanism, since all messages that are critical to verify the client’s authentication are randomized by Gn. If a cloned client wants to apply a DDoS attack, it must be able to be recognized by the server first. Since the first message sent by the server is protected with a symmetric key known only to the registered clients, no outsider can have the same key to decrypt the message from the server. In case the adversary somehow succeeds in arranging the correct key, it will not be able to recognize the correct timestamp pattern. In case the adversary is able to recognize the correct pattern, it will not have the hashed identity of the server. So, we can say, without having the server’s identification, the cloned client cannot produce a successful denial of service attack.

6.1.5. Desynchronization Attack

Since an adversary cannot impersonate the server to the client or the client to the server in order to desynchronize the client and the server, another approach is to block the last message of the current communication. In this case, the updating of the records will only take place at the client end but not at the server end. The desynchronization attack will not have any effect on the proposed mechanism because, in this case, both parties agreed on an old data set to store. If one party is not updated with a new set of data, both will communicate on the old set of data.

6.1.6. Forward/Backward Secrecy

Both NLFSR and PUF are computed on the basis of a generator value, Gn. This generator value is the product of a PRNG [45] working separately. The PRNG produces perfectly random nonce values each time it is called and, hence, cannot be determined by an adversary for the next time, no matter whether it is known for all the previous sessions. Furthermore, the server sends M3 to the client, where M3 is an XOR of the client’s ID and PRNG output. Since the PRNG output changes every time, it is impossible for an adversary to break the message, M3, from the server to the client. Similarly, messages M4 and M5 are also unbreakable.

6.2. Formal Analysis

An open-source tool called Scyther has become widely accepted for evaluating protocol security. Using it, users can analyze complex attack scenarios on the target protocol using a graphical user interface. With Scyther, the authors verified whether their assertions about security held for the protocol. As part of the Scyther process, the authors defined two identities, namely, the client and the server. The implementation details are presented in Appendix A, where we describe each role and its corresponding task. The authors also fixed the number of protocol runs to 100, the search pruning to “Find all attacks”, and the matching type of the Scyther tool to “Find all type flaws”. All the messages sent and received were covered by the proposed secret claims. The authors established that the security allegations are well-founded in Table 2, showing that the Scyther tool was unable to find any attacks within bounds. Additionally, we compared the improved protocol with some other protocols in Table 3 to determine its security level. The results show that the proposed protocol is secure and resistant to advanced attacks, addressing the security problems of other protocols.

7. Complexity Analysis

In the client verification phase, a timestamp is generated in the client recognition phase, so the time complexity of the client is Tc. The time complexity of an XOR operation is TXOR, and the time complexity for the encryption is TENC. In the process of authenticating the server in the mutual verification phase, there are four operations by a client, namely decryption, drop, XOR, and comparison. So, in the process of authenticating the server in the mutual verification phase, the time complexity of the client is (Tc + TENC + TXOR). In the process of authenticating the client in the mutual verification phase, there are three operations by a server, namely comparison, decrypt, drop, and XOR. So, in the process of authenticating the client in the mutual verification phase, the time complexity of the server is (TENC + TXOR). In the whole mutual verification phase, the time complexity of the tag is (Tc + 5TENC + 7TXOR). In the update phase, there is one operation by a client; the time complexity of the tag is (TXOR) in the update phase. Table 4 presents the time complexity of the proposed protocol.
The authors also performed their analysis on the space complexity. The client needs to store the hashed identity of the server and the client’s own identity. Thus, the space complexity of the client is 2 L. The case for the server side is similar. So, the space complexity of the reader is also 2 L. The comparison results are shown in Table 5.
The results obtained from both analyses show the suitability of our proposal in the current computing environment.

8. Conclusions and Future Work

A novel mechanism for mutual authentication based on hashing and PUF is proposed. It has been seen that previously proposed mechanisms have several security issues. The proposed mechanism utilizes the concept of PUF to protect the client from many physical attacks. PUFs are very strong mathematical computations based on a device’s manufacturing details and hence are impossible to break. Server verification, client verification, and mutual authentication processes are made more secure to make the mechanism resistant to impersonation, traceability, disclosure, desynchronization, and forward/backward secrecy. The proposed mechanism was also analyzed on the Scyther tool, where no attack within bounds was detected. The authors checked the status for all the secret IDs, random nonce values, and other functions used. All the statuses received from the Scyther tool were satisfactory. Hence, the authors can conclude that the proposed mechanism is more robust and secure than other available authentication mechanisms for a client-server scenario.
Modern application architecture relies heavily on APIs in today’s computing environment. Since API (security) was first incorporated into web-based applications, a great deal has changed. It is clear that API traffic has increased rapidly, some API protocols have gained traction, many new API security vendors and solutions have appeared, and, of course, attackers are developing new techniques and skills to compromise APIs. The need for authentication will remain the same between communicating parties, as previously, in order to make them mutually verified. Since integration among services requires low-complexity algorithms, the field of lightweight security design will remain an open topic for the research community. The authors will further try to reduce the computations inside the communicating parties to keep the security of the communicating devices intact. The challenge–response process of the implied PUF will further be reduced to gain another level of lightweight security system design.

Author Contributions

Conceptualization, K.B., S.K.P., V.K.S. and D.N.G.; methodology, K.B. and D.N.G.; validation, S.K.P. and V.K.S.; formal analysis, S.K.P.; investigation, V.K.S.; resources, S.K.P. and V.K.S.; data curation, K.B.; writing—original draft preparation, K.B. and D.N.G.; writing—review and editing, S.K.P. and V.K.S.; visualization, K.B. and D.N.G.; supervision, S.K.P. and V.K.S. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

No new data were created or analyzed in this study. Data sharing is not applicable to this article.

Conflicts of Interest

The authors declare no conflict of interest.

Appendix A

Implementation of the Proposed Protocol in the Scyther Tool:
  • hashfunction h;
  • const xor:Function;
  • const con:Function;
  • const puf:Function;
  • const enc:Function;
  • secret ID;
  • secret CID;
  • secret SID;
  • macro M1 = E[h(SID)||T1];
  • macro M2 = E[(h(SID) xor CID)||T2];
  • macro M3 = E[(CID xor Gn)||T3];
  • macro M4 = E[(Gn + 1 xor Kn xor CID)||T4];
  • macro M5 = E[(Gn + 2 xor Kn + 1 xor CID)T4];
  •  
  • protocol improved(C,S){
  •     role S{
  •        secret Gn;
  •        secret CID;
  •        secret SID;
  •        secret ID;
  •        fresh Ti;
  •        send_1(M1: E[H(SID)||T1]);
  •        recv_2(M2: E[(H(SID) ⊕ CID)||T2]);
  •        send_3(M3: E[(CID ⊕ Gn)||T3]);
  •        recv_4(M4: E[(Gn + 1 ⊕ Kn ⊕ CID)||T4]);
  •        recv_5(M5: E[(Gn + 2 ⊕ Kn + 1 ⊕ CID)||T4]);
  •        claim(S,Secret,ID);
  •        claim(S,Tiagree);
  •        claim(S,Gnsynch);
  •        claim(S,Alive);
  •        claim(S,Weakagree);
  •     }
  •     role C{
  •        fresh Ti;
  •        secret Gn;
  •        secret CID;
  •        secret SID;
  •        secret ID;
  •        recv_1(M1: E[H(SID)||T1]);
  •        send_2(M2: E[(H(SID) ⊕ CID)||T2]);
  •        recv_3(M3: E[(CID ⊕ Gn)||T3]);
  •        send_4(M4: E[(Gn + 1 ⊕ Kn ⊕ CID)||T4]);
  •        send_5(M5: E[(Gn + 2 ⊕ Kn + 1 ⊕ CID)||T4]);
  •        claim(C,Secret,SID);
  •        claim(C,Tiagree);
  •        claim(C,Gnsynch);
  •        claim(C,Alive);
  •        claim(C,Weakagree);
  •     }
  • }

References

  1. Shao, X.; Guo, Y.; Guo, Y. A PUF-based anonymous authentication protocol for wireless medical sensor networks. Wirel. Netw. 2022, 28, 3753–3770. [Google Scholar] [CrossRef]
  2. Zerrouki, F.; Ouchani, S.; Bouarfa, H. PUF-based mutual authentication and session key establishment protocol for IoT devices. J. Ambient Intell. Humaniz. Comput. 2022, 1–19. [Google Scholar] [CrossRef]
  3. OWASP Top 10 API Security Risks—2023. Available online: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ (accessed on 18 June 2023).
  4. Abdolinezhad, S.; Sikora, A. A Lightweight Mutual Authentication Protocol Based on Physical Unclonable Functions. In Proceedings of the 2022 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), McLean, VA, USA, 27–30 June 2022; pp. 161–164. [Google Scholar]
  5. Li, T.; Liu, Y.; Ning, J. SDRLAP: A secure lightweight RFID mutual authentication protocol based on PUF with strong desynchronization resistance. Peer-to-Peer Netw. Appl. 2023, 1–16. [Google Scholar] [CrossRef]
  6. API2:2023 Broken Authentication. Available online: https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/ (accessed on 18 June 2023).
  7. Bertoni, G.; Daemen, J.; Peeters, M.; Van Assche, G. On the indifferentiability of the sponge construction. In Proceedings of the Advances in Cryptology–EUROCRYPT 2008: 27th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Istanbul, Turkey, 13–17 April 2008. [Google Scholar]
  8. Gupta, D.N.; Kumar, R. DeeR-Hash: A lightweight hash construction for Industry 4.0/IoT. J. Sci. Ind. Res. 2023, 82, 142–150. [Google Scholar]
  9. Ravikanth, P.S. Physical One-Way Functions. Ph.D. Thesis, Department Media Arts Sciences, Massachusetts Institute Technology, Cambridge, MA, USA, 2001. [Google Scholar]
  10. Suh, G.E.; Devadas, S. Physical unclonable functions for device authentication and secret key generation. In Proceedings of the 44th Annual Design Automation Conference (DAC), San Diego, CA, USA, 4–8 June 2007; pp. 9–14. [Google Scholar]
  11. Maes, R.; Verbauwhede, I. Physically unclonable functions: A study on the state of the art and future research directions. In Towards Hardware-Intrinsic Security; Springer: Berlin/Heidelberg, Germany, 2010. [Google Scholar]
  12. Gassend, B.; Clarke, D.; Van Dijk, M.; Devadas, S. Silicon physical random functions. In Proceedings of the 9th ACM Conference on Computer and Communications Security (CCS), Washington, DC, USA, 18–22 November 2002; pp. 148–160. [Google Scholar]
  13. Yin, C.-E.; Qu, G.; Zhou, Q. Design and implementation of a group based RO PUF. In Proceedings of the 2013 Design, Automation & Test in Europe Conference & Exhibition (DATE), Grenoble, France, 18–22 March 2013; pp. 416–421. [Google Scholar]
  14. Holcomb, D.E.; Burleson, W.P.; Fu, K. Power-up SRAM state as an identifying fingerprint and source of true random numbers. IEEE Trans. Comput. 2009, 58, 1198–1210. [Google Scholar] [CrossRef]
  15. Hein, D.; Wolkerstorfer, J.; Felber, N. ECC is ready for RFID—A proof in silicon. In Selected Areas in Cryptography (Lecture Notes in Computer Science); Springer: Berlin/Heidelberg, Germany, 2009; Volume 5381, pp. 401–413. [Google Scholar]
  16. Hutter, M.; Feldhofer, M.; Plos, T. An ECDSA processor for RFID authentication. In Radio Frequency Identification: Security and Privacy Issues (Lecture Notes in Computer Science); Springer: Berlin/Heidelberg, Germany, 2010; Volume 6370, pp. 189–202. [Google Scholar]
  17. Avoine, G.; Bingol, M.A.; Carpent, X.; Yalcin, S.B.O. Privacyfriendly authentication in RFID systems: On sublinear protocols based on symmetric-key cryptography. IEEE Trans. Mob. Comput. 2013, 12, 2037–2049. [Google Scholar] [CrossRef]
  18. Kinoshita, S.; Ohkubo, M.; Hoshino, F.; Morohashi, G.; Shionoiri, O.; Kanai, A. Privacy enhanced active RFID tag. In Proceedings of the Workshop Exploiting Context Histories Smart Environments, Munich, Germany, 11 May 2005; pp. 43–52. [Google Scholar]
  19. Ng, C.; Susilo, W.; Mu, Y.; Safavi-Naini, R. New privacy results on synchronized RFID authentication protocols against tag tracing. In Computer Security—ESORICS (Lecture Notes in Computer Science); Springer: Berlin/Heidelberg, Germany, 2009; Volume 5789, pp. 321–336. [Google Scholar]
  20. Lee, C.-I.; Chien, H.-Y. An elliptic curve cryptography-based RFID authentication securing e-health system. Int. J. Distrib. Sens. Netw. 2015, 11, 642425. [Google Scholar] [CrossRef] [Green Version]
  21. Liao, Y.-P.; Hsiao, C. A secure ECC-based RFID authentication scheme integrated with ID-verifier transfer protocol. Ad Hoc Netw. 2014, 18, 133–146. [Google Scholar] [CrossRef]
  22. Chien, H.-Y. De-synchronization attack on quadratic residues-based RFID ownership transfer. In Proceedings of the 2015 10th Asia Joint Conference on Information Security, Kaohsiung, Taiwan, 24–26 May 2015; pp. 42–47. [Google Scholar]
  23. Chien, H.-Y. Combining Rabin crypto-system and error correction codes to facilitate anonymous authentication with un-traceability for low-end devices. Comput. Netw. 2013, 57, 2705–2717. [Google Scholar] [CrossRef]
  24. Chen, Y.; Chou, J.S.; Sun, H.M. A novel mutual authentication scheme based on quadratic residues for RFID systems. Comput. Netw. 2008, 52, 2373–2380. [Google Scholar] [CrossRef]
  25. Doss, R.; Zhou, W.; Sundaresan, S.; Yu, S.; Gao, L. A minimum disclosure approach to authentication and privacy in RFID systems. Comput. Netw. 2012, 56, 3401–3416. [Google Scholar] [CrossRef]
  26. Tan, C.C.; Sheng, B.; Li, Q. Secure and server-less RFID authentication and search protocols. IEEE Trans. Wirel. Commun. 2008, 7, 1400–1407. [Google Scholar] [CrossRef] [Green Version]
  27. Yang, J.; Park, J.; Lee, H.; Ren, K.; Kim, K. Mutual authentication protocol for low-cost RFID. In Proceedings of the Workshop RFID Lightweight Cryptograp, Graz, Austria, 14–15 July 2005; pp. 17–24. [Google Scholar]
  28. Luo, Z.; Chan, T.; Li, J.S. A lightweight mutual authentication protocol for RFID networks. In Proceedings of the IEEE International Conference on e-Business Engineering (ICEBE’05), Beijing, China, 12–18 October 2005; pp. 620–625. [Google Scholar]
  29. Gope, P.; Hwang, T. A realistic lightweight authentication protocol preserving strong anonymity for securing RFID system. Comput. Secur. 2015, 55, 271–280. [Google Scholar] [CrossRef]
  30. Bringer, J.; Chabanne, H.; Icart, T. Improved privacy of the treebased hash protocols using physically unclonable function. In Proceedings of the 6th International Conference on Security and Cryptology for Networks (SCN), Amalfi, Italy, 10–12 September 2008; pp. 77–91. [Google Scholar]
  31. Sadeghi, A.-R.; Visconti, I.; Wachsmann, C. PUF-enhanced offline RFID security and privacy. In Proceedings of the Secure Component Systems Identification, Cologne, Germany, 15–16 June 2010; pp. 102–106. [Google Scholar]
  32. Akgun, M.; Caglayan, M.U. Puf based scalable private RFID authentication. In Proceedings of the 2011 Sixth International Conference on Availability, Reliability and Security, Vienna, Austria, 22–26 August 2011; pp. 473–478. [Google Scholar]
  33. Kardas, S.; Kiraz, M.S.; Bing, M.A.; Demirci, H. A novel RFID distance bounding protocol based on physically unclonable functions. In RFID. Security and Privacy, Proceedings of the 7th International Workshop, RFIDSec 2011, Amherst, MA, USA, 26–28 June 2011; Springer: Berlin/Heidelberg, Germany, 2012; pp. 78–93. [Google Scholar]
  34. Kardas, S.; Celik, S.; Yildiz, M.; Levi, A. Puf-enhanced offline RFID security and privacy. J. Netw. Comput. Appl. 2012, 35, 2059–2067. [Google Scholar] [CrossRef]
  35. Akgun, M.; Caglayan, M.U. Providing destructive privacy and scalability in RFID systems using PUFs. Ad. Hoc. Netw. 2015, 32, 32–42. [Google Scholar] [CrossRef]
  36. Bohm, C.; Hofer, M. Physical Unclonable Functions in Theory and Practice; Springer: New York, NY, USA, 2012. [Google Scholar]
  37. Pandey, S.; Deyati, S.; Singh, A.; Chatterjee, A. Noise-resilient SRAM physically unclonable function design for security. In Proceedings of the 2016 IEEE 25th Asian Test Symposium (ATS), Hiroshima, Japan, 21–24 November 2016; pp. 55–60. [Google Scholar]
  38. Bendavid, Y.; Bagheri, N.; Safkhani, M.; Rostampour, S. IoT Device Security: Challenging “A Lightweight RFID Mutual Authentication Protocol Based on Physical Unclonable Function”. Sensors 2018, 18, 4444. [Google Scholar] [CrossRef] [Green Version]
  39. Xu, H.; Ding, J.; Li, P.; Zhu, F.; Wang, R. A Lightweight RFID Mutual Authentication Protocol Based on Physical Unclonable Function. Sensors 2018, 18, 760. [Google Scholar] [CrossRef] [PubMed] [Green Version]
  40. Kulseng, L.; Yu, Z.; Wei, Y.; Guan, Y. Lightweight Mutual Authentication and Ownership Transfer for RFID Systems. In Proceedings of the IEEE Infocom, San Diego, CA, USA, 14–19 March 2010; pp. 1–5. [Google Scholar]
  41. Cavusoglu, H.; Raghunathan, S.; Mishra, B. Optimal Design of Information Technology Security Architecture. In Proceedings of the International Conference on Information Systems, Barcelona, Spain, 15–18 December 2002; Volume 74. [Google Scholar]
  42. Bhattacharya, B.; Lu, Q.; Zhong, J. Reliability of redundant ductile structures with uncertain system failure criteria. Sadhana 2009, 34, 903–921. [Google Scholar] [CrossRef] [Green Version]
  43. Tyurin, S.F.; Grekov, A.V. Functionally Complete Tolerant Elements. Int. J. Appl. Eng. Res. 2015, 10, 34433–34442. [Google Scholar]
  44. Potapov, V.I.; Shafeeva, O.P.; Doroshenko, M.S.; Chervenchuk, I.V.; Gritsay, A.S. Numerically-analytical solution of problem gaming confrontation hardware-redundant dynamic system with the enemy operating in conditions of incomplete information about the behavior of participants in the game. J. Phys. Conf. Ser. 2018, 1050, 012062. [Google Scholar] [CrossRef] [Green Version]
  45. Gupta, D.N.; Kumar, R. DeeR-Gen: A pseudo random number generator for industry 4.0/IoT. J. Sci. Ind. Res. 2023, 82, 316–321. [Google Scholar]
  46. Aysu, A.; Gulcan, E.; Moriyama, D.; Schaumont, P.; Yung, M. End-to-end design of a PUF-based privacy preserving authentication protocol. In International Workshop on Cryptographic Hardware and Embedded Systems; Springer: Berlin/Heidelberg, Germany, 2015; pp. 556–576. [Google Scholar]
  47. Van Herrewege, A.; Katzenbeisser, S.; Maes, R.; Peeters, R.; Sadeghi, A.R.; Verbauwhede, I.; Wachsmann, C. Reverse fuzzy extractors: Enabling lightweight mutual authentication for PUF-enabled RFIDs. In Proceedings of the International Conference on Financial Cryptography and Data Security, Kralendijk, Bonaire, 27 Februray–2 March 2012; Springer: Berlin/Heidelberg, Germany, 2012; Volume 1, pp. 374–389. [Google Scholar]
Sensors 23 06307 g001a 550Sensors 23 06307 g001b 550
Figure 1. The proposed mutual authentication mechanism.
Figure 1. The proposed mutual authentication mechanism.
Sensors 23 06307 g001aSensors 23 06307 g001b
Table
Table 1. Definitions of the symbols used in the proposed mechanism.
Table 1. Definitions of the symbols used in the proposed mechanism.
SymbolDefinition
CIDIdentification of client
SIDIdentification of server
H(SID)Hashing over identification of server
⊕XOR operation
E Encryption function
T Timestamp
GnGenerator value
PUFPhysical unclonable function
FNonlinear-feedback shift register
Table
Table 2. The proposed protocol verification results using the Scyther tool.
Table 2. The proposed protocol verification results using the Scyther tool.
Claim StatusComments
ImprovedSimproved, S1Secret IDOKNo attacks within bounds.
improved, S2TiagreeOKNo attacks within bounds.
improved, S3GnsynchOKNo attacks within bounds.
improved, S4AliveOKNo attacks within bounds.
improved, S5WeakagreeOKNo attacks within bounds.
Cimproved, C1Secret SIDOKNo attacks within bounds.
improved, C2TiagreeOKNo attacks within bounds.
improved, C3GnsynchOKNo attacks within bounds.
improved, C4AliveOKNo attacks within bounds.
improved, C5WeakagreeOKNo attacks within bounds.
Table
Table 3. The security comparison of the improved protocol to other protocols against advanced attacks.
Table 3. The security comparison of the improved protocol to other protocols against advanced attacks.
ProtocolsImpersonationTraceabilityDisclosureDesynchronizationForward/Backward Secrecy
Sadeghi et al. [31]Non-resistantNon-resistantResistantResistantNon-resistant
Aysu et al. [46]ResistantNon-resistantNon-resistantResistantNon-resistant
Van Herrewege et al. [47]ResistantResistantNon-resistantResistantNon-resistant
Kulseng et al. [40]ResistantResistantNon-resistantNon-resistantNon-resistant
Xu et al. [39]ResistantResistantNon-resistantNon-resistantNon-resistant
Bendavid et al. [38]ResistantResistantResistantResistantNon-resistant
ProposedResistantResistantResistantResistantResistant
Table
Table 4. Result of time–cost analysis of the proposed protocol.
Table 4. Result of time–cost analysis of the proposed protocol.
ProtocolClient VerificationMutual VerificationUpdate
Kulseng [40]-2TP + 3TXOR + 2TFTXOR + TF
Xu et al. [39]Tc2TP + 8TXOR + 6TLEFT + 2TAND + TOR2TXOR + 6TLEFT + 2TAND
ProposedTcTc + 5TENC + 7TXORTXOR
Table
Table 5. Result of space–cost analysis of the proposed protocol.
Table 5. Result of space–cost analysis of the proposed protocol.
ProtocolClientServer
Kulseng [40]3 L4 L
Xu et al. [39]3 L9 L
Proposed2 L2 L
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Bhatia, K.; Pandey, S.K.; Singh, V.K.; Gupta, D.N. Hash and Physical Unclonable Function (PUF)-Based Mutual Authentication Mechanism. Sensors 2023, 23, 6307. https://doi.org/10.3390/s23146307

AMA Style

Bhatia K, Pandey SK, Singh VK, Gupta DN. Hash and Physical Unclonable Function (PUF)-Based Mutual Authentication Mechanism. Sensors. 2023; 23(14):6307. https://doi.org/10.3390/s23146307

Chicago/Turabian Style

Bhatia, Kavita, Santosh K. Pandey, Vivek K. Singh, and Deena Nath Gupta. 2023. "Hash and Physical Unclonable Function (PUF)-Based Mutual Authentication Mechanism" Sensors 23, no. 14: 6307. https://doi.org/10.3390/s23146307

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop