Can Formal Security Verification Really Be Optional? Scrutinizing the Security of IMD Authentication Protocols

The need for continuous monitoring of physiological information of critical organs of the human body, combined with the ever-growing field of electronics and sensor technologies and the vast opportunities brought by 5G connectivity, have made implantable medical devices (IMDs) the most necessitated devices in the health arena. IMDs are very sensitive since they are implanted in the human body, and the patients depend on them for the proper functioning of their vital organs. Simultaneously, they are intrinsically vulnerable to several attacks mainly due to their resource limitations and the wireless channel utilized for data transmission. Hence, failing to secure them would put the patient’s life in jeopardy and damage the reputations of the manufacturers. To date, various researchers have proposed different countermeasures to keep the confidentiality, integrity, and availability of IMD systems with privacy and safety specifications. Despite the appreciated efforts made by the research community, there are issues with these proposed solutions. Principally, there are at least three critical problems. (1) Inadequate essential capabilities (such as emergency authentication, key update mechanism, anonymity, and adaptability); (2) heavy computational and communication overheads; and (3) lack of rigorous formal security verification. Motivated by this, we have thoroughly analyzed the current IMD authentication protocols by utilizing two formal approaches: the Burrows–Abadi–Needham logic (BAN logic) and the Automated Validation of Internet Security Protocols and Applications (AVISPA). In addition, we compared these schemes against their security strengths, computational overheads, latency, and other vital features, such as emergency authentications, key update mechanisms, and adaptabilities.


Introduction
The need for continuous monitoring of physiological information of critical organs of the human body, combined with the ever-growing field of electronics and sensor technologies, and the colossal opportunities brought by 5G connectivity, have made implantable medical devices (IMDs) the most necessitated devices in the health arena. This is clearly shown by the global IMD market share, which was worth USD 96.6 billion in 2018 [1] and grew to around USD 103.3 Billion in 2019, and will likely rise to USD 148.8 Billion in 2024 [2].
IMDs possess several applications to help manage numerous health conditions. These include controlling the heart rhythm using cardiac pacemakers, heart support using ventricular assist devices, and chronic spinal pain reliefs using spinal cord stimulators [3]. Furthermore, they extend their applications by enabling wireless communication technologies that help manage the interaction between IMDs and external devices in wireless body area networks (WBANs) [4,5]. IMDs functioning in WBANs have made a significant Despite their critical roles in improving human health conditions, IMDs have various challenges, among which, limitations of resource (power, storage, computation, etc.) and security concerns are the most serious. The former challenge is directly related to their small size and inflexibility since they are implanted in the human body. Concerning the latter, IMDs are susceptible to many security and privacy threats that put a patient's life in danger [6]. Some of the most common security problems that IMDs face are impersonation, requesting confidential information, causing a shock to the patient, reprogramming of IMD, etc. Moreover, security assaults (e.g., side-channel attacks) targeting a wide range of internet of things (IoT) processors, such as the Cortex-A platform, also threaten the wellbeing of IMDs [7].
To date, many countermeasures have been taken to keep the confidentiality, integrity, and availability of IoT systems, along with different privacy and safety mechanisms [8][9][10][11][12]. In particular, to IMDs, different researchers have proposed several solutions that can be categorized into three main groups: cryptographic, access control, and misbehavior detection. The first group of solutions utilizes cryptographic rudiments (including public-key encryption, symmetric-key encryption, cryptographic hash functions, etc.) [13,14]. Access control mechanisms [15][16][17], on the other hand, protect IMDs from unauthorized access by employing different techniques, such as certificates and lists, designation-based, juxtaposition-based, and biometric-based [6]. The last type of method involves malicious behavior detection to shield IMDs from a range of attacks that may not be easily addressed by the former two solutions [18,19].
IMDs are very sensitive as they are implanted in the human body, and the patients depend on them for the proper functioning of their vital organs. Moreover, due to their resource limitations and the open channel utilized for data transmission, they are intrinsically vulnerable to several attacks, such as distributed denial of service with different attacker intentions [20]. Hence, failing to secure them would put the life of the patient in jeopardy, and damage the reputations of the manufacturer. Consequently, it is imperative to carefully examine the security of the IMD authentication protocols for any vulnerabilities. To do so, we followed two methods. First, we conducted an extensive literature review to understand the operations, architectural perspectives, critical security, and privacy requirements and proposed solutions. We also leveraged empirical data that approximated delays introduced by cryptographic operations for comparative analysis of the authentication protocols. Next, we used two well-known security verification approaches, BAN logic [21] and AVISPA [22], to formally analyze the authentication protocols. Unfortunately, many security protocols designed for IMDs are not formally verified, or they use only one verification method [23][24][25][26][27][28][29][30].
The main contributions of this research work can be summarized as follows: • We examined various security and privacy requirements along with numerous threats that surround IMDs.

•
We performed formal security validation of the contemporary authentication schemes based on BAN logic and AVISPA against several security goals.

•
We compared these schemes concerning security strength, computational overhead, latency, and additional features, such as emergency authentication, adaptiveness, and key update mechanisms. • Battery. Implanted sensors need the power to sense information on the body and produce an output. The source of energy for active implants comes from batteries. These batteries can be chargeable or non-chargeable, depending on the sensor type [32], and external or through independent power sources [33]. While the former approach uses optical charging, ultrasonic transducer, and inductive coupling, the latter uses the body environment energy to generate electrical energy for IMDs. Either way, efficient power management is a must since it is difficult (or not desirable) to change batteries now and then. Hence, batteries fixed with these implants should serve for a prolonged period. • Memory. Memory is vital for the proper functioning of IMDs. It enables implants to store sensed data, configurations, and other important information (such as security keys). The device memory is generally non-volatile (read-only memory (ROM)), retaining its contents regardless of the power supply. In addition, the electrically erasable programmable ROM (EEPROM) and flash memories can be good candidates [32]. • Processing unit. The processing unit is the brain of the entire IMD system, which processes instructions and control signals. The processing unit actively directs the communication between IMDs and external devices, efficient power and transceiver management, and is responsible for other essential tasks, such as sensing and processing data [32]. • Transceiver. To communicate different sensed data to the external devices (such as a programmer) and receive other information from the external devices, IMDs need to establish a wireless medium. An electronic device, known as a transceiver (transmit- Figure 1. A typical IMD system architecture. • Sensor devices. These are small, in-body implanted, battery-powered, and wireless communication enabled sensors to sense, collect, and send patient information to a controller. In general, there are three categories (based on the data measured/collected) of such sensors: those that measure vital physiological information (such as glucose level, EEG, ECG, etc.), those that gather main environmental parameters, such as humidity, temperature, and pressure, and those that measure signals related to the human body movements [31]. • Battery. Implanted sensors need the power to sense information on the body and produce an output. The source of energy for active implants comes from batteries. These batteries can be chargeable or non-chargeable, depending on the sensor type [32], and external or through independent power sources [33]. While the former approach uses optical charging, ultrasonic transducer, and inductive coupling, the latter uses the body environment energy to generate electrical energy for IMDs. Either way, efficient power management is a must since it is difficult (or not desirable) to change batteries now and then. Hence, batteries fixed with these implants should serve for a prolonged period. • Memory. Memory is vital for the proper functioning of IMDs. It enables implants to store sensed data, configurations, and other important information (such as security keys). The device memory is generally non-volatile (read-only memory (ROM)), retaining its contents regardless of the power supply. In addition, the electrically erasable programmable ROM (EEPROM) and flash memories can be good candidates [32]. • Processing unit. The processing unit is the brain of the entire IMD system, which processes instructions and control signals. The processing unit actively directs the communication between IMDs and external devices, efficient power and transceiver management, and is responsible for other essential tasks, such as sensing and processing data [32]. • Transceiver. To communicate different sensed data to the external devices (such as a programmer) and receive other information from the external devices, IMDs need to establish a wireless medium. An electronic device, known as a transceiver (transmitter and receiver), assists this exchange of information. A specifically designed transceiver called the Medical Implant Communication System (MICS) is available for medical implants with low-power, short-range, and high data rate features [34].
• Application-Specific Components. These components are optional, meaning they may not appear in all implanted devices. One good illustration is the Smart Implant Security Core (SISC) [35]. Communication between IMD and a programmer via wireless medium passes through this device. It runs an energy-efficient security protocol by using energy harvesting when it performs authentication with the programmer. Apart from that, SISC helps defend against denial-of-service attacks, particularly resource exhaustion attacks. • Wireless Identification and Sensing Platform (WISP). One of the significant constraints of implanted devices is related to power. These devices reside in the human body, making them challenging to recharge or frequently change. Hence, a device called WISP is proposed [32]. Using WISP, therefore, it is possible to conserve the battery of an IMD, especially during an authentication process, as it harvests energy from the reader via radiofrequency. • Programmer/Controller. Sensing or measuring vital physiological states is only half of the primary goal of using implants. The sensors should also convey the sensed information to an external device (a specially designed controller or a smartphone) near the IMDs. Apart from collecting sensed information from the implants, programmers/controllers assist in configuration setup and regulation of therapy, among others.

Security and Privacy Requirements, Threats, and Proposed Solutions
IMDs encounter several challenges, from their conception through their operation. These devices are implanted and severely limited in terms of power, storage, and computing capabilities, making it challenging to build effective communication technologies and security mechanisms. In this regard, IMDs must satisfy various security requirements to withstand the ever-increasing attacks that target them.
The privacy of patients is of paramount importance. Two critical issues in this regard are user anonymity and non-traceability [6,36]. The former refers to a strong requirement that it should be impossible (or difficult enough) for the attacker to intercept the patient's identity from the messages exchanged. Often, this is the first step towards an impersonation attack in which an adversary identifies the user's real identity to fool the other party. Nontraceability, on the other hand, protects the IMD by making it difficult for an attack to know where the patient is or from where he is communicating. As a result, the locations of patients remain confidential, and any acts they conduct cannot be traced back to them by an unauthorized entity.

Security and Privacy Requirements
Here, we describe nine essential security requirements relevant to the IMDs: • Confidentiality: the physiological information collected by IMDs is often sent out to a reader via a wireless medium, which both authorized and malicious users can observe. Accordingly, it is essential to encrypt this information to protect the data transmitted from exploitation by the adversaries sitting between the IMD and the reader. • Integrity: protecting the integrity of the information transmitted via the wireless link in IMD reader communication defends against unauthorized modification. In addition, when illegitimate users tamper with the data, it should be known by the authorized users that the data is modified. • Availability: this is one of the three security triads (confidentiality, integrity, and availability) that has the objective of making the IMD-enabled system accessible to authorized users despite the presence of adversaries.

•
Mutual authentication: unless authorized access is in place, an adversary can impersonate the IMD or the reader to fool the other. Hence, communicating parties need to make sure whom they are talking to before disclosing important information. • Authorization: once the confidentiality, integrity, and availability of IMDs are guaranteed, and the users (a human user or a device such as a reader) are authenticated, proper authorization to identify the privileges of these users' proceeds. For instance, a doctor who may issue commands to the IMD should be distinct from a nurse who may only read information to monitor the patient. • Non-repudiation: there are cases in which one party's actions (knowingly or not) bring unwanted consequences. For instance, in an IMD-enabled health care system, there can be many participants in the process of diagnosing, monitoring, and treating patients. These professionals should not be able to repudiate the actions they took during the process so that, if anything terrible happened next, it is possible to know who did what.

•
Session key agreement: communicating entities need to agree on a session key and use that key to encrypt the exchanged information. Session keys are symmetric keys that are primarily derived from another key (called a master key) to restrict ciphertexts and minimize the exposure of an attack. Furthermore, using session keys improves communication performance since these keys do not need to be stored and searched. Moreover, symmetric key encryption is faster. • Perfect forward secrecy: satisfying this security requirement means the past sessions will not be compromised even if a master key is compromised. In the context of IMDs, if the long-term key is stolen, and if this is known, the key can be updated, and only minimal information would be disclosed while all past communications can be kept safe from future compromises.

•
Emergency authentication: if we deal with patients with implanted devices, there can always be emergencies requiring human intervention. Emergency authentication is one of the paradox requirements since unauthorized users need to access the implants to override the authorization and authentication properties, which calls for a clear definition of an emergency.
Concerning privacy, there are at least five privacy requirements [12,37] that should be satisfied:

•
Device-existence privacy: this privacy requirement challenges the protocol designers to conceal the device's information of an IMD-enabled system and prohibit an adversary from learning its existence. • Device-type privacy: in the cases where the presence of a device cannot be wholly concealed or its privacy cannot be maintained, the type of the device should stay anonymous. By doing so, it is possible to protect the patient from device-type specific attacks. • Specific-device ID privacy: the unique ID (or serial number) of an IMD should not be disclosed to unauthorized users. Doing so protects the patients by prohibiting attackers from tracking down their locations. • Measurement and log privacy: the information measured, collected, and analyzed in either IMD or the reader should be kept private. Keeping the privacy of logs enables the investigation and trace actions taken during the communication.

•
Bearer privacy: these are often related to information such as patients' names, record history, tests, IMD characteristics, etc., which should be kept private.

Security Issues and Proposed Solutions
Threats are only dangerous because of adversaries, malicious entities that usually have access to the communication media and are placed between the authorized entities to violate confidentiality (and privacy), integrity, and availability. These adversaries can be passive or active, internal or external, computationally restrained or unrestrained, and single individual vs. group [6].
In regard to IMD security, we can broadly classify adversaries based on their capabilities as passive eavesdroppers and active attackers [37][38][39]. The first class of adversaries can only eavesdrop on the radio communication between the legitimate entities to discover unencrypted messages. Sometimes, even if the messages are encrypted, passive adversaries may observe patterns to violate the privacy of communicating parties, such as learning the existence of IMD.
On the other hand, active attackers can replay, modify, or delete messages in addition to possessing all of the capabilities of passive adversaries. These are the most dangerous types of adversaries that can bring life-threatening attacks to IMD-enabled systems. Adversaries in this category can execute replay attacks by forwarding exchanged messages later, changing critical settings of the implants by producing new commands, and exhausting the battery life of IMDs.
Different researchers have studied various security and privacy issues that challenge the normal operations of IMDs along with various proposed solutions that can be generally categorized as auditing-alone solutions, cryptographic solutions, and access control schemes [6]. The first category refers to solutions that solely depend on the access logs for the IMD. However, such techniques may not be suitable, as they cannot withstand active attacks if not used with other techniques such as access control mechanisms. The second measure utilizes cryptographic rudiments such as asymmetric-key cryptography, symmetric-key cryptography, and cryptographic hash functions. Three problems have been identified concerning the cryptographic solutions for IMDs [40]-the difficulty of implementation as most of the IMDs are already implanted in the human body, challenging to authenticate doctors during emergencies in which the patient is unconscious, and difficulty in maintaining the hardware and software of the implanted devices. The third solution refers to schemes that make use of access control help to protect IMDs from unauthorized access. The noticeable weakness in this solution is the difficulty of access during an emergency [6].

Formal Security Verification
Checking the safety of security protocols via a formal approach boosts users' confidence, giving more convincing proof than its informal counterpart. When it comes to security protocols, such techniques may be divided into three categories: modal logic, model checkers, and theorem provers. This section will use one from the variants of modal logic (BAN logic) and another from model checking (AVISPA) to perform formal security verification for the authentication schemes proposed to safeguard IMDs. It is worth mentioning that the last two IMD authentication protocols (shown in Sections 4.3.6 and 4.3.7) have also been analyzed, in [41,42], by the same authors.

BAN Logic Based Formal Security Verification
BAN logic uses logic of beliefs to analyze authentication protocols by following its own rules. First, the messages exchanged between the participants of the protocol are idealized. Then, reasonable assumptions will be formulated, and the objectives that the protocol intends to meet are defined. Finally, a derivation step follows where the BAN logic rules are used together with the assumptions and the intermediate results to reach the goals. Figure 2 shows a typical procedure of carrying out formal analysis using BAN logic. The BAN logic symbols and rules are shown in Tables 1 and 2, respectively.

Rule name Rule
Message Meaning Rule (MM)

AVISPA Based Formal Security Analysis
The previous section shows that BAN logic has been extensively used to verify authentication protocols by transforming them into a particular format and validating them through different logical rules. Unfortunately, BAN logic has limitations in accurately specifying a protocol in the idealization phase [21,43]. For that reason, most authentication protocols use automated formal security verification tools alongside BAN logic.
AVISPA provides a language called the high-level protocol specification language (HLPSL) [44] for describing security protocols and specifying their intended security properties, as well as a set of tools to validate them formally. An hlpsl2if translates the HLPSL specification into the Intermediate Format (IF). IF is a lower-level language that is read directly by the back-ends of the AVISPA Tool. The IF specification of a protocol is then input to the back-ends of the AVISPA Tool to analyze the stated security goals. Figure 3 shows this process.
The HLPSL specification is consists of basic roles, transitions, and composed roles used in three modules: role, session, and environment. Basic role refers to the specification of each of the modeled protocol participants and the initially known information as a parameter. These roles are then called to specify how the resulting participants interact by connecting various basic roles into a composed role. The transition part of an HLPSL specification encompasses a set of transitions between different roles. Each transition symbolizes the acceptance of a message and the sending of a response message.
properties, as well as a set of tools to validate them formally. An hlpsl2if translates the HLPSL specification into the Intermediate Format (IF). IF is a lower-level language that is read directly by the back-ends of the AVISPA Tool. The IF specification of a protocol is then input to the back-ends of the AVISPA Tool to analyze the stated security goals. Figure  3 shows this process.
The HLPSL specification is consists of basic roles, transitions, and composed roles used in three modules: role, session, and environment. Basic role refers to the specification of each of the modeled protocol participants and the initially known information as a parameter. These roles are then called to specify how the resulting participants interact by connecting various basic roles into a composed role. The transition part of an HLPSL specification encompasses a set of transitions between different roles. Each transition symbolizes the acceptance of a message and the sending of a response message.

Khan et al.'s Protocol
The protocol proposed by Khan et al. [23] is a privacy-preserving key agreement protocol for WBANs. The protocol has four main participants: the system administrator (SA), the hub node (HN), the intermediary nodes (IN), and the normal nodes (N). HN is often considered a trusted high-end server that does not have computing resource constraints. The Ns are implanted sensors with computational limitations. The intermediary nodes have better processing, battery, and storage than Ns, and they are placed between HN and Ns to relay traffic. Furthermore, the protocol is executed in three main phases: initialization, registration, and authentication. Figure 4 shows the final phase of the protocol. Figure 5 presents the OFMC and CL-AtSe back-end results of the protocol.  •

Wu et al.'s Protocol [24]
This protocol is a proxy-based access control protocol that uses attribute-based encryption, particularly the ciphertext policy attribute-based encryption (CP-ABE). The protocol is executed by three participants-IMD, operator, and proxy. The IMDs have unique identifications IDi and a master key Ki M , which is only used for the initial pairing process with the proxy. All operators with the public parameters PK used in CP-ABE, unique identifications IDo, a public and private key pair (PUOP and PROP, respectively), and a certificate Cert must first be registered at a Central Health Authority (CHA). The CHA will then generate the secret key SK. The operator uses a programmer to communicate with the IMD and proxy after it obtains the required information by manual inputting or reading in from a smart card. With the identification of IDp and connection with an IMD programmer through an audio cable, the proxy device performs the access control for the IMD. Figure 6 shows the flow of messages in the protocol. Figure 7 illustrates the OFMC and CL-AtSe back-end results of the protocol.

Wu et al.'s Protocol
This protocol [24] is a proxy-based access control protocol that uses attribute-based encryption, particularly the ciphertext policy attribute-based encryption (CP-ABE). The protocol is executed by three participants-IMD, operator, and proxy. The IMDs have unique identifications ID i and a master key K i M , which is only used for the initial pairing process with the proxy. All operators with the public parameters PK used in CP-ABE, unique identifications ID o , a public and private key pair (PU OP and PR OP , respectively), and a certificate Cert must first be registered at a Central Health Authority (CHA). The CHA will then generate the secret key SK. The operator uses a programmer to communicate with the IMD and proxy after it obtains the required information by manual inputting or reading in from a smart card. With the identification of ID p and connection with an IMD programmer through an audio cable, the proxy device performs the access control for the IMD. Figure 6 shows the flow of messages in the protocol. Figure 7 illustrates the OFMC and CL-AtSe back-end results of the protocol. 1. BAN logic-based formal security analysis.
ℎ( ) ( 10) ↔ 1. BAN logic-based formal security analysis.  This protocol uses a compressing-based encryption mechanism and public key infrastructure, and other cryptographic protocols, such as RSA, AES, and HMAC. The protocol comprises three participants-IMD, smartphone, and programmer. The IMD communicates with the patient's smartphone via Bluetooth, and it interacts with the doctor's programmer through the wireless medium. The smartphone refers to both the patient and doctor smartphones, in which the patient's smartphone links with the IMD utilizing Bluetooth and connects with a programmer wirelessly. The protocol involves four stagesinitialization, pairing, authentication, and authorization, as shown in Figures 8 and 9 presents the OFMC and CL-AtSe back-end results of the protocol. (a)

Chi et al.'s Protocol
This protocol [25] uses a compressing-based encryption mechanism and public key infrastructure, and other cryptographic protocols, such as RSA, AES, and HMAC. The protocol comprises three participants-IMD, smartphone, and programmer. The IMD communicates with the patient's smartphone via Bluetooth, and it interacts with the doctor's programmer through the wireless medium. The smartphone refers to both the patient and doctor smartphones, in which the patient's smartphone links with the IMD utilizing Bluetooth and connects with a programmer wirelessly. The protocol involves four stages-initialization, pairing, authentication, and authorization, as shown in Figures 8 and 9 presents the OFMC and CL-AtSe back-end results of the protocol. This protocol uses a compressing-based encryption mechanism and public key infrastructure, and other cryptographic protocols, such as RSA, AES, and HMAC. The protocol comprises three participants-IMD, smartphone, and programmer. The IMD communicates with the patient's smartphone via Bluetooth, and it interacts with the doctor's programmer through the wireless medium. The smartphone refers to both the patient and doctor smartphones, in which the patient's smartphone links with the IMD utilizing Bluetooth and connects with a programmer wirelessly. The protocol involves four stagesinitialization, pairing, authentication, and authorization, as shown in Figures 8 and 9 presents the OFMC and CL-AtSe back-end results of the protocol. (a)

Parvez et al.'s Protocol [26]
The proposed authentication scheme extended the protocol in [45] that comprises of sensors, which are resource-constrained devices that are implanted in (or wearable on) human body; mobile devices, which are small handheld devices to collect the data sent by the sensors; gateway, which is a trusted server that is used to register sensors, mobile devices and medical experts, and generates different keys for secure communication; and medical experts refers to medical professionals, such as doctors or nurses who analyze and take action with the collected information. The proposed protocol is executed in two phases-registration and authentication-as shown in Figures 10 and 11 illustrates the OFMC and CL-AtSe back-end results of the protocol.
1. BAN logic-based formal security analysis.

Parvez et al.'s Protocol
The proposed authentication scheme [26] extended the protocol in [45] that comprises of sensors, which are resource-constrained devices that are implanted in (or wearable on) human body; mobile devices, which are small handheld devices to collect the data sent by the sensors; gateway, which is a trusted server that is used to register sensors, mobile devices and medical experts, and generates different keys for secure communication; and medical experts refers to medical professionals, such as doctors or nurses who analyze and take action with the collected information. The proposed protocol is executed in two phases-registration and authentication-as shown in Figures 10 and 11 illustrates the OFMC and CL-AtSe back-end results of the protocol.

Iqbal et al.'s Protocol [27]
The proposed protocol works between the sensor nodes (SN), controller (BS), and a medical server (MS). The SNs are (implanted) medical devices that sense vital physiological information. In this protocol, a BS is only used to assist the authentication process so that the SN directly communicates with the MS after successful authentication is achieved. The protocol is executed in three stages: deployment, authentication, and data communication, as shown in Figures 12 and 13 presents the OFMC and CL-AtSe back-end results of the protocol.

Iqbal et al.'s Protocol
The proposed protocol [27] works between the sensor nodes (SN), controller (BS), and a medical server (MS). The SNs are (implanted) medical devices that sense vital physiological information. In this protocol, a BS is only used to assist the authentication process so that the SN directly communicates with the MS after successful authentication is achieved. The protocol is executed in three stages: deployment, authentication, and data communication, as shown in Figures 12 and 13 presents the OFMC and CL-AtSe back-end results of the protocol.

Iqbal et al.'s Protocol [27]
The proposed protocol works between the sensor nodes (SN), controller (BS), and a medical server (MS). The SNs are (implanted) medical devices that sense vital physiolog ical information. In this protocol, a BS is only used to assist the authentication process so that the SN directly communicates with the MS after successful authentication is achieved The protocol is executed in three stages: deployment, authentication, and data communi cation, as shown in Figures 12 and 13 presents the OFMC and CL-AtSe back-end result of the protocol. 1. BAN logic-based formal security analysis.
→ : ( 3) → : ↔   4.3.6. He and Zeadally's Protocol [28] He and Zeadally's authentication protocol comprises a programmer/controller, the AAL server, and a user. The controller is responsible for communicating with the IMDs and receiving collected physiological information. Once such information is collected, it can be accessed by a remote user after the AAL server authenticates the user. Furthermore, the controller may communicate with different devices, such as home robots for immediate nearby assistance, located in the patient's premises. The protocol is also executed in two stages: registration and authentication, as shown in Figures 14 and 15 illustrates the OFMC and CL-AtSe back-end results of the protocol.
1. BAN logic-based formal security analysis.

He and Zeadally's Protocol
He and Zeadally's authentication protocol [28] comprises a programmer/controller, the AAL server, and a user. The controller is responsible for communicating with the IMDs and receiving collected physiological information. Once such information is collected, it can be accessed by a remote user after the AAL server authenticates the user. Furthermore, the controller may communicate with different devices, such as home robots for immediate nearby assistance, located in the patient's premises. The protocol is also executed in two stages: registration and authentication, as shown in Figures 14 and 15 illustrates the OFMC and CL-AtSe back-end results of the protocol.

Ellouze et al.'s Protocol
This protocol [29] is a mutual authentication protocol for cardiac IMDs that integrates a powerless device called wireless identification and sensing platform (WISP) with IMDs to conserve the battery lifetime of IMDs by drawing energy from an RFID reader. The authentication scheme operates in regular and emergency modes between the WISP and the RFID reader. The final goal is to create mutual authentication between the programmer and the IMD. Figure 16 shows both modes of the protocol. The authors of this protocol performed AVISPA-based security verification and claimed that the protocol is secure. Hence, only BAN logic-based analysis is performed here.

Discussion
The authentication protocols described and analyzed in the previous section have shown the importance of formally analyzing security protocols for usage reliability.
Khan et al.'s protocol is safe as per the output of both BAN logic and AVISPA in satisfying the goals. The hub node can be sure about the validity of the temporary identification (G1 and G2) and the auxiliary authentication parameter (G3 and G4). Furthermore, the sensor node trusts the newly generated session key (G6 and G7).
The proxy-assisted access control scheme proposed by Wu et al. is the second safe protocol for the authentication goals set. The main objective of the protocol is to device a shared symmetric key K t that the programmer and the IMD will use to secure the information exchanged. Accordingly, (G2) to (G5), (G8), and (G9) show that this objective is satisfied. Furthermore, other less essential facts that involve the IDs of the participating agents are authentic.
Chi et al.'s access control scheme with forensic capability is designed to safeguard IMDs from unauthorized access. The protocol is secure as per the results of BAN logic and AVISPA on authenticity and secrecy properties. The goals in the BAN logic analysis investigated the authentication between the IMD, smartphone, and the programmer through the keys K d , K r , K p , and K i .
The user authentication scheme in WBAN, as proposed by Parvez et al., is found to be unsafe, by both AVISPA and BAN logic, on the authentication of the shared key K ssk . The shared key that will be used by the medical expert and the IMD is computed from the nonce, SN j , and M id . In terms of BAN logic, this means the IMD has to believe these values to believe the computed session key. Consequently, the derivations (D11) to (D13) alone cannot enable the IMD to derive its belief to the shared key-which calls for two new hypotheses about the control of the nonce and M id by the mobile device that acts as a proxy between the IMD and the external devices. Such hypotheses may not be accurate given that ME and GW generated these values, respectively. However, since the message passed from the MD to the IMD is fresh and protected by the key that both parties trust, we may still be convinced that the IMD can derive the session key. The final goal, (G5), can be derived after a new message arrives from the ME to IMD using the session key K ssk .
Iqbal et al.'s authentication and key agreement scheme are proposed for node authentication in the body sensor environment. The protocol has some serious issues, typically concerning reply attacks. Specifically, the security goals (G4) and (G5) related to the mutual authentication between the medical server and the IMD cannot be satisfied as-is. The medical server cannot be sure about the freshness of the shared session key forwarded by the base station, making the message vulnerable to replay attack. Consequently, the hypotheses (H1) and (H2) need to be added to maintain authentication. More importantly, it is possible to improve the protocol by including a nonce along with the session key SK when BS sends the message to the MS.
He and Zeadally's scheme aims to improve the security of ambient assisted living. It mainly focuses on the mutual authentication between the Controller and the User via the AAL server. With this regard, the goals (G3), (G5), (G8), and (G10) refer to the secure information exchange, while (G6) and (G11) specify the secure session key exchange between the User and the Controller. The remaining goals are related to the exchange of symmetric keys among all the participants of the authentication scheme. The result of both the BAN logic and AVISPA illustrate that it is not possible to conclusively state the protocol as safe to use. That is, the derivations show that for the AAL server to believe that TK A-U is a key that is only known by itself and the User (G1), it must first believe that PU is the public key of the User that is encrypting the messages by the key TK A-U (G2). This, in turn, needs the AAL server to believe that this User has jurisdiction over the public key PU, meaning that the AAL server has to trust this User concerning PU (H1). Consequently, we cannot prove the goals (G1) and (G2) without the hypothesis we added.
Ellouze et al.'s scheme is a specific authentication protocol proposed for cardiac IMDs with powerless authentication mechanisms. The protocol operates in both emergency and regular modes to authenticate the programmer to the IMD and vice versa. The authors of this protocol have performed AVISPA based formal security analysis and reported that the protocol is safe. However, when the protocol is analyzed using BAN logic, a contrary result is found. The result from the analysis of the BAN logic in the emergency mode of the protocol shows the requirement of two additional hypotheses to satisfy the authentication between the WISP and the RFID Reader. Specifically, the WISP cannot conclusively believe the K Bio . This key will be used to derive the session key K' latter if the reader believes it without guaranteeing the freshness of NR. Furthermore, the security goal that conditions the guarantee for the WISP that the RFID Reader believes the session key K' (G7) can only be satisfied if the freshness of NW is guaranteed. Concerning the regular mode, the same issue exists as shown in the hypotheses (H1) and (H2) for the derivation of (D3), (D4), and (D10).

Comparison by Security Strength
Here, we compare the authentication schemes that are formally analyzed in Section 3. The comparisons are based on security properties, key features that IMD authentication protocols need to possess, computational overhead, and latency. Accordingly, each of the authentication protocols is checked against different security requirements (integrity (INT), confidentiality (CNF), authentication (AUT), session key agreement (SKA), perfect forward secrecy (PFS), and replay attack protection (RAP)) as shown in Table 3.

Overall Comparison of the Authentication Protocols
The comparison metrics-security strength, functionality, and efficiency-can be collectively used to understand better these schemes regarding security, competence, and capability. Such comparison can be best described in a triangular graph, as shown in Figure 18.

Conclusions
In this research, we studied various IMD-related security and privacy requirements, such as confidentiality, integrity, availability, mutual authentication, non-traceability, user anonymity, session-key agreement, forward and backward secrecy, known attack resistance, device-existence privacy, device-type privacy, specific-device ID privacy, measurement and log privacy, and bearer privacy. Furthermore, we examined some of the well-known threats of IMDs: learning the existence of IMD, eavesdropping on the wireless channel that links the IMDs to the external devices, replay attacks by forwarding exchanged messages at a later time, changing critical settings of the implants by producing new commands, and exhausting the battery life of IMDs to execute denial of service attacks. After studying various IMD-related security and privacy concepts, we have used a formal approach to test the strength of seven contemporary authentication schemes designed to thwart attacks surrounding IMD-enabled systems. Consequently, we formally analyzed these authentication schemes using AVISPA and BAN logic, and compared them against their security strength, computational and communication overheads, and other features. The result analysis indicates that Khan et al. is the lightest and fastest while preserving privacy and satisfying the security properties shown in Table 3. The protocol uses only a cryptographic hash function and a bitwise XOR function, which made its computational and communication overheads lighter. Furthermore, the protocol is adaptable with minimal effort for the already implanted devices and no trouble for the yet-to-be

Conclusions
In this research, we studied various IMD-related security and privacy requirements, such as confidentiality, integrity, availability, mutual authentication, non-traceability, user anonymity, session-key agreement, forward and backward secrecy, known attack resistance, device-existence privacy, device-type privacy, specific-device ID privacy, measurement and log privacy, and bearer privacy. Furthermore, we examined some of the well-known threats of IMDs: learning the existence of IMD, eavesdropping on the wireless channel that links the IMDs to the external devices, replay attacks by forwarding exchanged messages at a later time, changing critical settings of the implants by producing new commands, and exhausting the battery life of IMDs to execute denial of service attacks. After studying various IMD-related security and privacy concepts, we have used a formal approach to test the strength of seven contemporary authentication schemes designed to thwart attacks surrounding IMD-enabled systems. Consequently, we formally analyzed these authentication schemes using AVISPA and BAN logic, and compared them against their security strength, computational and communication overheads, and other features. The result analysis indicates that Khan et al. is the lightest and fastest while preserving privacy and satisfying the security properties shown in Table 3. The protocol uses only a cryptographic hash function and a bitwise XOR function, which made its computational and communication overheads lighter. Furthermore, the protocol is adaptable with minimal effort for the already implanted devices and no trouble for the yet-to-be

Conclusions
In this research, we studied various IMD-related security and privacy requirements, such as confidentiality, integrity, availability, mutual authentication, non-traceability, user anonymity, session-key agreement, forward and backward secrecy, known attack resistance, device-existence privacy, device-type privacy, specific-device ID privacy, measurement and log privacy, and bearer privacy. Furthermore, we examined some of the well-known threats of IMDs: learning the existence of IMD, eavesdropping on the wireless channel that links the IMDs to the external devices, replay attacks by forwarding exchanged messages at a later time, changing critical settings of the implants by producing new commands, and exhausting the battery life of IMDs to execute denial of service attacks. After studying various IMD-related security and privacy concepts, we have used a formal approach to test the strength of seven contemporary authentication schemes designed to thwart attacks surrounding IMD-enabled systems. Consequently, we formally analyzed these authentication schemes using AVISPA and BAN logic, and compared them against their security strength, computational and communication overheads, and other features. The result analysis indicates that Khan et al. is the lightest and fastest while preserving privacy and satisfying the security properties shown in Table 3. The protocol uses only a cryptographic hash function and a bitwise XOR function, which made its computational and communication overheads lighter. Furthermore, the protocol is adaptable with minimal effort for the already implanted devices and no trouble for the yet-to-be implanted devices. Another important lesson taken from the analysis of the protocols is the necessity of formal security verification before IMD protocols are released for public use. In addition, IMD authentication schemes need to satisfy essential functionalities such as portability and emergency authentication while remaining lightweight. Accordingly, there is an interest to design a new security protocol for IMD-enabled insulin pumps in the future, which will serve as an artificial pancreas for patients in need. While designing such protocols, the authors would like to apply the essential lessons learned during this study. The newly designed protocol should be formally analyzed while satisfying the emergency authentication, adaptability, key update mechanisms, and anonymity requirements. The authors would also put forth an effort to balance these requirements with efficient communication and computational overhead and good attack resistance.