Cryptanalysis of Two Privacy-Preserving Authentication Schemes for Smart Healthcare Applications

Abstract

Ensuring the secure sharing of privacy-sensitive healthcare data is attracting considerable interest from researchers. Recently, Ogundoyin et al. designed a lightweight privacy-preserving authentication scheme named PAASH for smart health applications. Benil et al. proposed a public verification and auditing scheme named ECACS for securing e-health systems. Ogundoyin et al. and Benil et al. proposed an efficient certificateless aggregate signature (CLAS) scheme as their respective foundation signature schemes. They declared that their constructions were provably secure under the hardness assumption of cryptographic problems. In this work, we disprove their claim by analyzing the correctness and security of their underlying CLAS schemes. We first show that the batch verification process of n signatures for the CLAS scheme in PAASH is incorrect, and any public-key replacement attacker can easily break the scheme. We analyze the reasons for our attack and propose an improved scheme, named PAASH${}^{+}$. We then show that the CLAS scheme in ECACS fails to achieve correctness, an essential property that a cryptographic scheme should provide. As a result, it is impractical to deploy the designed PAASH and ECACS constructions in any real smart health applications.

1. Introduction

Nowadays, including intelligent transportation, smart industry, and smart healthcare, Internet of Things (IoT) technologies are widely used in various fields of our life. The market research company IDC estimates that 41.6 billion IoT devices will be connected by 2025 [1]. Taking the healthcare industry as an example, smart devices (e.g., smartphones, wearable or implantable sensors) are deployed in applications such as telemedicine, patient physiological monitoring, and clinical problem identification [2]. They collaborate with wireless communication technologies to make health data collection increasingly flexible. Due to the resource limitation of these devices, the collected health data will typically be outsourced to a remote cloud for storage and sharing. However, because of the openness of the network, these privacy-sensitive healthcare data are vulnerable to various security attacks such as eavesdropping and tampering, posing a serious threat to patients’ health. Therefore, it is essential to design effective mechanisms to ensure data security and privacy [3].

Historically, digital signatures have typically been used to ensure data authenticity and integrity. However, given the large amount of healthcare data that needs to be received from various smart devices, signature verification must be remarkably efficient to support low-latency emergencies. Consequently, the concept of aggregate signature introduced by Boneh et al. [4] is an ideal signature technique for supporting batch verification. Boneh et al.’s construction is based on the traditional public-key cryptosystem (PKC), which suffers from the costly key management problem. In view of this, aggregate signature schemes [5] based on an identity-based cryptosystem (IBC) have been proposed; nevertheless, Al-Riyami et al. [6] showed that IBC-based construction has the key escrow problem. To reduce the certificate management cost in traditional PKCs and eliminate the key escrow problem in IBCs, aggregate signature schemes based on the certificateless cryptosystem [7,8,9,10,11,12] have been put forward for smart healthcare applications.

Recently, Zhang et al. [13] integrated the ciphertext-policy attribute-based encryption (CP-ABE) technique and the certificateless aggregate signature (CLAS) scheme to design a secure smart health system called SSH. Notably, in a CP-ABE scheme, the data owner can apply an attribute secret key based on a set of attributes. The ciphertext is produced under an access policy, and decryption succeeds only when the owner’s attribute list satisfies the policy. Therefore, Zhang et al.’s SSH construction simultaneously achieves aggregate authentication, fine-grained access control, and data confidentiality. However, very recently, Ogundoyin et al. [2] found that Zhang et al.’s SSH scheme is vulnerable to any Type II attacker who knows the system master-secret key. To this end, Ogundoyin et al. put forward a new lightweight privacy-preserving authentication scheme named PAASH for smart health applications, which also consists of a CP-ABE scheme and a CLAS scheme. Ogundoyin et al. presented a formal security analysis of their design under the standard cryptographic assumption. To achieve aggregate authentication and data confidentiality, there are also several certificateless signcryption schemes [14,15] in the literature. However, they cannot achieve fine-grained access control.

In addition, as another important smart healthcare application, an electronic health record (EHR) is a record in an electronic version containing personal health-related data, which is stored and retrieved by different healthcare providers for healthcare-related purposes. Compared to the traditional paper-based health record, the EHR has many benefits, such as lowering costs, improving health care quality, promoting evidence-based medicine usage, helping in record-keeping, and ensuring the records’ mobility. To secure the storage and sharing of privacy-sensitive EHR data over the potentially untrusted cloud, many cryptographic schemes have been proposed in the literature [16,17,18]. Zhu et al. [16] proposed an authentication scheme with privacy protection and designated verification for XML-based healthcare records. Domadiya et al. [17] put forward a privacy-preserving scheme for distributed healthcare data collection and mining for EHR systems, which provides a healthcare data mining platform to medical researchers and physicians. Guo et al. [18] presented a hybrid blockchain-edge architecture for managing EHR with attribute-based cryptographic mechanisms. However, these designs require expensive pairing operations. Recently, Benil et al. [19] proposed a new public verification and auditing scheme called ECACS to secure EHRs. ECACS combines a certificateless public verification (CPV) scheme and a certificateless public auditing (CPA) scheme. Designed based on a CLAS scheme, the CPV scheme is used to guarantee the authenticity of the shared EHR data. Moreover, in combination with blockchain technology, the CPA scheme allows a cloud server to generate proof of possession of the EHR data and an auditor to check the correctness of the proof (please refer to [19] for the detailed application model).

Contributions. In this work, we observe that Ogundoyin et al.’s PAASH in [2] cannot satisfy correctness and unforgeability. More specifically, we find that the batch verification process of n signatures for the CLAS scheme in PAASH is incorrect, and any Type I attacker (public-key replacement attacker) can easily break the scheme. Namely, the attacker can impersonate a data owner (i.e., a patient) to forge a valid signature on his false healthcare information. This may lead healthcare professionals to make incorrect diagnoses of a patient’s health condition, even with catastrophic consequences. Therefore, the designed PAASH cannot be deployed in practical smart health applications. Based on our cryptanalysis, we discuss the related reason. Moreover, we suggest an improved PAASH${}^{+}$ scheme to fill this gap.

In addition, we show that the CLAS scheme in Benil et al.’s ECACS [19] fails to achieve correctness, the essential property that a cryptographic scheme should provide. Without correctness, other properties such as security and privacy become unattainable. As a result, we demonstrate that their scheme is incorrect/insecure for practical applications.

Organization. The remaining paper is organized as follows: We review some preliminaries in Section 2. In Section 3, we show our cryptanalysis to Ogundoyin et al.’s PAASH scheme. More concretely, we review their scheme in Section 3.1, provide the scheme analysis in Section 3.2, and present our discussion and improvement in Section 3.3. In Section 4, we show our cryptanalysis of Benil et al.’s ECACS Scheme, including a scheme review in Section 4.1 and a scheme analysis in Section 4.2. Conclusions are drawn in Section 5.

2. Preliminaries

We here introduce some preliminaries.

Notations. We use $\mathbb{N}=\{1,2,\dots \}$ and $\left|\right|$ to represent the set of positive integers and the concatenation of two strings, respectively. Denote by $x{\in }_{R}X$ the element x chosen uniformly and randomly from the set X.

Elliptic curve discrete logarithm problem (ECDLP) [20]. Given an elliptic curve E defined over a finite field ${\mathbb{F}}_p$, an additive cyclic subgroup $\mathbb{G}$ on $E/{\mathbb{F}}_p$ with generator P and prime order q, and a point $Q\in \mathbb{G}$, the ECDLP is to find $\alpha \in {\mathbb{Z}}_q^{*}$ such that $Q=\alpha P$.

Correspondingly, the ECDLP assumption refers to any probabilistic polynomial time (p.p.t) adversary $\mathcal{A}$ with negligible probability in solving the ECDLP.

3. Cryptanalysis of the PAASH Scheme in [2]

3.1. Review of the PAASH Scheme

The PAASH scheme is as follows; some notations for the scheme are shown in

Table 1. Notations and descriptions.

Notations	Descriptions
ℓ	System security parameter
$p{a}_{\mathrm{ABE}}$	Attribute-based parameter
$x_{\mathrm{ABE}}$	Attribute-based master secret key
$pparam$	System public parameter
$H_i$	Hash function, $i=1,2,3$
$(I{D}_i,{L_i}^{att})$	Patient $P_i$’s identity and attribute list
${S{K}_i}^{att}$	$P_i$’s attribute-based secret key
$PS{K}_i$	$P_i$’s partial secret key
$(S{K}_i,P{K}_i)$	(Full) secret key and public key of $P_i$
$m_i$	$P_i$’s healthcare data
$c_{p{o}_i}$	Ciphertext of $m_i$ under ${S{K}_i}^{att}$
${\sigma }_i$	Signature of $c_{p{o}_i}$
$\sigma$	Aggregate signature

.

• System Setup Phase
  Taking a security parameter ℓ as an input, the registration authority (RA) runs the underlying CP-ABE scheme in [21], which consists of the ABE.MasterKeyGen, ABE.AttributeKeyGen, ABE.Encrypt, and ABE.Decrypt algorithms. More concretely, it runs ABE.MasterKeyGen to obtain an attribute-based parameter $p{a}_{\mathrm{ABE}}$ and an attribute-based master secret key $x_{\mathrm{ABE}}$. Then it executes the following algorithm MasterKenGen to output a public parameter $param$ and a master secret key s.
  MasterKenGen: the RA performs the following:
  • Choose a non-singular elliptic curve $E:y^2=x^3+ax+bmodp$ and a q-order additive group $\mathbb{G}=\langle P\rangle$, where $p,q$ are large primes.
  • Pick $s{\in }_R{\mathbb{Z}}_q^{*}$ as the master secret key and compute the corresponding public key $P_{pub}=sP$.
  • Select three hash functions $H_1:{\{0,1\}}^{*}\to {\mathbb{Z}}_q^{*}$, $H_2:{\{0,1\}}^{*}\times \mathbb{G}\to {\mathbb{Z}}_q^{*}$, $H_3:{\{0,1\}}^{*}\times \mathbb{G}\times \mathbb{G}\to {\mathbb{Z}}_q^{*}$.
  • Store s secretly and broadcast public parameters $pparam=\{E,\mathbb{G},p,q,P,P_{pub},H_1,H_2,H_3\}$.
• Registration Phase
  Let a patient $P_i$ be the smart health client with identity $I{D}_i$ and an attribute list ${L_i}^{att}$. When $P_i$ wants to join the system, $P_i$ does the following:
  • Choose $d_i{\in }_R{\mathbb{Z}}_q^{*}$ and a timestamp ${t_i}^1$.
  • Compute $D_i=d_{i}P$, $Y_i=d_i{P}_{pub}$, and ${\mathsf{\Omega }}_i=I{D}_i\left|\right|{L_i}^{att}⨁H_1(Y_i\left|\right|{t_i}^1)$.
  • Send $({\mathsf{\Omega }}_i,D_i,{t_i}^1)$ to the RA as its registration request.
  Upon receiving $({\mathsf{\Omega }}_i,D_i,{t_i}^1)$ from $P_i$, the RA operates as follows:
  • Accept the request if ${t_i}^1$ is fresh and reject it otherwise.
  • Recover $I{D}_i$ and ${L_i}^{att}$ by computing $I{D}_i\left|\right|{L_i}^{att}={\mathsf{\Omega }}_i⨁H_1(s{D}_i\left|\right|{t_i}^1)$.
  • Confirm the validity of $I{D}_i$ and compute $PI{D}_i=H_1\left(s\right||I{D}_i\left|\right|T_i)$ as the pseudonym of $P_i$, where $T_i$ is the valid time period.
  Now, the RA runs ABE.AttributeKeyGen (i.e., using $x_{ABE}$) to generate $P_i$’s attribute-based secret key ${S{K}_i}^{att}$ and executes the following PartialSecKeyGen to generate $P_i$’s partial secret key $PS{K}_i$. Notably, $P_i$ will use ${S{K}_i}^{att}$ and $PS{K}_i$ to encrypt the healthcare data and sign the corresponding ciphertext, respectively.
  PartialSecKeyGen: the RA performs the following:
  • Choose a timestamp ${t_R}^1$.
  • Compute ${\alpha }_i=H_2(I{D}_i\left|\right|s\left|\right|P_{pub}\left|\right|T_i)$, ${\beta }_i=H_2(I{D}_i\left|\right|{L_i}^{att}\left|\right|pparam)$, ${\theta }_i={\alpha }_i{\beta }_i+s$, and $A_i={\alpha }_{i}P$.
  • Set $PS{K}_i=(A_i,{\theta }_i)$ as the partial secret key.
  • Compute a masking parameter ${\Theta }_i=H_1(s{D}_i\left|\right|{t_R}^1)⨁({S{K}_i}^{att}\left|\right|PS{K}_i)$.
  • Send $(PI{D}_i,{\Theta }_i,{t_R}^1)$ to $P_i$.
  Upon receiving $(PI{D}_i,{\Theta }_i,{t_R}^1)$, $P_i$ operates as follows:
  • Check the freshness of ${t_R}^1$.
  • Compute ${S{K}_i}^{att}\left|\right|PS{K}_i={\Theta }_i⨁H_1(s{D}_i\left|\right|{t_R}^1)$ to recover ${S{K}_i}^{att}$ and $PS{K}_i$. The validity of these keys can be verified by ${\theta }_{i}P={\beta }_i{A}_i+P_{pub}$, where ${\beta }_i=H_2(I{D}_i\left|\right|{L_i}^{att}\left|\right|pparam)$.
• Data Outsourcing Phase
  $P_i$ with pseudonym $PI{D}_i$ outsources its healthcare data $m_i$ to a medical cloud server (MCS) where authorized data requesters (e.g., healthcare providers or researchers) can access it. To do this, $P_i$ firstly defines a ciphertext policy $p{o}_i$ and executes ABE.Encrypt to obtain the ciphertext $c_{p{o}_i}$ corresponding to $m_i$. Then, $P_i$ executes the following algorithms SecretKeyGen and Sign:
  SecretKeyGen: $P_i$ picks $x_i,y_i{\in }_R{\mathbb{Z}}_q^{*}$ and computes $P{K}_i=y_{i}P$. Now, $P_i$ sets $S{K}_i=(x_i,y_i,{\theta }_i)$ as the secret key and $P{K}_i$ as the public key.
  Sign: $P_i$ does the following:
  • Select $r_i{\in }_R{\mathbb{Z}}_q^{*}$ and compute $V_i=r_i{x}_{i}P$, $R_i=V_i+{\beta }_i{A}_i$, $h_i=H_3(c_{p{o}_i}\left|\right|PI{D}_i\left|\right|R_i\left|\right|P{K}_i\left|\right|{t_i}^2)$, and ${\delta }_i=r_i{x}_i+h_i{y}_i+{\theta }_i$, where ${t_i}^2$ is a timestamp and ${\beta }_i=H_2(I{D}_i\left|\right|{L_i}^{att}\left|\right|pparam)$.
  • Set ${\sigma }_i=(R_i,{\delta }_i)$ as a signature on $c_{p{o}_i}\left|\right|{t_i}^2$.
  $P_i$ now uploads the tuple $(c_{p{o}_i},PI{D}_i,{\sigma }_i,P{K}_i,{t_i}^2)$ to the MCS.
  Suppose that the MCS receives a set of $(c_{p{o}_i},PI{D}_i,{\sigma }_i,P{K}_i,{t_i}^2)$ from $P_i$ for $i=1,2,\dots ,n$. It executes the algorithms Aggregate and AggregateVerify:
  Aggregate: the MCS performs the following:
  • Check the freshness of ${t_i}^2$ and recover $h_i=H_3(c_{p{o}_i}\left|\right|PI{D}_i\left|\right|R_i\left|\right|P{K}_i\left|\right|{t_i}^2)$ for $i=1,2,\dots ,n$.
  • Calculate $\Delta ={\mathsf{\Sigma }}_{i=1}^n{\delta }_i$, $R={\mathsf{\Sigma }}_{i=1}^n{R}_i$, and $PK={\mathsf{\Sigma }}_{i=1}^n{h}_{i}P{K}_i$.
  • Return $\sigma =(R,\Delta )$ as the aggregate signature on $c_{p{o}_i}\left|\right|{t_i}^2$, $i=1,2,\dots ,n$.
  AggregateVerify: The MCS accepts the message $c_{p{o}_i}\left|\right|{t_i}^2$, $i=1,2,\dots ,n$ if $\Delta P=R+PK+P_{pub}$ holds and rejects otherwise.
• Data Access Phase
  A data requester (e.g., a healthcare provider or a researcher) is allowed to download $P_i$’s healthcare information $(c_{p{o}_i},PI{D}_i,{\sigma }_i=(R_i,{\delta }_i),P{K}_i,{t_i}^2)$ from the MCS. More concretely, it firstly executes the following Verify algorithm:
  Verify: the data requester checks the freshness of ${t_i}^2$, recovers $h_i=H_3(c_{p{o}_i}\left|\right|PI{D}_i\left|\right|R_i\left|\right|P{K}_i\left|\right|{t_i}^2)$, and verifies whether ${\delta }_{i}P=R_i+h_{i}P{K}_i+P_{pub}$. Note that the data requester can also check a set of messages simultaneously as in AggregateVerify to improve verification efficiency.
  At last, if the data requester’s attributes match with the access policy $p{o}_i$, it can run the ABE.Decrypt to obtain the healthcare data $m_i$.

3.2. Scheme Analysis

The above PAASH scheme proposed by Ogundoyin et al. can be seen as a combination of two cryptographic schemes, i.e., the underlying lightweight CP-ABE scheme proposed by Gafif et al. in [21] and a new CLAS scheme designed by Ogundoyin et al. Here, the CLAS scheme is constructed by algorithms MasterKenGen, PartialSecretKeyGen, SecretKeyGen, Sign, Verify, Aggregate, and AggregateVerify. Meanwhile, the first five algorithms in CLAS naturally form a basic CLS scheme. Since the security of the CP-ABE scheme has been analyzed by Gafif et al., we only focus on the correctness and security analysis of Ogundoyin et al.’s CLAS scheme.

3.2.1. Correctness Analysis

In Ogundoyin et al.’s CLS scheme, upon obtaining $P_i$’s healthcare information $(c_{p{o}_i},PI{D}_i,{\sigma }_i=(R_i,{\delta }_i),P{K}_i,{t_i}^2)$, the verifier can use Verify to check the single signature ${\sigma }_i$ by checking whether the equation ${\delta }_{i}P=R_i+h_{i}P{K}_i+P_{pub}$ holds (we hereafter omit the hash operation in correctness analysis). This is true since the verification equation can easily verify a single valid signature. However, their aggregate signature on n signatures produced by Aggregate cannot be validated by AggregateVerify.

For example, when $n=2$, the MCS in Aggregate computes $\Delta ={\delta }_1+{\delta }_2$, $R=R_1+R_2$, and $PK=h_{1}P{K}_1+h_{2}P{K}_2$. It then sets $\sigma =(R,\Delta )$ as the aggregate signature on $c_{p{o}_1}\left|\right|{t_1}^2$ and $c_{p{o}_2}\left|\right|{t_2}^2$. To accept the signature $\sigma$, in AggregateVerify, one needs to check whether $\Delta P=R+PK+P_{pub}$ holds. However, it is obvious that the equation does not hold since

$$\begin{array}{cc}\hfill \Delta P=& ({\delta }_1+{\delta }_2)P\hfill \\ \hfill =& R_1+h_{1}P{K}_1+2P_{pub}+R_2+h_{2}P{K}_2\hfill \\ \hfill =& R+PK+2P_{pub}\hfill \\ \hfill \ne & R+PK+P_{pub}.\hfill \end{array}$$

To fix the problem, the verification equation in AggregateVerify needs to be changed to $\Delta P=R+PK+n{P}_{pub}$.

In the following section, we show that the fixed CLAS scheme is insecure.

3.2.2. Security Analysis

In [2], Ogundoyin et al. proved that their scheme can resist two types of security attacks. Namely, the Type I adversary is regarded as a public key replacement attacker. It knows the secret value of a target user but does not know the user’s partial secret key. Meanwhile, the Type II adversary is regarded as a malicious-but-passive KGC who is able to know the master secret key but does not obtain the secret value of the target user. We refer the readers to [22,23] for the detailed security model. Here, we disprove Ogundoyin et al.’s claim by presenting a concrete Type I attack.

We suppose that ${\mathcal{A}}_1$ is a Type I adversary, as shown in Figure 1. ${\mathcal{A}}_1$’s goal is to forge a signature ${{\sigma }_i}^{*}=({R_i}^{*},{{\delta }_i}^{*})$ on a message ${c_{p{o}_i}}^{*}\left|\right|{t_i}^2$ for a target participant $P_i$ with the pseudonym $PI{D}_i$, where ${t_i}^2$ is a random timestamp. Now, ${\mathcal{A}}_1$ will be provided with the system parameter $pparam=\{E,\mathbb{G},p,q,P,P_{pub},H_1,H_2,H_3\}$ and $P_i$’s public information $(PI{D}_i,P{K}_i)$.

${\mathcal{A}}_1$ picks ${y_i}^{*}{\in }_R{\mathbb{Z}}_q^{*}$, computes ${P{K}_i}^{*}={y_i}^{*}P$, and sets ${P{K}_i}^{*}$ as the replaced public key. ${\mathcal{A}}_1$ now executes as follows:

• Select $z{\in }_R{\mathbb{Z}}_q^{*}$ and set ${R_i}^{*}=zP-P_{pub}$.
• Compute ${h_i}^{*}=H_3({c_{p{o}_i}}^{*}\left|\right|PI{D}_i\left|\right|{R_i}^{*}\left|\right|{P{K}_i}^{*}\left|\right|{t_i}^2)$ and ${{\delta }_i}^{*}=z+{h_i}^{*}{y_i}^{*}$.
• Set ${{\sigma }_i}^{*}=({R_i}^{*},{{\delta }_i}^{*})$ as its forgery.

${\mathcal{A}}_1$ now sends the tuple $({c_{p{o}_i}}^{*},PI{D}_i,{{\sigma }_i}^{*},{P{K}_i}^{*},{t_i}^2)$ to a potential verifier (i.e., the MCS or the data requester). The correctness of ${{\sigma }_i}^{*}=({R_i}^{*},{{\delta }_i}^{*})$ is verified as:

$$\begin{array}{cc}\hfill {{\delta }_i}^{*}P=& (z+{h_i}^{*}{y_i}^{*})P=zP+{h_i}^{*}{y_i}^{*}P\hfill \\ \hfill =& {R_i}^{*}+P_{pub}+{h_i}^{*}{P{K}_i}^{*}\hfill \\ \hfill =& {R_i}^{*}+H_3({c_{p{o}_i}}^{*}\left|\right|PI{D}_i\left|\right|{R_i}^{*}\left|\right|{P{K}_i}^{*}\left|\right|{t_i}^2){P{K}_i}^{*}+P_{pub}.\hfill \end{array}$$

Apparently, ${\mathcal{A}}_1$ is successful in forging the signature on ${c_{p{o}_i}}^{*}\left|\right|{t_i}^2$. Since any single signature can be forged, the designed CLAS cannot provide its claimed security assurance.

Recall that in Ogundoyin et al.’s scheme, $P_i$ encrypts its healthcare data $m_i$ by running ABE.Encrypt. One may argue that the described adversary ${\mathcal{A}}_1$ cannot arbitrarily forge ciphertext $c_{p{o}_i}$ since it does not know the attribute-based secret key ${S{K}_i}^{att}$ of $P_i$. However, even with this, ${\mathcal{A}}_1$ is still able to accomplish its forgery by freely selecting the ${c_{p{o}_i}}^{*}$ from the historical encrypted data sent by $P_i$. Note that data requesters need to provide medical services such as diagnosis and treatment to the patient $P_i$ based on the received ${c_{p{o}_i}}^{*}$. However, incorrect or untimely ${c_{p{o}_i}}^{*}$ may lead to misdiagnosis of a patient’s health condition and, in severe cases, may even pose a significant health risk to the patient. Therefore, the proposed PAASH scheme cannot be deployed to real applications.

3.3. Discussion and Improvement

In Ogundoyin et al.’s scheme, $R_i$ and $P_{pub}$ are independent of each other in the verification equation ${\delta }_{i}P=R_i+h_{i}P{K}_i+P_{pub}$. This allows ${\mathcal{A}}_1$ to use the algebraic relationship between them to generate an intermediate value that can be used to bypass the master secret key s and thus forge the signature on $c_{p{o}_i}$.

In view of this, we suggested an improved PAASH${}^{+}$ scheme as below. Note that our improvement mainly focuses on their proposed CLAS scheme.

Recall that in the System Setup Phase, the RA in MasterKeyGen selects three hash functions. Here, we let RA choose four hash functions $H_i:{\{0,1\}}^{*}\to {\mathbb{Z}}_q^{*}$, $i=1,2,3,4$. The remaining part of the algorithm is the same as the original algorithm.

In the Registration Phase, the RA sets $A_i={\alpha }_i{\beta }_{i}P$. As a result, the partial secret key $PS{K}_i=(A_i,{\theta }_i)$ can be checked by ${\theta }_{i}P=A_i+P_{pub}$. The remaining part of the PartialSecretKeyGen algorithm is the same as the original algorithm.

In the Data Outsourcing Phase, four algorithms—SecretKeyGen, Sign, Aggregate, and AggregateVerify—are changed as follows:

SecretKeyGen: $P_i$ picks $x_i{\in }_R{\mathbb{Z}}_q^{*}$ and computes $X_i=x_{i}P$. Now, $P_i$ sets $S{K}_i=(x_i,{\theta }_i)$ as the secret key and $P{K}_i=(A_i,X_i)$ as the public key.

Sign: $P_i$ works as follows:

• Pick $r_i{\in }_R{\mathbb{Z}}_q^{*}$ and compute $R_i=r_{i}P$, $h_{3i}=H_3(PI{D}_i\left|\right|P{K}_i\left|\right|P_{pub})$, $h_{4i}=H_4(c_{p{o}_i}\left|\right|PI{D}_i\left|\right|R_i\left|\right|P{K}_i\left|\right|{t_i}^2)$, and ${\delta }_i={\theta }_i+r_i{h}_{4i}+x_i{h}_{3i}$, where ${t_i}^2$ is a timestamp.
• Set ${\sigma }_i=(R_i,{\delta }_i)$ as a signature on $c_{p{o}_i}\left|\right|{t_i}^2$.

$P_i$ now uploads the tuple $(c_{p{o}_i},PI{D}_i,{\sigma }_i,P{K}_i,{t_i}^2)$ to the MCS.

Suppose that the MCS receives a set of $(c_{p{o}_i},PI{D}_i,{\sigma }_i,P{K}_i,{t_i}^2)$ from $P_i$ for $i=1,2,\dots ,n$. It executes the algorithms Aggregate and AggregateVerify:

Aggregate: the MCS performs the following:

• Check the freshness of ${t_i}^2$ and calculate $\Delta ={\mathsf{\Sigma }}_{i=1}^n{\delta }_i$.
• Return $\sigma =(\Delta ,R_1,R_2,\dots ,R_n)$ as the aggregate signature on $c_{p{o}_i}\left|\right|{t_i}^2$, $i=1,2,\dots ,n$.

AggregateVerify: the MCS accepts the message $c_{p{o}_i}\left|\right|{t_i}^2$, $i=1,2,\dots ,n$ if $\Delta P={\sum }_{i=1}^n{A}_i+n{P}_{pub}+{\sum }_{i=1}^n{h}_{3i}{X}_i+{\sum }_{i=1}^n{h}_{4i}{R}_i$ holds and rejects otherwise, where $h_{3i}=H_3(PI{D}_i\left|\right|P{K}_i\left|\right|P_{pub})$ and $h_{4i}=H_4(c_{p{o}_i}\left|\right|PI{D}_i\left|\right|R_i\left|\right|P{K}_i\left|\right|{t_i}^2)$ for $i=1,2,\dots ,n$.

Accordingly, Verify in the Data Access Phase is modified as below:

Verify: the data requester checks the freshness of ${t_i}^2$, recovers $h_{3i}=H_3(PI{D}_i\left|\right|P{K}_i\left|\right|P_{pub})$ and $h_{4i}=H_4(c_{p{o}_i}\left|\right|PI{D}_i\left|\right|R_i\left|\right|P{K}_i\left|\right|{t_i}^2)$. Then the requester verifies whether ${\delta }_{i}P=A_i+P_{pub}+h_{3i}{X}_i+h_{4i}{R}_i$. The data requester can also check a set of messages simultaneously as in AggregateVerify to improve verification efficiency.

Security Analysis to PAASH${}^{+}$

In the above improved CLAS scheme, a Type I adversary ${\mathcal{A}}_1$ can forge a valid signature in two ways, i.e., by computing the partial secret key $PS{K}_i=(A_i,{\theta }_i)$ generated by the RA or bypassing it. Although ${\mathcal{A}}_1$ can obtain the public key corresponding to $PS{K}_i$, the computation of the partial secret key ${\theta }_i$ can be viewed as solving ECDLP. The second method is to bypass ${\theta }_i$. Namely, ${\mathcal{A}}_1$ can use some algebraic relation that may exist in the verification equation (i.e., ${\delta }_{i}P=A_i+P_{pub}+h_{3i}{X}_i+h_{4i}{R}_i$) to eliminate $P_{pub}$. To do this, ${\mathcal{A}}_1$ can only change the value of $X_i$ (or $R_i$) because $A_i$ and $P_{pub}$ are generated by the RA. Note that $h_{3i}=H_3(PI{D}_i\left|\right|P{K}_i\left|\right|P_{pub})$ and $h_{4i}=H_4(c_{p{o}_i}\left|\right|PI{D}_i\left|\right|R_i\left|\right|P{K}_i\left|\right|{t_i}^2)$. $X_i$ and $h_{3i}$ (or $R_i$ and $h_{4i}$) are bound together, any modification to $X_i$ (or $R_i$) will make the equation invalid.

A Type II adversary ${\mathcal{A}}_2$ also has two methods to forge a signature. The first method is to obtain the secret value $x_i$ generated by the target user $P_i$. Although ${\mathcal{A}}_2$ can obtain the partial public key $X_i$ corresponding to $x_i$, the computation of $x_i$ can also be stated as solving ECDLP. The second approach is to bypass $x_i$. That is, ${\mathcal{A}}_2$ may use some algebraic relation in the above verification equation to eliminate $X_i$. To do this, it needs to change $A_i$, $R_i$, or $P_{pub}$. However, $A_i$ has been made public as part of the user’s public key; $R_i$ and $h_{4i}$ as well as $P_{pub}$ and $h_{3i}{X}_i$ are bound together, respectively. Therefore, ${\mathcal{A}}_2$ cannot execute the modification.

By eliminating the algebraic relation between the public parameters in the verification equation, the suggested scheme can be proved secure through the theorem in Ogundoyin et al.’s security model:

Theorem 1.

If the ECDLP problem is hard, then the improved CLAS is unforgeable against Type I and Type II adversaries as defined by Ogundoyin et al. in [2] in the random oracle model.

However, we omit the concrete proof here to avoid duplication of work.

By adopting the improved CLAS scheme, a secure PAASH${}^{+}$ scheme is achieved.

Table 2. Comparison of features with several related schemes.

Scheme	Correctness	Resist Type I Attack	Resist Type II Attack	Authentication	Access Control	Confidentiality
[13]	✓	✓	×	×	✓	✓
[2]	×	×	✓	×	✓	✓
PAASH${}^{+}$	✓	✓	✓	✓	✓	✓

makes a simple comparison between SSH in [13], PAASH in [2], and the suggested PAASH${}^{+}$ in terms of features.

4. Cryptanalysis of the ECACS Scheme in [19]

4.1. Review of the ECACS Scheme

In [19], Benil et al. proposed a public verification and auditing scheme called ECACS to ensure EHRs security. Their design includes sixteen algorithms: Setup, Partial-Private-Key-Generation, Set-Secret-Value, Set-Private-Key, Set-Public-Key, Sign, Verify, Aggregate, Aggregate-Verify, Store, Audit, Challenge, Proof-Generation, Proof-Verify, Log-Generation, and Check-Log-and-Verify. The first nine algorithms constitute a certificateless public verification (CPV) scheme. The remaining algorithms form a certificateless public auditing (CPA) scheme, in which the cloud server is allowed to generate proof of possession of data, and an auditor can check the correctness of the proof. The CPA scheme is built on top of the CPV scheme. In this section, we simply review the CPV scheme.

Five entities are involved in their construction:

• Key generation center (KGC): the KGC is the trusted entity that generates the system parameters and partial public/private key pairs to all other four entities according to their registration.
• Data owner: a data owner represents the patient who collects his/her healthcare data and uploads the EHR data to the cloud server for storage.
• User: a user could be a doctor or a medical researcher who wants to query the patient’s EHR data.
• Medical cloud server (MCS): the MCS is managed by the cloud service provider. It stores a large amount of EHR data sent by the users.
• Third-party auditor (TPA): assigned by the data owner, a TPA is responsible for auditing the integrity of the stored EHR data. This is achieved by sending the audit challenge message to the server, and then the server replays back with a proof message.

We now describe Benil et al.’s CPV scheme, which consists of nine algorithms. Note that, in essence, the CPV scheme is a CLAS scheme. We use the same symbols as in their construction:

• Setup:
  • Choose a composite-order bilinear group [24] and a mapping $e:\mathbb{G}\times \mathbb{G}\to {\mathbb{G}}_T$. Let q and P be the order and a generator of $\mathbb{G}$, respectively.
  • Select $x\in Z_q^{*}$ as the system master private key and compute the corresponding master public key $P_{Pub}=xP$.
  • Let $H_1:{\{0,1\}}^{*}\times \mathbb{G}\times \mathbb{G}\to {\mathbb{Z}}_q^{*}$, $H_2:{\{0,1\}}^{*}\times \mathbb{G}\times \mathbb{G}\to {\mathbb{Z}}_q^{*}$, and $H_3:{\{0,1\}}^{*}\times \mathbb{G}\times \mathbb{G}\to {\mathbb{Z}}_q^{*}$ be three cryptographic hash functions.
  • Keep x as private and publish the system parameters as $S_{para}=\{e,q,P,P_{Pub},H_1,H_2,H_3\}$.
• Partial-Private-Key Generation:
  • Server partial private-key generation: it takes $S_{para}$, the identity of cloud server $ids$ and x as input. The KGC randomly selects $r_{ids}\in Z_q^{*}$ and computes $R_{ids}=r_{ids}P$, $h_{ids}=H_1(R_{ids}\left|\right|ids\left|\right|P_{ids})$, and $d_{ids}=r_{ids}+h_{ids}x$. It then outputs and sends $d_{ids},R_{ids}$ to the cloud server.
  • Data owner partial private-key generation: it takes $S_{para}$, the identity of data owner $ido$, and x as input. The KGC randomly selects $r_{ido}\in Z_q^{*}$ and computes $R_{ido}=r_{ido}P$, $h_{ido}=H_1(R_{ido}\left|\right|ido\left|\right|P_{ido})$, and $d_{ido}=r_{ido}+h_{ido}x$. It then outputs and sends $d_{ido},R_{ido}$ to the data owner.
  • User partial private-key generation: it takes $S_{para}$, the identity of user $idu$ and x as input. The KGC randomly selects $r_{idu}\in Z_q^{*}$ and computes $R_{idu}=r_{idu}P$, $h_{idu}=H_1(R_{idu}\left|\right|idu\left|\right|P_{idu})$, and $d_{idu}=r_{idu}+h_{idu}x$. It then outputs and sends $d_{idu},R_{idu}$ to the user.
• Set-Secret-Value:
  • Set the secret value of the server: the server randomly chooses its secret value $Y_{ids}\in Z_q^{*}$.
  • Set the secret value of the data owner: the data owner randomly chooses its secret value $Y_{ido}\in Z_q^{*}$.
  • Set the secret value of the user: the user randomly chooses its secret value $Y_{idu}\in Z_q^{*}$.
• Set-Private-Key:
  • Set the private key of the server: the server takes $S_{para}$, $d_{ids}$, and $Y_{ids}$ as input. Then its private key is $d{k}_{ids}=(ids,x_{ids})$.
  • Set the private key of the data owner: the data owner takes $S_{para}$, $d_{ido}$, and $Y_{ido}$ as input. Then its private key is $d{k}_{ido}=(ids,x_{ido})$.
  • Set the private key of the user: the user takes $S_{para}$, $d_{idu}$, and $Y_{idu}$ as input. Then its private key is $d{k}_{idu}=(idu,x_{idu})$.
• Set-Public-Key:
  • Set the public key of the server: taking as input $S_{para}$ and $Y_{ids}$, the server computes $P_{ids}=Y_{ids}P$. The public key of the server is $P{K}_{ids}=(P_{ids},Y_{ids})$.
  • Set the public key of the data owner: taking as input $S_{para}$ and $Y_{ido}$, the data owner computes $P_{ido}=Y_{ido}P$. The public key of the server is $P{K}_{ido}=(P_{ido},Y_{ido})$.
  • Set the public key of the user: taking as input $S_{para}$ and $Y_{idu}$, the data owner computes $P_{idu}=Y_{idu}P$. The public key of the server is $P{K}_{idu}=(P_{idu},Y_{idu})$.
• Sign: the user with identity $idu$ takes $S_{para}$, $Y_{idu}$, and the state information $\Delta$, and $d{K}_{idu}$ as input. To sign a message M, it performs the following:
  • Choose $r_i\in Z_q^{*}$ and compute $R_{id}=r_{id}P$.
  • Compute $B=H_2(\Delta )$ and $h_i=H_3({idu}_i\left|\right|M_i\left|\right|P{K}_{idu,i}\left|\right|R_i)$.
  • Compute $V_i=d_{idu}+r_{i}BM+h_i{Y}_{idu}{P}_{Pub}$.
  • Output the signature $\sigma =(R_i,V_i)$.
  Then the user uploads the message-signature pair to the cloud server. The server then verifies its validity via Verify.
• Verify: it takes as input $S_{para}$, $\sigma =(R_i,V_i)$, and $(M_i,\Delta ,P{K}_{id},T)$ as input. The server first computes $(h_{idu},B,h_i)$ as the same as in Sign. Then it check whether $e(V_i,P)$ = $e(h_{idu}{R}_{idu}+h_i{P}_{Pub}{P}_{idu})e(r_{i}P,B{M}_i)$ holds. It accepts the signature if the verification equation holds and rejects otherwise.
• Aggregate: it takes as input $S_{para}$, $\Delta$, and n distinct signatures ${\sigma }_i$, $i=1,\dots ,n$ on different messages $M_i$ from different users with corresponding identities ${idu}_i$ and public keys $P{K}_{idu,i}$. The aggregator computes $V={\sum }_{i=1}^n{V}_i$ and outputs $({\{Y_{id},M_i,P_{idu},R_i\}}_{i=1}^n,\Delta ,V)$ as the aggregate signature for n messages.
• Aggregate-Verify: taking as input $S_{para}$, $({\{Y_{id},M_i,P_{idu},R_i\}}_{i=1}^n,\Delta ,V)$, and tuples $({idu}_i,{P{K}_{idu}}_i)$ for $i=1,2,\dots ,n$, it operates as follows:
  • Compute $h_{idu}=H_1(R_{idu}\left|\right|idu\left|\right|P_{idu})$, $B=H_2(\Delta )$, and $h_i=H_3(id{u}_i\left|\right|M_i\left|\right|P{K}_{idu,i}\left|\right|R_i)$.
  • Check whether $e(V,P)=e\left({\sum }_{i=1}^n(h_{idu}{R}_{idu}+h_i{P}_{Pub}{P}_{idu})\right)·e\left({\sum }_{i=1}^n\left(r_{i}PB{M}_i\right)\right)$ holds.
  • Return true if the above equation holds and return false otherwise.

4.2. Scheme Analysis

We show some drawbacks of Benil et al.’s CPV scheme, which will break its correctness.

• According to the role definition, Sign should be executed by the data owner (i.e., the patient) rather than the user (e.g., the doctor).
• The calculation of partial private-key generation for the server, the data owner, and the user may be wrong. In Partial-Private-Key-Generation (i.e., the second algorithm in the scheme), to generate a partial private key for the server, the KGC randomly selects $r_{ids}\in Z_q^{*}$ and computes $R_{ids}=r_{ids}P$, $h_{ids}=H_1(R_{ids}\left|\right|ids\left|\right|P_{ids})$. It then computes and sets $d_{ids}=r_{ids}+h_{ids}x$ as the server’s partial private key. In this process, the KGC needs to use $P_{ids}$ for obtaining $h_{ids}$; however, the value $P_{ids}$ is not defined before. The same problem occurs when generating the partial private keys for the data owner and the user.
• The setting when generating private keys for the server, the data owner, and the user may be wrong. To generate its private key, the server takes the system parameters $S_{para}$, the partial private-key $d_{ids}$, and the secret value $Y_{ids}$ as input and sets its private key as $d{k}_{ids}=(ids,x_{ids})$. However, $x_{ids}$ is not defined before. Moreover, the partial private-key $d_{ids}$ does not seem to be used for constructing the full private key. The same problem occurs when setting the partial private keys for the data owner and the user.
• The setting when generating public keys for the server, the data owner, and the user may be wrong. To set the public key of the server, the algorithm Set-Public-Key takes as input the system public parameters $S_{para}$ and a secret value $Y_{ids}$ chosen by the server in Set-Secret-Value. It computes $P_{ids}=Y_{ids}P$, and the public key of the server is $P{K}_{ids}=(P_{ids},Y_{ids})$. In this setting, the secret value is a part of the public key, which may affect the security of the scheme.
• There are some undefined definitions in the signing process. In Sign, a piece of state information $\Delta$ and a value T are bound to the signature. One may infer that T is the timestamp; however, one cannot guess what state information $\Delta$ is used to store. Additionally, the signer needs to compute $R_{id}=r_{id}P$. However, neither $R_{id}$ nor $r_{id}$ has been defined. According to the description of Sign and Verify, the equation should be $R_i=r_{i}P$.
• The verification equation in Verify does not hold. In the CPV scheme, a single signature for a message is valid if the verification equation $e(V_i,P)$ = $e(h_{idu}{R}_{idu}+h_i{P}_{Pub}{P}_{idu})e(r_{i}P,B{M}_i)$ holds. The authors in [19] claimed its correctness as follows:

  $$\begin{array}{cc}\hfill e(V_i,P)& =e(d_{idu}+r_{i}B{M}_i+h_i{Y}_{idu}{P}_{Pub},P)\hfill \\ \hfill & =e(d_{idu},P)·e(r_{i}B{M}_i,P)·e(h_i{Y}_{idu}{P}_{Pub},P)\hfill \\ \hfill & =e(r_{idu}+h_{idu}x,P)·e(r_{i}B{M}_i,P)·e(h_i{Y}_{id}{P}_{Pub},P)\hfill \\ \hfill & =e(h_{idu}x,r_{idu}P)·e\left(xP\right)·e(r_{i}P,B{M}_i)·e(h_i{Y}_{id}P,P_{Pub})\hfill \\ \hfill & =e(h_{idu},R_{idu})·e\left(P_{Pub}\right)·e(r_{i}P,B{M}_i)·e(h_i{P}_{idu},P_{Pub})\hfill \\ \hfill & =e\left(h_{idu}{R}_{idu}{P}_{Pub}\right)·e(r_{i}P,B{M}_i)·e(h_i{P}_{Pub},P_{idu})\hfill \\ \hfill & =e(h_{idu}{R}_{idu}+h_i{P}_{Pub}{P}_{idu})e(r_{i}P,B{M}_i).\hfill \end{array}$$
  However, the equation does not hold from the fourth line according to the computation rule of bilinear pairing [25], which disproves their claim. The same error exists in Aggregate-Verify.

Obviously, the above analysis shows the proposed CPV scheme is incorrect. It is also for this reason that we do not offer any suggestions for the scheme’s improvement. Moreover, since the CPA scheme is built on top of the CPV scheme, its correctness also cannot be guaranteed.

Real-world dangers. Our analysis shows that the proposed protocol fails to achieve correctness. This means that it cannot achieve the security and privacy properties claimed by Benil et al. If the scheme in [19] is adopted in reality, the patient’s privacy-sensitive EHR data will be exposed to unprotected environments. For example, because the CPV scheme loses its function, the authenticity and integrity of the shared EHR data cannot be assured. In this situation, malicious entities may tamper with the real data. Moreover, this may mislead doctors to make an incorrect diagnosis, which is extremely dangerous for the patient’s life.

5. Conclusions

In this work, we analyzed two recent privacy-preserving authentication schemes for smart healthcare applications, i.e., Ogundoyin et al.’s PAASH in [2] and Benil et al.’s ECACS scheme in [19]. More concretely, we observed that the underlying CLAS scheme in PAASH construction cannot achieve correctness and unforgeability. We found that the batch verification process in their CLAS scheme was incorrect because the verification equation cannot be validated. In addition, our attack showed that any Type I attacker can impersonate a patient to forge a valid signature on his false healthcare information, which may lead healthcare professionals to make incorrect diagnoses of a patient’s health condition. We discussed the reason for our attack and suggested an improved PAASH${}^{+}$ scheme, which overcomes the design flaws of PAASH and simultaneously achieves aggregate authentication, fine-grained access control, and data confidentiality. In addition, we demonstrated that Benil et al.’s ECACS scheme had many drawbacks and was incorrect. Our analysis showed that both the above two recent schemes are not suitable to be deployed in practical smart health applications. We hope our analysis will improve the design of such schemes in future work.