CAKE: Compatible Authentication and Key Exchange Protocol for a Smart City in 5G Networks

: In a smart city, there are different types of entities, such as nature persons, IoT devices, and service providers, which have different computational limitations and storage limitations. Un-fortunately, all of the existing authentication and key exchange (AKE) protocols are designed for either client–server or client–client authentication, including the ones designed for smart cities. In this paper, we present the idea of a compatible authentication and key exchange (CAKE) protocol which provides cross-species authentication. We propose the ﬁrst CAKE protocol for a smart city that any two valid entities can authenticate with each other and create a secure session key without the help of any third party, while there is also no password table and no public key issuing problem. The entity can be a natural person having biometrics, an IoT device embedded with a physical unclonable function (PUF), or a service provider. Moreover, we extend the CAKE protocol to an anonymous CAKE (ACAKE) protocol, which provides natural persons an anonymous option to protect their privacy. In addition, both the proposed CAKE and ACAKE protocols can deal with the entity revocation problem. We deﬁne the framework and the security model of CAKE and ACAKE protocols. Under the security model, we formally prove that the proposed protocols are secure under the elliptic curve computational Difﬁe–Hellman (ECCDH) problem, the decisional bilinear Difﬁe–Hellman (DBDH) problem, and hash function assumptions. Comparisons with the related protocols are conducted to demonstrate the beneﬁts of our protocols. Performance analysis is conducted and the experience results show that the proposed protocols are practical in a smart city.


Introduction
Smart technologies play an important role in our daily lives, such as smart cities, smart grids, smart homes, autonomous vehicles, drones, telemedicine, teleportation, and remote education. With the development of smart technologies, the number of Internet of Things (IoT)-connected devices is currently around 30 billion and will increase to around 75 billion in 2025 [1]. The fifth generation (5G) technology standard for cellular networks provides high speed, high capacity, extremely low latency, and a significant improvement in users' perceived quality of service (QoS), as compared to current 4G LTE networks [2]. Fifth generation networks are expected to be the panacea of the network issues of IoT [3][4][5]. Fifth generation-based IoT middleware systems have several security challenges [6], in which the authentication and key exchange (AKE) protocol is the most significant security issue, since the entities communicate to each other in untrustworthy networks (i.e., the Internet).
An AKE protocol allows two parties to authenticate mutually and create a secure common session key to communicate with each other. All of the existing AKE protocols are designed for either client-server or client-client authentication. None of the existing AKE protocols provide cross-species authentication, which allows cross-species entities to authenticate mutually and create a secure session key. We first propose the concept of the compatible AKE (CAKE) protocol, which enables any two entities to mutually authenticate with each other over untrustworthy channels, for example, not only for client-server but also for client-client and server-server authentication.

Contributions
In this paper, we propose the first compatible AKE (CAKE) protocol for smart cities, which provides cross-species authentication; meanwhile, the proposed protocol achieves multi-factor authentication, suitability for a multi-server environment, independent authentication, member revocation, being password table-free, and being public key managementfree. According to the guidelines for designing a secure anonymous AKE (AAKE) protocol [7], we furthermore extend the proposed CAKE protocol to an anonymous CAKE (ACAKE) protocol, which achieves user anonymity and user untraceability/unlinkability, in order to protect the privacy of natural persons in a smart city.
We define the adversary model of CAKE/ACAKE protocols and provide the formal security proofs of the proposed protocols. We compare the proposed CAKE/ACAKE protocols with the related AKE protocols and analyze the performance to show that the proposed CAKE/ACAKE protocols are efficient and practical in smart cities. We estimate the executing costs of an IoT device on a 32-bit Philips HiPerSmart TM smart card with a maximum clock speed of 36MHz, a natural person on a Linux personal digital assistant equipped with a 206-MHz strong ARM processor and on an Intel PXA270 processor at 624-MHz installed on the Linux personal digital assistant, and a service provider and the registration center (RC) on a PIV 3-GHZ processor with 512-MB memory and a Windows XP operation system.

Paper Organization
The rest of the paper is organized as below. Section 2 presents the related work, and the preliminaries are presented in Section 3. We present the proposed protocols in Section 4 and analyze the security of the proposed protocols in Section 5. The comparisons and the performance analysis are given in Section 6, and the conclusion is drawn in Section 7.

Related Work
In the past, a large number of AKE protocols have been proposed. Here, we introduce some properties of these protocols that include multi-factor authentication, multi-server environment, independent authentication, user anonymity, user untraceability/unlinkability, and member revocation.

1.
Multi-factor authentication: Remote authentication schemes were developed from the one-factor, i.e., password, authentication [8] to the two-factor and multi-factor authentication. In general, a two-factor authentication adopts smartcards as the additional second factor to avoid replay attacks, and a three-factor authentication adopts biometrics or physical unclonable functions (PUFs) as the additional third factor to avoid smartcard stolen attacks.

2.
Suitability for a multi-server environment: Traditional client-server AKE protocols were proposed for single-server environments. Nowadays, there are many systems constructed in multi-server architectures. Many AKE protocols for multi-server environments were proposed and users need not to register at different servers.

3.
Independent authentication: There is a trusted third party who needs to involve the authentication phase in many AKE protocols. On the contrary, some AKE protocols can achieve independent authentication in the sense that two entities can freely authenticate with each other by themselves without the help of any third party.

4.
User anonymity: In an AAKE protocol, the real identity of a user would not be revealed to others when he/she logs into a server through an untrustworthy channel.

5.
User untraceability/unlinkability: In ordinary AAKE schemes, even though a user uses an anonymous identity to log in, the relationship between each login is exposed to a third party since the user uses a duplicate anonymous identity in each login. Some AAKE protocols not only achieve user anonymity but also achieve user untraceability/unlinkability, where a user cannot be traced by the login transmissions, i.e., no third party can derive the relationship between any two login transmissions. Without loss of generality, to avoid the physical location tracking in an AAKE scheme, users either can simply forge their location or use physical layer signatures [9] to simultaneously achieve privacy-preserving location authentication and user untraceability. 6.
Member revocation: Many AKE protocols did not deal with the member revocation problem when a member is disabled or leaving. As compared with traditional revocable AKE protocols using a certificate revocation list (CRL), the advanced ones adopt time periods to deal with revocation problems, namely, a revoked or disabled member could not obtain the latest secret key in the next time period. 7. Public key issuing-free: No public key needs to be announced; that is, either there are no public keys in the system or the identity can be used as the public key. 9.
Leakage-resilient: This property helps to resist side channel attacks.
According to the survey proposed by Chuang and Lei [10], there is no AKE protocol that simultaneously achieves all the properties mentioned above, and none of them provide cross-species authentication, which allows cross-species entities to authenticate mutually and create a secure session key.
Li et al. [11] proposed an authentication and key agreement scheme with user anonymity for a roaming service in a smart city in 2017, and their protocol did not provide multi-factor authentication, suitability for a multi-server environment, independent authentication, and member revocation. After that, both Li et al. [12] and Reddy et al. [13] proposed privacy-preserving authentication protocols for smart cities, which additionally achieved independent authentication as compared with Li et al.'s [11] protocol. In 2019, Xie and Hwang [14] proposed a two-factor anonymous roaming authentication scheme in a smart city, which additionally achieved suitability for a multi-server environment as compared with Li et al.'s [11] protocol. Jegadeesan et al. [15] proposed an anonymous mutual authentication technique for mobile cloud computing in a smart city in 2019, which additionally achieved independent authentication as compared with Xie and Hwang's protocol [14]. All of these schemes [11][12][13][14][15] do not provide compatible authentication. Although many existing anonymous AKE protocols [16][17][18][19][20][21][22][23][24][25] are suitable for a smart city, none of them provide cross-species authentication and none of them achieve all the properties mentioned above [10]. No CAKE protocol for a smart city has been proposed up to date.

Physical Unclonable Functions
A physical unclonable function (PUF) is a physical entity embedded in a physical device, such as a microprocessor, that provides a physically defined output (response) for a given input (challenge).
The challenge and the corresponding response are called the challenge response pair (CRP). PUFs provide alternate hardware fingerprints which can be used for lightweight authentication [26,27]. PUFs can be generally classified into strong PUFs and weak PUFs according to the number of possible CRPs [28]. A weak PUF only supports a small amount of CRPs in the sense that an attacker could obtain all the responses when it obtains temporary access to the device. Weak PUFs are typically used for key storage, since the responses are stable in the sense that a challenge always yields the same response in various environments and conditions. A strong PUF can support a large number of CRPs; hence, it is generally employed for authentication.

Fuzzy Extractors
A fuzzy extractor [29] or helper data algorithm can generate stable cryptographic keys with appropriate entropy from noisy and non-uniformly distributed random PUF responses [30][31][32].
Using the Bose-Chaudhuri-Hocquenghem (BCH) codes and the hash function can guarantee the elimination of noise from the collected noisy data and the uniform distribution of the derived key bits [29][30][31][32]. Kang et al.'s article [30] illustrates the implementation diagram for the efficient fuzzy extractor using the BCH code and syndrome concept (N = 255). The helper data along with a BCH decoder can be used to re-generate the correct response from the actual response of a PUF for a specific challenge.

•
Collision resistance: It is hard to find a, c ∈ A such that a = c and H(a) = H(c).

Proposed Protocols
In this section, the CAKE and ACAKE protocols for a smart city are proposed. In the proposed protocols, there are four kinds of components, namely, one registration center (RC), numerous service providers (Server), plenty of natural persons (NP), and a large number of IoT devices, which are depicted in Figure 1. RC is a trusted third party, which is responsible for the system setup and performing the registration, revocation, and key updating for members. Servers can have a variety of functions, such as providing services for NPs, monitoring and controlling IoT devices, and gathering and analyzing data from IoT devices. A server may be a cashier, an automated teller machine (ATM), a housekeeper, a web service provider, a cloud service provider, a medical service provider, a library, a school, a company, a bank, a city control center, a government department, etc. An IoT device is assumed to have embedded physical unclonable functions (PUFs) and low computational capability; it may be a sensor, electrical appliance, traffic signal, streetlight, surveillance camera, vehicle, etc. In addition, we summarize the notations in Table 1.

Framework of CAKE and ACAKE Protocols
A fuzzy extractor [29] or helper data algorithm can generate stable cryptographic keys with appropriate entropy from noisy and non-uniformly distributed random PUF responses [30][31][32]. Here, we present the framework of the proposed CAKE and ACAKE protocols. The ACAKE protocol is an extended CAKE protocol, which additionally provides an anonymity option for natural persons to protect their privacy. The framework of the proposed CAKE and ACAKE protocols consists of four phases, namely, initialization phase, registration phase, online update phase, and CAKE/ACAKE phase. Figure 2 presents the framework of the proposed CAKE and ACAKE protocols. In both the CAKE and ACAKE protocols, every member has to register at the registration center (RC) in a secure environment when it joins the system. In the CAKE phase, each member can mutually authenticate with the other member and establish a secure session key through an untrustworthy channel without the help of any third party, even if they are different kinds of members. NP has an anonymity option to run the ACAKE phase with the other NP, Server, or IoT device. In the ACAKE protocol, the real identity of NP would not be revealed in the transmitted channel, and the relation between NP's sessions is untraceable.
For the member revocation problem, both the CAKE and ACAKE protocols employ a key update method to refresh the current secret key for each new time period. In such a case, every member must run the online update phase to update its secret key. Each member has to update its secret key with the help of RC through an open channel at each time period. Once a member is revoked or disabled, it will not be able to receive the new updated key in the next time period. The length of a time period, which is decided by the supervisor, may be days, weeks, or months.

Proposed CAKE Protocol
The proposed CAKE protocol comprises four phases, namely, initialization, registration, online update, and compatible authentication and key exchange (CAKE) phases. Note that in both the online update and CAKE phases, we define an algorithm GETKEY(A) to be a procedure obtaining the secret key of member A.

Initialization Phase
RC chooses a large prime q and defines a finite field F q and an elliptic curve E(F q ) by an equation of the form y 2 = x 3 + mx + n, where m, n ∈ F q satisfy 4 m 3 + 27 n 2 = 0 (mod q). RC produces a bilinear map, ê: G 1 × G 1 → G 2 , where G 1 is a subgroup of the additive cyclic group of points on E with order q, and G 2 is a multiplicative cyclic subgroup over F q with order q. RC picks a generator point P in G 1 and chooses four distinct one-way hash functions, namely, H 1 :{0, 1} * → G 1 , H 2 :{0, 1} * → G 1 , h 1 :{0, 1} * → {0, 1} l , and h 2 :{0, 1} * → {0, 1} l , where l is the fixed length of the output. RC also generates the master secret key MSK ∈ Z p * . For each t-time period, RC randomly generates a seed s t ∈ Z q * , computes the master private key MRK t = h 1 (MSK||s t ) and master public key MPK t = MRK t ·P, and appends (t, s t , MRK t , MPK t ) to list L seed and keeps it secret. RC sets the public parameters Pub = {q, G 1 ,

Registration Phase: Natural Person
When a natural person NP i with a smart card wants to join the system, NP i interacts with RC as the following steps, which are illustrated in Figure 3. Step 1: NP i chooses his/her identity ID i and password pw i and imprints his/her biometric to the device to obtain B i . The device performs the generation procedure Gen of the fuzzy extractor on B i to obtain the secret string SS i and helper string HLP i , i.e., (SS i , HLP i ) = Gen(B i ). The device computes RPW i = H 2 (ID i ||pw i ||SS i ) and gives <ID i , RPW i , "NP"> to RC.
Step 2: RC checks the current time period index t and verifies the validity of NP i . If RC wants to authorize NP i , then RC computes K i_t = MRK t ·H 1 (ID i ||MPK t ) and Q i_t = K i_t + RPW i , lets Info ← {ID i , t, Q i , MPK t }, and issues a new smart card with Info to NP i .
Step 3: NP i inserts the received smart card into the device, and the device appends HLP i to the smart card.

Registration Phase: Server
When a new server S j wants to join the system, it has to register at RC and perform the following steps, which are illustrated in Figure 4, in a trusted environment. Step 1: S j chooses its identity ID j and password pw j and gives <ID j , "Server"> to RC.
Step 2: RC checks the current time period index t and verifies the validity of S j . If RC wants to authorize S j , then RC computes S j 's secret key K j_t = MRK t ·H 1 (ID j ||MPK t ) and sends <t, MPK t , K j_t > to S j .
Step 3: After receiving <K j_t >, S j computes RPW j = H 2 (ID j ||pw j ) and Q j_t = K j_t + RPW j and lets Info ← {ID j , t, Q j , MPK t }. S j then stores Info.

Registration Phase: IoT Device
The following steps, which are illustrated in Figure 5, are performed in a trusted environment before adding an IoT device D l into the system. Step 1: RC checks the current time period index t, chooses D l 's identity ID l , computes the challenge string C l = h 1 (ID l ||MPK t ), gives <ID l , C l > to D l , and waits for the response.
Step 2: D l performs a PUF on the challenge string C l to obtain the output response R l and performs the generation procedure Gen of the fuzzy extractor with the BCH encoder [30] on B i to obtain the secret string SS l and helper string HLP l , i.e., R l = PUF(C l ) and (SS l , HLP l ) = Gen(R l ). D l computes RPW l = H 2 (ID l ||SS l ) and sends <RPW l , HLP l > back to RC.
Step 3: RC computes D l 's secret key K l_t = MRK t ·H 1 (ID l ||MPK t ) and Q l_t = K l_t + RPW l , and lets Info ← {ID l , t, Q l , MPK t , HLP l }. RC then sends <Info l > to D l . D l then stores Info l .

GETKEY(A) Algorithm
If A is NP, then A takes as input ID A and pw A and imprints the biometric to obtain BA, and the smart card performs the deterministic reproduction procedure Rep on B i to recover SS A from the corresponding helper string HLP A , i.e., If A is Server, then A inputs ID A and pw A , computes RPW A = H 2 (ID A ||pw A ) and secret key K A_t = Q A − RPW A , and outputs K A .
If A is IoT, then A computes the challenge string C A = h 1 (ID A ||MPK), performs a PUF on C A to obtain the response string R A , performs the deterministic reproduction procedure Rep on R A to recover SS A from the corresponding helper string HLP A , i.e., R A = PUF(C A ) and SS A = Rep(R A , HLP A ), computes RPW A = H 2 (ID A ||SS A ) and secret key K A = Q A − RPW A , and outputs K A .

Online Update Phase
Each NP, Server, and IoT device needs to perform the following steps, which are illustrated in Figure 6, through an untrustworthy channel to online update its secret key before it authenticates with another member in t-time period. Step 1: The entity, say Entity A, executes K A_t ← GETKEY(A), randomly generates n ∈ Step 2: RC checks the current time period index t*. RC verifies ID A and computes K A_t Step 3: A computes K A_t* =U A_t* − H 2 (K A_t ||R), MPK t* = V A_t* − H 2 (K A_t ||N 1 ), and Q = Q A − K A_t + K A_t* . A verifies if d A_t* = h 2 (MPK t* ||K A_t* ||K A_t ||R). If so, then it rewrites Q i ← Q, t ← t*, and MPK t ← MPK t* .

CAKE Phase
When two entities, say Entity A and Entity B, want to mutually authenticate with each other in t-time period and create a secure session key, they perform the following steps, which are illustrated in Figure 7, through an untrustworthy channel. Note that the entity may be a natural person, server, or IoT device. Step 1: A randomly generates n A ∈ R Z q * , computes N A = n A ·P, and sends <ID A , N A , "CAKE"> to B.
Step 2: B randomly generates n B ∈ R Z q * and computes N B = n B ·P, K B_t ← GETKEY(B), Step 3: A performs K A_t ← GETKEY(A), computes y 1 = n A ·N B and y 2 = ê(K A_t , H 1 (ID B ||MPK t )), and verifies if v B = h 2 (ID A ||ID B ||MPK t ||y 1 ||y 2 ). If so, then the authority of B is confirmed, and A computes session key SK = h 1 (ID A ||ID B ||N A ||N B ||y 1 ||y 2 ) and v A = h 2 (ID A ||ID B ||h 2 (SK)), and sends <v A > to B.
Step 4: B computes SK = h 1 (ID A ||ID B ||N A ||N B ||y 1 ||y 2 ) and verifies if v A = h 2 (ID A ||ID B ||h 2 (SK)). If so, then the authority of A is confirmed, and B accepts SK as the session key.

Proposed ACAKE Protocol
The propose ACAKE protocol is an extension of the CAKE protocol, which has an extra anonymous compatible authentication and key exchange (ACAKE) phase for natural persons. The GETKEY algorithm and initialization, registration, online update, and CAKE phases are the same as those in the proposed CAKE protocol. NP can additionally perform the ACAKE phase as follows, which is illustrated in Figure 8, to make AKE with another member while keeping the secrecy of his/her real identity.

ACAKE phase
When a natural person, say NP i , wants to anonymously authenticate with Entity B, whose identity is known by NP i , they perform the following steps to mutually authenticate with each other and establish a secure common session key through an untrustworthy channel.
Step 1: NP i randomly generates n i R Z q * , computes N i = n i ·P, TK = ê(n i ·MPK t , H 1 (ID B ||MPK t )), and anonymous identity AID = TK ID i , and sends <AID, N i , "ACAKE"> to B.
Step 2: B randomly generates n B R Z q * and computes N B = n B ·P, K B_t ← GETKEY(B), Step 3: NP i performs K i_t GETKEY(NP i ), computes y 1 = n i ·N B and y 2 = ê(K i_t , H 1 (ID B ||MPK t )), and verifies if v B = h 2 (ID i ||ID B ||MPK t ||y 1 ||y 2 ). If so, then the author-ity of B is confirmed, and NP i computes session key SK = h 1 (ID i ||ID B ||N i ||N B ||y 1 ||y 2 ) and v i = h 2 (ID i ||ID B ||h 2 (SK)) and sends <v i > to B.
Step 4: B computes SK = h 1 (ID i ||ID B ||N i ||N B ||y 1 ||y 2 ) and verifies if v i = h 2 (ID i ||ID B ||h 2 (SK)). If so, then the authority of NP i is confirmed and SK is accepted as the session key.

Security Analysis
Here, we propose threat assumptions, and construct an adversarial model for a CAKE/ACAKE protocol. We then formally prove that our CAKE and ACAKE protocols achieve existential session key secrecy and perfect forward secrecy under ECCDH and hash function assumptions and existential unforgeability under the DBDH and hash function assumptions in Theorem 1 and Theorem 2, respectively. We also formally prove that our ACAKE protocol achieves existential anonymity under DBDH and hash function assumptions in Theorem 3.

Threat Assumptions
Assume that an adversary might have the following attack capabilities in a CAKE/ ACAKE protocol. AC7: Individually obtain the (identity, password) pair, obtain the secret data in the smart card, fake the biometric, and correctly predict the PUF's responses. However, breaking them all in polynomial time is not feasible.

Adversarial Model of CAKE Protocols
The adversarial model of the CAKE protocol is defined in a random oracle model [42]. There are four kinds of members in the adversarial model: a trusted registration center (RC), m Server, n natural persons (NP), and d IoT devices. Each entity has a unique identity. Let Π s α denote the s-session of entity α. Π s α and Π t β are partners if they are the same session, i.e., α and β authenticate with each other and accept a common session key in α's s-session and in β's t-session. Let A be a probabilistic polynomial time (PPT) algorithm that simulates the behavior of an adversary, who can potentially control all the communications by asking the queries described below, and the queries are responded to by a Challenger B (oracle).

1.
Hash (M): B maintains a hash list to ensure the identical responses and avoid the collision. If Hash (M) has been asked before, then B returns the same response. Otherwise, B generates a random value h, appends (M, h) to the hash list, and returns h.

2.
Extract (α): This query can be asked for entity α, who is not one of the existing members. B executes the registration phase of the protocol and responds to the corresponding results. (AC1) 3.
Send (Π s α , M): B responds to the corresponding results, which should be responded to by α after α receives the message M, by executing the protocol. It models the active attack. (AC1) (AC2) 4.
Execute (Π s α , Π t β ): B returns the complete transcripts of an honest execution between entity α in its s-session and its partner Π t β . It models the passive attack. (AC2)

5.
Reveal (Π s α ): If entity α has accepted a session key, say SK, in its s-session, then B returns SK. Otherwise, B returns "NULL". It models the known session key attack. 6.
Test SK (Π s α ): B flips an unbiased bit b ∈ {0,1}. If b = 1, then B returns the session key of entity α in its s-session. If b = 0, then B returns a random value.
An oracle Π s α with its partner Π t β is said to be fresh if the common session key SK = NULL between them is confirmed, both Reveal (Π s α ) and Reveal (Π t β ) queries have not been asked, and there is no Corrupt (α) or Corrupt (β) query asked before the Send (Π s α , M) or Send (Π t β , M) query. A can ask the Test SK (Π s α ) query only once at any time during the game and may ask other queries when asking the Test SK (Π s α ) query whenever Π s α is fresh. A outputs its guess b' for the bit b in the Test SK (Π s α ) query eventually. Let A's distinguishing ability in the Test query measure the advantage of A, and let Succ denote the event that A successfully guesses the unbiased bit b in the Test query, and the advantage of A attacking the protocol Ψ is defined by Adv Ψ (A) = |2 · Pr(Succ)− 1|. Note that if A guesses b totally in random, then Pr(Succ) would approach 1/2 and Adv Ψ (A) is negligible. The adversarial model is a random oracle model where oracles behave with a hash function as a true random function, which produces a random value for each new query.

Adversarial Model of ACAKE Protocols
The adversarial model of ACAKE protocols is the same as the adversarial model of a CAKE protocol, which additionally has an extra Test ID (Π s α ) query as follows.

1.
Test ID (Π s α ): B flips an unbiased bit b in {0, 1} and returns the real identity of entity α if b = 1. If b = 0, then a random value is returned.
A can ask the Test ID (Π s α ) query only once at any time during the game and may ask other queries when asking the Test ID (Π s α ) query whenever Π s α is fresh. A outputs its guess b' for the bit b in the Test ID (Π s α ) query eventually. A's ability of distinguishing the session key/identity from a random value in the Test query measures the advantage of A.

Definition 2.
A CAKE/ACAKE protocol achieves existential perfect forward secrecy, secrecy of the session key, and unforgeability if there is no probabilistic polynomial time adversary A, who has a non-negligible advantage in the following game played between A and an infinite set of oracles.

1.
The system is set up according to the initialization and registration phases of the protocol.

2.
A may ask the following queries and obtain the corresponding results: Test, Hash, Execute, Send, Extract, Corrupt, and Reveal.

3.
There is no Corrupt (α) or Reveal (Π s α ) query asked before the Test (Π s α ) query. A may ask other queries when asking the Test (Π s α ) query whenever Π s α is fresh and eventually outputs its guess b' for the unbiased bit b in the Test (Π s α ) query. The game is terminated.

Formal Proof
Theorem 1. The proposed CAKE and ACAKE protocols achieve existential perfect forward secrecy and secrecy of the session key under the ECCDH and hash function assumptions.  The proofs of Theorems 1, 2, and 3 are presented in Appendix A.

Comparisons and Performance Analysis
Biometrics and physical unclonable functions (PUFs) are, respectively, adopted as the third authentication factor of a nature person and an IoT device in the proposed CAKE/ACAKE protocols; hence, our protocols achieve multi-factor authentication. In the proposed CAKE/ACAKE protocols, servers are regarded as independent entities that have distinct secret keys, and no third party is involved in the CAKE/ACAKE phase; hence, our protocols are suitable for a multi-server environment and achieve the independent authentication property. Each member periodically executes the online update phase to achieve the member revocation property that a member cannot authenticate with another member if he/she does not update his/her secret key in the present period. In the proposed ACAKE protocols, anonymous nature persons use dynamic values to mask their real identities to achieve anonymity and untraceability/unlinkability.
The comparisons between our CAKE and ACAKE protocols and the related AKE protocols are listed in Table 2. The protocols in [11][12][13][14][15] are the related anonymous AKE protocols designed for smart cities, and all of them are two-factor authentication and do not provide compatible authentication and member revocation properties. The protocols in [16][17][18][19][20][21][22][23][24][25] are the related AKE protocols, which are suitable for multi-server environments; the protocols in [18][19][20][21][22] achieve independent authentication, but the protocols in [18,21] do not provide user anonymity. The protocols in [22][23][24][25] are three-factor authentication schemes, which are suitable for multi-server environments and provide user privacy protection (user anonymity and untraceability/unlinkability); however, the protocols in [23][24][25] do not provide independent authentication. As shown in Table 2, only our ACAKE protocol achieves all the listed properties; moreover, there is no password table or public key issuing problem in our CAKE/ACAKE protocols.
a using three or more than three factors to authenticate; b users do not need to register at each server; c without the help of any third party; d revocation list.
For convenience, let TG ê , TG mul , TG add , T H , and T h , respectively, denote the time cost of executing bilinear pairing, multiplication on ECC, point addition on ECC, hash function mapping a string to a point on ECC, and hash function mapping a string to a string. Scott et al. [43] implemented the standard Tate pairing (k = 2) over a large 512-bit field on a 32-bit Philips HiPerSmart TM smart card with a maximum clock speed of 36 MHz, an instantiation of the MIPS-32 based SmartMIPS TM architecture. Cao et al. [44] implemented the standard Tate pairing over a large 512-bit field and the 160-bit hash in group G on a PIV 3-GHz processor with 512-MB memory and a Windows XP operation system, and on a Linux personal digital assistant equipped with a 206-MHz Strong ARM processor. Xiong and Qin [45] implemented the same experiment on an Intel PXA270 processor at 624-MHz installed on the Linux personal digital assistant. The time costs of T H on a 36-MHz device and on a 3 GHz device are estimated by 3.04 × 3000/624 = 14.62 and 3.04 × 3000/36 = 253 milliseconds, respectively.
Cavalieri and Cutuli [46] implemented a hashing algorithm on the MSP430 family, assuming a frequency of 8 MHz, and the execution time was 0.065 milliseconds, which is negligible. We ignore the computational costs of the hash function, the point addition on ECC, generating a random number, and XOR and concatenation operations here.
In the online update phase, the time cost of cryptographic operations of a member and RC is 2TG mul + 3TG H + 4TG add + 2T h and 3TG mul + 4TG H + 2TG add + 2T h , respectively. The estimated execution times of an IoT member with a 36-MHz device, a natural person with a 206-MHz device, a natural person with a 624-MHz device, a server with a 3 GHz device, and RC with a 3  Table 3 summarizes the times of executing cryptographic operations and the times of RC and each kind of member executing cryptographic operations during three phases in the proposed protocols: online updating, CAKE, and ACAKE phases. Note that TG add and T h are negligible and ignored here. As shown in Table 3, the execution times are appropriate. Assume that RC has 100 computers, with a frequency of 3 GHz, simultaneously performing members' registration and online updating. Then, RC can perform registration for 10,615 entities in one second, where 1000 ms/((6.38 ms + 3.04 ms)/entity) × 100 = 10,615 entities, or perform online updating for 3194 members in one second, where 1000 ms/(31.3 ms/member) × 100 = 3194 members. Thus, RC has the ability to perform the online update for all members in each time period to deal with the member revocation issue. The proper length of a time period, which is decided by the supervisor, may be hours, days, or weeks.

Conclusions
In this paper, we first proposed the concept of compatible authentication, which provides an efficient cross-species authentication. We proposed the first CAKE and ACAKE protocols for a smart city in 5G networks. The proposed ACAKE protocol is the first protocol that simultaneously achieves all the presented properties: probably secure, compatible authentication, multi-factor authentication, suitability for multi-server environments, independent authentication, user anonymity, user untraceability/unlinkability, member revocation, list-free, public key management-free, and efficiency. We formally analyzed the security of the proposed protocols and demonstrated the efficiency.
In the proposed CAKE and ACAKE protocols, the registration center (RC) is assumed to be a powerful party working in a secure and trusted environment meaning that it does not matter if the RC cannot resist side channel attacks; members can partially resist side channel attacks since they periodically execute the online updating phase to change their secret keys. Our future work will enhance the proposed protocols to establish a protocol which resists side channel attacks, and we will consider the applicability in systems based on blockchains.

Conflicts of Interest:
The authors declare no conflict of interest.

Appendix A
Proof of Theorem 1. Suppose that there are one trusted third-party registration center (RC), m Server, n natural persons (NP), and d IoT devices in the smart city system. Each entity has a unique identity. Suppose that there is an adversary A, who can break the perfect forward secrecy or the secrecy of the session key of the proposed CAKE/ACAKE protocols with a non-negligible advantage in probabilistic polynomial time. Then, we can construct a Challenge Algorithm B to solve the ECCDH problem with a non-negligible advantage by using A's ability of breaking the protocol. An instance (G 1 , G 2 , P, ê, q, X = xP, Y = yP) of the ECCDH problem is given to B, and B's goal is to output xyP. B permeates the ECCDH problem into the queries, which are asked by A in the l-session for Π S U and its partner Π T V . B manages a time seed list L seed , and four hash lists L H1 , L H2 , L h1 , and L h , which are empty initially. B generates a master secret key MSK ∈ Z p * . For each t-time period, B randomly generates s t , r t ∈ Z q * , sets the master private key MRK t = h 1 (MSK||s t ) and master public key MPK t = MRK t ·P, and appends ((MSK||s t ), r t , r t ·P) to list L h1 and (t, s t , MRK t , MPK t ) to list L seed . B sets Pub = {q, G 1 , G 2 , P, ê} to be public parameters. B simulates the oracle queries:

1.
Hash (M): B checks the hash lists and returns the corresponding value if it is in the list. Otherwise, B randomly generates r ∈ Z q * and m ∈ {0,1} l and returns the value by the following three different types of hash queries. Extract (α, M): If α is one of the members, then it returns "Reject". Otherwise, it returns the corresponding registration parameters as follows. B checks the current time period t and list L seed to obtain (t, s t , MRK t , MPK t ).

4.
Send (Π n β , M): There are three different types of Send query in the proposed protocols: Update, CAKE, and ACAKE. Assume that the current time is in t*-time period. B checks list L seed to obtain (t*, s t* , MRK t* , MPK t* ) and responds according to the type of Send query.
Corrupt (α): If entity α is one of the system members, then B runs the same procedures as the Extract (α, M) query and returns the corresponding result. If A can successfully break the perfect forward secrecy or the secrecy of the session key of the proposed protocols, then xyP should appear in the L h1 list. B uses Tag to find (M = (Tag||y 1 ||y 2 ), r, R) in L h1 , where y 1 = xyP and R = SK. Then, B answers with xyP to the ECCDH problem. The successful probability of B solving the ECCDH problem depends on the successful probability of A asking the Test SK query in the l-session for Π S U or its partner Π S U and breaking the perfect forward secrecy or the secrecy of the session key of the proposed protocols. The successful probability of B solving the ECCDH problem depends on the event that A asks the Test SK query in the l-session for Π S U or its partner Π S U and breaks the session key secrecy or the perfect forward secrecy of the proposed protocol. The probability of A asking the Test SK query in the l-session for Π S U or its partner Π S U is 1/q n , where q n is the total number of sessions. If A successfully guesses b in the Test SK query with advantage δ, which is non-negligible, then B can solve the ECCDH problem with advantage δ/q n , which is also non-negligible. It contradicts the ECCDH assumption. Thus, there is no polynomial time adversary that can break the perfect forward secrecy or the secrecy of the session key of the proposed protocols with a non-negligible advantage.
Proof of Theorem 2. Suppose that there are one trusted third-party registration center (RC), m Server, n natural persons (NP), and d IoT devices in the smart city system, and each entity has a unique identity. Suppose that there is an adversary A, who can forge a member to cheat another member in the proposed CAKE/ACAKE protocol with a non-negligible advantage in probabilistic polynomial time. Then, we can construct a Challenge Algorithm B to solve the DBDH problem with a non-negligible advantage by using A's ability of forging a member. An instance (G 1 , G 2 , P, ê, q, X = xP, Y = yP, Z = zP, g) of the DBDH problem is given to B, and B's goal is to determine if g = ê(P, P) xyz . B guesses that A tends to forge member U to cheat member V and permeates the DBDH problem into the queries. A cannot ask the Corrupt query on U or on V. B manages a time seed list L seed and four hash lists L H1 , L H2 , L h1 , and L h2 , which are empty initially. For each t-time period, B randomly generates a t , r t ∈ R Z q * , computes MPK t = a t ·X, appends (t, a t , MPK t ) to list L seed , and appends ((ID U ||MPK t ), r t , r t ·Y) and ((ID V ||MPK t ), r t , r t ·Z) to list L H1 ; i.e., let H 1 (ID U ||MPK t ) = r t ·Y and H 1 (ID V ||MPK t ) = r t ·Z. Note that MRK t = a t ·x is unknown here. B sets Pub = {q, G 1 , G 2 , P, ê} to be public parameters. B simulates the oracle queries: 1.
The Hash, Reveal, Corrupt, and Test queries are identical to those in the proof of Theorem 1.

2.
Extract (α, M): If α is one of the members, then it returns "Reject". Otherwise, it returns the corresponding registration parameters as follows. B checks the current time period t and list L seed to obtain (t, a t , MPK t ).

3.
Send (Π n B , M): There are three different types of Send query in the proposed protocols: Update, CAKE, and ACAKE. Assume that the current time is in t-time period. B checks list L seed to obtain (t, a t , MPK t ) and responds according to the type of Send query.

4.
Execute (Π m α , Π n β ): B asks the corresponding Sendquery to obtain the result and return it.
B answers with g = ê(P, P) xyz to the DBDH problem if A answers with b = 1 to the Test SK query and answers with g = ê(P, P) xyz if A answers with b = 0. Whether B can successfully solve the DBDH problem depends on whether A asks the Send and Test SK queries on members U and V. The probability of A asking the Send and Test SK queries on member U, whose partner is V, or on member V (whose partner is U) is 2/(m + n + d). If A successfully guesses b in the Test SK query with advantage δ, which is non-negligible, then B can solve the ECCDH problem with advantage 2δ/(m + n + d), which is also non-negligible. It contradicts the DBDH assumption, and thus the proposed protocols achieve existential unforgeability.
Proof of Theorem 3. Suppose that there are one trusted third-party registration center (RC), m Server, n natural persons (NP), and d IoT devices in the smart city system, and each entity has a unique identity. Suppose that there is an adversary A, who has the ability to break the anonymity of NP in the proposed ACAKE protocol with a non-negligible advantage in probabilistic polynomial time. Then, we can construct a Challenge Algorithm B to solve the DBDH problem with a non-negligible advantage by using A's ability of forging a member. An instance (G 1 , G 2 , P, ê, q, X = xP, Y = yP, Z = zP, g) of the DBDH problem is given to B, and B's goal is to determine if g = ê(P, P) xyz . B guesses that A tends to break the anonymity of a natural person, who makes an ACAKE with entity U. B permeates the DBDH problem into the queries. B manages one time seed list L seed and four hash lists L H1 , L H2 , L h1 , and L h , which are empty initially. For each t-time period, B randomly generates a t , r t ∈ R Z q * , computes MPK t = a t ·X, appends (t, a t , MPK t ) to list L seed , and appends ((ID U ||MPK t ), r t , r t ·Y) to list L H1 , i.e., let H 1 (ID U ||MPK t ) = r t ·Y. Note that MRK t = a t ·x is unknown here. B sets public parameters Pub = {q, G 1 , G 2 , P, ê} and simulates the oracle queries: 1.
The Hash, Reveal, Corrupt, and Test queries are identical to those in the proof of Theorem 1, and the Extract query is identical to that in the proof of Theorem 2.

2.
Send (Π n β , M): There are three different types of Send query in the proposed protocols: Update, CAKE, and ACAKE. Assume that the current time is in t-time period. B checks list L seed to obtain (t, a t , MPK t ), asks the Hash H query to obtain H 1 (ID β ||MPK t ), finds ((ID β ||MPK t ), r β , H 1 (ID β ||MPK t )) in L H1 to obtain r β , and responds according to the type of Send query.
B answers with g = ê(P, P) xyz to the DBDH problem if A answers with b = 1 to the Test ID query and answers with g = ê(P, P) xyz if A answers with b = 0. Whether B can successfully solve the DBDH problem depends on whether A asks the Send and Test queries on members U and V. The probability of A asking the Send ACAKE and Test ID queries on any one of the natural members, whose partner is U, is n/(m + n + d). If A successfully guesses b in the Test query with advantage δ, which is non-negligible, then B can solve the ECCDH problem with advantage δn/(m + n + d), which is also non-negligible. It contradicts the DBDH assumption; hence, the proposed protocol achieves existential unforgeability.