Medical IoT needs to pay attention to the security of wireless connections

The Internet of Things (IoT) has brought new applications to connected devices. Manufacturers are moving beyond headsets and keyboards. One new use case in particular stands out: applications that rely less on continuous streams and instead relay small amounts of data periodically. This is especially true in sensor applications where remote peripherals are relaying information about their surroundings, such as thermostats, security sensors, or medical monitoring equipment. At the same time, advances in the Bluetooth standard are making these new applications possible.

A brief history of Bluetooth Classic and Bluetooth Low Energy

The original Bluetooth specification has been around since 1998, and the first hands-free headsets appeared on the market in 1999. Since then, it has been used to connect everything from computer mice and keyboards to portable speakers and headphones. The standard, now known as Bluetooth Classic, covers 79 channels and transmits speeds of up to 3Mb/s at a range of 50 meters, making it useful for data transfer, streaming audio, and sharing pictures with other smartphones, among other things.

While many devices that use Bluetooth Classic are battery-powered (at least the peripherals), power is never an issue — the components are designed to make it easy to charge and replace batteries. It doesn't matter if your computer mouse's battery has only lasted a few days, you can always plug in a charging cable or replace the battery.

A new standard, Bluetooth Low Energy (BLE), has since emerged to support lower bandwidth rates, ranging from 125 Kb/s to 2 Mb/s, and includes a new connectionless mode in addition to the connection-oriented mode of classic Bluetooth. The biggest advancement of BLE is that it saves power, powering devices for longer periods of time. By default, BLE peripherals sleep until they are ready to transmit data. Combined with lower power consumption during transmission at lower data rates, BLE devices typically consume only 1-5% of the power of devices using Bluetooth Classic. Their power consumption is between 15-20 microamps, which means that a standard button battery can power most BLE devices for many years.

Reshaping the Internet of Medical Things

Reasonable data rates coupled with low power consumption make BLE devices attractive for consumer applications such as headphones and thermostats, but that’s only part of the story. These same attributes also make BLE ideal for connecting medical devices – also known as the Internet of Medical Things (IoMT). For example, a blood glucose monitor can use BLE to transmit blood sugar levels to a smartphone for easy monitoring. In a hospital setting, inexpensive BLE tags attached to devices can make inventory tracking and location much easier. In addition, BLE’s support for a large number of connected peripherals makes it even more valuable in a clinical or hospital setting that may involve hundreds (or thousands) of connected medical devices. For example, think of a nurse’s monitoring station. With BLE, you can have ECGs and other patient monitoring devices on all floors relay telemetry information to a central location. The same idea applies to health-related wearables such as heart monitors and fitness watches – all of which relay information over BLE.

Eliminating cables, bulky batteries, and enabling smartphone communications is a big step forward. But as with any innovation, there are inevitable risks. In the case of medical devices, these risks go beyond inconveniences such as degraded audio quality or reduced battery life. For IoMT, device security risks directly jeopardize patient safety.

Cybersecurity in the Internet of Medical Things

For connected medical devices, cyberattacks are a huge threat to patient safety. For example, an attack on the BLE radio interface could interfere with the basic performance of an IoMT device - which could harm or potentially kill a patient. Multiple vulnerabilities like this have been discovered in Bluetooth-enabled medical devices, leading to widely publicized disclosures, mandatory mitigations, and device recalls. One of the most high-impact examples was the SweynTooth vulnerability, which affected a number of BLE IoMT devices. The impact was so severe that the FDA issued a safety communication to medical device manufacturers, warning of the dangers if one of the vulnerabilities is triggered - which could cause the device to crash, deadlock, and freeze, or even enable attackers to bypass its security safeguards.

The biggest lesson from SweynTooth (and other similar vulnerabilities) is that it made manufacturers aware of upstream vulnerabilities in the supply chain. Although the vulnerabilities were concerning, medical device manufacturers did not write the flawed code. In fact, they were unaware of their existence. They simply sourced Bluetooth System-on-Chip SoCs from trusted, well-known electronics companies and implemented them in their devices. The SoCs contained vulnerabilities and were not adequately tested for security before the products were shipped, which put every system they contained at risk.

Discover hidden vulnerabilities through protocol fuzz testing

The SweynTooth vulnerability affects multiple sophisticated manufacturers, including Texas Instruments, NXP, Cypress, Dialog Semiconductors, Microchip, STMicroelectronics, and Telink Semiconductor. How were so many different manufacturers affected? The problem is that these vulnerabilities are buried deep in the protocol stack, making detection and diagnosis incredibly difficult. While the security community has developed a range of best practices for discovering application-level vulnerabilities—including common strategies and databases of threat libraries that can be cross-checked with application software and libraries—protocol-level vulnerabilities are much harder to pinpoint. In fact, there’s only one way to adequately test for these kinds of vulnerabilities: an exhaustive testing regime known as protocol fuzzing.

In layman's terms, protocol fuzzing injects various errors into a communication exchange in order to confuse the entity at the other end of the connection and put it into an incorrect state. This can involve fairly simple errors, such as sending multiple copies of a packet, or can cause more complex protocol corruption. Here are some examples:

Flags indicating the start and end of a connection can be set in a single packet.

· Fields in the packet may be too large or too small.

Fields in a packet can be set to invalid values.

Packets can be sent out of order.

In many cases, the "handshake" that occurs at the beginning of a connection to establish security, encryption, and other communication parameters is an easy target for exploitation. Because the remote device configures itself based on the settings established during the handshake, a particularly corrupted packet (or sequence of packets) can cause a shutdown or communication error, requiring a manual reset.

In the worst case, an attacker could target the handshake itself, as described in CVE-2019-19194. Because the handshake establishes security and cryptographic parameters, an attacker could bypass controls that would normally restrict certain actions and enable arbitrary control of the system. For IoT devices in particular, this could have clearly catastrophic effects. An attacker could instruct a device to report incorrect telemetry data, ignore other commands, violate patient privacy rules by reporting data to unauthorized systems, or even administer potentially lethal doses of medication.

Protecting against protocol-level vulnerabilities in BLE-enabled IoMT devices

Clearly, this type of vulnerability is a serious concern for medical device manufacturers—as reflected by the FDA’s attention in the U.S. and similar regulatory scrutiny around the world. But what is the best way to protect connected devices? For starters, it means implementing a verification and validation strategy to identify vulnerabilities in the SoC protocol stack. Manufacturers need to act as the last line of defense. After all, they are responsible for quickly distributing warning communications, mitigation strategies, and remediation firmware updates for affected devices to patients and care providers. And, as the example above shows, even the best-resourced vendors are not immune to providing vulnerable chipsets.

However, security is a journey, not a destination. That’s why device manufacturers must at least insist on receiving remediation updates from chipset vendors before product release. At the same time, they must also undertake extensive protocol fuzzy assessments of their devices themselves — while also including their verification and validation strategies in FDA premarket clearance submissions.

As BLE connectivity for IoMT devices becomes more common, protocol fuzzing verification will become even more important to maintaining patient safety and trust in advanced technologies. Fortunately, fuzzing protocol toolkits are becoming more widely available and easier to use—even for quality control teams with little experience in cybersecurity. Given that it can take time for chipset vendors to thoroughly replicate, diagnose, fix, and verify vulnerabilities, now is the time to start testing products in development. One only needs to look at SweynTooth to see that the later a vulnerability is discovered, the more expensive it is to fix.