EAP-Based Group Authentication and Key Agreement Protocol for Machine-Type Communications

Abstract

Machine to machine (M2M) communications, also called machine-type communications (MTC), has widely been utilized in applications such as telemetry, industrial, automation, and SCADA systems. The group-based MTC, especially when MTC devices belong to non-3GPP network, will face new challenge of access authentication. In this paper, we propose a group authentication and key agreement protocol, called EG-AKA, for machine-type communications combining elliptic curve Diffie-Hellman (ECDH) based on EAP framework. Compared with conventional EAP-AKA, our protocol guarantees stronger security and provides better performance. Detailed security analysis has shown that the proposed EG-AKA protocol is secure in terms of user and group identity protection and resistance to several attacks. Furthermore, formal verification implemented in AVISPA proves that the proposed protocol is secure against various malicious attacks. Moreover, performance evaluation demonstrates its efficiency in terms of the signaling overhead, the bandwidth consumption, and the transmission cost.

1. Introduction

Machine to machine (M2M) communications [1], which is also defined as machine-type communications (MTC) [2] in release 10 of the 3rd Generation Partnership Project (3GPP), is one of the hottest issues not only in the standardization but also in the industrial circles. In M2M communications, both wireless and wired systems can communicate with other devices of the same ability. Thanks to MTC, many applications become possible [3, 4]. M2M communications uses a device, such as a sensor or meter, to capture an event (such as temperature and inventory level). Then this event is delivered through a wireless, wired, or hybrid network to an application (software program), which translates the captured event into meaningful information. For example, the event can be translated into what items need to be restocked [5]. Since MTC communications does not need direct human intervention, it is soon becoming a market-changing force for the next-generation intelligent real-time networked applications [6, 7].

Recently, most research on MTC has focused on congestion control, resource management, key management [8, 9], and so forth; however, there are few studies on security aspects. Lu et al. [10] point out that the existing challenges of M2M is energy efficiency (green), reliability, and security (GRS). Taleb and Kunz [11] present some potential challenges and solutions of MTC in 3GPP networks. Some security threats and corresponding solutions of 3GPP are discussed in [12]. Privacy preservation is also an important issue in M2M communications [13–15]. A new group message authentication protocol [16], which utilises only limited authenticated communication, combines short authenticated strings protocol with classical key agreement procedures. This SAS-based group authentication and key agreement protocol is secure against active attacks. If mobile terminals of non-3GPP short-distance wireless communication want to access the 3GPP core network, they must execute access authentication. Most access authentication protocols are based on Extensible Authentication Protocol (EAP), such as EAP-AKA [17], EAP-TTLS [18], EAP-PEAP [19], EAP-LEAP [20], and EAP-SPEKE [21]. However, the existing access authentication protocols cannot provide enough security for MTC [22]; on the other hand, present standard has not considered the group-based access authentication. Recently, several standardization organizations start to present the concept and requirement of group authentication, but the mechanism and procedure have not yet been developed.

To the best of our knowledge, the existing network authentication systems are mainly designed for a single object, and they all need 3 or 4 rounds of interaction to realize the mutual authentication between a user and a server. In practical applications, however, there may be a large number of users with the same properties in a network, such as MTC, and user terminals can form a group when they are in the same region, or belong to the same application, or have the same behavior. In these applications, if substantial numbers of user terminals of a group access the network over a short period of time successively, the available authentication methods may suffer from network congestion by the increasing signal of the network. In order to prevent network from congesting and efficiently authenticate user terminals of a group, the concept of group authentication, which performs authentication for group units, is introduced. As a kind of network authentication technology, group authentication aims to authenticate multiple or all users over a shorter period of time. In this technology, the group is assigned a unique identifier, and user terminals are authenticated together as corporate entities. Group authentication can be fulfilled by utilizing the authentication agency or the gateway. After successful group authentication, user terminals and network side entities can share some keys.

In the current literature, a few authentication protocols of group communication have been proposed. An individual and group authentication model, which uses dynamic key cryptography and group key management for individual and group of users and services, is proposed for wireless network services [23]. Chen et al. propose G-AKA protocol for a group of mobile stations roaming from the same home network to a serving network [24]. Aboudagga et al. propose a group authentication protocol for mobile networks and design a new architecture for authentication management and an associated authentication protocol for mobile groups and individual nodes over heterogeneous domains [25]. However, there are still no appropriate group authentication methods for MTC in 3GPP. On the other hand, EAP-AKA [17] is an important authentication and key agreement protocol between 3G/LTE and non-3GPP, but EAP-AKA does not support group authentication mechanism and cannot be applied to group-based MTC. In addition, there are some vulnerabilities in EAP-AKA, such as disclosure of user identity, man-in-the-middle attack [26].

In this paper, in order to resolve group access authentication for MTC, we propose a novel group authentication and key agreement protocol based on Mun's protocol [26], named EG-AKA. Our protocol guarantees stronger security and provides better performance than the existing protocols. The main idea of our protocol is that the first MTC device of a group, which wants to access to 3GPP core network, performs a full AKA authentication procedure. In this process, the first MTC device obtains group authentication information and group temporary key (GTK) on behalf of other MTC devices of the same group. Then the authentication, authorization, and accounting server (AAA server) is enabled to carry out mutual authentication with remaining MTC devices of the group using obtained group authentication information and GTK without interacting with the home subscriber server (the HSS). The authentication delay can be decreased as a whole and the signaling overhead between the AAA server and the HSS is considerably reduced.

The remainder of this paper is organized as follows. In Section 2, we will introduce relevant background and knowledge. In Section 3, we propose our group authentication protocol. In Section 4, the authentication and other secrecy properties are verified by the model checking tools, and detailed performance evaluations are given in Section 5. Finally, we draw our conclusion and give the future work in Section 6.

2. Background

Before going to the details of the proposed protocol, we first recall the elliptic curve Diffie-Hellman technique [27], Mun's Protocol [26], which serves as the basis of the proposed EG-AKA protocol. Then, we present the abbreviations and network architecture used in this paper.

2.1. Elliptic Curve Diffie-Hellman

Elliptic curve cryptography (ECC), which is based on the algebraic structure of elliptic curves over finite fields, is a famous approach used in public-key cryptography. This cryptography was first proposed in 1985 independently by Koblitz [28] and Miller [29]. The primary advantage of ECC is that the key size is smaller while providing the same level of security, which can reduce storage and transmission requirements; that is, an elliptic curve group could provide the same level of security afforded by an RSA-based system with a large modulus and correspondingly larger key. For example, a 160 bit ECC public key should provide comparable security to a 1024 bit RSA public key. Elliptic curve Diffie-Hellman (ECDH) is an anonymous key agreement protocol that allows two parties, each having an elliptic curve public-private key pair, to establish a shared secret over an insecure channel [30]. This shared secret may be directly used as a key, or better yet, to derive another key which can then be used to encrypt subsequent communications using a symmetric key cipher. It is a variant of the Diffie-Hellman protocol using elliptic curve cryptography.

Key establishment protocol of elliptic curve Diffie-Hellman is described briefly as follows. Suppose Alice wants to establish a shared key with Bob, but the channel available for them is not secure and may be eavesdropped by the others. Initially, the domain parameters (i.e., $(p,a,b,G,n,h)$ in the prime case or $(m,f(x),a,b,G,n,h)$ in the binary case) must be agreed upon. Also, each party must have a key pair suitable for elliptic curve cryptography, consisting of a private key d (a randomly selected integer in the interval $[\mathrm{1},n-\mathrm{1}]$ ) and a public key Q (where $Q=dG$ , that is, the result of adding G together d times). Let Alice's key pair be $(d_A,Q_A)$ and Bob's key pair be $(d_B,Q_B)$ . Each party must have the other party's public key (an exchange must occur). Alice computes $(x_k,y_k)=d_A{Q}_B$ . Bob computes $(x_k,y_k)=d_B{Q}_A$ . The shared secret is $x_k$ (the x coordinate of the point). Most standardized protocols based on ECDH derived a symmetric key from $x_k$ using some hash-based key derivation function. The shared secret calculated by both parties is equal, because $d_A{Q}_B=d_A{d}_{B}G=d_B{d}_{A}G=d_B{Q}_A$ . The only information about her private key that Alice initially exposes is her public key. So, no party other than Alice can determine Alice's private key, unless that party can solve the elliptic curve discrete logarithm problem. Bob's private key is similarly secure. No party other than Alice or Bob can compute the shared secret, unless that party can solve the elliptic curve Diffie-Hellman problem [27].

2.2. Mun's Protocol

Mun et al. [26] propose a new authentication and key agreement protocol based on EAP-AKA designed for 3G-WLAN interworking. This protocol combines elliptic curve Diffie-Hellman (ECDH) with symmetric key cryptosystem to overcome several vulnerabilities. In addition, their protocol provides perfect forward secrecy (PFS) to guarantee stronger security, mutual authentication, and resistance to replay attack. The major advantages of their protocol can be summarized as follows:

• (1)

providing strong user identity protection by encrypted IMSI using shared secret key between user equipment and HSS;

(2)

using ECDH to provide perfect forward secrecy between the user equipment and the AAA server;

(3)

resisting against three types of man-in-the middle attack.

Mun's protocol can guarantee stronger security; however, similar to EAP-AKA, the protocol is not suitable for group-based MTC due to lack of specific mechanism. We will modify Mun's protocol to design a novel security enhanced group authentication protocol for MTC.

2.3. Network Architecture

In order to avoid confusing, we list the abbreviations used throughout the rest of this paper in Table 1.

Table 1

Abbreviation used in the paper.

Abbreviation	Definition
3GPP	3rd generation partnership project
3G LTE	3G long term evolution
AAA Server	The authentication, authorization, and accounting server
AKA	Authentication and Key Agreement
AP	Access point
AVISPA	Automated validation of internet security protocols and applications
CN	Core network
EAP	Extensible authentication protocol
ECC	Elliptic curve cryptography
ECDH	Elliptic curve Diffie-Hellman
GAK	Group authentication and key agreement Protocol for MTC
GK	Group Key
GTK	Group temporary key
HSS	Home subscriber server
IMSI	International mobile subscriber identification number
M2M	Machine to machine
MAC	Message authentication code
MSK	Master session key
MTC	Machine-type communications
PFS	Perfect forward secrecy
PID	Permanent identity
PLMN	Public land mobile network

The network architecture mainly consists of four parts: machine-type communication devices, access point, the authentication, authorization, and accounting server, and the home subscriber server, as shown in Figure 1.

Figure 1

Network architecture of MTC.

Machine-Type Communication (MTC) Devices. An MTC device, which communicates through a public land mobile network (PLMN), is a device equipped for machine-type communications.

Access Point (AP). AP is a device that allows wireless devices to connect to a wired network using Wi-Fi, Bluetooth, or other related standards.

The Authentication, Authorization, and Accounting (AAA) Server. In the LTE network, the authentication, authorization, and accounting (AAA) server provides access authentication services for MTC devices on behalf of the 3GPP core network.

The Home Subscriber Server (HSS). In the LTE network, the home subscriber server (HSS) locates in 3GPP core network and provides authentication and management services for MTC devices on behalf of 3GPP core network.

3. The Proposed Group Authentication Protocol

In this section, we give the details of the group authentication and key agreement protocol for MTC (EG-AKA) to facilitate non-3GPP MTC devices to access to 3GPP core network (CN). In order to achieve this aim, there are three phases in the proposed protocol: group initialization, authentication data distribution, and mutual authentication and key agreement.

3.1. Group Initialization

In the group initialization phase, each MTC device has a permanent ID (PID), such as international mobile subscriber identification number (IMSI). This PID is a long-term private identity that identifies MTC device and should be installed in the MTC device by the supplier in order to allow the MTC device to register in a 3GPP network. At the same time, we assume that each MTC device has preshared a secret key with 3GPP CN, and these MTC devices form several groups based on certain principles, and then the supplier provides a group key (GK) to each group for authentication. As shown in Table 2, we create an index table to manage information of MTC devices and group; the index table contains fields of group identity, MTC device identity (PID) for each MTC device, and initial values. Table 3 is the protocol notations used in this paper.

Table 2

Index table.

Group	Group ID	MTC device ID	Initial value
$G1$	${PID}_{G1}$	${PID}_{G1-1}$	${IV}_{G1-1}$
		${PID}_{G1-2}$	${IV}_{G1-2}$
		⋮
		${PID}_{G1-n}$	${IV}_{G1-n}$
$G2$	${PID}_{G2}$	${PID}_{G2-1}$	${IV}_{G2-1}$
		⋮

Table 3

Protocol notation.

Notation	Definition
$MTC{D}_{G\mathrm{1}-\mathrm{1}}$	The first MTC device initiating authentication in group 1
$R_x$	The random number generated by x
$I{D}_x$	The identity of x
$PI{D}_x$	The permanent identity of x
$TI{D}_x$	The temporary identity of x
$K_{x-y}$	The shared secret key between x and y
$G{K}_{Gi}$	The group authentication key of the ith group
$GT{K}_{Gi}$	The group temporary key of the ith group
$f_k^1$	Temporary identity generation function using k
$f_k^2$	MAC generation function using k
$f_k^3$	GTK generation function using k
$f_k^4$	Shared key generation function using k

3.2. Authentication Data Distribution

Let $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ be the first MTC device initiating authentication in group 1. We assume that a secure communication channel between the AAA server and the HSS has already been established and can provide security services to the transmitted data. The authentication data distribution processes as follows.

Step 1.

$MTC{D}_{G\mathrm{1}-\mathrm{1}}$ sends an access request message to the AP.

Step 2.

AP sends an EAP Request/Identity message to require the identity of $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ .

Step 3.

Upon receiving the EAP Request/Identity message sent by AP, firstly, the $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ computes

$$\begin{array}{cc}& TI{D}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}=f_{K_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}-HSS}^{\mathrm{1}}\left(PI{D}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}\right),\end{array}$$

(1)

$$\begin{array}{cc}& TI{D}_{G\mathrm{1}-\mathrm{1}}=f_{K_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}-HSS}^{\mathrm{1}}\left(PI{D}_{G\mathrm{1}}\right),\end{array}$$

(2)

respectively, and then $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ generates $AUT{H}_{G\mathrm{1}}$ as follows:

$$\begin{array}{l}AUT{H}_{G\mathrm{1}}=(TI{D}_{G\mathrm{1}}\parallel TI{D}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}\parallel \\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}{R}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}\parallel MA{C}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}\parallel \\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}I{D}_{HSS}\parallel I{D}_{AAA}\parallel I{D}_{AP}\phantom{TI{D}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}}),\end{array}$$

(3)

where $MA{C}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}$ is calculated as

$$\begin{array}{l}MA{C}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}\\ \hspace{1em}=f_{K_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}-HSS}^{\mathrm{2}}\left(R_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}\parallel I{D}_{AAA}\parallel I{D}_{AP}\right).\end{array}$$

(4)

Step 4.

$MTC{D}_{G\mathrm{1}-\mathrm{1}}$ sends its $AUT{H}_{G\mathrm{1}}$ to the AAA server through AP, and then the AAA server finds out corresponding HSS according $I{D}_{HSS}$ and forwards $AUT{H}_{G\mathrm{1}}$ and its own $I{D}_{AAA}$ to the HSS by authentication data request message.

Step 5.

When the HSS receives authentication data request message containing $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ 's $AUT{H}_{G\mathrm{1}}$ and $I{D}_{AAA}$ , it verifies the received $MA{C}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}$ in $AUT{H}_{G\mathrm{1}}$ .

If verification passes, the HSS derives $PI{D}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}$ and $PI{D}_{G\mathrm{1}}$ from $TI{D}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}$ and $TI{D}_{G\mathrm{1}}$ using $K_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}$ , respectively. Then HSS retrieves the corresponding group key $G{K}_{G\mathrm{1}}$ to generate a group temporary key $GT{K}_{G\mathrm{1}}=f_{G{K}_{G\mathrm{1}}}^{\mathrm{3}}(R_{HSS}\parallel I{D}_{HSS})$ .

Step 6.

At the moment, the HSS also computes all temporary identities of the devices in group 1 and generates a temporary index table (as shown in Table 4) of group 1; then the HSS sends $I{D}_{AP}$ , $GT{K}_{G\mathrm{1}}$ , $R_{HSS}$ , and temporary index table to the AAA server by a preestablish security tunnel.

Table 4

Temporary index table of $G1$ .

Group	Group ID	MTC device ID	Initial value
$G1$	$TI{D}_{G1-1}$	$TI{D}_{MTC{D}_{G1-1}}$	$I{V}_{G1-1}$
		$TI{D}_{MTC{D}_{G1-2}}$	$I{V}_{G1-2}$
		⋮
	$TI{D}_{G1-n}$	$TI{D}_{MTC{D}_{G1-n}}$	$I{V}_{G1-n}$

Step 7.

The AAA server receives and stores $I{D}_{AP}$ , $GT{K}_{G\mathrm{1}}$ , $R_{HSS}$ , and temporary index table for future use.

3.3. Mutual Authentication and Key Agreement

Step 8.

The AAA server generates $R_{AAA}$ and computes $MA{C}_{AAA}$ as follows:

$$\begin{array}{l}MA{C}_{AAA}\\ \hspace{1em}=f_{GT{K}_{G\mathrm{1}}}^{\mathrm{2}}\left(R_{AAA}\parallel R_{HSS}\parallel R_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}\parallel I{V}_{G\mathrm{1}-\mathrm{1}}+i\right),\end{array}$$

(5)

where i represents the ith run of mutual authentication with $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ . After that, the AAA server selects random number a and computes $aP$ on E.

Step 9.

The AAA server generates

$$\begin{array}{cc}& AUT{H}_{AAA}=(MA{C}_{AAA}\parallel R_{AAA}\parallel R_{HSS})\end{array}$$

(6)

and sends $AUT{H}_{AAA}$ and $aP$ to $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ .

Step 10.

After receiving $AUT{H}_{AAA}$ , $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ verifies the received $MA{C}_{AAA}$ in $AUT{H}_{AAA}$ as follows.

• (1)

Firstly, $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ computes

$$\begin{array}{cc}& GT{K}_{G\mathrm{1}}=f_{G{K}_{G\mathrm{1}}}^{\mathrm{3}}\left(R_{HSS}\parallel I{D}_{HSS}\right);\end{array}$$

(7)

(2)

then, $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ computes

$$\begin{array}{l}MA{C}_{AAA}^{\prime }\\ \hspace{1em}=f_{GT{K}_{G\mathrm{1}}}^{\mathrm{2}}\left(R_{AAA}\parallel R_{HSS}\parallel R_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}\parallel I{V}_{G\mathrm{1}-\mathrm{1}}+i\right);\end{array}$$

(8)

(3)

$MTC{D}_{G\mathrm{1}-\mathrm{1}}$ verifies whether $MA{C}_{AAA}^{\prime }$ equals $MA{C}_{AAA}$ or not. If $MA{C}_{AAA}^{\prime }$ is not the same as $MA{C}_{AAA}$ , the HSS or the AAA server is not valid. Therefore, the $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ terminates the procedure.

Step 11.

If verification is successful, $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ computes $bP$ , $K_{MTC{D}_{G\mathrm{1}-\mathrm{1}}-AAA}=f_{GT{K}_{G\mathrm{1}}}^{\mathrm{4}}(abP)$ and $MA{C}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}-AAA}=f_{K_{MTC{D}_{G\mathrm{1}-\mathrm{1}}-AAA}}^{\mathrm{1}}(R_{AAA}\parallel bP)$ .

Step 12.

$MTC{D}_{G\mathrm{1}-\mathrm{1}}$ sends $MA{C}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}-AAA}$ and $bP$ to the AAA server by authentication response message, at the same time, $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ also calculates the MSK as EAP-AKA.

Step 13.

When the AAA server receives $MA{C}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}-AAA}$ and $bP$ , it also computes $K_{MTC{D}_{G\mathrm{1}-\mathrm{1}}-AAA}=f_{GT{K}_{G\mathrm{1}}}^{\mathrm{4}}(abP)$ using $bP$ and verifies $MA{C}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}-AAA}$ . If verification passes, AAA server also calculates the MSK as EAP-AKA.

Step 14.

The AAA server sends $I{D}_{AP}\parallel MSK$ with EAP Success message to the AP.

Step 15.

The AP verifies whether received $I{D}_{AP}$ equals its own ID or not. If the result is incorrect, the AP drops the MSK and then terminates the execution. Otherwise the AP stores the MSK. Then AP encrypts $I{D}_{AP}$ using the MSK and sends it with EAP Success message to $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ .

Step 16.

Through decryption, $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ recovers $I{D}_{AP}$ and verifies whether or not the $I{D}_{AP}$ received from the AP in Step 15 equals to the $I{D}_{AP}$ used in Step 4. If the result is correct, the procedure of authentication and key agreement is successful. Consequently, $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ can securely access to 3GPP CN using the MSK.

At this point, the full authentication and key agreement procedure for one MTC device is completed. The procedure is shown in Figure 2.

When other MTC device in the same group want to access the 3GPP CN, the AAA server performs mutual authentication and key agreement with $MTC{D}_{G\mathrm{1}-\mathrm{2}}$ locally using the existing $GT{K}_{G\mathrm{1}}$ . Taking the MTC device $MTC{D}_{G\mathrm{1}-\mathrm{2}}$ in the same group as an example, the full authentication and key agreement procedure for it is described as follows.

Steps 1 and 2 are similar to $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ s.

Figure 2

Authentication procedure of the first MTC device in our proposed protocol.

Step 3^*. Upon receiving EAP request/identity message by AP, similarly, the $MTC{D}_{G\mathrm{1}-\mathrm{2}}$ computes $TI{D}_{MTC{D}_{G\mathrm{1}-\mathrm{2}}}=f_{K_{MTC{D}_{G\mathrm{1}-\mathrm{2}}}-HSS}^{\mathrm{1}}(PI{D}_{MTC{D}_{G\mathrm{1}-\mathrm{2}}})$ and $TI{D}_{G\mathrm{1}-\mathrm{2}}=f_{K_{MTC{D}_{G\mathrm{1}-\mathrm{2}}}-HSS}^{\mathrm{1}}(PI{D}_{G\mathrm{1}})$ , respectively, and then $MTC{D}_{G\mathrm{1}-\mathrm{2}}$ generates $AUT{H}_{G\mathrm{2}}$ as follows:

$$\begin{array}{l}AUT{H}_{G\mathrm{1}}=(TI{D}_{G\mathrm{1}}\parallel TI{D}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}\parallel \\ \hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{0.17em}\hspace{1em}{R}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}\parallel MA{C}_{MTC{D}_{G\mathrm{1}-\mathrm{1}}}\parallel I{D}_{AAA}),\end{array}$$

(9)

where $MA{C}_{MTC{D}_{G\mathrm{1}-\mathrm{2}}}$ is calculated as

$$\begin{array}{l}MA{C}_{MTC{D}_{G\mathrm{1}-\mathrm{2}}}\\ \hspace{1em}\hspace{1em}=f_{K_{MTC{D}_{G\mathrm{1}-\mathrm{2}}}-HSS}^{\mathrm{2}}\left(R_{MTC{D}_{G\mathrm{1}-\mathrm{2}}}\parallel I{D}_{AAA}\parallel I{D}_{AP}\right).\end{array}$$

(10)

Step 4^*. $MTC{D}_{G\mathrm{1}-\mathrm{2}}$ sends its $AUT{H}_{G\mathrm{1}}$ to the AAA server through AP. Note that, the AAA server does not need to authenticate the group (G1) which $MTC{D}_{G\mathrm{1}-\mathrm{2}}$ belongs to by the HSSs assistance.

Step 5^*. The AAA server begins to perform mutual authentication with $MTC{D}_{G\mathrm{1}-\mathrm{2}}$ using the temporary index table (Table 4) and $GT{K}_{G\mathrm{1}}$ received in Step 6.

The remaining steps are similar to $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ s.

The other MTC devices perform the authentication and key agreement procedures similar to $MTC{D}_{G\mathrm{1}-\mathrm{2}}$ s until all devices complete the authentication.

4. Security Analysis

In this section, both security analysis and formal verification implemented by the AVISPA tool are conducted to show that the proposed protocol can work correctly to achieve security properties.

4.1. Security Property

In Table 5, we compare our proposed EG-AKA protocol with the other main AKA protocols: Mun's protocol [26], EAP-AKA [17], EAP-TTLS [18], EAP-PEAP [19], EAP-LEAP [20], and EAP-SPEKE [21]. The comparison results demonstrate that our protocol can provide the most comprehensive security performance compared to the other AKA protocols. Providing group access authentication and heterogeneous network access are the two main advantages of our protocol. In particularly, our proposed protocol meets the following security properties.

Table 5

Comparisons of properties among the EAP-based AKA protocols.

	Our proposed EG-AKA	Mun's protocol [26]	EAP-AKA [17]	EAP-TTLS [18]	EAP-PEAP [19]	EAP-LEAP [20]	EAP-SPEKE [21]
Type of cryptosystem	Symmetric and ECDH	Symmetric and ECDH	Symmetric	Public	Public	Public	Public
Computational overhead	Smaller	Smaller	Smallest	Large	Large	Large	Large
Protection of user identity	Yes	Yes	No	Yes	Yes	No	No
Heterogeneous network access	Yes	Yes	Yes	No	No	No	No
Secure against man-in-the middle attack	Yes	Yes	No	Yes	Yes	Yes	Yes
Secure against replay attack	Yes	Yes	Yes	Yes	Yes	Yes	Yes
PFS	Yes	Yes	Yes	Yes	No	No	No
Support group authentication	Yes	No	No	No	No	No	No

Protect User and Group Permanent Identity. In our protocol, PID cannot be got by attackers. The reason is that the MTC device generates the TID by using the $K_{MTC{D}_{Gi-j}}$ and then sends TID to the HSS. Therefore, the MTC device and the HSS can only retrieve user and group permanent identity included in TID through using $K_{MTC{D}_{Gi-j}}$ . Thus, our protocol provides strong user and group identity protection.

Secure against Man-in-the Middle Attack. In our proposed protocol, only the MTC devices and HSS can obtain real ID information of the devices and the group from encrypted temporary ID information. An attacker cannot derive and modify this information. The AP receives the EAP Success message with $I{D}_{AP}\parallel MSK$ sent by the AAA server. After that, the AP can verify whether its own ID equal to the received ID or not. If not the procedure of authentication and key agreement will fail. Furthermore, the AP will send $I{D}_{AP}$ encrypted by $MSK$ to the MTC device. The MTC device can verify whether it has accessed this AP or not. The MTC device can verity the legality of HSS by $MA{C}_{AAA}$ as well. Thus, our protocol can resist against several types of man-in-the middle attack.

Secure against Replay Attack. In our protocol, random numbers $R_{MTC{D}_{Gi-j}}$ generated by $MTC{D}_{Gi-j}$ , $R_{HSS}$ generated by the HSS and $R_{AAA}$ generated by the AAA server are temporarily used in generating challenge messages toward the opposite side, respectively. Since these random numbers used in each authentication procedure are different, even if an attacker acquires a random number in a authentication procedure, he still cannot fake challenge messages by reusing the random number in a new authentication procedure. Meanwhile, these two sites maintain an identical initial value $I{V}_{Gi-j}$ to keep themselves synchronized throughout AKA processing. An out-of-sync initialization value will lead to authentication failure. Thus a node without the required random numbers and initial value cannot perform a replay attack on our system.

Resistance to Impersonate Attack. Note that, in our protocol, all the MTC devices of a group share a common GTK. If an MTC device, without loss of generality, suppose that $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ intends to impersonate another MTC device in the same group, for example, $MTC{D}_{G\mathrm{1}-j}$ . $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ may eavesdrop traffic between $MTC{D}_{G\mathrm{1}-j}$ and the HSS, but $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ cannot generate unique $R_{G\mathrm{1}-j}$ and $I{V}_{G\mathrm{1}-j}$ . Therefore, $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ cannot generate a correct $MA{C}_{MTC{D}_{G\mathrm{1}-j}-AAA}$ to impersonate $MTC{D}_{G\mathrm{1}-j}$ to perform a successful authentication with the HSS. Similarly, $MTC{D}_{G\mathrm{1}-\mathrm{1}}$ cannot get the $K_{MTC{D}_{G\mathrm{1}-j}-AAA}$ between $MTC{D}_{G\mathrm{1}-j}$ and the AAA server. Therefore, it cannot decrypt traffic between $MTC{D}_{G\mathrm{1}-j}$ and the AAA server. In summary, the 3GPP CN can easily distinguish one MTC device from another even though all MTC devices use the same GTK; at the same time, one MTC device cannot decrypt traffic between any other MTC device and the 3GPP CN.

Perfect Forward Secrecy (PFS). Our protocol utilizes ECDH to provide PFS between the MTC device and the AAA server. While generating $K_{MTC{D}_{Gi-j}-AAA}$ , our protocol uses $aP$ and $bP$ that are not related with $K_{MTC{D}_{Gi-j}-HSS}$ . Therefore, if disclosure of $K_{MTC{D}_{Gi-j}-HSS}$ occurs, attackers cannot get $K_{MTC{D}_{Gi-j}-AAA}$ . In other words, guessing $K_{MTC{D}_{Gi-j}-AAA}$ is a computationally difficult problem.

Provide Mutual Authentication and Key Agreement. We can verify that the proposed protocol can provide a successful mutual authentication between MTC devices and the 3GPP CN by formal verification described in the Section 4.2. Key agreement includes two parts: (a) between the MTC device and the AAA server: the key agreement between the MTC device and the AAA server can achieve through ECDH with symmetric key, and the MTC device and the AAA server can share a secret key $K_{MTC{D}_{Gi-j}-AAA}$ by Steps 11–13; (b) between the MTC device and the AP: the key agreement between the MTC device and the AP is the same as EAP-AKA [7], and the MTC device and AP can securely communicate with other by the MSK.

4.2. Formal Verification

The primary goal of our proposed protocol is to provide mutual authentication and key agreement services between MTC devices and the 3GPP CN. We tested our protocol using formal security verification tool known as the “Automated Validation of Internet Security Protocols and Applications” (AVISPA) [31]. The AVISPA project aims at developing a push-button, industrial-strength technology for the analysis of large-scale Internet security-sensitive protocols and applications. This technology will speed up the development of the next generation of network protocols, improve their security, and therefore increase the public acceptance of advanced, distributed IT applications based on them. AVISPA will achieve this by advancing specification and deduction technology to the point where industry protocols can be specified and automatically analyzed. A central aim of the project is then to integrate this technology into a robust automated tool, tuned on practical, large-scale problems, and migrated to standardization bodies, whose protocol designers are in dire need of such tools. In the AVISPA tool, protocols are specified using the High Level Protocol Specification Language (HLPSL for short). Then, the HLPSL specification is translated into an Intermediate Format which is used by the various verification tools embedded in AVISPA. We use On-the-fly-Model-Checker (OFMC) and SAT-based model checker (SATMC) to text our EG-AKA protocol. The authentication goals that we need to verify are shown in Figure 3. The output of the model checking results are shown in Figures 4 and 5. We can conclude that the proposed protocol can accomplish the goal of mutual authentication, and it can resist those malicious attacks such as replay attacks, MitM attacks, and secrecy attacks under the test of AVISPA using the OFMC back-end and SATMC back-end.

Figure 3

Analysis goals of the model.

Figure 4

Results reported by the OFMC back-end.

Figure 5

Results reported by the SATMC back-end.

5. Performance Evaluation

In this section, we give a detailed performance evaluation of the proposed protocol from the signaling overhead and the transmission cost point of view.

5.1. Signaling Overhead

In order to evaluate the signaling overhead, we consider the following scenario: the number of MTC device is n, and the number of group is m. Suppose that each MTC device launches x (re)authentications. For EAP-AKA, authentication procedures performed by an MTC device require the total number of signaling messages which grows linearly with x. In EAP-AKA protocol, there are 12 signaling messages for one complete authentication procedure. Thus, the number of signaling message of a MTC device is $\mathrm{12}x$ and the total number of signal message is $\mathrm{12}nx$ . In Mun's protocol, the MTC device runs a full authentication using 8 messages at one time, a total of $\mathrm{8}x$ messages is required. Similarly, when n MTC devices belonging to m group perform authentication, there are a total of $\mathrm{12}nx$ messages for EAP-AKA, and a total of $\mathrm{8}nx$ messages for Mun's protocol. In the proposed protocol, the first MTC device initiating authentication in the group complete the whole procedure of authentication and the number of signaling message is 8. The rest devices of the group only need 6 signaling messages. In this scenario, the number of the rest devices is $n-m$ and the total number of signaling message is $\mathrm{8}m+\mathrm{6}(n-m)$ . If each device executes another $x-\mathrm{1}$ re-authentications, then the total number of signaling message is $\mathrm{8}m+\mathrm{6}(n-m)+\mathrm{6}n(x-\mathrm{1})$ . Figure 6 illustrates the number of signaling messages of the proposed procedure over the existing authentication protocols for several different cases. It can be seen that signaling messages of several AKA protocols are increasing as the number of MTC devices increases. Among three AKA protocols, our EG-AKA outperforms other protocols. This is because our protocol shifts the impact of the number of MTC devices on network to the impact of that of the number of MTC device groups on network; our EG-AKA can reduce both authentication delay and signaling overhead within the core network.

Figure 6

Comparison of the number of signaling messages of several EAP-based protocols.

5.2. Bandwidth Consumption

In order to analyze the bandwidth consumption, we assume that x AVs are transmitted every time the HSS successfully authenticates one ME, and there are n MTCDs forming m group. Without loss of generality, Table 6 shows the setting of parameters for evaluating bandwidth consumption.

Table 6

Setting of parameters.

Parameters	Value (bits)
ID/TID	128
GTK	128
MAC	64
Random number (RN)	128
ECDH key	192
Timestamp	32

The bandwidth consumption of AKA protocols are as follows, where $b{w}_{first}$ represents the bandwidth consumption of the authentication of the first MTCD.

• (1)

Bandwidth analysis of EAP-AKA: the sizes of authentication messages are calculated as follows:

$$\begin{array}{cc}& b{w}_{first}=\sum _{i=\mathrm{1}}^{\mathrm{5}}‍\left|{Message}_i\right|=\mathrm{704}+\mathrm{608}x\hspace{0.17em}\text{bits}.\end{array}$$

(11)

 

The overall bandwidth consumption for n devices is calculated as $n\times (\mathrm{704}+\mathrm{608}x)$ .

(2)

Bandwidth analysis of Mun's scheme: the sizes of authentication messages are calculated as follows:

$$\begin{array}{cc}& b{w}_{first}=\sum _{i=\mathrm{1}}^{\mathrm{7}}‍\left|Messag{e}_i\right|=\mathrm{2432}\hspace{0.17em}\text{bits}.\end{array}$$

(12)

• (i)

${Message}_{\mathrm{1}}=\mathrm{2}|ID|+|Timestamp|+|MAC|=\mathrm{352}\hspace{0.17em}\text{bits}$ .

(ii)

${Message}_{\mathrm{2}}=\mathrm{2}|ID|+|Timestamp|+|MAC|=\mathrm{352}\hspace{0.17em}\text{bits}$ .

(iii)

${Message}_{\mathrm{3}}=|RN|+|MAC|+|TK|+|ID|=\mathrm{448}\hspace{0.17em}\text{bits}$ .

(iv)

${Message}_{\mathrm{4}}=\mathrm{2}|RN|+|MAC|+|ECDH\mathrm{\hspace{0.17em}\hspace{0.17em}}key|=\mathrm{512}\hspace{0.17em}\text{bits}$ .

(v)

${Message}_{\mathrm{5}}=|ID|+|ECDH\hspace{0.17em}\hspace{0.17em}key|=\mathrm{256}\hspace{0.17em}\text{bits}$ .

(vi)

${Message}_{\mathrm{6}}=|ID|+|MSK|=\mathrm{256}\hspace{0.17em}\text{bits}$ .

(vii)

$Messag{e}_{\mathrm{7}}=|ID|+|MSK|=\mathrm{256}\hspace{0.17em}\text{bits}$ .

 

The overall bandwidth consumption for n devices is calculated as $n\times \mathrm{2432}$ .

(3)

Bandwidth analysis of EG-AKA: the sizes of authentication messages are calculated as follows:

$$\begin{array}{cc}& b{w}_{first}=\sum _{i=\mathrm{1}}^{\mathrm{6}}‍\left|{Message}_i\right|=\mathrm{2688}\hspace{0.17em}\text{bits}.\end{array}$$

(13)

• (i)

${Message}_{\mathrm{1}}=\mathrm{3}|ID|+|RN|+|MAC|=\mathrm{576}\hspace{0.17em}\text{bits}$ .

(ii)

${Message}_{\mathrm{2}}=\mathrm{4}|ID|+|RN|+|MAC|=\mathrm{704}\hspace{0.17em}\text{bits}$ .

(iii)

${Message}_{\mathrm{3}}=|RN|+|GTK|+|ID|=\mathrm{384}\hspace{0.17em}\text{bits}$ .

(iv)

$Messag{e}_{\mathrm{4}}=\mathrm{2}|RN|+|MAC|+|ECDH\mathrm{\hspace{0.17em}\hspace{0.17em}}key|=\mathrm{512}\hspace{0.17em}\text{bits}$ .

(v)

${Message}_{\mathrm{5}}=|MAC|+|ECDH\mathrm{\hspace{0.17em}\hspace{0.17em}}key|=\mathrm{256}\hspace{0.17em}\text{bits}$ .

(vi)

${Message}_{\mathrm{6}}=|ID|+|MSK|=\mathrm{256}\hspace{0.17em}\text{bits}$ .

 

Consider

$$\begin{array}{cc}& b{w}_{remaining}=\sum _{i=\mathrm{1}}^{\mathrm{3}}‍\left|{Message}_i\right|=\mathrm{1024}\hspace{0.17em}\text{bits},\end{array}$$

(14)

 

where $b{w}_{remaining}$ represents the bandwidth consumption of authentication of each remaining ME.

• (i)

${Message}_{\mathrm{1}}=\mathrm{2}|RN|+|MAC|+|ECDH\hspace{0.17em}\hspace{0.17em}key|=\mathrm{512}\hspace{0.17em}\text{bits}$ .

(ii)

${Message}_{\mathrm{2}}=|MAC|+|ECDH\mathrm{\hspace{0.17em}\hspace{0.17em}}key|=\mathrm{256}\hspace{0.17em}\text{bits}$ .

(iii)

${Message}_{\mathrm{3}}=|ID|+|MSK|=\mathrm{256}\hspace{0.17em}\text{bits}$ .

The overall bandwidth consumption for n devices is calculated as $m*\mathrm{2688}+(n-m)\times \mathrm{1024}$ .

Figure 7 shows the bandwidth consumption of several AKA protocols, when the number of the MEs is different. From Figures 7(a) to 7(d), we can see that the bandwidth consumption of our EG-AKA protocol is much better than that of EPS-AKA and Mun's scheme. Meanwhile, our EG-AKA protocol can provide much better security compared to the other protocols.

Figure 7

Comparison of the bandwidth consumption of several EAP-based protocols.

5.3. Transmission Cost

In order to evaluate the transmission cost, assume that energy dissipated during 1-message transmission between MTC device and HSS is $\mathrm{1}$ unit, the energy dissipated during 1-message transmission between MTC device and AAA server is a unit ( $a<\mathrm{1}$ ), and energy dissipated during 1-message transmission between AAA server and HSS is b unit ( $b<\mathrm{1}$ ). Assume that the number of devices in a group is y.

Since the other EAP-AKA based protocols only enhance the security aspect and the procedure of signaling mode is the same as the traditional EAP-AKA protocol, we only compare our proposed protocol with the traditional EAP-AKA protocol. We consider the following two case as shown in Figure 2 in our proposed protocol:

• (a)

the AAA server has to fetch the fresh authentication vector form the HSS;

(b)

the AAA server already has the fresh authentication vector.

In case (a), there are 4 messages between the MTC device and the AAA server, and there are 2 messages between the AAA server and HSS during one authentication procedure. The communication cost of our proposed protocol in this case is

$$\begin{array}{cc}& C_{prop\mathrm{1}}=(\mathrm{4}a+\mathrm{2}b)+(y-\mathrm{1})\times \mathrm{4}a.\end{array}$$

(15)

In case (b), since the AAA server already has the fresh authentication vector, it does not need to communicate with the HSS anymore. Thus, the communication cost of our proposed protocol in this case is

$$\begin{array}{cc}& C_{prop\mathrm{2}}=\mathrm{4}ay.\end{array}$$

(16)

Similarly, in the EAP-AKA protocol, there are 8 messages between the MTC device and the AAA server, and there are 2 messages between the AAA server and HSS during one authentication procedure. Therefore, the communication cost of the EAP-AKA protocol in case (a) is

$$\begin{array}{cc}& C_{EAP-AKA\mathrm{1}}=\left(\mathrm{8}a+\mathrm{2}b\right)y\end{array}$$

(17)

and in case (b) is

$$\begin{array}{cc}& C_{EAP-AKA\mathrm{2}}=\mathrm{8}ay.\end{array}$$

(18)

Suppose that the AAA server fetches n authentication vectors during the authentication procedure. The average communication cost of the proposed protocol is

$$\begin{array}{l}{C}_{prop}=\frac{\mathrm{1}}{n}{C}_{prop\mathrm{1}}+\frac{n-\mathrm{1}}{n}{C}_{prop\mathrm{2}}\\ \hspace{1em}\hspace{1em}=\frac{\mathrm{4}any+\mathrm{2}b}{n}.\end{array}$$

(19)

The average communication cost of the EAP-AKA protocol is

$$\begin{array}{cc}& C_{EAP-AKA}=\frac{\mathrm{1}}{n}{C}_{EAP-AKA\mathrm{1}}+\frac{n-\mathrm{1}}{n}{C}_{EAP-AKA\mathrm{2}}\\ =\frac{\mathrm{8}any+\mathrm{2}by}{n}.\end{array}$$

(20)

We define a improvement rate $IF$ to evaluate the improvement of our proposed protocol compared to the EAP-AKA protocol. The definition of improvement rate $IR$ is:

$$\begin{array}{cc}& IR=\frac{C_{EAP-AKA}-C_{prop}}{C_{EAP-AKA}}=\frac{\mathrm{4}any+\mathrm{2}by-\mathrm{2}b}{\mathrm{8}any+\mathrm{2}by}.\end{array}$$

(21)

From the definition of $IR$ , we know that the bigger the $IR$ is, the smaller the transmission cost of our proposed protocol is. Figure 8 plots the improvement rate $IR$ varying with the number of devices, the number of fetched authentication vectors, and the energy dissipated during 1-message transmission between the MTC device and AAA server. From the figures, we can easily see that the more the number of MTC devices in the group is, the bigger the $IR$ is. The reason is that in our proposed protocol we only need one communication between the AAA server and the HSS for the whole group authentication. While in the EAP-AKA protocol each MTC device has to execute a complete authentication. Furthermore, the more number of authentication vector the AAA server fetches from the HSS, the bigger the $IR$ is. The reason is that our proposed protocol only needs one authentication vector for the whole group. The communication cost can be reduced dramatically.

Figure 8

Comparison of the $IR$ .

6. Conclusion and Future Work

In this paper, we propose a group authentication and key agreement protocol for MTC device under the EAP framework, named EG-AKA. To the best of our knowledge, there is no protocol in the current literature that handles specific group access authentication for non-3GPP MTC. The proposed EG-AKA protocol not only enhances security on the basis of Mun's protocol, but also design specific group authentication mechanism for MTC. Formal verification and security analysis show that the proposed protocol is secure and fulfill its design goals. Detailed evaluations of performance illustrate that the proposed protocol achieves better performance in terms of transmission and signaling overhead compared with several existing protocols. In our future work, we will consider more practical group authentication protocol based on symmetric cryptography for resource-constrained devices in heterogeneous networks.