implementation and analysis of fully homomorphic ......implementation, healthcare system, fully...

Implementation and Analysis of Fully Homomorphic Encryptionin Wearable Devices

Amonrat Prasitsupparote 1 Yohei Watanabe 2 Junji Shikata 1

1Graduate School of Environment and Information Sciences, Yokohama National University, Japan2Security Fundamentals Laboratory, Cybersecurity Research Institute,

National Institute of Information and Communications Technology, [email protected], [email protected], [email protected]

ABSTRACT

Currently, wearable devices, which are known asone of the Internet of things (IoT) devices, havebeen widely used for healthcare systems. Most ofthe healthcare systems store users’ healthcare data,which is encrypted by ordinary symmetric-key en-cryption and/or public-key encryption schemes, ina (cloud) server. However, the encrypted data needsto be decrypted for data analysis, and it means thatsensitive information is leaked to the server. Onepromising solution is to use fully homomorphicencryption (FHE), which enables ones to performany computation among encrypted data while keep-ing it encrypted. Although FHE generally requireshigh computational and communication costs in thetheoretical sense, several researchers have imple-mented FHE schemes to measure their practicalefficiency. In this paper, we consider a privacy-preserving protocol for healthcare systems employ-ing wearable devices, and implement this proto-col over Raspberry Pi, which is a popular single-board computer, to measure the actual efficiencyof FHE over wearable devices. Specifically, weimplemented the protocol by using two FHE li-braries, HElib and SEAL, on Raspberry Pi and net-work simulator to measure both computational andcommunication costs in wireless body area network(WBAN). In terms of the communication overhead,our result shows that the protocol with SEAL is bet-ter than that with HElib. In particular, the proto-col with SEAL has almost the same communicationcosts as the trivial protocol, which is the same pro-tocol without encryption. On the other hand, HE-lib is better than SEAL regarding the running time,while SEAL can perform more homomorphic op-erations than HElib for the almost same plaintext-size. Therefore, HElib is suitable for applicationswhich require small time complexity, and SEAL is

suitable for applications which require many homo-morphic operations.

KEYWORDS

Implementation, Healthcare system, Fully homo-morphic encryption, Wearable devices, WBAN.

1 INTRODUCTION

Recently, the area of Internet of Thing (IoT)has grown significantly supporting wide rangeapplications including medical and healthcaresystems, especially wearable devices. In par-ticular, due to the cheap prices, wearable de-vices have been widely used in our daily lives.Among various wearable devices sold in themarket, smartwatches are most popular. Gen-erally, people tend to use wearable devices byplacing devices around (i.e., inside or outside)their bodies for monitoring their health condi-tions. The most popular wearable device ap-plications use symmetric-key encryption (e.g.,AES), public-key encryption or both schemesto encrypt the health data, and store it in athird party storage such as a cloud. The cloudneeds to decrypt the encrypted data to per-form a certain operation when a user requestsit. After that the cloud will send back the re-sult to the user in the encrypted form. In thecase, the third party storage can know every-thing about the data since the cloud has capa-bility of decryption. Furthermore, medical sen-sor devices or wearable devices in healthcaresystems usually exchange the personal healthrecord (PHR) between patients, caregivers andphysicians through a cloud or a data server.This will result in information leakage issuesas mentioned above. Therefore, the privacy

Proceedings of 4TH INTERNATIONAL CONFERENCE ON INFORMATION SECURITY AND DIGITAL FORENSICS ISDF2018, Greece, 2018

ISBN: 978-1-941968-54-3 ©2018 SDIWC 1

preserving is a critical problem in healthcaresystems.One solution to solve the privacy preservingproblem in healthcare systems is the usage ofhomomorphic encryption (HE), in particularfully homomorphic encryption (FHE). HE al-lows the operation over the encrypted data (i.e.,ciphertext), thereby a third party storage or adata server does not need to decrypt the ci-phertext to perform the operation on the data.On the other hand, HE often requires expensivecomputation and much memory storage in gen-eral, and also produces a large size of cipher-texts. Due to the resource limitation and mem-ory constrained in a wearable device, it mightbe difficult to apply and implement HE in awearable device. Actually, there are severalresearchers who applied HE to healthcare sys-tems. The results were not satisfactory becauseof a high computation time and a high commu-nication cost [1, 2, 3, 4, 5, 6]. Currently, sev-eral researchers propose an improved homo-morphic encryption algorithm [7, 8], and theyclaimed that it could be used in a real world.HE can be categorized into three types with re-spect to the number of allowed operations onthe ciphertext (see detail in Section 2). In thiswork, we focus on the fully homomorphic en-cryption (FHE) which allows arbitrary opera-tions with unlimited number of times.

1.1 Related Work

The privacy issue in healthcare systems is achallenging problem that received wide atten-tion in the past decade. There are several re-ports trying to solve this issue. Specifically,Riedle et al. [9] proposed a privacy archi-tecture in e-Health by integrating many en-cryption schemes: attribute-based encryption(ABE), symmetric-key encryption and thresh-old key sharing. Their architecture concealspatient data by encryption, and divides into twolayers: the inner layer for authorized users andthe outer layer for unauthorized users. How-ever, this system is insecure with untrusted datastorage or third party cloud provider.The works that utilize HE in healthcare sys-tems are as follows. In 2014, Bos et al. [10]

presented a private predictive analysis on en-crypted medical data by using homomorphicencryption based on the NTRU scheme [11].Their scheme used only one ring element anddid not use modulus switching for decreasingciphertext expansion. Their system took sensi-tive medical data as input and encrypted withHE scheme, which implemented on a laptopcomputer (Intel Core i7-3520M), and then up-loaded its encrypted data to the cloud (hostedon Microsoft’s Windows Azure). The cloudran a prediction algorithm on the encrypteddata (i.e., without decryption) and returned theprobability of cardiovascular disease for dia-betes. This system requires the correct param-eters, for example, the size of the function tobe computed, the size of the inputs, and themethod for encoding real data. It is difficultto choose the suitable parameters, therefore itprovides a parameter selection algorithm. Incontrast, the inputs of parameter selection al-gorithm must be defined manually and the sys-tem performance heavily relied on the param-eter selection. Therefore, this system is not sopractical. In addition, this work is developedby Microsoft Cryptography Research Group,which lead to the Simple Encrypted ArithmeticLibrary (SEAL) [12] later.

In [1, 2, 3, 4], Kocabas and colleagues pro-posed a general architecture for medical cy-ber physical system (MCPS), which consists offour layers: data acquisition, data aggregation,cloud processing, and action. This scheme em-ploys two schemes of HE: the Paillier scheme[13] for computing the average heart rate, andthe BGV scheme [14] (used in HElib library[7]) for the long QT syndrome detection. Theyalso showed the implementation for the diag-nosis of the heart problem on a workstationwith dual Xeon E5-2695 Processors and 256GB RAM. Their result showed that they couldretrieve the average heart rate on the cloudclose with a real time response. However, theyincur high computation time and high commu-nication cost on the user and the server side.

In 2016, Preuveneers and Joosen [5] imple-mented fully homomorphic encryption by us-ing the HElib library on wearable devices


ISBN: 978-1-941968-54-3 ©2018 SDIWC 2

for analyzing diabetics, and sharing data withphysicians or other caregivers (e.g. parentsof diabetic children). They converted a bloodglucose value and a hypoglycemia thresh-old into 10-bit binary representations, and se-quentially encrypted each bit of them, thenstored the encrypted data on the cloud server.The caregivers can analyze blood glucose, in-sulin values, and other parameters while keep-ing the privacy of data. They implementedtheir scheme on three platforms: Omate Truesmartwatch that operates on a dual-core ARMCortex-A7 CPU running at 1 GHz, SamsungGalaxy S4 smartphone with quad-core ARMCortex-A7 CPU running at 1.2 GHz, and aserver system with Intel Core i7-3770 pro-cessor running at 3.40 GHz. Due to the re-source limitation and memory constrained inthe wearable device, and computational com-plexity of this solution, it can send blood glu-cose data to the cloud server every five minuteseven though ignoring the three least significantbits, and it is an unacceptable time for moni-toring blood glucose in wearable device. Theyconcluded that they demonstrated the practi-cal feasibility of this solution but it was not sopractical due to the resource limitation.

In 2017, Sun et al. [6] presented an architec-ture of mobile healthcare systems, which con-sists of four sections: wearable device, pre-processing, cloud server, and physician diag-nosis. This solution was defined as three se-cure medical computations: the average heartrate, the long QT syndrome detection, and thechi-square tests. This work is similar to theKocabas’s work [4], however, the differencelies in the usage of the homomorphic encryp-tion library. Kocabas’s work employed HEliblibrary, while Sun’s work employed Dowlin’sscheme. In fact, both libraries are FHE basedon BGV scheme. Note that Dowlin’s schemebecomes a part of SEAL project later. Theyevaluated their solution on a PC with Intel Corei5-3470 processor running at 3.20 GHz and8 GB RAM. Their result shows that it pro-duces only one ciphertext for the average heartrate function, and one multiplication opera-tion for the long QT syndrome detection func-

tion. They also compared the implementationtime of the long QT syndrome detection in Ko-cabas’s work and their protocol, and this resultshowed that their protocol was faster than Ko-cabas’s scheme. Finally, they concluded thattheir scheme was better than the Kocabas’sscheme. This was done by comparing effi-ciency of SEAL library (this work) and HE-lib library (i.e., Kocabas’s work). Furthermore,they first implemented chi-square tests for ob-serving the probability of varicose veins arerelevant to overweight.Costache and Smart [15] extended the work[16] and showed a comparison result of fourHE schemes, FV, YASHE, BGV and NTRU.They applied the four schemes to the same APIand the same optimization. They also investi-gated applying modulus switching to the scaleinvariant schemes, and considered the plaintextmodulus, level bound and security parameters.They presented the results of all schemes invarious parameter sets, while fixing the secu-rity level of k = 80 bits, a Hamming weight ofh = 64 and a ring constant of cm = 1.3. Theyalso presented the relation between the largeplaintext-space p ≈ 232, the number of levelsL, and the ciphertext-size, and concluded thatthe BGV scheme appears to be more efficientfor large plaintext moduli, while the YASHEscheme seems more efficient for small plain-text moduli. Note that the BGV scheme meansHElib library, and the YASHE scheme meansSEAL library.

1.2 Our Contribution

As can be seen in Kocabas’s work [1, 2, 3, 4],FHE produces large ciphertexts, which lead tohigh communication costs on both the user andserver sides in healthcare systems. Our workhas been motivated by this problem. Notethat all related works were done by estimat-ing only the time complexity, even though thereal implementation in Kocabas’s work showssignificance of the overhead in communicationin FHE. Therefore, estimating the communi-cation overhead over the wearable-device net-work is important as well as time complex-ity. Note that a group of short-range wear-


ISBN: 978-1-941968-54-3 ©2018 SDIWC 3

able devices on, in, or around human bod-ies is based on IEEE 802.15.6 standard [17],which is called the wireless body area net-work (WBAN). Consequently, the first part ofour work investigates the communication over-head of healthcare systems using FHE overWBAN. Furthermore, several researchers pre-sented the practical FHE library [7, 8], andthey claimed that it could be used in a realworld. [1, 2, 3, 4, 5] showed implementa-tions of healthcare systems using the HElib li-brary over a PC and a wearable device, and[10, 6] implemented a healthcare system us-ing the SEAL library on a PC. [5] implementeda healthcare system using the HElib libraryover a smartwatch. In addition, Costache andSmart’s work [15] dealt with implementationsof various FHE schemes for general systems onPCs. However, there is no research on estimat-ing the efficiency of HElib and SEAL librarieson restricted resource devices in a general set-ting, which is the second part of our work.Specifically, the contribution of this paper is asfollows:

• We investigate the communication over-head of a certain privacy-preserving pro-tocol using FHE for healthcare systemover WBAN. We implement the protocolby using two FHE libraries, HElib andSEAL, with a network simulator to mea-sure communication costs over WBAN.Our result shows that the protocol withSEAL is better than that with HElib. Inparticular, the former has almost the samecommunication costs as the trivial proto-col, which is the same protocol withoutconsidering privacy (i.e., a protocol with-out FHE).

• We evaluate efficiency of two FHE li-braries, HElib and SEAL on a restrictedresource device. We implement themon a PC supposed to be a cloud server,and Raspberry Pi supposed to be a wear-able device such as a smartphone or anyrestricted resource device over WBAN.Our result shows that HElib is better interms of running time than SEAL, while

SEAL can perform more homomorphicoperations than HElib for the almost sameplaintext size. Therefore, HElib is suit-able for applications which require smalltime complexity, and SEAL is suitable forapplications which require a lot of homo-morphic operations.

2 FULLY HOMOMORPHIC ENCRYP-TION (FHE)

Homomorphic encryption (HE) is a public-key encryption that enables us to performan arithmetic or logical operation on cipher-texts without decrypting it. Generally, aHE scheme consists of four polynomial timealgorithms: KeyGen,Enc,Dec, and Eval.KeyGen is a probabilistic algorithm for gen-erating a key-pair, a public key pk and a se-cret key sk. Enc is an algorithm to en-crypt a plaintext m and to output a ciphertextc. Dec is an algorithm to decrypt a cipher-text c and to output the plaintext m. In fact,KeyGen,Enc,Dec are the same as those inthe traditional public key encryption scheme,however Eval is a special algorithm includedin a HE scheme. An evaluation algorithmEval takes two ciphertexts of two plaintextsm1 and m2 respectively, and an operation ?as input, and it outputs an evaluated ciphertextc := Evalpk(Encpk(m1),Encpk(m2), ?), whichsatisfies Decsk(c) = m1 ? m2. HE can be cat-egorized into three types with respect to thenumber of allowed operations on the ciphertextas follows:

• In Partially Homomorphic Encryption(PHE), Eval can perform only one type ofoperation (e.g., either addition or multipli-cation), though the number of operationsperformed is unlimited. For instance, thePaillier scheme [13] based on compositeresiduosity problem [18] allows only ad-dition, and was used in [4] to calculate theaverage heart rate on the cloud.

• In Somewhat Homomorphic Encryption(SHE), Eval can perform two kinds of op-erations such as both addition and multi-plication, though the number of one of the


ISBN: 978-1-941968-54-3 ©2018 SDIWC 4

two operations is limited. SHE schemesinclude BGN [19] based on a subgroupdecision problem [20]. In the BGNscheme, the number of allowed addition-operations is unlimited, while the mul-tiplication operation is allowed only onetime.

• Fully Homomorphic Encryption (FHE)was proposed by Gentry [21] in 2009where Eval can perform any operations(i.e., both addition and multiplication),and the number of performed operationsis unlimited. It was constructed based onideal lattices, and has a massive overheadin computation and memory. FHE has alot of attractive applications, especially incloud environments, and therefore a vari-ety of FHE schemes have been proposedafter Gentry’s work. There are four maincategories in FHE after Gentry’s work:Ideal lattice-based FHE [21], FHE overintegers [22, 23], FHE from the learningwith errors (LWE) assumption [24, 25,26], and NTRU-like FHE [11, 27]. InFHE, whenever a homomorphic operationis applied, some noise will be added intothe ciphertext and the ciphertext-size in-creases. When the noise grows over thelimitation, the decryption algorithm can-not correctly decrypt ciphertexts. To re-solve this problem, there is a bootstrap-ping technique to reduce the noise, andget a fresh ciphertext from the noisy ci-phertext corresponding to the same plain-text. After applying bootstrapping, a ho-momorphic operation can be applied tothe fresh ciphertext as long as the noiseis within the limitation.

Table 1. The property of FHE libraries

Name HElib [7] SEAL [12]Base Scheme BGV [14] BFV [28]

Language C/C++ C++/.NETRequired GMP [29], NoLibraries NTL [30]

Bootstrapping Yes No

In this paper, we focus on two well-knownFHE libraries: HElib and SEAL, which we

summarize in Table 1. The first is HE-lib [7], an open source library implemented byHalevi and Shoup in 2014, which is based onthe Brakerski-Gentry-Vaikuntanathan (BGV)scheme [14]. Halevi and Shoup also appliedseveral techniques: a ciphertext packing pro-posed by Smart and Vercauteren [31], an op-timization for homomorphic evaluation pro-posed by Gentry, Halevi, and Smart [32], and anoise management by bootstrapping [33]. Thislibrary is written in C++ and has several pa-rameters which effect to the performance andsecurity level, thus it is difficult to choose thesuitable parameters for non-experts. Moreover,it requires two prerequisite libraries: GNUMultiple Precision Arithmetic (GMP) library[29] and NTL mathematical library [30] (ver-sion 10.0.0 or higher). However, it is a low-level implementation, thereby it was applied invarious areas. The current version is 1.3, whichis available at github [34].The second one, Simple Encrypted Arith-metic Library (SEAL) [12], was developedby Cryptography Research Group at Mi-crosoft Research in 2015. It is based onthe Brakerski/Fan-Vercauteren scheme (BFV)[28], and it is a SHE scheme since bootstrap-ping is not yet supported. The goal of this li-brary is to be easily used by both crypto expertsand non-experts like in bioinformatics. Ac-cordingly, there are automatic parameter selec-tion and noise estimator tools for non-experts,and this library does not require any exter-nal dependencies. It is written in C++, andcontains .NET wrappers for the public API,thereby it can be compiled on various plat-forms. The current version of SEAL is 2.3.1.Although this version does not provide boot-strapping, the developer encourages to use pa-rameter selection and noise estimator tools in-stead. It needs the Microsoft Research LicenseAgreement to use and be free for the researchpurpose.3 PRIVACY PRESERVING PROTO-

COL FOR WEARABLE DEVICES INHEALTHCARE SYSTEMS

We assume that there are a user (e.g., a pa-tient), a user’s smartphone, a cloud server, and


ISBN: 978-1-941968-54-3 ©2018 SDIWC 5

Figure 1. A privacy preserving protocol for wearable devices in healthcare systems.

a caregiver (e.g., a physician). In Fig. 1, thegreen arrow means a secure wireless chan-nel, and other arrows mean insecure chan-nels, which can be wired or wireless chan-nels. The red dotted square means a wirelessbody area network (WBAN) following IEEE802.15.6 [17]. A working group of IEEE de-fines IEEE 802.15.6 that specifies the standardfor low-power and short-range wireless deviceson, in, or around human bodies, called WBAN.This standard also means a wireless network ofwearable devices in healthcare systems. Cur-rently, WBAN consists of one or more wire-less medical sensor devices, and sink nodes(i.e., gateway nodes). A sink node can be asmartphone, a PC, or a high performance sen-sor node, however, it must be connected in awireless environment. WBAN in our protocolconsists of wearable devices and a smartphoneas a sink node which communicate throughWi-Fi. Each wearable device may contain sin-gle or multiple medical sensors depending onits aim, however in this paper we assume thereare n sensor nodes SN1, . . . , SNn in total on

a user’s body. A cloud server stores the healthdata, and performs operations then sends theresult back to a caregiver. Our protocol con-sists of the following four phases:

1) Key generation: We omit this phase inFig. 1 for simplicity. At the first time ofusing a wearable device, a user calls a keygeneration algorithm KeyGen to gener-ate a key-pair (pk, sk) through the wear-able device’s application on the user’ssink node (e.g., smartphone). The sinknode broadcasts pk to all devices overWBAN, and keeps sk. All devices inWBAN obtain pk, and store it in theirmemory. In addition, the sink nodecan send sk to a caregiver’s applicationthrough a secure wireless channel. On theother hand, a caregiver can call KeyGenon behalf of a user though an applicationon his/her PC, tablet or smartphone, andthe application can send sk to the sinknode through a secure wireless channel.

2) Encryption and transmission: When


ISBN: 978-1-941968-54-3 ©2018 SDIWC 6

each sensor SNi in a wearable devicereads the health data mi, it was encryptedby the encryption algorithm Enc imme-diately. We write this operation as ci ←Encpk(mi). In case that the size of ci isgreater than the maximum packet size,1

we divide the ciphertext ci into k piecesfor some k. We write this operationas (c

(1)i , . . . , c

(k)i ) ← Divide(ci,max),

where max is the maximum packet size.The wearable device stores the divided ci-phertexts c(j)i in transmission’s buffer, andtransmits c(j)i in each time slot. When thesink node receives all c(j)i (1 ≤ j ≤ k), itreconstructs ci from them. We write thisoperation as ci ← Agg(c

(1)i , . . . , c

(k)i ). Af-

ter that, the sink node uploads the cipher-text ci to the cloud server.

3) Homomorphic operation: A caregiver’srequest is denoted by f(), and we assumethat every f() is expressed by additionand/or multiplication operations. Afterthe cloud server receives the request f(),it runs Eval and outputs the resulting ci-phertext c to the requester. The noise inciphertexts becomes to be large wheneverEval is applied. When the noise is closeto the limit, the cloud server must performbootstrapping to reduce the noise, and geta fresh ciphertext having the same under-lying plaintext. After applying bootstrap-ping, a fresh ciphertext allows us to con-tinue to perform homomorphic operationsas long as the noise is within the limita-tion.

4) Decryption: A caregiver’s device de-crypts the ciphertext c by the decryp-tion algorithm Dec using a secret keysk. We write this operation as f(M) ←Decsk(c), where M denotes the healthdata stored in the cloud with the encryptedform. The caregiver finally obtains the re-sult f(M) for his/her request f() on thedata M .

1We consider the maximum packet size based onIEEE 802.15.6 [17].

4 ANALYSIS OF COMMUNICATIONOVERHEAD IN WBAN

In [35], it is stated: “The total number of pack-ets are to be transferred or transmitted from onenode to another, which is known as the com-munication overhead; It includes the overheadof routing process, routing table and packetpreparation in a sensor node”. This implies thecommunication cost treated in Kocabas’s work[4]. Kocabas also mentioned that the com-munication overhead was concern in systems.Therefore, we implement our protocol with anetwork simulator to investigate the communi-cation overhead in WBAN on a PC with IntelCore i7 processor running at 4.0 GHz and 32GB of RAM where it is running on Ubuntu 64-bit operating system.

4.1 Experimental Setup

Xian et al. [36] presented the comparision ofseveral major wireless sensor network (WSN)simulators. The results show that OMNET++[37] is better than NS2 and OPNET in terms ofexecution time and memory usage in simulat-ing WSN. In addition, OMNET++ was widelyused in this research area. In 2007, Australia’sInformation and Communications TechnologyResearch Centre of Excellence (NICTA) pub-lished a simulator for WSN, WBAN, and moregenerally for networks of low-power embed-ded devices, which is called Castalia. It isbased on the OMNET++ platform with real-istic node behaviours and Baseline MAC forBody Area Networks (BAN), following IEEE802.15.6. The WBAN testbed of Castaliacollected data from the real wearable sen-sors on human bodies in daily life activitiessuch as walking, running, jogging, and sleep-ing. It is an open source and available ongithub [38]. Our experiment simulates WBANthrough OMNET++ version 4.6 and Castaliaversion 3.3.We simulate WBAN through OMNET++ andCastalia with parameters in Table 2. Firstly, welimit the number of sensor nodes from 2 to 16,and the assigned Medium Access Control pro-tocol (MAC) is Baseline BAN MAC, which is


ISBN: 978-1-941968-54-3 ©2018 SDIWC 7

Table 2. Simulation parameters.

Parameters ValueNumber of sensor nodes 2− 16Medium Access Control Baseline BAN MAC

protocol (MAC)Read data interval 30s

Maximum packet size 2kbDelayed limit 30s

Packet rate 5sSimulation time 3600s

important for the node’s behavior. Generally,medical sensor devices generate many smallpackets in a short time interval, thereby wesuppose that each node reads sensitive data ev-ery 30 seconds. If the node’s buffer is full, itskips reading sensitive data, and will read itagain in a next period. Moreover, we assumethat the maximum packet size is 2kb, and thedelay limit in transmission is 30 seconds, be-cause we assume each node reads the data ev-ery 30 seconds. Each node sends a packet ev-ery 5 seconds, and limit our simulation time to3600 seconds.We implement our protocol with two FHE li-braries: HElib and SEAL, and compare theirperformance with NoEncrypt scheme. TheNoEncrypt scheme is a trivial protocol withoutencryption, where all packets are transimttedin cleartext. One of disadvantages in HElib li-brary is the parameter selection for non-expertsbecause it has a lot of parameters and some pa-rameters have a relationship, however the sev-eral appropriate parameters are suggested in[7]. Therefore, this implementation use theirsuggested parameters. In contrast, SEAL hasa tool for automatic parameter selection fornon-experts: a user only defines the plaintext-size (i.e., plaintext modulus in SEAL library)and runs an automatic parameter selection tool.Our experiment assigns a security parameterto be 110-bit for all libraries. It is knownthat the multiplication operation causes a largenoise to ciphertexts compared to addition oper-ation, a user cannot use a multiplication opera-tion if the plaintext-space is not large enough.Therefore, our experiment selects the mini-mum plaintext-size such that a homomorphic

operation for multiplications can be executedat least one time. Taking into the above condi-tions, we have selected the following parame-ters: the plaintext-space of HElib is GF(p) withp = 1693, that of SEAL is GF(210) (i.e., its sizeis |GF (210)| = 1024).This simulation assigns a sink node SN0,and SN0 receives a packet from other nodesSN1, SN2, ..., SNn every 5 seconds, where nis the number of sensor nodes. We considerfour measurements to evaluate communicationoverhead as follows:

1) What is the number of packets per cipher-text?: This is evaluated as follows. LetJ be the number of ciphertexts by whichSN0 could reconstruct by receiving allpieces of the ciphertext from some sen-sor nodes, and we do not count ciphertextssuch that SN0 could not reconstruct them.Suppose that such J ciphertexts are de-noted by C(1), C(2), . . . , C(J) and thatj-th ciphertext C(j) (1 ≤ j ≤ J) wasdivided into kj packets in transmission.Then, we calculate the number of packetsper ciphertext by

∑Jj=1 kj/J .

2) What is the number of packets transmittedfrom each sensor node?: This is evaluatedas follows. Let K be the amount numberof packets which arrived at SN0 from Isensor nodes in total minus one becauseof fixed one sink node. Note that K in-cludes a re-transmitted packet. Then, wecalculate the number of packets transmit-ted from each sensor node by the averageK/I .

3) What is the number of delayed packetsfrom each sensor node?: We define thata packet is delayed, if the time differ-ence between the time when the packetwas created and the time when the packetarrived at SN0 is more than 30 seconds.This is reasonable in our simulation, sincewe assume each node reads data every 30seconds.

4) How many times a packet was success-fully transmitted?: This is investigated at


ISBN: 978-1-941968-54-3 ©2018 SDIWC 8

the MAC level. SN0 must receive allpackets from other nodes, and aggregatesthem to reconstruct a ciphertext ci. How-ever, in the process of transmission, therewould be packet loss from some node,and then the node has to re-send such apacket until SN0 will successfully receiveit. Moreover, if SN0 is in the collisionstate, some packets must be re-sent manytimes. By taking into account such a sit-uation, we count a number of times thatthe packet was successfully transmitted,namely a packet was successfully trans-mitted in the first time (1st-try), a packetwas successfully transmitted in the secondtime (2nd-try), ..., and a packet was suc-cessfully transmitted in the sixth time ormore (6 or more tries).

4.2 Simulation results

Firstly, we investigate the reasonable numberof sensor nodes for our protocol by comparingthat of NoEncrypt scheme. In Fig. 2, the x-axis means the number of nodes in WBAN andthe y-axis means the number of delayed pack-ets in average. It can be seen that the numberof delayed packets in our protocol with all li-braries are almost same as that in NoEncryptscheme, when WBAN consists of two nodes.However, the number of delayed packets in ourprotocol with SEAL library is close to that inNoEncrypt scheme, when WBAN consists oftwo to ten nodes. In fact, there is a moderatedifference of the number of delayed packetsbetween our protocol with SEAL library andNoEncrypt scheme, when WBAN consists ofeight nodes. Thereby, the reasonable numberof sensor nodes for our protocol is not overten nodes. In addition, Castalia recommendsthat the number of nodes in WBAN is six.According to this result and recommendationby Castalia, we change the number of sensornodes in our simulation to six.Next, we observe the number of packets perciphertext and the number of packets transmit-ted from each sensor node in Table 3. It canbe seen that NoEncrypt method has only onepacket per ciphertext, however our protocol

Figure 2. The number of delayed packets with vary thenumber of nodes.

Table 3. The number of packets per ciphertext and thenumber of packets transmitted from each sensor node.

Name Packets/ciphertext Packets transmittedNoEncrypt 1 120.02

HElib 80 9601.78SEAL 17 2040.02

with HElib has the highest number of packetsper ciphertext, which means HElib library pro-duces the largest ciphertext-size. In contrast,the number of packets per ciphertext of ourprotocol with SEAL is close to that of NoEn-crypt scheme. The tendency of the number ofpackets per ciphertext is the same as the num-ber of packets transmitted from each sensornode. The number of packets transmitted fromeach sensor node of our protocol with HElib isthe highest, while that of SEAL is close to thatof NoEncrypt scheme.

Table 4. The number of delayed packets from each sen-sor node.

Name NoEncrypt HElib SEALSN1 0.0 7234.8 0.0SN2 0.3 172.4 5.1SN3 0.1 6206.8 1.7SN4 0.4 7662.6 6.8SN5 0.3 5761.6 6.0

Average 0.2 5407.6 3.9

Table 4 shows the number of delayed packetsfrom each sensor node. It can be seen thatthe number of delayed packets from each sen-sor node of our protocol with HElib is enor-mous more than that of other methods, and thatof SEAL is close to that of NoEncrypt. The


ISBN: 978-1-941968-54-3 ©2018 SDIWC 9

number of delay packets in SN1 of our pro-tocol with SEAL and NoEncrypt scheme is 0,which means SN0 received all packets fromSN1. According to this situation and the re-sult in Fig. 2, we confirm that the best numberof sensor nodes for our protocol is only two.

Figure 3. A number of times that the packet was suc-cessfully transmitted by expression with fractions of 1.

In Fig. 3, we depict a number of times thatthe packet was successfully transmitted. Thex-axis means the schemes, NoEncrypt andour protocols with HElib and SEAL libraries.The y-axis means a number of times that thepacket was successfully transmitted by expres-sion with fractions of 1. It is clearly seen thatthe result of our protocol with SEAL is almostthe same as NoEncrypt scheme. Moreover,the packets was successfully transmitted in thefirst time (1st-try) of NoEncrypt scheme andour protocol with SEAL approximately 80%,while that of HElib approximately 70%. Thisresult corresponds to the result in Table 4 andFig. 2.As a result, it can be seen that our proto-col with HElib produces much communica-tion overhead in WBAN. However, our proto-col with SEAL produces few communicationoverhead close to NoEncrypt scheme. There-fore, we can conclude that our protocol withSEAL is best in terms of communication cost,and the best number of sensor nodes for ourprotocol is two, however our protocol can effi-ciently perform if the number of sensor nodesare not over six.

5 ANALYSIS OF EFFICIENCY FORFHE

In this section, we investigate efficiency of HE-lib and SEAL libraries. As explained in Sec-tion 3, our protocol has three kinds of com-ponents, wearable devices (for sensor nodes),smartphone (for a sink node and a caregiver’sdevice), and a cloud server. This experimentuses a PC with Intel Core i7 processor runningat 4.0 GHz and 32 GB of RAM which is sup-posed to be a cloud server, and a Raspberry PiModel B+ v1.2 with ARM11 at 700 MHz and512 MB SDRAM which is supposed to be awearable device or a smartphone. Nowadays,smartphones in market have much higher per-formance than this Raspberry Pi, and we canexpect that implementation results on smart-phone would be much better than our imple-mentation results on this Raspberry Pi. In ad-dition, the hardware of this Raspberry Pi is al-most the same as those of cheap wearable de-vices in market, thereby this Raspberry Pi canbe used instead of implementation in wearabledevices.

5.1 Experimental Setup

We export health data from the network sim-ulator in the previous experiment (see Section4) and use it as the input in this experiment aswell. The previous experiment used the mini-mum plaintext-space that can allow us to per-form homomorphic operations for both addi-tion and multiplication. However, this experi-ment observes the running time for computinghomomorphic operations and that for comput-ing bootstrapping, thus our experiment shoulduse the same plaintext-size for fair comparison.Therefore, this experiment uses the plaintext-sapce is 1024 in SEAL library (the same as theprevious experiment in Section 4.1); and theplaintext-space of HElib must be a prime num-ber (or a power of a prime), thereby we use thesize 1021 which is close to 1024.

5.2 Comparison Results

Firstly, we observe the running time (in mil-liseconds) in each algorithm of HElib and


ISBN: 978-1-941968-54-3 ©2018 SDIWC 10

Table 5. The running time (Milliseconds)

KeyGen Encryption Decryption Addition Multiplication Bootstrapping

PC HElib 0.760058 0.032094 0.013368 0.000094 0.066178 85.323830SEAL 1.930100 2.342723 0.177101 0.005329 2.187750 -

Raspberry Pi HElib 79.933075 2.084733 1.258043 0.006370 4.707492 7,846.207000SEAL 181.319900 229.979548 46.673325 0.920642 480.622600 -

SEAL libraries on PC and Raspberry Pi in Ta-ble 5. It can be seen that HElib library is fasterthan SEAL library on both platforms. Thebootstrapping takes a long time than other al-gorithms. Note that SEAL library does not pro-vide a bootstrapping function. We can explic-itly observe that the running time for perform-ing a homomorphic operation for multiplica-tion is much more than that of a homomorphicoperation for addition in each library. Addi-tionally, Raspberry Pi takes much more timethan PC in every algorithm, however the run-ning time of HElib on Raspberry Pi is accept-able for the practical use.

Table 6. The ciphertext-size of HElib library be-fore/after using bootstrapping (bytes)

PC Raspberry PiBefore 84,251.4 63,486.8After 29,138.6 29,156.8

Moreover, we observe the ciphertext-size inHElib library before/after using bootstrappingon PC and Raspberry Pi in Table 6. Our re-sults in Section 4.2 show that the large cipher-texts lead to a high communication overhead.The usage of bootstrapping can reduce theciphertext-size over 60% on both platforms.

Table 7. The maximum number of allowed homomor-phic operations

Plaintext-space Addition Multiplication

HElib 1021 26 01693 44 1

SEAL 1024 510 1

We also investigate the maximum number upto which homomorphic operations are allowedto apply, and the results are summarized in Ta-ble 7. Under the condition that plaintext-sizein each library is almost the same (i.e., 1021in HElib, and 1024 in SEAL), SEAL provides

the largest number up to which homomorphicoperations for addition or multiplication are al-lowed. In particular, HElib cannot allow a ho-momorphic operation for multiplication for theselected plaintext-size. Afterwards, we haveincreased the size of plaintexts in HElib sothat we can apply a homomorphic operation formultiplication at least one time, and the result-ing size of plaintexts in HElib is 1693.As a result, HElib is better than SEAL interms of running time, while our protocol withSEAL is better than our protocol with HE-lib in terms of the communication overhead inWBAN. In addition, SEAL can provide us thelargest number up to which homomorphic op-erations are applied than HElib when we regardthose as SHE schemes. However, HElib pro-vides bootstrapping for refreshing the cipher-texts, and hence we can continue to use ho-momorphic operations. Furthermore, in HE-lib, we can observe the running time of boot-strapping is much more than those of other al-gorithms, whereas the ciphertext-size of HElibis reduced over 60% after applying bootstrap-ping.

6 CONCLUSION

We investigated the communication overheadin WBAN when using FHE in the privacypreserving protocol for healthcare. We im-plemented the protocol by using two FHE li-braries, HElib and SEAL, on a PC, RaspberryPi and network simulator (OMNET++ andCastalia) to measure both computational andcommunication costs in WBAN. In terms ofthe communication overhead, our result showsthat the protocol with SEAL is better than thatwith HElib. In particular, the protocol withSEAL has almost the same communicationcosts as the trivial protocol, which is the sameprotocol without encryption. However, HElib


ISBN: 978-1-941968-54-3 ©2018 SDIWC 11

is better than SEAL in terms of the runningtime, while SEAL can perform more homo-morphic operations than HElib for the almostsame plaintext-size as SHE schemes. There-fore, HElib is suitable for applications whichrequire small time complexity, and SEAL issuitable for applications which require manyhomomorphic operations. It would be interest-ing to investigate power consumption requiredin the protocol by implementation, and it willbe our future work.

REFERENCES

[1] O. Kocabas, T. Soyata, J. Couderc, M. Aktas,J. Xia, and M. Huang, “Assessment of cloud-based health monitoring using homomorphic en-cryption,” in 2013 IEEE 31st International Con-ference on Computer Design (ICCD), Oct 2013,pp. 443–446.

[2] v. Kocabas and T. Soyata, “Medical Data Analyt-ics in the Cloud Using Homomorphic Encryption,”Handbook of Research on Cloud Infrastructuresfor Big Data Analytics, pp. 471–488, 2014.

[3] O. Kocabas and T. Soyata, “Utilizing Homomor-phic Encryption to Implement Secure and PrivateMedical Cloud Computing,” in 2015 IEEE 8th In-ternational Conference on Cloud Computing, Jun.2015, pp. 540–547.

[4] O. Kocabas, T. Soyata, and M. K. Aktas, “Emerg-ing security mechanisms for medical cyber phys-ical systems,” vol. 13, no. 3, May 2016, pp. 401–416.

[5] D. Preuveneers and W. Joosen, “Privacy-enabledRemote Health Monitoring Applications for Re-source Constrained Wearable Devices,” in Pro-ceedings of the 31st Annual ACM Symposium onApplied Computing, ser. SAC ’16. New York,NY, USA: ACM, 2016, pp. 119–124.

[6] X. Sun, P. Zhang, M. Sookhak, J. Yu, and W. Xie,“Utilizing fully homomorphic encryption to imple-ment secure medical computation in smart cities,”Personal and Ubiquitous Computing, vol. 21,no. 5, pp. 831–839, Oct 2017.

[7] S. Halevi and V. Shoup, “Algorithms in helib,” inAdvances in Cryptology – CRYPTO 2014, J. A.Garay and R. Gennaro, Eds. Berlin, Heidelberg:Springer Berlin Heidelberg, 2014, pp. 554–571.

[8] N. Dowlin, R. Gilad-Bachrach, K. Laine,K. Lauter, M. Naehrig, and J. Wernsing, “Manualfor using homomorphic encryption for bioinfor-matics,” Proceedings of the IEEE, vol. 105, no. 3,pp. 552–567, March 2017.

[9] B. Riedl, V. Grascher, S. Fenz, and T. Neubauer,“Pseudonymization for improving the privacy in e-health applications,” in Proceedings of the 41st An-nual Hawaii International Conference on SystemSciences (HICSS 2008), Jan 2008, pp. 255–255.

[10] J. W. Bos, K. Lauter, and M. Naehrig, “Private pre-dictive analysis on encrypted medical data,” Jour-nal of Biomedical Informatics, vol. 50, pp. 234–243, Aug. 2014.

[11] A. Lopez-Alt, E. Tromer, and V. Vaikuntanathan,“On-the-fly multiparty computation on the cloudvia multikey fully homomorphic encryption,” inProceedings of the Forty-fourth Annual ACM Sym-posium on Theory of Computing, ser. STOC ’12.New York, NY, USA: ACM, 2012, pp. 1219–1234.

[12] “Simple Encrypted Arithmetic Library- SEAL Crypto.” [Online]. Avail-able: https://www.microsoft.com/en-us/research/project/simple-encrypted-arithmetic-library/

[13] P. Paillier, “Public-key cryptosystems based oncomposite degree residuosity classes,” in Advancesin Cryptology — EUROCRYPT ’99, J. Stern, Ed.Berlin, Heidelberg: Springer Berlin Heidelberg,1999, pp. 223–238.

[14] Z. Brakerski, C. Gentry, and V. Vaikuntanathan,“(leveled) fully homomorphic encryption withoutbootstrapping,” in Proceedings of the 3rd Innova-tions in Theoretical Computer Science Conference,ser. ITCS ’12. New York, NY, USA: ACM, 2012,pp. 309–325.

[15] A. Costache and N. P. Smart, “Which ring basedsomewhat homomorphic encryption scheme isbest?” in Topics in Cryptology - CT-RSA 2016,K. Sako, Ed. Cham: Springer International Pub-lishing, 2016, pp. 325–340.

[16] T. Lepoint and M. Naehrig, “A comparison of thehomomorphic encryption schemes fv and yashe,”in Progress in Cryptology – AFRICACRYPT 2014,D. Pointcheval and D. Vergnaud, Eds. Cham:Springer International Publishing, 2014, pp. 318–335.

[17] “IEEE 802.15.6-2012 - IEEE Standard for Lo-cal and metropolitan area networks - Part 15.6:


ISBN: 978-1-941968-54-3 ©2018 SDIWC 12

https://www.microsoft.com/en-us/research/project/simple-encrypted-arithmetic-library/

https://www.microsoft.com/en-us/research/project/simple-encrypted-arithmetic-library/

Wireless Body Area Networks.” [Online]. Avail-able: http://standards.ieee.org/findstds/standard/802.15.6-2012.html

[18] T. Jager, The Generic Composite ResiduosityProblem. Wiesbaden: Vieweg+Teubner Verlag,2012, pp. 49–56. [Online]. Available: https://doi.org/10.1007/978-3-8348-1990-1 5

[19] D. Boneh, E.-J. Goh, and K. Nissim, “Evaluat-ing 2-DNF formulas on ciphertexts,” in Theory ofCryptography, TCC 2005, J. Kilian, Ed. Berlin,Heidelberg: Springer Berlin Heidelberg, 2005, pp.325–341.

[20] K. Gjøsteen, Subgroup membership problemsand public key cryptosystems, 2004. [Online].Available: https://brage.bibsys.no/xmlui/handle/11250/249681

[21] C. Gentry, “Fully Homomorphic Encryption UsingIdeal Lattices,” in Proceedings of the Forty-firstAnnual ACM Symposium on Theory of Computing,ser. STOC ’09. New York, NY, USA: ACM, 2009,pp. 169–178.

[22] J.-S. Coron, A. Mandal, D. Naccache, and M. Ti-bouchi, “Fully homomorphic encryption over theintegers with shorter public keys,” in Advancesin Cryptology – CRYPTO 2011, P. Rogaway, Ed.Berlin, Heidelberg: Springer Berlin Heidelberg,2011, pp. 487–504.

[23] M. van Dijk, C. Gentry, S. Halevi, and V. Vaikun-tanathan, “Fully homomorphic encryption over theintegers,” in Advances in Cryptology – EURO-CRYPT 2010, H. Gilbert, Ed. Berlin, Heidelberg:Springer Berlin Heidelberg, 2010, pp. 24–43.

[24] Z. Brakerski and V. Vaikuntanathan, “Fully homo-morphic encryption from ring-lwe and security forkey dependent messages,” in Advances in Cryptol-ogy – CRYPTO 2011, P. Rogaway, Ed. Berlin,Heidelberg: Springer Berlin Heidelberg, 2011, pp.505–524.

[25] Z. Brakerski, “Fully homomorphic encryp-tion without modulus switching from classicalGapSVP,” in Advances in Cryptology – CRYPTO2012, R. Safavi-Naini and R. Canetti, Eds.Berlin, Heidelberg: Springer Berlin Heidelberg,2012, pp. 868–886.

[26] Z. Brakerski and V. Vaikuntanathan, “Efficientfully homomorphic encryption from (standard)LWE,” SIAM Journal on Computing, vol. 43, no. 2,pp. 831–871, 2014.

[27] K. Rohloff and D. B. Cousins, “A scalable im-plementation of fully homomorphic encryptionbuilt on NTRU,” in Financial Cryptography andData Security, FC 2014, R. Bohme, M. Brenner,T. Moore, and M. Smith, Eds. Berlin, Heidelberg:Springer Berlin Heidelberg, 2014, pp. 221–234.

[28] J. Fan and F. Vercauteren, “Somewhat practicalfully homomorphic encryption,” Cryptology ePrintArchive, Report 2012/144, 2012, https://eprint.iacr.org/2012/144.

[29] “The GNU MP Bignum Library.” [Online].Available: https://gmplib.org/

[30] “NTL: A Library for doing Number Theory.”[Online]. Available: https://www.shoup.net/ntl/

[31] N. P. Smart and F. Vercauteren, “Fully homomor-phic simd operations,” Designs, Codes and Cryp-tography, vol. 71, no. 1, pp. 57–81, Apr 2014.

[32] C. Gentry, S. Halevi, and N. P. Smart, “Fullyhomomorphic encryption with polylog overhead,”in Advances in Cryptology – EUROCRYPT 2012,D. Pointcheval and T. Johansson, Eds. Berlin,Heidelberg: Springer Berlin Heidelberg, 2012, pp.465–482.

[33] S. Halevi and V. Shoup, “Bootstrapping for helib,”in Advances in Cryptology – EUROCRYPT 2015,E. Oswald and M. Fischlin, Eds. Berlin, Heidel-berg: Springer Berlin Heidelberg, 2015, pp. 641–670.

[34] S. Halevi, “HElib: An Implementation ofhomomorphic encryption.” [Online]. Available:https://github.com/shaih/HElib

[35] N. Kumar and Y. Singh, “Routing Protocolsin Wireless Sensor Networks,” Handbookof Research on Advanced Wireless SensorNetwork Applications, Protocols, and Ar-chitectures, pp. 86–128, 2017. [Online].Available: https://www.igi-global.com/chapter/routing-protocols-in-wireless-sensor-networks/162116

[36] X. Xian, W. Shi, and H. Huang, “Comparison ofOMNET++ and other simulator for WSN simula-tion,” in 2008 3rd IEEE Conference on IndustrialElectronics and Applications, Jun. 2008, pp. 1439–1443.

[37] “OMNeT++ Discrete Event Simulator - Home.”[Online]. Available: https://omnetpp.org/


ISBN: 978-1-941968-54-3 ©2018 SDIWC 13

http://standards.ieee.org/findstds/standard/802.15.6-2012.html

http://standards.ieee.org/findstds/standard/802.15.6-2012.html

https://doi.org/10.1007/978-3-8348-1990-1_5

https://doi.org/10.1007/978-3-8348-1990-1_5

https://brage.bibsys.no/xmlui/handle/11250/249681

https://brage.bibsys.no/xmlui/handle/11250/249681

https://eprint.iacr.org/2012/144

https://eprint.iacr.org/2012/144

https://gmplib.org/

https://www.shoup.net/ntl/

https://github.com/shaih/HElib

https://www.igi-global.com/chapter/routing-protocols-in-wireless-sensor-networks/162116



https://omnetpp.org/

[38] T. Boulis, “Castalia: An OMNeT-based simulatorfor low-power wireless networks such as WirelessSensor Networks and Body Area Networks.”[Online]. Available: https://github.com/boulis/Castalia


ISBN: 978-1-941968-54-3 ©2018 SDIWC 14

https://github.com/boulis/Castalia

https://github.com/boulis/Castalia

implementation and analysis of fully homomorphic ......implementation, healthcare system, fully...

Documents