Protecting Medical Data Stored in Public Clouds

Nikos Fotiou and George Xylomenos

Mobile Multimedia Laboratory, Department of Informatics, School of Information Sciences and Technology,

Athens University of Economics and Business, Patision 76, Athens 10434, Greece

Keywords:

Access Control, Identity-based Encryption, Proxy Re-encryption.

Abstract:

Public Clouds offer a convenient way for storing and sharing large amounts of medical data. Nevertheless,

using a shared infrastructure raises signiﬁcant security and privacy concerns. Even if the data are encrypted,

the data owner should share some information with the Cloud provider, in order to enable the latter to perform

access control; given the high sensitivity of medical data, even such limited information may jeopardize end-

user privacy. In this paper we employ an access control delegation scheme to enable the users themselves to

perform access control on their data, which are stored in a public Cloud. To selectively provide access to these

data without sacriﬁcing their conﬁdentiality we rely on encryption: our system encrypts data before storing

them in the Cloud and applies proxy re-encryption so as to encrypt data separately for each (authorized) user.

1 INTRODUCTION

Nowadays, smart devices that collect users’ vital sig-

nals have become a commodity. It is expected that

soon the data collected by these devices will be used

for preventing and/or diagnosing various health re-

lated problems, as well as for promoting a health-

ier way of living and well-being. Storing and shar-

ing these data using a public Cloud infrastructure ap-

pears to be an appealing option, as public Clouds of-

fer cost effective and reliable storage services. On the

other hand, security and privacy concerns are raised,

as medical data are highly sensitive and they should

be protected, even against the Cloud service provider.

Encryption and access control can be used as a coun-

termeasure, but privacy threats remain. For exam-

ple, an access control policy of the form “these (en-

crypted) data can only be accessed by psychiatrist A”

reveals to the entity that performs access control that

the data owner shares some data with a psychiatrist.

In this paper we propose a system that allows se-

cure and private storage of medical records in the

Cloud. Our system allows data owners to deﬁne ac-

cess control policies and to enforce them by them-

selves. The Cloud provider is only responsible for

storing data and for respecting the access control de-

cisions of the data owner. Even if the Cloud provider

misbehaves, the data remain protected since they are

encrypted in a way that only authorized users can ac-

cess them; unauthorized users – including the Cloud

provider – learn nothing about the data. In order

to achieve our goal we extend the system proposed

by (Fotiou et al., 2015) by adding an additional layer

of data conﬁdentiality protection. Our proposal en-

crypts data before storing them in the Cloud and

re-encrypts them as necessary before sharing; data

are encrypted only once by an entity owned by the

data owner, and then the Cloud is responsible for re-

encrypting the data in such a way that only authorized

clients can access them.

The remainder of the paper is organized as fol-

lows. Section 2 brieﬂy presents access control del-

egation and proxy re-encryption. Section 3 presents

our system design. In Section 4 we evaluate our so-

lution and in Section 5 we present related work in the

area. Finally we conclude our paper in Section 6

2 BACKGROUND

2.1 Access Control Delegation

The access control scheme proposed in (Fotiou et al.,

2015) separates data storage and access control func-

tions: the former is implemented in a public Cloud,

whereas the latter is implemented by a trusted entity

named access control provider (ACP). These entities

interact with each other as follows (Figure 1)

: Ini-

tially, a data owner creates an access control policy,

The description has been modiﬁed to ﬁt the purposes of

the present paper.

Fotiou, N. and Xylomenos, G.

Protecting Medical Data Stored in Public Clouds.

In Proceedings of the International Conference on Information and Communication Technologies for Ageing Well and e-Health (ICT4AWE 2016), pages 127-132

ISBN: 978-989-758-180-9

127

Data Owner

(1) Access control policy

(2) URI to policy

(3) Data, URI to policy

(4) Request data

(5) Token, URI to policy

(6) Authenticate, Token, URI to policy

Cloud

Client

ACP

(9) Data

Figure 1: Access control delegation.

stores it in an ACP (step 1) and obtains a URI for

that policy (step 2). Then, he stores some data in the

Cloud, indicating at the same time the URI of the pol-

icy that protects these data (step 3). When a client

tries to access these data (step 4), the Cloud responds

with the URI of the access control policy and a unique

token (step 5). Then, the client authenticates herself

to the ACP and requests authorization (step 6). If the

client “satisﬁes” the access control policy, the ACP

generates a signed authorization and sends it back

(step 7). Finally, the client repeats her request to the

Cloud, this time including the authorization (step 8).

The Cloud checks the validity of the authorization and

if it is valid, it returns the desired data (step 9).

This scheme has many advantages. The Cloud

provider learns nothing about the client since all her

personal data (which are required to evaluate the ac-

cess control policy) are stored in the ACP. Moreover,

Cloud providers do not have to interpret any access

control policies, therefore they do not need to under-

stand content owner speciﬁc semantics. Access con-

trol policies are reusable i.e, in order to protect a new

item using an existing access control policy the same

URI can be simply re-used. Access control policies

can be easily updated; updating and access control

policy does not involve any communication with the

Cloud provider. Finally, providing that many Cloud

providers support this scheme, it is trivial for a data

owner to migrate from one Cloud provider to another.

2.2 Proxy Re-encryption

A Proxy re-encryption (PRE) scheme is a scheme in

which a third, semi-trusted party, the proxy, is allowed

to alter a ciphertext encrypted with the public key of

a user A (the delegator), in a way that another user B

(the delegatee) can decrypt it with her own appropri-

ate key (in most cases, her secret private key). During

this process the proxy learns nothing about the pri-

vate keys of A and B, and does not gain access to the

encrypted data.

In this paper we employ the identity-based proxy

re-encryption (IB-PRE) scheme by Green and Ate-

niese (Green and Ateniese, 2007). In particular we

use a variant of that scheme in which the delegatee

uses an RSA public key instead of identity-based en-

cryption (section 5 of (Green and Ateniese, 2007)).

This scheme speciﬁes the following algorithms (the

description has been adapted to the RSA variant):

• Setup: it is executed by a Private Key Generator

(PKG). It takes as input a security parameter k and

returns a master-secret key (MSK) and some

system parameters (SP). The MSK is kept se-

cret by the PKG, whereas the SP are made pub-

licly available.

• Extract: it is executed by a PKG. It takes as input

the SP, the MSK, and an arbitrary string ID, and

returns a secret key SK

• Encrypt: it can be executed by anyone. It takes

as input an arbitrary string ID, a message M, and

the SP, and returns a ciphertext C

• RKGen: it is executed by the owner of the iden-

tiﬁer ID1. It takes as input the SP, the secret key

ID1

and an RSA public key RSA2 and generates

a (public) re-encryption key RK

ID1→RSA2

• Reencrypt: it is executed by a proxy. It takes

as input the SP, a re-encryption key RK

ID1→RSA2

and a ciphertext C

ID1

and outputs a new ciphertext

RSA2

ICT4AWE 2016 - 2nd International Conference on Information and Communication Technologies for Ageing Well and e-Health

128

ID2

(2) Extract SK

ID1

RSA

ID3

ID1

(3) Encrypt using ID1

Proxy

(5) Reencrypt using RK

ID1

ID2

(6) Decrypt using SK

RSA2

ID1

(1) Setup

PKG

MSK

Figure 2: IBE-PRE example.

• Decrypt: is is executed by the owner of the key

RSA2. It takes as input the SP, C

RSA2

, the corre-

sponding RSA private decryption key SK

RSA2

, and

returns the message M.

Figure 2 gives an example of a complete IBE-PRE

transaction. In this ﬁgure, initially the PKG generates

the MSK and the SP, and makes the SP publicly avail-

able (step 1). Then it extracts SK

ID1

and distributes it

to the corresponding user ID1 (step 2). Another user

creates a ciphertext using as a public key the string

ID1 and stores it in a proxy (step 3). This can only

be decrypted by the user that owns ID1, (and there-

fore knows the corresponding SK

ID1

). To allow a user

ID2 to decrypt the content using an RSA private key

RSA

, the user that owns ID1 creates a re-encryption

key RK

ID1→RSA2

and sends it to the proxy. The proxy

re-encrypts C

ID1

using the re-encryption key and gen-

erates C

RSA2

. The user ID2 is now able to decrypt

the re-encrypted ciphertext. The proxy learns nothing

about the contents of the ciphertext or the secret keys

of the users. Moreover, the scheme of Green and Ate-

niese assures the SK of the delegator (in this example,

ID1

) is protected even if the proxy and the delegatee

collude.

If the original version of the scheme is used (in-

stead of the RSA variant) then all delegator-delegatee

pairs have to agree on the the same PKG. This how-

ever, raises security concerns, since PKGs will know

the private keys of both parties of a transaction. More-

over, if a delegatee interacts with many delegators (as

for example in the case of a hospital that interacts with

its patients) then this results in a non-negligible key

management overhead.

3 DESIGN

Our system assumes smart devices that collect user

related data (such as smart watches that measure car-

dio activity) and store them in a public Cloud. All

these devices interact with the Cloud through a user

controlled gateway. This gateway has the roles of the

PKG and ACP described in the previous section. All

communications (between the smart devices and the

gateway and between the gateway and the Cloud) are

secured using TLS. Data storage is implemented us-

ing the following steps:

• Initially the gateway executes the IBE-PRE setup

algorithms and generates the user’s master secret

key (MSK) and the corresponding (public) sys-

tem parameters. The MSK is then securely stored

in the gateway. Moreover, the gateway generates

a secret key (SK) that corresponds to the user’s

identity. The form and the semantics of a user

identity are application speciﬁc.

• The user deﬁnes access control policies specify-

ing the public keys that can access the data gener-

ated by each device. These policies are also stored

in the gateway. For each policy the gateway gen-

erates a URI of the form <gateway FQDN/access

control policy name>. We will refer to this URI

as URI

policy

• For each data item that arrives in the gateway, the

gateway generates a symmetric encryption key K,

encrypts the item using K (we refer to the output

as Enc(key)), and encrypts K using the IB-PRE

encrypt algorithm, with the user’s identity as input

(we refer to the output as C

(K)).

• The gateway stores Enc(key), C

(K), and

URI

policy

in the Cloud.

All potential clients that want to access some data

stored in the Cloud must have generated a pub-

lic/private key pair. The public part of this pair (which

we refer to as PK

client

) is the key used by data owners

when deﬁning access control policies. Data access is

implemented using the following steps:

• The client sends a data request to the Cloud. The

Cloud responds with URI

policy

and a token.

• The client communicates with the gateway of the

user (located in gateway FQDN), and authenti-

cates himself. The authentication procedure is

application speciﬁc. For example, it can be im-

plemented by having the client digitally sign a

gateway-generated nonce using his private key.

When the authentication procedure is completed,

Protecting Medical Data Stored in Public Clouds

129

Smart device PKG

ACP

Gateway

Cloud

Client

Files

Data

Owner

Policies

File Request

Token, URI

Token, Authorisation Req.

Authorization, Re-key

Figure 3: Design overview.

and providing that the client is authorized to ac-

cess data items protected by URI

policy

, the gate-

way generates the appropriate authorization and

uses the IB-PRE RKGen algorithm to generate the

(public) re-encryption key RK

ID→PK

Client

• The client sends a new data request to the Cloud,

including this time the authorization and the re-

encryption key. The Cloud provider validates

the authorization, and if it is valid, it re-encrypts

(K) and sends the new ciphertext along with

Enc(key) to the client.

• Provided that the client is indeed the owner of the

client

used during the authentication process, he

is able to decrypt the re-encrypted version of K

and then use K to decrypt the ﬁle.

Figure 3 gives an overview of our system. It

should be noted that access control policies and re-

encryption keys are re-usable. Therefore, if a client,

authorized for a particular URI

policy

, requests another

item protected by the same policy, then communica-

tion with the gateway is not required.

3.1 Group Policies

It is often desirable to organize potential clients in

a group and deﬁne access control polices based on

these groups. For example, “doctors of hospital A”

could be considered a group. Contemporary crypto-

graphic techniques such as attributed-based encryp-

tion (Goyal et al., 2006), or hierarchical identity-

based encryption (Boneh et al., 2005) could be used to

achieve this goal. However, we do not consider this

option, because, for security reasons, we want each

client to be able to generate her keys by herself, which

is not possibly with these cryptographic techniques.

Instead, we follow a more conservative approach. We

assume that each group is identiﬁed by a public key.

This key is known to data owners and it is used dur-

ing access control deﬁnition. Moreover, each group

member has generated a public/private key pair. The

public part of this pair is included in a X.509 certiﬁ-

cate which is digitally signed using the private key of

the group. For instance, in our example the public

keys of the doctors should be signed by the private

key of the group “doctors of hospital A”. If a client

belongs to multiple groups, he should have multiple

X.509 certiﬁcates.

When a client requests authorization from the

gateway, she includes in her request her digital certiﬁ-

cate. The digital signature included in the certiﬁcate

is used by the gateway in order to evaluate whether or

not the client belongs to an authorized group. If this

is the case, then the gateway can use the public key of

the client (included in the certiﬁcate) to perform the

proxy re-encryption procedure described above, and

therefore to allow the user access to the data. Note

that the gateway does not need to know or store any

details about the members of the group; it only needs

to know the public key of the group.

4 EVALUATION

We have implemented the IB-PRE part of our sys-

tem by modifying the Green-Ateniese IBE-PRE

implementation included in the Charm Crypto li-

brary (Akinyele et al., 2013) to support RSA public

keys for the delegatee. In order to achieve a security

level equivalent to RSA with a key size of 1024 bits

for the encryption of the symmetric key, the size of

(key) is 3232 bits, and the size of a re-encryption

key is 1536 bits. In an Ubuntu 12.04 Desktop ma-

chine, running in a single core of an Intel i5-4440

3.1 GHz processor with 2GB of RAM, the creation

of C

(key) required 40 ms, the creation of a re-

encryption key required 20 ms, the re-encryption of

a ciphertext required 31 ms, and the decryption of a

ciphertext required 28 ms.

The IB-PRE cryptographic algorithm used by our

system has been proven to be secure in (Green and

Ateniese, 2007). Moreover, the access control dele-

ICT4AWE 2016 - 2nd International Conference on Information and Communication Technologies for Ageing Well and e-Health

130

gation solution used by our system exhibits many ad-

vantages: it is generic enough, it can be easily im-

plemented by a Cloud provider, data can be easily

transferred between Cloud providers that implement

this solution, it protects client privacy against third

parties (including the Cloud providers), and it allows

easy modiﬁcation of access control policies (Fotiou

et al., 2015).

Each data item is encrypted using a different sym-

metric encryption key, therefore, the compromise of

a symmetric encryption key would require the re-

encryption of that speciﬁc item only with another

fresh key. This is an inevitable overhead of all sim-

ilar systems and it is due to the fact that public key

encryption cannot be applied directly to the ﬁle con-

tents, due to its computation complexity. Neverthe-

less, for small data items, such as readings from wear-

able devices, it may be possible to negate the need for

symmetric encryption.

5 RELATED WORK

ohr et al. (L

ohr et al., 2010) have proposed a solution

for securing e-health clouds based on Trusted Virtual

Domains (TVDs). TVD is a virtualization technique

that creates secure “sandboxes” where user data can

reside. This solution is orthogonal to our system: the

solution by L

ohr et al. concerns the design of secure

clouds speciﬁc to e-health services, whereas our so-

lution assumes a generic cloud service and builds a

secure data sharing system on top of it.

Wu et al. (Wu et al., 2012) propose an access con-

trol mechanism for sharing electronic health records

in the Cloud. The main component of their mecha-

nism is an access broker that is responsible for en-

forcing access control policies. The access broker is

an entity shared among many stakeholders, therefore,

privacy concerns are raised. In our work, access con-

trol policies are enforced by data owners in a way that

reveals no information about data owners or clients

to third parties (including the Cloud provider). Son

et al. (Son et al., 2015) propose a mechanism that

supports “dynamic” access control, i.e., access con-

trol that takes into consideration the user’s context.

In their solution, access control is also implemented

in the Cloud, therefore the same privacy concerns are

raised.

Fabian et al. (Fabian et al., 2015) use attribute-

based encryption (ABE) to protect medical data

stored in multi-Cloud environments and shared

among different cooperative organizations. ABE pro-

duces encrypted data in a way that only users with

speciﬁc “attributes” can decrypt. In essence, ABE

incorporates access control policies into ciphertexts.

The disadvantage of using ABE for this purpose is

that the loss of a private key that corresponds to an at-

tribute requires the generation of a new key, the distri-

bution of this key to all users that have this attribute,

and the appropriate encryption of all ﬁles protected

by this attribute. In contrast, in our system the loss

of the data owner’s secret key only requires a new en-

cryption of all symmetric keys. Similarly, (Li et al.,

2013), (Liu et al., 2015) use attribute-based encryp-

tion to protect personal health records stored in public

cloud environments; these solution also suffer from

the same problems.

Thilakanathan et al. (Thilakanathan et al., 2014)

use ElGamal public key encryption and a proxy re-

encryption like protocol to protect generic health data

stored in the cloud. Their solution relies on a cen-

tralized trusted third party that generates private keys

on behalf of users. In our system users generate their

private keys by themselves, therefore our approach of-

fers increased security.

6 CONCLUSION AND FUTURE

WORK

In this paper we presented a solution that allows se-

cure and privacy preserving storage of medical data

in public Clouds, by leveraging access control dele-

gation and proxy re-encryption. Our solution is based

on a gateway-based design, where a user controlled

gateway is responsible for encrypting user generated

data, as well as for enforcing access control policies.

Future work involves the transfer of the encryp-

tion process to the devices that generate the data. In

this manner, the device could store the data directly

to the Cloud, avoiding the gateway, therefore reduc-

ing communication overhead. Currently, our work as-

sumes that devices can be securely authenticated to

the gateway and, similarly, the gateway can be se-

curely authenticated to the Cloud. Future enhance-

ments of our system would also consider and imple-

ment these functions.

REFERENCES

Akinyele, J., Garman, C., Miers, I., Pagano, M., Rushanan,

M., Green, M., and Rubin, A. (2013). Charm:

a framework for rapidly prototyping cryptosystems.

Journal of Cryptographic Engineering, 3(2):111–128.

Boneh, D., Boyen, X., and Goh, E.-J. (2005). Hierarchical

identity based encryption with constant size cipher-

text. In Cramer, R., editor, Advances in Cryptology

Protecting Medical Data Stored in Public Clouds

131

EUROCRYPT 2005, volume 3494 of Lecture Notes

in Computer Science, pages 440–456. Springer Berlin

Heidelberg.

Fabian, B., Ermakova, T., and Junghanns, P. (2015). Collab-

orative and secure sharing of healthcare data in multi-

clouds. Information Systems, 48:132 – 150.

Fotiou, N., Machas, A., Polyzos, G. C., and Xylomenos,

G. (2015). Access control as a service for the cloud.

Journal of Internet Services and Applications, 6(1):1–

15.

Goyal, V., Pandey, O., Sahai, A., and Waters, B. (2006).

Attribute-based encryption for ﬁne-grained access

control of encrypted data. In Proceedings of the 13th

ACM Conference on Computer and Communications

Security, CCS ’06, pages 89–98, New York, NY, USA.

ACM.

Green, M. and Ateniese, G. (2007). Identity-based proxy re-

encryption. In Katz, J. and Yung, M., editors, Applied

Cryptography and Network Security, volume 4521 of

Lecture Notes in Computer Science, pages 288–306.

Springer Berlin Heidelberg.

Li, M., Yu, S., Zheng, Y., Ren, K., and Lou, W. (2013).

Scalable and secure sharing of personal health records

in cloud computing using attribute-based encryption.

Parallel and Distributed Systems, IEEE Transactions

on, 24(1):131–143.

Liu, J., Huang, X., and Liu, J. K. (2015). Secure shar-

ing of personal health records in cloud computing:

Ciphertext-policy attribute-based signcryption. Fu-

ture Generation Computer Systems, 52:67 – 76. Spe-

cial Section: Cloud Computing: Security, Privacy and

Practice.

ohr, H., Sadeghi, A.-R., and Winandy, M. (2010). Secur-

ing the e-health cloud. In Proceedings of the 1st ACM

International Health Informatics Symposium, IHI ’10,

pages 220–229, New York, NY, USA. ACM.

Son, J., Kim, J.-D., Na, H.-S., and Baik, D.-K. (2015).

Dynamic access control model for privacy preserving

personalized healthcare in cloud environment. Tech-

nology and Health Care, 24(s1):S123–S129.

Thilakanathan, D., Chen, S., Nepal, S., Calvo, R., and

Alem, L. (2014). A platform for secure monitoring

and sharing of generic health data in the cloud. Future

Generation Computer Systems, 35:102 – 113. Special

Section: Integration of Cloud Computing and Body

Sensor Networks; Guest Editors: Giancarlo Fortino

and Mukaddim Pathan.

Wu, R., Ahn, G.-J., and Hu, H. (2012). Secure sharing of

electronic health records in clouds. In Collaborative

Computing: Networking, Applications and Workshar-

ing (CollaborateCom), 2012 8th International Con-

ference on, pages 711–718.

ICT4AWE 2016 - 2nd International Conference on Information and Communication Technologies for Ageing Well and e-Health

132