# Preserving Data Privacy in the Internet of Medical Things Using Dual Signature ECDSA

Authors: Maria-Dolores Cano; Antonio Cañavate-Sanchez
Journal: Security and Communication Networks
 (2020)

---

## Abstract

The disclosure of personal and private information is one of the main challenges of the Internet of Medical Things (IoMT). Most IoMT-based services, applications, and platforms follow a common architecture where wearables or other medical devices capture data that are forwarded to the cloud. In this scenario, edge computing brings new opportunities to enhance the operation of IoMT. However, despite the benefits, the inherent characteristics of edge computing require countermeasures to address the security and privacy issues that IoMT gives rise to. The restrictions of IoT devices in terms of battery, memory, hardware resources, or computing capabilities have led to a common agreement for the use of elliptic curve cryptography (ECC) with hardware or software implementations. As an example, the elliptic curve digital signature algorithm (ECDSA) is widely used by IoT devices to compute digital signatures. On the other hand, it is well known that dual signature has been an effective method to provide consumer privacy in classic e-commerce services. This article joins both approaches. It presents a novel solution to enhanced security and the preservation of data privacy in communications between IoMT devices and the cloud via edge computing devices. While data source anonymity is achieved from the cloud perspective, integrity and origin authentication of the collected data is also provided. In addition, computational requirements and complexity are kept to a minimum.


---

## Body

## 1. Introduction

Our physical universe is acquiring a new digital existence with the arrival of the Internet of Things (IoT). Many beings/objects are expected to have connectivity and the capacity to collaborate. With billions or trillions of IoT devices connecting to the cloud to exchange, process, and store information, the network architecture must adapt in the most agile, intelligent, and efficient way possible to maintain the quality of the provided services while considering the heterogeneity of networks and devices. Despite the advantages of a conventional, centralized cloud model, the future IoT faces significant challenges: latency, velocity, volume of data, location awareness, mobility support, or monopoly versus an open IoT contention, among others [1, 2]. This is of great importance in the Internet of Medical Things, since data are not only used for disease prediction but also for health monitoring and treatment, where it is vital to control these key performance metrics [3–5].Edge computing can address these challenges by offering the additional computing, storage, and communication resources for particular tasks, thus liberating both IoMT devices and the cloud and improving the performance of traditional cloud computing services [6]. However, one key concern about the use of edge computing is security. The edge not only inherits some of the cloud’s security challenges but also attributes to new vulnerabilities and threats (e.g., in terms of secure data computation, secure data storage, privacy protection, authentication, and access control [7]). Particularly, the authors focus this work on how to preserve the privacy of data sent by IoMT devices to the cloud using edge computing while at the same time permitting the cloud and the edge devices to authenticate the integrity and the origin of the data. Authentication is defined as the ability to demonstrate you are who you say you are. In terms of data exchange in a communication network, there is authentication if the sender of a message can be identified unequivocally by the receiver. In turn, there is integrity if it can be demonstrated that a message/information has not been created, modified, or deleted by unauthorized users or systems.In this work, the authors propose a method to be used in IoMT scenarios that is able to provide data integrity and data privacy while guaranteeing that the data have come from an authenticated IoMT source. To this end, the authors introduce the concept of dual signature (DS) in the elliptic curve digital signature algorithm (ECDSA) [8]. Note that a dual signature is not a double signature, but a technique to couple two values of different natures, keeping them anonymous to two different entities in a secure fashion. Besides simplicity, the authors’ approach differs from previous works in that it is compatible with hardware implementations. Recent works have demonstrated that public key cryptography with elliptic curve cryptography (ECC) in constrained IoT devices, in general, is not a concern. Furthermore, ECDSA signature creation is affordable and effective [9–11]. Moreover, ECDSA signature verification, which is considered to be a computationally intensive task [12], will not be carried out by IoMT devices but by edge network elements, which have no operational constrains, thus making this an appropriate, agile, and simple solution for IoMT environments.The rest of the paper is organized as follows. Section2 reviews the state of the art, showing related works from the scientific literature. In Section 3, the authors introduce the concept of dual signature in ECDSA, describing the communication process from the IoMT transmission device to the cloud via edge computing elements, demonstrating its security features. Section 4 is devoted to security analysis and computational requirements. The paper ends summarizing the most important outcomes.


## 2. Related Works

It is important to note that providing data privacy in terms of anonymity and integrity is needed not only in advanced health systems but also in other scenarios such as intelligent traffic systems (ITS) dealing with driver or vehicle information or in collaborative social applications managing peoples’ data. Therefore, it is encouraging to observe the proposals that researchers are suggesting in these other communication fields. In this regard, several works can be found in the related literature addressing the preservation of data privacy in IoT [13–20].In [14], the authors presented a public key ECC-based solution for intelligent transportation environments, where the task of authenticating the vehicles within the coverage of a road side unit (RSU) was a shared assignment between the vehicles themselves and the RSU. Specifically, those vehicles with better computation resources and which were closer to the RSU were selected as edge nodes. These vehicles were then responsible for the authentication of messages transmitted by nearby vehicles, incorporating batch authentication. They were also responsible for sending the results to the RSU, which then verified the previously processed information. The authors also proposed the use of a cuckoo filter and fuzzy logic to speed up the process. It is important to note that in [14], there are third-party authorities that are trusted by all entities (one for each RSU), which are able to ascertain the real identity of the vehicles. A similar approach is followed in [18]. In [15], several Bloom filter probabilistic data structures are employed to authenticate both vehicles and unmanned aerial vehicles (UAV). Basically, the IDs of vehicles under UAV coverage that have been authenticated are hashed and stored in Bloom filters, and thus messages from these vehicles are only forwarded to the next communication element if the UAV queries the Bloom filters and the result is positive. No more information about the authentication, integrity, or privacy processes was provided in that work.Li et al. introduced in [16] a homomorphic Boneh–Goh–Nissim-based method for preserving privacy in mobile edge computing scenarios. The solution seems to be very interesting and robust from a security perspective. The performance evaluation of this method was previously presented in [21]. Similar approaches to [16, 21] were proposed by Wang et al. [22] and Wang [23]. In both cases, the proposals were based on the use of homomorphic encryption to provide confidentiality. In the former, privacy was achieved by using pseudonyms when data are forwarded from the edge/fog computing device to the cloud, instead of using the device identification information. Aggregation at the edge/fog device allowed for a more efficient data transmission to the cloud in terms of overhead compared to other methods, as shown by the authors. In the latter, the same idea of including an intermediate element (edge or fog device) to aggregate data and to provide users’ privacy is proposed, with comparable results. However, it is noteworthy to mention that possible limitations to the use of homomorphic encryption could arise in terms of IoT device energy consumption. Nevertheless, these challenges could be reduced or even resolved as new improvements are incorporated into homomorphic encryption techniques, as indicated in [24].Particularly for the IoMT paradigm, its novelty limits the contributions found in the scientific literature. Deebak et al. presented in [25] an anonymous and secure user authentication method based on biometric data to protect communications in healthcare applications. Their proposal was also based on the use of elliptic cryptography, together with smart cards that stored users’ biometric information. Once a user was authenticated, a key generation process started so that the communication channel would be made secure (ciphered) using this key. Two possible limitations of this proposal are the necessity of using physical smart cards (an active approach from the users’ perspective) and the congestion that could appear in case of a high number of IoMT devices, as the authors state in their conclusions.In [26], the authors proposed a novel method for encryption and encoding to be used in IoMT based on the Advanced Encryption Standard (AES). They experimentally tested the performance of their proposal, whose main advantage was that the time required to perform the encryption and encoding processes was shorter compared with traditional cryptographic techniques. As another example, the authors in [27] proposed a key generation mechanism using biometric information as input. The keys were then employed for medical data encryption. As a key generation method, their proposal outperformed other existing technologies.From a different perspective, Guan et al. addressed in [28] privacy in IoMT by using machine learning. Their goal was to guarantee that by accessing the medical information dataset, an attacker could not obtain specific individual information but only approximate data. In order to do so, they suggested an original process to update the centroids of the clusters, which are used for clustering-based learning, incorporating controlled noise. The results were notable, but as indicated by the authors, there is a trade-off between privacy preservation and the accuracy of cluster results. Other works can be found dealing with the assessment of security levels in IoMT [29, 30] or how to perform accurate auditing actions [31].The approach introduced in this paper differs from previous works in two main factors: simplicity and hardware compatibility. Although Bloom filters and other more recent data structures such as cuckoo filters are very promising for security applications, they still face problems having to do with hardware implementation [32]. Nevertheless, it is important to observe that our proposal is compatible with the use of these membership query techniques. In addition, previous works have mostly focused on how to achieve a successful level of confidentiality by improving either the encryption technique or the key generation process. In this work, our proposal is not focused only on confidentiality but also on how to protect the anonymity of the person/device that generates the data, with the awareness that data confidentiality can be added as another security layer depending on the energy and computational restrictions of the IoMT source device.


## 3. ECDSA with Dual Signature

### 3.1. System Description

Digital signatures have been widely used since their introduction in cryptosystems [33]. Dual signature was presented in [34] as an effective way to link two different types of information in e-commerce, particularly, the buyer’s order information (OI) and the buyer’s payment information (PI). Linking is done in such a way that the PI is hidden from the seller and the OI is hidden from the bank, but both recipients (seller and bank) can unquestionably verify the authenticity and integrity of both data. Dual signature can be implemented with any asymmetric encryption algorithm.Figure1 shows the general procedure of a dual signature. As depicted in Figure 1(a), both the OI and PI are individually hashed. Then, these two hashes are concatenated and hashed. The resulting hash is encrypted with the client’s private key and the output is called a dual signature. Observe that when the client sends a message to the seller and the bank (Figure 1(b)), the seller receives the OI in plaintext and the hash of the PI. Therefore, the seller can verify the dual signature without receiving the payment information and using the client’s public key. The same applies to the bank, but in this case, the information that the seller forwards to the bank is only what appears encrypted with the bank’s public key (KPBank) in Figure 1(b). Consequently, the bank will not know what the client bought (the OI) and will only know the payment information.Figure 1
General procedure of a dual signature whereH represents a secure hash function (E≡encrypt; D≡decrypt; ||≡concatenate; Kpclient≡the buyer’s private key; KPclient≡the buyer’s public key; KPBank≡the bank’s public key; ✓≡available data): (a) dual signature generation and (b) message sent from the buyer to the merchant and to the bank together with the dual signature verification processes.
(a)(b)The authors’ proposal inherits the procedure shown in Figure1 and adapts it to the IoMT paradigm. Figure 2 represents a general IoT communication scenario with three participants, namely, transmission devices (TDs), edge computing servers/devices (ECSs), and the cloud (C). TDs are IoT devices with computational and energy constraints that collect and send data to the C via an ECS. ECSs are located near TDs, at the edge of the network, and they have computing abilities. Smartphones or computers can be examples of ECS devices. C is a central cloud service that stores and processes data.Figure 2
IoT communication scenario.Table1 includes all the notations that will be used hereinafter. The proposal is based on the use of ECC [35, 36]. It is assumed that all participants go through a secure initiation phase to obtain a private/public ECC key pair (d, Q), using G as the generator point of the elliptic group Ep(a, b) and n being a very large integer. Alternatively, the key pairs (d, Q) could be obtained using a prestored strategy. In any case, private keys are kept secret and the relationship between private and public keys is Q = d ⋅ G.Table 1
Notation.
SymbolMeaningTDiThei-th transmission deviceECSjThej-th edge computing device/serverIDTDiThe identification of TDiG, nA generator point inEp(a, b) with a very large order nHA secure hash algorithmdTDiThe private key of TDiQTDiQTDi = dTDiG, the public key of TDidCThe private key ofCQCQC = dC⋅G, the public key of C(r, s)The dual signaturePPoints withinEp(a, b)PA prime numberEThe hash of datamFThe hash of the value IDTDiGH(e ‖ f), the hash of e and fMData to be sent by a transmission device TDiOnce key pairs are generated,C’s public key QC is published and veritably known by all TDi and ECSj, where i = {1, 2, …, m}, j = {1, 2, …, z}, and z << m. Likewise, each ECSj knows the public keys QTDi of all TDi under its coverage. Note that C does not need to be aware of TDi’s public keys. Then, when an IoMT device TDi has collected information m that needs to be sent, it proceeds as follows:(1)
TDi selects a random (or pseudorandom) integer k, k ∈ [1, n − 1].(2)
TDi computes P1(x1, y1) = k⋅G and r is defined as follows(1)r=x1modn.(3)
Then, TDi computes e = H(m), f = H(IDTDi), and g = H(e || f). In all cases, H should be a strong hash function (e.g., SHA-2 or SHA-3)(4)
Finally, TDi calculates s as shown in equation (2). The obtained dual signature is the pair (r, s).(2)s=k−1g+dTDi⋅rmodn.At this point, TDi sends a message M1 to ECSj containing health-related data. M1 is depicted in Figure 3. This message M1 has two parts. The first part {IDTDi, e, (r, s)} is sent in plaintext and contains the following information: the identification of TDi, the hash e of the collected health data m, and the dual signature (r, s). The second part of M1 is encrypted with an asymmetric cryptographic technique using the public key of the cloud, QC. Any asymmetric encryption technique can be used depending on the capabilities of TDi. The encrypted data that M1 contains are the collected health data m, the hash f of the identification of TDi, the public key QTDi, and the dual signature (r, s).Figure 3
MessageM1 from TDi to ECSj.Upon the reception ofM1, the edge device ECSj verifies the authenticity and integrity of M1 using the public key QTDi as follows:(1)
ECSj verifies that both r and s are integers, i.e., (s, r) ∈ [1, n − 1].(2)
ECSj calculates f = H(IDTDi) and g= H(e || f); observe that IDTDi and e were sent as plaintext in M1 (Figure 3).(3)
Then, the ECSj calculates w as shown in the following equation:(3)w=s−1modn.(4)
It calculatesu1 and u2 as depicted in equations (4) and (5):(4)u1=w⋅g,(5)u2=w⋅r.(5)
Fromu1 and u2, ECSj computes the point P2 as shown in equation (6). Observe that, as usual in asymmetric methods, ECSj knows the public key of TDi.(6)P2x2,y2=u1⋅G+u2⋅QTDi.(6)
Then, ECSj computes v = x2 mod n.Consequently, ifv= r, then ECSj accepts the dual signature, or else it rejects it. Even though ECSj does not have access to the collected health data m (note that m is encrypted with QC as depicted in Figure 3), ECSj can guarantee that TDi was the IoMT device that sent this information m. The reason is that only TDi knows its secret key dTDi, which was used to create the dual signature. In addition, ECSj knows that m has not been modified, hence confirming the integrity of the information; otherwise, the dual signature would have been invalid (and rejected). The demonstration of the verification of the dual signature is detailed later in Section 3.2.Next, we assume that ECSj sends a message M2 to C. The message M2 also has two parts, as illustrated in Figure 4. The first part will be used by C to authenticate the source of this message. This could be done with a classic ECDSA signature. In Figure 4, IDECSj is the ID of ECSj, which sends this message, and h is the resulting hash of the complete message M2. The second part of M2 is equal to the batch of all the encrypted data in messages M1i coming from the different IoMT devices TDi within the coverage of the same ECSj. In other words, ECSj appends each grey part corresponding to the encrypted information that each TDi transmitted to ECSj {m, f, QTDi, (r, s)}Qc. This message M2 is sent from ECSj to C. Upon the arrival of M2 to the cloud C and after verifying the origin and integrity of this message by checking the ECDSA classic signature, C proceeds as follows:Figure 4
MessageM2 from ECSj to C.(1)
C decrypts all blocks {m, f, QTDi, (r, s)}Qc using the cloud’s private key dC.(2)
For each block, C calculatese = H(m) and g= H(e ‖ f).(3)
Then, it calculatesw= s−1 mod n.(4)
Now,C calculates u1 and u2 as depicted in equations (7) and (8):(7)u1=w⋅g,(8)u2=w⋅r.(5)
C computes the point asP3 as indicated in the following equation:(9)P3x3,y3=u1⋅G+u2⋅QTDi.(6)
Finally,C computes v= x3 mod n.As described before, ifv= r, the dual signature is accepted by the cloud C (otherwise, it is rejected). After this operation, C can guarantee that the received data m has not been modified and that m was sent by an authenticated IoMT TD, although the identity of this device is unknown to C. Observe that C knows the value of the public key QTDi, but it does not know the identity of TDi. In other words, health data privacy is preserved without losing origin authentication and integrity.


### 3.2. Demonstration

In order to demonstrate the goodness of the proposal, let us assume that ECSj has received the message M1 = {IDTDi, e, {m, f, QTDi)}Qc, (r, s)}. Let us also assume that M1 has not been altered. Then, from equation (2) we can carry out the following operations:(10)k=s−1g+dTDi⋅rmodn,k=s−1⋅g+s−1⋅dTDi⋅rmodn.In equation (10), we can substitute some terms using equations (3)–(5), so the new expression will be(11)k=w⋅g+w⋅dTDi⋅rmodn,k=u1+u2⋅dTDimodn.At the transmission device TDi we defined P1(x1, y1) = k⋅G, whereas in reception (at the ECSj), we have that P2(x2, y2) = u1⋅G +  u2⋅ QTDi. If P1 is equal to P2, then r and vwould be equal and the dual signature would be correct because both values r and v correspond to the x coordinates of P1 and P2, respectively. Let us verify this by taking into account that the public key of TDi was obtained as QTDi = dTDi⋅G:(12)P2x2,y2=u1⋅G+u2⋅QTDi=u1⋅G+u2⋅dTDi⋅G=u1+u2⋅dTDi⋅G.Subsequently, applying equation (11), we have that(13)P2x2,y2=u1+u2⋅dTDi⋅G=k⋅G=P1x1,y1.Accordingly, both valuesr = x1 mod n (calculated at TDi) and v= x2 mod n (calculated at ECSj) will be equal. Any modification of the transmitted values in M1 would cause different values for e or f and therefore for g, leading to the detection of the attack. The same demonstration procedure should be applied for M2.


## 3.1. System Description

Digital signatures have been widely used since their introduction in cryptosystems [33]. Dual signature was presented in [34] as an effective way to link two different types of information in e-commerce, particularly, the buyer’s order information (OI) and the buyer’s payment information (PI). Linking is done in such a way that the PI is hidden from the seller and the OI is hidden from the bank, but both recipients (seller and bank) can unquestionably verify the authenticity and integrity of both data. Dual signature can be implemented with any asymmetric encryption algorithm.Figure1 shows the general procedure of a dual signature. As depicted in Figure 1(a), both the OI and PI are individually hashed. Then, these two hashes are concatenated and hashed. The resulting hash is encrypted with the client’s private key and the output is called a dual signature. Observe that when the client sends a message to the seller and the bank (Figure 1(b)), the seller receives the OI in plaintext and the hash of the PI. Therefore, the seller can verify the dual signature without receiving the payment information and using the client’s public key. The same applies to the bank, but in this case, the information that the seller forwards to the bank is only what appears encrypted with the bank’s public key (KPBank) in Figure 1(b). Consequently, the bank will not know what the client bought (the OI) and will only know the payment information.Figure 1
General procedure of a dual signature whereH represents a secure hash function (E≡encrypt; D≡decrypt; ||≡concatenate; Kpclient≡the buyer’s private key; KPclient≡the buyer’s public key; KPBank≡the bank’s public key; ✓≡available data): (a) dual signature generation and (b) message sent from the buyer to the merchant and to the bank together with the dual signature verification processes.
(a)(b)The authors’ proposal inherits the procedure shown in Figure1 and adapts it to the IoMT paradigm. Figure 2 represents a general IoT communication scenario with three participants, namely, transmission devices (TDs), edge computing servers/devices (ECSs), and the cloud (C). TDs are IoT devices with computational and energy constraints that collect and send data to the C via an ECS. ECSs are located near TDs, at the edge of the network, and they have computing abilities. Smartphones or computers can be examples of ECS devices. C is a central cloud service that stores and processes data.Figure 2
IoT communication scenario.Table1 includes all the notations that will be used hereinafter. The proposal is based on the use of ECC [35, 36]. It is assumed that all participants go through a secure initiation phase to obtain a private/public ECC key pair (d, Q), using G as the generator point of the elliptic group Ep(a, b) and n being a very large integer. Alternatively, the key pairs (d, Q) could be obtained using a prestored strategy. In any case, private keys are kept secret and the relationship between private and public keys is Q = d ⋅ G.Table 1
Notation.
SymbolMeaningTDiThei-th transmission deviceECSjThej-th edge computing device/serverIDTDiThe identification of TDiG, nA generator point inEp(a, b) with a very large order nHA secure hash algorithmdTDiThe private key of TDiQTDiQTDi = dTDiG, the public key of TDidCThe private key ofCQCQC = dC⋅G, the public key of C(r, s)The dual signaturePPoints withinEp(a, b)PA prime numberEThe hash of datamFThe hash of the value IDTDiGH(e ‖ f), the hash of e and fMData to be sent by a transmission device TDiOnce key pairs are generated,C’s public key QC is published and veritably known by all TDi and ECSj, where i = {1, 2, …, m}, j = {1, 2, …, z}, and z << m. Likewise, each ECSj knows the public keys QTDi of all TDi under its coverage. Note that C does not need to be aware of TDi’s public keys. Then, when an IoMT device TDi has collected information m that needs to be sent, it proceeds as follows:(1)
TDi selects a random (or pseudorandom) integer k, k ∈ [1, n − 1].(2)
TDi computes P1(x1, y1) = k⋅G and r is defined as follows(1)r=x1modn.(3)
Then, TDi computes e = H(m), f = H(IDTDi), and g = H(e || f). In all cases, H should be a strong hash function (e.g., SHA-2 or SHA-3)(4)
Finally, TDi calculates s as shown in equation (2). The obtained dual signature is the pair (r, s).(2)s=k−1g+dTDi⋅rmodn.At this point, TDi sends a message M1 to ECSj containing health-related data. M1 is depicted in Figure 3. This message M1 has two parts. The first part {IDTDi, e, (r, s)} is sent in plaintext and contains the following information: the identification of TDi, the hash e of the collected health data m, and the dual signature (r, s). The second part of M1 is encrypted with an asymmetric cryptographic technique using the public key of the cloud, QC. Any asymmetric encryption technique can be used depending on the capabilities of TDi. The encrypted data that M1 contains are the collected health data m, the hash f of the identification of TDi, the public key QTDi, and the dual signature (r, s).Figure 3
MessageM1 from TDi to ECSj.Upon the reception ofM1, the edge device ECSj verifies the authenticity and integrity of M1 using the public key QTDi as follows:(1)
ECSj verifies that both r and s are integers, i.e., (s, r) ∈ [1, n − 1].(2)
ECSj calculates f = H(IDTDi) and g= H(e || f); observe that IDTDi and e were sent as plaintext in M1 (Figure 3).(3)
Then, the ECSj calculates w as shown in the following equation:(3)w=s−1modn.(4)
It calculatesu1 and u2 as depicted in equations (4) and (5):(4)u1=w⋅g,(5)u2=w⋅r.(5)
Fromu1 and u2, ECSj computes the point P2 as shown in equation (6). Observe that, as usual in asymmetric methods, ECSj knows the public key of TDi.(6)P2x2,y2=u1⋅G+u2⋅QTDi.(6)
Then, ECSj computes v = x2 mod n.Consequently, ifv= r, then ECSj accepts the dual signature, or else it rejects it. Even though ECSj does not have access to the collected health data m (note that m is encrypted with QC as depicted in Figure 3), ECSj can guarantee that TDi was the IoMT device that sent this information m. The reason is that only TDi knows its secret key dTDi, which was used to create the dual signature. In addition, ECSj knows that m has not been modified, hence confirming the integrity of the information; otherwise, the dual signature would have been invalid (and rejected). The demonstration of the verification of the dual signature is detailed later in Section 3.2.Next, we assume that ECSj sends a message M2 to C. The message M2 also has two parts, as illustrated in Figure 4. The first part will be used by C to authenticate the source of this message. This could be done with a classic ECDSA signature. In Figure 4, IDECSj is the ID of ECSj, which sends this message, and h is the resulting hash of the complete message M2. The second part of M2 is equal to the batch of all the encrypted data in messages M1i coming from the different IoMT devices TDi within the coverage of the same ECSj. In other words, ECSj appends each grey part corresponding to the encrypted information that each TDi transmitted to ECSj {m, f, QTDi, (r, s)}Qc. This message M2 is sent from ECSj to C. Upon the arrival of M2 to the cloud C and after verifying the origin and integrity of this message by checking the ECDSA classic signature, C proceeds as follows:Figure 4
MessageM2 from ECSj to C.(1)
C decrypts all blocks {m, f, QTDi, (r, s)}Qc using the cloud’s private key dC.(2)
For each block, C calculatese = H(m) and g= H(e ‖ f).(3)
Then, it calculatesw= s−1 mod n.(4)
Now,C calculates u1 and u2 as depicted in equations (7) and (8):(7)u1=w⋅g,(8)u2=w⋅r.(5)
C computes the point asP3 as indicated in the following equation:(9)P3x3,y3=u1⋅G+u2⋅QTDi.(6)
Finally,C computes v= x3 mod n.As described before, ifv= r, the dual signature is accepted by the cloud C (otherwise, it is rejected). After this operation, C can guarantee that the received data m has not been modified and that m was sent by an authenticated IoMT TD, although the identity of this device is unknown to C. Observe that C knows the value of the public key QTDi, but it does not know the identity of TDi. In other words, health data privacy is preserved without losing origin authentication and integrity.


## 3.2. Demonstration

In order to demonstrate the goodness of the proposal, let us assume that ECSj has received the message M1 = {IDTDi, e, {m, f, QTDi)}Qc, (r, s)}. Let us also assume that M1 has not been altered. Then, from equation (2) we can carry out the following operations:(10)k=s−1g+dTDi⋅rmodn,k=s−1⋅g+s−1⋅dTDi⋅rmodn.In equation (10), we can substitute some terms using equations (3)–(5), so the new expression will be(11)k=w⋅g+w⋅dTDi⋅rmodn,k=u1+u2⋅dTDimodn.At the transmission device TDi we defined P1(x1, y1) = k⋅G, whereas in reception (at the ECSj), we have that P2(x2, y2) = u1⋅G +  u2⋅ QTDi. If P1 is equal to P2, then r and vwould be equal and the dual signature would be correct because both values r and v correspond to the x coordinates of P1 and P2, respectively. Let us verify this by taking into account that the public key of TDi was obtained as QTDi = dTDi⋅G:(12)P2x2,y2=u1⋅G+u2⋅QTDi=u1⋅G+u2⋅dTDi⋅G=u1+u2⋅dTDi⋅G.Subsequently, applying equation (11), we have that(13)P2x2,y2=u1+u2⋅dTDi⋅G=k⋅G=P1x1,y1.Accordingly, both valuesr = x1 mod n (calculated at TDi) and v= x2 mod n (calculated at ECSj) will be equal. Any modification of the transmitted values in M1 would cause different values for e or f and therefore for g, leading to the detection of the attack. The same demonstration procedure should be applied for M2.


## 4. Security Analysis

The security characteristics of the proposal are analyzed in this section, demonstrating that it complies with the stated security requirements for IoMT scenarios.


### 4.1. Message Authentication

The legitimacy of the sender of a message is guaranteed by the digital signature ECDSA. The secret key dTDi is only known by the transmission device TDi. This secret value is employed to compute the digital signature as shown in equation (2). Assuming that TDi was resistant to tampering, this key could not be retrieved by an attacker. Accordingly, TDi could not be impersonated since an attacker would not be able to generate a valid digital signature.For instance, let us assume that an attacker modifies IDTDi in message M1 (Figure 3), attempting to impersonate TDi. Then, the corresponding hash f’ would be different from f, so g= H(e || f’) would also be different than g, and the digital signature verification would be detected as nonvalid.


### 4.2. Identity Privacy

The proposed dual signature procedure guarantees data privacy as follows: (i) health data sent by the transmission devices are hidden from the edge device, but not the identifiers, and (ii) the identities of the transmission devices are hidden from the cloud, but not the health data.The identity of a transmission device TDi is only known by ECSj. Indeed, ECSj receives the identification of each TDi that sends a message of type M1 (as depicted in Figure 3). The reason for allowing the ECS to be aware of the identity of the transmission devices is that the former needs to associate the identity of TDi to the corresponding public key QTDi to verify the digital signature. However, it is important to realize that ECSj does not know the information m that TDi is sending to the cloud: information m is kept secret from the ECSj.On the other hand, when C receives messages of typeM2 (see Figure 4) from an ECSj, the cloud cannot deduce the identity of the TDi that sent that information because C only knows the hash of IDTDi, which is irreversible if a strong hash function has been used. Observe that C will need to be able to verify the public key of ECSj, so the identity of ECSj is not hidden from C.


### 4.3. Data Tampering

The use of strong hash functions guarantees integrity and security against data tampering. In the communication part from TDi to ECSj, if an attacker alters IDTDi, e, or the digital signature itself (r, s) in M1 (see Figure 3), the verification process would detect the attack because the resulting hashes would be different; therefore, the verification would be erroneous, resulting in the rejection of the digital signature.An attacker could also try to modify the encrypted part ofM1 (Figure 3). The procedure would be as follows. The attacker captures M1. Then, it maintains the first part of the message unaltered (the one that is in plaintext), but it creates fake values for m and f and provides a false key QTDi’. However, when the digital signature from TDi is checked at the cloud C, this digital signature is detected as invalid. Another option for the attacker would be to modify the encrypted part of M2 (Figure 4): any part of the batched messages from the TDs. But in this case, the verification of the ECDSA signature introduced by the ECSj in M2 (as shown in Figure 4) would detect the attack.


### 4.4. Replay Attacks

In order to avoid attacks in which messages are captured by an attacker and later injected/replayed into the network, timestamps or sequence numbers could be used. If a TDi sends a timestamp together with the data m, then the ECSj could verify whether the message has expired (e.g., assuming that data have a validity time of x units of time) and if so, reject the message. Using sequence numbers, the ECSj could also verify that this number is not repeated within a transmission window. We have not included the use of timestamps or sequence numbers in this paper to provide a clearer understanding of the proposal.


## 4.1. Message Authentication

The legitimacy of the sender of a message is guaranteed by the digital signature ECDSA. The secret key dTDi is only known by the transmission device TDi. This secret value is employed to compute the digital signature as shown in equation (2). Assuming that TDi was resistant to tampering, this key could not be retrieved by an attacker. Accordingly, TDi could not be impersonated since an attacker would not be able to generate a valid digital signature.For instance, let us assume that an attacker modifies IDTDi in message M1 (Figure 3), attempting to impersonate TDi. Then, the corresponding hash f’ would be different from f, so g= H(e || f’) would also be different than g, and the digital signature verification would be detected as nonvalid.


## 4.2. Identity Privacy

The proposed dual signature procedure guarantees data privacy as follows: (i) health data sent by the transmission devices are hidden from the edge device, but not the identifiers, and (ii) the identities of the transmission devices are hidden from the cloud, but not the health data.The identity of a transmission device TDi is only known by ECSj. Indeed, ECSj receives the identification of each TDi that sends a message of type M1 (as depicted in Figure 3). The reason for allowing the ECS to be aware of the identity of the transmission devices is that the former needs to associate the identity of TDi to the corresponding public key QTDi to verify the digital signature. However, it is important to realize that ECSj does not know the information m that TDi is sending to the cloud: information m is kept secret from the ECSj.On the other hand, when C receives messages of typeM2 (see Figure 4) from an ECSj, the cloud cannot deduce the identity of the TDi that sent that information because C only knows the hash of IDTDi, which is irreversible if a strong hash function has been used. Observe that C will need to be able to verify the public key of ECSj, so the identity of ECSj is not hidden from C.


## 4.3. Data Tampering

The use of strong hash functions guarantees integrity and security against data tampering. In the communication part from TDi to ECSj, if an attacker alters IDTDi, e, or the digital signature itself (r, s) in M1 (see Figure 3), the verification process would detect the attack because the resulting hashes would be different; therefore, the verification would be erroneous, resulting in the rejection of the digital signature.An attacker could also try to modify the encrypted part ofM1 (Figure 3). The procedure would be as follows. The attacker captures M1. Then, it maintains the first part of the message unaltered (the one that is in plaintext), but it creates fake values for m and f and provides a false key QTDi’. However, when the digital signature from TDi is checked at the cloud C, this digital signature is detected as invalid. Another option for the attacker would be to modify the encrypted part of M2 (Figure 4): any part of the batched messages from the TDs. But in this case, the verification of the ECDSA signature introduced by the ECSj in M2 (as shown in Figure 4) would detect the attack.


## 4.4. Replay Attacks

In order to avoid attacks in which messages are captured by an attacker and later injected/replayed into the network, timestamps or sequence numbers could be used. If a TDi sends a timestamp together with the data m, then the ECSj could verify whether the message has expired (e.g., assuming that data have a validity time of x units of time) and if so, reject the message. Using sequence numbers, the ECSj could also verify that this number is not repeated within a transmission window. We have not included the use of timestamps or sequence numbers in this paper to provide a clearer understanding of the proposal.


## 5. Performance Evaluation

In this section, we consider the computational cost and the communication cost of the dual signature ECDSA, introduced in this paper. We also compare the performance with other related schemes. Particularly, we focus on usingEp(a, b) with p of a length of 256 bits. By doing so, the security level would be equivalent to using RSA with an N length of approximately 3000 bits. The selected hash function is SHA-256.


### 5.1. Computational Cost

For this evaluation, it is assumed that IDs will have a length of 32 bits (4 bytes), and messages will have a size of 1024 bits (128 bytes). We also assume that the IoMT scenario hasm transmission devices TDi, where i = {1, 2, …, m}, and z edge devices ECSj, where j = {1, 2, …, z} and z << m. Then, in order to study the computational cost of this proposal, the times required for performing the most relevant operations will be taken into account as indicated in [37, 38], the latter using an Intel Xeon CPU (E3-1220 V2) at 3.10 GHz in 64 bit mode and the GCC 5.4.0 compiler. It is important to note that these times will vary notably depending on the platforms where the algorithms are run. Numerous works from the related literature can be found addressing improvements in the execution times of ECC cryptographic operations [12, 39].Observe that to generate messageM1 (Figure 3), a TDi needs(a)
To generate three hashes, namely,e, f, and g(b)
To encrypt the messagem, the hash f, and the public key QTDi(c)
To generate the digital signature (r, s) with ECDSATable2 details the notation and time cost of the different cryptographic operations. Taking into account that e = H(m), f = H(IDTDi), and g= H(e || f), a TDi needs to generate three hashes with inputs of 128 bytes (1024 bits), 4 bytes (32 bits), and 64 bytes (512 bits), respectively. Thus, the total cycles required for hashing are (128 + 4 + 64)·THash. In addition, if AES in Counter Mode (CTR) is employed to generate the encrypted part of M1, then the time required for encryption in TDi would be (128 + 32 + 32)·TEnc. Finally, the time required to generate the digital signature ECDSA would be TSig. Consequently, the total computational cost for each IoMT transmission device TDi would be (128 + 4 + 64)·THash + (128 + 32 + 32)·TEnc + TSig ≈ 21 ms.Table 2
Notation and time cost (at the transmission devices) of the cryptographic operations used in the comparative performance evaluation. In our proposal, it includes P256 ECC, AES CTR 256, and SHA256 [37, 38].
SymbolMeaningTime costCryptool [40]Boneh–Goh–Nissim [21]Castagnos–Laguillaumie [22]Homomorphic identity-based method [23]Our proposalTSigSignature creation2.88 ms0.969 ms0.924 ms0.629 ms0.918 msTVerOne signature verification8.53 ms14.339 ms27.974 ms27.349 ms26 msTHashSHA-25615.8 cycles/byte5.174μs/byte——4.726μs/byteTEncTime for encryption18.2 cycles/byte0.828 ms0.756 ms1.098 ms99.82μs/byteTTOTAL_TDTotal time at TD—1.7968 ms29.656 ms1.727 ms21.009 msAt the edge device, ECSj, the time required to verify the digital signature and to batch the health data sent from all the TDi elements under its coverage (or associated to it) would be the following. Assuming there are x TDi elements for one ECSj, then this needs to verify x ECDSA signatures and needs to calculate 2·x hashes, namely, f = H(IDTDi) and g= H(e || f). Consequently, the time required is x·TVer + (4 + 64)·THash. If the verification is successful, then the ECSj batches the encrypted health data received from all its TDi and carries out two actions to generate M2. First, it calculates the hash h of the complete message M2. Second, it creates the digital signature ECDSA of the whole message M2. Thus, this time corresponds to ((128 + 16 + 32) + 64)·x·THash cycles plus TSig. In sum, the total computational cost of verification and aggregation for each ECSj is x·TVer + (4 + 64)·THash + ((128 + 16 + 32) + 64)·x·THash + TSig = . Since the cloud device C is not expected to have computation limitations, the time required to perform the corresponding operations is not included, although its calculation is straightforward. It is also relevant to note that the verification of a digital signature with ECDSA requires a double scalar multiplication on an elliptic curve, and this is an operation with a higher impact in execution time and therefore in energy consumption, as has been demonstrated in the related literature.Comparing this performance with other relevant schemes, we find out the following. We gather in Table2 the time cost of all cryptographic operations for several hardware/software configurations as found in the scientific literature. In terms of computation cost for the IoMT devices, the proposal introduced by Li et al. [16] has a total computation cost for each TDi equal to 2Te2 + Tmp + Te, as indicated by the authors. In particular, 2Te2 is the time needed to encrypt the health data and Tmp + Te is the time needed for signature creation (see Table 3). Similarly, the method presented in [22] requires Te + Te2 for the cyphering process, Tmp + Ts for signature creation, and 2Tp + Tmp for verification (see Table 3). As another example, the method introduced in [23] requires a total computation cost of (2Te + Te2) + (Tmp + Tm), the former for encryption and the latter for signature creation (see Table 3). As previously mentioned, these times will vary according to the hardware and/or software characteristics of the device that runs these functions. However, if we compare the total computational cost for the TD, we can see in last row of Table 2 that our scheme performs better than [22] and worse than [21, 23]. The reason lies on the fact that we are using AES CTR for encryption, which heavily influences the performance. Nevertheless, observe that the dual signature ECDSA could be compatible with homomorphic-based cryptosystems, avoiding the use of AES and highly reducing the time cost.Table 3
Notation and time cost of cryptographic operations from [16, 21] and used also in [22, 23].
SymbolMeaningTime (ms)Te2Time of double exponentiation in a cyclic group0.4139TmpTime of map to point0.6272TeTime of exponentiation0.3418TpTime of bilinear pairing13.6736TiTime of inversion in cyclic group0.0256TmTime of multiplication in group0.0019TsTime of scalar multiplication0.2986Regarding the performance of the edge device ECS, Figure5 represents the time cost from the ECS perspective as a function of the number of TD under its coverage. Assuming there are x TDi elements for one ECSj, the total time cost for an ECSj in our proposal is equal to x·TVer + (4 + 64)·THash + ((128 + 16 + 32) + 64)·x·THash + TSig. If we substitute the values using Table 2, then the total computational cost is (x·27,134) + 1,239 ms. As observed in Figure 5, our scheme is affected by the use of the AES algorithm for encryption, and thus any modification in this task will benefit our proposal. It is important to note that using AES is just an example for encryption, but our proposal does not require to employ this algorithm in order to apply the dual signature ECDSA.Figure 5
Computational cost for an ECSj.


### 5.2. Communication Cost

To assess the communication cost, we assume that there are a total ofz ECS and that each ECS includes x TD devices. Then, the communication cost would be as follows. The message M1 sent from each TDi contains [{IDTDi, e, (r, s)}, {m, f, QTDi}], as depicted in Figure 3. Without taking into account the health data m, the communication overhead would be (4 + 32 + 64 + 32 + 8) bytes, respectively, i.e., 140 bytes. Similarly, the message M2 sent from an ECSj to the cloud C contains [{IDECSj, h, (r, s)M2}, {m, f, QTDi, (r, s)}·x], as depicted in Figure 4. Therefore, the communication overhead introduced by the ECSj is equal to (4 + 32 + 64) bytes, i.e., 100 bytes. This represents a total communication overhead from all TDi and all ECSj equal to (140 × z + 100·z) bytes, which is a communication overhead that is slightly smaller than the method presented in [21] and outperforms the proposals from [22, 23].


## 5.1. Computational Cost

For this evaluation, it is assumed that IDs will have a length of 32 bits (4 bytes), and messages will have a size of 1024 bits (128 bytes). We also assume that the IoMT scenario hasm transmission devices TDi, where i = {1, 2, …, m}, and z edge devices ECSj, where j = {1, 2, …, z} and z << m. Then, in order to study the computational cost of this proposal, the times required for performing the most relevant operations will be taken into account as indicated in [37, 38], the latter using an Intel Xeon CPU (E3-1220 V2) at 3.10 GHz in 64 bit mode and the GCC 5.4.0 compiler. It is important to note that these times will vary notably depending on the platforms where the algorithms are run. Numerous works from the related literature can be found addressing improvements in the execution times of ECC cryptographic operations [12, 39].Observe that to generate messageM1 (Figure 3), a TDi needs(a)
To generate three hashes, namely,e, f, and g(b)
To encrypt the messagem, the hash f, and the public key QTDi(c)
To generate the digital signature (r, s) with ECDSATable2 details the notation and time cost of the different cryptographic operations. Taking into account that e = H(m), f = H(IDTDi), and g= H(e || f), a TDi needs to generate three hashes with inputs of 128 bytes (1024 bits), 4 bytes (32 bits), and 64 bytes (512 bits), respectively. Thus, the total cycles required for hashing are (128 + 4 + 64)·THash. In addition, if AES in Counter Mode (CTR) is employed to generate the encrypted part of M1, then the time required for encryption in TDi would be (128 + 32 + 32)·TEnc. Finally, the time required to generate the digital signature ECDSA would be TSig. Consequently, the total computational cost for each IoMT transmission device TDi would be (128 + 4 + 64)·THash + (128 + 32 + 32)·TEnc + TSig ≈ 21 ms.Table 2
Notation and time cost (at the transmission devices) of the cryptographic operations used in the comparative performance evaluation. In our proposal, it includes P256 ECC, AES CTR 256, and SHA256 [37, 38].
SymbolMeaningTime costCryptool [40]Boneh–Goh–Nissim [21]Castagnos–Laguillaumie [22]Homomorphic identity-based method [23]Our proposalTSigSignature creation2.88 ms0.969 ms0.924 ms0.629 ms0.918 msTVerOne signature verification8.53 ms14.339 ms27.974 ms27.349 ms26 msTHashSHA-25615.8 cycles/byte5.174μs/byte——4.726μs/byteTEncTime for encryption18.2 cycles/byte0.828 ms0.756 ms1.098 ms99.82μs/byteTTOTAL_TDTotal time at TD—1.7968 ms29.656 ms1.727 ms21.009 msAt the edge device, ECSj, the time required to verify the digital signature and to batch the health data sent from all the TDi elements under its coverage (or associated to it) would be the following. Assuming there are x TDi elements for one ECSj, then this needs to verify x ECDSA signatures and needs to calculate 2·x hashes, namely, f = H(IDTDi) and g= H(e || f). Consequently, the time required is x·TVer + (4 + 64)·THash. If the verification is successful, then the ECSj batches the encrypted health data received from all its TDi and carries out two actions to generate M2. First, it calculates the hash h of the complete message M2. Second, it creates the digital signature ECDSA of the whole message M2. Thus, this time corresponds to ((128 + 16 + 32) + 64)·x·THash cycles plus TSig. In sum, the total computational cost of verification and aggregation for each ECSj is x·TVer + (4 + 64)·THash + ((128 + 16 + 32) + 64)·x·THash + TSig = . Since the cloud device C is not expected to have computation limitations, the time required to perform the corresponding operations is not included, although its calculation is straightforward. It is also relevant to note that the verification of a digital signature with ECDSA requires a double scalar multiplication on an elliptic curve, and this is an operation with a higher impact in execution time and therefore in energy consumption, as has been demonstrated in the related literature.Comparing this performance with other relevant schemes, we find out the following. We gather in Table2 the time cost of all cryptographic operations for several hardware/software configurations as found in the scientific literature. In terms of computation cost for the IoMT devices, the proposal introduced by Li et al. [16] has a total computation cost for each TDi equal to 2Te2 + Tmp + Te, as indicated by the authors. In particular, 2Te2 is the time needed to encrypt the health data and Tmp + Te is the time needed for signature creation (see Table 3). Similarly, the method presented in [22] requires Te + Te2 for the cyphering process, Tmp + Ts for signature creation, and 2Tp + Tmp for verification (see Table 3). As another example, the method introduced in [23] requires a total computation cost of (2Te + Te2) + (Tmp + Tm), the former for encryption and the latter for signature creation (see Table 3). As previously mentioned, these times will vary according to the hardware and/or software characteristics of the device that runs these functions. However, if we compare the total computational cost for the TD, we can see in last row of Table 2 that our scheme performs better than [22] and worse than [21, 23]. The reason lies on the fact that we are using AES CTR for encryption, which heavily influences the performance. Nevertheless, observe that the dual signature ECDSA could be compatible with homomorphic-based cryptosystems, avoiding the use of AES and highly reducing the time cost.Table 3
Notation and time cost of cryptographic operations from [16, 21] and used also in [22, 23].
SymbolMeaningTime (ms)Te2Time of double exponentiation in a cyclic group0.4139TmpTime of map to point0.6272TeTime of exponentiation0.3418TpTime of bilinear pairing13.6736TiTime of inversion in cyclic group0.0256TmTime of multiplication in group0.0019TsTime of scalar multiplication0.2986Regarding the performance of the edge device ECS, Figure5 represents the time cost from the ECS perspective as a function of the number of TD under its coverage. Assuming there are x TDi elements for one ECSj, the total time cost for an ECSj in our proposal is equal to x·TVer + (4 + 64)·THash + ((128 + 16 + 32) + 64)·x·THash + TSig. If we substitute the values using Table 2, then the total computational cost is (x·27,134) + 1,239 ms. As observed in Figure 5, our scheme is affected by the use of the AES algorithm for encryption, and thus any modification in this task will benefit our proposal. It is important to note that using AES is just an example for encryption, but our proposal does not require to employ this algorithm in order to apply the dual signature ECDSA.Figure 5
Computational cost for an ECSj.


## 5.2. Communication Cost

To assess the communication cost, we assume that there are a total ofz ECS and that each ECS includes x TD devices. Then, the communication cost would be as follows. The message M1 sent from each TDi contains [{IDTDi, e, (r, s)}, {m, f, QTDi}], as depicted in Figure 3. Without taking into account the health data m, the communication overhead would be (4 + 32 + 64 + 32 + 8) bytes, respectively, i.e., 140 bytes. Similarly, the message M2 sent from an ECSj to the cloud C contains [{IDECSj, h, (r, s)M2}, {m, f, QTDi, (r, s)}·x], as depicted in Figure 4. Therefore, the communication overhead introduced by the ECSj is equal to (4 + 32 + 64) bytes, i.e., 100 bytes. This represents a total communication overhead from all TDi and all ECSj equal to (140 × z + 100·z) bytes, which is a communication overhead that is slightly smaller than the method presented in [21] and outperforms the proposals from [22, 23].


## 6. Conclusions

In this paper, an original method to include a dual signature into ECDSA has been proposed. The use of the presented method allows for the preservation of privacy in data transferred from IoMT devices to the cloud through edge computing servers. Specifically, collected health data remain invisible to the edge device, and the identity of the transmission medical IoT device, e.g., wearables or smartphones, is anonymous to the cloud. This solution is affordable for constrained IoMT devices, and at the same time, its hardware implementation is completely feasible because of its ECC-based approach.



---

*Source: 4960964-2020-06-10.xml*