CDAKA: A Provably-Secure Heterogeneous Cross-Domain Authenticated Key Agreement Protocol with Symptoms-Matching in TMIS

Abstract

Telecare Medical Information System (TMIS) provides the flexible and convenient e-health care. It helps the patients to gain health monitoring information and provides patients to share their experience wirelessly. Traditional authentication and key agreement (AKA) protocols in TMIS are mostly considered in same-domain environment. However, future generation network may integrate various of wireless mesh networks under various domain. What’s more, patients heterogeneous cross-domain service has become an inevitable trend. However, there is still no heterogeneous cross-domain authenticated protocol between PKI-domain and IBC-domain in TMIS. In this paper, we propose a heterogeneous cross-domain AKA protocol with symptoms-matching in TMIS (short for CDAKA). It not only keeps good security features, but also truly provides patients’ anonymity to protect sensitive information from illegal interception. It still provides patients in two different domains to share their experience, broaden their understanding of illness by using their mobile device freely. Besides, it can realize AKA with extremely low computing cost and communication cost. What’s more, it is proved to be secure against known possible attacks under the Elliptic Curve Computable Diffie-Hellman problem (ECDHP) assumption in the random oracle model. Hence, these features make CDAKA protocol very suitable for mobile application scenarios, where resource is severely constrained and security is particularly concerned.

Introduction

Aging is a universal phenomenon affecting all countries, although its dynamic can be different in each. According to the lasted census report, the population of the world is on the trend of aging rapidly, where more than 12.3% of the world’s population are over 60 years old, partly due to a longer life span but declining birth rate. It is predicted that the population over 60 will exceed the ones under 15 by 2050. Further, the incidence of mortality rate among the elderly people is much higher than non-elderly ones [1]. Meanwhile, elderly people are suffering from different chronic conditions and disability. Hence, using health care services will be a necessity of life. For example, the US will need to hire 2.3 million new health care workers by 2025 in order to adequately take care of its aging population, a new report finds (http://money.cnn.com/2018/05/04/news/economy/health-care-workers-shortage/index.html). It is no doubt that the demand of medical service is increasing, not just for the US, but the world.

The rapid development of mobile Internet has greatly changed our daily life, especially in Telecare Medical Information System (TMIS). In TMIS, the patients can receive professionals symptom diagnosis from the health care providers to direct their treatment. On the other hand, these patients also have the intention to communicate with other patients who have the same symptom. Then, they want to build a symptom-matching based communication to facilitate the illness-related information exchange, treatment experience sharing and specialist doctor recommendation. Besides, they may chat with each other to talk about their real-time illness conditions and encourage each other to overcome the disease, regardless of the patients’ locations and conditions. Sometimes, self-confidence is more effective than drugs in patients’ conditions.

Traditional authentication and key agreement (AKA) protocols in TMIS are mostly considered in same-domain environment. In same-domain environment (Public Key Infrastructure-PKI or Identity Based Cryptography-IBC), several session keys can be easily established by real world meeting. They actually have to stay in the same hospital for the treatment. However, no opportunity is offered for them to meet in the real life. Actually, the patients are always physically affiliated to different medical domains. Those with the same symptoms most likely come from various medical institutions in different cities or even different countries. What’s more, the patients with some rare diseases could hardly find the fellow sufferers in the same area [2]. Let’s consider a scenario, as shown in Fig. 1b. A patient PA_i in PKI-domain needs to share his/her treatment experience with the other patient PA_j in IBC-domain multiple times in a short time and requests a secure communication service. Additionally, PA_i needs to communicate with the trusted authority (IBC) in IBC-domain, which further communicates with the trusted authority PKI. As a consequence, trusted authorities PKI and IBC will easily become the bottleneck of the system. The involvement of the trusted authorities in both domains also increases the authentication delay. Hence, they do not reach the case. (The CDAKA protocol is even simpler for this case on each short time, as shown in Fig. 1c.) Therefore, it is very important and urgent to design heterogeneous cross-domain authenticated key agreement mechanism to provide the interactions with different domain patients.

Fig. 1

Architecture for accessing cross-domain medical service in TMIS

On the other hand, most of medical datas are transmitted and exposed during the unsecured-public communication channel, the patient’s privacy is susceptible to be divulged. Most patients in TMIS are connected with each other wirelessly. Then, the adversaries may eavesdrop, intercept, delete, and modify all messages in the common communication channel. Hence, it is easily overlooked when the origin of data is traced. Specifically, the patients locations, jobs, and home addresses can be acquired and the habits and tastes can be derived immediately. It also largely reduces the difficulty of guessing the patients’ real identities. When the least expected thing happens, unauthorized adversaries may get access to the patients current health condition, medical history and other binding information like mobile phone number and credit card number. Undoubtedly, the patient will suffer much more than the illness itself. Considering the worst condition, if the adversary has an attempt at harming the patient, he may modify the patients vital health information. And when these modified messages are transmitted to their sick friends, wrong information can be made and the patients life may be threatened [3, 4]. Obviously, patient’s privacy protection has not been adequately addressed and it is still an urgent demanding in medical environment. The protocols designed for TMIS should take patients’ privacy-protection into account.

Our contributions

In the CDAKA protocol, the patient $PA_{i}$ in PKI-domain can remotely communicate with the other patient $PA_{j}$ who is in IBC-domain by themselves without the help of their registration centers. It perfectly eliminates the bottlenecks of systems. Hereafter, $PA_{i}$ and $PA_{j}$ not only realize mutual authentication but also establish a session key. Compared with [5, 6], the CDAKA protocol not only needs lower computational consumption, but also can provide the following security features.

• First, the CDAKA protocol not only can provide patient’s anonymity to protect patient’s privacy by randomized-dual pseudonym $PID_{i}(PID_{j})$, but also can provide patient’s traceability if necessary. When a patient $PA_{i}$(PA_j) sends the false messages to deceive others, PKI(IBC) extracts $PA_{i}$’s(PA_j’s) static anonymous identity $pid_{i}$(pid_j) from randomized-dual pseudonym $PID_{i}(PID_{j})$ and obtains $PA_{i}$’s(PA_j’s) real identity by decrypting $pid_{i}$ using its private key. Besides, the register center PKI in PKI-domain and register center IBC in IBC-domain, no one can obtain the others’ real identities. Hence, the CDAKA protocol is practical in the privacy-enhanced scenarios.

• Second, the CDAKA protocol can truly realize heterogeneous cross-domain authentication and obtain the session key among the mobile terminal patients in different remote medical domains. The entire process only costs two-round communications with low computation cost and communication cost. Hence, the CDAKA protocol is very simple, efficient and energy-saving and it is very suitable for computation-limited mobile devices.

• Third, the CDAKA protocol based on certificateless cryptography can overcome the key escrow problem of identity-based public key cryptography. The patients’ full private keys consist of two parts: the secret information chosen by patients themselves and the partial private keys generated by registration centers. It properly resolves the complicated certificate management problems in traditional public key infrastructure system.

• Fourth, the CDAKA protocol is proved to be secure under the Elliptic Curve Computational Diffie-Hellman problem (ECDHP) assumption in the random oracle model. The CDAKA protocol is proved secure against possible known attacks and satisfy the secure requirements of AKA protocols for heterogeneous cross-domain architecture. Hence, the CDAKA protocol is practical in complex network environment.

Related works

For better efficiency and accuracy, authentication has become an essential mechanism to assure the distributed systems’ security and privacy from malicious adversaries. Due to the widespread applications of Internet and the great convenience of remote medical services, how to securely access the remote medical servers and get the corresponding service has received considerable attention. In recent years, various remote AKA protocols are successively proposed in TMIS [7,8,9,10,11,12,13].

Wu et al. [7] first proposed a novel authentication protocol for TMIS. However, it was vulnerable to insider attack and impersonation attack [8]. Later, Wei et al. [9] pointed out that the both protocols in [7] and [8] failed to meet multi-factor authentication and further proposed an improved protocol. Thereafter, Zhu et al. [10] described Wei et al.’s protocol [9] was vulnerable to off-line password guessing attack. Then, Lee-Liu [11] demonstrated that the new protocol in [10] could not withstand parallel session attack and presented an improved one. In 2013, Tan et al. [12] proposed an efficient biometrics-based authentication scheme for TMIS, which was claimed to resist many kinds of attacks. However, Yan et al. [13] declared that the protocol in [12] was vulnerable to DoS attack. In 2017, Zhang et al. [4] proposed a privacy protection dynamic authentication based on three-factor for TMIS. Later, Chaudhry et al. [14] proposed a lightweight authentication based on three-factor for TMIS. However, all schemes above are suitable for single-medical server in same-domain environment.

In 2015, Amin et al. [15] first proposed a novel AKA protocol for accessing remote multi-medical server in TMIS, which was claimed to resist many kinds of attacks. However, Amin et al.’s scheme [15] was vulnerable to internal attack, replay attack and the man-in-middle attack [16]. In 2017, Liu et al.’s [17] pointed out that the protocol in [16] still suffered from internal attack, impersonation attack and stolen smart card attack. Although, these protocols are suitable for multi-medical servers, they are still only for same-domain environment.

In previous years, researchers have presented several cross-domain authenticated key agreement schemes. In 2010, Sun et al. [18] proposed a scheme between PKI and IBC, but their scheme was vulnerable to insider attacks. Later, Huang et al. [19] proposed another scheme based on heterogeneous systems. However, their scheme could not deliver messages from PKI to IBC. In order to compensate for these loopholes, Li et al. [23] proposed a truly scheme between PKI and IBC, where the messages can be transmitted not only from PKI to IBC but also from IBC to PKI. Thereafter, several cross-domain protocols and models are proposed in [2, 5, 23,24,25,26,27]. However, they are managed by one trusted authority(TA) as shown in Fig. 1a. The TA needs to participate in each registration and authentication processes and is possible for the system bottleneck.

Moreover, in the PKI system, the certificate authority (CA) is responsible to distribute, storage, verify and revoke the certificate, which brings a high management cost. In IBC system, each user has an identity and the secret keys of all users are generated by a key generation center (KGC). The identity based cryptosystem will be broken easily if the storage server of KGC is hacked since all the users secret keys are escrowed to KGC. The certificateless cryptography authentication system does not require the certificate system and solves the key escrow problem since the KGC only knows part of the secret key of user. It admirably avoids the disadvantages of PKI and IBC. Some signcryption schemes from IBC to certificateless public key infrastructure (CLPKI) was proposed in [2, 5, 9, 20,21,22,23].

However, there is still no certificateless heterogeneous cross-domain authenticated key agreement protocols between PKI-domain and IBC-domain applied to TMIS. It becomes a big obstacle for the patients from PKI-domain and IBC-domain to connect with each other for some help. Although, Yuan et al. [6] proposed a heterogeneous cross-domain authenticated key agreement protocol, as shown in Fig. 1b, it needs heavy calculations because of the public encryption/signature algorithms or other time-consuming computation (such as bilinear pairing). What’s more, trusted authorities need to take apart in registration phase and AKA phase. As a consequence, it will easily become the bottleneck of the system. Therefore, it is not suitable for the energy-limited mobile devices. Consider a huge number of mobile terminal patients have limit computation and energy (battery-powered), they frequently login through a remote terminal according to their needs. The low energy remote AKA protocols are urgently required. Therefore, it is unsurprising that constructing the efficient and energy-saving AKA protocols keep pace with the development of the mobile Internet. In this paper, a novel heterogeneous cross-domain authenticated key agreement protocol with symptoms-matching in TMIS is proposed.

Organization

The rest of paper is organized as follows. Some mathematical preliminaries about ECDHP is introduced in “Mathematical preliminaries”. “Adversarial model” briefly reviews adversarial model and the CDAKA protocol is presented in “Network frame of CDAKA protocol”. Detailed security analysis and proof are given in “Security analysis and proof of CDAKA protocol”. The comparisons of the performance and security features between CDAKA protocol with other related schemes are discussed in “Performance evaluation”. “Conclusion and ongoing work” concludes this paper.

Mathematical preliminaries

Let P be a large prime number. An elliptic curve $E(F_{P})$ over the finite field $F_{P}$ is defined by the equation: $y^{2}=x^{3}+\alpha \cdot x+\beta$ mod P, where α,β ∈ F_P and $\bigtriangleup = 4\alpha ^{3}+ 27\beta ^{2}\neq 0$ mod P. All points on $E(F_{P})$ are form an additive group $G_{1}$ [5, 23].

Elliptic Curve Computable Diffie-Hellman problem (ECDHP):

Choose $G_{1}$ as an additive cyclic group generated by P, whose order is a prime q. Given (P,aP,bP)∈ G₁ for any unknown $a, b\in Z^{*}_{q}$, , the goal of the ECDHP is to compute $abP$. Define the advantage of any probabilistic polynomialłtime algorithm $\mathscr{A}$ against ECDHP in $G_{1}$. For every probabilistic $\mathscr{A}$, the advantage is negligible, which will be used in the security analysis of our proposed CDAKA protocol.

Adversarial model

There are two types adversaries who have different abilities considered in certificateless cryptography: Type-I $\mathscr{A}_{I}$ and Type-II $\mathscr{A}_{II}$[2, 21, 28, 29].

Type-I $\mathscr{A}_{I}$:$\mathscr{A}_{I}$ dose not have access to the master-key. However, $\mathscr{A}_{I}$ may request public keys, replace public keys with values of its choice, extract partial private and private keys and make decryption queries, all for identities of its choice. Some natural restriction on $\mathscr{A}_{I}$ are as follows:

• $\mathscr{A}_{I}$ cannot extract the private key for challenge identity at any point.

• $\mathscr{A}_{I}$ cannot request the private key for any identity if the corresponding public key has already been replaced.

• $\mathscr{A}_{I}$ cannot both replace the public key for the challenge identity before the challenge phase and extract the partial private key for challenge identity in some phase.

• In Phase 2, $\mathscr{A}_{I}$ cannot make a decryption query on the challenge ciphertext for the combination of challenge identity and public key that was used to encrypt plaintext.

Type-II $\mathscr{A}_{II}$: The master-key is possessed by $\mathscr{A}_{II}$. But he has no ability to replace the public key of any user. Adversary $\mathscr{A}_{II}$ can compute partial private keys for itself, given master-key. It can also request public keys, make private key extraction queries and decryption queries, both for identities of its choice. The restrictions on this type of adversary are:

• $\mathscr{A}_{II}$ cannot replace public keys at any point.

• $\mathscr{A}_{II}$ cannot extract the private key for challenge identity at any point.

• In Phase 2, $\mathscr{A}_{II}$ cannot make a decryption query on the challenge ciphertext for the combination of challenge identity and public key that was used to encrypt plaintext.

Network frame of CDAKA protocol

The CDAKA protocol is composed of Registration phase, Login phase and Authentication and Key agreement phase. To simplify the subsequent description, some symbol notations are given in Table 1. Figure 1c simply depicts the heterogeneous cross-domain authentication model. At the beginning, each domain sets up their systems:

Table 1 Symbol notations

In the PKI-domain, PKI randomly selects its private key $\omega$, where $\omega \in Z^{*}_{q}$ and computes the corresponding public key $Pub_{i}=\omega P$. PKI chooses three cryptographically secure one-way hash functions $H_{i}(\cdot )$: $\{0,1\}^{*}\rightarrow Z^{*}_{q}$ and $i=\{1,2\}$, $H_{3}(\cdot )$: $\{0,1\}^{*} \rightarrow \{0,1\}^{l}$. PKI chooses a cryptographic symmetric encryption/decryption pair $E(\cdot )/ D(\cdot )$ with symmetric key. Then, PKI publishes {q,P,E(⋅)/D(⋅),Pub_i,H₁,H₂,H₃} and saves $\omega$ secretly.

In the IBC-domain, IBC randomly selects its private key s, where $s\in Z^{*}_{q}$ and computes the corresponding public key $Pub_{j}=sP$. IBC chooses three cryptographically secure one-way hash functions $H_{i}(\cdot )$: $\{0,1\}^{*}\rightarrow Z^{*}_{q}$ and $i=\{1,2\}$, $H_{3}(\cdot )$: $\{0,1\}^{*}\rightarrow \{0,1\}^{l}$. IBC chooses a cryptographic symmetric encryption/decryption pair $E(\cdot )/D(\cdot )$ with symmetric key. Then, IBC publishes $\{q, P, E(\cdot )/D(\cdot ), Pub_{j}, H_{1}, H_{2}, H_{3}\}$ and saves s secretly.

Registration phase

Patient P A _i in PKI-domain registration phase

When a patient $PA_{i}$ in PKI-domain wants to access medical services in the system, he/she should register in PKI firstly. The following steps run between $PA_{i}$ and PKI as shown in Fig. 2.

Ri1:

$PA_{i}$ chooses his/her $ID_{i}$ and a random number $x_{i}\in Z^{*}_{q}$ and computes $P_{i}=x_{i}P$. Then, $PA_{i}\Rightarrow PKI$: $(ID_{i}, P_{i}, S_{i})$;

Ri2:

Upon receiving the registration message from $PA_{i}$, PKI chooses random value $\xi _{i}, r_{i}\in Z^{*}_{q}$, computes $pid_{i}=E_{\omega }(ID_{i},\xi _{i}, S_{i})$, $R_{i}=r_{i}P$, $\alpha _{i}=H_{1}(pid_{i}||P_{i}||R_{i}||S_{i})$, $y_{i}=\alpha _{i}\omega +r_{i}$ and stores $pid_{i}$ in its database. Then, $PKI\Rightarrow PA_{i}$: $(pid_{i}, R_{i}, y_{i})$;

Ri3:

After receiving the message $(pid_{i}, R_{i}, y_{i})$ from PKI, $PA_{i}$ checks $y_{i}P?=\alpha _{i}Pub_{i}+R_{i}$. If the verification fails, the request is rejected. Otherwise, $PA_{i}$ stores secret key $sk_{i}=(x_{i}, y_{i})$ securely and airs public key $pk_{i}=(P_{i}, R_{i})$.

Fig. 2

Patient PA_i in PKI-Domain registration phase

Patient P A _j in IBC-domain registration phase

When a patient $PA_{j}$ in IBC-domain wants to access medical services in the system, he/she should register in IBC firstly. The following steps run between $PA_{j}$ and IBC as shown in Fig. 3.

Rj1:

$PA_{j}$ chooses his/her $ID_{j}$. Then, $PA_{j}\Rightarrow IBC$: $(ID_{j}, S_{j})$;

Rj2:

Upon receiving the registration message from $PA_{j}$, IBC selects random value $\xi _{j}\in Z^{*}_{q}$, computes $pid_{j}=E_{s}(ID_{j},\xi _{j}, S_{j})$, $r_{j}=H_{2}(ID_{j})$, $R_{j}=r_{j}P$, $\alpha _{j}=H_{1}(pid_{j}||R_{j}||S_{j})$, $y_{j}=\alpha _{j}s+r_{j}$ and stores $pid_{j}$ in its database. Then, $IBC\Rightarrow PA_{j}$: $(pid_{j}, R_{j}, y_{j})$;

Rj3:

After receiving the message $(pid_{j}, R_{j}, y_{j})$ from IBC, $PA_{j}$ checks $y_{j}P?=\alpha _{j}Pub_{j}+R_{j}$. If the verification fails, the request is rejected. Otherwise, $PA_{j}$ selects a random number $x_{j}\in Z^{*}_{q}$, computes $P_{j}=x_{j}P$, stores secret key $sk_{j}=(x_{j}, y_{j})$ and airs public key $pk_{j}=(P_{j}, R_{j})$.

Fig. 3

Patient PA_j in IBC-Domain registration phase

Login phase

When $PA_{i}$ and $PA_{j}$ want to establish a session key to exchange status about their illness and share their positive experience of treatment, they will compute α_i = H₁(pid_i||P_i||R_i||S_i) and $\alpha _{j}=H_{1}(pid_{j}||R_{j}||S_{j})$ respectively, exchange $\{\alpha _{i}, Pub_{i}, P_{i}, R_{i}, S_{i}\}$ and {α_j,Pub_j,P_j,R_j,S_j} preferentially to achieve mutual authentication. After receiving the interactive messages, they first check $S_{i}?=S_{j}$. If it does not match, terminate the session. Otherwise, do the following steps as shown in Fig. 4:

L1:

$PA_{i}$ selects random value $a_{i}\in Z^{*}_{q}$, reads the current time ${T^{1}_{i}}$ and computes $M_{i1}=(\alpha _jPub_j+P_j+R_j)(x_i+y_i)$, $M_{i2}=M_{i1}\oplus a_iP$, $PID_i=H_3(M_{i1}||M_{i2})\oplus pid_i$, $M_{i3}=H_3(pid_i||Pub_i||P_i||R_i||Pub_j||P_j||R_j||T^{1}_i)$, $M_{i4}=H_3(M_{i1}||M_{i2}||M_{i3}||a_iP||pid_i)$. Then,$PA_{i}\rightarrow PA_j : \mathbf {msg1}=\{PID_i, M_{i2}, M_{i4}, T^{1}_i\}$.

Fig. 4

Authentication and key agreement phase

Authentication and key agreement phase

V1:

Upon receiving msg1, $PA_j$ reads the current time $T^{1}_j$, checks $|T^{1}_j-T^{1}_i|?\leq {\Delta } T$ and the pair $(PID_i, M_{i2})$ according to $PID_i$. If that above verifications do not hold, the login request is rejected. Otherwise; $PA_j$ computes, $M_{j1}=(\alpha _iPub_i+P_i+R_i)(x_j+y_j)$, $a_iP=M_{j1}\oplus M_{i2}$, $pid_i=PID_i\oplus H_3(M_{j1}||M_{i2})$, $M_{j3}=H_3(pid_i||Pub_i||P_i||R_i||Pub_j||P_j||R_j||T^{1}_i)$, and checks $M_{j4}?=H_3(M_{j1}||M_{i2}||M_{j3}||a_iP||pid_i)$. If the equality is not established, the login request is rejected. Otherwise;

V2:

$PA_j$ replaces the $M_{i2}^{old}$ with $M_{i2}$, stores the pair $(PID_i, M_{i2})$ in database, generates a random value $a_j$, reads the current time $T^{2}_j$, and computes $M_{j5} = M_{j1}\oplus a_jP$, $PID_j=H_3(M_{j1}||M_{j5})\oplus pid_j$, SK_ij = H₃(M_j1||pid_i||pid_j||Pub_i||Pub_j||a_iP||a_jP||a_ia_jP), $M_{j6}=H_3(SK_{ij}||M_{j5}||a_iP||a_jP||T^{2}_j)$. Then, $PA_j\rightarrow PA_i : \mathbf {msg2}=\{PID_j, M_{j5},M_{j6}, T^{2}_j\}$;

V3:

Upon receiving msg2, $PA_i$ reads the current time $T^{2}_i$, checks $|T^{2}_i-T^{2}_j|?\leq {\Delta } T$ and checks the pair $(PID_j, M_{j5})$ according to $PID_j$. If that above verifications do not hold, the authentication request is rejected. Otherwise; $PA_i$ replaces the $M_{j5}^{old}$ with $M_{j5}$, stores the pair $(PID_j, M_{j5})$ in database, computes $a_jP=M_{j5}\oplus M_{i1}$, $pid_j=PID_j\oplus H_3(M_{j1}||M_{j5})$, $SK_{ij}=H_3{}({}M_{{}j1}|{\kern -.5pt}|pid_i|{\kern -.5pt}|pid_j|{\kern -.5pt}|P{\kern -.5pt}ub_i|{\kern -.5pt}|P{\kern -.5pt}ub_j|{\kern -.5pt}|a_iP|{\kern -.5pt}|a_jP|{\kern -.5pt}|a_ia_jP)$, and checks $M_{j6}?=H_3(SK_{ij}||M_{j5}||a_iP||a_jP||T^{2}_j)$. If it is not equal, the session is terminated. Otherwise, $PA_j$ is authenticated by $PA_i$. At last, $PA_i$ and $PA_j$ share the session key $SK_{ij}$.

Security analysis and proof of CDAKA protocol

In this section, we will analyze the security of the CDAKA protocol under the same adversary model mentioned in “Adversarial model”.

Security analysis

Completeness and mutual authentication and key agreement

In the CDAKA protocol, all the authentication information (M_i2,M_i4,M_j5,M_j6) are based on secret value $M_{i1}(M_{j1})$,

$$\begin{array}{@{}rcl@{}} M_{i1}&=&(\alpha_jPub_j+P_j+R_j)(x_i+y_i)=(y_jP+P_j)(x_i+y_i)\\\ &=&(y_jP+x_jP)(x_i+y_i)\\ M_{j1}&=&(\alpha_iPub_i+P_i+R_i)(x_j+y_j)=(y_iP+P_i)(x_j+y_j)\\ &=&(y_iP+x_iP)(x_j+y_j) \end{array} $$

(Here, $y_i=\alpha _i\omega +r_i$, $y_iP=\alpha _iPub_i+R_i$ and $y_j=\alpha _js+r_j$, $y_jP=\alpha _jPub_j+R_j$), which is only shared between $PA_i$ and $PA_j$, which anyone cannot obtain it except $PA_i$ and $PA_j$. In the whole protocol as shown in Fig. 4, $PA_i$ authenticates $PA_j$, and $PA_j$ authenticates $PA_i$. In the end, they share a session key $SK_{ij}$. Hence, the CDAKA achieves mutual authentication and key agreement.

Patient anonymity

The CDAKA protocol adopts the anonymous blind identities $PID_i=H_3(M_{i1}||M_{i2})\oplus pid_i$ and $PID_j=H_3(M_{j1}||M_{j5})\oplus pid_j$ instead of the static identity $ID_{i}$ and $ID_{j}$ in the public communication channel. Meanwhile, they are differen in each run. Here, $pid_{i}={E}_{\omega }(ID_{i},\xi _{i}, S_{i})$ and $pid_{j}=E_{s}(ID_{j},\xi _{j}, S_j)$. By using a secure cryptographic symmetric encryption, the malicious adversary $\mathscr{A}$ cannot extract the $ID_i$ and $ID_j$ without knowing $\omega$ or s required to successfully decrypt the ciphertext. Further, in the CDAKA protocol, the patients $PA_i$ and $PA_j$ cannot know the others’ real identity either. In this way, the CDAKA protocol provides patient anonymity, which can prevent the privacy leakage of patient identity.

Patient traceability

If a patient $PA_i$ sends same false messages to deceive others, PKI or IBC can extract real identity of $PA_i$ or $PA_j$ by decrypting $pid_i$ or $pid_j$ using their private key $\omega$ or s. Hence, the CDAKA achieves patient traceability to prevent malicious users from doing something to harm systems.

Cross-domain communication

According to the specification of CDAKA protocol, two patients $PA_i$ in PKI-domain and $PA_j$ in IBC-domain separately registered with PKI and IBC can authenticate each other and generate a session key for secure communication. Hence, the CDAKA protocol can provide heterogeneous cross-domain communication.

Perfect forward secrecy

In the CDAKA protocol, suppose $\mathscr{A}$ steals both private keys of two patients $PA_i$ and $PA_j$. We also assume that $\mathscr{A}$ intercepts messages $\mathbf {msg1}=\{PID_i, M_{i2}, M_{i4}, T^{1}_i\}, \mathbf {msg2}=\{PID_j, M_{j5},M_{j6}, T^{2}_j\}$ transmitted between $PA_i$ and $PA_j$. Using their private keys, the adversary is able to compute M_i1 = (α_jPub_j + P_j + R_j)(x_i + y_i) and $M_{j1}=(\alpha _iPub_i+P_i+R_i)(x_j+y_j)$ to obtain $a_iP=M_{i1}\oplus M_{i2}$ and $a_jP=M_{j1}\oplus M_{j5}$ further. To obtain the session key $SK_{ij}=H_3(M_{j1}||pid_i||pid_j||Pub_i||Pub_j||a_iP||a_jP||a_ia_jP)$, $\mathscr{A}$ has to compute $a_ia_jP$ from $a_iP$ and $a_jP$. In other words, $\mathscr{A}$ has to solve the ECDHP. Due to the hardness of the ECDHP, the CDAKA protocol provides perfect forward secrecy.

Impersonation attack

If $\mathscr{A}$ can obtain the information $\mathbf {msg1}=\{PID_i, M_{i2}, M_{i4}, T^{1}_i\}, \mathbf {msg2}=\{PID_j, M_{j5},M_{j6}, T^{2}_j\}$ in public channel. $\mathscr{A}$ (other domain servers and malicious-legitimate patients) cannot get the secret information $M_{i1}$ and $M_{j1}$ only shared between $PA_i$ and $PA_j$. So $\mathscr{A}$ can not figure out the valid authentication message $M_{j4}$ $=$ $H_3(M_{j1}||M_{i2}||M_{j3}||a_iP||pid_i)$ and $M_{j6}$ $=$ $H_3(SK_{ij}||M_{j5}||a_iP||a_jP)$ to pass the authentication. Hence, the CDAKA protocol can resist the impersonation attack.

Internal attacks

Assume that $\mathscr{A}$ is a malicious-legitimate patient, $\mathscr{A}$ uses his own information in public channel. He obtains nothing about other patients’ secret information $M_{i1}$ and $M_{j1}$. And he also cannot get the random values $a_iP$ or $a_jP$. So he cannot succeed in forging authentication information $M_{j4}=H_3(M_{j1}||M_{i2}||M_{j3}||a_iP||pid_i)$ and $M_{j6}=H_3(SK_{ij} ||M_{j5}||a_iP||a_jP)$ to pass the authentication. Hence, the CDAKA protocol can resist the internal attacks.

Replay attack

Suppose $\mathscr{A}$ intercepts the massage msg1, where $M_{i2}=M_{i1}\oplus a_iP$, $M_{i4}=H_3(M_{i1}||M_{i2}|| M_{i3}||a_iP||pid_i)$, and replies this message to PA_j. However, $PA_j$ stores the pair $(PID_i, M_{i2})$ in its database. Later, when $PA_j$ receives the next login request message msg1, $PA_j$ compares $M_{i2}$ corresponding to $PID_i$. If it matches, $PA_j$ ensures that this request message is a replay message and rejects this request. Or else, $PA_j$ replaces $M_{i2}$ with $M_{i2}^{new}$. So does the $PA_i$. Hence, the CDAKA protocol can resist the replay attack.

Man-in-the-middle attack

In this attack, $\mathscr{A}$ may try to impersonate a valid patient $PA_i$, or his partner $PA_j$ by intercepting the message. However, in the CDAKA protocol the secret values $M_{i1}$ and $M_{j1}$ are only shared between $PA_i$ and $PA_j$, they will never be discovered by anybody else except $PA_i$ and $PA_j$. Hence, the CDAKA protocol is secure against man-in-the-middle attack.

Security proof

Assuming that the ECDHP is hard, the security of the CDAKA protocol is demonstrated blow.

Theorem 1

In the random oracle, if there exists a type-I adversary $\mathscr{A}_I$, who is able to forge a legitimate login message or its partner’s respond message with a non-negligible probability $\varepsilon$ in time t. We show that there is a challenger $\mathscr{C}$ who can solve the ECDHP with a non-negligible probability $\varepsilon ^{\prime }$, where

$$\varepsilon^{\prime}\geq \left( 1-\frac{2}{q_{ep}+ 1}\right)^{q_{ep}}\left( 1-\frac{2}{q_{sq}+ 1}\right)^{q_{sq}}\frac{1}{nm}\frac{2}{q_{H_3}}\varepsilon, $$

in time

$$t^{\prime}\leq t + 2q_{se}t_{se}+ 2(q_{es}+q_{ep}+ 2q_{sq})t_{sm}. $$

Here, $q_{se}, q_{H_{i}}, q_{es}, q_{ep}, q_{sq}$ denote the times of symmetric-encryption queries, hash-query,extract-secret-value queries, extract-partial-secret-value queries and send queries. n and m denote the number of patients in PKI-domain and IBC-domain separately. $t_{se}$ and $t_{sm}$ denote the time of symmetric-encryption and scalar multiplications separately.

Proof

Let $\mathscr{C}$ be a ECDHP challenger who receives a random instance (P,Q₁ = aP,Q₂ = bP) of ECDHP in $G_{1}$. A type-I adversary $\mathscr{A}_{I}$ interacts with $\mathscr{C}$ as follows. We show how $\mathscr{C}$ may use $\mathscr{A}_{I}$ to solve the ECDHP, that is to compute $abP$. □

Setup: :

$\mathscr{C}$ randomly selects the initiator patient $PA_{I}$ in PKI-domain and the responder patient $PA_{J}$ in IBC-domain as the challenge patients. Then, $\mathscr{C}$ generates six numbers $\alpha _{I}$, $r_{I}$, $x_{I}\alpha _{J}$, $r_{J}$, $x_{J}\in Z^{*}_{q}$ randomly, computes $Pub_{i}=\alpha ^{-1}_{I}(Q_{1}-r_{I}P-x_{I}P)$, $Pub_{j}=\alpha ^{-1}_{J}(Q_{2}-r_{J}P-x_{J}P)$ and gives $\{ q, P, G_{1}, Pub_{i}, Pub_{j}, H_{1}, H_{2}, H_{3} \}$ to $\mathscr{A}_{I}$ as public parameters. $\mathscr{C}$ maintains the following lists to avoid inconsistency and for quick response to the adversary $\mathscr{A}_{I}$:

Symmetric encryption query: :

A list $L_{se}$ is utilized to store the query result. Obtaining a symmetric encryption query on $m_{k}$ and key $k_{k}$. $\mathscr{C}$ checks whether a tuple $(m_{k}, k_{k}, c_{k})$ exists in $L_{se}$. If it exists, $c_{k}$ is returned. Otherwise, $\mathscr{C}$ selects a randomized string $c_{k}\in \{0,1\}^{*}$, stores in $L_{se}$ and sends $c_{k}$ to $\mathscr{A}_{I}$.

Hash query: :

$\mathscr{C}$ maintains several initialized-empty lists $L_{H_{k}}$. Upon receiving the Hash query with $m_{k}$. $\mathscr{C}$ checks whether a tuple $(m_{k}, n_{k})$ exists in $L_{H_{k}}$. If it exists, $n_{k}$ is returned. Otherwise, $\mathscr{C}$ selects a randomized value $n_{k}$, stores in $L_{H_{k}}$ and sends $n_{k}$ to $\mathscr{A}_{I}$, where $k = 1, 2, 3$.

Extract secret value of ( P A _k ): :

A initialized-empty list $L^{1}_{PA}$ is utilized to store the query result. Obtaining a secret value extraction on patient $PA_{k}$ with identity $ID_{k}$. $\mathscr{C}$ checks whether a tuple $(PA_{k}, ID_{k}, x_{k}, P_{k})$ exists in $L^{1}_{PA}$. If it exists, $x_{k}$ is returned. Otherwise, $\mathscr{C}$ selects a random number $x_{k}\in Z^{*}_{q}$, computes $P_{k}=x_{k}P$, stores the new tuple in $L^{1}_{PA}$ and sends $x_{k}$ to $\mathscr{A}_{I}$.

Extract partial secret value query( P A _k ): :

$\mathscr{C}$ maintains several initialized-empty lists $L^{2}_{PA}$. Upon receiving the partial secret value query on the patient $PA_{k}$, $\mathscr{C}$ checks whether a tuple $(PA_{k}, pid_{k}, R_{k}, y_{k})$ exists in $L^{2}_{PA}$. If it exists, $y_{k}$ is returned. Otherwise, $\mathscr{C}$ calculates as following:

• If $PA_{k}=PA_{I}$, $\mathscr{C}$ selects random number $\xi _{I}\in Z^{*}_{q}$, random string $pid_{I}\in \{0,1\}^{*}$ and inserts the tuple $((ID_{I}\oplus \xi _{I}), \bot , pid_{I})$ into list $L_{se}$. $\mathscr{C}$ computes $R_{I}=r_{I}P$, sets $y_{I}=\bot$ and reads $P_{I}$ from the list $L^{1}_{PA}$ according to $PA_{I}$. At last, $\mathscr{C}$ stores $(pid_{I}, P_{I}, R_{I}, S_{I}, \alpha _{I})$ and $(ID_{I}, pid_{I}, r_{I}, R_{I}, \bot )$ into $L_{H_{1}}$ and $L^{2}_{PA}$ separately.

• If $PA_{k}=PA_{J}$, $\mathscr{C}$ selects random number $\xi _{J}\in Z^{*}_{q}$, random string $pid_{J}\in \{0,1\}^{*}$ and inserts the tuple $((ID_{J}\oplus \xi _{J}), \bot , pid_{J})$ into list $L_{se}$. $\mathscr{C}$ reads $H_{2}(ID_{J})$ from the list $L^{1}_{PA}$ according to $ID_{J}$, computes $R_{J}=r_{J}H_{2}(ID_{J})$, sets $y_{J}=\bot$. At last, $\mathscr{C}$ stores $(pid_{J}, R_{J}, T_{J}, \alpha _{J})$ and $(ID_{J}, pid_{J}, r_{J}, R_{J}, \bot )$ into $L_{H_{1}}$ and $L^{2}_{PA}$ separately.

• Otherwise, $\mathscr{C}$ selects random value $\xi _{k}, \alpha _{k}$ $\in$ $Z^{*}_{q}, pid_{k}$ $\in$ $\{0,1\}^{*}$, inserts $((ID_{k}\oplus \xi _{k}), \bot , pid_{k})$ into list $L_{se}$, computes $R_{k}$ $=$ $\alpha ^{-1}_{k}r_{k}P+Pub_{k}$, and sets $y_{k}$ $=$ $\alpha _{k}r_{k}$ (Here, if $PA_{k}$ is in PKI-domain, $Pud_{k}$ $=$ $Pub_{i}$ and $r_{k}$ is random number chosen by $\mathscr{C}$. Otherwise, $Pud_{k}$ $=$ $Pub_{j}$ and $r_{k}$ $=$ $H_{2}(ID_{k})$). At last, $\mathscr{C}$ stores $(pid_{k}, P_{k}, R_{k}, S_{k}, \alpha _{k})$ and $(ID_{k}, pid_{k}, R_{k}, y_{k})$ into $L_{H_{1}}$ and $L^{2}_{PA}$ separately.

Request public key of ( P A _k ): :

A initialized-empty list $L^{3}_{PA}$ is utilized to store the query result. Obtaining a request public key on patient $PA_{k}$. $\mathscr{C}$ checks whether a tuple $(PA_{k}, x_{k}, P_{k}, r_{k}, R_{k})$ exists in $L^{3}_{PA}$. If it exists, $(P_{k}, R_{k})$ is returned. Otherwise, $\mathscr{C}$ responds $(P_{k}, R_{k})$ by accessing to list $L^{1}_{PA}$ and list $L^{2}_{PA}$ and set $d_{k}$:= 0 (d_k denotes the time of public key replacement). At last, the tuple $(PA_{k}, x_{k}, P_{k}, r_{k}, R_{k}, d_{k})$ is inserted to $L^{3}_{PA}$.

Replace public key of ( P A _k ): :

Upon receiving the replace public key query on the patient $PA_{k}$, $\mathscr{C}$ first makes a request public key on (PA_k) and finds the tuple $(PA_{k}, x_{k}, P_{k}, r_{k}, R_{k}, d_{k})$ on $L^{3}_{PA}$. Then, $\mathscr{C}$ replaces $pk_{k}=(P_{k}, R_{k})$ with $pk^{\prime }_{k}=(P^{\prime }_{k}, R^{\prime }_{k})$ which is chosen by $\mathscr{A}_{I}$ and puts $d_{k}:=d_{k}+ 1$. At last, the tuple $(PA_{k}, x^{\prime }_{k}, P^{\prime }_{k}, r^{\prime }_{k}, R^{\prime }_{k}, d_{k})$ is inserted to $L^{4}_{PA}$.

Send query of ( P K _k , M ): :

Obtaining the send query with mesage M, $\mathscr{C}$ responds the query as follows:

• $M=(M_{i2}, M_{i4})$: The query is message M from $PA_{i}$ to $PA_{j}$.

  • If $PA_{i}=PA_{I}$, $\mathscr{C}$ aborts the session.

  • If $PA_{i}\neq PA_{I}$, $PA_{j}=PA_{J}$, $\mathscr{C}$ aborts the session.

  • If $PA_{i}\neq PA_{I}$, $PA_{j}\neq PA_{j}$, $\mathscr{C}$ runs according to the specification of the protocol, where $\mathscr{C}$ knows the private key of $PK_{i}$.

• $M=(M_{j5}, M_{j6})$: The query is message M from $PA_{j}$ to $PA_{i}$.

  • If $PA_{j}=PA_{J}$, $\mathscr{C}$ aborts the session.

  • If $PA_{j}\neq PA_{J}$, $PA_{i}=PA_{I}$, $\mathscr{C}$ aborts the session.

  • If $PA_{j}\neq PA_{j}$, $PA_{i}\neq PA_{I}$, $\mathscr{C}$ runs according to the specification of the protocol, where $\mathscr{C}$ knows the private key of $PK_{j}$.

Reveal query of ( P K _k ): :

Upon receiving the query, $\mathscr{C}$ checks if $PA_{k}=PA_{I}$ or $PA_{k}=PA_{J}$. If yes, $\mathscr{C}$ aborts the session. Otherwise, $\mathscr{C}$ returns the session key between $PA_{k}$ and its partner to $\mathscr{A}_{I}$.

Corrupt query of ( P K _k ): :

Obtaining the corrupt query, $\mathscr{C}$ looks up the list $L^{1}_{PA}$ and the list $L^{2}_{PA}$ for the tuples $(PA_{k}, ID_{k}, x_{k}, P_{k})$ and $(PA_{k}, pid_{k}, R_{k}, y_{k})$. Then, $\mathscr{C}$ returns $(x_{k}, P_{k}, R_{k}, y_{k})$ to $\mathscr{A}_{I}$.

Finally, $\mathscr{A}_{I}$ outputs a legitimate login message $(M_{i2}, M_{i4})$ or its partner’s respond message $(M_{j5}, M_{j6})$. If (PK_i,PK_j)≠(PK_I,PK_J), $\mathscr{C}$ aborts the game. Otherwise, $\mathscr{C}$ randomly chooses a tuple $(*, M_{i1},* )$ or $(*, M_{j1},* )$ from the list $L_{H_{3}}$ and outputs $M_{i1}$ or $M_{j1}$ as the solution of ECDHP.

To complete the the proof, we shall show that $\mathscr{C}$ solves the given instances of ECDHP with probability $\varepsilon ^{\prime }$. First, we analyze several events for $\mathscr{C}$ to succeed:

• $E1$: $\mathscr{C}$ does not abort any $\mathscr{A}_{I}$’s “Extract partial secret value queries”.

• $E2$: $\mathscr{C}$ does not abort any $\mathscr{A}_{I}$’s “Send queries”.

• $E3$: $\mathscr{C}$ obtains a legitimate login message or its partner’s respond message.

• $E4$: $(PK_{i}, PK_{i})=(PK_{I}, PK_{J})$.

• $E5$: $\mathscr{C}$ chooses a correct tuple from the list $L_{H_{3}}$.

Then, we have:

$$\begin{array}{@{}rcl@{}} &&\text{Pr}[E1]\geq \left( 1-\frac{2}{q_{ep}+ 1}\right)^{q_{ep}}\\ &&\text{Pr}[E2|E1]\geq \left( 1-\frac{2}{q_{sq}+ 1}\right)^{q_{sq}}\\ &&\text{Pr}[E3|E1\wedge E2]\geq \varepsilon\\ &&\text{Pr}[E4|E1\wedge E2\wedge E3]\geq \frac{1}{nm}\\ &&\text{Pr}[E5|E1\wedge E2\wedge E3\wedge E3]\geq \frac{2}{q_{H_{3}}} \end{array} $$

Hence, we have:

$$\begin{array}{@{}rcl@{}} \varepsilon^{\prime}&\,=\,&\text{Pr}[E1\wedge E2\wedge E3\wedge E4\wedge E5]\,=\, \text{Pr}[E1]\text{Pr}[E2|E1]\text{Pr}[E3|E1\\ &&\wedge E2]\text{Pr}[E4|E1\wedge E2\wedge E3]\text{Pr}[E5|E1\wedge E2\wedge E3\wedge E3]\\ &\!\geq\!&\left( 1-\frac{2}{q_{ep}\,+\,1}\right)^{q_{ep}}\left( 1-\frac{2}{q_{sq}\,+\,1}\right)^{q_{sq}}\frac{1}{nm}\frac{2}{q_{H_{3}}}\varepsilon. \end{array} $$

The running time t for $\mathscr{C}$ is the sum of $\mathscr{A}_{I}$’s running time, the time that $\mathscr{C}$ responds queries and the time that $\mathscr{C}$ computes the ECDHP. Hence,

$$t^{\prime}\leq t + 2q_{se}t_{se}+ 2(q_{es}+q_{ep}+ 2q_{sq})t_{sm}. $$

Theorem 2

In the random oracle, if there exists a type-II adversary $\mathscr{A}_{II}$, who is able to forge a legitimate login message or its partner’s respond message with a non-negligible probability $\varepsilon$ in time t. We show that there is a challenger $\mathscr{C}$ who can solve the ECDHP with a non-negligible probability

$$\varepsilon^{\prime}\geq \left( 1-\frac{2}{q_{es}+ 1}\right)^{q_{es}}\left( 1-\frac{2}{q_{sq}+ 1}\right)^{q_{sq}}\frac{1}{nm}\frac{2}{q_{H_{3}}}\varepsilon. $$

in time

$$t^{\prime}\leq t + 2q_{se}t_{se}+ 2(q_{es}+ 2q_{sq})t_{sm}. $$

Proof

Let $\mathscr{C}$ be a ECDHP challenger who receives a random instance (P,Q₁ = aP,Q₂ = bP) of ECDHP in $G_1$. A type-II adversary $\mathscr{A}_{II}$ interacts with $\mathscr{C}$ as follows. We show how $\mathscr{C}$ may use $\mathscr{A}_{II}$ to solve the ECDHP, that is to compute $abP$. □

Setup: :

$\mathscr{C}$ randomly selects the initiator patient $PA_I$ in PKI-domain and the responder patient $PA_J$ in IBC-domain as the challenge patients. Then, $\mathscr{C}$ generates two numbers $\omega , s \in Z^{*}_{q}$ randomly, computes $Pub_i=\omega P$, $Pub_j=sP$ and gives $\{ q, P, G_1, Pub_i,Pub_j, H_1, H_2, H_3 \}$ to $\mathscr{A}_{II}$ as public parameters. $\mathscr{C}$ maintains the following lists to avoid inconsistency and for quick response to the adversary $\mathscr{A}_{II}$:

Due to the initiate-respond process of “Symmetric encryption query”, “Hash query” and “Extract secret value query” are same as Theorem 1.. We will not repeat them here. For more details, please refer to Theorem 1.

Request public key of ( P A _k ): :

A initialized-empty list $L^{3}_{PA}$ is utilized to store the query result. Obtaining a request public key on patient $PA_k$. $\mathscr{C}$ checks whether a tuple $(PA_k, x_k, P_k, r_k, R_k)$ exists in $L^{3}_{PA}$. If it exists, $(P_k, R_k)$ is returned. Otherwise, $\mathscr{C}$ calculates as following:

• If $PA_k=PA_I$, $\mathscr{C}$ obtains $\alpha _I, P_I$ by accessing to $L_{H_1}$ and $L^{1}_{PA}$ and computes $R_I=Q_1-\alpha _IPub_i-P_I$. At last, the tuple $(PA_I, P_I, R_I)$ is inserted to $L^{3}_{PA}$.

• If $PA_k=PA_J$, $\mathscr{C}$ obtains $\alpha _J, P_J$ by accessing to $L_{H_1}$ and $L^{1}_{PA}$ an computes $R_J=Q_2-\alpha _JPub_j-P_J$. At last, the tuple $(PA_J, P_J, R_J)$ is inserted to $L^{3}_{PA}$.

• If $PA_k\neq PA_I$, $PA_k\in PKI-domain$, $\mathscr{C}$ selects random number $r_k\in Z^{*}_{q}$, and computes $R_k=r_kP$. At last, the tuple $(PA_k, P_k, R_k)$ is inserted to $L^{3}_{PA}$.

• If $PA_k\neq PA_J$, $PA_k\in IBC-domain$, $\mathscr{C}$ obtains $H_2(ID_k)$ by accessing to $L_{H_2}$ and computes $R_k=H_2(ID_k)P$. At last, the tuple $(PA_k, P_k, R_k)$ is inserted to $L^{3}_{PA}$.

Send query of ( P K _k , M ): :

Obtaining the send query with mesage M, $\mathscr{C}$ responds the query as follows:

• $M=(M_{i2}, M_{i4})$: The query is message M from $PA_i$ to $PA_j$.

  • If $PA_i=PA_I$, $\mathscr{C}$ aborts the session.

  • If $PA_i\neq PA_I$, $PA_j=PA_J$, $\mathscr{C}$ aborts the session.

  • If $PA_i\neq PA_I$, $PA_j\neq PA_j$, $\mathscr{C}$ runs according to the specification of the protocol, where $\mathscr{C}$ knows the private key of $PK_i$.

• $M=(M_{j5}, M_{j6})$: The query is message M from $PA_j$ to $PA_i$.

  • If $PA_j=PA_J$, $\mathscr{C}$ aborts the session.

  • If $PA_j\neq PA_J$, $PA_i=PA_I$, $\mathscr{C}$ aborts the session.

  • If $PA_j\neq PA_j$, $PA_i\neq PA_I$, $\mathscr{C}$ runs according to the specification of the protocol, where $\mathscr{C}$ knows the private key of $PK_j$.

Reveal query of ( P K _k ): :

Upon receiving the query, $\mathscr{C}$ checks if $PA_k=PA_I$ or $PA_k=PA_J$. If yes, $\mathscr{C}$ aborts the session. Otherwise, $\mathscr{C}$ returns the session key between $PA_k$ and its partner to $\mathscr{A}_{II}$.

To complete the the proof, we shall show that $\mathscr{C}$ solves the given instances of ECDHP with probability $\varepsilon ^{\prime }$. First, we analyze several events for $\mathscr{C}$ to succeed:

• $E1$: $\mathscr{C}$ does not abort any $\mathscr{A}_{II}$’s “Extract secret value queries”.

• $E2$: $\mathscr{C}$ does not abort any $\mathscr{A}_{II}$’s “Send queries”.

• $E3$: $\mathscr{C}$ obtains a legitimate login message or its partner’s respond message.

• $E4$: $(PK_i, PK_i)=(PK_I, PK_J)$.

• $E5$: $\mathscr{C}$ chooses a correct tuple from the list $L_{H_3}$.

Then, we have:

$$\begin{array}{@{}rcl@{}} &&\text{Pr}[E1]\geq \left( 1-\frac{2}{q_{es}+ 1}\right)^{q_{es}}\\ &&\text{Pr}[E2|E1]\geq \left( 1-\frac{2}{q_{sq}+ 1}\right)^{q_{sq}}\\ &&\text{Pr}[E3|E1\wedge E2]\geq \varepsilon\\ &&\text{Pr}[E4|E1\wedge E2\wedge E3]\geq \frac{1}{nm}\\ &&\text{Pr}[E5|E1\wedge E2\wedge E3\wedge E3]\geq \frac{2}{q_{H_3}}\\ \end{array} $$

Hence, we have:

$$\begin{array}{@{}rcl@{}} \varepsilon^{\prime}&\,=\,&\text{Pr}[E1\wedge E2\wedge E3\wedge E4\wedge E5]\,=\, \text{Pr}[E1]\text{Pr}[E2|E1]\\ &&\text{Pr}[E3|E1\wedge E2]\text{Pr}[E4|E1\wedge E2\wedge E3]\text{Pr}[E5|E1\\ &&\wedge E2\wedge E3\wedge E3]\!\geq\! \left( 1\,-\,\frac{2}{q_{es}\,+\,1}\right)^{q_{es}}\left( 1\,-\,\frac{2}{q_{sq}\,+\,1}\right)^{q_{sq}}\\ &&\frac{1}{nm}\frac{2}{q_{H_{3}}}\varepsilon. \end{array} $$

The running time t for $\mathscr{C}$ is the sum of $\mathscr{A}_{II}$’s running time, the time that $\mathscr{C}$ responds queries and the time that $\mathscr{C}$ computes the ECDHP. Hence,

$$t^{\prime}\leq t + 2q_{se}t_{se}+ 2(q_{es}+ 2q_{sq})t_{sm}. $$

Performance evaluation

In this paper, the communication cost is reduced by removing the unnecessary information transmitted, while remaining high security. The computation cost is mainly discussed in the following. We compare CDAKA protocol to the [5] and [6] protocols, both of which provide cross-domain authenticated key agreement. For convenience, we define some notations about the running time and energy cost in Tables 2 and 3 [4, 30,31,32, 34], respectively. In addition, we also discuss how our protocol is efficient than others from its implementation point of view later in this section as roughly shown in Fig. 5.

Table 2 Computational notations

Table 3 Energy notations

Fig. 5

Performance comparisons of related lightweight AKA protocol

NOTE::

We mainly focus on the efficiency of login and authentication phases, since these two phases are the main body of an authentication scheme and are executed much more frequently than the other phases.

Computation cost

We analyze and compare the computation cost of CDAKA protocol and related AKA protocols. Let $t_{h}$, $t_{c}$, $t_{x}$, $t_{b}$, $t_{m}$, $t_{sg}$, $t_{ed}$ and $t_{hp}$ denote hash function, concatenation operation, XOR operation, the time complexity for scarlar bilinear paring operation, multiplication operation, signature generation operation, encryption/decryption operation and hash-to-point operation. Since the time of hash function, concatenation operation and XOR operation are negligible as compared to the other five operations, we do not take $t_{h}$, $t_{c}$ and $t_{x}$ into account.

Based on the implementation results in [33], we analyze and compare the computation cost of related AHA protocols, as shown in Fig. 5a. The comparisons among related protocols are listed in Table 4.

Table 4 Performance comparison among relevant authentication protocols

In session initiator’s side, He et al.’s [5] protocol has to carry out six multiplication operations and two hash-to-point operations. Therefore, the running time of patients is 6t_m + 2t_hp ≈ 59.812ms. In session response’s side, it cost six multiplication operations and two hash-to-point operations, too. Hence, the running time is 59.812 ms. In the trusted authenticated (TA) side, the TAs not participate in the these processes. Hence, the running time of them is 0 ms. The total time is $59.812 + 59.812 = 119.624$ ms.

In session initiator’s side, Yuan et al.’s [6] protocol has to carry out one scalar bilinear paring operation, four multiplication operations, one signature generation operation, thirteen encryption/decryption operations and one hash-to-point operation. Therefore, the running time is 1t_b + 4t_m + 1t_sg + 13t_ed + 1t_hp ≈ 123.856 ms. In session response’s side, it costs thirteen encryption/decryption operations. Hence, the running time is 13t_ed ≈ 50.05 ms. In the trusted authenticated (TA) side, it has to carry out two scalar bilinear paring operations, two multiplication operations, one signature generation operation and ten encryption/decryption operations. Hence, the running time is 2t_b + 2t_m + 1t_sg + 10t_ed ≈ 98.2 ms. In certificate authority (CA) side, it has to carry out three signature generation operations, seven encryption/decryption operations and one hash-to-point operation. Therefore, the running time is 3t_sg + 7t_ed + 1t_hp ≈ 115.656 ms. The total time is 123.856 + 50.05 + 98.2 + 115.656 $=$ 387.762 ms.

In session initiator’s side, the CDAKA protocol has to carry out four multiplication operations and one hash-to-point operation. Therefore, the running time is 4t_m + 1t_hp ≈ 38.406 ms. In session response’s side, it has to carry out the same operations. Hence, the running time is 4t_m + 1t_hp ≈ 38.406 ms. The users can remotely communicate with the other ones by themselves without the help of their registration centers. Hence, the running time is 0 ms. The total time is 38.406 + 38.406 $=$ 76.812 ms.

According to the above comparisons of computation cost, we know that the CDAKA protocol has much less running time than other two related AKA protocols [5, 6] in both sides of session initiator and session response.

Communication cost

In this subsection, we analyze and compare the communication costs of the CDAKA protocol and other two related AKA protocols [5, 6]. Because the size of P is 512 bits, then the size of an element in $G_1$.

Without loss of generality, let the sizes of an element in $G_1$, bilinear paring’s value, signature value, encryption/decryption value is 512 bits. The size of the length of the pseudo identity is 128 bits. The size of the general hash functions output is 160 bits. The size of current timestamp is 32 bits.

In He et al.’s [5] protocol, among the interactive messages, there are six elements in $G_1$, two outputs of the general hash function and four pseudo identities. Therefore, the communication cost of He et al.’s [5] protocol is 6 * 512 + 2 * 160 + 4 * 128 $=$ 3904 bits.

In Yuan et al.’s [6] protocol, among the interactive messages, there are two elements in $G_1$ and twenty-two encryption/decryption values. Therefore, the communication cost of Yuan et al.’s [6] protocol is 1 * 512 + 22 * 512 $=$ 11776 bits.

In CDAKA protocol, among the interactive messages, there are ten elements in $G_1$, two outputs of the general hash function, two pseudo identities and two timestamp. Therefore, the communication cost of 10 * 512 + 2 * 160 + 2 * 128 + 2 * 32 $=$ 5760 bits.

According to the above comparisons, we know that the CDAKA protocol increases the communication cost compared with He et al.’s [5] protocol. The reason for the increases is that CDAKA really implement authentication for multi-domain as Yuan et al.’s [6] protocol. It is worthy to achieve cross-domain authentication at the cost of increasing computation cost only. However, compared with Yuan et al.’s [6] protocol, the communication cost is greatly reduced.

Energy cost

In mobile devices, energy-saving is an important indicator. Here, we only discuss the client side or session initiator side from three part: energy to transmit, energy to receive and energy to operations, as shown in Fig. 5b.

From the above, in client side of He et al.’s [5] protocol, it needs to transmit two pseudo identities, three elements in $G_1$ and one output of the general hash function, total 1952 bits. According to [31, 34], it costs 14.44 mJ. It receives two pseudo identities, three elements in $G_1$ and one output of the general hash function, total 1952 bits, which costs 6.56 mJ. The operations are six multiplication operations, two hash-to-point operations and three general hash functions. The energy is 1238.75 mJ.

In client side of Yuan et al.’s [6] protocol, it needs to transmit two elements in $G_1$ and twelve encryption/decryption values, total 7168 bits, which costs 53.04 mJ. It receives seven encryption/decryption values, total 3584 bits, which costs 12.05 mJ. The operations are one scalar bilinear paring operation, four multiplication operations, one signature generation operation, thirteen encryption/decryption operations and one hash-to-point operation. The energy is 872.75 mJ.

In client side of CDAKA protocol, it needs to transmit five elements in $G_1$, one outputs of the general hash function, one pseudo identities and one timestamp, total 2880 bits, which costs 21.13 mJ. It receives five elements in $G_1$, one outputs of the general hash function, one pseudo identities and one timestamp, total 2880 bits, which costs 9.684 mJ. The operations are four multiplication operations, one hash-to-point operation and foue general hash functions. The energy is 795.67 mJ.

According to the above comparisons, we know that the CDAKA protocol is energy-saving, which is very suitable for mobile application scenarios, where resource is severely constrained.

Security comparisons

To show the security advantages of CDAKA protocol, we present security comparisons between CDAKA protocol and other two related AKA protocols [5, 6]. The security comparisons are listed in Table 5. From Table 5, we can get that the protocol in [5] cannot provide cross-domain authentication and the the protocol in [6] cannot provide traceability. The CDAKA protocol can satisfy all ten security and function requirements. Therefore, the CDAKA protocol is more secure than other two related AKA protocols.

Table 5 Security features comparison among related authentication protocols

Conclusion and ongoing work

System security and patients privacy-preserved are a challenging issue in distributed medical heterogeneous cross-domain authentication systems. A provably-secure heterogeneous cross-domain authenticated key agreement protocol with symptoms-matching in TMIS presented in this paper is trying to find a balance between the system security and patients privacy-preserved. The CDAKA protocol investigates a systematic approach of heterogeneous cross-domain authentication from PKI-domain to IBC-domain or from IBC-domain to PKI-domain. Only the register centers PKI and IBC know patients’ identities, it not only realizes anonymity to protect patient’s privacy, but also addresses other prominent issues (e.g. patient traceability). Meanwhile the CDAKA protocol is proven to be secure under the Elliptic Curve Computable Diffie-Hellman problem (ECDHP) assumption in the random oracle model.. Compared with the recently relevant schemes, the CDAKA protocol has better performance (such as energy-saving) and better security features. Thus, CDAKA protocol is more secure and efficient for computation-limited mobile device. The future work is to fully identify the practical threats on heterogeneous cross-domain authentication protocols. Based on artificial intelligence, develop concrete heterogeneous cross-domain authentication with better performance.