Hierarchical Group Based Mutual Authentication and Key Agreement for Machine Type Communication in LTE and Future 5 G Networks

In view of the exponential growth in the volume of wireless data communication among heterogeneous devices ranging from smart phones to tiny sensors across a wide range of applications, 3GPP LTE-A has standardized Machine Type Communication (MTC) which allows communication between entities without any human intervention. The future 5G cellular networks also envisage massive deployment of MTCDevices (MTCDs) which will increase the total number of connected devices hundredfold.This poses a huge challenge to the traditional cellular system processes, especially the traditional Mutual Authentication and Key Agreement (AKA) mechanism currently used in LTE systems, as the signaling load caused by the increasingly large number of devices may have an adverse effect on the regular Human to Human (H2H) traffic. A solution in the literature has been the use of group based architecture which, while addressing the authentication traffic, has their share of issues. This paper introduces Hierarchical Group based Mutual Authentication and Key Agreement (HGMAKA) protocol to address those issues and also enables the small cell heterogeneous architecture in line with 5G networks to support MTC services. The aggregate Message Authentication Code based approach has been shown to be lightweight and significantly efficient in terms of resource usage compared to the existing protocols, while being robust to authentication message failures, and scalable to heterogeneous network architectures.


Introduction
The market for cellular data is growing at a tremendous pace with the birth of a new generation of cellular system at almost every decade.This has been largely triggered by the explosive growth in mobile traffic coupled with advancements in wireless communication technologies.As per the Cisco Visual Networking Index 2014-19 [1], machine to machine (M2M) also termed as Machine Type Communication (MTC) connections are expected to grow to 10.5 billion by 2019.M2M or MTC communication refers to communication between entities without any human intervention, intended to support applications like home automation, security and surveillance, healthcare, traffic management, and many others.The communicating entities are termed Machine Type Communication Devices (MTCDs).Standardization organizations, like Third Generation Partnership Project (3GPP), European Telecommunications Standards Organization (ETSI), and so forth, have already come up with standards on MTC architecture and security architecture under 3GPP Long Term Evolution Advanced (LTE-A) [2].Under the 7th Framework Programme for Research (7FP) [3], the European Union has initiated several programs to promote research in technologies to build wired and wireless communication networks of the future.A key project, Mobile and wireless communication Enablers for Twenty-twenty Information Society (METIS) [4], the flagship program of the European Union on Fifth Generation Cellular Network (5G), has attempted to prepare the groundwork for 5G network before any standardization activities are carried out.The scenarios and use cases analyzed by METIS [5] indicate a massive deployment of MTCDs in future cellular networks.The existing cellular network is ill-equipped to handle the surge in traffic from such massive MTC deployment.The traffic generated from the authentication procedure, executed for security reasons by each MTCD before they can attach to the network, becomes a serious concern in such scenarios.A sizable number of MTCDs trying to attach to the network simultaneously with each having to undergo the Mutual Authentication and Key Agreement (AKA) procedure result in massive signaling overload at both access network and core network.
The existing literature on MTC authentication has tried to find different approaches to reduce the signaling traffic needed for the AKA procedure by grouping the MTCDs based on different criteria like belonging to the same application, appearing in the same location, and so forth.The schemes exploiting the group based approach use one of the following methods for reducing the AKA signaling load: (1) First MTCD performs a full AKA with the core network and also authenticates the group by fetching the authentication data for the entire group to the serving network; the rest of the group members authenticates locally at the serving network using the prefetched authentication data.
(2) Each MTCD sends its authentication message to a MTCD selected from among the group to be a group leader who in turn aggregates the same and transmits it to the core network.
The main drawback of the first approach is that while it reduces the signaling load between the home network and the serving network, the load at the access network remains unchanged.The latter approach successfully reduces the load at the access network but a single corrupt authentication message in the aggregate will result in the rejection of the authentication of the entire group.Furthermore, the group leader based approach also includes the complexity and consequent delay of group leader selection and, in the event of group leader failure/exit, reselection of the new incumbent.Hence, a natural corollary to these contributions would be one that addresses these limitations.
In this paper, the authors propose the Hierarchical Group based Mutual Authentication and Key Agreement (HGMAKA) protocol for MTC which will be suitable for both current LTE-A and future 5G networks.The main contributions of this paper are the following: (1) Introduction of a hierarchical approach, as against the existing first MTCD based or group leader based approach, for implementation of group based AKA between a group of MTCDs and the Core Network.
(2) Adoption of hierarchical small cell architecture, in line with 5G architecture, for reduction in signaling load due to authentication as against macrocell architecture in existing literature.
(3) Introduction of en route integrity verification of authentication messages to avoid batch reauthentication due to failures.
(4) Performance comparison with ten other group based schemes in the literature.
The proposed group based hierarchical protocol uses the support of network elements instead of a group leader, thereby eliminating the additional complexity related to group leader management.In view of resource constrained devices used in most M2M applications, it uses the lightweight symmetric key based aggregate Message Authentication Code (MAC) approach with integrity verification of authentication messages at each level of the hierarchy.This eliminates the chance of group authentication failure at the core network which can otherwise be caused, in the existing group based schemes using aggregate MAC, by even a single corrupt MAC appearing in the aggregate authentication message.
Furthermore, the use of small cells helps in offloading traffic from the macrocells to small cells resulting in further reduction in signaling load at the access network level.This is also in line with the architectures of future cellular networks as proposed by several projects like METIS, iJOIN [6], TRO-PIC [7], and so forth advocating the use of small cells.Depending on applications, MTCDs may be deployed in low coverage areas like underground parking or remote inaccessible locations where connectivity to cellular networks may not be feasible.The proposed HGMAKA scheme takes into consideration such cases through the use of small cells and capillary network of devices.Being hierarchical in nature, it allows larger group sizes through multilevel aggregation resulting in lesser number of groups for a given number of MTCDs.Moreover, highly mobile MTCDs like those in public vehicles will need frequent handovers resulting in high overhead.The proposed protocol uses mobile femtocells to address this issue.
The rest of the paper is organized as follows: Section 2 provides an overview of MTC under LTE-A, the mutual AKA protocol, and the importance of heterogeneous cellular network architecture; Section 3 spells out the motivation behind the proposed protocol; Section 4 reviews some related works from the literature on group based mutual AKA protocols and highlights the issues therein; Sections 5 and 6 present the proposed system architecture along with the proposed protocol; Section 7 presents the security analysis of the protocol; Section 8 provides performance analysis of the proposed protocol vis-à-vis existing group based protocols; and Section 9 concludes the paper.

Machine Type Communication and Small
Cell Architecture In case of indoor traffic, a smaller and less powerful base station, named Home eNodeB (HeNB) [9], can be used, which improves the coverage in indoor locations with higher data rates.The HeNB is a small, less expensive base station that is located at the customer site and connects to the EPC via the customer's existing broadband access line like DSL or broadband cable.Multiple HeNBs can be managed by an optional element of the EPC called the Home eNodeB Gateway (HeNB-GW).It multiplexes connections from multiple HeNBs into a single stream in order to alleviate the load on the MME.The HeNB-GW is transparent to the MME as well as to the HeNBs.Figure 1 gives the network architecture of LTE.
A Mutual Authentication and Key Agreement procedure is carried out between the MME/AAA/ePGD and the MTCD.The authentication procedure used is the Evolved Packet System-Authentication and Key Agreement (EPS-AKA) [10] for 3GPP and Extensible Authentication Protocol-AKA (EAP-AKA) [11] for non-3GPP networks.On successful completion of the authentication procedure, both parties share a secret session key to be used for confidentiality and integrity protection or for deriving next level keys to be used for the same purpose.Figure 2 shows the steps involved in the EPS-AKA protocol.

Small Cell Architecture and HetNets.
As mentioned in the previous section, the growing number of MTC connection is a concern for the current cellular network which will face tremendous challenges in providing the desired level of user satisfaction to both M2M and Human to Human (H2H) communications.One of the possible approaches to handle hyper densification of cells is to offload traffic into smaller cells served by low powered base stations like micro and pico eNodeBs (eNB), Home eNodeBs (HeNB), Relay Nodes (RN), and even Remote Radio Heads (RRH) (radio elements which have a wired connection to an existing macro eNB).As the deployment of additional macrocells is not practically possible due to paucity of space and prohibitive costs, a network of macro as well as small cells, termed as Heterogeneous Network or HetNet [12], will assist in a long way in handling the massive numbers of users.Small cells bring in the advantages of load balancing between cells, improved coverage leading to improved user satisfaction, and reduced latency and lower power consumption as the base stations are closer to the users.A HetNet in LTE-A can consist of macrocells, microcells, picocells, and femtocell, in the decreasing order of the base station power.While femtocells cater to only indoor traffic, the others mostly cater to outdoor traffic.Another small cell termed mobile femtocell (MFemtocell) [13] combines the concepts of femtocell with mobile relay.It consists of dedicated relay nodes mounted outside public vehicles like buses, trains, and so forth.The users inside the vehicle form a femtocell which uses the mobile relay node to communicate with the macro base station.The base station views the MFemtocell and all its users as a single entity and at the same time, the users are unaware of the existence of the mobile relay node.The deployment of MFemtocell will prove to be beneficial for high mobility scenarios and also improve network coverage.
In addition to the above which operate in the licensed spectrum, the network can also incorporate Capillary Networks of MTCDs where the devices also use some local communication technologies like Bluetooth, ZigBee, WiFi, and so forth in the unlicensed spectrum.The devices in the network communicate with MTC Servers via a MTC Gateway Device that acts as the intermediary between the cellular network and the capillary network of devices.The MTC Gateway Device is equipped with dual communication capabilities like cellular and some local access technology [14].
The small cells have their share of challenges to overcome.These include cost effective deployment and efficient operation and management of small cells by operators, intercell interference management, technologies for backhauling traffic from small cells to core networks, security, and many more.The authors in [15] have listed some of the issues related to use of capillary M2M networks, which includes interference and low data rates for applications with high end-to-end reliability requirement.
Considering the fact that small cells are expected to be an integral component of future mobile cellular networks, the proposed hierarchical group based authentication protocol uses an architecture which brings together a macrocells network with an overlay of small cells and capillary networks.

Motivation
While MTC applications span across a wide domain, each with distinct features and requirements, the common feature distinguishing them from the regular H2H communication is the presence of massive number of devices.As these devices have to execute EPS-AKA to connect to the EPC for access authentication, a large number of these trying to connect at the same time will create substantial signaling overload in the access network.In a roaming scenario, where the devices are away from their home network (HN), the serving network (SN) will have to fetch the authentication data from the HN leading to an increased signaling load.Consequently  Agreement protocols for MTC aimed at minimizing the signaling overhead.
In addition, the MTCDs are usually low powered devices lacking high computational capabilities.This calls for an authentication protocol of lower computational complexity.Furthermore, an additional issue with cellular MTC is the presence of the devices at cell edges and in indoor spaces like inside underground parking lots, shopping malls, hospitals, and so forth, where network connectivity may be poor.Likewise, some of the devices may not exhibit any form of mobility (e.g., security camera) while others may be highly mobile (e.g., devices in trains or buses).Thus, the authentication procedure needs to take into consideration the following factors: (i) Massive deployment of MTCDs causing signaling overload (ii) Deployment environment of the MTCDs (i.e., indoor/ outdoor) (iii) Mobility behavior of the MTCDs (i.e., stationary/ mobile) (iv) Computational and storage capabilities of MTCDs This paper thus proposes an Authentication and Key Agreement protocol to reduce the signaling load, while addressing the aforementioned factors.The first three factors are accounted for in the deployment architecture while the last factor is handled by the use of symmetric cryptography in the proposed algorithm.

Related Works
A number of group based mutual authentication schemes exist in the literature.The schemes can be categorized into three types: (i) Schemes consist of one device of the group performing a full AKA with the core network and thereafter the authentication records for all members of the group are retrieved from the HN and sent to the SN.For the second group member onwards, the HN remains offline with the authentication being performed locally at the SN with the prefetched data.Some of the schemes following this approach are SE-AKA [16]  While the scheme [20] is based on the concept of aggregate signature proposed by Boneh et al. [25], the scheme [21] uses the Nyberg Rueppel signature scheme [26].
The aggregate MAC approach for group authentication is a lightweight one, significantly reducing the signaling overhead at the access network level as compared to aggregate signature schemes.Most existing schemes use a group leader to aggregate the MACs received from the individual MTCDs in a group.However, this can cause a bottleneck at the group leader and also involves the additional complexity and delay associated with group leader selection and management.Another drawback of the aggregation approach is that a single bad (message, MAC) pair or a single invalid signature in the aggregate can cause the entire authentication to fail resulting in repeating the entire authentication process.An attacker only needs to change a single bit in a message or MAC across the group to ensure a failure.So, the cost of this endeavor from the attacker's point of view is very low, making the system susceptible to Denial of Service attacks.
(iii) Schemes follow a batch processing approach whereby authentication requests from multiple devices are processed at once as a batch, like ABAKA [27] by Huang et al.
These schemes are also hounded by the issue of a single invalid signature requiring the rerun of the entire authentication process.

HGMAKA Protocol: System Architecture
The proposed system architecture consists of macrocells, femtocells, mobile femtocells, and also capillary network of devices, thereby forming a HetNet.The architectural elements are classified into three tiers, each consisting of heterogeneous devices performing distinct activities: (i) The first tier, Tier 1, consists of the data generating/ consuming MTCDs, for example, smart meters and medical equipment.They generate data periodically or on being triggered and send the data to some MTC Server.The MTCDs may be static (e.g., surveillance camera) or may be mobile (devices inside train, bus, etc.).They need to be authenticated before they can use the network for sending data to the MTC Servers.Thus, they generate authentication request messages which are sent to the Tier 2 elements.
(ii) The second tier, Tier 2, comprises aggregating elements, those which aggregate the multiple streams of data received from elements in the first tier into a single stream and forward it to the elements in the next tier.Additionally, they verify the MACs of the received messages to verify their integrity and ensure that no tampered messages are included in the aggregate.These elements can be HeNBs, mobile femtocells, MTC Gateway devices, and so forth.
(iii) The third tier, Tier 3, elements provide the last mile connectivity to the core network.They accept the multiple incoming aggregated streams from Tier 2 elements and forward them to the core network either as individual streams or as an aggregate stream as per the requirements.They are also the second level aggregator and verifier.Like the Tier 2 elements, they also verify the integrity of the incoming messages from Tier 2 using MAC before including them in the aggregate.These elements include Home eNodeB Gateway, if HeNBs were the Tier 2 elements, and eNodeB if the corresponding Tier 2 elements were MFemtocells or MTC Gateway devices.
The proposed protocol thus not only performs the aggregation of multiple streams from a lower tier into a single stream at a higher tier, but also eliminates the possibility, due to presence of tampered messages in the aggregate, of authentication failure of the entire group.The Tiers 2 and 3 elements take up the role of aggregation from the group leaders of aggregate based schemes in the literature, thus eliminating the requirement of group leader and the associated computational overheads.Moreover, the limited communication range of group leader due to the use of local access technology at the group level restricts the group sizes.The use of hierarchical architecture also removes this limitation, thereby allowing larger groups of MTCDs to spread across a macrocell.Figure 3 shows the network architecture while Figure 4 illustrates the advantage of hierarchical architecture in terms of group sizes.Table 1 lists the classification of the architectural elements.

HGMAKA Protocol: Algorithm
The aggregation of authentication message at various hierarchies in HGMAKA protocol is followed by a key agreement phase resulting in a unique secret session key being shared among an individual MTCD and the corresponding SN.
The grouping of MTCDs in this protocol may be predetermined or may be done on the fly.For example, a group of MTCDs belonging to the same MTC owner or using the same MTC application may be grouped together by the operator and assigned a group key.Alternately, a group can also be created on the fly based on, say, the current location of the MTCDs, like group of MTCDs inside a vehicle/train/bus and so forth.In this scenario, a group key agreement protocol must be used to generate a group key for all group members with the HSS involved in the process.The group key can also be changed dynamically as changes in membership occur in the group.While there are various group key management protocols available in the literature [28][29][30] and so forth, the same is beyond the scope of the paper and hence not discussed here.The group key is shared among the MTCDs, HSS, the Tier 1, the Tier 2, and the Tier 3 elements.Notations explain the symbols used in the protocol.The proposed protocol consists of two phases: (i) Aggregate generation phase, where the authentication request messages and MACs, sent by Tier 1 elements, are aggregated at higher levels, first by Tier 2 elements and followed by Tier 3 elements.Integrity verification of the incoming messages is performed at each level prior to the aggregate generation.
(ii) Group based Mutual Authentication and Key Agreement phase, where the HSS authenticates all group members simultaneously from the aggregate MAC and the MTCDs authenticate the MME and HSS through a random challenge response protocol terminating with the derivation of unique shared secret keys between the MME and each MTCD.

Aggregate Generation Phase
(1) Consider a group G where the th MTCD MTCD G- , identified by its Unique International Mobile Subscriber Identity IMSI G- , shares a secret key  G- with the HSS.In this phase, MTCD G- generates the authentication request message ( G- 1 ) containing the IMSI (IMSI G- ), Group Identifier (GID G ), random number ( G- ), and a MAC (MAC G- ) computed on the same using the secret key  G- and sends it to the Tier 2 element.Also included in this communication is another MAC (MAC G- 1 ) computed on  G- 1 and MAC G- using the group key GK G .While the former is used for authentication of the MTCD by the HSS, the latter is used for verifying the integrity of the message by the Tier 2 element.The detailed steps are listed below: (a) Each MTCD  of group G generates an authentication message  G- 1 which contains MTCD identity (IMSI G- ), group identifier (GID G ), a random number  G- generated by the MTCD G- , and a MAC, MAC G- .This MAC, later aggregated by the Tier 2 elements, is used by the HSS to authenticate the MTCD. where The MTCD computes a second MAC on  G- 1 with the group key GK G , to be used for integrity verification of these Tier 1 messages at the Tier 2 element, (c) MTCD G- sends  G- 1 ‖ MAC G- 1 to the Tier 2 element.
(2) On receiving the message  G- 1 ‖ MAC G- 1 , the Tier 2 element of group G first verifies the integrity of the received message from MAC G- 1 using the shared group key GK G .On successful verification, it proceeds to compute the aggregate MAC (aggMAC G 2 ) and aggregate message (agg G 2 ) for all Tier 1 elements under it.Finally, the Tier 2 element computes a MAC, MAC G 2 , on agg G 2 ‖ aggMAC G 2 to be later used for the integrity verification of the message at the Tier 3 element.The steps are listed below: (a) For each Tier 1 element  of group G under the Tier 2 element , the Tier 2 element verifies MAC G- 1 in the received message  G- 1 ‖ MAC G- 1 using (2).Successful verification assures that the message  G- 1 has not been tampered with.(b) The Tier 2 element then computes aggregate MAC, aggMAC G 2 , by performing XOR operation on the individual MACs received from the Tier 1 elements (c) Aggregate message agg G 2 is compiled by concatenating individual messages received from Tier 1 elements

Security and Communication Networks
The remove function excluded the MAC field from individual messages.
(d) MAC G 2 is then computed for integrity verification of message at the next higher Tier element (e) Finally, the first level aggregate message agg G 2 ‖ aggMAC G 2 ‖ MAC G 2 is sent to Tier 3 element.
(3) The Tier 3 element performs integrity verification of the message received from Tier 2 and then the second level aggregation is as follows: (a) For each Tier 2 element of group G under the Tier 3 element, the Tier 3 element verifies MAC G 2 in the received aggregate message agg G 2 ‖ aggMAC G 2 ‖ MAC G 2 using (6).
(b) On successful verification, an aggregate MAC, aggMAC G , is computed from the first level aggregate MACs, to be used by the HSS for authenticating the entire group G (c) The aggregate message agg G is compiled by concatenating the level one aggregate messages of group G: (d) The second level aggregate message agg G ‖ aggMAC G is then sent to MME.

Group Authentication and Key Agreement Phase
(1) On receiving the aggregate authentication request and aggregate MAC, that is, agg G ‖ aggMAC G from the Tier 3 element, the MME forwards this, along with its Serving Network Identity (SN ID), that is, agg G ‖ aggMAC G ‖ SN ID, to the HSS.
(2) The HSS receives this aggregate message authentication request for group G from the MME and authenticates the entire group from the aggregate MAC: (a) The HSS verifies the aggregate MAC, aggMAC G (see (7)).(b) The HSS uses a random number  HSS to compute a Temporary Group Key, TGK G , and generates an authentication token AUTH HSS , to be used by the MTCD for authenticating the HSS, as AUTH HSS =  HSS ‖ MAC HSS G .
(c) Next, the HSS generates individual session keys ( ASME G- ) for each MTCD in the group as well as the expected response XRES to the random challenge that the HSS sends to the MTCDs for authentication purposes via MME.
For each  member  of group G For  = 1 to  AK G- = 5( G- ,  HSS ) The HSS compiles the authentication information together with the computed  ASME and XRES for all members of the group in the form of a table called Group Key Index (GKI).The GKI for group G is constructed as seen in Table 2.(d) The HSS sends the GKI and AUTH HSS (from (11)) to the MME.
(2) The MME receives these from the HSS and saves the GKI.It forwards AUTH HSS to each MTCD of group GID G .
(3) At each MTCD, on receiving the authentication challenge, one has the following: (a) The MTCDs authenticate the HSS from this challenge by verifying MAC HSS G after computing TGK G (using (9), (10)).(b) Each MTCD  in the group also computes a response (RES G- ) to the challenge given by the HSS The group members send their response to the Tier 2 element who aggregates the response in the same way as for MAC.The aggregate RES is sent to the Tier 3 element that again aggregates the response and sends it as an aggregate response aggRES G for the group.
The procedure is the same as aggregate MAC generation.
Thus, at the end of the Authentication and Key Agreement phase, a shared secret key  ASME G is shared between each MTCD and the MME.
Figure 5 shows a working example of the aggregate generation phase and Figure 6 shows the message sequence in the group Authentication and Key Agreement phase.

Security Analysis
To illustrate that the proposed protocol is secure, the authors have followed a three-pronged approach to security analysis.First, an informal security analysis of the protocol has been performed to demonstrate the resilience of the protocol against different protocol attacks.Second, the automated formal verification tool AVISPA has been used to verify if the security goals of mutual authentication and secure key agreement have been met.And third, a provable security approach has been used to formally prove that no feasible polynomial time adversary exists which can break the security of the scheme.) is generated at both ends after mutual authentication and is never transmitted over any channel.Also, the respective keys are generated at both ends as KDF(SQN ⊕ AK G- , CK G- , IK G- , SN ID), where AK G- , CK G- , and IK G- are computed from  HSS and the shared secret key  G- only after mutual authentication is successful.

7.3.
Man-in-the-Middle Attack.Despite the fact that the entire communication, both within the capillary network/ femtocell and between the MTC-GW and the network, occurs in plaintext, an intruder cannot determine the session keys (TGK G and  ASME G- ) as these require the knowledge of long term secret keys shared between the MTCD and the HSS as well as the random numbers and sequence numbers.

Replay Attack.
Replay attacks can be thwarted by the use of the random numbers generated by the MTCDs and HSS in the authentication procedure.Even if an attacker captures the messages, the same random number cannot be used for another round of authentication as fresh numbers are required for a fresh round of authentication.

Key Compromise Impersonation (KCI).
A key agreement protocol is KCI-resilient if no adversary can masquerade as an honest user and establish a session key with another user whose long term key has been compromised by the adversary.The proposed protocol is KCI-resilient as proved formally in the next section.
7.6.Forward Secrecy.Forward secrecy implies that if the long term key of the entity is compromised then the secrecy of the earlier session keys generated is not affected.In case of HGMAKA, the session key  ASME G- is computed as a function of the long term secret key  G- as well as  HSS and SQN, both of which changes for each session.Thus, even if  G- is compromised, it will be difficult for the attacker to correlate both the correct  HSS and SQN to be used for generating a past session key.Hence, the protocol has forward key secrecy.

Formal Verification Using AVISPA.
The main goal of the proposed protocol is to provide mutual authentication between the MTCD and the MME/HSS and secured key agreement between the entities.The formal verification of the proposed protocol is tested on Automated Validation of Internet Security Protocols and Applications (AVISPA) [31].AVISPA is a tool for automatic security analysis of protocols represented in High Level Protocol Specification Language (HLPSL) and evaluated using automatic deduction techniques.We have modeled three roles, MTCD, Gateway, and MME, using HLPSL.As the MME and HSS have a secured channel between them, so we have integrated the roles of MME and HSS into a single role.The On-the-Fly Model Checker has been used to test our protocol.The goals of the Tier 1 Tier 2 Tier 3 protocol are given in Algorithm 1 and the output is given in Algorithm 2. The HLPSL roles for MTCD and MME are given in Appendix A as Algorithms 3 and 4.
7.8.Formal Protocol Analysis.The foundation of the security proof of the proposed protocol lies in Shoup's formal security model [32] for secure Mutual Authentication and Key Agreement using the simulation based technique.In [33] Zhang suitably modified Shoup's model to fit the mobile communication scenario.Further, Huang et al. in [34,35] also used Zhang's model to present a provably secure AKA protocol for UMTS.The authors have based their security proof on Zhang's model.In Zhang's simulation based model, the proof of security is arrived at by comparing the performance of an adversary in a real protocol execution (real world) and an ideal scenario (ideal world) which is assumed to be secure by definition.The protocol is said to be provably secure if it is not possible to distinguish between the actions of the attacker in the real world and the ideal world.
As per Shoup's model, the MTC scenario involves two types of communication channels: a secure (assumed) channel between network entities and an insecure wireless channel between the MTCD entities and the network entities.The latter is under the full control of the adversary who can read, modify, and replay the messages transmitted over the channel.The adversary can set up and initiate multiple sessions between MTCD and network and also acquire session keys and apply it on some mathematical function.The activities of the adversary are captured under two scenarios: ideal world and real world.The security of the proposed protocol is proved by comparing the actions of the adversary in the two worlds and proving that the adversary cannot do any more harm in the real world than it would do in the ideal world.Appendix B contains the descriptions of the ideal and real world as well as certain preliminary definitions.
Security Proof.Each entity in the proposed protocol possesses a random number generator which produces random numbers,  G- (for all  and ) and  HSS , for the entity instances.Let all random numbers be selected randomly in  and 1 is the event that   is collision-free; we get where   is the count of instances created by  and | G- | and | HSS | are lengths of the respective random numbers and are polynomial in , and then Pr(1) is negligible.
Lemma 1.For real world adversary  with collision-free (assumed) transcript   and independent function family 2 assumed to be collision resistant in   , the probability of the event 2 (2 is the event that   is authentic) is given by where  = () and  = (  ) and  is the execution time of .
Proof.For   to be nonauthentic, we must have at best one instance that has accepted based on a stimulus sent by a noncompatible instance.To prove this we show that upper bound on the probability of   being nonauthentic is given by ( 15) and the proof proceeds as follows.
Case Let Succ(, 2) be the event that  outputs aggMAC and a message which has not been given to the oracle 2  as a query.Let the event that      has accepted on stimulus by noncompatible instance be represented by      .If      = 1 then the adversary has been successful in forging the MAC for the given message.Thus, hence, Pr ( where  = () and  = (  ).
Case  If   has occurred then the adversary was successful in forging the MAC for the message  HSS .An execution of  results in an adversary   for 2 such that the event of   accepting results in   ends with output MAC HSS G and  HSS .Thus in (18), we have Pr(  = 1) ≤ Pr(Succ(  , 2) = 1).Hence, Therefore, the upper bound on the probability that MTCD instance   accepted on a stimulus from a network instance noncompatible with it is given by Pr (  = 1) + Pr (  adversary was successful in forging MAC HSS G and it can be proved similar to (17) that the upper bound on this event is Adv mac 2 (, ).Further, say, aggRES G was output by noncompatible MTCD instance  11 .In this case  11 received AUTH HSS (which contains  HSS ) prior to generating the stimulus.With   being collision-free, it is not possible for a network entity, other than      , to output AUTH HSS pointing to an adversary having forged MAC HSS G .Similar to (19) we have an upper bound on this event as Adv mac 2 (, ).Thus, the upper bound on the probability that the stimulus on      was from a noncompatible MTCD instance is 2 × Adv mac 2 (, ).We can therefore conclude that the probability of the event 2 is Lemma 2. Let 1, 3, 4, 5, 6, and KDF, represented by , be a family of pseudorandom functions and  is independent of 2 and collision resistant in the real world adversary 's authentic and collision-free transcript   .The algorithm  that distinguishes between the transcript of the real world adversary  and the ideal world adversary  * has where  initializes  MTCD MTCD entities and   instances. = () and  = (  ).
Proof.A simulator with a real world adversary  creates an ideal world adversary  * and converts the transcript in the real world (  ) into a transcript in the ideal world (  * ) so that the two are almost identical.The conversion is carried out in the following manner: (i) An implementation record in   is copied to   * through an implementation operation.
(ii) A (start session, , ) record in   is connection assignment with the ring master replacing the session key  ASME  with idealized random session key   .(iii) An (abort session, , ) is copied to   * with   * executing (abort session, , ) operation.
(iv) In case of an application action in   , all necessary evaluation is made by the ring master using the session key of the ideal world.
The main difference between   and   * lies in the application records.We prove that the assignments made by Therefore, Again, Hence, The probabilities Pr(1) and Pr(2 | 1) are negligible in  (from (14) and Lemma 1); hence Adv dist   ,  * () is also negligible.Hence it is proved that HGMAKA is a secure AKA protocol.

Theorem 4. HGMAKA is KCI-resilient.
Proof.We consider the case when the long term secret key of a MTCD has been compromised by an adversary.Let  denote a MTCD entity instance who tries to execute the Authentication and Key Agreement protocol with a compatible network entity instance   .  accepts with session key  ASME G- on the stimulus agg G ‖ aggMAC G .Now, the adversary corrupts MTCD G- and   responds with message AUTH HSS .This is intercepted by the adversary and replaced by message AUTH HSS  .Next,  accepts and generates session key  ASME

G𝑖-𝑗
which is the same as the one generated by the adversary and different from  ASME G- generated by   .In the ideal world, the session key generated by   was prior to the adversary corrupting the MTCD entity instance.Hence, the only connection assignment possible is create.Further, in case of  since it was corrupted by the adversary, the only possible connection assignment is compromise.However,  cannot be compromised without invalidating the rules of the ideal world as PID  = ID   .Also, connect is not possible without  ASME G- =  ASME G-  .Thus, the real world transcript will be different from the ideal world transcript causing the simulation to be impossible.Therefore, we can conclude that HGMAKA is KCI-resilient.

Performance Analysis
A comparative analysis of the proposed HGMAKA protocol vis-à-vis ten others discussed in Section 4 was performed with respect to three different metrics: (a) number of signaling messages exchanged in executing the protocol; (b) cost, is, the amount of data (in number of bits) transferred in executing the protocols; and (c) computational complexity, that is, the time (in milliseconds) taken for executing the cryptographic operations involved in the protocols, by both the MTCD and the network.
An example scenario is given in the annexure.A total population, , of 10000 MTCDs was considered which may be divided into groups of varying sizes.It is assumed that 1% of this population can generate corrupt authentication requests, represented by   ; that is, 100 corrupt messages can exist.The presence of even a single corrupt message can cause authentication failure resulting in a reauthentication requirement for the entire group.For a group size of   , the probability that exactly  invalid requests out of   are present in the group   follows the hypergeometric distribution as If  represents the event that reverification of the entire group is required, then probability of  is This computation has been applied for different group sizes that is   and the corresponding probabilities are shown in Table 3.
Thus for a group size of 100, there are 0.6358 probabilities that group reauthentication will be required and 0.3642 that group reauthentication will not be required.As the number of groups decreases resulting in increase in the number of MTCDs in each individual group, the probability of reauthentication (due to failure) increases.
These probabilities are taken into account in the performance analysis for the proposed protocol vis-à-vis the existing protocols.Each of the aforementioned metrics was computed for different protocols using the following formula: Quantity of metric required for  groups for successful authentication =  ⋅ Pr() ⋅  +  ⋅ (1 − Pr()) ⋅ , where  is the number of authentication runs,  is the quantity of metric required for authentication of  groups, and  is the quantity of metric required for reauthentication of  groups.A total of  = 10 runs of the authentication protocol have been considered.For each metric, comparison of the various protocols has been performed considering the probabilities mentioned in Table 3.

Number of Signaling Messages.
The number of message exchanges that takes place for  rounds of authentication for different number of groups across existing group based protocols vis-à-vis proposed HGMAKA protocol was considered.Only group based protocols are considered as the advantages of group based as against nongroup based schemes have already been shown in existing literature.As the HGMAKA protocol allows group sizes to be large due to the hierarchical nature of the aggregation, two variants of this were compared: one with a single large group with the entire population of 10000 MTCDs as members and the other consisting of multiple smaller groups.
The HGMAKA protocol requires the lowest number of signaling messages as compared to the existing protocols as seen in Figure 7. Furthermore, the reduction in signaling messages with increasing number of groups is far more significant in the single group variation as compared to the multiple group version, the reason being that even though the probability of reauthentication increases with larger group size, the proposed protocol does not require the entire group to be reauthenticated in case of failure.

Communication Cost.
The communication costs of the protocols are computed as the sum of the sizes of the individual messages that are exchanged for a full round of AKA.The parameters used are placed in the annexure for reference; for example, the size of the messages exchanged between Tier 1 and Tier 2 elements, Tier 2 and Tier 3 elements, and Tier 3 and core networks in HGMAKA is added to arrive at its communication cost.The plot in Figure 8 compares the communication costs.HGMAKA protocol, with a single group, requires the least communication cost which is significantly lower as compared to others.When considered in multiple smaller group, it still exhibits a low communication cost, with only Choi-AKA and SE-AKA performing a little better.

Computational Cost.
For calculation of the computational complexity of the protocols, only significant cryptographic operations like hash, point multiplication, map-topoint, pairing, and so forth were considered.A table has been included in the annexure that lists the execution times of these operations using Crypto++ library on a Celeron 1.1 GHz processor as MTCD and Dual Core 2.6 GHz processor as a network element (MME/HSS) as reported in [16].
The plots in Figure 9 show that the computation cost exhibited by HGMAKA protocol is low, sharing the same with only three other protocols: MTC-AKA, Choi-AKA, and GAKA.
While the main motivation was to reduce the signaling load on the network, HGMAKA is seen to be light even in terms of communication and computation costs.

Conclusion
This paper presents a hierarchical group based mutual authentication scheme, HGMAKA, for Machine Type Communication over LTE network.The proposed lightweight symmetric key based HGMAKA protocol introduces an architectural model that utilizes a heterogeneous network of femtocells, mobile femtocell, and capillary network of MTCDs in line with the future 5G networks.The HGMAKA protocol contributes by reducing the overall signaling load on the access network eNBs and offloads the same to the smaller cells.It also significantly reduces the number of signaling  message exchanges and the size of the exchanged messages by using a single aggregate MAC in place of individual MACs for each MTCD.The scheme also addresses the important issue with aggregate MACs: single corrupt MAC-message pair invalidating the aggregate MAC, through the use of hierarchical en route filtering of MACs.HGMAKA has been shown to perform significantly better compared to other group based protocols.Moreover, this also releases the overhead of group leader management, which includes selection of group leader, its failure, and so forth, which plagues many of the group based protocols.

A.1. Example Scenario Used for Evaluation of Performance
Parameters of Various Schemes.An area where M2M communication is currently used is the Smart Metering Applications.These applications deal with monitoring and management of utilities like electricity, gas, or water.Some of the activities include obtaining meter reading, self-configuration of smart meters, monitoring usage and detecting outages, leakage, and taking necessary actions, like closing-down valves, circuit breakers, and so forth.From the HGMAKA architecture perspective, one can look at this application from the following viewpoints: (i) First, the smart meters can be considered as MTCDs (Tier 1) which can communicate with a gateway device (Tier 2) which further communicates with the eNodeB (Tier 3) for communication with the core network.
(ii) Second, the household appliances, devices, and so forth can be considered to be MTCDs (Tier 1) forming a capillary network with the smart meters acting as the gateway device (Tier 2).The gateway device can further communicate with the eNodeB (Tier 3) for the last mile connectivity to core network.
In both cases, the final aggregator is the eNodeB.This allows group sizes to be very large, often spanning across a very large geographical area.This is in contrast with other aggregation schemes where the aggregator is a group leader selected from across the MTCDs.In the latter scenario, all MTCDs in a group must be colocated within a specific range of the group leader thus limiting the group size.Consequently, the larger group will result in lower signaling overload on the access network as opposed to multiple smaller groups formed from the same number of MTCDs.
A housing complex with 10 multistoried apartment blocks or towers is considered as test case.Each block consists of 100 households, each equipped with a smart meter.That gives approximately 1000 smart meters in the entire complex.Each apartment block has a gateway device (a total of 10 in the complex) installed by the operator which communicates with the smart meters, aggregates the data/authentication signals received, and sends a single message/signal to the eNodeB.Next, we assume that there are 10 such housing complexes located in the nearby area, all under the coverage of the same macro base station, increasing the number of smart meters to 10000.If all houses in the locality are availing the services of the same utility provider, then all 10000 smart meters can be said to belong to a single group.
Whenever the utility provider wants to communicate with the smart meters, all 10000 smart meters will try to connect to the core network to send their usage, billing, or any other information thus overloading the eNodeB.
As per the proposed hierarchical architecture, which allows large groups, all 10000 smart meters form a group, communicating with the gateways which aggregates and forwards the messages/signals to the eNodeB, which further proceeds with the last level aggregation, and ultimately a single message/signal is forwarded to the MME.
In schemes, where aggregation is performed by group leader, the size of groups will be small, say all 100 smart meters in an apartment block forming a single group.One of the smart meters in each block is selected as a group leader and aggregates the messages/signals for all 100 meters.Thus, for each housing complex consists of 10 groups and for 10 such complexes we will have 100 groups.The group leader sends a single message/signal per group to the eNodeB which forwards them (as received without any aggregation) to the MME.

A.2. Formal Verification Using AVISPA. See Algorithms 3 and 4.
A.3.Performance Comparison.See Tables 4 and 5.Each MTCD entity has to be registered with some network entity through the execution of a registration routine.The identity of an MTCD is assumed to be prefixed with the identity of the home network to which it is registered (e.g., IMSI).During the registration routine of MTCD   with previously initialized network    , the ring master assigns arbitrary bit-string   to both   and    which is stored in the variable LTS i by   and (  ,   ) in variable LTS   by    .
Additionally, a group registration routine is carried out between a group of MTCDs and the network.Here, a list of IDs of MTCD entities forming a group is assigned a group identity GID  and an arbitrary bit-string as group key GK  by the ring master.The identity and the key are sent to all MTCDs and    .The MTCD   stores (GID  , GK  ) in variable GS  and    stores the same in GS   .
An entity instance is implemented in the form of a state machine having access to ID  , role  , LTS  , and GS  .A state change occurs on receiving some message of the form (deliver message, , , type, InMsg) from an adversary.  responds by reporting OutMsg along with status to the adversary.The status can be continue (if   can receive a next message), accept (  ends with session key SK  ), or reject (  ends without session key).The transcript   records (implementation, deliver message, , , type, InMsg, OutMsg, status) and (start session, , ) if status is accept and (abort session, , ) if status is reject.
Also, the operation (, ) can be executed by the adversary using the actual session key {SK  }.

B.3.2. Function Family.
A function family is a map  : K ×  → , where K is the set of keys,  is the domain of , and  is the range of .The set of keys and  are finite sets.The function  takes two inputs  ∈ K and  as input and returns a point  in .(, ) = .
For a key  ∈ K, the mapping   :  →  is defined by   () = (, ) = .  is said to be an instance of the function family .An adversary, , is a probabilistic polynomial time algorithm that has oracle access for computing MAC for random key .The mac advantage of  is the probability that  outputs (, ) such that  = (, ) and  was not a query to the oracle by .
belong to group G1.They fall under two cells covered by Tier 2 element 1 and Tier 2 element 2

Figure 7 :
Figure 7: Comparison of signaling messages per MTCD with increasing number of groups.

Figure 9 :
Figure 9: Comparison of computation cost per MTCD at the MTCD and at the network with increasing number of groups.

B. 3 . 3 .
Random Function.Let  = {0, 1}  be a finite set and let  be an oracle which implements a random function.If an adversary queries (), where  is an input parameter, it receives a random point from .If () is queried multiple times, the response remains unchanged.B.3.4.Pseudorandom Function Family.It is a family of functions with the property that the input-output behavior of a random instance of the family is computationally indistinguishable from a truly random function.For a family of functions  : {0, 1}  × {0, 1}  → {0, 1}  and   :  →  with  ∈ K.In the real world,   is an instance of  and in the ideal world   is a truly random function.B.3.5.Distinguishing Advantage.The advantage of a probabilistic polynomial time algorithm  in distinguishing between two families of random variables is  = {  } ≥0 and  = {  } ≥0 , where   and   take values from a finite set   .The output of  is 0 or 1 depending on whether it can distinguish between  and .The distinguishing advantage of  is Adv dist   () =     Pr ( (  ) = 1) − Pr ( (  ) = 1)     .(B.1) B.3.6.Prf-Advantage.Let  : K ×  →  be a family of functions and let  :  →  be another family of functions from {0, 1}  to {0, 1}  and let  be a probabilistic polynomial time oracle algorithm.The prf-advantage of  is Adv prf  () = |Pr ( () = 1) − Pr ( () = 1)| .(B.2) An insecurity function associated with  is given by Adv prf  (, ) = max ∈A(,) Adv prf  () , (B.3) where A(, ) is the set of adversaries that make a maximum of  oracle queries and have running time of .If, for every probabilistic polynomial time adversary , Adv prf  () is negligible in , then we say that  is a pseudorandom family.B.3.7.MAC Advantage.A Message Authentication Code is a family of functions : {0, 1}  × Dom() → {0, 1}  , where Dom() is the domain of  and Dom() = {0, 1} ≤ .For  ∈ {0, 1}  and  ∈ {0, 1} ≤  = (, ) is the MAC of .
Evolved Packet Core (EPC), via the evolved Node B (eNodeB/eNB) which is the base station in the Radio Access Network (RAN), named Evolved Universal Terrestrial RAN (eUTRAN) in case of LTE.LTE also supports other non-3GPP RAN which can be either trusted or untrusted, depending on the operator's policies.The RAN, and thereby, the base There can also be scenarios where the MTC Server triggers the MTCD to perform some action.A third scenario may involve two MTCDs communicating among themselves with or without involving any MTC Server.Standardization organizations, like 3GPP, have published specifications to enable optimization of 3G and LTE cellular networks for MTC traffic.The MTCD connects to the LTE core network, also known as

Table 1 :
Network elements.The end-device in the communication scenario which generates the authentication requests MTCD Tier 2 Level 1 aggregator and integrity verifier of authentication requests from Tier 1 HeNB, MTC-GW, mobile femtocell Tier 3 Last mile connecting device and Level 2 aggregator and integrity verifier of Tier 2 messages HeNB-GW, eNodeB

Table 2 :
Group Key Index.
. The proposed protocol is based on the aggregate MAC concept.An aggregate MAC (aggMAC G ) is generated at two levels, Level 1 by Tier 2 elements and Level 2 by Tier 3, from the individual MACs sent by the MTCDs in the group.This is sent to the MME which forwards it to the HSS.The HSS verifies this aggregate MAC and generates a random challenge and forwards it to the MME in the form of an authentication token (AUTH HSS ) along with the expected response (XRES) for each MTCD in the group.The MME broadcasts the same to all MTCDs.All MTCDs authenticate the HSS from AUTH HSS .The MTCD computes their individual response to the random challenge and sends it via the Tier 2 and Tier 3 elements after going through two levels of aggregation to arrive at the aggregate response (aggRES G ).The MME then completes the mutual authentication by comparing the received aggregate response to the precomputed responses stored at the MME.Thus, the MME and MTCDs perform a mutual authentication.7.2.Secured Key Agreement.Once mutual authentication is successful, both parties, that is, MME and MTCD, have a session key shared between them.The key ( ASME G- 1. Say, the network entity instance      accepted on receipt of aggregate message agg G ‖ aggMAC G .We try to prove that the stimulus was sent by a compatible MTCD entity.If      has accepted, that means that the MAC verification has been successful.However, the identity IMSI G- of each MTCD entity instance in the group is used in the computation of MAC.Since the IMSI contains the HN identity embedded in it, if      accepts then it could only be on stimulus sent by a compatible MTCD instance.Let  be the adversary for Message Authentication Code 2 with oracle access to 2  where  is a randomly selected key.Let PID     = IMSI of user  and  might be initialized by . starts its execution by picking keys for all users other than  and proceeds as in the real world.If  needs access to the MAC function 2  under the key of , the same is provided by the corresponding oracles.Further, the evaluation of functions 1, 3, 4, 5, 6, and KDF with 's key is realized through returning a constant or random number by .Say,      accepts at some point and  outputs aggMAC G and the message agg G and stops else  stops with a null string as output.
2. Say, MTCD instance   accepted on stimulus AUTH HSS .Let the event that   accepted on stimulus from a nonnetwork entity be denoted by   and let the event that   accepted on stimulus from a noncompatible network entity      be denoted by    .If    has occurred then      must have received agg G ‖ aggMAC G before sending AUTH HSS .As   is collision-free  G- could be generated only by   which implies that the adversary has successfully forged one or more MACs in aggMAC.Thus, * are legal and   and   * are indistinguishable.Security and Communication Networks made earlier as AUTH HSS contains  HSS which the MTCD can verify as not being repeated.Thus, the ring master can substitute the session key  ASME  with an idealized (random) session key   .Case 2. Say      , a network instance, receives agg G ‖ aggMAC G .  is an MTCD instance whose individual MAC is included in aggMAC G and      accepts on this stimulus.The connection assignment made by  * is (create, , ).The random session key   is assigned by the ring master instead of  ASME     .Since 2 is collision resistant in   , hence the received message could be the stimulus only on      .Thus, the connection assignment (create, , ) has not be made earlier.This can be proved similarly for all MTCD instances included in the group MAC construction.Case 3. Let      be the network instance that receives aggRES G from a group G and let   be a MTCD instance of an MTCD belonging to this group.Assume    has accepted on this stimulus.Since 2 is collision resistant and   is collision-free, as in Case 2, we can prove that   has accepted on receiving stimulus provided by     .Thus, the adversary  * has made a valid connection assignment (connect, , ) with the ring master setting the session key  ASME     to   .Each start session record in   * has a connection assignment as seen from the analysis.The main difference between   and   * now lies only in the application records.For a single MTCD entity initialized by  and algorithm  that distinguishes between   and   * , an adversary   for  is such that Adv dist  For  MTCD MTCD entities with keys  G-1 ,  G-2 , . . .,  G-MTCD ,  and   have access to oracles   G-1 ,   G-2 , . . .,   G-MTCD  .Thus, Adv dist   ,  * () ≤  MTCD Adv Case 1.Let us assume that an MTCD instance   receives AUTH HSS and accepts.This message cannot be sent by a noncompatible network entity as   is authentic.Let the stimulus on   be sent by compatible MTCD entity instance      .The connection assignment (create,   ,   ) is made by adversary  * .This connection assignment has not been  ,  * () = Adv prf  (  ).Hence, Adv dist   ,  * () ≤ Adv prf  (, ), where  = () and  = (  ).

Table 3 :
Probability of authentication failure and success.

Table 4 :
Parameters for computing communication costs.

Table 5 :
Parameters for computing computation costs.Security and Communication Networks instances and can query the ring master.The ring master also provides session keys to the entity instances.The adversary can perform operations which are recorded in a transcript.These operations are as follows:(i) (Initialize entity, ,   ,   ): Adversary assigns an identity ID  (a unique arbitrary bit-string) to the th entity with the role as 0 for a MTCD entity and 1 for network entity.It specifies how a session key   for an entity instance   is generated.The possible connection assignments are as follows:(1) (Create,   ,   ): A random bit-string   is generated by the ring master.This is valid only if (a)      is an instance compatible with   and initialized earlier that is PID  = ID   and PID     = ID  and role  ̸ = role  , (b) (create,   ,   ) had not been made earlier either on   or any other instance.We can say that   is isolated for      once the start session operation completes.(2)(Connect,   ,   ): The key   is set to      by the ring master.This assignment is legal only if      is isolated for   .(3)Compromise: The ring master sets   to key.(, {  }) where  is a random input and   is a session key.The adversary receives the output of this function from the ring master.In the real world, the adversary has full control over the channel.The real world adversary works towards defeating the Mutual Authentication and Key Agreement goals.The adversary starts by initializing the entities using the initialize entity operation followed by the initialize entity instance operations.In addition to the operations available in the ideal world, the entities in the real world can perform protocol specific operations which can modify their internal state.A network entity   with identity ID  can start an initialization routine whereby it interacts with other network entities with which it has service agreements.The ring master provides a list of networks to   with which it has service agreements.  sends agreement messages to each network in this list to which the other party responds with an approval message.Communication between the two networks is modeled with the ring master providing a secure communication with the help of mailboxes at both sides.
): MTCD or network (can be either home network or serving network, referred to simply as network).MTCD entities communicate with network entities in a two-party setting.Each   ( = 1, 2, . ..) can participate in multiple instances denoted by   ( = 1, 2, . ..).An adversary plays a game with its opponent a ring master who generates random numbers.The adversary can create and connect entity (iv) (Start session, , , connection assignment [, key]): The insecurity function of  is Adv mac  (, ) = max ∈A(,) Adv mac  () .(B.4) We say that  is a secure message authentication code if, for every polynomially bounded adversary , Adv mac  () is negligible in .For a real world entity instance   , a message received by   causing it to change its status to accept is called a stimulus on   .B.4.2.Authentic Transcript.For every real world adversary  with transcript   ,   is said to be authentic if, for an instance   , the stimulus to accept comes only from another compatible instance.B.4.3.Collision-Free Transcript.For every real world adversary  with transcript   ,   is said to be collision-free if every entity and its instances generate unique nonrepeated random numbers.B.4.4.Collision Resistant Transcript.For every real world adversary  with transcript   , if for function family  is used by entity and entity instance to compute tags  1 ,  2 , . . .,   and   ̸ =   ,  ̸ = , we say that  is collision resistant in   .Notations MTCD G- : MTCD belonging to group G IMSI G- : Unique International Mobile Subscriber Identity Number for MTCD G- GID G : Group identifier of group G GK G : Group key of group  shared by all members of the group with the HSS.The group key is also shared between the Tier 2 and Tier 3 elements catering to the group  G- : Secret key shared between the MTCD G- with the HSS  G- 1 : Authentication request message generated by MTCD G-  G- : Random number generated by MTCD G- MAC G- : Message authentication code sent by MTCD G- for authentication by MME MAC G- 1 : Message authentication code sent by MTCD G- for verification by Tier 2 element  HSS :