Dave Singelée - COSIC Group, KU Leuven
Eduard Marin - COSIC Group, KU Leuven
NI Products Used
LabVIEW, USRP-2920 and USB-6351
Who Are We?
The Computer Security and Industrial Cryptography (COSIC) group is a team of researchers within the Department of Electrical Engineering at KU Leuven. We provide broad expertise in digital security and strive for innovative security solutions. More specifically, the research work of COSIC spans mathematical foundations for algorithms and protocols, as well as their efficient and secure implementations in hardware and software. COSIC adopts an integrated approach to problem solving, which has led to important successes, such as the selection of the Rijndael algorithm as the US Advanced Encryption Standard (AES), a worldwide standard today.
What Problem Do We Want to Solve?
Currently, most implanted medical devices (IMDs) such as pacemakers, insulin pumps, and neurostimulators include wireless capabilities that enable doctors to remotely monitor and reprogram the IMD through an external device. We would expect cryptography to be used to protect the wireless communication between the IMD and the device programmer. However, in practice, medical companies typically use proprietary (that is, non-standard) protocols and keep the protocol specifications secret to ensure “security” (security-through-obscurity).
This approach goes against the rules followed by the security community, in which security experts thoroughly review cryptographic solutions before use. The goal of our research project was to show that security-through-obscurity is a dangerous approach. Clearly, proprietary solutions can be broken through various reverse engineering techniques, which could result in breaching patient privacy, or even worse, fatalities.
Evaluating the security of these proprietary protocols is crucial to raise awareness of the importance of protecting information transmitted over the air by using cryptography. We must also protect a patient’s health and privacy by preventing unauthorized access to the medical devices.
By identifying common pitfalls in these protocols, we want to assess the process used by medical companies when designing lightweight and strong cryptographic solutions. In addition, we hope that our results are considered when designing future devices to ensure a safer experience for all patients requiring IMDs. We provided our results to the relevant companies whose devices we used prior to us publishing them, so the medical companies now know the steps they must take to ensure more effective security.
Reverse engineering the proprietary protocol implies discovering both:
(a) The format of the messages being sent over the air
(b) How these messages are exchanged between the devices.
This is challenging because medical device manufacturers do not share information about how their protocols work. We do, however, have some options to reverse engineer the proprietary protocol using various techniques. One possibility would be to physically open the devices and analyse their software. However, we followed a non-invasive, black-box approach, which consisted of providing some inputs to the devices and then inferring information about the protocol by looking at their outputs (that is, the produced messages).
Although our black-box process is labour intensive, it mimics the approach that a less skilled adversary would use to hack an IMD without prior knowledge about the system specifications. By following this approach, we want to investigate the feasibility of reverse engineering the protocol by a weak attacker who can wirelessly intercept the messages sent over the air between the devices, but cannot physically access the devices.
Empowering Our Research
Before beginning our research, we evaluated several combinations of wireless transceivers and software development tools. One option was to use a USRP (Universal Software Radio Peripheral) device combined with GNU Radio, an open-source software tool that focuses on signal processing and software defined radio applications. However, LabVIEW has several advantages over GNU Radio.
Firstly, LabVIEW delivers a fast and intuitive graphical programming paradigm, as well as hundreds of prebuilt code modules that can immediately implement common engineering functions. This allows users to create complex programs by using only a few functional blocks. Secondly, LabVIEW provides seamless hardware integration using pre-programmed APIs and drivers. Thirdly, thanks to the user forums on ni.com and the huge LabVIEW developer community, we can also access support and solve questions quickly and easily. Although the functionality of the code is intricate, thanks to the power of dataflow in LabVIEW the implementation of the code makes it look simple.
In our experiments, we used LabVIEW combined with NI hardware, the USRP-2920 and the USB-6351, respectively, to capture and transmit signals sent by the IMD and device programmer at different frequency ranges.
We took advantage of the ample flexibility of the USRP-2920, including its high-speed A/D and D/A converters, frequency range, and signal bandwidth. In addition, we used the USB-6351 with its high-speed, high-resolution multifunctional capabilities to perform the necessary data acquisition with ease. Furthermore, we installed software add-ons such as the Modulation Toolkit, which facilitated the modulation and demodulation of the data, as well as processing signals and plotting them across the frequency and time domains. This toolkit meant we could test the communication system and thoroughly validate our results.
We aimed to emphasise the importance of wireless security in medical devices. Using the NI platform, we successfully reverse engineered the proprietary protocols of different IMDs from major medical equipment manufacturers, thereby demonstrating that security-by-obscurity is a dangerous approach that often conceals negligent designs.
We have shown that, using a simple black-box approach to reverse engineer proprietary protocols, malicious hackers could eavesdrop the IMD channels to learn sensitive patient information. Worse still, they could send commands to the IMD to cause it to drain its batteries, and modify or disable a therapy. No physical access is required to pull off these attacks, and the consequences could prove fatal for the patient.
We hope that the results that we provided to the medical companies emphasise the need to improve the security mechanisms of their IMDs through the inclusion of strong cryptography and standard symmetric key authentication, and accelerate the process by which this is done.
COSIC Group, KU Leuven
Kasteelpark Arenberg 10 - bus 2452