Protecting Data: BLE Security for Smart Healthcare Devices

Bluetooth Low Energy (BLE) technology is the backbone of modern medical devices. It's making our healthcare gadgets smaller, smarter, and more connected than ever. But here's an important question: How do we protect all that sensitive patient data?

Let's explore the world of BLE security in healthcare. We'll examine the challenges, uncover solutions, and highlight the best practices shaping the future of connected care.

The Rise of Smart Healthcare Devices

Imagine a world where your watch seamlessly monitors your heart rate, tracks your blood pressure, and analyzes your sleep patterns. It's not the future, but today's reality, thanks to ensuringe IoT.

But what exactly is IoT in healthcare, and how is it changing how we approach medical care? Let’s take a closer look.

It's a seamless ecosystem of smart medical technologies that collect, analyze, and share data in real-time. Devices like Continuous Glucose Monitors (CGMs), Smart Inhalers, and Wireless Blood Pressure Monitors are now essential tools for collecting and transmitting real-time data to improve care. The result? More personalized and proactive patient care that's improving health management.

According to a study, the global Internet of Things market in healthcare is expected to reach USD 169.99 billion by 2030 and grow at a 21.2% CAGR from 2023 to 2030. That's significant growth!

BLE: A Critical Component of IoT in Healthcare

How does BLE technology translate to better healthcare? Let's consider a few scenarios:

Imagine a small, comfortable wearable device that can monitor your vitals 24/7 without needing a charge for months. That's the advantage of BLE's low energy consumption.

Or consider a hospital where doctors can monitor patients in real-time across different wings or even in-home care settings. That's BLE's extended range and fast connections at work.

Here’s why BLE is the go-to technology for medical devices:

1. Low Power Consumption: Devices can run for months, even years, on a single battery charge.
2. Cost-Effectiveness: Affordable implementation means more accessible healthcare tech for everyone.
3. Extended Range: Reliable connectivity across hospital rooms or entire floors.
4. Fast Connections: Quick data transmission for real-time monitoring.
5. Scalability: Support for multiple device connections.
6. Interoperability: Works seamlessly with various smartphone and tablet platforms.
7. Data Transfer: Efficient for sending small packets of data.
8. Security Features: Includes encryption and authentication protocols to protect sensitive information.
9. Remote Control and Automation: Healthcare providers can adjust settings or trigger actions from a distance.
10. Location Services: Supports indoor positioning, useful for asset tracking in hospitals.

‍

Challenges and Risks of BLE in Healthcare

As we connect more devices to our networks, we also increase potential security risks. Let's examine some key concerns:

1. Data Breaches: Unsecured BLE connections could lead to unauthorized access to sensitive health information.
2. Device Hijacking: Hackers could potentially take control of medical devices.
3. Denial of Service (DoS) Attacks: Bad actors could overwhelm BLE networks, disrupting critical healthcare operations.
4. Man-in-the-Middle Attacks: Intercepting and altering data transmitted between devices could compromise patient care.
5. Malware Infections: One compromised device could spread malware to others on the network.

‍

We also need to consider regulatory compliance. Manufacturers must meet stringent security and privacy standards set by organizations like HIPAA and GDPR.

The intricate balance between security, device functionality, and patient comfort in implantable medical devices is a critical concern. As noted in the article "Security and Privacy for Implantable Medical Devices," the issue of medical device security is evolving, with devices increasingly interconnected and interoperable, creating new challenges in their design.

Solving Our Client’s BLE Security Challenges with the Cortex-M33 Platform

For our client, a manufacturer of molecular analysis devices that detect pathogens in biological samples, ensuring maximum automation and security in their devices is critical. Therefore, one of our key tasks was to develop a solution for automatically discovering and pairing devices via BLE in the most secure way possible. 

In light of this, we explored several security options based on the Cortex-M33 platform, each of which we discuss below. 

BLE Security: Core Mechanisms and Applications

Let’s take a look at some applications of these methods.

Pairing and Bonding

There are different pairing methods in BLE depending on the Input/Output (I/O) capabilities of the devices involved, and each method has different levels of protection against MITM attacks:

• Just Works: No authentication or input is required from the user. This method is used when neither device has a display or input capability (e.g., a BLE beacon).
• Passkey Entry: One device displays a 6-digit passkey, and the user enters it on the other device.
• Numeric Comparison: Both devices display a 6-digit number, and the user confirms if the numbers match on both devices.
• Out-of-Band: BLE also supports Out-of-Band (OOB) pairing, where the pairing information (the Temporary Key) is exchanged through a different communication channel (like NFC). This can be used to securely exchange the keys, providing a strong level of security since the key exchange happens over a trusted medium.

Encryption

Bluetooth 4.2 improves BLE security by implementing stronger encryption and key exchange mechanisms using:

• ECDH: Devices generate a shared secret through public and private keys using ECDH, which is resistant to eavesdropping and MITM attacks
• MITM: The Numeric Comparison or Passkey Entry method can be used to ensure protection against MITM attacks, as both devices confirm the shared secret
• AES-CCM: asymmetric encryption algorithm is used for encrypting the data exchanged between devices
• LTK: The devices use the long-term key generated during pairing to establish encrypted communication for future connections 

Authentication

• BLE implements privacy features to prevent device tracking based on its address as well as mechanisms to ensure data integrity and verify the authenticity of the sender:
• IRK: BLE devices can use random private addresses instead of a static MAC address. The IRK allows authorized devices to resolve the random address back to a known device identity.
• MIC: Each data packet includes a MIC, which ensures that the data has not been tampered with during transmission.
• CSRK Data Signing: For certain types of communication, BLE can use Connection Signature Resolving Keys (CSRK) to sign data, ensuring that the data comes from a trusted source.

Automating BLE Security: Solutions for User-Free Pairing

As can be seen from the Pairing and Bonding section above most of such mechanisms involve an interaction with the user. But what can we do in case when we intend to implement secured BLE communication without having user interaction opportunity, for instance, in our embedded device to be able to be automatically paired, bonded and secured for BLE communication with it?

Here’s how we can achieve this in an embedded system:

Out-of-Band (OOB) Pairing

• Allows two devices to exchange pairing information through a different communication channel such as NFC, QR code, or a secure wired interface. This eliminates the need for user interaction during pairing and adds a layer of security since the key exchange happens over a trusted medium.

Approach:

• If a device has NFC capabilities, we can use this channel to exchange the Temporary Key (TK) between devices. The TK is then used during the BLE pairing process to establish a secure connection.
• If no OOB medium is available, we could embed a static OOB key into both devices during manufacturing. This static key could be securely stored in a microcontroller and used to initiate pairing when the devices come within range.

 Implementation:

1. Enable OOB pairing: in the BLE stack of the embedded device.
2. Exchange TK via OOB: When the devices first communicate, use the OOB channel (NFC, for example) to exchange a secure key (TK)
3. Pairing: Use the shared TK to authenticate and establish an encrypted BLE connection.
4. Bonding: After pairing, devices can store the Long-Term Key (LTK) for future secure connections without repeating the pairing process. 

Pre-Shared Keys (PSK) or Pre-Provisioned Keys

We can pre-program a Pre-Shared Key (PSK)  into both devices during the manufacturing process.  PSK is a shared secret used in cryptographic communication, where both parties involved in the communication agree on the key beforehand. BLE devices will then use this key to authenticate each other when establishing a connection.

Approach:

• During production, program a unique PSK or shared key into each device. Store it securely in non-volatile memory, such as flash or an encrypted section of the microcontroller.
• When the devices attempt to pair, they use this key to generate a shared secret.

Implementation:

1. Provision the PSK: Embed the same pre-shared key in both the central and peripheral devices during the production process.
2. Pairing: When the devices establish a BLE connection, they use the PSK to authenticate and establish encryption.
3. LE Secure Connections: The devices can further secure the connection with ECDH, which adds additional protection against eavesdropping. 

LE Secure Connections with Auto-Validated Numeric Comparison

In this method, we can use LE Secure Connections, a feature that provides enhanced security for data exchanges through the use of stronger encryption and improved key generation methods, ensuring secure pairing and communication between devices. With this method, we can skip the need for user interaction by "auto-validating" the numeric comparison during the pairing process.The devices are programmed in the way to assume that the comparison is valid if the devices are paired within a trusted environment.

Approach:

• Enable LE Secure Connections ECDH key exchange in the BLE stack of the embedded device.
• Instead of requiring the user to confirm the numeric comparison, the devices automatically validate the shared secret during pairing.

Implementation:

1. LE Secure Connections: Use LE Secure Connections for stronger encryption.
2. Auto-Validation: Modify the pairing process to automatically accept the numeric comparison instead of displaying the number to the user.
3. Bonding: Once paired, the devices bond and store the Long-Term Key (LTK) for future use.

Storing and Managing Pre-Provisioned Keys

There is also an essential part of an automated BLE secure connection setup related to storing pre-provisioned keys and managing it. Let’s consider the main approaches to deal with keys in a secure way for instance on Arm Cortex-M devices. Here are some strategies to securely store BLE pre-provisioned keys on an ARM Cortex-M devices: 

Secure Storage

• Secure Flash Memory: Some Cortex-M MCUs offer secure flash regions or specific memory protection units (MPUs) that can be used to store sensitive information, making it inaccessible to unauthorized code. We can configure this secure region to store the pre-provisioned keys.
• Flash Memory Encryption: Some Cortex-M devices have built-in hardware encryption for flash memory, meaning that data stored in the flash is automatically encrypted and decrypted by the hardware. This provides an extra layer of protection in case the flash memory is read out by an attacker. 

Trusted Execution Environment or Security Extensions

• TrustZone-M: TrustZone-M is a security technology developed by Arm for microcontrollers and embedded devices, based on the Armv8-M architecture. It is designed to provide a robust security foundation for resource-constrained environments, such as those found in Internet of Things (IoT) devices and embedded systems. TrustZone-Mprovides hardware-based isolation between secure and non-secure environments. This allows it to run security-critical code and store sensitive data in a secure environment, separate from the rest of the application. We can set up secure memory regions where sensitive data like pre-provisioned keys can be stored and processed. Non-secure parts of the system cannot access these secure regions.
• Store the pre-provisioned keys in the secure environment, and ensure that all sensitive cryptographic operations (such as pairing and encryption) are handled within this zone. Configure the device so that prevent non-secure code from reading or modifying the keys. 

Hardware Security Modules

Some ARM Cortex-M devices include secure cryptographic hardware or a secure key storage module:

• Nordic’s CryptoCell: which provides robust cryptographic functions and security services for embedded systems and IoT devices. It is designed to enhance the security of devices by handling sensitive operations in a secure and efficient manner.
• STMicroelectronics' STSAFE-A Secure Elements: which offers secure authentication capabilities to verify the identity of devices, users, and services in various applications, such as securing access to cloud services or enabling secure transactions.
• NXP’s Secure Key Storage: which ensures that cryptographic keys are stored, managed, and used securely, addressing various security challenges in connected environments.

Provision the keys into the HSM/Secure Storage securely store the pre-provisioned keys during manufacturing or device initialization:

• During manufacturing, keys are programmed into secure storage using a debug-disabled mode to prevent readout.
• Usage a secure provisioning tool to inject the pre-provisioned keys into the secure hardware module.

Provision the keys can be stored and managed with help of CryptoCell or similar cryptographic hardware:

• The pre-provisioned keys can be stored in CryptoCell's Key Storage area, which provides hardware isolation and encryption. Keys are typically loaded and stored in encrypted format, and CryptoCell manages the keys internally for secure operations.
• To use the pre-provisioned key for any cryptographic operation, request it from the CryptoCell, which will handle encryption, decryption, and key management internally without exposing the key to the firmware or software.

Conclusion

Bluetooth Low Energy (BLE) technology is driving the transformation of healthcare IoT, enabling medical devices to become smarter, more connected, and more patient-focused than ever.

Yet, the sensitive nature of healthcare data and its direct impact on patient safety make securing BLE devices a critical priority. The right approach depends on the device’s capabilities and use case. For embedded BLE devices requiring secure communication without user interaction, these strategies are key:

• Out-of-Band (OOB) Pairing: Use external communication channels like NFC to establish secure connections without user input.
• Pre-Shared Keys (PSK) or Auto-Validated LE Secure Connections: Ensure secure communication in controlled environments with minimal complexity.
• Secure Storage and Cryptographic Solutions: Protect keys using ARM Cortex-M tools like Cryptocell and TrustZone. Provision keys securely during manufacturing, prevent exposure to application code, and implement regular key rotation and erasure.

We implemented Custom LE Secure Connections with Auto-Validated Numeric Comparison, leveraging ARM Cryptocell and TrustZone to create a robust, secure, and automated pairing mechanism tailored for healthcare IoT.

Ready to shape the future of connected healthcare? Let’s get started.‍