Abstract
We study how to generally construct a PUF-based multifactor authenticated key exchange (MAKE) protocol from any secure password-based authenticated key exchange protocol. We newly consider a new setting in which a user holding a PUF-embedded device desires to perform an authenticate key exchange through multifactor authentication factors (password, biometrics, secret). Our construction is the first PUF-based general MAKE construction. By applying a PUF in a device, our MAKE construction is still secure even if all authentication factors are totally compromised. Our construction is the first PUF-based generic MAKE protocol requiring additional three communication flows without any public key based primitives such as signature.
1. Introduction
To establish a secure communication over public network, a secure exchange of secret key with authentication is an absolute prerequisite. Thus, authenticated key exchange (for short, AKE) has been one of the most important cryptographic primitives. Basically, for practical and secure AKE, a memory requirable long-term secret key, a human memorable password, and human-dependent biometric information have been utilized as authentication factors in the AKE. If the AKE protocol is designed with only one factor (e.g., secret key or password) for authentication, it is considered as a one-factor AKE. Bellare and Rogaway first formalized security notions and definitions for the one-factor AKE based on symmetric secret key [1]. Subsequently, Bellare et al. have established a new security model in case of memorable password [2] (for short, PAKE). In a span of twenty years, these two models not only have been the foundation for subsequent PAKE results achieving augmented provable security with efficiency [3, 4], but also have been bases for the extended model such as group, three-party, and multifactor (secret, password, biometrics) authentication settings [5–9]. In this paper, we aim to design a generic framework to transform any secure PAKE into a secure MAKE with physical unclonable function. Before discussing our motivations, let us briefly summarize relevant results on provably secure AKE and MAKE constructions.
If two authentication factors (secret key and password) are simultaneously used into an AKE protocol, we consider it as a two-factor AKE (for short, TAKE) protocol. With the rapid popularization of smartcard, there have been huge amounts of research on TAKE in a practical scenario where a user memorizes own password and possesses a secret key in each own smartcard [10–16]. In a smartcard setting, it is impossible to list all (or even some specific related works and topics) works here. One main research stream is that many protocols have been found to be flawed and then finally redesigned repeatedly. Furthermore, our paper does focus on not the TAKE, but the MAKE that handles multifactor AKE. However, in the TAKE, there have been good relevant works on generic construction. First, Yang et al. [17] have designed a framework to transform a secure password-based PAKE [18] suggested by Halevi and Krawczyk into the TAKE protocol. The main idea is to combine the HK password-based PAKE with signature-based authenticator, which finally enables achieving a general TAKE scheme. However, it is not general construction since the scheme is only able to transform the HK scheme into two-factor scheme, and is not be able to handle all kinds of secure PAKE for building TAKE. In 2010, Stebila et al. suggested multifactor password-based AKE [19]. It has been designed to allow multiple kinds of passwords. More precisely, this protocol deals with multiple passwords for authentication (note that biometrics is not included at all). Hence it is fair to say that it falls into the TAKE protocol. Besides, the protocol relies on the PKI environment and random oracle model for security proof. In 2014, Huang et al. have presented new types of adversaries with precomputed and different data on the smart card in a TAKE setting [20]. Two TAKE schemes [21, 22] have been analyzed and securely revised under the new adversaries [20]. In 2018, Wang and Wang have syntagmatically and universally defined an explicit and new security model with practical adversaries’ capabilities for a TAKE setting. Also, a new and secure TAKE scheme, satisfying all security criteria, has been suggested. Very recently, Wang et al. have also proposed a new framework for evaluating security, efficiency, and scalability for a TAKE wireless sensor network [23]. Under the framework, two existing schemes [24, 25] have been found to be flawed [23]. Furthermore, 44 TAKE schemes have been universally compared and analyzed. It is one of the systematic comparisons over such vast amounts of research.
A multifactor AKE (for short, MAKE) deals with three types of authentication factors (secret, password, and biometrics). The main advantage of MAKE over TAKE is its ability to preserve the security even if one or two authentication factors are compromised. Despite its merits, relatively, the MAKE has been received less attention in the literature than the TAKE. In 2008, Pointcheval and Zimmer have designed a provably secure MAKE protocol (for short, PZ) under computational Diffie-Hellman assumption [26]. It uses an ElGamal public key encryption [27] for securing biometric information. However, in 2012, it has been found to be insecure by Hao and Clarke [28]. The insecurity of PZ is that an attacker, who steals a password, is able to deduce biometric information. After the PZ, there have been attempts to design a MAKE in smartcard, cloud computing, three-party, and multiserver environments [29–32]. In 2009, Fan et al. have proposed a public key based MAKE in a smartcard setting [29]. It protects users’ biometric data from anyone else including a server while allowing secure authentication. Later, the PZ has been extended into three-party setting by Liu et al. [30]. It has been the first work on addressing the three-party setting that assumes an intervention of trusty party between a client and a server. A new MAKE based on elliptic curve has been suggested in a multiserver setting by He et al. in 2015 [31]. Very recently, Wei et al. have presented a privacy-preserving multifactor authenticated key exchange for cloud computing [32]. It has achieved better efficiency than the PZ in terms of computation and bandwidth costs.
1.1. Related Works
Our goal is to construct a secure generic PUF-based MAKE protocol from any secure PAKE protocol. To the best of our knowledge, a PUF-based MAKE protocol has not been proposed yet in the literature. However, regarding generic MAKE constructions, which are not based on PUF, there have been few results in recent years. First, in 2011, Huang et al. have designed a generic transformation that combines any secure PAKE in the smartcard setting with biometrics for building a MAKE [33]. Their main idea is to execute a TAKE twice. They use a fuzzy extractor to handle user’s biometrics. Later, it has been enhanced by Yu et al. in 2014 [34]. Its enhanced version applied a fuzzy vault based on euclidian distance for handling biometric features. And also, it used a TAKE just once. Despite its efficiency and novelty, these two constructions have been built under a PKI setting where participants must be allowed to sign (verify) and encrypt (decrypt) based on public key cryptography. Moreover, one critical problem is that these two constructions [33, 34] have not been built in a generic way. For example, in [34], they first make and apply into a TAKE where is a password, is a biometric information, and is a cryptographic secure hash function. Depending on what kind of TAKE is being used, an input of is not always an input for TAKE. For instance, if TAKE uses a structure (or ) inside, then, before application, should be customized as where is a function that converts an input to a cyclic group element output (or fixed length output, e.g., 128 bits, 256 bits). In [34], they select a good but specific TAKE [17] and demonstrate how it can be initiated to build a final MAKE. It does not mean that their generic MAKE is able to cover all cases of TAKE. One important observation from this issue is that a generic MAKE should execute a TAKE first and then use its session key for integrating multifactor authenticators rather than executing TAKE with an integration of multifactor authenticators.
Fleischhacker et al. have presented a generic MAKE construction (for short, FMA) by combining subprotocols such as unauthenticated key exchange, password-based authentication (password), public key authentication (secret key), and biometric authentication protocols (biometric) [35]. The main idea is that it uses subprotocols independently for building a general MAKE. This approach guarantees not only better security but also simplicity for implementation. However it does not allow two authentication factors to be used together for one subprotocol; hence it has a limitation to enhance the total communication cost.
1.2. Motivation
In the paper, we firstly attempt to use a physical unclonable function (PUF) for generally building a secure MAKE. The PUF is basically embedded in a device at manufacturing stage. It always produces an unpredictable output depending on device’s physical status, and it cannot be duplicated or cloned over a new device. This unpredictability has been one of the good properties for enhancing security in cryptology. However, if the PUF always outputs different unpredictable result, then its output itself cannot become a secret key. A secret key in cryptology should be not only unpredictable, but also the same value when it is used for a secret key of encryption, decryption, and authentication. For this reason, generally, a fuzzy extractor (FE) has been used with the PUF for making a secure fixed secret from the unpredictable PUF’s outputs. In fact, much research on how the PUF can be securely combined with the existing cryptographic primitives, such as PUF-based authentication, bit commitment, and PUF-based encryption, has been conducted in recent decades. From the short histories of the PAKE, MAKE, and PUF, one question naturally arises; can we design a MAKE protocol by using the existing and well-proved PAKE protocol? More precisely, is it possible to generally construct MAKE if we are given any secure PAKE and hardware dependent PUF? Generally, the MAKE needs a storage device for maintaining a long-term secret. That is why a huge amount of MAKE has been presented in a smartcard setting so far. Besides, the PUF is hardware dependent function and it is well suited for a storage device. Therefore, it is quite natural for a MAKE to assume a PUF-embedded device such as smartcard, DRAM, SRAM. This setting has one important benefit that the previous MAKE inherently has not satisfied. That is, even if three authentication factors (password, secret, biometrics) are all compromised, our MAKE with PUF-based device can be still secure.
1.3. Our Result
In the paper, we first study a topic on how to systematically construct a MAKE protocol with any secure PAKE protocol in a PUF-embedded device setting. In our setting, a user holds a PUF-embedded device and desires to mutually authenticate it with a server by multifactor authenticators. The design difficulties come from how common symmetric secrets are securely established from multiple authenticators. As illustrated in Figure 1, our main idea is to apply user’s strong secrets (a long-term secret, biometrics) into an input of PUF in a device and obtain an output secret . Our PUF in a MAKE actually does not need a password as an input;, instead, our MAKE just needs to execute a secure PAKE first and obtain PAKE’s session key. Finally, PUF’s and PAKE’s session key are hashed (random oracle) in order to produce two symmetric authentication keys. These keys perform a critical role for securely making message authentication codes for Diffie-Hellman values and a final session key of MAKE. Executing a secure PAKE first can avoid the security problem on the password such as off-line or on-line dictionary attacks. For instance, in case of using a long-term secret or biometric based AKE, we should first go through a problem on how a weak secret, password, can be securely combined with a secret or biometrics based AKE, which would be much more harder than the cases of combining the PAKE with a long-term secret and biometrics.
Most of all, our construction is the first PUF-based general MAKE constructions. By applying a PUF in a device, our MAKE construction can be still secure even if all authentication factors (password, secret, biometrics) are totally revealed. Moreover, our construction is relatively efficient in terms of communication cost. That is, our construction needs at most 6 communication flows (one execution of PAKE and three additional communication flows) that no public key based primitives such as signature are using. Unless the underlying PAKE is asymmetric-based setting, our MAKE construction is comprised of only symmetric primitives such as symmetric encryption, MAC function, which are relatively efficient than the works [35], as analyzed in Table 2. While the total communication round is greatly enhanced, our communication cost is not better than the FMA [35]. This slight inefficiency is due to the use of PUF and Diffie-Hellman keying materials. However, enhanced security and the reduced total communication flow balance up these little computation loss.
2. Preliminaries
2.1. Fuzzy Extractor and PUF
Definition 1 (fuzzy extractor[36]). A fuzzy extractor consists of two procedures, Gen, Rep: (1)Gen outputs a string and a helper string , on input , guaranteeing that for any distribution with min-entropy , if Gen, then SD, where the SD means statistical distance.(2)Rep takes on inputs and it outputs Rep if dist and Gen.
Definition 2 ([37, 38]). A physically unclonable function -PUF is a function satisfying the following. (1)A PUF is bound to a device and its evaluation is efficient.(2)For any PPT adversary , PUF’s output is impossible to characterize. Let PUF: be an ideal PUF. An experiment is defined for where is a security parameter. means an experiment in which can access an ideal PUF in polynomial number of times. That is, in this experiment, an oracle returns on input . Otherwise if , in , returns a random as an answer. ’s goal is to finally output a guessing bit for . To be precise, the following puf-advantage, , should be negligible.(3)The distance between two PUF’s outputs on the same challenge is at most ; e.g., the following probability is negligible .(4)The distance between two outputs, from different devices , on the same challenge , is at least ; e.g., the following probability is negligible .
Our PUF is based on an ideal PUF model where a PUF is considered as a random permutation oracle. In the same way as a random oracle, an adversary is adaptively able to query the PUF within polynomial time [37–41], but is never able to tell apart which one is real PUF or simulated PUF. This second property basically follows the definition in [37]. The third property says that the PUF’s output () is always different within a certain distance on the same input . It is one of the good properties as any adversary cannot predict PUF’s outputs, but its uncertainty makes it hard to directly apply itself for making a cryptographic key. Thus, a PUF is usually combined with a fuzzy extractor which consists of Gen and Rep for making and recovering a fixed cryptographic secret . That is, even if any adversary corrupts the input , it cannot predict output or without PUF while only valid user who holds PUF can recover . The last property means that each PUF in different device should have own unique output on the same input. These third and fourth properties follow definitions in [38].
2.2. PRF and DDH
Definition 3 (pseudorandom function family (PRF)). A pseudorandom function family is a collection of functions indexed by a key , where is the set of keys of and is the set of domains of , such that for any PPT algorithm , it holds the following: (i)Given and , there is a PPT algorithm to compute .(ii)For any PPT algorithm , the following prf-advantage, , is negligible: where is the set of all functions mapping from to and denotes an element chosen randomly.
Definition 4 (decisional Diffie-Hellman assumption (DDH)). The DDH problem is defined as follows: Let be a cyclic group that has a prime order and a generator . The advantage of iswhere is PPT adversary with time complexity . The DDH assumption is that the advantage of is negligible.
2.3. Secure MAC and Secure Symmetric Encryption under CCA
Definition 5 (secure message authentication code under chosen message attack). A message authentication code is a pair of algorithms MAC = (, ). We define a MAC key set = where is the size of MAC key. An algorithm is a MAC generation algorithm which takes as inputs a MAC key and message and outputs a string called a tag. An algorithm is a MAC verification algorithm which takes key , message , and tag and outputs a bit 1 (authentic) or 0 (unauthentic). Let us consider the following experiment. A notation of indicates that the adversary can access an oracle .
Experiment
MKey
: is a tag value for a new message
If and was never outputted by in response to query , then return 1; else return 0.
We define cma (chosen message attack) advantage of as follows.If cma-advantage of MAC is negligible, the MAC scheme is secure under chosen message attack.
Definition 6 (secure symmetric encryption under chosen cipher attack). Let SE = () be a symmetric encryption scheme and be an adversary of SE. We define a symmetric key set Key = where is the size of encryption key. An algorithm E is a probabilistic symmetric encryption algorithm which takes a symmetric key Key and plaintext and outputs ciphertext . An algorithm is a deterministic decryption algorithm which takes key , plaintext , and as inputs and outputs message . Let us consider the following experiment. A notation of indicates that the adversary can access an oracle .(1)Key(2)(Find Stage) (3), (4)(Guess Stage) (5)If then return else return For any , , , we define cca-advantage of SE asIf cca-advantage of SE is negligible, the SE scheme is secure under chosen ciphertext attack.
3. Security Model for Multifactor Authenticated Key Exchange
Based on the BPR model [2], in this section, a new security model is presented for PUF-based MAKE. We follow the basic framework and its notations of BPR model [2]. As our compiler converts any secure PAKE into secure PUF-based MAKE, two security models (PAKE and MAKE) are required for security proof. Two security models are the same except the number of authentication factors, session freshness.
3.1. Communication Model
Participants, long-lived secrets in the MAKE. Two types of protocol participants, a set of users and a set of servers , are assumed in a MAKE protocol with multiple long-lived secrets. That is, we suppose that each user owns a tuple . U memorizes a secret password and possesses a physical unclonable function, PUF, which is usually embedded into a smartcard or memory card. U holds a long-term secret s. U itself owns biometric template such as iris or fingerprint. securely keeps in its database, where is an identifier and is a transformation of . A user U (or a server S) may execute MAKE protocol multiple times and we also denote the -th instance executed by entity (resp., ) as (resp. ).
Participants, long-lived secret in the PAKE. We assume two types of protocol participants, a user and a server . The set of all participants is the union . We suppose that each user memorizes a secret password and the server S keeps a vector that contains entry for each client. The passwords are called the long-lived key of user U and server S. A user U (or a server S) may execute the 2-party PAKE protocol multiple times. The -th instance is executed by entity (resp., ) as (resp., ).
Queries of Adversary in the MAKE. Queries are defined to model malicious behaviors of an adversary. We assume that there is an adversary that is able to control communications over the networks and interact with the oracles by asking queries defined below.(i) It sends the message to an oracle . This query models that sends a message to an instance of in the real protocol. The oracle will return the next message that an honest should be sent according to the protocol.(ii) If the oracle has a session key, then this query outputs a session key to . This query models the possibility that gets session keys.(iii) This query models the possibility that corrupts a client . We assume that can just obtain long-lived keys, but cannot obtain ephemeral states of instances. This query is classified into three types according to .(a)If a = 1, then the password pw of U is returned as an answer.(b)If a = 2, then the secret PUF of U is returned as an answer.(c)If a = 3, then the secret of U is returned as an answer.(d)If a = 4, then the secret s of U is returned as an answer. In case of PAKE, the cases of are only considered.(iv) This query returns transcripts of an honest execution between user instance and server instance . This query models a passive adversary who simply eavesdrops transcripts on an honest execution.(v) This query is only used to measure’s knowledge on a session key. When asks a Test query to the fresh , a coin is flipped to generate a random bit . If = 1, the real session key is returned to . Otherwise a random value is returned. is allowed to make a Test query only once at any time during the experiment.
Queries of Adversary in the PAKE. All queries and their responses are the same as those of MAKE except a corrupt query with notions. A corrupt query in the PAKE is defined only in case of a=1. A notion on the instance, , is replaced with (). And also, to distinguish notations in the security proof, we define notations of queries for the PAKE without subscript (e.g., Send, Corrupt, Execute, Reveal, Test).
3.2. Security Definition
Definition 7 (session identifier, session key, partner identifier, and partnering 2-party ). We define a session identifier (SID) for as which is the concatenation of all messages sent and received by . A session key is denoted as. A partner ID is a corresponding participant with whom is interacting, which is denoted as. Instances and are partnering if the following conditions are satisfied: (1) Both instances have been accepted with the same session key, session ID, and partner ID. That is, if both oracles have been accepted with,, then. (2) No oracle other than and is accepted with the pid of and . (, ).
Regarding the PAKE, we use essentially the same definitions, notations for SID, a session key, and PID with the ones of MAKE model. Thus we do not define them again here. Next, we consider freshness, forward secure freshness for MAKE and PAKE, respectively.
Definition 8 (freshness for 2-party ). An instance is fresh in terms of multifactor AKE if (1) neither nor its partner has been asked for a Reveal query; (2) neither nor its partner has been asked for a Corrupt(, 1), Corrupt(, 2), Corrupt(, 3), Corrupt(, 4) queries. The second condition means that and its partner have been asked for less than four corrupt queries. That is, can ask Corrupt queries satisfying the following equation.If has asked query of Corrupt() where , then it is Corrupt(a) = TRUE. Otherwise, it is Corrupt(a) = FALSE.
Definition 9 (forward secure freshness for 2-party ). Regarding forward secrecy, a new freshness, fs-fresh, is defined. An instance is fs-fresh in terms of multiple authentication factors if (1) neither nor its partner has been asked for a Reveal query; (2) before Test(), neither nor its partner has been asked for all three Corrupt(, 1), Corrupt(, 2), Corrupt(, 3), Corrupt(, 4) queries and queries.
Remark 10. The above first property (1) is for Reveal case for both PAKE and MAKE. However, the second property (2) has been modified by multiple authentication factors. For example, let us consider some cases of fs-fresh. If asks Corrupt(, 1), Corrupt(, 2) queries (less than all four Corrupt queries) before Test() and does ask query, then it is fs-fresh. Also, if asks Corrupt(, 1), Corrupt(, 2), and Corrupt(, 3) queries before Test() and does not ask query, then it is fs-fresh. If all Corrupt queries have been asked after Test query, then it is also fs-fresh.
Definition 11 (freshness for 2-party ). It is defined in the same way as MAKE except the second condition. That is, the first condition is the same as the MAKE, but the second condition is that neither nor its partner has been asked for a Corrupt(, 1) query.
Definition 12 (forward secure freshness for 2-party ). It is defined in the same way as the above MAKE except the second condition. That is, before Test(), neither nor its partner has been asked for a Corrupt(, 1) query and query.
Definition 13 (session key security for 2-party ). Let us consider the following experiment. We assume that an adversary is run within a polynomial time bound . interacts with a finite number of oracles by asking queries defined above during the experiment. can ask a Test query to a fresh oracle at any time. When asks a Test query to the fresh , then the experiment flips a coin for bit . If it lands = 1, then the real session key is returned to the adversary. Otherwise, a random key is returned to the adversary. Eventually guesses , outputs the guessed bit , and terminates the experiment. The sk advantage of in attacking the MAKE protocol is defined as . It should be negligible as follows.where is a negligible function, is a password space for a Zipf’s parameters , , which follows Zipf’s law for password [42, 43], is the number of on-line Send queries asked, and is a security parameter.
Remark 14. Since a memorable password is chosen by a user, it is not uniformly distributed. That is, due to the memorable property, it is natural for the user not to be able to make full use of the whole distribution of at password selection stage. Thus, regarding the formalization term on an on-line-password guessing attack in all of our definitions here, we follow the Zipf assumption for password distributions [42, 43], which formalizes user own memorable password (not uniform from ), , rather than a uniformly modeled term , where are Zipf’s parameters [42, 43] depending on dataset, policy, language.
Definition 15 (session key security for 2-party ). The definition for PAKE is the same as the MAKE security except that a notion is replaced with a notion . It is defined as and it should be as follows. where is a negligible function, is a password space for a Zipf’s parameters , , which follows Zipf’s law for password [42, 43], is the number of on-line Send queries asked, and is a security parameter.
Definition 16 (forward secure session key security for 2-party ). A forward secure 2-party PAKE protocol is defined with a condition that the fs-fresh instance should be asked for a Test query. Basically its definition is the same as the definition of session key secure PAKE except that a notion is replaced with a notion . It should be as follows: where is a negligible function, is a password space for a Zipf’s parameters , , which follows Zipf’s law for password [42, 43], is the number of on-line Send queries asked, and is a security parameter.
The mutual authentication for MAKE and PAKE is defined by an event, Succ, as follows.
Definition 17 (mutual Authentication [2]). We follow a definition of mutual authentication defined in [2]. For client authentication, we consider sessions where the server accepts with no partner instance of the client. With regard to server authentication, we consider sessions where the client accepts with no partner instance of the server. We say that an adversary breaks mutual authentication if either server or client instance is accepted, but has no partner oracle. We denote this event by Succ and its probability is defined as . We say that a given MAKE protocol provides mutual authentication if is negligible as follows:where is a negligible function and is a security parameter.
4. A Compiler from PAKE to MAKE with PUF
The construction of MAKE consists of two phases; one is for the PAKE phase to derive a common key, and the other is for generic authentication phase with the derived common key, as illustrated in Figure 2 and Figure 3, respectively. We use the following notations in the protocol.
4.1. Notation
(i): It is a set of messages transferred between the user U and the server S in the PAKE. We assume that it has bits. We can assume a function (pseudorandom or hash function) that maps a set of messages generated by any PAKE into the fixed size bits.(ii), , : is an identifier of U and it has bits. is U’s biometric template, pw is U’s memorable password, and s is a long-term secret key. is an agreed-upon common key between U and S in the PAKE, which are assumed to have bits.(iii): They are all cryptographic secure hash functions, which are simulated as random oracles in the security proof. They are, respectively, defined as , , , .
4.2. A Setup Description
(i)A setup is executed over a secure channel. U first computes a strong secret from its own biometric template . And, U evaluates PUF and generates from Gen. The values are sent to S.(ii)U and S securely maintain , respectively.
We note that the setup phase is a necessary step to share pw in the PAKE setting. Our MAKE setup phase is also unavoidable for securely delivering multiple authentication factors between U and S.
4.3. A Description of the Compiler
(1)A user U and a server S execute any efficient and provably secure PAKE protocol with (a set of all transferred messages) and a common key . If the agreement of or authentication is failed in the PAKE, then our compiler outputs a failure and stops the protocol. Otherwise, it continues to run the next step .(2)The user U inputs own biometric template and then computes a strong secret from. U evaluates PUF and executes Gen with , then computes )), and derives common keys for message authentication. U finally computes and and sends them to S.(3)On receiving , S first searches U’s list, from database. Then S derives from . S with verifies that is valid or not. If it is valid then S makes for a random , its authentication tag , and . S also computes keying material and its authenticator . The messages are sent to U.(4)Regarding , U verify ’s authenticator . If it is valid then U computes keying material . U also verifies by using . If it is also valid then U makes and sends it to S. Then U finally computes a common session key . On receiving , S verifies with . If it is valid, S finally computes a common session key .
In Figures 2 and 3, we illustrate a setup phase and a final general PUF-based MAKE construction, respectively. Our construction combines two authentication factors, biometric template, and long-term secret and makes one secret using a PUF. However, our compiler does not directly handle a password at all, but just takes a PAKE as an input. That is, our MAKE obtains PAKE’s session key through executing a secure PAKE. This approach can guarantee the password security such as off-line or on-line dictionary attacks, as explained earlier. Anyway, these two secret values are mainly used to establish intermediate keys .
4.4. Security Proof
The following well-known lemma [44] is used for calculating difference of probability between adjacent games in the security proof.
Lemma 18. Let , , and be events defined on a probability space such that . Then, we have .
Theorem 19. Let be a PPT adversary against the session key security of MAKE protocol P within a time bound T. can ask to send queries, executes queries, and thenwhere . are the total numbers of, tag, verification (for MAC) queries. are the computation time for MAC, exponentiation, and hash function, respectively.
Proof. We assume an adversary that runs in games from to . In each game, asks a query, then a coin for bit is flipped to specify a real key or a random key, and then outputs a guessing bit . Let be an event that = in and Pr[] is its probability. Also, is defined as an event that a server or a user instance accepts with no partner instance of the client in as in Definition 17.
Game The game provides a real environment for the MAKE protocol. By the security definition, the session key advantage of is defined as follows.Game In this game, a random key is selected randomly and it is replaced with the established key of the PAKE. Through the replacement, we show that if there exists a PPT adversary that distinguishes two games, then one can build an adversary that breaks the security of PAKE, which is shown in Lemma 20.
Lemma 20. The difference of success probability between and is at most the advantage of breaking 2-party PAKE protocol.where . is the total number of queries. are the computation time for MAC, exponentiation, and hash function.
Proof. exploits to guess a hidden bit defined in the experiment of 2-party PAKE. provides simulations on queries asked by . All queries are simulated as follows.(i)Hash queries of : If asks a hash query of to (resp. ) where a list appears in the hash table (resp. , ), then is returned as an answer for (resp. ). Otherwise, a new (resp. ) is chosen at random and returned. Then the list is added to the table (resp. ).(ii) It is classified into two types as follows.(a)If Send query is asked to the parts of PAKE, first asks Send() query to the PAKE and then returns its output as an answer. At the end of PAKE protocol, there exists a Send query to let the instance be accepted in the PAKE. For this Send query, uses the random key to simulate an answer . That is, first, evaluates PUF, computes , and then decides ), ) from and oracles. finally produces an answer, , for a random from . keeps for later simulations.(b)Otherwise if , then verifies . If it is valid, then it is accepted with and . finally outputs as an answer.(iii) There are also three types of queries as follows.(a)If Send query belongs to the query in PAKE, asks Send() query to the PAKE and then uses its output as an answer.(b)If , then verifies . If it is valid, then makes ), ) with previously made value . finally produces an answer, , for a random from . keeps for later simulations.(c)Otherwise if , then first verifies . If it is valid, then accepts it with .(iv) To return transcripts of an honest execution between and , collects all outputs of queries and outputs them as an answer(v) For the instance that has been accepted, returns as an output where .(vi) According to , it outputs registered password pw , PUF , biometric template , and s for .(vii) When asks query, chooses a random bit and selects a fs-fresh instance in aspect of MAKE and asks a Test query. For the hidden bit (real or session key), outputs . If , then outputs 1; otherwise, outputs 0. Let us consider the advantage of over the above simulation. We define an event real as a real session key, () is given by experiment of MAKE security while an event rand is a random key, and () is given to .If we suppose runs with polynomial time , then ’s running time is dependent on . Additionally, it requires the time of making the messages . Hence the total time is bounded as . is the total number of queries. are the computation time for MAC, exponentiation, hash function.
This completes the proof of Lemma 20.
Game . In this game, we consider a value in the protocol, which is an output of ideal PUF. We replace with a random value as a random oracle. That is, a table is maintained for a valid simulation. Regarding each input , if a list appears in , then is outputted as an answer. Otherwise, a random is selected from and returned as an answer for. The list is added to the list . Then, if there exists that is able to distinguish two adjacent games, then it is clear to build an adversary . In , an ideal PUF has been used, but in , a randomly chosen value is used. returns an output bit if . Otherwise, returns . Then we have the following.Game In this game, we analyze a collision event Col that an identical session key is accidentally generated for any two sessions. This event is due to a random oracle that produces final secrets . It can be analyzed in two cases. The first case is that if its simulated output (randomly chosen value) is identical for two sessions, then two sessions naturally have the same . For example, on two different input queries , each output can be simulated as an one random value . However, its probability is , which is negligible. The second case is that the input queries themselves can be the same and then they naturally output the same output of . The security (duplication) of comes from the security of PAKE, which is negligible. In addition, the values are decided by . Hence, for two sessions, the probability of equally selecting is bound to where are the total numbers of Send, Execute queries. We have the following.Game In this game, we consider an event MS that makes valid Send() queries where . Regarding valid messages , their query has been simulated in . Here, our goal is to exclude forgery events among queries that have valid MAC pair . Let us assume a MAC forgery . If this event happens, then halts and outputs the pair as its forgery of MAC, which contradicts a secure MAC assumption. If there are no forgeries, then returns a failure notification. Other processes of simulation for are the same as those of previous games. requires computational time such that , where is computational time for MAC and , are tag and verification queries that makes. The same analysis applies to the case of . We have the following.Game In this game, we consider a random DDH triple where , and . Using , the Send queries are simulated as follows.(i) It is classified into two types as follows.(a)If Send query is asked for letting the instance be accepted in the PAKE, then uses the random key to make . However, the value is replaced with . Accordingly, the value is made by . Other simulations are the same as the previous games.(b)Otherwise if , then verifies . If it is valid, then accepts with and . finally outputs as an answer.(ii) There are also three types of queries as follows.(a)If Send query belongs to the query in PAKE, the way of simulations is the same as the previous game.(b)If , then verifies . If it is valid, then makes , . However, the answer value is replaced with and its MAC value is also computed by . Others are the same as the previous games.By using , which tries to distinguish two games and , one can build a polynomial time algorithm that breaks the assumption of DDH. For a Test query, guesses a coin and outputs . If , then outputs 1, which means that the input triple is a real DDH triple. Otherwise it outputs 0 which means that the input triple is a random DDH triple. The success probability of is calculated as follows. requires computation time for simulating Send queries such that .Let us consider in . As simulated in Send queries, the session key is decided by the given random element . Hence is random and independent of elements , . That is, no information of is leaked through the Test query. We have the following.Thus, we obtain the final result as follows.Let us consider the event. We have already excluded collision events on and MAC forgeries on in the previous games. The left analysis is on . In this game, the secret is made by a random oracle and is also simulated by a random oracle . Thus, for successful impersonation, should correctly guess , . This probability is bounded as , respectively.By the following difference, we can bound . ( is the probability difference between and .) This completes the proof of Theorem 19.
5. Performance Analysis and Discussion
For coherent comparison and analysis, we follow a recent evaluation metrics that has been suggested by Wang and Wang [45] and been utilized in many other recent studies [20, 23, 45–47]. One important difference is that our scheme is not two-factor (smartcard and password) AKE scheme, but a generic construction that securely converts any secure PAKE into MAKE. Hence, regarding criteria on a password, our construction depends on the properties that the basis PAKE itself guarantees. And also, our scheme aims for a universal construction and thus it cannot guarantee or handle criteria on a smart card. Moreover, our scheme is the first generic MAKE using a PUF; for short, there is no scheme for comparison. However, in view of generic construction, we compare our generic construction with other recent schemes in Table 1 (security) and Table 2 (efficiency). As explained earlier, we remind again that recent schemes [33, 34] cannot be a generic construction, unlike their claims, even though their subjects are on general construction. However, please note that their constructions have been built up with the assumption of secure existing PAKE or TAKE. Thus, those two schemes [33, 34] have been analyzed with the FMA [35] scheme in each table. First, we briefly summarize 12 evaluation criteria introduced in [45].(i)C1: The server never needs a database for user password or verifier.(ii)C2: The user can freely choose and change a memorable password(iii)C3: The server administrator should not be able to derive user’s password.(iv)C4: The scheme is strong against a smart card loss attack.(v)C5: The scheme is strong against off-line, replay, parallel session, desynchronization, stolen verifier, impersonation, key control, unknown key share, and known key attacks.(vi)C6: The user can revoke own card without changing its own identity.(vii)C7: The scheme provides a key agreement between participants.(viii)C8: The scheme is free from a clock synchronization.(ix)C9: If a wrong password is typed by mistake, any type of notification is alarmed to the user.(x)C10: The scheme provides a mutual authentication.(xi)C11: The scheme protects users’ identities.(xii)C12: The scheme provides forward secrecy.
5.1. Discussion on Security Criteria
Our MAKE has been built up with a secure PAKE scheme. From the PAKE, our compiler securely adds other multiple factors to achieve an authenticated key exchange. Since the secure PAKE itself handles security of password, our construction is free from its related attacks. Thus, in some criteria, our scheme depends on how the basis PAKE has been instantiated. The same applies to other schemes [33–35]. It is because not only they have been constructed from secure initiations (general construction), but also security criteria defined in [45] (Table 1) are actually motivated from two-factor authenticators (password and smart card). For instance, a general MAKE construction just assumes multiple long-term secrets and does not take account of how these secrets are maintained. Thus, a smart card stolen attack (C4) cannot be considered in a general construction model. In our model, however, we firstly use PUF as an authenticator that is dependent on a hardware device such as a smart card, and C4 can be analyzed for comparison. Even if an adversary obtains PUF, our scheme is still secure authentication unless other secrets remain secure, which is better criterion than others. The criteria C2, C3, C4, C6, C9 are closely related to the underlying PAKE or TAKE. In particular, C1 evaluates whether a database is required or not for a password verifier. In most TAKE schemes over a smart card, actually C1 may be easily attained. It is because they assume a smart card that is capable enough to take a valid password as an input through a card reader and calculate a valid shared secret with a server if its input password is valid on a smart card. Afterwards, the server just takes a step for checking whether the shared secret is valid or not, which never requires a password or password verifier on a server side. However, in generic compiler setting, first of all, holding a smart card is not necessary condition. It just focuses on how to securely transform a secure primitive one into an integrated primitive one. One may argue that a general MAKE can be systematically constructed from a TAKE with a smart card. But, in this approach, the underlying TAKE already includes a smart card, and it is hard (or not practical) to include a new hardware dependent PUF more. In conclusion, in PUF setting, it is more reasonable to initiate PAKE (or AKE) first and then construct MAKE by using PUF. Table 1 shows that our scheme is an accurate general MAKE construction with relatively better security performances.
5.2. Discussion on Efficiency
Table 2 shows, in general construction setting, that our scheme achieves better communication cost than the FMA [35] scheme. The FMA scheme executes many types of subprotocols for making a general MAKE. It may guarantee better security from the secure underlying subprotocols with simple implementation. However, two authentication factors are never used together for one subprotocol, and many types of subprotocols should be initiated independently. Hence, it has a fundamental limits in order to reduce the total communication cost. In Table 2, we assume that a normal PAKE or TAKE can be designed in two communication flows without an authentication. This influences upper or lower bounding of TFR. In conclusion, our scheme requires at most 6 communication flows with no public key based setting such as a signature used. While the total communication flow is more greatly enhanced than the FMA [35], our communication cost is not better than the FMA. This slight inefficiency is due to the use of PUF and Diffie-Hellman keying materials for guaranteeing forward secrecy. That is, enhanced security and the reduced total communication cost balance up this little computation loss. One interesting topic would be on how we can design MAKE with PUF at the lower communication bounding cost . Except the part of PAKE, our compiler additionally needs three more communication flows. But, by initiating PAKE, we already share a common key. This common secret can be used for making a final session key with slight modification. For instance, in our protocol, a user can compute a final session key after receiving messages in step , ignoring step . In the same way, upon messages of , a server can generate a final session key before step . The messages in steps and can be designed for just sharing ephemeral values and verifying (authentication) keying materials by using a shared key from PAKE. This construction remains one of future work including security analysis under rigorous security model.
6. Concluding Remarks
In the paper, we presented a general PUF-MAKE construction that securely transforms a PAKE into a MAKE with a physically unclonable function. Our construction especially takes a secure PAKE rather than taking the PKI-based (or non PKI-based) AKE as an input. The reason is that it naturally resolves a password issue such as off-line or on-line dictionary attacks. For instance, in case of transforming a PKI-based AKE into a MAKE, we should first go through a problem on how an easy-to-guess password can be securely combined with the PKI-based AKE and biometrics, which would be much more harder than the case of combining the PAKE with a long-term key and biometrics. Nevertheless, in view of foundation works, it is quite meaningful to show the existence of PUF-MAKE from PKI, non-PKI-based AKE, or other AKE primitives. In addition, we elaborated on two-party setting here, but a general PUF-MAKE construction for a group setting would also be a good future work.
Data Availability
The data used to support the findings of this study are included in the article.
Conflicts of Interest
The author declares that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This research was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (NRF-2017R1D1A1B03032424).