Protecting Data: BLE Security for Smart Healthcare Devices

Bluetooth Low Energy (BLE) is a low-power wireless protocol that lets a battery-powered medical device transmit patient data for months on a single charge. Securing a healthcare BLE link comes down to how the devices prove identity when they pair, and where the keys they generate are stored. This article covers both, then shows how we built automated secure pairing for a client's molecular analysis device on ARM Cortex-M33.

Which Medical Devices Use BLE?

BLE powers the wearable and at-home monitors that stream readings to a phone or hub: continuous glucose monitors, smart inhalers, wireless blood pressure cuffs. These devices sit on the body for weeks at a time, which rules out anything with a heavier power budget.

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!

Why Do Medical Devices Use BLE?

BLE runs for months on one coin cell, so a monitor can stay on the patient without a charging routine. Range covers a hospital floor, and connection setup takes milliseconds.

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.

What Are the Security Risks of BLE in Healthcare?

An unsecured BLE link exposes patient data to interception and hands an attacker a path into the device itself. Five attack types account for most of the exposure.

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.

These attack types show up in shipping products. In May 2026 CISA published advisory ICSMA-26-148-01 for the Fourth Frontier X2, a chest-worn ECG monitor that allowed unauthenticated BLE read and write access to critical GATT characteristics. An attacker within radio range could change the clinical readings the device reported. CISA lists every version of the device as affected, with the fix delivered through the Android and iOS applications.

FDA now reviews wireless security as part of device safety. Section 524B of the FD&C Act requires any product meeting its definition of a cyber device to ship with a software bill of materials and a plan for monitoring and patching vulnerabilities after launch. FDA's current final guidance sets out what the premarket submission should contain, including a threat model. A BLE device usually reaches the internet through a paired phone or gateway, which is generally enough to bring it inside the definition.

HIPAA and GDPR govern the patient data itself. They reach a device manufacturer that stores or transmits that data on behalf of a provider.

How Do You Secure BLE Pairing on ARM Cortex-M33?

We implemented custom LE Secure Connections with auto-validated numeric comparison, running on ARM CryptoCell and TrustZone. The devices pair and bond with no user input. Auto-validation holds only where the devices pair inside a trusted environment.

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. 

What are the core BLE security mechanisms?

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.

How Do You Pair BLE Devices Without User Interaction?

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.

How do you store BLE keys securely on Cortex-M?

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: How Do You Choose a BLE Security Approach?

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.‍