Enabling Privacy-Preserving Data Sharing with Bilateral Access Control for Cloud

Abstract

Cloud computing plays an essential role in various fields. However, the existing cloud services face a severe challenge, which is how to share the data among a large scale of devices securely. In this paper, we introduce a cloud-based privacy-preserving data sharing scheme, derived from identity-based matchmaking encryption. In our scheme, the access policies are designed by both the sender and receiver simultaneously, to support bilateral access control. To improve efficiency, we delegate the match algorithm to the cloud server, reducing the computation cost and communication overhead on end devices without revealing the users’ privacy. Through formal security analysis, we show that our scheme holds security, authenticity, and privacy. Finally, we evaluate our scheme by conducting extensive experiments, indicating that our scheme is more efficient than the other data-sharing schemes in ME-based services in a real-world dataset.

1. Introduction

Recently, cloud services [1] have been rapidly promoted by the development of the internet technique. As a widely used paradigm of outsourcing service, the cloud has been accepted by the market (e.g., iCloud, Dropbox, and Microsoft Cloud), providing a convenient and low-cost method for data storage and data sharing [2]. As shown in Figure 1, cloud services play an important role in our daily life, such as smart healthcare, smart agriculture, smart cities, and smart transport [3,4,5,6]. According to the report released by Gartner in 2021, more than 45% of IT spending will be on building infrastructure, applications, and business process outsourcing, shifting from traditional solutions to the cloud by 2024. Despite the proliferation of the cloud, data security and privacy preservation arise as long-term concerns from the user side, since they lose physical control of their data. Therefore, cloud service providers (CSPs) are commonly treated as honest-but-curious (HBC) entities. On the other hand, different cloud services should prevent data breaches on the cloud to enhance CSPs’ reliability [7]. Therefore, it is crucial to design a secure and privacy-preserving data sharing scheme for cloud services.

The General Data Protection Regulation (GDPR) sets strict privacy requirements for CSPs. Specifically, three principles must be satisfied: (1) Receiver access control. From the data collection limitation principle, the data should only be sent to receivers that meet the data sender’s access policies. (2) Sender access control. From the data quality principle, the data sender should be identified to ensure data accuracy. (3) Data privacy. From the data privacy principle, sensitive data (e.g., access policies and shared data) should not be disclosed. Thereby, the access control in the data sharing scheme should be designed by both the sender and receiver. Moreover, the cloud-based data sharing scheme should guarantee data privacy when devices share data and store it on the cloud.

Inherently, several significant challenges arise when applying existing data sharing schemes to cloud services [8,9,10,11,12,13,14], which are not only caused by data breaches but also by the users’ strict privacy requirements. Taking the smart transport system as an example, end devices (e.g., distance sensors, speed sensors, and temperature sensors) collect information from vehicles [15]. By analyzing the relevant information, the smart transport system is able to perform more precise and effective traffic management. Due to the restricted computational resources and storage capability of end devices, vehicles primarily outsource the data collection to the cloud server. As is shown in Figure 1, vehicles are willing to share their data for the purpose of avoiding traffic jams and planning optimal travel paths. The data collections are transmitted from end devices to the cloud server. Then, the required data will be sent to target vehicles by the cloud server. Commonly, the collected data might contain sensitive information such as individuals’ daily action trajectories and real-time locations. If this information stored on the cloud server is accessible to anyone, it will directly threaten users’ data security. Therefore, it is necessary to ensure that sensitive information cannot be snooped on by the cloud server and prevent unauthorized entities from illegal access.

However, most current access control schemes only support one-side access control (i.e., sender/receiver access control). The one-side access control schemes cannot satisfy the practical privacy requirements, but result in vast communication overhead for transmitting information in the system. By applying bilateral access control, the access policy can be designed both by senders and receivers. Specifically, vehicles expect to grant access privileges to their information to the designated end devices. The end devices can also decide to get the information from the specified vehicles or other devices simultaneously. Intuitively, attribute-based encryption (ABE) seems to be a possible solution to address access control among multiple users [16]. The standard ABE approaches cannot support bilateral access control. To tailor the ABE technique for bilateral access control, ABE with a keyword search (ABKS) enables receivers to seek suitable senders using keywords [10]. Their scheme, however, requires additional interactions between the users and the cloud server, introducing extra communication overheads to users. Later, Ateniese et al. [17] presented an encryption primitive on CRYPTO’19, named Matchmaking Encryption (ME), to achieve bilateral access control without revealing any privacy for both senders and receivers. When the matching fails, nothing (i.e., the access policies and data) will be disclosed. However, the matching process brings heavy computation and communication overhead to end devices. To further improve efficiency, it is desirable to delegate the matching process to the cloud without revealing any users’ private information. To summarize, the practical secure data sharing for cloud services should be with privacy preservation and bilateral access control in order to facilitate the blossom of cloud services.

In this paper, we introduce a cloud-based privacy-preserving data sharing scheme with bilateral access control. By analyzing the practical security requirements, we formalize the crucial challenges in the state-of-the-art. Specifically, to provide bilateral access control, we construct our scheme based on identity-based matchmaking encryption (IB-ME) for realizing both sides designing the match policies simultaneously. To achieve high efficiency, we delegate the matching process to the cloud server while protecting the user’s private information and data by designing a signature-based match tag. The contributions of our work are summarized as follows:

• We suggest a data-sharing scheme for cloud services, derived from identity-based matchmaking encryption, named IBME-DS. The access policies in IBME-DS are specified by both the sender and receiver to achieve bilateral access control.
• To further improve the system efficiency, we design a privacy-preserving matching mechanism to delegate the matching process to the cloud server, which ensures user privacy and data confidentiality during the matching procedure.
• We formally define the system model, threat model, and security model of IBME-DS. Then, a comprehensive security analysis is to demonstrate that our proposed scheme meets the practical security requirements.
• Finally, we evaluate the performance of IBME-DS by conducting extensive experiments on a real-world dataset to show that IBME-DS is more efficient than relevant works.

Organization. The remainder of this paper is structured as follows. Section 2 discusses the preliminary adopted in this paper. In Section 3, we define the system model, threat model and security model of our scheme. Section 4 provides the concrete construction based on bilinear groups. Then, in Section 5, we give rigorous security proof to prove the security of our scheme. Then, Section 6 presents the theoretical analysis and experimental performance. In Section 7, we introduce relevant works on access control and matchmaking encryption. In Section 8, we discuss the advantages of our research and the limitations of it. Finally, we conclude our work in Section 9.

2. Preliminary

Definition 1

(Bilinear Pairing). Let ${\mathbb{G}}_1$, ${\mathbb{G}}_2$ and ${\mathbb{G}}_T$ be multiplicative cyclic groups of order p, with p being a large prime. We call them bilinear groups with such a bilinear map $e:{\mathbb{G}}_1\times {\mathbb{G}}_2\to {\mathbb{G}}_T$, if they hold the properties as follows.

• Bilinearity: The map e is bilinear, if $e(g^a,h^b)=e(g^b,h^a)=e{(g,h)}^{ab}$, for $\forall g\in {\mathbb{G}}_1$, $h\in {\mathbb{G}}_2$ and $a,b\in {\mathbb{Z}}_p^{*}$.
• Non-degeneracy: There exists $e(g,h)\ne 1_{{\mathbb{G}}_T}$, where $1_{{\mathbb{G}}_T}$ is the identity in ${\mathbb{G}}_T$.
• Computability: $e(g,h)$ can be computed efficiently, for $\forall g\in {\mathbb{G}}_1$, $h\in {\mathbb{G}}_2$.

Our scheme is constructed on symmetric pairing that ${\mathbb{G}}_1={\mathbb{G}}_2$. In the following part of this paper, we denote the bilinear pairing e as $e:\mathbb{G}\times \mathbb{G}\to {\mathbb{G}}_T$.

2.1. Matchmaking Encryption

In this part, we briefly review the matchmaking encryption [17]. In ME, the access control is specified by both sender and receiver. Specifically, ME contains six algorithms:

• Setup$\left(1^{\lambda }\right)\to (\mathtt{mpk},\mathtt{kpol},\mathtt{msk})$: Given the security parameter $1^{\lambda }$, the algorithm is to initialize the system and output a set of master keys, as master public/policy/secret key $\{\mathtt{mpk},\mathtt{kpol},\mathtt{msk}\}$.
• $\mathbf{SKGen}(\mathtt{msk},\sigma )\to e{k}_{\sigma }$: Given the sender’s attributes $\sigma \in {\{0,1\}}^{*}$, and the master secret key $\mathtt{msk}$, the algorithm is to generate the encryption key $e{k}_{\sigma }$ to the sender with attributes $\sigma$.
• $\mathbf{RKGen}(\mathtt{msk},\rho )\to d{k}_{\rho }$: Given the receiver’s attributes $\rho \in {\{0,1\}}^{*}$, and the master secret key $\mathtt{msk}$, the algorithm is to generate the decryption key $d{k}_{\rho }$ to the sender with attributes $\rho$.
• $\mathbf{PolGen}(\mathtt{kpol},\mathbb{S})\to d{k}_{\mathbb{S}}$: Given the access policy $\mathbb{S}$, and the master policy key $\mathtt{kpol}$, the algorithm is to generate the decryption key $d{k}_{\mathbb{S}}$ for the access policy $\mathbb{S}$.
• $\mathbf{Enc}(e{k}_{\sigma },\mathbb{R},m)\to c$: Given the encryption key $e{k}_{\sigma }$, the access policy $\mathbb{R}$, and the message m, the algorithm is to generate the ciphertext c.
• $\mathbf{Dec}(d{k}_{\rho },d{k}_{\mathbb{S}},c)\to m$ or ⊥: Given the decryption key $d{k}_{\rho }$, the decryption key $d{k}_{\mathbb{S}}$, and the ciphertext c, the algorithm is to output either the message m or ⊥.

If $\rho =\mathbb{R}$ and $\sigma =\mathbb{S}$, the given ciphertext will be correctly decrypted by the receiver. Worthy, it will reveal nothing except the matching does not occur.

2.2. Identity-Based Matchmaking Encryption

Additionally, we recap identity-based matchmaking encryption, including five algorithms:

• Setup$\left(1^{\lambda }\right)\to (\mathtt{mpk},\mathtt{msk})$: Given the security parameter $1^{\lambda }$, the algorithm will output the master public/secret key $\{\mathtt{mpk},\mathtt{msk}\}$.
• $\mathbf{SKGen}(\mathtt{msk},\sigma )\to e{k}_{\sigma }$: Given the sender’s identity $\sigma$, and the master secret key $\mathtt{msk}$, the algorithm will output the encryption key $e{k}_{\sigma }$.
• $\mathbf{RKGen}(\mathtt{msk},\rho )\to d{k}_{\rho }$: Given the receiver’s identity $\rho$, and the master secret key $\mathtt{msk}$, the algorithm will output the decryption key $d{k}_{\rho }$.
• $\mathbf{Enc}(\mathtt{mpk},e{k}_{\sigma },\mathtt{rcv},m)\to c$: Given the target receiver’s identity $\mathtt{rcv}$, the master public key $\mathtt{mpk}$, the encryption key $e{k}_{\sigma }$, and the message $m\in {\{0,1\}}^n$, and the algorithm will output the ciphertext c, associated to both $\sigma$ and $\mathtt{rcv}$.
• $\mathbf{Dec}(\mathtt{mpk},d{k}_{\rho },\mathtt{snd},c)\to m$ or ⊥: Given the target sender’s identity $\mathtt{snd}$, the master public key $\mathtt{mpk}$, the decryption key $d{k}_{\rho }$, and the ciphertext c, the algorithm will compute and output either the message m or ⊥.

The message will be correctly recovered from the decryption algorithm if $\rho =\mathtt{rcv}$ and $\sigma =\mathtt{snd}$.

3. Definition and System Model

In this section, we formally define the system model of IBME-DS. Furthermore, we describe the potential threats to IBME-DS and formally define the security model and the design goal of our proposed scheme.

3.1. System Model

To clarify the system architecture of IBME-DS, we describe the system model in this section. There are four entities involved in our scheme, including key generation center (KGC), cloud server (CS), sender and receiver, as shown in Figure 2. The CS is responsible for storing and managing the data, sent from users (i.e., sender and receiver), who are registered in KGC. Once the senders and receivers have been registered in KGC, both of them will be distributed a pair of keys for the further communications.

• Key Generation Center: KGC is defined as the fully trusted party in the system, to initialize system parameters and generate master public/secret keys for users. By taking the identity from users as input, it secretly outputs the encryption key and decryption key to senders and receivers via the secure channel.
• Cloud Server: CS receives the information from users and performs matching. Then, it returns the successful matching results to the receiver.
• Sender: The sender has his/her own unique identity $\sigma$. Through the identity $\sigma$, the sender can be uniquely designated. In particular, the sender can specify the target receiver in the ciphertext. The sender’s identity will not be revealed even if the match fails.
• Receiver: The receiver also has his/her own unique identity $\rho$. Similarly, the receiver can also specify the target sender.

We formally define IBME-DS, which consists of seven algorithms, as follows:

• $\mathbf{Setup}\left(1^{\lambda }\right)\to (\mathtt{mpk},\mathtt{msk})$: Given the security parameter $1^{\lambda }$, the probabilistic algorithm will output the master public/secret key $\{\mathtt{mpk},\mathtt{msk}\}$.
• $\mathbf{SKGen}(\mathtt{msk},\sigma )\to e{k}_{\sigma }$: Given the sender’s identity $\sigma$ and the master secret key $\mathtt{msk}$, the probabilistic algorithm will output the encryption key $e{k}_{\sigma }$.
• $\mathbf{RKGen}(\mathtt{msk},\rho )\to d{k}_{\rho }$: Given the receiver’s identity $\rho$ and the master secret key $\mathtt{msk}$, the probabilistic algorithm will output the decryption key $d{k}_{\rho }$.
• $\mathbf{Enc}(\mathtt{mpk},e{k}_{\sigma },{\rho }_r,m)\to C$: Given the target receiver’s identity ${\rho }_r$, the master public key $\mathtt{mpk}$, the encryption key $e{k}_{\sigma }$, and the message $m\in {\{0,1\}}^n$, the probabilistic algorithm will output the ciphertext C.
• $\mathbf{MatchTag}(\mathtt{mpk},{\sigma }_s)\to Tag$: Given the target sender’s identity ${\sigma }_s$, the master public key $\mathtt{mpk}$, the probabilistic algorithm will output the match tag $Tag$.
• $\mathbf{Match}(\mathtt{mpk},C,Tag)\to$“accepted” or “failed”: Given the master public key $\mathtt{mpk}$, the ciphertext C, and the match tag $Tag$, the deterministic algorithm will output “accepted”, if the match occurs. Otherwise, “failed”.
• $\mathbf{Dec}(\mathtt{mpk},d{k}_{\rho },{\sigma }_s,C)\to m$: Given the target sender’s identity ${\sigma }_s$, the master public key $\mathtt{mpk}$, the decryption key $d{k}_{\rho }$, and the ciphertext C, the deterministic algorithm will recover the message m, if $\rho ={\rho }_r$ and $\sigma ={\sigma }_s$.

3.2. Threat Model

KGC is fully trusted and is responsible for generating master public/secret keys and secretly distributing encryption/decryption keys via the secure channel. In our system, CS is considered to be HBC as a semi-trusted party. CS will return correct results to users, but keep curious about users’ data. Moreover, both senders and receivers are considered to be untrusted. The sender may pretend to be another sender to generate the ciphertext. The receiver may try to access the unauthorized data. Specifically, we summarize the threat model of IBME-DS as follows:

Type I Adversary: The Type I adversary is the HBC cloud server, which receives the ciphertext message from the sender and the match tag from the receiver. Then, it completes the matching operation based on the received information. In this process, the Type I adversary will launch the ciphertext-only attack to spy on the user’s data, designing an access policy.

Type II Adversary: The Type II adversary is the malicious user (sender and receiver), who possesses the encryption key. The malicious users initiate the chosen ciphertext attack to get others’ data and the access policy.

3.3. Security Model

Definition 2.

Our proposed IBME-DS is said to be IND-CPA secure if it can resist the probabilistic polynomial-time (PPT) adversary by a game, as follows:

• Setup: The system is established with the input security parameter. Then, the challenger sets the master public/secret key $\{\mathtt{mpk},\mathtt{msk}\}$.
• Hash Query: The adversary requests the hash oracle to get the corresponding hash values for polynomial times.
• KeyGen Query: The adversary requests the key generation oracle ${\mathcal{O}}_{\mathbf{SKGen}}(\mathtt{msk},·)$ and ${\mathcal{O}}_{\mathbf{RKGen}}(\mathtt{msk},·)$ for polynomial times to obtain the corresponding ${ek}_i,{dk}_j$, respectively.
• Challenge: The adversary claims $m_0,m_1$ to be challenged, and provides two instances $I_0=(m_0,{\rho }_{r,0},{\sigma }_0)$ and $I_1=(m_1,{\rho }_{r,1},{\sigma }_1)$. Then, the challenger chooses $b\in \{0,1\}$ randomly. By running $\mathbf{Enc}$ algorithm, the challenger can compute $C^{*}=\mathbf{Enc}({ek}_{{\sigma }_b},{\rho }_{r,b},m_b)$. Finally, $C^{*}$ will be sent to the adversary.
• Guess: After receiving $C^{*}$ from the challenger, the adversary outputs a guess $b^{\prime }$ on b.

If the adversary can give a correct guess on b, that $b^{\prime }=b$, we say the adversary can break our proposed IBME-DS. We define the advantage of the adversary breaking the security of IBME-DS as Equation (1):

$${\mathrm{Adv}}_{\mathcal{A},\mathrm{IBME}-\mathrm{DS}}^{\mathrm{IND}-\mathrm{CPA}}=\left|Pr\left[{\mathrm{b}}^{\prime }=\mathrm{b}\right]-\frac{1}{2}\right|\le ϵ.$$

(1)

Definition 3.

Our proposed IBME-DS holds authenticity if it can resist the PPT adversary by a game, as follows.

• Setup: The system is established with the input security parameter. Then, the challenger sets the master public/secret key $\{\mathtt{mpk},\mathtt{msk}\}$.
• Hash Query: The adversary requests the hash oracle to get the corresponding hash values for polynomial times.
• SKGen Query: The adversary requests the SKGen oracle by inputting ${\sigma }_i$, the challenger returns the sender’s encryption key.
• RKGen Query: The adversary requests the RKGen oracle by inputting ${\varphi }_i$, the challenger returns the receiver’s decryption key.
• Forgery: The adversary sends the tuple $(C,\rho ,{\sigma }^{\prime })$ to the challenger, in which ${\sigma }^{\prime }$ has never been input to the SKGen oracle. The challenger generates $d{k}_{\rho }$ by executing the $\mathbf{RKGen}$ algorithm. Then, the challenger computes the message m from the ciphertext C by executing the $\mathbf{Dec}$ algorithm.

If the above game holds, i.e., the message m belongs to the message space M, we say that the adversary can break the authenticity of our proposed IBME-DS. Specifically, the adversary can forge the valid ciphertext even if it is not authorized. We define the advantage of the adversary breaking the authenticity of IBME-DS as Equation (2):

$${\mathrm{Adv}}_{\mathcal{A},\mathrm{IBME}-\mathrm{DS}}^{\mathrm{Authenticity}}=Pr\left[\mathrm{m}=\mathrm{Dec}\left(\mathrm{C}\right)|\mathrm{m}\in \mathrm{M}\right]\le ϵ.$$

(2)

3.4. Design Goal

According to the system model, threat model and security definition defined for our proposed IB-ME-based data sharing scheme, we summarize the design goals to clarify the vital features of our proposed scheme.

• Security. The security is to ensure the system is with semantic security under the attack launched by any PPT adversary. The security is the basic demand of the data-sharing scheme in cloud services, which ensures the message m is unknown to others.
• Privacy. The privacy is aimed at preventing the stored data and access policy from being revealed to the cloud, even in the matching phase.
• Authenticity. The authenticity means that a valid ciphertext under identity $\sigma$ can only be generated by a valid encryption key ${ek}_{\sigma }$ from KGC. In other words, it guarantees that if a sender with the proper identity can produce a ciphertext, the ciphertext can be decrypted correctly.
• Bilateral Access Control. The bilateral access control ensures that the access policy is designed by both the sender and receiver. Compared to the existing access control scheme, of which the policy is only designed by one side, bilateral access control is a practical requirement for data sharing to cloud services.

4. Concrete Construction

We will describe our proposed IBME-DS, derived from IB-ME. The notations used in IBME-DS are listed in

Table 1. Notations.

Notation	Description
e	bilinear map
$\mathbb{G},{\mathbb{G}}_T$	bilinear groups
p	large prime
g	random number $g\in \mathbb{G}$
$H_1,H_2$	hash functions
$\mathsf{\Phi }$	padding function
n	the length of message
$\mathtt{msk}$	master secret key
$\mathtt{mpk}$	master public key
$\sigma$	sender’s identity
$\rho$	receiver’s identity
${\rho }_r$	target receiver’s identity
$e{k}_{\sigma }$	sender’s encryption key
$d{k}_{\rho }$	receiver’s decryption key
m	message
C	ciphertext

. Then, we will give a workflow of our proposed IBME-DS, and a concrete construction based on bilinear groups.

4.1. Workflow of IBME-DS

IBME-DS can provide a privacy-preserving data-sharing solution for end devices. The workflow of our scheme includes four phases: system initialization, data updating,  user matching and data downloading, as shown in Figure 3.

System Initialization: By running $\mathbf{Setup}$, KGC is to generate system parameters. Also, KGC generates encryption/decryption keys for users through $\mathbf{SKGen}$ and $\mathbf{RKGen}$.

Data Upload: The sender runs $\mathbf{Enc}$ to generate the ciphertext. After that, the sender uploads the ciphertext to CS.

User Matching: Firstly, the receiver will generate the match tag by running $\mathbf{MatchTag}$ to specify the target sender. The match tag will be sent to CS. After that, CS runs $\mathbf{Match}$ to find the matched ciphertext, then sends the matched ciphertext to the receiver. During the matching process, CS will get nothing except whether the match occurs.

Data Download: If the matching occurs, the receiver runs $\mathbf{Dec}$ to decrypt the ciphertext.

4.2. IB-ME-Based Data-Sharing Scheme

The detailed construction of our proposed IBME-DS is described as the following Algorithms 1–6.

• Setup$\left(1^{\lambda }\right)$: The system runs this probabilistic algorithm. Taking in the security parameter $1^{\lambda }$, the system sets $(p,\mathbb{G},{\mathbb{G}}_T,g,\widehat{g},e)$, where $e:\mathbb{G}\times \mathbb{G}\to {\mathbb{G}}_T$. Then, it selects two hash functions as $H_1:{\{0,1\}}^{*}\to \mathbb{G}$, and $H_2:{\mathbb{G}}_T\to {\{0,1\}}^l$, and a padding function $\mathsf{\Phi }:{\{0,1\}}^n\to {\{0,1\}}^l$, where $\mathsf{\Phi }$ is efficiently invertible. Additionally, the system chooses four random numbers $\alpha ,\beta ,u,t\leftarrow {\mathbb{Z}}_p$ and sets $g_{\alpha }=g^{\alpha },g_{\beta }=g^{\beta },g_u=g^u,\widehat{g_{\alpha }}=g^{\alpha ·u}$, and $g_t=g^t$. The system publishes the master public key $\mathtt{mpk}=(e,\mathbb{G},{\mathbb{G}}_T,g,g_{\alpha },g_{\beta },\widehat{g_{\alpha }},g_u,g_t)$. The master secret key $\mathtt{msk}=(\alpha ,\beta ,u,t)$ keeps secretly.
• $\mathbf{SKGen}(\mathtt{msk},\sigma )$: KGC runs this probabilistic algorithm. Taking in the sender’s identity $\sigma$, and the master secret key $\mathtt{msk}$, KGC computes the encryption key $e{k}_{\sigma }=H_1{\left(\sigma \right)}^{\beta }$. Then, KGC sends $e{k}_{\sigma }$ to the sender with the identity $\sigma$.

  Algorithm 1 SKGen$(\mathtt{msk},\sigma )$

  Input: the sender’s identity $\sigma$, the master secret key $\mathtt{msk}$. Output: the sender’s encryption key $e{k}_{\sigma }$. Compute $e{k}_{\sigma }=H_1{\left(\sigma \right)}^{\beta }$. return the sender’s encryption key $e{k}_{\sigma }$

• $\mathbf{RKGen}(\mathtt{msk},\rho )$: KGC runs this probabilistic algorithm. Taking in the receiver’s identity $\rho$, and the master secret key $\mathtt{msk}$, KGC computes the decryption key $d{k}_{\rho }=(d{k}_{\rho ,1},d{k}_{\rho ,2},d{k}_{\rho ,3})$, as Equation (3):

  $$\begin{array}{cc}\hfill d{k}_{\rho ,1}& =H_1{\left(\rho \right)}^{\alpha },\hfill \\ \hfill d{k}_{\rho ,2}& =H_1{\left(\rho \right)}^{\beta },\hfill \\ \hfill d{k}_{\rho ,3}& =H_1\left(\rho \right).\hfill \end{array}$$

  (3)

  Then, KGC sends $d{k}_{\rho }$ to the receiver with the identity $\rho$.

  Algorithm 2 RKGen$(\mathtt{msk},\rho )$

  Input: the receiver’s identity $\rho$, the master secret key $\mathtt{msk}$. Output: the receiver’s decryption key $d{k}_{\rho }$. Compute $d{k}_{\rho ,1}=H_1{\left(\rho \right)}^{\alpha },d{k}_{\rho ,2}=H_1{\left(\rho \right)}^{\beta },d{k}_{\rho ,3}=H_1\left(\rho \right)$. return the receiver’s decryption key $d{k}_{\rho }\leftarrow (d{k}_{\rho ,1},d{k}_{\rho ,2},d{k}_{\rho ,3})$.

• $\mathbf{Enc}(\mathtt{mpk},e{k}_{\sigma },{\rho }_r,m)$: The sender runs this probabilistic algorithm. Taking in the target receiver’s identity ${\rho }_r$, the master public key $\mathtt{mpk}$, the sender’s encryption key $e{k}_{\sigma }$, and the message $m\in {\{0,1\}}^n$, the sender conducts as the following steps:

  1.

  Select $r_1,r_2,x_1\in {\mathbb{Z}}_p$.

  2.

  Compute $R_1=g^{r_1},R_2=g^{r_2}$.

  3.

  Compute $T=g_t^{x_1}$.

  4.

  Compute Equation (4)

  $$\begin{array}{cc}\hfill k_1& =e(H_1\left({\rho }_r\right),\widehat{g_{\alpha }}),\hfill \\ \hfill k_2& =e(H_1\left({\rho }_r\right),g_t·e{k}_{\sigma }),\hfill \\ \hfill {\sigma }^{\prime }& =H_1{\left(\sigma \right)}^{x_1},\hfill \\ \hfill {\rho }^{\prime }& =H_1{\left({\rho }_r\right)}^{x_1}.\hfill \end{array}$$

  (4)

  5.

  Compute $V=\mathsf{\Phi }\left(m\right)\oplus H_2(k_1·e(H_1{\left(\sigma \right)}^{r_1},g^{x_1}))\oplus H_2(k_2·e(H_1{\left({\rho }_r\right)}^{r_2},g^{x_1})).$

  6.

  Output ciphertext $C=(R_1,R_2,T,{\sigma }^{\prime },{\rho }^{\prime },V)$.

  Algorithm 3 Enc$(\mathtt{mpk},e{k}_{\sigma },{\rho }_r,m)$

  Input: the target receiver’s identity ${\rho }_r$, the master public key $\mathtt{mpk}$, the sender’s encryption key $e{k}_{\sigma }$, and the message m. Output: ciphertext C. Select random numbers $r_1,r_2,x_1\in {\mathbb{Z}}_p$. Compute $R_1=g^{r_1},R_2=g^{r_2}$. Compute $T=g_t^{x_1}$. Compute $$k_1=e(H_1\left({\rho }_r\right),\widehat{g_{\alpha }}),$$ $$k_2=e(H_1\left({\rho }_r\right),g_t·e{k}_{\sigma }),$$ $${\sigma }^{\prime }=H_1{\left(\sigma \right)}^{x_1},$$ $${\rho }^{\prime }=H_1{\left({\rho }_r\right)}^{x_1}.$$ Compute $V=\mathsf{\Phi }\left(m\right)\oplus H_2(k_1·e(H_1{\left(\sigma \right)}^{r_1},g^{x_1}))\oplus H_2(k_2·e(H_1{\left({\rho }_r\right)}^{r_2},g^{x_1}))$. return ciphertext $C\leftarrow (R_1,R_2,T,{\sigma }^{\prime },{\rho }^{\prime },V)$.

• $\mathbf{MatchTag}(\mathtt{mpk},{\sigma }_s)$: The receiver runs this probabilistic algorithm. Taking in the target sender’s identity ${\sigma }_s$, the master public key $\mathtt{mpk}$, the receiver computes the auxiliary information as the match tag when the matching is delegated to the CS. The receiver chooses randomly $x_2\leftarrow {\mathbb{Z}}_p$. It computes Equation (5) as follows:

  $$\begin{array}{cc}\hfill I{D}_r^{\prime }& =(I{D}_{r,1}^{\prime },I{D}_{r,2}^{\prime },I{D}_{r,3}^{\prime }),\hfill \\ \hfill {{\sigma }_s}^{\prime }& =H_1{\left({\sigma }_s\right)}^{x_2}·g_t^{x_2}.\hfill \end{array}$$

  (5)

  The detailed computations on $I{D}_r^{\prime }$ are as Equation (6):

  $$\begin{array}{cc}\hfill I{D}_{r,1}^{\prime }& =d{k}_{{\rho }_{r,1}}^{x_2},\hfill \\ \hfill I{D}_{r,2}^{\prime }& =d{k}_{{\rho }_{r,2}}^{x_2},\hfill \\ \hfill I{D}_{r,3}^{\prime }& =d{k}_{{\rho }_{r,3}}^{x_2}.\hfill \end{array}$$

  (6)

  The receiver sends $Tag=(I{D}_r^{\prime },{{\sigma }_s}^{\prime })$ to the CS.

  Algorithm 4 MatchTag$(\mathtt{mpk},{\sigma }_s)$

  Input: the target sender’s identity ${\sigma }_s$, the master public key $\mathtt{mpk}$. Output: the match tag $Tag$. Choose randomly $x_2\leftarrow {\mathbb{Z}}_p$. Let $I{D}_r^{\prime }=(I{D}_{r,1}^{\prime },I{D}_{r,2}^{\prime },I{D}_{r,3}^{\prime })$. Compute $$I{D}_{r,1}^{\prime }=d{k}_{{\rho }_{r,1}}^{x_2},$$ $$I{D}_{r,2}^{\prime }=d{k}_{{\rho }_{r,2}}^{x_2},$$ $$I{D}_{r,3}^{\prime }=d{k}_{{\rho }_{r,3}}^{x_2};$$ Compute ${{\sigma }_s}^{\prime }=H_1{\left({\sigma }_s\right)}^{x_2}·g_t^{x_2}$. return the match tag $Tag\leftarrow (I{D}_r^{\prime },{{\sigma }_s}^{\prime })$.

• $\mathbf{Match}(\mathtt{mpk},C,Tag)$: CS runs this deterministic algorithm. Taking in the master public key $\mathtt{mpk}$, the ciphertext C, and the match tag $Tag$, CS executes check Equation (7)

  $$\begin{array}{cc}\hfill e({\rho }^{\prime },{{\sigma }_s}^{\prime })& \stackrel{?}{=}e(I{D}_{r,3}^{\prime },{\sigma }^{\prime }·T).\hfill \end{array}$$

  (7)

  If the equation holds, CS outputs “accepted”, to indicate the match occurs. Otherwise, “failed”.

  Algorithm 5 Match$(\mathtt{mpk},C,Tag)$

• $\mathbf{Dec}(\mathtt{mpk},d{k}_{\rho },{\sigma }_s,C)$: The receiver runs this deterministic algorithm. Taking in the target sender’s identity ${\sigma }_s$, master public key $\mathtt{mpk}$, the decryption key $d{k}_{\rho }$, and the ciphertext C, the receiver conducts the following operations:

  1.

  Parse C as $(R_1,R_2,T,{\sigma }^{\prime },{\rho }^{\prime },V)$.

  2.

  Compute

  $$\begin{array}{cc}\hfill k_1^{\prime }& =e(d{k}_{\rho ,1},g_u),\hfill \\ \hfill k_2^{\prime }& =e(d{k}_{\rho ,2},H_1\left({\sigma }_s\right))·e(d{k}_{\rho ,3},g_t).\hfill \end{array}$$

  3.

  Compute $\mathsf{\Phi }\left(m\right)=V\oplus H_2(k_1^{\prime }·e(R_1,{\sigma }^{\prime }))\oplus H_2(k_2^{\prime }·e(R_2,{\rho }^{\prime }))$.

  4.

  Recover the message m by the reversibility of $\varphi \left(m\right)$.

  Algorithm 6 Dec$(\mathtt{mpk},d{k}_{\rho },{\sigma }_s,C)$

  Input: the target sender’s identity ${\sigma }_s$, the master public key $\mathtt{mpk}$, the decryption key $d{k}_{\rho }$, and the ciphertext C. Output: the message m. Parse C as $(R_1,R_2,T,{\sigma }^{\prime },{\rho }^{\prime },V)$; Compute $$\begin{array}{cc}\hfill k_1^{\prime }& =e(d{k}_{\rho ,1},g_u),\hfill \\ \hfill k_2^{\prime }& =e(d{k}_{\rho ,2},H_1\left({\sigma }_s\right))·e(d{k}_{\rho ,3},g_t).\hfill \end{array}$$ Compute $\mathsf{\Phi }\left(m\right)=V\oplus H_2(k_1^{\prime }·e(R_1,{\sigma }^{\prime }))\oplus H_2(k_2^{\prime }·e(R_2,{\rho }^{\prime }))$. return the message $m\leftarrow \varphi \left(m\right)$.

Correctness. We demonstrate the correctness of IBME-DS from Equations (8)–(10):

$$\begin{array}{cc}\hfill k_1& =e(H_1\left({\rho }_r\right),\widehat{g_{\alpha }})=e(H_1\left({\rho }_r\right),g^{u\alpha }),\hfill \\ \hfill k_1^{\prime }& =e(d{k}_{\rho ,1},g_u)=e(H_1{\left(\rho \right)}^{\alpha },g^u).\hfill \end{array}$$

(8)

The above equations clearly show that $k_1=k_1^{\prime }$ if ${\rho }_r=\rho$. Then, similarly, we can check $k_2=k_2^{\prime }$, if ${\rho }_r=\rho$ and ${\sigma }_s=\sigma$.

$$\begin{array}{cc}\hfill k_2& =e(H_1\left({\rho }_r\right),g_t·e{k}_{\sigma })\hfill \\ \hfill & =e(H_1\left({\rho }_r\right),g_t)·e(H_1\left({\rho }_r\right),e{k}_{\sigma })\hfill \\ \hfill & =e{(H_1\left({\rho }_r\right),g)}^t·e{(H_1\left({\rho }_r\right),H_1\left(\sigma \right))}^{\beta },\hfill \\ \hfill k_2^{\prime }& =e(d{k}_{\rho ,2},H_1\left({\sigma }_s\right))·e(d{k}_{\rho ,3},g_t)\hfill \\ \hfill & =e(H_1{\left(\rho \right)}^{\beta },H_1\left({\sigma }_s\right))·e{(H_1\left(\rho \right),g)}^t.\hfill \end{array}$$

To successfully recover the message, Equations (9) and (10) should hold.

$$H_2(k_1·e(H_1{\left(\sigma \right)}^{r_1},g^{x_1}))=H_2(k_1^{\prime }·e(R_1,{\sigma }^{\prime })),$$

(9)

$$H_2(k_2·e(H_1{\left({\rho }_r\right)}^{r_2},g^{x_1}))=H_2(k_2^{\prime }·e(R_2,{\rho }^{\prime }))$$

(10)

As we proved before, $k_1=k_1^{\prime }$ and $k_2=k_2^{\prime }$. We have to ensure $e(H_1{\left(\sigma \right)}^{r_1},g^{x_1})=e(R_1,{\sigma }^{\prime })$ and $e(H_1{\left({\rho }_r\right)}^{r_2},g^{x_1})=e(R_2,{\rho }^{\prime })$. Therefore, if ${\sigma }^{\prime }=H_1{\left(\sigma \right)}^{x_1}$ and ${\rho }^{\prime }=H_1{\left(\rho \right)}^{x_1}$, the decryption is successful and the message will be recovered correctly.

5. Security Analysis

Theorem 1.

If the underlying IB-ME is IND-CPA secure, our proposed IBME-DS is secure.

Proof. 

Assume that a PPT adversary $\mathcal{A}$ can break IBME-DS, a simulator $\mathcal{B}$ can use $\mathcal{A}$ to break the underlying IB-ME.

Setup: Choose random values $\alpha ,\beta ,u,t\in {\mathbb{Z}}_p$ and set $g_{\alpha }=g^{\alpha },g_{\beta }=g^{\beta },g_u=g^u,\widehat{g_{\alpha }}=g^{\alpha ·u}$, and $g_t=g^t$. The master secret key is $\mathtt{msk}=(\alpha ,\beta ,u,t)$ and the master public key is the tuple $\mathtt{mpk}=(p,\mathbb{G},{\mathbb{G}}_T,e,g,g_{\alpha },g_{\beta },\widehat{g_{\alpha }},g_u,g_t,H_1,H_2)$. Then, the $\mathtt{mpk}$ is sent to $\mathcal{B}$. $\mathcal{B}$ selects a random value $\beta \in {\mathbb{Z}}_p$. Then, $\mathcal{B}$ sends system parameters $(p,\mathbb{G},{\mathbb{G}}_T,e,g,g_{\alpha },\widehat{g_{\alpha }},g_u,g_t,H_1,H_2)$ to $\mathcal{A}$. And the padding function $\mathsf{\Phi }$ is under control.

${\mathbf{H}}_{\mathbf{1}}$ Queries: $\mathcal{B}$ performs the hash queries on $H_1$ to construct hash table list ${\mathcal{L}}_1$:

1.

If query ${\rho }_i$ has been requested before, that the query can be found in $({\rho }_i,Q_i,{\gamma }_i,d_i)\in {\mathcal{L}}_1$, $\mathcal{B}$ returns $Q_i$. Otherwise, $\mathcal{B}$ generates a coin $d_i$, $Pr[d_i=0]=\delta$.

2.

If $d_i=0$, $\mathcal{B}$ chooses ${\gamma }_i\in {\mathbb{Z}}_p$ and computes $Q_i=g^{{\gamma }_i}$. Then, add $({\rho }_i,Q_i,{\gamma }_i,0)$ to ${\mathcal{L}}_1$. Otherwise, $\mathcal{B}$ sets $Q_i=g^{x{\gamma }_i}$, and adds $({\rho }_i,Q_i,\perp ,1)$ to ${\mathcal{L}}_1$, where x is unknown to $\mathcal{B}$.

3.

Return $Q_i$.

${\mathbf{H}}_{\mathbf{2}}$ Queries: $\mathcal{B}$ performs the hash queries on $H_2$. The hash list ${\mathcal{L}}_2=\{re{s}_i,Z_i\}$ is constructed by $\mathcal{B}$. If $re{s}_i$ was already queried, $\mathcal{B}$ returns the value $Z_i$. Otherwise, $\mathcal{B}$ chooses $Z_i\in {\{0,1\}}^l$. Then, it adds $\{re{s}_i,Z_i\}$ to ${\mathcal{L}}_2$. Finally, $\mathcal{B}$ returns $Z_i$ to $\mathcal{A}$.

KeyGen Queries: Upon ${\sigma }_i$ being the input, $\mathcal{B}$ obtains $H_1\left({\sigma }_i\right)=Q_i$ by $({\sigma }_i,Q_i)$ from ${\mathcal{L}}_1$, and returns ${\left(Q_i\right)}^{\beta }$. Upon ${\rho }_i$ being the input, $\mathcal{B}$ obtains $H\left({\rho }_i\right)=Q_i$ from ${\mathcal{L}}_1$. If $d_i=0$, $\mathcal{B}$ returns $d{k}_{{\rho }_i}=({Q_i}^{\alpha },{Q_i}^{\beta },Q_i)$. Otherwise, $\mathcal{B}$ terminates the game.

Challenge: $\mathcal{A}$ sends $(m_0,m_1,{\rho }_{r,0},{\rho }_{r,1},{\sigma }_0,{\sigma }_1)$ to $\mathcal{B}$, where ${\rho }_{r,0}={\rho }_0$, ${\rho }_{r,1}={\rho }_1$. Then $\mathcal{B}$ performs as follows:

1.

$\mathcal{A}$ queries $H_1\left({\rho }_0\right)=Q_0$ and $H_1\left({\rho }_1\right)=Q_1$. Let $d_0=1$ and $d_1=1$, it means that $Q_i=g^{x{\gamma }_i}$.

2.

$\mathcal{B}$ selects a random $r_1,r_2,x_1\in {\mathbb{Z}}_p$.

3.

$\mathcal{B}$ sends $C^{*}=(R_1,R_2,T,{\sigma }^{\prime },{\rho }^{\prime },V)$ to $\mathcal{A}$.

Guess: $\mathcal{A}$ outputs a $b^{\prime }$ as a guess on b.

If $b^{\prime }=b$ holds, we say that $\mathcal{A}$ breaks the security of our proposed scheme. Then, $\mathcal{B}$ can make use of the result from $\mathcal{A}$ to break the underlying IB-ME. $re{s}_i/e(H_1{\left(\sigma \right)}^{r_1},g^{x_1})$ and $re{s}_i/e(H_1{\left({\rho }_r\right)}^{r_2},g^{x_1})$ are used in IB-ME. If $\mathcal{A}$ can tell $C^{*}$ is computed from $m_0,m_1$, $\mathcal{A}$ also can tell that in IB-ME with the same advantage.

Moreover, in MatchTag and Match, $\{I{D}^{\prime },{{\sigma }_s}^{\prime }\}$ are computed with a randomness $x_2$. From the view of $\mathcal{A}$, the distribution of these elements is indistinguishable from the random elements. If $\mathcal{A}$ can tell the difference, then $\mathcal{A}$ can solve the discrete logarithm problem. □

Theorem 2.

Our proposed IBME-DS holds authenticity, if the bilinear Diffie–Hellman (BDH) problem is hard.

Proof. 

Suppose that a PPT adversary $\mathcal{A}$ breaks the authenticity of IBME-DS, a simulator $\mathcal{B}$ is able to use $\mathcal{A}$ to break BDH problem with non-negligible advantage. Receiving the challenge $(g,g^a,g^b,g^c)$, $\mathcal{B}$ computes $D=e{(g,g)}^{abc}$.

Setup: $\mathcal{B}$ sends the public system parameters $(p,\mathbb{G},{\mathbb{G}}_T,e,g,g_{\alpha },\widehat{g_{\alpha }},g_u,g_t,H_1,H_2)$ to $\mathcal{A}$, where two hash functions $H_1$ and $H_2$ are under control.

${\mathbf{H}}_{\mathbf{1}}$ Queries: $\mathcal{B}$ performs the hash queries on $H_1$ to construct hash table list ${\mathcal{L}}_1$:

1.

If query ${\rho }_i$ has been requested before, that the query can be found in $({\rho }_i,Q_i,{\gamma }_i,d_i)\in {\mathcal{L}}_1$, $\mathcal{B}$ returns $Q_i$. Otherwise, $\mathcal{B}$ generates a coin $d_i$ randomly, $Pr[d_i=0]=\delta$.

2.

If $d_i=0$, $\mathcal{B}$ randomly selects ${\gamma }_i\in {\mathbb{Z}}_p$ and computes $Q_i=g^{{\gamma }_i}$. Otherwise, $\mathcal{B}$ computes $Q_i=g^{c{\gamma }_i}$. Then, add $({\rho }_i,Q_i,{\gamma }_i,d_i)$ to ${\mathcal{L}}_1$.

3.

Finally, send $Q_i$ to $\mathcal{A}$.

${\mathbf{H}}_{\mathbf{1}}$ Queries: $\mathcal{B}$ performs the hash queries on $H_1$ to construct the hash table list ${\mathcal{L}}_2$:

1.

If query ${\sigma }_i$ has been requested before, then the query can be found in $({\sigma }_i,Q_i,{\gamma }_i,d_i)\in {\mathcal{L}}_2$, $\mathcal{B}$ returns $Q_i$. Otherwise, $\mathcal{B}$ generates a coin $d_i$ randomly, $Pr[d_i=0]=\delta$.

2.

If $d_i=0$, $\mathcal{B}$ randomly selects ${\gamma }_i\in {\mathbb{Z}}_p$ and computes $Q_i=g^{{\gamma }_i}$. Otherwise, $\mathcal{B}$ computes $Q_i=g^{a{\gamma }_i}$. Then, add $({\rho }_i,Q_i,{\gamma }_i,d_i)$ to ${\mathcal{L}}_2$.

3.

Finally, send $Q_i$ to $\mathcal{A}$.

${\mathbf{H}}_{\mathbf{2}}$ Queries: $\mathcal{B}$ performs the hash queries on $H_2$. The hash list ${\mathcal{L}}_3=\{X_i,h_i\}$ is constructed by $\mathcal{B}$. If $X_i$ was already queried, $\mathcal{B}$ returns the value $h_i$. Otherwise, $\mathcal{B}$ randomly chooses $h_i\in {\{0,1\}}^l$. Then, it adds $\{X_i,h_i\}$ to ${\mathcal{L}}_2$. Finally, $\mathcal{B}$ returns $h_i$ to $\mathcal{A}$.

SKGen Queries: Input ${\sigma }_i$, $\mathcal{B}$ obtains $H_1\left({\sigma }_i\right)=Q_i$ by $({\sigma }_i,Q_i)$ from ${\mathcal{L}}_2$. If $d_i=0$, $\mathcal{B}$ returns $\left(e{k}_{{\sigma }_i}\right)=g^{b{\gamma }_i}$; otherwise, $\mathcal{B}$ aborts.

RKGen Queries: Input ${\rho }_i$, $\mathcal{B}$ obtains $H_1\left({\rho }_i\right)=Q_i$ by $({\rho }_i,Q_i)$ from ${\mathcal{L}}_1$. If $d_i=0$, $\mathcal{B}$ returns $\left(d{k}_{{\rho }_i}\right)=(g^{a{\gamma }_i},g^{b{\gamma }_i},Q_i=g^{{\gamma }_i})$; otherwise, $\mathcal{B}$ aborts.

Forgery: $\mathcal{A}$ sends the tuple $(C,\rho ,{\sigma }^{\prime })$ to $\mathcal{B}$. Let ${\sigma }^{\prime }=\sigma$, $\mathcal{B}$ performs as follows:

1.

$\mathcal{B}$ queries $H_1\left(\rho \right)=Q_0$ and $H_1\left(\sigma \right)=Q_1$.

2.

If both the tuples $(\rho ,Q_0,{\gamma }_0,d_0)\in {\mathcal{L}}_1$ and $(\sigma ,Q_1,{\gamma }_1,d_1)\in {\mathcal{L}}_2$ without $d_0=1$ and $d_1=1$, $\mathcal{B}$ aborts. If not, $d{k}_{\rho ,2}=g^{cb{\gamma }_0}$, $H\left(\sigma \right)=g^{a{\gamma }_1}$, $H_2(k_2^{\prime }·e(R_2,\rho ))=H_2(e(d{k}_{\rho ,2},H_1\left(\sigma \right))e(d{k}_{{\rho }_3},g_t),e(R_2,\rho ))$, where $e(d{k}_{\rho ,2},H_1\left(\sigma \right))=e(g^{cb{\gamma }_0},g^{a{\gamma }_1})=D^{{\gamma }_0{\gamma }_1}$, and $Q_0=d{k}_{\rho ,3}$.

3.

$\mathcal{B}$ parses C as $(R_1,R_2,T,V)$, computes $z=1/\left({\gamma }_0{\gamma }_1\right)$ and selects a random tuple $(X_i,h_i)$.

4.

Return $D^{\prime }={(X_i·e{(Q_0,g_t)}^{-1}·e{(R_2,\rho )}^{-1})}^z$.

If the above simulation holds, we say that $\mathcal{A}$ breaks the authenticity of our proposed scheme. $\mathcal{A}$ can forge the valid ciphertext even if it is not authorized, as it can solve the BDH problem.

Next, we assume that the adversary makes $q_R$ and $q_S$ queries to oracle SKGen and RKGen, and analyze the advantage that $\mathcal{B}$ outputs the solution to the BDH assumption. By the above proof, the probability that $\mathcal{B}$ does not abort for any of these calls is ${\delta }^{q_R+q_S}$ and the probability that $\mathcal{B}$ does not abort in the forgery phase is ${(1-\delta )}^2$. Thus, the total probability that $\mathcal{B}$ does not abort is ${\delta }^{q_R+q_S}{(1-\delta )}^2$ and will get the maximum value when $\delta =(q_R+q_S)/(q_R+q_S+2)$ which is $4/e^2{(q_R+q_S+2)}^2$. If $\mathcal{B}$ does not abort, it outputs the correct solution $D^{\prime }$ with a probability at least $2ϵ/q_{H_2}$. Hence, $\mathcal{B}$ can solve the BDH problem with advantage $8ϵ/e^2{(q_R+q_S+2)}^2{q}_{H_2}$. □

Theorem 3.

Our proposed IBME-DS holds privacy preservation, if the DL problem is hard.

Proof. 

The privacy preservation of IBME-DS lies in the fact that no one can obtain any private information (i.e., the outsourced data and access policy) from the communication by intercepting or making any unauthorized modifications.

From the data privacy aspect, IBME-DS encrypts the data using the user’s secret encryption key. According to the security of IBME-DS, the encrypted data is a string of random characters from the view of the adversary. Therefore, any PPT adversary cannot get the data contained in the system.

From the aspect of the sender’s identity and access policy, even though receivers can specify the sender $\sigma$ to generate the sender’s corresponding hash $H_1\left(\sigma \right)$, it is impossible to further calculate the sender’s secret key $e{k}_{\sigma }=H_1{\left(\sigma \right)}^{\beta }$ due to the hardness of the DL problem. The designed access policy is embedded in the ciphertext as $H_1{\left({\rho }_r\right)}^{x_1}$.

From the aspect of the receiver’s identity and access policy, the identity and access policy are hidden in $d{k}_{\rho }$, which should be kept secretly by receivers. During the matching process, receivers will hide their secret decryption key by randomly choosing parameter $x_2$.

Therefore, any PPT adversary cannot find out the certain identity and access policy of the sender and receiver. We complete the proof that IBME-DS holds privacy preservation, if the DL problem is hard. □

Theorem 4.

There does not exist any PPT adversary who can forge the match tag for the match algorithm in IBME-DS, if the CDH assumption holds.

Proof. 

With the master public key $\mathtt{mpk}$, the ciphertext C and the match tag $Tag$, the cloud server can get $C=(R_1,R_2,T,{\sigma }^{\prime },{\rho }^{\prime },V)=(g^{r_1},g^{r_2},H_1{\left(\sigma \right)}^{x_1},H_2{\left({\rho }_r\right)}^{x_1},V)$ and $Tag=(I{D}_r^{\prime },{{\sigma }_s}^{\prime })=((d{k}_{{\rho }_{r,1}}^{x_2},d{k}_{{\rho }_{r,2}}^{x_2},d{k}_{{\rho }_{r,3}}^{x_2}),H_1{\left({\sigma }_s\right)}^{x_2}·g_t^{x_2})$. However, since the random numbers $r_1,r_2,x_1,x_2$ are unknown to the cloud server, the cloud server cannot retrieve any sensitive information about $\sigma ,{\rho }_r,{\sigma }_s$ from C and $Tag$, according to the hardness of the CDH problem. Furthermore, for the final result of match $e({\rho }^{\prime },{{\sigma }_s}^{\prime })\stackrel{?}{=}e(I{D}_{r,3}^{\prime },{\sigma }^{\prime }·T)$, its construction is based on the BDH problem. Hence, the cloud server only knows what we expect to disclose, which is whether the equation holds. We complete the proof that there does not exist any PPT adversary who can forge the match in IBME-DS, if the CDH assumption holds. □

6. Theoretical Analysis and Performance Evaluation

In this section, we present the comprehensive theoretical analysis of computational overhead. Then, we conduct extensive experiments to evaluate our proposed IBME-DS, comparing it with the two most related works, AFNV19 [17], called ME, and CFDS20 [18], called MABE. Specifically, AFNV19 [17] is the first paper to propose the matchmaking encryption algorithm, and in this paper, the IB-ME scheme is implemented. CFDS20 is an improvement on AFNV19 that implements the matchmaking encryption and ME-based data-sharing scheme using fog computing, which allows bilateral access control. These two schemes are similar to our scheme in terms of construction and implemented functionality. Therefore, we have selected these schemes to compare computational cost and communication overhead.

6.1. Theoretical Analysis

We theoretically compare the computational overhead of our proposed IBME-DS with the existing similar schemes, in terms of key generation, encryption and decryption.

Specifically, we compare the computational overhead of our proposed IBME-DS with [17,18,19] intuitively. We choose the main cryptographic operations from algorithms, such as bilinear pairing and multiplication operation, as the important references to measure the computational overhead of similar schemes. Our scheme takes $E_G$, $2E_G$, $4P+8E_G+M_G+2M_{G_T}$, $3P+3M_{G_T}$ for the SKGen, RKGen, Enc and Dec, respectively. Moreover, only the computational overhead of the encryption and decryption algorithm is slightly higher than that of IB-ME [17]. Based on the above analysis, the comparison of computational overhead is as shown in

Table 2. Theoretical analysis of computational overhead.

Scheme	Approach	SKGen	RKGen	Enc	Dec
Damgaard [19]	ACE	$n_s{E}_G$	$n_r{E}_G$	$n_s(5E_G+M_G)$	$n_r(E_G+M_G)$
Ateniese [17]	IB-ME	$E_G$	$2E_G$	$2P+3E_G+M_G$	$3P+M_{G_T}$
Xu [18]	MABE	$n_S(E_G+M_G)+2E_G$	$n_R(3E_G+M_G)$	$(n_R+n_{S^{\prime }}+3)E_G+n_{S^{\prime }}{M}_{G_T})$	$n_{R^{\prime }}(2P+E_G)+M_{G_T}$
Our scheme	IB-ME	$E_G$	$2E_G$	$4P+8E_G+M_G+2M_{G_T}$	$3P+3M_{G_T}$

SKGen: the sender’s encryption key generation algorithm; RKGen: the receiver’s decryption key generation algorithm; Enc: the encryption algorithm; Dec: the decryption algorithm; E_G: the computational cost of an exponential function in $\mathbb{G}$; M_G: the computational cost of a multiplication function in $\mathbb{G}$; M_GT: the computational cost of a multiplication function in ${\mathbb{G}}_{\mathbb{T}}$; P: the computational cost of pairing; n_s: the number of senders; n_r: the number of receivers; n_S: the number of the sender’s attributes; n_R: the number of the receiver’s attributes.

.

6.2. Experimental Setting

As is shown in

Table 3. Experimental configuration.

Hardware Configuration
CPU	Intel(R)Core(TM)[email protected] GHz
RAM	8.00 GB
Software Configuration
OS	64-bit Windows 10
Language	Java 14.0.2
Library	JPBC-2.0.0
Elliptic Curve
Type	Type A
Security Level	AES-80
Based Field Size	512 bits
Group Order Size	160 bits

, the configuration is with a laptop running 64-bit Windows 10 with Intel(R) Core(TM) i5-6200U CPU @ 2.30 GHz and 8 GB RAM. We implement the proposed scheme using JAVA 14.0.2 on the laptop using the JPBC library. Type A elliptic curves are used to implement the experiment, by initializing the system parameters from “a.properties”. To make the experimental data more accurate, we average the resulting times after running each algorithm 100 times. To verify the feasibility of the scheme, we simulate a multi-user scenario by setting different numbers of senders. We choose two related schemes based on ME: IB-ME [17] and MABE [18].

Dataset: In our experiments, we combine the real-world dataset and the simulated dataset to evaluate the performance of IBME-DS. Specifically, the real data are obtained from a real-world dataset of OpenITS https://www.openits.cn/openData2/746.jhtml, consisting of the traffic data (including traffic signal control data, section travel time data and intersection lane traffic volume data) collected on 15 December 2016, in Anhui, China. The simulated dataset mainly comprises the vehicle information (consisting of the license plate number, geolocation and speed). These traffic data are used to represent the transmitted messages, and the identity of the user is set by license plate number or road ID. We implement our proposed IBME-DS to simulate data sharing among users based on the above dataset. The total number of users in the experiment will be capped at 30, and the number of attributes will be set to 5.

6.3. Computational Cost

The first experiment is to obtain the runtime of system initialization. The second experiment is to obtain the runtime of key generation. The third and fourth experiments are to obtain the runtime for encryption and decryption. The fifth experiment is to obtain the runtime for the matching process.

In Figure 4, the experiment shows the running time required for Setup versus the number of senders. The experimental results indicate that the initialization computational cost of our scheme is between the MABE and IB-ME. Compared with IB-ME, our scheme has a slightly higher initialization time cost, for the reason that two additional parameters are set to ensure that the matching process is safely outsourced to the cloud server. Moreover, MABE needs two additional pairing calculations during the system initialization, so the time cost is higher than our scheme.

In Figure 5, the experiment shows the running time required for SKGen and RKGen. The experimental results indicate that our scheme takes about the same amount of time as IB-ME. As the characteristics of the identity-based scheme and the appropriate access control policy settings, our scheme achieves less computation cost than MABE. And as the number of senders increases, the gap becomes more pronounced.

In Figure 6, the experiment shows the running time required for Enc. The experimental results indicate that the MABE takes more time than IB-ME and ours, as directly scaling from an attribute-based setting to an identity would incur high computational cost. Our scheme adds two pairing computations to delegate the matching process to the cloud server. Thus, the computational cost of data encryption in our proposed IBME-DS is slightly higher than in IB-ME.

In Figure 7, the experiment shows the running time required for Dec. The experimental results indicate that we spend less time on decryption than MABE. Compared with IB-ME, the computational cost of data decryption in our scheme is slightly larger than that in IB-ME for a single decryption process. In IB-ME, the receivers require to determine whether the message is sent from the designed senders when they receive each ciphertext. In practical applications, such an operation will cause the waste of huge computation and communication resources on the receiver side.

In

Table 4. Running time for match.

Experimental Performance
Number of senders	5	10	15	20	25	30
Running time (ms)	515	1010	1543	2047	2679	3058

Note: to verify the practicality of the scheme, we conduct a series of experiments, including Setup, SKGen, RKGen, Enc, Dec and Match. We develop a matching mechanism to outsource the matching process to the cloud server to reduce the computational and communication overhead on the user side. As in the theoretical analysis of the scheme, the experiments show that our algorithm has slightly higher computational overhead in Setup, SKGen, RKGen, Enc and Dec than IB-ME, since we build an outsourced matching mechanism and add $E_G$ operations to ensure data privacy. Although we have more time overhead compared to IB-ME, our scheme is capable of meeting practical requirements for cloud services.

, the experiment shows the running time required for Match versus the number of senders. The experimental results indicate that the computational cost of the matching process grows linearly with the number of senders. By delegating the matching process to the cloud server, the computation cost on the local side will be significantly reduced.

6.4. Communication Overhead

In

Table 5. Space cost of different schemes.

Scheme	Encryption Key	Decryption Key	Ciphertext
Ateniese19 [17]	512	1536	1280
Xu22 [18]	3072	5120	7168
Our scheme	512	1536	2816

and Figure 8, the experiment shows the communication overhead on the receiver and the sender side in terms of the encryption key, decryption key and ciphertext. The experimental results indicate that by delegating the matching process to the cloud server, the communication overhead on the receiver side will be significantly reduced than in others, although our scheme has slightly more communication overhead on the ciphertext than IB-ME.

7. Related Work

We will describe the state-of-the-art works on access control and matchmaking encryption in this section. As is shown in

Table 6. Comprehensive comparison among the state-of-the-art schemes.

	Type of Scheme	Data Privacy	Sender Privacy	Outsource Match	Identity-Based Encryption	Access Control
[20]	ABAC	×	×	×	×	one-way
[21,22,23]	ABE	√	√	×	×	one-way
[19]	ACE	√	×	√	×	bilateral
[17]	ME	√	√	×	×	bilateral
[24,25]	ME	√	√	√	×	bilateral
[26]	CL-ME	√	√	×	√	bilateral
[18,27]	AB-ME	√	√	√	×	bilateral
[28,29]	IB-ME	√	√	×	√	bilateral
Ours	IB-ME	√	√	√	√	bilateral

, we compare the existing schemes with our scheme from different perspectives.

7.1. Access Control

In 1969, Lampson et al. [30] first proposed access control technology and introduced the concept of subject and object and autonomous access control. The owner of autonomous access control can independently decide to grant object permissions to other subjects. To realize an access control in the cross-domain network environment, Eric et al. [20] described a dynamic Attribute-Based Access Control (ABAC). ABAC takes attributes as the core and authorization basis, providing fine-grained authorized access and large-scale user dynamic expansion in complex network environments. Specifically, Attribute-Based Encryption (ABE) was first introduced by Sahai and Waters [21] in the fuzzy identity encryption scheme in 2006, which aimed to improve the security of attribute-based access control. Subsequently, Goyal et al. [22] divided ABE into Ciphertext-Policy ABE (CP-ABE) and Key-Policy ABE (KP-ABE). But none of them satisfy the protection of sender privacy. To solve the above problem, Zheng et al. [23] first introduced the Attribute-based Keyword Search (ABKS), allowing the user to search for encrypted data outsourced by the data owner. However, their scheme cannot support multiple rounds to search the messages securely. Damgard et al. [19] proposed Access Control Encryption (ACE) based on security policies for information flow to allow fine-grained access control. In ACE, different authorizations will be given to users for reading and writing. However, to ensure secure data flow, ACE needs to introduce the sanitizer that controls the communication, which is a fully trusted party. In terms of our literature review on conventional access control, the aforementioned schemes have two crucial issues when applied to cloud services. Firstly, most access control schemes only support that one side specifies the access policy (e.g., CP-ABE, KP-ABE). Secondly, even if some access control scheme (e.g., ACE) is equipped with bilateral access control, it has to involve a fully trusted party. The strong trusted requirement will throw threats to the system security.

7.2. Matchmaking Encryption

Ateniese et al. [17] proposed the matchmaking encryption (ME) on CRYPTO’19. In their work, an efficient identity-based matchmaking encryption scheme (IB-ME) is given as an instantiation. Both senders and receivers are allowed to specify their access policies simultaneously, which realizes bilateral access control. But none of the schemes proposed in this paper support outsourced matching, which may become a performance bottleneck for devices with limited resources. To support the outsourced matching, Li et al. [27] proposed a bilateral friend-matching scheme by combining ME with ABE. However, the outsourcing center in their scheme can identify which party does not meet the access policy of the others. Chen et al. [26] proposed an efficient certificateless matchmaking encryption (CL-ME) scheme for IoT. In the cloud-fog computing environment, Xu et al. [24] proposed a data-sharing system based on lightweight ME. Subsequently, Xu et al. [18] proposed a data-sharing system specified for cloud-fog devices (CFDS), based on matchmaking attribute-based encryption (MABE). In the field of IIoT, Sun et al. [25] proposed a privacy-preserving bilateral access control scheme, which is based on fine-grained access control and ME. In 2022, Wu et al. [29] extended ME to cross-domain scenarios and proposed a cross-domain IB-ME, by which users from different domains can get their secret keys from different authority centers. However, the aforementioned ME-based works are constructed under the attribute-based cryptosystem, with huge computation overhead to the resource-restricted devices. Moreover, Danilo et al. [28] proposed an IB-ME scheme based on standard assumption. The matching is conducted by users while decrypting the ciphertext. Also, the resource-restricted devices are not competent to resolve the complex computation and huge communication overhead. Hence, there is a certain gap in implementing a privacy-preserving data-sharing scheme with bilateral access control, supporting the matching delegation for devices in cloud services.

8. Discussion

In this section, we focus on discussing the advantages of our research and the limitations of it. The advantages of our proposed scheme are obvious by reviewing the related works as shown in Table 6. Our proposed IBME-DS possesses the semantic security, authenticity and data privacy, where the delegation will not reveal sensitive information (e.g., access policies and shared data) for cloud services. As a new way to protect both receiver and sender access control simultaneously, ME enables bilateral access control [17]. We construct our scheme based on IB-ME to fulfill the practical requirements of identity authentication in cloud services. To enhance the security, we design a privacy-preserving matching mechanism to realize the secure outsource match. There is a limitation to be improved, which concerns the communication overhead that needs to be further reduced during large-scale deployment of cloud services.

9. Conclusions

In this work, we propose a data-sharing scheme with bilateral access control, based on IB-ME. Our scheme can provide effective privacy preservation for both the sender and receiver in cloud services. Due to delegating the matching process to the cloud server, our scheme can provide more efficient data-sharing capabilities, and reduce the computation overhead on end devices without revealing any private information. Additionally, we point out some interesting issues to be resolved in the future. Firstly, we consider protecting forward secrecy by applying the key exposure resistant cryptographic primitives. Secondly, our scheme is designed for devices in cloud services. We will attempt to further enhance the efficiency of our scheme by applying the edge computing technique [31].