Skip to main content
Sensors (Basel, Switzerland) logoLink to Sensors (Basel, Switzerland)
. 2025 Jul 24;25(15):4588. doi: 10.3390/s25154588

Revocable Identity-Based Matchmaking Encryption with Equality Test for Smart Healthcare

Xiaokun Zheng 1, Dong Zheng 2, Yinghui Zhang 2,*
Editor: Nikolaos Pitropakis
PMCID: PMC12349389  PMID: 40807754

Abstract

Smart healthcare establishes a safe, reliable, and efficient medical information system for the public with the help of the Internet of Things, cloud storage, and other Internet technologies. To enable secure data sharing and case-matching functions in smart healthcare, we construct a revocable identity-based matchmaking encryption with an equality test (RIBME-ET) scheme for smart healthcare. Our scheme not only ensures the confidentiality and authenticity of messages and protects the privacy of users, but also enables a cloud server to perform equality tests on encrypted ciphertexts from different identities to determine whether they contain the same plaintext and protects the confidentiality of data in the system through a user revocation mechanism. Compared with the existing identity-based encryption with equality test (IBEET) and identity-based matchmaking encryption with equality test (IBME-ET) schemes, we have improved the efficiency of the scheme and reduced communication overhead. In addition, the scheme’s security is proven in the random oracle model under the computational bilinear Diffie–Hellman (CBDH) assumption. Finally, the feasibility and effectiveness of the proposed scheme are verified by performance analysis.

Keywords: revocable, identity-based matchmaking encryption, equality test, smart healthcare

1. Introduction

Smart healthcare [1,2,3] is a new medical model that uses cloud storage, cloud computing, big data, and other information technologies to improve people’s health. It provides complete data support for patients and doctors and enables telemedicine, intelligent monitoring, data analysis, and other medical services. The purpose of smart healthcare is to use the user’s medical data to complete relevant medical operations and to provide more intelligent services.

Smart healthcare can effectively achieve optimal allocation of resources and can improve the medical level of local hospitals, but under the smart healthcare system, sensitive medical data transmission is involved. This poses a challenge to how smart healthcare can be used to store and manage data more effectively. Smart healthcare systems face several security issues, such as data origin and integrity verification; data confidentiality and user privacy protection; and key leakage issues. The complexity of security issues facing smart healthcare makes it crucial to design a secure and efficient data encryption scheme. Especially in systems where there may be users who do not want sensitive medical data to be leaked to other unrelated personnel, there is a need to achieve user privacy protection while securing medical data.

The most common method for securing data is encryption, which ensures the confidentiality of the data. We aim to achieve secure sharing of medical data and matching of patient cases to help patients communicate better. Lin et al. provided a diversified butterfly attractors of memristive Hopfield neural network (HNN) with two memristive systems, which can successfully realize the privacy protection of medical data [4]. Ding et al. proposed a novel chaotic memristive neural network (MNN) that integrates two memristors into a traditional Hopfield neural network [5]; the secure algorithm was then successfully applied in a remote sensing system to protect image data privacy. Although chaotic encryption protects data privacy, public key encryption is more suitable for implementing fine-grained access control, data sharing, and case matching of users in smart healthcare. Yang et al. [6] proposed public key encryption with equality test (PKEET) for use in Internet-based systems for private health records (PHRs) [7,8,9], which enables the cloud server to perform an equality test of two encrypted ciphertexts to confirm whether they contain the same plaintext, and the cloud server helps the patient to match the their data with that of others. When uploading data in a smart healthcare system, it is important to ensure the authenticity of the user’s data during data uploading to prevent other malicious users from posting malicious or false medical information.

In recent years, several scholars have shifted their research focus to identity-based encryption with equality test schemes (IBEET). IBEET eliminates certificate management issues in the PKEET, and IBEET is used in several applications, such as in smart healthcare and Internet of Vehicles (IoV) road monitoring. However, there are some security issues with IBEET, since the current IBEET [10,11] does not consider the anonymity of both the sender and the receiver, which may lead to the disclosure of identity information. The identity-based matchmaking encryption (IBME) scheme investigated by Ateniese et al. [12] provides an enhanced privacy protection mechanism for user matching in smart healthcare. IBME provides a bilateral access control function, which allows the sender and receiver to specify each other’s respective identities at the same time. The IBME scheme prevents the leakage of identity privacy, and when there is a mismatch, except for decryption failures, the receiver cannot access arbitrary information. In addition, user revocation [13,14,15] is also an issue that needs to be considered in intelligent medical systems; when the user’s key is leaked or lost, an attacker can obtain the user’s key and decrypt the ciphertext sent by the sender to obtain the corresponding medical information, leading to the leakage of the user’s private information.

In smart healthcare, the user can issue a query request to the server to help contact other users with the same disease, for example, two patients with different doctors but the same symptoms wanting to seek each other’s experience and help. One question here is how bilateral access control can be realized [16] to better protect the privacy of both parties. The doctor and patient designate each other; the doctor encrypts the data for a patient, and only the patient can successfully decrypt it. When the two parties do not match, there is no information leakage except for decryption failure. However, the traditional IBEET scheme does not solve this problem.

To address the challenges of protecting sender and receiver privacy, enabling bilateral access control, preserving data authenticity, and mitigating key loss and disclosure risks, we propose a revocable identity-based matchmaking encryption with equality test (RIBME-ET) scheme. This solution integrates identity-based matchmaking encryption (IBME) with an equality test mechanism. Our scheme achieves user revocation and uses less time in the decryption, trapdoor generation, and equality test phases compared to the existing identity-based matchmaking encryption with equality test scheme (IBME-ET) [17]. Compared to the existing IBEET [10,18] scheme, our scheme enables user revocation, achieves finer-grained access control, and further enhances user privacy. The main contributions of this paper are as follows:

  • We establish the first formal definition and security model for RIBME-ET, along with its concrete construction. The scheme implements a privacy-enhanced bilateral access control mechanism tailored to user matching in smart healthcare systems, ensuring both medical data authenticity and user privacy preservation.

  • Cloud servers leverage the equality test functionality to compare ciphertexts in smart healthcare scenarios, enabling patients to seek mutual assistance and share experiences securely. Our design incorporates user revocation, safeguarding encrypted medical data from decryption even if keys are compromised or lost. Comprehensive security proofs and performance evaluations validate the scheme’s robustness and efficiency.

Organization of the paper: Here, we outline the structure of the rest of the paper. Section 2 introduces some related works. Preliminaries and definitions are described in Section 3 and Section 4, and we propose a security model for our scheme. In Section 5, we construct a RIBME-ET scheme. In Section 6, we prove the security of our scheme. Performance evaluations are presented in Section 7. Finally, we conclude this paper in Section 8.

2. Related Work

In smart healthcare, to ensure data confidentiality, patients encrypt their medical data and store it in an encrypted form on cloud servers. When one of these patients, Alice, wants to find other patients with the same condition as her to share their experiences, Alice will commission a third party to help her find such patients. At the same time, considering privacy, Alice will not directly disclose her disease information to the third party but will encrypt her disease information and send it to the third party. When another patient, Bob, also wants the third party to help him find other patients with the same condition, Bob similarly encrypts his medical information and sends it to the third party. Subsequently, the third party performs equivalence testing on the encrypted disease information without decrypting it. If Alice’s encrypted message and Bob’s encrypted message are both encrypted from the same disease information, the third party will notify Alice and Bob. It is important to note that the third party does not obtain this disease information. Traditional identity-based encryption and searchable encryption cannot meet the specific requirements of this application scenario. Encryption schemes encrypt information, and without the decryption key, it is impossible to perform computational processing on the ciphertext and therefore impossible to distinguish the relationships between these ciphertexts. In searchable encryption schemes, the ciphertext used for retrieval and the trapdoor sent by the user must be generated using the same public–private key pair. If the ciphertext and trapdoor used for retrieval are encrypted using different public–private key pairs, the ciphertext cannot be identified.

Yang et al. proposed a public key encryption scheme supporting equality testing (PKEET), which allows anyone to determine whether two ciphertexts generated under different public keys contain the same message [6]. This scheme provided a solution for case matching and user classification in smart healthcare. Tang et al. proposed a fine-grained authorization PKEET scheme that allows an authorized equality test to be conducted on ciphertexts by two users [19]. The scheme effectively improves PKEET authorization. Then Tang proposed the all-or-nothing PKEET scheme (AON-PKEET) [20], which specifies who can perform an equality test on ciphertexts. Moreover, Tang proposed the PKEET scheme with authorization of different granularity (ADG-PKEET) [21]. This scheme is an extension of FG-PKEET, which protects against offline message recovery attacks (OMRAs) through the dual-server mechanism.

Ma et al. proposed an equality test scheme with flexible authorization (PKEET-FA). This cryptographic scheme provides authorization based on four different scenarios [22], and the security of these cryptosystems is based on the difficult assumption of bilinear pairs. Huang et al. proposed public key encryption with an authorized equality test (PKE-AET), which employs cipher-level authorization and user-level authorization to enhance privacy protection [23], and this scheme allows for a comparison of specific users’ ciphertexts or all ciphertexts. Hassan et al. proposed an efficient certificateless public key encryption scheme with authorized equality tests in healthcare environments [24]. Susilo et al. proposed public key encryption with a multi-ciphertext equality test in cloud computing [25]. Ma et al. proposed efficient public key encryption with an outsourced equality test for cloud-based IoT environments [26].

An increase in users in the cloud environment may lead to an increase in certificate management burden. To better enable PKEET to be better applied to the cloud environment, Ma et al. combined identity-based encryption and an equality test [18] and proposed, for the first time, an identity-based encryption scheme with an equality test function (IBEET). Lee et al. proposed a semi-generic construction of public key encryption and identity-based encryption with equality test [10]. Xiong et al. constructed the notion of identity-based signcryption with equality test (IBSC-ET) by combining signcryption and an equality test scheme [27]. Yang et al. proposed an efficient identity-based encryption with an equality test in cloud computing [28].

Ateniese et al. proposed a new encryption scheme termed identity-based matchmaking encryption (IBME) [12]. This scheme enables both senders and receivers to specify the identity conditions that the other party must satisfy to decrypt the message. The main security guarantee is privacy-preserving identity matching: during the decryption process, when the sender and receiver do not match each other, no information will be revealed. IBME opens up new ways of secretly communicating and enables several new applications. IBME ensures message confidentiality and authenticity in a non-interactive manner and provides the functionality required for bilateral access control of identities. Therefore, IBME offers users a more convenient and secure communication approach.

Chen et al. proposed an IBME from standard assumptions in the standard model [29]. Jiang et al. proposed a revocable IBME in the standard model, whose security is reduced to the hardness of the decisional bilinear Diffie–Hellman problem and computational Diffie–Hellman problem [30]. Wu et al. proposed a fuzzy IBME and implemented it [31]. Yan et al. proposed an IBME-ET and proved its security under the random oracle [17].

As shown in Table 1, except for the IBME scheme, all other schemes achieved CCA security. The traditional PKEET [6] scheme implements a ciphertext equality test but does not consider user revocation and finer-grained access control features. The IBEET [10] scheme accomplishes identity substitution via public keys as opposed to the PKEET scheme but does not consider user revocation and bilateral access control. Recent IBME [12] schemes have achieved finer-grained access control from the sender to the receiver but have not implemented the ciphertext equality test. In contrast, the IBME-ET [17] scheme implements the ciphertext equality test and bilateral access control and does not consider key revocation. Compared with the above schemes, our scheme not only improves the efficiency of decryption and trap generation but also considers user revocation, so it is better able to protect data in smart healthcare.

Table 1.

Comparison of functionality.

Schemes Equality Test User Revocation Bilateral Access Control Security Model
PKEET [6] 1 × 2 × CCA
IBEET [10] × × CCA
IBME [12] × × CPA
IBME-ET [17] × CCA

1 ✓: Supports the functionality. 2 ×: Does not support the functionality.

3. Preliminaries

In this section, we review preliminaries including notations, bilinear maps, and the computational bilinear Diffie–Hellman (CBDH) assumption.

3.1. Bilinear Map

Given two cyclic groups G1 and G2 of prime order p, let g be a generator of G1 and an admissible bilinear mapping e: G1×G1G2 is expected to satisfy the following properties:

  • Bilinearity: e(g1x,g2y)=e(g1,g2)xy for ∀g1,g2G1, and x,yZp*.

  • Non-degeneracy: e(g,g)1.

We say that G1 is a bilinear group if the group operation in G1 and the bilinear map e: G1×G1G2 are both efficiently computable.

3.2. Computational Bilinear Diffie–Hellman Assumption

Given a random tuple (g,ga,gb,gc) of a CBDH problem, where g is the generator of group G1 and a,b, and c are randomly chosen from Zp*, its solution is e(g,g)abc. Formally, the CBDH problem is hard in (G1,G2,e) if, for every PPT adversary A,

Pr[A(q,G1,G2,e,g,ga,gb,gc)=e(g,g)abc]negl(λ).

We say that the CBDH assumption holds in (g,G1,G2,e) if no PPT algorithm can compute e(g,g)abc with a non-negligible advantage.

4. Definition

In this section, we formalize the syntax and security of the RIBME-ET scheme.

4.1. System Model

The system model is shown in Figure 1. The system model consists of the following four entities, namely the sender, receiver, key generation center (KGC), and cloud server, as listed below:

  • Sender: The sender encrypts the messages with the encryption key and the specified receiver’s identity and then sends the resulting ciphertexts to the receiver.

  • Receiver: The receiver can decrypt the ciphertexts, generate trapdoors, and upload both the ciphertexts and computed trapdoors to the cloud server.

  • KGC: KGC is responsible for managing users in the system and generating encryption and decryption keys for senders and receivers. For user revocation, the KGC manages the distribution of the key; if the KGC stops sending the decryption key to the receiver, it means that the user has been revoked. Decryption algorithms and trapdoor algorithms require a decryption key that is related to the time period t.

  • Cloud server: This entity is responsible for storing ciphertexts and providing equality tests.

Figure 1.

Figure 1

System model.

4.2. Syntax of RIBME-ET

RIBME-ET is composed of the following polynomial algorithm:

  • Setup(1λ)(mpk,msk): Input the security parameter λ, and the algorithm outputs a time period t as input to produce the system’s master public key mpk and master secret key msk. Then the mpk is used as an implicit input for the following algorithms.

  • SKGen(msk,IDSnd)ekIDSnd: After inputting the master secret key msk and the sender’s identity IDSnd, the algorithm outputs the encryption key ekIDSnd.

  • RKGen(msk,t,IDRev)ekIDRev: After inputting the master secret key msk and the receiver identity IDRev, during time period t, the algorithm outputs the decryption key dkIDRev, which is associated with the time.

  • Enc(ekIDSnd,t,IDRev,m)C: Given mpk, the encryption key ekIDSnd, a period time t, a receiver identity IDRev, and the message m, the algorithm outputs the ciphertext C.

  • Dec(dkIDRec,IDSnd,C)m: Given mpk, the decryption key dkIDRev, a sender identity IDSnd, and the ciphertext C, the algorithm outputs m.

  • Trap(dkIDRev)tdID: It takes as input a portion of the receiver’s private key to compute the trapdoor corresponding to the ciphertext.

  • Test(CIDi,tdIDi,CIDj,tdIDj)result: This algorithm takes a receiver’s ciphertext with trapdoor tdIDi and another receiver’s ciphertext with trapdoor tdIDj as inputs and outputs a result of 0 or 1.

Correctness of RIBME-ET scheme: RIBME-ET Π = (Setup, SKGen, RKGen, Enc, Dec, Trap, Test) is correct if λN, (mpk,msk) Setup(1λ), Pr[Dec(dkIDRev, snd, Enc(ekIDSnd,t,rcv,m))=m]1negl(λ), and Test(CIDi,tdIDi,CIDj,tdIDj) = 0 or 1, where ekIDSnd,dkIDRev, and tdID are generated by SKGen(msk,IDSnd), RKGen(msk,t,IDRev), and Trap(dkIDRev).

4.3. Security Definitions of RIBME-ET

We analyze the security model of the RIBME-ET scheme and define three types of adversaries under our system model:

  • Type-I adversary: A Type-I adversary A1, who possesses a trapdoor, attempts to recover the plaintext m from a ciphertext. Security against A1 is defined as one-wayness under chosen identity and chosen ciphertext attacks (OW-ID-CCA).

  • Type-II adversary: A Type-II adversary A2, who has no trapdoor, attempts to determine which plaintext corresponds to a given ciphertext. Security against A2 requires indistinguishability under chosen identity and chosen ciphertext attacks (IND-ID-CCA).

  • Type-III adversary: A Type-III adversary A3 tries to forge a ciphertext C corresponding to the sender’s identity. The forgery (C,Rev,Snd) is considered valid if for all encryption keys ekIDSnd obtained by the adversary A3 it holds that IDSnd=Snd and the identity Rev is not held by the adversary A3. Security against Type-III adversary is existential unforgeability against identity under chosen message attacks (EU-ID-CMA).

Definition 1

(OW-ID-CCA). Regarding A1, the RIBME-ET scheme meets OW-ID-CCA security when no PPT A1 is winning the game below with a non-negligible advantage.

  1. Setup: Challenger C takes the security parameter λ as input, runs RIBME-ET.Setup(1λ)mpk, and sends the master public key mpk to A1.

  2. Phase 1: A1 may query the following oracles polynomially many times adaptively and in any order: OSKGen,ORKGen,ODec, and OTrap.

    • OSKGen: Given the identity of the sender Snd is received, A1 answers the encryption key ekSnd.

    • ORKGen: Given the identity of the receiver Rev is received, A1 answers the decryption key dkRev.

    • ODec: Given the identity of the receiver Rev, the identity of the target sender snd, and the ciphertext C are received, C answers the result of Dec(mpk,dkRev,Snd,C).

    • OTrap: Given the identity of the target sender Snd and the identity of the receiver Rev are received, C answers the corresponding trapdoor td(Snd,Rev).

  3. Challenge: A1 sends identities Snd* and Rev* to C. Subsequently, C randomly chooses a message m*{0,1}n in answer to A1 with the challenge ciphertext C = Enc(mpk,ekSnd*,Rev*,t*,m*).

  4. Phase 2: A1 makes queries like in Phase 1.

  5. Guess: A1 answers a guess m.

We say that the adversary A1 wins if m=m* in the above game, and the advantage of A1 is defined as advRIBMEET,A1OWIDCCA(λ)=Pr(m=m*).

In the above game, A1 cannot ask the following queries:

ORKGen(Rev*) and ODec(Rev*,Snd*,C*).

Definition 2

(IND-ID-CCA). We say that a RIBME-ET scheme is IND-ID-CCA-secure against Type-II adversaries if for any PPT adversary A2, the advantage of A2 in the following game with the challenger C is negligible in terms of the security parameter λ.

  1. Setup: This step is the same as that of the OW-ID-CCA security game in Definition 1.

  2. Phase 1: This step is the same as that of the OW-ID-CCA security game in Definition 1 except for OTrap.

  3. Challenge: A2 sends snd* and rcv* and selected messages m0*,m1*{0,1}n of the same length to C. C selects a random bit b{0,1}, runs RIBMEET.Enc(ekIDSnd,t,IDRev,mb)Cb, and sends Cb to A2.

  4. Phase 2: C responds to A2’s queries as in Phase 1.

  5. Guess: A2 outputs b{0,1}.

We say that the adversary A2 wins if b=b in the above game, and the advantage of A2 is defined as advRIBMEET,A2INDIDCCA(λ)=|Pr(b=b)12|.

In the above game, A2 cannot ask the following queries: ORKGen(Rev*),OTrap(Snd*,

Rev*), and ODec(Rev*,Snd*,C*).

Definition 3

(EU-ID-CMA). We say that a RIBME-ET scheme is EU-ID-CMA-secure against Type-III adversaries if for any PPT adversary A3, the advantage of A3 in the following game with the challenger C is negligible in terms of the security parameter λ.

  1. Setup: This step is the same as that of the OW-ID-CCA security game in Definition 1.

  2. Phase 1: This step is the same as that of the OW-ID-CCA security game in Definition 1 except for ODec and OTrap.

  3. Forgery: A3 outputs a forged ciphertext C=(C,IDRev,IDSnd) to C, C runs the ReceiverKey generation to obtain dkRev, C uses dkRev to decrypt ciphertext C, and C outputs m. If SndQOSKGen, SndIDSndRevQORKGenm, the adversary A3 wins and C returns 1. Else, if the adversary A3 fails, C returns 0.

We say that the adversary A3 wins if C outputs m and returns 1 in the above game; the advantage of A3 is defined as advRIBMEET,A3EUIDCMA(λ)=Pr[A3wins].

5. Construction of RIBME-ET

In this section, we provide a RIBME-ET construction, and the scheme coincides with our system model. The concrete scheme is as follows:

  • Setup: When the security parameter λ is input, the algorithm outputs a time period t{0,1}* and a bilinear group (p,e,G1,G2) with a generator gG1, where the order of G1 and G2 is p. Then it randomly selects seven cryptographic hash functions H0:{0,1}*×{0,1}*G1, H1:{0,1}*G1, H2:G2{0,1}l, H3:{0,1}n+γZp*, H4:G2G1, H5:{0,1}nG1, and H6:G1{0,1}l, modeled as random oracles, and a polynomial-time computable padding function φ:{0,1}n{0,1}l. We require that for all m{0,1}n, one can verify in polynomial time if m has been padded correctly and that φ(m) is efficiently invertible. In addition, it also selects two random numbers r, sZp* and computes g0=gr. Finally, the master public key and master secret key are mpk=(g,g0,p,e,G1,G2,H0,H1,H2,H3,H4,H5,H6,φ) and msk=(r,s).

  • Sender Key generation: Given the master key pair (mpk,msk) and a sender’s identity IDsnd{0,1}*, the algorithm outputs the sender’s encryption key ekIDSnd = H1(IDSnd)s.

  • Receiver Key generation: Given the master key pair (mpk,msk) and a receiver’s identity IDRev{0,1}*, with a period of time t, the algorithm outputs the receiver’s decryption key dkIDRev=(dkIDRev1, dkIDRev2, dkIDRev3)=(H0(IDRev,t)r, H0(IDRev,t)s, H0(IDRev,t)).

  • Encryption: Given the master public key mpk, the encryption key ekIDSnd, a time period t, the receiver’s identity IDRev, and a message m{0,1}n, the algorithm proceeds as follows:

    1. Sample random a, bZp*, and z{0,1}γ.

    2. Compute C0=gb and C1=ga.

    3. Compute k1 = e(H0(IDRev,t),g0a) and k2 = e(H0(IDRev,t),C0·ekIDSnd).

    4. Compute C2=gH3(m,z) and C3 = φ(m)H2(k1)H2(k2)H6(C2).

    5. Compute C4=H5(m)H3(m,z)·H4(e(g,H1(IDSnd)·H0(IDRev,t))).

    6. Output ciphertext C=(C0,C1,C2,C3,C4).

  • Decryption: Given the master public key mpk, a decryption key dkIDRev, a target identity IDSnd=Snd, and ciphertext C=(C0,C1,C2,C3,C4), the algorithm proceeds as follows:

    1. Parse C=(C0,C1,C2,C3,C4).

    2. Compute k1 = e(dkIDRev1,C1) and k2 = e(dkIDRev2,H1(IDSnd))·e(dkIDRev3,C0).

    3. Compute φ(m) = C3H2(k1)H2(k2)H6(C2).

    4. If the padding is valid, return m. Otherwise, return ⊥.

  • Trapdoor: The algorithm is performed by a receiver who takes H1(IDSnd) and dkIDRev as input to produce the trapdoor. tdRev = H1(IDSnd)·dkIDRev3= H1(IDSnd)·H0(IDRev,t). The scheme uses the decryption key of the receiver in the trapdoor generation phase, and the decryption key is divided into three components. The trapdoor generation phase uses one of the components to generate the trapdoor, which is not associated with the msk. Even if dkIDRev3 is leaked, it is not possible to compute the decryption key as a whole, and thus the use of a part of the decryption key has no effect on the security of the scheme.

  • Test: This algorithm is performed by the cloud server, which takes two ciphertext–trapdoor pairs (CA,tdA) and (CB,tdB).

    CA=(C0A,C1A,C2A,C3A,C4A),

    CB=(C0B,C1B,C2B,C3B,C4B).

    1. Compute ηA and ηB as follows:

      ηA = C4AH4(e(g,tdA)),

      ηB = C4BH4(e(g,tdB)).

    2. Compute e(C2A,ηB) and e(C2B,ηA) as follows:

    Check whether e(C2A,ηB)=e(C2B,ηA) holds. If it holds, output 1; otherwise, output 0.

Correctness:

  1. For decryption, if IDSnd=Snd, IDRev=Rev, and Snd matches Rev, the receiver will be able to decrypt the ciphertext. For a ciphertext C=(C0,C1,C2,C3,C4) under an encryption of a message m, let k1 and k2 be the keys computed by the decryption algorithm.

    Compute k1 = e(dkIDRev1,C1) = e(H0(IDRev,t)r,ga) = e(H0(IDRev,t),gra) = e(H0(IDRev,t),g0a) = k1.

    Compute k2 = e(dkIDRev2,H1(IDSnd))·e(dkIDRev3,C0) = e(H0(IDRev,t)s,H1(IDSnd))·e(H0(IDRev,t),gb) = e(H0(IDRev,t),gb·H1(IDSnd)s) = k2.

    φ(m) = C3H2(k1)H2(k2)H6(C2). Then return m.

  2. For the equality test, if IDSnd=SndAIDRev=RevAIDSnd=SndBIDRev=RevB, SndA matches RevA, and SndB matches RevB, only receivers A and B can compute their respective trapdoors. For the ciphertext CA encrypted by message mA and the ciphertext CB encrypted by message mB, we check the following:
    ηA=C4AH4(e(g,tdA))=H5(mA)H3(mA,zA),
    ηB=C4BH4(e(g,tdB))=H5(mB)H3(mB,zB),
    e(C2A,ηB)=e(gH3(mA,zA),H5(mB)H3(mB,zB))=e(g,H5(mB))H3(mA,zA)H3(mB,zB),
    e(C2B,ηA)=e(gH3(mB,zB),H5(mA)H3(mA,zA))=e(g,H5(mA))H3(mB,zB)H3(mA,zA).

    If mA=mB, then e(C2A,ηB)=e(C2B,ηA), and it outputs 1; otherwise, it outputs 0.

6. Security Analysis of RIBME-ET

In this section, we demonstrate that our RIBME-ET construction is OW-ID-CCA-secure against a PPT Type-I adversary, IND-ID-CCA-secure against a PPT Type-II adversary, and EU-ID-CMA-secure against a PPT Type-III adversary.

6.1. OW-ID-CCA Security Against Type-I Adversary

As for confidentiality, we first look into the OW-ID-CCA security of our construction against a Type-I adversary. We change the Boneh–Franklin CCA-secure IBE’s proof method; our method of proof is similar to that of the IBME scheme. We prove that RIBME-ET is OW-ID-CCA-secure under the CBDH assumption. First, we define BPub+, a variant of BasicPub that is more suitable for our needs. BPub+ is composed of the following algorithms:

  • Setup(1λ): Generate a symmetric pairing e: G1×G1G2, with G1 and G2 of an order p that depends on λ. Choose a random generator g of G1. Sample a random sZq* and set g0=gs. Choose three hash functions: H0:G2{0,1}n, H1:{0,1}n×{0,1}nZp*, and H2:{0,1}n{0,1}n, with mpk=(p,e,n,g,g0,G1,G2,H0,H1,H2) and msk=s.

  • KGen(mpk,msk): Choose a random GG1. The public key is pk=G. The private key is sk=Gs.

  • Enc(mpk,pk,m): To encrypt a message m under the public key pk=G, choose a random μ{0,1}n, set y=H1(μ,m), and output C=(C0,C1,C2)= (gy,μH0(e(G,g0)y)),mH2(μ)).

  • Dec(mpk,sk,C): Let C=(C0,C1,C2) be a ciphertext for the public key pk. To decrypt C using the private key sk, compute the following:

    1. C1H0(e(sk,C0))=μ.

    2. C2H2(μ)=m.

    3. Set y=H1(μ,m). Test that C0=gy. If not, reject the ciphertext.

    4. Output m as the decryption of C.

We show that if BPub+ is OW-CCA-secure, then our scheme is OW-ID-CCA-secure.

Theorem 1.

Let the hash functions Hi(i=0,1,2,3,4,5,6) be random oracles. Our construction is OW-ID-CCA-secure against a PPT Type-I adversary under the basis of the BDH assumption. More precisely, if A1 can break our proposal with the advantage ε, suppose that A1 makes at most qS sender key extraction queries, at most qR receiver key queries, at most qD decryption key queries, and at most qT trapdoor queries. We can conceive of a PPT algorithm A1 to address the CBDH assumption with the advantage ε512ε/e4(qR+qS+qD+qT+4)4qH2.

Proof of Theorem 1.

Given a CBDH assumption instance (g,ga,gb,gc), where a,b,cZp*, the task of A1 is to calculate D=e(g,g)abc by interacting with A1 as shown below:

  1. Setup: A1 first performs the setup algorithm to generate mpk=(g,g0,p,e,G1,G2,H0,H1,H2,H3,H4,H5,H6,φ), randomly selects x,yZp*, and gives the mpk to A1. A1 then implicitly sets msk=(x,y), g0=gx, and A1 has no knowledge about x and y. A1 preserves the LHi(i=0,1,2,3,4,5,6) lists to simulate the oracle Hi-query.

  2. Phase 1: A1 answers A1’s queries.

    • H0-query: On receiving this query with identity IDRev, if the query IDRev is in a tuple (IDRev,Q,β,b)LH0, then Q is returned. Otherwise, A1 randomly picks βZp* and inserts the new tuple (IDRev,Q,β,b) into LH0, with a random coin b{0,1}, so that Pr[b=0]=ξ. If b=0, A1 sets Q=gβ; otherwise, A1 sets Q=gcβ. Finally, (IDRev,Q,β,b) is added to LH0, and A1 sends Q to A1.

    • H1-query: On receiving this query with identity IDSnd, if the query IDSnd is in a tuple (IDSnd,Q,β,b)LH1, then Q is returned. Otherwise, A1 randomly picks βZp* and inserts the new tuple (IDSnd,Q,β,b) into LH1, with a random coin b{0,1}, so that Pr[b=0]=ξ. If b=0, A1 sets Q=gβ; otherwise, A1 sets Q=gaβ. Finally, (IDSnd,Q,β,b) is added to LH0, and A1 sends Q to A1.

    • H2-query: A1 maintains a list LH2 that stores tuples of the form (X,h2) with the history of calls to LH2. If the query X has already been completed, the challenger returns the value h2. If not, it samples a random h2{0,1}n, adds (X,h2) to the list LH2, and returns h2.

    • H3-query: A1 maintains a list LH3 that stores tuples of the form (m,u,h3) with the history of calls to LH3. If the queries m and u have already been completed, the challenger returns the value h3. If not, it randomly picks m{0,1}n, u{0,1}n, and h3{0,1}γ and inserts the new tuple (m,u,h3) into LH3. Subsequently, A1 sends h3 to A1.

    • H4-query: A1 maintains a list LH4 that stores tuples of the form (gh4,h4) with the history of calls to LH4. If the query gh4 has already been completed, the challenger returns the value gH4. If not, it randomly picks gh4G2 and h4G1 and inserts the new tuple (gh4,h4) into LH4. Subsequently, A1 sends h4 to A1.

    • H5-query: A1 maintains a list LH5 that stores tuples of the form (m,h5) with the history of calls to LH5. If the query m has already been completed, the challenger returns the value h5. If not, it randomly picks m{0,1}n and h5G1 and inserts the new tuple (m,h5) into LH5. Finally, A1 sends h5 to A1.

    • H6-query: A1 maintains a list LH6 that stores tuples of the form (gH6,h6) with the history of calls to LH6. If the query gH6 has already been completed, the challenger returns the value h6. If not, it randomly picks gH6G1 and h6{0,1}l and inserts the new tuple (gH6,h6) into LH6. Finally, A1 sends h6 to A1.

    • OSKGen: A1 performs a simulation algorithm with the H1-query. Let IDSnd be the input of OSKGen. A1 obtains H1(Snd)=Q. There is a tuple (IDSnd,Q,β,b) in LH1. If b=1, A1 aborts; otherwise, it returns ekSnd=gyβ.

    • ORKGen: A1 performs a simulation algorithm with the H0-query. Let IDRev be the input of ORKGen. A1 obtains H0(Rev,t)=Q. There is a tuple (IDRev,Q,β,b) in LH0. If b=1, A1 aborts; otherwise, it returns dkRev=(gxβ,gyβ,Q=gβ).

    • ODec: Let IDSnd=Snd. A1 performs a simulation algorithm to query the H0-query and H1-query. A1 obtains the ciphertexts C=(C0,C1,C2,C3,C4). A1 sends the output of Dec(mpk,dkRev,Snd,C) to A1.

      When revRev*, A1 can query ORKGen to obtain dkRev and returns the outcome Dec(mpk,dkRev,snd,C).

      Otherwise, A1 can query OSKGen to obtain ekSnd and compute k2 = e(Q,C0·ekSnd). For each tuple (X,h2) in LH2 and (gH6,h6) in LH6, A1 computes φ(m) = C3h2h6 and H3(m,u). If C2=gH3(m,u) and there exists a tuple (gh4,h4) in LH4 such that C4=H5(m)H3(m,u)·h4 is valid, it returns m. When LH4 has no such tuple, it returns ⊥.

    • OTrap: Let snd=Sndi. A1 performs a simulation algorithm to query H0 and H1. A1 runs the receiver key queries on the ID to obtain dkRev=(dkRev1, dkRev2, dkRev3)=(gxβ,gyβ,Q=gβ) and responds to A1 with tdid. When Snd=Snd* or Rev=Rev*, A1 fails. Otherwise, A1 sends tdid to A1.

  3. Challenge: Algorithm A1 outputs a pair of sender and receiver identities (Snd*,Rev*) to A1. A1 randomly select a message m*{0,1}n and utilizes a simulation algorithm to query oracles H0 and H1. The challenge pair of sender and receiver identities do not appear in the receiver key queries of Phase 1. Now A1 performs the following steps:

    • (1)

      Compute H0(rev,t)=Q and H1(snd)=Q. If both the tuples (Rev,Q,β,b)LH0 and (Snd,Q,β,b)LH1 do not have coins b and b equal to 1, A1 aborts. If not, we know that dkRev2=gcyβ and H1(Snd)=gxβ. Hence, H2(k2) = H2(e(dkIDRev2,H1(IDSnd))·e(dkIDRev3,C0)), where e(dkIDRev2,H1(IDSnd)) = e(gcyβ,gxβ) = Dββ, and Q=dkRev3.

    • (2)

      Parse C=(C0,C1,C2,C3,C4), compute L=1/(ββ), and take a random tuple (X,h2). Return D=(X·e(Q,C0)1)L.

  4. Phase 2: A1 makes queries like in Phase 1.

  5. Guess: A1 answers with a guess m for m*. A1 answers with a CBDH solution D.

Analysis: First of all, note that the simulation is perfect since in the above game we require that the challenge (C,Rev,Snd) satisfies the condition that Rev disappears in ORKGen, Rnd disappears in OSKGen, and the challenge C disappears in ODec. Assuming that the adversary makes at most qR,qS,qD, and qT queries for ORKGen,OSKGen,ODec, and OTrap, the probability that A1 does not abort for any of these calls is δqR+qS+qD+qT. Similarly, the probability that A1 does not abort overall is δqR+qS+qD+qT(1δ)4, which is maximized at δopt=(qR+qS+qD+qT)/(qR+qS+qD+qT+4). If we use δopt as the probability of obtaining coins b=0 in the H0 and H1 queries, we have that the probability of A1 not aborting is at least 256/e4(qR+qS+qD+qT+4)4.

If A1 does not abort, it outputs the correct solution D with a probability of at least 2ε/qH2. Hence, A1 solves the CBDH problem with an advantage of 512ε/e4(qR+qS+qD+qT+4)4qH2. □

6.2. IND-ID-CCA Security Against Type-II Adversary

As for privacy, we look into the IND-ID-CCA security of our construction against a Type-II adversary.

Theorem 2.

Let the hash functions Hi(i=0,1,2,3,4,5,6) be random oracles. Our construction is IND-ID-CCA-secure against a PPT Type-II adversary under the basis of the CBDH assumption. More precisely, if A2 can break our proposal with the advantage ε, suppose that A2 makes at most qS sender key extraction queries, at most qR receiver key queries, and at most qD decryption key queries. We can conceive of a PPT algorithm A2 to address the CBDH assumption with the advantage ε54ε/e3(qR+qS+qD+3)3qH2.

Proof of Theorem 2.

Given a CBDH assumption instance (g,ga,gb,gc), where a,b,cZp*, the task of A2 is to calculate D=e(g,g)abc by interacting with A2 as shown below:

  1. Setup: A2 first performs the setup algorithm to generate mpk=(g,g0,p,e,G1,G2,H0,H1,H2,H3,H4,H5,H6,φ), randomly selects x,rZp*, and sends the mpk to A2. A2 implicitly sets msk=x and g0=gx, and A2 has no knowledge about x. A2 preserves the LHi(i=0,1,2,3,4,5,6) lists to simulate the oracle Hi-query.

  2. Phase 1: A2 answers A2’s queries.

    • H0-query: On receiving this query with identity IDRev, if query IDRev is in a tuple (IDRev,Q,β,b)LH0, then Q is returned. Otherwise, A2 randomly picks βZp* and inserts the new tuple (IDRev,Q,β,b) into LH0, with a random coin b{0,1}, so that Pr[b=0]=ξ. If b=0, A2 sets Q=gβ; otherwise, A2 sets Q=gcβ. Finally, (IDRev,Q,β,b) is added to LH0, and A2 sends Q to A2.

    • H1-query: A2 maintains a list LH2 that stores tuples of the form (Sndi,Yi) with the history of calls to LH2. If the query Sndi has already been completed, the challenger returns the value Yi. If not, it samples a random YiG1, adds (Sndi,Yi) to the list, and returns Yi.

    • H2-query: A2 maintains a list LH2 that stores tuples of the form (X,h2) with the history of calls to LH2. If the query X has already been completed, the challenger returns the value h2. If not, it samples a random h2{0,1}n, adds (X,h2) to the list LH2, and returns h2.

    • H3-query: A2 maintains a list LH3 that stores tuples of the form (m,u,h3) with the history of calls to LH3. If the queries m and u have already been, the challenger returns the value h3. If not, it randomly picks m{0,1}n, u{0,1}n, and h3{0,1}γ and inserts the new tuple (m,u,h3) into LH3. Subsequently, A2 sends h3 to A2.

    • H4-query: A2 maintains a list LH4 that stores tuples of the form (gh4,h4) with the history of calls to LH4. If the query gh4 has already been completed, the challenger returns the value gH4. If not, it randomly picks gh4G2 and h4G1 and inserts the new tuple (gh4,h4) into LH4. Subsequently, A2 sends h4 to A2.

    • H5-query: A2 maintains a list LH5 that stores tuples of the form (m,h5) with the history of calls to LH5. If the query m has already been completed, the challenger returns the value h5. If not, it randomly picks m{0,1}n and h5G1 and inserts the new tuple (m,h5) into LH5. Finally, A2 sends h5 to A2.

    • H6-query: A2 maintains a list LH6 that stores tuples of the form (gH6,h6) with the history of calls to LH6. If the query gH6 has already been completed, the challenger returns the value h6. If not, it randomly picks gH6G1 and h6{0,1}l and inserts the new tuple (gH6,h6) into LH6, finally, A2 sends h6 to A2.

    • OSKGen: A2 performs a simulation algorithm with the H1-query. Let IDSnd be the input of OSKGen. A2 obtains H1(Snd)=Y. There is a tuple (Sndi,Yi) in LH1, and it returns Yir.

    • ORKGen: A2 performs a simulation algorithm with the H0-query. Let IDRev be the input of ORKGen. A2 obtains H0(Rev,t)=Q. There is a tuple (IDRev,Q,β,b) in LH0. If b = 1, A2 aborts; otherwise, it returns dkRev=(g0β,Qr,Q=gβ).

    • ODec: Let IDSnd=Snd. A2 performs a simulation algorithm to query the H0-query and H1-query. A2 obtains the ciphertexts C=(C0,C1,C2,C3,C4). A2 sends the output of Dec(mpk,dkRev,Snd,C) to A2.

      When RevRev*, A1 can query ORKGen to obtain dkRev and returns the outcome Dec(mpk,dkRev,Snd,C).

      Otherwise, A2 can query OSKGen to obtain ekSnd and compute k2 = e(Q,C0·ekSnd). For each tuple (X,h2) in LH2 and (gH6,h6) in LH6, A2 computes φ(m) = C3h2h6 and H3(m,u). If C2=gH3(m,u) and there exists a tuple (gh4,h4) in LH4 such that C4=H5(m)H3(m,u)·h4 is valid, m is returned. When LH4 has no such tuple, ⊥ is returned.

  3. Challenge: Algorithm A2 outputs equal-length messages m0,m1{0,1}n along with the two pairs of sender and receiver identities (Snd0,Rev0,Snd1,Rev0) to A2. The pairs of sender and receiver identities do not appear in the receiver key queries of Phase 1. Afterwards, A2 utilizes a simulation algorithm to query the oracles H0 and H1. A2 performs the following steps:

    • (1)

      After selecting Rev0 and Rev1, A2 queries H0(Rev0)=Q0 and H0(Rev1)=Q1. If the tuples (IDRev0,Q0,β0,1) and (IDRev1,Q1,β1,1) do not belong to LH0, A2 aborts. Otherwise, we know that b0 = 0 and b1 = 1, which means that Q0=ek0 and Q1=ek1.

    • (2)

      A2 computes C0=gd for a random dZp* and queries H1(Snd0)=Y0 and H1(Snd1)=Y1. It uses them to obtain φ(m0) = C3H2(Q0,C0·Y1r)H6(gH6) and φ(m1) = C3H2(Q1,C0·Y1r)H6(gH6). Note that ekSnd=Yir.

    • (3)

      A2 sends m0,m1,Q0, and Q1 to its challenger and receives C=(C1,C2,C3,C4) as a response.

    • (4)

      A2 computes C=(C0,C1,C2,C3,C4) and sends it to A2. This is a proper encryption of mb under the condition IDRevb=Revb and sender’s identity Sndb.

  4. Phase 2: A2 makes queries like in Phase 1.

  5. Guess: A2 answers with a guess b{0,1}. A2 responds to its challenger with the same guess.

Analysis: Note that the simulation is perfect since in the above game we require that the challenge (m0,m1,Rev0,Snd0,Rev1,Snd1) satisfies the condition that Revb disappears in ORKGen and Sndb disappears in OSKGen; meanwhile, the encrypted challenge ciphertext cannot access ODec. Assuming that the adversary makes at most qR,qS, and qD queries for ORKGen,OSKGen, and ODec, the probability that A2 does not abort for any of these calls is δqR+qS+qD. Similarly, the probability that A2 does not abort overall is δqR+qS+qD(1δ)3, which is maximized at δopt=(qR+qS+qD)/(qR+qS+qD+3). If we use δopt as the probability of obtaining coins b=0 in the H0 and H1 queries, we have that the probability of A2 not aborting is at least 27/e3(qR+qS+qD+3)3.

If A2 does not abort, it outputs the correct solution D with a probability of at least 2ε/qH2. Hence, A2 solves the CBDH problem with an advantage of 54ε/e3(qR+qS+qD+3)3qH2. □

6.3. EU-ID-CMA Security Against Type-III Adversary

As for the authenticity, we look into the EU-ID-CMA security of our construction against a Type-III adversary.

Theorem 3.

Let the hash functions Hi(i=0,1,2,3,4,5,6) be random oracles. Our construction is EU-ID-CMA-secure against a PPT Type-III adversary on the basis of the CBDH assumption. More precisely, if A3 can break our proposal with the advantage ε, suppose that A3 makes at most qS sender key extraction queries and at most qR receiver key queries. We can conceive of a PPT algorithm A3 to address the CBDH assumption with the advantage ε8ε/e2(qR+qS+2)2qH2.

The proof of this theorem is very similar with that of Theorem 1, which demonstrates the OW-ID-CCA security of our RIBME-ET scheme. Similarly to the proof of Theorem 1, we can prove the EU-ID-CMA security of our scheme. We provide the full proof of this theorem in Appendix A.

7. Performance Evaluation

In this section, we will evaluate the performance of our proposed scheme through theoretical comparisons and experimental evaluations to show its effectiveness and practicality.

7.1. Functionality and Security Comparisons

Table 2 shows the functionality and security comparisons between our RIBME-ET scheme and similar schemes. It is obvious that the IBME [12] scheme ensures the authenticity of data and privacy of users but does not provide equality test functionality or achieve CCA security. Since IBME [12] only implements CPA security, with valid plaintext and ciphertext pairs at the sender and receiver, an attacker can use it to forge any message, thus threatening the authenticity of the ciphertext in cloud storage.

Table 2.

Comparison of functionality and security.

Schemes Security Equality Test Authenticity Privacy User Revocation Bilateral Access Control
IBEET [10] CCA 1 ×2 × × ×
IBME [12] CPA × ×
IBEET [18] CCA × × × ×
IBME-ET [17] CCA ×
Ours CCA

1 ✓: Supports the functionality. 2 ×: Does not support the functionality.

The IBEET [10,18] scheme ensures data confidentiality but provides neither bilateral access control nor user revocation. The IBME-ET [17] scheme does not support user revocation. In the later comparison of the experimental analysis, our scheme is found to be more efficient than theirs. By comparing different schemes, our proposed RIBME-ET scheme can be found to realize all the functionality and security required, which not only ensures the confidentiality of data, privacy of users, user revocation, and bilateral access control and achieves CCA security but also provides equality test functionality for ciphertexts generated under different identities in smart healthcare.

Table 3 shows the computational cost comparison of our scheme with other schemes in terms of encryption key generation, decryption key generation, encryption, decryption, trapdoor generation, and equality testing. In Table 3, Exp is the exponentiation, p is the pairing, H and H are hash-to-point operations in G1 and G2, and the symbol − indicates that the scheme does not have this phase. Our scheme has a lower computational cost compared to the IBME-ET [17] scheme in the decryption key generation, decryption, trapdoor generation, and equality test phases. Table 4 gives a comparison of the communication overhead of our scheme with that of other schemes, showing the results for encryption key, decryption key, trapdoor, and ciphertext comparisons. In Table 4, |G1| and |G2| are the sizes of the elements in groups G1 and G2, respectively. |Zp| is the size of the elements in Zp, and λ is the security level. Our scheme has a lower communication cost in the trapdoor and ciphertext generation phases compared to the IBME-ET [17] scheme.

Table 3.

Comparison of computation costs.

Schemes SKGen RKGen Enc Dec Trap Test
IBEET [10] 3H+3Exp 3H+3p+6Exp 3p+2Exp 0 2p+2Exp
IBEET [18] H H+2Exp 2H+6Exp 2p+2Exp H+Exp 4p
IBME-ET [17] H+Exp 2H+3Exp 2H+2p+6Exp H+3p+3Exp H+p+4Exp 6p
Ours H+Exp H+3Exp 2H+3p+5Exp 3p H 4p

Table 4.

Comparison of communication costs.

Schemes Encryption Key Decryption Key Trapdoor Ciphertext
IBEET [10] 3|G2| |G2| 4|G1|+5λ
IBEET [18] |G1| 2|G1| |G1| 4|G1|+|Zp|
IBME-ET [17] |G1| 3|G2| 2|G2| 3|G1|+|G2|+|Zp|+λ
Ours |G1| 3|G2| |G2| 4|G1|+|Zp|

7.2. Experimental Analysis

We evaluated the performance of our schemes by conducting extensive experiments. The tests were performed on a PC with the following specifications: Windows 10 Professional operating system, AMD Ryzen 5 5600 @ 3.5 GHz processor, and 32 GB RAM. The code was implemented in Java using the Java Pairing-Based Cryptography Library (JPBC) and tested on a 160-bit elliptic curve group constructed by the equation y2=x3+x over a 512-bit field. We implemented the proposed scheme and compared it with IBEET [10,18] and IBME-ET [17]. The experimental results are shown in Figure 2 and Figure 3, which illustrate the computation costs and communication costs of these schemes, respectively.

Figure 2.

Figure 2

Computation cost of each scheme. (a) Encryption. (b) Decryption. (c) Trapdoor. (d) Test. These schemes: Lee2016 [10], Ma2016 [18], Yan2024 [17].

Figure 3.

Figure 3

Communication cost of each scheme. (a) Encryption key. (b) Decryption key. (c) Trapdoor. (d) Ciphertext. These schemes: Lee2016 [10], Ma2016 [18], Yan2024 [17].

Figure 2 shows the computational cost of each scheme. Our scheme has an advantage in the decryption and trapdoor generation phases, as it takes less time compared to the IBEET [10,18] and IBME-ET [17] schemes. In the equality test phase, our scheme takes the same amount of time as IBEET [18] and less time compared to IBEET [10] and IBME-ET [17]. Figure 3 shows the communication cost of each scheme and the communication cost used by our scheme in the trapdoor phase. Additionally, the ciphertext is the same as that of the IBME-ET scheme [18], which has a lower communication cost compared to the IBEET [10] and IBME-ET [17] schemes.

From Table 2, Table 3 and Table 4 and Figure 2 and Figure 3, we can conclude that, with a small sacrifice in computational and communication efficiency, our RIBME-ET scheme not only ensures the authenticity and confidentiality of data, the privacy of users, user revocation, and CCA security but also provides equality test functionality for ciphertexts generated under different identities in smart healthcare. Other related schemes cannot support this feature.

8. Conclusions and Future Work

In this paper, we introduce a new primitive RIBME-ET scheme, which not only ensures the privacy of users, the authenticity and confidentiality of data, and user revocation but also supports privacy-enhanced bilateral access control and provides equality test functionality for ciphertexts generated under different identities in smart healthcare. We proved the security of the scheme under random oracles. A comprehensive performance analysis shows the efficiency of our scheme. The limitation of our solution is that it is one-to-one for both the sender and the receiver. Considering specific smart healthcare scenarios, there may be a need for one-to-many data sharing and case matching between the sender and the receiver. Regarding future research, on the one hand, we can extend the scheme in the future to the case of fuzzy matching to further enhance the privacy of identities, as well as to mitigate key escrow and create an efficient infrastructure for key management and key revocation. On the other hand, we could consider increasing support for multi-user data sharing and case matching, extending the scheme to post-quantum security, and improving large-scale smart healthcare data integration.

Acknowledgments

We gratefully acknowledge Qiuxia Zhao for their critical review of the study proposal. We also thank Axin Wu for their contributions to data collection and Zhichao Yuan for their editorial assistance in the manuscript preparation. Their expertise and dedication significantly enhanced the quality of this work.

Appendix A. Proof of Theorem 3

The proof of Theorem 3 is very similar as that of Theorem 1. Let A3 be a PPT Type-III adversary who breaks our proposal with the advantage ε. Suppose A3 makes at most qS sender key extraction queries and at most qR receiver key queries. Then we can construct a PPT algorithm A3 to address the CBDH assumption with the advantage ε8ε/e2(qR+qS+2)2qH2.

Proof of Theorem 3.

Given a CBDH assumption instance (g,ga,gb,gc), where a,b,cZp*, the task of A3 is to calculate D=e(g,g)abc by interacting with A3 as shown below:

  1. Setup: A3 gives A3 the public parameters (g,g0=ga,p,e,G1,G2,H0,H1,H2,H3,H4,H5,H6,φ), where Hi(i=0,1,2,3,4,5,6) are random oracles controlled by A3.

  2. Phase 1: A3 answers A3’s queries.

    • H0-query: On receiving this query with identity IDRev, if the query IDRev is in a tuple (IDRev,Q,β,b)LH0, then it returns Q. Otherwise, A3 randomly picks βZp* and inserts the new tuple (IDRev,Q,β,b) into LH0, with a random coin b{0,1}, so that Pr[b=0]=ξ. If b = 0, A3 sets Q=gβ; otherwise, A3 sets Q=gcβ. Finally, (IDRev,Q,β,b) is added to LH0, and A3 sends Q to A3.

    • H1-query: On receiving this query with identity IDSnd, if the query IDSnd is in a tuple (IDSnd,Q,β,b)LH1, then it returns Q. Otherwise, A3 randomly picks βZp* and inserts the new tuple (IDSnd,Q,β,b) into LH1, with a random coin b{0,1}, so that Pr[b=0]=ξ. If b = 0, A3 sets Q=gβ; otherwise, A3 sets Q=gaβ. Finally, (IDSnd,Q,β,b) is added to LH0, and A3 sends Q to A3.

    • H2-query: A3 maintains a list LH2 that stores tuples of the form (X,h2) with the history of calls to LH2. If the query X has already been completed, the challenger returns the value h2. If not, it samples a random h2{0,1}n, adds (X,h2) to the list LH2, and returns h2.

    • H3-query: A3 maintains a list LH3 that stores tuples of the form (m,u,h3) with the history of calls to LH3. If the queries m and u have already been completed, the challenger returns the value h3. If not, it randomly picks m{0,1}n, u{0,1}n, and h3{0,1}γ and inserts the new tuple (m,u,h3) into LH3. Subsequently, A3 sends h3 to A3.

    • H4-query: A3 maintains a list LH4 that stores tuples of the form (gh4,h4) with the history of calls to LH4. If the query gh4 has already been completed, the challenger returns the value gH4. If not, it randomly picks gh4G2 and h4G1 and inserts the new tuple (gh4,h4) into LH4. Subsequently, A3 sends h4 to A3.

    • H5-query: A3 maintains a list LH5 that stores tuples of the form (m,h5) with the history of calls to LH5. If the query m has already been completed, the challenger returns the value h5. If not, it randomly picks m{0,1}n and h5G1 and inserts the new tuple (m,h5) into LH5. Finally, A3 sends h5 to A3.

    • H6-query: A3 maintains a list LH6 that stores tuples of the form (gH6,h6) with the history of calls to LH6. If the query gH6 has already been completed, the challenger returns the value h6. If not, it randomly picks gH6G1 and h6{0,1}l and inserts the new tuple (gH6,h6) into LH6. Finally, A3 sends h6 to A3.

    • OSKGen: A3 performs a simulation algorithm with the H1-query. Let IDSnd be the input of OSKGen. A3 obtains H1(Snd)=Q. There is a tuple (IDSnd,Q,β,b) in LH1. If b = 1, A3 aborts; otherwise, it returns ekSnd=gyβ.

    • ORKGen: A3 performs a simulation algorithm with the H0-query. Let IDRev be the input of ORKGen. A3 obtains H0(Rev,t)=Q. There is a tuple (IDRev,Q,β,b) in LH0. If b = 1, A3 aborts; otherwise, it returns dkRev=(gxβ,gyβ,Q=gβ).

  3. Forgery: Now A3 sends (C,Rev,Snd) to A3. Let IDSnd=Snd. A3 performs the following steps:

    • (1)

      Compute H0(rev,t)=Q and H1(snd)=Q. If both the tuples (Rev,Q,β,b)LH0 and (Snd,Q,β,b)LH1 do not have coins b and b equal to 1, A1 aborts. If not, we know that dkRev2=gcyβ and H1(Snd)=gxβ. Hence, H2(k2) = H2(e(dkIDRev2,H1(IDSnd))·e(dkIDRev3,C0)), where e(dkIDRev2,H1(IDSnd)) = e(gcyβ,gxβ) = Dββ, and Q=dkRev3.

    • (2)

      Parse C=(C0,C1,C2,C3,C4), compute L=1/(ββ), and take a random tuple (X,h2). Return D=(X·e(Q,C0)1)L.

Analysis: Note that the simulation is perfect since in the above game we require that the challenge (C,Rev,Snd=IDSnd) satisfies the conditions that Rev disappears in ORKGen, Snd disappears in OSKGen, and the challenge C disappears in ODec. Assuming that the adversary makes at most qR and qS queries for ORKGen and OSKGen, the probability that A3 does not abort for any of these calls is δqR+qS. Similarly, the probability that A3 does not abort at all is δqR+qS(1δ)2, which is maximized at δopt=(qR+qS)/(qR+qS+2). If we use δopt as the probability of obtaining coins b=0 in the H0 and H1 queries, we have that the probability of A3 not aborting is at least 4/e2(qR+qS+2)2.

If A3 does not abort, it outputs the correct solution D with a probability of at least 2ε/qH2. Hence, A3 solves the CBDH problem with an advantage of 8ε/e2(qR+qS+2)2qH2. □

Author Contributions

Formal analysis, writing—original draft preparation, X.Z.; writing—review and editing, D.Z. and Y.Z. All authors have read and agreed to the published version of the manuscript.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

The data used to support the findings of this study are included within the article.

Conflicts of Interest

The authors declare no conflicts of interest.

Funding Statement

This research was funded in part by the National Cryptologic Science Fund of China (No.2025NCSF02037), in part by the National Natural Science Foundation of China (62072369, 62072371), in part by the Youth Innovation Team of Shaanxi Universities (23JP160), in part by the Shaanxi Special Support Program Youth Top-notch Talent Program, in part by the Technology Innovation Leading Program of Shaanxi (2023-YD-CGZH-31), and in part by the Technology Innovation Guidance Special Fund of Shaanxi Province (2024QY-SZX-17).

Footnotes

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

References

  • 1.Su J., Zhang L., Mu Y. Ba-rmkabse: Blockchain-aided ranked multi-keyword attribute-based searchable encryption with hiding policy for smart health system. Future Gener. Comput. Syst. 2022;132:299–309. doi: 10.1016/j.future.2022.01.021. [DOI] [Google Scholar]
  • 2.Mehla R., Garg R. Anonymous attribute-based searchable encryption for smart health system. SN Comput. Sci. 2024;5:879. doi: 10.1007/s42979-024-03206-4. [DOI] [Google Scholar]
  • 3.Popoola O., Rodrigues M.A., Marchang J., Shenfield A., Ikpehai A., Popoola J. An optimized hybrid encryption framework for smart home healthcare: Ensuring data confidentiality and security. Internet Things. 2024;27:101314. doi: 10.1016/j.iot.2024.101314. [DOI] [Google Scholar]
  • 4.Lin H., Deng X., Yu F., Sun Y. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems. IEEE; New York, NY, USA: 2024. Diversified butterfly attractors of memristive hnn with two memristive systems and application in iomt for privacy protection. [Google Scholar]
  • 5.Ding S., Lin H., Deng X., Yao W., Jin J. A hidden multiwing memristive neural network and its application in remote sensing data security. Expert Syst. Appl. 2025;277:127168. doi: 10.1016/j.eswa.2025.127168. [DOI] [Google Scholar]
  • 6.Yang G., Tan C.H., Huang Q., Wong D.S. Probabilistic public key encryption with equality test; Proceedings of the Topics in Cryptology-CT-RSA 2010: The Cryptographers’ Track at the RSA Conference 2010; San Francisco, CA, USA. 1–5 March 2010; Berlin/Heidelberg, Germany: Springer; 2010. pp. 119–131. Proceedings. [Google Scholar]
  • 7.Li M., Yu S., Zheng Y., Ren K., Lou W. Scalable and secure sharing of personal health records in cloud computing using attribute-based encryption. IEEE Trans. Parallel Distrib. Syst. 2012;24:131–143. doi: 10.1109/TPDS.2012.97. [DOI] [Google Scholar]
  • 8.Liu C.-H., Lin F.-Q., Chiang D.-L., Chen T.-L., Chen C.-S., Lin H.-Y., Chung Y.-F., Chen T.-S. Secure phr access control scheme for healthcare application clouds; Proceedings of the 2013 42nd International Conference on Parallel Processing; Lyon, France. 1–4 October 2013; New York, NY, USA: IEEE; 2013. pp. 1067–1076. [Google Scholar]
  • 9.Zhen Y. Ph.D. Dissertation. Worcester Polytechnic Institute; Worcester, MA, USA: 2011. Privacy-Preserving Personal Health Record System Using Attribute-Based Encryption. [Google Scholar]
  • 10.Lee H.T., Ling S., Seo J.H., Wang H. Semi-generic construction of public key encryption and identity-based encryption with equality test. Inf. Sci. 2016;373:419–440. doi: 10.1016/j.ins.2016.09.013. [DOI] [Google Scholar]
  • 11.Wu L., Zhang Y., Choo K.-K.R., He D. Efficient and secure identity-based encryption scheme with equality test in cloud computing. Future Gener. Comput. Syst. 2017;73:22–31. doi: 10.1016/j.future.2017.03.007. [DOI] [Google Scholar]
  • 12.Ateniese G., Francati D., Nuñez D., Venturi D. Match me if you can: Matchmaking encryption and its applications; Proceedings of the Advances in Cryptology–CRYPTO 2019: 39th Annual International Cryptology Conference; Santa Barbara, CA, USA. 18–22 August 2019; Berlin/Heidelberg, Germany: Springer; 2019. pp. 701–731. Proceedings, Part II 39. [Google Scholar]
  • 13.Zhang Y., Yu J., Hao R., Wang C., Ren K. Enabling efficient user revocation in identity-based cloud storage auditing for shared big data. IEEE Trans. Dependable Secur. Comput. 2018;17:608–619. doi: 10.1109/TDSC.2018.2829880. [DOI] [Google Scholar]
  • 14.Zhang R., Li J., Lu Y., Han J., Zhang Y. Key escrow-free attribute based encryption with user revocation. Inf. Sci. 2022;600:59–72. doi: 10.1016/j.ins.2022.03.081. [DOI] [Google Scholar]
  • 15.Wang G., Liu Q., Wu J., Guo M. Hierarchical attribute-based encryption and scalable user revocation for sharing data in cloud servers. Comput. Secur. 2011;30:320–331. doi: 10.1016/j.cose.2011.05.006. [DOI] [Google Scholar]
  • 16.Zhang Y., Deng R.H., Xu S., Sun J., Li Q., Zheng D. Attribute-based encryption for cloud computing access control: A survey. ACM Computing Surv. (CSUR) 2020;53:1–41. doi: 10.1145/3398036. [DOI] [Google Scholar]
  • 17.Yan Z., Lin X., Zhang X., Xu J., Qu H. Identity-based matchmaking encryption with equality test. Entropy. 2024;26:74. doi: 10.3390/e26010074. [DOI] [PMC free article] [PubMed] [Google Scholar]
  • 18.Ma S. Identity-based encryption with outsourced equality test in cloud computing. Inf. Sci. 2016;328:389–402. doi: 10.1016/j.ins.2015.08.053. [DOI] [Google Scholar]
  • 19.Tang Q. Towards public key encryption scheme supporting equality test with fine-grained authorization; Proceedings of the Australasian Conference on Information Security and Privacy; Melbourne, Australia. 11–13 July 2011; Berlin/Heidelberg, Germany: Springer; 2011. pp. 389–406. [Google Scholar]
  • 20.Tang Q. Public key encryption supporting plaintext equality test and user-specified authorization. Secur. Commun. Netw. 2012;5:1351–1362. doi: 10.1002/sec.418. [DOI] [Google Scholar]
  • 21.Tang Q. Public key encryption schemes supporting equality test with authorisation of different granularity. Int. J. Appl. Cryptogr. 2012;2:304–321. doi: 10.1504/IJACT.2012.048079. [DOI] [Google Scholar]
  • 22.Ma S., Huang Q., Zhang M., Yang B. Efficient public key encryption with equality test supporting flexible authorization. IEEE Trans. Inf. Forensics Secur. 2014;10:458–470. doi: 10.1109/TIFS.2014.2378592. [DOI] [Google Scholar]
  • 23.Huang K., Tso R., Chen Y.-C., Rahman S.M.M., Almogren A., Alamri A. “Pke-aet: Public key encryption with authorized equality test. Comput. J. 2015;58:2686–2697. doi: 10.1093/comjnl/bxv025. [DOI] [Google Scholar]
  • 24.Hassan A., Wang Y., Elhabob R., Eltayieb N., Li F. An efficient certificateless public key encryption scheme with authorized equality test in healthcare environments. J. Syst. Archit. 2020;109:101776. doi: 10.1016/j.sysarc.2020.101776. [DOI] [Google Scholar]
  • 25.Susilo W., Guo F., Zhao Z., Wu G. Pke-met: Public-key encryption with multi-ciphertext equality test in cloud computing. IEEE Trans. Cloud Comput. 2020;10:1476–1488. doi: 10.1109/TCC.2020.2990201. [DOI] [Google Scholar]
  • 26.Ma S., Zhong Y., Huang Q. Efficient public key encryption with outsourced equality test for cloud-based iot environments. IEEE Trans. Inf. Forensics Secur. 2022;17:3758–3772. doi: 10.1109/TIFS.2022.3212203. [DOI] [Google Scholar]
  • 27.Xiong H., Hou Y., Huang X., Zhao Y. Secure message classification services through identity-based signcryption with equality test towards the internet of vehicles. Veh. Commun. 2020;26:100264. doi: 10.1016/j.vehcom.2020.100264. [DOI] [Google Scholar]
  • 28.Yang Z., He D., Qu L., Ye Q. An efficient identity-based encryption with equality test in cloud computing. IEEE Trans. Cloud Comput. 2023;11:2983–2992. doi: 10.1109/TCC.2023.3248308. [DOI] [Google Scholar]
  • 29.Chen J., Li Y., Wen J., Weng J. Identity-based matchmaking encryption from standard assumptions; Proceedings of the International Conference on the Theory and Application of Cryptology and Information Security; Taipei, Taiwan. 5–9 December 2022; Berlin/Heidelberg, Germany: Springer; 2022. pp. 394–422. [Google Scholar]
  • 30.Jiang Z., Wang X., Zhang K., Gong J., Chen J., Qian H. Revocable identity-based matchmaking encryption in the standard model. IET Inf. Secur. 2023;17:567–581. doi: 10.1049/ise2.12116. [DOI] [Google Scholar]
  • 31.Wu A., Luo W., Weng J., Yang A., Wen J. Fuzzy identity-based matchmaking encryption and its application. IEEE Trans. Inf. Forensics Secur. 2023;18:5592–5607. doi: 10.1109/TIFS.2023.3310663. [DOI] [Google Scholar]

Associated Data

This section collects any data citations, data availability statements, or supplementary materials included in this article.

Data Availability Statement

The data used to support the findings of this study are included within the article.


Articles from Sensors (Basel, Switzerland) are provided here courtesy of Multidisciplinary Digital Publishing Institute (MDPI)

RESOURCES