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.

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. Section 2 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.

Figure 1 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 (K_PBank) in Figure 1(b). Consequently, the bank will not know what the client bought (the OI) and will only know the payment information.

(a)

(b)

(a)
(b)

Figure 1 

General procedure of a dual signature where H represents a secure hash function (E≡encrypt; D≡decrypt; ||≡concatenate; K_pclient≡the buyer’s private key; K_Pclient≡the buyer’s public key; K_PBank≡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.

The authors’ proposal inherits the procedure shown in Figure 1 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.

Table 1 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 E_p(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.

Once key pairs are generated, C’s public key Q_C is published and veritably known by all TD_i and ECS_j, where i = {1, 2, …, m}, j = {1, 2, …, z}, and z << m. Likewise, each ECS_j knows the public keys Q_TDi of all TD_i under its coverage. Note that C does not need to be aware of TD_i’s public keys. Then, when an IoMT device TD_i has collected information m that needs to be sent, it proceeds as follows:(1)TD_i selects a random (or pseudorandom) integer k, k ∈ [1, n − 1].(2)TD_i computes P₁(x₁, y₁) = k⋅G and r is defined as follows(3)Then, TD_i computes e = H(m), f = H(ID_TDi), and  = H(e || f). In all cases, H should be a strong hash function (e.g., SHA-2 or SHA-3)(4)Finally, TD_i calculates s as shown in equation (2). The obtained dual signature is the pair (r, s).

At this point, TD_i sends a message M₁ to ECS_j containing health-related data. M₁ is depicted in Figure 3. This message M₁ has two parts. The first part {ID_TDi, e, (r, s)} is sent in plaintext and contains the following information: the identification of TD_i, the hash e of the collected health data m, and the dual signature (r, s). The second part of M₁ is encrypted with an asymmetric cryptographic technique using the public key of the cloud, Q_C. Any asymmetric encryption technique can be used depending on the capabilities of TD_i. The encrypted data that M₁ contains are the collected health data m, the hash f of the identification of TD_i, the public key Q_TDi, and the dual signature (r, s).

Figure 3 

Message M₁ from TD_i to ECS_j.

Upon the reception of M₁, the edge device ECS_j verifies the authenticity and integrity of M₁ using the public key Q_TDi as follows:(1)ECS_j verifies that both r and s are integers, i.e., (s, r) ∈ [1, n − 1].(2)ECS_j calculates f = H(ID_TDi) and = H(e || f); observe that ID_TDi and e were sent as plaintext in M₁ (Figure 3).(3)Then, the ECS_j calculates as shown in the following equation:(4)It calculates u₁ and u₂ as depicted in equations (4) and (5):(5)From u₁ and u₂, ECS_j computes the point P₂ as shown in equation (6). Observe that, as usual in asymmetric methods, ECS_j knows the public key of TD_i.(6)Then, ECS_j computes  = x₂ mod n.

Consequently, if = r, then ECS_j accepts the dual signature, or else it rejects it. Even though ECS_j does not have access to the collected health data m (note that m is encrypted with Q_C as depicted in Figure 3), ECS_j can guarantee that TD_i was the IoMT device that sent this information m. The reason is that only TD_i knows its secret key d_TDi, which was used to create the dual signature. In addition, ECS_j 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 ECS_j sends a message M₂ to C. The message M₂ 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, ID_ECSj is the ID of ECS_j, which sends this message, and h is the resulting hash of the complete message M₂. The second part of M₂ is equal to the batch of all the encrypted data in messages M_1i coming from the different IoMT devices TD_i within the coverage of the same ECS_j. In other words, ECS_j appends each grey part corresponding to the encrypted information that each TD_i transmitted to ECS_j {m, f, Q_TDi, (r, s)}_Qc. This message M₂ is sent from ECS_j to C. Upon the arrival of M₂ 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 

Message M₂ from ECS_j to C.

(1)C decrypts all blocks {m, f, Q_TDi, (r, s)}_Qc using the cloud’s private key d_C.(2)For each block, C calculates e = H(m) and = H(e ‖ f).(3)Then, it calculates = s⁻¹ mod n.(4)Now, C calculates u₁ and u₂ as depicted in equations (7) and (8):

As described before, if = 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 Q_TDi, but it does not know the identity of TD_i. 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 ECS_j has received the message M₁ = {ID_TDi, e, {m, f, Q_TDi)}_Qc, (r, s)}. Let us also assume that M₁ has not been altered. Then, from equation (2) we can carry out the following operations:

In equation (10), we can substitute some terms using equations (3)–(5), so the new expression will be

At the transmission device TD_i we defined P₁(x₁, y₁) = k⋅G, whereas in reception (at the ECS_j), we have that P₂(x₂, y₂) = u₁⋅G +  u₂⋅ Q_TDi. If P₁ is equal to P₂, then r and would be equal and the dual signature would be correct because both values r and correspond to the x coordinates of P₁ and P₂, respectively. Let us verify this by taking into account that the public key of TD_i was obtained as Q_TDi = d_TDi⋅G:

Subsequently, applying equation (11), we have that

Accordingly, both values r = x₁ mod n (calculated at TD_i) and = x₂ mod n (calculated at ECS_j) will be equal. Any modification of the transmitted values in M₁ would cause different values for e or f and therefore for , leading to the detection of the attack. The same demonstration procedure should be applied for M₂.

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 d_TDi is only known by the transmission device TD_i. This secret value is employed to compute the digital signature as shown in equation (2). Assuming that TD_i was resistant to tampering, this key could not be retrieved by an attacker. Accordingly, TD_i 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 ID_TDi in message M₁ (Figure 3), attempting to impersonate TD_i. Then, the corresponding hash f’ would be different from f, so = H(e || f’) would also be different than , 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 TD_i is only known by ECS_j. Indeed, ECS_j receives the identification of each TD_i that sends a message of type M₁ (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 TD_i to the corresponding public key Q_TDi to verify the digital signature. However, it is important to realize that ECS_j does not know the information m that TD_i is sending to the cloud: information m is kept secret from the ECS_j.

On the other hand, when C receives messages of type M₂ (see Figure 4) from an ECS_j, the cloud cannot deduce the identity of the TD_i that sent that information because C only knows the hash of ID_TDi, 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 ECS_j, so the identity of ECS_j 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 TD_i to ECS_j, if an attacker alters ID_TDi, e, or the digital signature itself (r, s) in M₁ (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 of M₁ (Figure 3). The procedure would be as follows. The attacker captures M₁. 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 Q_TDi’. However, when the digital signature from TD_i 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 M₂ (Figure 4): any part of the batched messages from the TDs. But in this case, the verification of the ECDSA signature introduced by the ECS_j in M₂ (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 TD_i sends a timestamp together with the data m, then the ECS_j 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 ECS_j 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 using E_p(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 has m transmission devices TD_i, where i = {1, 2, …, m}, and z edge devices ECS_j, 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 message M₁ (Figure 3), a TD_i needs(a)To generate three hashes, namely, e, f, and (b)To encrypt the message m, the hash f, and the public key Q_TDi(c)To generate the digital signature (r, s) with ECDSA

Table 2 details the notation and time cost of the different cryptographic operations. Taking into account that e = H(m), f = H(ID_TDi), and = H(e || f), a TD_i 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)·T_Hash. In addition, if AES in Counter Mode (CTR) is employed to generate the encrypted part of M₁, then the time required for encryption in TD_i would be (128 + 32 + 32)·T_Enc. Finally, the time required to generate the digital signature ECDSA would be T_Sig. Consequently, the total computational cost for each IoMT transmission device TD_i would be (128 + 4 + 64)·T_Hash + (128 + 32 + 32)·T_Enc + T_Sig ≈ 21 ms.

At the edge device, ECS_j, the time required to verify the digital signature and to batch the health data sent from all the TD_i elements under its coverage (or associated to it) would be the following. Assuming there are x TD_i elements for one ECS_j, then this needs to verify x ECDSA signatures and needs to calculate 2·x hashes, namely, f = H(ID_TDi) and = H(e || f). Consequently, the time required is x·T_Ver + (4 + 64)·T_Hash. If the verification is successful, then the ECS_j batches the encrypted health data received from all its TD_i and carries out two actions to generate M₂. First, it calculates the hash h of the complete message M₂. Second, it creates the digital signature ECDSA of the whole message M₂. Thus, this time corresponds to ((128 + 16 + 32) + 64)·x·T_Hash cycles plus T_Sig. In sum, the total computational cost of verification and aggregation for each ECS_j is x·T_Ver + (4 + 64)·T_Hash + ((128 + 16 + 32) + 64)·x·T_Hash + T_Sig = . 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 Table 2 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 TD_i equal to 2T_e2 + T_mp + T_e, as indicated by the authors. In particular, 2T_e2 is the time needed to encrypt the health data and T_mp + T_e is the time needed for signature creation (see Table 3). Similarly, the method presented in [22] requires T_e + T_e2 for the cyphering process, T_mp + T_s for signature creation, and 2T_p + T_mp for verification (see Table 3). As another example, the method introduced in [23] requires a total computation cost of (2T_e + T_e2) + (T_mp + T_m), 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.

Regarding the performance of the edge device ECS, Figure 5 represents the time cost from the ECS perspective as a function of the number of TD under its coverage. Assuming there are x TD_i elements for one ECS_j, the total time cost for an ECS_j in our proposal is equal to x·T_Ver + (4 + 64)·T_Hash + ((128 + 16 + 32) + 64)·x·T_Hash + T_Sig. 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 ECS_j.

5.2. Communication Cost

To assess the communication cost, we assume that there are a total of z ECS and that each ECS includes x TD devices. Then, the communication cost would be as follows. The message M₁ sent from each TD_i contains [{ID_TDi, e, (r, s)}, {m, f, Q_TDi}], 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 M₂ sent from an ECS_j to the cloud C contains [{ID_ECSj, h, (r, s)_M2}, {m, f, Q_TDi, (r, s)}·x], as depicted in Figure 4. Therefore, the communication overhead introduced by the ECS_j is equal to (4 + 32 + 64) bytes, i.e., 100 bytes. This represents a total communication overhead from all TD_i and all ECS_j 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.

Data Availability

No data were used to support this study.

Conflicts of Interest

The authors declare that there are no conflicts of interest regarding the publication of this paper.

Acknowledgments

This research was supported by the AEI/FEDER EU project grant (AIM) (TEC2016-76465-C2-1-R).