# An Intelligent and Secure Health Monitoring Scheme Using IoT Sensor Based on Cloud Computing

Authors: Jin-Xin Hu; Chin-Ling Chen; Chun-Long Fan; Kun-hao Wang
Journal: Journal of Sensors
 (2017)

---

## Abstract

Internet of Things (IoT) is the network of physical objects where information and communication technology connect multiple embedded devices to the Internet for collecting and exchanging data. An important advancement is the ability to connect such devices to large resource pools such as cloud. The integration of embedded devices and cloud servers offers wide applicability of IoT to many areas of our life. With the aging population increasing every day, embedded devices with cloud server can provide the elderly with more flexible service without the need to visit hospitals. Despite the advantages of the sensor-cloud model, it still has various security threats. Therefore, the design and integration of security issues, like authentication and data confidentiality for ensuring the elderly’s privacy, need to be taken into consideration. In this paper, an intelligent and secure health monitoring scheme using IoT sensor based on cloud computing and cryptography is proposed. The proposed scheme achieves authentication and provides essential security requirements.


---

## Body

## 1. Introduction

With the rapid development of the Internet of Things (IoT), medical sensors, and Internet applications, online medical service has become possible in recent years. It is noteworthy that the number of elders with chronic disease is increasing every year. An aging society refers to a population structure model in which the aging population reaches or exceeds a certain proportion. According to the UN’s traditional standard a region is regarded as an aging society when people over 60 years old account for 10% of the total population, while the new standard is people over 65 years old representing 7% of the total population. Between 2015 and 2050, the proportion of the world’s population over 60 years will nearly double, from 12% to 22% [1]. An aging society means low fertility, aging population structure, and social security system lag. In the meantime, the health of the elderly has become a highlighted social issue. While more and more elders need long-term care, they also want to remain independent and active and reside in their own homes for as long as possible. Due to the lack of medical resources, they cannot be treated appropriately. The hospitals are filling up with an aging population, recovery groups and high risk groups. Continuous monitoring of critical vital signs of patients is a key process in hospitals. Today, this is usually performed via different cabled sensors attached to the patient and connected to bedside monitors [2]. The limitation here is that the elders are tied to bedside devices. Consequently, it has become feasible and necessary to perform personal diagnoses of medical diseases with the measurement repository without visiting hospitals [3]. With the increasing availability of medical sensors and IoT devices for personal use, this situation opens up a new application area for body sensor networks.Wireless sensor networks (WSNs) are an emerging technology that possesses a huge potential to play an important role in many applications [4]. The rapid growth in physiological sensors, low-power integrated circuits, and wireless communication has enabled a new generation of wireless sensor networks, now used for purposes such as monitoring traffic, crops, infrastructure, and health. The body area network field is an interdisciplinary area which could allow inexpensive and continuous health monitoring with real-time updates of medical records via the Internet [5].However, with the presence of sensor networks, many challenges have emerged in terms of flexibility, scalability, and heterogeneous information services. The integration of WSN with cloud provides greater flexibility, unlimited resources, immense processing power, and the ability to provide quick response to the user [6]. Cloud computing provides scientists with a completely new model for utilizing the computing infrastructure. Computer resources and storage resources and applications can be dynamically provisioned (and integrated within the existing infrastructure) on a pay-per-use basis [7]. To provide more suitable and convenient network services, cloud computing has become even more flexible for personal use. Since the cloud is a broad collection of services, organizations can choose where, when, and how they use cloud computing [8]. There are different types of cloud computing services commonly referred to as Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). Many studies [3, 9] pointed out that cloud computing services are clearly the future trend. Cloud computing services are provided through a browser to access online programming applications, software, and data [9]. Cloud providers have to adhere to security and privacy policies to ensure their users’ data remain confidential and secure [10].Moreover, since the number of smart phones is estimated to reach 1 billion, traditional phones started to be gradually eliminated in 2015. The rapid development of smart phones and the related technology means that mobile computing is no longer the priority; we should also focus on reducing the computation cost and communication cost to achieve the optimal efficiency. Despite the agreement and certification of parties to browse medical information, the public still has concerns about the electronic medical record (EMR) system because of the information security issues, such as hacking, information transfer time, and long-term data management problems.In recent years, many medical resources have been implemented for people seeking medical advice conveniently [11]. In the literature [12], researchers combine mobile devices and body sensors but do not sufficiently discuss security issues. Security issues of IoT sensors and medical systems have always been a vital aspect part of active research. It is important to consider security solutions to guarantee data authenticity, freshness, replay protection, integrity, and confidentiality. Some research, such as [13–15], specifically address security issues with respect to healthcare applications. In 2014, Ben Othman et al. proposed an efficient solution for securing data transmission, which combines compressive sensing with encryption and integrity checking [16]. In 2015, an ECC-based mutual authentication protocol for secure communication between embedded devices and cloud servers was presented in a paper by Kalra and Sood [17]. In 2016, Lounis et al. proposed a new cloud-based architecture for medical wireless sensor networks which can ensure the security of medical data without patients/doctors interventions [18]. However, these schemes still fail to ensure a patient’s privacy and nonrepudiation. In this paper, we propose an intelligent and secure monitoring scheme using IoT sensors based on cloud computing to protect the elders’ privacy.The main problem here is that the elderly population is increasing every day and they should not be tied to their bed with monitoring machines, causing them inconvenience and entailing the waste of medical resources. On the other hand, the elderly with chronic conditions also have a high probability of suffering some acute diseases or episodes, such as heart attacks. Without the appropriate medical assistance, the consequences will be very serious. The EMR will be used in our scheme to provide more flexible and appropriate medical service. Due to the importance of the elders’ privacy, the proposed scheme should focus on the advantages offered by the characteristics of cloud computing and the security of the elders’ information.The remainder of the paper is organized as follows: Section2 describes the current approaches on the configuration of medical sensor networks. Section 3 introduces our scheme architecture for a wireless IoT sensor network and the set-up procedure. In Section 4, we analyze the security issues of our scheme and compare it with other schemes. Section 5 contains some conclusions and offers some ideas for future work.


## 2. The Proposed Scheme

In our scheme, each party should register at the key generation center which will issue a pair of public key and private key, to communicate with other parties. The user also gets the pregenerated key; it can be used to encrypt the private health information. The elders can use a mobile device to connect to the IoT medical sensor which can collect the biological data. Seven parties are involved in our scheme as follows.(1  ) Elder (E). The aging population with chronic disease (e.g., heart disease, diabetes, and hypertension) wears the IoT medical sensor which can collect biological data.(2  ) Cloud (C): Intelligent Data Storage. The elder can access the cloud service to upload/download the health information via authentication. It can provide smart applications and send private health reports to the elder at set periods of time. Once there is an emergency situation, the cloud will notify the hospital.(3  ) Hospital (H). It is a hospital where the elder can get physical inspection and the report. Once the elder’s biological data are over a threshold, the hospital will notify the elder and dispatch an ambulance after it gets the cloud’s notification.(4  ) Key Generation Center (KGC). The key generation center will issue a pair of public key and private key for the registered parties. The user’s pregenerated key and the time of the key’s generation are stored in the database.(5  ) IoT Medical Sensor (MS). It is the collecting device of the elder’s biological data. The IoT medical sensor can also transfer the collected data to the mobile device via Bluetooth (Bluetooth 4.0) and the mobile device can transfer the data to the cloud.(6  ) Mobile Device (MD). A portable computing device with a unique International Mobile Equipment Identity (IMEI) which can connect with the IoT medical sensor. It can locate the elder with Global Positioning System (GPS) when there is an emergency and get the reports for normal situation.(7  ) Emergency Family Contacts (EFC). They are the elder’s family members.The elder goes to the hospital for a health inspection and the report will be uploaded to the cloud. Every set period of time, the IoT medical sensor will collect the elder’s biological data and transfer them to the cloud via mobile device. The hospital and the cloud process authentication procedure. The scenarios are described in Figure1.(1)
The elder, the hospital, and the cloud must register at the key generation center in advance via secure channel.(2)
The elder goes to hospital for a physical inspection.(3)
The hospital uploads the elder’s physical inspection report to the cloud.(4)
The IoT medical sensor gets the elder’s biological data via set periods of time and sends it to the mobile device.(5)
The mobile device uploads the biological data to the cloud.(6)
The cloud compares the data sent from the mobile device with the standard values stored in the database. Once there is an emergency, the cloud notifies the hospital and contacts the elder’s family in an acceptable time.(7)
After the hospital gets the notification, it sends messages and dispatches an ambulance to the elder.(8)
If the data collected by the IoT medical sensor are normal, the cloud sends a health report to the elder at set periods of time.Figure 1
The system architecture.


### 2.1. Notations

The following lists notations that will be used in our scheme:IDX: X’s identity.s: the secret value.x: the KGC’s private key.h0(): the hash function h0:{0,1}∗→h1{0,1}l, l=256.h1(): the hash functionh1:G2×{0,1}∗×G1→{0,1}l, l=256.ΔT: the valid transmission time interval.TXi: the ith timestamp generated by X.DataHi: the elder’s physical inspection report generated by the hospital.DataMSi: the elder’s biological data collected by the IoT medical sensor, for example, EGC, heart rate, oxygen saturation, blood pressure, body temperature, and blood glucose.CertX: X party’s identity certification being issued by the KGC.IMEI: International Mobile Equipment Identity.PKX/SKX: X’s public/private key.keyX-Y: the session key between X and Y.SEK(M)/SDK(M): using the symmetric key K to encrypt/decrypt a message M.SSKxM/DSKx(M): using the private key SKx to sign/decrypt a message M.VPKx(M)/EPKx(M): using the public key PKx to verify/encrypt a message M.MSGX: the patient’s health information being generated by X.MSGEM: the emergency message.MSGNM: the normal report.A≟B: checking if A is equal to B.


### 2.2. Registration Phase

Both the elder and the hospital must register at the key generation center in advance. The KGC will issue a pair of public key and private key for each party. The user will get the cloud’s public key and use the pregenerated key to encrypt/decrypt the medical information. The KGC will also record the key’s generation time in the database. The flowchart of the registration phase is shown in Figure2.Figure 2
The registration phase.(1) The elder, the hospital, and the cloud choose the identityIDE/IDH/IDC and send it to the key generation center through a secure channel. The elder should also send his/her mobile devices IMEI and personal contact information to the KGC, including emergency family contacts.(2) After receiving the message, the KGC uses the private keyx to compute the user’s public key PKE/PKH/PKC, the private key SKE/SKH/SKC, and the pregenerated session key keyE-KGC/keyH-KGC/keyC-KGC as follows:(1)SKE=h0IDE,x,SKH=h0IDH,x,SKC=h0IDC,x,keyE-KGC=h1SKE,x,TKGC,keyH-KGC=h1SKH,x,TKGC,keyC-KGC=h1SKC,x,TKGC.Then, the KGC sends (PKE,SKE,keyE-KGC), (PKH,SKH,keyH-KGC), and (PKC,SKC,keyC-KGC) to the elder, the hospital, and the cloud, respectively. In addition, the KGC generates the certification CertE/CertH for the elder and hospital, respectively.(3) Each party stores (PKE,SKE,keyE-KGC), (PKH,SKH,keyH-KGC), and (PKC,SKC,keyC-KGC), respectively. The elder and hospital can use the certification CertE/CertH to process authentication.


### 2.3. The Health Data Uploading Phase

#### 2.3.1. The Hospital Uploads Physical Inspection Report Case

The elder goes to the hospital for a physical inspection. After the hospital and the cloud process authentication, the hospital uploads the physical inspection report to the cloud. The flowchart of the hospital uploading physical inspection report case is shown in Figure3.Figure 3
The hospital uploads physical inspection report case.(1) The hospital uses the session keykeyH-C to encrypt the physical inspection report and makes a timestamp TH1. The hospital uses the cloud’s public key PKC to encrypt keyH-C and makes a signature Sig1 as follows:(2)MSGH1=IDH,IDE,DataH1,DataH2,…,DataHn,TH1,(3)C1=SEkeyH-CMSGH1,(4)C2=EPKCkeyH-C,(5)Sig1=SSKHh1MSGH1.Then, the hospital sendsSig1, IDH, IDE, CertH, C1, C2, and TH1 to the cloud.(2) The cloud verifies the hospital’s signature according to the hospital’s identityIDH and checks if the timestamp TH1 is valid or not as follows:(6)TC1-TH1≤ΔT.If (6) holds, the cloud uses the KGC’s public key PKKGC to verify the hospital’s certification CertH. Then, the cloud finds SDkeyH-C according to IDH and uses the private key SKC and session key keyH-C to decrypt C1 and C2:(7)VPKHSig1≟h1MSGH1,(8)keyH-C=DSKCC2,(9)IDH,IDE,DataH1,DataH2,…,DataHn,TH1=SDkeyH-CC1.Afterwards, the cloud storesMSGH1 and Sig1.


#### 2.3.2. The Mobile Device Uploads Biological Data Case

In this phase, we consider the IoT medical sensors embedded into an elder’s body. The elder uses the mobile device to transfer the biological data which are measured by IoT medical sensors to the cloud. The flowchart of the mobile device uploading biological data case is shown in Figure4.Figure 4
The mobile device uploads biological data case.(1) The IoT medical sensor collects the biological dataMSGMS1 and sends them to the elder’s mobile device through a secure channel:(10)MSGMS1=IDE,DataMS1,DataMS2,…,DataMSn,TMS1.(2) After receiving the message, the mobile device uses the session keykeyE-C to encrypt the elder’s health information MSGMD and makes a timestamp TMD. Afterwards, the mobile device uses the cloud’s public key PKC to encrypt keyE-C:(11)MSGMD1=IMEI,MSGMS1,TMD1,(12)C3=SEkeyE-CMSGMD1,(13)C4=EPKCkeyE-C.Then, the mobile device sendsIDE, CertE, C3, C4, and TMD1 to the cloud.(3) The cloud checks if the timestampTMD1 is valid or not:(14)TC3-TMD1≤ΔT.If (14) holds, the cloud verifies the received IMEI by finding the mobile device’s registered IMEI which is stored in the database according to the elder’s identity IDE. If it holds, the cloud uses the public key PKKGC to verify the elder’s certification CertE. Then, the cloud uses the private key SKC and session key keyE-C to decrypt C3 and C4, respectively:(15)keyE-C=DSKCC4,(16)MSGMD1=SDkeyE-CC3.Afterward, the cloud storesMSGMD1.


### 2.4. The Notification Phase

#### 2.4.1. The Emergency Case

When the cloud gets the elder’s biological data from the mobile device, the cloud compares the data with the standard values stored in the database. If there is an emergency situation, the cloud sends the alert message to the hospital and contacts the emergency family simultaneously. Then, the hospital will contact the elder and dispatch an ambulance to help the elder, if necessary. The flowchart of the emergency case is shown in Figure5.Figure 5
The emergency case.(1) The IoT medical sensor collects the elder’s biological data, such as ECG, oxygen saturation, blood pressure, and body temperature. The IoT medical sensor sends the biological data to the mobile device through a secure channel and makes a timestampTMS2:(17)MSGMS2=IDE,DataMS1,DataMS2,…,DataMSn,TMS2.(2) After receiving the message, the mobile device makes a timestampTMD2 and integrates IMEI and MSGMS2:(18)MSGMD2=IMEI,MSGMS2,TMD2.The mobile device then uses the session keykeyE-C to encrypt MSGMD2 and the cloud’s public key PKC to encrypt keyE-C. In the meantime, the elder uses the private SKE  and a signature Sig2 via mobile device as follows:(19)C5=SEkeyE-CMSGMD2,(20)C6=EPKCkeyE-C,(21)Sig2=SSKEIMEI.The mobile device sendsSig2, IDE, CertE, C5, C6, and TMD2 to the cloud.(3) After receiving the message, the cloud checks if the timestampTMD2 is valid or not:(22)TC5-TMD2≤ΔT.If (22) holds, the cloud uses the private key SKC and session key keyE-C to decrypt C6 and C5 as follows:(23)keyE-C=DSKCC6,IMEI,MSGMS2,TMD2=SDkeyE-CC5.The cloud then uses the KGC’s public keyPKKGC to verify the elder’s certification CertE and check if the mobile device’s IMEI is the same as the registered IMEI: (24)VPKpSig2≟IMEI.The cloud then compares the elder’s biological data with the standard value stored in the database. If some of the inspection data is beyond the threshold, the cloud uses the hospital’s public key PKH to encrypt the emergency message MSGC1 and make a timestamp TC1:(25)MSGC1=IDC,IDE,MSGEM,TC1,(26)C7=EPKHMSGC1.The cloud sendsIDC, IDE, CertE,CertC, C7, and TC1 to the hospital.(4) After receiving the message, the hospital checks if the timestampTC1 is valid or not as follows:(27)TC7-TC1≤ΔT.If (27) holds, the hospital uses the public key PKKGC to verify the cloud’s and the elder’s certification. Then, the hospital uses the private key SKH to decrypt C7:(28)MSGC1=DSKHC7.(5) The hospital gets the elder’s identity and obtains his/her contact information which is stored in the database. The hospital then gets the elder’s location via the mobile device. According toMSGC1, the hospital evaluates the elder’s situation to determine whether to dispatch the ambulance to help the elder. If the elder is able to receive the message, the hospital uses the elder’s public key PKE to encrypt the notification MSGH2 and makes a timestamp TH2:(29)MSGH2=IDE,CertE,IDH,CertH,MSGEM,TH2,(30)C8=EPKEMSGH2.The hospital then sendsIDH, CertH,IDE,CertE, C8, and TH2 to the elder.(6) The elder checks if the timestampTH2 is valid or not when he/she receives the message:(31)TC8-TH2≤ΔT.If (31) holds, the elder uses the public key PKKGC to verify the hospital’s certification and uses the private key SKE to decrypt C8:(32)MSGH2=DSKHC8.(7) If the elder is unconscious and cannot respond to the hospital’s notification, the hospital gets the elder’s location via GPS and dispatches an ambulance to help him/her directly.


#### 2.4.2. The Normal Case

If the elder’s biological data fall in the average scope, the cloud will send a report back to the elder via period of time. The flowchart of the normal case is shown in Figure6.Figure 6
The normal case.(1) The cloud uses the elder’s public keyPKE to encrypt the normal health report MSGC2 and makes a timestamp TC2:(33)MSGC2=IDC,IDE,MSGNM,TC2,(34)C9=EPKHMSGC2.The cloud sends the encrypted health informationC9, IDC, CertC, and TC2 to the elder via set period time.(2) After receiving the message, the elder checks if the timestampTC2 is valid or not as follows:(35)TC9-TC2≤ΔT.If (35) holds, the elder uses the public key PKKGC to verify the cloud’s certification CertC. The elder then uses the private key SKE to decrypt C9.(36)MSGC2=DSKEC9.The elder storesMSGC2.


## 2.1. Notations

The following lists notations that will be used in our scheme:IDX: X’s identity.s: the secret value.x: the KGC’s private key.h0(): the hash function h0:{0,1}∗→h1{0,1}l, l=256.h1(): the hash functionh1:G2×{0,1}∗×G1→{0,1}l, l=256.ΔT: the valid transmission time interval.TXi: the ith timestamp generated by X.DataHi: the elder’s physical inspection report generated by the hospital.DataMSi: the elder’s biological data collected by the IoT medical sensor, for example, EGC, heart rate, oxygen saturation, blood pressure, body temperature, and blood glucose.CertX: X party’s identity certification being issued by the KGC.IMEI: International Mobile Equipment Identity.PKX/SKX: X’s public/private key.keyX-Y: the session key between X and Y.SEK(M)/SDK(M): using the symmetric key K to encrypt/decrypt a message M.SSKxM/DSKx(M): using the private key SKx to sign/decrypt a message M.VPKx(M)/EPKx(M): using the public key PKx to verify/encrypt a message M.MSGX: the patient’s health information being generated by X.MSGEM: the emergency message.MSGNM: the normal report.A≟B: checking if A is equal to B.


## 2.2. Registration Phase

Both the elder and the hospital must register at the key generation center in advance. The KGC will issue a pair of public key and private key for each party. The user will get the cloud’s public key and use the pregenerated key to encrypt/decrypt the medical information. The KGC will also record the key’s generation time in the database. The flowchart of the registration phase is shown in Figure2.Figure 2
The registration phase.(1) The elder, the hospital, and the cloud choose the identityIDE/IDH/IDC and send it to the key generation center through a secure channel. The elder should also send his/her mobile devices IMEI and personal contact information to the KGC, including emergency family contacts.(2) After receiving the message, the KGC uses the private keyx to compute the user’s public key PKE/PKH/PKC, the private key SKE/SKH/SKC, and the pregenerated session key keyE-KGC/keyH-KGC/keyC-KGC as follows:(1)SKE=h0IDE,x,SKH=h0IDH,x,SKC=h0IDC,x,keyE-KGC=h1SKE,x,TKGC,keyH-KGC=h1SKH,x,TKGC,keyC-KGC=h1SKC,x,TKGC.Then, the KGC sends (PKE,SKE,keyE-KGC), (PKH,SKH,keyH-KGC), and (PKC,SKC,keyC-KGC) to the elder, the hospital, and the cloud, respectively. In addition, the KGC generates the certification CertE/CertH for the elder and hospital, respectively.(3) Each party stores (PKE,SKE,keyE-KGC), (PKH,SKH,keyH-KGC), and (PKC,SKC,keyC-KGC), respectively. The elder and hospital can use the certification CertE/CertH to process authentication.


## 2.3. The Health Data Uploading Phase

### 2.3.1. The Hospital Uploads Physical Inspection Report Case

The elder goes to the hospital for a physical inspection. After the hospital and the cloud process authentication, the hospital uploads the physical inspection report to the cloud. The flowchart of the hospital uploading physical inspection report case is shown in Figure3.Figure 3
The hospital uploads physical inspection report case.(1) The hospital uses the session keykeyH-C to encrypt the physical inspection report and makes a timestamp TH1. The hospital uses the cloud’s public key PKC to encrypt keyH-C and makes a signature Sig1 as follows:(2)MSGH1=IDH,IDE,DataH1,DataH2,…,DataHn,TH1,(3)C1=SEkeyH-CMSGH1,(4)C2=EPKCkeyH-C,(5)Sig1=SSKHh1MSGH1.Then, the hospital sendsSig1, IDH, IDE, CertH, C1, C2, and TH1 to the cloud.(2) The cloud verifies the hospital’s signature according to the hospital’s identityIDH and checks if the timestamp TH1 is valid or not as follows:(6)TC1-TH1≤ΔT.If (6) holds, the cloud uses the KGC’s public key PKKGC to verify the hospital’s certification CertH. Then, the cloud finds SDkeyH-C according to IDH and uses the private key SKC and session key keyH-C to decrypt C1 and C2:(7)VPKHSig1≟h1MSGH1,(8)keyH-C=DSKCC2,(9)IDH,IDE,DataH1,DataH2,…,DataHn,TH1=SDkeyH-CC1.Afterwards, the cloud storesMSGH1 and Sig1.


### 2.3.2. The Mobile Device Uploads Biological Data Case

In this phase, we consider the IoT medical sensors embedded into an elder’s body. The elder uses the mobile device to transfer the biological data which are measured by IoT medical sensors to the cloud. The flowchart of the mobile device uploading biological data case is shown in Figure4.Figure 4
The mobile device uploads biological data case.(1) The IoT medical sensor collects the biological dataMSGMS1 and sends them to the elder’s mobile device through a secure channel:(10)MSGMS1=IDE,DataMS1,DataMS2,…,DataMSn,TMS1.(2) After receiving the message, the mobile device uses the session keykeyE-C to encrypt the elder’s health information MSGMD and makes a timestamp TMD. Afterwards, the mobile device uses the cloud’s public key PKC to encrypt keyE-C:(11)MSGMD1=IMEI,MSGMS1,TMD1,(12)C3=SEkeyE-CMSGMD1,(13)C4=EPKCkeyE-C.Then, the mobile device sendsIDE, CertE, C3, C4, and TMD1 to the cloud.(3) The cloud checks if the timestampTMD1 is valid or not:(14)TC3-TMD1≤ΔT.If (14) holds, the cloud verifies the received IMEI by finding the mobile device’s registered IMEI which is stored in the database according to the elder’s identity IDE. If it holds, the cloud uses the public key PKKGC to verify the elder’s certification CertE. Then, the cloud uses the private key SKC and session key keyE-C to decrypt C3 and C4, respectively:(15)keyE-C=DSKCC4,(16)MSGMD1=SDkeyE-CC3.Afterward, the cloud storesMSGMD1.


## 2.3.1. The Hospital Uploads Physical Inspection Report Case

The elder goes to the hospital for a physical inspection. After the hospital and the cloud process authentication, the hospital uploads the physical inspection report to the cloud. The flowchart of the hospital uploading physical inspection report case is shown in Figure3.Figure 3
The hospital uploads physical inspection report case.(1) The hospital uses the session keykeyH-C to encrypt the physical inspection report and makes a timestamp TH1. The hospital uses the cloud’s public key PKC to encrypt keyH-C and makes a signature Sig1 as follows:(2)MSGH1=IDH,IDE,DataH1,DataH2,…,DataHn,TH1,(3)C1=SEkeyH-CMSGH1,(4)C2=EPKCkeyH-C,(5)Sig1=SSKHh1MSGH1.Then, the hospital sendsSig1, IDH, IDE, CertH, C1, C2, and TH1 to the cloud.(2) The cloud verifies the hospital’s signature according to the hospital’s identityIDH and checks if the timestamp TH1 is valid or not as follows:(6)TC1-TH1≤ΔT.If (6) holds, the cloud uses the KGC’s public key PKKGC to verify the hospital’s certification CertH. Then, the cloud finds SDkeyH-C according to IDH and uses the private key SKC and session key keyH-C to decrypt C1 and C2:(7)VPKHSig1≟h1MSGH1,(8)keyH-C=DSKCC2,(9)IDH,IDE,DataH1,DataH2,…,DataHn,TH1=SDkeyH-CC1.Afterwards, the cloud storesMSGH1 and Sig1.


## 2.3.2. The Mobile Device Uploads Biological Data Case

In this phase, we consider the IoT medical sensors embedded into an elder’s body. The elder uses the mobile device to transfer the biological data which are measured by IoT medical sensors to the cloud. The flowchart of the mobile device uploading biological data case is shown in Figure4.Figure 4
The mobile device uploads biological data case.(1) The IoT medical sensor collects the biological dataMSGMS1 and sends them to the elder’s mobile device through a secure channel:(10)MSGMS1=IDE,DataMS1,DataMS2,…,DataMSn,TMS1.(2) After receiving the message, the mobile device uses the session keykeyE-C to encrypt the elder’s health information MSGMD and makes a timestamp TMD. Afterwards, the mobile device uses the cloud’s public key PKC to encrypt keyE-C:(11)MSGMD1=IMEI,MSGMS1,TMD1,(12)C3=SEkeyE-CMSGMD1,(13)C4=EPKCkeyE-C.Then, the mobile device sendsIDE, CertE, C3, C4, and TMD1 to the cloud.(3) The cloud checks if the timestampTMD1 is valid or not:(14)TC3-TMD1≤ΔT.If (14) holds, the cloud verifies the received IMEI by finding the mobile device’s registered IMEI which is stored in the database according to the elder’s identity IDE. If it holds, the cloud uses the public key PKKGC to verify the elder’s certification CertE. Then, the cloud uses the private key SKC and session key keyE-C to decrypt C3 and C4, respectively:(15)keyE-C=DSKCC4,(16)MSGMD1=SDkeyE-CC3.Afterward, the cloud storesMSGMD1.


## 2.4. The Notification Phase

### 2.4.1. The Emergency Case

When the cloud gets the elder’s biological data from the mobile device, the cloud compares the data with the standard values stored in the database. If there is an emergency situation, the cloud sends the alert message to the hospital and contacts the emergency family simultaneously. Then, the hospital will contact the elder and dispatch an ambulance to help the elder, if necessary. The flowchart of the emergency case is shown in Figure5.Figure 5
The emergency case.(1) The IoT medical sensor collects the elder’s biological data, such as ECG, oxygen saturation, blood pressure, and body temperature. The IoT medical sensor sends the biological data to the mobile device through a secure channel and makes a timestampTMS2:(17)MSGMS2=IDE,DataMS1,DataMS2,…,DataMSn,TMS2.(2) After receiving the message, the mobile device makes a timestampTMD2 and integrates IMEI and MSGMS2:(18)MSGMD2=IMEI,MSGMS2,TMD2.The mobile device then uses the session keykeyE-C to encrypt MSGMD2 and the cloud’s public key PKC to encrypt keyE-C. In the meantime, the elder uses the private SKE  and a signature Sig2 via mobile device as follows:(19)C5=SEkeyE-CMSGMD2,(20)C6=EPKCkeyE-C,(21)Sig2=SSKEIMEI.The mobile device sendsSig2, IDE, CertE, C5, C6, and TMD2 to the cloud.(3) After receiving the message, the cloud checks if the timestampTMD2 is valid or not:(22)TC5-TMD2≤ΔT.If (22) holds, the cloud uses the private key SKC and session key keyE-C to decrypt C6 and C5 as follows:(23)keyE-C=DSKCC6,IMEI,MSGMS2,TMD2=SDkeyE-CC5.The cloud then uses the KGC’s public keyPKKGC to verify the elder’s certification CertE and check if the mobile device’s IMEI is the same as the registered IMEI: (24)VPKpSig2≟IMEI.The cloud then compares the elder’s biological data with the standard value stored in the database. If some of the inspection data is beyond the threshold, the cloud uses the hospital’s public key PKH to encrypt the emergency message MSGC1 and make a timestamp TC1:(25)MSGC1=IDC,IDE,MSGEM,TC1,(26)C7=EPKHMSGC1.The cloud sendsIDC, IDE, CertE,CertC, C7, and TC1 to the hospital.(4) After receiving the message, the hospital checks if the timestampTC1 is valid or not as follows:(27)TC7-TC1≤ΔT.If (27) holds, the hospital uses the public key PKKGC to verify the cloud’s and the elder’s certification. Then, the hospital uses the private key SKH to decrypt C7:(28)MSGC1=DSKHC7.(5) The hospital gets the elder’s identity and obtains his/her contact information which is stored in the database. The hospital then gets the elder’s location via the mobile device. According toMSGC1, the hospital evaluates the elder’s situation to determine whether to dispatch the ambulance to help the elder. If the elder is able to receive the message, the hospital uses the elder’s public key PKE to encrypt the notification MSGH2 and makes a timestamp TH2:(29)MSGH2=IDE,CertE,IDH,CertH,MSGEM,TH2,(30)C8=EPKEMSGH2.The hospital then sendsIDH, CertH,IDE,CertE, C8, and TH2 to the elder.(6) The elder checks if the timestampTH2 is valid or not when he/she receives the message:(31)TC8-TH2≤ΔT.If (31) holds, the elder uses the public key PKKGC to verify the hospital’s certification and uses the private key SKE to decrypt C8:(32)MSGH2=DSKHC8.(7) If the elder is unconscious and cannot respond to the hospital’s notification, the hospital gets the elder’s location via GPS and dispatches an ambulance to help him/her directly.


### 2.4.2. The Normal Case

If the elder’s biological data fall in the average scope, the cloud will send a report back to the elder via period of time. The flowchart of the normal case is shown in Figure6.Figure 6
The normal case.(1) The cloud uses the elder’s public keyPKE to encrypt the normal health report MSGC2 and makes a timestamp TC2:(33)MSGC2=IDC,IDE,MSGNM,TC2,(34)C9=EPKHMSGC2.The cloud sends the encrypted health informationC9, IDC, CertC, and TC2 to the elder via set period time.(2) After receiving the message, the elder checks if the timestampTC2 is valid or not as follows:(35)TC9-TC2≤ΔT.If (35) holds, the elder uses the public key PKKGC to verify the cloud’s certification CertC. The elder then uses the private key SKE to decrypt C9.(36)MSGC2=DSKEC9.The elder storesMSGC2.


## 2.4.1. The Emergency Case

When the cloud gets the elder’s biological data from the mobile device, the cloud compares the data with the standard values stored in the database. If there is an emergency situation, the cloud sends the alert message to the hospital and contacts the emergency family simultaneously. Then, the hospital will contact the elder and dispatch an ambulance to help the elder, if necessary. The flowchart of the emergency case is shown in Figure5.Figure 5
The emergency case.(1) The IoT medical sensor collects the elder’s biological data, such as ECG, oxygen saturation, blood pressure, and body temperature. The IoT medical sensor sends the biological data to the mobile device through a secure channel and makes a timestampTMS2:(17)MSGMS2=IDE,DataMS1,DataMS2,…,DataMSn,TMS2.(2) After receiving the message, the mobile device makes a timestampTMD2 and integrates IMEI and MSGMS2:(18)MSGMD2=IMEI,MSGMS2,TMD2.The mobile device then uses the session keykeyE-C to encrypt MSGMD2 and the cloud’s public key PKC to encrypt keyE-C. In the meantime, the elder uses the private SKE  and a signature Sig2 via mobile device as follows:(19)C5=SEkeyE-CMSGMD2,(20)C6=EPKCkeyE-C,(21)Sig2=SSKEIMEI.The mobile device sendsSig2, IDE, CertE, C5, C6, and TMD2 to the cloud.(3) After receiving the message, the cloud checks if the timestampTMD2 is valid or not:(22)TC5-TMD2≤ΔT.If (22) holds, the cloud uses the private key SKC and session key keyE-C to decrypt C6 and C5 as follows:(23)keyE-C=DSKCC6,IMEI,MSGMS2,TMD2=SDkeyE-CC5.The cloud then uses the KGC’s public keyPKKGC to verify the elder’s certification CertE and check if the mobile device’s IMEI is the same as the registered IMEI: (24)VPKpSig2≟IMEI.The cloud then compares the elder’s biological data with the standard value stored in the database. If some of the inspection data is beyond the threshold, the cloud uses the hospital’s public key PKH to encrypt the emergency message MSGC1 and make a timestamp TC1:(25)MSGC1=IDC,IDE,MSGEM,TC1,(26)C7=EPKHMSGC1.The cloud sendsIDC, IDE, CertE,CertC, C7, and TC1 to the hospital.(4) After receiving the message, the hospital checks if the timestampTC1 is valid or not as follows:(27)TC7-TC1≤ΔT.If (27) holds, the hospital uses the public key PKKGC to verify the cloud’s and the elder’s certification. Then, the hospital uses the private key SKH to decrypt C7:(28)MSGC1=DSKHC7.(5) The hospital gets the elder’s identity and obtains his/her contact information which is stored in the database. The hospital then gets the elder’s location via the mobile device. According toMSGC1, the hospital evaluates the elder’s situation to determine whether to dispatch the ambulance to help the elder. If the elder is able to receive the message, the hospital uses the elder’s public key PKE to encrypt the notification MSGH2 and makes a timestamp TH2:(29)MSGH2=IDE,CertE,IDH,CertH,MSGEM,TH2,(30)C8=EPKEMSGH2.The hospital then sendsIDH, CertH,IDE,CertE, C8, and TH2 to the elder.(6) The elder checks if the timestampTH2 is valid or not when he/she receives the message:(31)TC8-TH2≤ΔT.If (31) holds, the elder uses the public key PKKGC to verify the hospital’s certification and uses the private key SKE to decrypt C8:(32)MSGH2=DSKHC8.(7) If the elder is unconscious and cannot respond to the hospital’s notification, the hospital gets the elder’s location via GPS and dispatches an ambulance to help him/her directly.


## 2.4.2. The Normal Case

If the elder’s biological data fall in the average scope, the cloud will send a report back to the elder via period of time. The flowchart of the normal case is shown in Figure6.Figure 6
The normal case.(1) The cloud uses the elder’s public keyPKE to encrypt the normal health report MSGC2 and makes a timestamp TC2:(33)MSGC2=IDC,IDE,MSGNM,TC2,(34)C9=EPKHMSGC2.The cloud sends the encrypted health informationC9, IDC, CertC, and TC2 to the elder via set period time.(2) After receiving the message, the elder checks if the timestampTC2 is valid or not as follows:(35)TC9-TC2≤ΔT.If (35) holds, the elder uses the public key PKKGC to verify the cloud’s certification CertC. The elder then uses the private key SKE to decrypt C9.(36)MSGC2=DSKEC9.The elder storesMSGC2.


## 3. Security Analysis

In this section, we present a security analysis to discuss how our scheme can defend against various attacks.


### 3.1. Replay Attack

In our scheme, we use the timestamp mechanism to defend against the replay attack. The receiver will verify if the timestamp is valid or not by checking the valid time interval via (6), (14), (22), (27), (31), and (35). Therefore, our scheme can defend against replay attack.


### 3.2. Man-in-Middle Attack

If there is a man-in-middle attack, our scheme will be able to resist it by checking the timestamps to verify if the messages are valid.The elder, the hospital, and the cloud can prove his/her identity via certification in our scheme. The elder sends the certificationCertE to the cloud and the hospital. The hospital sends the certification CertH to the cloud and the elder. The cloud sends the certification CertC to the elder and the hospital. Every party will check if the received certification is valid or not.In our scheme, during the health data uploading phase, the hospital and the mobile device use the session keykeyH-C/keyE-C and the public key PKC to encrypt the information via (3), (4), (12), (13), (19), (20), (26), (30), and (34).Other parties cannot decrypt the message without the private key or the session key, so attackers cannot achieve the man-in-middle attack.


### 3.3. Integrity

In the transmission process, the mobile device’s IMEI is authenticated:(37)VPKESig2≟IMEI.Therefore, tampering behaviors can be rapidly detected, so the proposed scheme can ensure data integrity.


### 3.4. Data Security

Our scheme involves the digital envelope mechanism. In order to ensure the elder’s privacy, we use the public key to encrypt the symmetric key via (3), (12), (19), (26), (30), and (34), emergency information MSGEM, and normal report MSGNM. We use the symmetric key to protect the elder’s secret biological data, via (4), (13), and (20).


### 3.5. Confidentiality

In our scheme, we use the asymmetric/symmetric key to ensure the safety of the patient’s personal information as shown in (3), (4), (12), and (13).In the notification phase, the mobile device uses the session keykeyE-C and cloud’s public key PKC to encrypt the information as shown in (19) and (20).Then, the cloud uses the hospital’s public keyPKH to encrypt the emergency message as shown in (26).Afterwards, the hospital uses the elder’s public keyPKE to encrypt the notification as shown in (30).In the normal case, the cloud uses the elder’s public keyPKE to encrypt the normal health report as shown in (34).The elder’s privacy information is protected. Therefore, our scheme can achieve confidentiality.


### 3.6. Nonrepudiation

The cloud can use the hospital’s public key to verify the uploaded data via (7). The hospital cannot deny the uploading fact. The cloud can verify the correctness of the mobile device’s IMEI via (24). The mobile device cannot deny the transmission. Every party can use the KGC’s public key PKKGC to verify whether the sender’s certification is valid or not. The nonrepudiation proof is shown in Table 1.Table 1
The nonrepudiation proof.
Nonrepudiation proof Issuer Holder Nonrepudiation verification S i g 1 = S S K H ( h 1 ( M S G H 1 ) ) Hospital Cloud V P K H ( S i g 1 )  ≟  h 1 ( M S G H 1 ) S i g 2 = S S K E ( I M E I ) Elder Cloud V P K E ( S i g 2 )  ≟  I M E I


### 3.7. Privacy

Data transmission on the Internet is insecure and the elder’s private information may be revealed in the transmission process. In this paper, we use symmetric encryption to protect his/her personal privacy from unauthorized access. The elder’s privacy is ensured.


### 3.8. Transmission Continuity

The elder’s physical report and the biological data which are measured by IoT medical sensors will be stored in the cloud. In order to ensure transmission continuity, the receiver will send information to the sender. If the cloud has not received the elder’s biological data in an acceptable time, which is recommended by the doctor, the cloud will notify the elder and contact his/her emergency family.


### 3.9. Security Analysis Comparison

According to the security issue, we make a comparison with other schemes in Table2. In Table 2, Ben Othman et al.’s scheme [16] and Lounis et al.’s scheme [18] have some weaknesses. They cannot resist the replay attack. Ben Othman et al.’s scheme cannot ensure the security of data. And Kalra and Sood‘s scheme [17] cannot achieve integrity. The proposed scheme can resist the replay attack and man-in-middle attack and provide integrity and data security.Table 2
The security comparisons of related works.
Security issue Proposed scheme Ben Othman et al. [16] Kalra and Sood [17] Lounis et al. [18] Our scheme Replay attack N/A Yes N/A Yes Man-in-middle attack N/A Yes Yes Yes Integrity Yes N/A Yes Yes Data security N/A Yes Yes Yes Confidentiality Yes Yes Yes Yes Nonrepudiation N/A N/A N/A Yes Privacy N/A N/A N/A Yes


## 3.1. Replay Attack

In our scheme, we use the timestamp mechanism to defend against the replay attack. The receiver will verify if the timestamp is valid or not by checking the valid time interval via (6), (14), (22), (27), (31), and (35). Therefore, our scheme can defend against replay attack.


## 3.2. Man-in-Middle Attack

If there is a man-in-middle attack, our scheme will be able to resist it by checking the timestamps to verify if the messages are valid.The elder, the hospital, and the cloud can prove his/her identity via certification in our scheme. The elder sends the certificationCertE to the cloud and the hospital. The hospital sends the certification CertH to the cloud and the elder. The cloud sends the certification CertC to the elder and the hospital. Every party will check if the received certification is valid or not.In our scheme, during the health data uploading phase, the hospital and the mobile device use the session keykeyH-C/keyE-C and the public key PKC to encrypt the information via (3), (4), (12), (13), (19), (20), (26), (30), and (34).Other parties cannot decrypt the message without the private key or the session key, so attackers cannot achieve the man-in-middle attack.


## 3.3. Integrity

In the transmission process, the mobile device’s IMEI is authenticated:(37)VPKESig2≟IMEI.Therefore, tampering behaviors can be rapidly detected, so the proposed scheme can ensure data integrity.


## 3.4. Data Security

Our scheme involves the digital envelope mechanism. In order to ensure the elder’s privacy, we use the public key to encrypt the symmetric key via (3), (12), (19), (26), (30), and (34), emergency information MSGEM, and normal report MSGNM. We use the symmetric key to protect the elder’s secret biological data, via (4), (13), and (20).


## 3.5. Confidentiality

In our scheme, we use the asymmetric/symmetric key to ensure the safety of the patient’s personal information as shown in (3), (4), (12), and (13).In the notification phase, the mobile device uses the session keykeyE-C and cloud’s public key PKC to encrypt the information as shown in (19) and (20).Then, the cloud uses the hospital’s public keyPKH to encrypt the emergency message as shown in (26).Afterwards, the hospital uses the elder’s public keyPKE to encrypt the notification as shown in (30).In the normal case, the cloud uses the elder’s public keyPKE to encrypt the normal health report as shown in (34).The elder’s privacy information is protected. Therefore, our scheme can achieve confidentiality.


## 3.6. Nonrepudiation

The cloud can use the hospital’s public key to verify the uploaded data via (7). The hospital cannot deny the uploading fact. The cloud can verify the correctness of the mobile device’s IMEI via (24). The mobile device cannot deny the transmission. Every party can use the KGC’s public key PKKGC to verify whether the sender’s certification is valid or not. The nonrepudiation proof is shown in Table 1.Table 1
The nonrepudiation proof.
Nonrepudiation proof Issuer Holder Nonrepudiation verification S i g 1 = S S K H ( h 1 ( M S G H 1 ) ) Hospital Cloud V P K H ( S i g 1 )  ≟  h 1 ( M S G H 1 ) S i g 2 = S S K E ( I M E I ) Elder Cloud V P K E ( S i g 2 )  ≟  I M E I


## 3.7. Privacy

Data transmission on the Internet is insecure and the elder’s private information may be revealed in the transmission process. In this paper, we use symmetric encryption to protect his/her personal privacy from unauthorized access. The elder’s privacy is ensured.


## 3.8. Transmission Continuity

The elder’s physical report and the biological data which are measured by IoT medical sensors will be stored in the cloud. In order to ensure transmission continuity, the receiver will send information to the sender. If the cloud has not received the elder’s biological data in an acceptable time, which is recommended by the doctor, the cloud will notify the elder and contact his/her emergency family.


## 3.9. Security Analysis Comparison

According to the security issue, we make a comparison with other schemes in Table2. In Table 2, Ben Othman et al.’s scheme [16] and Lounis et al.’s scheme [18] have some weaknesses. They cannot resist the replay attack. Ben Othman et al.’s scheme cannot ensure the security of data. And Kalra and Sood‘s scheme [17] cannot achieve integrity. The proposed scheme can resist the replay attack and man-in-middle attack and provide integrity and data security.Table 2
The security comparisons of related works.
Security issue Proposed scheme Ben Othman et al. [16] Kalra and Sood [17] Lounis et al. [18] Our scheme Replay attack N/A Yes N/A Yes Man-in-middle attack N/A Yes Yes Yes Integrity Yes N/A Yes Yes Data security N/A Yes Yes Yes Confidentiality Yes Yes Yes Yes Nonrepudiation N/A N/A N/A Yes Privacy N/A N/A N/A Yes


## 4. Discussions

### 4.1. The Computation Cost of Our Scheme

In this subsection, we present the proposed scheme’s computation cost in Table3. We use SHA-256 hash function, AES-symmetric encryption, Menezes-Vanstone cryptosystem, and signature generated by the ECDSA [20].Table 3
The computation cost of our scheme.
Case Party Elder Hospital Cloud/key generation center The case when hospital uploads physical inspection report N/A 2 T A S + 1 T S i g + 1 T S + 1 T H 1 T A S + 1 T S i g + 1 T S The case when mobile device uploads biological data 1 T A S + 1 T S N/A 1 T A S + 1 T S The emergency case 3 T A S + 1 T S i g + 1 T S 2 T A S 2 T A S + 1 T S i g + 1 T S The normal case 1 T A S N/A 1 T A S T H: the time to execute a one-way hash function. T S: the time to execute a symmetric encryption/decryption operation. T A S: the time to execute an asymmetric encryption/decryption operation. T S i g: the time to execute/verify a signature.


### 4.2. The Communication Cost of Our Scheme

In this subsection, we show the communication cost of the proposed scheme in Table4. The highest communication cost in our scheme is for emergency case, while the cost is 5TID+3TAS′+1TS′+1TSig′+3TT+5TCert=5∗80+3∗1024+1∗256+1∗1024+3∗16+5∗8192 = 45,760 bits. The time of transmitting these messages is 45,760/20∗10-6 = 0.9152 ms under the 20 Mbps bandwidth network environment. Fast transmission makes our scheme feasible and efficient.Table 4
The communication cost of our scheme.
Case Cost The case when hospital uploads physical inspection report 2 T I D + 1 T A S ′ + 1 T S ′ + 1 T S i g ′ + 1 T T + T C e r t The case when mobile device uploads biological data 1 T I D + 1 T A S ′ + 1 T S ′ + 1 T T + T C e r t The emergency case 5 T I D + 3 T A S ′ + 1 T S ′ + 1 T S i g ′ + 3 T T + 5 T C e r t The normal case 1 T I D + 1 T A S ′ + 1 T T + T C e r t Total 8 T I D + 6 T A S ′ + 3 T S ′ + 2 T S i g ′ + 6 T T + 8 T C e r t T I D: the time to transmit the identity (80 bits). T T: the time to transmit a timestamp (16 bits). T S ′: the time to transmit a symmetric encryption, ciphertext (256 bits). T A S ′: the time to transmit an asymmetric encryption, ciphertext (1,024 bits). T S i g ′: the time to transmit a signature (1024 bits). T C e r t: the time to transmit a certificate (8192 bits) [19].


## 4.1. The Computation Cost of Our Scheme

In this subsection, we present the proposed scheme’s computation cost in Table3. We use SHA-256 hash function, AES-symmetric encryption, Menezes-Vanstone cryptosystem, and signature generated by the ECDSA [20].Table 3
The computation cost of our scheme.
Case Party Elder Hospital Cloud/key generation center The case when hospital uploads physical inspection report N/A 2 T A S + 1 T S i g + 1 T S + 1 T H 1 T A S + 1 T S i g + 1 T S The case when mobile device uploads biological data 1 T A S + 1 T S N/A 1 T A S + 1 T S The emergency case 3 T A S + 1 T S i g + 1 T S 2 T A S 2 T A S + 1 T S i g + 1 T S The normal case 1 T A S N/A 1 T A S T H: the time to execute a one-way hash function. T S: the time to execute a symmetric encryption/decryption operation. T A S: the time to execute an asymmetric encryption/decryption operation. T S i g: the time to execute/verify a signature.


## 4.2. The Communication Cost of Our Scheme

In this subsection, we show the communication cost of the proposed scheme in Table4. The highest communication cost in our scheme is for emergency case, while the cost is 5TID+3TAS′+1TS′+1TSig′+3TT+5TCert=5∗80+3∗1024+1∗256+1∗1024+3∗16+5∗8192 = 45,760 bits. The time of transmitting these messages is 45,760/20∗10-6 = 0.9152 ms under the 20 Mbps bandwidth network environment. Fast transmission makes our scheme feasible and efficient.Table 4
The communication cost of our scheme.
Case Cost The case when hospital uploads physical inspection report 2 T I D + 1 T A S ′ + 1 T S ′ + 1 T S i g ′ + 1 T T + T C e r t The case when mobile device uploads biological data 1 T I D + 1 T A S ′ + 1 T S ′ + 1 T T + T C e r t The emergency case 5 T I D + 3 T A S ′ + 1 T S ′ + 1 T S i g ′ + 3 T T + 5 T C e r t The normal case 1 T I D + 1 T A S ′ + 1 T T + T C e r t Total 8 T I D + 6 T A S ′ + 3 T S ′ + 2 T S i g ′ + 6 T T + 8 T C e r t T I D: the time to transmit the identity (80 bits). T T: the time to transmit a timestamp (16 bits). T S ′: the time to transmit a symmetric encryption, ciphertext (256 bits). T A S ′: the time to transmit an asymmetric encryption, ciphertext (1,024 bits). T S i g ′: the time to transmit a signature (1024 bits). T C e r t: the time to transmit a certificate (8192 bits) [19].


## 5. Conclusions

The elder’s continuous medical monitoring is a serious problem. In this paper, we proposed a scheme with IoT sensor based on cloud computing to make the elder safely and conveniently monitored. In our scheme, the digital envelope, digital certification, signature, and timestamp mechanisms are involved. We also use the cloud’s characteristics to make sure that the elder can get the available medical service conveniently. The asymmetric/symmetric encryption technology is used to protect the inspection report and the biological data of the elder. The elder’s biological data and other personal information can be uploaded to the cloud via authentication. The hospital can notify the elder or dispatch an ambulance directly to him/her if there is an emergency situation. The elder can receive his/her personal health reports via set periods of time and browse the reports on their mobile device. Therefore our scheme can provide more flexible and accurate medical service as well as reduce the waste of medical resource.Besides, our scheme can defend against the replay attack and man-in-middle attack and offer data security, integrity, nonrepudiation, and confidentiality in a cloud environment. As a result, the elder need not worry about the insecure access of medical records in our proposed medical environments.In the future, we will focus on the bioinformatics certification to make the whole process easier for the elderly.



---

*Source: 3734764-2017-01-03.xml*