The Challenges of Implanted Cardiac Device Security: Lessons From Recent Compromises

G. Stuart Mendenhall


Europace. 2019;21(4):535-538. 

In This Article

Lessons Learned From Device Compromises

1. Inter-device communication will be examined and protocols 'sniffed', so strong encryption must be used for any communication of sensitive information over public or readily accessible channels.

For the device manufacturer, a major lesson is that the comforts of a relatively lax security through proprietary or obscure protocols is increasingly insufficient, with the latter termed 'security through obscurity'. As there are more internet-facing portals or consumer-accessible equipment, there will be more eyes and opportunity to pop the hood of devices, literally and figuratively, to explore protocols and attempt to decipher communication. This is particularly important with the next generation of implanted devices which may use consumer or non-proprietary protocols to allow patient access to medical data, where many other devices may easily listen into the communication.

It may seem that strong encryption should always be used in any medical device storing data; however, encryption can make debugging and troubleshooting difficult, may introduce new software bugs, break compatibility, hinder authorized or legitimate access, require updates and software patches, increase computational complexity and power requirements, and must be done without error to be effective. If not needed, encryption is not universally advised. As an analogy in the physical world, rapidly needed hospital supplies are typically not kept behind lock and key to prevent the inefficiencies of needless authentication and potential delays or denials of access. Areas of already restricted access may have less than strong encryption, such as a four digit keylock, but doors leading in from a public city street would have higher security restriction such as a keycard, user-specific combination, or both.

Devices given to the customer or with internet accessible front-ends are most similar to the public facing front door in the city, with the continuous potential and low barrier to attempted unauthorized access.

2. Any physical device that is released to the public could be examined and rooted.

As best practice, device manufacturers should assume that their products will be examined in detail if released, widely available, and technically possible. Thus communication devices like home monitors should never rely on simple common authentication factors, such as a common key, which, once compromised through examination of device memory or other means, negates security of the class of device.

Maintaining security of a device that can be examined is very difficult—as an example, Apple Computer, Inc. (Cupertino, CA, USA) has thousands of engineers working on their systems with security a major priority, and typically their devices are compromised within months of release, also termed 'jailbreaking'. A single error in implementation of a security protocol or access vulnerability can allow unchecked code to run, which allows opening or modification of the entire system. A chain is only as strong as its weakest link.

With assumption that protocols and key values will be known, standard computer security best practices can be implemented with strong encryption, non-reuse or absence of master keys, and proper seeding of random cryptographic values can ensure that compromise or system knowledge of a single unit does not lead to compromise of an entire family of devices. These types of security are used to maintain secure communication in other high security enterprises such as banking, and there is no technical barrier to implementation by all major device manufacturers.

3. Any device that has critical functions accessed over an internet-facing or publicly accessible interface must be able to be securely updated or patchable.

As software is not likely to be perfect when released, continuous and automated patching of home programmers should take place as vulnerabilities are found as condition of continued interaction with an implanted device, and detected rooted programmers taken offline or completely reinitialized with updates. Similar to other industries, the updates that are issued to a device can verify its non-compromised state and then update to the latest software. In the same fashion, compromised devices can be identified and taken off-line.

Additionally, device manufactures may increasingly choose to rely on well-established software technology specifications and suites such as Bluetooth LE (Low Energy) (Bluetooth Special Interest Group, Kirkland, WA, USA) for consumer or inter-device connectivity. These protocols generally are well-examined and compromises are discovered early in their life cycle. In the event that a vulnerability in the underlying protocol is uncovered the ability to patch device using the protocol, possibly without intervention required from the user, is again required.

4. Just as in the physical world, complex security systems often have to choose between increased security and the convenience of clear and facile programming, and ready user access of a device.

In the case of the Medtronic 2090 lack of code-signing, the security firms WhiteScope and QED Secure Solutions notified Medtronic, who was aware of the potential for code compromise, but Medtronic felt this was an acceptable risk after evaluation, which required a compromised network with imitation Medtronic servers. As an analogue, somebody could put on a white coat and copied name badge and access numerous somewhat restricted areas of the hospital, but even after notification of an event, putting up a strict badge-check and access control may not be worth overhead and restriction to legitimate users.

5. Aggressive counterattack of individuals or groups uncovering security vulnerabilities is unlikely to be optimal use of resources.

With the Muddy Waters incident, it is disappointing that potential compromise of device would be used as an attempted avenue for profit via securities trading and anticipated stock movement, and worrisome that St. Jude was not given forewarning of vulnerabilities. While alerting of manufacturers prior to the public would certainly be expected of reputable security firms, in this case the exact implementation details of the exploits were not made public, and no patients have been reported harmed by the potential compromise, and further detail publicly emerged as a result of defence of legal action brought by the manufacturer.

Curiosity and the intellectual challenge of examining and decrypting complex systems will provide continued motivation for all hackers, and the monetary gain from holding companies and patient well-being for ransom, and financial/securities manipulation will lure more malicious or self-serving operators. Aggressive counterattacks may encourage anonymous release of compromise information instead of directly approaching the company, due to fears of legal or criminal retaliation. Focus should remain on the swift remedy of the vulnerability and lessons provided from the exploit. Non-malicious, or 'white hat' hackers will generally share the information uncovered with the affected party and allow them to fix the findings, while true 'black hat' hackers may keep the exploits uncovered and use them for malicious purposes. In between, are 'grey hat' hackers, such as the Muddy Waters firm, who performed financial exploitation, without release of potentially lethal details of the compromise to the public.