A Mutual Authentication Protocol for Telecare Services in an IoT Network

: The emergence of Internet of Things (IoT), Cloud computing as well as the introducing of device to deice communication for devices in proximity has resulted in the emerging of new innovative services such as Tele-care in the health sector. However, issues such as privacy and security associated with such a service (Tele-care) are a challenge as most of the associated devices are resource constrained in terms of both operational power and computing capability requirements. As such it becomes problematic to implement any traditional as well as current privacy and security measures. Thus, in this paper, we mitigate on a framework to that will ensure a robust privacy as well as security for a Tele-care service. Notably our focus is in ensuring computational simplicity, privacy preservation as well as energy efficiency. Overall analysis shows that the proposed protocol has improved performance in comparison with existing ones.


Figure.1. Tele-care system
Likewise, at devices level, each device performs a mandatory mutual authentication with the cloud server before any data exchange sessions can be sanctioned. Not all devices are within the 3GPP coverage infrastructure. Only those within its coverage may use it to access the cloud server. Otherwise, those which are not within coverage ranges rely on D2D communication to perform mutual authentication, prior to dispatching any patients related reports. Relays will also assist other D2D devices to reach the cloud servers. Devices that connect directly to the 3GPP infrastructure may also utilize D2D communication for data exchanges with the cloud and other key parties. The medical personnel, namely medical doctors are also expected to mutually authenticate before gaining access to a patient's records.
We next summarize the mandatory details of the multi-phase mutual authentication between the various entities (including patients and devices) and the cloud server as follows: used.

Related Work
The task of contention minimization in OBS switched backbone networks is accomplished by proper dimensioning of necessary and available resources at wavelength assignment, link and path levels. The key constraint being that more than one data burst cannot be assigned the same wavelength concurrently on the same link. At wavelength assignment level, various schemes such as random wavelength assignment, first-fit (FF), minimum product, maximum sum, best-fit least loaded, least utilized, most frequently used and relative capacity loss have been explored [4]. The FF scheme generally performs relatively better in terms of burst loss probability and fairness. Furthermore, it has low computational overhead and complexity. To maximize on the number of simultaneous end-to-end lightpath connections, wavelength reassignment algorithms using minimum overlap and reconfiguration techniques have been suggested [5]. However, the suggested techniques only slightly reduce the blocking probabilities. The priority-based FF offline wavelength assignment scheme proposed in 6 is geared towards maximizing both the number of simultaneous connections as well as low burst losses. With this scheme, the wavelengths to be utilized for the connection requests are prioritized according to their estimated burst loss probabilities. The priority-based FF approach requires a longer setup time as it requires extra processing time to further estimate the loss probabilities on each selected lightpath connection. At link and path levels, it is desirable that the shortest light path(s) from ingress to egress node be utilized, subject to constraints such as traffic load, congestion as well as wavelength assignment. As suggested in [7], efficient routing can be partly achieved by ensuring that path computation is optimized as much as possible. Examples include the Dijkstra algorithm-based routing protocols such as the Open Shortest Path First (OSPF) and the Intermediate System to Intermediate System (ISIS). Whereas they always thrive to find an optimal path for each ingress to egress node pair, they however cause the same shortest links to become congested as well as be prone to contentions. With respect to the ingress-node destination pair, the longer paths remain underutilized and overall there is traffic imbalance in the network. In order to counter this, authors in [8] propose a distributed Path Computation Element (PCE) that enables routing protocols to efficiently utilize all available network links. PCE also applies software-defined networking (SDN) paradigms to separate signaling and routing paths, thus giving more network control to operators and in that way, contentions are reduced overall. An algorithm called the Self-Tuned Adaptive Routing (STAR) [9], was further incorporated to enhance traffic balancing as well prevent links from being overwhelmed.
A dynamic contention as well as congestion aware scheme that seeks to reduce blocking probabilities as well as boosting utilization by symmetrically distributing network traffic over all active links was proposed in [10]. Finally,in [11], the researchers proposed and investigated a per-link congestion control-based scheme that seeks to balance available network resources allocation by utilizing present and forecast demands of lightpath requests statistics. In essence, practical networks have a regularized topology and lightpath connection requests are generally random in nature. Given a fixed amount of resources (link, wavelengths, paths, as well as constraints), an increase in the traffic load results in the reduction of the number of idle resources per link and hence this will lead to both contention as well as blockings.

Proposed Authentication Protocol
We now proceed to describe, discuss as well as analyze the Group Authentication scheme in a D2D Communication based telecare framework which among other things will involve as well as enable large volumes of confidential health related data It was proposed in [6] and it is symmetric cryptography based. Fig  1.in section II is provided to illustrate the system overall.
We next summarize the mandatory details of the multi-phase mutual authentication between the various entities (including patients and devices) and the cloud server as follows: used.

Device Discovery Scheme
For the invoking of any service, which might include several devices, each of the group members must perform neighbor device discovery to identify collaborating devices within vicinity. Each device does that via the HSS. The Home Subscriber Server (HSS) will in turn verify whether its International Mobile Subscriber Identity (IMSI) matches the device records in its database and whether the device is indeed authorized (privileged) for the intended service, plus it is D2D communication compliant. Upon successful verification, the authorization will be relayed to eNB and at the same time tagged with a timer.
Next, all verified devices belonging to a group can now mutually identify each other as belonging to that group by possibly using WLAN direct radio signals is sharing their attributes.

Registration Phase
Key mutual authentication-related primitives are exchanged during this phase, The IMSI of each device must be registered in the HSS and normally this is done by the vendor. All key personnel and patients are registered to the cloud server via some identified secured channel. Each device is assigned a temporary identity.
where k R is an arbitrary chosen random number that will remain mapped to their real identities y ID ; 1 h is a hash function for the y TID generation. Both the real and temporary IDs will be furnished to the cloud server for storage and subsequent use in other authentication phases.

Hospital Uploading Phase (HUP)
This phase is exclusive to registered entities. At this stage, preparations are being made to mutually authenticate parties that will be involved in the updating of any data acquired from the patient. The authentication does not necessarily need to be done on a secured channel. Rather an unsecured channel is preferred for the purpose. The phase commences with the would be patient (user) paying a visit to his/her nearest health center for a health checkup. Alternatively, this could be due to some evident ailment. At the health center the patient will be issued with login credentials which can now be used to access the service via a standard GSM handset (smart phone). The overall authentication at this phase is sequentially carried out as follows: Using a randomly generated integer h R and its real identity h ID the hospital computes its own message authentication code ( h MAC ) as follows: h is a has function for generating the MAC . Later, the key primitives are relayed to the cloud server Upon receiving 1 m together with h T from the Hospital the cloud server performs the necessary validations by initially computing: (4) Note that the validation of (4) above is done using the real and temporary identities furnished by the hospital at registration phase. It therefore suffices to compares its own computed MAC and that contained in 1 m hs hs Upon successful authentication, it goes on to select a random number sh R before computing.
This will now be sent as a time stamped ( s T ) confirmation message ( 2 m ) back to the hospital.
Upon receiving the time stamped message 2 m from the server, likewise the hospital performs all the necessary validations as follows: First, it checks that the validity of the received time stamp. This is followed by re-computing of the following.
Subject to the validity of (9), the next step would be to generate a common session key.
Where 3 h once again is a MAC generation function; sh R is a randomly generated number by the cloud and sent to the hospital. A session key validator is also computed, with the help of a session key generator hash function 4 h as follows: The session key is used to cipher the patient's records before uploading to the server in the form of a message The message 3 m is then time stamped from the hospital side before dispatching it to the cloud server.
Upon receipt of 3 m and h T the cloud server computes the session key and deciphers the patient's report.
Ultimately it computes, ) ( 4 hs hs K h C  and validates: hs hs C C  ' (15) Only then will the records be admitted to the Cloud server's database.

Patient Uploading Phase (PUP)
This involves uploading all acquired patient's health related data via sensors to be uploaded to the cloud server. This can be done over a generally insecure channel since most patients are scattered around the countryside and with not sufficient network (3GGPP)/ coverage. This data will thus be encrypted for confidentiality sake. The patient's main device will prompt all sensors within vicinity (around his/her body) to release the data to it. Authentication is necessary before the data collection by the main patient's device initiates. It is important to note that all associated devices must be initially successfully authenticate with the available 3GPP network.
If they are to utilize the D2D communication mode, then a random number p R , is generated by the patient's device. It uses this same number to compute a hash of its IMSI .
Once authenticated by the HSS the patient's device can perform discovery with peer proximity devices using their temporary devices as well. It is also possible for a device that is outside a 3GPP coverage area to rely on close by devices to access the 3GPP network coverage range and ultimately authenticate with the cloud server.

Prescriptions Phase (PP)
Once again the two parties involved; the medical specialist and cloud server must mutually authenticate. Ultimately a session key will be generated and used to cipher all patients reports, body sensor measurements as well as the overall diagnosis. The procedures taken are as follows.
The medical specialist must initiate the authentication with the server by generating a random number d R as well as providing a temporary ID ( d TID ). The two will be used to generate: Upon receiving 2 m and s T , the medical specialist validates them and ultimately generates a session key: He will then decipher the received patient records before sending a time stamped confirmation message ( 3 m ) back to the cloud server. The latter will have to positively validate 3 m otherwise this a malicious activity of the side of the medical specialist (i.e., a hacker is attempting to infiltrate the system).

Performance Analysis
In this section we summarily analyze the protocol in terms of security requirements as well as performance. The performance is restricted to computational simplicity, communications overhead as well as energy efficiency.

Security Analysis
Mutual Authentication: With the protocol any two communicating parties reciprocate each other in computing the MAC for mutual authentication purposes.
Forward/Backward Secrecy: The protocol relies on the generation of random values in each initiated session hence the old system keys are not valid for future sessions. In that way backward secrecy is guaranteed. Similarly, keys intended for future use are not valid for use in already past sessions, and thus it is for that reason that forward secrecy is guaranteed.
Confidentiality: The protocol runs authentication scripts for very session. Specifically, each session key generation is robustly authenticated.
Non-Repudiation: The use of temporary identities by all parties (TIDH, TIDP, TIDD) and restricting the knowledge of real identities to the cloud server ensures non-repudiation.
Anonymity: Assigning and relying on temporary identities (TIDH, TIDP, TIDD), for authentication purposes ensured anonymity. The cloud server is secluded in the authentication process hence the reliance on insecure channels for the initial authentication does not compromise its identity.
Non-Traceability: Periodically changing temporary identities or assigning a set to each entity ensures non traceability. This is further enhanced with the use of randomly generated numbers for each authentication procedure (session) Session Key Security: Session keys are localized and not exchanged. In that way they cannot be intercepted along compromised channels in case they were exchanged via such channels. Impersonation Attack: The lack of knowledge of real identities of both the cloud server and the rest of the entities means intruders or attackers have no chance in succeeding to impersonate them. Furthermore, a valid MAC is a function of the associated entity's real identity.
Replay Attack: Random values are constantly generated for computing new session keys and other authentication related primitives hence this secludes the possibility of an attacker succeeding to forge messages utilizing old values.
Denial of Service (DoS): Usage of time stamping throughout secludes the possibility of DoS attacks, Man-in-the-Middle Attack: Authentication is accomplished using exchangeable values and localized(unexchangeable) values. In that way Main-in-the -Middle attacks are impossible to execute

Performance Analysis
In this subsection, we analyse the performance of the protocol. In this regard we carry out a comparative performance analysis of the computational demands (intensities), communication overheads as well as energy efficiencies [14], [15] of the proposed versus similar protocols presented in [6] and [ 12].
The evaluation of computational costs of the protocols are solely based on an estimate of the time lapses required to accommodate the execution of operations, that are regarded as integral part of the messages exchanged in the various phases of each protocol. Provided in Table 1 are example operations and associated computational costs of the proposed protocol. (28) We now compare the computational loads of the three schemes namely the proposed, and two others proposed in [6] and [12] respectively. The number of devices per group, or rather in a particular target area is varied from 0 to 100.   Plots of the communication overheads for the three protocols as a function of the number of active devices is provided in figure 3. From the same graph, it can be deduced that the proposed protocol generates relatively low communication overheads hence it is best suited for adaptation to D2D communication.

Figure.3. Communication cost comparisons
The other two schemes incur relatively much higher communication overheads s, since they involve the exchanging of quite a few costly signature parameters, for their mutual authentication. As we gradually move towards energy efficient aware networking and protocol design, [15], [17]. It is necessary to minimise on the operational energy requirements of any protocol thereof. Besides most of the devices are resource constrained in terms of power supply. Most of the energy consumptions are incurred by the CPUs of the respective devices.
The normalized energy cost for the various protocols are calculated as set out in the next three following formulae: For the proposed protocol: (32) A plot of the operational energy requirements for the 3 different schemes is provided in Fig 4.

Figure. 4. Energy cost comparison
By comparison, proposed scheme in is more energy efficient.

Conclusion
This paper proposes a D2D communication-based authentication and key agreement Tele-care scheme that ensures both privacy and security for patients who have enrolled for the service. The fact that the authentication can be done via an insecure link means that even in the absence of 3GPP network coverage, patients would still be able to link with the nearest health care center and medical specialists, thus making the scheme both resilient and robust. This is because D2D communication supports direct device linking of proximity devices and thus an affected device would still reach the nearest peer that is within sufficient coverage range.
The paper uses lightweight message authentication that is meant to reduce computational and communication loads, as well as operating in an energy efficient manner. Its efficacy in terms of ensuring both security and privacy was explored. Overall, we conclude that the scheme would be quite viable in the practical implementation of telecare as most of the devices are resource constrained in terms of computational as well as operation power requirements.