Conference PaperPDF Available

Abstract and Figures

Availability of medical records during an emergency situation is of paramount importance since it allows healthcare professionals to access patient's data on time and properly plan the next steps that need to be taken. Cloud storage has the potential to provide a solution to the problem of data unavailability during an emergency situation. However, sharing medical records raises several concerns about security and privacy. In this paper, we study the problem of how to share encrypted patients' data during an emergency situation. To this end, we propose a protocol through which a team of healthcare professionals can securely decrypt the medical records of a patient who is under an emergency situation (e.g. acute stroke). Furthermore, our protocol ensures that a team of healthcare professionals will only have access to the patient's data for the time needed to complete a specific process related to the patient's situation (e.g. transfer patient to the hospital). In our study, the dynamically granting and revoking data access during an emergency treatment is the main novelty.
Content may be subject to copyright.
Red Alert: Break-Glass Protocol to Access
Encrypted Medical Records in the Cloud
Marcela Tuler de Oliveira
dept. KEBB/BMEP, Amsterdam UMC
University of Amsterdam
Amsterdam, Netherlands
m.tuler@amc.uva.nl
Antonis Michalas
Computing Sciences
Tampere University
Tampere, Finland
antonios.michalas@tuni.fi
Adrien E. D. Groot
Neurology, Amsterdam UMC
University of Amsterdam
Amsterdam, Netherlands
a.e.groot@amc.uva.nl
Henk A. Marquering
dept. BMEP, Amsterdam UMC
University of Amsterdam
Amsterdam, Netherlands
h.a.marquering@amc.uva.nl
Silvia Delgado Olabarriaga
dept. KEBB, Amsterdam UMC
University of Amsterdam
Amsterdam, Netherlands
s.d.olabarriaga@amc.uva.nl
Abstract—Availability of medical records during an emergency
situation is of paramount importance since it allows healthcare
professionals to access patient’s data on time and properly plan
the next steps that need to be taken. Cloud storage has the
potential to provide a solution to the problem of data unavail-
ability during an emergency situation. However, sharing medical
records raises several concerns about security and privacy. In this
paper, we study the problem of how to share encrypted patients’
data during an emergency situation. To this end, we propose
a protocol through which a team of healthcare professionals
can securely decrypt the medical records of a patient who is
under an emergency situation (e.g. acute stroke). Furthermore,
our protocol ensures that a team of healthcare professionals will
only have access to the patient’s data for the time needed to
complete a specific process related to the patient’s situation (e.g.
transfer patient to the hospital).
Index Terms—Attribute-Based Encryption; e-Health Privacy;
Electronic Medical Records; Emergency care, Secure Cloud
Storage.
I. INTRODUCTION
The use of Electronic Medical Records (EMR) improves the
overall quality of care that a patient receives since their use can
lead to a substantial reduction of unnecessary investigations
and improvement of communication between the healthcare
professionals that are involved in the treatment [1]. Therefore,
the availability of EMR, especially when a patient is under an
emergency situation, is of paramount importance. For example,
in stroke treatment, the phrase ‘Time is brain’ conveys the
idea that minutes can make the difference between life and
death [2]. Hence, guaranteeing that the patient’s EMR will
be available to healthcare professionals involved in an acute
This work was funded by the ASCLEPIOS: Advanced Secure Cloud
Encrypted Platform for Internationally Orchestrated Solutions in Healthcare
Project No. 826093 EU research project.
©2019 IEEE. Personal use of this material is permitted. Permission from
IEEE must be obtained for all other uses, in any current or future media,
including reprinting/republishing this material for advertising or promotional
purposes, creating new collective works, for resale or redistribution to servers
or lists, or reuse of any copyrighted component of this work in other works.
stroke treatment can save time and improve the efficiency of
decision-making processes, leading to quality of care.
EMR management on cloud infrastructure increases the
availability of data. However, this poses new challenges for
security and privacy [3]. Initially, researchers proposed to send
sensitive data to the cloud service provider, where it would
be encrypted and stored. In this case, the key used for data
encryption is known by the cloud provider, which does not
protect the EMR against internal attacks [4]. To overcome
this, other studies rely on encrypting the EMR with a secret
key before storing it in the cloud. In most scenarios, the
secret key needs to be pre-shared with all users that wish or
need to access the EMR [5], [6]. However, this makes access
control inefficient. Especially because, when a user needs to
be revoked, the EMR must be re-encrypted with a fresh key
and the new key must be distributed to the other legitimate
users.
In the case of acute stroke treatment, having access to
patient data is vital. Therefore, it is necessary to provide access
to encrypted data - even if the patient cannot consent explicitly.
The so-called ’break-glass’ access mechanism provides emer-
gency access to the patient’s EMR in such situations. Although
some studies approach the break-glass access to encrypted
EMR [7]–[9], the revocation after the emergency is still a
problem. For security and privacy sake, immediately after the
emergency situation ends, the access needs to be revoked. In
addition, revoking a user must not affect the rest of the users.
Our Contribution: In this paper, we describe a proto-
col to provide access to a patient’s encrypted EMR during
acute stroke treatment with an additional security mechanism
that ensures authorisation only for the period which the
access is necessary. The protocol securely enables sharing
of medical records among multi-treatment teams through a
cloud platform. The proposed solution adopts the concept of
Attribute-Based Encryption (ABE) associated with policies
defined explicitly for the emergency situation. Additionally,
it adopts tokenized authentication to dynamically grant and
revoke access during the timeline of acute stroke treatment.
Organization: Section II discusses related works, and
Section III summarizes the flow of patient information dur-
ing stroke emergency. Section IV defines the cryptographic
primitives used throughout the paper. In Section V we present
the main entities that participate in our system model and in
Section VI we define both the problem statement and the con-
sidered threat model. In Section VII we describe our protocol
and in Section VIII we analyze its security against malicious
behaviour. Section IX presents preliminary conclusions.
II. RE LATE D WOR K
Many studies have addressed access control to medical
records. Here, however, we focus on emergency situations
where the break-glass condition is valid. Very few research
works have considered this requirement.
One of the earliest arguments for a break-glass concept was
formulated by Povey [10]. It states that the basic approach of
an optimistic security system is to assume that any emergency
situation requesting data access is legitimate and should be
granted. Petrisch and Bruker presented in [11] a generic break-
glass model where the data subjects are permitted to override
specific access control permissions. In [12] Zhang et al. pro-
posed a concrete break-glass method based on two-factor
encryption: password-based encryption and master secret key
based encryption. In [13] the authors presented ’Rampole’, a
model that implements access permissions in a fine-grained
manner using a declarative query language to specify a break-
glass decision procedure. All the approaches described above
do not support attribute-based access control.
In [7] the authors leveraged ABE techniques to control
access to patient data. This study approaches break-glass
access under emergency scenarios using a unique authority
which authenticates the medical staff to access the data. To
revoke access, the data needs to be re-encrypted with a new
key. Brucker et al. [8] presented an integration of fine-grained
break-glass concepts into a system based on ABE. The authors
present multi-levelled break-glass access control; however, the
solution does not enable revoking access after it has been
granted. Yang et al. [9] proposed an ABE access control in
which the patient pre-shares her password with the emergency
contact person. When the patient is in an emergency situation,
the contact person utilizes the password to derive the break-
glass key and to decrypt the patient’s medical files.
Even though [7]–[9] present interesting solutions for the
break-glass situation, they do not provide a concrete and effi-
cient solution for access revocation. Our approach overcomes
the revocation problem by using a Ciphertext-Policy ABE (CP-
ABE) scheme and an access control token scheme to grant and
revoke access dynamically without re-encrypting the patient
EMR. In addition, our protocol supports the involvement of
multi-treatment teams, even from different institutions, which
brings the solution closer to a real emergency scenario.
III. PATIE NT DATA SH AR IN G DU RI NG S TRO KE E ME RG EN CY
Emergency care for acute stroke treatment involves pro-
fessionals at the emergency call centre, ambulance service
and primary and comprehensive stroke hospitals, all of which
need to share information on a break-glass access mechanism.
Below we describe a typical scenario, providing high-level
information of involved parties and the basic information
exchange that takes place between them.
When a patient suffers from a stroke, the patient or someone
who is present with the patient is the first to contact the emer-
gency call centre by phone. The call centre team is composed
of trained healthcare workers who are able to determine if
there is an emergency situation, and how to address it best.
During the phone call, the call centre professional follows a
triage process, collecting information about the time of the
stroke onset, personal data (e.g. age, gender etc.) and some
impressions about the patient conditions.
When there is a suspicion of stroke, the call centre profes-
sional contacts the ambulance service and shares the collected
information about the patient. An ambulance that is closer to
the event location is sent from the closest regional centre and,
as soon as the ambulance arrives, the ambulance team contin-
ues triage process. They perform examinations, measurements
and medical procedures at the patient’s location and during
the travel to the hospital. When the ambulance arrives at the
hospital, all the information about patient’s condition is orally
shared with the hospital team.
During the travel, the ambulance professional communicates
by phone with the proposed destination hospital. Therefore, the
hospital prepares the emergency room and prepares the team
with the relevant experts to receive the patient (e.g. neurolo-
gist, interventional neuroradiologist, anesthesiologist, nurses).
If the patient has already a record in this hospital local system,
the hospital team can access the patient’s medical record. If
there is no information about the patient, the hospital team may
attempt to contact other hospitals to retrieve the patient’s med-
ical record. Furthermore, the hospital team collects additional
data about the patient, which is stored at the patient’s EMR
at the treating hospital. In the case of a patient with a large
vessel occlusion eligible for additional endovascular treatment,
the patient needs to be transported by a second ambulance to
the comprehensive stroke hospital. Therefore, it is necessary
that the teams in the second ambulance and second hospital
also access and update the patient’s medical record.
Note that in this case three or more teams are involved in
the treatment, requiring access to the patient’s EMR and gen-
erating new content for it. Therefore, to improve accessibility
to medical records and protect patient’s privacy, it is necessary
to dynamically grant and revoke access to the EMR.
IV. CRYP TO GR AP HI C PRIMITIVES
We first define the basic cryptographic primitives that are
used throughout the paper and then we continue with the
definition of a CP-ABE scheme as described in [14].
The set of all binary strings of length nis denoted by
{0,1}n, and the set of all finite binary strings as {0,1}.
Given a set V, we refer to the ith element as vi. Additionally,
we use the following notations for cryptographic operations
throughout the paper:
For an arbitrary message m∈ {0,1},c=Enc (K, m)
denotes a symmetric encryption of musing the secret key
K∈ {0,1}, and m=Dec (K, c) = Dec (K,Enc (K, m))
is the corresponding symmetric decryption operation.
We denote by pk/sk a public/private key pair for an
IND-CCA2 secure public key encryption scheme PKE.
An encryption of message munder the public key pk is
denoted by c=Encpk (m)and the corresponding decryp-
tion operation by m=Decsk(c) = Decsk (Encpk(m)).
σ=Signsk(m)denotes a digital signature over a message
m. The corresponding verification operation for a digital
signature is denoted by b=Verifypk(m, σ), where b= 1
if the signature is valid, and b= 0 otherwise.
A one-way hash function (H) over a message mis
denoted by Hm=H(m).
We denote by τ=RAND(n)a random binary sequence
of length n, where RAND(n)represents a random func-
tion that takes a binary length argument nas input and
gives a random binary sequence of this length in return1.
A CP-ABE scheme is a tuple of the following four algo-
rithms:
1. CPABE.Setup is a probabilistic algorithm that takes as
input a security parameter λand outputs a master public
key MPK and a master secret key MSK. We denote this
by (MPK,MSK)Setup(1λ).
2. CPABE.Gen is a probabilistic algorithm that takes as in-
put a master secret key, a set of attributes A ∈ and the
unique identifier of a user, and it outputs a secret key that
is bound both to the corresponding list of attributes and
the user. We denote this by (skA,i)Gen(MSK,A, ui).
3. CPABE.Enc is a probabilistic algorithm that takes as
input a master public key, a message mand a policy
P∈ P. After a proper run, the algorithm outputs a
ciphertext cPwhich is associated to the policy P. We
denote this by cPEnc(MPK, m, P ).
4. CPABE.Dec is a deterministic algorithm that takes as
input a user’s secret key and a ciphertext and outputs
the original message miff the set of attributes Athat
are associated with the underlying secret key satisfies
the policy Pthat is associated with cP. We denote this
by Dec(skA,i, cP)m.
V. SY ST EM MO DE L
The system model presented here is based on the model
introduced in [15]. Below we present an overview of the main
entities and the most relevant communication between them.
1We assume that a true random function is replaced by a pseudo-random
function, the input-output behaviour of which being “computationally indis-
tinguishable” from that of a true random function.
Cloud Service Provider (CSP): The cloud computing
environment is based on a trusted Infrastructure-as-a-Service
(IaaS) provider. The IaaS platform consists of cloud hosts
that operate virtual machine (VM) guests and communicate
through a network. In our model, we require that the IaaS
runs a protocol similar to the one described in [16], where
the integrity of the underlying CSP is verified. In principle,
such integrity verification can be added to any IaaS. A CSP
stores patients’ EMR encrypted under a CP-ABE scheme.
Additionally, the CSP is responsible for controlling the access
to the encrypted EMR.
Registration Authority (RA): responsible for the registra-
tion of all healthcare entities and users. The RA is responsible
for generating user attributes that will be used for the proper
authorization (e.g. membership to a particular treatment team).
The RA can run as a separate third party, but can be also
implemented as part of the CSP.
Master Authority (MA): has a master secret key MSK and
a public key MPK. The master key is kept private, while the
public key is known to everyone. Additionally, the MA uses
MSK to generate CP-ABE secret keys for users, based on user
attributes to authorize recovery of encrypted EMR. The MA is
also responsible for granting and revoking the access tokens.
User: We consider three different types of users: patients,
healthcare professionals and healthcare entities. The set of all
patients registered at RA is denoted by U={u1, . . . , uNu}
and the set of all registered healthcare professionals is denoted
as S={s1, . . . , sNs}. A healthcare entity is a special type
of user represented by an attested smart device. This device
serves to confirm the following treatment team locations:
Emergency Call Centre (e), Ambulance (a) and Hospital (h).
A treatment team is a group of professionals co-located at
one of the entities that attest each other’s involvement in the
emergency situation.
Each user from U,Sand the healthcare entities has a unique
public/private key pair (pk/sk) used to communicate securely
through an IND-CCA2 secure public key encryption scheme
PKE and an EUF-CMA secure signature scheme sign.
VI. PRO BL EM STATE ME NT A ND TH RE AT MODE L
A. Problem Statement
Let uibe a patient from the set Uand sj∈ S be a member
of one of the stroke treatment teams. Let’s assume that uihas
a set of Ndifferent files stored in the CSP. We denote this set
of files as Di={di
1, ..., di
N}. The problem is to find a way
to achieve the following:
1. Enable access to the content of each di
lDito sj
involved in the treatment of ui;
2. User sjhas access to Diif and only if she has a
legitimate role in the treatment team of uiat the time,
as given by a valid policy;
3. Access control to Dishould be granted and revoked
dynamically as requested for the patient’s treatment.
This should not require to decrypt and re-encrypt the
file with a fresh key, and it should not affect the access
by the rest of the legitimate users.
B. Threat Model
We follow the threat model of [15], [17], which is based
on the Dolev-Yao adversarial model [18] and further assumes
that privileged access rights can be used by a remote adversary
ADV to leak confidential information. ADV ,e.g. a corrupted
user, can obtain remote access to any host maintained by the
IaaS provider, but cannot access the volatile memory of a guest
VMs residing on this host. We explicitly exclude denial-of-
service attacks [19] and focus on ADV that aim to compromise
the confidentiality of data in IaaS.
Hardware Integrity: We assume that the CSP has taken
necessary technical and non-technical measures to prevent
hardware tampering.
Physical Security: We assume physical security of the
data centres where the IaaS is deployed. This assumption
holds both when the IaaS provider owns and manages the
data centre (as in the case of Amazon Web Services, Google
Compute Engine, Microsoft Azure, etc.) and when the provider
utilizes third-party capacity, since physical security can be
observed, enforced and verified through known best practices
by audit organizations. This assumption is important to build
higher-level hardware and software security guarantees for the
components of the IaaS.
Low-Level Software Stack: We assume that at installation
time the IaaS provider reliably records integrity measurements
of the low-level software stack: the Core Root of Trust for
measurement; BIOS and host extensions; host platform con-
figuration; Option ROM code, configuration and data; Initial
Platform Loader code and configuration; state transitions and
wake events, and a minimal hypervisor. We assume the record
is kept on protected storage with read-only access and the
adversary cannot tamper with it.
Network Infrastructure: The IaaS provider has physical
and administrative control of the network. An ADV that is in
full control of the network configuration can overhear, create,
replay and destroy all messages communicated between any
entities participating in our protocol.
Cryptographic Security: We assume encryption schemes
are semantically secure and the ADV cannot obtain the
plain text of encrypted messages. We also assume the sig-
nature scheme is unforgeable, i.e., the ADV cannot forge
the signature of a user and the MAC algorithm correctly
verifies message integrity and authenticity. We assume that
the ADV, with a high probability, cannot predict the output
of a pseudorandom function.
VII. RED AL ERT PROTOC OL
We propose a protocol for the problem presented in Sec-
tion VI. More precisely, our approach follows the protocols
proposed in [15] and [17], with additions to meet the specific
needs of the acute stroke care case described in Section III.
The ‘Red Alert Protocol’ (RAP) describes steps to grant and
revoke access to a patient’s EMR during an emergency session
to the involved treatment teams. Figure 1 shows an overview
of the protocol.
CSP
token, val
token, val
revoked
tokens list
Users
Revoke token
Encrypt new file
(I)
(VI)
Emergency key
Access token
Ciphertext
MA
RA
Attribute s
id, etc
id, etc
emergency
sessions list
Decrypt ciphertext
(III)
(II)
Emergency event
(V)
(VI)
Tea m x
Challenge
Challenge solved
Fig. 1. Overview of the Red Alert Protocol: entities and their communication
during a emergency session.
At step (I), the patient has her EMR encrypted using
CPABE and an emergency policy, and the resulting ciphertext
is stored in the CSP. At step (II) the call centre professional se
uses the patient’s unique identifier uito request MA to start
the emergency session that will involve the ambulance and
hospital treatment teams. The MA subsequently establishes
an emergency session associated with this patient, which ends
after complete treatment and patient discharge. During the
emergency session, at step (III) each involved treatment team
needs to prove to the MA that their service is requested. This is
done through a challenge in which the healthcare entity and at
least two members from the same treatment team participate.
After the challenge is solved and users’ attributes are validated,
the MA generates an emergency ABE key. However, direct
sharing the emergency key is not secure enough, because
getting access to that key would allow anyone to access ui’s
ciphertexts at any future moment. Therefore, the MA also
generates an access control token to the team. This token has
a default expiration time and also contains the identity of the
professionals from the treatment team. The MA subsequently
sends the key and token to sj. Upon reception, one of the
professionals in the team sends the access token to the CSP at
step (IV). If the token is valid, CSP grants access to retrieve the
ciphertext containing the EMR of the patient under emergency
treatment. Through a secure read-only application, the EMR is
decrypted using the CPABE emergency key. Token validation
also takes place when sjadds new data to the patient’s EMR
by uploading a new ciphertext to the CSP at step (V). As soon
as the patient is no longer with a treatment team, at step (VI)
MA sends a revocation message for the access token to the
CSP. Thus, even if a token is still valid according to the default
expiration time, the CSP will not allow any type of access to
the data after the revocation time. The MA ends this patient’s
emergency session when there is no valid token associated
with it.
The RAP Protocol defines the exchange of messages
to grant and revoke access, as well as to rightfully en-
crypt and decrypt the patient data. The protocol con-
sists of initialization (RAP.Setup) and six steps described
below: RAP.StoreData,RAP.BreakGlass,RAP.JoinTeam
RAP.RetrieveData,RAP.AddData and RAP.RevokeAccess.
Additionally, two steps are internal to the MA: RAP.GenKey
and RAP.GenToken. An overview of all messages is presented
in Table I. We assume that during the protocol, each party
verifies the integrity and freshness of the message.
RAP.Setup :Each model entity (MA, CSP, and users)
obtains a public/secret key pair (pk,sk) and publishes its public
key while keeping the private key secret. The following keys
are generated: (pkCSP,skCSP ) for the CSP and (pkMA,skMA )
for MA. Furthermore, MA runs CPABE.Setup to generate a
master public/secret key pair (MPK,MSK).
Each user (from Uor S) is registered through a central
RA2. During registration, each user receives a unique identifier
iand a public/private key pair (pki/ski). Furthermore, a set
of attributes Abased on user’s personal data is created. For
patients, identifying attributes such as name and surname
could be used. For healthcare professionals, attributes include
identification and function in the organization, and in particular
the membership and role in an emergency treatment team. This
set of attributes is sent to MA, and stored for future use to
generate ABE secret keys skA,ito decrypt patient EMR.
RAP.StoreData (I) : A patient uistores her EMR in
the CSP as a ciphertext ci
P. The generation of ci
Prequires
running CPABE.Enc(MPK,di
l, P ), where di
lis the file that
the user wishes to encrypt and Pis a policy defining
who can access di
l. In this paper we explicitly focus on
the problem of how only authorized users can access a
patient’s EMR during an emergency session. To this end,
Pneeds to always contain a condition that will allow a
user sjto successfully decrypt di
lDi,l[1,|Di|].
Among other conditions in P, the following should
be added for ui: “...OR (Emergency=TRUE
AND TreatmentTeamMember=TRUE AND
UserInEmergency=i)”. A professional sjwill be
then granted access to the EMR of uionly when her
attributes satisfy this policy.
RAP.BreakGlass (II) : Through this process the MA ac-
knowledges the emergency event for a patient uiand begins
the emergency session. This takes place when a patient, or
someone on her behalf, contacts the call centre team by phone.
The emergency call is received by se∈ S. After identifying
patient ui,secontacts MA to notify the emergency event
and requests to become part of the session by sending the
message m1=hr1,EncpkMA (ui, t, se), σse(H(r1||ui||t||se)i,
where r1is a random number generated by seand tis the
registered time of the call. Upon reception, MA confirms that
seis indeed part of the call centre team. In this proposal
we trust that sewill contact the MA only if she receives a
legitimate phone call from the patient or someone on behalf
of the patient. The phone call authentication is very important,
but it is considered outside the scope of this paper. MA
includes seto the emergency session and generates the ABE
2For the sake of simplicity we assume a single RA for all organizations.
Also, the same format is used to store EMR shared during emergency.
key (using RAP.GenKey) and token (using RAP.GenToken)
for the emergency call centre team.
The MA then sends the following message to se:m2=
hr2, τe,Encpkse(skAe,i), σMA(H(r2||τe||skAe,i))i, where skAe,i
is the ABE key including emergency attributes, and τeis the
access token for the call centre team.
RAP.JoinTeam (III) : In this step the MA associates users
in a treatment team to an existing emergency session. This is
initiated by some user who is already part of the emergency
session, and therefore in possession of an ABE key and a
valid token. At first the call centre includes the ambulance
team, which later invites the hospital team, to join the session
(see figure 2). To add a new team to the emergency session,
the following message is sent by a user sjto the MA: m3=
hr3,EncpkMA (x, sx1, sx2), σsj(H(r3||x||sx1||sx2))i, where x
{a, h}is the attested device in the ambulance aor hospital h,
and sx1, sx2are two3users co-located with x.
After receiving m3, MA confirms the identity of xand
the users. Additionally, sx1and sx2need to prove that they
are indeed together in the same location of x, which has
been specified by sj. For this confirmation, MA creates a
challenge for x,sx1and sx2in the following way: MA
generates a random number v, splits it into three random
shares such that v=v0+v1+v2, and creates challenge =
hEncpkx(v0),Encpksx1 (v1),Encpksx2 (v2)i. It then creates the
message m4=hr4,challenge, σMA(H(challenge||r4))iand
sends it to x,sx1and sx2. Upon reception, each one recovers
its own share (i.e., xuses skxto recover v0,sx1uses
skx1 for v1, etc.). Then, each one sends back its location
and the solved challenge value to the MA. For example, x
sends m5=hr5,EncpkMA (v0, lx), σx(H(r5||v0||sx1||sx2||lx))i
where lxstands for the current location of x. Analogous
messages are sent by sx1and sx2. After receiving all m5
messages, MA checks if the locations are the same (i.e.,
lx=lx1=lx2), and verifies the identities of all three
users. MA then calculates v0by adding the received shares
and checks if v=v0, in which case the verification is
completed successfully. At this moment, MA includes all the
team members (x, sx1, sx2) into the emergency session. It then
generates the ABE key (using RAP.GenKey) and access token
(using RAP.GenToken) for the team, and sends these to the
users through a message analogous to m2presented above.
RAP.RetrieveData (IV) : After having received the ABE
key and token, sjfrom team x∈ {e, a, h}is ready to
access the patient’s data. First sjsends a request to the
CSP to access all ciphertexts in the EMR of ui:m6=
hr6, τx, σsj(H(r6||τx))i, where τxis the token for team x.
Note that the token is already encrypted with the CSP public
key, and that it contains the identity of team members, uiand
token expiration time. The CSP verifies the identity of sjand
the token validity and authenticity.
After successful verification, the CSP retrieves uis ci-
phertexts and forwards them to sjthrough this message:
3Here we assume that at least two professionals are part of the team, but
more could be included in similar way.
Patient ca lls
emergency
call centre
Ambulance
arrives at
patient location
Ambulance
arrives at
1st hospital
Arrival at
1st hospital
Arrival at
2nd hospital
Timeline
Patient interaction
Call centre session
Emergency care request
Ambulance session
Hospital session
Ambulance session
Hospital session
Extra expiration time
Fig. 2. Stroke care and data access session timelines. The top line represents
events of interaction between healthcare provider entities and the patient. The
others show the period of time that each team has access to the patient data.
m7=hr7,Encpksj(ci
P), σCSP(H(r7||ci
P))i, where ci
Pis the set
of ciphertexts. Finally, through a secure application, sjuses
the emergency key skAe,ito recover ui’s EMR from ci
P.
RAP.AddData (V) : During and after patient’s treat-
ment, all teams may upload new files di
lto the patient
EMR. These files include the report of the emergency treat-
ment and needs to be encrypted with the same policy P
used by in RAP.StoreData. To do so, a professional sj
runs CPABE.Enc(MPK,di
l, P )and the output is the cipher-
text ci
P. After that, sjsends a message to CSP: m8=
hr8, τx,EncpkCSP (ci
P), σsj(H(r8||τx||ci
P))i, where τxis a token
for the team xof which sjis a member. The CSP checks the
token validity and stores ci
P.
RAP.RevokeAccess (VI) : Access needs to be revoked
when it is no longer necessary for patient treatment. This
happens when a treatment team leaves the emergency session,
which in our solution requires revocation of the token for that
treatment team. After that moment, the CSP will no longer
allow access to the ciphertexts of the patient to the users in
that treating team.
In stroke treatment, the moments when the patient arrives
and leaves the emergency care of the hospital define the end
of involvement of treatment teams. When the patient arrives at
the first hospital, the call centre team and the ambulance teams
leave the emergency session. For the call centre, revocation
of τeshould be immediate. The ambulance team, however,
is granted extra time after arrival at the hospital to add
their reports into the medical record. The revocation of τa
is therefore delayed (see figure 2). In principle, τhneeds to be
revoked when the patient leaves the hospital emergency care.
However, if the patient needs to be transferred for treatment,
the token for the first hospital will be revoked as soon as
the patient arrives at the second hospital. For this reason, as
soon as the patient arrives or leaves the hospital, shinforms
MA by sending m9=hr9,EpkMA (t), σsh(H(r9||t)i, where t
can be used as the time that the patient has been delivered
to the hospital or the time the patient leaves the hospital
emergency care. As soon as the MA knows the moment when
the patient arrived or left the hospital, it sends a message
to the CSP as follows: m10 =hr10, τx, σMA(H(r10 ||τx))i,
where τxis the token for the team xwhich is revoked from
the emergency session. The emergency session ends when all
tokens associated with it have expired or explicitly revoked.
After this, no new team is allowed to join the session anymore.
RAP.GenKey :The MA runs CPABE.Gen(MSK,Ae, ui)
to generate an ABE key for a treatment team. As
attributes, among others, MA inserts in Aethe following:
[Emergency, TreatmentTeamMember, i]”. This
guarantees that the generated key will satisfy the policy
bound to ui’s ciphertexts. The ABE key is sent to the users
in a treatment team that has joined the emergency session.
RAP.GenToken :The MA generates a token for each team
involved in the emergency session (call centre e, ambulances
aand hospitals h). These tokens are used to prove to the
CSP that a user sjhas a valid permission to access uis data.
Professionals in the different teams share the token for that
team. A token for team x∈ {e, a, h}is defined as follows:
τx= (tgen, texp ,EncpkCSP (r, sx1, sx2, ui), σMA(Hτ)), where r
is a random number, tgen is the time when the token was
generated by MA, texp is the default expiration time and Hτis
the hash of (tgen||texp ||r||x||sx1||sx2||ui). Note that the tokens
also include identification about all team members certified
through the challenge (see RAP.JoinTeam), enabling the CSP
to implement user authentication and traceability.
Tokens need to be used within a predefined time interval
from the time that are generated (tgen). This expiration time
can vary and will be defined by each implementation of
our system based on the specific needs of the underlying
environment.
VIII. SECURITY ANALYSIS
In this section, we analyze the security of the proposed ‘Red
Alert Protocol’ against several malicious behaviours. For the
needs of this analysis, we assume that all the involved crypto-
graphic schemes are semantically secure. Hence, our analysis
is focused on looking at protocol’s exchanged messages.
First, we consider the case where a corrupted user ADV
had been legitimately part of a treatment team in the past.
This implies that at some point ADV received a valid token τ
to access the medical records of a legitimate user’s ul.ADV
may now try to alter τto either access uls data after the token
expiration or use τto access the data of another patient uk,
TABLE I
PROTO COL ME SS AGE S
Index Message
m1hr1,EncpkMA (ui, t, se), σse(H(r1||ui||t||se)i
m2hr2, τe,Encpkse(skAe,i), σMA(H(r2||τe||skAe,i))i
m3hr3,EncpkMA (x, sx1, sx2), σsj(H(r3||x||sx1||sx2))i
m4hr4,challenge, σMA(H(r4||challenge))i
m5hr5,EncpkMA (v0, lx), σMA(H(r5||v0||sx1||sx2||lx))i
m6hr6, τx, σsj(H(r6||τx))i
m7hr7,Encpksj(ci
P), σCSP(H(r7||ci
P))i
m8hr8, τx,EncpkCSP (ci
P), σsj(H(r8||τx||ci
P))i
m9hr9,EpkMA (t), σsh(H(r9kt)i
m10 hr10, τx, σMA (H(r10||τx))i
l6=k. To this end, ADV needs to generate an altered token τ0
with a new t0
gen,t0
exp and/or uk, but she cannot alter the hash
in the signature of MA. When ADV sends m6or m8using
τ0to access patient data, the CSP will drop the connection
because the signature of MA will not match with the hash of
altered token.
Second, we consider the case where ADV tries to use a
token τissued to another legitimate healthcare professional
slto add a false ciphertext to the patient’s EMR. To capture
τ,ADV could overhear the communication between a sland
MA to intercept m2, or between sland CSP to intercept m6
or m8. However, the intercepted τcontains the identity of
sl, which cannot be changed because ADV cannot generate a
valid signature for the modified token, as described above. The
only remaining alternative for ADV is to use the τdirectly.
To do so, ADV uses the CSP public key to encrypt a false
ciphertext and generates m8. However, this message has to be
signed by sl, which cannot be achieved by ADV because of
the assumption that the signature scheme is unforgeable.
Third, we consider the case where the ADV wants to access
the EMR of a legitimate patient ul. To do this, the ADV needs
to have an emergency key and a valid token, which requires her
inclusion in the emergency session for ul. This attack would
need the collaboration of another corrupted user scwho is
already part of the session. More precisely, scinvites ADV to
the session by sending m3to MA with the identity of ADV
and the others in the team. After that, MA sends m4with the
challenge, which requires all users to authenticate the team
from the same location. Thus, if at least one user denies the
solution to the challenge, the attack will be prevented. As a
result, the whole team will not receive access to the emergency
key or to the token.
IX. CONCLUSION
In this paper, we proposed Red Alert – a protocol that
provides secure access control to medical records during
emergency situations. Red Alert is based on Ciphertext-Policy
Attribute-Based Encryption and allows healthcare profession-
als from different teams to decrypt patients’ medical records
during an emergency situation. The healthcare professionals
get access to the patient’s private data through an access token
that is issued to them by a semi-trusted authority. The issued
access tokens cannot be transferred and they expire to suc-
cessfully revoke access to users. Furthermore, the security of
the proposed protocol is shown by analyzing several malicious
behaviours.
It is worth mentioning that this is our first approach in
looking into the problem of how to grant access to encrypted
medical records during an emergency situation. As a result,
our approach has some drawbacks that we plan to overcome
in the future. For example, while the use of ABE offers great
flexibility in terms of access management, the size of the
produced ciphertexts and the time required to both encrypt
and decrypt a file grows proportionally with the complexity
of the underlying policy. Hence, one of our future directions
will be to reduce the use of ABE and make our protocol
more efficient by utilizing a private encryption scheme in
combination with ABE. Finally, we hope that this work will
inspire other researchers to work into this direction and design
even better protocols.
REFERENCES
[1] D. P. Manca, “Do electronic medical records improve quality of care?:
Yes,” Canadian Family Physician, vol. 61, no. 10, pp. 846–847, 2015.
[2] J. L. Saver, “Time is brain-quantified,” Stroke, vol. 37, no. 1, pp. 263–
266, 2006.
[3] A. Michalas, N. Paladi, and C. Gehrmann, “Security aspects of e-health
systems migration to the cloud,” in 2014 IEEE 16th International Con-
ference on e-Health Networking, Applications and Services (Healthcom).
IEEE, 2014, pp. 212–218.
[4] A. Abbas and S. U. Khan, “A review on the state-of-the-art privacy-
preserving approaches in the e-health clouds,” IEEE Journal of Biomed-
ical and Health Informatics, vol. 18, no. 4, pp. 1431–1441, 2014.
[5] D. Mashima and M. Ahamad, “Enhancing accountability of electronic
health record usage via patient-centric monitoring,” in Proceedings of the
2nd ACM SIGHIT International Health Informatics Symposium. ACM,
2012, pp. 409–418.
[6] R. Zhang and L. Liu, “Security models and requirements for healthcare
application clouds,” in 2010 IEEE 3rd International Conference on cloud
Computing. IEEE, 2010, pp. 268–275.
[7] M. Li, S. Yu, K. Ren, and W. Lou, “Securing personal health records
in cloud computing: Patient-centric and fine-grained data access control
in multi-owner settings,” in International conference on security and
privacy in communication systems. Springer, 2010, pp. 89–106.
[8] A. D. Brucker, H. Petritsch, and S. G. Weber, “Attribute-based encryp-
tion with break-glass,” in IFIP International Workshop on Information
Security Theory and Practices. Springer, 2010, pp. 237–244.
[9] Y. Yang, X. Zheng, W. Guo, X. Liu, and V. Chang, “Privacy-preserving
smart iot-based healthcare big data storage and self-adaptive access
control system,” Information Sciences, vol. 479, pp. 567–592, 2019.
[10] D. Povey, “Optimistic security: a new access control paradigm,” in
Proceedings of the 1999 workshop on New security paradigms. ACM,
1999, pp. 40–45.
[11] A. D. Brucker and H. Petritsch, “Extending access control models with
break-glass,” in Proceedings of the 14th ACM Symposium on Access
Control Models and Technologies, ser. SACMAT ’09. New York, NY,
USA: ACM, 2009, pp. 197–206.
[12] T. Zhang, S. S. Chow, and J. Sun, “Password-controlled encryption with
accountable break-glass access,” in Proceedings of the 11th ACM on Asia
Conference on Computer and Communications Security. ACM, 2016.
[13] S. Marinovic, R. Craven, J. Ma, and N. Dulay, “Rumpole: a flexible
break-glass access control model,” in Proceedings of the 16th ACM
symposium on Access control models and technologies. ACM, 2011.
[14] J. Bethencourt, A. Sahai, and B. Waters, “Ciphertext-policy attribute-
based encryption,” in Proceedings of the 2007 IEEE Symposium on
Security and Privacy, ser. SP’07. Washington, DC, USA: IEEE
Computer Society, 2007, pp. 321–334.
[15] A. Michalas, “Sharing in the rain: Secure and efficient data sharing
for the cloud,” in 2016 11th International Conference for Internet
Technology and Secured Transactions (ICITST). IEEE, 2016.
[16] N. Paladi, C. Gehrmann, and A. Michalas, “Providing user security
guarantees in public infrastructure clouds,” IEEE Transactions on Cloud
Computing, vol. 5, no. 3, pp. 405–419, July 2017.
[17] A. Michalas, “The lord of the shares: Combining attribute-based
encryption and searchable encryption for flexible data sharing,”
in Proceedings of the 34th ACM/SIGAPP Symposium on Applied
Computing, ser. SAC ’19. New York, NY, USA: ACM, 2019, pp. 146–
155. [Online]. Available: http://doi.acm.org/10.1145/3297280.3297297
[18] D. Dolev and A. C. Yao, “On the security of public key protocols,
Information Theory, IEEE Transactions on, vol. 29, no. 2, 1983.
[19] A. Michalas, N. Komninos, and N. Prasad, “Multiplayer game for ddos
attacks resilience in ad hoc networks,” in Wireless Communication,
Vehicular Technology, Information Theory and Aerospace Electronic
Systems Technology (Wireless VITAE), 2011 2nd International Confer-
ence on, Feb 2011, pp. 1–5.
... We propose 'Red Alert Protocol' (RAP) for the problem presented in Section 6. More precisely, our approach follows the protocols proposed in [18,21], with additions to meet the specific needs of the acute stroke care case described in Section 3. RAP was initially presented in [22], but here we extend that work by revising the protocol to address a broader threat model and presenting the protocol in a more formal construction. Below we first present an overview of the protocol followed by its definition. ...
Article
Full-text available
In emergency care, fast and efficient treatment is vital. The availability of Electronic Medical Records (EMR) allows healthcare professionals to access a patient’s data promptly, which facilitates the decision-making process and saves time by not repeating medical procedures. Unfortunately, the complete EMR of a patient is often not available during an emergency situation to all treatment teams. Cloud services emerge as a promising solution to this problem by allowing ubiquitous access to information. However, EMR storage and sharing through clouds raise several concerns about security and privacy. To this end, we propose a protocol through which all treatment teams involved in the emergency care can securely decrypt relevant data from the patient’s EMR and add new information about the patient’s status. Furthermore, our protocol ensures that treatment teams will only access the patient’s EMR for the period during which the patient is under their care. Finally, we present a formal security analysis of our protocol and some initial experimental results.
Conference Paper
Full-text available
Secure cloud storage is considered one of the most important issues that both businesses and end-users are considering before moving their private data to the cloud. Lately, we have seen some interesting approaches that are based either on the promising concept of Symmetric Searchable Encryption (SSE) or on the well-studied field of Attribute-Based Encryption (ABE). In the first case, researchers are trying to design protocols where users' data will be protected from both internal and external attacks without paying the necessary attention to the problem of user revocation. On the other hand, in the second case existing approaches address the problem of revocation. However, the overall efficiency of these systems is compromised since the proposed protocols are solely based on ABE schemes and the size of the produced ciphertexts and the time required to decrypt grows with the complexity of the access formula. In this paper, we propose a protocol that combines both SSE and ABE in a way that the main advantages of each scheme are used. The proposed protocol allows users to directly search over encrypted data by using an SSE scheme while the corresponding symmetric key that is needed for the decryption is protected via a Ciphertext-Policy Attribute-Based Encryption scheme.
Article
Full-text available
The infrastructure cloud (IaaS) service model offers improved resource flexibility and availability, where tenants – insulated from the minutiae of hardware maintenance – rent computing resources to deploy and operate complex systems. Large-scale services running on IaaS platforms demonstrate the viability of this model; nevertheless, many organizations operating on sensitive data avoid migrating operations to IaaS platforms due to security concerns. In this paper, we describe a framework for data and operation security in IaaS, consisting of protocols for a trusted launch of virtual machines and domain-based storage protection. We continue with an extensive theoretical analysis with proofs about protocol resistance against attacks in the defined threat model. The protocols allow trust to be established by remotely attesting host platform configuration prior to launching guest virtual machines and ensure confidentiality of data in remote storage, with encryption keys maintained outside of the IaaS domain. Presented experimental results demonstrate the validity and efficiency of the proposed protocols. The framework prototype was implemented on a test bed operating a public electronic health record system, showing that the proposed protocols can be integrated into existing cloud environments.
Article
Full-text available
Cloud computing is emerging as a new computing paradigm in the healthcare sector besides other business domains. Large numbers of health organizations have started shifting the electronic health information to the cloud environment. Introducing the cloud services in the health sector not only facilitates the exchange of electronic medical records among the hospitals and clinics, but also enables the cloud to act as a medical record storage center. Moreover, shifting to the cloud environment relieves the healthcare organizations of the tedious tasks of infrastructure management and also minimizes development and maintenance costs. Nonetheless, storing the patient health data in the third-party servers also entails serious threats to data privacy. Because of probable disclosure of medical records stored and exchanged in the cloud, the patients’ privacy concerns should essentially be considered when designing the security and privacy mechanisms. Various approaches have been used to preserve the privacy of the health information in the cloud environment. This survey aims to encompass the state-of-the-art privacy-preserving approaches employed in the e-Health clouds. Moreover, the privacy-preserving approaches are classified into cryptographic and noncryptographic approaches and taxonomy of the approaches is also presented. Furthermore, the strengths and weaknesses of the presented approaches are reported and some open issues are highlighted.
Conference Paper
Full-text available
This paper proposes a multiplayer game to prevent Distributed Denial of Service attack (DDoS) in ad hoc networks. The multiplayer game is based on game theory and cryptographic puzzles. We divide requests from nodes into separate groups which decreases the ability of malicious nodes to cooperate with one another in order to effectively make a DDoS attack. Finally, through our experiments we have shown that the total overhead of the multiplayer game as well as the the total time that each node needs to be served is affordable for devices that have limited resources and for environments like ad hoc networks where nodes must exchange information really fast. Index Terms—DDoS, DoS, Ad-hoc Networks, Security. I. INTRODUCTION One of the major threats in network nodes is the so called Distributed Denial of Service (DDoS) attack. In the past years we saw lot of popular sites such as Yahoo, eBay, Amazon, CNN and many more to be under such attacks. DDoS attacks present a significant security threat to corporations, and the threat appears to be growing (11). In the sixth of August (2009) the Social Networks world was under attack, in other words, we were in the middle of a planned attempt to take down two of the world's most popular social media sites: Facebook and Twitter. Even though no user data was at risk, the sites were down for several hours. DDoS, is a relatively simple, yet very powerful technique to attack Internet resources. DDoS attacks add the many-to-one dimension to the Denial of Service (DoS) problem making the prevention and mitigation of such attacks more difficult and the impact proportionally severe. DDoS exploits the intrinsic weakness of the Internet system architecture, its open resource access model, which paradoxically, also happens to be its greatest advantage (8). In this paper we propose a multiplayer game to prevent DDoS attacks in ad hoc networks, where nodes do not neces- sarily belong to a single authority and the network topology is altered dynamically. Our approach combines cryptographic puzzles and game theory to develop a multiplayer game, where every node in the network that sends a request needs to solve a puzzle, and becomes a member of a specific group. We assume that all nodes in a group play the multiplayer game and are able to communicate directly. Each multiplayer game is conducted through a series of 2-player sub-games. Once all possible 2-player combinations have been played in a group, the highest scoring node is the one whose initial request is authorized, while the rest of the nodes in the group have to continue playing the game until all of their requests have been authorized. Hence, each group will end up having one last player, in which case a different type of sub-game will be played, between the remaining node and the node that is authorizing the requests. This method ensures that the bulk of the computation overhead is taken up by the requesting node, and not the authorizing node, which is only tasked with checking winning results. With the exception of dealing with the last remaining node in each group, the authorizing node is not competing directly in the game process, and not expending computational resources. In this method, a possible malicious node will be responsible for making the most expensive computations of the protocol in order to get access to the resources of another node in the network. Following this introduction the paper is organized as fol- lows. In Section 2 we examine related works that have been made in order to solve DoS and DDoS problems with the use of client puzzles and game theory. In Section 3 we describe our technique, combining game theory and puzzles. In Section 4 we analyze our approach and we present our experimental results and we conclude in Section 5.
Conference Paper
Full-text available
With the widespread use of electronic health record (EHR), building a secure EHR sharing environment has attracted a lot of attention in both healthcare industry and academic community. Cloud computing paradigm is one of the popular healthIT infrastructure for facilitating EHR sharing and EHR integration. In this paper we discuss important concepts related to EHR sharing and integration in healthcare clouds and analyze the arising security and privacy issues in access and management of EHRs. We describe an EHR security reference model for managing security issues in healthcare clouds, which highlights three important core components in securing an EHR cloud. We illustrate the development of the EHR security reference model through a use-case scenario and describe the corresponding security countermeasures and state of art security techniques that can be applied as basic security guards.
Article
In this paper, a privacy-preserving smart IoT-based healthcare big data storage system with self-adaptive access control is proposed. The aim is to ensure the security of patients' healthcare data, realize access control for normal and emergency scenarios, and support smart deduplication to save the storage space in big data storage system. The medical files generated by the healthcare IoT network are encrypted and transferred to the storage system, which can be securely shared among the healthcare staff from different medical domains leveraging a cross-domain access control policy. The traditional access control technology allows the authorized data users to decrypt patient's sensitive medical data, but also hampers the first-aid treatment when the patient's life is threatened because the on-site first-aid personnel are not permitted to get patient's historical medical data. To deal with this dilemma, we propose a secure system to devise a novel two-fold access control mechanism, which is self-adaptive for both normal and emergency situations. In normal application, the healthcare staff with proper attribute secret keys can have the data access privilege; in emergency application, patient's historical medical data can be recovered using a password-based break-glass access mechanism. To save the storage overhead in the big data storage system, a secure deduplication method is designed to eliminate the duplicate medical files with identical data, which may be encrypted with different access policies. A highlight of this smart secure deduplication method is that the remaining medical file after the deduplication can be accessed by all the data users authorized by the different original access policies. This smart healthcare big data storage system is formally proved secure, and extensive comparison and simulations demonstrate its efficiency.
Conference Paper
Cloud storage has rapidly become a cornerstone of many businesses and has moved from an early adopters stage to an early majority, where we typically see explosive deployments. As companies rush to join the cloud revolution, it has become vital to create the necessary tools that will effectively protect users' data from unauthorized access. Nevertheless, sharing data between multiple users' under the same domain in a secure and efficient way is not trivial. In this paper, we propose Sharing in the Rain – a protocol that allows cloud users' to securely share their data based on predefined policies. The proposed protocol is based on Attribute-Based Encryption (ABE) and allows users' to encrypt data based on certain policies and attributes. Moreover, we use a Key-Policy Attribute-Based technique through which access revocation is optimized. More precisely, we show how to securely and efficiently remove access to a file, for a certain user that is misbehaving or is no longer part of a user group, without having to decrypt and re-encrypt the original data with a new key or a new policy.
Conference Paper
We propose the notion of password-controlled encryption, a two-factor scheme involving a user-chosen password and the master public/secret key pair. The data owner obtains a secret key generated from a password and the master secret key of a key generation center (KGC) after authentication, and shares this password with encryptors and an emergency contact. In normal circumstances, the data owners can enforce access control by themselves. In emergency when the data owner is unavailable, any one with the same password can request for the decryption key from a KGC, without letting the KGC to know the password. At the same time, the KGC is held accountable if the key generation process is abused. Password-controlled encryption is especially applicable for protecting electronic medical record, which provides confidentiality with break-glass access, without relying on a key-escrow server or trusted hardware.
Conference Paper
Access control operates under the assumption that it is possible to correctly encode and predict all subjects' needs and rights. However, in human-centric pervasive domains, such as health care, it is hard if not impossible to encode all emergencies and exceptions, but also to imagine a priori all the permissible requests. Break-glass is an approach that em- bodies the idea that under certain conditions it is possible for a subject to break-the-glass and explicitly override the denied request. Current break-glass models make this decision without considering and investigating what the reasons for issuing the denial are, and they have a fixed decision procedure to determine whether the override is permitted. Furthermore, they do not explicitly represent and reason over conflicting and missing information about subjects and the context; which in human-centric pervasive domains is a norm rather than an anomaly. This paper presents a novel break-glass model, Rumpole, that structures a break-glass policy by establishing why the access was denied. It uses Belnap's four-valued logic to represent conflicting and missing (unknown) information, allowing the policy to make a more informed decision when faced with missing or inconsistent knowledge. The model also provides a declarative query language that is used to specify an explicit break-glass decision procedure, rather than having an implicitly hard-coded one. This allows a policy writer to further condition and restrict when and how break-glass access is permitted.