Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000.

Digital Object Identifier 10.1109/ACCESS.2020.3015686

IMDfence: Architecting a SecureProtocol for Implantable Medical DevicesMUHAMMAD ALI SIDDIQI1, CHRISTIAN DOERR2, AND CHRISTOS STRYDIS1, (SeniorMember, IEEE)1Department of Neuroscience, Erasmus Medical Center, Rotterdam, The Netherlands (e-mail: m.siddiqi@erasmusmc.nl, c.strydis@erasmusmc.nl)2Cyber Threat Intelligence Lab, Hasso Plattner Institute, University of Potsdam, Germany (e-mail: christian.doerr@hpi.de)

Corresponding author: Muhammad Ali Siddiqi (e-mail: m.siddiqi@erasmusmc.nl).

This work has been supported by the EU-funded project SDK4ED (Grant Agreement No. 780572).

ABSTRACT Over the past decade, focus on the security and privacy aspects of implantable medicaldevices (IMDs) has intensified, driven by the multitude of cybersecurity vulnerabilities found in variousexisting devices. However, due to their strict computational, energy and physical constraints, conventionalsecurity protocols are not directly applicable to IMDs. Custom-tailored schemes have been proposed insteadwhich, however, fail to cover the full spectrum of security features that modern IMDs and their ecosystemsso critically require. In this paper we propose IMDfence, a security protocol for IMD ecosystems thatprovides a comprehensive yet practical security portfolio, which includes availability, non-repudiation,access control, entity authentication, remote monitoring and system scalability. The protocol also allowsemergency access that results in the graceful degradation of offered services without compromising securityand patient safety. The performance of the security protocol as well as its feasibility and impact onmodern IMDs are extensively analyzed and evaluated. We find that IMDfence achieves the above securityrequirements at a mere less than 7% increase in total IMD energy consumption, and less than 14 ms and 9kB increase in system delay and memory footprint, respectively.

INDEX TERMS Authentication protocol, battery-depletion attack, battery DoS, denial-of-service attack,IMD, implantable medical device, non-repudiation, smart card, zero-power defense

I. INTRODUCTIONModern implantable medical devices (IMDs), such as cardiacpacemakers and defibrillators, neurostimulators, and more,are equipped with wireless connectivity in order to aid intreatment-related reconfiguration, patient-health monitoring,device testing etc. [1], [2]. However, wireless links have madeIMDs susceptible to various attacks by malicious entities.

Earlier-generation IMDs had little or no security provi-sions whatsoever, as confirmed by numerous ethical-hackingincidents over the past decade [3]–[5]. The research commu-nity has responded with a wealth of new schemes and, even-

This article has been accepted for publication in a future is-sue of this journal, but has not been fully edited. Content maychange prior to final publication. Citation information: DOI 10.1109/AC-CESS.2020.3015686, IEEE Access. This work is licensed under a Cre-ative Commons Attribution 4.0 License. For more information, seehttps://creativecommons.org/licenses/by/4.0/.

tually, top IMD manufacturers now claim to have rectified thesecurity weaknesses over the past few years [6], [7].

However, due to the constraints imposed by an IMD’sscant computational, storage and energy resources, mostproposed schemes in research have refrained from takingproven security approaches. Moreover, since these schemeshave been specifically tailored for IMDs, they have missedthe big picture and resulted in limited coverage of the securityproperties essential to a modern IMD. Specifically, mostfocus has been drawn on confidentiality, integrity, authen-tication and emergency access (e.g., [8]–[11] etc.), whilenon-repudiation, remote monitoring and system scalabilityhave been left unaddressed for the most part. Besides beingdifficult to tackle, prior seminal work has not identified orstressed the importance of these additional requirements.

In this paper, we debunk the myth that advanced securityis impossible in modern IMDs. To this end, we collect bothwell-studied and overlooked security requirements, imposestrict design constraints, and propose IMDfence, a novel se-

VOLUME 4, 2016 1

arX

iv:2

002.

0954

6v4

[cs

.CR

] 1

3 A

ug 2

020

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

curity protocol for IMD ecosystems. This works contributes:• A comprehensive security protocol for a modern IMD

ecosystem, IMDfence, which addresses crucial, yet pre-viously ignored requirements, i.e., non-repudiation, re-mote monitoring and system scalability.

• A realistic solution for accessing the IMD duringemergencies without compromising security or patientsafety.

• A rigorous evaluation of IMDfence paying special atten-tion to the protection against battery denial-of-service(DoS) attacks.

The rest of the paper is organized as follows: We enumer-ate modern IMD-system requirements in Section II, and thendiscuss existing systems and related works in Sections IIIand IV, respectively. Section V details our proposed securityprotocol. We evaluate IMDfence in Section VI and provideconcluding remarks in Section VII.

II. IMD-SECURITY REQUIREMENTSIn this section, we collect and present the necessary securityand related functional requirements that should be satisfiedin modern IMD systems. These requirements form the basisof the IMD-specific security protocol, to be detailed in Sec-tion V.

In order to evaluate the IMD-system security, we consideran implant that is capable of communicating wirelessly witha reader/programmer1. We assume an attacker whose aimcould be to either (1) modify or sabotage IMD operationin order to prevent patient treatment, (2) manipulate patient-related data, or (3) steal patient data. Furthermore, we assumethat the attacker has full control of the wireless channelbetween the reader and IMD. This means that he/she caneavesdrop, modify, insert, block or replay messages betweenthese two entities at will. As a result, the IMD-securitysystem has to satisfy certain security requirements (SRs):

A. BASIC SECURITY SERVICES (SR1 & SR2)As in other domains, the IMD-security system should providethe fundamental security services: Confidentiality, Integrityand Availability. The first two services (SR1) are usuallyaddressed through the use of lightweight block-ciphers andmessage-authentication codes (MAC) [12]. More specifi-cally, the commands sent from the reader to the IMD andthe associated responses (e.g., data logs) should be treatedas confidential and it should be ensured that such data is notmodified in transit.

Availability ensures that the IMD is always available forpatient treatment whenever required (SR2). This implies thatthe device should be protected against Denial-of-Service(DoS) attacks. One of the highest-likelihood and lowest-costattacks is the battery-depletion attack (or battery DoS attack),as indicated in the IMD-specific threat-modeling analysisin [1] and practically demonstrated in [3], [4].

1The term reader will be used for any device that is able to directlycommunicate with the implant.

B. NON-REPUDIATION (SR3)Non-repudiation ensures that the sender of a message is notable to deny (or repudiate) its creation. Since there is alwaysa possibility of malpractices, medical mistakes or insiderattacks, we require non-repudiation to aid in computer foren-sics in case a patient experiences medical issues as a directconsequence of such actions. This security service ensuresthat a physician, paramedic or nurse is not able to denyhis/her involvement in such scenarios. Non-repudiation hasnot been given due consideration by the research communitywhen it comes to IMD systems. One of the reasons is thattrue non-repudiation can only be achieved through the use ofpublic-key (or asymmetric) cryptography for computing dig-ital signatures [13], which has traditionally been consideredto be too resource-costly for IMDs [12], [14]. Another, veryimportant, reason is that past generations of IMDs could onlybe accessed by one person, i.e., the physician. Nowadays,the IMDs can be accessed by multiple people, includingthe patients themselves [15]–[17]. Hence, there is a need tointroduce user accountability.

Most of the existing IMD-security works have looked intostrict reader-IMD communication (without the involvementof a trusted third party). Even if we assume that the resource-constrained IMD is able to support public-key computations,this reader-IMD configuration makes it impossible for theIMD to effectively use public-key cryptography since itcannot keep track of the validity of the reader certificates(due to lack of Internet connectivity). What is more, thesedevices do not have sufficient memory to store the requiredcertificates [18]. For instance, the IMD must store all possiblereader certificates if we want to support access during travelsor when the patient is visiting abroad. Hence, a scheme isrequired that employs additional architectural components(as will be discussed in Section V) to solve these issues.

Another complication is the legal aspect. Since non-repudiation is there to provide evidence, it should be incor-porated based on the assumption that such evidence will bescrutinized by a hostile legal expert [19]. One main limitationof cryptography-based non-repudiation is that there is noformally-verifiable link between the device that signs thedigital signature and its user. For example, the user, i.e.,the private-key owner, can falsely claim that the signaturehas been generated by a malware program without his/herconsent, or that the private key has been stolen. There isno technical mechanism that can determine whether such aclaim is false [20]. The IMD security protocol should addressthis limitation, which we term as the Non-repudiation gap.

C. EMERGENCY ACCESS (SR4)Patient safety always outweighs device security. Hence, dur-ing emergencies the security protocol should not hinder ordelay paramedic access to the IMD [2], [21]. Although itseems reasonable to drop security altogether in such situa-tions, this can be a problem if, while in a normal mode, anadversary fools the IMD into entering the emergency-accessmode. The security protocol must be capable of allowing the

2 VOLUME 4, 2016

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

IMD to accurately classify whether a communication attemptis an emergency or a normal access. This ensures that theadversary is unable to trigger and exploit the emergency-access mode. Furthermore, since there is a high likelihoodof the patient losing control of his/her actions in emergencies,the emergency-access mode should be independent of patientparticipation.

D. MULTI-MANUFACTURER ENVIRONMENT (SR5)Past works on emergency access have ignored the fact that,in emergencies, it is unlikely for the paramedic to know theIMD make and model beforehand. Moreover, it is not possi-ble to preemptively stock all the readers from all the manu-facturers in the ambulance. Hence, to achieve true emergencyaccess, the IMD-security system should be manufacturer-independent, i.e., all manufacturers need to agree on a unifiedstandard for secure reader-IMD communication. This way,an ambulance can use one generic reader regardless of theIMD manufacturer and type. It follows that an emergency-access scheme should be adoptable by all IMD types. E.g.,an emergency-access solution that requires an IMD measur-ing the cardiac signal [21], can be easily incorporated inpacemakers, but it will require significant modifications inneurostimulators.

As things stand, true emergency access does not exist incommercial IMDs. As long as this remains acceptable tothe medical community, SR5 can be relaxed. This is furtherdiscussed in Section V-D2.

E. ACCESS CONTROL (SR6)The access privileges of the reader should be differentiatedbased on the type of user. For example, nurses, patients orpatient relatives may only be allowed to read status datafrom the implant, whereas a physician and a paramedic mayfurther be allowed to modify the implant configuration fortherapy updates, suspend or resume its operation. Similarly,a technician may be allowed to modify the implant firmwarein addition to tasks of the above user roles.

F. USER AND READER-IMD AUTHENTICATION (SR7)In order to aid in non-repudiation and access control, theIMD system should be able to identify the physician, nurse,paramedic etc. who is using the reader to communicate withthe implant. Similarly, the reader should also be able toauthenticate the IMD in order to prevent spoofing attacks onthe reader. Hence, there is a requirement for performing mu-tual authentication instead of just authenticating the readerunilaterally [12]. Furthermore, said authentication is requiredto be strong, i.e., it should imply both message and entityauthentication, and guarantee message freshness, or in otherwords replay protection.

G. FLEXIBILITY AND SCALABILITY (SR8)The IMD should not be limited to communicating with only afixed amount of readers since this severely limits portability,e.g., during emergencies when a paramedic reader is used, or

when there is a need for treatment at some hospital duringtravels. Hence, there should not be any pre-shared secretsbetween the reader and IMD.

H. BEDSIDE-READER OPERATION FOR REMOTEMONITORING (SR9)Some of the modern IMD systems also include a bedsidereader, which enables remote monitoring [22]. It establishescommunication with the IMD when the patient is asleep andsends treatment status to a back-end server via an Internetconnection. However, this additional connection representsan increase in the attack surface, which imposes additionalsecurity requirements. We predict that the use of such readerswill become more widespread over time due to their time-and cost-saving features. Hence, this phenomenon shouldproactively be considered when designing secure IMD sys-tems.

III. EXISTING SYSTEMSIMD manufacturers have typically relied on “securitythrough obscurity”; they choose to hide the communication-protocol specifications in order to enhance security. This isnot a recommended practice, and as a consequence of usingthis approach, we have seen several successful blackbox-hacking attempts over the past few years [3], [4].

Some of the latest commercial IMDs, including neurostim-ulators [17], insertable cardiac monitors [16] and even pace-makers [15] offer a Bluetooth Low Energy (BLE) connectionbetween the patient smart-phone and the implant. The initialpairing between these devices is based on the BLE standardin addition to proprietary protocols [17]. However, they donot disclose the association models used in these pairings,which makes these devices vulnerable to attacks due to thereasons mentioned above. In most of the cardiac devices, inthe absence of an IMD-programmer, a magnet can be usedto disable therapy or to switch to a default behavior [23].This mode, however, can be easily exploited by adversariesthrough the use of a strong magnet when in close proximityto the patient (e.g., in public transport).

IV. RELATED WORKFrom the perspective of the research community, we observea steep rise in the number of works proposed over the lastfew years [31]. For data confidentiality, integrity and messageauthentication, the use of lightweight primitives has beenproposed. Early works focused on basic security protocolsbased on symmetric ciphers, which rely on a common pre-shared key between the reader and the IMD [12]. However,such approaches are not scalable in terms of adding newreaders that can access the implant. They also do not allowparamedic access during emergencies. Therefore, most of theexisting works deal with emergency access, in addition toentity authentication and key exchange. For entity authenti-cation, these works rely on a touch-to-access policy, whichensures that only the entities that can physically touch thepatient for a prolonged period of time are allowed access to

VOLUME 4, 2016 3

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

TABLE 1. Overview of related works

[8] [10] [11] [24] [25] [26] [27] [28] [29] [30]

Confidentiality & Integrity (SR1) • • • • • • • • • •Availability (SR2) ◦ ◦ ◦ ◦ ◦ ◦ ◦ • ◦ ◦Non-repudiation (SR3) ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ •Emergency Access (SR4) • • ◦ ◦ ◦ • • • • •Multi-manufacturer support (SR5) ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦Access Control (SR6) • • ◦ • • • • ◦ ◦ •Authentication (SR7) • • • • • • • • • •Flexibility & Scalability (SR8) ◦ • ◦ ◦ ◦ ◦ ◦ • • ◦Beside-reader operation (SR9) ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦•: Satisfies requirement,◦: Does not satisfy requirement

the implant [1], [21]. In other words, it is infeasible for anattacker to get in close proximity to the patient, and even ifthat is the case, the patient can detect this and reject physicalcontact. Also, the attacker would then have far easier methodsto harm the patient than via accessing the implant, e.g., byphysically attacking the patient. These works can be broadlycategorized as follows [2]:

Biometric-based: These approaches (such as [21], [32])rely on both the reader and IMD to measure a physiologicalsignal from different parts of the patient’s body. The devicesare paired based on the similarity of these measurements.

Proxy-based: These works propose to use an additionaldevice in the possession of the patient, such as a smart phone,watch, etc [33], [34]. The device is paired with the IMD and isused to authenticate the reader that is trying to communicatewith the implant. In case of emergency, the device can bephysically distanced from the patient in order to grant thereader unsecured access to the IMD.

Distance-based: These works (e.g., [35], [36]) employweak or out-of-band (OOB) signals for reader-IMD commu-nication. These can either involve direct transfer of a sessionkey, which would be hard for an attacker to eavesdrop, orthey can require the devices to mutually prove proximity toone another.

Token-based: This is the simplest approach, which relieson the patients having the IMD-access key or passwordwith them, which is stored e.g., on a bracelet. During anemergency, a paramedic can access the IMD using this token.

We now present a brief overview of the latest works fromliterature that were specifically tailored for IMDs.

Bu et al. propose a low-energy IMD-security schemecalled Bulwark [8], which, in addition to satisfying SR1, alsoallows IMD access in emergencies (SR4). This emergencyaccess scheme is based on Shamir’s secret sharing, whichrelies on the users (including the paramedics) to register withthe manufacturer of the specific IMD in advance in order toretrieve the access key in case of an emergency. As evident,such a requirement inhibits IMD access in case the patient isout of town (SR8).

Chi et al. [10] propose a protocol that relies on the patient’ssmartphone for the reader access. However, requiring thepatient to be in possession of this additional device (i.e., thesmartphone) all the time, including during emergencies, puts

a significant burden on the patient.Belkhouja et al. [11] propose a symmetric crypto system

in which they use a Chaotic key generator that is employedby both the reader and IMD to generate the symmetrickey. However, in order for this key generator to work, bothentities are required to have similar pre-installed initial con-ditions/values. Hence, this scheme cannot function in anemergency scenario, or when the patient is traveling, sincethe IMD and the reader will not be sharing the same initialconditions.

Wazid et al. [24] and Mao et al. [25] propose three-factorprotocols, which rely on passwords, smart cards, and bio-metrics. Their protocols rely on a reader-registration phasebefore the IMD deployment in the field. This inhibits SR4and SR8 since it is unlikely for the paramedic/doctor topossess a pre-registered reader during an emergency or whenthe patient is visiting abroad. Rathore et al. [26] propose ascheme in which the identifiers of each user (including thepatient) are derived from their cardiac signals and are storedin the implant. Hence, it requires a user-registration phasesimilar to the above protocols. However, their scheme allowsemergency access since the paramedic can measure patient’scardiac signal, which is compared by the IMD against thestored identifier in order to grant access. The three-factorprotocol from Fu et al. [27] also provides emergency access.However, the patient is required to always be in possessionof a personal smart card so that the paramedic is able to useit during an emergency.

A few works [3], [12], [28] have also focused on the IMDavailability (SR2). In these works, RF energy harvesting isemployed to protect the IMD against battery-depletion at-tacks. In addition, quite a few authentication and emergency-access schemes have been proposed recently that rely onstatic biometrics (such as fingerprints) [37], dynamic biomet-rics (such as cardiac signals) [28], [29] and combination ofboth [9]. The interested reader can refer to [31], [38]–[41] toget an overview of prior works in this area.

Overall, the above works address only parts of the IMDsecurity requirements (SR1, SR2, SR4, SR6, SR7 and SR8),which is also summarized in Table 1. For instance, non-repudiation is not considered and the emergency-accessschemes do not take into account the (current) multi-manufacturer environment, as discussed in Section II. To the

4 VOLUME 4, 2016

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

Wireless

Reader (R)

IMD (I)(registered with S)

Programmer

Bedside reader

Contact

Smart card (C)(registered with S)

Hospital server (S)

Internet

FIGURE 1. Proposed IMD ecosystem

best of our knowledge, there is no protocol that provides allthe services highlighted in Section II.

The work from literature that came closest to fulfilling theabove requirements was proposed by Park [30]. It establishesa session key between the IMD and a personalized readerbased on shared secrets between these entities and a trustedthird party (hospital server). The use of public-key cryptoin the personalized reader and the server facilitates non-repudiation. However, the work lacks a few additional piecesin order to properly close the non-repudiation gap (as will bediscussed in Section V-C5). The protocol addresses accesscontrol by first allowing only read access to the implant viathe server. Based on the result of the read-out data, the serverprovides write keys to the reader-IMD pair which allows theuser to change IMD settings. The personalization processinvolves the physician inserting a personal smart card intothe reader. However, since it resembles a single-factor au-thentication for the user (i.e., through the use of a smart cardwithout PIN), any person in possession of a valid (stolen)card can access the implant by getting hold of a reader. Theserver maintains a list of primary-care physicians authorizedto access each registered implant. If the physician is a mem-ber of this list, then a read-key is granted to the physician.We believe that maintaining such a user list is not scalable,it inhibits flexibility, and hence, should not be employed. Asan example, such a scheme will not work in case the patientrequires some treatment at a hospital abroad. Besides, theproposed emergency-access scheme uses a bracelet that has asecret key. However, such token-based security schemes aresingle points of failure (e.g., in case the token is stolen or thecontents are disclosed). Also, it requires the patient to wearthe bracelet at all times, which is inconvenient. Moreover, inthe emergency scenario, the scheme drops access control andnon-repudiation. Lastly, this work excludes battery DoS fromits adversarial model, and it does not consider bedside-readeroperation.

V. IMDfence: SECURITY PROTOCOL FOR IMDECOSYSTEMSThe absence of a complete security solution for IMD sys-tems has led us to propose IMDfence, a novel secure-communication protocol that satisfies the extensive and strictrequirements enumerated in Section II. As will be shown,

TABLE 2. Table of Notations

Notation Definition

IDA ID of entity ANA Nonce generated by AKpubA/KprA Public/private key pair of AKAB Pre-shared symmetric key between A and BK′AB Short-term symmetric key between A and BKA A secret only known to APA Privilege information of user/card ACMD Configuration commandANS Answer to CMDk Difficulty of solving a client puzzlex < i > ith bit of a bitstring xx < i : j > Bit sequence x < i >, ..., x < j >t Time stampT Lifetime of reader-card authentication{}KAB Authenticated encryption

*using KABMACKAB () MAC operation using key KABsigKprA() Signature (of a hashed message) using KprACertA Certificate consisting of IDA, PA, KpubA and

sigKprCA(IDA, PA,KpubA)

* Such as Encrypt-then-MAC (EtM). Separate keys should be used forthe encryption and MAC operations to prevent certain attacks and toease key management [20]. However, these keys are not differentiatedhere for simplicity.

IMDfence addresses the complete IMD ecosystem.

A. CONFIGURATION AND ASSUMPTIONSThe IMDfence configuration includes a smart card (C) forthe user (U ) trying to access the IMD (e.g., a physician),and a trusted third party (TTP), i.e., a hospital server (S), inaddition to the implant (I) and the reader (R); see Fig. 1.The list of notations used in this paper is summarized inTable 2. The extra components, C and S, are employedto facilitate non-repudiation (SR3), access control (SR6)and user authentication (SR7), as identified in Section II.Each personal smart card, which is inserted in R, supportspublic-key cryptography. Its private key, which is unique toeach card/user, enables digital-signature computation, thusproviding non-repudiation. Since R and C are untrusted withrespect to each other, a TTP (S) is required to mutuallyauthenticate the two entities. Non-repudiation can technicallyalso be provided through the use of a personal reader thatsupports public-key computations in order to get rid of Cand S. However, such a solution would be highly impracticaland expensive since it would require all the doctors andnurses to be in possession of their personal readers at alltimes. Moreover, the use of S also enables access controland facilitates bedside-reader operation (SR9). Every userrequires their own C and should know the associated PIN(two-factor authentication). Since patients are only allowedread-only access (as discussed in Section II-E), losing ormisplacing their C will not inhibit any future treatment. Toavoid additional attack vectors, we propose to not support theuse of contactless smart cards and magnetic-strip cards.

VOLUME 4, 2016 5

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

1) Interfaces

For tackling flexibility and scalability (SR8), there is no pre-shared key between R ↔ I , R ↔ C, S ↔ R, and C ↔ I .The only pre-shared symmetric keys that exist are between S↔ I (KSI ) and S ↔ C (KSC). A unique KSI is installedin the implant at the time of manufacturing, which is thenshared with the server of the hospital where the implantationsurgery is going to take place. During this IMD-registrationprocess, the implant is also assigned a unique and randomidentifier IDI , which is stored in the implant. Likewise,KSCis installed in the smart card and is shared with the hospitalwhere the card user is registered. Moreover, S, I and C canonly talk to R directly and only indirectly with each other2.

The secure communication between S ↔ R is made pos-sible by employing public-key-based key exchange in whichthe public/private key pairs of these entities are used. Thisconfiguration helps in making R independent of the need topre-share keys with the hospital, which aids in scalability.As a result, a patient can use his/her personal reader fromany location, and/or buy a new reader from the manufacturerwithout the need of registering it first at the hospital.

In our proposed configuration, each smart card also has itsown public/private key pair. Technically,R has the capabilityof maintaining a comprehensive certificate-revocation list(CRL) of smart cards due to frequent Internet connectivity.Hence, it is able to verify smart-card certificates. On the otherhand, due to the limited on-board memory and less-frequentInternet connectivity, C can only maintain a small CRL thatdoes not change frequently. Hence, C can not verify theauthenticity of the multitude of reader certificates. As a result,public-key-based key exchange cannot be used to establisha session key between R ↔ C. However, it will be shownin Section V-C that the session key between R ↔ C willbe established using S as a TTP. The same will be done forestablishing a session key between R↔ I . Lastly, no sessionkey is required between C ↔ I .

2) Centralization and Public-key infrastructure

The public keys of S, R and C are signed by a trustedcertification authority (CA) belonging to the manufacturer.The smart-card certificates, in addition, also include the userprivileges.

We consider the precise implementation details of public-key infrastructure (PKI) and certificate revocation outside thescope of this paper. In case of a smart card, certificate revo-cation would be needed when a card is stolen, a user leaves,or he/she changes roles (e.g., from nurse to paramedic). Fora reader, certificate revocation would be required in case Ris stolen or deemed as out-of-service. The server is given theresponsibility to verify the certificates of R and C and hence,it is assumed that it maintains an up-to-date CRL.

2The routing details of the messages communicated via the reader havebeen omitted for brevity.

Online setting

Reader-card authentication

User authentication

Session-key establishment

Main phase

OOB session-key transfer

Main phase (offline)

User authentication

Offline access in the field

FIGURE 2. IMDfence flow under online and offline scenarios

3) Modes of operationWe propose two modes of operating in IMDfence, one forregular (online) operation and the other in the absence of anactive Internet connection (offline), e.g., during emergencies(SR4); see Fig. 2. Online mode offers the full security- andfunctional-requirement portfolio highlighted in Section II,whereas offline mode results in the graceful degradation ofoffered services without compromising security and patientsafety. Since S is not available in offline mode, R and I willbe required to undergo an out-of-band (OOB) pairing phasein order to securely exchange a short-term session key. Thesemodes and the constituent phases will be elaborated in thefollowing sections.

B. THREAT MODELAs discussed in Section II, we assume an attacker A that hasfull control of the wireless channel between R and I . R isassumed to be untrustworthy by I , C and S, and vice versa.Moreover, we assume that if A steals a personal smart cardor a valid reader, then the user or hospital staff should notifythe hospital server so that it is blacklisted. Additionally, weassume that A can hack the reader to read out or modify dataat the interface of the inserted smart card. However, A doesnot have access to the keys stored in R and C. This impliesthat protection against side-channel attacks is consideredoutside the scope of this work since such attacks are typicallyaddressed through specialized countermeasures. Moreover,due to the assumption that S is notified of a lost/stolen device,A has a limited time window to perform such attacks afterstealing a device. We also assume that the hospital personaldo not have access to the keys stored in the server since suchattacks can be prevented by employing standard practices,such as hardware security modules (HSM) etc.

C. REGULAR (ONLINE) MODEThe regular mode of IMDfence is shown in Figures 3 to 6. Itstarts with the R↔ C mutual authentication phase after thephysician (or any other user) inserts their smart card into thereader.

1) R ↔ C mutual authenticationIn this phase, R first tries to establish a secure connectionwith S by sending its identifier and a nonce (which is afreshly generated number that is used only once). In order

6 VOLUME 4, 2016

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

Back-end server S Reader R User smart card CIDR, NR

x = h(IDR,KS , t),puzzle = (h(x), x < k + 1 : n >)

puzzle, t

Calculatesolution = x < 1 : k >

IDR, t, solution

Calculate x,Verify solution,

Check puzzle expiry

Client-puzzle protocol

NS

DH-based key (K ′SR) exchange. S checksR validity

IDR, NR, NS

CalculatemSC1 ={CertC , IDR, NC,R,S}KSC

IDC , NC ,mSC1

{mSC1}K′SR

VerifymSC1 & CertC , Check C validity,Get PC from CertC ,

Check source network and time of access,tokenC = {IDR, NC , valid,K ′RC}KSC ,tokenR = {IDC , NR, valid,K ′RC , T}K′SR

tokenC , tokenR

Decrypt tokenR

tokenC ,MACK′RC (NR, NC)

Decrypt tokenC ,Verify MAC,

Store NC,R,S ,K ′RC in ash

MACK′RC (NC , NR + 1)

Verify MAC,Set token-expiry time to T

IMDfence

FIGURE 3. Reader-card authentication. Steps that are common withbedside-reader mode are marked in blue.

to deter distributed-denial-of-service (DDoS) attacks againstS (to ensure server availability (SR2)), a basic client-puzzleprotocol (CPP) is employed [42]. CPP is a proof-of-worksystem in which any client (or in this case a reader) thatwants to access the server (during high load) is required tocorrectly solve a cryptographic puzzle. For a single client thecosts of solving this puzzle are negligible. However, in orderto launch a successful DDoS by initiating a large number ofsimultaneous connections, it would be computationally in-feasible for the attacker to solve a multitude of such puzzles.S initiates CPP if it senses a DDoS attack or it is dealing

with an abnormally high number of simultaneous connec-tions. It first calculates x, which is the n-bit hash of IDR,the current time stamp t and its long-term secret KS . Itthen computes a second hash (h(x)). S sends h(x) and x

excluding the first k bits of x, along with the t. R computesthe solution, i.e., the missing k bits of x, and sends it alongwith IDR and the received time stamp. k represents thedifficulty of solving the puzzle. S calculates x again andverifies that the solution indeed corresponds to the missingbits. It also verifies, with the help of t, that the puzzle hasnot expired. S is protected against memory exhaustion sinceit is not required to store any data for the verification of thepuzzle solution. In case these checks are successful, S sendsits nonce to R.R then performs a Diffie–Hellman (DH)-based handshake

with S in which a session key is established between thembased on their public/private key pairs (see Fig. 3). Duringthis handshake, both verify each other’s certificates and,additionally, S checks if R is valid (i.e., it is not reportedas stolen or out-of-service).

In order to achieve authentication between R and C, Rthen initiates a five-pass, mutual-authentication protocol bor-rowed from the ISO/IEC 9798-2 standard [43] with S actingas a TTP (see Fig. 3). R and C ensure message freshnessby exchanging their nonces in the first messages betweenthem, and then verifying the existence of these nonces inthe subsequent messages. R generates its nonce and sendsit along with its identifier and NS to C. C responds by gen-erating NC and sending a cryptogram (mSC1 ) that includesauthenticated encryption of its certificate, IDR and nonces,along with IDC and NC in plaintext. This cryptogram iscalculated using KSC since it is intended for the server. Rstores IDC and NC , and forwards the cryptogram to theserver, which establishes that it originated from C and thatit is also tied to R. The server then verifies CertC andchecks the validity of C, in case it has been reported stolen orhas expired. It then determines the required privileges (PC)for the particular user (e.g., physician, paramedic, nurse etc)from CertC . It also calculates tokens for both these entitiesusing the respective symmetric keys. These tokens includethe nonces and identifiers of R and C and a fresh symmetrickey K ′RC . Additionally, tokenR also contains T (reader-card-authentication lifetime). Based on these tokens, R andC can ascertain each other’s trustworthiness.R decrypts tokenR, retrieves K ′RC , calculates the MAC

of the nonces, and forwards it along with tokenC to C.The smart card similarly decrypts tokenC and verifies thereceived MAC using K ′RC . It stores the nonces and K

′RC

in its internal flash memory3 so that it can verify and createmessages in the subsequent stages. C then sends a MAC thatis calculated over NR and NC (including an addition by 1to protect against replay of the previous message). R verifiesthe received MAC using K ′RC . At this point, both R and Chave mutually authenticated each other.R then sets its internal real-time clock to T and starts it

to track the period over which the subsequent phases can

3There can be a time gap between this and the next stage (in offline mode).Since smart cards can only be powered byR, the above data has to be storedin the non-volatile (flash) memory so that C can be taken out of R duringthis period.

VOLUME 4, 2016 7

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

User smart card C Reader R

Doctor enters PIN,Check token-expiry time

{PIN,NR, NC}K′RC

Verify PIN,mSC2 = {Success,NR, NS}KSC

mSC2 ,MACK′RC (mSC2 , Success)

Verify MAC

Reader-card authentication

FIGURE 4. User authentication at the reader

execute without the need of reader-card authentication. Sinceit is possible that R is not connected to the Internet during itsoperation (e.g., in emergencies), this scheme enforces thatR,by design, shall only be usable for a certain duration until ithas first established an Internet connection. This makes surethat R receives critical firmware updates in time, if there areany. The selection and configuration of T will be discussedin Section VI-A4.

2) User authenticationThis phase is shown in Fig. 4 and its objective is to au-thenticate the card holder. The physician enters his/her PINusing a keypad on the reader. R then checks its internal real-time clock to verify the validity of its token. R encryptsthe PIN and the nonces (in order to prevent replays) usingK ′RC . C decrypts the message using the same key, verifiesthe PIN by comparing it with the stored one and sends back acryptogram intended for the server, which is encrypted withKSC . It contains the confirmation of success in addition tothe nonces.

3) Session-key (K′RI ) establishmentR then initiates a TTP-based key established protocol withS and I in order to acquire a symmetric session key K ′RIfor providing confidentiality and integrity (SR1), as shownin Fig. 5. R first exchanges the nonces and identifiers withI and then sends the nonces and identifiers of all parties toS along with mSC2 . S first verifies mSC2 . It then generatesK ′RI , encrypts it in two independent messages mR and mIintended for R and I respectively, and then sends these to R.R decrypts mR and verifies its contents. It then encrypts NRand NI using K ′RI (to form mRI ) and then sends it alongwith mI to I . I first retrieves K ′RI by decrypting mI , andthen decrypts mRI to verify that R has the knowledge ofK ′RI and that the nonces are valid. I finally creates a MACusing the new session key forR to validate. At the end of thisprotocol, both R and I are mutually authenticated (SR7) andhave arrived at a fresh session key in addition to performingkey confirmation. Similar to the reader-card authenticationstage, this phase is also based on the five-pass protocol fromISO/IEC 9798-2 since it involves a TTP.

Back-end server S Reader R Implant IÀ IDR, NRÁ IDI , NI

{IDR,I , NR,I , IDC , NC ,mSC2}K′SR

VerifymSC2 ,Check source network and time of access,

Generate K ′RImR = {K ′RI , NR, IDI}K′SR

mI = {K ′RI , IDR, NI , IDC , NC , PC}KSImR,mI

DecryptmR, verify NR, IDImRI = {NR, NI}K′RI

 mRI , mI

à Decrypt mI , mRIVerify IDR, NI

Store IDC , NC , NR

Ä MACK′RI (NI , NR, IDR)

Verify MAC

Kerberos style key exchange between A and B

FIGURE 5. Session-key establishment between R and I via S. Operationsthat are not relevant to bedside-reader mode are marked in orange.

User smart card C Reader R Implant I

Doctor types in CMD(or receive CMD and

mac = MACKSI (CMD,NR, NI) from S)

{CMD,NR, NC}K′RC

sig = sigKprC (CMD,NR, NC)

sig,MACK′RC (sig)

Verify MAC

Å {CMD, sig}K′RIor {CMD,mac}K′RI

Verify CMD ↔ PC(or read only),

Store sig and CMDnext to IDC , NC , NR

Æ {ANS}K′RI

Display ANS on screen (orsend to S)

Main phase

FIGURE 6. Main phase. Steps that are common with bedside-reader modeare marked in blue. Operations that are unique to bedside-reader mode aremarked in green.

To protect against battery-DoS attacks (which impactavailability (SR2)), steps 1 to 4 of session-key establishmentshould be as lightweight as possible so that the IMD is ableto execute it using harvested RF energy. This will be furtherdiscussed in Section VI-B.

8 VOLUME 4, 2016

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

4) Main phaseAfter session-key establishment, R allows the user to enter acommand on the reader interface (see Fig. 6). The commandis encrypted along with the nonces (to prevent replay attacks)usingK ′RC and is sent toC. The card decrypts the command,digitally signs the message using KprC (to form sig) andsends it to R. R re-encrypts the command using K ′RI andsends it to the implant along with sig.I decrypts the command and verifies if it corresponds to

the privileges information received inmI during the previousphase, hence ensuring access control. sig and CMD arestored by the IMD next to IDC , NC and NR, which werestored during session-key establishment. This is required toensure non-repudiation since sig was signed using a personalprivate key. For example, in the case of a medical mistake(e.g., an incorrect command) that led to patient death, thephysician will not be able to deny his/her involvement sincethis signature can always be retrieved from the IMD and sub-sequently verified using the associated data. It follows thatsignature storage is not required for read-only commands.Since the implant trusts the reader at this point, there isno need for I to verify the signature since the associatedMAC has already been verified by R. This relieves I ofthe need to employ public-key cryptography and to trackuser certificates. After processing the command, the implantresponds with an answer message encrypted with K ′RI . Rdisplays it on its screen for the convenience of the user. Thesession keys expire after a finish command and its associatedresponse, or after a period T .

5) Addressing the non-repudiation gapAs discussed in Section II, the use of a signature alone is notsufficient to address the legal aspects of non-repudiation. Inorder to bridge the non-repudiation gap, one option could beto enforce that the user protects C and the associated PIN,or immediately reports in case it is lost. However, due to thepossibility of human error in general, this is too much of alegal responsibility for the user.

A realistic way of bridging this gap is by introducingadditional checks in the implementation of reader-card-authentication and session-key-establishment phases (seeFigures 3 and 5, respectively). The server can ensure that theimplant write access (determined from PC) is requested fromwithin the hospital network and during the working hours ofthe user. On the other hand, the server can allow read-only ac-cesses from external networks, e.g., in case the access is madeby the patient or their bedside reader. The user just has toensure that R is issued from a certified repository, and that Rshould only be connected to a trusted Ethernet/Wi-Fi network(i.e., in a hospital or patient home). With these precautions,which a responsible user can easily follow, protection canbe ensured against the malicious replacement of a commandusing a compromised reader, or against an attacker sending amalicious command him/herself in order to frame said user.Due to the above risk-based, multi-factor authentication, auser cannot falsely deny his/her involvement in a certain

Wireless

Reader

IMD(registered with SL)

Smart card(registered with SR)

Remote hospital server (SR)

Manufacturer server (SM)

Home-town (local) hospital server (SL)

FIGURE 7. Scenario when the patient is out of town

implant access because the alternative explanation impliesthat (1) the attacker stole a valid reader, card and pin, (2)accessed the implant from within the hospital and during theuser’s working hours, and (3) R and C were not reportedas stolen. The combined probabilities of all these eventsoccurring at once is extremely small, or, in other words, thenon-repudiation gap is effectively bridged by the introductionof above checks.

6) Bedside-reader operationThe online mode also facilitates bedside-reader operation(see Fig. 1). Here, only the CPP and DH-based handshakebetween the bedside R and S (from reader-card authenti-cation phase), the session-key establishment phase, and themain phase (with a few differences, as indicated in Fig. 5 andFig. 6, respectively) need to be executed, since the commandsand responses are only sent and read by S. Moreover, sincethe remote monitoring done in practice is only read only, i.e.,with the lowest access privileges, there is no need for non-repudiation if the read-only access control is implementedcorrectly. This can be done if sig in step 6 is replacedby MAC of CMD from S (i.e., MACKSI (CMD,NR, NI)).Using this MAC, I is able to verify that the command camefrom the server, and hence, it can be executed with read-only privileges. Finally, the hospital staff can retrieve thecritical treatment data by logging into S. It can be argued thatthis remote-access mode should support read/write accessinstead of just read-only in order to enable remote firmwareupdates. However, we stress that such updates should alwaysoccur in the presence of a qualified professional. This isimportant in case patient health suddenly deteriorates due tothe update process. Moreover, in practice it is quite commonand acceptable to get the IMD firmwares updated at the clinicin the presence of a physician [7]. This mode is also usefulfor securely retrieving the stored signatures pertaining toprevious programming sessions in order to free up limitedIMD memory.

7) IMD access from a non-local locationIn Section V-A1, we discussed that C and I are registeredat the local hospital (SL), or in other words, they share theirrespective symmetric keys with the hospital server. During

VOLUME 4, 2016 9

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

travels or when the patient is out of town, a situation mayarise that requires access to the IMD for status monitoring.In this case, the scheme from Fig. 1, can still work if thepatient is in possession of R and his/her C. However, fortreatment updates, which require higher access privileges, thepatient would need to visit a nearby (remote) hospital (SR).In this case, the above scheme would not work straightawaysince the IMD is not registered at SR and the remote-location physician’s C is not registered at SL. Hence, minorextensions are required (see Fig. 7), in which SR establishesa secure connection with SL via an IMD-manufacturer serverSM . SM maintains a list of all the IMDs in service and thehospitals at which they are registered. Based on IDI sentby R to SR (and then SR to SM ) during the session-keyestablishment phase (see Fig. 5), SM determines SL andestablishes a secure connection with it. SR sends K ′RI , therelevant identifiers, nonces and PC to SL (via SM ) so that SLis able to construct mI and send it back to SR. The protocolthen proceeds normally and the IMD eventually retrievesK ′RI after decrypting mI .

D. OFFLINE MODEIn the absence of an active Internet connection and hence, theTTP (S), e.g., during emergencies, R and I need to establisha temporary shared key so that they can communicate directlyin a secure manner. We propose to employ an OOB-channel-based key exchange while using the principle of touch-to-access (as discussed in Section IV). This principle is em-ployed by I to establish trust withR since we assumeR to beuntrustworthy from the perspective of the IMD. We proposeto either use ultrasound communication or galvanic couplingas the OOB channel (between R and I) since they result invirtually zero information leakage compared to other cou-pling methods, such as capacitive coupling [44]. Moreover,they have an advantage over biometric-based touch-to-accessmechanisms (mentioned in Section IV) in that they do notrequire any initial RF communication messages before theIMD is sure that the external entity is in close proximity.This provides an additional security layer, which is criticalfor the pre-deployment configuration that will be discussedin Section V-D1.

Assuming that galvanic coupling is used, the paramedicplaces the OOB interface of the reader on the patient skin4

at a point that is nearest to the IMD. The patient is assumedto thwart advances of a stranger trying to place a reader onhis/her skin, if there is no emergency or a need for treatment.Hence, the implant assumes that the message received fromthe OOB interface is from a trustworthy source. In otherwords, in offline mode, the IMD-system security hinges onthis OOB pairing and favors availability over security but ina more controlled fashion than state of the art.

The protocol is shown in Fig. 8. The paramedic is requiredto perform reader-card authentication when starting his/herduty, so that bothR andC obtain their respective tokens from

4Touching the skin is mandatory for the galvanic channel to function.

User smart card C Reader R Implant I

User authentication similar to regular modebased on prior tokenR and tokenC

Start oine mode, IDR

K ′RI , IDI , NI

OOB pairing between R and I

NR,MACK′RI (NR, NI , IDI)

verify MAC

MACK′RI (NI , NR, IDR)

Verify MAC

Session-key transfer

Doctor types in CMD

{CMD,NR, NC}K′RC

sig =sigKprC (CMD,NR, NC)

sig,MACK′RC (sig)

Verify MAC

{CMD, sig, IDC , NC}K′RI

Verify CMD ↔paramedic’s PC ,

Store sig, IDC , NC , NRand CMD

{ANS}K′RI

Display ANS on screen

Main phase (oine)

P-EMV

FIGURE 8. IMDfence (Offline mode)

S. When IMD access is required in an offline setting, R firstinitiates user authentication with the paramedic smart card inthe same way as in the regular mode. During user authen-tication, R verifies that its internal real-time-clock value isless than T . Through the OOB channel,R sends a request foroffline access along with its identifier. Upon receiving thisrequest, the implant assumes that this is an offline scenariosince this channel is activated only in such extraordinarycircumstances. As a result, it generates a random key K ′RIand its nonce and sends them along with IDI to the readerusing the same channel.R, then, initiates session-key confirmation with I in which

both entities verify each other’s MACs that are generatedusing K ′RI . In order to update or inquire about the implantoperation, the paramedic enters the command on the readerinterface, which is encrypted using K ′RC and is sent to C.The card digitally signs this command and sends it backto R. R encrypts the command using K ′RI , calculates itsMAC and sends it to I along with sigKprC(CMD,NR, NC).

10 VOLUME 4, 2016

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

This signature and CMD are stored by the IMD and arerequired to ensure non-repudiation, as already discussed inSection V-C. The IMD responds with an answer encrypted bythe same session key, which is subsequently displayed on thereader display. The session key expires in a manner similarto that in the regular mode.

In offline mode, the user is only allowed paramedic-levelprivileges, which have less access rights compared to a tech-nician (see Section II). The use of the OOB channel makesit straightforward for the IMD to decide on granting onlyparamedic-role commands.

1) Offline access with/without non-repudiation and accesscontrolWe also propose a second flavor of the offline mode inwhich non-repudiation and user authentication are not arequirement. This is suitable for less critical implants, suchas neurostimulators. This flavor does not require a smart card,and as a result we do not require the reader-card- and user-authentication phases in addition to signature generation.This improves usability, since the paramedic is not requiredto perform reader-card authentication when starting theirduty. In this scheme, the touch-to-access principle is deemedto be sufficient in order to ensure trust establishment. Itis important to note that, for IMDfence, supporting non-repudiation during offline mode has to be decided beforeIMD-system deployment since it cannot be configured atruntime, so as to avoid exploitation.

2) Offline access with/without reader-interfacestandardizationAs indicated in Section II, supporting emergency accessin the field requires a standardized reader interface, whichdemands collaboration between major IMD manufacturers.In order to facilitate this multi-manufacturer environment(SR5), there has to be one agreed-upon root CA that grantscertificates to the manufacturers, who can then act as in-termediate CAs that sign public keys of S, R and C. Asthings stand, however, true emergency access does not existin commercial IMDs. As long as this remains an open issue,the above standardization is not required, and as a result,IMDfence can be simplified by eliminating the need for aglobal root CA. Emergency-access support in IMDfence isintended to be there in anticipation of any future changes inthis regard.

E. SUMMARY OF PROTOCOL CONFIGURATIONSThe different configurations of IMDfence are highlightedin Fig. 9. The dotted boxes indicate (fixed) pre-deploymentconfigurations, which cannot be changed at run-time. Suchconfigurations were discussed in Sections V-D1 and V-D2.

IMDfence is designed in such a way that an attacker cannottarget one mode over another for exploitation. For instance,the offline mode is only triggered after an OOB access, whichis protected by the touch-to-access principle. Moreover, thesub-modes of online access only come about by disabling

IMDfence

Offline mode

With/without non-repudiation and user

authentication

With/without reader-interface standardization

Regular (online) mode

Bedside-reader mode

IMD access from a non-local location

Regular doctor access

FIGURE 9. IMDfence configurations and use cases

certain IMDfence steps instead of switching to a totallyindependent behavior.

VI. EVALUATIONIn this section, we evaluate our system in terms of securityfeasibility and also look into the handling of battery-DoSprotection for IMDs.

A. SECURITY ANALYSIS1) Automatic validation using AVISPA toolFor the automated and formal validation of IMDfence, weused AVISPA (Automated Validation of Internet SecurityProtocols and Applications) [45]. Any protocol to be vali-dated using this tool is specified using the High-Level Pro-tocol Specification Language (HLPSL). An HLPSL specifi-cation consists of a description of the principals (i.e., R, I ,C, S and the user in our case), security goals of the protocol,and the details of the session(s) to be analyzed. AVISPA in-tegrates four back-end engines that provide different types ofautomatic analysis of an HLPSL specification [45]. The toolhelps in detecting vulnerabilities against Man-in-the-middleand replay attacks. It also detects whether the HLPSL spec-ification is executable, i.e., all the specified protocol statesare traversable. Using AVISPA, we can also optimize ourprotocols by removing certain parameters from the messagesin order to reduce communication overhead and analyze ifthis results in a new vulnerability.

The analysis of IMDfence using AVISPA is summarizedin Table 3. The handshake-specific protocol requirements(SR1, SR3, SR6 and SR7) are satisfied by specifying theappropriate goals. In phase III, S extracts user privileges fromCertC after successful authentication of C, based on NS inmSC2 . I then verifies S based on NI to complete the chainfrom the card to the implant in order to ensure access control.In order to check non-repudiation using the tool, the serververifies that the retrieved sig from the IMD originated fromC during the session corresponding to NS .

2) Reader-specific attacksWhen considering all possible attack scenarios, we define thefollowing reader types:

1) Valid R (Rvalid): This is a legitimate device, which isnot reported as stolen.

VOLUME 4, 2016 11

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

TABLE 3. Summary of AVISPA analysis

Phase AVISPA goal* Coverage

I. Reader-card auth. Secrecy of K′RC SR1, SR7C → R | NCR → C | NRS → C | NS

II. User auth. Secrecy of PIN SR1, SR7C → U | PIN

III. Session-key est. Secrecy of K′RI SR1, SR6,S → C | NS SR7I → R | NIR → I | NRI → S | NI

IV. Main Phase Secrecy of CMD,ANS SR1, SR3S → C | NS

* A→ B | N : A authenticates B based on value NSecrecy of N : Confidentiality of value N is ensured

TABLE 4. Enumeration of attack scenarios Sn in terms of user-readercombinations

ReaderValid Stolen Hacked Forged

Trusted, honest user S1 S2 S3 S3Trusted, malicious user S1 S2 S4 S5Attacker S6 S2 S7 S7

2) Stolen R (Rstolen): A legitimate device which is re-ported as stolen.

3) Hacked R (Rhacked): A stolen reader which is alsomodified by A in order to e.g., replace the signatureor CMD.

4) Forged R (Rforged): A custom-built or software-defined radio used by A in order to communicate withan implant. This reader does not have any pre-sharedkeys with S.

The following scenarios are possible in terms of user-reader combinations (which are also summarized in Table 4):

S1 – Any user & Rvalid: This is the most commonscenario, which must be handled by IMDfence. A cannotinsert a false signature remotely (in order to frame some-one) since the connection between R and C is protectedby MAC-based integrity checks. Moreover, an insider attack(from a legitimate, malicious user) should be detected by thenon-repudiation check. However, after sending a maliciouscommand, such a user can attempt multiple harmless writecommands in order to eventually overwrite the signaturecorresponding to the malicious command. We term this asthe signature-overwrite attack. For each command, 72 bytesof flash space is required to store the signature and theassociated session parameters. As an example, if a 32-kBflash memory is allocated for signature storage, 456 attemptswill be required to successfully overwrite the targeted signa-ture, which is highly impractical. Even if the user managesto achieve this, the signature record will still point to anabnormally high number of write commands correspondingto a single session, which will raise suspicions.

S2 – Any user or attacker & Rstolen: No individual will

be able to use Rstolen because of the checks involved in thereader-card-authentication phase.

S3 – Trusted, honest user & Rhacked/Rforged: In orderto frame someone, A has to force the legitimate user touse a hacked reader, which replaces the command with anincorrect one. As a guideline,Rmust be issued from a trustedrepository, which rules out the use of Rhacked and Rforgedfor trusted users.

S4 – Trusted, malicious user & Rhacked: Legitimatemalicious users can cover their tracks by using a hackedreader that can replace the signature corresponding to amalicious command, which is to be stored in the IMD, withthe one corresponding to a safe command. Such an attack isquite costly to execute and is time-critical since it will involvecolluding with someone who has advanced engineering skillswhile requiring that Rhacked is not reported as stolen. Since,the user is considered trusted by the patient and can thus be inclose proximity, he/she has far easier and inexpensive meansto harm the patient without getting caught.

S5 – Trusted, malicious user & Rforged: Such a usercannot send commands using a forged reader in an onlinecase since Rforged does not share a key with S. In theoffline case, however, such a user can use a forged readerthat is able to create a bogus sig and hence does not requireany involvement of C. Moreover, he/she can use the OOB-pairing interface because of being considered as trusted bythe patient. Similar to S4, such a scenario also requires hiringan advanced attacker to develop such a reader, and basedon the touch-to-access assumption, the user has significantlyeasier methods to harm the patient.

S6 – Attacker & Rvalid: For online access, the securityprotocol will break if A gets hold of a valid reader, card andits associated PIN, accesses the IMD from within the hospitaland during the user’s working hours, and C is not reported asstolen. It is recommended that the user protects her card andPIN, or immediately reports it in case it is lost. Moreover,as a guideline, the user should never lend or sell R to athird party. The protocol will also break if A gets hold of anOOB-paired reader and a card with valid respective tokens,and knows the PIN. We assume that the paramedic resets thepairing after treatment. Overall, A cannot effectively launchthe above attacks since the likelihood of all the dependenciesbeing true is extremely low.

S7 – Attacker & Rhacked/Rforged: For online access,A will not be able to use Rhacked because of the reasonsmentioned in S6 above. Similarly, A cannot use Rforgedsince it does not have a shared key with S. Moreover, for anoffline scenario, getting hold of these readers will not help anattacker A since the main symmetric key (KRI ) comes fromI in the OOB pairing process. Hence, to gain advantage usingthese readers, A would still need to get close to I (touch-to-access).

3) Smart-card-specific attacksSince IMDfence employs smart cards, it is important toensure that it is safe from the weaknesses [13], [46] present

12 VOLUME 4, 2016

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

in another widely used smart-card system: EMV (Europay,Mastercard, and Visa). These vulnerabilities exist due to theavailability of less secure options for backward compatibilityand due to a problematic threat model, in which the reader(i.e., the POS terminal) is assumed to be uncorrupted.

One major issue is that most of the important data isexchanged in plain-text (e.g., account data, amount etc.) sincethe terminal and the card do not share a symmetric key.Moreover, in the offline use of the cards that do not supportpublic-key cryptography, the PIN is also sent as plain-text.An attacker can modify the unencrypted initialization mes-sages to force the terminal to use this mode [13]. The PIN canbe recorded using e.g., a hacked terminal that has additionalprobes to read data from the smart card interface. In caseof an offline-encrypted PIN, the terminal can be hacked torecord the keystrokes. Using the account data and PIN, theattacker can create a magnetic-strip card for use in a countrythat does not support chip-based smart cards [47].

Another issue is that the terminal cannot use MAC toauthenticate messages from the card since they do notshare a symmetric key. Cards following the Combined-Data-Authentication (CDA) scheme from EMV address this byemploying signatures. However, in the schemes prior toCDA, the terminal is unable to verify the authenticity of allthe card messages either due to unavailability of signatures(in the case of Static Data Authentication, SDA) or thesignature-less transaction messages (in the case of DynamicData Authentication, DDA). As a result, an SDA card can becloned for use in offline transactions [13], and a stolen DDAcard can be employed in a two-card attack, in which the at-tacker uses his/her own card for PIN verification and uses thestolen card in the transaction phase [48]. Moreover, the cardresponse at the end of PIN verification is unauthenticated. Asa result, this response can be modified to deceive the terminalinto assuming that the entered PIN is correct.

All these attacks exist because in EMV some of the criticaldata is left unencrypted or not signed. In contrast, in boththe online and offline modes of IMDfence, all data betweenR and C is encrypted and is authenticated using MACs.Additionally, our recommendation to avoid magnetic-strip-based cards rules out cloning. Similarly, avoiding contactlesscards removes an additional attack vector.

Another far more advanced type of attack is the relayattack [46], [47], which exploits the fact that the card userscannot know for sure if the display of the terminal is show-ing correct information. It is a time-critical attack wheretwo transactions are simultaneously taking place. The vic-tim inserts his/her card in a counterfeit terminal (e.g., at arestaurant), which is connected to a fake card of the attackerthat is inserted in a valid terminal (e.g. at a jewelry store).The details of the fraudulent transaction are forwarded to thevictim’s terminal. Her screen shows the correct information,but in effect she pays the amount for the other party.

We observe that the relay attack is far less likely in the caseof IMDfence since it requires a legitimate user operating aforged reader. This corresponds to scenario S3 discussed in

Section VI-A2.

4) Selection of TThe touch-to-access principle guarantees that an unreason-ably high T (reader-card-authentication lifetime) value doesnot cause a security vulnerability in IMDfence, as evidentfrom Section VI-A2. However, the careful reader may havenoticed that a prolonged offline operation enabled by sucha large value may result in R’s and/or IMD’s firmwaresbecoming outdated. On the other hand, a very small valuehinders legitimate access, i.e., availability. Therefore, thehospital server should ensure that T is assigned an appropri-ate value (within maximum and minimum limits) based onthe patient’s location and the reader-IMD usage patterns.

Regarding the patient’s locality, the probability of havingstable Internet connectivity is higher when the patient isbased in an urban area compared to a rural setting. Moreover,it stands to reason that the chances of attacker presenceought to be higher in an urban environment. Hence, it makessense to assign a lower T value for urban areas compared torural environments. When assigning the T value, reader-IMDusage patterns should also be taken into consideration, whichdepend on the patient condition and IMD type, ranging fromcritical implants, such as cardiac defibrillators, to less criticalones, such as neurostimulators. The IMDs requiring frequentreader access should be granted a larger T value. Furtherinvestigation on this topic is interesting but is consideredoutside the scope of this work.

It should be noted that the (re)setting of T can be per-formed throughout the operational lifetime of the IMD. Thephysician is required to manually modify this parameter (inS) based on the above guidelines, which then ultimately takeeffect in the reader-card authentication phase (see Fig. 3).

B. AVAILABILITY – DOS PROTECTIONAs highlighted in Section II, one of the system requirementsis to ensure that the IMD is always available for treatment.One high-likelihood and low-cost attack that affects thisrequirement is the battery-DoS attack, as practically demon-strated in [3], [4]. This attack forces the IMD to continuouslyrun energy-consuming operations, which results in batterydepletion and ultimately causes device shutdown. For exam-ple, the attacker can repeatedly try to establish a connectionwith the implant using incorrect credentials. The IMD willscrutinize each invalid request through energy-consumingauthentication operations, which will drain its battery despitefailing to authenticate properly.

The IMD can defend against battery DoS by employing azero-power defense (ZPD) scheme in which the authentica-tion operation is executed using borrowed energy [3]. Thisenergy can be harvested from the incoming RF communica-tion messages from the external reader. The IMD switches tobattery power only after it has successfully authenticated theexternal entity.

Another type of DoS attack can occur when the attackersends repeated communication requests to the implant. For

VOLUME 4, 2016 13

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

an IMD with a single-processor, such requests may block thedevice from performing its primary medical functionality. Toprotect against this, a dual-CPU paradigm can be employed,in which the first CPU executes the original medical function-ality, while the second CPU is responsible for dealing withthe (secure) communication requests. This dual-core orga-nization offers, then, both functional and power decoupling,which effectively shields the IMD main functionality frombattery-DoS attacks, as previously showcased in [12].

In order to assess the viability of IMDfence under energy-harvesting conditions (be it in single- or dual-CPU configu-ration), we construct the following experimental setup:(I) Computational costs: Similarly to [49], we employ anARM Cortex-M0+ based 32-bit MCU [50]. Due to itsultra-low-power capabilities, and the on-board hardware-accelerated, security building blocks (i.e., encryption, MAC,hash function, random-number generator etc.), this MCU isbecoming increasingly employed in IoT and WBAN set-tings [51], and hence, is a plausible choice for this evaluation.The security-related computations, i.e., authenticated en-cryption (AES-128), cipher-based MAC and random-numbergeneration were performed using the MCU’s dedicated pe-ripherals (“CRYPTO” and “TRNG”); thus, in our energymeasurements, hardware-accelerated primitives are consid-ered. However, as a reference, we also include a software-only MCU implementation of IMDfence.(II) Wireless-communication costs: Commercial transceiverZL70103 specifically designed for IMDs has been used [52].To get reasonable energy costs for (encrypted) data transmis-sion, we chose packet-size lengths similar to the ones usedin low-cost RFID tags, due to their similarities with IMDs interms of computational, memory and energy constraints [12].Hence N , ID, CMD and ANS were set to 32, 96, 32 and64 bits, respectively. The sig size was set at 384 bits, whichcorresponds to an ECDSA (Elliptic-Curve Digital-SignatureAlgorithm) signature with a 96-bit security level.

The protocol sequence executed by the IMD is shown asnumbered steps in Figures 5 and 6. In the case of hardware-accelerated primitives, the energy consumption for thesesteps is shown in Fig. 10 using a supply voltage of 3.3 V,and the default MCU and transceiver clock frequencies of19 MHz and 24 MHz, respectively. The transceiver data rateis set at 400 kbps (with an effective rate of 265 kbps). Weobserve that the energy required for authentication (Eauth),i.e., for steps 1 to 4 in Fig. 5, is only 59.6 µJ. In thecase of software implementation, however, Eauth is only119.4 µJ, as shown in Fig. 11. For such a low harvested-energy requirement (Eauth), it has been demonstrated beforein [49] that real-time performance is possible in the IMDwith or without hardware acceleration. Total IMD energyconsumption per type of activity is also shown Fig. 12.

C. IMD LIFETIMEIn the previous section, we discussed the feasibility of IMD-fence under energy-harvesting conditions to defend againstbattery-DoS attacks. In this section, we wish to assess the

0

1

2

3

4

5

6

0

10

20

30

40

1 2 3 4 5 6 7

Dela

y (

ms)

Energ

y (μ

J)

Protocol Steps

Total energy consumption = 108.3 μJ. 59.6 μJ required for auth., i.e., steps 1-4 and 48.7 μJ for steps 5-7

TX Energy RX Energy

Computational Energy Total delay (ms)

FIGURE 10. IMD energy consumption and performance perIMDfence-protocol step while using hardware-accelerated security primitives

0

5

10

15

20

25

0

10

20

30

40

50

60

1 2 3 4 5 6 7

Dela

y (

ms)

Energ

y (μ

J)

Protocol Steps

Total energy consumption = 217.9 μJ. 119.4 μJ required for auth., i.e., steps 1-4 and 98.5 μJ for steps 5-7

TX Energy RX Energy

Computational Energy Total delay (ms)

FIGURE 11. IMD energy consumption and performance perIMDfence-protocol step when implementing the security primitives in software

6.0623.43

78.82

108.31115.64

217.89

0

40

80

120

160

200

Comp. Energy TX Energy RX Energy Total

Energ

y (μ

J)

IMDfence (H/W)

IMDfence (S/W)

FIGURE 12. IMD energy consumption per IMDfence-protocol activity

total energy costs that the IMDfence protocol incurs overthe whole lifetime of a modern IMD. To do so, we needto consider realistic usage patterns of actual devices, drawnfrom medical practice. There are two prominent IMD classes:neurostimulators and cardiac implants. Neurostimulators typ-ically consume more power than cardiac devices [53] and,therefore, often come with rechargeable batteries whichwould pose no challenge for IMDfence. Cardiac implants,on the other hand, are not rechargeable due to their criticalnature [49], and represent more pessimistic devices to assessIMDfence against. Thus, for our evaluation here, we considera communication session between a pacemaker and a com-mercial bedside reader (Merlin@homeTM) [22].

We consider different data volumes being transferred be-

14 VOLUME 4, 2016

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

tween the reader and IMD, ranging from a daily two-minute5

communication session to a two-minute weekly session.Since this reader is intended for monitoring the IMD sta-tus, it is assumed that most of the communicated data istransferred from the implant to the reader (e.g., in the formof data logs). Hence, the size of ANS is increased from64 bits (for a basic session) to roughly 3 MB in order toform a two-minute session. However, for worst-case analysis,the transceiver is considered to be enabled throughout thissession and we do not assume the use of energy harvestingfor ZPD. Moreover, without loss of generality and in orderto more accurately (and pessimistically) quantify the costof adding IMDfence to an existing system, we consider adual-CPU IMD, as discussed in the previous section. In thisconfiguration, the security CPU is assumed to execute thecomplete IMDfence protocol, while the medical CPU is setto a 5% duty cycle (active vs. sleep mode), based on typicalpacemaker usage [54], and consumes 20 µJ per heartbeatto provide electrical-stimulation impulses, based on reportedfigures of commercial devices [55].

With the above consideration, the impact of IMDfenceon IMD-battery lifetime can be visualized using Fig. 13 fordifferent implantable-grade battery sizes [56]. The variabilityin each data point captures the different volumes of datatransfer between the reader and IMD.

Since the majority of the cryptographic operations in theprotocol (authenticated encryption and MAC) are based onsymmetric block ciphers, as shown in Figures 5 and 6, it isvery interesting to investigate the impact of different cipherversions and/or implementations thereof on IMD lifetime,e.g., a pacemaker. More box plots have, thus, been addedto Fig. 13, where we readily notice that the hardware imple-mentation of AES-128 significantly outperforms the softwareAES-128 implementation, plus other lightweight softwareciphers such as SPECK and MISTY1. It is also interestingto observe that the energy impact of the hardware AES-128-based protocol is not significant when comparing with anunsecured communication.

D. IMD PERFORMANCETo study the impact of IMDfence on performance duringnormal operation, we will only analyze the bottleneck ofthe reader-IMD system in this regard, i.e., the IMD itself.This is because modern readers, such as tablets [17], havefar superior computational resources (and battery autonomy)than implants. As far as the smart card is concerned, theamount of computations performed by it is approximately thesame as that in commercial uses (e.g., EMV), which we knowto exhibit adequate performance.

As far as the IMD is concerned, the performance figure ofmerit that is crucial to capture here is the delay that IMDfenceincurs to the system, both for security computations anddata transmission over the air. For unsecured data transfer,

5This corresponds to an unencrypted session. An equivalent secure ses-sion (by employing IMDfence) will take longer than two minutes due to theadditional data transferred.

0.325 0.75 1.5 3.1Battery Capacity (Ah)

1

2

3

4

5

6

Yea

rs

No SecuritySPECK (S/W)MISTY1 (S/W)AES-128 (S/W)AES-128 (H/W)

FIGURE 13. IMD-battery lifetime with respect to cryptographic primitive used.Boxplot variation is due to different data-transfer volumes

the wireless transceiver incurs a delay of 2.2 ms. As shownin Fig. 10, for (hardware-accelerated) secure data transferthe time delay incurred by each (numbered) protocol stepis no higher than 6 ms, for a total protocol delay of 15.7ms. Therefore, for the time scales involved in biologicalprocesses, we can safely assume that the IMDfence delayoverhead is negligible.

E. SUMMARY OF INTRODUCED OVERHEADSTable 5 summarizes the impact of IMDfence on an IMDin terms of energy, performance and program-memory foot-print. For the hardware implementation of IMDfence, it canbe observed that, although the energy requirements increaseby more than 6 times for a basic session, the total dailyIMD consumption (that includes a two-minute communica-tion session and electrical-stimulation costs) increases from16.60 J to just 17.69 J, which amounts to a mere 6.57%increase, as previously shown in Fig. 13. The reason for thissmall increase is that the basic medical functionality, e.g., thecontinuous electrical stimulation of a pacemaker, dominatesthe security provisions since the reader accesses are far lessfrequent. In the case of software (AES-128) implementationof IMDfence, the total daily IMD consumption increases by19.82% (as shown in Fig. 13). Moreover, there is a minimalincrease in the computational delay and required program-memory size. In the context of current MCU technology,8.22–10.48 kB of additional memory size is negligible.Hence, we conclude that there is no noticeable change in theIMD costs when IMDfence is employed.

VII. CONCLUSIONSIn this paper, we have proposed a novel security protocolfor IMD ecosystems, IMDfence. We have demonstrated thatour approach offers a meticulous coverage of security re-quirements that are critical to these systems. This becomespossible through the use of a personal smart card and a trustedthird party, which helps in facilitating access control, non-repudiation, user authentication, bedside-reader operation

VOLUME 4, 2016 15

Siddiqi et al.: IMDfence: Architecting a Secure Protocol for Implantable Medical Devices

TABLE 5. Summary of costs for running the IMDfence protocol on an IMD

Energy Delay Prog-Mem1 basic 1 daily IMD footprint∗∗

session (µJ) cycle∗ (J) (ms) (kB)

Without security 16.61 16.60 2.17 16.50IMDfence (H/W) 108.31 17.69 15.73 24.72IMDfence (S/W) 217.89 19.89 58.99 26.98

* Which includes a daily two-minute comm. session (see Section VI-B)** This includes the comm. data handling, security processing and MCU

peripheral support library for GPIO and USART, which are needed tocommunicate with the transceiver.

and system scalability. We have also shown that IMDfencedoes not introduce any noticeable overheads in the implant,and it has the ability to support zero-power defense againstbattery-DoS attacks. It is observed that our proposed protocolincreases the total IMD energy consumption by just 6.57%,which is minimal in the context of the IMD lifespan. We havealso proposed an OOB-channel-based version of IMDfence,which enables offline or emergency access.

REFERENCES[1] M. A. Siddiqi, R. M. Seepers, M. Hamad, V. Prevelakis, and C. Strydis,

“Attack-tree-based threat modeling of medical implants,” in PROOFS2018. 7th International Workshop on Security Proofs for Embedded Sys-tems, ser. Kalpa Publications in Computing, vol. 7. EasyChair, 2018, pp.32–49.

[2] R. M. Seepers, “Implantable Medical Devices: Device security and emer-gency access,” Ph.D. dissertation, Erasmus University Medical Center,Rotterdam, Netherlands, December 2016.

[3] D. Halperin, T. S. Heydt-Benjamin, B. Ransford, S. S. Clark, B. Defend,W. Morgan, K. Fu, T. Kohno, and W. H. Maisel, “Pacemakers andimplantable cardiac defibrillators: Software radio attacks and zero-powerdefenses,” in Security and Privacy, 2008. SP 2008. IEEE Symposium on.IEEE, 2008, pp. 129–142.

[4] E. Marin, D. Singelée, F. D. Garcia, T. Chothia, R. Willems, and B. Pre-neel, “On the (in) security of the latest generation implantable cardiacdefibrillators and how to secure them,” in Proceedings of the 32nd AnnualConference on Computer Security Applications. ACM, 2016, pp. 226–236.

[5] E. Marin, D. Singelée, B. Yang, V. Volski, G. A. Vandenbosch, B. Nuttin,and B. Preneel, “Securing wireless neurostimulators,” in Proceedingsof the Eighth ACM Conference on Data and Application Security andPrivacy. ACM, 2018, pp. 287–298.

[6] Medtronic, SECURITY BULLETIN – ConexusTM Telemetry and Moni-toring Accessories, 2019.

[7] FDA, Firmware Update to Address Cybersecurity Vulnerabilities Identi-fied in Abbott’s (formerly St. Jude Medical’s) Implantable Cardiac Pace-makers: FDA Safety Communication, 2019.

[8] L. Bu, M. G. Karpovsky, and M. A. Kinsy, “Bulwark: Securing im-plantable medical devices communication channels,” Computers & Secu-rity, vol. 86, pp. 498–511, 2019.

[9] T. Belkhouja, X. Du, A. Mohamed, A. K. Al-Ali, and M. Guizani,“Biometric-based authentication scheme for implantable medical devicesduring emergency situations,” Future Generation Computer Systems,vol. 98, pp. 109–119, 2019.

[10] H. Chi, L. Wu, X. Du, Q. Zeng, and P. Ratazzi, “e-SAFE: Secure, Efficientand Forensics-Enabled Access to Implantable Medical Devices,” in 2018IEEE Conference on Communications and Network Security (CNS), 2018,pp. 1–9.

[11] T. Belkhouja, X. Du, A. Mohamed, A. K. Al-Ali, and M. Guizani,“Symmetric Encryption Relying on Chaotic Henon System for SecureHardware-Friendly Wireless Communication of Implantable Medical Sys-tems,” Journal of Sensor and Actuator Networks, vol. 7, no. 2, p. 21, 2018.

[12] C. Strydis, R. M. Seepers, P. Peris-Lopez, D. Siskos, and I. Sourdis, “Asystem architecture, processor, and communication protocol for secureimplants,” ACM Transactions on Architecture and Code Optimization(TACO), vol. 10, no. 4, p. 57, 2013.

[13] J. van den Breekel, D. A. Ortiz-Yepes, E. Poll, and J. de Ruiter, “Emv in anutshell,” KPMG, Tech. Rep., 2016.

[14] M. A. Siddiqi and C. Strydis, “IMD Security vs. Energy: Are we tiltingat windmills?: POSTER,” in Proceedings of the 16th ACM InternationalConference on Computing Frontiers. ACM, 2019, pp. 283–285.

[15] Medtronic, AzureTM S SR MRI SureScanTM W3SR01 - Device Manual,2017.

[16] St. Jude Medical, Confirm RxTM Model DM3500 Insertable CardiacMonitor - User’s Guide, 2016.

[17] ——, ProclaimTM Implantable Pulse Generator - Clinician’s Manual,2017.

[18] E. Marín Fàbregas, “Security and Privacy of Implantable Medical De-vices,” Ph.D. dissertation, KU Leuven, Belgium, 2018.

[19] R. J. Anderson, “Liability and computer security: Nine principles,” inEuropean Symposium on Research in Computer Security. Springer, 1994,pp. 231–245.

[20] M. Roe, “Cryptography and evidence,” University of Cambridge, Com-puter Laboratory, Tech. Rep. UCAM-CL-TR-780, May 2010. [Online].Available: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-780.pdf

[21] M. Rostami, A. Juels, and F. Koushanfar, “Heart-to-heart (H2H): authen-tication for implanted medical devices,” in Proceedings of the 2013 ACMSIGSAC conference on Computer & communications security. ACM,2013, pp. 1099–1112.

[22] St. Jude Medical, FAQs - Merlin.netTM Patient Care Network (PCN) 8.0Q&A, 2015.

[23] ——, Ellipse, Fortify Assura ICD, Quadra Assura, Quadra Assura MP,Unify Assura CRT-D User Manual, 2017.

[24] M. Wazid, A. K. Das, N. Kumar, M. Conti, and A. V. Vasilakos, “A novelauthentication and key agreement scheme for implantable medical devicesdeployment,” IEEE journal of biomedical and health informatics, vol. 22,no. 4, pp. 1299–1309, 2018.

[25] D. Mao, L. Zhang, X. Li, and D. Mu, “Trusted authority assisted three-factor authentication and key agreement protocol for the implantablemedical system,” Wireless Communications and Mobile Computing, vol.2018, 2018.

[26] H. Rathore, C. Fu, A. Mohamed, A. Al-Ali, X. Du, M. Guizani, and Z. Yu,“Multi-layer security scheme for implantable medical devices,” NeuralComputing and Applications, pp. 1–14, 2018.

[27] C. Fu, X. Du, L. Wu, Q. Zeng, A. Mohamed, and M. Guizani, “POKsBased Secure and Energy-Efficient Access Control for Implantable Medi-cal Devices,” in Security and Privacy in Communication Networks, 2019,pp. 105–125.

[28] N. Ellouze, S. Rekhis, N. Boudriga, and M. Allouche, “Powerless securityfor cardiac implantable medical devices: Use of wireless identification andsensing platform,” Journal of Network and Computer Applications, vol.107, pp. 1–21, 2018.

[29] C. Camara, P. Peris-Lopez, J. M. De Fuentes, and S. Marchal, “Accesscontrol for implantable medical devices,” IEEE Transactions on EmergingTopics in Computing, 2020.

[30] C.-S. Park, “Security mechanism based on hospital authentication serverfor secure application of implantable medical devices,” BioMed researchinternational, vol. 2014, 2014.

[31] M. Rushanan, A. D. Rubin, D. F. Kune, and C. M. Swanson, “Sok: Securityand privacy in implantable medical devices and body area networks,” in2014 IEEE Symposium on Security and Privacy. IEEE, 2014, pp. 524–539.

[32] R. M. Seepers, J. H. Weber, Z. Erkin, I. Sourdis, and C. Strydis, “Securekey-exchange protocol for implants using heartbeats,” in Proceedings ofthe ACM International Conference on Computing Frontiers. ACM, 2016,pp. 119–126.

[33] V. Pournaghshband, M. Sarrafzadeh, and P. Reiher, “Securing legacymobile medical devices,” in International Conference on Wireless MobileCommunication and Healthcare. Springer, 2012, pp. 163–172.

[34] J. Sorber, M. Shin, R. Peterson, C. Cornelius, S. Mare, A. Prasad,Z. Marois, E. Smithayer, and D. Kotz, “An amulet for trustworthy wearablemhealth,” in Proceedings of the Twelfth Workshop on Mobile ComputingSystems & Applications. ACM, 2012, p. 7.

[35] K. B. Rasmussen, C. Castelluccia, T. S. Heydt-Benjamin, and S. Capkun,“Proximity-based access control for impl