1 d-MABE: Distributed Multilevel Attribute-Based EMR ...renjian/pubs/TSC-d-MABE.pdf · 1 d-MABE:...

1939-1374 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2020.3003321, IEEETransactions on Services Computing

1

d-MABE: Distributed Multilevel Attribute-BasedEMR Management and Applications

Ehab Zaghloul, Tongtong Li, Matt Mutka and Jian Ren

Abstract—Current systems used by medical institutions for the management and transfer of Electronic Medical Records (EMRs) canbe vulnerable to security and privacy threats. In addition, these systems are centralized, often lack interoperability, and give patientslimited or no access to their own EMRs. In this paper, we propose a novel distributed data sharing scheme that applies the securitybenefits of blockchain to address these concerns. We deploy smart contracts on Ethereum blockchain and utilize a distributed storagesystem to alleviate the dependence on the record-generating institutions to manage and share patient records. To preserve privacy ofpatient records, we implement our smart contracts as a method to allow patients to verify attributes prior to granting access rights. Ourproposed scheme also facilitates selective sharing of medical records among staff members that belong to different levels of ahierarchical institution. We provide extensive security, privacy, and evaluation analyses to show that our proposed scheme is bothefficient and practical.

Index Terms—EMRs, distributed data sharing, Ethereum blockchain, smart contract, symmetric, and attribute-based encryption.

F

1 INTRODUCTION

Record-sharing between medical institutions can help im-prove medical diagnoses, treatment decisions, and enhancethe overall patient experience. However, the current meth-ods used to manage and share medical records can beinefficient or limited due to the lack of interoperable sys-tems. Institutions may integrate computerized systems tostore EMRs, however, in most cases, these systems are notdesigned to communicate with one another resulting inadditional overhead costs when sharing patient records.In addition, patients generally must rely on the record-generating institution to do the sharing in an efficient, se-cure, and private way. This incurs additional computationalcosts to safely store, maintain, and transmit records whenrequested by other institutions. Furthermore, some nationsmay have insufficient legal requirements associated withsharing of patient records which makes patient data espe-cially vulnerable to security and privacy threats. In the caseof a nation with a central healthcare network, the systemsemployed may be mis-managed, antiquated, and potentiallyjeopardize patient data. Therefore, there has been an effortto develop comprehensive, secure, and private electronicrecord sharing systems that also eliminate reliance on therecord generating institution.

In the U.S., the Health Insurance Portability and Ac-countability Act of 1996 (HIPAA) [1] sets a guideline forsecure and private use of patient health data. It does notdefine, however, how these systems are to be developed andapplied. As a result, many centralized and private applica-tions have come to market in the U.S. as ways to manageEMRs. Because these systems are often built on propri-etary technology, lack of interoperability between medicalinstitutions is a major concern. Meaning that, in majority,the burden of transferring health records lies on patients,

The authors are with Michigan State University, East Lansing, MI 48824-1226, Email: {ebz, tongli, mutka, renjian}@msu.edu

often times in printed copies from one medical institutionto another. In other cases, patient records are transferredvia fax or systems similar to electronic mail. These commontransfer methods can be inefficient and possibly jeopardizepatient privacy and data security. There is also a lack ofan auditable trail of data transfer, and there is no way topreclude who will view a patient record on the other end ofa fax. Lastly, in cases where there is no likely method of datatransfer or data cannot be trusted, physicians may resort toduplicate testing causing resource waste.

Other nations with universal healthcare may use a na-tional system, such as the National Health Service (NHS) [2]in the United Kingdom. The NHS serves as a centralizednational authority allowing patients and medical institu-tions to share records efficiently. Many features of the NHSsystem provide advantages that address the challenges ofrecord-sharing seen in the U.S. health system. As part ofthe NHS, patients have free access to a service named theSummary Care Record (SCR) [3]. This service can providemedical institutions essential information of the patient incases where the patient is being treated by someone otherthan their General Practitioner (GP). The NHS providespatients some control over how their data is shared withthe ability to opt-out of the SCR using an SCR opt-outform. However, while the NHS system may address somechallenges with sharing patient data effectively, the use of acentralized system presents security and privacy complica-tions. To complete the SCR opt-out form, a patient must fillout the form and send it to their GP’s practice in either paperor digital format. Depending on the administrative practicesof the GP, action in response to the form may take days toweeks to complete. In addition, since the NHS is a centralentity when compared to individual medical institutions inthe US system, a malicious actor could potentially accessmore patient EMRs if the system becomes compromised.

In this paper, we propose a novel distributed record shar-ing scheme that leverages blockchain and smart contracts to

Authorized licensed use limited to: Michigan State University. Downloaded on August 04,2020 at 17:41:03 UTC from IEEE Xplore. Restrictions apply.



2

eliminate the record-generating institution from the record-sharing process. Blockchain technology was first introducedin 2009 with the evolution of the digital cryptocurrency,Bitcoin [4], as a result of growing security concerns asso-ciated with the reliance on a central party. One of the maingoals of this project was to eliminate the need of a trustedthird party, such as banks, to facilitate payments betweenindividuals. Shortly after the advent of Bitcoin, based onthe concept initially introduced by Nick Szabo in 1994 [5],smart contracts were incorporated into blockchain-basedsystems. Smart contracts are self-executing pieces of codethat can digitally enforce and facilitate verified negotiationsof contracts between two participating individuals withoutthe need of a trusted third party. They continue to appear intoday’s systems such as Ethereum [6], which aim to provideservices beyond simple payments. Using such smart con-tracts, users can design and customize their own systemson top of blockchains such as Ethereum. Similar to pay-ment transactions, the deployment and execution of smartcontracts is immutable, irreversible and can be tracked overthe public blockchain. Therefore, smart contracts are wellsuited to facilitate data management and sharing. They canbe used by data owners to define access control mechanismsthat grant certain data users access to the data.

Our proposed work aims at solving the security andprivacy challenges and interoperability issues of the currentsolutions. In the existing systems, EMRs are stored withinthe generating institution, which significantly limits thepatients’ access to their own records. They must also trustthat the institutions will not leak any sensitive informationof their EMRs to unintended organizations. In comparison,our proposed work empowers them over their EMRs. First,it provides record ownership to the patients, allowing themto be in actual possession of their records, rather than havethem stored by the generating institution. Second, it allowspatients to selectively share different parts of their recordswith distinct data users based on their privacy preferences.

The work presented in this paper expands significantlyon the model presented in [7]. In this model, patients haveno method to monitor access to their EMRs. They must relyon trusted third parties to efficiently share this information.In comparison, our proposed scheme is distributed in termsof data management and storage, and grants patients con-trol over their records, thereby minimizing the dependencyon the trusted third parties. Patients can also independentlytrace the history of access to their EMRs. The main contri-butions of this paper can be summarized as follows:

1) We develop a novel distributed electronic medicalrecord-sharing scheme for patients that is secure,preserves the privacy of patient data, and is moreefficient than traditional paper record sharing.

2) We propose a distributed method for verifyingmedical institution staff member attributes over theblockchain before issuing them access keys. Thismethod can help minimize blind reliance on key-issuers whose behavior cannot be verified whenvalidating attributes of staff members.

3) We conduct comprehensive security and privacyanalyses of the proposed scheme.

4) We implement our proposed scheme using smart

contracts and deploy them over the Ethereumblockchain for performance evaluation and empir-ical results.

The rest of this paper is organized as follows. In Sec-tion 2, the related work is reviewed. In Section 3, prelimi-naries are introduced that summarize key concepts used inthis research. Next, in Section 4, the problem formulationis described, outlining the system model and our designgoals. In Section 5, our proposed scheme is presented indetail, outlining the proposed algorithms. Following that, inSection 6 we formally prove the security of our proposedscheme. In Section 7, we present a performance and ap-plication analysis that is supported with numerical results.Finally, in Section 8, a conclusion is drawn to summarizeour research.

2 RELATED WORK

In 2015, a decentralized data management scheme wasintroduced that facilitated access-control management overa blockchain [8]. In this system, the actual data records arestored in an off-blockchain storage while pointers to theserecords are maintained by a key-value storage over theblockchain. This solution helps simplify the amount of dataprocessed on the blockchain. However, the method usedto define access policies in this scheme does not considerhierarchical data sharing. A user that desires to share filesselectively among multiple users in a hierarchy will have todefine several access policies that could become a complexproblem as the number of users increases drastically.

In 2016, MedRec [9], the first functional electronic med-ical record-sharing system built on some concepts from [8]was introduced. This work builds on three Ethereum [6]smart contracts that manage the authentication, confiden-tiality, and accountability during the data sharing process.In this system, the primary entities involved in maintainingthe blockchain are the parties interested in gaining data,such as researchers and public health authorities. In return,the institutions are rewarded with access to aggregate andanonymized data. However, the success of such a system isdependent on the participation of entities that maintain thesystem in return for data. Similar to [8], MedRec does notconsider hierarchical data sharing.

In 2017, another functioning electronic medical record-sharing scheme was presented to provide a secure solutionusing blockchain [10]. However, the system uses a cloud-based storage system to store medical records. With cen-tralized storage, the system becomes liable to a single pointof failure. Moreover, similar to MedRec, this work buildsover a private and monitored blockchain where each nodeinvolved in maintaining consensus is known. In compari-son, our proposed work eliminates the need for centralizedstorage by relying on distributed storage such as IPFS. It alsobuilds over a permissionless blockchain instead of a privateone, mitigating the reliance on predefined validating nodesin a private blockchain setting. Moreover, in contrast to bothschemes, we also present a security analysis and show thatour proposed is secure against potential attacks.

In 2018, a study was conducted to discuss several openproblems in order to use blockchains for data managementand analytics [11]. The study shows that more research




3

is required in order to leverage the capabilities of currentdata management systems into blockchain-based models. Inaddition, the study reflects the importance of improving thesecurity and privacy countermeasures.

3 PRELIMINARIES

3.1 Ciphertext Policy Attribute-Based EncryptionCiphertext Policy Attribute-Based Encryption (CP-ABE) isa fine-grained access control and encryption scheme [12].It allows users to share their data selectively by usingaccess policies that are integrated into the ciphertexts duringencryption. CP-ABE formally divides the process into fourmain functions.

(i) Setup(1κ): a probabilistic function with input securityparameter κ. The function is performed by a key-issuer togenerate a public key PK and the master key MK.

(ii) KeyGeneration(MK,A): a probabilistic function car-ried out by a key-issuer to generate a unique secret keySK for a data user based on the MK and a set of attributesA = {A1,A2 . . . ,An} possessed by the user.

(iii) CPABE-Enc(PK,m,T ): a probabilistic function car-ried out by the data owner to encrypt message m under anaccess policy T and generate ciphertext CT.

(iv) CPABE-Dec(CT,SK): a deterministic function car-ried out by the data user to decrypt a ciphertext CT usingthe uniquely generated secret key SK for the user.

3.2 Privilege-based Multilevel Organizational Data-sharingPrivilege-based Multilevel Organizational Data-sharingscheme (P-MOD) [13] is an extension of the CP-ABE thathandles data sharing in complex hierarchical organizations.P-MOD partitions a data file into multiple segments basedon user privileges and data sensitivity. Each segment of thedata record is shared according to user privileges and theset of attributes that satisfy the hierarchical access policies.Privilege-based Access Structure: The privilege-based ac-cess structure divides the data users of an organization intoa hierarchy that consists of k levels, {L1,L2, . . . ,Lk}. Eachlevel is associated with an access policy, {T1, T2, . . . , Tk}. Anaccess policy Ti specifies a set of rules defined using logicgates and the different sets of attributes that can satisfy theserules. Data users in possession of a correct set of attributesthat can satisfy a certain access policy Ti belong to level Li.Data Partitioning and Encryption: The data owner par-titions a data file F into a set of k record segments, thatis F = {F1,F2, . . . ,Fk}. Segment F1 contains the mostsensitive information of F that is to be shared with datausers belonging to level L1. Segment Fk contains the leastsensitive information of F that is to be shared with alldata users belonging to any level. Next, the data ownergenerates a set of secret keys {sk1, sk2, . . . , skk} to encryptthe corresponding segments of F . The key sk1 is randomlyselected by the data owner. The remaining keys are thenderived using a cryptographic hash function Hash as follows

ski+1 = Hash(ski). (1)

A privileged data user that satisfies access policy Tibelongs to level Li and is granted key ski. Given ski, the

data user can derive keys {ski+1, . . . , skk} belonging tolevels {Li+1, . . . ,Lk} as defined in equation (1). However,given the properties of Hash function, ski cannot be usedto derive any of the keys {sk1, . . . , ski−1}. Each Fi ∈ F isthen encrypted with its corresponding generated secret keyski. Finally, each ski is encrypted with CP-ABE under itscorresponding access policy Ti.

3.3 Blockchain

A blockchain is a public ledger that stores all the crypto-graphically processed transactions performed over a peer-to-peer (P2P) network. For presentation purposes, we referto Ethereum, an open source blockchain-based networkthat provides its users with a platform to build, deployand run decentralized applications [14]. The P2P networknodes offer a decentralized Turing-complete virtual machinenamed the Ethereum Virtual Machine (EVM). It can executesmart contracts deployed by the users over the public andnon-trusted network nodes. In addition, log entries maybe contained in receipts which are attached to transactionsexecuted by the EVM. These logs represent the results ofevents fired from the smart contracts.

3.4 InterPlanetary File System

InterPlanetary File System (IPFS) [15] is a peer-to-peer (P2P)network used to store and share content-addressable dataover the network nodes in a distributed manner. The net-work runs a stack of protocols that are responsible forstoring and accessing the data stored over it.

Identities: To join the P2P network, nodes first generateunique node identities before establishing connections.

Network: The network layer in IPFS manages the estab-lished connections between the connected peers.

Routing: The routing layer keeps track of the addresses ofnodes within the network and the data they store. It usesa Distributed Hash Table (DHT) to identify the data storedover any node of the network.

Exchange: IPFS uses BitSwap, a data exchange protocolinspired by BitTorrent [16], to exchange data between nodes.

Objects: IPFS partitions data files into segments andcryptographically hashes each segment, where the hashesare used to reference the location of the correspondingsegments.

4 PROBLEM FORMULATION

Upon visiting a medical institution, a patient interacts witha wide spectrum of distinct staff members that may includebut is not limited to: admittance staff members, physiciansassisted by nurses and technicians that provide the re-quired treatment, and maybe even financial or dischargingstaff members. If those staff members can individually andefficiently access the necessary parts of previous medicalrecord(s) of the patient generated by other institutions re-quired to perform their specific jobs, they can provide thepatient with expedited admittance and enhanced diagnosisand treatment decisions, reducing the overall time spentduring the visit. For example, an ER physician may learn




4

severe drug allergies or current medication for an unre-sponsive patient being rushed into the ER from his/herprevious records. As a result, the physician can preventiatrogenic illnesses caused by administering inappropriatemedication to that patient or harmful drug interactions.By accessing critical medical information, patient safety isenhanced while saving time and resources. However, forthe sake of patient privacy, only necessary staff membersshould be given permission to access patient record(s) fromthe medical history determined by the profile of the patient.

In this paper, we denote a record generated by an insti-tution for a patient as R. We denote the record attributes as{Rj ∈ R | 1 ≤ j ≤ n}, where n is the maximum number ofattributes within the record. Record attributes may includeprevious medical history, medical treatment, lab tests, med-ication, personal information, financial statements, creditcard information, and others. The corresponding attributevalues of the record generated for the patient can be denotedas {a(Rj) | 1 ≤ j ≤ n}.

In current systems, records often have a variety of at-tributes and may be blocked or intentionally delayed bycompetitive record-generating institutions. To prevent this,record-generating institutions should have minimal controlover the records of patients whereby empowering patientsover their own records. Patients may have different attitudesin terms of sensitivity of their record attributes. The chal-lenge today is to provide patients with a method that allowsthem to share the attribute values of their records efficientlyand securely while maintaining the privacy preferences theydesire. Patients should also be able to selectively sharecertain parts of their record(s) with the healthcare providersthey select. Although patients may not easily understandhow to share the medical parts of their record(s), empower-ing them would at least allow them to consult their trustedmedical staff such as their Primary Care Physicians (PCPs)to decide on how and which parts of their medical record(s)are to be shared. With their consent, patients may evendelegate this process to such entities to avoid situations suchas being unconscious, requiring someone to make decisionsfor them. Lastly, patients should not be concerned withthe availability nor the guaranteed secure storage of theirrecords.

4.1 System ModelThe general model of our proposed record-sharing schemeis illustrated in Fig. 1. The system consists of six mainentities:Patients: Patients are data owners that wish to sharetheir data selectively based on their privacy preferences. Wedenote the set of patients as {pa ∈ P | 1 ≤ a ≤ ∞}.Medical institutions: Medical institutions provide treat-ment and generate medical records for the patients. Wedenote the set of medical institutions as {mb ∈ M | 1 ≤b ≤ ∞}.Staff members: Personnel employed at a medical in-stitution. We denote the set of staff members at medicalinstitution mb as {sb,l | ∀ 1 ≤ l ≤ ∞}. Staff members arecategorized into groups of similar characteristics based onthe set of attributes A = {A1,A2 . . . ,An} they each possess.Attributes represent identifiers that are selected from an

Key-Issuer

Medical Institution

Patient

Distributed Storage P2P network

BlockchainP2P network

2. Accesspolicy 1. Partition and

encrypt 3. Visit

4. Request access permissions

5. Granting keys

7. Record fetching

6. Fetch keys

Most SensitiveLess Sensitive

Least Sensitive

Fig. 1: General scheme orchestration.

infinite pool set. They may be as general as the role of astaff member and could be as unique as a biometric.Key-issuer: A semi-trusted party that generates keys forpermissioned staff members upon their requests to accessparts of the record.Distributed storage P2P network: A non-trusted P2Pnetwork used by the patients to store and share their recordswith staff members at any medical institution.Blockchain P2P network: A non-trusted P2P network thatmaintains a blockchain to regulate access permissions ofpatient records to the staff members of medical institutions.

In general, in order for patients, medical institutions,staff members or key-issuers to interact with any of the twoP2P networks, they must run nodes that are capable of con-necting to either network. These nodes may be light-weightnodes (similar to the simple payment verification nodes inBitcoin [4]) that can assemble transactions and propagatethem to the network. Running light-weight clients does notrequire powerful computing machines and can be donevia simple machines such as mobile devices making ourproposed scheme accessible to everyone. The common re-quirement for running either node is being able to generatethe public key pub and private key pr pair.

4.2 Design GoalsOur proposed scheme aims at satisfying the following:Data Ownership: Patients are empowered over theirrecords and control how to share them.Fine-grained access control: Patients can grant specific ac-cess permissions to the desired staff members based on theirprivacy preferences. They can selectively share any part oftheir records using any set of staff member attributes theywish, limiting access to specific parts of their record and tocertain staff members at particular medical institutions.Collusion resistant: Two or more staff members thatpossess different sets of attributes and/or are employedat the same/different institution(s) cannot combine theirattributes to gain access to any part of the records they arenot authorized to access individually.Data confidentiality: Records are completely protectedfrom any unauthorized staff members that do not possessthe correct set of attributes predefined by the patient. Thisincludes any type of space that stores the records for thepatients.Distributed storage: Patient records are stored in a dis-tributed storage network. They can be accessed at anytime and by any permissioned staff member. Storage isnot centralized and/or controlled by the record-generatinginstitution.




5

TABLE 1: NotationsSymbol Definition

pa the ath patient in the set of patients Pmb the bth medical institution in the set of institutions Msb,l the lth staff member working at mb

pr private key of sb,lpub public key of sb,lA the set of attributes of a staff memberTi the ith access policy defined by patient at level Li

ski the ith secret key belonging to TiSBK subscription-based keyRi the ith partition of record RERi the ith encrypted record partition under ski‖SBKPK public key of key-issuerMK master key of key-issuerEski encryption of ski under PKSK secret key issued for a staff memberESK encryption of SK under pub

Data access trace-ability: Patients can trace-back to the en-tire history of accesses of their records. This allows patientsto keep track of how their records are being accessed.

5 THE PROPOSED d-MABE SCHEME

In this section, we first present an overview of the majorchain of events in our proposed scheme. For discussionpurposes, we assume that a patient pa has already receivedsome medical treatment at institution mb and that a medicalrecord R was generated for him/her. We also assume thatpa anticipates visiting some other institution {mb | b ≥ 1} inthe future and would like to share R selectively among itsstaff members. Based on our description, we then propose ageneralized structure through three smart contracts that canbe deployed on a blockchain. We assume patients and datausers interact with our smart contracts via easy-to-use anduser-friendly interfaces, hence, onboarding new users to ourproposed model becomes a trivial task.

5.1 Scheme OrchestrationThe proposed scheme can be divided into seven majorevents as demonstrated in Fig. 1.

Record partition and encryption: Following the workpresented in [13], pa initially defines a privilege-based ac-cess structure that satisfies his/her privacy desires. Theaccess structure is divided into k levels {L1,L2, . . . ,Lk}where each level is associated with an access policy{T1, T2, . . . , Tk}. The pa then partitions R into k segments{R1,R2, . . . ,Rk} of different sensitivity. Each Ri ∈ R mayrepresent one or more record attribute(s) depending on howpa partitions R. Next, pa derives a set of symmetric keys{sk1, sk2, . . . , skk} as described in Section 3.2. Using thesekeys, pa then encrypts each corresponding Ri ∈ R as

ERi = Sym-Encski‖SBK(Ri), (2)

where Sym-Enc is a symmetric encryption algorithm suchas the Advanced Encryption Algorithm (AES) and SBKdenotes the subscription-based key. The SBK can only beaccessed by either a system call or an attributed-based pro-tection to active members through successful membershipsubscription authentication. Members have no direct accessto SBK and can only use it while on-site. This design servestwo purposes: (i) it prevents any users from sharing the

ERi’s even if they share their ski’s with others and givethem unprivileged access and (ii) it provides an easy optionto disable unsubscribed members from accessing EMRs. Inother words, with this design, key revocation is no longerneeded. Finally, using the Encryption function discussed inSection 3.1, pa encrypts each ski under its corresponding Tidefined in the privilege-based access structure, such that

Eski = CPABE-Enc(PK, ski, Ti), (3)

where CPABE-Enc is the CP-ABE encryption functionand PK is the public key generated during the Setupphase. The pa then stores the generated ciphertexts{ER1,ER2, . . . ,ERk} and {Esk1,Esk2, . . . ,Eskk} over IPFS.

In cases that EMRs consist of multiple/diverse at-tributes, it may be a burden for patients to define theirprivilege-based access structures and may even leak sen-sitive information if defined inappropriately. A possibleapproach that patients may consider is to divide theirrecords into multiple categories based on the nature of databeing shared. For example, a record could be divided intopersonal information, medical information, and financialinformation. For each category, a patient can then definea separate privilege-based access structure which wouldreduce the overall complexity of each structure. Patientsmay even consult their trusted Primary Care Physicians(PCPs) on how to define a privilege-based access structurefor proper medical information sharing.

Access policy: To facilitate data management and shar-ing, pa shares the privilege-based access structure that in-corporates the access policies {T1, T2, . . . , Tk}. The accessstructure is incorporated into a smart contract that is thendeployed over the blockchain.

Medical institution visit: When pa visits a medical insti-tution {mb | b ≥ 1} to get medical treatment, pa interactswith various staff members that may or may not belong toa predefined privilege-based access structure.

Requesting access permissions: Permissioned staff mem-bers will be granted access to certain parts of a record basedon the attributes they possess. To request access, a staffmember sb,l interacts with the smart contract previouslydeployed by pa that incorporates the privilege-based ac-cess structure. The smart contract will verify whether thesb,l possesses a set of attributes that can satisfy an accesspolicy within the access structure. Once the verification isperformed the smart contract will publicly announce theaccess permissions of the sb,l over the blockchain.

Granting keys: The key-issuer continuously monitors theblockchain for access announcements. An announcementcontains the set of attributes A that the sb,l possesses. Itis a form of verification to the key-issuer that the sb,lpossesses set A before generating a secret key SK using theKeyGeneration function described in Section 3.1. The key-issuer then encrypts SK with the public key pub of sb,l as

ESK = Asym-Encpub(SK), (4)

where Asym-Enc is the asymmetric encryption function. Toshare the key with the sb,l, the key-issuer transacts with aglobal smart contract that publicly announces the encryptedkey over the blockchain.




6

Algorithm 1: SMR smart contract

1 struct staffMember contains2 staffID3 staffAttributes[upBound]4 end

5 variable mapping(address→ staffMember) Map

// Adding a new staff member6 function

addStaffMember( address, id, attributes[upBound])7 if (msg.sender 6∈ setOfCertifiers) then8 throw9 else

10 Map( address→ id, attributes[upBound])11 end12 end

// Return the attributes of a staff member13 function getAttributes( address)14 return Map[ address].staffAttributes15 end

Key fetching: The sb,l can obtain the uniquely encryptedsecret key ESK by monitoring the announcements madeover the blockchain. Once obtained, the sb,l can decrypt ESKusing his/her private key pr that corresponds to the publickey pub such that

SK = Asym-Decpr(ESK), (5)

where Asym-Dec is the asymmetric decryption function.Record fetching: The storage location of the encryptedEMRs over IPFS is also provided to the sb,l in an encryptedform under his/her public key in the announcement madeover the blockchain. The sb,l decrypts the IPFS location tofetch the EMRs. Here, the sb,l possesses the necessary key todecrypt the parts he/she has been granted access to. Oncefetched, the sb,l can decrypt the encrypted symmetric keyEski using the derived key SK as explained in Section 3.1.That is

ski = CPABE-Dec(Eski,SK), (6)

where CPABE-Dec is the CP-ABE decryption function. Afterobtaining ski, the sb,l can derive the remaining set of secretkeys {ski+1, . . . , skk} using equation (1). Finally, the sb,l candecrypt each encrypted partition, such that

Ri = Sym-Decski‖SBK(ERi), (7)

where Sym-Dec is the decryption function.

5.2 Smart ContractsOur proposed scheme includes three main smart contracts:(i) staff member registration, (ii) access verification andpermission announcements, and (iii) granting keys.Staff member registration: Staff Member Registra-tion (SMR) is a global smart contract that registers staffmembers of medical institutions for patient EMRs access.The process of registering staff members by interacting withthis smart contract can be delegated to a number of certifiedinstitutions that verify staff members against their possessedattributes before registering them. This is achieved by in-corporating precise policies into the smart contract which

Algorithm 2: AVPA smart contract

1 Initialized variables address = SMR address2 event LogAnnounce(address, attributes, Ti)3 function verifyRequest( msg, σ)

// Verify 1: validate digital signature4 signer← ecrecover( msg, σ)5 if (signer 6= Hash(pub)) then6 throw7 else

// Verify 2: fetch stored attributes of the staffmember

8 r← SMR( address)fetched← r.getAttributes(signer)

// Verify 2: fetched attr. vs access policies9 for i← 1 to k do

10 if (satisfy(Ti, fetched) == true) then11 LogAnnounce(signer, fetched, Ti)12 break13 end14 end15 end16 end

requires certain identities to trigger it. Once a certified insti-tution verifies the attributes of a staff member, it executes thesmart contract and uses the attributes as input. This resultsin the attributes are stored over the blockchain. This processmaps the identity (in our case the Ethereum address) of thestaff member to the set of attributes possessed. By observingthe blockchain, we can trace-back the on-going activity ofthese certified institutions as they add, delete, or modifythe information of staff members, hence, we can also detectmalicious data manipulation.

Algorithm 1 outlines the general functions of the SMRsmart contract. Lines 1-4 represent a generalized data struc-ture staffMember that the smart contract uses to store newstaff members. It incorporates the identity staffID and the ar-ray of attributes staffAttributes of the staff member. Lines 6-15 represent the two main functions addStaffMember andgetAttributes of the smart contract. The addStaffMemberfunction allows only certified institutions setOfCertifiers toupload the data of new staff members after physically ver-ifying their attributes. This conditioned access is to preventmalicious attackers from granting access to themselves orothers. On the contrary, the getAttributes function can becalled by any user. Given the address address of a specificstaff member, this function returns the previously verifiedand stored attributes of this staff member.

Access verification and permission announcements: TheAccess Verification and Permission Announcements (AVPA)is a unique smart contract defined by each patient thatincorporates his/her personally defined privilege-based ac-cess structure in order to facilitate the selective recordmanagement and sharing. The staff members interested inobtaining parts of the record interact with AVPA contracts torequest access permissions. The smart contract is outlined inAlgorithm 2.

The smart contract performs a sequential verifica-tion process. This is represented in a single functionverifyRequest that takes two inputs: a message msg prior




7

Algorithm 3: GK smart contract

1 event LogKeys(staffAddress, ipfsAddress)

// Sharing the location of a generated access key2 function addKey( staffAddress, ipfsStorageAddress)3 if (msg.sender 6∈ setOfIssuers) then4 throw5 else6 LogKeys( staffAddress, ipfsStorageAddress)7 end8 end

to being signed and its signature σ. That is

msg = Hash(staffID), (8)σ = Sign(pr, pub, msg), (9)

where Hash is the hashing function and Sign is an ECDSAsigning function.

In the initial verification process, the AVPA smartcontract uses an ECDSA compatible validation functionecrecover( msg, σ) to validate σ by verifying whether

ecrecover( msg, σ) = Hash(pub) (10)

holds true. In fact, if the validation function is conductedtruthfully, then the correctness of equation (10) follows fromthe ECDSA. Next, the signer is compared to the addressof the requesting staff member as shown in line 5. If theaddresses match, the contract uses the signer to fetch thepreviously verified and stored attributes of this staff mem-ber in the SMR contract. However, this method is liable toreplay attacks. In section 6, we discuss this issue and ourproposed countermeasure.

If the initial verification is successful, the contract exe-cutes the second verification as outlined in lines 10-14. Inthis process, the fetched attributes are checked against theaccess policy Ti within the access structure. The access struc-ture is defined by the patient during contract deploymentand maintains the desired privacy settings as discussed inequations (2) and (3). The access policies are tested sequen-tially starting from the highest ranked access policy T1 atlevel L1. If the attributes satisfy the access policy Ti, theverification is discontinued and the function fires an eventLogAnnounce that announces a permanent log of the smartcontract transaction stored over the blockchain. This eventis a public and immutable announcement to ensure thatthe staff member in possession of signer should be grantedaccess to the parts of the record {Ri . . . Rk} correspondingto levels {Li . . .Lk}.Granting keys: Granting Keys (GK) is a global smartcontract that is used to share the location of the generatedand encrypted access keys over the distributed storage. Thecontract generally consists of a single function, addKey, asoutlined in Algorithm 3.

When the key-issuer observes a LogAnnounce event firedby the AVPA smart contract, it generates an access secretkey SK for the specified staff member using the unique setof attributes fetched stored in the logs. Next, the key-issuerencrypts this access key as shown in Equation 4 with thepublic key of the staff member. It also encrypts the IPFSrecord location as ERA = Asym-Encpub( ipfsRecordAddress)

with the same public key and uploads both values to theIPFS storage, maintaining their reference location. Followingthat, the smart contract fires an event, LogKeys as shown inline 6, which permanently stores the address of the request-ing staff member staffAddress along with the IPFS stor-age location ipfsStorageAddress. Using ipfsStorageAddress,the staff member can fetch the encrypted key ESK andERA stored over the network. However, as shown in theaddKey function, only certified key-issuers setOfIssuers arecapable of triggering this function. Therefore, attackers areprevented from spamming the smart contract logs with fakekeys or addresses. The staff member can listen for these firedevents and obtain the corresponding ipfsStorageAddress asit appears in the logs. Using the ipfsStorageAddress, thestaff member can fetch ESK and ERA from the network.It is important to note that only the staff member in pos-session of the private key pr corresponding to the publickey pub will be able to decrypt the fetched encrypted keyand IPFS record address. Attackers continuously listeningto the fired events may be able to learn certain IPFS ad-dresses storing generated encrypted keys, but not the actualkeys or the record address. First the data user decryptsipfsRecordAddress = Decpr(ERA) to learn the location of

the encrypted record. Next, using the obtained secret keySK, the staff member can then decrypt Eski to generate thesecret key ski. Finally, the staff member can decrypt ERistored over IPFS at ipfsRecordAddress to obtain the recordpart Ri.

5.3 Access Permission Revocation

Attributes possessed by members may change over timedue to, for example, job switch or retirement. As a result,the access rights to the patient records should be revoked tobe consistent with the access policy. However, this could bechallenging since it requires the attributes of the staff mem-bers to be updated periodically. While adding an expirationdate [17] to each attribute when registering staff membersseems to be a simple solution, it requires the patients toincorporate time constraints into their access policies.

The proposed d-MABE scheme can handle access per-mission revocation efficiently without requiring any extraprocess for the key-issuer. The staff members only need tobe registered to ensure attribute-based access control. Asa result, if at any point in time a staff member is unableto provide evidence of registration to the level of accessclaimed, future access to the patient records will be dis-abled. Consequently, if the staff member attempts to requestrecords he/she is no longer entitled to access, the AVPAsmart contract will fail to verify the request.

For data users that have already accessed certain recordsand are no longer registered, our proposed scheme can alsorevoke their access permissions since each record partitionRi is encrypted under ski‖SBK. To revoke access from thosedata users that are no longer registered, the patient onlyneeds to generate a new subscription-based key SBK thenre-encrypt his/her record partitions under ski‖SBK. Thisdesign does not require regenerating a new set of keys{sk′1 . . . sk′k} or making any changes to the privilege-basedaccess structure. To prevent any data user that has beengranted key ski at some point with an inactive membership




8

from accessing the record partitions, we only need to re-encrypt the record partitions either periodically (such asmonthly), or based on demand.

6 SECURITY AND PRIVACY ANALYSIS

In this section, we present the security and privacy dis-cussions of our proposed scheme. We assume our systemruns over a blockchain that is maintained by a signifi-cant number of nodes, for example, Ethereum. In suchblockchain platforms, it is very expensive to tamper withverified transactions processed into blocks. The best bet ofthe attackers would be to control more than half of thecomputational power in the network in order to perform51% attacks. We also consider distributed storage networkssuch as IPFS that are content addressable. These networksuse the hash computation of the original data when storingand referencing it over the network nodes, resulting intamper-resistant storage. Moreover, we consider adversariesthat can act as any entity within the system and can man-age to connect to either the IPFS or the blockchain net-work. Such adversaries are capable of generating fraudulenttransactions and propagating them through the blockchainnetwork. By fraudulent transactions, we mean transactingwith smart contracts in an effort to access data to whichthey are not granted access. They may also deploy theirown smart contracts over the blockchain, request/store dataover the IPFS nodes, and continuously monitor the networkchannels.

6.1 Security Analysis

We first discuss how our proposed scheme is secure againstpotential attacks. Next, we present good practices that mayhelp improve the security of the system.

Theorem 1. The proposed scheme is secure against replay attacks.

Proof. The initial verification process performed by theAVPA smart contract requires the requesting staff mem-bers to submit ECDSA digital signatures σ to prove theiridentities. Given that all data sent over the blockchain ispublic, malicious attackers can easily maintain a copy of thesubmitted signatures and later on impersonate the honeststaff members, giving them access to data they should notbe able to access. To work around this issue, staff membersare required to time-stamp their digital signatures beforetransacting with the AVPA contract, such that

σ ← Sign(pr, pub,Hash(staffID‖T)), (11)

where T is the time at which the signature is generated.Any submitted time-stamped signature is stored over theblockchain in order for the nodes to check if it has beensubmitted before. The blockchain nodes will not execute anyrequests associated with time-stamped signatures that haveappeared previously. Therefore, to be able to perform replayattacks requires the attackers to reverse the transactions thatcontain an already used digital signature. The success ofreversing a transaction can be modeled as a race betweenthe honest miners and the attackers trying to generate blocksby competing to solve a hard cryptopuzzle known as Proof-of-Work [4]. The race can be modeled as a binomial random

walk. It is denoted as z which represents the number ofblocks generated by the honest miners with computationalpower p minus the number of blocks generated by theattackers with computational power q = 1 − p. This racecan be derived as

zi+1 =

{zi + 1, with probability p,zi − 1, with probability q.

(12)

Using the negative binomial distribution, we can modelthe probability of success of the attackers. Assume the keygenerator waits for n blocks to be generated by the honestminers with computational power p before generating aprivate key for the requesting attacker. Also assume that, atthat time, the attacker is able to secretly generate m blockswith computational power q = 1−p, wherem = n−z−1. Bydefinition, this can be modeled as the m number of blocksthat the attacker can generate before the n number of blocksgenerated by the honest miners. Therefore, the probabilityof a reversing a transaction for a given value m is

P (m) =

(m+ n− 1

m

)× pnqm. (13)

Overall, the probability for an attacker to surpass suc-cessfully the number of blocks generated by the honestminers can be computed as

Ps =∞∑m=0

P (m)×Qn−m−1

= 1−∞∑m=0

(m+ n− 1

m

)× pnqm

×

1−(qp

)n−m, if q < p or k ≤ n−m,

1− 1 = 0, if q > p or k > n−m.

(14)

Equation (14) confirms that when q > p, the attacker willalways succeed since Ps = 1. When q < p, the probabilityof success can be defined as

Ps = 1−n−1∑m=0

(m+ n− 1

k

)× pnqm ×

(1−

(q

p

)n−m)

= 1−n−1∑m=0

(m+ n− 1

m

)× (pnqm − pmqn). (15)

Therefore, as more blocks are appended to theblockchain and q < p, replay attacks are infeasible. More-over, by incorporating active registration, we can limit thepool of malicious attackers to only the staff members withthe same level of access, making it even more infeasible.

Theorem 2. The proposed smart contracts are collusion resistant.

Proof. Our proposed scheme requires staff members to beregistered through the SMR contract before being able torequest access permissions through the AVPA contracts.During registration, each member address is mapped to asingle set of attributes A = {A1,A2 . . . ,An} after providingproof of possession to the certified institutions. The AVPAcontract can only accept a single signature as input whentriggered. Therefore, to perform a collusion attack, the at-tackers are required to regenerate a single digital signatureof an already registered member that possesses the set of




9

attributes desired. For ECDSA, a signature is generatedby randomly selecting a cryptographically secure randominteger d, such that

(x1, y1) = d×G, (16)

where (x1, y1) are the calculated elliptic curve points, G isthe generator of the elliptic curve with a large prime ordern, and d ∈r [1, n−1]. Next, the digital signature is calculatedas two components σ = (r, s). That is

r = x1 (mod n), (17)

s = d−1(z + r · pr) (mod n), (18)

where z is the Ln leftmost bits of msg such that Ln is thebit length of the group order n. If any of the values r or sare equal to zero, d is randomly selected again and equa-tions (16), (17), and (18) are recalculated. Since the signaturecomponents (r, s) are both derived based on the randomvalue d, it is infeasible for the attackers to regenerate aspecific signature that belongs to a certain staff member,hence, the smart contracts are collusion resistant.

Theorem 3. Using a content-addressable storage such as IPFSensures that data is tamper-resistant.

Proof. In IPFS, records are initially partitioned into n smallersegments before being stored. That is

R = {R1 . . .Rn}, (19)

where each Ri ∈ R is 256KB, by default. However, thesize of a partition may also be customized by the patientas desired. Next, each Ri ∈ R is hashed as

hi = Hash(Ri), (20)

where hi is the resulting digest and is used to referencerecords stored in the network nodes through the DHT. ForHash, it is computationally infeasible to find an R′i 6= Ri,such that

Hash(R′i) = Hash(Ri). (21)

Therefore, it is computationally infeasible for an attacker totamper with the records of the patients.

Theorem 4. The proposed scheme can counter Distributed De-nial of Service (DDoS) attempts.

Proof. DDoS attacks over IPFS aim at congesting the net-work by sending numerous requests to the nodes storingthe requested data. However, to perform such attacks, theattackers must initially identify all the nodes storing thetarget data from the DHT. Next, they must disrupt theservice by sending these nodes a large number of requests,such that

Number of requests� MAX TRAN, (22)

where MAX TRAN is the maximum number of transactionsaccepted by a node as defined in its configuration file.

Attackers may also try to isolate and monopolize allinbound and outbound connections and data flows of thestorage nodes (referred to as an Eclipse attack [18]) fromthe entire network. These attacks become infeasible as thenumber of nodes storing the data increases since the recordis replicated across the network nodes. In addition, such

attacks are limited by the time tscheme for a request toappear over the blockchain until the staff member fetchesthe data from the IPFS network nodes. Attackers must beable to perform the entire attack in time tattack. That is

tattack < tscheme. (23)

An attacker with no prior knowledge of which data will berequested by staff members has no advantage of identifyingthe nodes storing the data. Therefore, as the value of tschemebecomes smaller and with an increased record replication,DDoS attacks become infeasible.

6.2 Recommended Security PracticesSecurity may also be enhanced by adopting good develop-ment practices. In the following, we present some highlyrecommended techniques that developers should keep inmind while implementing the system.Global smart contracts access control: It is necessaryto ensure integrity of the data stored in the SMR and GKglobal contracts since they provide the necessary informa-tion required to verify AVPA contracts and grant keys tothe staff members. Therefore, it is imperative to halt theattackers from manipulating the state of these contracts withfraudulent information. Attackers with access rights thatcan modify the SMR contract may easily register themselveswith any set of attributes required to pass the verificationof certain AVPA contracts. It is also feasible to performdistributed denial-of-service (DDoS) attacks by deleting ormodifying the registration of staff members in the SMRcontract or spamming the logs of the GK contract withfraudulent information. This will result in interrupting orslowing down the process of retrieving patient records.Therefore, when developing such contracts, it is importantto limit the ability to modify the state of global contracts toonly certified institutions. This is outlined in lines 7 and 3 ofAlgorithms 1 and 3, respectively. The current smart contractprogramming languages, for example, Solidity [19], pro-vide specific functions to verify certain conditions and/orvariable values before execution is performed. Well knownexamples include the require() or assert() functions thatverify preliminary conditions and consume a portion or allof the gas associated with a transaction. In general, two mainreasons for charging users gas to trigger contracts deployedover the blockchain are to reward the executing networknodes and make potential attacks expensive. This meansthat attackers must pay for each transaction they request forit to be executed by the network nodes. This approach willnot prevent attackers from registering themselves into theSMR with a set of fraudulent attributes but could help haltthose trying to spam the network. Assuming an attackerhas been able to modify the state of a global contract, theattacker will still have to pay for each requested transaction.To increase the security measures in this scenario, contractsmay be designed to require a minimum gas amount in orderto execute them. However, this countermeasure results in atrade-off between security and cost for the honest users.External smart contract calls: Our proposed schemerelies on external smart contract calls that fetch the storedattributes of registered staff members to compare them tothose sent by the requesting staff members before validating




10

if they satisfy a certain access policy. External calls canintroduce several unexpected risks or errors if the smartcontracts mistakenly execute malicious code. Therefore, itis important that patients cautiously implement their AVPAcontracts to handle errors when externally calling the SMRglobal contracts during the initial verification process. InSolidity [19], external calls can be performed in two ways:low-level calls and contract calls. Low-level calls do notthrow exceptions, instead they return false if the externalcall of another smart contract itself encounters an exception.Patients that use low-level calls must check if the returnedvalue within the AVPA contract fails and then properlyhandle it. On the other hand, contract calls are more direct asthey throw exceptions as encountered by the external call.From a security standpoint, it may be more secure to usecontract calls especially when the patient is less experiencedin handling complex scenarios.

Non-Public Blockchains: The security of our proposedscheme could also be enhanced by running the smart con-tracts over a consortium or private blockchain. In such asetting, miners are selected nodes within the peer-to-peernetwork that are known and trusted. If any of these nodesattempt to act maliciously, they are immediately identifiedand eliminated. A good example of such candidate nodescould be the medical institutions themselves that are inter-ested in maintaining the system in return for efficient dataaccess when required.

6.3 Privacy AnalysisWhile our proposed scheme aims at satisfying the privacydesires of patients and their records, it tends to leak knowl-edge about the staff members and their access patterns.Each staff member must initially become registered andis linked to a unique address before engaging with thesystem. Since this information can be leaked, attackers cansimply monitor requests triggered by the staff members byobserving the blockchain activity. However, since no infor-mation is revealed about the records of patients throughthe AVPA smart contracts, attackers can only track whenstaff members trigger requests, but not the data they haverequested or the patient information.

From the perspective of patients, our proposed schemeis intentionally designed to allow them to trace-back theaccesses performed by staff members to their records. Thisis possible by tracing the history of LogAnnounce eventsfired as outlined in line 12 of Algorithm 2. All fired eventsare permanently stored over the blockchain, allowing thepatients to continuously monitor how their records arebeing accessed. If a patient notices irregular staff memberaccesses that are undesired, the patient can simply redeploya new AVPA smart contract that defines new or more strictaccess policies.

Theorem 5. Under the proposed model, the privacy of patientrecords location is preserved.

Proof. First, since the user record is encrypted as describedin equation (4) before it is uploaded to IPFS, the content ofthe user record is protected. Second, for the current IPFSsystem, any user in possession of the data can reproduce itscryptographic-hash, search its corresponding location that is

maintained by the DHT, and locate it within the peer-to-peernetwork nodes determined by the default IPFS partitioningtechniques. This will also result in recursively locating anydata linked to it. To ensure data privacy, we will append arandom value r to the record before uploading it to IPFS.Therefore, the storage location is determined by

h = Hash(R‖r). (24)

The randomness of r makes it infeasible for the attacker tolocate the data stored over IPFS nodes.

7 PERFORMANCE AND APPLICATION ANALYSIS

In this section, we will first evaluate the performance of ourproposed smart contracts. The performance measurementof smart contracts can be performed either through (i)measuring the computational complexity of the algorithms,or (ii) calculating the gas costs required to deploy/transactwith the contract.

Method (i) analyzes the computational complexity basedon the number of inputs. The computational complexitydirectly correlates to the gas costs paid by the data ownersto deploy their smart contracts and by data users to executethem. However, with smart contracts, reducing computa-tional complexity is not of significant importance sinceblockchain transactions are generally executed at discreteintervals. Therefore, reducing the computational complexitymay only reduce the gas costs required rather than the totallatency. On the other hand, method (ii) is usually moreaccurate since it presents an estimate of the actual monetarycosts paid by the users in order to deploy/transact withthe contract. However, this method is directly dependenton the actual source code implementation. Therefore, codeoptimization techniques may probably end up reducingmore gas costs. To measure the performance of our proposedsmart contracts, we will present discussions on each of ourproposed algorithms that combine both methods. Our dis-cussions assume that smart contracts will be implemented inSolidity [19], a contract-oriented, high-level language for im-plementing smart contracts deployable over the Ethereuemblockchain and processed by the EVM.

Following that, we analyze the symmetric encryp-tion overhead and present our discussion for EMRs re-encryption.

7.1 Smart Contracts Computational Complexities

SMR contract: As outlined in Algorithm 1, theaddStaffMember function takes attributes as input to reg-ister a new staff member. Due to the computational limita-tions of the EVM, returning dynamic content from externalfunction calls is not possible, i.e. returning a dynamicallysized array of attributes resulting from the getAttributesfunction when called by the AVPA contract. This means,the size of Map[ address].staffAttributes must be fixed inorder to be executed by the EVM. As a result, the onlyworkaround is to use statically-sized upBound arrays ofattributes as input to the addStaffMember. In this case,performance is based on the size of upBound, such that

Performance ∝ upBound. (25)




11

AVPA contract: As discussed previously in Agorithm 2, theAVPA contract consists of two sequential verifications thatplay a dominant role in the performance of the contract. Inthe initial verification, an input digital signature σ is vali-dated to prove the identity of the requesting staff member.With Solidity, the only available cryptographic function thatcan perform such a process is the ECDSA ecrecover function.The function recovers the Ethereum address associated withthe public key from the elliptic curve signature or returnszero on error. At the time of writing, the ecrecover functionrequires 3000 gas units. In comparison to most of the avail-able possible computations available by the EVM [6], theecrecover function is considered to be relatively expensive.However, this initial verification is fixed with each AVPAcontract transaction.

Assuming the initial verification is successful, the AVPAexternally fetches the attributes of the staff member to testthem against the incorporated access structure. Similar tothe SMR contract, the performance of the AVPA contract isdependent on the upBound of the fetched attributes. Finally,the fetched attributes are tested against the access policiesstarting at the highest level within the hierarchy. Here, per-formance is affected by the complexity of the overall accessstructure defined and the number of levels k within thehierarchy. Assuming the worst case scenario, a requestingstaff member might have his/her attributes tested againstall access policies within the access structure and onlyreceive the least sensitive part Rk of the record or nothingat all. The computational complexity can be representedas O(k × upBound × |Ti|), where |Ti| is the number ofattributes that form the access policy at level Li. To reducethis complexity, we can modify the AVPA contract such thatthe staff members can request that their attributes be testedagainst only specific access policies rather than being testedsequentially against all policies. This would reduce thecomputational complexity toO(upBound×|Ti|). We can alsoincorporate optimized search functions, for example, binarysearch, that can help optimize searching for attributes in thefetched set against those in the access policies. This meansthat we can further reduce the computational complexity toO(upBound× log |Ti|). However, it is important to note thatin such a scenario, the patients need to make their accessstructures publicly available in order for the staff membersto request certain access policies. This results in a trade-off between the performance of the AVPA contract and theprivacy of the access policy defined.

GK contract: The GK contract requires the least computa-tional complexity and gas costs when compared to the SMRand AVPA smart contracts. The computations involved areas simple as firing a LogKeys event when access permissionsare granted to staff members. The gas costs of such opera-tions are minimal in comparison to the other computationsin the SMR and AVPA smart contracts.

7.2 Smart Contracts Gas Costs

In this section, we implement, simulate and present theestimated costs required to deploy/transact with the smartcontracts of our proposed scheme in multiple scenarios.Our experiments are performed over the Ethereum test-net blockchain [20]. We specifically choose the Ethereum

blockchain given that it is by far the most widely usedsmart contract hosting public blockchain. We intend to showthat costs of running d-MABE over a public blockchain arereasonable and that our results may even be improved whenchoosing a consortium or private blockchain. We also notethat our proposed scheme can be implemented over anyother blockchain that incorporates smart contracts.

In our simulation, the AVPA smart contract with thehighest degree of complexity is implemented. When exe-cuted, the AVPA smart contracts sequentially check whetherthe attributes of the requesting users satisfy the accesspolicies in order starting from the highest level of thehierarchy. As discussed in Section 7, there is a trade-offbetween privacy and performance. Therefore, we note thatour presented results can be further enhanced in termsof performance as discussed previously. However, we in-tentionally choose to implement our smart contracts thisway to show that even with these conditions, our pro-posed contracts are still cheaper when compared to thecurrent systems used by the record-generating institutionsto share medical records. In contrast to the current record-sharing systems, our proposed scheme eliminates the roleof the record-generating institution completely. This resultsin eliminating other overhead costs required when sharingmedical records. For example, in developed countries suchas the U.S., record-generating institutions must comply withcertain state laws that enforce a maximum fee a record-generating institution may charge when requested to shareits records. Table 3 illustrates a sample of these fees thatcould be inclusive or exclusive to the methods of deliver-ing the record itself. Given the current competitiveness, inmost cases, the medical institutions would charge the entireallowed fees to maximize their profits.

For our simulations, we apply the values k = {5, 10},upBound = {10, 20, 30, 40, 50} and N = {25, 50, 100},where k is the number of levels in the hierarchy and Nis the total number of attributes used in the entire accessstructure. Without loss of generality, we also assume thatthe number of attributes for each level follows the uniformdistribution. For example, if k = 5 and N = 50, thenthe number of attributes used to define an access policy is|Ti| = 10. The following experiments have been conductedthrough an Ethereum node running on a system with 1.8GHz Intel Core i5 and 8 GB RAM. Our numerical results arealso the averages of 10 trials under each scenario.

Based on our experiments, the costs of deploying oursmart contracts are not affected by the value of upBoundsince there is no major change in code as this value changes.Therefore, for all values of upBound that we tested, thecosts remained constant. Table 2 summarizes these costsin terms of gas limits and their estimated and equivalentcosts in ETH and United States Dollar (USD) at the timeof testing. To measure the optimum gas limit for eachsmart contract deployment, we used the JSON-RPC method,eth estimateGas [21], that generates and returns an estimateof the required gas limit based on the network success rate.We also set the gas price to 20 GWEI, where 1 ETH = 1×109

GWEI. We intentionally select this value relatively higherthan the average gas prices specified in [22] for guaranteedand fast processing. Again, we note that our presentedresults can be further optimized by selecting reduced gas




12

TABLE 2: Estimated smart contract deployment costsSmart k = 5, N = 25 k = 5, N = 50 k = 10, N = 100

Contract Gas Limit Cost/ETH Cost/USD Data/bytes Gas Limit Cost/ETH Cost/USD Data/bytes Gas Limit Cost/ETH Cost/USD Data/bytesSMR 240383 0.004809 1.4 736 240447 0.004809 1.42 736 240447 0.004809 1.42 736AVPA 857419 0.017148 5.21 3323 1132628 0.022653 6.67 4536 1303607 0.026072 7.56 5188GK 125617 0.002512 0.74 304 125617 0.002512 0.74 304 125617 0.002512 0.74 304

TABLE 3: U.S maximum state fees [23] to copy and deliverrecords upon being requested by others.State Search fee Cost per page Misc. costs per pageCalifornia N/A $0.25 Microfilm: $0.50

Texas $82.95

P.1-10: $45.79 flat feeP.11-60: $1.54P.61-400: $0.76P.401+: $0.41

Microfilm:P.1-10: $69.74 flat feeP.11+: $1.54

Florida $1.00/year $1.00 Microfilm: $2.00

New York N/A $0.75 X-rays: Actual cost of re-production

Illinois $27.91P.1-25: $1.05P.26-50: $0.70P.50+: $0.35

Microfilm: $1.74

TABLE 4: Estimated addStaffMember function costsupBound

10 20 30 40 50Gas Limit 246531 449890 653249 856674 1060034Cost/ETH 0.004931 0.008998 0.013065 0.017133 0.021201Cost/USD 1.45 2.65 3.85 5.06 6.29

TABLE 5: Estimated addKey function costsupBound

10 20 30 40 50Gas Limit 26379 26380 26375 26379 26378Cost/ETH 0.000528 0.000528 0.00053 0.000524 0.000528Cost/USD 0.14 0.14 0.14 0.15 0.15

price values. As demonstrated in Table 2, the estimatedcosts for deploying the SMR and GK smart contracts remainconstant as we alter the values of k and N . However, thecosts for deploying the AVPA smart contracts increase withan increase in the values k and/or N .

Figure 2 demonstrates the changes in USD costs of trans-acting with already deployed AVPA contracts as we alter thevalues k and N for permissioned staff members at levelsL1, L5 and L10. As shown by the figure, we recognize anincrease in costs as these values increase. We also realize thatas the upBound value increases while keeping the values k,N , and Li constant, the costs slightly increase.

Finally, in Tables 4 and 5, we present the gas limitsand costs in both ETH and USD to transact with theaddStaffMember and addKey functions. As shown in Table 4,the costs of the transactions increase as the value upBoundincreases. On the contrary, as presented in Table 5, the costsof transacting with the addKey function remains constantregardless of the upBound value used.

7.3 Symmetric Encryption OverheadOur proposed work does not require patients to reconstructtheir privilege-based access trees and regenerate a newset of keys. In order to revoke access from certain datausers, patients need only to symmetrically re-encrypt theirEMRs under the same set of keys {sk1, . . . , skk} along witha new SBK. The overhead for re-encrypting EMRs canbe very low when utilizing a high encryption/decryption

Fig. 2: Estimated costs to run the AVPA smart contract

implementation such as Advanced Encryption Standard(AES), Counter Mode (CTR) operations, and Cipher-Block-Chaining (CBC). According to the Crypto++ 5.6.0 Bench-marks1, the performance for AES/CTR on an Intel Core2 1.83 GHz processor measures under Windows Vista are139MiB/Second, 113MiB/Second, and 96MiB/Second for128-bit, 192-bit, and 256-bit key sizes respectively. Similarly,the performance measures for AES/CBC are 109MiB/Sec-ond, 92MiB/Second, and 80MiB/Second for 128-bit, 192-bit,and 256-bit key sizes respectively. These commonly usedcryptographic algorithms are widely accepted and incurminimal costs making our model feasible.

7.4 Extended Application DiscussionsAggregated patient data has the capability of transform-ing the future standard of care for patients through theapplication of predictive analytics and big data methods.One of the biggest challenges to using health data to itsfullest extent is the inaccessibility and segmentation ofEMRs [24]. As demonstrated by our analyses, the proposedscheme can eliminate these constraints. It grants healthcareproviders the ability to efficiently extract knowledge fromdisconnected EMRs that have been willingly shared. Forexample, a meaningful opportunity for big data analyticsin this context is the capability to model drug and treatmentefficacy. Healthcare providers can access previously sharedEMRs to understand how life-saving drugs and treatmentsperform, respective to the disease state and profile of thepatient. This data can be used to make enhanced andcustomized treatment decisions for patients. As healthcaretreatment becomes more individualized, successful patientoutcomes are more likely and a one-size-fits-all approach topatient treatment is no longer adequate.

8 CONCLUSION

In this paper, we proposed d-MABE, a secure, privacy-preserving and distributed data sharing scheme that runs

1. https://www.cryptopp.com/benchmarks.html




13

over a blockchain using smart contracts. We demonstratedthat d-MABE can be used in cases such as medical record-sharing where patients require an efficient and selectivemethod to share their records with staff members of medicalinstitutions. Our d-MABE proposed scheme eliminates thereliance on the record-generating institutions when data isshared and completely empowers the patients. Our securityand privacy analyses show that d-MABE is secure andpreserves the privacy of patient records. We also presentedsome recommended security practices developers shouldkeep in mind when developing their system. Finally, ourcomprehensive evaluation proves the efficiency of d-MABEand presents numerical results that support our perfor-mance analysis.

9 ACKNOWLEDGEMENT

The authors would like to thank the Associate Editor andthe anonymous reviewers for their valuable comments.

REFERENCES

[1] U.S. Dept of Health and Human Services, “Heath insurance porta-bility and accountability act.” https://www.hhs.gov/hipaa, 2018.

[2] N. England, “Nhs england and nhs improvement.” https://www.england.nhs.uk, 2019.

[3] N. Digital, “Summary care records (scr)- information for patients.” https://digital.nhs.uk/services/summary-care-records-scr/summary-care-records-scr-information-for-patients, 2019.

[4] S. Nakamoto, “Bitcoin: A p2p electronic cash system.” https://bitcoin.org/bitcoin.pdf, 2008.

[5] N. Szabo, “Smart contracts: building blocks for digital markets,”EXTROPY: The Journal of Transhumanist Thought,(16), 1996.

[6] G. Wood, “Ethereum: A secure decentralised generalised transac-tion ledger,” Ethereum project yellow paper, vol. 151, pp. 1–32, 2014.

[7] E. Zaghloul, T. Li, and J. Ren, “An attribute-based distributed datasharing scheme,” in 2018 IEEE Global Communications, IEEE, 2018.

[8] G. Zyskind, O. Nathan, et al., “Decentralizing privacy: Usingblockchain to protect personal data,” in Security and Privacy Work-shops (SPW), 2015 IEEE, pp. 180–184, IEEE, 2015.

[9] A. Azaria, A. Ekblaw, T. Vieira, and A. Lippman, “Medrec: Usingblockchain for medical data access and permission management,”in Open and Big Data (OBD), pp. 25–30, IEEE, 2016.

[10] A. Dubovitskaya, Z. Xu, S. Ryu, M. Schumacher, and F. Wang,“Secure and trustable electronic medical records sharing usingblockchain,” in AMIA Annual Symposium Proceedings, vol. 2017,p. 650, American Medical Informatics Association, 2017.

[11] H. T. Vo, A. Kundu, and M. K. Mohania, “Research directionsin blockchain data management and analytics.,” in ExtendingDatabase Technology EDBT, pp. 445–448, 2018.

[12] J. Bethencourt, A. Sahai, and B. Waters, “Ciphertext-policyattribute-based encryption,” in 2007 IEEE symposium on securityand privacy (SP’07), pp. 321–334, IEEE, 2007.

[13] E. Zaghloul, K. Zhou, and J. Ren, “P-MOD: Secure privilege-basedmultilevel organizational data-sharing in cloud computing,” IEEETransactions on Big Data, accepted, to appear.

[14] V. Buterin, “Ethereum: A next-generation smart contract anddecentralized application platform, 2013.” http://ethereum.org/ethereum.html, 2017.

[15] J. Benet, “IPFS - content addressed, versioned, P2P file sys-tem (draft 3).” https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf.

[16] “Bittorrent.” http://www.bittorrent.com, 2018.[17] M. Pirretti, P. Traynor, P. McDaniel, and B. Waters, “Secure

attribute-based systems,” J. of Comp. Security, vol. 18, no. 5,pp. 799–837, 2010.

[18] A. Singh, T. wan Ngan, P. Druschel, and D. S. Wallach, “Eclipseattacks on overlay networks: Threats and defenses,” in In IEEEINFOCOM, Citeseer, 2006.

[19] “Solidity.” http://solidity.readthedocs.io/en/v0.4.24/, 2018.[20] “Ropsten (revival) testnet.” https://ropsten.etherscan.io, 2018.[21] “Json RPC.” https://github.com/ethereum/wiki/wiki/

JSON-RPC#eth estimategas, 2018.

[22] “Ethereum average gas price chart.” etherscan.io/chart/gasprice,2018.

[23] MediCopy, “State-by-state guide of medical record copying fees.”https://medicopy.net, 2018.

[24] S. E. White, “A review of big data in health care: challenges andopportunities,” Open Access Bioinformatics, vol. 6, pp. 13–18, 2014.

PLACEPHOTOHERE

Ehab Zaghloul received his B.S. and M.Scdegrees in Computer Engineering from ArabAcademy for Science and Technology (AAST),Alexandria, Egypt in 2012 and 2015 respectively.He earned his Ph.D. degree in Electrical andComputer Engineering at Michigan State Uni-versity (MSU), East Lansing, USA. His researchinterests include applied cryptography, secureand private cloud data sharing, cryptocurren-cies, and blockchain.

PLACEPHOTOHERE

Tongtong Li (SM’09) received her Ph.D. degreein Electrical Engineering in 2000 from AuburnUniversity. From 2000 to 2002, she was with BellLabs, and had been working on the design andimplementation of 3G and 4G systems. Since2002, she has been with Michigan State Univer-sity, where she is now an Associate Professor.Prof. Li’s research interests fall into the areasof wireless and wired communications, wirelesssecurity, information theory and statistical signalprocessing, with applications in neuroscience.

She is a recipient of a National Science Foundation (NSF) CAREERAward (2008) for her research on efficient and reliable wireless com-munications. Prof. Li served as an Associate Editor for IEEE SignalProcessing Letters from 2007-2009, and an Editorial Board Memberfor EURASIP Journal Wireless Communications and Networking from2004-2011. She served as an Associate Editor for IEEE Transactionson Signal Processing from 2012-2016.

PLACEPHOTOHERE

Matt W. Mutka received the B.S. degree inelectrical engineering from the University ofMissouri-Rolla, the M.S. degree in electrical en-gineering from Stanford University, and the Ph.D.degree in Computer Sciences from the Univer-sity of Wisconsin-Madison. He is a Professoron the faculty of the Department of ComputerScience and Engineering at Michigan State Uni-versity (MSU) and is currently serving as a Pro-gram Director at the National Science Founda-tion (NSF) within the Division of Computer and

Networks Systems (CNS) of the Directorate for Computer and Infor-mation Science and Engineering (CISE). He served as Chairpersonof the MSU Department of Computer Science and Engineering from2007-2017. He has been a visiting scholar at the University of Helsinki,Helsinki, Finland, and a member of technical staff at Bell Laboratoriesin Denver, Colorado. He is an IEEE Fellow and was honored withthe MSU Distinguished Faculty Award. His current research interestsinclude mobile computing, sensor networking and wireless networking.

PLACEPHOTOHERE

Jian Ren (SM’09) received the BS and MS de-grees both in mathematics from Shaanxi NormalUniversity, and the Ph.D. degree in EE from Xi-dian University, China. He is an Associate Pro-fessor in the Department of ECE at MichiganState University. His current research interestsinclude network security, cloud computing se-curity, privacy-preserving communications, dis-tributed network storage, and Internet of Things.He is a recipient of the US National ScienceFoundation Faculty Early Career Development

(CAREER) award in 2009. Dr. Ren served as the TPC Chair of IEEEICNC’17, General Chair of ICNC’18 and Executive Chair of ICNC’19and ICNC’20. Currently Dr. Ren serves as an Associate Editor forIEEE Transactions on Mobile Computing (TMC), IEEE Internet of ThingsJournal (IoT), ACM Transactions on Sensor Networks (TOSN) and aSenior Associate Editor for IET Communications. Dr. Ren is a seniormember of the IEEE.


1 d-MABE: Distributed Multilevel Attribute-Based EMR ...renjian/pubs/TSC-d-MABE.pdf · 1 d-MABE:...

Documents

Transcript of 1 d-MABE: Distributed Multilevel Attribute-Based EMR ...renjian/pubs/TSC-d-MABE.pdf · 1 d-MABE:...