A Secure and Efficient Authentication Scheme with Privacy Protection for Internet of Medical Things

TL;DR

This paper presents a secure and efficient authentication method for medical IoT devices that protects user privacy and improves real-world performance.

Contribution

A novel pairing-free certificateless signature scheme and hash-based MAC for secure and efficient medical IoT authentication.

Findings

The proposed scheme provides formal security proofs under standard cryptographic assumptions.

The method achieves better computational and communication efficiency compared to existing solutions.

The system is designed to be practical for real-world Internet of Medical Things applications.

Abstract

The Internet of Medical Things represents a pivotal application of Internet of Things technology in Healthcare 4.0, offering substantial practical benefits in enhancing medical quality, reducing costs, and minimizing errors. In history, researchers have proposed numerous privacy-preserving authentication schemes to safeguard Internet of Medical Things applications. Nevertheless, due to design shortcomings, existing solutions still encounter significant security and performance challenges, rendering them impractical for real-world use. To resolve the issue, this work introduces a novel practical Internet of Medical Things-based smart healthcare system, leveraging a pairing-free certificateless signature scheme and hash-based message authentication code. Through formal security proofs under standard cryptographic assumptions, and performance analysis, our scheme demonstrates enhanced security while maintaining desirable computational and communication efficiency.

Figures

Full text

1. Introduction

The Internet of Things (IoT) builds a dynamic interactive intelligent network platform by seamlessly connecting numerous intelligent sensing devices, embedded systems, and the Internet. It not only realizes real-time data collection, transmission, and collaborative processing between devices, but also promotes revolutionary application scenarios in smart home, industrial automation, smart city, and medical health. The Internet of Medical Things (IoMT) emerges as a critical application subset within this framework, where healthcare devices/applications are intricately integrated with healthcare IT systems to furnish patients with high-quality health services. According to recent market insights from Grand View Research, the global IoMT market is anticipated to exceed USD 658.57 billion by 2030 [1], propelled by innovations in wearable technology, remote patient monitoring, and AI-driven diagnostics. This significant growth trajectory highlights the transformative impact of IoMT on healthcare in the Healthcare 4.0 era, promoting proactive disease management and the implementation of tailored treatment strategies [2].

In typical IoMT application environments, such as wireless body area networks and wireless medical sensor networks, wearable or implanted sensors on the human body capture vital health metrics, including blood oxygen saturation, temperature, heart rate, and respiratory rate [3,4]. Due to the constrained resources of these sensor devices, the gathered data are transmitted to a remote medical cloud server (MCS) for storage and subsequent analysis. Subsequently, healthcare providers can retrieve the patient’s health information (PHI) from the MCS to deliver prompt medical interventions.

Normally, PHI is frequently transmitted across inherently insecure public networks, such as the internet and wireless channels, where it faces a spectrum of security risks that compromise both its integrity and confidentiality. For example, during transmission, PHI may suffer from inadvertent or malicious tampering, leading to altered medical records or distorted diagnostic images. Such modifications can mislead healthcare providers into making clinically erroneous decisions. Beyond integrity threats, PHI inherently contains highly sensitive personal data. Unauthorized disclosure of this information, whether through eavesdropping, data breaches, or insufficient access controls, carries severe privacy repercussions [5,6]. For example, the harm from health data leakage may include financial fraud, identity theft, and reputational damage, leading to discrimination or stigma, and can also affect physical and mental well-being. It is said that healthcare breaches are the costliest of any industry, with average costs per incident reaching approximately USD 7.42 million in 2025. Breaches specifically involving IoMT average even higher, at an estimated USD 10 million per attack [7]. Therefore, these integrity and confidentiality risks underscore the critical need for robust privacy-preserving authentication frameworks to protect PHI.

Throughout the history of IoMT security research, numerous privacy-preserving authentication schemes have been proposed to ensure data integrity and authenticity [8]. Early implementations primarily rely on two kinds of cryptographic mechanisms, namely, public key infrastructure (PKI) and identity-based cryptography (IBC) [9,10]. However, both mechanisms exhibit inherent limitations in resource-constrained IoT applications. In particular, PKI-based systems demand substantial overhead for key certificate management, such as certificate issuance, distribution, update, and revocation, which are expensive for medical sensors. Meanwhile, an IBC system can address the certificate management problem. However, it suffers from the key escrow problem, where a key generation center (KGC) knows both the private and public keys of the user. In [9], Kumar et al. designed an escrow-free identity-based aggregated signcryption scheme for IoMT. They used an interactive system key generation method to address the key escrow problem. However, their design lacks formal security analysis, and the heavyweight bilinear pairing and map-to-point hash operations are unfriendly to resource-constrained medical sensors.

To eliminate the key management and key-escrow problems, a pivotal advancement emerged when the concept of certificateless cryptography (CLC) was introduced in [11]. The CLC paradigm redefines key generation by splitting user keys into two components, namely, a partial secret derived from a KGC and a user-generated private value. By eliminating both certificate management burdens and key escrow vulnerabilities, CLC strikes an optimal balance between security and efficiency. This also makes CLC an ideal cryptographic system for deployment in resource-limited IoMT applications.

1.1. Related Work and Motivation

Prior to that, to protect data integrity and confidentiality at the same time, many CLC-based privacy-preserving authentication schemes have been constructed for IoMT environments. Liu et al. [12] designed an RSA-based certificateless signcryption (CLSC) scheme for healthcare applications. Such a scheme can merge the digital signature and encryption operations into a single logical step. However, their computational and communication costs pose a performance challenge for resource-constrained sensor devices. Subsequently, some new CLSC schemes were proposed one after another, such as [13,14,15,16]. Considering the significant increase in the number of sensors in IoMT, the traditional mode of verifying signcrypted messages one by one can easily lead to network congestion. To this end, researchers have proposed a number of certificateless aggregate signcryption (CLASC) schemes that support batch signcryption verification, which have become a critical path for optimizing communication efficiency in IoMT scenarios [15,16,17,18,19,20,21,22]. However, these solutions still have some shortcomings in terms of security and performance.

In addition to signcryption construction, in [23], Chang et al. introduced a new IoMT-based smart healthcare system (SHS) on the basis of a homomorphic certificateless signature (CLS) scheme and a hash-based message authentication code (HMAC) [24]. Compared to the conventional CLS scheme, their homomorphic CLS scheme can achieve public verifiability, i.e., allowing internal or external entities to check the integrity of data without knowing the actual PHI data stored in MCS [9]. Meanwhile, the HMAC construction can encrypt the PHI by using only XOR and hash operations, which are quite lightweight. However, in [25], Xu et al. demonstrated that the design in [23] cannot resist signature forgery attacks by public key replacement attackers. In particular, such an attack allows the attacker to extract the signer’s full private key, thereby compromising the basic data integrity guarantee. To address the issue, Xu et al. proposed a security-enhanced CLS scheme and designed a new IoMT-based SHS. However, using theoretical analysis methods, their design still has security vulnerabilities. More concretely, in their design, each biomedical sensor encrypts its encrypted data to a personal-assisted device (PAD), which then signs the data and further sends the data–signature pair to an MCS for subsequent processing. In this process, the PAD does not know the actual PHI data. However, in real-world environments, it cannot detect whether this encrypted data has been unintentionally or maliciously tampered with during transmission. Note that once the data integrity is compromised, the patient may receive incorrect medical services, causing significant health risks. In summary, Table 1 compares the features of several related works. Therefore, there still exists a research gap for an IoMT-based SHS that provides both data integrity and confidentiality assurance.

In view of this, this work aims to answer the following research question: Can we design a practical IoMT-based SHS that can simultaneously protect data integrity and confidentiality?

1.2. Contribution

To answer the above research question, we mainly design a practical IoMT-based SHS. The scheme overview is shown in Section 3. The main contributions are as follows:

• We design a new IoMT-based SHS based on a new pairing-free CLS signature and the ChaCha20-Poly1305 algorithm. Our solution achieves data integrity and privacy protection throughout the entire process from data generation to data usage.
• We formally prove the security of our design based on standard cryptographic assumptions in the random oracle (RO) model.
• Through comparative evaluation with existing research, we assess the efficacy of our proposed scheme. The results show that our solution has ideal computational and communication costs while ensuring high security, making it suitable for resource-constrained IoMT applications.

1.3. Road Map

The structure of the remaining paper is as follows: We revisit required preliminaries in Section 2. Section 3 presents our new IoMT-based SHS with related security proofs. Section 4 evaluates its performance, and Section 5 ends the paper.

2. Preliminaries

We introduce some preliminaries in this section, including general symbols, the elliptic curve discrete logarithm problem (ECDLP), and the ChaCha20-Poly1305 algorithm.

2.1. Symbols

Some symbols are described in Table 2.

2.2. ECDLP

Let G be a q-order cyclic elliptic curve group and P be a generator of G. Given $[eqn]$ for some unknown $[eqn]$ , the ECDLP’s goal is to find $[eqn]$ .

2.3. ChaCha20-Poly1305

ChaCha20-Poly1305 [26] is an authenticated encryption algorithm that combines the ChaCha20 stream cipher for confidentiality and the Poly1305 message authentication code for integrity and authenticity. It is a fast, secure, and efficient symmetric-key algorithm used in protocols like Transport Layer Security and Secure Shell to protect data. At a high level, ChaCha20-Poly1305 consists of three algorithms:

• CP.KeyGen: Given a security parameter $[eqn]$ , the algorithm returns a 32-byte key $[eqn]$ .
• CP.Enc-Auth: Given a message $[eqn]$ , a 12-byte random nonce $[eqn]$ , an a variable length associate data $[eqn]$ , and the key $[eqn]$ , the algorithm returns a ciphertext c and a 16-byte tag $[eqn]$ .
• CP.Verify: Given the key $[eqn]$ , ciphertext c, tag $[eqn]$ , nonce $[eqn]$ , and associate data t, the algorithm returns a message m or ⊥ indicating decryption failure.

We refer the readers to [26] for a detailed description of the ChaCha20-Poly1305.

3. The Proposed IoMT-Based SHS

To illustrate the IoMT-based SHS, similar to prior work [9,23,25], we consider one patient as a concrete example. As depicted in Figure 1, five core entities interact within the system: The KGC mainly builds the system and issues the partial private key to the PAD. Wearable/implantable biomedical sensors (BMSs), with constrained resources, continuously collect PHI. During System Setup, each BMS securely obtains two ChaCha20-Poly1305 keys from the PAD and SD, respectively, which it subsequently uses for PHI encryption and authentication. This process can be achieved through authenticated key-exchange protocols [27], which is beyond the scope of the work. Acting as a data aggregator, the PA receives encrypted PHI from multiple BMSs, checks the data integrity, signs the “compressed” ciphertext, and transmits the validated data to a MCS. On the healthcare provider side, the SD authorizedly access stored PHI through MCS to deliver healthcare services to the patient.

In the following, we will introduce the detailed implementation of our proposed SHS, which integrates a new CLS scheme with a secure ChaCha20-Poly1305 mechanism (using algorithms (CP.KeyGen, CP.Enc-Auth, CP.Verify)), whose specifications are given in Section 2.3.

3.1. System Setup

The KGC sets up the system by generating the required system parameters. PAD and SD interact with KGC, respectively, to establish their public–private key pairs. Without loss of generality, we assume that a PAD is linked to n BMSs. Algorithm 1 provides a detailed description of the phase. Algorithm 1 System Setup.

• 1:Given a security parameter $[eqn]$ , the KGC sets a system master key $[eqn]$ at random and public parameters $[eqn]$ . Specifically, $[eqn]$ is a q-order cyclic group, P is a generator of $[eqn]$ , and $[eqn]$ . In addition, $[eqn]$ , $[eqn]$ are cryptographic hash functions.
• 2:To generate a public–private key pair, the PAD with identity $[eqn]$ picks a secret value $[eqn]$ at random and calculates $[eqn]$ . It provides KGC with $[eqn]$ . Then, the KGC picks $[eqn]$ at random, calculates $[eqn]$ , $[eqn]$ , $[eqn]$ , and sends $[eqn]$ to the PAD as its partial private key. After checking the correctness of $[eqn]$ by verifying $[eqn]$ , the PAD sets its private key $[eqn]$ and public key $[eqn]$ .
• 3: For j-th BMS, the PAD executes CP.KeyGen( $[eqn]$ ) to generate a symmetric private key $[eqn]$ . The SD also executes CP.KeyGen( $[eqn]$ ) to generate the symmetric private key $[eqn]$ . Then, $[eqn]$ are securely stored in the non-volatile memory of the j-th BMS.

3.2. Data Flow from BMS to PAD

This part describes how the BMS sends its collected data to the PAD. Assuming that $[eqn]$ is the PHI gathered by BMS_j_, $[eqn]$ , at time t, Algorithm 2 provides a detailed description of the phase. Algorithm 2 BMS-to-PAD data sharing.

• 1: For $[eqn]$ , BMS_j_ randomly picks 12-byte $[eqn]$ , calculates $[eqn]$ , where (associate data) t is a timestamp. For $[eqn]$ , BMS_j_ further computes $[eqn]$ and sets $[eqn]$ .
• 2: Send $[eqn]$ to PAD for further processing.

3.3. Data Flow from PAD to MCS

For each received item $[eqn]$ with regard to BMS_j_, the PAD first checks and confirms its validity. Then, it generates a signature $[eqn]$ for messages sent by n BMSs, and sends the message–signature pair to the MCS for subsequent processing. Note that in this phase, the PAD does not access the actual PHI as the transmitted message component $[eqn]$ is securely maintained in encrypted format. Algorithm 3 shows the phase. Algorithm 3 PAD-to-MCS data sharing.

• 1: Check and decrypt $[eqn]$ for $[eqn]$ .
• 2:For $[eqn]$ , the PAD calculates $[eqn]$ . It randomly picks $[eqn]$ and calculates $[eqn]$ and $[eqn]$ . Then, it computes $[eqn]$ and sets $[eqn]$ as the signature.
• 3:Send the item $[eqn]$ to MCS for storage.

3.4. Data Access

To facilitate patient-specific medical services utilizing data aggregated by the MCS, the SD must securely access authenticated and encrypted PHI data $[eqn]$ . The operational workflow for this phase is defined in Algorithm 4. Algorithm 4 Data access.

• 1:The SD downloads the data $[eqn]$ from the MCS.
• 2:Compute $[eqn]$ , $[eqn]$ , and $[eqn]$ .
• 3:Use the equation $[eqn]$ to check the validity of $[eqn]$ . The correctness:

$$[eqn]$$

The SD stops the verification if $[eqn]$ is invalid; otherwise, it operates as follows.

• 4:Check and decrypt $[eqn]$ for $[eqn]$ .

3.5. Security Proof

Now, we prove the security of our IoMT-based SHS. Note that our design consists of an underlying CLS scheme and the ChaCha20-Poly1305 algorithm. For the CLS scheme, two types of adversaries should be considered, namely, a public-key replacement attacker (called a Type 1 adversary) and a malicious-but-passive KGC (called a Type 2 adversary). In particular, a Type 1 attacker knows a target user’s secret value. However, the adversary cannot access the user’s partial private key. In addition, a Type 2 attacker knows the KGC’s private key but cannot know the target user’s secret value. For more security definitions and security models, we refer the readers to [28] for details.

Theorem 1.  In the RO model, if the underlying CLS scheme and ChaCha20-Poly1305 algorithm are secure, then our IoMT-based SHS is secure.

Proof. This theorem demonstrates that if an attacker exists who can compromise the security of our SHS, then another attacker must exist who can break either the underlying CLS scheme or the ChaCha20-Poly1305 algorithm. As ChaCha20-Poly1305 algorithm is specified in RFC 7539, we omit its security analysis. Given this in mind, the proof for our theorem incorporates the demonstrations detailed in Theorems 2–4. □

Theorem 2.  Our underlying CLS scheme is secure against a Type 1 adversary if the ECDLP is hard.

Proof. This theorem demonstrates that if a Type 1 adversary $[eqn]$ compromises the underlying CLS scheme, then it must be possible to construct an adversary $[eqn]$ that can solve the ECDLP. Now, $[eqn]$ and $[eqn]$ perform the following:

• Step-1: $[eqn]$ runs as System Setup to obtain system parameters $[eqn]$ , where $[eqn]$ for some unknown $[eqn]$ . It then sends $[eqn]$ to $[eqn]$ . For simplicity, let $[eqn]$ be $[eqn]$ ’s target identity. During the forgery game, $[eqn]$ keeps a series of lists as defined below to record the query results. In the initial stage, these lists are empty.
• Step-2: In this stage, $[eqn]$ responds to $[eqn]$ ’s adaptive queries as below. $[eqn]$ -Query: When an $[eqn]$ query is received from $[eqn]$ for $[eqn]$ , if the item $[eqn]$ exists in the list $[eqn]$ , $[eqn]$ returns $[eqn]$ to $[eqn]$ . Otherwise, $[eqn]$ picks $[eqn]$ at random, inserts $[eqn]$ to $[eqn]$ , and responds $[eqn]$ to $[eqn]$ . $[eqn]$ -Query: For an $[eqn]$ query on $[eqn]$ , if the item $[eqn]$ exists in the list $[eqn]$ , $[eqn]$ returns $[eqn]$ to $[eqn]$ . Otherwise, $[eqn]$ randomly picks $[eqn]$ , inserts $[eqn]$ to the list, and responds $[eqn]$ to $[eqn]$ .Secret value-Query: $[eqn]$ can issue such query on $[eqn]$ . $[eqn]$ searches the tuple $[eqn]$ from the list $[eqn]$ and provides it to $[eqn]$ . Otherwise, $[eqn]$ selects $[eqn]$ at random, stores $[eqn]$ to $[eqn]$ , and responds $[eqn]$ to $[eqn]$ .Partial private key-Query: $[eqn]$ can issue such query regarding $[eqn]$ . If $[eqn]$ , $[eqn]$ reports failure. Otherwise, $[eqn]$ finds the tuple $[eqn]$ from the list $[eqn]$ and then responds it to $[eqn]$ . Note that if $[eqn]$ does not exist in $[eqn]$ and the tuple $[eqn]$ does not exist in $[eqn]$ , $[eqn]$ selects $[eqn]$ at random, computes $[eqn]$ , and sets $[eqn]$ . $[eqn]$ updates lists $[eqn]$ and $[eqn]$ and returns $[eqn]$ to $[eqn]$ .Public key-Query: Once $[eqn]$ receives $[eqn]$ ’s query on $[eqn]$ ( $[eqn]$ ), $[eqn]$ checks if $[eqn]$ exists in the list $[eqn]$ . If it exists, $[eqn]$ returns $[eqn]$ . Otherwise, $[eqn]$ runs as Secret value-Query and Partial private key-Query to generate and update $[eqn]$ , and then returns $[eqn]$ .Public key replacement-Query: Once $[eqn]$ receives a query for the tuple $[eqn]$ from $[eqn]$ , $[eqn]$ searches the tuple $[eqn]$ from the list $[eqn]$ and replaces it with $[eqn]$ .Signing-Query: For $[eqn]$ ’s query on $[eqn]$ , $[eqn]$ performs as below. If $[eqn]$ , $[eqn]$ scans the lists to obtain the required parameters and runs as Signing to generate a signature $[eqn]$ as the response. Otherwise, $[eqn]$ picks $[eqn]$ , $[eqn]$ at random, sets $[eqn]$ , and returns $[eqn]$ .
• Step-3: Eventually, $[eqn]$ either admits failure or returns its forgery $[eqn]$ on $[eqn]$ .

If in the case that $[eqn]$ is a valid forgery under $[eqn]$ , the verification equation $[eqn]$ holds. By applying the forking lemma in [29], $[eqn]$ replays $[eqn]$ with the same random tape, but provides two distinct values of $[eqn]$ hash. $[eqn]$ can output another valid signature $[eqn]$ . Hence, we have $[eqn]$ . Therefore, $[eqn]$ calculates $[eqn]$ as a solution to the ECDLP. □

Theorem 3.  Our underlying CLS scheme is secure against any Type 2 adversary if the ECDLP is hard.

Proof. This theorem demonstrates that if a Type 2 adversary $[eqn]$ compromises the underlying CLS scheme, then it must be possible to construct an adversary $[eqn]$ that can solve the ECDLP. Now, $[eqn]$ and $[eqn]$ perform the following:

• Step-1: $[eqn]$ runs as System Setup to obtain system parameters $[eqn]$ , where $[eqn]$ and $[eqn]$ . It then sends $[eqn]$ to $[eqn]$ . For simplicity, let $[eqn]$ be $[eqn]$ ’s target identity. During the forgery game, $[eqn]$ keeps a series of lists as defined below to record the query results. In the initial stage, all lists are empty.
• Step-2: In this phase, $[eqn]$ responds to $[eqn]$ ’s adaptive queries. The queries $[eqn]$ -Query, $[eqn]$ -Query, Public key replacement-Query, and Signing-Query are the same as in the proof of Theorem 2.Secret value-Query: $[eqn]$ can issue the secret value query on $[eqn]$ . If $[eqn]$ , $[eqn]$ aborts. Otherwise, $[eqn]$ searches the tuple $[eqn]$ from the list $[eqn]$ and returns it to $[eqn]$ . Otherwise, $[eqn]$ selects $[eqn]$ at random, stores $[eqn]$ to $[eqn]$ , and responds $[eqn]$ to $[eqn]$ .Partial private key-Query: For $[eqn]$ ’s query on $[eqn]$ , $[eqn]$ operates as the following: If $[eqn]$ , $[eqn]$ aborts. Otherwise, $[eqn]$ checks $[eqn]$ to find $[eqn]$ , picks $[eqn]$ at random, computes $[eqn]$ , and sets $[eqn]$ and $[eqn]$ . Then, it inserts $[eqn]$ and $[eqn]$ to lists $[eqn]$ and $[eqn]$ , respectively, and returns $[eqn]$ to $[eqn]$ .Public key-Query: Once $[eqn]$ receives $[eqn]$ ’s query on $[eqn]$ , $[eqn]$ performs the steps as below. If $[eqn]$ , $[eqn]$ runs as Secret value-Query and Partial private key-Query to obtain and update $[eqn]$ , and then returns $[eqn]$ . Otherwise, $[eqn]$ first sets $[eqn]$ for some unknown $[eqn]$ , and operates as Partial private key-Query to generate $[eqn]$ . Then, $[eqn]$ records the item $[eqn]$ to $[eqn]$ and returns $[eqn]$ .
• Step-3: Eventually, $[eqn]$ either admits failure or returns its forgery $[eqn]$ on $[eqn]$ .

If in the case that $[eqn]$ is a valid forgery under $[eqn]$ , the verification equation $[eqn]$ holds. By applying the forking lemma in [29], $[eqn]$ replays $[eqn]$ with the same random tape, but provides two distinct values of $[eqn]$ . $[eqn]$ can output another valid signature $[eqn]$ . Hence, we have $[eqn]$ . Therefore, $[eqn]$ obtains two independent equations satisfying $[eqn]$ and $[eqn]$ [30]. Therefore, $[eqn]$ can compute the value of $[eqn]$ , which is a solution to the ECDLP. □

Theorem 4.  Our SHS achieves privacy preservation if the underlying ChaCha20-Poly1305 algorithm is secure.

Proof. To protect the privacy of PHI data, in our design, each BMS adopts a widely used ChaCha20-Poly1305 algorithm to encrypt data. As fully analyzed by Bellare et al. in [31], this encrypt-then-MAC paradigm provides both privacy and integrity. In particular, the privacy property inherently implies the security of indistinguishability under chosen-ciphertext attacks. We omit the rigorous proof here for simplicity. □

4. Performance Evaluation

This section presents a comparative performance analysis of our proposed SHS, benchmarking its computational and communication costs against prior art solutions detailed in studies [9,19,23,25].

The proposed SHS system consists of four sequential phases: System Setup (A), BMS-to-PAD data sharing (B), PAD-to-MCS data sharing (C), and SD’s data access (D). As stage A can be executed once during the offline phase to complete the establishment of system parameters and entity registration, we will omit the performance comparison for this stage.

4.1. Computational Costs Comparison

To evaluate the computational efficiency of these schemes, we set up a benchmark experiment for testing several cryptographic operations. More concretely, a Raspberry Pi 3B+ device simulates the BMS, while a PC equipped with a 2.5 GHz Intel Core i5-13400 processor and 16 GB RAM simulates the PAD and SD. In particular, to test related cryptographic operations, the secp256k1 curve defined by $[eqn]$ is used for schemes based on the elliptic curve cryptography (ECC), where the prime q is 32 bytes and $[eqn]$ . To achieve the same security level (i.e., about 128 bit), for schemes, we leverage the bilinear pairing $[eqn]$ , $[eqn]$ is a $[eqn]$ -order group constructed on a BLS12-381 curve $[eqn]$ , where primes $[eqn]$ and $[eqn]$ are 48 bytes and 32 bytes, respectively.

For ease of presentation, the time cost for one pairing operation, modular exponentiation operation, pairing-related point multiplication operation, pairing-related point addition operation, ECC-related point multiplication operation, ECC-related point addition operation, map-to-point hash, and a general hash are denoted by the symbols $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ , $[eqn]$ , and h, respectively. We also use $[eqn]$ and $[eqn]$ to denote encryption and decryption operations related to Chacha20-Poly1305 algorithm, respectively. Specifically, omitting the lightweight XOR operation, the running times for these different operations are presented in Table 3.

In phase B of our design, BMS_j_ needs to compute two encryption operations to obtain $[eqn]$ . Hence, the time cost for this phase is $[eqn]$ ms. In the next phase, the PAD executes n encryption operations and one general hash operation to check the validity of $[eqn]$ and obtain M. Then, to generate a signature $[eqn]$ on M, it computes one ECC-related point multiplication and one general hash operation. Hence, the total cost of this phase is $[eqn]$ $[eqn]$ ms. In phase D, the SD executes one general hash to check M. Then, it computes two general hash, three ECC-related point multiplication, and three point addition operations to verify $[eqn]$ . After that, it computes n decryption operations to obtain $[eqn]$ . Therefore, the total cost of this phase is $[eqn]$ $[eqn]$ ms. Similarly, we calculate the computational costs of the schemes [9,19,23,25], and the results are provided in Table 4.

As presented in the table, in phase B, compared to the schemes in [9,19], the computational cost of all other schemes, including ours, is the same and quite lightweight. For example, compared with the scheme in [9], our computational efficiency is 465 times higher. To better analyze the cost in phases C and D, we visually present the numerical results in Figure 2. As can be seen from Table 4 and Figure 2, in phase C, the computational overheads of schemes [9,25] are both constant, namely, 6.871 ms and 1.854 ms. The cost is positively correlated with the number of BMS n in both [23] and our design. Nevertheless, our solution still achieves a very low computational cost. For example, consider a patient utilizing 50 BMSs (we believe that this quantity is sufficient): the execution times of our proposal and the scheme in [23] are $[eqn]$ ms and $[eqn]$ ms, respectively. At this point, even compared to the most efficient scheme in [25], the gap between our two solutions is acceptable. Also note that, compared to the scheme in [25], our solution can achieve higher security. In phase D, the computational cost of all schemes increases linearly with the size of n. As can be seen from Table 4, the computational cost of our solution is lower than that of solutions [9,19,23], but higher than that of solution [25]. For example, when $[eqn]$ , the time cost of our solution is 40.238 ms, while such a cost for remaining schemes are 1572.61 ms, 1385.551 ms, 2688.274 ms, and 7.59 ms. The above analysis indicates that our proposal achieves ideal computational cost while ensuring enhanced security.

4.2. Communication Costs Comparison

We will quantitatively evaluate the communication overhead of our SHS against four prior works in [9,19,23,25] regarding phases B, C, and D. According to the curve parameters mentioned earlier, elements in $[eqn]$ , $[eqn]$ , $[eqn]$ , and $[eqn]$ occupy 48 bytes, 32 bytes, 32 bytes, and 64 bytes, respectively [25]. Cryptographic operations employ SHA-256 as the foundational hash function, producing 32-byte digests. We assume that the message is 20 bytes. Auxiliary fields include 4-byte timestamps and 4-byte identity markers [32]. We exclude the cost of the message as it is the same in all schemes. In phase B of our design, the BMS_j_ sends $[eqn]$ to the PAD, where $[eqn]$ . In this process, $[eqn]$ is the identity and t is the timestamp. Both $[eqn]$ and $[eqn]$ are 12-byte nonce. $[eqn]$ and $[eqn]$ are the outputs of the ChaCha20-Poly1305 algorithm. Therefore, the cost is $[eqn]$ 68 bytes.

In the next phase, the PAD sends the tuple $[eqn]$ to the MCS, where $[eqn]$ is PAD’s identity and the signature $[eqn]$ . In this regard, the cost is $[eqn]$ bytes.

Next, in phase D, the SD downloads the tuple $[eqn]$ from the MCS to obtain the encrypted PHI data for further processing. Hence, the communication cost is quantified as $[eqn]$ bytes. For comprehensive evaluation, we further count the designs in [9,19,23,25] and present the numerical results in Figure 3.

As presented in Figure 3a, the cost of our design in phase B is lower than the schemes in [9,19,23,25]. In the meantime, Figure 3b reveals that the communication expense of each scheme in phases C and D exhibits a linear growth relative to the number of messages transmitted. Among the compared schemes, our proposed scheme is the most efficient in terms of communication cost scalability in phases C and D. For example, when $[eqn]$ , the cost for our scheme is 3468 bytes, while the costs of other schemes [9,19,23,25] are 7444 bytes, 5220 bytes, 3532 bytes, 3644 bytes, and 1904 bytes, respectively. In particular, compared to these recent works, the percentage range of our performance improvement is from $[eqn]$ to $[eqn]$ .

In summary, it is evident that our proposed system not only has ideal computational efficiency but also maintains the lowest overheads. Consequently, it is well suited for IoMT-based SHS.

5. Conclusions

In this paper, we explored the security and privacy issue of IoMT applications. To address the shortcomings in security and performance of existing work, we proposed a new IoMT-based SHS based on a new pairing-free CLS signature and the ChaCha20-Poly1305 algorithm. Our solution can achieve data integrity and privacy protection throughout the entire process from PHI data generation to data usage. We proved the security of our design based on standard cryptographic assumptions in the RO model. We evaluated the performance of our solution by comparing it with relevant work. The results show that our solution has ideal computational and communication costs while ensuring high security, making it suitable for resource-constrained IoMT applications.

Similar to many existing approaches, the private keys of entities in our scheme are used throughout the entire system lifecycle. This limitation lies in the absence of countermeasures for key compromise scenarios. Therefore, building an efficient key update mechanism to achieve forward security is still an open research question. In addition, designing an IoMT-based SHS that is more resource-efficient for sensors with severe resource constraints is also one of our future research interests.