Content uploaded by Eduard Marin
Author content
All content in this area was uploaded by Eduard Marin on Oct 25, 2017
Content may be subject to copyright.
On the (in)security of the Latest Generation Implantable
Cardiac Defibrillators and How to Secure Them
Eduard Marin
ESAT-COSIC and iMinds
KU Leuven, Belgium
eduard.marin@esat.kuleuven.be
Dave Singelée
ESAT-COSIC and iMinds
KU Leuven, Belgium
dave.singelee@esat.kuleuven.be
Flavio D. Garcia
School of Computer Science
University of Birmingham, UK
f.garcia@bham.ac.uk
Tom Chothia
School of Computer Science
University of Birmingham, UK
t.p.chothia@cs.bham.ac.uk
Rik Willems
Cardiology, University Hospital
Gasthuisberg
Leuven, Belgium
rik.willems@uzleuven.be
Bart Preneel
ESAT-COSIC and iMinds
KU Leuven, Belgium
bart.preneel@esat.kuleuven.be
ABSTRACT
Implantable Medical Devices (IMDs) typically use propri-
etary protocols with no or limited security to wirelessly com-
municate with a device programmer. These protocols enable
doctors to carry out critical functions, such as changing the
IMD’s therapy or collecting telemetry data, without hav-
ing to perform surgery on the patient. In this paper, we
fully reverse-engineer the proprietary communication pro-
tocol between a device programmer and the latest genera-
tion of a widely used Implantable Cardioverter Defibrilla-
tor (ICD) which communicate over a long-range RF channel
(from two to five meters). For this we follow a black-box
reverse-engineering approach and use inexpensive Commer-
cial Off-The-Shelf (COTS) equipment. We demonstrate that
reverse-engineering is feasible by a weak adversary who has
limited resources and capabilities without physical access to
the devices. Our analysis of the proprietary protocol results
in the identification of several protocol and implementation
weaknesses. Unlike previous studies, which found no secu-
rity measures, this article discovers the first known attempt
to obfuscate the data that is transmitted over the air. Fur-
thermore, we conduct privacy and Denial-of-Service (DoS)
attacks and give evidence of other attacks that can compro-
mise the patient’s safety. All these attacks can be performed
without needing to be in close proximity to the patient. We
validate that our findings apply to (at least) 10 types of
ICDs that are currently on the market. Finally, we propose
several practical short- and long-term countermeasures to
mitigate or prevent existing vulnerabilities.
1. INTRODUCTION
Implantable Medical Devices (IMDs) such as pacemakers
and Implantable Cardioverter Defibrillators (ICDs) are used
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full cita-
tion on the first page. Copyrights for components of this work owned by others than
ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-
publish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from permissions@acm.org.
ACSAC ’16, December 05-09, 2016, Los Angeles, CA, USA
c
2016 ACM. ISBN 978-1-4503-4771-6/16/12.. . $15.00
DOI: http://dx.doi.org/10.1145/2991079.2991094
to monitor and help control abnormal heart rhythms. ICDs
are battery-powered devices that deliver electric shocks to
the patient’s heart if the heartbeat is too fast. Some ICDs
can also act as a pacemaker and give tiny electrical shocks
if the heartbeat is too slow. ICDs have evolved over three
generations. The first generation (or the oldest) do not have
any wireless interface and hence do not allow reprogramming
once the ICD is implanted. The second and third generation
enable wireless communication with external devices includ-
ing device programmers and base stations. Device program-
mers are used by medical personnel to wirelessly modify the
ICD’s settings or collect telemetry data, whereas base sta-
tions, installed in the patients’ home, allow remote monitor-
ing by gathering telemetry data from the ICD and sending
this data to the hospital. Both device programmers and base
stations have a programming head that activates the ICD’s
wireless interface when it is placed above the implantation
site (the patient’s chest) for a few seconds.
The second generation of ICDs supports wireless commu-
nication between the programming head and the ICD only
over a short-range communication channel (less than 10 cm ).
In the third generation (the latest), the programming head
is first used over the short-range communication channel to
activate the long-range communication link of the ICD. This
process is illustrated in Fig 1. Both devices can then com-
municate with each other over a long-range communication
channel (from two to five meters), not requiring the use of
the programming head anymore, unless the session expires.
While these advances bring substantial clinical benefits
to patients, new security and privacy threats also emerge,
specially due to the wireless communication between these
devices. Adversaries may eavesdrop the wireless channel to
learn sensitive patient information, or even worse, send ma-
licious messages to the ICD. The consequences of these at-
tacks can be fatal for patients as these messages can contain
commands to deliver a shock or to disable a therapy.
Our contribution: This paper presents the first reverse
engineering and security analysis of the proprietary long-
range communication protocol between the device program-
mer and the latest generation of ICDs. For the reverse
engineering we use a black-box approach and inexpensive
Commercial Off-The-Shelf (COTS) equipment. This task is
not trivial since it was first necessary to find the symbol
rate from the waveform of the signals sent by the devices in
order to demodulate the captured messages correctly. We
show that for proprietary protocols on which we had no prior
knowledge or documentation, reverse-engineering is possible
by a weak adversary without even needing to have physi-
cal access to the devices. Our second contribution consists
of demonstrating several attacks that can compromise the
ICD’s availability and the patient’s privacy. We give evi-
dence that replay and spoofing attacks are possible as well.
To evaluate the feasibility of these attacks, we describe sev-
eral ways to circumvent the short-range communication step,
which requires being close to the patient, and perform ses-
sion hijacking. We validated that our findings apply to (at
least) 10 different ICD models. Our third contribution is the
proposal of several short- and long-term measures to miti-
gate or solve the existing vulnerabilities in the latest genera-
tion of ICDs including a novel key agreement protocol which
we formally verified using ProVerif.
Disclosure of results: In accordance with the principle
of responsible disclosure, we have contacted and discussed
our findings with the manufacturer before disclosure. Given
the sensitive nature of our work, we omitted some of the
obtained results to avoid easy replication of the attacks.
Paper outline: The remainder of this paper is organ-
ised as follows. Section 1gives an overview of related work
and shows our laboratory setup. Section 2explains the pro-
cess of reverse-engineering the proprietary protocol between
the device programmer and the ICD. Section 3describes
several strategies to circumvent the short-range communi-
cation, which requires close proximity to the patient. Sec-
tion 4shows the protocol weaknesses and implementation
flaws whereas practical and effective short- and long-term
countermeasures to mitigate or solve these vulnerabilities
are presented in Section 5. Finally, Section 6gives conclud-
ing remarks.
ICD
programming head
device
programmer
Figure 1: ICD activation procedure.
1.1 Related work
1.1.1 Software radio-based attacks on IMDs
Several papers have demonstrated that IMDs often lack
strong security mechanisms, which makes them vulnerable
to different types of remote attacks. Hei et al. showed a sim-
ple yet effective attack where adversaries force the IMD to
respond to their messages, which reduces the battery life of
the IMD [13]. Halperin et al. analysed the proprietary proto-
col between the device programmer and a second generation
ICD to communicate over the short-range communication
channel [12]. As no security mechanisms were found, they
were able to carry out several software radio-based attacks
just by replaying past transmissions sent by the legitimate
device programmer. Similar attacks can also be performed
on an insulin pump, as shown by Li et al. [7]. Marin et al.
fully reverse-engineered the proprietary protocol between all
devices in a wireless insulin pump system, and extended the
attacks of Li et al. [16]. Unlike the work by Halperin et
al. [12], which focused on the short-range communication
(less than 10 cm), we analyse the proprietary protocol be-
tween the device programmer and a latest generation of ICD
over long-range communication (from two to five meters).
1.1.2 Countermeasures
Various countermeasures have been proposed to solve the
vulnerabilities found in IMDs. Gollakota et al. presented
the “shield”, an external device that acts as a proxy between
the device programmer and the ICD. The shield jams the
messages to/from the IMD to prevent others from decoding
them, while still being able to successfully decode them it-
self [10]. Although this solution mitigates some of the exist-
ing problems, it does not protect against adversaries who can
transmit malicious messages with much more power than the
shield. Tippenhauer et al. demonstrated that the shield does
not provide confidentiality as a MIMO eavesdropper could
cancel out the interference produced by the shield and then
recover the messages sent by the devices [21]. Xu et al. intro-
duced a wearable device, also known as “IMDGuard”, which
does not only work as a proxy but also performs an authen-
tication process on the ICD’s behalf [22]. But Rostami et
al. found that the “IMDGuard” is vulnerable to a Man-In-
The-Middle (MITM) attack which reduces its effective key
length from 129 bits to 86 bits [19]. Rostami et al. pre-
sented Heart-to-Heart (H2H), a commitment-scheme-based
pairing protocol through which the device programmer au-
thenticates to the IMD without needing to share any prior
secrets [20]. H2H implements a novel access-control policy
called “touch-to-access” that ensures access to the IMD by
any device programmer that can make physical contact with
the patient and measure his heart rate. However, Marin et
al. found that the H2H is vulnerable to a reflection and a
MITM attack [15].
Another line of research relies on exchanging a crypto-
graphic key between the device programmer and the IMD
via an auxiliary or Out-Of-Band (OOB) channel. Halperin
et al. proposed a zero-power authentication that uses an
RFID tag in combination with a piezo-element for audio-
based key distribution. However, Halevi et al. demonstrated
the feasibility of eavesdropping the audio transmissions of
the piezo element [11]. Rasmussen et al. proposed an ac-
cess control scheme based on ultrasonic distance bounding
which enables the IMD to grant access to its resources to
only a device programmer that is in its close proximity [18].
However, this typically requires dedicated analog hardware,
which makes the solution expensive to integrate in resource-
constrained devices like IMDs. Another proposal is to use
a Body-Coupled Communication (BCC) channel. Yet, Li
et al. showed that remote eavesdropping on a BCC channel
is possible with a very sensitive antenna [7]. In this paper,
we present practical and effective countermeasures that can
be divided into two groups: short-term and long-term mea-
sures. The former do not require any modification on the
ICDs and hence may be immediately adopted whereas the
latter can be implemented in future generations of ICDs.
1.2 Laboratory setup
Our laboratory setup comprises available Commercial Off-
The-Shelf (COTS) hardware including an Universal Serial
Radio Peripheral (USRP) [4], a data acquisition system
(DAQ) [1] and a few antennas, as shown in Fig 2. In addi-
tion, we have the following medical devices: a device pro-
grammer, a base station and several ICD models of the latest
generation. For our experiments, we created a receiver and a
transmitter programs using LabVIEW [3]. The first step of
our black-box reverse-engineering approach is to eavesdrop
the wireless channel and capture the messages exchanged be-
tween the device programmer and the ICD. We then analyse
the messages to discover its format, and study how the mes-
sages are exchanged between the devices, i.e. the protocol
state-machine. Subsequently, we are able to create and send
our own messages to the ICD by means of the USRP, the
antenna and our transmitter program. To better evaluate
the feasibility of these attacks, we also study the ICD acti-
vation procedure. For this we use a DAQ and an antenna
to intercept the messages exchanged over the short-range
communication channel.
Figure 2: Laboratory setup. At the top, from left
to right, are our USRP and the DAQ. Our antennas
are shown at the bottom.
2. INTERCEPTING THE WIRELESS
TRANSMISSIONS
Several articles [12,7,16] have already pointed out that
IMD manufacturers often rely on hiding the protocol spec-
ifications to provide security. This is commonly known as
security-by-obscurity. Proprietary protocols typically offer
very limited or no security guarantees and have been bro-
ken via different reverse-engineering techniques. This paper
analyses the proprietary protocol between device program-
mers and the latest generation of ICDs to communicate over
a long-range channel. Instead of opening the devices to get
their firmware for the purpose of reverse-engineering the pro-
tocol, we follow a black-box approach. A similar approach
has been used in other articles [8,9]. Our black-box ap-
proach consists of giving some inputs to the devices and
then inferring information by looking at their outputs, i.e.
the produced messages. In our work we study the feasibility
of reverse-engineering the proprietary protocol by a weak ad-
versary who has limited resources and capabilities. Through
meticulous analysis of these messages, we can infer the mes-
sage format and the protocol state-machine. Our black-box
approach, which is a labour-intensive process, is more chal-
lenging yet more realistic than other existing techniques, as
it assumes a weak attacker who can intercept the messages
sent wirelessly using a USRP and an antenna, but cannot
have physical access to the devices. We will now summarise
our approach and main findings.
2.1 Wireless communication parameters
Transmission frequency: The ICD and the device pro-
grammer’s programming head first communicate over the
short-range communication channel (between 30-300 kHz)1.
After the ICD is activated, both devices communicate over
the long-range communication channel using the MICS2band
(402-405 MHz). The transmission frequency of the devices
can be obtained through their Federal Communications Com-
mission (FCC) ID [2].
Modulation: By examining the signals sent by the de-
vices both in the time and frequency domain, we found that
the device programmer and the ICD use distinct modula-
tions to transmit their data. In particular, the transmis-
sions from the device programmer to the ICD use a Fre-
quency Shift Keying (FSK) modulation, whereas a Differen-
tial Phase Shift Keying (DPSK) modulation is used in the
transmissions from the ICD to the device programmer [17].
Symbol rate: Due to the modulations being used, dis-
covering how many symbols (i.e. modulated bits) are sent
in each message simply by looking at signal’s waveform is a
challenging problem.
To estimate the symbol rate, we created a Matlab program
that uses the Hilbert transform to obtain the instantaneous
frequency of the signal. A key observation is that by de-
modulating the signals using an FM receiver and looking
at the demodulated waveforms, we found that the message
sent by the device programmer to request telemetry data is
always identical. This message is sent continuously to the
ICD when no operation is performed. The first step is to in-
tercept several of these messages and store their waveforms
in a file. Our program takes these waveforms as inputs and
produces a graph that shows where the frequency shifts oc-
cur, i.e. where each symbol starts and ends.
Fig 3shows the instantaneous frequency of the device pro-
grammer’s signal. The symbol rate can then be obtained by
computing the inverse of the difference between the times
where two abrupt peaks occur. However, instead of giv-
ing only one symbol rate value, this approach gives a small
range of possible values. Therefore, the second step was to
create another program that performs a sweep over all pos-
sible symbol rate values within this range, increasing the
symbol rate by one symbol each time. For each iteration,
our program demodulates several of the messages previously
captured, and then checks whether the demodulated bits are
equal for all the messages. This allows us to find the symbol
rate being used by the devices, as the correct symbol rate is
the one for which no bit errors are produced.
1We do not specify the exact transmission frequency as this
may implicitly reveal the manufacturer’s identity.
2Medical Implant Communications Service.
Time (sec) ×10 -3
0 0.2 0.4 0.6 0.8 1
Amplitude (V)
-0.2
-0.1
0
0.1
0.2
Time (sec) ×10 -3
0 0.2 0.4 0.6 0.8 1
Freq (Hz)
×10 4
-5
0
5
Figure 3: Symbol rate estimation based on the
Hilbert transform. In the top chart, the waveform
of the signal transmitted by the device programmer.
In the bottom chart, the instantaneous frequency of
the device programmer’s signal.
2.2 Reverse-engineering the long-range
communication protocol
In this section, we show how to reverse-engineer the pro-
prietary protocol between the device programmer and the
ICD to communicate over the long-range channel. We first
activate the ICD and put the device in“interrogation”mode.
More details on how adversaries can activate the ICD are
given in Section 3.
We found that all messages have a common Start-of-Frame
(SoF) that consists of a series of alternating “1s” and “0s”
sent consecutively to indicate the presence of an incoming
message. This is followed by a preamble sequence which
indicates that the information bits are about to begin. To
distinguish the messages sent by the device programmer and
the ones sent by the ICD, we placed the device programmer
close to our USRP while keeping the ICD further away, thus
getting more power from the device programmer. Unlike
the messages sent by the ICD, which only use one preamble
sequence, two preamble sequences can be used in the mes-
sages sent by the device programmer; a specific sequence or
its inverse. Messages from device programmers have a fixed
length and include a 3-bit End-of-Frame (EoF) sequence
whilst ICDs send messages with three possible lengths that
do not contain any EoF.
2.2.1 Transmissions device programmer - ICD
We intercepted the messages sent from the device pro-
grammer to the ICD while carrying out different operations
(e.g. changing the therapy settings). For the sake of simplic-
ity, we will focus only on the messages sent from the device
programmer to the ICD in order to change the patient’s
name. This process typically includes 16 messages and is
always composed of two differentiated groups of messages
separated by a long message sent by the ICD, as shown in
Figure 4. The former group includes messages 1-8, whereas
the second group includes the 9th up to the 16th message.
We found that the 16 messages have a x-bit sequence that
denotes the message type. In each of the two messages’
groups, there are three possible message types independently
of the operation being conducted: (i) an opening message,
(ii) intermediate messages and (iii) a closing message. We
determined that the first and the nineth messages contain
the Serial Number (SN) of the device programmer. The
ICD SN appears only in the messages sent by the device
programmer when the ICD is in the “no telemetry” mode.
In other words, this is sent only if the ICD loses the connec-
tion with the device programmer during an ongoing session.
Each SN is represented by a 24-bit sequence. Subsequently,
we observed that there is a y-bit sequence to indicate the
message number within the first group of messages. This
field is kept static in the second group of messages. Since
the message number field only has a short length and eight
messages are sent by the device programmer within the first
group of messages, this field is reset frequently. By cap-
turing and analysing the 16 messages sent by the device
programmer in several consecutive iterations within a re-
programming session, we found two short counters, in the
first and ninth message respectively. Both counters are in-
creased every time an operation is performed and are reset
when a new reprogramming session is established.
Am
p
litud
e
0,02
-0,02
-0,01
0
0,01
T
ime
1,00
200,00m 300,00m
400,00m 500,00m 600,00m 700,00m 800,00m 900,00m
(1) (2) (3) (4) (5) (6) (7) (8)
FIRST GROUP
(9) (10)(11) (12) (13) (14) (15) (16)
SECOND GROUP
Figure 4: Messages exchanged between the device
programmer and the ICD while changing the pa-
tient’s name.
We discovered that there is a 16-bit sequence at the end of
each message that seems to be random and varies depending
on the headers and data being sent. This lead us to think
that a checksum, such as a Cyclic Redundancy Code (CRC),
is used. To validate our hypothesis, we took the GCD of sev-
eral of these messages (in polynomial form), and discovered
that the CRC-16-CCITT is being used [14]. Other mecha-
nisms, such as repetition codes, are used to help the ICD
detecting bit errors. We noted that if the patient’s name
contains less than 14 characters, it is sent three times, oth-
erwise it is sent twice within the first group of messages.
Fig 5shows the device programmer’s message format.
2.2.2 Data whitening
We carried out a series of experiments to find how the
data is encoded in the message. For this we focused on the
messages sent by the device programmer when changing the
patient’s name.
The first experiment consisted on finding where the let-
ters are within the messages and see how many bits are used
to represent each letter. In particular, we changed the pa-
tient’s name to “A”, “AA”, “AAA”, “AAAA” and “AAAAA”,
respectively. We then intercepted the messages and com-
pared them with the ones sent by the device programmer
when the patient’s name field is left empty. We found that
the first four letters are sent within the first message and
that each letter is represented by an 8-bit sequence. In ad-
dition, we observed that there is no unique pattern to repre-
sent the “A”. The next step was to reprogram the patient’s
SoF
| {z }
49 bits
Preamble
| {z }
31 bits
Message type
| {z }
x bits
Message number
| {z }
y bits
Payload
| {z }
z bits
CRC
| {z }
16 bits
EoF
| {z }
3bits
Figure 5: Device programmer’s message format. The exact bit lengths are not shown.
name while keeping a specific letter in more than one posi-
tion. We modified the patient’s name to “AAAA”, “ABAB”
and “ACAC”, respectively. This experiment demonstrated
that the way how each letter is encoded depends on its po-
sition within the patient’s name. In other words, an “A” in
the first position is always represented in the same way but
differently to an “A” in another position. By comparing the
8-bit sequences of the “A”,“B” and“C”in the second and the
fourth position, respectively, we noticed that the Hamming
distance between the sequences is constant. This allowed
us to conclude that the data is XORed with an output se-
quence from a Linear Feedback Shift Register (LFSR) (see
Figure 6)3. The vendor states that this is a data whitening
operation to prevent long strings of “1s” and “0s” in the d ata.
However, this operation could also serve as data obfuscation.
In our experiments, we were able to recover the LFSR
sequence by intercepting the messages sent by the device
programmer when the patient’s name is left empty (i.e. only
spaces). We then computed the XOR between the first mes-
sage sent by the device programmer when changing the pa-
tient’s name to “AAAA” and the LFSR sequence. After
performing this operation, we found a unique pattern to
represent each of the four “As” of the patient’s name. This
pattern turned out to be identical to its ASCII representa-
tion. Our experiments reveal that this LFSR sequence is
constant throughout sessions. Moreover, we found that the
LFSR sequence is the same for all the ICDs we studied in our
experiments. We validated our findings in 10 different ICD
models, and concluded that all models use this technique to
encode the data that is sent over the air.
00101011 10111101 00011010
00011010
01101001 01010001
01010001
01010001
11101000
11101000
00101011
00101011
00101011 11101000
10001001
01100001
01101001
00001000
01100001
01111101
00011100
01100001
01001010
01100001
-----------------------------------
A A A A
(a)"A"
"AA"
"AAA"
"AAAA"
LFSR seq
ASCII
(b)
(c)
(d)
(e)
(f)
Figure 6: LSFR XOR operation.
2.2.3 Transmissions ICD - device programmer
We intercepted and examined several messages transmit-
ted by the ICD. We did not find any header that is specific
for the ICD type or any field that denotes the ICD type.
We verified that all messages sent from the ICD to the de-
vice programmer use the same LFSR sequence as the one
previously described. We noted that all the messages have
the ICD SN. In contrast, the ICD includes the device pro-
grammer’s SN only in replies to no telemetry messages. We
3The data and the LFSR sequence that are shown in Figure
6 are not the real ones.
discovered that the ICD messages have a counter that helps
the device programmer to sort the incoming messages or de-
tect message losses. We observed that most of the informa-
tion bits seem random. Since the ICD’s leads are no longer
connected to the patient’s heart and are very sensitive to
low-frequency changes, we noticed that they were measur-
ing the ambient noise and treating it as random telemetry
data. To investigate where the telemetry data is within the
message, instead of injecting our own signal to the ICD’s
leads, we introduced the ICD’s leads into a Faraday cage to
isolate them. We then captured several messages sent by
the ICD, and noted that they have a more constant pattern
which is no longer random. Furthermore, we identified sev-
eral bit sequences that are common to the three types of ICD
message regardless of the operation being performed. These
sequences are most likely used for synchronization purposes.
Finally, we discovered that, similarly to the messages sent
by the device programmer to the ICD, all messages have a
16-bit checksum, which is based on the standard CRC-16-
CCITT.
3. HOW TO ACTIVATE THE ICD?
Before exploiting our findings to carry out attacks, we first
need to activate the ICD. To demonstrate the feasibility of
these attacks, we describe several ways to bypass the current
activation procedure, which requires almost physical contact
with the patient and is carried out over a short-range com-
munication channel. For simplicity, in the next sections we
often use the term “external device” to denote both device
programmers and base stations.
Sleep mode
Standby
mode
Interrogation
mode
Reprogramming
mode
2h
5min
Figure 7: ICD modes of operation.
Our experiments show that the ICD can operate in five
different modes: “sleep”, “interrogation”, “reprogramming”,
“no-telemetry” or “standby”. In the rest of this paper, we
will not discuss the “no-telemetry” mode further since this
mode was not relevant for our experiments. Figure 7gives
an overview of the modes. Initially, the ICD is in a “sleep”
mode in which it occasionally activates the wireless inter-
face to check whether there is an incoming message sent by
a device programmer over the short-range communication
channel. Once the ICD is activated, it remains in “interro-
gation” mode where it continuously sends telemetry data to
the device programmer over the long-range communication
channel. If no reprogramming operation is performed by the
doctor, the ICD is in the “interrogation” mode for two hours.
If the doctor modifies the ICD settings within this two-hour
window, the ICD switches to “reprogramming” mode for a
few seconds and then goes b ack to the “interrogation” mode,
where is kept active for two hours. When the session expires
(after two hours), we observed that, instead of immediately
switching to “sleep” mode, the ICD goes first to “standby”
mode. We will explain the “standby” mode more in detail
later in this section.
We will now describe four possible ways to send malicious
messages to the ICD, depending on whether the ICD is ac-
tive, in “standby” or in “sleep” mode.
Exploit an active session: Intuitively, adversaries could
attempt to hijack an ongoing session between the external
device and the ICD to send malicious commands to the ICD.
This is a challenging task since this requires the adversary
to be in close proximity to the patient (e.g. in the hospi-
tal). Furthermore, adversaries need to send the malicious
commands to the ICD while having to block the messages
sent by the genuine external device. To masquerade their
attacks, adversaries may also send fake telemetry data to
the genuine external device to avoid that the doctor/patient
notices that the ICD is no longer communicating with it.
Standby mode: We discovered that the ICDs do not im-
mediately switch to “sleep” mode after finishing an ongoing
session with the device programmer, but they all remain in
a “standby” mode for five minutes. This is a safety feature
but also has security consequences.
While being in “standby” mode, any device programmer
can activate the ICD again by sending a specific message
over the long-range communication channel. This message
turns out to be identical for all ICDs. We also found this
weakness in the case where the ICD is activated by means
of the base station. In that case, the ICD is active for five
minutes only if the session with the base station is not ter-
minated correctly.
We were able to impersonate the device programmer and
successfully send this message to the ICD to keep it alive.
For our experiments, we used the transmitter port of our
USRP to emulate the device programmer’s behaviour and
the receiver port of our USRP to capture this signal and
the response sent by the ICD. To distinguish between the
messages sent by our USRP and the responses sent by the
ICD, we placed the ICD close to the receiver port of our
USRP while keeping the transmitter port of our USRP fur-
ther away, thus getting more power from the ICD. This at-
tack is illustrated in Figure 8. Therefore, adversaries could
wait until the session between the device programmer and
the ICD finishes and then repeatedly send this message to
the ICD. This could be used to drain the ICD’s battery, or
even worse, to extend the time window as long as needed to
send as many malicious messages as required to compromise
the patient’s safety.
Wake up the ICD from “sleep” mode : We noted that
the device programmer’s programming head is magnetic. To
eliminate the possibility that a magnet is needed to boot-
strap the communication with the ICD, we conducted an
experiment where we placed a magnet near the ICD. The
result of this experiment showed that the magnet alone can-
Amplitude
0,03
-0,03
-0,02
-0,01
0
0,01
0,02
Time
Figure 8: Messages sent to the ICD while the ICD
is in “standby” mode in order to activate it. From
left to right, two messages sent (with different gain)
from our USRP to wake up the ICD, the response
of the ICD and two messages sent by the USRP.
not activate the ICD’s wireless interface. The next step was
to investigate which data is exchanged between the devices
before the long-range communication starts. For this we
studied the short-range communication between the device
programmer and the ICD, focusing on the messages sent by
the device programmer.
We used our DAQ and an antenna to capture the mes-
sages sent by the device programmer at 30-300 kHz. Every
time a new session is established, the device programmer
sends three messages to the ICD via the programming head.
Following the same steps as those described in the previous
section, we were able to unveil the wireless communication
parameters being used. In particular, we found that the
messages sent by the device programmer are modulated us-
ing a FSK and encoded under Non-Return-to-Zero Inverted
(NRZI). In NRZI, a ‘1’ is represented by a transition of the
voltage level, whereas a ‘0’ has no voltage transition. We also
determined that the symbol rate is 12500 symbols/second.
We created a LabVIEW program to intercept and demod-
ulate the three messages transmitted by the device program-
mer’s programming head. We noted that the first message is
always identical regardless of the ICD being used, whilst the
second and third message vary depending on the ICD’s SN.
The other headers and information bits within the second
and third message are kept constant, making the short-range
communication vulnerable to replay attacks. Thus, adver-
saries need to eavesdrop the wireless channel only once to
intercept the three messages sent by the device programmer.
Adversaries could then carry a backpack with all the neces-
sary equipment and re-send these messages to the ICD when
the patient is in a crowded place (e.g. the public transporta-
tion) where adversaries can be relatively close to the patient
and still go unnoticed.
Using legitimate external devices: Alternatively, ad-
versaries can also use any legitimate external device to con-
duct the attacks. Unlike device programmers, which are big,
heavy and cannot be hidden easily, base stations are inex-
pensive, portable and can be easily purchased. Therefore,
one possibility is to use a legitimate base station to carry out
these attacks. However, a base station by itself cannot send
commands to reprogram the ICD. In our experiments, we
show that adversaries can use any legitimate base station
to activate the ICD. Since the ICD remains in “standby”
mode if the session with the base station is not terminated
correctly, adversaries can simply carry the base station in a
backpack and turn it off before the communication with the
ICD ends in order to keep the ICD alive. Adversaries can
then use their own equipment to send malicious messages to
the ICD over the long-range communication.
4. EXISTING VULNERABILITIES
In this section we will briefly summarise the weaknesses
we found after fully reverse-engineering the proprietary pro-
tocol. These weaknesses can result in several types of active
and passive software radio-based attacks. We want to stress
that adversaries could use sophisticated equipment and di-
rectional antennas to extend the distance from which they
can carry out attacks by several orders of magnitude.
4.1 Privacy attacks
Our analysis of the proprietary protocol between the de-
vice programmer and one model of the latest generation of
ICDs reveals that the messages sent over the air are “obfus-
cated” using an LFSR sequence. This LFSR sequence is the
same for all models that we studied.
The messages exchanged between the devices include pa-
tient private sensitive information such as personal data (e.g.
his name or medical history) or telemetry data. Clearly, the
way they use the LFSR sequence to obfuscate the data can
result in serious patients’ privacy breaches. Passive adver-
saries can compromise the patient’s privacy just by eaves-
dropping the wireless channel while there is an ongoing com-
munication. However, this attack typically requires the ad-
versaries to wait until the devices exchange this data. This
limitation can be overcome by active adversaries who can
additionally send malicious messages to the ICD to request
this data.
By intercepting the messages sent by ICDs and looking
at their unique SN, adversaries could track, locate or iden-
tify patients. For example, adversaries could install beacons
in strategic locations (e.g. the train station or the hospital)
to infer the patients’ movement pattern based on the signals
transmitted by their ICDs. This could reveal their addresses,
the places they often go, and other potential sensitive infor-
mation. Furthermore, the messages sent between the devices
during a reprogramming session may allow adversaries to in-
fer the patient’s treatment or the therapy details. Telemetry
data, which is sent continuously by the ICD when it is active,
could reveal the patient’s health state. Overall, it is clear
that the consequences of all these attacks can be severe for
patients.
4.2 Denial-of-Service (DoS) attacks
As shown in the previous sections, ICDs can operate in
four distinct modes: “sleep”, “interrogation”, “reprogram-
ming” and “standby”.
Intuitively, the ICD should immediately switch to “sleep”
mode when the communication session with the device pro-
grammer finishes or when it expires after two hours with no
reprogramming operation. However, we discovered that, af-
ter the ICD has been activated, it remains in“standby”mode
for five minutes, where it can be put in the “interrogation”
mode again if it receives a specific message. This message
turns out to be identical for all ICDs and is sent over the
long-range communication channel. In other words, there
is no need for being in close proximity with the patient to
activate his ICD. This is an important implementation flaw
that makes these devices vulnerable to DoS attacks. The
purpose of these attacks is to keep the ICD alive by contin-
uously sending this message over the long-range communi-
cation, which could drastically reduce the ICD battery life.
Yet, this also opens up the door for adversaries to perform
other types of attacks more easily, as they can send this
message to extend the five minute window as many times
as needed to send malicious messages to the ICD without
requiring being close to the patient.
4.3 Spoofing and replay attacks
After fully reverse-engineering the proprietary commu-
nication protocol between the device programmer and the
ICD, we were able to fully document the message format in
use. Our results show that there is no mechanism to pre-
vent replay attacks; the counters found in the first and ninth
message are reset every time a new session is established
or after a relatively small number of operations. Without
even knowing the protocol specifications, adversaries could
successfully perform replay attacks just by re-sending past
transmissions sent by the legitimate device programmer. In
addition, the protocol does not provide any means to check
the integrity and authenticity of the messages. Thus, it is
possible to perform spoofing attacks, which allow adversaries
to send arbitrary commands to the ICD.
5. COUNTERMEASURES
In this section, we present practical and effective coun-
termeasures to mitigate/solve the vulnerabilities found in
the previous sections. We divide our countermeasures into
two groups: short-term measures and long-term measures.
The former group could be deployed immediately to miti-
gate some of the existing security issues in already-implanted
ICDs, whereas the latter group require minor modifications
on the devices and hence could be integrated into future
generations of ICDs.
5.1 Short-term measures
5.1.1 Jamming the wireless channel
As shown in the previous section, adversaries can take ad-
vantage of the time the ICD is in “standby” mode to carry
out a DoS attack, or even worse, to extend the time they can
send malicious messages to the ICD. Thus, our first coun-
termeasure consists of adding a “shutdown” command in all
external devices so that they continuously jam the wireless
channel while the ICD is in “standby” mode. A more efficient
solution is to jam the wireless channel only if an adversary is
detected. This is also known as reactive jamming. Several
articles have already used friendly-jamming as a defensive
mechanism.
One possible drawback of our countermeasure is that it
could interrupt the ongoing communications between other
legitimate devices. We leverage on the fact that the patient
typically has his ICD being reprogrammed/interrogated in
isolated controlled locations; either in the doctor’s office or in
the patient’s home. This clearly reduces the risks of jamming
other ongoing communications. Another downside of our
countermeasure is that it works only if the patient stays
close to the external device for five minutes while his ICD is
in “standby” mode. Due to that the ICD listens to all MICS
channels while being in “standby” mode, external devices
need to be equipped with several antennas to simultaneously
jam all MICS channels.
5.2 Long-term measures
5.2.1 Adding a shutdown command in the ICDs
Instead of relying on friendly-jamming to prevent adver-
saries from sending malicious messages to the ICD, our sec-
ond countermeasure is based on modifying both external
devices and ICDs to include a “shutdown” message. This
way, the external device can send the “shutdown” message
to the ICD before they finish the communication to ensure
that the ICD goes directly to “sleep” mode. Even though
this countermeasure does not completely solve the existing
vulnerabilities, this makes it more difficult for adversaries to
send malicious messages to the ICD.
5.2.2 Key agreement protocol
As a long term improvement, Halperin et al. proposed
adding standard symmetric key authentication and encryp-
tion between the ICD and the programmer. For this they
proposed to have the master key on every device program-
mer (stored in tamper-resistant hardware) and diversified
keys in the ICDs. This setup is clearly a significant im-
provement over existing systems. Yet, having the master
key stored in every device programmer is latent risk. If the
tamper-resistant hardware of a single device programmer is
ever compromised, then there is no way to revoke the keys
and every patient with an implant will be exposed indefi-
nitely, or until the IMD is replaced.
Another alternative is to store the master key in the cloud,
in order to limit its distribution to a single instance, and
have the device programmers online. But this is not a viable
option as the device programmers are required to operate (in
case of emergency) at all times, including during Internet or
cloud provider outages.
In this paper we propose a middle ground between these
two approaches: a semi-offline protocol. We leverage on the
fact that both IMDs and device programmers have a precise
internal clock which is synchronised at every communica-
tion session. This clock allows the IMD to keep a log file
with all critical events and the time when they occurred.
Let G1and G2be two multiplicative groups of prime order
q. Furthermore, let e:G1×G1→G2be a bilinear map
satisfying:
Bilinearity ∀g, h ∈G1,∀a, b ∈Z∗
q, e(ga, hb) = e(g, h)ab .
Non-degeneracy ∀g∈G1, g 6= 0 implies that e(g, g ) is a
generator of G2.
Computability ecan be computed in polynomial time.
Let H1, H2:{0,1}∗→G1be two different cryptographic
hash functions satisfying standard security requirements.
When the system is initialised, the key generation centre
generates the system master secret key msk which is stored
securely at the back office, and is never shared with anyone.
Let ID be the IMD identities domain which is assumed to
be disjoint to the time domain. Each IMD id ∈ID stores a
diversified key H2(id)msk which is provided at manufacture
time (all the operations here are done modulo q). Device
programmers receive a temporal key H1(t)msk which is valid
to derive all IMD’s diversified keys but only for the time pe-
riod t. This period of time can be anything, but for the sake
of example let us take this time period to be three months.
In that case, every three months, the device programmer (or
a health-care employee) needs to contact the device manu-
facturer to obtain the key for the next quarter H1(t+ 1)msk
which is sent over a secure channel. In this way, if a de-
vice programmer is lost, stolen or tampered with, this can
be reported to the device manufacturer and then this de-
vice will no longer receive key updates, rendering it useless.
Any key material which may have been extracted from the
device becomes obsolete after (at most) three months and
then the system goes back to a secure state. Fig 9describes
our semi-offline key agreement protocol in detail.
This protocol requires one bilinear pairing computation
on the IMD which is expensive, but this only needs to hap-
pen once every three months. On a daily basis, IMD and
device programmer simply run a standard symmetric key
authentication protocol like the one proposed by Halperin
et al., using the agreed key e(H1(t), H2(id))msk . Note that
this protocol does not provide key confirmation, but this
can be easily achieved by the symmetric key authentication
protocol as it is the case in Halperin et al.
5.2.3 Formal analysis of our protocol
To provide some level of assurance for our protocol we
model and analyse it using the applied pi-calculus [5] and
the checking tool ProVerif [6]. The applied pi-calculus al-
lows us to model protocols, using primitives such as input,
output, new name generation and parallel composition. It
also allows us to define functions and equations that can
be used to model a range of cryptographic primitives. The
ProVerif tool can ensure secrecy and correspondence prop-
erties for an arbitrary number of runs of a protocol using a
automated theorem proving method, however the tool is not
guaranteed to terminate and may report false attacks.
We model an idealised version of bilinear pairings using
functions and equations in the applied pi-calculus, i.e., we
define the functions power(x, y), prod(x, y) and e(x, y ) to
represent xy,xy and the bilinear map e(x, y). We would
then like to define the equation:
equation e(power(a, x),power(b, y)) =
power(e(a, b),prod(x, y))
However, such an equation causes ProVerif’s proof tactics
to enter any infinite loop. Therefore, we introduce an aux-
iliary function to represent the right hand side of this equa-
tion, i.e., we define powere(a, b,prod(x, y)) to represent
e(a, b)xy. We note that this gives an abstract model of bi-
linear pairings that does not include any number theoretic
attacks, such as factoring the product, inverse powers, or
low entropy secrets.
Our model is made up of four processes: Programmer,
which models the programmer protocol role, IMD which
models the IMD, CompromisedReader, which publicly
broadcasts a programmers diversified key for a time period
different to the one used by Programmer, and Compro-
misedUnAuthIMD which models a compromised IMD by
publicly broadcasting the diversified key for a medical device
that is not one accepted by the programmer.
At the end of their run the Programmer and IMD pro-
cesses broadcast a secret value encrypted with the key they
have established. We test the system to see if it is possible
for an attacker to learn this secret, which would mean they
had successfully established a key with the IMD or Program-
mer. The full model is given in Appendix A.
Device Programmer IMD
Stores: H2(id)msk, H2(id), id
Stores: H1(t)msk
id
check id ∈ID t= current time period
e(H1(t)msk, H2(id)) = e(H1(t), H2(id))msk e(H1(t), H2(id)msk ) = e(H1(t), H2(id))msk
Figure 9: A semi-offline key agreement protocol for IMDs.
Testing this model in ProVerif we find that it does in-
deed keep the keys secret. This means that only an IMD
with an ID accepted by the programmer, and a programmer
with a diversified key for the right time period, can set up
and learn keys, even if there are an arbitrary number of old
compromised programmers and IMDs.
To check for redundancy in our protocol, and to see what
kinds of attacks ProVerif can find, we experiment with possi-
ble simplifications. We first try removing the IMD identity
check in the programmer (the “if imdID=id then” line
of the model), in this case ProVerif finds an attack in which
the attacker uses a diversified key from an old, compromised
IMD. If we also remove the CompromisedUnAuthIMD
process, we find that the protocol is then safe. This tells us
that this identity check by the programmer is only needed
to stop attacks using compromised IMDs, if we decided to
discount compromised IMDs in our attacker model we would
not need this check.
As a second test, we tried using a single hash function,
rather than two. In this case, ProVerif finds an attack that
lets an attacker impersonate an IMD: The attacker sends
the old time stamp from a compromised programmer (t′) in
place of the id to the targeted programmer. This leads to
the key programmer using the key e(H(t)msk , H (t′)), however
from the compromised programmer the attacker can learn
H(t′)msk and so construct the matching key e(H(t), H (t′)msk).
This suggests that our protocols use of two hash functions
is a sensible precaution to avoid attacks based on confusing
times and identities. These additional checks gived us in-
crease confidence that the analysis method we use can find
attacks, when present, and that our protocol is not unnec-
essarily complex.
5.2.4 Differentiating between device programmers
and base stations
There is an important distinction to make between device
programmers and base stations as the former are in a much
more controlled environment than the latter. Device pro-
grammers are not sold to anyone: they are available only to
accredited health-care professionals and institutions whereas
base stations are much more available at the patients home.
Some base stations are sometimes available to purchase on
auction sites such as Ebay and is relatively easy to get hold of
one. But their usage is also very different. Base stations only
need read access to the IMD in order to forward telemetry
information to the relevant health-care practitioner. There-
fore, it makes sense to have different keys for each of these
devices which provide different access levels. In this way, if
the key of a base station gets compromised for a period of
time, this still represents a potential privacy violation but
at least it is not life threatening.
6. CONCLUSIONS
In this work we have analysed the security and privacy
properties of the latest generation of ICDs. For this we
fully reverse-engineered the proprietary protocol between
the ICD and the device programmer using commercial and
inexpensive equipment. We want to emphasise that reverse-
engineering was possible by only using a black-box approach.
Our results demonstrated that security-by-obscurity is a dan-
gerous design approach that often conceals negligent designs.
Therefore, it is important for the medical industry to mi-
grate from weak proprietary solutions to well-scrutinised se-
curity solutions and use them according to the guidelines.
Our work revealed serious protocol and implementation
weaknesses on widely used ICDs, which lead to several ac-
tive and passive software radio-based attacks that we were
able to perform in our laboratory. Our first attack consisted
on keeping the ICD alive while the ICD is in “standby” mode
by repeatedly sending a message over the long-range com-
munication channel. The goal of this attack was to drain
the ICD’s battery life, or to enlarge this time window to
send the necessary malicious messages to compromise the
patient’s safety. Our second attack aimed at compromising
the patient’s privacy. For this we leveraged the fact that we
were able to recover the LFSR sequence used to “obfuscate”
the messages. We discovered that this LFSR sequence is
constant throughout sessions and is the same for all ICDs
we studied.
We proposed short-term and long-term countermeasures.
As a short-term countermeasure, the only solution is to use
jamming as a defensive mechanism. As long-term counter-
measures, ex ternal devices could send a “shutdown” message
to the ICD so that the ICD can immediately switch to “sleep”
mode after the communication ends. Moreover, we designed
and formally verified a semi-offline key agreement protocol
between the device programmer and the ICD.
In accordance with the principle of responsible disclosure,
we have notified and discussed our findings with the manu-
facturer before publishing this article.
7. ACKNOWLEDGEMENTS
The authors would like to thank Stefaan Foulon for his
support and the anonymous reviewers for their helpful com-
ments. This work was supported in part by the Research
Council KU Leuven: C16/15/058 and the Cryptacus COST
Action IC1403.
8. REFERENCES
[1] DAQ NI USB-6351. http://www.ni.com.
[2] Federal Communications Commission (FCC) ID.
http://www.fcc.gov/encyclopedia/fcc-search-tools.
[3] LabVIEW. http://www.ni.com/labview.
[4] NI USRP-2920. http://www.ni.com.
[5] M. Abadi and C. Fournet. Mobile values, new names,
and secure communication. In Symposium on
Principles of Programming Languages (POPL), 2001.
[6] B. Blanchet, B. Smyth, and V. Cheval. ProVerif 1.88:
Automatic cryptographic protocol verifier, user
manual and tutorial, 2013.
[7] L. Chunxiao, A. Raghunathan, and N. Jha. Hijacking
an insulin pump: Security attacks and defenses for a
diabetes therapy system. In e-Health Networking
Applications and Services, 13th IEEE International
Conference on, pages 150–156, Jun 2011.
[8] F. D. Garcia, G. Koning Gans, R. Muijrers,
P. Rossum, R. Verdult, R. W. Schreur, and B. Jacobs.
Dismantling mifare classic. In Proceedings of the 13th
European Symposium on Research in Computer
Security: Computer Security, ESORICS ’08, pages
97–114, Berlin, Heidelberg, 2008. Springer-Verlag.
[9] F. D. Garcia, D. Oswald, T. Kasper, and P. Pavlid`es.
Lock it and still lose it —on the (in)security of
automotive remote keyless entry systems. In 25th
USENIX Security Symposium (USENIX Security 16),
Austin, TX, Aug. 2016. USENIX Association.
[10] S. Gollakota, H. Hassanieh, B. Ransford, D. Katabi,
and K. Fu. They Can Hear Your Heartbeats:
Non-invasive Security for Implantable Medical
Devices. SIGCOMM Comput. Commun. Rev.,
41(4):2–13, Aug. 2011.
[11] T. Halevi and N. Saxena. On pairing constrained
wireless devices based on secrecy of auxiliary channels:
the case of acoustic eavesdropping. In Proceedings of
the 17th ACM Conference on Computer and
Communications Security, CCS 2010, Chicago,
Illinois, USA, October 4-8, 2010, pages 97–108, 2010.
[12] D. Halperin, T. S. Heydt-Benjamin, B. Ransford, S. S.
Clark, B. Defend, W. Morgan, K. Fu, T. Kohno, and
W. H. Maisel. Pacemakers and implantable cardiac
defibrillators: Software radio attacks and zero-power
defenses. In Proceedings of the 29th Annual IEEE
Symposium on Security and Privacy, pages 129–142,
May 2008.
[13] X. Hei, X. Du, J. Wu, and F. Hu. Defending resource
depletion attacks on implantable medical devices. In
Global Telecommunications Conference (GLOBECOM
2010), 2010 IEEE, pages 1–5, Dec 2010.
[14] P. Koopman and T. Chakravarty. Cyclic redundancy
code (crc) polynomial selection for embedded
networks. In Dependable Systems and Networks, 2004
International Conference on, pages 145–154, June
2004.
[15] E. Marin, E. Argones R´ua, D. Singel´ee, and
B. Preneel. A survey on physiological-signal-based
security for medical devices. Cryptology ePrint
Archive, Report 2016/188, 2016.
http://eprint.iacr.org/.
[16] E. Marin, D. Singel´ee, B. Yang, I. Verbauwhede, and
B. Preneel. On the feasibility of cryptography for a
wireless insulin pump system. In Proceedings of the
Sixth ACM Conference on Data and Application
Security and Privacy, CODASPY ’16, pages 113–120,
New York, NY, USA, 2016. ACM.
[17] J. Proakis and M. Salehi. Digital Communications.
McGraw-Hill higher education. McGraw-Hill
Education, 2007.
[18] K. B. Rasmussen, C. Castelluccia, T. S.
Heydt-Benjamin, and S. Capkun. Proximity-based
access control for implantable medical devices. In
Proceedings of the 16th ACM Conference on Computer
and Communications Security, CCS ’09, pages
410–419, New York, NY, USA, 2009. ACM.
[19] M. Rostami, W. Burleson, F. Koushanfar, and
A. Juels. Balancing security and utility in medical
devices? In The 50th Annual Design Automation
Conference 2013, DAC ’13, Austin, TX, USA, May 29
- June 07, 2013, pages 13:1–13:6, 2013.
[20] M. Rostami, A. Juels, and F. Koushanfar.
Heart-to-heart (H2H): authentication for implanted
medical devices. In 2013 ACM SIGSAC Conference on
Computer and Communications Security, CCS’13,
Berlin, Germany, November 4-8, 2013 [20], pages
1099–1112.
[21] N. O. Tippenhauer, L. Malisa, A. Ranganathan, and
S. Capkun. On limitations of friendly jamming for
confidentiality. In Security and Privacy (SP), 2013
IEEE Symposium on, pages 160–173, May 2013.
[22] F. Xu, Z. Qin, C. C. Tan, B. Wang, and Q. Li.
Imdguard: Securing implantable medical devices with
the external wearable guardian. In INFOCOM 2011.
30th IEEE International Conference on Computer
Communications, Joint Conference of the IEEE
Computer and Communications Societies, 10-15 April
2011, Shanghai, China, pages 1862–1870, 2011.
APPENDIX
A. A FORMAL MODEL OF OUR PROPOSED
PROTOCOL FROM SECTION 5.2.2
(* Secure IMD protocol *)
free c.
(* bilinear pairings *)
fun power/2. (* power(x,y) = x^y *)
fun powere/3. (* powere(a,b,x) = e(a,b)^x *)
fun prod/2. (* prod(a,b) = a x b *)
fun e/2. (* e (a^x,b^y) = e(a,b)^(xy)*)
equation e(power(a,x),power(b,y)) = powere(a,b,prod(x,y)).
equation prod(x,y) = prod(y,x).
data one/0.
(* hashes *)
fun H1/1.
fun H2/1.
(* Shared key cryptography *)
fun senc/2.
reduc sdec(y, senc(y,x)) = x.
private free sec.
private free msk.
(*
Test if the attacker can learn secret
encrypted with the established key
*)
query attacker:sec.
let Programmer = in (c,imdID);
if imdID=id then
let rkey = e(rsec,power(H2(imdID),one)) in
in(c,message);
out(c,senc(rkey,sec)).
let IMD = let imdkey = e(power(H1(t),one),psec) in
out(c,id);
out (c,senc(imdkey,sec)).
let CompromisedReader = new t’; out(c,t’);
out(c,power(H1(t’),msk)).
let CompromisedUnAuthIMD = new id’; out (c,id’);
out(c,power(H2(id’),msk)).
process new msk;
!new t; out(c,t);
!new id; out(c,id);
( let psec = power(H2(id),msk) in !IMD
| let rsec = power(H1(t),msk) in !Programmer
| !CompromisedReader | !CompromisedUnAuthIMD )
