After two recent security attacks against implantable medical devices (IMDs) have been reported, the privacy and security risks of IMDs have been widely recognized in the medical device market and research community, since the malfunctioning of IMDs might endanger the patient’s life. During the last few years, a lot of researches have been carried out to address the security-related issues of IMDs, including privacy, safety, and accessibility issues. A physician accesses IMD through an external device called a programmer, for diagnosis and treatment. Hence, cryptographic key management between IMD and programmer is important to enforce a strict access control. In this paper, a new security architecture for the security of IMDs is proposed, based on a 3-Tier security model, where the programmer interacts with a Hospital Authentication Server, to get permissions to access IMDs. The proposed security architecture greatly simplifies the key management between IMDs and programmers. Also proposed is a security mechanism to guarantee the authenticity of the patient data collected from IMD and the nonrepudiation of the physician’s treatment based on it. The proposed architecture and mechanism are analyzed and compared with several previous works, in terms of security and performance.
Implantable medical devices (IMDs), such as implantable cardiac defibrillators, insulin pumps, and neurostimuli, monitor chronic disorder within the body and perform life-critical functions to treat cardiac arrhythmia, diabetes, and Parkinson’s disease. For instance, implantable cardioverter defibrillators sensing cardiac events can store measurements such as electrocardiograms and administer an electrical shock to restore a normal heart rhythm, when a rapid heartbeat is sensed. Healthcare practitioners can extract data from IMD or modify its settings wirelessly, using an external device called a “programmer.” Modern IMDs also support delivery of telemetry, for remote monitoring over long-range, high-bandwidth wireless links, so that chronic patients can be continuously monitored at home or work, without visiting a hospital [
Recently, the privacy and security risks of IMDs have been widely recognized in the medical device market and research community [
During the last few years, a lot of researches have been carried out addressing the privacy and security issues of IMD. Most of them have concentrated on the authenticated key establishment problems for setting up a secure channel between IMD and programmer. Even though security mechanisms [
In this paper, a new security architecture for the security of IMDs is proposed, based on a 3-Tier security model, where the programmer interacts with a Hospital Authentication Server (HAS) to get permissions to access IMDs. Regardless of the type of cryptography for the authenticated key establishment, it is assumed in the research carried out so far that there is a single programmer to take care of several IMDs and that the keying material of each IMD is stored in the programmer. However, there are many IMDs and programmers, where any IMD should be able to be accessed from any programmer. In this case, there are two problems, in terms of security and scalability. The keying material of each IMD should be preinstalled into each programmer, so that the scalability problem occurs. Furthermore, if one of the programmers falls into an adversary’s hands and the keying materials of IMDs are exposed, the patient’s privacy can be compromised by eavesdropping, and the patient’s health might even be endangered, by allowing an unauthorized access to IMDs. To address these problems, HAS is introduced, which plays the role of distributing access keys to IMD, according to the physician’s privilege. Instead of installing the keying materials of IMDs into several programmers, HAS both maintains the access keys to several IMDs and distributes them to each authorized physician, via the programmer.
A security mechanism is also proposed in this paper to guarantee the authenticity of the patient data collected from IMD and the nonrepudiation of the physician’s treatment based on it. An authorized physician usually modifies IMD’s settings according to the patient data read out from the patient’s IMD, for the purpose of increasing the efficacy of the treatment. However, if the physician’s treatment associated with IMD is not correct or appropriate, a medical accident might occur. It could be due to a medical malpractice or a medical error. In order to clearly resolve the medical dispute, a record of the physician’s treatments based on the observed patient data will be valuable corroborated facts. Hence, the treatment record should be securely maintained, with nonrepudiation. Regarding this issue, another security mechanism is introduced to ensure that the patient data extracted from its IMD is not modified by the physician illegally, and a record of the physician’s treatments based on the patient data cannot be modified, either, even by HAS.
After an introduction of the current commercial IMDs, together with their usage for pervasive patient monitoring in Section
IMDs are capable of measuring and altering the physiological characteristics of a patient. IMDs receive commands from an external device (programmer) that enable the adjustment of settings on the implanted device. They can also send information on their current status (as well as sensed data) to an external device. Modern IMDs contain the high-capacity lithium batteries that last five to seven years and the ultralow-power microprocessor with about 128 Kbytes of RAM for telemetry storage. Radio frequency (RF) telemetry, which operates within the Medical Implant Communications Service (MICS) Band, is used for wireless communication between IMD and programmer in the hospital or clinic. Using the MICS Band prevents interference with home electronics such as microwaves, cell phones, and baby monitors. The MICS Band (402 to 405 MHz) allows for 250 Kbps and read range of up to 5 meters.
To open a wireless communication channel between IMD and programmer, a magnet switch inside IMD should be activated by RF command. Then, the programmer searches for activated IMDs within telemetry range, by sending an
(a) Generic patient session protocol and (b) remote monitoring service for IMD patients.
On the other hand, IMD manufacturers, such as Medtronics [
Since current commercial IMDs and programmers do not employ any security mechanisms for access control and transmission protection, a lot of research papers have been recently proposed to address the security issues associated with IMDs and programmers. Most of them are based on the secret information (e.g., password, secret key) preshared between IMDs and programmers, much like in other network security environments. Basically, the IMD security can be approached through access control at the programmer level. Only authorized personnel can access the programmer capable of communicating with IMD. However, if an adversary possesses his own programmer, this approach cannot be effective. The study in [
Personal devices, such as
Some research efforts [
Since patient data should be available only to the authorized personnel, strict access control to IMD is indispensable, and the wireless link between IMD and programmer should be cryptographically protected. In particular, due to the wireless reprogramming capability, an adversary could conceivably cause direct physical harm to a patient, by sending commands to modify the treatment parameters of IMD. First, the wireless link should be protected, for both confidentiality and authenticity of the patient data. Second, the
Figure
(a) 2-Tier security model and (b) 3-Tier security model.
First, the security mechanism proposed here is based on the 3-Tier security model in Figure
Prior to implanting IMD, it is initialized, by installing security-related information. As in Figure
IMD initialization.
During the IMD initialization phase, a list of primary care physicians,
In order to initiate a new patient session through a programmer, the physician first personalizes the programmer, by inserting his/her smartcard containing both the long-term key
The READ session consisting of the four commands is for the personalized programmer, namely, physician, to read out the patient data stored in the target IMD. The
(Step-①②) The personalized programmer first computes the session key
(Step-③④) When receiving the
The WRITE session also consists of the four commands whose purpose is for the patient treatment, by adjusting the running parameters of IMD. In order for the personalized programmer to obtain permission for the write operation to IMD, the Write-Key is provided to the personalized programmer by HAS. In particular, since the physician’s treatment,
(Step-
We consider two types of adversaries with polynomially bounded computational power: an outside adversary and an inside adversary as in Figure
As mentioned in Section
When designing a cryptographic protocol such as the one in Figure
Proposed protocol for secure patient session.
Threat model and preestablished security associations.
There are three principals (programmer, IMD, and HAS) in the protocol proposed in Figure
In this section, the correctness of the proposed cryptographic protocol is formally validated, based on BAN logic. The notations and five inference rules of the BAN logic are shown in Figure
Notations and inference rules of BAN logic.
We verify the correctness of the proposed protocols, the READ session and WRITE session, of Figure
Formal verification for correctness of the proposed protocol.
All the commands between IMD and personalized programmer are secured using the Read-Key,
The
The HAS maintains a list of primary care physicians
A reason to include
The current programmer stores the patient data in plaintext form retrieved from IMD into its internal or external memory. Since the patient data is not protected at all, as long as it remains in the programmer, there is a possibility that it can be modified intentionally or accidentally, before it is sent to HAS. Even though the physician is authorized to retrieve the patient data, its origin and integrity should be guaranteed, so that even the physician cannot modify it. Hence, the patient data is accompanied by the origin-check value
After examining the patient data,
Suppose the physician is an inside adversary. Then, the following two security attacks can be imagined: the first is to generate an abnormal treatment, given the correct patient data. The second is to modify the patient data and generate a normal treatment corresponding to the modified patient data. In the first case, if a medical accident occurs, the liability of the physician is proven, due to the physician’s signature. In the second case, it is not possible to modify the patient data arbitrarily by the physician, since it is protected with
In emergency situations, where an unconscious patient with IMD should be taken care of in either an unfamiliar emergency room of a different hospital or an emergency vehicle, IMD should first be disabled for emergency care. However, the emergency medical staff would not have access to IMD, if the access key is not available. Several methods [
In this section, various security features of the proposed protocol are compared with those in [
Security comparisons.
[ |
[ |
[ |
[ |
Proposed | |
---|---|---|---|---|---|
Security model | 2-Tier | 2-Tier | 2-Tier | 3-Tier w/PD | 3-Tier w/HAS |
Cryptographic method for authentication | Password | CR with |
CR with |
CR with |
CR with |
Authentication type | Unilateral | Unilateral | Mutual | Unilateral | Mutual |
SK generation | None | None | Diffie- |
PD |
HAS |
Key management | N/A | IMD-specific key from MK | N/A | PD maintains multiple PKs | RK and WK from LK |
Multiple programmers | N/A | Insecure |
Secure |
Insecure |
Secure |
Patient data |
N/A | N/A | N/A | N/A | Secure |
Treatment protection | N/A | N/A | N/A | N/A | Possible with |
CR: challenge-response; PD: personal device; MK: master key; SK: session key; LK: long-term key; PK: public key; RK: Read-Key; WK: Write-Key.
Except [
The key management scheme is employed in the proposed one and in [
In the case that a programmer is stolen by an adversary, the security of IMD can be endangered. Since the master key and private key of the programmer are stored in the programmer in [
The proposed protocol in Figure
Since each of [
Performance comparisons.
2009 | [ |
[ |
Proposed w/HAS | |||||
---|---|---|---|---|---|---|---|---|
IMD | Prog. | IMD | PD | Prog. | IMD | Prog. | HAS | |
Authentication/integrity | 1 mac |
1 mac |
1 enc |
1 enc |
2 enc/1 dec |
2 mac | 4 mac | 2 mac |
SK generation/distribution | 1 DH w/RBE | 1 DH w/RBE | 1 dec | 1 Penc |
1 Pdec | 1 kdf | 1 dec | 1 kdf |
No. msg | 4 · |
IMP-PD: 1/PD-Prog.: 3 |
IMD-Prog.: 2/Prog.-HAS: 2 | |||||
Patient data protection | N/A | N/A | 1 enc |
1 enc |
1 hash | |||
Treatment protection | N/A | N/A | N/A | 1 sig | 1 ver |
PD: personal device; Prog.: programmer; No. msg: number of messages exchanged; mac: MAC function; UniL: unilateral authentication; RBE: rapid bit exchange; DH: Diffie-Hellman; hash: hash function; Penc: public-key encryption; Pdec: public-key decryption; enc: symmetric encryption; dec: symmetric decryption; kdf: key derivation function; sig: signature generation; ver: signature verification.
In order to generate a session key,
The proposed one and that in [
In the proposed one, there are two distinct sessions, the READ and WRITE sessions, for a patient session. Since they are identical in terms of computational complexity, only the READ session is considered for equivalent comparisons with [
Recently, the privacy and security issues of IMDs have been widely recognized in the medical device market and research community, and a lot of researches have been carried out to address the privacy and security issues of IMDs. Most of them have concentrated on the authenticated key establishment between the IMD and programmer, as well as solving the tension between the security and the safety of IMDs in emergency situations. By introducing a new security architecture in this paper, we have addressed three security-related issues associated with the IMDs: support for multiple programmers, prevention of patient data falsification, and the physician’s treatment protection. In particular, by introducing HAS, multiple programmers can be supported for the IMDs, without embedding the keying materials inside the programmers. Furthermore, even the physician cannot modify the patient data arbitrarily, and the physician’s treatment history based on the observed patient data can be monitored securely.
IMD’s device identification number
Physician’s identification number
Patient information such as patient name, date-of-birth, and gender
The
Patient data collected from IMD during the
Physician’s treatment to change parameters of IMD during the
Message authentication code computed over all preceding fields of a command using symmetric key
Encryption of
Key derivation function
One-way hash function
A long-term key shared between IMD and HAS
Physician’s public key and private key for signature
A long-term key shared between physician and HAS
Read-Key and Write-Key for the
Session key derived from
Signature computed over all preceding fields of a command using the physician’s private key.
The author declares that there is no conflict of interests regarding the publication of this paper.
This research was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education, Science and Technology (NRF-2012R1A1A2000677). This research was also supported by the MSIP (Ministry of Science, ICT and Future Planning), Republic of Korea, under the CPRC (Communications Policy Research Center) Support Program supervised by the KCA (Korea Communications Agency) (KCA-2013-003) and under the “Employment Contract based Master’s Degree Program for Information Security” supervised by the KISA (Korea Internet Security Agency)(H2101-14-1001).