# Mutual Authentication Protocol for D2D Communications in a Cloud-Based E-Health System
## 4 Proposed Protocol
### Treatment Phase (TP)  
This phase is performed over an insecure channel. It aims at mutual authentication between the doctor and the cloud server and generation of a session key for encrypting the patient's health report and sensors' measures before they are sent to the doctor, in addition to encrypting the doctor's diagnosis before it is sent to the cloud server. The complete procedure is shown in Figure 5.  
Figure 4: Message exchange in PUP when device-to-device (D2D) communication is adopted to reach the 3 GPP infrastructure and the cloud server.  
Figure 3: Message exchange in patient upload (PUP) for direct access to 3 GPP infrastructure.  
Step 1. The doctor selects one of his/her temporary identities \(TID_{D}\), generates a random number \(R_{D}\), calculates \(MAC_{DC}=h_{2}(ID_{D}\parallel R_{D})\) and sends _Message 1_ = (\(TID_{D}\), \(R_{D}\), \(MAC_{DC}\)) with a timestamp \(T_{D}\) to the cloud server.  
Step 2. The cloud server receives {_Message 1_, \(T_{D}\)} and verifies if \(T_{D}\) is valid. If the verification fails, the procedure is terminated. Otherwise, it calculates \(MAC_{DC^{\prime}}=h_{2}(ID_{D}\parallel R_{D})\) and verifies if \(MAC_{DC^{\prime}}=MAC_{DC}\). If the verification fails, the procedure is interrupted. Otherwise, the cloud server authenticates the doctor, selects a random number \(R_{CD}\) and calculates \(MAC_{CD}=h_{2}(ID_{D}\parallel R_{CD})\), a session key \(K_{DC}=h_{3}(ID_{D}\parallel R_{D})\) and \(C_{DC}=h_{4}(K_{DC})\). It then uses the doctor's real identity to obtain the patient's report and sensors' health information measures previously stored in the cloud and prepare the information to be sent to the doctor, encrypting the data with the session key calculated, \(M_{RPMS}=E_{KHC}\) (Patient Report, Sensors Measures, \(TID_{P}\), \(C_{DC}\)). Finally, it sends _Message 2_ = (\(MAC_{CD}\), \(R_{CD}\), \(M_{RPMS}\)) with a timestamp \(T_{C}\) to the doctor.  
Step 3. The doctor receives {_Message 2_, \(T_{C}\)} and checks if \(T_{C}\) is valid. If the validation fails, the procedure ends. Otherwise, the health center calculates \(MAC_{CD^{\prime}}=h_{2}(ID_{D}\parallel R_{CD})\) and verifies if \(MAC_{CD^{\prime}}\) = \(MAC_{CD}\). If the verification fails, the procedure is terminated. Otherwise, the doctor authenticates the cloud server, generates the session key \(K_{DC}=h_{3}(ID_{D}\parallel R_{D}\parallel R_{CD})\), decrypts \(M_{RPMS}\) to obtain the patient's report and the health information measured by the sensors, _(Patient's Report, Sensors Measures, \(TID_{P}\), \(C_{DC}\))_ = \(D_{KDC}(M_{RPMS})\), calculates \(C_{DC^{\prime}}=h_{4}(K_{DC})\) and verifies if \(C_{DC^{\prime}}=C_{DC}\). Then, he/she analyzes the data received, generates the patient's diagnosis, encrypts it, \(M_{Diag}=E_{KDC}\) (_Doctor Diagnosis, \(TID_{P}\)_) and finally sends _Message 3_ = \(M_{Diag}\) and a new timestamp \(T_{D}\) to the cloud server.  
Step 4. After receiving _Message 3_ and \(T_{D}\), the cloud server verifies if \(T_{D}\) is valid. If the verification fails, it terminates the procedure. Otherwise, it calculates the session key \(K_{DC}=h_{3}(ID_{D}\parallel R_{D}\parallel R_{CD})\), \(C_{DC^{\prime}}=h_{4}(K_{DC})\) and verifies if \(C_{DC^{\prime}}=C_{DC}\). If the verification fails, it interrupts the procedure because the message was not originated from the authenticated doctor and might have been forged by an intruder. If the verification succeeds, the cloud server uses the session key to decrypt the doctor's diagnosis and its respective temporary identity, _(Doctor Diagnosis, \(TID_{D}\))_ = \(D_{KDC}(M_{Diag})\). Finally, it stores the doctor's diagnosis with its respective identities.  
Figure 5: Message exchange in treatment phase (TP).