# EPPDA: An Efficient and Privacy-Preserving Data Aggregation Scheme with Authentication and Authorization for IoT-Based Healthcare Applications

Authors: Faris A. Almalki; Ben Othman Soufiene
Journal: Wireless Communications and Mobile Computing
 (2021)

---

## Abstract

Nowadays, IoT technology is used in various application domains, including the healthcare, where sensors and IoT enabled medical devices exchange data without human interaction to securely transmit collected sensitive healthcare data towards healthcare professionals to be reviewed and take proper actions if needed. The IoT devices are usually resource-constrained in terms of energy consumption, storage capacity, computational capability, and communication range. In healthcare applications, many miniaturized devices are exploited for healthcare data collection and transmission. Thus, there is a need for secure data aggregation while preserving the data integrity and privacy of the patient. For that, the security, privacy, and aggregation of health data are very important aspects to be considered. This paper proposes a novel secure data aggregation scheme called “An Efficient and Privacy-Preserving Data Aggregation Scheme with authentication for IoT-Based Healthcare applications” (EPPDA). EPPDA is based to verification and authorization phase to verify the legitimacy of the nodes that need to join the process of aggregation. EPPDA, also, uses additive homomorphic encryption to protect data privacy and combines it with homomorphic MAC to check the data integrity. The major advantage of homomorphic encryption is allowing complex mathematical operations to be performed on encrypted data without knowing the contents of the original plain data. The proposed system is developed using MySignals HW V2 platform. Security analysis and experimental results show that our proposed scheme guarantees data privacy, messages authenticity, and integrity, with lightweight communication overhead and computation.


---

## Body

## 1. Introduction

The IoT is a paradigm that is rapidly gaining ground in the modern wireless telecommunications scenarios. The basic idea behind this concept is that the ubiquitous presence around us of a variety of things or objects—such as RFID, sensors, actuators, cell phones, which able to interact with each other to achieve common goals through unique addressing schemes [1]. The IoT can promote the development of applications in many different fields (e.g., smart buildings, automation, industrial automation, medical aids, mobile healthcare, intelligent energy management, and traffic management) [2]. These applications can be used to generate big data to provide new services to citizens, businesses, and public administrations to make smart decisions [3]. More in-depth understanding of IoT with its applications, challenges, and open research issues is discussed in [1–7]. Many benefits are provided by IoT technologies to the healthcare field, and the resulting applications can be grouped mainly in the tracking of objects and people (staff and patients); identification and authentication of persons; automatic data collection and detection [8]. Figure 1 shows the typical structure of the healthcare surveillance system using IoT. The sensors are deployed in the human body to monitor parameters like temperature, heart rate, and blood pressure. The values read from the sensors are transmitted to the server where physicians can access this data. Therefore, healthcare remote monitoring solutions could potentially reduce medical costs across the country [9].Figure 1
IoT-based healthcare monitoring architecture.IoT-based healthcare systems are extremely vulnerable to be attacked for several reasons. First, system components are mostly unattended, and thus, it is easy to attack them physically. Second, most communications are wireless, which makes eavesdropping more vulnerable than wired scenarios [10]. Finally, most IoT components are characterized by low capacities in terms of energy and computing resources; therefore, these cannot implement complex schemes supporting security. According to Health Insurance Portability and Accountability (HIPAA) [11], it is mandatory to protect all sensitive medical data relating to a patient’s health. Data aggregation is a process of collecting data and aggregating it from the sensor node, which can be considered as one of the essential procedures for not only removing redundant data but also saving energy [12, 13]. However, data aggregation scheme faces many security challenges, which should be carefully addressed [10–20]. Sensor nodes are often deployed in hostile environments with low bandwidth and unsecured communication channels [21]. This can lead to malicious modification of data and tampering with data, resulting in the violation of a user’s privacy [22, 23].To solve the problems mentioned above, this paper proposes a novel secure data aggregation scheme based on homomorphic primitives, called Secure and Privacy Preserving Data Aggregation (EPPDA) designed to reduce the requirements of existing security protocols. EPPDA is based on the verification and authorization phase to verify the legitimacy of the nodes want to join the process of aggregation. In our proposed work, we distinguish different types of health data with different characteristics, including Emergency Data, Vital Health Data and Regular Health Data. The emergency data considers as the highest priority data, where it should be successfully delivered to the Medical Server as soon as required. The vital health data are the requested data by doctors for continuous monitors a patient’s condition. The regular data are not for emergency data and do not presents urgent delivery requirements. The Medical Server receives periodical updates.To the best of our knowledge, the literature shows that detection of attacks can only be performed after reception of aggregate. Thus, this detection is inefficient and too late; besides, it may result in significant loss in terms of computation and communication costs as well as the privacy of patients’ information. Therefore, this proposal uses a signature scheme based on Chebyshev polynomials. By this process, sensor devices, aggregator, and medical server are mutually authenticated before the actual health data transmission. The confidentiality of data is mandatory in data aggregation within healthcare-based IoT. It ensures that the data cannot be accessed by unauthorized person while they flow in the network. The homomorphic encryption algorithm which can protect end-to-end data confidentiality will be applied in this protocol. The proposed EPPDA uses additive homomorphic encryption to protect data privacy and combines it with homomorphic MAC to check the data integrity. Security analysis and performance evaluation based on experimental results of the proposed work is presented.The remainder of this paper is organized as follows: The related works are investigated in Section2. Network model and design goals are presented in Section 3. In Section 4, we described in detail the solution, followed by the security analysis and performance evaluation in Sections 5 and 6, respectively. Finally, Section 7 concluded this paper.


## 2. Related Work

Security is one of the important factors that must be considered when developing IoT-based healthcare systems [5, 6]. This section describes the popular research projects on secure data aggregation of IoT-based healthcare applications. Then, we used this review to highlight the research gaps and report own research motivations. Table 1 shows all techniques that been discussed above and summarized it in.Table 1
Summary of techniques.
Technique and referenceFocus area(s) of the paperStrengthsWeaknessPHDA [15](i) Priority-based health data aggregation.(ii) Paillier cryptographic technique(i) Low energy consumption(ii) Ensure data privacy and integrity(i) Asymmetric cryptosystem is computationally expensivePPM-HAD [16](i) Privacy-preserving and multifunctional health data aggregation(i) High fault tolerant(ii) Ensure data privacy and integrity(i) Not verified in a real-life environment(ii) High traffic loadLSDA [17](i) Secure data aggregation in healthcare using IoT(ii) Homomorphic encryption and MAC.(iii) Packet checking at aggregator(i) Evaluation results using an experimental network of medical sensors(ii) Robust communication(iii) Efficient communication between doctors and patients(i) ECEG is power hungry cryptography(ii) Low fault tolerant(iii) Can be vulnerable to impersonation attackRESDA [18](i) Secure data aggregation in healthcare using IoT(ii) Homomorphic encryption and MAC(iii) No packet checking at aggregator(i) Evaluation results using an experimental network of medical sensors(ii) Providing strong privacy guarantees(i) ECEG is power hungry cryptography(ii) Easy target for high-end attacksERCS [19](i) Trust-based communication scheme to ensure reliability and privacy of WBAN(ii) Cooperative communication approach(i) Increases service delivery ratio, reliability, and trust with reduced average delay(ii) Guaranteeing the confidentiality of sensitive medical data(i) High traffic load(ii) Not verified in a real-life environment(iii) Energy consumptionCBCSES [20](i) Efficient and provable secure scheme for IoT in Mobile health system(ii) Certificate-based combined signature, encryption and signcryption(i) Securing the patients’ sensitive data(ii) Providing efficient performance in terms of energy consumption, frequency and cost.(i) Not verified in a real-life environment(ii) Communication cost is high.(iii) Not considering heterogeneity of sensorsProposed EPPDA(i) Secure and energy-efficient data aggregation in healthcare using IoT with malicious node detection.(ii) Homomorphic encryption and MAC(iii) Packet checking at aggregator(iv) Priority-based health data aggregation(i) Evaluation results using an experimental network of medical sensors(ii) Ensure data privacy and integrity(iii) Efficient communication between doctors and patients(iv) Malicious node detection(v) Considering heterogeneity of sensors(i) Can have high storage overhead to store large number of keysAuthors in [15] present a health data aggregation scheme, namely, a priority-based health data aggregation with privacy preservation for cloud assisted WBANs (PHDA). It is used to improve the efficiency of aggregation between different types of health data. Based on different data priorities, adjustable transfer strategies that can be selected to transmit user’s health data to cloud servers at reasonable communication costs. In addition, PHDA can resist tampering attacks and achieve a desirable delivery rate with reasonable communication costs and reduced delivery time for data in different priorities. But at the same time, it reduces the communication overload. Indeed, their system was not tolerant of failure in the event of failure of users or cloud servers, nor is it resistant to different types of attacks.In [16], an efficient and privacy-friendly data aggregation known as Fault Tolerance Multifunctional Health and Privacy Preserving Data Aggregation for Cloud Assisted WBANs (PPM-HAD) is introduced. The PPM-HAD is aimed at addressing the need for a fault-tolerant cloud framework to manage sensitive user health data in a large-scale network. The aggregation of temporal and spatial statistical data on health is taken into account. In other words, the PPM-HDA mechanism preserves not only differential confidentiality for additive aggregations, such as summation and variance aggregations, but also nonadditive aggregations, such as min/max, median, percentile, and histogram. The additive aggregation feature uses the Boneh-Goh Nissim Encryption System, which is a public key encryption scheme used to protect user privacy. The PPM-HDA scheme ensures that the remaining uncompromising cloud servers can decrypt the aggregated data, which is collected by the healthcare sensors. The prefix membership check scheme is used to reduce computational overhead by changing the question of whether a data item belongs to a range of data or not to a few check questions whether a numeric value is equal or not.Another approach proposed by Othman et al. in [17] was named Lightweight Secure Data Aggregation Scheme in Healthcare using IoT (LSDA). This new scheme is characterized by the use of homomorphic encryption. In addition, each aggregator should check all the packets received from its member nodes, which can filter out the false packets in the network, and thus, the nodes can save power in the transmission phase. The LSDA scheme has three phases: encryption, authentication and aggregation, and decryption and verification. By using this LSDA, many advantages can be obtained, such as reduced power consumption as well as improved bandwidth utilization and data privacy. Indeed, the limit of the approach is that it does not consider different types of health data.In [18], Othman et al. present an end-to-end secure data aggregation scheme, namely, Robust and Efficient Secure Data Aggregation Scheme in Healthcare Using IoT (RESDA). The main objective of the proposed scheme is the security of the data aggregation to be achieved without introducing significant overheads on the sensors limited by the battery. The proposed approach uses homomorphic privacy encryption. The proposed RESDA program meets several security requirements, including confidentiality, authenticity, and integrity. The results of the performance appraisal demonstrated the feasibility and advantages of the proposed system as well as the performance gains. Indeed, the limit of the approach is that it does not take into account different types of health data.Liu et al. [19] proposed a new contribution, namely, a Reliable and Energy-Efficient Communication System based on trust for remote monitoring of patients in body-zone wireless networks (ERCS). Is a trust-based communication scheme to ensure the reliability and confidentiality of the WBAN. To ensure reliability, a cooperative communication approach is used, while for the preservation of confidentiality, a cryptographic mechanism is used. The cooperative strategy was adopted to create trust between the biosensors in order to make the network more reliable. Additionally, the trust was generated at the remote medical server by applying the trust certificate. The performance evaluation has shown that the proposed system outperforms previously offered advanced systems in terms of confidence, energy efficiency, and reliability.Researchers in [20] proposed a novel contribution, namely, an efficient and provable secure Certificate-Based Combined Signature, Encryption and Signcryption Scheme for Internet of Things in Mobile Health System (CBCSES). The novelty of this scheme lies in the fact that it offers the functions of digital signature and encryption simultaneously and individually. To show the effectiveness of the proposed scheme, detailed security analyzes, i.e., indistinguishable under chosen adaptive ciphertext attacks and tamper-proof under selected adaptive message attacks, and comparisons with relevant existing schemes are performed. The results obtained confirm the superiority of the scheme in terms of computation and communication costs with enhanced security.


## 3. System Model and Design Objectives

In this section, we formalize the system model, the adversary model, and the design goals of the EPPDA scheme.


### 3.1. Network Model

The proposed architecture is shown in Figure2, where it can be utilized in a hospital and by even a located remotely patient. The architecture model of our proposed scheme comprises three architectural components, namely, a Medical Sensors Nodes, an Aggregator, and a Medical Server.(i)
Medical Sensor Nodes: The patients are equipped through wearable devices that were forming a Wireless Medical Sensors (MSs). These sensors are on human body to monitor body functions and the surrounding environment. Each sensor node is integrated with biosensors which are body temperature, electromyography, electrocardiography, blood pressure, pulsi-oximeter, and electroencephalography. The Medical Sensors are responsible for reporting the sensed health data to the Aggregator.(ii)
Aggregator: Is a special sensor node with a superior certain ability to calculation and communication range. Aggregation nodes, as the name suggests, will aggregate the data using aggregation functions. The Aggregator collects the individual health data and check the legitimacy of the Medical Sensors wishing to communicate with it to prevent the adversary nodes from joining the network, then compute the aggregation on them. The patient’s mobile device is used as the Aggregator. The Aggregator works as a router between the Medical Sensor nodes and the Medical Server.(iii)
Medical Server: The Medical Server includes healthcare providers (e.g., doctors, physicians, nurses, and researchers). It possesses almost infinite storage capability and the computation of the resources. The Medical Server has the computation abilities to execute the calculations over the stored data including disease learning and prediction. We consider a scenario where the medical server can be accessed by the trusted authorities and the concerned doctor/emergency medical team. On receiving the patient’s health data, the doctor can get real-time situational awareness.Figure 2
The proposed architecture for IoT-based healthcare.


### 3.2. Adversary Model of the EPPDA Scheme

An algorithm is considered to provide security of data aggregation to provide confidentiality, integrity, and authenticity as the basic requirements that can be targeted by attackers.(i)
Category A: Attacks against Confidentiality. Attackers always attempt to access keys by launching one of the following attacks such as known plaintext attack, chosen ciphertext attack, and chosen plaintext attack. Once the attacker gains control over the key, the aggregated data can be decrypted.(ii)
Category B: Attack on Integrity. Attackers successfully compromises one or more aggregator or sensor nodes, which may lead to either drop some data or change aggregated result with the intention of propagating false aggregate to the Medical Server (e.g., replay attack).(iii)
Category C: Attack on Authenticity. There are two types of attacks that can form threat against authenticity: (i) attacker pretends to be Medical Server and injects query into the network; (ii) attacker pretends to be a genuine sensor node or aggregator and injects false data into the network.


### 3.3. Design Objectives of the EPPDA Scheme

The following design goals are to be achieved.(i)
High Efficiency: The proposed aggregation scheme should be efficient, where the computational costs at IoT devices should be as less as possible, while the communication overheads should also be minimal in order to conserve energy and prolong the networks lifetime.(ii)
Security: The proposed aggregation scheme should resist against the false data injection attack from external attackers, where the proposed system must filter false data locally at the Aggregator. In the IoT-Based Healthcare Applications, the security services are obligatory desired to prevent the unauthorized nodes to access to the sensitive data, which leads to data confidentiality. Further, data integrity and authentication are considered to prevent attacks that target the integrity of sensitive data and to detect impersonation.(iii)
Robustness: A security mechanism must guarantee the availability of packet even with the presence of some compromised or defective nodes.


## 3.1. Network Model

The proposed architecture is shown in Figure2, where it can be utilized in a hospital and by even a located remotely patient. The architecture model of our proposed scheme comprises three architectural components, namely, a Medical Sensors Nodes, an Aggregator, and a Medical Server.(i)
Medical Sensor Nodes: The patients are equipped through wearable devices that were forming a Wireless Medical Sensors (MSs). These sensors are on human body to monitor body functions and the surrounding environment. Each sensor node is integrated with biosensors which are body temperature, electromyography, electrocardiography, blood pressure, pulsi-oximeter, and electroencephalography. The Medical Sensors are responsible for reporting the sensed health data to the Aggregator.(ii)
Aggregator: Is a special sensor node with a superior certain ability to calculation and communication range. Aggregation nodes, as the name suggests, will aggregate the data using aggregation functions. The Aggregator collects the individual health data and check the legitimacy of the Medical Sensors wishing to communicate with it to prevent the adversary nodes from joining the network, then compute the aggregation on them. The patient’s mobile device is used as the Aggregator. The Aggregator works as a router between the Medical Sensor nodes and the Medical Server.(iii)
Medical Server: The Medical Server includes healthcare providers (e.g., doctors, physicians, nurses, and researchers). It possesses almost infinite storage capability and the computation of the resources. The Medical Server has the computation abilities to execute the calculations over the stored data including disease learning and prediction. We consider a scenario where the medical server can be accessed by the trusted authorities and the concerned doctor/emergency medical team. On receiving the patient’s health data, the doctor can get real-time situational awareness.Figure 2
The proposed architecture for IoT-based healthcare.


## 3.2. Adversary Model of the EPPDA Scheme

An algorithm is considered to provide security of data aggregation to provide confidentiality, integrity, and authenticity as the basic requirements that can be targeted by attackers.(i)
Category A: Attacks against Confidentiality. Attackers always attempt to access keys by launching one of the following attacks such as known plaintext attack, chosen ciphertext attack, and chosen plaintext attack. Once the attacker gains control over the key, the aggregated data can be decrypted.(ii)
Category B: Attack on Integrity. Attackers successfully compromises one or more aggregator or sensor nodes, which may lead to either drop some data or change aggregated result with the intention of propagating false aggregate to the Medical Server (e.g., replay attack).(iii)
Category C: Attack on Authenticity. There are two types of attacks that can form threat against authenticity: (i) attacker pretends to be Medical Server and injects query into the network; (ii) attacker pretends to be a genuine sensor node or aggregator and injects false data into the network.


## 3.3. Design Objectives of the EPPDA Scheme

The following design goals are to be achieved.(i)
High Efficiency: The proposed aggregation scheme should be efficient, where the computational costs at IoT devices should be as less as possible, while the communication overheads should also be minimal in order to conserve energy and prolong the networks lifetime.(ii)
Security: The proposed aggregation scheme should resist against the false data injection attack from external attackers, where the proposed system must filter false data locally at the Aggregator. In the IoT-Based Healthcare Applications, the security services are obligatory desired to prevent the unauthorized nodes to access to the sensitive data, which leads to data confidentiality. Further, data integrity and authentication are considered to prevent attacks that target the integrity of sensitive data and to detect impersonation.(iii)
Robustness: A security mechanism must guarantee the availability of packet even with the presence of some compromised or defective nodes.


## 4. Proposed EPPDA Solution

In this section, we present the EPPDA protocol for secure data aggregation in healthcare-based IoT, which mainly consists of the following five parts: (1) setup and key generation phase; (2) encryption-sign data; (3) verification and authorization phase; (4) data aggregation phase with priority; and (5) decryption and verification phase. The flowchart for the proposed solution process is shown in Figure3.Figure 3
Concrete sequence flow diagram of the EPPDA.


### 4.1. Setup and Key Generation Phase

For each patient, putting an admitted-on sensor-based monitoring can rely on the recommendation of the doctor. According to the patient’s health data needs, the medical personnel places the medical sensors on the patient’s body. Each patient must be registered into the Medical Server prior attaching any sensors. When the hardware configuration ends, the Medical Server sends a demand key information from each sensor. Then, after receiving the request by the Aggregator, the Medical Sensor nodes process the request and send the key parameter as a broadcast message toward the Aggregator.For each Medical Sensor, the ID and the private key are generated and sent to the Aggregator, which can be denoted as IDMS and MSPvkey, respectively. The private key of the sensor node is created using the Diffie-Hellman key exchange [24]. While the Aggregator receives the sensor node ID and the private key and stores it. On the other hand, the Aggregator generates the IDAgg and AggPvkey, before transferring the generated info to the Medical Server. Then, the Medical Server receives the ID and private key of Aggregator and stores it. Table 2 shows symbol description of the proposed EPPDA solution, whereas Figure 4 presents the key exchange model of the setup and key generation phase of the proposed EPPDA. The pseudocode of the setup and key generation phase can be seen in Algorithm 1.Algorithm 1: Setup and key generation phase.
Generate sensor ID:IDMSGenerate private key of Medical Sensor:MSPvkeySend theIDMS and MSPvkey to AggregatorGenerate ID of Aggregator:IDAggGenerate private key of Aggregator:AggPvkeySend theIDAgg and AggPvkey to Medical ServerTable 2
Symbol description of the proposed EPPDA solution.
SymbolDescriptionIDMSMedical sensor IDmiHealth dataIDAggAggregator IDMSPvkeyPrivate key of medical sensorAggPvkeyPrivate key of aggregator∗StoredS1,S2Messages exchangeRN1, RN 2Random numbersPKMSPublic key of medical serverSKMSSecret key shared between the medical sensor and medical server.Figure 4
Setup and key generation phase of the proposed solution.


### 4.2. Encryption and Signing Phase

The health data comes from various devices, which in turn leads to large volume of data records [15]. In general, we differentiate different types of health data with different characteristics, including emergency situation, vital health data, and regular health data. The Medical Sensors sensing the physiological parameters (e.g., blood pressure, glucose level), where for each parameter, the normal range is recorded in a table. For most emergency situations, some alerts will be generated if a patient is in danger. For example, the blood pressure readings suddenly exceed 180/120 mmHg, which may be signs of organ damage that requires immediate medical attention. Hence, an alert message should be sent to a doctor immediately. The emergency situations are the highest priority data; thus, it should be successfully delivered to the Medical Server as soon as need be. The vital health data are the requested data by doctors for continuous monitors of a patient’s condition. There are many diseases that can be diagnosed and controlled through regular monitoring of these medical data, where regular data are not for emergency situation and do not need urgent delivery requirements. The Medical Server receives periodical updates, in order to validate the data. If a patient’s data falls within the reference interval, no emergency alert will be sent to doctors. However, in case of any abnormalities of the data, the Medical Server sends a notification to doctors for actions to be taken.The confidentiality of data is mandatory in data aggregation in healthcare-based IoT. It ensures that the data cannot be accessed by unauthorized person while they flow in the network. The homomorphic encryption algorithm which can protect end-to-end data confidentiality will be applied in this protocol. The major advantage of homomorphic encryption is allowing complex mathematical operations to be performed on encrypted data without knowing the contents of the original plain data [25]. As calculations are performed on encrypted texts, the data privacy and confidentiality are protected [26]. Therefore, we can ensure that the content exchanged between Medical Sensors and Medical Server is protected against any modification by malicious or unauthorized users. Moreover, to allow the Medical Server determining the evil data, we use a homomorphic Message Authentication Code (MAC) scheme, to provide data integrity. MAC ensures that received message is from the authenticated source and it is not tempered by any third-party during transmission [26]. The proposed solution can guarantee data freshness in time and value. In each exchange of encrypted data between of the proposed network devices, we send a nonce N, which is an implicit sequence number that is used only once for data freshness. Algorithm 2 describes the algorithm that executed by the Medical Sensor for encryption and signing the collected data.Algorithm 2: Encrypt and Signing the collected data.
Input: PKMS, SKMS, mi, NonceOutput :Ci, MACi(1) Mapmi into point of the elliptic curve Pi(i) If Emergency Situation, the Medical Sensor calculate and send to the Aggregator:(a) Compute:CiES=Pi+SKMS∗PKMSIDMSNiTimeLocation(b) Compute:MACiES=HMACCiES,SKMS(ii) If Vital Health data, the Medical Sensor calculate and send to the Aggregator:(a) Compute:CiVD=Pi+SKMS∗PKMSIDMSNiTime(b) Compute:MACiVD=HMACCiVD,SKMS(iii) If Regular Health data, the Medical Sensor calculate and send to the Aggregator:(a) Compute :CiRD=Pi+SKMS∗PKMSIDMSNiTime(b) Compute :MACiRD=HMACCiRD,SKMS(2) Send (CiES,MACiES), (CiVD,MACiVD), and (CiRD,MACiRD) to AggregatorIn the literature, attack detection can only be performed after receiving aggregate, which is considered as an inefficient detection, due to lateness of detection, significant loss in terms of computation and communication costs, and privacy information of patients [27, 28]. Hence, this proposed solution uses a scheme that allows early detection of any attack, which aims to verify the legitimacy communication between of the proposed network devices. In this regard, the proposed solution also presents a verification and authorization phase using a signature scheme based on Chebyshev polynomials [29–31]. The first verification is between Medical Sensors and Aggregator, and for this, a signature is created by the Medical Sensor. In the first order, the Medical Sensor creates two different messages as, S1 and S2 and the Chebyshev polynomial factor. The message S1 is generated by encrypting the private key of the Medical Sensor, then get modulated with the random number RN1. Message S1 is expressed as(1)S1=EMSPvkeymodRN1.MessageS2 is computed as follows. The sensor node IDMS is concatenated with the Chebyshev polynomial, which is concatenated with the message S1. The hashing function is applied to the concatenated factor to generate the message S2.(2)S2=hIDMS//M//S1,where M denotes Chebyshev polynomial and h denotes the hashing function. The Chebyshev polynomial factor M generated at the Medical Sensor is expressed as(3)M=8b4−8b2+1.The EX-OR operation is applied with the private key of the Medical Sensor and the hashing function of the node IDMS to generate the factor b, where the term b is computed as(4)b=MSPvkey⊕hIDMS.Finally, the signatureα is generated using the messages S1 and S2, respectively. Therefore, the signature generated at the Medical Sensor is denoted as(5)α=S1,S2.The signatureα generated by the Medical Sensors is forwarded and stored in the Aggregator to perform the verification phase. The messages that is stored in the Aggregator is denoted as S1∗ and S2∗, respectively. Figure 5 shows the different stages of the encryption and signing phase in the proposed EPPDA. The pseudocode of the generated signature α stage can be seen in Algorithm 3.Algorithm 3: Generate the signature α.
Created theS1 and S2S1=EMSPvkeymodRN1S2=hIDMS//M//S1Generate the signatureα=S1,S2The Medical Sensors Sendα to AggregatorFigure 5
Encryption and signing stages of the proposed solution.


### 4.3. Verification and Authorization Phase

Authentication is a process of verifying the legitimacy of the nodes wanting to join the process of aggregation. This local authentication phase is aimed at verifying the legitimacy of the Medical Sensors wishing to communicate with the Aggregator. The Medical Sensor and Aggregator establish interaction for local verification to prevent the adversary nodes from joining the network. The Aggregator calculatesS1∗ and S2∗, and check the legality of the Medical Sensors; if it passes the verification, the Aggregator authenticates the legality of the Medical Sensors, and receives the related health data successfully. Conversely, if the Medical Sensors is malicious and unauthorized, the Aggregator rejects the Medical Sensors from joining his network. The Aggregator receives the signature generated by the Medical Sensors and stores it to perform the verification process. The messages S1 and S2 that are stored in the Aggregator are specified as(6)S1∗=EMSPvkey∗modRN1,S2∗=hIDMS∗//M∗//S1∗.The Chebyshev polynomial will be sent to the Aggregator and get stored for further processing. Thus, the Chebyshev polynomial that is received by the Aggregator is specified as(7)M∗=8b4−8b2+1.Here, the termm is expressed as(8)b=MSPvkey∗⊕hIDMS∗.If the signature received by the Aggregator and the signature generated by the Medical Sensor are equal,S1=S1∗ and S2=S2∗, then the signatures are well verified. After the verification of the legitimacy of the Medical Sensors is completed, the Aggregator sends a demand to the Medical Server to request the Aggregation authorization. So, the Aggregator generates the message S3, which can be specified as(9)S3=hIDAgg//RN2⊕AggPvkey.The messageS3 generated at Aggregator is sent to the Medical Server and stored as S3∗. The message S3∗ is expressed as(10)S3∗=hIDAgg∗//RN2∗⊕AggPvkey.Once the Medical Server receivesS3, the S3∗ gets verified with the message S3. If S3=S3∗ then, the Medical Server generates an Aggregation Authorization messages SAA for Aggregator. Conversely, if the Aggregator is malicious and unauthorized, the Medical Server rejects the Aggregator from joining his network. By this process, the sensor devices, gateway device, and medical server are mutually authenticated before the actual heath data transmission. Next, the Medical Server sends the message SAA to Aggregator. Then, the Aggregation phase is activated. Figure 6 shows the system model of the verification phase, while the pseudocode of the verification phase can be seen in Algorithm 4.Algorithm 4: Verification and Authorization phase.
MessageS1 and S1 are stored in the AggregatorThe Aggregator calculate:S1∗=EMSPvkey∗modRN1S2∗=hIDMS∗//M∗//S1∗IfS1=S1∗ and S2=S2∗, signature is verifiedThe Aggregator generates the messageS3S3=hIDAgg//RN2⊕AggPvkeyThe Aggregator sendS3 to Medical Server and storedThe Medical Server calculate:S3∗=hIDAgg∗//RN2∗⊕AggPvkeyIfS3=S3∗The Medical Server generate the Aggregation Authorization messageSAAThe Medical Server sendSAA to AggregatorFigure 6
Verification phase of the proposed solution.


### 4.4. Data Aggregation Phase with Priority

After receiving the Aggregation an authorization message from the Medical Server, the Aggregator runs the Data Aggregation phase. In the proposed EPPDA solution, the data aggregation phase is based on priority of data. In our proposed solution, the ciphertexts for each data priorities cannot be combined. Whereas only the ciphertext from the same data priority can be combined. The pseudocode of the Data Aggregation phase can be seen in Algorithm5.Algorithm 5: Data Aggregation phase with Priority.
Input: (CiES,MACiES), (CiVD,MACiVD), and (CiRD,MACiRD)If Emergency Situation, the Aggregator calcute and send to the Medical Server:ForL ciphertexts (C1ES . . . CiES): Compute CAggES=∑i=1⋯.LjCiESForL MACs (MAC1ES . . . MACiES): Compute MACAggES=⊕MACiESIf Vital Health data, the Aggregator calculate and send to the Medical Server:ForL ciphertexts (C1VD . . . CiVD): Compute CAggVD=∑i=1⋯.LjCiVDForL MACs (MAC1VD . . . MACiVD): Compute MACAggVD=⊕MACiVDIf Regular Health data, the Aggregator calculate and send to the Medical Server:ForL ciphertexts (C1RD . . . CiRD): Compute CAggRD=∑i=1⋯.LjCiRDForL MACs (MAC1RD . . . MACiRD): Compute MACAggRD=⊕MACiRDOutput: (CAggES,MACAggES), (CAggVD,MACAggVD), and (CAggRD,MACAggRD)


### 4.5. Decryption and Verification Phase

In this phase, after receiving all data packets (e.g., aggregated data), the medical server invokes the decryption and verification processes. The medical server decrypts the aggregated ciphertext and checks the end-to-end integrity. If the verification holds, the aggregated data will be accepted, otherwise rejected. Then, the data can be accessed by different entities, including hospital, doctors, insurance companies. The pseudocode of the Data Decryption and Verification phase can be seen in Algorithm6.Algorithm 6: Decryption and Verification Phase.
Input:(CAggES,MACAggES), (CAggVD,MACAggVD), and (CAggRD,MACAggRD)Output :miFor each pair ((CAggESorVDorRDg, (MACAggESorVDorRDg) doComputeMACagg′ of Cagg using SKMSIfMACagg′ = Cagg thenDecryptCaggelseReject (Cagg, MACagg)


## 4.1. Setup and Key Generation Phase

For each patient, putting an admitted-on sensor-based monitoring can rely on the recommendation of the doctor. According to the patient’s health data needs, the medical personnel places the medical sensors on the patient’s body. Each patient must be registered into the Medical Server prior attaching any sensors. When the hardware configuration ends, the Medical Server sends a demand key information from each sensor. Then, after receiving the request by the Aggregator, the Medical Sensor nodes process the request and send the key parameter as a broadcast message toward the Aggregator.For each Medical Sensor, the ID and the private key are generated and sent to the Aggregator, which can be denoted as IDMS and MSPvkey, respectively. The private key of the sensor node is created using the Diffie-Hellman key exchange [24]. While the Aggregator receives the sensor node ID and the private key and stores it. On the other hand, the Aggregator generates the IDAgg and AggPvkey, before transferring the generated info to the Medical Server. Then, the Medical Server receives the ID and private key of Aggregator and stores it. Table 2 shows symbol description of the proposed EPPDA solution, whereas Figure 4 presents the key exchange model of the setup and key generation phase of the proposed EPPDA. The pseudocode of the setup and key generation phase can be seen in Algorithm 1.Algorithm 1: Setup and key generation phase.
Generate sensor ID:IDMSGenerate private key of Medical Sensor:MSPvkeySend theIDMS and MSPvkey to AggregatorGenerate ID of Aggregator:IDAggGenerate private key of Aggregator:AggPvkeySend theIDAgg and AggPvkey to Medical ServerTable 2
Symbol description of the proposed EPPDA solution.
SymbolDescriptionIDMSMedical sensor IDmiHealth dataIDAggAggregator IDMSPvkeyPrivate key of medical sensorAggPvkeyPrivate key of aggregator∗StoredS1,S2Messages exchangeRN1, RN 2Random numbersPKMSPublic key of medical serverSKMSSecret key shared between the medical sensor and medical server.Figure 4
Setup and key generation phase of the proposed solution.


## 4.2. Encryption and Signing Phase

The health data comes from various devices, which in turn leads to large volume of data records [15]. In general, we differentiate different types of health data with different characteristics, including emergency situation, vital health data, and regular health data. The Medical Sensors sensing the physiological parameters (e.g., blood pressure, glucose level), where for each parameter, the normal range is recorded in a table. For most emergency situations, some alerts will be generated if a patient is in danger. For example, the blood pressure readings suddenly exceed 180/120 mmHg, which may be signs of organ damage that requires immediate medical attention. Hence, an alert message should be sent to a doctor immediately. The emergency situations are the highest priority data; thus, it should be successfully delivered to the Medical Server as soon as need be. The vital health data are the requested data by doctors for continuous monitors of a patient’s condition. There are many diseases that can be diagnosed and controlled through regular monitoring of these medical data, where regular data are not for emergency situation and do not need urgent delivery requirements. The Medical Server receives periodical updates, in order to validate the data. If a patient’s data falls within the reference interval, no emergency alert will be sent to doctors. However, in case of any abnormalities of the data, the Medical Server sends a notification to doctors for actions to be taken.The confidentiality of data is mandatory in data aggregation in healthcare-based IoT. It ensures that the data cannot be accessed by unauthorized person while they flow in the network. The homomorphic encryption algorithm which can protect end-to-end data confidentiality will be applied in this protocol. The major advantage of homomorphic encryption is allowing complex mathematical operations to be performed on encrypted data without knowing the contents of the original plain data [25]. As calculations are performed on encrypted texts, the data privacy and confidentiality are protected [26]. Therefore, we can ensure that the content exchanged between Medical Sensors and Medical Server is protected against any modification by malicious or unauthorized users. Moreover, to allow the Medical Server determining the evil data, we use a homomorphic Message Authentication Code (MAC) scheme, to provide data integrity. MAC ensures that received message is from the authenticated source and it is not tempered by any third-party during transmission [26]. The proposed solution can guarantee data freshness in time and value. In each exchange of encrypted data between of the proposed network devices, we send a nonce N, which is an implicit sequence number that is used only once for data freshness. Algorithm 2 describes the algorithm that executed by the Medical Sensor for encryption and signing the collected data.Algorithm 2: Encrypt and Signing the collected data.
Input: PKMS, SKMS, mi, NonceOutput :Ci, MACi(1) Mapmi into point of the elliptic curve Pi(i) If Emergency Situation, the Medical Sensor calculate and send to the Aggregator:(a) Compute:CiES=Pi+SKMS∗PKMSIDMSNiTimeLocation(b) Compute:MACiES=HMACCiES,SKMS(ii) If Vital Health data, the Medical Sensor calculate and send to the Aggregator:(a) Compute:CiVD=Pi+SKMS∗PKMSIDMSNiTime(b) Compute:MACiVD=HMACCiVD,SKMS(iii) If Regular Health data, the Medical Sensor calculate and send to the Aggregator:(a) Compute :CiRD=Pi+SKMS∗PKMSIDMSNiTime(b) Compute :MACiRD=HMACCiRD,SKMS(2) Send (CiES,MACiES), (CiVD,MACiVD), and (CiRD,MACiRD) to AggregatorIn the literature, attack detection can only be performed after receiving aggregate, which is considered as an inefficient detection, due to lateness of detection, significant loss in terms of computation and communication costs, and privacy information of patients [27, 28]. Hence, this proposed solution uses a scheme that allows early detection of any attack, which aims to verify the legitimacy communication between of the proposed network devices. In this regard, the proposed solution also presents a verification and authorization phase using a signature scheme based on Chebyshev polynomials [29–31]. The first verification is between Medical Sensors and Aggregator, and for this, a signature is created by the Medical Sensor. In the first order, the Medical Sensor creates two different messages as, S1 and S2 and the Chebyshev polynomial factor. The message S1 is generated by encrypting the private key of the Medical Sensor, then get modulated with the random number RN1. Message S1 is expressed as(1)S1=EMSPvkeymodRN1.MessageS2 is computed as follows. The sensor node IDMS is concatenated with the Chebyshev polynomial, which is concatenated with the message S1. The hashing function is applied to the concatenated factor to generate the message S2.(2)S2=hIDMS//M//S1,where M denotes Chebyshev polynomial and h denotes the hashing function. The Chebyshev polynomial factor M generated at the Medical Sensor is expressed as(3)M=8b4−8b2+1.The EX-OR operation is applied with the private key of the Medical Sensor and the hashing function of the node IDMS to generate the factor b, where the term b is computed as(4)b=MSPvkey⊕hIDMS.Finally, the signatureα is generated using the messages S1 and S2, respectively. Therefore, the signature generated at the Medical Sensor is denoted as(5)α=S1,S2.The signatureα generated by the Medical Sensors is forwarded and stored in the Aggregator to perform the verification phase. The messages that is stored in the Aggregator is denoted as S1∗ and S2∗, respectively. Figure 5 shows the different stages of the encryption and signing phase in the proposed EPPDA. The pseudocode of the generated signature α stage can be seen in Algorithm 3.Algorithm 3: Generate the signature α.
Created theS1 and S2S1=EMSPvkeymodRN1S2=hIDMS//M//S1Generate the signatureα=S1,S2The Medical Sensors Sendα to AggregatorFigure 5
Encryption and signing stages of the proposed solution.


## 4.3. Verification and Authorization Phase

Authentication is a process of verifying the legitimacy of the nodes wanting to join the process of aggregation. This local authentication phase is aimed at verifying the legitimacy of the Medical Sensors wishing to communicate with the Aggregator. The Medical Sensor and Aggregator establish interaction for local verification to prevent the adversary nodes from joining the network. The Aggregator calculatesS1∗ and S2∗, and check the legality of the Medical Sensors; if it passes the verification, the Aggregator authenticates the legality of the Medical Sensors, and receives the related health data successfully. Conversely, if the Medical Sensors is malicious and unauthorized, the Aggregator rejects the Medical Sensors from joining his network. The Aggregator receives the signature generated by the Medical Sensors and stores it to perform the verification process. The messages S1 and S2 that are stored in the Aggregator are specified as(6)S1∗=EMSPvkey∗modRN1,S2∗=hIDMS∗//M∗//S1∗.The Chebyshev polynomial will be sent to the Aggregator and get stored for further processing. Thus, the Chebyshev polynomial that is received by the Aggregator is specified as(7)M∗=8b4−8b2+1.Here, the termm is expressed as(8)b=MSPvkey∗⊕hIDMS∗.If the signature received by the Aggregator and the signature generated by the Medical Sensor are equal,S1=S1∗ and S2=S2∗, then the signatures are well verified. After the verification of the legitimacy of the Medical Sensors is completed, the Aggregator sends a demand to the Medical Server to request the Aggregation authorization. So, the Aggregator generates the message S3, which can be specified as(9)S3=hIDAgg//RN2⊕AggPvkey.The messageS3 generated at Aggregator is sent to the Medical Server and stored as S3∗. The message S3∗ is expressed as(10)S3∗=hIDAgg∗//RN2∗⊕AggPvkey.Once the Medical Server receivesS3, the S3∗ gets verified with the message S3. If S3=S3∗ then, the Medical Server generates an Aggregation Authorization messages SAA for Aggregator. Conversely, if the Aggregator is malicious and unauthorized, the Medical Server rejects the Aggregator from joining his network. By this process, the sensor devices, gateway device, and medical server are mutually authenticated before the actual heath data transmission. Next, the Medical Server sends the message SAA to Aggregator. Then, the Aggregation phase is activated. Figure 6 shows the system model of the verification phase, while the pseudocode of the verification phase can be seen in Algorithm 4.Algorithm 4: Verification and Authorization phase.
MessageS1 and S1 are stored in the AggregatorThe Aggregator calculate:S1∗=EMSPvkey∗modRN1S2∗=hIDMS∗//M∗//S1∗IfS1=S1∗ and S2=S2∗, signature is verifiedThe Aggregator generates the messageS3S3=hIDAgg//RN2⊕AggPvkeyThe Aggregator sendS3 to Medical Server and storedThe Medical Server calculate:S3∗=hIDAgg∗//RN2∗⊕AggPvkeyIfS3=S3∗The Medical Server generate the Aggregation Authorization messageSAAThe Medical Server sendSAA to AggregatorFigure 6
Verification phase of the proposed solution.


## 4.4. Data Aggregation Phase with Priority

After receiving the Aggregation an authorization message from the Medical Server, the Aggregator runs the Data Aggregation phase. In the proposed EPPDA solution, the data aggregation phase is based on priority of data. In our proposed solution, the ciphertexts for each data priorities cannot be combined. Whereas only the ciphertext from the same data priority can be combined. The pseudocode of the Data Aggregation phase can be seen in Algorithm5.Algorithm 5: Data Aggregation phase with Priority.
Input: (CiES,MACiES), (CiVD,MACiVD), and (CiRD,MACiRD)If Emergency Situation, the Aggregator calcute and send to the Medical Server:ForL ciphertexts (C1ES . . . CiES): Compute CAggES=∑i=1⋯.LjCiESForL MACs (MAC1ES . . . MACiES): Compute MACAggES=⊕MACiESIf Vital Health data, the Aggregator calculate and send to the Medical Server:ForL ciphertexts (C1VD . . . CiVD): Compute CAggVD=∑i=1⋯.LjCiVDForL MACs (MAC1VD . . . MACiVD): Compute MACAggVD=⊕MACiVDIf Regular Health data, the Aggregator calculate and send to the Medical Server:ForL ciphertexts (C1RD . . . CiRD): Compute CAggRD=∑i=1⋯.LjCiRDForL MACs (MAC1RD . . . MACiRD): Compute MACAggRD=⊕MACiRDOutput: (CAggES,MACAggES), (CAggVD,MACAggVD), and (CAggRD,MACAggRD)


## 4.5. Decryption and Verification Phase

In this phase, after receiving all data packets (e.g., aggregated data), the medical server invokes the decryption and verification processes. The medical server decrypts the aggregated ciphertext and checks the end-to-end integrity. If the verification holds, the aggregated data will be accepted, otherwise rejected. Then, the data can be accessed by different entities, including hospital, doctors, insurance companies. The pseudocode of the Data Decryption and Verification phase can be seen in Algorithm6.Algorithm 6: Decryption and Verification Phase.
Input:(CAggES,MACAggES), (CAggVD,MACAggVD), and (CAggRD,MACAggRD)Output :miFor each pair ((CAggESorVDorRDg, (MACAggESorVDorRDg) doComputeMACagg′ of Cagg using SKMSIfMACagg′ = Cagg thenDecryptCaggelseReject (Cagg, MACagg)


## 5. Security Analysis

This section discusses the security strength of our proposed EPPDA scheme, which is aimed at achieving confidentiality, authenticity, and end-to-end privacy on patient’s medical health data.(i)
End-to-End Data Confidentiality: To protect the data patient’s privacy, the data should be transmitted securely. The data confidentiality is the most important factor to be considered when designing the healthcare security architecture using the IoT. In the proposed EPPDA scheme, the collected sensor’s data are encrypted using the homomorphic encryption algorithm. Thus, the Aggregator or attacker has no access to the data even if the Aggregator is compromised physically or virtually since the major advantage of homomorphic encryption is allowing operations to be performed on encrypted data without knowing the contents of the original data. In the following, we analyse how our scheme is secured against attacks launched by an adversary of category A.(a)
Eavesdrop Attack: In our scheme, the sensing data are encrypted under the public key of the Medical Server during the transmission process. After receiving packets from its member nodes, an Aggregator does not decrypt messages but only aggregates them. Only the Medical Server can decrypt messages to obtain the sensing data. Even though an adversary eavesdrops on a transmitted packet, he has no way to decrypt the ciphertext without the private key of the base station. Hence, the privacy is maintained end-to-end.To conclude, our proposed scheme provides a good level of confidentiality for patient’s health data (e.g., protects users’ privacy of data patient’s). The security proofs of the homomorphic encryption are provided in [25, 26].(ii)
End-to-End Data Integrity: To guarantee the integrity of the health data, our scheme allows the Medical Server to check whether the aggregation is done correctly since the data can be perceived at any time. We claim that the proposed scheme provides data integrity and originality. As previously described and to maintain data integrity, each Medical Sensor computes the HMAC for its encrypted measurement and sends the result to the Aggregator. The Aggregator calculates the aggregates on encrypted data without knowing the contents of the original data. The security proof of HMAC is provided in [26]. Hence, an adversary will be unable to generate a valid HMAC unless he/she knows the secret key that is shared between the Medical Sensors and the Medical Server. Even if the attacker successfully modifies the information or launches replay attacks, the Medical Server can verify the correctness of the received data. In the following, we analyse how our scheme is secured against attacks launched by an adversary of category B.(a)
Malleability: An adversary can alter a ciphertext by injecting false data, but it will not be detected due to the homomorphic property. In our scheme, we use a homomorphic MAC scheme to verify the integrity of the data. If the encrypted data is tampered, the integrity verification will fail; thus, the Medical Server will refuse the received packet.(b)
Replay Attack: An adversary can impersonate any node through replaying old packets recorded from past communications; therefore, we add current timestamps to messages being signed to resist replay attacks. Thus, the Medical Server can ensure data freshness by checking the validity of the timestamps.(c)
Injection Attack: With public key cryptography, any adversary can generate a reasonable ciphertext and inject it into the network to deceive the Medical Server. In our scheme, each sender computes a MAC using the symmetric key shared with the Medical Server, so the receiver will reject these injected packets in the verification of MAC step if an adversary injects its false data.To conclude, our proposed scheme provides a good level of integrity for patient’s health data.(iii)
Identity Anonymity and Authenticity: To verify the legitimacy communication between the network component devices, we propose an authentication phase in each layers of proposed network model. We analyse how our scheme is secured against attacks launched by an adversary of category C. In the proposed scheme, the authentication of the communicating parties depends on the verification of proposed signature. In the authentication phase, the hash Chebyshev polynomials are jointly applied to achieve mutual authentication. The initial authentication is between the Medical Sensors and the Aggregator, where the Aggregator authenticates the Medical Sensors using the shared signatures. If the signature stored by the Aggregator and the signature generated by the Medical Sensor are equal,S1=S1∗ and S2=S2∗, then the signatures are well verified. In case of a successful authentication, the Aggregator receives the related health data successfully. Conversely, if the Medical Sensor is in successful authentication, the Aggregator rejects the health data and not accept the Medical Sensors wants to join its network. On the other hand, the second authentication is between the Aggregator and the Medical Server. The Medical Server verifies the legitimacy of the Aggregator. The Aggregator is authenticated when the S3∗value stored in the Medical Server matches with the received S3. If S3=S3∗, then the successful authentication. Conversely, if the Aggregator is malicious and unauthorized, the Medical Server rejects the Aggregator from joining its network. However, our identity authenticity mechanism can identify the identity fraud behaviour. We can see that the proposed scheme realizes the mutual authentication of between the communication parties. By this process, the sensor devices, the gateway device, and medical server are mutually authenticated before the actual heath data transmission.(iv)
Unauthorized Aggregation: In the proposed scheme and to protect from unauthorized aggregation, the Medical Sensor and Aggregator establish interaction for local verification to prevent the adversary nodes from joining the network and in order to prevent any unauthorized third parties from performing illicit alterations. The Aggregator calculatesS1∗ and S2∗, and check the legality of the Medical Sensors. If it passes the verification, the Aggregator authenticates the legality of the Medical Sensors, and receives the related health data successfully. Conversely, if the Medical Sensor is malicious and unauthorized, the Aggregator rejects the Medical Sensors from joining its network.(v)
Data Freshness: To ensure the data freshness of the message originator, the number of the nonce and the time of sensing data are added to each data transmissions. An attacker who attempts to send valid packets already transmitted, called replay attack, cannot disrupt the network, because even if it is valid, it is not fresh, and the use of nonce prevents that attack, so the scheme ensures the data freshness.


## 6. Performance Analyses and Experimental Results

The EPPDA scheme is evaluated by providing an overview of the hardware platform, before presenting the performance results of our proposed EPPDA scheme.


### 6.1. Hardware Components

The vital sign sensing unit of this system is the MySignals HW V2 platform, which is a development platform for medical devices and health applications, as Figure7 displays [32]. It monitors patients’ health by deploying different medical sensors on patients’ body to get vital data of patients for subsequent analysis that is done by physicians [33]. The MySignals HW V2 platform is one of the most comprehensive versions on the market, as it supports more than 20 biomedical sensors to measure biometric parameters such as ECG signals, blood pressure, blood oxygen, pulse, respiratory rate, and body temperature. The MySignals HW V2 platform relies on the Atmega 328 (Arduino UNO) microcontroller to manage various sensors and allows tablets and smartphones to communicate with it [34].Figure 7
MySignals HW V2 platform [33].In contrast to the medical sensor, the Aggregator should be a device that has access to unlimited power and resources. The tablet acts as the Aggregator role and communicates with the MySignals HW V2 platform via WiFi to collect the vital signs. Figure8 shows the MySignals platform with various sensor ports. This platform can be also integrated with a WiFi serial transceiver module ESP8266, where all the data gathered by MySignals is encrypted and sent to the Aggregator through WiFi. Therefore, the Medical server is developed with the purpose of receiving, storing, and distributing the medical data from patients. In healthcare application, the medical information usually needs to be distributed among medical doctors and display, archival, and analysis devices. In the proposed solution, the Medical server is a laptop. These laptops have relatively powerful processing, memory, and transmission capacity; thus, there is no power constraint, which in turn lead to long battery life. Further, it can be displayed in an easy-to-read format for fast assessment and action. The Medical Server is composed of presentation tier, web tier, and database tier. The medical information of the patient that is stored the Medical Server will be accessible by specific people who have the authorization to access such as patient himself, doctor, and patient’s family member. The aggregated data between the system components can be encrypted by our proposed EPPDA scheme to protect it from any malicious acts of the hackers [35].Figure 8
MySignals with sensor nodes and WiFi module.


### 6.2. Experiment and Performance Evaluation

This section analyses the efficiency of the proposed EPPDA scheme by evaluating the end-to-end delay, computation overhead, communication overhead, and energy consumption, following by presenting the comparative analysis of our proposed system with the existing systems LSDA [17] and RESDA [18].


#### 6.2.1. End-to-End Delay

The end-to-end delay considers as the total time consumed between the data packet sending by the Medical Sensors and the time when the packet arrives at the Medical Server, and can be mathematically expressed as(11)Av.EndtoEndDelay=Starttimeij‐EndtimeijN,where ij is the time when sending/receiving of packet j at node i starts/stops and N is the total number of nodes. Figure 9 demonstrates the results of end-to-end delay for our proposed scheme with a comparison with other solutions in the literature. We notice that the EPPDA protocol had an enough end-to-end delay in comparison of other solutions. The experimental results revealed that the end-to-end delay of the proposed EPPDA show decreases with 17%, 28%, and 34% under varying time intervals in compassion to LSDA and RESDA, respectively. Thus, the end-to-end delay of proposed EPPDA is the best compared to the existing protocols especially when the Medical Sensors count increases. It consists of two reasons for the reduction of end-to-end delay in EPPDA:(i)
In the proposed solution, the Medical Sensors wants join the process of aggregation are verified, if the Medical Sensors is in-successful authentication, the Aggregator rejects their data in order to prevent the adversary nodes inject the false traffic; thus, avoid energy consumption unnecessary due to transmitting them.(ii)
In the medical server of the proposed solution, the packet of each Medical Sensor is verified individually. In this way, if the verification fails to pass for one packet, only this packet is discarded. Unlike other schemes, once the verification fails, all packets, including valid packets will be abandoned, which means all data need to be retransmitted.Figure 9
The end-to-end delay for LSDA, RESDA, and EPPDA.


#### 6.2.2. Computational Cost

The computation cost of the proposed EPPDA scheme can be calculated as three levels: (i) at the Medical Sensors; (ii) at the Aggregator; and (iii) at the medical server, respectively. In the Medical Sensor, we calculate the computational cost of data encryption, generation of MAC, and generation of signature used for the verifying the legitimacy of the Medical Sensor at the Aggregator. The same, at the Aggregator, we calculate the computation cost of verifying the legitimacy of the Medical Sensors, the generation of aggregate ciphertext, generation of aggregate MAC, and generation of signature used of the verifying the legitimacy of the Aggregator and medical server. At the medical server, we calculate computational cost of verifying the legitimacy of the Aggregator and verification of aggregate MAC.In the computational overhead, we designate symbol SM as the cost of one Scalar Multiplication, PA is the cost of one Point Addition,E is the cost of one modular Exponentiation, and H is the cost of one Hash operation.In our proposed scheme, when the medical sensor crypt his health data, he needs one Scalar Multiplication and two modular Exponentiation. Consequently, the computation involves (1SM+2PA) operations. Also, for generating the MAC, the sensor needs 1 hashing operation and 1 exponentiation operation. Subsequently, the computation involves (1SM+1H) operations. Moreover, each sensor generates the signature of verification which requires 1 hashing operation. The computational overhead of each medical sensor is (2SM+2PA+2H) in total for every health data.After receiving all the ciphertext and corresponding signatures, the Aggregator first verify the legitimacy of the Medical Sensors, which involves 1 hashing operation. After the verification of the legitimacy of each Medical Sensor, the Aggregator generates an aggregated cipher textCagg, which involves Scalar Multiplication. Moreover, it generates an aggregated MACagg, which involves Scalar Multiplication. Moreover, the Aggregator generates the signature of verification which requires 1 hashing operation for authentication between the Aggregator and the Medical Server. The computational overhead at Aggregator is (n∗2SM+2H).At the medical server, the computational cost of verifying the legitimacy of the Aggregator involves 1 hashing operation. Moreover, when the medical server receives the aggregated results, it needs 1 hashing operation for verifying the aggregate MAC, and it needs one Scalar Multiplication and two modular Exponentiation for computing decryption of aggregated ciphertext. The computational overhead at Aggregator is (SM +2H). The computation complexities of the major entities in the system are shown in Table3.Table 3
Computation complexity of the proposed EPPDA scheme.
Entity nameInvolving operationsComputation complexityMedical sensors(1) Crypt his health data(2) Generate the MAC(3) Generates the signature of verification the medical sensor at the aggregator2SM+2PA+2HAggregator(1) Verify the legitimacy of the medical sensors(2) Generates an aggregated cipher text Cagg(3) Generates an aggregated MACagg(4) Generates the signature of verification the aggregator at the medical server(n∗2SM+2H)Medical server(1) Verify the legitimacy of the aggregator(2) Aggregated data integrity verification(3) Data decryption5In Figure10, we present the computational cost of the proposed EPPDA scheme with a comparison to other solutions. It can be observed that our proposed scheme achieves a significant reduction in the total computation cost compared with LSDA and RESDA. To illustrate more, when the number of Medical Sensors is 10, the total computation cost of our proposed scheme is 0.6 ms, which means 20% and 35% less than LSDA and RESDA, respectively.Figure 10
The computational cost for LSDA, RESDA, and EPPDA.


#### 6.2.3. Communication Overhead

The communication overhead in the proposed EPPDA scheme is divided into two levels, namely, the communication overhead between the Medical Sensors and the Aggregator. While the second level is the communication overhead between the Aggregator and the Medical Server. The communication overhead is measured as the total data transmitted in the networks.In the Medical Sensors-to-Aggregator communication, each Medical Sensor sign their health data and transmit the data to the Aggregator. According to [18], a ciphertext generated by the OU algorithm is 160 bits. Moreover, we consider a 4-byte homomorphic MAC for calculation in accordance to [33], while the signature of verification is also 4 bytes. Therefore, in our scheme, the size of one packet transmitted to Aggregator from each Medical Sensor is 224 bits. In the Aggregator-to-Medical Server communication, the length of ciphertext Cj is 160 bits, the communication overhead of Cagg is equals 160∗n, when their n sensors are evolved into the process. In our scheme, we consider a 4-byte MAC, 4 bytes MACagg, 4 bytes for the signature of verification. Therefore, the size of one transmitted packet in our scheme is 160∗n+32+32bits. In Figure 11, we present the communication overhead of the proposed EPPDA scheme with a comparison to other solutions.Figure 11
The communication overhead for LSDA, RESDA, and EPPDA.


#### 6.2.4. Energy Consumption

Energy consumption is the central issue in application based on IoT. The Computational and communication cost are two aspects that have a direct impact on energy consumption, which subsequently leading to shorten the life of sensor nodes. Thus, the energy consumption is calculated for cryptographic operations as follows:(12)EmJ=UV×ImA×tms,where U represents the supply voltage, I represent the current draw of the hardware, and t represents the time. According to the datasheet available in [28], with MySignals HW V2 platform, the voltage is 3 V, and the wireless transceiver draws a current of 20 mA for receiving and 17.7 mA for radio transmissions. The current draw for CPU is about 1.8 mA, and in low power mode, the current draw is 0.0545 mA. The wireless communication currents (20 mA for listening and 17.7 mA for radio transmission) are much more important than the CPU current (1.8 mA); that is why communications are more expensive in terms of energy consumption than the computational primitives. In MySignals HW V2 platform, the timer produces 32,768 ticks per second. The Communication Cost is computed with the following equation, where Tx and Tr are, respectively, the Transmission time and the Receiving time.(13)CommCostmJ=Tx×17.7mA+Tr×20mA32768×3V.The Computational Energy Cost of sensor nodes is a key constituent of the overall operational energy costs in IoT. The Computational Cost is computed according to the following equation whereTcpu is the time elapsed in CPU operations:(14)ComptCostmJ=Tcpu32768×1.8mA×3V.The total power consumption by the sensor node for EPPDA scheme is estimated with the following equation:(15)TotalEnergymJ=EnergyComm+EnergyCompt.Figure12 shows the energy consumption by EPPDA is lower than that of two other schemes. The reason is that the ECIPAP and SDA-HP schemes generate too many unnecessary messages for providing integrity and privacy in data aggregation. This gain can be explained by the fact that far fewer computational loads are engaged in our algorithm, because of the use of homomorphic encryption and the Medical Sensors wanting to join the process of aggregation are verified, thus, avoid energy consumption unnecessary due to transmitting them.Figure 12
The total energy consumption for LSDA, RESDA, and EPPDA.


### 6.3. Comparison of Secure Data Aggregation Protocols

This section compares the proposed protocol with existing secure data aggregation protocols. The comparison is based on the security requirements and the performance evaluation. From Table4, it is evident that the proposed EPPDA scheme satisfies most of the security properties unlike other related data aggregation schemes in IoT-based healthcare applications. In addition, through performance evaluation, we have also demonstrated the proposed EPPDA satisfies the communication and computation overheads requirements.Table 4
Comparison between EPPDA and other solutions in the IoT-based healthcare.
SolutionsSecurity featuresEfficiencyConfidentialityIntegrityAuthenticationFreshnessScalabilityComputational costCommunication costCommunication overheadPHDA [15]YesNoYesYesNoVery highHighLargePPM-HAD [16]YesYesNoNoNoHighHighVery highLSDA [17]NoYesYesNoNoVery highVery highFairRESDA [18]YesYesYesYesNoMediumMediumFairERCS [19]YesYesNoNo⊗VeryMediumMediumCBCSES [20]YesNoYesYesNoLowVery highLargeEPPDAYesYesYesYesYesSmallVery lowVery small


## 6.1. Hardware Components

The vital sign sensing unit of this system is the MySignals HW V2 platform, which is a development platform for medical devices and health applications, as Figure7 displays [32]. It monitors patients’ health by deploying different medical sensors on patients’ body to get vital data of patients for subsequent analysis that is done by physicians [33]. The MySignals HW V2 platform is one of the most comprehensive versions on the market, as it supports more than 20 biomedical sensors to measure biometric parameters such as ECG signals, blood pressure, blood oxygen, pulse, respiratory rate, and body temperature. The MySignals HW V2 platform relies on the Atmega 328 (Arduino UNO) microcontroller to manage various sensors and allows tablets and smartphones to communicate with it [34].Figure 7
MySignals HW V2 platform [33].In contrast to the medical sensor, the Aggregator should be a device that has access to unlimited power and resources. The tablet acts as the Aggregator role and communicates with the MySignals HW V2 platform via WiFi to collect the vital signs. Figure8 shows the MySignals platform with various sensor ports. This platform can be also integrated with a WiFi serial transceiver module ESP8266, where all the data gathered by MySignals is encrypted and sent to the Aggregator through WiFi. Therefore, the Medical server is developed with the purpose of receiving, storing, and distributing the medical data from patients. In healthcare application, the medical information usually needs to be distributed among medical doctors and display, archival, and analysis devices. In the proposed solution, the Medical server is a laptop. These laptops have relatively powerful processing, memory, and transmission capacity; thus, there is no power constraint, which in turn lead to long battery life. Further, it can be displayed in an easy-to-read format for fast assessment and action. The Medical Server is composed of presentation tier, web tier, and database tier. The medical information of the patient that is stored the Medical Server will be accessible by specific people who have the authorization to access such as patient himself, doctor, and patient’s family member. The aggregated data between the system components can be encrypted by our proposed EPPDA scheme to protect it from any malicious acts of the hackers [35].Figure 8
MySignals with sensor nodes and WiFi module.


## 6.2. Experiment and Performance Evaluation

This section analyses the efficiency of the proposed EPPDA scheme by evaluating the end-to-end delay, computation overhead, communication overhead, and energy consumption, following by presenting the comparative analysis of our proposed system with the existing systems LSDA [17] and RESDA [18].


### 6.2.1. End-to-End Delay

The end-to-end delay considers as the total time consumed between the data packet sending by the Medical Sensors and the time when the packet arrives at the Medical Server, and can be mathematically expressed as(11)Av.EndtoEndDelay=Starttimeij‐EndtimeijN,where ij is the time when sending/receiving of packet j at node i starts/stops and N is the total number of nodes. Figure 9 demonstrates the results of end-to-end delay for our proposed scheme with a comparison with other solutions in the literature. We notice that the EPPDA protocol had an enough end-to-end delay in comparison of other solutions. The experimental results revealed that the end-to-end delay of the proposed EPPDA show decreases with 17%, 28%, and 34% under varying time intervals in compassion to LSDA and RESDA, respectively. Thus, the end-to-end delay of proposed EPPDA is the best compared to the existing protocols especially when the Medical Sensors count increases. It consists of two reasons for the reduction of end-to-end delay in EPPDA:(i)
In the proposed solution, the Medical Sensors wants join the process of aggregation are verified, if the Medical Sensors is in-successful authentication, the Aggregator rejects their data in order to prevent the adversary nodes inject the false traffic; thus, avoid energy consumption unnecessary due to transmitting them.(ii)
In the medical server of the proposed solution, the packet of each Medical Sensor is verified individually. In this way, if the verification fails to pass for one packet, only this packet is discarded. Unlike other schemes, once the verification fails, all packets, including valid packets will be abandoned, which means all data need to be retransmitted.Figure 9
The end-to-end delay for LSDA, RESDA, and EPPDA.


### 6.2.2. Computational Cost

The computation cost of the proposed EPPDA scheme can be calculated as three levels: (i) at the Medical Sensors; (ii) at the Aggregator; and (iii) at the medical server, respectively. In the Medical Sensor, we calculate the computational cost of data encryption, generation of MAC, and generation of signature used for the verifying the legitimacy of the Medical Sensor at the Aggregator. The same, at the Aggregator, we calculate the computation cost of verifying the legitimacy of the Medical Sensors, the generation of aggregate ciphertext, generation of aggregate MAC, and generation of signature used of the verifying the legitimacy of the Aggregator and medical server. At the medical server, we calculate computational cost of verifying the legitimacy of the Aggregator and verification of aggregate MAC.In the computational overhead, we designate symbol SM as the cost of one Scalar Multiplication, PA is the cost of one Point Addition,E is the cost of one modular Exponentiation, and H is the cost of one Hash operation.In our proposed scheme, when the medical sensor crypt his health data, he needs one Scalar Multiplication and two modular Exponentiation. Consequently, the computation involves (1SM+2PA) operations. Also, for generating the MAC, the sensor needs 1 hashing operation and 1 exponentiation operation. Subsequently, the computation involves (1SM+1H) operations. Moreover, each sensor generates the signature of verification which requires 1 hashing operation. The computational overhead of each medical sensor is (2SM+2PA+2H) in total for every health data.After receiving all the ciphertext and corresponding signatures, the Aggregator first verify the legitimacy of the Medical Sensors, which involves 1 hashing operation. After the verification of the legitimacy of each Medical Sensor, the Aggregator generates an aggregated cipher textCagg, which involves Scalar Multiplication. Moreover, it generates an aggregated MACagg, which involves Scalar Multiplication. Moreover, the Aggregator generates the signature of verification which requires 1 hashing operation for authentication between the Aggregator and the Medical Server. The computational overhead at Aggregator is (n∗2SM+2H).At the medical server, the computational cost of verifying the legitimacy of the Aggregator involves 1 hashing operation. Moreover, when the medical server receives the aggregated results, it needs 1 hashing operation for verifying the aggregate MAC, and it needs one Scalar Multiplication and two modular Exponentiation for computing decryption of aggregated ciphertext. The computational overhead at Aggregator is (SM +2H). The computation complexities of the major entities in the system are shown in Table3.Table 3
Computation complexity of the proposed EPPDA scheme.
Entity nameInvolving operationsComputation complexityMedical sensors(1) Crypt his health data(2) Generate the MAC(3) Generates the signature of verification the medical sensor at the aggregator2SM+2PA+2HAggregator(1) Verify the legitimacy of the medical sensors(2) Generates an aggregated cipher text Cagg(3) Generates an aggregated MACagg(4) Generates the signature of verification the aggregator at the medical server(n∗2SM+2H)Medical server(1) Verify the legitimacy of the aggregator(2) Aggregated data integrity verification(3) Data decryption5In Figure10, we present the computational cost of the proposed EPPDA scheme with a comparison to other solutions. It can be observed that our proposed scheme achieves a significant reduction in the total computation cost compared with LSDA and RESDA. To illustrate more, when the number of Medical Sensors is 10, the total computation cost of our proposed scheme is 0.6 ms, which means 20% and 35% less than LSDA and RESDA, respectively.Figure 10
The computational cost for LSDA, RESDA, and EPPDA.


### 6.2.3. Communication Overhead

The communication overhead in the proposed EPPDA scheme is divided into two levels, namely, the communication overhead between the Medical Sensors and the Aggregator. While the second level is the communication overhead between the Aggregator and the Medical Server. The communication overhead is measured as the total data transmitted in the networks.In the Medical Sensors-to-Aggregator communication, each Medical Sensor sign their health data and transmit the data to the Aggregator. According to [18], a ciphertext generated by the OU algorithm is 160 bits. Moreover, we consider a 4-byte homomorphic MAC for calculation in accordance to [33], while the signature of verification is also 4 bytes. Therefore, in our scheme, the size of one packet transmitted to Aggregator from each Medical Sensor is 224 bits. In the Aggregator-to-Medical Server communication, the length of ciphertext Cj is 160 bits, the communication overhead of Cagg is equals 160∗n, when their n sensors are evolved into the process. In our scheme, we consider a 4-byte MAC, 4 bytes MACagg, 4 bytes for the signature of verification. Therefore, the size of one transmitted packet in our scheme is 160∗n+32+32bits. In Figure 11, we present the communication overhead of the proposed EPPDA scheme with a comparison to other solutions.Figure 11
The communication overhead for LSDA, RESDA, and EPPDA.


### 6.2.4. Energy Consumption

Energy consumption is the central issue in application based on IoT. The Computational and communication cost are two aspects that have a direct impact on energy consumption, which subsequently leading to shorten the life of sensor nodes. Thus, the energy consumption is calculated for cryptographic operations as follows:(12)EmJ=UV×ImA×tms,where U represents the supply voltage, I represent the current draw of the hardware, and t represents the time. According to the datasheet available in [28], with MySignals HW V2 platform, the voltage is 3 V, and the wireless transceiver draws a current of 20 mA for receiving and 17.7 mA for radio transmissions. The current draw for CPU is about 1.8 mA, and in low power mode, the current draw is 0.0545 mA. The wireless communication currents (20 mA for listening and 17.7 mA for radio transmission) are much more important than the CPU current (1.8 mA); that is why communications are more expensive in terms of energy consumption than the computational primitives. In MySignals HW V2 platform, the timer produces 32,768 ticks per second. The Communication Cost is computed with the following equation, where Tx and Tr are, respectively, the Transmission time and the Receiving time.(13)CommCostmJ=Tx×17.7mA+Tr×20mA32768×3V.The Computational Energy Cost of sensor nodes is a key constituent of the overall operational energy costs in IoT. The Computational Cost is computed according to the following equation whereTcpu is the time elapsed in CPU operations:(14)ComptCostmJ=Tcpu32768×1.8mA×3V.The total power consumption by the sensor node for EPPDA scheme is estimated with the following equation:(15)TotalEnergymJ=EnergyComm+EnergyCompt.Figure12 shows the energy consumption by EPPDA is lower than that of two other schemes. The reason is that the ECIPAP and SDA-HP schemes generate too many unnecessary messages for providing integrity and privacy in data aggregation. This gain can be explained by the fact that far fewer computational loads are engaged in our algorithm, because of the use of homomorphic encryption and the Medical Sensors wanting to join the process of aggregation are verified, thus, avoid energy consumption unnecessary due to transmitting them.Figure 12
The total energy consumption for LSDA, RESDA, and EPPDA.


## 6.2.1. End-to-End Delay

The end-to-end delay considers as the total time consumed between the data packet sending by the Medical Sensors and the time when the packet arrives at the Medical Server, and can be mathematically expressed as(11)Av.EndtoEndDelay=Starttimeij‐EndtimeijN,where ij is the time when sending/receiving of packet j at node i starts/stops and N is the total number of nodes. Figure 9 demonstrates the results of end-to-end delay for our proposed scheme with a comparison with other solutions in the literature. We notice that the EPPDA protocol had an enough end-to-end delay in comparison of other solutions. The experimental results revealed that the end-to-end delay of the proposed EPPDA show decreases with 17%, 28%, and 34% under varying time intervals in compassion to LSDA and RESDA, respectively. Thus, the end-to-end delay of proposed EPPDA is the best compared to the existing protocols especially when the Medical Sensors count increases. It consists of two reasons for the reduction of end-to-end delay in EPPDA:(i)
In the proposed solution, the Medical Sensors wants join the process of aggregation are verified, if the Medical Sensors is in-successful authentication, the Aggregator rejects their data in order to prevent the adversary nodes inject the false traffic; thus, avoid energy consumption unnecessary due to transmitting them.(ii)
In the medical server of the proposed solution, the packet of each Medical Sensor is verified individually. In this way, if the verification fails to pass for one packet, only this packet is discarded. Unlike other schemes, once the verification fails, all packets, including valid packets will be abandoned, which means all data need to be retransmitted.Figure 9
The end-to-end delay for LSDA, RESDA, and EPPDA.


## 6.2.2. Computational Cost

The computation cost of the proposed EPPDA scheme can be calculated as three levels: (i) at the Medical Sensors; (ii) at the Aggregator; and (iii) at the medical server, respectively. In the Medical Sensor, we calculate the computational cost of data encryption, generation of MAC, and generation of signature used for the verifying the legitimacy of the Medical Sensor at the Aggregator. The same, at the Aggregator, we calculate the computation cost of verifying the legitimacy of the Medical Sensors, the generation of aggregate ciphertext, generation of aggregate MAC, and generation of signature used of the verifying the legitimacy of the Aggregator and medical server. At the medical server, we calculate computational cost of verifying the legitimacy of the Aggregator and verification of aggregate MAC.In the computational overhead, we designate symbol SM as the cost of one Scalar Multiplication, PA is the cost of one Point Addition,E is the cost of one modular Exponentiation, and H is the cost of one Hash operation.In our proposed scheme, when the medical sensor crypt his health data, he needs one Scalar Multiplication and two modular Exponentiation. Consequently, the computation involves (1SM+2PA) operations. Also, for generating the MAC, the sensor needs 1 hashing operation and 1 exponentiation operation. Subsequently, the computation involves (1SM+1H) operations. Moreover, each sensor generates the signature of verification which requires 1 hashing operation. The computational overhead of each medical sensor is (2SM+2PA+2H) in total for every health data.After receiving all the ciphertext and corresponding signatures, the Aggregator first verify the legitimacy of the Medical Sensors, which involves 1 hashing operation. After the verification of the legitimacy of each Medical Sensor, the Aggregator generates an aggregated cipher textCagg, which involves Scalar Multiplication. Moreover, it generates an aggregated MACagg, which involves Scalar Multiplication. Moreover, the Aggregator generates the signature of verification which requires 1 hashing operation for authentication between the Aggregator and the Medical Server. The computational overhead at Aggregator is (n∗2SM+2H).At the medical server, the computational cost of verifying the legitimacy of the Aggregator involves 1 hashing operation. Moreover, when the medical server receives the aggregated results, it needs 1 hashing operation for verifying the aggregate MAC, and it needs one Scalar Multiplication and two modular Exponentiation for computing decryption of aggregated ciphertext. The computational overhead at Aggregator is (SM +2H). The computation complexities of the major entities in the system are shown in Table3.Table 3
Computation complexity of the proposed EPPDA scheme.
Entity nameInvolving operationsComputation complexityMedical sensors(1) Crypt his health data(2) Generate the MAC(3) Generates the signature of verification the medical sensor at the aggregator2SM+2PA+2HAggregator(1) Verify the legitimacy of the medical sensors(2) Generates an aggregated cipher text Cagg(3) Generates an aggregated MACagg(4) Generates the signature of verification the aggregator at the medical server(n∗2SM+2H)Medical server(1) Verify the legitimacy of the aggregator(2) Aggregated data integrity verification(3) Data decryption5In Figure10, we present the computational cost of the proposed EPPDA scheme with a comparison to other solutions. It can be observed that our proposed scheme achieves a significant reduction in the total computation cost compared with LSDA and RESDA. To illustrate more, when the number of Medical Sensors is 10, the total computation cost of our proposed scheme is 0.6 ms, which means 20% and 35% less than LSDA and RESDA, respectively.Figure 10
The computational cost for LSDA, RESDA, and EPPDA.


## 6.2.3. Communication Overhead

The communication overhead in the proposed EPPDA scheme is divided into two levels, namely, the communication overhead between the Medical Sensors and the Aggregator. While the second level is the communication overhead between the Aggregator and the Medical Server. The communication overhead is measured as the total data transmitted in the networks.In the Medical Sensors-to-Aggregator communication, each Medical Sensor sign their health data and transmit the data to the Aggregator. According to [18], a ciphertext generated by the OU algorithm is 160 bits. Moreover, we consider a 4-byte homomorphic MAC for calculation in accordance to [33], while the signature of verification is also 4 bytes. Therefore, in our scheme, the size of one packet transmitted to Aggregator from each Medical Sensor is 224 bits. In the Aggregator-to-Medical Server communication, the length of ciphertext Cj is 160 bits, the communication overhead of Cagg is equals 160∗n, when their n sensors are evolved into the process. In our scheme, we consider a 4-byte MAC, 4 bytes MACagg, 4 bytes for the signature of verification. Therefore, the size of one transmitted packet in our scheme is 160∗n+32+32bits. In Figure 11, we present the communication overhead of the proposed EPPDA scheme with a comparison to other solutions.Figure 11
The communication overhead for LSDA, RESDA, and EPPDA.


## 6.2.4. Energy Consumption

Energy consumption is the central issue in application based on IoT. The Computational and communication cost are two aspects that have a direct impact on energy consumption, which subsequently leading to shorten the life of sensor nodes. Thus, the energy consumption is calculated for cryptographic operations as follows:(12)EmJ=UV×ImA×tms,where U represents the supply voltage, I represent the current draw of the hardware, and t represents the time. According to the datasheet available in [28], with MySignals HW V2 platform, the voltage is 3 V, and the wireless transceiver draws a current of 20 mA for receiving and 17.7 mA for radio transmissions. The current draw for CPU is about 1.8 mA, and in low power mode, the current draw is 0.0545 mA. The wireless communication currents (20 mA for listening and 17.7 mA for radio transmission) are much more important than the CPU current (1.8 mA); that is why communications are more expensive in terms of energy consumption than the computational primitives. In MySignals HW V2 platform, the timer produces 32,768 ticks per second. The Communication Cost is computed with the following equation, where Tx and Tr are, respectively, the Transmission time and the Receiving time.(13)CommCostmJ=Tx×17.7mA+Tr×20mA32768×3V.The Computational Energy Cost of sensor nodes is a key constituent of the overall operational energy costs in IoT. The Computational Cost is computed according to the following equation whereTcpu is the time elapsed in CPU operations:(14)ComptCostmJ=Tcpu32768×1.8mA×3V.The total power consumption by the sensor node for EPPDA scheme is estimated with the following equation:(15)TotalEnergymJ=EnergyComm+EnergyCompt.Figure12 shows the energy consumption by EPPDA is lower than that of two other schemes. The reason is that the ECIPAP and SDA-HP schemes generate too many unnecessary messages for providing integrity and privacy in data aggregation. This gain can be explained by the fact that far fewer computational loads are engaged in our algorithm, because of the use of homomorphic encryption and the Medical Sensors wanting to join the process of aggregation are verified, thus, avoid energy consumption unnecessary due to transmitting them.Figure 12
The total energy consumption for LSDA, RESDA, and EPPDA.


## 6.3. Comparison of Secure Data Aggregation Protocols

This section compares the proposed protocol with existing secure data aggregation protocols. The comparison is based on the security requirements and the performance evaluation. From Table4, it is evident that the proposed EPPDA scheme satisfies most of the security properties unlike other related data aggregation schemes in IoT-based healthcare applications. In addition, through performance evaluation, we have also demonstrated the proposed EPPDA satisfies the communication and computation overheads requirements.Table 4
Comparison between EPPDA and other solutions in the IoT-based healthcare.
SolutionsSecurity featuresEfficiencyConfidentialityIntegrityAuthenticationFreshnessScalabilityComputational costCommunication costCommunication overheadPHDA [15]YesNoYesYesNoVery highHighLargePPM-HAD [16]YesYesNoNoNoHighHighVery highLSDA [17]NoYesYesNoNoVery highVery highFairRESDA [18]YesYesYesYesNoMediumMediumFairERCS [19]YesYesNoNo⊗VeryMediumMediumCBCSES [20]YesNoYesYesNoLowVery highLargeEPPDAYesYesYesYesYesSmallVery lowVery small


## 7. Conclusions

The recent developments in the area of IoT shows a great promise for providing solutions for healthcare. Yet, protecting data privacy and integrity during data aggregation at the same time is a common challenge in IoT-based healthcare systems. This paper presents a novel secure aggregation scheme that provide provably secure message integrity with different trade-off between computation cost, communication payload, and security assumptions. The proposed EPPDA is based on the verification and authorization phase to verifying the legitimacy of the nodes wanting to join the process of aggregation. The proposed scheme, also, uses on an additive homomorphic encryption algorithm that allows aggregation on encrypted data that combined with homomorphic MAC. The security analysis and performance evaluation show that our scheme is able to resist against various attacks such as compromise node attacks and unauthorized aggregation. A comparison of the communication overhead with respect to the existing protocols exhibits the viability efficiency of the proposed protocol on resource-constrained devices. Further research can be considered to study the possibility of applying this algorithm in different types of medical sensors and then assess whether or not there are better outcome results can be obtained.



---

*Source: 5594159-2021-03-09.xml*