enforcing patient privacy in healthcare wsns through key distribution algorithms

SECURITY AND COMMUNICATION NETWORKSSecurity Comm. Networks. 2008; 1:417–429Published online 28 August 2008 in Wiley InterScience(www.interscience.wiley.com) DOI: 10.1002/sec.40

Enforcing patient privacy in healthcare WSNs through keydistribution algorithms

Jelena Misic∗,† and Vojislav MisicUniversity of Manitoba, Winnipeg, Manitoba, Canada

Summary

Patient data privacy, as one of the foremost security concerns in healthcare applications, must be enforced throughthe use of strong cryptography. However, in the scenario where the patient wears a body network in whichlightweight, battery-operated wireless sensors monitor various health variables of interest, the requirements forstrong cryptography must often be balanced against the requirements for energy efficiency. In this paper, wedescribe two algorithms for key distribution. The first algorithm relies on a central trusted security server (CTSS)to authenticate that participants indeed belong to the patient’s group and to generate the session key. In the secondalgorithm, participants authenticate each other using certificates and are largely independent of the central trustedsecurity server (CTSS); this algorithm uses elliptic curve cryptography (ECC) to reduce energy consumption bycryptographic computations. In both cases, the patient’s security processor has a lead role in authenticating groupmembership and the key generation process. Using the data from commercial devices compliant with the IEEE802.15.4 low data rate WPAN technology, we show that this approach can be successfully implemented in networksbuilt with low power motes. Copyright © 2008 John Wiley & Sons, Ltd.

KEY WORDS: clinical information systems; key distribution algorithms; authentication; privacy

1. Introduction

Protection of integrity and privacy of patient’s healthdata must be ensured throughout the healthcareinformation system, in particular, in the context of aclinical information system in which patient’s data maybe collected through automated systems and/or in realtime. These general requirements translate into a num-ber of specific constraints. First, integrity and privacymust be upheld from the moment that data are collected,throughout the process by which data is stored in thepatient’s medical record and processed as necessary,and at all times afterward [1]. Access to that data should

*Correspondence to: Jelena Misic, University of Manitoba, E2-407, Winnipeg, Manitoba, Canada, R3T 2N2.†E-mail: [email protected]

be limited to the patient’s attending group of clinicians,which includes the patient’s attending clinician and theattending nurse [1,2]; other clinicians and/or nursesmay be allowed access as necessary, but their accessmust be limited only to the subset of data needed toreach qualified decisions regarding patient’s treatment.Furthermore, any treatment prescribed by the attendingclinician (or other clinicians, if appropriate) must beaccompanied by patient’s explicit consent. Finally, thepatient must be informed of any access to her record.As these requirements are far from trivial, discretionaryaccess control such as the one enforced through accesscontrol lists is not sufficient. Instead, it becomes

Copyright © 2008 John Wiley & Sons, Ltd.

418 J. MISIC AND V. MISIC

necessary to apply mandatory access control, supportedthrough appropriate cryptographic techniques, for boththe patient and the members of the attending group ofclinicians.

The problems of implementing access controls areparticularly hard when the edge component of a fullyconnected clinical information system consist of awireless sensor network (WSN) which the patientwears on her body. Such a WSN, often called a piconet,is built from lightweight, battery-operated deviceswhich monitor different health parameters (such asbody temperature, heartbeat rate, blood pressure, orother physiological variables of interest) and sendrelevant data to the dedicated piconet coordinator.The piconet coordinator is connected to the clinicalinformation system network through an access pointin a room or ward, which allows the patient’s healthdata collected from the sensors to be sent to the centraldatabase of the clinical information system in a timelyand reliable manner. Figure 1(a) shows the simplifiedarchitecture of such a clinical information system. Notethat access points are usually fixed, and thus mustbe shared not only among patients, but also amongclinicians and nurses (or, rather, their wireless devices)whenever they are within the transmission range of therespective access points.

In this scenario, the piconet coordinator ofthe patient’s body piconet must perform bothcommunications- and security-related functions. Thepiconet coordinator of the patient’s body networkfunctions as the patient security processor (PSP), whilstthe wireless devices of the principal clinician andnurse must possess dedicated security processors thatfunction as the clinician security processor (CSP),and nurse security processor (NSP), respectively.Together with a CTSS, the three security processorscollaborate to provide the security related functionality;in particular, they need to enforce the chosen accesscontrol policy (or policies). The security architecturedescribing the CTSS and three security processors isschematically shown in Figure 1(b).

Protection of data integrity and privacy necessitatesthe use of strong cryptography. However, thisrequirement must often be balanced against therequirement for energy efficiency, esp. in the casewhen the body network uses lightweight, battery-operated wireless sensors. In general, all cryptographicalgorithms necessary to support the desired set ofsecurity requirements must be carefully evaluated withrespect to their computational complexity as well asenergy efficiency. This is particularly important for keygeneration and distribution algorithms.

Fig. 1. Pertaining to the architecture of a clinical informationsystem. (a) Simplified network architecture. (b) Securityarchitecture: a patient and her attending group of clinicians.

It is worth noting that the application of wirelessnetworks in healthcare is attracting a lot of attentionsince it enables continuous surveillance of humanvital parameters without active involvement ofmedical personnel. Deployment of various networkingtechnologies in healthcare monitoring like cellularnetworks, wireless LANs, and WSN has beenconsidered in References [3–6]. However, securityissues in wireless networks when used in healthcarehave not attracted much attention, although healthcaresecurity policies have been described in Reference [2].Security of wireless healthcare systems using IPSecand secure socket laye (SSL) has been proposed inReference [7]. Recently security over WSNs usingclassical RSA-based cryptography has been discussedin Reference [8], but without considering energyconsumption of cryptographic algorithms.

In this paper, we discuss two algorithms forkey distribution. The first algorithm is a centralizedone which relies on the CTSS to authenticate theparticipants (i.e., to verify that they indeed belong

Copyright © 2008 John Wiley & Sons, Ltd. Security Comm. Networks. 2008; 1:417–429

DOI: 10.1002/sec

ENFORCING PATIENT PRIVACY IN HEALTHCARE WSNs 419

to the patient’s attending group of clinicians) andto generate the session key that will be used forsubsequent communications. In the second algorithm,participants (i.e., their respective security processors)authenticate each other using certificates, and are thuslargely independent of the central authority of the CTSSwhich nevertheless has to be informed of the new key soas to be able to use it. In both algorithms, the patient’ssecurity processor has a lead role in authenticatinggroup membership and the key generation process.The second algorithm uses elliptic curve cryptography(ECC), since it provides good protection at moderatekey sizes and thus leads to lower power consumptionthan the better known RSA [9,10].

Both algorithms are independent of the particulartechnology used for data communications, but theirapplicability in practice must be validated usingthe power consumption data of commercial devices.We have focused on the devices compliant withthe recently introduced IEEE 802.15.4 low data rateWPAN technology, which is often used to implementWSNs, and is thus a suitable candidate for theimplementation of the body piconets described above.Our results indicate that the second algorithm cansuccessfully be implemented with low power 802.15.4motes.

The paper is organized as follows. In Section 2, wepresent more details, from both network and securityperspective, about the architecture of the clinicalinformation system. Section 3 gives a brief overviewof ECC and low power CPU architectures runningIEEE 802.15.4 protocol stack. The centralized anddistributed key establishment protocols are describedin Section 4.1 and 4.2, respectively. Section 5 discussesenergy consumption of the proposed algorithms, whileSection 6 concludes the paper and discusses our futurework.

2. Clinical Information System:Architectural and Security Issues

In the architecture shown in Figure 1(b), theCTSS participates in the process of key generationbetween the patient and the group of clinicians. Thecentral medical database (DB) stores results of sensormeasurements from the body sensor network; thosemeasurements are authenticated, timestamped, andencrypted. CTSS and DB should be located at aphysically secure location.

As mentioned above, the coordinator of the patient’sbody sensor network (piconet) also functions as the

PSP . The PSP moves with the patient and monitorsall data communications. It also participates in the keygeneration protocol with the members of the attendinggroup of clinicians; this key is used to encrypt allpatient’s records prior to insertion in the DB. Thatsame key may be used to protect the communicationsbetween the PSP (in its capacity as the body piconetcoordinator) and the sensor devices in the piconet, asexplained in Section 4.3 below.

The PSP must be implemented on a trusted hardware,operating system, and application platform, since itcontrols all major functions of the patient’s bodypiconet. These functions include event detectionreliability of the sensing function; location report-ing which accompanies sensed data; and finally,power management, which monitors the traffic anddetermines sleep times for individual nodes in orderto maximize the network lifetime. Moreover, all ofthese functions must provide integrity, availability, andconfidentiality.

IEEE 802.15.4 networks operating in beacon-enabled mode with star topology suit this architecturewell, since their conceptual model supports manysensing nodes communicating directly with the piconet(cluster) coordinator [11]. In our case, the coordinatorembodies the functions of the data collecting device,bridge toward the access point and the rest of theclinical information system, but also those of the PSP.Individual network nodes contain a sensing subsystemwhich monitors the physiological parameters on thepatient’s body and collect the data, and the radiosubsystem which sends that data, authenticated andencrypted, to the coordinator/PSP which forwardsthem (possibly aggregated) to the room accesspoint.

The room access point is, in turn, connected tothe central medical record database, to which itforwards encrypted and authenticated patient datathrough a suitable wired or wireless network. Somedata aggregation may take place at the access pointas well. From the networking point of view, theaccess point is simply an interconnection device whichlinks personal area network technology used in thepatient’s body network to the hospital network.

The room access point is also used by the wirelessdevices that function as security processors for themedical personnel, in particular the clinician andnurse from the patient’s group of attending clinicians.From the application point of view, clinicians andnurses need to access the patient data and reportback the actions taken as part of the treatment.From the security standpoint, their respective security


DOI: 10.1002/sec


processors (CSP and NSP) need to authenticateother participants, encrypt data traffic, and participatein key generation and distribution together withthe PSP. Each security processor has a dedicatedsymmetric key which encrypts data communicationswith CTSS; we will denote these keys as kcc, kcn,and kcp, for clinician, nurse, and patient-owned keys,respectively.

Coexistence of several patients’ and clinicians’wireless devices (piconets and security processors)within the transmission range of each other is facilitatedby the availability of several RF channels in the802.15.4 standard—16 channels are available if the802.15.4 network operates in the ISM band at 2.4 GHz[11]. Alternative ways of sharing the RF spectrum arealso possible, that is, by using other WPAN standardssuch as Bluetooth [12] or 802.11 [13].

3. ECC and Hardware Platform forHealthcare WSNs

As healthcare WSNs are typically formed by low cost,battery operated devices, it is of utmost importance todeploy energy efficient cryptographic algorithms forprotecting the privacy and integrity of relevant data andcommunications in general.

Recently, ECC has been demonstrated as relativelycomputationally lightweight solution which providessecurity levels comparable to that of much better knownRSA. The main difference between integer-based andelliptic curve algorithm resides in the way in whichthe public key (e.g., for Diffie–Hellman exchange) iscomputed; it has implications on computational and, byextension, energy efficiency. In case of RSA, modularexponentiation of the private key is required; in case ofECC, a simpler scalar point multiplication (SPM) of thesecret key with selected base point on the elliptic curveis needed. The inverse operation, that is, the recoveryof the private key in ECC, given that the public key andthe base point are known, is known as the elliptic curvediscrete logarithm problem.

What makes ECC particularly well suited to theuse in healthcare WSNs is the fact that, for thesame level of security, it requires much smaller keysizes compared to RSA [9,10], as shown in Table I.Use of smaller keys results in faster key exchanges,user authentication, and digital signature generationand verification. Furthermore, smaller key size makethem more suitable for storage in limited memoryresources of wireless sensor nodes. First measurementsfrom eight-bit Atmel ATmega CPU architecture [14]

Table I. Key sizes giving equivalent security.

Algorithm

Integer ECC Symmetric key

512 106 641024 163 802048 210 112

reported in References [15,16] indicate a reduction ofcomputation time of almost 40%.

Efficiency of ECC cryptography in a WSN dependson the choice of elliptic curve parameters [10]and the computational capabilities of the hardwareplatform. The general form of elliptic curve equation isy2 + a1xy + a3y = x3 + a2x

2 + a4x + a6, whereai ∈F [10]. In this case, F is a Galois field over setsp or 2p, where p is a prime. An implementationover F2p is reported in Reference [15], while animplementation over Fp is reported in [17]. Hardwareplatforms which support elliptic curve SPM arealso rapidly evolving since general purpose eight-bitarchitectures are not very suitable for large integerbased arithmetic operations. For example, a recent16-bit microcontroller Tmote sky [18] uses 8 MHz,16-bit RISC microcontroller with maximal currentconsumption during computation (radio is off) of2.4 mA [18]; assuming a supply voltage of 3 V,this translates into power consumption of 7.2 mW.Alternatively, a dedicated hardware architecture can beused, as described in Reference [19], which supportselliptic curve operations and consumes 400 �W atclock frequency of 500 kHz. Also, a recent hardwareco-processor for ECC SPM was proposed offeringenergy consumption on 8-bit architecture of 1 mJper multiplication [20]. Nevertheless, the ECC SPMremains the most computationally expensive operationin the ECC based key exchange algorithm.

An ECC key length of 160 bit gives 80 bit ofequivalent symmetric key security and is probablysufficient for the whole network lifetime whichdoes not exceed couple of years. However, asindicated in Reference [21] and re-stated for WSNin Reference [22], the longer the key is used, thegreater the chance that it will be compromised, andconsequently the greater will be the loss caused by thatcompromise. Therefore, it is beneficial for the WSN toperiodically update the session key, but the problem is,then, how to generate a new session key and securelydistribute it to all the participants—in this case, theCTSS and the security processors of the patient and the


DOI: 10.1002/sec


members of her attending clinician’s group. Dependingon the period of key exchange, the length of the ECCkey may be reduced below 160 bit, which results infaster computation and lower energy consumption.

For improved privacy, it is recommended that eachentity should have two public/private key pairs, one ofwhich should be used for digital signature while theother should be used for symmetric key exchange [21].Keys for the digital signatures must last throughout theentire network lifetime, they should be at least 160 bitlong, and they should be stored in digital certificates.The same requirement holds for the key used by thecertifying authority (CA) that signs all the certificates,that is, the node signature keys. For signature, a suitablealgorithm such as the Elliptic Curve Digital SignatureAlgorithm (ECDSA [10] is used.

4. Key Generation for the PatientGroup

We assume that the patient group consists of theresponsible (principal) clinician, nurse, and the patientherself; it might contain more clinicians and nursesas well. No person from this group must have thecapability to derive the key without the participationof other members. As we mentioned previously, eachgroup member communicates with the CTSS using adedicated symmetric encryption key shared betweenits security processor and CTSS. Together, this smallgroup of users must interact with CTSS and generate adedicated secret session key, which we shall denotewith L. If the patient is unable to participate inthe decisions regarding her healthcare, then her partof the key generation must be undertaken by anauthorized proxy or by the central hospital authority. Inan emergency, the central hospital authority, togetherwith the responsible (principal) clinician, should beable to reconstruct the patient key. These details ofthese procedures are, however, beyond the scope ofthis paper.

The key will be used as encryption key of ansymmetric encryption system such as advanced en-cryption standard (AES) [1,21] which is supported byTmote sky devices [18]. The main reason for choosinga symmetric key-based protocol is performance;encryption using public key cryptography takes a longtime and generates high packet payload, which maybe a problem for existing wireless technologies andexisting low power sensor nodes.

The interaction between the clinician, the nurse,and the patient takes place in a number of sessions.

One session corresponds to a limited time periodduring which the membership of the access list usedto control access to the patient medical record remainsunchanged. When the contents of the access control listchange due to an addition or deletion of an authorizeduser, or perhaps because of updates for the rights of anexisting user, a new session must be created. A newsession is also created when the predefined time periodexpires. Each session uses a new secret session key,which is generated by the CTSS based on the datareceived from the group members. All measurementstaken by the sensors, as well as the observations,prescriptions, and recommendations made or taken bythe clinician(s), are encrypted by this key. The auditrecord for the session is further authenticated by thekey derived by the interaction of all group members.

Before the key is generated, mutual authenticationof the members of the patient’s group needs to beconducted, and the patient needs to be informedabout medical personnel involved in the healthcaresession. Therefore, PSP needs to receive and verifyidentities of CSP and NSP. This can be done in twoways: the first approach involves CTSS which willactually conduct the authentication on PSP’s behalf, aspresented in Section 4.1, and subsequently generate theshared session key. In the second approach, involvedparties can authenticate each other using certificates,and derive the session key with or without CTSSparticipation, as discussed in Section 4.2.

4.1. Mutual Authentication and KeyGeneration Using CTSS

One approach to mutual authentication, remotelysimilar to the classical one proposed in [23], involvesCTSS which assists in authenticating the parties. Letus denote concatenation of new session number n withidentities of participating nodes as:

IDs = n‖PSPid‖CSPid‖NSPid

PSP will also generate a random challenge randp,concatenate it with the new session number n anddevice IDs, and encrypt it with the secret key whichit shares with CTSS, to obtain the record:

Ap = {randp‖n‖PSPid‖CSPid‖NSPid}kcp

Protocol begins with PSP creating its authenticatingrecord

Bp = IDs‖Ap


DOI: 10.1002/sec


Fig. 2. Mutual authentication and session key distribution using keys shared with CTSS. (a) PSP distributes its authenticatingrecord. (b) CSP and NSP distribute their authentication records. (c) PSP forwards all authentication records to CTSS.

as shown in Figure 2(a), which includes the identitiesof all involved parties (PSPid, CSPid, and NSPid), itschallenge randp, and the session number n. One partof the record is encrypted with the secret symmetrickey kcp shared between PSP and CTSS, whichallows CTSS to determine that the authenticator isreally generated by PSP, and that PSP really intendsto communicate with NSP and CSP. Upon receiptof the session key generation request from PSP,CSP, and NSP will generate similar authenticatingrecords:

Ac = {randc‖n‖PSPid‖CSPid‖NSPid}kcc

and

An = {randc‖n‖PSPid‖CSPid‖NSPid}kcn

encrypted by their respective secret keys kcc and kcn.Then, they will concatenate them with the IDs recordreceived from PSP, and return the following recordsto PSP: Bc = IDs‖Ac and Bn = IDs‖An as shown inFigure 2(b). Note that the arrivals of authentication

records from CSP and NSP to PSP need not besynchronized in time and therefore no timestamps areneeded.

When PSP collects the authentication records Ac andAn, it knows that all parties are informed about groupmembership and forthcoming healthcare transaction,as shown in Figure 2(c). In order to make sure thatgroup membership will not be changed and that it willnot be removed from the list in the next steps, PSP willforward the request for the session key to the CTSS inthe following record:

Rq = n‖PSPid‖CSPid‖NSPid‖Ap‖Ac‖An

If the task of forwarding record R is not given to PSP,it might be possible for CSP and NSP to collude andforward only their authenticators, but without listingthe PSP or additional devices, to the CTSS, and thuscompromise the key generation process.

CTSS checks whether the contents of authenticationrecords list can be decrypted with the secret keysof the members whose IDs are listed. It furtherchecks whether group membership is the same in


DOI: 10.1002/sec


all authentication records. If these checks pass,CTSS generates a symmetric session key L andstores it together with the timestamp and IDsof the patient, clinician, and nurse. Then, CTSSconcatenates the session key L with the randomchallenge from each group member, and encrypts itwith the secret key shared with that group member.The results of this check, be they positive ornegative, are forwarded to all involved parties by theCTSS. Positive acknowledgement contains the sessionsequence number n and three concatenated key records.

Each key record contains the corresponding randomchallenge randp, randc, or randn, and the session keyL encrypted with corresponding secret key betweenCTSS and each involved party (kcp, kcc, or kcn), asfollows:

Rr = n‖{randp‖L}kcp‖{randc‖L}kcc‖{randn‖L}kcn

In the last step, presented in Figure 3(b), thePSP distributes appropriate session key records,n‖{randc‖L}kcc and n‖{randn‖L}kcn, to CSP and NSP,respectively. They decrypt the records with their secretkeys kcc and kcn, respectively. Upon comparing thereceived challenge with the original one, they canconfirm that the record has indeed been generated bythe CTSS. Note that any phase of this protocol canbe interrupted if the received records do not matchexpected format.

4.1.1. Security analysis

Use of node identity together with the secret keybetween node and CTSS prevents external attacks suchas false identity attack or replay attack, which mightlead into man-in-the-middle attack. False identityattack such as the Sybil attack [24], might originate

from a party impersonating the PSP, but it can notbe performed without knowledge of appropriate secretkey kcp. Replay attack might occur in two steps. Inthe first one, attacker may replay an old record fromPSP containing ID′

s‖Ap where he/she has changed thesession number n to n + 1. CSP and NSP will not beable to detect this attack and they will respond withtheir Bc and Bn records. However, when the attackerforwards Rq to the CTSS, all authentication recordswill be decrypted, which will reveal the use of theobsolete challenge in the Ap record. The second pointwhere an attack might be launched is when an attackerreplays an old request, Rq, for the session key tothe CTSS. However, this will not work since everysession key request has new challenges encrypted byappropriate secret keys. Upon detecting that an obsoletechallenge is used, the CTSS will cancel the session keyrequest.

It is worth noting that this approach for mutualauthentication with ensuring patient’s privacy does notrequire certificates, but relies on the secrecy of the keyskcp, kcc, and kcn instead. It also relies on the availabilityof networking channels between the CSP, NSP, andPSP, on one side, and the CTSS, on the other. It alsoputs computational burden on the CTSS which has toperform the actual authentication. Finally, it makes theCTSS the single most critical point of failure, since it isthe only entity authorized to generate the keys, whichmay or may not be acceptable for a clinical informationsystem. In the latter case, a decentralized approach suchas the one discussed in the next subsection may be moreappropriate.

Regarding internal attacks, we note that NSP andCSP cannot collude to generate the session key withoutPSP, since the consent of PSP is needed in thisalgorithm. It is also possible that any one of thenodes attempts to prevent the key generation process

Fig. 3. Mutual authentication and session key distribution using keys shared with CTSS. (a) CTSS sends session key record toPSP. (b) PSP forwards appropriate records to CSP and NSP.


DOI: 10.1002/sec


by withholding messages necessary in key generationprocess, in which case the CTSS will not get the requestfor key generation. Also, the PSP may not forward keyinformation to CSP and NSP. In both cases, the disputemust be solved off-band since PSP, NSP, and CSP areall considered trusted once they have obtained theirindividual secret keys with CTSS.

4.2. Scaled Multi-party SSL Protocol withEphemeral ECC Diffie–Hellman Key Exchange

Mutual authentication may also be accomplishedthrough an exchange of certificates among all parties.Note that classical X.509 RSA-1024 certificates areunsuitable for use in a WSN, since they have a length ofmore than 700 byte (for comparison, the largest payloadin an 802.15.4 packet is only about 127 byte [11]).However, WSNs allow the digital certificates to containonly identity (ID), public key, and hash of these fields,signed by a CA. In the clinical information systemapplication, the role of CA may be undertaken by theCTSS. The size of certificate can be further reduced byusing ECC, since the size of the ECC signature is equalto approximately two key sizes. For example, with ECCkeys of 160 bit, the certificate contains only 86 byte, asdemonstrated in [16], which fits comfortably in a singleIEEE 802.15.4 packet.

The algorithm proceeds as follows.

Step 1. Certificate exchange: In this step, PSP, CSP,and NSP exchange certificates, as shown inFigure 4(a). Certificates with signature keysneed to be exchanged whenever new personnelis added to the access list of the patient’srecord, or when a predefined time intervalhas elapsed after the last certificate exchange.Certificate contain public key for signatureverifications and node ID, followed by a hashof these fields signed by the CA. Privatesignature keys are denoted as ksp, ksc, and ksnfor PSP, CSP, and NSP, respectively.

Step 2. Exchange of challenges: In this step, PSP,CSP, and NSP exchange acknowledgementsfor certificates, as shown in Figure 4(b).If identity verification was successful, theauthenticator node (PSP, CSP, or NSP) willsend a positive acknowledgement followedby the new sequence number of the sessionand a new random challenge. If certificateverification was not successful at this point,any party can interrupt the protocol witha negative acknowledgement. If certificates

Fig. 4. Mutual authentication using ECC certificates.(a) Certificate exchange. (b) Exchange of acknowledgementswith challenges. (c) Request for the start of key generation

process.

have been exchanged relatively recently,some sessions might start without exchangingcertificates; however, a new sequence numberand random challenges need to be exchangedeach time when the session key needs to beupdated.

Step 3. Request to CTSS: If all parties havesubmitted positive acknowledgements, thePSP broadcasts request for session to CTSS,CSP, and NSP, as shown in Figure 4(c). Thecourse of action taken by the CTSS dependson how much autonomy should be given tothe PSP, CSP, and NSP. If fully autonomousoperation of PSP, CSP, and NSP is desirable,then the CTSS should merely note that newsession n is to be created between the threeof PSP, NSP, and CSP, and leave the keygeneration process entirely to the PSP, CSP,and NSP. In this case, PSP, NSP, and CSP


DOI: 10.1002/sec


should have all necessary information for keygeneration, and they should proceed withoutthe participation of CTSS, except for storingthe final key value.

However, there may be applications inwhich the CTSS ought to undertake asupervisory role in the key generation process.In this work we will discuss this, more generalscenario, in which the CTSS coordinateswith PSP, CSP, and NSP in key distributionprocess; the case with fully autonomous keygeneration is just a subset of it. We willillustrate this approach using the multi-partyDiffie–Hellman technique with ephemeral keyexchange, which is one of the suggestedapproaches for SSL handshake [1]. However,traditional SSL uses the classic Diffie–Hellman key exchange based on discretelogarithm problem [25]. In order to adapt it foruse in WSNs, it has to be translated to ellipticcurve discrete logarithm problem, as discussedin Reference [9,15].

Step 4. Base point distribution: In this step, shownin Figure 5(a), the CTSS sends to thePSP, CSP, and NSP the ECC base point G

encrypted with dedicated symmetric keys kcp,

Fig. 5. Distribution of the base ECC point and acknowledge-ment. (a) Distribution of base ECC point. (b) Confirmation.

kcc, and kcn, respectively (these keys protectcommunications between the CTSS and thePSP, CSP, and NSP, respectively). Note thatthe ECC base point may be pre-installed in thesecurity processors’ certificates, which meansthat it is constant during the lifetime of thecertificate.

Step 5. Confirmation of the reception of base point;The PSP, CSP, and NSP exchange the hashh(G‖randc‖randp‖randn) signed with theirprivate signature keys ksp, ksc, and ksn,respectively, as shown in Figure 5(b).

Step 6. Symmetric key generation: In this step, theshared symmetric key for the patient groupis generated. To reduce complexity, wedivide this step in four sub-steps, labeled 6-athrough 6-d.6-a. The PSP generates a private key kp and

a public key kp · G, and sends the publickey to the NSP, followed by the hash ofthree challenges concatenated with thebase point G and the public key, andencrypted with its private signature keyksp, that is,

sigp = {h((kp · G)||randc||randn||randp||G)}ksp

Analogous actions are taken by the NSPand CSP, as seen from Figure 6(a).

6-b. The PSP computes the scalar pointproduct kc · kp · G and sends this valueto the CSP, followed by the signature

sigp = {h((kp · kc · G)‖randc‖randn‖randp‖G)}ksp

Analogous actions are taken by the NSPand CSP, Figure 6(b).

6-c. Having learned about all three keys, thePSP computes kn · kc · kp · G and sendsthis value to the CTSS encrypted with thesecret symmetric key kcp which is sharedbetween the PSP and the CTSS. Thatsame value is sent by the CSP and NSP,except that their respective secret keysare used for encryption. These actionsare presented in Figure 6(c).

6-d. Finally, CTSS generates its own privatekey ks and computes the secret key as:

L = ks · kn · kc · kp · G

The key L will be sent to the PSP, CSP,and NSP, each time encrypted with


DOI: 10.1002/sec


Fig. 6. Symmetric key generation. (a) Distribution of public keys. (b) Distribution of products among the members. (c) Distributionof products to CTSS. (d) CTSS distributes the session key.

their respective secret keys, kcp, kcc,and kcn. These actions are presented inFigure 6(d).

4.3. Maintenance of the Session Key

The CTSS stores the session key L together with thetimestamp and ID’s of the patient, clinician and nurse.Patient data encrypted with this key can be accessedonly by the clinician and the nurse who participatedin key generation. The session key is also assigned alifetime by the CTSS, which means that it has to be re-computed when the lifetime expires. The session keyhas to be re-computed (i.e., a new session key has tobe generated) whenever the responsible clinician addsother clinicians to the access list of the patient record.In this case, the new session key has to be generatedwith the participation of all members of the access list,including the patient herself, which will require herconsent. When the new session key is computed, thevalue of the old session key has to be stored in thepatient record, but encrypted with the new session key.

Data packets are authenticated by using keyed-hashmessage authentication code (HMAC) [1]. For hashfunction, which will be denoted as H , we can adoptthe secure hash algorithm (SHA) [26]. Let us denote

the ith packet containing measurements of some healthvariable as Pi, the timestamp which records the time ofpacket generation as Ts,i, its medium access controlheader as Ai, and its payload as Di. The packetauthentication code for packet i, PACi, can then becalculated as:

PACi = H((L ⊕ opad)‖H(L ⊕ ipad‖Ai‖Ts,i‖Di)

)

4.4. Distribution of the Session Key

When the session key L is calculated, the PSP has todistribute it securely to the wireless sensor nodes in itspiconet. When the patient WSN begins operating, thePSP and each node exchange certificates with signaturekeys and challenges. Certificates with signature keysneed to be exchanged only once during the lifetime ofthe node. On the other hand, new challenges need tobe exchanged each time when the session key needsto be updated. In the next step, PSP sends the newsession key L[n] encrypted with the previous sessionkey L[n − 1] (here n denotes index of key exchangecycle). These data are authenticated by concatenatingit with the signature:

sigp = {h(L[n]‖L[n − 1]‖randp‖randi)}ksp


DOI: 10.1002/sec


where randp denotes the challenge sent by the PSP,while randi denotes the challenge sent by wirelessnode ni.

4.5. Security Analysis

External attacks, such as false identity attack froma node impersonating the PSP, are prevented by theexistence of the secret signature key and certificatecontaining public signature key signed by CA. Replayattack may be launched (and prevented) in variousphases of the algorithm. First, an attacker might try toreplay the message in which the PSP distributes requestfor base point associated with session number to allparties, or the message in which the CTSS distributesthe base point associated with session number toall parties encrypted with appropriate secret keys.However, the replay messages will not be preceded bya legitimate request from the PSP, and other nodes willdetect the repeated base point and session number. Anode that detects such a replay attack will distribute thisinformation to all the others in step 5, confirmation ofthe reception of base point.

Second, during symmetric key generation, randomchallenges are included in the signature at the end ofeach message. Therefore, steps 6-a and 6-b cannot bereplayed without being detected.

Finally, step 6-c cannot be replayed to CTSS at somelater time since CTSS has to be informed about the startof the algorithm and about the request for the base point.

Internal attacks can be formed if NSP and CSP cancollude to generate symmetric key without the PSP.However, in this algorithm the PSP initiates request fora base point to CTSS; this request contains identities ofall involved nodes, sequence number of the session, andis signed with PSP’s private signature key. Therefore,PSP must participate in key generation.

5. Analysis of Energy Consumption

Let us now estimate the energy consumption of thefirst, centralized algorithm for key generation. For

energy consumption of hashing, we have scaled resultsfrom [16] derived for eight-bit microcontroller ATMELATmega128L using relationships between Telos andMICA2DOT reported in [27] and further comparisonof data sheets for Telos and Tmote sky. We haveadopted the energy consumption for the calculationof SHA-1 hash value to be 0.814 �J/byte. For energyconsumption of encryption/decryption operation wehave scaled the numbers reported in Reference [16]to 0.25 �J/byte for encryption and 0.39 �J/byte fordecryption.

For comparison purposes, Table II gives the energyconsumption of a Tmote sky mote operating in theISM band [18]. For reference, transmission powerof 0 dBm allows the transmission range of about50 m indoors and up to 125 m outdoors, dependingon terrain conditions. The impact of collisions,interference, and noise is not taken into account;more details can be found in [28]. Values in theTable are calculated for the nominal supply voltageof 2.85 V, which can be supplied by standard1.5 V batteries. Battery capacity depends on theimplementation: typical values for AA batteriesare 400 to 900 mAh (milli-Amp-hours) for zinc–carbon batteries, and about 40–60% more for zinc–chloride batteries or rechargeable nickel–cadmiumones.

These results show that the energy expenditureof security computations, as seen from the PSP orone of its sensor nodes, is minuscule compared tothe energy expenditure of data communication (inparticular, reception).

However, our second, decentralized algorithm relieson public key cryptography which is computationallymore demanding. Public key computation, shared keycomputation, and digital signature generation willrequire one ECC-SPM each, while digital signatureverifications takes two SPM [15,20]. Since theanalysis from [27] is based on the TelosB [29] mote,which uses the same microcontroller as Tmote skybut consumes 4 mA, we have used the results forenergy consumption from [27] scaled with factor 0.6;therefore, we assumed that an ECC spm takes 0.5 s

Table II. Current and energy consumption for the Tmote sky mote.

Operating mode of the radio subsystem Energy consumption at 2.85 V supply voltage (per byte, without collisions)

Transmitting at 0 dBm 1.58 �JTransmitting at −3 dBm 1.38 �JReceiving 1.79 �JSwitched off (idle) 1.82 nJ


DOI: 10.1002/sec


and consumes 3.6 mJ. We estimated time and energyfor signature generation on Tmote sky as 0.52 s and3.75 mJ, while 1.02 s and 7.44 mJ are needed forsignature verification [27].

The phase which concerns the distribution ofbase ECC point requires symmetric key decryptionby each node; this consumes several dozen of �J.The phase with confirmation, Figure 5(b), requiresone digital signature generation and two digitalsignature verifications, for a total of five ECC-SPM.The phase with public key distribution, Figure 6(a), willhave one public key computation, one digital signaturegeneration, and one digital signature verification pernode. This results in four SPM per node, for eachof the PSP, CSP, and NSP. The phase in whichintermediate key products are distributed will requirethe same number of SPM per node as shownin Figure 6(b). Distribution of products depictedin Figure 6(c) requires one SPM and symmetrickey encryption per node. Finally, the last phasedepicted in Figure 6(c) requires only symmetric keydecryption by each node. Therefore, using Tmote skymicrocontrollers, one key distribution cycle roughlytakes 14 SPM or 52.5 mJ. This value is much higherthan in the first algorithm, and in fact is muchhigher than the communication cost. This should comeas no surprise, given that the main burden of keygeneration in the first algorithm rests on the CTSS,which operates from a virtually infinite power source,while the second algorithm relies on computationallydemanding actions executed by the security processorsthemselves.

Obviously, the number of confirmations, interme-diate products and cycles to distribute them, and thetotal energy consumption, will depend on the numberof participants—that is, the number of members on theaccess list for the patient record.

6. Conclusion

In this paper, we have developed two algorithmsfor key distribution which can be used in healthcareWSNs in order to enforce patient’s privacy. The firstalgorithm relies on a CTSS to approve membershipin the patient’s group and to generate the sessionkey. In the second algorithm, participants are lessdependent on the CTSS, and can authenticate eachother using certificates. In both algorithms the patient’ssecurity processor has insight into group membershipand leads the key generation process. Both algorithmshave pros and cons: for example, the first algorithm

is more communication intensive, esp. toward theCTSS, which makes CTSS a central point of failure.The second algorithm has to bear the computationalburden of public key cryptography. In order to ease thisburden, we propose to use elliptic curve cryptographywhich leads to reduced energy consumption requiredby cryptographic computations. Using the energyconsumption data for a commercial 802.15.4 sensormote with a low power microcontroller, we haveevaluated the energy consumption of the second,decentralized algorithm. The results show that the useof public key cryptography is feasible and that theproposed algorithm can be safely used in practicalapplications.

Acknowledgement

This research is partly supported by the NSERCStrategic Grant.

References

1. Bishop M. Computer Security—Art and Science. PearsonEducation, Inc.: Boston, MA, 2003.

2. Anderson RJ. A security policy model for clinical informationsystems. IEEE Symposium on Security and Privacy, Oakland,CA, May 1996; 34–48.

3. Stankovic JA, Cao Q, Doan T, Fang L, He Z, Kiran R.Wireless sensor networks for in-home healthcare: potentialand challenges. High Confidence Medical Device Software andSystems (HCMDSS), 2005.

4. Jovanov E, Milenkovic A, Otto C, de Groen PC. A wirelessbody area network of intelligent motion sensors for computerassisted physical rehabilitation. Journal of NeuroEngineeringand Rehabilitation, 2005; 2: 1–10.

5. Varshney U. Patient monitoring using infrastructure-orientedwireless LANs. International Journal of Electronic Healthcare,2006; 2: 149–163.

6. Sneha S, Varshney U. A wireless ECG monitoring systemfor pervasive healthcare. International Journal of ElectronicHealthcare, 2007; 2(1): 32–50.

7. Marti R, Delgado J. Security in a wireless mobile health caresystem. MobEA Emerging Applications for Wireless and MobileAccess, 2003.

8. Misic J, Misic VB. Implementation of security policy for clinicalinformation systems over wireless sensor networks. Ad HocNetworks, 2007; 5: 134–144.

9. Fiskiran A, Lee R. Workload characterization of ellipticcurve cryptography and other network security for constrainedenvironments. WWC-5, 2002; 127–137.

10. Hankerson D, Menezes A, Vanstone S. Guide to Elliptic CurveCryptography. Springer-Verlag: New York, 2004.

11. IEEE. Wireless MAC and PHY specifications for low rateWPAN. IEEE Std 802.15.4-2006. IEEE: New York, NY,2006.

12. Misic J, Misic VB. Performance Modeling and Analysis ofBluetooth Networks: Network Formation, Polling, Scheduling,and Traffic Control. CRC Press: Boca Raton, FL, 2005.


DOI: 10.1002/sec


13. O’Hara B, Petrick A. IEEE 802.11 Handbook: A Designer’sCompanion. IEEE Press: New York, NY, 1999.

14. Atmega128(l)—8-bit AVR microcontroller with 128k bytes in-system programmable flash. Datasheet, ATMEL Corporation,2006.

15. Malan DJ, Welsh M, Smith MD. A public-key infrastructure forkey distribution in TinyOS based on elliptic curve cryptography.SECON 2004, 2004; 71–80.

16. Wander AS, Gura N, Eberle H, Gupta V, Shantz SC.Energy analysis of public-key cryptography for wireless sensornetworks. PerCom 2005, March 2005; 324–328.

17. Großschadl J. TinySA: a security architecture for wireless sensornetworks. In Proceedings of CoNEXT 2006, 2006.

18. Moteiv. Tmote sky low power wireless sensor module, 2006.19. Gaubatz G, Kaps J-P, Ozturk E, Sunar B. State of the art in ultra-

low power public key cryptography for wireless sensor networks.PerCom 2005 Workshops, 2005; 146–150.

20. Bertoni G, Breveglieri L, Venturi M. Power aware design ofan elliptic curve coprocessor for 8 bit platforms. PerCom 2006Workshops, March 2006.

21. Schneier B. Applied Cryptography (2nd edn). John Wiley &Sons, Inc.: New York, NY, 1996.

22. Arazi B, Elhanany I, Arazi O, Qi H. Revisiting public-keycryptography for wireless sensor networks. IEEE Computer2005; 38(11): 103–105.

23. Otway D, Rees O. Efficient and timely mutual authentication.Operating Systems Review 1987; 21(1): 8–10.

24. Newsome J, Shi E, Song D, Perrig A. The Sybil attack insensor networks: analysis and defenses. Proceedings of IEEEInternational Conference on Information Processing in SensorNetworks (IPSN 2004), Berkeley, CA, 2004; 259–268.

25. Diffie W, Hellman ME. New directions in cryptography.IEEE Transactions on Information Theory 1976; IT-22(6):644–654.

26. NIST. Digital Signature Standard. US Department ofCommerce, Gaithersburg, MD, 1994.

27. Piotrowski K, Peter S. How public key cryptography influenceswireless sensor node lifetime. Fourth ACM Workshop on Securityof Ad Hoc and Sensor Networks, 2006; 169–176.

28. Misic J, Misic VB. Wireless Personal Area Networks:Performance, Interconnections, and Security with IEEE802.15.4. John Wiley & Sons: New York, NY, 2008.

29. TelosB mote platform datasheet. Mote datasheet, CrossBowTechnology, 2006.


DOI: 10.1002/sec

enforcing patient privacy in healthcare wsns through key distribution algorithms

Documents