# Mutual Authentication Protocol for D2D Communications in a Cloud-Based E-Health System
## 4 Proposed Protocol  
The proposed protocol is based on challenge-response and was developed as a secure and efficient mutual authentication scheme alternative, without incurring high computational and communication costs. The use of symmetric cryptography may generate security issues due to key exchanges over public channels. However, the proposed protocol does not exchange keys or real identities over insecure channels, as explained in Sections 5.4 and 5.7, and consequently, it is not affected by these problems. We also propose a D2D communication environment, which provides the chance for devices inside the 3 GPP network to do data offloading and the connection to devices outside the coverage area to be connected and send their owner's health reports. Figure 1 shows the system architecture, which is composed of a health center, a cloud server, patients with and without sensors, patient's devices, doctors, the 3 GPP access technology, the evolved node B (eNB) and the 3 GPP evolved packet core (EPC), represented by the home subscriber server (HSS). There are two coverage domains. The first is the device's coverage domain, which is composed of devices located inside the 3 GPP coverage area and of devices located outside the coverage area. Patients located outside the coverage area can access the 3 GPP network relaying their data through devices located inside the coverage area. The other domain is the 3 GPP domain where the doctor is located. Patients without sensors visit the health center in order to collect identity information to be used in future mutual authentication sessions. The health center must perform mutual authentication with the cloud server prior to sending its patients' data. Patients' devices perform mutual authentication with the cloud server prior to sending the data collected from the respective sensors. Devices with direct access to the 3 GPP infrastructure might use it to reach the cloud server. Those devices located outside of the coverage area can execute the mutual authentication using D2D communication, prior to sending health reports. In the second case, the other D2D devices in the path to the cloud server are used as relays. A device with a direct connection with 3 GPP infrastructure might choose to send its information through D2D communication to perform data offload, which is not addressed in this work. Finally, each doctor also has to execute mutual authentication to obtain patients' reports, evaluate their health conditions and guide them to the more suitable treatment. The following sections detail each of the phases necessary to perform the mutual authentication of the entities considered and the cloud server. The phases are the following: registration, health center upload, patient upload, treatment and checkup. Table 2 presents the notations used in the protocol. \begin{table}
\begin{tabular}{c c c c c} \hline \hline  & \begin{tabular}{c} **D2D** \\ **Communication** \\ \end{tabular} & \begin{tabular}{c} **m-Health/e-Health/TMIS** \\ \end{tabular} & \
\begin{tabular}{c} **Type of** \\ **Cryptography** \\ \end{tabular} &
\begin{tabular}{c} **Cloud Server** \\ \end{tabular} \\ \hline [PERSON] et al. [7] & No & Yes & Asymmetric & Yes \\ [PERSON] et al. [6] & No & Yes & Asymmetric & Yes \\ [PERSON] and [PERSON] [8] & No & Yes & Symmetric & No \\ [PERSON] et al. [9] & No & Yes & Asymmetric & No \\ [PERSON] and [PERSON] [16] & Yes & No & Asymmetric & No \\ [PERSON] et al. [17] & Yes & No & Asymmetric & No \\ [PERSON] et al. [14] & Yes & Yes & Asymmetric & No \\ Our Protocol & Yes & Yes & Symmetric & Yes \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparison among some protocols.