Bluetooth is not a Commodity Part 2
On June 10th, limitedresults.com generated significant buzz by disclosing a security vulnerability in the Nordic nRF52 series of Bluetooth SoC (System-on-Chip) components that are at the heart of hundreds of millions of Bluetooth devices, including many connected medical devices.
As Sunrise Labs designs Bluetooth-enabled medical devices, including many with the nRF52 chipset, news of a security vulnerability resulted in an internal evaluation of the risk to our customers. Additionally, Sunrise reassessed the viability of the nRF52 series for future products. Sunrise’s risk management process pre-emptively minimized or eliminated the risks associated with this vulnerability and Sunrise continues to recommend the nRF52 series for future products with additional attention given to the vulnerability.
What is the vulnerability?
The security vulnerability is a simple form of lockout bypass using voltage fault injection. Basically, the chip has a lockout feature that prevents an unauthorized agent from reading the device memory; however, this lockout feature must read from the device memory on startup to determine whether it should enable the lockout. Interrupting this startup process by quickly removing voltage from the chip prevents the lockout feature from engaging, allowing the attacker to access the device memory, read out the memory contents, write new firmware to the device flash, and even permanently disable the lockout feature.
What does bypassing this lockout allow the attacker to do?
An attacker can read out the device memory, including the firmware in the flash memory, and also write new firmware to the device. This has two implications: business risk and safety risk. The business risk is the possibility of a third party reverse engineering the firmware to discover protected IP. The safety risk is the possibility of extracting encryption keys or inserting malware into the firmware that either allows eavesdropping on secured Bluetooth communications or alters the device’s behavior.
Can Nordic patch the device to fix it?
The lockout feature appears to be baked into the hardware, so Nordic may be able to update the hardware to eliminate the vulnerability in future devices. The hundreds of millions of devices already in the field can’t be patched to eliminate this vulnerability.
How serious is this, really?
Sunrise Labs was unsurprised to hear of this vulnerability because bypassing copy protections via voltage fault injection is an extremely common vulnerability that affects many, if not most, microcontrollers. Devices from many manufacturers and many processor families, including MSP430, 8051, AVR, PIC, MC68, 78K, and ARM, have similar vulnerabilities. Sunrise knows that this is a pervasive problem and addressed these risks in the product design even before the vulnerability was announced.
The business risk, the possibility of IP theft due to reverse engineering the firmware, is often of little concern in medical devices. For most medical devices, the critical IP relates to the therapeutic or diagnostic function, not the Bluetooth communications. Even when the same nRF52 is used for therapeutic or diagnostic data processing, the actual data storage and processing are rarely of critical importance and often could be as easily reverse-engineered through external means that don’t require decompilation of the device firmware. In cases where the data storage and algorithms require protection, Sunrise recommends moving the data up to a secure cloud server that performs the data processing remotely. This approach provides the most effective means to shield critical data and algorithms, at the expense of additional infrastructure required to move the data to the server. Alternately, cryptoprocessors may be used to keep the data storage and processing within the medical device; however, cryptoprocessors are also periodically hacked, so this is not necessarily a perfectly secure solution. Also, cryptoprocessors are not usually designed for general-purpose data processing, so cryptoprocessors may not provide the performance needed for many applications. Ultimately, there is a tradeoff between the effort that a third party must exert to extract and reverse engineer the firmware vs the effort it would take to recreate the functionality from scratch. Understanding that balance for a specific application is necessary to determine the level of protection required.
In the medical device industry, safety risk is paramount. This nRF52 vulnerability introduces the safety risks of tampering with the medical device to allow eavesdropping or man-in-the-middle attacks on secure communications or altering the device’s behavior.
Eavesdropping and man-in-the-middle attacks are well-known cybersecurity risks that Sunrise addresses in a cybersecurity hazard analysis for connected devices. Although the likelihood is low, the severity of such hazards can be high if sensitive patient information is communicated over the connection; therefore, Sunrise always designs communication protocols to limit the quantity of sensitive information transmitted and limit the frequency of these transmissions. In most devices, no sensitive patient information needs to be transmitted, only device identifiers are used to correlate the device to the patient record.
Altering the device behavior through this vulnerability sounds scary because the nRF52 chip could be reprogrammed to do anything, including outputting wrong information that may lead to errors in treatment, or even directly harming the patient in the case of a therapeutic device such as a neurostimulator. While the severity of those harms is great, the likelihood that this vulnerability will be used to cause those harms is minuscule. To take advantage of this vulnerability, the malicious party needs direct access to the internals of the patient’s medical device and, once access is gained, the malicious party must use precision soldering equipment to detach some components from the circuit board and attach wires to a set of test equipment used to inject the voltage fault. If the malicious party has such intimate access to the user’s device, then they could simply use similar precision soldering equipment to replace the nRF52 device with an alternate device that was pre-programmed to cause harm. This approach would use less test equipment and take less time than performing the voltage fault injection. These approaches to causing harm are unlikely because a malicious party with such intimate access to a user’s medical devices has many easier avenues to cause harm.
Will Sunrise Labs still use the nRF52?
Yes. This vulnerability has little effect on the overall risk profile of devices designed by Sunrise, so Sunrise Labs will continue to use the nRF52 series in designs where it is the most appropriate solution. Sunrise keeps abreast of the Bluetooth industry and works with different chipsets based on their applicability to the product needs. The nRF52 series includes some of the physically smallest, lowest power, and lowest cost options in the Bluetooth Low Energy space, making it a good candidate for miniature and low-cost devices. Additionally, the Nordic Bluetooth software stack is one of the best and most tested software stacks in this market space, reducing the development time and cost over many alternate solutions. If firmware security is a major concern for the product, Sunrise is likely to suggest an alternate part or, more likely, a separate application processor for the sensitive firmware; however, Sunrise does not expect that the other part will be immune to voltage fault injection attacks, simply that it adds another layer of work to the attack and may dissuade attackers.
Ultimately, the reason for FDA regulation of medical devices is that medical devices all create some risk of harm. A good medical device design team understands how to assess and mitigate these risks throughout the design process. Risk management is central to Sunrise Labs’ product development process, resulting in an excellent track record of designing medical devices that are durable, reliable, and secure.
Contact Sunrise Labs: Decades Experience in Product Development
If you’re concerned about the complexities of device security or seeking a partner with proven expertise in risk management for your product development, contact Sunrise Labs. Our team is dedicated to ensuring the durability, reliability, and security of medical devices, particularly those utilizing components like the nRF52 Bluetooth series. Reach out to us today and let’s design a secure future for your medical products.
Read the blog Vulnerabilities – SweynTooth is Just the Beginning, the intro to “Bluetooth is not a Commodity” Series
FAQ’s
1. What is the security vulnerability in Nordic’s nRF52 Bluetooth SoC?
An attacker can interrupt the startup process of the chip to bypass a security lockout feature. This allows them to read or write data from the device memory, including the firmware.
2. What are the risks of this vulnerability?
- Business risk: An attacker could steal intellectual property from the device firmware.
- Safety risk: An attacker could tamper with the device firmware to eavesdrop on communications, alter the device’s behavior, or even harm a patient (for medical devices).
3. Can this vulnerability be patched?
No, existing devices cannot be patched. Newer versions of the nRF52 may have improved security features.
4. How serious is this vulnerability, really?
The business risk is generally low for medical devices because the critical intellectual property is usually not in the Bluetooth communication firmware.
The safety risk is more serious, but attackers would need physical access to the device to exploit it. Sunrise Labs believes the likelihood of this happening is very low.
5. Will Sunrise Labs continue to use the nRF52 in their products?
Yes. The nRF52 is still a good choice for many devices due to its small size, low power consumption, and low cost. Sunrise Labs will use mitigation strategies to address the security vulnerability. These may include:
- Limiting the amount of sensitive information transmitted over Bluetooth.
- Using separate processors for critical firmware.
- Staying up-to-date on the latest security threats.
