Pacemaker systems are “system-of-systems”. Looking at all four manufacturers, there are essentially four components to modern pacemaker system deployments: the pacemaker devices, pacemaker programmers, home monitoring systems, and the supporting/update infrastructure. All components are vital to the safe functioning of the pacemaker system. The figure below shows how these components interact with each other.





Pacemaker System Ecosystem

), keeping devices fully patched and updated continues to be a challenge. Despite efforts from the FDA to streamline routine cybersecurity updates, all programmers we examined had outdated software with known vulnerabilities. Across the 4 programmers built by 4 different vendors, we discovered over 8,000 vulnerabilities associated with outdated libraries and software in pacemaker programmers. As seen in other medical device verticals ( https://ics-cert.us-cert.gov/advisories/ICSMA-16-089-01 ), keeping devices fully patched and updated continues to be a challenge. Despite efforts from the FDA to streamline routine cybersecurity updates, all programmers we examined had outdated software with known vulnerabilities. Across the 4 programmers built by 4 different vendors, we discovered over 8,000 vulnerabilities associated with outdated libraries and software in pacemaker programmers.





Outdated Third Party Components





We believe that this statistic shows that the pacemaker ecosystem has some serious challenges when it comes to keeping systems up-to-date. No one vendor really stood out as having a better/worse update story when compared to their competitors. In two instances, we were able to confirm that patient data was stored unencrypted on the programmer. In one instance, we discovered actual unencrypted patient data (SSNs, names, phone numbers, medical data…etc) on a pacemaker programmer. The patient data belonged to a well-known hospital on the east coast and has been reported to the appropriate agency. These types of issues highlight the need for strong device disposal policies from hospitals.





How do Pacemaker Programmers Work?

Of all the components in pacemaker systems, pacemaker programmers provide the most insight into how pacemaker systems actually work. In total, we examined seven different pacemaker programmers from four different manufacturers. Six pacemaker programmer utilized unencrypted IDE hard drives. One pacemaker programmer utilized an unencrypted PCMICA flash drive. We saw a variety of operating systems such as the familiar Windows XP, Real Time Operating Systems (RTOS) like MonteVista, old operating systems like DOS, we even encountered one programmer using OS2!





All of the programmers we examined booted directly into the programming software without first requiring any type of login or password. Pacemaker programmers do not authenticate to pacemaker devices. Any pacemaker programmer can program any pacemaker from that specific vendor. This is true for all programmers we examined. Proximity is the primary criteria for pacemaker programming. This is an area where is appears that patient care has influenced the cybersecurity posture of the pacemaker programmer. While older pacemaker programmers only utilize a close proximity “telemetry wand”, newer programmers from all vendors utilize longer range RF communications in addition to the close proximity telemetry wand. Our research focused on programmers that supported the use RF communications. By intended design, all the pacemaker programmers we examined first required the use of a telemetry wand in order to communicate with the pacemaker. This is the intended design; situations where devices can communicate with a pacemaker without first requiring a telemetry wand is more complicated and will be addressed in a later post. In all implementations we observed, the telemetry wand would retrieve a token from the pacemaker device itself. In some cases, the token is the device serial number/ID. In one case, the token value retrieved from the pacemaker device was a static AES key. This token value is then used to derive a session value/key and communications is passed from the telemetry wand to longer range, higher bandwidth radio signal. The method/algorithms used to derive the session token/key values is different amongst different manufacturers.





These session token generation algorithms are stored within the programmer logic and software. Once a proper session is established, the programmer can perform a variety of functions over radio, including the alteration of therapy. This is by-design and is the case for all pacemaker programmers we examined. Obviously, compromise of a pacemaker programmer is a serious matter. The by-design capabilities of pacemaker programmers is significant and compromise of a pacemaker programmer would result in situations where alteration of therapy is possible.





The software implementation of pacemaker programmers shows an area where cross-pollination between vendors has likely already occurred. All of the modern programmers we examined use a core application to initialize the programmer hardware and interfaces. Communications to pacemakers is done through “apps”. Each pacemaker device model has its own app on the programmer. The app contains the specific commands supported by that specific pacemaker. The pacemaker app also contains the telemetry structure used to retrieve data, program, and reprogram the pacemaker device. Most of the implementations we observed allowed programmers to both update pacemaker therapy settings and pacemaker firmware. We did not observe any cryptographically signed pacemaker firmware. Given pacemaker firmware are not cryptographically signed, it would be possible update the pacemaker device with a custom firmware. Once interaction with a pacemaker is complete, the pacemaker app passes control back to the main application and the main application will await an another inductive telemetry wand action.





Steps for RF Programming

(1) Pacemaker programmer system starts the main application (no password required)

(2) A close proximity telemetry wand is used to interrogate a pacemaker

(3) The pacemaker device provides a token and identifying information

(4) The pacemaker token and identifying data is received by the main application

(5) The main application launches the pacemaker app for the identified pacemaker

(6) The pacemaker programmer switches to RF communications



