# Low-Cost Authentication Protocol for D2D Communication in m-Health with Trust Evaluation

Authors: Ana Paula G. Lopes; Paulo R. L. Gondim
Journal: Wireless Communications and Mobile Computing
 (2020)

---

## Abstract

Relay-assisted device-to-device (D2D) communication serves users at the edge of system coverage of 5G networks, enabling communication among sensors and patients’ mobile devices, and improving spectral and power efficiency. The security of D2D-based m-health applications requires attention due to the delicacy of the data treated in the collection, transmission, and storage of information on patients, whose devices must be adequately authenticated. However, traditional authentication and key agreement schemes are not suitable for D2D scenarios, since they might expose patients to security vulnerabilities and lead to an excessive use of resources. This article proposes a secure and lightweight scheme based on Shamir secret sharing for the mutual authentication of m-health devices in relay-assisted D2D communications, which provides security robustness and reduces resources (energy, processing) consumption. The manuscript also addresses the trustworthiness of devices involved in data relay and device discovery procedures.


---

## Body

## 1. Introduction

Mobile device communication has grown over the past few years due to the development of thousands of new applications and devices. The Internet of Things (IoT), the main responsible actor for such a revolution, enables the connection of several applications (e.g., those based on smartphones, smart watches, smart TVs, smart homes and vehicles, and smart metering). Mobile-health (m-health), which is an interesting human health-related application, provides the monitoring and evaluation of vital signs and other important health information on patients, preventing the escalation of diseases and affording immediate relief in emergencies.The m-health system commonly works with a group of sensors coupled to a patient’s body and a mobile device that receives the measurements from such sensors and sends the information to the respective health center. Huang et al. [1] observed high-quality healthcare services, such as remote monitoring, mobile telemedicine, remote disease diagnosis, and emergency care require the assurance of security of both the system and the communication channels through which messages are exchanged.On the other hand, D2D communication refers to direct and low-power communication between two mobile devices [1]; it offers services based on their proximity, and its advantages include higher throughput, low latency, and instantaneous communications between devices [2]. Moreover, traffic offloading/traffic steering between cellular and D2D networks is an excellent alternative for the bandwidth demands imposed over cellular networks, increasing spectral efficiency, and reducing energy consumption [1].Device-to-device communication (D2D) is a strong candidate for communication of devices involved in m-health applications. For example, in a scenario of remote telemonitoring of patients implemented on a large scale by cellular and wireless body area networks (WBAN), the high volume of data exchanged, jointly with concurrent data traffic from other applications, requires a new perspective on the communication of near devices for providing important health information on patients’ health, 24 hours a day and seven days a week. As another example, in emergency care situations in which information about a patient must be rapidly transmitted for the evaluation and acting by a health professional (a doctor, for example), D2D communications contribute to the transmission and reception of data in a timely manner.Health services provided at the edge of communication networks, such as LTE (Long-Term Evolution) and LTE-A (LTE-Advanced) can benefit from technological resources and principles inherited from mobile edge computing (or, more recently, multiaccess edge computing (MEC)) [3–6] discussed the integration of MEC and D2D technologies. In particular, a possible use of relay D2D devices can promote coverage extension and a better removal of constraints related to computation resources, since the task of a device can be offloaded to an edge node and a nearby D2D device ([4]).Nonetheless, Wang and Yan [2] highlighted the success of D2D communication depends on security, which has not been properly studied. D2D cannot work adequately to fulfill the application’s expectations if security is not assured. Its requirements were addressed by Wang and Yan [2] and Haus et al. [7] and include authentication, privacy, anonymity, nonrepudiation, integrity, confidentiality, and resistance to attacks (e.g., man-in-the-middle, impersonation, and replay, among others).Some of such security requirements might be fulfilled by a mutual authentication among devices and among devices and the core of the 3GPP (Third Generation Partnership Project) network. However, the traditional authentication and key agreement (AKA) standardized by 3GPP is not suitable for D2D authentication, since it leads to high consumption of processing and bandwidth resources as described by [8, 9]; moreover, D2D devices have commonly memory limitations and the energy (battery) consumption should also be reduced. Therefore, new applications that exchange critical data (e.g., m-health) require novel AKA schemes to fulfill such a demand [10].This article proposes a novel mutual authentication and key agreement scheme (protocol) for D2D devices in m-health that enables patients to securely send their medical information to a health center and doctors. In comparison to other authentication protocols, our scheme reduces energy consumption and the use of processing resources.An important issue regarding m-health is trust among devices supported by D2D communication. Whenever a patient must send data and no direct connection with the 3GPP infrastructure is provided, such data are sent through relay and device to device until the network infrastructure has been reached. The problem is that not all devices are trustworthy to perform such a task; consequently, trust assurance and evaluation become a critical problem for D2D m-health applications.The protocol has been designed to forecast the relay of data when devices are outside the 3GPP coverage area, or inside it, but with no access to the network, regarding the necessity of computational trust.The main contributions of the present study include the following:(i)
A secure secret sharing scheme for D2D m-health applications that fulfills all security aspects discussed in 3GPP D2D security specification TS 33.303 [11](ii)
A mutual authentication scheme for D2D m-health groups of devices focused on the 3GPP architecture for proximity-based services(iii)
An adaptation of the trust mechanism based on the local trust concept proposed by Yan et al. [12] that enables D2D devices to choose the most reliable device in their proximity to perform the relay of their data; in the proposed protocol, the local trust secret key encryption is based on symmetric cryptography, thus reducing computational costs when compared with [12], which is based on asymmetric cryptography(iv)
An evaluation of computational and energy costs of our scheme, which revealed its superior performance, in comparison to two other protocols(v)
An assessment of the security properties of the scheme and possible protection against attacks and threats(vi)
A semiautomated formal validation of the protocolThe remainder of the manuscript is organized as follows: Section2 discusses some related work. Section 3 presents the 3GPP reference architecture for proximity services. Section 4 introduces the protocol, its phases, the authentication and key agreement process, and a trust evaluation. Section 5 is devoted to a security analysis and comparisons with other protocols. Section 6 reports an evaluation of computational and energy costs. Section 7 discusses AVISPA verification. Section 8 provides the conclusions and suggests some future work.


## 2. Related Work

m-health security has been the focus of several studies. Zhang et al. [13] developed an efficient certificateless generalized signcryption (CLGSC) scheme based on the Elliptic Curve Discrete Logarithm Problem (ECDLP) and a lightweight and robust security-aware (LRSA) D2D-assisted data transmission protocol for m-health based on CLGSC. However, according to Zhou [14], the scheme proposed by [15] shows some security weaknesses, such as vulnerability to an insider attack, which affects its confidentiality. Zhou enhanced it by improving the CLGSC scheme and proposed a certificateless signcryption scheme for m-health [16], towards correcting the abovementioned vulnerabilities in CLGSC scheme. According to the author, it uses some extra variables in the authentication procedure in comparison to [15], which enables attackers to obtain some authentication parameters through queries.Harn [15] presented three authentication schemes based on Shamir’s secret sharing [17], which enables the generation of a common secret for a group of entities. According to Shamir’s secret sharing, a previously established system manager chooses a random polynomial and generates a secret based on the secret tokens of each entity participating in the system. The tokens are then securely exchanged among the entities so that they reconstruct the secret through the Lagrange interpolating formula and authenticate each other by comparing the secret generated with the secret received from the system manager.Harn [15] designed the Asynchronous (t; m; n) Group Authentication Scheme (GAS) with Multiple Authentications, which authenticates n members of m groups and is resilient until t tokens have been compromised. Each entity has two tokens generated by the system manager through two different polynomials, which must remain secret. The system manager also generates a secret based on the tokens of the entities. Using its own two tokens, each member generates two Lagrange components, which are based on the Lagrange interpolating formula. The entities then exchange their Lagrange components to obtain a secret to be compared with that received from the system manager.Mustafa and Philip [18] discussed the way a scheme of group key exchange for D2D medical IoT communication with cryptographic secret sharing must be designed to be efficient. Although it uses Shamir secret sharing [17], the authors do not detail the calculations and messages exchanged for the authentication of the devices, and only describe the procedure. A device is required to be a supernode that calculates the key generation process and distributes the key shares (tokens) to each device. The node is considered a single point of failure, since all devices rely upon it for the creation of the group-based session key. As future work, the authors propose the creation of a distributed key exchange approach. However, the development of a trust scheme for the D2D m-health environment has not been considered.Yan et al. [12] designed a scheme for secure D2D communications that operates over the 3GPP infrastructure, based on two-dimensional trust levels, namely, Local Trust (LT), controlled by the communicating devices, and General Trust (GT), controlled by the 3GPP infrastructure. It considers D2D communication in general and presents the following three coverage scenarios: coverage, relay coverage, and out of coverage. The devices obtain support from ProSe Function Server (PFS) and ProSe App Server (PAS) to perform a trust evaluation. The scheme is composed of algorithms that authenticate and measure the trust level of devices in three situations, i.e., when only LT (local trust) level, or only GT (global trust), or both levels are used for the trust measurement, and has been partially used for the construction of our trust mechanism.Last, but not least, we considered several technical reports and specifications of 3GPP regarding D2D communication and ProSe to strengthen the technical foundation of this study, including 3GPP TS 33.303 [11], 3GPP TS 23.303 [19], and TR 36.843 [20]. The former describes the security aspects to be considered when ProSe is used in the Evolved Packet System (EPS) and comprises the security procedures involving interfaces among network entities, the configuration of ProSe-enabled User Equipment (UE), and data transfer between ProSe Function and ProSe-enabled UE. The second specification [11] regards the ProSe features in EPS, i.e., ProSe discovery (identification of UEs in the proximity) and ProSe Direct Communication, which enables the establishment of communication paths between two or more UEs in a direct communication range. The technical specifications in [20] address enhancements for ProSe UE-to-network relay for commercial and public safety applications, as wearables and IoT devices.


## 3. 3GPP Reference Architecture for ProSe Services

### 3.1. Functional Description

Since the development of applications and equipment can benefit from the adoption of standardized architectures, we considered the architecture adopted by a normative organization (in this case, the 3GPP) for proximity-based services.The following entities of the 3GPP reference architecture for ProSe services have been considered:(i)
Home Subscriber Server (HSS): part of the Evolved Packet Core (EPC) of LTE (Long-Term Evolution) networks that contains users’ and subscribers’ information, supports authentication and authorization of devices, and manages mobility(ii)
ProSe Function Server (PFS): the logical function used for network-related actions required for ProSe that plays different roles for each of its feature [11], such as generation of trust tokens and identities in the management of D2D communication(iii)
ProSe App Server (PAS): an entity that stores and manages ProSe User IDs and maintains permission information for restricted ProSe Direct Discovery(iv)
User Equipment (UE): a mobile device associated with each user(v)
Evolved NodeB (eNodeB): an entity that provides a wireless connection with UE and enables its connection with the core networkFigure1 shows the reference architecture proposed by 3GPP for Proximity Services [20]. Domain A is inside the red dotted circle and comprises the security domain of EPC, PFS, and PAS. Domain B is defined by the lilac dotted circle and refers to the security domain of UE and PAS. Finally, Domain C defines the security domain comprised only of users’ equipment.Figure 1
3GPP ProSe reference architecture (based on Yan et al. [11]).


### 3.2. Reference Points

Below is a list of reference points of 3GPP TS 23 303 [19], as shown in Figure 1:(i)
PC1: the reference point between the ProSe application in the UE and the ProSe Application Server that defines application-level signalizing requirements(ii)
PC2: the reference point (PC2) between the ProSe Function Server (PFS) and the ProSe Application Server (PAS) that defines the interaction between PFS and PAS. PFS receives a proximity request from an originating UE and sends a proximity map request to PAS to obtain the identity of the targeted application user. PAS determines whether the originating UE is allowed to discover the targeted UE(iii)
PC3: the reference point between the UE and the ProSe Function that authorizes discovery requests in the EPC level and allocates the identities used in discovery procedures(iv)
PC4: the reference point between HSS and PFS used by the latter to retrieve EPC-level discovery-related subscriber data(v)
PC5: the reference point between UEs used for control and user plane for direct discovery


### 3.3. 3GPP ProSe Device Discovery

The 3GPP device discovery is detailed in technical specification TS 23.303 [19] and involves the detection and identification of other devices (UEs) located in proximities using E-UTRAN or WLAN direct radio signals. The device discovery can be open if no permission is required by the UE being discovered, or restricted, otherwise. It can also be used by applications to initiate ProSe Direct Communication.It has the following two models for operations:(i)
Model A (“I am here”): interested devices announce certain information in a predefined discovery interval, which could be used by devices nearby to obtain permission to discover their existence. They monitor the devices that showed interest in the messages, read, and process them(ii)
Model B (“who is there?”/“are you there”): devices transmit a request with the information on what they are interested in discovering. The addressed devices respond with information related to the source device’s requestsOur scheme has adopted Model A of device discovery. First, each device must obtain authorization for direct discovery and direct communication from the PFS. Prior to announcing the information, they must send a discovery request to the PFS; if it succeeds, they can start announcing on the PC5 interface. Next, they send a request to the PFS to be authorized to monitor. If they succeed and have a Discovery Filter, they can start the monitoring. Finally, when the monitoring devices detect one or more devices that have matched the filter, they report them to the PFS. For a more detailed description, readers should consult 3GPP TS 23.303 [19].


### 3.4. Security Requirements

The several security requirements and aspects expected by the 3GPP standardization [19] for D2D communication that uses the ProSe architecture include the following:(i)
Avoidance of attacks: the systems must resist several attacks, e.g., replay and impersonation(ii)
Authorization of devices: the system must allow only currently authorized devices to be discovered by other UEs(iii)
Tracking of devices: the tracking of devices based on their discovery messages should be minimized(iv)
Authentication of devices and PFS: the devices involved must authenticate the source of the data received. UE and PFS must authenticate each other(v)
Integrity and confidentiality: both integrity and confidentiality of data exchanged among the entities must be guaranteed(vi)
Privacy: the privacy of users must be provided


## 3.1. Functional Description

Since the development of applications and equipment can benefit from the adoption of standardized architectures, we considered the architecture adopted by a normative organization (in this case, the 3GPP) for proximity-based services.The following entities of the 3GPP reference architecture for ProSe services have been considered:(i)
Home Subscriber Server (HSS): part of the Evolved Packet Core (EPC) of LTE (Long-Term Evolution) networks that contains users’ and subscribers’ information, supports authentication and authorization of devices, and manages mobility(ii)
ProSe Function Server (PFS): the logical function used for network-related actions required for ProSe that plays different roles for each of its feature [11], such as generation of trust tokens and identities in the management of D2D communication(iii)
ProSe App Server (PAS): an entity that stores and manages ProSe User IDs and maintains permission information for restricted ProSe Direct Discovery(iv)
User Equipment (UE): a mobile device associated with each user(v)
Evolved NodeB (eNodeB): an entity that provides a wireless connection with UE and enables its connection with the core networkFigure1 shows the reference architecture proposed by 3GPP for Proximity Services [20]. Domain A is inside the red dotted circle and comprises the security domain of EPC, PFS, and PAS. Domain B is defined by the lilac dotted circle and refers to the security domain of UE and PAS. Finally, Domain C defines the security domain comprised only of users’ equipment.Figure 1
3GPP ProSe reference architecture (based on Yan et al. [11]).


## 3.2. Reference Points

Below is a list of reference points of 3GPP TS 23 303 [19], as shown in Figure 1:(i)
PC1: the reference point between the ProSe application in the UE and the ProSe Application Server that defines application-level signalizing requirements(ii)
PC2: the reference point (PC2) between the ProSe Function Server (PFS) and the ProSe Application Server (PAS) that defines the interaction between PFS and PAS. PFS receives a proximity request from an originating UE and sends a proximity map request to PAS to obtain the identity of the targeted application user. PAS determines whether the originating UE is allowed to discover the targeted UE(iii)
PC3: the reference point between the UE and the ProSe Function that authorizes discovery requests in the EPC level and allocates the identities used in discovery procedures(iv)
PC4: the reference point between HSS and PFS used by the latter to retrieve EPC-level discovery-related subscriber data(v)
PC5: the reference point between UEs used for control and user plane for direct discovery


## 3.3. 3GPP ProSe Device Discovery

The 3GPP device discovery is detailed in technical specification TS 23.303 [19] and involves the detection and identification of other devices (UEs) located in proximities using E-UTRAN or WLAN direct radio signals. The device discovery can be open if no permission is required by the UE being discovered, or restricted, otherwise. It can also be used by applications to initiate ProSe Direct Communication.It has the following two models for operations:(i)
Model A (“I am here”): interested devices announce certain information in a predefined discovery interval, which could be used by devices nearby to obtain permission to discover their existence. They monitor the devices that showed interest in the messages, read, and process them(ii)
Model B (“who is there?”/“are you there”): devices transmit a request with the information on what they are interested in discovering. The addressed devices respond with information related to the source device’s requestsOur scheme has adopted Model A of device discovery. First, each device must obtain authorization for direct discovery and direct communication from the PFS. Prior to announcing the information, they must send a discovery request to the PFS; if it succeeds, they can start announcing on the PC5 interface. Next, they send a request to the PFS to be authorized to monitor. If they succeed and have a Discovery Filter, they can start the monitoring. Finally, when the monitoring devices detect one or more devices that have matched the filter, they report them to the PFS. For a more detailed description, readers should consult 3GPP TS 23.303 [19].


## 3.4. Security Requirements

The several security requirements and aspects expected by the 3GPP standardization [19] for D2D communication that uses the ProSe architecture include the following:(i)
Avoidance of attacks: the systems must resist several attacks, e.g., replay and impersonation(ii)
Authorization of devices: the system must allow only currently authorized devices to be discovered by other UEs(iii)
Tracking of devices: the tracking of devices based on their discovery messages should be minimized(iv)
Authentication of devices and PFS: the devices involved must authenticate the source of the data received. UE and PFS must authenticate each other(v)
Integrity and confidentiality: both integrity and confidentiality of data exchanged among the entities must be guaranteed(vi)
Privacy: the privacy of users must be provided


## 4. Proposed Scheme

Our scheme considers situations in which devices are outside the coverage area, in the coverage area, and directly connected with the 3GPP infrastructure, or in the coverage area, but with no direct access to 3GPP. In the second case, D2D nodes operate as the relay of a network, as proposed by Zhang et al. [13] and Zhou [14]. Moreover, computational trust is fundamental for a proper operation of the system.HSS manages the device authentication and key distribution, whereas PFS and PAS manage the trust of devices. D2D communication involves patient’s devices willing to perform the relay of data. Finally, the health center infrastructure receives the patients’ data and forwards them to doctors, nurses, and physicians. Figure2 shows the architecture of the protocol, derived from 3GPP ProSe [11] standards, with all entities involved.Figure 2
System architecture.Table1 shows the main symbols and parameters used in the proposal.Table 1
Parameters used in the protocol.
SymbolDescriptionDiPatienti or device i, where i=1,2,3,⋯,np,qLarge public prime numbersZp∗/Zq∗A finite field of orderp/prime field of order qEZpElliptic curve overZpGpGroup of orderpGqA subgroup ofGp of order qgPoint generator ofG; i=1,2,3⋯flxRandom polynomial;l=1,2,⋯zMaster private keyMkpubMaster public keySKDiPrivate key of deviceDiPKDiPublic key of deviceDiIDx/TIDxReal identity of entityx/temporary identity of entity xRjj random number generatedTx_iTimestamp generated by entityx=Di, HSS; i=1,2,3⋯h1Temporary identity generation hash function;H1:0,1∗Zp∗h2Device’s partial private key generation hash function;H2:0,1∗Gqh3Symmetric key generation hash function;H4:0,1∗×GqGpHShamir’s secret hash functionLTiLocal trust level of deviceiLTKDu−Du′Local trust secret keySecure channelInsecure channelSome basic assumptions are as follows:(i)
The health center infrastructure is considered trustworthy and secure(ii)
The entities of the 3GPP infrastructure and their communication channels are considered trustworthy and secure(iii)
The channel between the patients’ device and their respective body sensors is considered safe(iv)
The D2D communication channels and the channel between devices and eNB are considered unsafe (they are the focus of this study)The domain considered covers one or more 3GPP cells. Several groups can be inside the system domain of operation and are formed according to the patients’ needs regarding the sending of their data.The protocol uses asymmetric and symmetric cryptography. The former is used in the generation of private keys and temporary identities for mutual authentication, while symmetric cryptography is employed in the trust evaluation for reducing costs, when compared to [12]. It is based on the Asynchronous (t; m; n) Group Authentication Scheme (GAS) with Multiple Authentications, proposed by Harn [15], since it provides a way of sharing a secret in a group of entities that might be used in the generation of secret keys. Timestamps and random variables are freshly generated in each session for avoiding attacks. A session key is generated among devices, as well as among devices and HSS at the end of the mutual authentication phase, and a local trust key is generated whenever a local trust evaluation is required from one device to another. New keys are generated at every single execution of the protocol.The following 5 (five) phases, described in the next subsections, must be executed for a patient outside the coverage area to send their data in a protected manner:(i)
Initialization(ii)
Registration(iii)
Mutual authentication(iv)
Trust evaluation(v)
Encryption/decryption


### 4.1. Initialization

Some important system parameters are generated in this phase, and all devices accredited by the health center server must perform the phase offline.Initially, HSS selects two random prime numbersp and q that satisfy condition q/p−1 and defines a finite field Zp∗ and a secure elliptic curve EZp∗. Next, it selects a group Gp of order p, Gqthat is a subgroup of Gp, g as the generation point of Gq, and Zq∗ as a prime field of order q. Then, it selects a random number zϵZq∗ as the master private key and calculates Mkpub=z∗g to obtain the master public key.HSS selects three hash functions (h1., h2., and h3.) (described in Table 1) for the mutual authentication phase and generates j random numbers, Rj, (j=1,2,⋯,i), for each device and for itself for the calculation of a set of temporary identities TIDDi:(1)TIDDi=h1IDDiRj∗z.It also selects its ownTIDHSS:(2)TIDHSS=h1IDHSSRj∗z.Next, it sends each device its respective set. A differentTIDDi is used whenever a new session has been established to provide a relay of data to a specific device. When the last TID available is being used, the device must notify the HSS after the authentication procedure. Then, HSS sends a new set of temporary identities encrypted with the freshly generated session key.HSS generates a piece of each device’s private key (similar to [15]), chooses a yϵZq, and calculates the following:(3)YDi=h2TIDDiy∗MKpub.Finally, it sets the partial key calculated for each respective device and publishes the following parameters:g,G,EZp∗,Mkpub,TIDHSS,h1.,h2.,h3.,H..


### 4.2. Registration

The ProSe device discovery mechanism is initially applied in this phase for the discovery of nearby devices, as described in [11]. The phase is performed over an insecure channel, and the main steps are described below.Each user generates a share of its private key (based on [13]) choosing xϵZq∗ and calculates its public key:(4)PKDi=x∗YDi∗g.Then, it sendsTIDDi,PKDi, and a timestamp TDi¯1 to the other devices and the nearby device sends HSS all the information received from relay devices.The device sets its private key as pairSKDi=x,YDi using the other share of its private key received from the HSS in the initialization phase.Each device chooses an integervDi−DjϵZq∗ as a secret value to be sent to other devices and HSS, encrypted with its public key, as follows:(5)VDi−Dj=EPKDivDi−Dj,where j represents either a device Dj or HSS.Consequently, only the correct device can decrypt the message and obtain the secret token. The secret values are broadcast to the entities involved in the communication, which find and decrypt them to obtain all secret values necessary for the generation of session keys.The asynchronous mode of the group authentication protocol designed by Harn [15] is considered for providing multiple authentications in a t-secure m-user n-group authentication scheme (GAS). In other words, for a group with n members, m-users are authenticated at once, with at most (t−1) compromised tokens; a unique token is assigned for each user of a group by the group manager for determining the membership of a user to a group. Therefore, considering what is proposed by [15], we have designed our authentication scheme as follows:First, HSS selects two random polynomialsflx,l=1,2 of degree t−1 each, where t≤n is the number of devices involved in the relay (i.e., number of tokens necessary for the recovery of secret S):(6)flx=∑i=0t−1aiximodp.All coefficients are in finite fieldZp∗.HSS generates two tokens for each device calculatingflTIDDi. Each TIDDi has its respective token. HSS also calculates its own two tokens flTIDHSS and finds integers wi,j,di,j,j=1,2ϵZp∗, such that S=∑j=0kdi,jfjwi,j, where wi,1≠wi,2 for every pair i and j. It then generates a secret S, as in [17]:(7)S=fl0=a0,(8)S=g∑j=12di,jfjwi,jmodqmodp.Finally, it chooses an integervHSS−DiϵZq∗ and sends it to the respective devices of the relay group:(9)AUTHDi=EPKDiTIDHSS,HS,wi,j,di,j,flTIDDi,vHSS−Di,TIDDi,THSS¯1.The devices decrypt the message and store the parameters.Figure3 shows a summary of the registration phase.Figure 3
Messages exchanged in the registration phase.


### 4.3. Mutual Authentication

Since the devices still must authenticate each other and HSS, each device selects a pair of nonusedTIDDi and respective tokens flTIDDi, l=1,2,⋯ and computes its Lagrange component (an adaptation of what is proposed in [15]) LCDi through the Lagrange interpolating formula:(10)LCDi=∑l=12di,lflTIDDi∏q=1;q≠inwi,l−TIDDi−qTIDDi−TIDDi−qmodq.Next, they calculateeDi=gLCDimodp.HSS also calculates its Lagrange componentLCHSS through the Lagrange interpolating formula:(11)LCHSS=∑l=12di,lflTIDHSS∏q=1;q≠inwi,l−TIDDi−qTIDHSS−TIDDi−qmodq.Its owneHSSwas also calculated:(12)eHSS=giLCHSSmodp.It generates a random valuerDiϵZq∗. The devices send TIDDi,eDi, rHSS, and a timestampTDi¯2 to the other devices in the relay group and to HSS, which also sends TIDHSS,eHSS, THSS¯2, andrHSS to the other devices in the relay group. After receiving such parameters, the entities verify the validity of the timestamp to avoid denial of service (DoS) attack. They proceed with the authentication only if the timestamp is valid. Otherwise, they discard the respective entity. When each entity has a complete set of eDi and eHSS, a secret S′ is calculated:(13)S′=eHSS∗∏i=1neDimodp=giLCHSS+∑LCDimodqmodp.Again, an attacker must solve the DLP problem to obtaineDi,eHSS, and S′, as in [15].Next, each device checks if theHS′ calculated is equal to the HSreceived from HSS in the registration phase. If HS=HS′, the devices and HSS are legit and mutually authenticated. If the verification fails, one or more intruders are in the path.Finally, a session key is generated for each possible connection between devicesDi and HSS.(14)SKeyDi−k=h3SrDiruvDi−u⊕vu−DiIn this stage, if the source device has direct access to the network infrastructure, it can encrypt its health information with the session key and send it to the core network. Otherwise, it must execute phase 3.4 prior to phase 3.5.Figure4 shows a summary of the mutual authentication phase.Figure 4
A message exchanged in the mutual authentication phase.


### 4.4. Trust Evaluation

This phase is executed whenever a patient that must send his/her health information to the doctor/physician is not in the coverage area of a 3GPP cell. Therefore, data must be relayed through other D2D devices available, until a device with a direct connection to the network infrastructure has been reached.Due to the delicacy of the data exchanged, the trust level of each node authenticated in the mutual authentication phase must be measured before the data are sent. The trust evaluation enables the origin device to choose the path with the most reliable devices available for the relay of data. The trust system adopted follows the same idea of local trust presented by Yan et al. [12]. However, we have created our own calculations, which differ from those of [12], due to the use of symmetric cryptography for reducing costs.This phase is performed over an insecure channel. An architecture involving the use of relay devices, as shown in Figure2, is employed. After the measurement of local trust, all devices considered trusted are candidates to be relay devices.


#### 4.4.1. Local Trust Evaluation

The local trust evaluation is based on the experiences of nearby devices. Each device defines a trust threshold for deciding whether the devices are trustworthy or not.When a deviceDu wants to know if a device Du′ is trustworthy, it compares the LTDu′ level with the desired threshold LT. If it is higher than the threshold, device Du′ is considered trustworthy, and device Du can relay data through it. Otherwise, the communication is refused.Whenever a deviceDu wants to obtain LTDu′ of a device Du′, it sends TIDDu′ to another device Dk, which once communicated with device Du′, to request its local trust evaluation LTDu′.Dk generates local trust level LTDu′ of device Du′, encrypts the result with the session key generated between Dk and Du, and sends it to Du and Du′:(15)BDk−Du=ESKeyDk−DuLTDu′.Du decrypts the message and obtains the local trust level of Du′. It then checks if LTDu′ is acceptable by comparing it with the local trust threshold. If it is acceptable, Du calculates a local trust secret key:(16)LTKDu−u′=h3SrDiruvDi−u⊕vu−DiLTDu′.Otherwise, it must choose another available device suitable to relay the message.Figure5 shows a summary of the local trust evaluation phase.Figure 5
Messages exchanged when LT is used.


### 4.5. Encryption/Decryption

Finally, after the tests, the original device encrypts the data with session keySKeyDi−HSS:(17)M=ESKeyDi−HSSdata.The result (M) is encrypted with the proper key:(18)C=ELTKDu−Du′M.The message is sent to the most adequate device in the relay group withTDi¯5and ESKeyDu−Du′LTDu′. Then, Du′ calculates the secret key:(19)LTKDu−u′=h3SrDiruvDi−u⊕vu−DiLTDu′,decrypts the message, and obtainsM:(20)M=DLTKDu−u′C.Du′ encrypts M with its own trust information through Equation (17) and sends the resulting message to the most adequate device in the relay group with a timestamp TDi¯5. The process is repeated until the device nearest the 3GPP infrastructure has been reached. This device sends Mwith a timestamp TDm¯5 to HSS.HSS decryptsM using session key SKeyDi−HSS generated at the end of the mutual authentication phase, thus guaranteeing the legitimacy of the sender and the integrity of the data. It then forwards the patient’s information to the health center server, which sends it to the doctor on a secure channel. Finally, the doctor receives the data and evaluates them.Figure6 shows a summary of the encryption/decryption phase, with a focus on encryption.Figure 6
Encrypted data sent to HSS.


## 4.1. Initialization

Some important system parameters are generated in this phase, and all devices accredited by the health center server must perform the phase offline.Initially, HSS selects two random prime numbersp and q that satisfy condition q/p−1 and defines a finite field Zp∗ and a secure elliptic curve EZp∗. Next, it selects a group Gp of order p, Gqthat is a subgroup of Gp, g as the generation point of Gq, and Zq∗ as a prime field of order q. Then, it selects a random number zϵZq∗ as the master private key and calculates Mkpub=z∗g to obtain the master public key.HSS selects three hash functions (h1., h2., and h3.) (described in Table 1) for the mutual authentication phase and generates j random numbers, Rj, (j=1,2,⋯,i), for each device and for itself for the calculation of a set of temporary identities TIDDi:(1)TIDDi=h1IDDiRj∗z.It also selects its ownTIDHSS:(2)TIDHSS=h1IDHSSRj∗z.Next, it sends each device its respective set. A differentTIDDi is used whenever a new session has been established to provide a relay of data to a specific device. When the last TID available is being used, the device must notify the HSS after the authentication procedure. Then, HSS sends a new set of temporary identities encrypted with the freshly generated session key.HSS generates a piece of each device’s private key (similar to [15]), chooses a yϵZq, and calculates the following:(3)YDi=h2TIDDiy∗MKpub.Finally, it sets the partial key calculated for each respective device and publishes the following parameters:g,G,EZp∗,Mkpub,TIDHSS,h1.,h2.,h3.,H..


## 4.2. Registration

The ProSe device discovery mechanism is initially applied in this phase for the discovery of nearby devices, as described in [11]. The phase is performed over an insecure channel, and the main steps are described below.Each user generates a share of its private key (based on [13]) choosing xϵZq∗ and calculates its public key:(4)PKDi=x∗YDi∗g.Then, it sendsTIDDi,PKDi, and a timestamp TDi¯1 to the other devices and the nearby device sends HSS all the information received from relay devices.The device sets its private key as pairSKDi=x,YDi using the other share of its private key received from the HSS in the initialization phase.Each device chooses an integervDi−DjϵZq∗ as a secret value to be sent to other devices and HSS, encrypted with its public key, as follows:(5)VDi−Dj=EPKDivDi−Dj,where j represents either a device Dj or HSS.Consequently, only the correct device can decrypt the message and obtain the secret token. The secret values are broadcast to the entities involved in the communication, which find and decrypt them to obtain all secret values necessary for the generation of session keys.The asynchronous mode of the group authentication protocol designed by Harn [15] is considered for providing multiple authentications in a t-secure m-user n-group authentication scheme (GAS). In other words, for a group with n members, m-users are authenticated at once, with at most (t−1) compromised tokens; a unique token is assigned for each user of a group by the group manager for determining the membership of a user to a group. Therefore, considering what is proposed by [15], we have designed our authentication scheme as follows:First, HSS selects two random polynomialsflx,l=1,2 of degree t−1 each, where t≤n is the number of devices involved in the relay (i.e., number of tokens necessary for the recovery of secret S):(6)flx=∑i=0t−1aiximodp.All coefficients are in finite fieldZp∗.HSS generates two tokens for each device calculatingflTIDDi. Each TIDDi has its respective token. HSS also calculates its own two tokens flTIDHSS and finds integers wi,j,di,j,j=1,2ϵZp∗, such that S=∑j=0kdi,jfjwi,j, where wi,1≠wi,2 for every pair i and j. It then generates a secret S, as in [17]:(7)S=fl0=a0,(8)S=g∑j=12di,jfjwi,jmodqmodp.Finally, it chooses an integervHSS−DiϵZq∗ and sends it to the respective devices of the relay group:(9)AUTHDi=EPKDiTIDHSS,HS,wi,j,di,j,flTIDDi,vHSS−Di,TIDDi,THSS¯1.The devices decrypt the message and store the parameters.Figure3 shows a summary of the registration phase.Figure 3
Messages exchanged in the registration phase.


## 4.3. Mutual Authentication

Since the devices still must authenticate each other and HSS, each device selects a pair of nonusedTIDDi and respective tokens flTIDDi, l=1,2,⋯ and computes its Lagrange component (an adaptation of what is proposed in [15]) LCDi through the Lagrange interpolating formula:(10)LCDi=∑l=12di,lflTIDDi∏q=1;q≠inwi,l−TIDDi−qTIDDi−TIDDi−qmodq.Next, they calculateeDi=gLCDimodp.HSS also calculates its Lagrange componentLCHSS through the Lagrange interpolating formula:(11)LCHSS=∑l=12di,lflTIDHSS∏q=1;q≠inwi,l−TIDDi−qTIDHSS−TIDDi−qmodq.Its owneHSSwas also calculated:(12)eHSS=giLCHSSmodp.It generates a random valuerDiϵZq∗. The devices send TIDDi,eDi, rHSS, and a timestampTDi¯2 to the other devices in the relay group and to HSS, which also sends TIDHSS,eHSS, THSS¯2, andrHSS to the other devices in the relay group. After receiving such parameters, the entities verify the validity of the timestamp to avoid denial of service (DoS) attack. They proceed with the authentication only if the timestamp is valid. Otherwise, they discard the respective entity. When each entity has a complete set of eDi and eHSS, a secret S′ is calculated:(13)S′=eHSS∗∏i=1neDimodp=giLCHSS+∑LCDimodqmodp.Again, an attacker must solve the DLP problem to obtaineDi,eHSS, and S′, as in [15].Next, each device checks if theHS′ calculated is equal to the HSreceived from HSS in the registration phase. If HS=HS′, the devices and HSS are legit and mutually authenticated. If the verification fails, one or more intruders are in the path.Finally, a session key is generated for each possible connection between devicesDi and HSS.(14)SKeyDi−k=h3SrDiruvDi−u⊕vu−DiIn this stage, if the source device has direct access to the network infrastructure, it can encrypt its health information with the session key and send it to the core network. Otherwise, it must execute phase 3.4 prior to phase 3.5.Figure4 shows a summary of the mutual authentication phase.Figure 4
A message exchanged in the mutual authentication phase.


## 4.4. Trust Evaluation

This phase is executed whenever a patient that must send his/her health information to the doctor/physician is not in the coverage area of a 3GPP cell. Therefore, data must be relayed through other D2D devices available, until a device with a direct connection to the network infrastructure has been reached.Due to the delicacy of the data exchanged, the trust level of each node authenticated in the mutual authentication phase must be measured before the data are sent. The trust evaluation enables the origin device to choose the path with the most reliable devices available for the relay of data. The trust system adopted follows the same idea of local trust presented by Yan et al. [12]. However, we have created our own calculations, which differ from those of [12], due to the use of symmetric cryptography for reducing costs.This phase is performed over an insecure channel. An architecture involving the use of relay devices, as shown in Figure2, is employed. After the measurement of local trust, all devices considered trusted are candidates to be relay devices.


### 4.4.1. Local Trust Evaluation

The local trust evaluation is based on the experiences of nearby devices. Each device defines a trust threshold for deciding whether the devices are trustworthy or not.When a deviceDu wants to know if a device Du′ is trustworthy, it compares the LTDu′ level with the desired threshold LT. If it is higher than the threshold, device Du′ is considered trustworthy, and device Du can relay data through it. Otherwise, the communication is refused.Whenever a deviceDu wants to obtain LTDu′ of a device Du′, it sends TIDDu′ to another device Dk, which once communicated with device Du′, to request its local trust evaluation LTDu′.Dk generates local trust level LTDu′ of device Du′, encrypts the result with the session key generated between Dk and Du, and sends it to Du and Du′:(15)BDk−Du=ESKeyDk−DuLTDu′.Du decrypts the message and obtains the local trust level of Du′. It then checks if LTDu′ is acceptable by comparing it with the local trust threshold. If it is acceptable, Du calculates a local trust secret key:(16)LTKDu−u′=h3SrDiruvDi−u⊕vu−DiLTDu′.Otherwise, it must choose another available device suitable to relay the message.Figure5 shows a summary of the local trust evaluation phase.Figure 5
Messages exchanged when LT is used.


## 4.4.1. Local Trust Evaluation

The local trust evaluation is based on the experiences of nearby devices. Each device defines a trust threshold for deciding whether the devices are trustworthy or not.When a deviceDu wants to know if a device Du′ is trustworthy, it compares the LTDu′ level with the desired threshold LT. If it is higher than the threshold, device Du′ is considered trustworthy, and device Du can relay data through it. Otherwise, the communication is refused.Whenever a deviceDu wants to obtain LTDu′ of a device Du′, it sends TIDDu′ to another device Dk, which once communicated with device Du′, to request its local trust evaluation LTDu′.Dk generates local trust level LTDu′ of device Du′, encrypts the result with the session key generated between Dk and Du, and sends it to Du and Du′:(15)BDk−Du=ESKeyDk−DuLTDu′.Du decrypts the message and obtains the local trust level of Du′. It then checks if LTDu′ is acceptable by comparing it with the local trust threshold. If it is acceptable, Du calculates a local trust secret key:(16)LTKDu−u′=h3SrDiruvDi−u⊕vu−DiLTDu′.Otherwise, it must choose another available device suitable to relay the message.Figure5 shows a summary of the local trust evaluation phase.Figure 5
Messages exchanged when LT is used.


## 4.5. Encryption/Decryption

Finally, after the tests, the original device encrypts the data with session keySKeyDi−HSS:(17)M=ESKeyDi−HSSdata.The result (M) is encrypted with the proper key:(18)C=ELTKDu−Du′M.The message is sent to the most adequate device in the relay group withTDi¯5and ESKeyDu−Du′LTDu′. Then, Du′ calculates the secret key:(19)LTKDu−u′=h3SrDiruvDi−u⊕vu−DiLTDu′,decrypts the message, and obtainsM:(20)M=DLTKDu−u′C.Du′ encrypts M with its own trust information through Equation (17) and sends the resulting message to the most adequate device in the relay group with a timestamp TDi¯5. The process is repeated until the device nearest the 3GPP infrastructure has been reached. This device sends Mwith a timestamp TDm¯5 to HSS.HSS decryptsM using session key SKeyDi−HSS generated at the end of the mutual authentication phase, thus guaranteeing the legitimacy of the sender and the integrity of the data. It then forwards the patient’s information to the health center server, which sends it to the doctor on a secure channel. Finally, the doctor receives the data and evaluates them.Figure6 shows a summary of the encryption/decryption phase, with a focus on encryption.Figure 6
Encrypted data sent to HSS.


## 5. Security Analysis

This section reports on a security analysis of all D2D communication security devices and discusses the way they are approached by the proposed scheme.


### 5.1. Mutual Authentication

Devices perform mutual authentication to authenticate the other devices in the relay group. Each device calculates its Lagrange component (LCDi) and eDi, and they share eDi with the other devices in the relay group. Next, they calculate secret S′ and HS′ and compare the value obtained with the HS received from HSS in the registration phase. If HS′=HS, all devices involved are mutually authenticated. Otherwise, the operation is terminated.After mutual authentication, the devices start the mutual authentication procedure with HSS. Each device generatesMACDi and sends it with the respective TIDDi to HSS, which calculates MAC′Di and checks if MAC′Di=MACDi. If the values are equal, HSS authenticates the devices and proceeds. Otherwise, the operation is terminated. Then, HSS generates its own Lagrange component LCHSS and eHSS and sends eHSS to the group of relay devices. Each device recalculates its own Lagrange component LCnewDi, eDi−new, and a new secret S″ and compares S″ with secret S′ previously calculated. If S″=S′, HSS is authenticated by the devices. In the proposed scheme, an attacker finds a Lagrange component by solving the DLP problem, which has proven computationally infeasible.


### 5.2. Forward/Backward Secrecy of Session Key

Forward secrecy guarantees an intruder with access to an old key does not use it in the future for forging its authenticity. On the other hand, backward secrecy provides security against the use of newer keys for access to information originated in older sections. In the proposed scheme, forward and backward secrecies of the session key are guaranteed through the use of freshly generated random valuesrDi, timestamps TDi, and session keys SKDi−HSS/SKDi−Dk in each authentication procedure.


### 5.3. Confidentiality

The scheme provides confidentiality of patients’ data by generating a different session keySKDi−HSS/SKDi−Dk in each session established between any device and HSS. All data exchanged over an insecure channel are encrypted with the respective session key, whose security is ensured.


### 5.4. Integrity

Data integrity is guaranteed by the encryption of the data sent by each patient through a securely established session keySKDi−HSS/SKDi−Dk before it is sent over an insecure channel. When HSS decrypts the messages with the appropriate session key, it knows the information was generated by the genuine source and not modified on the way to the destination.


### 5.5. Anonymity

The anonymity of entities, devices, and HSS is safeguarded through the exchange of only temporary identities (TIDDi, TIDHSS) over an insecure channel. Therefore, the permanent identities are not disclosed over an insecure channel. HSS knows the permanent identity of all devices; however, this information is obtained offline.


### 5.6. Nonrepudiation

Nonrepudiation certifies an entity cannot deny its actions. In the proposed scheme, it is guaranteed through the use of permanent (IDDi) and temporary identities (TIDDi,TIDHSS) and private and public keys.


### 5.7. Session Key Security

The security of the session key is ensured by confidential informationYDi and IDDi in its generation process, as shown in Equation (13).


### 5.8. Resistance to Impersonation Attack

Impersonation attack is avoided by different temporary identities in each session established. ATID is never used twice and HSS can recognize whether a certain TIDhas already been used.


### 5.9. Resistance to Replay Attack

A replay attack is avoided by freshly generated parameters, such as random valuesrDi and timestamps TDi in the mutual authentication phase, generation of session keys, and use of different TIDDi and TIDHSS in each session.


### 5.10. Resistance to Denial of Service (DoS) Attack

The use of timestamps in each message exchanged over an insecure channel avoids denial of service (DoS) attacks. Each timestamp is synchronized with its respective entity’s clock, which is also synchronized with the whole system.


### 5.11. Resistance to Man-in-the-Middle Attack

Session keys and local trust keys do not depend only on values exchanged on an insecure channel, but on secret values securely exchanged in the registration phase encrypted with devices’ public key.Such security objectives were not accomplished by [13, 16 and [18]. First, any of the compared protocol performs the trust evaluation of relay devices. Secondly, as shown by [14], the scheme proposed in [13] is vulnerable to an insider attack, which compromises its confidentiality and might also affect patients’ privacy and the protocol’s resistance to replay and man-in-the-middle attacks.The schemes proposed by [13, 16] are vulnerable to DoS attacks, since they do not use verification values as nonces or timestamps prior to the execution of more complex calculations. The scheme designed by [18] does not protect the anonymity of devices because it does not mention the use of temporary or pseudoidentity instead of their permanent identities.Table2 shows a comparison among our scheme and those of [13, 18] and [16].Table 2
Comparison of security objectives among protocols.
Security objectivesZhang et al. [13]Mustafa [18]Zhou [16]Proposed protocolMutual authenticYesYesYesYesTrust evaluationNoNoNoYesConfidentialityNoYesYesYesIntegrityYesYesYesYesPrivacyNoYesYesYesAnonymityYesNoYesYesForward/backward secrecyYesYesYesYesNonrepudiationYesYesYesYesSession key securityYesYesYesYesResistance to replay attackNoYesYesYesResistance to insider attackNoYesYesYesResistance to DoS attackNoYesNoYesResistance to man-in-the-middle attackNoYesYesYes


## 5.1. Mutual Authentication

Devices perform mutual authentication to authenticate the other devices in the relay group. Each device calculates its Lagrange component (LCDi) and eDi, and they share eDi with the other devices in the relay group. Next, they calculate secret S′ and HS′ and compare the value obtained with the HS received from HSS in the registration phase. If HS′=HS, all devices involved are mutually authenticated. Otherwise, the operation is terminated.After mutual authentication, the devices start the mutual authentication procedure with HSS. Each device generatesMACDi and sends it with the respective TIDDi to HSS, which calculates MAC′Di and checks if MAC′Di=MACDi. If the values are equal, HSS authenticates the devices and proceeds. Otherwise, the operation is terminated. Then, HSS generates its own Lagrange component LCHSS and eHSS and sends eHSS to the group of relay devices. Each device recalculates its own Lagrange component LCnewDi, eDi−new, and a new secret S″ and compares S″ with secret S′ previously calculated. If S″=S′, HSS is authenticated by the devices. In the proposed scheme, an attacker finds a Lagrange component by solving the DLP problem, which has proven computationally infeasible.


## 5.2. Forward/Backward Secrecy of Session Key

Forward secrecy guarantees an intruder with access to an old key does not use it in the future for forging its authenticity. On the other hand, backward secrecy provides security against the use of newer keys for access to information originated in older sections. In the proposed scheme, forward and backward secrecies of the session key are guaranteed through the use of freshly generated random valuesrDi, timestamps TDi, and session keys SKDi−HSS/SKDi−Dk in each authentication procedure.


## 5.3. Confidentiality

The scheme provides confidentiality of patients’ data by generating a different session keySKDi−HSS/SKDi−Dk in each session established between any device and HSS. All data exchanged over an insecure channel are encrypted with the respective session key, whose security is ensured.


## 5.4. Integrity

Data integrity is guaranteed by the encryption of the data sent by each patient through a securely established session keySKDi−HSS/SKDi−Dk before it is sent over an insecure channel. When HSS decrypts the messages with the appropriate session key, it knows the information was generated by the genuine source and not modified on the way to the destination.


## 5.5. Anonymity

The anonymity of entities, devices, and HSS is safeguarded through the exchange of only temporary identities (TIDDi, TIDHSS) over an insecure channel. Therefore, the permanent identities are not disclosed over an insecure channel. HSS knows the permanent identity of all devices; however, this information is obtained offline.


## 5.6. Nonrepudiation

Nonrepudiation certifies an entity cannot deny its actions. In the proposed scheme, it is guaranteed through the use of permanent (IDDi) and temporary identities (TIDDi,TIDHSS) and private and public keys.


## 5.7. Session Key Security

The security of the session key is ensured by confidential informationYDi and IDDi in its generation process, as shown in Equation (13).


## 5.8. Resistance to Impersonation Attack

Impersonation attack is avoided by different temporary identities in each session established. ATID is never used twice and HSS can recognize whether a certain TIDhas already been used.


## 5.9. Resistance to Replay Attack

A replay attack is avoided by freshly generated parameters, such as random valuesrDi and timestamps TDi in the mutual authentication phase, generation of session keys, and use of different TIDDi and TIDHSS in each session.


## 5.10. Resistance to Denial of Service (DoS) Attack

The use of timestamps in each message exchanged over an insecure channel avoids denial of service (DoS) attacks. Each timestamp is synchronized with its respective entity’s clock, which is also synchronized with the whole system.


## 5.11. Resistance to Man-in-the-Middle Attack

Session keys and local trust keys do not depend only on values exchanged on an insecure channel, but on secret values securely exchanged in the registration phase encrypted with devices’ public key.Such security objectives were not accomplished by [13, 16 and [18]. First, any of the compared protocol performs the trust evaluation of relay devices. Secondly, as shown by [14], the scheme proposed in [13] is vulnerable to an insider attack, which compromises its confidentiality and might also affect patients’ privacy and the protocol’s resistance to replay and man-in-the-middle attacks.The schemes proposed by [13, 16] are vulnerable to DoS attacks, since they do not use verification values as nonces or timestamps prior to the execution of more complex calculations. The scheme designed by [18] does not protect the anonymity of devices because it does not mention the use of temporary or pseudoidentity instead of their permanent identities.Table2 shows a comparison among our scheme and those of [13, 18] and [16].Table 2
Comparison of security objectives among protocols.
Security objectivesZhang et al. [13]Mustafa [18]Zhou [16]Proposed protocolMutual authenticYesYesYesYesTrust evaluationNoNoNoYesConfidentialityNoYesYesYesIntegrityYesYesYesYesPrivacyNoYesYesYesAnonymityYesNoYesYesForward/backward secrecyYesYesYesYesNonrepudiationYesYesYesYesSession key securityYesYesYesYesResistance to replay attackNoYesYesYesResistance to insider attackNoYesYesYesResistance to DoS attackNoYesNoYesResistance to man-in-the-middle attackNoYesYesYes


## 6. Performance Analysis

This section reports on a performance analysis of our protocol regarding computational and energy costs in each authentication session executed, and a performance comparison among our scheme and those of [13, 16].


### 6.1. Computational Costs

The evaluation of computational costs is based on an estimate of the time necessary for the execution of unitary operations, considered part of the messages previously described in the different phases of the protocol. Table3 shows such unitary operations (hash, multiplication, and addition over elliptical curve, exponentiation,…) with the corresponding computational costs (running times, measured in milliseconds) for both devices and the fixed part of the cellular wireless network.Table 3
Cost of each unitary operation.
NotationDevices (ms)Network (ms)DescriptionThash0.2010.067Cost of a one-way hash operationTmul1.840.612Cost of a multiplication operation over an elliptical curve, represented as∗Tadd0.3750.125Cost of an addition operation over an elliptical curveTmod0.3720.124Cost of a modular operationTexp0.370.123Cost of an exponential operationTpair13.534.51Cost of a bilinear pairing operationTPK1.10.367Cost of public key encryptionTAES0.4830.161Cost of an AES encryption/decryption operationThe cost values are based on common and realistic values obtained by experimentation and adopted for performance comparisons of authentication protocols, as in Choi et al. 2014 [8] and Hsu et al. 2018 [21].The computational platform was configured as follows:(i)
Intel Core Duo 1.86 GHz and 2 gigabyte RAM under an Ubuntu 11.10 operating system [8](ii)
HTC One X smartphone with Android 4.1.1, 1.5 GHz Quad-core ARM Cortex-A9 CPU, 1 GB RAM [21]The methodology adopted for the performance evaluation considers the cost of each unitary operation multiplied by the number of times each operation is executed, comprehending the several messages that include one or more of such unitary operations, as required for the different authentication protocols.Table4 shows a comparison of the computational costs (in milliseconds) among our protocol and those designed by [13, 16]. An environment with “n” devices registered in the 3GPP network and “m” devices involved in the relay of the messages sent from the source device and the HSS was considered. Only the devices involved in the relay of data performed the calculations of the trust evaluation phase.Table 4
Comparison of computational costs.
ProtocolDevices (ms)Server network (ms)Total (ms)Zhang et al. [13]3n+3m+9Tmul+2nTmod+4m+9Thash+2nTexp+n+4m+2Tadd+3TECC=7.38n+7.83m+22.42n+6Tmul+2nTmod+n+7Thash+2nTexp+n+2Tadd+2TECC=1.3n+5.134n+3m+15Tmul+4nTexp+n+4m+16Thash+4nTexp+2n+4m+4Tadd+5TECC=8.68n+7.83m+27.53Zhou [16]3n+3m+11Tmul+2n+2Tmod+4m+12Thash+2nTexp+n+4m+2Tadd+TECC=7.38n+7.83m+25.25n+10Tmul+2nTmod+n+6Thash+2nTexp+n+5Tadd+TECC=1.3n+7.524n+3m+21Tmul+4n+2Tmod+n+4m+18Thash+4nTexp+2n+4m+7Tadd+2TECC=8.68n+7.83m+32.77Proposed protocolnTmul+3nTmod+n+2mThash+nTexp+3nTECC+3m+1TAES=6.83n+1.85m+0.48n+1Tmul+2n+7Tmod+3nThash+2n+4Texp+nTECC+TAES=1.67n+2.13n+1Tmul+5n+7Tmod+4n+3mThash+3n+4Texp+4nTECC+4m+2TAES=8.5n+1.85m+2.61The devices takenTmul+3nTECC in the registration phase to calculate their partial public key and encrypt/decrypt secret values vDi−Du. Then, they take 3nTmod+nThash+nTexp in the mutual authentication and key agreement phase to calculate their Lagrange component, secret S′, and session key SKeyDi−k. Next, mThash+mTAES is required for the encryption of local trust result LTDu′ and local trust secret key LTKDu−u′ is calculated. Finally, the devices expend mThash+2m+1TAES to encrypt the patients’ information generating M and encrypting/decrypting M with local trust secret key LTKDu−u′. Consequently, the total computational cost for the devices is nTmul+3nTmod+n+2mThash+nTexp+3nTECC+3m+1TAES. According to Table 4, the computational cost for the devices is 6.827n+1.851m+0.483ms.3GPP network takesn+1Tmul+2nThash to calculate temporary identities and partial private keys for each device and its master public key in the initialization phase. It takes 2n+4Tmod+2n+3Texp+nTECC to generate tokens for each device and for itself in the registration phase. Next, it requires 3Tmod+nThash+Texp to calculate the Lagrange component of HSS, secret S′, and session keys SKeyDi−HSS. Finally, it takes TAES to decrypt message M and obtain the source patient’s information. Therefore, the computational cost for the core network is n+1Tmul+2n+7Tmod+3nThash+2n+4Texp+nTECC+TAES. According to the operation costs in Table 4, the computational cost for the network is 1.674n+2.133ms.The lines in Figure7 show satisfactory results of our protocol regarding computational costs. A situation in which 25% of devices are involved in the relay of data was considered. The protocol clearly showed better costs than [13, 16]; [16] yielded slightly different results from [13].Figure 7
Comparison of computational costs.Regarding the similarity involving the results of [13, 16] is an improvement of [13], and, consequently, most calculations are similar.The main difference between [13, 16] is the correction of security vulnerabilities, made in [16] with the use of more variables in the authentication procedure. In terms of operations, [16] requires the calculation of only an extra elliptic curve cryptography-based (ECC-based) scalar multiplication on G1 when compared to [13]; such operation requires small processing time.Our scheme has shown excellent computational performance regarding all subjects addressed. The use of Shamir’s secret sharing in the authentication phase reduces the computational resources consumption, since all devices and HSS are authenticated with a single calculation and comparison of secretsS′ and S, respectively.


### 6.2. Energy Costs

This section reports on an analysis of the energy cost of our protocol and a comparison with [13, 16]. The evaluation is based on the proposals of Kumar et al. [22] and He et al. [23], which consider 10.88 Watts the maximum CPU power of devices (W). The following operation was performed for the calculation of the energy overhead: ETotal=CCTotal×W, where CCTotal is the computational cost of each operation. Table 5 shows the results.Table 5
Comparison of energy costs.
ProtocolDevicesNetworkTotal (mJ)Zhang et al. [13]80.3n+85.2m+243.9314.14n+55.8194.44n+85.19m+299.53Zhou [16]80.3n+85.2m+274.7214.14n+81.8294.44n+85.19m+356.54Proposed protocol74.31n+20.13m+5.2218.17n+23.1792.48n+20.13m+28.4Figure8 shows a comparison based on the energy costs provided in Table 5. The red line representing our protocol proves its lower energy consumption in comparison to the protocols of [13, 16]. As in the evaluation of computational costs, the energy costs of [13, 16] were similar.Figure 8
Comparison of energy costs.The main differences between [13, 16] that lead to consequences in the energy costs are the same of the computational costs. Our scheme also shows higher energy efficiency due to reduced processing efforts and computational cost.


## 6.1. Computational Costs

The evaluation of computational costs is based on an estimate of the time necessary for the execution of unitary operations, considered part of the messages previously described in the different phases of the protocol. Table3 shows such unitary operations (hash, multiplication, and addition over elliptical curve, exponentiation,…) with the corresponding computational costs (running times, measured in milliseconds) for both devices and the fixed part of the cellular wireless network.Table 3
Cost of each unitary operation.
NotationDevices (ms)Network (ms)DescriptionThash0.2010.067Cost of a one-way hash operationTmul1.840.612Cost of a multiplication operation over an elliptical curve, represented as∗Tadd0.3750.125Cost of an addition operation over an elliptical curveTmod0.3720.124Cost of a modular operationTexp0.370.123Cost of an exponential operationTpair13.534.51Cost of a bilinear pairing operationTPK1.10.367Cost of public key encryptionTAES0.4830.161Cost of an AES encryption/decryption operationThe cost values are based on common and realistic values obtained by experimentation and adopted for performance comparisons of authentication protocols, as in Choi et al. 2014 [8] and Hsu et al. 2018 [21].The computational platform was configured as follows:(i)
Intel Core Duo 1.86 GHz and 2 gigabyte RAM under an Ubuntu 11.10 operating system [8](ii)
HTC One X smartphone with Android 4.1.1, 1.5 GHz Quad-core ARM Cortex-A9 CPU, 1 GB RAM [21]The methodology adopted for the performance evaluation considers the cost of each unitary operation multiplied by the number of times each operation is executed, comprehending the several messages that include one or more of such unitary operations, as required for the different authentication protocols.Table4 shows a comparison of the computational costs (in milliseconds) among our protocol and those designed by [13, 16]. An environment with “n” devices registered in the 3GPP network and “m” devices involved in the relay of the messages sent from the source device and the HSS was considered. Only the devices involved in the relay of data performed the calculations of the trust evaluation phase.Table 4
Comparison of computational costs.
ProtocolDevices (ms)Server network (ms)Total (ms)Zhang et al. [13]3n+3m+9Tmul+2nTmod+4m+9Thash+2nTexp+n+4m+2Tadd+3TECC=7.38n+7.83m+22.42n+6Tmul+2nTmod+n+7Thash+2nTexp+n+2Tadd+2TECC=1.3n+5.134n+3m+15Tmul+4nTexp+n+4m+16Thash+4nTexp+2n+4m+4Tadd+5TECC=8.68n+7.83m+27.53Zhou [16]3n+3m+11Tmul+2n+2Tmod+4m+12Thash+2nTexp+n+4m+2Tadd+TECC=7.38n+7.83m+25.25n+10Tmul+2nTmod+n+6Thash+2nTexp+n+5Tadd+TECC=1.3n+7.524n+3m+21Tmul+4n+2Tmod+n+4m+18Thash+4nTexp+2n+4m+7Tadd+2TECC=8.68n+7.83m+32.77Proposed protocolnTmul+3nTmod+n+2mThash+nTexp+3nTECC+3m+1TAES=6.83n+1.85m+0.48n+1Tmul+2n+7Tmod+3nThash+2n+4Texp+nTECC+TAES=1.67n+2.13n+1Tmul+5n+7Tmod+4n+3mThash+3n+4Texp+4nTECC+4m+2TAES=8.5n+1.85m+2.61The devices takenTmul+3nTECC in the registration phase to calculate their partial public key and encrypt/decrypt secret values vDi−Du. Then, they take 3nTmod+nThash+nTexp in the mutual authentication and key agreement phase to calculate their Lagrange component, secret S′, and session key SKeyDi−k. Next, mThash+mTAES is required for the encryption of local trust result LTDu′ and local trust secret key LTKDu−u′ is calculated. Finally, the devices expend mThash+2m+1TAES to encrypt the patients’ information generating M and encrypting/decrypting M with local trust secret key LTKDu−u′. Consequently, the total computational cost for the devices is nTmul+3nTmod+n+2mThash+nTexp+3nTECC+3m+1TAES. According to Table 4, the computational cost for the devices is 6.827n+1.851m+0.483ms.3GPP network takesn+1Tmul+2nThash to calculate temporary identities and partial private keys for each device and its master public key in the initialization phase. It takes 2n+4Tmod+2n+3Texp+nTECC to generate tokens for each device and for itself in the registration phase. Next, it requires 3Tmod+nThash+Texp to calculate the Lagrange component of HSS, secret S′, and session keys SKeyDi−HSS. Finally, it takes TAES to decrypt message M and obtain the source patient’s information. Therefore, the computational cost for the core network is n+1Tmul+2n+7Tmod+3nThash+2n+4Texp+nTECC+TAES. According to the operation costs in Table 4, the computational cost for the network is 1.674n+2.133ms.The lines in Figure7 show satisfactory results of our protocol regarding computational costs. A situation in which 25% of devices are involved in the relay of data was considered. The protocol clearly showed better costs than [13, 16]; [16] yielded slightly different results from [13].Figure 7
Comparison of computational costs.Regarding the similarity involving the results of [13, 16] is an improvement of [13], and, consequently, most calculations are similar.The main difference between [13, 16] is the correction of security vulnerabilities, made in [16] with the use of more variables in the authentication procedure. In terms of operations, [16] requires the calculation of only an extra elliptic curve cryptography-based (ECC-based) scalar multiplication on G1 when compared to [13]; such operation requires small processing time.Our scheme has shown excellent computational performance regarding all subjects addressed. The use of Shamir’s secret sharing in the authentication phase reduces the computational resources consumption, since all devices and HSS are authenticated with a single calculation and comparison of secretsS′ and S, respectively.


## 6.2. Energy Costs

This section reports on an analysis of the energy cost of our protocol and a comparison with [13, 16]. The evaluation is based on the proposals of Kumar et al. [22] and He et al. [23], which consider 10.88 Watts the maximum CPU power of devices (W). The following operation was performed for the calculation of the energy overhead: ETotal=CCTotal×W, where CCTotal is the computational cost of each operation. Table 5 shows the results.Table 5
Comparison of energy costs.
ProtocolDevicesNetworkTotal (mJ)Zhang et al. [13]80.3n+85.2m+243.9314.14n+55.8194.44n+85.19m+299.53Zhou [16]80.3n+85.2m+274.7214.14n+81.8294.44n+85.19m+356.54Proposed protocol74.31n+20.13m+5.2218.17n+23.1792.48n+20.13m+28.4Figure8 shows a comparison based on the energy costs provided in Table 5. The red line representing our protocol proves its lower energy consumption in comparison to the protocols of [13, 16]. As in the evaluation of computational costs, the energy costs of [13, 16] were similar.Figure 8
Comparison of energy costs.The main differences between [13, 16] that lead to consequences in the energy costs are the same of the computational costs. Our scheme also shows higher energy efficiency due to reduced processing efforts and computational cost.


## 7. AVISPA Verification

The protocol was validated by Automated Validation of Internet Security Protocols and Applications (AVISPA) [24], which simulates messages exchanged among entities involved in an authentication scheme. AVISPA simulation is written in High-level Protocol Specification Language (HLPSL), which divides the message exchanged into roles representing each entity involved in the authentication procedure.Figure9 shows an example of the role of an ordinary D2D communication device. The objectives verified were ability of the protocol to perform D2D mutual authentication and key agreement and secrecy of session keys.Figure 9
Role of a device in HLPSL language for AVISPA software.AVISPA has four backends to verify security. We used two of them, namely, On-the-Fly-Model-checker (OFMC) [25] and Constraint Logic-Based Attack Searcher (CL-AtSe) [26], which return “SAFE” if the protocol analyzed is considered safe, and “UNSAFE” if it has found an issue that might compromise security. According to Figures 10 and 11, the protocol was considered safe.Figure 10
OFMC analysis.Figure 11
CL-AtSe analysis.


## 8. Conclusions and Future Work

Internet of Things (IoT) devices have been designed for several new applications and creation of a framework of benefits that improves services and people’s life quality, assures safety and security, and reduces expenses [27]. Some of such applications include solutions for m-health, which enable patients to share information on their health to be monitored or receive fast aid in emergencies, thus improving the quality of care [28]. D2D communication is suitable for m-health IoT applications, since it provides direct communication among devices with no intermediation of infrastructures, such as the one available by 3GPP.The traditional authentication and key agreement standardized by 3GPP is not suitable for D2D authentication and therefore cannot deal with the lack of access to the network infrastructure faced by some devices. New applications that exchange critical data (e.g., m-health applications) require novel AKA schemes to fulfill such a demand. A good alternative is the relay of data through close devices until the network infrastructure has been reached, as proposed by [12].Our protocol has been designed to provide a new AKA scheme; it aims at fulfilling the security properties detailed by 3GPP specifications TS 23.303 [19] and TS 33.303 [11] and reducing resource consumption. Such a reduction has been achieved by the scheme adopted, as proposed by Harn [15], based on Shamir’s secret sharing [17]. A trust evaluation indicated the close devices suitable for the relay of data; it was based on the scheme developed by [12], to guarantee the delivery of data from the source device to the health centerSeveral security properties and resistance to attacks, as addressed in Section5.4, demonstrated the robustness of our protocol, which has proven safer than those of [13, 16]. The protocol designed by [13] showed confidentiality issues and, consequently, is not resistant to attacks (e.g., insider and man-in-the-middle). The scheme of [16] is not resistant to DoS attack, and the one developed by [18] shows anonymity problems, since it offers no protection to devices’ real identities.Our protocol has proven the safest, because it has fulfilled all security objectives required by [11, 19], as shown in Table 2, and achieved better performance, in comparison to [13, 16], which have similar costs due to their similarity. The validation made by AVISPA with the use of two of its backends also confirmed the safety of the protocol regarding message exchange of secret parameters. Therefore, no intruder can discover confidential and critical parameters and information.Our protocol is part of a project that involves the development of software applications, which benefit from the junction of D2D communications and edge computing. Among the application areas considered are smart cities, e-health/m-health, and smart grid networks.Future work will include the proposal of authentication and authorization protocols based on cyber-physical systems ([28, 29]), as well as the formal validation of our protocol by tools, such as ProVerif and Tamarin. The simulation of our protocol by NS-3 or OMNET++ tools has been considered for the evaluation of energy efficiency and influence of device mobility.



---

*Source: 8876807-2020-10-27.xml*