An Efﬁcient Privacy-preserving Recommender System for e-Healthcare

Systems

Danilo Verhaert, Majid Nateghizad and Zekeriya Erkin

Cyber Security Group, Department of Intelligent Systems, Delft University of Technology, The Netherlands

Keywords:

Recommender System, Privacy-preserving, Homomorphic Encryption, Multi-party Computation,

Comparison Protocol.

Abstract:

The signiﬁcant growth of medical data has necessitated the development of secure health-care recommender

systems to assist people with their health-being effectively. Unfortunately, there is still a considerable gap

between the performance of secure recommender systems and normal versions. In this work, we develop

a privacy-preserving health-care recommendation algorithm to reduce that gap. The main strength of our

contribution lies in providing a highly efﬁcient solution, while the sensitive medical data are kept conﬁdential.

Our studies show that the runtime of our protocol is 81,5% faster than the existing implementation for small

bit-lengths, and even more so for large bit-lengths.

1 INTRODUCTION

Deploying advanced information technology in the

healthcare ﬁeld has resulted in the migration of med-

ical records from paper-based to Electronic Health

Records (EHRs). This migration has facilitated shar-

ing of medical data to healthcare organizations and

research institutions, to provide high-quality health-

care services faster and more convenient (Longo and

Drazen, 2016). This concerns health services includ-

ing but not limited to storing, managing, analyzing,

and sharing of EHRs (Baroody and Hansen, 2012;

Tiggle, 2012). Having a large amount of EHRs along-

side other health information can be very beneﬁcial

for people who are seeking for medical information.

In fact, this amount of medical information is chang-

ing the behavior of patients to become more edu-

cated and self-caring (Gavgani, 2010). Recent stud-

ies (Kivits, 2006; McMullan, 2006) show that well-

informed patients are more involved in their treat-

ment, and their behavior in the patient-physician re-

lationship changes.

However, the vast amount and irrelevancy of med-

ical information are great challenges for patients, hin-

dering them from drawing a conclusion on their health

status and taking proper actions (Sommerhalder et al.,

2009). As a solution to this challenge, Recommender

Systems (RSs) can collect the information from dif-

ferent resources and generate recommendations based

on the preferences of patients for a set of condi-

tions such as age, gender, and symptoms (Lu et al.,

2015). RSs allow patients to get preliminary advice

on speciﬁc symptoms, choose proper physicians in

their vicinity who are experts in the particular ﬁeld,

or build a community of patients who have the simi-

lar diseases.

Although RSs can beneﬁt patients in many ways,

using RSs, especially in the medical domain, raises

privacy concerns (Ramakrishnan et al., 2001; Fiza

et al., 2016). Patients’ preferences and medical in-

formation are highly privacy-sensitive. Medical in-

formation may include types of diseases and symp-

toms, personal data, and ﬁnancial information, which

are the potential targets for attackers (Chhanabhai

and Holt, 2007; Alem

´

an et al., 2013). The privacy

challenges in RSs arises doubts in patients, making

them less willing to share their sensitive medical data

RSs. Data encryption is a well-known approach to

address the privacy concerns in RSs, since it provides

data conﬁdentiality, while the data can be still uti-

lized for generating recommendations without loss of

accuracy (Katzenbeisser and Petkovic, 2008; Hoens

et al., 2013). However, applying data encryption

to any system introduces signiﬁcant overheads both

computation- and communication-wise. This chal-

lenge is what causes a huge performance gap between

the performance of a system when operations are per-

formed over clear data and the secure version of the

same system. Many researchers have been focusing

on improving cryptographic building-blocks recently

188

Verhaert, D., Nateghizad, M. and Erkin, Z.

An Efﬁcient Privacy-preserving Recommender System for e-Healthcare Systems.

DOI: 10.5220/0006858501880199

In Proceedings of the 15th International Joint Conference on e-Business and Telecommunications (ICETE 2018) - Volume 2: SECRYPT, pages 188-199

ISBN: 978-989-758-319-3

Copyright © 2018 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

(Nateghizad et al., 2016; Schoenmakers and Tuyls,

2006).

In this work, we improve the performance of

(Hoens et al., 2013) through using state-of-the-

art cryptographic building blocks and algorithmic

changes. In (Hoens et al., 2013), a framework is intro-

duced that enables patients to receive recommenda-

tions to choose the best physicians based on their pref-

erence and conditions in a privacy-preserving form.

The system also allows patients to rate their physi-

cians, which later helps to rank these physicians based

on their reputation and thereby generate more accu-

rate recommendations. However, the low efﬁciency

of the system makes it challenging to use it in large-

scale applications.

2 RELATED WORK

The importance of protecting users’ private data in

RSs has made researchers introduce different ap-

proaches to achieve secure RSs. Among these ap-

proaches, data perturbation (Agrawal and Srikant,

2000) and cryptography (Lindell and Pinkas, 2000)

have as of late been investigated further in the litera-

ture. To statistically protect private data, Polat and Du

in (Polat and Du, 2005) proposed a secure RS by us-

ing randomized perturbation techniques in (Agrawal

and Srikant, 2000). Later, Zhang et al. (Zhang et al.,

2006) proved that original private data can be de-

rived from the disguised data by employing two tech-

niques: k-means clustering and singular value decom-

position. To achieve a trade-off between privacy and

accuracy, Shokri et al. (Shokri et al., 2009) introduced

an RS that is built on a distributed communication

and aggregation to hide private data. McSherry and

Mironov (McSherry and Mironov, 2009) proposed

an RSs that provides differential privacy, surveyed

by Dwork (Dwork, 2007), with the same trade-off

between security and privacy. Cissee and Albayrak

(Ciss

´

ee and Albayrak, 2007) developed a privacy-

preserving RS based on multi-agent system technol-

ogy demanding a secure environment and trusted soft-

ware. Canny (Canny, 2002) introduced a secure RS

to aggregate data securely, allowing users to generate

recommendations from their preference data.

Katzenbeisser and Petkovic (Katzenbeisser and

Petkovic, 2008) proposed a secure RS for consumer

healthcare using cryptographic private proﬁle match-

ing techniques. Erkin el al. (Erkin et al., 2011; Erkin

et al., 2012) developed more efﬁcient RSs built on

multi-party computation and homomorphic encryp-

tion. Although using cryptographic techniques guar-

antees preventing private data leakage, it introduces

computational and communicational overheads and

requires the presence of a semi-trusted third party in

the protocols. Hoens et al. (Hoens et al., 2013) de-

veloped a framework built upon cryptographic tools

that enables patients to ﬁnd proper physicians based

on their preference data. Their system allows patients

to contribute their rating for physicians in the sys-

tem. However, (Hoens et al., 2013) introduces sig-

niﬁcant overhead, computation- and communication-

wise. Using inefﬁcient building blocks and converting

encrypted decimal values to binary form are among

the main reasons that make the recommendation sys-

tem in (Hoens et al., 2013) impractical in large-scale

databases.

3 PRELIMINARIES

In this section, we describe several preliminaries re-

quired for understanding the protocol. We ﬁrst ex-

plain the cryptographic primitives and follow up by

describing the building blocks in the protocol. Here-

after the framework and architecture of the system are

elaborated on.

3.1 Cryptographic Primitives

3.1.1 Homomorphic Encryption

Homomorphic encryption is a type of encryption

where performing certain operations on encrypted

data results in operations on the underlying data. In

this work, we rely on an additively homomorphic

cryptosystem, Paillier (Paillier, 1999). Given two

encrypted messages E

pk

(m

1

) and E

pk

(m

2

), a new

ciphertext whose decryption yields the sum of the

plaintext messages m

1

and m

2

can be obtained by

performing a certain operation over the ciphertexts:

D

sk

(E

pk

(m

1

)∗E

pk

(m

2

)) = m

1

+m

2

. Consequently, an

exponentiation of a ciphertext with any public value

yields the encrypted product of the original plaintext

and exponent: D

sk

(E

pk

(m)

e

) = m ∗ e.

3.1.2 Secret Sharing

The concept of secret sharing refers to methods for

distributing a secret s amongst a group of participants,

each of whom is allocated a part of the secret. The se-

cret can be reconstructed only when a sufﬁcient num-

ber of shares are combined together. We use the secret

sharing scheme of A. Shamir (Shamir, 1979), which

assumes n parties share a secret s in a way that each

party owns the function value f

s

(i) of a polynomial f

s

with a degree of at most t and s = f

s

(0). Note that in

An Efﬁcient Privacy-preserving Recommender System for e-Healthcare Systems

189

Table 1: Symbols and their descriptions.

Symbol Description Symbol Description

a,b Secret inputs n Number of servers

E Encryption function t threshold

D Decryption function s

jk

Score for physician j on condition k

m Plaintext r

jk

Rating for physician j on condition k

c Ciphertext w

jk

Weight for physician j on condition k

s Secret v Weight for certain health conditions

l Bit length of secret inputs b Experience factor

i Patient q Thresholds for the experience factor

j Physician m thresholds for the experience factor

k Health condition ∈

R

X A random number in X

[a] Encrypted value of a / Integer division

[a]

lB

Encryption of l least signiﬁcant bits of a f

jk

Non-zero ﬂag

Z

n

Paillier message space δ Difference in experience factors

the remainder of this paper, computational servers are

used as parties for this scheme.

3.1.3 Secure Multi-party Computation

The goal of secure multi-party computation is to eval-

uate a certain function based on the secrets of multiple

parties. This work makes use of two secure multi-

party computations (MPC). The ﬁrst MPC is sharing

a value additively amongst several parties, and the

second MPC is threshold decryption which enables a

group of k out of n parties to securely decrypt a value

without leaking any information about the private key

as studied by Damg

˚

ard and Jurik (Damg

˚

ard and Ju-

rik, 2001). This relies on the secret sharing scheme

mentioned above.

3.2 Building Blocks

In this section, we describe four building blocks used

in existing (Hoens et al., 2013) and our proposal. In

what follows, [a] is used to denote an encrypted value

of a. Furthermore, [a]

lB

denotes encryption of l least

signiﬁcant bits a, i.e., [a]

lB

= h[a

0

],...,[a

l−1

]i, where

a

i

∈ {0,1} for i = 0,...,l − 1 and a =

∑

l−1

i=0

a

i

2

i

.

MULT A protocol that on input [a] and [b] produces

[a ∗ b].

BITS A protocol that on input [a] and l, produces en-

cryption of at least l least signiﬁcant bits of the

underlying plaintext of [a], i.e. [a]

lB

.

BIT-LE A protocol that, given [a

1

]

lB

and [a

2

]

lB

out-

puts an encrypted bit [b], where b = 1 if a

1

≤ a

2

.

COMP A protocol that takes two encrypted inputs

[a] and [b] and generates [1] if a > b, and [0] oth-

erwise.

The way in which these building blocks function is as

follows.

3.2.1 MULT

Secure multiplication is a well-researched problem

with a large number of available solutions. Since

multiplication of the underlying values using only en-

crypted values is impossible in the Paillier cryptosys-

tem, one of the values to be multiplied has to be de-

crypted, and consequently an exponentiation can be

done to obtain the product of the two encrypted val-

ues. The MULT building block in this instance starts

additive sharing, where an encrypted value is addi-

tively split among a number of server. Given input [a]

and [b] where the product [a · b] is desired. We choose

to additively split the value [b] among n servers. Each

server i for i = 1,....n − 1 chooses a random number

r

i

∈ Z

N

, encrypts and broadcasts this encryption [r

i

] .

Each server now possesses [b], [r

1

],.... [r

n−1

] and lo-

cally computes [b

0

] = [b−

∑

n−1

i=1

[r

i

] = [b]

∏

∑

n−1

i=1

r

i

]

−1

.

Then all participants (or at least t) jointly decrypt

[b

0

] for party n using threshold decryption as for ex-

ample in (Damg

˚

ard and Jurik, 2001). Note that ev-

ery server now has a share, of which the sum is

b

0

+ r

1

+ .... + r

n

= b. Each server can then use the

homomorphic property of the encryption scheme to

compute [a]

b

i

= [a · b

i

], after which all the servers as-

semble their values to obtain [a · (b

0

+ r

1

+ ... + r

n

)] =

[a · b],

3.2.2 BITS

Schoenmakers et al. (Schoenmakers and Tuyls, 2006)

describe gates to produce an encryption of the l least

signiﬁcant bits of the underlying plaintext of [a].

Three different gates are described: LSB, LSBs, and

BITREP. LSB only encrypts the least signiﬁcant bit,

LSBs a number l of least signiﬁcant bits and BITREP

the entire binary number. Since we require the l least

signiﬁcant bits of [a], we use the LSBs gate which

SECRYPT 2018 - International Conference on Security and Cryptography

190

produces these on input [a]. To do so, the n par-

ties should ﬁrst jointly generate l random bits and

encrypt these to jointly obtain the bits [r

0

],...,[r

l−1

].

Next, all parties generate their own random num-

ber r

∗,i

∈

R

{0,...,2

l+κ−1

− 1} and broadcast it so that

r

∗

=

∑

n

i=1

r

∗,i

can be publicly computed. Here κ is

a security parameter which when increased leads to

better security but more computation time.

The value y is then computed in the following

manner:

y = a −

l−1

∑

j=0

r

j

2

j

+

n

∑

i=1

r

∗,i

· 2

l

mod n (1)

Note that the values of r are encrypted, so this re-

sults in these actual computations:

[y] = [a] ∗

l−1

∏

j=0

[r

j

]

2

j

∗

n

∏

i=1

[r

∗,i

]

2

l

−1

mod n

2

(2)

Now y is jointly decrypted using the thresh-

old scheme and converted to its binary notation

y

0

,...,y

l−1

. Since a = y+r, if both y and r were avail-

able in plaintext a would be trivial to obtain using an

addition circuit:

a

i

= y

i

+ r

i

+ c

i−1

− 2c

i

c

i

= y

i

r

i

+ y

i

c

i−1

+ r

i

c

i−1

− 2y

i

r

i

c

i−1

, c

−1

= 0

(3)

Where 0 ≤ i ≤ l −1 and c is the so-called ’carry’

bit used for intermediate computation. However, de-

crypting r is not an option since that would reveal the

plaintext value of a and remove the point of this en-

tire building block. Instead, this addition circuit can

be implemented in the encrypted domain as follows:

If y

i

= 0:

[a

i

] = [r

i

] · [c

i−1

] · ([c

i

]

2

)

−1

[c

i

] = MULT ([r

i

],[c

i−1

]), c

−1

= 0

(4)

If y

i

= 1:

[a

i

] = [y

i

] · [r

i

] · [c

i−1

] · ([c

i

]

2

)

−1

[c

i

] = [r

i

] · [c

i−1

] · MULT ([r

i

],[c

i−1

])

−1

, c

−1

= 0

(5)

Notice that ﬁrst, since y

i

can take the value of ei-

ther 0 or 1, and unfortunately the number 0 is not

in mod n, we have to make different cases for y = 0

and y = 1 (this does save computation time though).

Next, we are dealing with a multiplication of two en-

crypted numbers, where we use the previously in-

troduced MULT block. Finally, note that the [...]

−1

stands for a modulo inverse operation. The output of

the protocol now is l encrypted output bits [a

i

] (the ﬁ-

nal carry bit is ignored, hence computing modulo 2

m

),

which is the desired output.

3.2.3 BIT-LE

Bunn and Ostrovsky (Bunn and Ostrovsky, 2007) de-

scribe a protocol to ﬁnd the minimum of two numbers.

The existing realization builds upon this protocol in

the encrypted domain by making use of additive ho-

momorphism. Let X = c

1

c

2

...c

M

and Y = d

1

d

2

...d

m

(so that c

1

and d

1

are the MSBs). This building block

returns an output of L = 0 if X ≤ Y and L = 1 if X > Y :

L = (c

1

⊕ d

1

)c

1

+ (c

1

⊕ d

1

⊕ 1)(c

2

⊕ d

2

)c

2

+(c

1

⊕ d

1

⊕ 1)(c

2

⊕ d

2

⊕ 1)(c

3

⊕ d

3

)c

3

+ ...+

+(c

1

⊕ d

1

⊕ 1)...(c

M−1

⊕ d

M−1

⊕ 1)(c

M

⊕ d

M

)c

M

(6)

Where ⊕ signiﬁes an XOR operation which can

be rewritten to:

c ⊕ d = c + d − 2cd (7)

Since all input bits are delivered in the encrypted do-

main, an encrypted XOR can be computed in the fol-

lowing manner:

[c] ⊕ [d] = [c] ⊕ [d] ⊕ (MULT ([c],[d])

2

)

−1

(8)

Rewriting the entire building block in this manner

then gives an encrypted bit [L] as an output where

L = 1 if X > Y . Since we want L = 1 if X ≤ Y , we

simply swap the inputs in out protocol to obtain our

desired value.

3.3 Framework

It is important to choose a base framework, containing

the essential structure of a system and is a good guide-

line for deﬁning one. In light of a fair comparison of

efﬁciency with Hoens et al. (Hoens et al., 2013) the

same framework is used, based on several functional,

privacy and reliability requirements. These require-

ments exist to maintain both the privacy of the patient

and the integrity of the system.

3.3.1 Functional Requirements

A suitable framework allows patients to rate their

physicians according to the patients’ satisfaction. Pa-

tients i can submit a rating for a physician j concern-

ing health condition k. This rating, denoted as r

i jk

,

is selected from a pre-deﬁned range [1,n], where 1 is

the lowest score and n the highest. The submission

of these ratings by a multitude of patients leads to the

physician receiving an aggregate score relating to a

certain health condition denoted by s

jk

. It is computed

by any function of the sum of individual ratings and

An Efﬁcient Privacy-preserving Recommender System for e-Healthcare Systems

191

the number of patients who have submitted a rating

w

jk

, e.g., r

jk

/w

jk

.

Additionally, the framework should allow the ex-

istence of this score to be available for new patients,

enabling them to ﬁnd a physician relating to their

health condition. It should also allow a patient to ﬁnd

a physician for a combination of conditions.

3.3.2 Privacy and Reliability Requirements

As previously discussed, a vital aspect of a recom-

mender system in the medical domain should be its

privacy. Both the inquiries a patient makes and the

existing data of the RS should be inaccessible to

the public, and even when somehow partially leaked

should not be traceable to a patient. Another essential

property of an RS framework is that it should be re-

liable. Patients should be able to get honest ratings,

which cannot be manipulated by parties like small

groups of unreasonable users or dishonest competi-

tors. This effect should be either prevented or de-

tected and compensated for.

3.4 Architecture

The next step in constructing an RS is to ensure all the

requirements of the framework are met by construct-

ing a suitable architecture. Hoens et al. (Hoens et al.,

2013) propose an architecture called SPA (Secure

Processing Architecture), which we use and elabo-

rate on in this section. In this architecture data is al-

ready encrypted at the patient’s side before sending,

suggesting the computation of all recommendations

is performed over encrypted data.

3.4.1 Computing Recommendations

Each computational server maintains the encrypted

sum of all the ratings for a certain physician j and

health condition k, [r

jk

], and the encrypted total num-

ber of submitted ratings for those also called the

weight [w

jk

]. When a patient submits a new rating

[r

i jk

], she includes a weight [w

i jk

], being equal to 1

for health conditions the patient wants to submit a rat-

ing for and 0 for all others. The sum of ratings is

then updated as [r

jk

]∗ [r

i jk

] = r

jk

+r

i jk

and the weight

[w

jk

] ∗ [w

i jk

] = w

jk

+ w

i jk

by utilizing the property of

the Paillier cryptosystem (Section 3.1.1).

A straightforward way to compute the physicians’

scores s

jk

is used: dividing r

jk

by w

jk

, thereby com-

puting the average rating. How this division is done

in the encrypted domain using the properties of the

homomorphic cryptosystem is explained in Section

3.4.3.

3.4.2 Bonus Factor

It might be beneﬁcial to add a factor to let experienced

physicians with a large number of patients have some

advantage compared to physicians who have treated

a small number of patients for a certain health condi-

tion k. For this reason a bonus factor b

jk

is proposed,

so that s

jk

= r

jk

/w

jk

+ b

jk

. Here r

jk

/w

jk

∈ [1, n] and

b

jk

∈ [1,m], for a n and m free of choice. To determine

b

jk

, we check how many patients w

jk

a certain physi-

cian j has treated concerning health condition k, com-

pare this w

jk

with certain bucket values (t

1

,t

2

,...,t

q

),

and assign a factor (b

1

,b

2

,...,b

q

) accordingly, i.e. for

i = 1,2,....,q we set b

jk

= b

i

if the value of w

jk

is be-

tween thresholds t

i

and t

i+1

. The values of t

i

and b

i

are picked beforehand as desired, with the constraint

that they are increasing and b

i

≤ m.

For example, we can choose n = 10, m = 5,

b = (1,2, 3,4, 5) and q = (0,3,5, 10,20). The sys-

tem allows a patient to give ratings in the range of

[1,10], giving a bonus b

jk

of 1 to physicians j who

have treated more than 0 patients concerning a cer-

tain health condition k, a bonus of 2 when they have

treated more than three patients, etcetera. Using a

non-linear scale like this ensures physicians can’t be

the top recommended ones after having been rated

just once or twice but also doesn’t give a too unfair

advantage over a physician who has treated for exam-

ple 12 patients versus a physician who has treated 31

patients (just one point).

3.4.3 Comparing Scores

Computing two scores can then be done by computing

the following for two different physicians:

s

j

1

k

= r

j

1

k

/w

j

1

k

+ b

j

1

k

vs s

j

2

k

= r

j

2

k

/w

j

2

k

+ b

j

2

k

(9)

Since a division over the plaintext like this is im-

possible without decryption, s

jk

is instead stored as

a numerator-denominator pair ([s

0

jk

],[w

jk

]) = ([r

jk

+

b

jk

w

jk

],[w

jk

]). This allows us to compare two physi-

cians j

1

and j

2

by comparing s

0

j

1

k

w

j

2

k

to s

0

j

2

k

w

j

1

k

, de-

livering the same results as one would get by compar-

ing the two scores in 9.

A technical difﬁculty arising with this is that the

comparison might be incorrect if a physician j has no

ratings. That is, both w

j

k

and s

0

j

k

will be 0. To ensure

the result is always correct, a ﬂag f

jk

is added which

indicates whether w

jk

is non-zero. The comparison

will then be between s

0

j

1

k

w

j

2

k

+ non-zero(w

j

1

k

) and

s

0

j

2

k

w

j

1

k

+ non-zero (w

j

2

k

) (note that this still always

delivers a correct comparison). To compute this non-

zero property we use an OR-function over the en-

SECRYPT 2018 - International Conference on Security and Cryptography

192

crypted bits, which is realized by a number of secure

additions and a bitwise comparison and gives an en-

crypted bit as an output (the output is one if the OR

over the plaintext bits is 1).

3.4.4 Privacy Requirements

The public-key cryptosystem Paillier is used, where it

is assumed that the public key necessary for data en-

cryption is known to all parties. However, in this case,

we choose to make the private key unavailable to any

single entity; accordingly a decryption can only be

done using threshold decryption as mentioned in Sec-

tion 3.1.3. This concept is relied on to let a number of

computational servers collect data from patients and

jointly compute recommendations. The earlier de-

ﬁned privacy requirement stated that when part of the

data was leaked, it should not in any way reveal infor-

mation regarding a patient. To comply to this require-

ment, the computational servers should be maintained

by mutually distrustful parties, such that any t of them

are unlikely to conspire. It is essential that in no way

any party ﬁnds out anything about the patient. Even

if a patient encrypts the data before sending it if she

only sends a rating for a particular physician j and

health condition k it is quite apparent to learn what

kind of condition the patient has. The easiest way to

hide the actual information sent is to let the patient

submit weights for not just one but every physician

j and condition k. In that case, only one (or possi-

bly more if the patient was treated more) submitted

rating has the actual rating and carries a weight of 1,

while the other submitted values will have a rating

and weight 0. The servers are then able to compute

the scores or recommendations for all physicians and

conditions without learning anything about which rat-

ing the patient wanted to send.

Note that the computational servers can’t just re-

veal the scores s

jk

: given these scores, when a patient

would then submit a rating and a weight for a spe-

ciﬁc physician j and condition k, it would be trivial

to ﬁnd out what value and for which condition and

physician this patient submitted a rating. While de-

signing a speciﬁc system, it is important to realize

that there is a continuous trade-off between high pri-

vacy and low computational overhead. For example, a

consideration would be to do reveal the scores s

jk

but

only periodically update them, having the beneﬁt of a

patient being instantly able to see which physician is

recommended for which condition and therefore sav-

ing both the hassle of communication and computing.

However, in doing this, with low volumes of recom-

mendations, a malicious server might be able to deci-

pher what an individual patient submitted. Depending

on the size of the user base, this might become an at-

tractive option, but for now, we choose not to reveal

the scores.

4 PRIVACY-PRESERVING

RECOMMENDER SYSTEM

Where the previous section contained an explanation

of the existing protocol, in this section, we propose

an improved version of this protocol. Since the most

time-consuming steps of the protocol are the building

blocks, for our proposal we started by looking care-

fully at these building blocks, and for possible ways

how to improve them.

Inspecting the performance (elaborately done later

in 6) shows us that the runtime of the current proto-

col is dominated by the execution time of the BITS

and BIT-LE building blocks. The function of these

building blocks is to convert an encrypted number to

an encrypted bitwise representation and do a compar-

ison over these encrypted bits respectively.

The combined goal of these two building blocks

is to ﬁnd out if a > b for given a and b without dis-

closing them, which is a common multi-party com-

putation problem known as a secure comparison. In

addition to it being the ﬁrst multi-party (two-party)

computation problem to be ever considered (By Yao

et al. (Yao, 1982) under the name of the millionaire’s

problem), it is a fundamental primitive in a consid-

erable amount of applications. The setting for most

applications is that neither the inputs nor the output

are revealed to any of the parties, which is also the

setting of this application.

We use the state-of-the-art two-party comparison

protocol by Nateghizad et al. (Nateghizad et al.,

2016) to construct a multi-party comparison protocol

for use in the current application. Since this proto-

col takes two encrypted bits as an input and returns

an encrypted bit with the comparison result as an out-

put, it does the same as the two combined building

blocks. We, therefore, denote this improved secure

comparison as a building block COMP and proceed

by explaining it.

4.1 Improved Protocol

Using the new building block COMP, the improved

protocol can be realized. Besides the different build-

ing block, we perform the protocol in the same way

except for one detail. Recall a non-zero ﬂag f

jk

was

used to make sure the comparisons are not between

zero’s. We choose to initialize w

jk

to 1, making it so

that this value will never be zero (and raise the thresh-

olds accordingly). As a result, comparing two physi-

An Efﬁcient Privacy-preserving Recommender System for e-Healthcare Systems

193

cians while one has no ratings will still be no problem

at all.

We are now ready to present an improved version

of the protocol.

1. The computational server compute for every

physician j in parallel:

(a) set [c

1

] = [1] and execute [c

i

] ←

COMP([t

i

],[w

jk

]) for i = 2, ...,q.

(b) locally compute [b

jk

] = [

∑

m

i=1

c

i

δ

i

] =

∏

m

i=1

[c

i

]

δ

i

(c) execute [d] ← MULT ([b

jk

],[w

jk

]) and locally

set [s

0

jk

] = [r

jk

+ d] = [s

jk

] · [d].

2. The servers sort all tuples ([s

0

jk

],[w

jk

],[ f

jk

]) for

all physicians j using a suitable sorting algo-

rithm and output the result, where each com-

parison is performed on ([s

0

xk

],[w

xk

],[ f

xk

]) and

([s

0

yk

],[w

yk

],[ f

yk

]) as follows:

(a) execute [v

x

] ← MULT([s

0

xk

],[w

yk

]) and [v

y

] ←

MULT ([s

0

yk

],[w

xk

])

(b) locally compute [v

0

x

] = [v

x

]·[ f

xk

] = [v

x

+ f

xk

] and

[v

0

y

] = [v

y

] · [ f

yk

] = [v

y

+ f

yk

]

(c) execute [z] ← COMP([v

x

],[v

y

]) and open the

value of z.

5 SECURITY ANALYSIS

In this section, we provide proof to show that health-

care recommender system (HCRS) is simulation se-

cure in the semi-honest security model. We use the

simulatability paradigm (Lindell, 2017) in our proofs,

where security is deﬁned as a comparison of compu-

tation work-ﬂow in “real world” and “ideal world”.

In real world, each party in the protocol executes

its part of the computation. Let us denote π as the

health-care recommender system; we can split π into

two parts: π = π

CS

and π

KM

, CS refers to the compu-

tation server and KM is the key manager. Assuming

CS is corrupted by an adversary A, then A has access

to its inputs, and the given messages from KM. Simi-

larly, when KM is corrupted, the adversary has access

to the intermediate computation results.

In an ideal world, it is assumed that the corrupted

party uses a simulator to generate the outputs of the

other parties. This setting is similar to the condition,

where all the computations are performed with only

one corrupted party. In an ideal world, an adversary

´

A has only access to the inputs of the corrupted party

and the randomly generated outputs from the simula-

tors. The goal is to show that A can learn equal or

negligibly more than

´

A, meaning that they are com-

putationally indistinguishable, then we can claim that

HCRS is a simulation secure protocol.

Deﬁnition 5.1. Let a ∈ {0,1}

∗

represents the parties’

inputs, n ∈ N to be a security parameter, and X =

{X(a,n)}

a∈{0,1}

∗

;n∈N

and Y = {Y (a, n)}

a∈{0,1}

∗

;n∈N

,

two inﬁnite sequences of random variables, are prob-

ability ensembles. Then, X and Y are computation-

ally indistinguishable, denoted as X

c

≡ Y , if there is

a polynomial p(.) for every non-uniform polynomial-

time probabilistic algorithm (nuPPT) D such that:

|Pr[D(X (a, n)) = 1] − Pr[D(Y (a,n)) = 1]| < 1/p(n)

(10)

5.1 Security of HCRS

The inputs of CS for generating recommendations is

[r

jK

], [w

jk

], [t

i

], [b

i

], and δ

i

, where j and k refer to the

physician and condition, respectively. Note that KM

has no private input that is denoted by φ. To show that

the process of generating recommendation is simula-

tion secure, we need to prove that parties are unable to

infer any private information about the patient’s pref-

erence and physicians private data.

Let denote the computation of c

i

as (CS ◦ KM)

f

1

,

b

jk

as CS

f

1

, d as (CS ◦ KM)

f

2

, and ´s

jk

as CS

f

2

,

◦ refers to multi-party computation. Let f =

((CS ◦ KM)

f

,CS

f

), where (CS ◦ KM)

f

= ((CS ◦

KM)

f

1

,(CS ◦ KM)

f

2

) and CS

f

= (CS

f

1

,CS

f

2

), and

f to be the functionality that computes the health-

care recommendation. The view of the i

th

party

i ∈ {CS,KM} for generating recommendation on

([r

jK

],[w

jk

],[t

i

],[b

i

];φ; n) = (w,r

i

;m

i

1

,··· , m

i

z

), where

w ∈ {[r

jK

],[w

jk

],[t

i

],[b

i

],φ} based on the value of i,

r

i

are the i

th

party internal random numbers, and

m

i

z

represents the z

th

message that is received by

i

th

party. out put

HCRS

i

([r

jK

],[w

jk

],[t

i

],[b

i

];φ; n) repre-

sents the output of each party in HCRS. To represent

the joint output of both parties, we denote

out put

HCRS

= (out put

HCRS

1

([r

jK

],[w

jk

],[t

i

],[b

i

];φ; n),

out put

HCRS

2

([r

jK

],[w

jk

],[t

i

],[b

i

];φ; n)).

(11)

Deﬁnition 5.2. HCRS securely computes f =

(CS

f

,KM

f

) in the semi-honest security setting if there

exits PPT algorithms Sim

CA

and Sim

KM

such that:

{(Sim

CS

(1

n

,[r

jK

],[w

jk

],[t

i

],[b

i

],CS

f

, f ))}

c

≡ {(view

f

CS

([r

jK

],[w

jk

],[t

i

],[b

i

];φ; n),

out put

f

([r

jK

],[w

jk

],[t

i

],[b

i

];φ; n))}

(12)

and

{(Sim

KM

(1

n

,φ,KM

f

, f ))}

c

≡

{(view

f

KM

([r

jK

],[w

jk

],[t

i

],[b

i

];φ; n),

out put

f

([r

jK

],[w

jk

],[t

i

],[b

i

];φ; n))}

(13)

SECRYPT 2018 - International Conference on Security and Cryptography

194

Theorem 1. HCRS securely computes the function-

ality f , when CS is corrupted by adversary A in the

presence of semi-honest adversaries.

Proof. We need to show that A cannot computation-

ally distinguish between the random generated out-

puts of S

2

and truly generated ones from KM. CS

receives outputs from KM in performing the opera-

tions COMP and MULT . By using S

2

instead of KM,

CS receives encryption of randomly generated values;

however, because A has not access to the private key

and a semantically secure encryption scheme is used

in the protocol, A is unable to distinguish between

garbage outputs from S

2

and real generated outputs

from KM. Therefore, we can claim that HCRS is

simulation secure when CS is corrupted if the used

building-blocks in HCRS, COMP (Nateghizad et al.,

2016) and MULT (Nateghizad et al., 2016), are se-

cure (Canetti, 2001).

Theorem 2. HCRS securely computes the function-

ality f , when KM is corrupted by adversary A in the

presence of semi-honest adversaries.

Proof. Unlike the CS, KM has access to the private

key and can decrypt the outputs of the CS. Thus, we

need to show the A cannot infer any private informa-

tion about the encrypted inputs of CS during the pro-

cess of generating recommendation. Given S

1

as the

simulator of CS and security parameter 1

n

, KM works

for every physician j as follows:

1. S

1

generates q − 1 pair of random numbers ˆr

i

and

´r

i

, and run the (CS ◦ KM)

f

1

for i ∈ {2,· ·· ,q}.

2. S

1

generates two random numbers r

1

and r

2

, then

performs (CS ◦ KM)

f

2

.

The only collaboration between two parties CS and

KM happen for the computation of [c

i

] and [d], and

the rest of the operations are performed locally in CS.

Therefore, if A cannot learn any private information

by performing (CS ◦ KM)

f

1

and (CS ◦ KM)

f

2

, then

HCRS is simulation secure when KM is corrupted.

The security proof of COMP and MULT are already

provided in (Nateghizad et al., 2016) and (Canetti,

2001), respectively. Thus,

{(Sim

KM

(1

n

,φ,KM

f

, f ))}

c

≡

{(view

f

KM

([r

jK

],[w

jk

],[t

i

],[b

i

];φ; n),

out put

f

([r

jK

],[w

jk

],[t

i

],[b

i

];φ; n))}

(14)

6 COMPUTATIONAL

COMPLEXITY

Clearly, the protocol we propose has less steps than

the original protocol proposed by Hoens et al (Hoens

et al., 2013). However, we still need to conﬁrm that

the protocol is actually more efﬁcient. We do this by

checking the exact computational complexity for both

protocols. We do this in terms of computational oper-

ations, and summarize the results in a table.

6.1 Building Blocks

The computational complexity formalizes a difﬁcult

problem by quantifying the amount of resources

needed to solve it. Usually a rough approximation

like the ”big O” notation is used, but we choose

to compute the exact computational complexity by

checking the exact number of computations done.

A computation on a plaintext value is incredibly

cheap in comparison to an operation on an encrypted

value. For instance, a simple operation as 2

3

in the

plaintext domain is very easy to compute whereas [2]

3

involves possibly taking the third power of a 1024-bit

number when using a relatively small 1024-bit Pail-

lier key. Since operations on encrypted values heav-

ily dominate the runtime only these are listed for the

computational complexity. Since we are using addi-

tive homomorphism, in this case in the form of the

Paillier cryptosystem, these operations can be split up

in two general categories:

• A multiplication of encrypted values [a] · [b], re-

sulting in an addition of the underlying plaintext

values a + b.

• An exponentiation of an encrypted value by a

plaintext value [a]

b

, resulting in a multiplication

of the underlying plaintext values a · b.

A multiplication of encrypted values always takes

around the same amount of time, since the encrypted

numbers are of the same order of size. However, an

exponentiation of encrypted values can vary greatly:

[2]

2

is much easier to compute than [2]

1024

. We ac-

cordingly use slightly different notations for the two

of these: 1 exponentiation for the former and 1

1024

exponentiation for the latter.

The computational complexity of the protocol for

both the existing and the proposed protocol are dom-

inated by the building blocks. Hence, we express the

computational complexity of all these building blocks

and use this as a measure to check the improved ef-

ﬁciency. Recall that n is the amount of servers, l the

length of the greatest number in bits and t out of n

An Efﬁcient Privacy-preserving Recommender System for e-Healthcare Systems

195

servers are needed to perform the threshold decryp-

tion.

6.1.1 MULT

We start by computing [b]

∏

∑

n−1

i=1

[r

i

]

−1

, which is

equal to n − 1 multiplications. Then, the threshold

decryption scheme is ran, which has 2t − 1 exponen-

tiations on encrypted numbers. Finally each server

has to ompute an exponent [a]

b

i

, resulting in n expo-

nentiations.

The MULT scheme therefore has in total n − 1

multiplications and n + 2t − 1 exponentiations.

6.1.2 BITS

We start by looking at computing the value of y. 2

shows us l − 1 multiplications from the ﬁrst prod-

uct and n − 1 multiplications from the second prod-

uct, with one multiplication between these two for

l +n − 1 multiplications. Next are the exp operations.

A number of l exponentiations are done in the ﬁrst

summation, one in the second summation, and one

over the total product in the brackets for a total of

l + 2 exp operations. Finally one ﬁnal multiplication

is done to compute y. Next is the addition circuit, as

shown in equations 4 and 5. Since y

i

can take the val-

ues of both 0 and 1 and the computation varies for

both situations, the complexity differs:

y

i

= 0 : Two multiplications, one exp(−1), one

exp(2) and one MULT.

y

i

= 1 : Five multiplications, one exp(−1), one

exp(2) and one MULT.

Therefore we take the average of these two situa-

tions as the complexity, being 3.5 multiplications, one

exp(−1), one exp(2) and one MULT. This results in

a total of l + n + 3.5 multiplications, l

2

1

,...,2

l

+ 1

2

l

+ 3

exponentiations and one MULT for the entire BITS

building block.

6.1.3 BIT-LE

Since the complexity of the BIT-LE building block

varies heavily depending on the number of bits and is

not easily readable, we compute the complexity for a

few cases and deduce the actual complexity by check-

ing the pattern.

Therefore we can conlude that for BIT-LE the

complexity of multiplications increases with (3l −

1)n, whereas the complexity of exponentiations in-

creases with (3l − 1)n

w

i

+ (2l − 1)

−1

.

6.1.4 COMP

Alice starts by doing 3 multiplications and 1 exponen-

tiation.

Bob performs a threshold decryption. Next to

this he only performs operations on plaintext and en-

crypts, so this is not very computationally intensive.

Hereafter Alice does l multiplications and l expo-

nentiations. Bob continues by doing l threshold de-

cryptions. Finally, Alice computes the result using

three multiplications and two exponentiations.

In total, this comes down to l + 6 multiplications,

l +3 exponentiations and l + 1 threshold decryptions.

6.2 Total Computational Complexity

Summarizing the previously found results leads to

the total computational complexity for each building

block as shown in 2.

Table 2: Computational complexity for the building blocks

used in both protocols, where the MULT building block is

shown as an operation.

[a + b] exp

MULT n − 1 n

BITS l + n + 3.5 l

2

1

,...2

l

+ 1

2

l

+ 3

BIT-LE 3l − 1 2l − 1

COMP 6 + l l + 3

Since the number of operations required for the

MULT and threshold decryption d

t

operations is

known, we can further reduce our table. The amount

of operations for a threshold decryptions are 2t − 1

exponentiations. By doing this and working out the

products we obtain 3.

Table 3: Computational complexity for the building blocks

of the protocol introduced in (Hoens et al., 2013).

[a + b] exp

MULT n − 1 n + 2t − 1

BITS l + 2n + 2.5 l

2

1

,...2

l

+ 1

2

l

+ 2 + n + 2t

BIT-LE 3ln − n 6lt + 3ln − 3l − n + 1

COMP 6 + l 2lt + 2t + 2

From this we can clearly see the difference in

complexity and the signiﬁcant improvement made by

the new protocol. Especially for large numbers l, note

that the complexity of exponentiations of BITS and

BIT-LE increase a lot in comparison to the complex-

ity of COMP. This is logical, because BITS has to

output a great number of bits and BIT-LE will have to

perform a comparison on each of these.

SECRYPT 2018 - International Conference on Security and Cryptography

196

The notion that the new protocol is faster is fur-

ther conﬁrmed by the implementation results in the

following section.

7 IMPLEMENTATION

For the sake of analyzing the performance, the exist-

ing and improved realizations were implemented us-

ing Java using Paillier encryption with a 1024-bit key.

Java was chosen to both follow suit with the exist-

ing implementation and due to its ease of implement-

ing distributed algorithms. First, the old protocol was

implemented, consisting of the three building blocks

MULT, BITS and BIT-LE, the paillier and threshold

decryption scheme, some other small functions like

OR and XOR and of course the main protocol for exe-

cution. After this the new protocol was implemented,

which basically changes the BITS and BIT-LE build-

ing blocks to one COMP building block.Because we

were mainly interested in the computational complex-

ity involved we tested the protocol on one desktop,

having an Intel Core i7-7700 HQ CPU with 2.80 GHz

and 4 cores and a total of 16 GB of memory (RAM).

To make the tests more general and since the main

focus of this work is to show the improved compu-

tational performance of the building blocks only step

1 of the protocol was implemented. Note that the ta-

ble with execution times shown in Hoens et al (Hoens

et al., 2013) also only mention a table with the execu-

tion times of step 1.

The three values that mostly impact the perfor-

mance are 1)Amount of physicians j, 2) Amount of

bucket thresholds t

i

, and 3) Bit length of the thresh-

olds l.

In order to vary these three metrics, various sce-

narios of thresholds which might be applicable to

practice were devised, enabling an overview in which

the time can be seen by putting the number of physi-

cians against several scenarios:

1. (0,1,3) - bit length = 2

2. (0,3,5, 10,20) - bit length = 5

3. (10,50,100, 500,1000) - bit length = 10

4. (1000,5000,10000, 50000,100000) - bit length =

20

5. (0,10,50, 100,500, 1000,5000, 10000,50000

100000) - bit length = 20

The number of servers n was chosen to be 5, of

which 3 are required to do threshold decryption. The

results of the existing implementation are presented in

4, whereas the results of the proposed implementation

are found in 5. In both tables, the execution time of

Table 4: Execution times (seconds) for step 1 of the protocol

using the the existing realization. No.P refers to the number

of physicians.

No.P

Thresholds scenario used

s

1

s

2

s

3

s

4

s

5

5 141 505 1186 2337 4029

10 281 1010 2290 4985 7970

20 532 2134 4638 9650 16394

50 1284 5005 10970 26384 40772

Table 5: Execution times (seconds) for step 1 of the protocol

using the the proposed realization.

No.P

Thresholds scenario used

s

1

s

2

s

3

s

4

s

5

5 26 72 120 222 396

10 52 134 245 455 775

20 101 270 504 933 1527

50 251 716 1208 1938 4013

step 1 of the protocol is shown, where the number of

physicians is presented vertically, and the threshold

scenario is used horizontally.

To give the reader a graphical overview, the exe-

cution times for scenario 2 and scenario 5 have been

plotted in Figure 1 and Figure 2 respectively.

10 20 30 40

50

0

1,000

2,000

3,000

4,000

5,000

Number of physicians

Execution time (s)

Existing realization

Proposed realization

Figure 1: Timing results of scenario 2 for the existing and

proposed realization.

The proposed realization is much faster. For sce-

nario 1, a speedup of approximately 81,5% is already

achieved, while for scenario ﬁve a speedup of approx-

imately 90% is achieved. This relative difference in

speedups can be explained by the fact that the com-

plexity of the old building blocks is much more de-

pendent on the bit length l in comparison to the new

building block. The execution time of the proposed

implementation is dominated mostly by the use of

threshold decryptions; therefore, this time could be

even further reduced by employing a technique called

data packing. Essentially, the main idea of this is to

An Efﬁcient Privacy-preserving Recommender System for e-Healthcare Systems

197

10 20 30 40

50

0

1

2

3

4

·10

4

Number of physicians

Execution time (s)

Existing realization

Proposed realization

Figure 2: Timing results of scenario 5 for the existing and

proposed realization.

use the message space of the Paillier cryptosystem

that is much larger than the values to be compared,

so that multiple values can be stored in one encrypted

variable.

8 CONCLUSION

This work presents a reliable medical privacy pre-

serving recommender system, building on an exist-

ing framework by Hoens et al. (Hoens et al., 2013).

Since medical information is considered private in-

formation, an architecture is provided satisfying the

requirements of this framework, relying on secure

(encrypted) data and secure multi-party techniques to

perform operations on this data. Unfortunately, the

secure architecture of the existing realization is com-

putationally expensive, hindering the deployment of

the protocol in practice. In this paper, we investigated

the performance of the existing realization and signif-

icantly improved upon this by changing several parts

of the protocol without laying a hand on the underly-

ing framework or architecture. Especially the propo-

sition of a protocol executing secure comparison de-

livered a signiﬁcant speedup. More precisely, the run-

time of the existing protocol is reduced by 81,5% for

small bit-lengths, and it is reduced even further for

larger bit lengths. This improvement leads to a more

efﬁcient and practical reliable medical privacy pre-

serving recommender system.

ACKNOWLEDGMENTS

We would like to thank T. R. Hoens and M. Blanton

for their help in understanding their ideas and provid-

ing the implementation of their work.

REFERENCES

Agrawal, R. and Srikant, R. (2000). Privacy-preserving data

mining. In Proceedings of the 2000 ACM SIGMOD

International Conference on Management of Data,

May 16-18, 2000, Dallas, Texas, USA., pages 439–

450.

Alem

´

an, J. L. F., Se

˜

nor, I. C., Lozoya, P.

´

A. O., and Toval,

A. (2013). Security and privacy in electronic health

records: A systematic literature review. Journal of

Biomedical Informatics, 46(3):541–562.

Baroody, A. J. and Hansen, S. W. (2012). Changing per-

spectives: Institutional logics of adoption and use

of health information technology. In Proceedings of

the International Conference on Information Systems,

ICIS 2012, Orlando, Florida, USA, December 16-19,

2012.

Bunn, P. and Ostrovsky, R. (2007). Secure two-party k-

means clustering. In Proceedings of the 14th ACM

conference on Computer and communications secu-

rity, pages 486–497. ACM.

Canetti, R. (2001). Universally composable security: A

new paradigm for cryptographic protocols. In 42nd

Annual Symposium on Foundations of Computer Sci-

ence, FOCS 2001, 14-17 October 2001, Las Vegas,

Nevada, USA, pages 136–145.

Canny, J. F. (2002). Collaborative ﬁltering with privacy.

In 2002 IEEE Symposium on Security and Privacy,

Berkeley, California, USA, May 12-15, 2002, pages

45–57.

Chhanabhai, P. and Holt, A. (2007). Consumers are ready

to accept the transition to online and electronic records

if they can be assured of the security measures. Med-

scape General Medicine, 9(1):8.

Ciss

´

ee, R. and Albayrak, S. (2007). An agent-based ap-

proach for privacy-preserving recommender systems.

In 6th International Joint Conference on Autonomous

Agents and Multiagent Systems (AAMAS 2007), Hon-

olulu, Hawaii, USA, May 14-18, 2007, page 182.

Damg

˚

ard, I. and Jurik, M. (2001). A generalisation, a sim-

pliﬁcation and some applications of paillier’s proba-

bilistic public-key system. In Public Key Cryptogra-

phy, 4th International Workshop on Practice and The-

ory in Public Key Cryptography, PKC 2001, Cheju

Island, Korea, February 13-15, 2001, Proceedings,

pages 119–136.

Dwork, C. (2007). An ad omnia approach to deﬁning and

achieving private data analysis. In Privacy, Security,

and Trust in KDD, First ACM SIGKDD International

Workshop, PinKDD 2007, San Jose, CA, USA, August

12, 2007, Revised Selected Papers, pages 1–13.

Erkin, Z., Beye, M., Veugen, T., and Lagendijk, R. L.

(2011). Efﬁciently computing private recommenda-

tions. In Proceedings of the IEEE International Con-

ference on Acoustics, Speech, and Signal Processing,

SECRYPT 2018 - International Conference on Security and Cryptography

198

ICASSP 2011, May 22-27, 2011, Prague Congress

Center, Prague, Czech Republic, pages 5864–5867.

Erkin, Z., Veugen, T., Toft, T., and Lagendijk, R. L.

(2012). Generating private recommendations efﬁ-

ciently using homomorphic encryption and data pack-

ing. IEEE Trans. Information Forensics and Security,

7(3):1053–1066.

Fiza, A. R., Lizawati, S., Zuraini, I., and Narayana, S. G.

(2016). Safety and privacy issues of electronic med-

ical records. Indian Journal of Science and Technol-

ogy, 9(42).

Gavgani, V. Z. (2010). Health information need and seek-

ing behavior of patients in developing countries’ con-

text; an iranian experience. In ACM International

Health Informatics Symposium, IHI 2010, Arlington,

VA, USA, November 11 - 12, 2010, Proceedings, pages

575–579.

Hoens, T. R., Blanton, M., Steele, A., and Chawla, N. V.

(2013). Reliable medical recommendation systems

with patient privacy. ACM TIST, 4(4):67:1–67:31.

Katzenbeisser, S. and Petkovic, M. (2008). Privacy-

preserving recommendation systems for consumer

healthcare services. In Proceedings of the The Third

International Conference on Availability, Reliability

and Security, ARES 2008, March 4-7, 2008, Techni-

cal University of Catalonia, Barcelona , Spain, pages

889–895.

Kivits, J. (2006). Informed patients and the internet: a medi-

ated context for consultations with health profession-

als. Journal of health psychology, 11(2):269–282.

Lindell, Y. (2017). How to simulate it - A tutorial on the

simulation proof technique. In Tutorials on the Foun-

dations of Cryptography., pages 277–346.

Lindell, Y. and Pinkas, B. (2000). Privacy preserving

data mining. In Advances in Cryptology - CRYPTO

2000, 20th Annual International Cryptology Confer-

ence, Santa Barbara, California, USA, August 20-24,

2000, Proceedings, pages 36–54.

Longo, D. L. and Drazen, J. M. (2016). Data sharing. New

England Journal of Medicine, 374(3):276–277.

Lu, J., Wu, D., Mao, M., Wang, W., and Zhang, G. (2015).

Recommender system application developments: A

survey. Decision Support Systems, 74:12–32.

McMullan, M. (2006). Patients using the internet to obtain

health information: how this affects the patient–health

professional relationship. Patient education and coun-

seling, 63(1):24–28.

McSherry, F. and Mironov, I. (2009). Differentially pri-

vate recommender systems: Building privacy into the

netﬂix prize contenders. In Proceedings of the 15th

ACM SIGKDD International Conference on Knowl-

edge Discovery and Data Mining, Paris, France, June

28 - July 1, 2009, pages 627–636.

Nateghizad, M., Erkin, Z., and Lagendijk, R. L. (2016).

An efﬁcient privacy-preserving comparison protocol

in smart metering systems. EURASIP J. Information

Security, 2016:11.

Paillier, P. (1999). Public-key cryptosystems based on com-

posite degree residuosity classes. In Advances in

Cryptology - EUROCRYPT ’99, International Confer-

ence on the Theory and Application of Cryptographic

Techniques, Prague, Czech Republic, May 2-6, 1999,

Proceeding, pages 223–238.

Polat, H. and Du, W. (2005). Svd-based collaborative ﬁl-

tering with privacy. In Proceedings of the 2005 ACM

Symposium on Applied Computing (SAC), Santa Fe,

New Mexico, USA, March 13-17, 2005, pages 791–

795.

Ramakrishnan, N., Keller, B. J., Mirza, B. J., Grama, A.,

and Karypis, G. (2001). Privacy risks in recommender

systems. IEEE Internet Computing, 5(6):54–62.

Schoenmakers, B. and Tuyls, P. (2006). Efﬁcient binary

conversion for paillier encrypted values. In Advances

in Cryptology - EUROCRYPT 2006, 25th Annual In-

ternational Conference on the Theory and Applica-

tions of Cryptographic Techniques, St. Petersburg,

Russia, May 28 - June 1, 2006, Proceedings, pages

522–537.

Shamir, A. (1979). How to share a secret. Commun. ACM,

22(11):612–613.

Shokri, R., Pedarsani, P., Theodorakopoulos, G., and

Hubaux, J. (2009). Preserving privacy in collabora-

tive ﬁltering through distributed aggregation of ofﬂine

proﬁles. In Proceedings of the 2009 ACM Conference

on Recommender Systems, RecSys 2009, New York,

NY, USA, October 23-25, 2009, pages 157–164.

Sommerhalder, K., Abraham, A., Zufferey, M. C., Barth, J.,

and Abel, T. (2009). Internet information and medical

consultations: experiences from patients and physi-

cians perspectives. Patient education and counseling,

77(2):266–271.

Tiggle, M. (2012). Urban Alabama physicians and the elec-

tronic medical record: A qualitative study. PhD thesis.

Yao, A. C. (1982). Protocols for secure computations. In

Foundations of Computer Science, 1982. SFCS’08.

23rd Annual Symposium on, pages 160–164. IEEE.

Zhang, S., Ford, J., and Makedon, F. (2006). Deriving pri-

vate information from randomly perturbed ratings. In

Proceedings of the Sixth SIAM International Confer-

ence on Data Mining, April 20-22, 2006, Bethesda,

MD, USA, pages 59–69.

An Efﬁcient Privacy-preserving Recommender System for e-Healthcare Systems

199