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

Abstract

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. Unfortunately, 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 first 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 define 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 Diffie–Hellman (ECCDH) problem, the decisional bilinear Diffie–Hellman (DBDH) problem, and hash function assumptions. Comparisons with the related protocols are conducted to demonstrate the benefits of our protocols. Performance analysis is conducted and the experience results show that the proposed protocols are practical in a smart city.

1. 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.

1.1. 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 management-free. 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.

1.2. 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.

2. 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.

• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• Table-free: No password table or verification list needs to be stored or maintained.
• 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.
• 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.

3. Preliminaries

Here, we introduce physical unclonable functions (PUFs), fuzzy extractors, bilinear pairing, and hard problem assumptions.

3.1. 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.

3.2. 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.

Definition 1. 

Let M be a metric space on N points with distance function dis, and U_l denote the uniform distribution on l-bit binary strings. An (M, δ, l, d, ε) fuzzy extractor is a pair of procedures (Gen, Rep) [29,30].

• Gen is a probabilistic generation procedure, which takes an input R ∈ M and outputs an extracted string SS ∈ {0, 1}^l and a helper string HLP ∈ {0, 1}^*. For any distribution D on M of min-entropy δ, if (SS, HLP) ← Gen(D), we have SD ((SS, HLP), (U_l, HLP)) ≤ ε.
• Rep is a deterministic reproduction procedure that can recover SS from the corresponding helper string HLP and any vector m’ close to m, namely, for all R’, R ∈ M satisfying dis (R’, R) ≤ d, if (SS, HLP) ← Gen(R), then Rep (R’, HLP) = SS.

3.3. Bilinear Pairing

Let E be an elliptic curve over a finite field F_q, which is a field of integers modulo, and a large prime number q, and E(F_q) denote the set of all the points on E. Let G₁ be an additive cyclic subgroup of points on E(F_q), a point P be a generator of G₁, and G₂ be a multiplicative group with the same order q. A bilinear pairing [33,34,35,36] is a map, ê: G₁ × G₁ → G₂, which satisfies the following properties:

• Bilinear: ê(aQ, bR) = ê(Q, R)^ab for all a, b ∈ Z_q^* and all Q, R ∈ G₁.
• Non-degenerate: There are two points Q, R ∈ G₁ such that ê(Q, R) ≠ 1.
• Computability: There is an efficient algorithm to compute ê(Q, R) for all Q, R ∈ G₁.

3.4. Hard Problem Assumptions

Three hard mathematical problems [35,36] used in this paper are listed below.

• Elliptic curve discrete logarithm (ECDL) problem: Given a point aP in G₁, find the integer a.
• Elliptic curve computational Diffie–Hellman (ECCDH) problem: Given P, aP, and bP in G₁, find abP in G₁.
• Decisional bilinear Diffie–Hellman (DBDH) problem: Given P, aP, bP, and cP in G₁ and ê(P, P)^d in G₂, determine whether ê(P, P)^d = ê(P, P)^abc.

Four security assumptions are listed below.

• ECDL assumption: No probabilistic polynomial time (PPT) algorithm can solve the ECDL problem with a non-negligible advantage.
• ECCDH assumption: No PPT algorithm can solve the ECCDH problem with a non-negligible advantage.
• DBDH assumption: No PPT algorithm can solve the DBDH problem with a non-negligible advantage.
• Hash function assumption: There is a one-way and collision-resistant cryptographic hash function H: A → B satisfying the following three conditions:
  • Preimage resistance: For any given b ∈ B, it is hard to find a ∈ A such that H(a) = b.
  • Second preimage resistance: For any given a ∈ A, it is hard to find c ∈ A such that a ≠ c and H(a) = H(c).
  • Collision resistance: It is hard to find a, c ∈ A such that a ≠ c and H(a) = H(c).

4. 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. Notations.

Symbol	Meaning	Symbol	Meaning	Symbol	Meaning
RC	Registration center	MSK	Master secret key	IDα	Identity of member α
NPi	i-th natural person	MRK	Master private key	pwα	Password of member α
Sj	j-th server	MPK	Master public key	Bi	Biometric of NPi
Dl	l-th IoT device	t	Index of time period	SK	Session key
CA/RA	Challenge/response string of PUF function	Gen/Rep	Generation/reproduction procedure of fuzzy extractor	Kα_t	Secret key of member α in t-time period
SSi/HLPi	Secret/helper string	||	Concatenation operation	⊕	XOR operation

.

4.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.

4.2. 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.

4.2.1. 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² = x³ + mx + n, where m, n ∈ F_q satisfy 4 m³ + 27 n² ≠ 0 (mod q). RC produces a bilinear map, ê: G₁ × G₁ → G₂, where G₁ is a subgroup of the additive cyclic group of points on E with order q, and G₂ is a multiplicative cyclic subgroup over F_q with order q. RC picks a generator point P in G₁ and chooses four distinct one-way hash functions, namely, H₁:{0, 1}^* → G₁, H₂:{0, 1}^* → G₁, h₁:{0, 1}^* → {0, 1}^l, and h₂:{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₁(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₁, G₂, P, ê, H₁(), H₂(), h₁(), h₂()}.

4.2.2. 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₂(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₁(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.

4.2.3. 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₁(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₂(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.

4.2.4. 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₁(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₂(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₁(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.

4.2.5. 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., SS_A = Re(B_A, HLP_A), computes RPW_A = H₂(ID_A||pw_A||SS_A) and secret key K_A = Q_A − RPW_A, and outputs K_A.

If A is Server, then A inputs ID_A and pw_A, computes RPW_A = H₂(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₁(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₂(ID_A||SS_A) and secret key K_A = Q_A − RPW_A, and outputs K_A.

4.2.6. 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 ∈ _R Z_q^*, computes N₁ = n·P, R = n·MPK_t, N₂ = h₂(ID_A||t||N₁||R||K_{A_t}), and sends <ID_A, t, N₁, N₂, “Update”> to RC.

Step 2: RC checks the current time period index t*. RC verifies ID_A and computes K_{A_t*} = MRK_t*·H₁(ID_A||MPK_t*), K_{A_t} = MRK_t·H₁(ID_A||MPK_t), R = MRK_t·N₁. RC verifies if N₂ = h₂(ID_A||t||N₁||R||K_{A_t}). If not, it aborts it. Otherwise, it computes U_{A_t*} = K_{A_t*} + H₂(K_{A_t}||R), V_{A_t*} = MPK_t* + H₂(K_{A_t}||N₁), and d_{A_t}= h₂(MPK_t*||K_{A_t*}||K_{A_t}||R) and sends <ID_A, t*, U_{A_t*}, V_{A_t*}, d_{A_t*}> to A.

Step 3: A computes K_{A_t*} =U_{A_t*} − H₂(K_{A_t}||R), MPK_t* = V_{A_t*} − H₂(K_{A_t}||N₁), and Q = Q_A − K_{A_t} + K_{A_t*}. A verifies if d_{A_t*} = h₂(MPK_t*||K_{A_t*}||K_{A_t}||R). If so, then it rewrites Q_i ← Q, t ← t*, and MPK_t ← MPK_t*.

4.2.7. 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), y₁ = n_B·N_A, y₂ = ê(K_{B_t}, H₁(ID_A||MPK_t)), and v_B = h₂(ID_A||ID_B||MPK_t||y₁||y₂). B then sends <ID_B, N_B, v_B> to A.

Step 3: A performs K_{A_t} ← GETKEY(A), computes y₁ = n_A·N_B and y₂ = ê(K_{A_t}, H₁(ID_B||MPK_t)), and verifies if v_B = h₂(ID_A||ID_B||MPK_t||y₁||y₂). If so, then the authority of B is confirmed, and A computes session key SK = h₁(ID_A||ID_B||N_A||N_B||y₁||y₂) and v_A = h₂(ID_A||ID_B||h₂(SK)), and sends <v_A> to B.

Step 4: B computes SK = h₁(ID_A||ID_B||N_A||N_B||y₁||y₂) and verifies if v_A = h₂(ID_A||ID_B||h₂(SK)). If so, then the authority of A is confirmed, and B accepts SK as the session key.

4.3. 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₁(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), TK = ê(N_i, K_{B_t}), ID_i = AID TK, y₁ = n_B·N_i, y₂ = ê(K_{B_t}, H₁(ID_i||MPK_t)), and v_B = h₂(ID_i||ID_B||MPK_t||y₁||y₂). B then sends <N_B, v_B> to NP_i.

Step 3: NP_i performs K_{i_t} GETKEY(NP_i), computes y₁ = n_i·N_B and y₂ = ê(K_{i_t}, H₁(ID_B||MPK_t)), and verifies if v_B = h₂(ID_i||ID_B||MPK_t||y₁||y₂). If so, then the authority of B is confirmed, and NP_i computes session key SK = h₁(ID_i||ID_B||N_i||N_B||y₁||y₂) and v_i = h₂(ID_i||ID_B||h₂(SK)) and sends <v_i> to B.

Step 4: B computes SK = h₁(ID_i||ID_B||N_i||N_B||y₁||y₂) and verifies if v_i = h₂(ID_i||ID_B||h₂(SK)). If so, then the authority of NP_i is confirmed and SK is accepted as the session key.

5. 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.

5.1. Threat Assumptions

Assume that an adversary might have the following attack capabilities in a CAKE/ACAKE protocol.

• AC1: Be an outsider or any one of the legitimate members [8].
• AC2: Eavesdrop, delete, replay, or modify any message transmitted over an untrustworthy channel [8].
• AC3: Offline, try all the (identity, password) pairs within probabilistic polynomial time [37].
• AC4: Steal the smart card and analyze the instruction power consumption to extract the secret data from the smart card [8,38,39].
• AC5: Fake the biometric [40].
• AC6: Correctly predict the PUF’s responses to arbitrary challenges with high probability [41].
• 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.

5.2. 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 ${\mathsf{\Pi }}_{\alpha }^s$ denote the s-session of entity α. ${\mathsf{\Pi }}_{\alpha }^s$ and ${\mathsf{\Pi }}_{\beta }^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).

• 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.
• 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)
• Send (${\mathsf{\Pi }}_{\alpha }^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)
• Execute (${\mathsf{\Pi }}_{\alpha }^s$, ${\mathsf{\Pi }}_{\beta }^t$): B returns the complete transcripts of an honest execution between entity α in its s-session and its partner ${\mathsf{\Pi }}_{\beta }^t$. It models the passive attack. (AC2)
• Reveal (${\mathsf{\Pi }}_{\alpha }^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.
• Corrupt (α): B returns the secret key of α, who is one of the existing members. (AC1) (AC3) (AC4) (AC5) (AC6)
• Test_SK (${\mathsf{\Pi }}_{\alpha }^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 ${\mathsf{\Pi }}_{\alpha }^s$ with its partner ${\mathsf{\Pi }}_{\beta }^t$ is said to be fresh if the common session key SK ≠ NULL between them is confirmed, both Reveal (${\mathsf{\Pi }}_{\alpha }^s$) and Reveal (${\mathsf{\Pi }}_{\beta }^t$) queries have not been asked, and there is no Corrupt (α) or Corrupt (β) query asked before the Send (${\mathsf{\Pi }}_{\alpha }^s$, M) or Send (${\mathsf{\Pi }}_{\beta }^t$, M) query.

A can ask the Test_SK (${\mathsf{\Pi }}_{\alpha }^s$) query only once at any time during the game and may ask other queries when asking the Test_SK (${\mathsf{\Pi }}_{\alpha }^s$) query whenever ${\mathsf{\Pi }}_{\alpha }^s$ is fresh. A outputs its guess b’ for the bit b in the Test_SK (${\mathsf{\Pi }}_{\alpha }^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.

5.3. 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 (${\mathsf{\Pi }}_{\alpha }^s$) query as follows.

• Test_ID (${\mathsf{\Pi }}_{\alpha }^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 (${\mathsf{\Pi }}_{\alpha }^s$) query only once at any time during the game and may ask other queries when asking the Test_ID (${\mathsf{\Pi }}_{\alpha }^s$) query whenever ${\mathsf{\Pi }}_{\alpha }^s$ is fresh. A outputs its guess b’ for the bit b in the Test_ID (${\mathsf{\Pi }}_{\alpha }^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.

• The system is set up according to the initialization and registration phases of the protocol.
• A may ask the following queries and obtain the corresponding results: Test, Hash, Execute, Send, Extract, Corrupt, and Reveal.
• There is no Corrupt (α) or Reveal (${\mathsf{\Pi }}_{\alpha }^s$) query asked before the Test (${\mathsf{\Pi }}_{\alpha }^s$) query.

A may ask other queries when asking the Test (${\mathsf{\Pi }}_{\alpha }^s$) query whenever ${\mathsf{\Pi }}_{\alpha }^s$ is fresh and eventually outputs its guess b’ for the unbiased bit b in the Test (${\mathsf{\Pi }}_{\alpha }^s$) query. The game is terminated.

5.4. 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.

Theorem 2. 

The proposed CAKE and ACAKE protocols achieve existential unforgeability under DBDH and hash function assumptions.

Theorem 3. 

The proposed ACAKE protocol achieves existential anonymity under DBDH and hash function assumptions.

The proofs of Theorems 1, 2, and 3 are presented in Appendix A.

6. 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. Comparisons.

	[11]	[12]	[13]	[14]	[15]	[16]	[17]	[18]	[19]	[20]	[21]	[22]	[23]	[24]	[25]	Our ACAKE
Compatible authentication	N	N	N	N	N	N	N	N	N	N	N	N	N	N	N	Y
Multi-factor authentication a	N	N	N	N	N	N	N	N	N	N	N	Y	Y	Y	Y	Y
Multi-server environment b	N	N	N	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
Independent authentication c	N	Y	Y	N	Y	N	N	Y	Y	Y	Y	Y	N	N	N	Y
User anonymity	Y	Y	Y	Y	Y	Y	Y	N	Y	Y	N	Y	Y	Y	Y	Y
User untraceability/unlinkability	Y	Y	Y	Y	Y	Y	Y	N	Y	N	N	Y	Y	Y	Y	Y
Entity revocation	N	N	N	N	N	N	Y	N	N	Y	Y	N	Y d	N	N	Y

^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.

. 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.

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 GHz device are approximately 2 × 270 ms +3 × 253 ms = 1299 ms, 2 × 92.91 ms + 3 × 44.27 ms = 318.63 ms, 2 × 30.67 ms +3 × 14.62 ms = 105.2 ms, 2 × 6.38 ms +3 × 3.04 ms = 21.88 ms, and 3 × 6.38 ms +4 × 3.04 ms = 31.3 ms, respectively.

The time cost of cryptographic operations of each member is TG_ê + 2TG_mul + 2TG_H + TG_add + 4T_h in the CAKE phase. 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 GHz device are approximately 1 × 290 ms +2 × 270 ms +2 × 253 ms = 1336 ms, 1 × 291.84 ms +2 × 92.91 ms +2 × 44.27 ms = 566.2 ms, 1 × 96.2 ms +2 × 30.67 ms +2 × 14.62 ms = 186.78 ms, and 1 × 20.04 ms +2 × 6.38 ms +2 × 3.04 ms = 38.88 ms, respectively.

In the ACAKE phase, the time costs of cryptographic operations of NP and his/her partner member are 2TG_ê + 3TG_mul + 2TG_H + TG_add + 4T_h and 2TG_ê + 2TG_mul + 2TG_H + TG_add + 4T_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 GHz device are approximately 2 × 290 ms +3 × 270 ms + 2 × 253 ms = 1896 ms, 2 × 291.84 ms + 3 × 92.91 ms + 2 × 44.27 ms = 950.95 ms, 2 × 96.2 ms + 3 × 30.67 ms + 2 × 14.62 ms = 313.65 ms, and 2 × 20.04 ms + 3 × 6.38 ms + 2 × 3.04 ms = 65.3 ms, respectively.

Table 3. Execution times of cryptographic operations (in milliseconds).

	IoT Device	Natural Person		Server	RC
	(36-MHz) [43]	(206-MHz) [44]	(624-MHz) [45]	(3 GHz) [44]
TGê	290	291.84 (estimated)	96.2	20.04
TGmul	270	92.91	30.67	6.38
TH	253 (estimated)	44.27	14.62 (estimated)	3.04
Executing updating	1299	318.63	105.2	21.88	31.3
Executing CAKE	1336	566.2	186.78	38.88	-
Executing ACAKE	1896	950.95	313.65	65.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.

7. 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.