Amphion Forum discusses medical device security in Minneapolis on November 3

Join MDSC co-director Dr. Kevin Fu and several other experts on medical device security at the Amphion Forum in Minneapolis on November 3. Request an invitation and then take a morning break from MDM to learn about the emerging security risks of software-based medical devices.

It's not too surprising that medical devices have security risks. The bigger question is how to find effective and balanced ways to reduce security risks in a landscape where threats can emerge without warning. Dr. Fu explains that if a medical device company wishes to attract hackers to devices, the company should follow this simple, four-step program:

1. Increase software complexity so that testing becomes an ineffective technique for risk management. Make extensive use of pointers and non-type-safe programming languages.
2. Add unprotected radio communication so that previous physical barriers no longer keep out the bad. Special overconfidence points are awarded for using "proprietary techniques" to "secure" a radio/wireless link.
3. Trust the Internet for clinical decision making; add decades of Internet security holes and web browser vulnerabilities to your trusted computing base.
4. Be complacent. Assume that absence of a security problem today means there never will be.

Software race conditions in intravascular radiation delivery systems

There are very few MAUDE reports that cite "race conditions" in medical device software as a cause of malfunction, patient harm, or death. But to a computer scientist, this 2002 MAUDE report on a radiation delivery device sounds like it's describing a classic race condition:

The root cause for the appearance of the partial treatment button is the result of a software anomaly combined with the user not following the ifu. The time window necessary for this anomaly to occur (after completion of the treatment and prior to the treatment summary screen being displayed) is small (approximately 1 second),...

The phrase "race condition" does appear occasionally in MAUDE. Here's a sample excerpt.

Engineering investigation determined that after the table top is tilted to 88 degees, releasing and engaging the angulation knob very quickly when the table is near its extension limit creates a software race condition that allows the table to continue its motion towards the floor.

Another wireless infusion pump announced

Another wireless infusion pump has been announced. Wireless has the potential to revolutionize medicine, but what about the challenging security and privacy risks of wireless? I wonder how well the software system adheres to the classic open design principle for security engineering. What kind of cryptographic protocols are in place for secure updates of drug libraries? If SSL is used, how does the manufacturer revoke certificates when a CA is compromised? Does the device rely on proprietary techniques or sound security engineering? These are important types of questions to ponder when taking a previously non-wireless medical device and then exposing the device to the wild west of wireless. Meanwhile, it's still a vexing problem to protect a Facebook account from wireless compromise let alone a medical device.

According to this public database entry, this pump was cleared through the 510(k) process and deemed substantially equivalent to a predicate device. The database entry does not indicate whether the predicate device was wireless.

Improving implantable medical device security and privacy with the IMD Shield

We researchers at the MDSC spend a lot of time thinking about vulnerabilities in implantable medical devices (IMDs), but it's über-exciting when we can also work on emerging technology that improves the security and privacy of medical devices. The IMD Shield, presented at ACM SIGCOMM 2011, takes a fresh look at IMD communications and offers somewhat unorthodox solutions to several hard security problems:

1. How can we protect an IMD without requiring that it be surgically replaced?
2. How should an IMD's security and privacy mechanisms fail open—that is, protect the device by default but allow emergency responders to bypass them?
3. How can we prevent eavesdroppers from receiving sensitive patient information from an IMD?
4. How can we prevent an IMD from obeying commands from unauthorized transmitters?

The secret sauce is friendly jamming, applied judiciously. The IMD Shield takes advantage of the specific properties of medical communications (in the MICS band) to protect IMDs from passive and active adversaries, to fail open when appropriate, and to reduce the risks related to surgical replacement.

Sidebar: Overview of the IMD Shield from a USENIX Security 2011 poster.

On to the paper's details: A shield is a wearable electronic device that acts as a proxy for an IMD's communications. In a future form, the shield might resemble a locket or necklace. It has two antennas inside, designated TX (transmit) and RX+TX (receive and transmit). It listens on a certain set of wireless channels for messages to or from the IMD. When it hears a message destined for the IMD, the shield transmits a random jamming signal that prevents the IMD from receiving the message. Only after authenticating the message's sender does the shield stop jamming. In the other direction, the shield jams every message sent by the IMD to foil eavesdroppers: it transmits a random jamming signal while simultaneously transmitting an antidote signal that cancels the jamming only at the shield's RX+TX antenna. The shield and an authorized IMD programmer (e.g., one in a doctor's clinic, or a bedside monitor) establish an encrypted channel out of band and exchange messages over it.

Sidebar: The IMD Shield's jamming strategy provides information-theoretic security akin to that of a one-time pad. The shield fails open when off or absent. (From a USENIX Security 2011 poster.)

Mapping the shield's operations to the four key problems above: (1) None of the shield's protection mechanisms require IMD replacement. (2) When the shield is powered off or removed by an emergency responder, it does not jam any signals; the system fails open. (3) The shield's jamming of IMD transmissions foils eavesdroppers, who cannot distinguish IMD transmissions from junk. (4) The shield prevents the IMD from obeying—or even hearing—unauthorized commands.

The shield is currently implemented as a prototype on USRP boards controlled by GNU Radio.

["They Can Hear Your Heartbeats: Non-Invasive Security for Implanted Medical Devices"
by Shyamnath Gollakota, Haitham Hassanieh, Ben Ransford, Dina Katabi and Kevin Fu received the Best Paper Award at ACM SIGCOMM 2011.]

Hugh Darrow and Medical Device Security

This morning a friend sent me a screenshot from the new video game Deus Ex: Human Revolution, which he said gave him déjà vu. The game is about a dystopian future in which the use of human augmentation for clinical and military purposes is widespread. I won't comment on the game's sci-fi prognostication, but it looks like they decided to use our work as background material for this fictional universe.

The screenshot, which appears to the left, contains three sentences taken directly from the abstract of our IEEE paper from 2008: Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-power Defenses.

Compare the screenshot with our original abstract to see for yourself.

I think it only fair that the publisher or the developers send the team here at the Medical Device Security Center a few copies for "peer review." I have an Xbox and a PC, in case anyone is wondering....

Meata Culpa: Methods for Well Done Experiments with Medical Devices and RF

By Shane S. Clark, Benjamin Ransford, and Kevin Fu

This posting is a mea culpa of sorts to correct a research trend of using ground beef and bacon for in vitro experimentation with implanted medical devices in the context of computer communication and trustworthy computing. We have seen several research papers repeating our methods in a variety of computer science venues. While the methods consistently elicit laughter during presentations, our recommendation is that researchers should instead use a less amusing but more carefully calibrated saline bath or synthetic torso.

In 2008, members of the Medical Device Security Center published Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-power Defenses. The paper describes our security analysis of an Implantable Cardioverter Defibrillator (ICD). We found no mechanisms that prevented unauthorized reprogramming of an implant. For example, we demonstrated how to issue a command shock that is designed to induce ventricular fibrillation (a deadly heart rhythm). A number of privacy vulnerabilities were also identified. In concert with our analysis, we developed prototype zero-power defenses intended to mitigate the vulnerabilities that we uncovered. To validate our zero-power defenses, we needed to complete in vitro testing in a somewhat realistic environment. Crunched for time, but with a desire to do better than simple open air testing, we implanted our defensive prototype in a plastic bag full of ground beef and bacon. Kevin was walking through Whole Foods near Amherst in late 2007, and after a quick call with a cardiologist decided to buy some high-fat bacon and ground chuck beef. The cashier gave Kevin some strange looks when he asked if the meat would be a good stand-in for human tissue.

The bag of ground beef and bacon that we used to prototype
our defenses. The video on the bottom shows a batteryless, computational RFID called the WISP. We wirelessly powered the piezoelement (which is audible).

Providing further evidence of the importance of reversing this trend, Jeff Mogul from HP Labs composed this haiku poetry that reflects on our research presented at ACM SIGCOMM.

They can hear your heart beats
Through several layers of
Bacon and beef

Unfortunately, meat remains the state of the art testing methodology for computer scientists working with implantable medical devices (IMDs). We made our original decision to use a bag of meat based on time constraints, and our methodology lacked the scientific rigor for meaningfully reproducible results. As a practicing cardiologist told us, "Dead meat don't beat… a pig heart from the grocery store will be no more electrically active than a cold hot dog - the physiological processes that govern the propagation of electrical impulses through the heart require metabolically active, i.e. 'alive' cells."

We have recently begun to explore the question of how we should conduct in vitro testing in order to have greater confidence in our results. We would like to share what we have found. A scientist from the FDA Center for Devices and Radiological Health pointed us to a methodology that has been used by the FDA to test wireless interference with implantable devices caused by, e.g., RFID readers. This methodology is described in sufficient detail to reproduce in a paper titled, Electromagnetic compatibility of pacemakers and implantable cardiac defibrillators exposed to RFID readers. We have reproduced this experimental setup using ~$30 worth of parts from a hardware store and a handful of other items (see picture below). While this human analogue has the virtue of being a de facto standard used by the FDA, it is still not perfect. It does not conform to any fully specified standard that we are aware of and working with a tub full of water can be an experimental hazard. The next experimental setup that we intend to build conforms to the Association for the Advancement of Medical Instrumentation (AAMI) standard number PC69 and consists completely of discrete analog components. We will be sure to share the details of our experiences once we have completed this next step.

Our FDA-inspired prototype required only: a plastic tub,
steel plates, bolts, nuts, silicone caulk, a refactometer,
distilled water, and table salt.

We encourage any researchers interested in working with IMDs to carefully consider what in vitro testing methodology to use. If computer scientists and other security researchers wish to have an impact that reaches outside of our own community, we will need to adopt credible standards that are used by biomedical engineers and other domain experts. Moreover, experiments must be meaningfully reproducible.

In summary, please avoid beef and bacon in experiments to show that your prototype implantable medical device works effectively. Instead, use a calibrated saline bath or synthetic torso according to AAMI standard PC69. No in vitro apparatus will perfectly model the behavior of a device in vivo, but these methods will lead to more reproducible experiments of stronger scientific rigor. Meata culpa. And may your research now be more well done.