This paper explored the security and privacy vulnerabilities of a
particular implantable pacemaker, and discovered that the device could
be remotely eavesdropped and attacked using an ordinary
software-defined radio.  They conjecture that similar attacks could
be launched against many types of implantable medical devices.

This paper is interesting because it discusses attacks on a physical
device that can potentially kill a person, goes over some of the
ethical concerns of performing and presenting research on such a
device, presents a very interesting case study of how to reverse
engineer specialized equipment using inexpensive parts, presents many
attacks that can then be performed using that inexpensive equipment,
and concludes with a set of potential countermeasures to the attacks
that were identified.

Due to the criticality of these devices, the authors purposefully
restrain themselves from presenting so many details that a malicious
attacker could potentially replicate their attacks.

ICDs are capable of monitoring the operation of a person's heart,
detecting when a problem occurs, adminstering an electrical shock to
restore the proper function of the heart, reporting those events to a
care provider, and also storing a lot of information about the patient
himself, such as his name, his doctor's name, the date on which the
defibrillator and its leads were installed, etc.  These devices are
typically implanted in the patient under the skin with no protruding
parts.  Ordinarily, the batteries are not rechargeable.

The ICD in question contains a magnetic switch that is supposed to
prevent remote programming of the device.  It closes when a
sufficiently strong magnetic field is exerted upon the switch, and the
ICD beeps to indicate that programming is now possible.  However, the
authors' experiments showed that the switch in fact has no control
over when programming can occur, raising questions as to why it exists
at all.  

This is the first paper to demonstrate that general-purpose software
radios can be used to reverse engineer a wireless protocol, which they
did by first determining the general characteristics of the waveforms
transmitted by the ICD and its programmer using an oscilloscope to
visualize the waveforms, and then programming the software radio to
decode those transmissions, using a chained architecture of GNU radio
software components.  To accomplish this, they only needed knowledge
of the broad radio band used by the devices, and the typical encoding
methods used at the physical layer of wireless networks.

They did not fully reverse engineer the system, only enough to
identify the major fields with data they were interested in stealing
or modifying.  They replayed packets that were generated by the
commercial programmer to change the internal state of the ICD.  They
were able to affect the stored patient name, ICD clock, and selected
therapies.  Even after disabling all therapies, they were able to
cause the ICD to issue a test shock to the patient's heart, with
obvious health and safety consequences.  The commercial user interface
for the ICD programmer blocked such dangerous actions, and the authors
argue that such protections should be integrated into the ICD itself.
More subtly, they were able
to cause the ICD to transmit telemetry for several seconds for each
packet received by the ICD, potentially draining the battery.  In
fact, the test ICD started indicating that it should be replaced
during these experiments.

The authors propose several countermeasures to these threats.  To
alert the patient to security-sensitive events, they propose including
a piezo buzzer under the skin, that can be sensed by touch as well as
sound.  However, such a system could also drain power from the
device.  To prevent that, they propose harvesting energy from the
incoming RF signal.  This energy harvesting can also be used to power
a key exchange session, before permitting the programmer to modify
any settings within the ICD.  This key exchange relies upon a global
shared key, which is highly suspect.  Instead, an acoustic key
exchange protocol can be used.

Questions:

 - How difficult would it be for a malicious attacker to replicate the
   attacks described in this paper?  What equipment would be required?

 - Is the subject material of this paper clearly differentiable from
   other security topics?  What about attacks on control networks?
   Vehicles? Peoples' banking credentials?  How should the research
   community regulate itself?

 - It is very easy to eavesdrop on targeted audio from long distances,
   so the acoustic key exchange mechanism described in the paper is
   probably useless.  Can you think of any more effective key exchange
   mechanisms that the acoustic ones proposed in the paper?

 - What do you think of having the patient explicitly authenticate
   security-sensitive requests by pressing a sub-dermal button?

Cons:

 - Bizarre data patterns were unconvincing
 - Experiments were somewhat unconvincing.  Why couldn't they have
   implemented the full protocol?  It's just an extra nonce.