TY - JOUR AU1 - Liu,, Weiran AU2 - Liu,, Xiao AU3 - Liu,, Jianwei AU4 - Wu,, Qianhong AB - Abstract Electronic Health Record (EHR) systems bring an abundance of convenience for telediagnosis, medical data sharing and management. A main obstacle for wide adoption of EHR systems is due to the privacy concerns of patients. In this work, we propose a role-based access control (RBAC) scheme for EHR systems to secure private EHRs. In our RBAC, there are two main types of roles, namely independent patients and hierarchically organized medical staffs. A patient is identified by his/her identity, and a medical staff is recognized by his/her role in the medical institute. A user can comprehend an EHR only if he/she satisfies the access policy associated with this EHR, which implies a fine-grained access control. A public auditor is employed to verify whether the EHR is correctly encapsulated with the specified access policy, which provides an a priori approach to find fraudulent EHRs and reduce potential medical disputes. Moreover, our RBAC enforces a forward revocation mechanism. A revoked user cannot access the future EHRs even if his/her previous role satisfies the access policy. These security properties are formally proven under well-established assumptions. Theoretical and experimental analyses show the efficiency of our RBAC in terms of communication and computation. 1. INTRODUCTION The development of electronic health records (EHR) for enabling electronic health systems has drawn extensive attentions from both academia and industry. Compared with traditional paper-based health records (PBHR), EHRs can be stored and shared in a more flexible way. Various types of health data can be contained in one’s EHR account, including prescription files, medical images such as X-ray, B-scan, audio clips and video files. The digital feature also allows EHRs to be accessed in a convenient manner. To find one’s EHRs, the patient and his/her doctors just need to retrieve them from the storage server, instead of seeking carefully in a piled-up archive room. These attractive properties render EHRs as a promising alternative over PBHRs. The Veterans Administration Healthcare System1 in the United States is one of the successful implementations of this kind, with more than 1700 hospitals, clinics and other medical institutes. Nowadays, many countries and regions, including Germany2 and Taiwan [1], have established or are establishing their own EHR systems. It is a daunting task for healthcare providers without required professional skills to manage a large-scale EHR database with universal access (e.g. for telediagnosis). This impedes the practicability of EHR system [2]. Nevertheless, the recent advancement of cloud computing may relieve healthcare providers from this issue. Instead of establishing EHR servers locally, EHRs can be outsourced to a cloud storage server, e.g. Microsoft HealthVault.3 In this way, the capital and operational expenditures can be tremendously reduced for healthcare providers, simultaneously preserving EHR data availability [3, 4]. Nevertheless, there are remaining obstacles for outsourcing EHRs. Among them, privacy and security risks on patients’ health records are considered as the dominating barriers [5, 6]. Patient’s EHRs are often the target of various malicious attacks, vulnerable to loss, leakage or theft [7]. To ensure data secrecy of EHRs, a plausible way is to encapsulate patients’ EHRs by encrypting them prior to outsourcing them to the storage server, e.g. by applying classical private key or public key cryptosystems. In this way, patients’ EHRs would be only allowed to decrypt by the ones who have the corresponding keys, while malicious adversaries cannot obtain useful information from the encrypted results, even if it can access illegally. However, the problem in outsourcing EHRs is that the EHR owners (i.e. patients) may not know who will be allowed to access the EHRs prior to the next diagnosis. This brings difficulties of on-demand EHR sharing. A possible remedy is to encrypt many copies with different keys and assign each key to the doctor who needs to access the EHRs. However, this implies either overwhelming key management and computational overhead [8–10] or failure of flexible access control [11]. New appropriate access control approaches are required to secure outsourced EHRs before they are widely adopted [12]. To address this problem, we consider a typical hospital organization as depicted in Fig. 1. In such a scenario, there are two main types of users, i.e. patients and medical staffs. The patients can be recognized by their national identity numbers, social security numbers or names plus their telephone numbers. The medical staffs in the hospital are usually grouped hierarchically into a relatively small number of roles. For example, the out-patient doctors and out-patient nurses are grouped into the role ‘(out-patient)’. In the department of medicine, the chief doctor is recognized by the role ‘(Department of Medicine, chief doctor)’. Its subordinates, including head nurses, nurses and associate doctors, are all labeled with their roles. One may observe that in the real world, the users’ access privileges are usually determined by their roles in the system. This observation indicates a conceivable role-based access control (RBAC) over outsourced EHRs. Figure 1. Open in new tabDownload slide Typical hospital organization. Figure 1. Open in new tabDownload slide Typical hospital organization. We propose a generic framework of RBAC over outsourced EHRs. We formalize the system model and identify security and secrecy requirements in such a system. Based on the generic framework, we present an efficient and secure RBAC scheme for securing EHRs stored in a storage server maintained by a third party who is not fully trusted. Our RBAC scheme is equipped with the following essential and attractive features. Versatile access control: Our RBAC offers a novel and more efficient approach to fine-grained access control without leveraging attribute-based encryption (ABE) [13, 14]. A user can encapsulate each EHR with an on-demand access policy. Only the corresponding patient and medical staffs with roles that satisfy the access policies can decapsulate. Scalable sharing of EHRs is supported by allowing senior medical staffs to delegate access credentials for their subordinates. Provable secrecy: The security of RBAC is formally defined. The security of our concrete construction is strictly proven under well-established assumptions. Specifically, ones without matching roles can get no useful information about the EHR data, even if they collude and the storage server is untrusted. Public auditability: A public auditor is employed to verify whether the EHR is correctly encapsulated according to the specified access policy. In this way, RBAC provides an a priori approach to find fraudulent EHRs stored in outsourced databases [15, 16] and reduce potential medical disputes. Forward revocation: An automatic revocation mechanism is supported in our RBAC scheme. The revoked user cannot access to the future EHRs even if its previous role satisfies the access policy associating in the newly generated EHRs. Theoretical and experimental analyses show the feasibility and the efficiency of our RBAC in terms of communication and computation. The encapsulation header for an EHR associated with any access policy contains only two group elements. Time consumptions for all procedures involved in our RBAC, including EHR encapsulation and EHR decapsulation, are less than 1 s even when the access policies are considerably complicated. All of these features commit the proposed RBAC a practical solution to secure EHR systems. The remainder of this paper is organized as follows. We survey related works in Section 2. The system framework of RBAC is presented in Section 3. Section 4 proposes our RBAC construction. The formal security evaluations are shown in Section 5. We conduct theoretical and experimental analyses in Section 6, followed by the conclusion in Section 7. 2. RELATED WORK It is essential to identify the potential security and privacy threats of EHR systems in their deployment for seeking design guidelines. Kwak [17] introduced relevant definitions of EHR systems and summarized the available standards of EHR systems presented by International Standards Developing Organizations (SDO). Ray and Wimalasiri [18] identified privacy requirements for EHR systems in the context of HealthLink in Australia and HIPAA in USA, which are the two well-known eHealth frameworks around the world. Recently, Li et al. [19] presented new threats against EHR systems and indicated that EHRs are very vulnerable without effective privacy protection. Efforts have been devoted to access control in EHR systems. Benaloh et al. [11] showed efficient EHR systems that allow patients to both share access rights with others, and to support searches over their EHRs. Löhr et al. [5] presented a security architecture allowing legitimate sharing and ensuring privacy for EHR systems. Some proposals have been implemented to handle access control with security and secrecy enabled approaches, including identity-based authentication [20, 21] and smartcard-based authentication [22]. Very recently, Liu et al. [23] presented a concrete data security mechanism that combines identity-based authentication and smartcard-based authentication to realize data access control with efficient revocation . Schemes exploiting multiple cryptographic primitives have been further proposed to achieve additional functionalities, such as cross-domain EHR sharing [24], emergency EHR sharing [25] and multi-function data sharing with efficient conjunctive keyword search [26]. A plain implementation of aforementioned proposals does not achieve flexible access control. Attribute-based encryption (ABE) [27] is a novel method to obtain flexible access control in clouds [28, 29]. Applications have also been proposed to obtain access control [6, 30] and authentication [31] for outsourced EHRs. Very recently, an access control framework of EHR systems was proposed [8] by combining identity-based encryption and ABE, in which the former is employed to encapsulate EHRs for patients while the latter is for medical staffs. To further improve the security of attribute-based data access control and to extend the expression of access policy, Wang et al. [32] introduced weighted attributes in ABE and proposed an improved attribute-based data sharing scheme with removing the well-known key escrow problem. Although a large body of prominent schemes has been suggested to secure outsourced EHRs, especially for fine-grained access control, there are still remaining challenges unaddressed for these proposals to be deployed in the real world. The practical issues include scalability (to host a large number of users), provable secrecy (to assure convincing EHR secrecy), public auditability (to avoid fraudulent EHRs and reduce potential medical disputes) and revocation of users compromised or left. In this paper, we make efforts to address these practical issues. We also note that some recent EHR systems [33] enforce EHR integrity auditing mechanisms. This is different from our auditing mechanism for the EHRs being outsourced. Indeed, the former is to check whether the outsourced EHRs have been kept intact by the storage service provider, while ours is to validate that the EHRs to be outsourced have been correctly encapsulated according to their associated access policies. These two auditing mechanisms are supplementary for ensuring the availability, integrity and secrecy of EHRs. 3. SYSTEM MODEL 3.1. System architecture As illustrated in Fig. 2, five entities are involved in our RBAC: Trusted Keying Authority (TKA), Patient, Medical Staff, Auditor and Storage Server. We assume that TKA is always trusted in our system. Patient, Medical Staff and Auditor are untrusted but honest, i.e. they honestly execute the algorithms that they are responsible to execute. If they are authorized by an access policy specified to an EHR, they do not reveal any useful information of the EHR to unauthorized entities. However, if they are not authorized by an access policy, they may be a potential adversary. Figure 2. Open in new tabDownload slide System model. Figure 2. Open in new tabDownload slide System model. For the ease of description, we assume that the owner of the EHR is the patient. In some specific situations, patients might not have access to their own EHRs. For example, according to HIPAA, patients are not allowed to access to their own psychotherapy notes without proper authorization from their medical staffs. We can follow the regulations to set parametric roles in such scenarios to meet more accurate access control requirements. All patients need to be identified individually in our RBAC. Their roles are labeled by their identities. Medical staffs in a hospital that provide healthcare services for patients are hierarchically organized. Each medical staff is defined by a role consisting of ordered atom roles. A medical staff whose role is at higher level of the medical institute is responsible for managing other medical staffs with roles at lower level, which implies a tree-like organization. For instance, as shown in Fig. 2, a medical staff in the department of surgery with a lower-level role (dept. surgery, chief doctor, associate doctor, doctor) consisting of different atom roles ‘dept. surgery’, ‘chief doctor’, ‘associate doctor’, ‘doctor’, is administrated by the associate doctor in the same department with the higher-level role (dept. surgery, chief doctor, associate doctor). The associate doctor is then managed by the chief doctor with the role (dept. surgery, chief doctor). TKA is responsible for setting up the system and authenticating users (patients and medical staffs) to determine their eligibilities for accessing EHRs. All patients and medical staffs are eventually managed by TKA. Patients and medical staffs can generate and encapsulate different kinds of EHRs (X-ray, B-scan, etc.) associated with on-demand access policies. Each access policy is described by a role vector set. Any medical staff whose role is in the set can access the corresponding EHRs. For example, the access policy (dept.surgery,chiefdoctor,associatedoctor),(dept.medicine,headnurse) represents that the chief doctor, the associated doctor at the dept. surgery and the head nurse, the associated nurse at the dept. medicine can have access. EHR encapsulations are stored in the storage server for sharing with the designating patient and the entitled medical staffs. The storage server only needs to guarantee basic storage functionalities, such as storage management and integrity examination, which have been widely studied and implemented by existing researches [33, 34]. Before storing EHRs, an auditor is employed to verify whether the EHR is associated with the specified access policy. Only valid EHRs can be stored in the storage server. 3.2. Security requirements Since inside attackers can gain more information to attack the system than outsiders, the system is secure against outside attackers if it is secure against insider attacks. Hence, we will focus on inside attackers. In practice, all entities except TKA are likely to attack the system. A dishonest party may try to get useful information from encapsulated EHRs that he/she is not authorized to access, or divert from the system instructions for benefits (e.g. with false EHRs in medical disputes). Multiple dishonest parties may collude to achieve this goal. In the context of such attacks, an RBAC system is expected to meet the following security requirements. Data secrecy: The secrecy of outsourced EHRs should be protected for authorized access. Specifically, the users (patients and medical staffs) whose roles satisfy the access policy specified in encapsulated EHRs can have access. Unauthorized entities cannot get any useful information from encapsulated EHRs, even if they collude. Public auditability: A public procedure can be employed to verify whether the EHR is correctly encapsulated with the specified access policy, which provides an a priori approach to find fraudulent EHRs and reduce potential medical disputes. Forward revocation: A forward revocation mechanism should be designed to disallow revoked users to access the future EHRs, even if their previous roles satisfy the access policy defined in the newly generated EHRs. 4. A CONCRETE RBAC SCHEME 4.1. Notations We introduce several notations to simplify the description of our RBAC. Table 1 summarizes these notations and their corresponding meanings that will be used in the rest of the paper. Table 1. Notations. Notation . Description . λ Security parameter ID Identity for patient R Atom role R⃗ Role SR⃗ Atom role set for R⃗ IR⃗ Atom Role Position Index set for R⃗  Access policy S Atom role set for  I Atom Role Position Index set for  MSK Master secret key ACID Access credential for an identity ID ACR⃗ Access credential for a role R⃗ EHR Electronic health record Hdr Header of an uploaded EHR K Message encapsulation key EF Encapsulated file of an uploaded EHR t Lifetime Notation . Description . λ Security parameter ID Identity for patient R Atom role R⃗ Role SR⃗ Atom role set for R⃗ IR⃗ Atom Role Position Index set for R⃗  Access policy S Atom role set for  I Atom Role Position Index set for  MSK Master secret key ACID Access credential for an identity ID ACR⃗ Access credential for a role R⃗ EHR Electronic health record Hdr Header of an uploaded EHR K Message encapsulation key EF Encapsulated file of an uploaded EHR t Lifetime Open in new tab Table 1. Notations. Notation . Description . λ Security parameter ID Identity for patient R Atom role R⃗ Role SR⃗ Atom role set for R⃗ IR⃗ Atom Role Position Index set for R⃗  Access policy S Atom role set for  I Atom Role Position Index set for  MSK Master secret key ACID Access credential for an identity ID ACR⃗ Access credential for a role R⃗ EHR Electronic health record Hdr Header of an uploaded EHR K Message encapsulation key EF Encapsulated file of an uploaded EHR t Lifetime Notation . Description . λ Security parameter ID Identity for patient R Atom role R⃗ Role SR⃗ Atom role set for R⃗ IR⃗ Atom Role Position Index set for R⃗  Access policy S Atom role set for  I Atom Role Position Index set for  MSK Master secret key ACID Access credential for an identity ID ACR⃗ Access credential for a role R⃗ EHR Electronic health record Hdr Header of an uploaded EHR K Message encapsulation key EF Encapsulated file of an uploaded EHR t Lifetime Open in new tab We use [a,b] to denote an integer set {a,a+1,…,b} and [a] as the shorthand of [1,a] ⁠. The role of a medical staff is denoted by a vector =(R1,…,Rd) consisting of distinct atom roles Ri ⁠. We define ∥∥ as the number of atom roles in  and S as the atom role set of  ⁠. An access policy  is defined by a role set consisting of distinct roles. Similarly, the number of atom roles in  and the atom role set of  can be defined accordingly. We slightly abuse the term prefix and define the prefix of a role =(R1,…,Rd) as a role set denoted by Pref()={(R1,…,Rd′):d′≤d} Similarly, we define the prefix of an access policy  as Pref()=⋃∈Pref() 4.2. Bilinear groups Bilinear groups have been shown useful in constructing advanced access control schemes to secure EHRs [25, 31] and remote storage systems [28, 29]. They are defined by using a group generator G ⁠, an algorithm which takes a security parameter λ as an input and outputs a description of a bilinear group, (p,G,GT,e)←G(1λ) ⁠, where p is a large prime, G and GT are cyclic groups of order p, and an efficient bilinear map e:G×G→GT satisfying the following properties: Bilinearity: For all g,h∈G and all a,b∈Zp ⁠, e(ga,hb)=e(g,h)ab ⁠. Non-degeneracy: There exists at least an element g∈G such that e(g,g) has order p in GT ⁠. 4.3. The proposal We are now ready to describe our scheme. The basic idea of our construction is shown in Fig. 3. Technically, our proposal contributes in three aspects. Figure 3. Open in new tabDownload slide Basic idea. Figure 3. Open in new tabDownload slide Basic idea. First, we extend a recent hierarchical identity-based encryption (HIBE) scheme [35] to efficiently encrypt to multiple receiver paths, inspired by the work of Liu et al. [36]. As shown in Fig. 3, the RBAC system architecture naturally matches the system model of HIBE schemes, where roles associated with medical staffs and identities associated with patients can be defined as the distinct identity vectors. However, an encryptor can only encrypt to a single path in HIBE [35], which implies either constrained access policy or repetitive encryption to multiple receiver paths. To overcome this problem, we extend the HIBE scheme proposed by Boneh et al. [35] to support multiple receiver paths. In the Boneh–Boyen–Goh HIBE, each hierarchy is associated with a random element to blind the atom identities for the users. When encapsulating, the encryptor combines the related random elements with the receivers’ identity vector to support hierarchical encapsulation with constant size header. In our RBAC construction, we extend the idea by assigning distinct random element to each node, instead of each hierarchy. The encapsulation can be done by combining the random elements with atom roles. In this way, our RBAC construction supports fine-grained access control by encapsulating EHRs to any subset of hierarchically organized users with constant size header. Note that our RBAC offers a novel and more efficient approach to fine-grained access control without using ABE [13, 14]. Second, we propose a new direct header verification approach with marginal cost. We add one on-the-fly dummy verification role in the RBAC scheme. When encapsulating, the EHR owner treats the hash of the associated access policy, the patient’s identity, the lifetime and the encapsulation as the dummy verification role. Then, the EHR owner leverages the dummy verification role to encapsulate the EHR once again. The auditor can later leverage the built-in header verification mechanism in our RBAC scheme to audit the encapsulated EHRs. This approach was introduced by Boyen et al. [37] which builds chosen-ciphertext secure l-hierarchy HIBE from chosen-plaintext secure (l+1)-hierarchy HIBE. Compared with their approach, our approach only adds one on-the-fly dummy verification role in the first hierarchy, instead of a hierarchy of dummy identities. Also, this approach allows public verification of the encapsulation consistency, which implies that a single public auditor can be employed to validate all EHRs to be outsourced. Third, our RBAC facilitates forward revocation. Till now, existing revocation mechanisms can be classified into two categories: direct and indirect revocation. With direct revocation, the data owners specify the revocation list when encapsulating so that the revocation can be done immediately [38, 39]. However, such a mechanism requires all data owners to update the current revocation list in time [40]. Since EHRs can be uploaded by medical staffs, patients or even patients’ family members who may not join the system when uploading, it is difficult to ask them to carry each data user’s status. In our scheme, we focus on indirect revocation, in which TKA periodically updates access credentials to medical staffs. This is realized by introducing a lifetime t as a special role to each access credential and each EHR header, where t is decided by the expiry time of EHRs and published by TKA. This is more effective, since medical staffs are required to be well managed by medical institutions so that access credential updating can be easily operated. We stress that in our scheme we distinguish two types of roles, i.e. independent roles and hierarchical-organized roles. We believe that it is flexible enough for most deployments. For ease of description, we assume that the independent roles can be played by the patients or their guardians, while the hierarchical-organized roles may be played by the medical staffs or the officers of the medical administration authorities. However, we also note that there may be different medical regulatory rules. In some cases, the patients may be not allowed to access their EHRs without the authorization from their doctors. Our scheme can support such deployments as roles are parameterizable. For smoothly applying our RBAC in the actual system, we strongly recommend representing and managing roles by following the RBAC standards [41]. Our scheme works as follows: (PK,MSK)←𝖲𝖾𝗍𝗎𝗉(λ,n) ⁠. It is run by TKA to establish our RBAC. Given the security parameter λ∈Z* ⁠, TKA runs (p,G,GT,e)←G(1λ) to generate a prime p, two groups G ⁠, GT or order p, and a bilinear map e:G×G→GT ⁠. A secure symmetric encryption scheme εsym with algorithms 𝖲𝗒𝗆𝖤𝗇𝖼(K,M) and 𝖲𝗒𝗆𝖣𝖾𝖼(K,M) ⁠, and a collision resistant hash function 𝖧:{0,1}*→Zp are also employed in the scheme. Then, TKA selects a random generator g←RG ⁠, a random exponent α←RZp ⁠, and sets g1←gα ⁠. Next, it picks random elements g2,g3,gh←RG and ui←RG for all i∈[0,n+1] ⁠. The master secret key MSK←(g2α) is kept secret by TKA, while the system parameter PK is published as PK←((p,G,GT,e),g,g1,g2,g3,gh,{ui}i∈[0,n+1]) ACR⃗←𝖠𝖢𝖦𝖾𝗇𝖬(PK,MSK,R⃗) ⁠. It is run when a medical staff is authenticated by TKA. Recall that the lifetime t is published by TKA. To generate an access credential for a medical staff associated with a role R⃗=(R1,…,Rd) using the master secret key MSK, TKA picks a random exponent r←RZp and outputs ACR⃗←(g2α(g3u0t∏i∈IR⃗uiRi)r,gr,ghr,{ujr}j∈[n+1]⧹IR⃗) Note that TKA can generate access credentials for any medical staff with authorized roles by running ACGenM. ACR⃗←𝖠𝖢𝖣𝖾𝗅𝖾𝖬(PK,ACR′⃗,R) ⁠. When a junior medical staff associated with a role R⃗=(R′⃗,R) is authenticated by a supervisor associated with the role R′⃗ ⁠, the supervisor delegates the access credential for the junior one by using ACR′⃗=g2α·(g3·u0t∏i∈IR′⃗uiRi)r′,gr′,ghr′,{ujr′}j∈[n+1]⧹IR′⃗=(a0,a1,a2,{a3,j}j∈[n+1]⧹IR′⃗) where r′ is the random exponent used in ACR′⃗ ⁠. The senior medical staff picks a random exponent s←RZp and outputs the access credential ACR⃗←a0·(b3,iRi)i∈IR⃗⧹IR′⃗(g3·u0t∏i∈IR⃗uiRi)s,a1·gs,a2·ghs,{a3,j·ujs}j∈[n+1]⧹IR⃗ By implicitly setting r=r′+s ⁠, this delegated access credential can be written in the form ACR⃗=(g2α(g3u0t∏i∈IR⃗uiRi)r,gr,ghr,{ujr}j∈[n+1]⧹IR⃗) which is well formed as if it were generated directly by 𝖠𝖢𝖦𝖾𝗇𝖬 ⁠. Hence, it is a properly distributed access credential for the medical staff associated with the role R⃗=(R′⃗,R) ⁠. ACID←𝖠𝖢𝖦𝖾𝗇𝖯(PK,MSK,ID) ⁠. It is run by TKA when a patient with identity ID requests an access credential in order to access its own EHRs. To do so, TKA picks a random exponent r←RZp and outputs ACID←(g2α·(g3·ghID)r,gr,{ujr}j∈[0,n+1]) (Hdr,EF)←𝖤𝖧𝖱𝖤𝗇𝖼(PK,ID,,EHR) ⁠. When EHR needs to be encapsulated under the patient’s identity ID and the access policy  ⁠, the user (a patient or a medical staff) first picks a random exponent β←RZp and computes the first element of the header C0←gβ ⁠. Next, the user generates the message encapsulation key K←e(g1,g2)β and computes EF←𝖲𝗒𝗆𝖤𝗇𝖼(K,EHR) ⁠. Finally, the user computes w←𝖧(ID∥∥t∥C0) and gets the second element of the header C1←(u0t·ghID·un+1w·g3·∏i∈IuiRi)β ⁠. The encapsulated EHR is formed as (Hdr,EF)←(C0,C1,EF) {0,1}←𝖤𝖧𝖱𝖠𝗎𝖽𝗂𝗍(PK,ID,,(Hdr,EF)) ⁠. Before outsourcing (Hdr,EF)=(C0,C1,EF) to the storage server, the auditor verifies whether the EHR is correctly encapsulated under the specified access policy or not by testing the following equation: e(g,C1)=?e(C0,(u0t·ghID·un+1w·g3·∏i∈IuiRi))(1) w←𝖧(ID∥∥t∥C0) ⁠. If Equation (1) holds, the auditor outputs 1 to indicate the encapsulated EHR is valid. Otherwise, the auditor outputs 0 to alarm related parties. Note that the inputs of EHRAudit are publicly known to all entities. Hence, the auditing procedure can be done publicly. EHR←𝖤𝖧𝖱𝖣𝖾𝖼𝖬(PK,ID,,(Hdr,EF),ACR⃗) ⁠. Given (Hdr,EF)=(C0,C1,EF) stored in the storage server, a medical staff whose role R⃗ satisfies the access policy  ⁠, i.e., R⃗∈Pref() ⁠, can use his/her access credential to decapsulate (Hdr,EF) ⁠. Suppose the access credential for the medical staff associated with the role R⃗ is ACR⃗=(a0,a1,a2,{a3,j}j∈[n+1]⧹IR⃗) The medical staff computes K←e(a0·a2ID·bn+1w·∏i∈I⧹IR⃗biRi,C0)/e(C1,a1) where w←𝖧(ID∥∥t∥C0) ⁠. It finally runs EHR←𝖲𝗒𝗆𝖣𝖾𝖼(K,EF) to get the decapsulated EHR. EHR←𝖤𝖧𝖱𝖣𝖾𝖼𝖯(PK,ID,,(Hdr,EF),ACID) ⁠. The patient with identity ID can decapsulate his/her own EHRs using his/her access credential. Suppose the access credential ACID for the patient associated with identity ID is ACID=(g2α·(g3ghID)r,gr,{ujr}j∈[0,n+1])=(b0,b1,{b2,j}j∈[0,n+1]) The patient computes the encapsulation key K←e(b0·b2,0t·b2,n+1w·∏i∈Ib2,iRi,C0)/e(C1,b1) where w←𝖧(ID∥∥t∥C0) ⁠. Then it also runs EHR←𝖲𝗒𝗆𝖣𝖾𝖼(K,EF) to get its own EHR. Correctness. If an EHR is correctly encapsulated under the specified access policy, then we have that e(g,C1)=e(g,(u0t·ghID·un+1w·g3·∏i∈IuiRi)β)=e(gβ,(u0t·ghID·un+1w·g3·∏i∈IuiRi))=e(C0,(u0t·ghID·un+1w·g3·∏i∈IuiRi)) Hence, Equation (1) holds. The auditing can be approved for the correctly encapsulated EHRs. The medical staff whose role satisfies the access policy, that is, R⃗∈Pref() ⁠, can extract the message encapsulation key K by the following equalities: K=e(a0·a2ID·a3,n+1w·∏i∈I⧹IR⃗a3,iRi,C0)e(C1,a1)=e(g2α·(g3·u0t·∏i∈IR⃗uiRi)r,gβ)e((u0t·ghID·un+1w·g3·∏i∈IuiRi)β,gr)·(ghID·un+1w·∏i∈I⧹IR⃗uiRi)r=e(g2α·(u0t·ghID·un+1w·g3·∏i∈IuiRi)r,gβ)e((u0t·ghID·un+1w·g3·∏i∈IuiRi)β,gr)=e(g2α,gβ)=e(g1,g2)β Therefore, the medical staff with a suitable role can correctly decapsulate and access the EHR from (Hdr,EF) ⁠. The patient with identity ID can also obtain the message encapsulation key K by the following equalities: K=e(b0·b2,0t·b2,n+1w·∏i∈Ib2,iRi,C0)e(C1,b1)=e(g2α·(g3·ghID)r·(u0t·un+1w·∏i∈IuiRi)r,gβ)e((u0t·ghID·un+1w·g3·∏i∈IuiRi)β,gr)=e(g2α·(u0t·ghID·un+1w·g3·∏i∈IuiRi)r,gβ)e((u0t·ghID·un+1w·g3·∏i∈IuiRi)β,gr)=e(g2α,gβ)=e(g1,g2)β Hence, the patient can use its access credential ACID to correctly recover the EHR from (Hdr,EF) ⁠. 4.4. Security results We states that the proposed RBAC scheme achieves the security requirements described in Section 3.2. More formal security analysis is given in Section 5. Data secrecy. The secrecy of EHRs is protected by applying a secure symmetric encryption scheme εsym such as advanced encryption standard (AES) [42]. The message encapsulation key K can only be obtained by the corresponding patient and medical staffs with matching roles. The ones whose roles do not satisfy the access policy cannot extract K to reveal useful information from encapsulated EHRs. Public auditability. The public auditing procedure ensures the legitimacy of encapsulated EHRs. The inequality of Equation (1) shows that the EHR is not encapsulated with the specified access policy, or be tampered by malicious entities. Forward revocation. The lifetime t has embedded in the access credentials of medical staffs. Hence, they can only decapsulate EHRs encapsulated under the assigned lifetime t. Newly uploaded EHRs under lifetime t′≠t cannot be decapsulated by expired access credentials of medical staffs. Note that for each lifetime, TKA generates access credentials for all non-revoked medical staffs. Since ACGenM and ACDeleM are run, respectively, by TKA and junior medical staffs that have high computational abilities, periodically updating access credentials is practical. Also, TKA can pre-generate access credentials for further improving the efficiency. The patients, on the other hand, can still correctly decapsulate their own EHRs since the lifetime is not embedded in their access credentials. However, due to the fact that the identity has been embedded in his/her access credential, the patient can only access EHRs that are encapsulated under his/her identity. 5. SECURITY ANALYSIS 5.1. Formal security definition We first formally define the security model of the proposed RBAC scheme. In this model, an adversary wants to extract useful information from an encapsulated EHR of a patient with identity ID* of its choice. The attacked EHR is encapsulated with an access policy * containing all medical staffs who are allowed to decapsulate it under the lifetime t* ⁠, both of which are chosen by the adversary. The adversary is endowed with great capacity. It can obtain access credentials for patients associated with identities ID≠ID* of its choice. It can further obtain three kinds for access credentials for medical staffs: (1) access credentials associated with roles R⃗∉Pref(*) under the lifetime t* ⁠, which implies that the adversary can collude any medical staff with roles that do not satisfy the target access policy; (2) access credentials associated with roles R⃗ under the outdated lifetimes tt* ⁠, which means that the adversary can obtain access credentials for newly employed medical staffs. In the security model, the adversary can also ask for decapsulation for any encapsulated EHRs of its choice, except the target EHR. The encapsulated EHRs can be honestly generated by the adversary, in which case correct decapsulations are required. However, if the adversary maliciously tampers existing encapsulations and asks for decapsulation, the public auditing procedure, i.e. EHRAudit, can immediately detect such illegitimate encapsulations and reject to decapsulate. In this way, only legitimate encapsulations can be successfully approved to decapsulate. This indicates that the public auditing procedure can precisely detect invalid encapsulated EHRs and alert related entities to prevent such encapsulated EHRs from being stored in the storage server. Even such an adversary cannot distinguish the target encapsulated EHR from a randomly encapsulated EHR, which indicates no information is revealed to the adversary. We define the security model of our RBAC in the classical ‘selective’ setting. The selective security model was coined by Canetti et al. [43] and has been widely used in state-of-the-art cryptographic primitives [35, 44, 45] and schemes [2, 6]. In this security model, the adversary needs to ahead of time declare the target patient’s identity ID* ⁠, the target access policy * ⁠, and the target lifetime t* before seeing the system parameter PK. One may wonder that this requirement is artificial and wish to deploy schemes proven secure under the standard (sometimes called adaptive or full) security model. There exist advanced cryptographic primitives that offer securities under the standard security model [36, 46–48]. However, existing fully secure schemes are built on more complicated bilinear groups, e.g. composite-order bilinear groups or dual pairing vector space, since advanced algebraic properties are required for applying the new and more systematic security proof approach to achieve standard securities. Operations on such groups are much more time-consuming than those on classical bilinear groups (see Experimental results in [49]). Although such security proof approach can be applied to our RBAC scheme [36, 50] to achieve full security, we design our scheme under the selective security model for practicality consideration. Formally, the selective security model of our RBAC is defined through a game played by an adversary  and a challenger C ⁠. Both of them are given the parameters n and λ as inputs. Init.  commits to an identity ID* ⁠, a access policy * and a lifetime t* ⁠, which describes all the users (patients and medical staffs) that  wishes to attack under the lifetime t* ⁠. It sends * ⁠, ID* and t* to C ⁠. Setup. C runs Setup to obtain the system parameter PK and gives it to  ⁠. Phase 1.  adaptively issues three kinds of queries: Access credential query for a medical staff associated with a role R⃗ and a lifetime t, both of which do not simultaneously satisfy R⃗∈Pref(*) and t=t′ ⁠. C generates an access credential for R⃗ and gives it to  ⁠. Access credential query for a patient with identity ID≠ID* ⁠. C generates an access credential for ID and gives it to  ⁠. Decapsulation query for the encapsulated EHR (Hdr,EF) with a patient’s identity ID and an access policy  ⁠. If EHRAudit outputs 1 by taking (Hdr,EF) as an input, then C decapsulates (Hdr,EF) and returns the EHR to  ⁠. Otherwise, (Hdr,EF) is invalid reported by the public auditing procedure and C returns ⊥ to  ⁠. Challenge.  outputs two equal-length EHRs EHR0 and EHR1 ⁠. C flips a random coin b∈{0,1} and encapsulates EHRb under the access policy * ⁠, the identity ID* and the lifetime t* ⁠. C returns the encapsulated EHR (Hdr*,EF*) of EHRb to  ⁠. Phase 2.  further adaptively issues access credential queries for medical staffs, access credential queries for patients, and decapsulation queries for encapsulated EHRs (Hdr,EF) associated with access policies  ⁠. The constraints are that  does not query access credentials for a medical staff with a role R⃗∈Pref(*) under t* ⁠.  does not query an access credential for the patient with the identity ID=ID* ⁠.  does not make decapsulation queries for the target encapsulated EHR (Hdr*,EF*) ⁠. C responds the same as in Phase 1. Guess. Finally,  outputs a guess b′∈{0,1} of b and wins in the game if b′=b ⁠. The advantage of such  in attacking the RBAC scheme with parameters n and λ is defined as Adv,n(λ)=Pr[b′=b]−12 Definition 1 The RBAC scheme is secure if all polynomial time adversaries have at most a negligible advantage Adv,n(λ)winning in the above game. The above definition covers all security properties stated in Section 4.4. ’s capacity of obtaining access credentials for any medical staff under outdated lifetime t