Red Alert: Break-Glass Protocol to Access Encrypted Medical Records in the Cloud

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 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.

Full text

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 cP←Enc(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
l∈Dito 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
l∈Di,∀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 ui’s 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 ui’s 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 ul’s 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.