pacemakers and implantable cardiac deﬁbrillators: software … · pacemakers and implantable...

Pacemakers and Implantable Cardiac Defibrillators:Software Radio Attacks and Zero-Power Defenses

Daniel Halperin†University of Washington

Thomas S. Heydt-Benjamin†University of Massachusetts Amherst

Benjamin Ransford†University of Massachusetts Amherst

Shane S. ClarkUniversity of Massachusetts Amherst

Benessa DefendUniversity of Massachusetts Amherst

Will MorganUniversity of Massachusetts Amherst

Kevin Fu, PhD∗

University of Massachusetts AmherstTadayoshi Kohno, PhD∗

University of WashingtonWilliam H. Maisel, MD, MPH∗

BIDMC and Harvard Medical School

Abstract—Our study analyzes the security and privacy prop-erties of an implantable cardioverter defibrillator (ICD). Intro-duced to the U.S. market in 2003, this model of ICD includespacemaker technology and is designed to communicate wirelesslywith a nearby external programmer in the 175 kHz frequencyrange. After partially reverse-engineering the ICD’s communi-cations protocol with an oscilloscope and a software radio, weimplemented several software radio-based attacks that couldcompromise patient safety and patient privacy. Motivated byour desire to improve patient safety, and mindful of conventionaltrade-offs between security and power consumption for resource-constrained devices, we introduce three new zero-power defensesbased on RF power harvesting. Two of these defenses are human-centric, bringing patients into the loop with respect to the securityand privacy of their implantable medical devices (IMDs). Ourcontributions provide a scientific baseline for understanding thepotential security and privacy risks of current and future IMDs,and introduce human-perceptible and zero-power mitigationtechniques that address those risks. To the best of our knowledge,this paper is the first in our community to use general-purposesoftware radios to analyze and attack previously unknown radiocommunications protocols.

I. INTRODUCTION

Wirelessly reprogrammable implantable medical devices(IMDs) such as pacemakers, implantable cardioverter defibril-lators (ICDs), neurostimulators, and implantable drug pumpsuse embedded computers and radios to monitor chronic disor-ders and treat patients with automatic therapies. For instance,an ICD that senses a rapid heartbeat can administer an elec-trical shock to restore a normal heart rhythm, then later report

∗Corresponding faculty authors:• Kevin Fu, Medical Device Security Center, Department of Computer

Science, University of Massachusetts Amherst, 140 Governors Drive,Amherst, Massachusetts 01003 ([email protected]);

• Tadayoshi Kohno, Medical Device Security Center, Department of Com-puter Science and Engineering, University of Washington, Box 352350,Seattle, Washington 98195 ([email protected]);

• William H. Maisel, Medical Device Safety Institute, Beth Israel Dea-coness Medical Center, Harvard Medical School, 185 Pilgrim Road,Baker 4, Boston, MA 02215 ([email protected]).

Additional information online at http://www.secure-medicine.org.†Co-student leads listed in alphabetical order; each participated equally.

this event to a health care practitioner who uses a commercialdevice programmer1 with wireless capabilities to extract datafrom the ICD or modify its settings without surgery. Between1990 and 2002, over 2.6 million pacemakers and ICDs wereimplanted in patients in the United States [19]; clinical trialshave shown that these devices significantly improve survivalrates in certain populations [18]. Other research has discussedpotential security and privacy risks of IMDs [1], [10], but weare unaware of any rigorous public investigation into the ob-servable characteristics of a real commercial device. Withoutsuch a study, it is impossible for the research community toassess or address the security and privacy properties of past,current, and future devices. We address that gap in this paperand, based on our findings, propose and implement severalprototype attack-mitigation techniques.

Our investigation was motivated by an interdisciplinarystudy of medical device safety and security, and relied ona diverse team of area specialists. Team members fromthe security and privacy community have formal trainingin computer science, computer engineering, and electricalengineering. One team member from the medical communityis a practicing cardiologist with hundreds of pacemaker andimplantable defibrillator patients and was past chairpersonof the FDA’s Circulatory System Medical Device AdvisoryPanel. Our technical contributions toward understanding andimproving the security, privacy, and safety of these devicesinclude: analyses; software radio-based methodologies; andhuman-perceptible and zero-power (battery-free) defenses.

Overview of contributions. We assess the security and pri-vacy properties of a common ICD and present attacks onprivacy, integrity, and availability. We show that the ICDdiscloses sensitive information in the clear (unencrypted);we demonstrate a reprogramming attack that changes theoperation of (and the information contained in) the ICD; and

1The reader should not confuse the term “device programmer” with a personwho programs computers. The former is an external device that communicateswith and adjusts the settings on an IMD.

This paper, copyright the IEEE, will appear in the proceedings of the 2008 IEEE Symposium on Security and Privacy. 1

we give evidence that a battery-powered ICD can be madeto communicate indefinitely with an unauthenticated device,thereby posing a potential denial-of-service risk. All of ourattacks can be mounted by an unauthorized party equippedwith a specially configured radio communicator within rangeof the ICD. In our experiments, we performed attacks fromdistances up to several centimeters; we did not experimentwith increasing this range. We also present prototype defensesagainst the attacks we describe.

Developing these attacks and defenses required some un-derstanding of relevant devices and protocols. We give anaccount of our attempts to reverse-engineer communicationsto and from the ICD using a commercial ICD programmerand a software radio; we believe that this work is the first inour community to successfully use general purpose softwareradios in the reverse engineering of wireless protocols for secu-rity analysis. Information directly available from RF signals,given knowledge gained from reverse engineering, includespatient information (such as name and diagnosis) and medicaltelemetry (information about vital signs); we demonstrate thisbreach of privacy by showing redacted transmissions. Wealso demonstrate active attacks on device integrity whereinan unauthorized software radio transmitter (or unauthorizedexternal programmer) that follows a certain protocol canchange information on the ICD, including therapy settingsthat determine when the device should administer an electricshock; the unauthorized radio transmitter can also make theICD issue a commanded electrical shock. Finally, we describeour discovery that an attacker can keep an ICD in a stateof elevated energy consumption, thereby potentially depletingbattery life and threatening availability. Table I provides asummary of our attacks and their implications.

With the above attacks in mind, we present prototypedefenses against them. Our defenses comprise three differentdeterrence and prevention mechanisms that sit at the interfacebetween an ICD and the outside world. Our defenses do notrequire battery power and therefore may require only mini-mal design changes to future implantable devices. We referto these mechanisms as zero-power defenses to emphasizethat they draw no energy from the primary battery, insteadharvesting RF energy from an external source. Zero-powernotification audibly warns a patient of security-sensitive eventsand can help mitigate the risk of attacks both by outsiderswho have custom equipment (like our software radio-basedattack system) and by insiders who have access to commercialICD programmers. Zero-power authentication uses symmetriccryptographic techniques to prevent unauthorized access; itaims to protect against adversaries who have custom equip-ment. Finally, sensible security combines elements of zero-power notification and authentication by allowing patientsto physically sense an acoustic key exchange. We show theeffectiveness of these defenses by measuring the performanceof our prototype zero-power system, WISPer, which is a WISPUHF RFID tag [25], [27] augmented with a piezo-element.(Notationally, although WISPer is batteryless and is basedon RFID technologies, the term passive does not accurately

characterize the radio conversation that takes place.)Our study examines a single Medtronic Maximo DR VVE-

DDDR model #7278 ICD. This model, introduced to the U.S.market in 2003 [21], is a typical ICD: it incorporates pacemak-ing (steady, periodic electrical stimulation) and defibrillation(single large shock) functions, and it communicates with anexternal device programmer at a range of several centimeters.

Implications, challenges, and broader issues. Our studyfocuses on a single ICD, and therefore provides only a smallsnapshot in the evolution and breadth of ICD technologiesand more general implantable medical devices. Nevertheless,we believe that this snapshot is necessary toward assessingthe current trajectory of IMD security and privacy. We hopethat the analyses and defenses presented in this paper willmotivate broader scientific investigations into how to bestprovide security, privacy, safety, and effectiveness for futureimplantable medical devices. Improving IMD security andprivacy is, however, significantly challenging due to rapidlyevolving threat models, trends toward longer-range wirelesscommunication, explorations into multi-agent systems of inter-communicating IMDs [4], [7], [33], and resource constraintsof an IMD’s battery, processor, and memory. Moreover, as wepreviously observed [10], there is tension between security(restricted access) and safety (open access in emergencyscenarios); the zero-power notification portion of our WISPerprototype aims to address this tension.

Attack scenarios. Since health care is a very sensitive andpersonal subject for many people, we explicitly choose to de-viate from standard practice in the academic security researchcommunity and do not describe specific scenarios in which anattacker might compromise the privacy or health of a victim.We also do not discuss the potential impact on patients if anadversary were to carry out an attack in vivo. Rather, whendiscussing attacks we focus solely on the technical propertiesof those attacks. In addition, in each case where we identify avulnerability, we propose a solution or technical direction tomitigate it.

Context. Pacemakers, ICDs, and other implantable medicaldevices have improved and saved innumerable lives. To ourknowledge, no IMD patient has ever been harmed by amalicious security attack. While our research demonstratesthat such a scenario is possible, our goals in conducting thisresearch are to: (1) demonstrate that IMD security and privacyvulnerabilities exist; (2) propose solutions to the identifiedweaknesses; (3) encourage the development of more robustsecurity and privacy features for IMDs; and (4) improve theprivacy and safety of IMDs for the millions of patients whoenjoy their benefits. This paper, which focuses on a single ICDand our zero-power defenses, should be read in concert withour previous work [10], which surveys the potential securityand privacy issues for broad classes of IMDs independent ofany particular IMD technology.

Disclosure. In light of the rapid advances and changes in ICDtechnology, we conducted this scientific investigation with the


Commercial Software radio Software radio Primaryprogrammer eavesdropper programmer risk

Determine whether patient has an ICD 4 4 4 PrivacyDetermine what kind of ICD patient has 4 4 4 PrivacyDetermine ID (serial #) of ICD 4 4 4 PrivacyObtain private telemetry data from ICD 4 4 4 PrivacyObtain private information about patient history 4 4 4 PrivacyDetermine identity (name, etc.) of patient 4 4 4 PrivacyChange device settings 4 4 IntegrityChange or disable therapies 4 4 IntegrityDeliver command shock 4 4 Integrity

TABLE IRESULTS OF EXPERIMENTAL ATTACKS. A CHECK MARK INDICATES A SUCCESSFUL IN VITRO ATTACK.

goal of understanding and addressing the potential securityrisks of ICDs before future ICDs and other IMDs becomemore complex and the potential security and privacy risks topatients increase. However, we also firmly believe in disclosingthis information in an ethical manner that fully considers thewell-being of patients. We specifically and purposefully omitdetails that would allow someone to use this article as a guidefor creating attacks against ICDs.

Paper organization. Section II gives a brief introductionto ICDs, describes the security model we consider in thiswork, and summarizes related work. Section III discussesthe process of intercepting and reverse-engineering an ICD’swireless communications, beginning with RF signal analysisand culminating in readable plaintext. Section IV discussesreplay attacks that compromise device integrity by changingstored information or therapy settings. Section V extends thediscussion of zero-power defenses into the realm of devicedesign. Finally, Section VI offers concluding remarks.

II. BACKGROUND, MODEL, AND RELATED WORK

This section summarizes the characteristics and medicalusage of a modern implantable cardioverter defibrillator. It alsointroduces some of the equipment we used in our analyses.Following this introduction, we construct a security model thatclassifies potential adversaries in terms of their capabilities.Finally, we summarize previous research that motivates andinforms the methods and results of this work.

A. Implantable Cardioverter Defibrillators (ICDs)

An implantable cardioverter defibrillator (ICD) is a devicethat monitors and responds to heart activity. ICDs have modesfor pacing, wherein the device periodically sends a smallelectrical stimulus to the heart, and for defibrillation, whereinthe device sends a larger shock to restore normal heart rhythm.A physician surgically implants the ICD below the patient’sclavicle and close to the skin (Fig. 1). The physician alsoimplants electrical leads that connect the ICD to the heartmuscle. Post-surgery, a health care practitioner can use anexternal programmer to perform diagnostics, read and writeprivate data, and adjust therapy settings. A malfunctioning ormaliciously configured ICD could harm a patient in multiple

Fig. 1. Chest xray image of an implanted ICD (top right, near shoulder,solid outline) and electrical leads connected to heart chambers (center of ribcage, dotted outline).

ways, including by inaction (failure to deliver treatment whennecessary) or by extraneous action such as a command shockwhen the heart is beating normally.

Magnetic switch. Inside the ICD is a magnetic switch.A magnetic field in proximity to this switch causes it toclose, which in turn causes the ICD to wirelessly transmittelemetry data, including electrocardiogram (EKG) readings.(We discovered, however, that we can activate transmission oftelemetry on our ICD solely with an RF command and withoutthe presence of a magnet; see Section IV.) In a clinical setting,the magnetic field comes from a magnet in the programminghead, which is the component of the programmer that is placedin proximity to a patient’s implanted ICD. At the surface ofone programming head we measured this magnet at 700 gauss.

Wireless communications. Our ICD wirelessly communicateswith the external programmer using the 175 kHz band, whichis intended for short-range communications. Newer ICDscan communicate at both the 175 kHz frequency and in


the 402–405 MHz Medical Implant Communications (MICS)band [26], the latter intended for longer-range communica-tions. One motivation for incorporating longer-range com-munications in new ICDs is that doing so provides greaterflexibility in both clinical and home settings; for example,a patient’s ICD could transmit data to an at-home monitorwhile the patient sleeps. (The specific communication rangesin Section I and throughout this paper are for the commercialICD programmers we used in our experiments. We did notexperiment with increasing the communications ranges of theICDs.)

Diversity in IMDs. When considering implantable medicaldevice security and privacy, it is important to draw distinc-tions between classes of devices that have different physicalproperties and healthcare goals. This paper discusses ICDs andpacemakers together because they are common devices withoverlapping functions and similar operating environments.

Designers of IMDs make design decisions based in parton the fundamental properties of the problems the devicesaddress. Some IMDs, like modern ICDs and pacemakers, areentirely self-contained with respect to power and connectiv-ity. They are designed to last for several years, use non-rechargeable internal batteries, and have no physical connec-tions (e.g., tubes) outside the body. Other IMDs with compu-tational capabilities are more exposed, like cochlear implants,and are designed to last for the patient’s entire lifetime. Suchdevices might utilize externally worn, rechargeable batteriesor, like insulin pumps, might have tubes leading outside thepatient. These external channels and recharging requirementscould potentially make such devices susceptible to humanerror. While non-computational implantable devices exist, suchas artificial joints, this paper considers only those IMDs thathave computational capabilities.

B. Security Model

Our research focuses on evaluating and improving the secu-rity and privacy of communication between ICDs and externalICD programmers. We consider attacks by three classes ofadversaries (see also Table I):

• An adversary with a commercial ICD programmer, i.e.,an external device commercially produced and marketedfor use with ICDs. At least for the programmers withwhich we have experimented, there are no technologicalmechanisms in place to ensure that programmers can beoperated only by authorized personnel.

• A passive adversary who eavesdrops on communicationsbetween the ICD and a commercial programmer. This ad-versary can record RF messages output by ICDs and pro-grammers. This adversary might use standard or custom-built equipment, including oscilloscopes, software radios,amplifiers, and directional antennas.

• An active adversary who extends the passive adversarywith the ability to generate arbitrary RF traffic, not nec-essarily conforming to the expected modulation schemesor FCC regulations. This attacker may interfere with

legitimate transactions or create spurious ones by, e.g.,spoofing a commercial programmer.

For the purposes of this research we assume that ICDs are hon-est and that they attempt to follow the protocols as specified;we do not experiment with adversarial actions that employ(possibly fake) ICDs to compromise or otherwise adverselyaffect the operation of commercial programmers.

C. Related Work

Past research has investigated the challenges of manufac-turing and providing safe computer-based medical treatmentsin the presence of unintentional failures (e.g., accidents inradiation treatments from the Therac-25 [16]). Our work fromthe perspective of security and privacy investigates how toprovide safety and effectiveness in the presence of intentionalfailures. In the more general study of medical device security,some research focuses on securing patient data in a medicaldatabase [22]. Work by Venkatasubramanian and Gupta [31]has focused on pervasive health care security, including secu-rity involving medical sensors. Our earlier work [10] surveysa wide range of IMD security issues, including the needto balance IMD security and privacy goals with safety andeffectiveness goals. In contrast, our current study is based onthe systematic and pragmatic analysis of the security of a real,commercial device.

There is also a body of research studying wireless securityin low-power environments, especially in the areas of sensornetworks [13], [23] and wireless body area networks [32]. Incontrast with these works, our zero-power security approacheseliminate the stored-energy overhead of cryptography. Chae etal. [2] also used RF power to implement RC5 on the WISP;we leverage their work in the context of medical devices andextend it with the new techniques of zero-power notificationand zero-power human-sensible key exchange. A separate ap-proach to our sensible key exchange uses physiological valuesas keys [3]. The notion of plaintext key exchange via physicalcontact appears in work by Stajano and Anderson [29]. Ourwork extends that notion by allowing key exchange to occurover an acoustic, rather than an electrical, channel.

Previous research, such as that of Goodrich et al. [8] andMcCune et al. [20], considered cryptographic operations, likekey agreement and authentication, that involved human actiondirected by sensory input. Our work sets a different goal,namely patient notification as a side-effect of a cryptographicoperation, and accomplishes it through a combination ofauditory and tactile feedback.

Finally, there is work using software radios to receivetransmissions from commercial wireless protocols, such asBlueSniff [28] and the A5 Cracking Project [15]. Our workfurther demonstrates the utility of software radios by usingthem to help reverse-engineer and then participate in previ-ously unknown radio protocols. Earlier work that analyzedradio transmissions of RFID-enabled credit cards [11] reliedon similar reverse-engineering techniques, but the radio wasbuilt on a Gumstix embedded Linux system rather than on thegeneral-purpose Universal Software Radio Peripheral (USRP).


Fig. 2. Equipment used in our experiments. At top is a 4 GSa/s oscilloscope.At bottom, from left to right, are: our eavesdropping antenna, an ICD, ourtransmitting antenna (mounted on cardboard), and a USRP with a BasicTXcard attached.

III. INTERCEPTING ICD COMMUNICATIONS

We combined several reverse-engineering and eavesdrop-ping techniques to intercept, understand, and extract infor-mation from the communications between our ICD and acommercial programmer. Our results show that wireless trans-missions disclose private data.

We used two hardware tools to intercept the radio frequency(RF) signals emitted by the ICD and the programmer: a record-ing oscilloscope and a Universal Software Radio Peripheral(USRP) [5]. The oscilloscope is standard lab equipment; theUSRP is a programmable device that interacts with open-source GNU Radio [30] libraries on a host PC. Section III-D1describes the equipment in more detail and Fig. 2 shows apicture.

A. Reverse-Engineering Transmissions

We began by capturing RF transmissions around 175 kHz.Using an oscilloscope, we were trivially able to identify trans-missions from our ICD and the commercial ICD programmer.We saved traces from both the oscilloscope and the USRP. Weprocessed these RF traces in software (using Matlab and theGNU Radio toolchain) to recover symbols, then bits. Finally,by analyzing these bits we discovered key aspects of the ICD’sprotocols and the data that it and the programmer transmit.

The physical layer. Before we could analyze protocols at theapplication layer, we needed to determine the data bits thatcorresponded to the raw electromagnetic signals in the traceswe obtained with the oscilloscope and USRP. For complete-ness, Section III-D2 discusses radio terminology and describesthe process of extracting bits from RF traces. We determinedthat the ICD and the programmer share an encoding schemebut use different modulation schemes. Fig. 3 shows segmentsof the transmissions we examined.

Transmissions from the programmer. In reverse-engineeringthe programmer’s transmissions, we had an advantage: aserial connection between the programmer device and theprogramming head carries the raw bits to be transmitted. Bytapping this serial connection we were able to obtain these bitsfor comparison with the encoded and modulated RF signalsoutput by the programmer’s radio.

Through spectral analysis of the programmer’s RF trans-missions, we determined that it uses binary frequency shiftkeying (2-FSK) as its modulation scheme. We confirmed thisby demodulating bits from the RF trace and comparing theresults to the raw bits we collected on the serial line; wefound them to be identical. We also determined via standardtechniques that the length of a single symbol transmitted bythe programmer is 14 cycles of the center frequency, makingthe symbol rate 12.5 kBd (i.e., 12 500 symbols per second).

Transmissions from the ICD. Reverse-engineering the ICD’stransmissions was more difficult because we did not haveaccess to a wire carrying raw bits. However, we knew thatthe ICD transmits certain stored information, so we insertedinformation in the ICD using the programmer (by, for ex-ample, setting the patient name to a string of ‘A’s). Weanalyzed the RF signal to identify phase shift-keyed bits and,using our cribbed patient name, learned that the ICD uses amodulation scheme known as differential binary phase shiftkeying (DBPSK). We also determined that the symbol lengthof ICD transmissions is two cycles of the carrier wave, makingthe symbol rate 87.5 kBd.

Decoding. When we attempted to decode the demodulatedsymbols, we looked for the cribs (known plaintexts) we hadinserted. We observed that transmissions from both ICD andprogrammer are encoded under Non-Return-to-Zero Inverted(NRZI) with bit stuffing. Section III-D2 explains this encodingscheme and Fig. 5 shows an example of NRZI decoding.

B. Eavesdropping with a Commodity Software Radio

We built an eavesdropper using the Universal SoftwareRadio Peripheral (USRP) in concert with the open source GNURadio libraries. For the initial analysis in Section III-A, wesimply used programs included with GNU Radio to captureand store received radio signals, then wrote code in Matlaband Perl to analyze those signals. To eavesdrop in real time,we integrated the necessary functions back into the C++ andPython framework of GNU Radio. This section describes theeavesdropping process in detail and shows the results of ourpassive attacks.

Establishing a transaction timeline. Our first step towardunderstanding where and when to eavesdrop was to establisha timeline for bidirectional conversations between the ICDand the programmer; this timeline is shown in Fig. 4. Weestablished the timeline by interacting with the programmerand capturing programmer and ICD transmissions on anoscilloscope. We did not need to decipher these transmissions;we were able to infer their meanings and some of their contentsby observing the order in which the programmer acquired


100 200 300 400 500 600 700 800 900−4

−2

0

2

4P

hase

of s

igna

l

100 200 300 400 500 600 700 800 900

−0.5

0

0.5

Cha

nge

in p

hase

0 5 10 15 20

0

0.5

1

Dec

oded

bit

Sample index of programmer symbol (2−FSK)

100 200 300 400 500 600 700 800 900−4

−2

0

2

4

Pha

se o

f sig

nal

100 200 300 400 500 600 700 800 900−4

−2

0

2

4

Cha

nge

in p

hase

0 50 100 150

0

0.5

1

Dec

oded

bit

Sample index of ICD signal (DBPSK)

Fig. 3. Demodulating received programmer (left) and ICD transmissions. The top plot in each figure shows the phase of the raw RF signal, downconvertedfrom 175 kHz to baseband. Both 2-FSK and DBPSK encode data by the phase change of the signal, pictured in the middle row. The final row shows thedecoded bits: in 2-FSK the bit is determined by the sign of the phase change, and in DBPSK by whether it is closer to 0 or π. Note that there are fewer bitsthan samples; our 500 kHz sampling rate generates 40 samples per programmer symbol and about 6 per ICD symbol.

Magneticfieldintroduced

ACK ...Auto-ID

Model,Serial #

Interrogate

Patientdata ...

Command

Response

ICD

ICDProgrammer

Telemetry

...

Fig. 4. Timeline of a conversation between an ICD programmer and an ICD. If a programmer is present it will acknowledge each packet automatically.When told by an operator to do so, the programmer asks the ICD for identifying information, which the ICD provides. The programmer then interrogates theICD for patient data, which the ICD provides. Other commands (such as ICD programming commands) and their responses follow.

information about the ICD. We used the timeline to determinewhich transmissions to inspect using GNU Radio and our owntools.

Using GNU Radio. One builds a GNU Radio program byassembling digital signal processing blocks into an informationflow graph that connects a source to a sink. If a suitablehardware device such as a USRP is attached, source andsink blocks can represent radio interface cards. Intermediateblocks perform signal and data processing steps. Becausetransmissions from ICDs and ICD programmers differ greatlyin amplitude, because their modulation schemes differ, andbecause we wanted to assess our ability to eavesdrop on thetwo sides separately, we developed a slightly different GNURadio receiver for each end. See Section III-D3 for moredetails regarding one of those receivers.

An example illustrates the relative ease with which onecan develop a GNU Radio block: while inspecting demod-ulated and decoded traces in search of patterns, we dis-covered byte sequences that appeared to be packet delim-iters (1000000 for end-of-packet and 1111110000001for beginning-of-packet). We built a GNU Radio block to

packetize bitstreams and gather data about the resultingpackets. This block is logically simple and was adaptedfrom similar functionality in the GNU Radio library. Thecomplexity of this change was modest: we removed 87 of166 total lines of C++ code (discounting comments andwhitespace) from gr.correlate_access_code_bb andgr.framer_sink_1, and added 44 lines of code. Forperspective, the C++ source files for the other blocks usedin this receiver contain roughly 1600 lines of code, mostlyimplementing signal processing operations.

Intercepting Patient Data. Analysis of our captures viathe reverse engineering process described in Section III-Arevealed several things. First, we were able to find cleartextrepresentations of a wide range of what would have beenpatient data in captured transmissions. (We experimented withartificial patient data that we stored on the ICD; we did notexperiment with real patient data.) Even without knowledgeof the semantics of the packet format, these data are easilyextractable.

From this we conclude that this model of ICD programmerand this model of ICD do not protect their transmissions cryp-


tographically against disclosure when communicating witheach other. The personal data transmitted in cleartext includethe patient’s name, date of birth, medical ID number2, andpatient history. Equally easy to find are the name and phonenumber of the treating physician, the dates of ICD and leadimplantation (which may differ), the model, and the serialnumber of the ICD and leads. This list is not exhaustive;we observed other items of personally identifying data beingtransmitted in cleartext. All this information is sent either inthe clear or in inverted form from the ICD to the programmerduring interrogation. Furthermore, for the fields we manipu-lated via reprogramming attempts, these fields are sent in theclear from the programmer to the ICD.

Intercepting Telemetry. Our ICD begins to broadcast teleme-try data in cleartext as soon as a magnetic field of sufficientstrength is introduced. We activated telemetry with a magnetwe measured at 700 gauss by placing it within 5 cm of theICD. Telemetry transmissions, sent over the 175 kHz FMband at a rate of 32 packets per second in our experiments,contain representations of a patient’s electrocardiogram (EKG)readings; these readings convey heart rate and other potentiallyprivate information about the patient’s cardiac activity in realtime. We determined this information leak with a known-plaintext attack on ICD telemetry in which we attached afunction generator to one of the ICD’s sensing ports with thevoltage set larger than that generated by a real heart. Feedingthe device a predictable signal (in place of a heartbeat), wewere then able to observe the same period in the payloadsof the ICD telemetry packets. Varying the period of the inputresulted in a change of the output frequency to match, andin the absence of our input the telemetry data appeared asaperiodic binary noise (values from 0x00 to 0x03).

C. Limitations

Because our goal was to assess disclosure of private data,we did not fully reverse-engineer the communication protocol;rather, we inspected captured traffic and learned where to lookfor certain cribs. In particular, we were not always able topredict the value of a certain field which we believed to bea checksum. Another field appeared to be a sequence numberthat increased according to a rule we did not fully investigate.

As evidenced by the ICD programmer’s many (more than10 screens) informational displays and data graphs, the ICDtransmits a large amount of information to the programmer.We looked for cribs that we expected to see encoded underfairly predictable schemes (e.g., ASCII). We did not attemptto map all of the fields shown in the programmer’s menus totheir counterparts in the radio transmissions.

We do not provide an estimate of the upper bound oncommunication distance, as this distance is sensitive to manyfactors that are beyond the scope of this paper. Without anamplifier or any other specialized hardware, we were able to

2A medical ID number need not be globally unique; it is assigned accordingto the policy of the hospital and may, in some cases, serve as an index intoa database of patient records.

eavesdrop on both the ICD and the ICD programmer from adistance of several centimeters.

D. Auxiliary Information

This section provides supplementary information about ourequipment, our reverse engineering of the physical layer, andour programming of software radios. The reader can view thissection as the appendix to Section III. Skipping this sectionshould not affect one’s understanding of the core contents ofthis paper.

1) Equipment: Capturing RF packets requires equipmentcapable of operation at the relevant frequency bands — inour case, an antenna tuned to 175 kHz. We achieved our bestresults with an antenna that we removed from an explantedpacemaker and an antenna that we removed from a MedtronicCarelink device (model 2490C). We also performed successfuleavesdropping experiments using a homemade, hand-wound,ferrite core antenna and even a simple closed loop made byjoining the grabbers of an oscilloscope probe. We used thesame antennas for our replay attacks, sometimes in combi-nation with an amplifier; once again, we achieved our bestresults with the antennas removed from the pacemaker andthe Carelink device.

The oscilloscope eavesdropping setup is trivial: the os-cilloscope samples the voltage on an attached eavesdrop-ping antenna at regular time intervals, and we store these〈Time, Voltage〉 pairs to disk for later offline processing. Theoscilloscope proved very useful in our research; however, itslimited memory meant that we could record only about eightseconds of RF communication at a time, which was insufficientfor recording an entire conversation between our ICD andprogrammer.

Because of the oscilloscope’s limited memory depth, wealso used a Universal Software Radio Peripheral (USRP) [5] inour analysis. The USRP is a single board containing an FPGAfor fast signal processing and swappable radio interface cardscalled daughterboards. We used a BasicRX daughterboard,suitable for low-frequency communication, to interface withour eavesdropping antenna. The USRP records signals ascomplex I/Q samples, which are interconvertible with thedata format used by the oscilloscope. The daughterboards andFPGA perform RF conversion in hardware and stream theresults to the PC. The USRP can sample at a rate of up to8 MHz (32 MB/s) over a time range limited only by harddrive capacity; we performed the majority of our experimentsusing this setup with a sampling rate of 500 kHz.

2) Reverse-Engineering the Physical Layer: Two key pro-cesses are used in transmission of data over RF: encodingand modulation. Encoding is the process used to convert databits into radio symbols, and modulation determines how thehardware varies the carrier radio wave to transmit those sym-bols. In order to receive data, a receiver must first demodulateand then decode using the respective schemes. In RF systemswith asymmetric hardware constraints, such as with ICDsand programmers, it is not uncommon for transmissions fromdifferent devices to use different modulations and encodings.


We found that this is indeed the case for the programmer andthe ICD.

To collect RF data, we connected one of our antennas toa recording device (oscilloscope or USRP), then placed theantenna in close proximity to the ICD and programmer as theycommunicated wirelessly. We determined that the modulationscheme used by the programmer is binary frequency shiftkeying (2-FSK). In 2-FSK, the programmer encodes symbolsby transmitting at a different frequency for each symbol state.In this case, 150 kHz and 200 kHz respectively represent thetwo possible states.

The ICD uses a different modulation scheme, differentialbinary phase shift keying (DBPSK), in which the two possiblesymbols are represented by transmission at the same frequencybut opposite phase. DBPSK is a common modulation schemefor resource-constrained devices because it remains robustwhen the transmitting oscillator is inaccurate. Such oscillatorvariability is often observed in low-power devices that saveenergy by partially or fully disabling RF circuitry when itis not needed. One technique a device like an ICD mayemploy is to turn off the synchronization circuitry that keepsthe RF carrier frequency accurate between transmissions. Weobserved some evidence of this method in the ICD we studied.

Fig. 5 shows the symbols we obtained by demodulatingpart of a packet from a programmer transmission in whichthe programmer issues commands to the ICD to change thestored patient name to AA AAAA. As can be seen in row (a),different patterns of symbols can be used to express the samepattern of bits. For example, 111111011 and 000000100can both correspond to ASCII ‘A’. In determining the encodingscheme, we experimented with several common binary linecode schemes (e.g., Manchester). By searching for the knownplaintext crib of the patient name, we ultimately determinedthat both programmer and ICD transmissions are encoded inNRZI (Non-Return-to-Zero Inverted) form with bit stuffing.In NRZI encoding, zero bits are represented by no change insymbol over one symbol period, and one bits are representedby a change of symbol state. Bit stuffing is a commontechnique (used in the USB standard, for example) in whichdata containing the end-of-frame delimiter (EFD) is brokenup by the insertion of an extra bit to allow their transmissionwithout prematurely ending the frame.

3) Programming the Software Radio: Fig. 6 gives the blockdiagram of our eavesdropper for ICD programmer transmis-sions. Complex samples are streamed from the USRP withBasicRX daughterboard to the PC via USB, then output by thegr.usrp_source_c block. The frequency demodulationblock gr.blks.fm_demod_cf computes the frequencyshift of the incoming signal and finds the correct sampling in-terval for each signal. These symbols, in the form of frequencyshifts, are mapped to bits by gr.binary_slicer_fb, andthe bits are NRZI-decoded using gr.diff_decode_bb.This functionality is implemented entirely with existing blocksbuilt into the GNU Radio library. Finally, the resultant bits areframed as packets by our imd.sink_175 block, which weadapted from code in the GNU Radio library.

For active attacks, as for passive attacks, we employ sev-eral of GNU Radio’s standard signal processing blocks. Agr.file_source block streams complex samples from afile on disk. These are processed by an imd_clean_fmmodblock of our own design (80 lines of C++) which separatesprogrammer transmissions from background noise and ICDtransmissions, then generates a clean FM-modulated signalcarrying the exact same data. The clean signal is amplifiedin software and then streamed into usrp.sink_c, whichpasses the signal to the USRP for transmission over the air.

IV. ACTIVE ATTACKS WITH A COMMODITY SOFTWARERADIO

We implemented several active attacks using the USRP anda BasicTX daughterboard to transmit on the 175 kHz band.Because the BasicTX card lacks built-in amplification, wealso interposed a simple RF amplifier circuit for many of ourreplay attempts. With amplification, we were able to mountactive attacks across an air gap of several centimeters; we didnot attempt further amplification or longer distances. Withoutamplification, we successfully mounted selected replay attackswith the antenna from a Carelink device within one cm of theICD. Additionally, during the course of our experiments, theICD entered its elective replacement indicator (ERI) mode,which normally indicates to physicians that ICD replacementshould be scheduled. We successfully mounted all of ourreplay attacks before and after the ICD entered this mode.

All of our active attacks fall into the category of replayattacks: only simple waveform manipulation and repetition— not packet analysis or reassembly — were necessary.Creating a software radio programmer capable of emulatingall the functions of a commercial programmer would requireadditional reverse engineering; we chose instead to focus onattacks that are both significant and illuminating (in particular,those that violate confidentiality, integrity, or availability) andthat pose minimal complexity to adversaries.

A. Replay Attacks

For simplicity, our replay attack technique is transmit-only:we did not attempt to synchronize replayed programmer pack-ets with the ICD’s response packets. The penalty we paid as aresult was that each successful replay attack was preceded byzero or more unsuccessful attempts. It was generally sufficientto set the ICD to a known state, replay the desired transmissionin a loop for several minutes, and then re-evaluate the resultingstate of the ICD. This process allowed us to determine whetherone or more replays were successful but did not reveal theprecise number of successes. The transmissions we replayedvaried in length from one second to 37.7 seconds. We did notattempt to optimize our attacks by removing silent periodsfrom the replayed traces. Each of our replay attacks targetedonly the ICD against which we recorded the original trace.

In order to rule out the possibility that proximity of themagnet in the programming head is necessary for the ICD toaccept programming commands, we tested each replay attackwith and without a magnet near the ICD. In all cases, both


(a) 101010100000001|...|000000100|111111011|000000100|111111011|...|1111111(b) _11111110000001|...|100000x10|100000x10|100000x10|100000x10|...|1000000(c) ------SFD------ A A A A --EFD--

Fig. 5. Part of a sample programmer transmission containing the crib text AAAA. Row (a) represents the demodulated bits, (b) are the NRZI-decoded bits,and (c) are the bits rendered as ASCII. The Start-of-Frame and End-of-Frame Delimiters pictured mark the beginning and end of each packet.

Software Radio

gr.usrp_source_c

FM demodulator

gr.blks.fm_demod_cf

Differential (NRZI) decoder

gr.diff_decode_bb

Binary Slicer

gr.binary_slicer_fb

Programmerpacket sink

imd.sink_175

Fig. 6. Architecture of a GNU Radio-based eavesdropper. The purpose and Python class name of each signal processing block is included, as well as theformat of the data it processes. All blocks but the last are from GNU Radio’s built-in block library. We adapted the last block, our imd.sink_175 packetframer, from built-in GNU Radio blocks.

scenarios were successful. We conducted all of our activeattacks with our commercial programmer turned off.

Triggering ICD identification. We performed several exper-iments in which we replayed a 1.5-second auto-identificationtrace we had recorded from the programmer. Each of thesetransmissions resulted in an identical response from the ICD,disclosing the ICD’s presence and several details about thedevice such as its model and serial number. As the auto-identification command is the first set of packets sent by aprogrammer in a normal session, our experiments suggest thatno prior synchronization is required for a successful exchangeas long as the programmer transmits during ICD radio silence.

Disclosing patient data. After the auto-identification step, theprogrammer asks the ICD for the rest of the information storedon it, including patient data. We used GNU Radio to replaya 26-second capture containing both an auto-identificationcommand and the interrogation command that elicits the moredetailed data. Using the demodulation and framing code de-scribed in Section III-A, we confirmed that the ICD respondedto our interrogation command with the same response it gaveto the ICD programmer’s original command. This responseincludes personal information such as patient name, diagnosis,and many other details.

Disclosing cardiac data. We observed that certain conditionscause the ICD to send periodic telemetry transmissions at arate of 32 packets per second. If a sufficiently strong magnetis near the ICD, the ICD appears to transmit telemetry indef-initely. When the strong magnet is taken away (as when theprogramming head is removed from the patient’s skin), thesetransmissions stop after 10 seconds. However, introducing amagnet is not the only way to elicit telemetry transmissionsfrom the ICD. We observed that replaying certain sectionsof recorded conversations, in particular the beginning of theinterrogation command sequence, caused the ICD to emitpackets for several seconds after the end of the replay. Wehypothesize that an attacker could replay these commands ina tight loop to elicit continual telemetry from the ICD.

Changing patient name. Medical personnel can learn apatient’s name by interrogating an ICD. We used GNU Radio

to replay traces in which the programmer changes the patientname stored on the ICD. After ten (on average) replays ofthe same trace, more than one of which may have succeeded,we used the programmer to confirm that we had successfullychanged the patient name stored on the ICD. We repeated thisexperiment several times, each time changing the name to adifferent value and confirming the change on the programmer.

Setting the ICD’s clock. The ICD programmer and the ICDhave separate clocks. The ICD’s clock allows it to recordtimestamps in its event log and can be set from a menu onthe programmer. We used GNU Radio to replay traces inwhich the programmer sets the time or date on the ICD. Wethen confirmed in a new programming session that we hadsuccessfully set the ICD’s clock. As with the patient namechange, this attack succeeded after an average of ten replays,more than one of which may have succeeded.

Changing therapies. Therapies are the ICD’s responses tocardiac events. A commercial programmer can be used toenable and personalize therapies for an individual patient’smedical needs or to disable (i.e., turn off) the device’s life-saving functions. We used GNU Radio to replay capturesin which the programmer turns off therapies. With therapiesturned off, the ICD does not respond to potentially dangerouscardiac conditions. After 24 replay attempts, more than oneof which may have succeeded, we confirmed in a new pro-gramming session that we had successfully disabled all of thetherapies we had enabled before our attempts.

Inducing fibrillation. During implantation surgery, it is com-mon for a physician to test the newly implanted ICD toensure that it can both sense and appropriately treat a cardiaccondition known as ventricular fibrillation (V-Fib), one of themost common kinds of heart rhythm problems. Accordingly,the ICD has several testing modes in which it can induce V-Fib. Such a test — called an electrophysiological (EP) study— is normally conducted with cardiologists standing by tostop the fibrillation if the ICD fails to do so. After a physicianputs the programmer in EP study mode, sets certain studyparameters, and explicitly confirms that the study should begin,the programmer sends the ICD a sequence of commands that


requests a low-energy (∼1 joule) command shock to be appliedto the patient’s heart at a precise point in the patient’s cardiacrhythm, with the goal of inducing V-Fib. When its automatictherapies are enabled, the ICD should immediately detect andtreat the fibrillation by delivering the proper therapy.

We introduced a 100 Ω resistor between two of the ICD’s la-beled defibrillation ports to measure the voltage applied duringa command shock. We then used our commercial programmerto conduct an EP study in which we sent a 1.0 J shock fromone defibrillation port to the other across the resistor. Usingour oscilloscope, we measured the pulse’s peak voltage atan average of 138.4 V over three trials. We then replayeda recording of the EP study command sequence via oursoftware radio. At least three of 30 replay attempts succeededin causing similar voltage spikes, averaging 137.7 V. Besidesobserving voltage spikes on the oscilloscope, we confirmedthat the ICD’s last high-voltage therapy field, shown in aprogrammer menu, changed to reflect the date and time ofour last successful attack. We successfully triggered commandshocks via replayed commands even after turning off all of theICD’s automatic therapies.

The commercial programmer’s user interface provides safe-guards to make it difficult for a physician to accidentally issuea command shock when the ICD’s therapies are disabled.Our successful replay attacks demonstrate that although thesesafeguards are implemented in the programmer’s software, anadversary who bypasses the commercial programmer usinga software radio could circumvent these safeguards. Thebroader lesson is that external devices such as commercialprogrammers should not be considered part of an IMD’strusted computing base. Additionally, we argue that if anyIMD exhibits a test procedure T for some property P , andif there are no medical reasons for conducting procedure Tother than testing property P , then it should be impossible totrigger T unless P is enabled. For example, as our experimentssuggest, if P is the efficacy of the device when therapies areenabled and T is a test, then the ICD — not only the externalprogrammer — should verify that therapies are enabled priorto conducting the test T .

Power denial of service attack. Our experiments suggestthat the ICD could be forced to remain in a mode in whichit continually engages in wireless communications. As wediscuss above, a strong magnetic field causes the ICD totransmit telemetry continually, and the ICD responds to RFcommands without the presence of a nearby magnet. We havenot measured the power consumed by telemetry or other RFtransmissions, but it is possible that these operations decreasebattery life faster than normal ICD operation alone.

Other attack vectors. As noted in our earlier work [1],[10], there may be other attack vectors against IMDs, such asinsecure software updates or buffer overflow vulnerabilities.We do not experiment with such attack vectors in this work,but note that the existence of such exploitable vulnerabilitiescould allow for further adversarial control over the state andoperation of an IMD.

V. ZERO-POWER AND SENSIBLE DEFENSES FOR IMDSECURITY AND PRIVACY

Providing security and privacy on an IMD involves healthrisk factors and tight resource constraints. Traditional ap-proaches could potentially introduce new hazards to patientsafety. For instance, protecting an IMD with a cryptographickey may provide security, but the unavailability of a key couldhinder treatment in emergency situations. Another risk to IMDavailability is excessive power consumption by mechanismsother than those needed for the device’s primary function.For instance, the energy cost of performing computation forcryptography or radio communication could directly competewith the energy demands of pacing and defibrillation. Effectivemechanisms for security and privacy should not provide newavenues for an unauthorized person to drain a device’s battery.For instance, spurious wake-ups or a cryptographic authenti-cation process itself could cause a device to enter a state thatconsumes excessive amounts of energy (as in, e.g., the sleepdeprivation torture attacks of Stajano and Anderson [29]).

Therefore, three goals guided our design of zero-powerapproaches for IMD security and privacy. First, an effective ap-proach should either prevent or deter attacks by both maliciousoutsiders with custom equipment and insiders with commercialprogrammers. Because IMD therapies rely on long-lastingbatteries, a second goal is that security and privacy shoulddraw no power from the primary battery, thus preventing denialof service attacks on power. Third, security-sensitive eventsshould be effortlessly detectable by the patient. We must alsoensure that new security mechanisms do not introduce newfailure modes.

Our contributions include three zero-power defenses andprototype implementations, one of which we evaluated foreffectiveness in a substance approximating the radio propertiesof human tissue. Zero-power notification harvests induced RFenergy to wirelessly power a piezo-element that audibly alertsthe patient of security-sensitive events at no cost to the battery.Zero-power authentication similarly harvests RF energy topower a cryptographically strong protocol that authenticatesrequests from an external device programmer. Finally, sensiblekey exchange combines techniques from both zero-powernotification and zero-power authentication for vibration-basedkey distribution that a patient can sense through audible andtactile feedback. While we implemented prototypes of ourproposed defenses, we did not incorporate our prototypes intoa real IMD. (We use the term zero-power only to emphasizethat no expenditure of energy from the primary battery isnecessary. Zero-power defenses are also a step beyond theuse of a secondary battery for security-only or other auxiliarypurposes.)

We do not claim that our defenses are final designs that IMDmanufacturers should immediately incorporate into commer-cial IMDs. Rather, we believe that our research establishes apotential foundation upon which others can create, evaluate,and implement new defensive mechanisms for future IMDdesigns.


Fig. 7. The WISP with attached piezo-element.

A. Detection: Zero-Power Notification for Patients

As our earlier work notes [10], it may be possible todeter malicious activities by making patients aware of thoseactivities. Our zero-power notification alerts a patient to poten-tially malicious activities both by insiders using commercialprogrammers and by outsiders using custom attack hardware,thereby making patients effortlessly aware of remote com-munications. On some modern ICDs, triggering the magneticswitch causes the ICD to beep. Whether intentional or not,such beeping represents a step towards the concept of patientawareness by way of audible alerts. But beeps triggered by amagnet alone do not raise patient awareness for RF-initiatedactions, which our approach does.

Our approach: WISPer. Our prototype of zero-power notifi-cation wirelessly drives a piezo-element that can audibly warna patient of security-sensitive events. The prototype buildsupon revision 1.0 of the Wireless Identification and Sens-ing Platform (WISP) [27], a postage stamp-sized embeddedsystem that contains RFID circuitry and a Texas InstrumentsMSP430F1232 microcontroller with 256 bytes of RAM and8 KBytes of flash memory. The WISP harvests energy froma 915 MHz RF signal generated by the Alien ALR-9640nanoscanner, a UHF RFID reader running the EPC Class1 Gen 1 protocol. Although we prototyped at 915 MHz, itmay be possible to create similar hardware that operates atthe frequency of current ICD programmers. WISPer adds tothe WISP’s base code a 30-line C program that activatesa piezo-element which we attached to the general-purposeI/O (GPIO) ports of the WISP. After WISPer receives asequence of wireless requests from the RFID reader, it emitsconstant chirping, thereby informing the patient of the wirelessinteraction. A future version of WISPer could set a separateGPIO high after buzzing for a certain number of cycles, andthe IMD could allow remote communications only after thatGPIO is raised. WISPer satisfies our zero-power notificationdesign constraints: it draws no energy from a battery and canissue alerts for all reprogramming activity.

Evaluation. Two measurements quantify the effectiveness ofthe WISPer prototype for zero-power notification. We useda sound level meter to measure Sound Pressure Level (SPL)with a reference pressure of 20 micropascals (the standardfor above-water calculations). The buzzing volume peaked at67 dB SPL from a distance of 1 m. For reference, a normal

conversation is about 60 dB SPL and a vacuum cleaner at adistance of 3 meters is about 70 dB SPL [17]. We then placedour prototype in an environment designed to simulate implan-tation in a human (Fig. 8). We implanted the device beneath1 cm (a standard ICD implantation depth) of bacon, with 4 cmof 85% lean ground beef packed underneath. We took severalreadings at the surface of tissue in order to ascertain the effectsof obstruction by tissue. We measured 84 dB SPL of soundat the surface of the tissue, and subjectively were easily ableto hear it from a meter away (more than the distance betweenstandard ICD implantation sites and a patient’s ear).

These tests of our prototype device suggest that its piezo-element is audible under reasonable simulations. Becausemalicious attackers may attempt their attacks in noisy, chaoticenvironments to vitiate auditory notification, and because somepatients with ICDs may have limited hearing, we note thata piezo-element can be used to produce vibration instead ofaudible sound. In our experiments, the 4 kHz alert used waseasily sensed by touch.

B. Prevention: Zero-Power Authentication

Our second defense implements a zero-power method thatallows an IMD to verify that it is communicating with a realcommercial programmer (and not an unauthorized softwareradio programmer).

Approach. The device implements a simple challenge-response protocol (Fig. 10) based on RC5-32/12/16 [24]. Inthis model, all commercial programmers know a master keyKM , each IMD has an serial number or identity I , and eachIMD has an IMD-specific key K = f(KM , I), where f isany cryptographically strong pseudorandom function (such asAES). The value KM should be stored in secure hardwareon the programmers. The protocol works as follows. Theprogrammer transmits a request to authenticate to the WISP.The WISP responds with its identity I and a nonce N .The programmer computes K = f(KM , I) to get the IMD-specific key and then returns the response R = RC5(K, N)to the WISP. The WISP computes the same value and verifiesthe value it received from the programmer against its result.The WISP finally sets a GPIO high which, if attached to orbuilt into a real IMD, would inform the IMD that the WISPsuccessfully authenticated a programmer.

For the sake of simplicity, our prototype does not implementthe full protocol. Namely, in our experiments we use a fixednonce and assume that the programmer knows the noncein advance. Using this simplified model, we experimentallyverified that, upon receiving the programmer response R, theWISP was able to perform its own RC5 encryption and verifyequality. We were able to run this subset of the protocol withcomplete reliability using only harvested energy. To lift fromthe simplified model to a real implementation of our protocol,we note that the nonce should appear random to an adversary.Since we, and others [2], show that it is possible to run RC5on a WISP, a natural solution would be to generate the noncewith RC5 in counter mode. A better approach that wouldyield a truly random nonce is to exploit process variations


Fig. 8. To simulate implantation in a human, we placed the WISP in a bag containing bacon and ground beef.

and omnipresent thermal noise by extracting random bits fromSRAM using the FERNS technique of Holcomb et al. [12].Applying FERNS to 256 bytes of SRAM could yield 100 bitsof true randomness each time the SRAM is powered up. Ourwork would benefit from an implementation of the memory-as-TRNG technique on the WISP.

Evaluation. We learned from our successful attacks thatprivate data transmitted between our ICD and programmerare not encrypted. We propose that cryptography be added atleast at critical junctures. Encryption of the entire conversationwould be optimal — for example, a secure channel betweenprogrammer and ICD could prevent third-party disclosure,replay, and many other attacks — but in the interest of mod-ularity we consider in this paper only defensive approachesthat might be implemented with less extensive modifications tocurrent ICD designs. Modularity aside, if we were to proposecryptographic extensions that required significant changes toICD design, it would be necessary to consider the power costof our proposed changes. Without detailed knowledge of theinner workings of ICDs, however, we cannot accurately assessthe cost of adding cryptography to existing devices.

The tension between increased security and increased powerconsumption can be resolved by requiring successful zero-power authentication before the device switches to higherpower consumption modes. Our prototype shows that thisproposal is feasible for bootstrapping stronger (and possiblymutual) authentication methods. Our prototype harvests powerfrom RF transmissions, performs a cryptographic authentica-tion, and on successful authentication of a programmer, setsa GPIO high which, if connected to or built into a real ICD,would permit the ICD to participate in active RF communica-tion and other higher-level protocols. This approach addressesthe risk of sleep deprivation torture described by Stajano andAnderson [29].

Key management. This paper does not address the well-known problem of key management. Using a shared secret(called Km above) is reasonable for a prototype implemen-tation, but a large-scale deployment of shared key material— in implanted devices, hospitals, clinics, ambulances, IMDprogrammers, and so on — may pose an unacceptable riskbecause of the ease with which an unauthorized party could de-crypt transmissions upon obtaining the key material. (Thoughour recommendation of storing Km in secure hardware does

partially mitigate this risk under certain threat models.) Thesimple scheme described above also fails to address revocationof privilege and is therefore ill-suited to situations in whichkey material might be compromised, although the proposedsystem is still no less secure than the open-access model ofconventional systems. An SKEYS [9] or key-regression [6]approach, with periodic updates of programmer keys, mightmitigate the time-window in which an attacker can use com-promised keys while also not significantly changing the overallmodel. Furthermore, the offline nature of the transactions thatmust be secured — imagine an ambulance reaching an ICDpatient in a remote setting — further complicates the problemof key management and revocation.

In the context of medical devices, security-related de-sign choices must balance security, privacy, safety, and effi-cacy [10]. An ideal key management scheme for this context,which we present as an important open problem, must providesecurity and support privacy without hindering the operationof medical devices that are already known to provide safe andeffective treatments.

C. Zero-Power Sensible Key Exchange

We now present a key-distribution technique that comple-ments both of our previous defensive techniques: distributionof a symmetric cryptographic key over a human-perceptiblesensory channel. The primary goal is to allow the patient todetect a key exchange while it occurs.

Approach. The programmer initiates our protocol by supply-ing an unmodulated RF carrier signal that could power thepassive component of the IMD. The IMD then generates arandom value to be used as a session key and broadcastsit as a modulated sound wave. The amplitude of this soundwave is such that it can be easily received and demodulatedby a reader with a microphone in contact with the patient’sbody near the implantation site, but it cannot be heard overbackground noise at any appreciable distance from the patient,at least not without dedicated sensing equipment. The closeproximity this enforces further ensures patient awareness andconsent to the authentication attempt. Once key exchange hasbeen performed, RF communication can safely occur over alonger range without fear of eavesdropping.

Evaluation. We implemented our key exchange mechanismon the WISP using as carrier frequency the same 4 kHz


ICD

Programming head

1 cm Key material

Fig. 9. Zero-power sensible key exchange: a nonce is transmittedfrom the ICD to the programmer using acoustic waves. It can be clearlypicked up only if the programmer is in contact with the patient’s bodynear the implantation site, and can be used as the secret key in theauthentication protocol from the previous section. (1 cm is a typicalimplantation depth. Diagram is not to scale.)

ProgrammerD = (IDi, SKi), ...

WISPIDi, SKi=F(IDi,Km)

Auth?

(IDi, N)

R'

Accept

N ∈ 0,1128

(IDi, SKi) ∈ DR' = RC5(SKi, N)

RC5(SKi, N) = R'

Enable IMD communication

Master key (Km)

?

Fig. 10. The protocol for communication between an ICD programmerand a zero-power authentication device (a WISP RFID tag, in the caseof our prototype).

audible and tactile signal discussed above. To effect keyexchange, we used the same modulation scheme currentlyin use by our reader (2-FSK). We achieved a baud rate of310 Bd, permitting transmission of a 128-bit nonce in 0.4 s.The components performed key exchange without drawingpower from a battery, and the exchange was clearly audible,measuring 75 dB SPL through a human hand. When themicrophone was not in contact with the skin, the sound pickupwas too low to be measured on our meter (< 60 dB SPL). Inour ad hoc experiments, transmission of the key was easyto feel with the hand, but difficult to hear at a distance.While these preliminary measurements show the plausibilityof making eavesdropping difficult, further work is necessary toilluminate the relationship between sound levels and the abilityto eavesdrop. Furthermore, an adversary may attempt to eaves-drop on the electromagnetic emanations [14] of the electricalcomponents that generate the sound rather than on the sounditself. Radio shielding in the form of a Faraday cage or use ofnon-electromagnetic, optical links between security-sensitivemodules may help to reduce these unintended emanations. Analternate approach for sensible key exchange might be for theprogrammer to transmit the key to the IMD over an audiochannel, or for the final key to be derived from keys sent inboth directions.

VI. CONCLUSION AND FUTURE WORK

Our investigation shows that an implantable cardioverterdefibrillator (1) is potentially susceptible to malicious attacksthat violate the privacy of patient information and medicaltelemetry, and (2) may experience malicious alteration to theintegrity of information or state, including patient data andtherapy settings for when and how shocks are administered.Moreover, standard approaches for security and access controlmay not always be suitable for IMDs due to tensions betweensecurity (e.g., access for pre-authorized parties only) and safety(e.g., access for previously unauthorized parties in emergencycircumstances) [10]. Our three new methods for zero-powersecurity (zero-power notification, zero-power authentication,

and sensible key exchange) implemented on a prototype aresteps toward mitigating this tension without simultaneouslydrawing power from a battery.

Reflections on existing and next-generation IMD technolo-gies. Evaluating the security and privacy of an IMD bestleverages skills from many disciplines, including security,cryptography, cardiology, signal processing, radio communica-tions, and antenna design. Next-generation IMDs, which mayincorporate greater communications capabilities and be morenetworked, should not rely solely upon external mechanismslike firewalls on external devices and controlled distribution ofcommercial programmers. Firewalls on wireless programmersor Internet-connected at-home monitors do not immediatelyprotect the wireless links themselves and may not protect theintegrity of communications. Controlled distribution of pro-grammers cannot prevent insider access, and the availabilityof software radios can make the possession of a commercialwireless reprogrammer unnecessary. In essence, device man-ufacturers should not view external devices, like commercialprogrammers, as part of the trusted computing base for IMDs.Additionally, the trend toward increasing nominal read rangeallows flexible home monitoring for better safety, but it alsoincreases the exposure of devices to attacks from nearbyadversaries. Finally, for economic and safety reasons, certainIMDs typically contain non-rechargeable batteries and requiresurgery for replacement. Conventional approaches for securityand privacy may facilitate trivial denial of service attacksagainst these batteries.

Future directions and open problems. Critical systems thatrely on computing devices are already designed with greatcare. When these systems include wireless computing devices,additional precautions are necessary to ensure that the comput-ing devices appropriately balance safety with convenience anddo not introduce unacceptable risks. Medical device design isone such situation. Our research into implantable cardioverterdefibrillators has demonstrated failure modes that do notappear to be addressed by some present-day design strategies


and certification processes.Our work therefore leaves open a number of research

problems. While there are a few obvious minor next steps,our research calls for much broader and innovative action. Inconcert with Halperin et al. [10], this work illuminates theneed for a principled and deeper investigation into preventionmechanisms, detection mechanisms, audit mechanisms, deter-rents, and methods that enhance patient awareness and ensureconsent. Moreover, a fundamental challenge will be to developmethods that appropriately balance security and privacy withtraditional goals such as safety and effectiveness. Our workprovides a foundation for these explorations, on top of whichwe hope to see much subsequent innovation. Such innovationswill become more crucial as the technologies and capabilitiesof implantable medical devices continue to evolve.

ACKNOWLEDGMENTS

We thank Rick Adrion, Tom Anderson, Mark Corner,Matthew Garber, Robert W. Jackson, Barry Karas, Jim Kurose,Ed Lazowska, Mark McGovern, Jerry Saltzer, Stefan Sav-age, Prashant Shenoy, Joshua Smith, Bill Stasny, Paul vanOorschot, David Wagner, Matt Welsh, David Wetherall, DanYeager, Serge Zhilyaev, and the anonymous reviewers fortheir collective assistance, feedback, and generous supportof this many-person, interdisciplinary project. This work wassupported in part by National Science Foundation (NSF) grantsCNS-0435065, CNS-0520729, CNS-0627529, and the NSFResearch Experiences for Undergraduates (REU) program. Dr.Maisel is a U.S. Food and Drug Administration consultant. Theopinions expressed in this paper are those of the authors anddo not necessarily reflect the opinions, positions, practices, orpolicies of the FDA.

REFERENCES

[1] A. Bellissimo, J. Burgess, and K. Fu. Secure software updates:disappointments and new challenges. In Proceedings of USENIX HotTopics in Security (HotSec), July 2006.

[2] H.-J. Chae, D. J. Yeager, J. R. Smith, and K. Fu. Maximalist cryptog-raphy and computation on the WISP UHF RFID tag. In Proceedings ofthe Conference on RFID Security, July 2007.

[3] S. Cherukuri, K. Venkatasubramanian, and S. Gupta. BioSec: A biomet-ric based approach for securing communication in wireless networks ofbiosensors implanted in the human body. In ICPP Workshops, 2003.

[4] T. Drew and M. Gini. Implantable medical devices as agents andpart of multiagent systems. In Fifth International Joint Conference onAutonomous Agents and Multiagent Systems, May 2006.

[5] Ettus Research, LLC. The universal software radio peripheral. http://www.ettus.com.

[6] K. Fu, S. Kamara, and T. Kohno. Key regression: Enabling efficientkey distribution for secure distributed storage. In Proceedings of theSymposium on Network and Distributed Systems Security, February2006.

[7] M. Fukomoto, M. Shinagawa, and T. Sugimura. A broad-band intrabodycommunication system with electro-optic probe. In Proceedings of theFirst International Conference on Appliance Design 2003, 2003.

[8] M. T. Goodrich, M. Sirivianos, J. Solis, G. Tsudik, and E. Uzun. Loudand clear: Human-verifiable authentication based on audio. CryptologyePrint Archive, Report 2005/428, 2005. http://eprint.iacr.org/.

[9] N. M. Haller. The S/KEY one-time password system. In Proceedings ofthe Symposium on Network and Distributed Systems Security, February1994.

[10] D. Halperin, T. S. Heydt-Benjamin, K. Fu, T. Kohno, and W. H. Maisel.Security and privacy for implantable medical devices. IEEE PervasiveComputing, Special Issue on Implantable Electronics, January 2008.

[11] T. S. Heydt-Benjamin, D. V. Bailey, K. Fu, A. Juels, and T. O’Hare. Vul-nerabilities in first-generation RFID-enabled credit cards. In Proceed-ings of Financial Cryptography and Data Security, 11th InternationalConference, LNCS 4886, February 2007.

[12] D. E. Holcomb, W. P. Burleson, and K. Fu. Initial SRAM state asa fingerprint and source of true random numbers for RFID tags. InProceedings of the Conference on RFID Security, July 2007.

[13] C. Karlof, N. Sastry, and D. Wagner. TinySec: A link layer securityarchitecture for wireless sensor networks. In Second ACM Conference onEmbedded Networked Sensor Systems (SenSys 2004), November 2004.

[14] M. Kuhn. Compromising emanations: eavesdropping risks of computerdisplays. PhD thesis, Computer Laboratory, University of Cambridge,Wolfson College, 2003.

[15] J. Lackey and D. Hulton. The A5 cracking project: Practical attacks onGSM using GNU radio and FPGAs. In Chaos Communication Camp,2007.

[16] N. G. Leveson and C. S. Turner. An investigation of the Therac-25accidents. Computer, 26(7):18–41, 1993.

[17] Maine State Planning Office. Noise technical assistance bulletin#4. http://www.maine.gov/spo/landuse/docs/NoiseTABulletin.pdf, May2000. Last viewed November 9, 2007.

[18] W. H. Maisel. Safety issues involving medical devices. Journal of theAmerican Medical Association, 294(8):955–958, August 2005.

[19] W. H. Maisel, M. Moynahan, B. D. Zuckerman, T. P. Gross, O. H.Tovar, D.-B. Tillman, and D. B. Schultz. Pacemaker and ICD generatormalfunctions: Analysis of Food and Drug Administration annual reports.Journal of the American Medical Association, 295(16):1901–1906, April2006.

[20] J. M. McCune, A. Perrig, and M. K. Reiter. Seeing-is-believing: Usingcamera phones for human-verifiable authentication. In IEEE Symposiumon Security and Privacy, pages 110–124. IEEE Computer Society, 2005.

[21] Medtronic. Maximo DR. http://www.medtronic.com/crm/performance/icd/7278-maximo-dr.html. Last viewed November 8, 2007.

[22] M. Meingast, T. Roosta, and S. Sastry. Security and privacy issueswith health care information technology. In Proceedings of the 8thAnnual International Conference of the IEEE Engineering in Medicineand Biology, pages 5453–5458, August 2006.

[23] A. Perrig, R. Szewczyk, V. Wen, D. Culler, and J. D. Tygar. SPINS:Security protocols for sensor networks. Wireless Networks, 8(5):521–534, Sept. 2002.

[24] R. L. Rivest. The RC5 encryption algorithm. In B. Preneel, editor, FastSoftware Encryption, pages 86–96. Springer, 1995. (Proceedings SecondInternational Workshop, Dec. 1994, Leuven, Belgium).

[25] A. P. Sample, D. J. Yeager, P. S. Powledge, and J. R. Smith. Design ofa passively-powered, programmable platform for UHF RFID systems.In IEEE International Conference on RFID 2007, March 2007.

[26] H. Savci, A. Sula, Z. Wang, N. S. Dogan, and E. Arvas. MICStransceivers: regulatory standards and applications [medical implantcommunications service]. In Proceedings of IEEE SoutheastCon 2005,pages 179–182, April 2005.

[27] J. R. Smith, A. P. Sample, P. S. Powledge, S. Roy, and A. Mamishev.A wirelessly-powered platform for sensing and computation. In 8thInternational Conference on Ubiquitous Computing (Ubicomp 2006),pages 495–506, Orange Country, CA, USA, September 2006.

[28] D. Spill and A. Bittau. BlueSniff: Eve meets Alice and Bluetooth. InProceedings of USENIX Workshop on Offensive Technologies (WOOT),August 2007.

[29] F. Stajano and R. J. Anderson. The resurrecting duckling: Security issuesfor ad-hoc wireless networks. In Proceedings of Security Protocols, 7thInternational Workshop, LNCS 1796, pages 172–194, 1999.

[30] The Free Software Foundation. The GNU software radio. http://www.gnu.org/software/gnuradio.

[31] K. K. Venkatasubramanian and S. K. S. Gupta. Security for pervasivehealth monitoring sensor applications. In Proceedings of 4th Interna-tional Conference on Intelligent Sensing and Information Processing(ICISIP), pages 197–202, December 2006.

[32] S. Warren, J. Lebak, J. Yao, J. Creekmore, A. Milenkovic, and E. Jo-vanov. Interoperability and security in wireless body area networkinfrastructures. In Proceedings of the 2005 IEEE Engineering inMedicine and Biology 27th Annual Conference, 2005.

[33] L. Zhong, D. El-Daye, B. Kaufman, N. Tobaoda, T. Mohamed, andM. Liebschner. OsteoConduct: Wireless body-area communication basedon bone conduction. In Proc. Int. Conf. Body Area Networks (BodyNets),June 2007.


pacemakers and implantable cardiac deﬁbrillators: software … · pacemakers and implantable...

Documents