Making Connected Health Safe and Secure Under Smartphone Control

By Vinay Gokhale, Vice President of Business Development with Thirdwayv

The security of insulin pumps, heart-rate monitors and other medical devices that are connected in Internet of Things (IoT) Systems is often simply assumed to exist. An equally dangerous mistake is to believe adequate security is prohibitively expensive to add, especially as a growing percentage of connected health systems move under smartphone control. Solution providers must go beyond these mobile devices’ inadequate built-in security mechanisms while also ensuring the necessary “always-on” connectivity for reliably exchanging safety-critical data and commands between smartphone apps, the IoT devices and the cloud.

While Bluetooth, NFC, LTE, Ethernet and other protocols do mitigate some breaches, they don’t protect systems against all threats in today’s safety-critical healthcare IoT applications. Cybersecurity risks extend to each “thing” in an IoT solution, including items that are subject to counterfeiting. This includes consumables such as controlled substances that must be correctly dosed to an authenticated individual, or x-ray plates for an imaging system. Mitigating these threats requires a multi-layered, security-by-design approach with three key elements:

Application-layer security: This provides a secure communication channel between the smartphone app, the medical device and the cloud so that the connected health solution is resistant to malware and wireless channel cybersecurity attacks. Creating this secure tunnel between the sender and receiver enables the application to natively build in its own security rather than relying solely on the lower stack levels. It also eliminates the risks of typical Layer-4 security that only protects the message payload at or below this layer as they move up and down the OSI stack during sending and receiving. The session is authenticated, and all messages are encrypted before exiting the app, which exchanges keys required for the recipient app to decrypt the messages. Together, these safeguards augment the security mechanisms that exist in Android OS and iOS while overcoming their communication protocol vulnerabilities.

Establishing a “root of trust” within and between each system element: The solution must ensure that only authorized and trusted sources can originate information and commands. This trust is established through user and device authentication, identity management and attestation of one system component to the other. A unique digital cryptographic identity is given to the smartphone app, cloud, and other devices connected to the solution’s communication system. Authentication using these identities is most effectively implemented by factory-provisioning a hardware security module (HSM) that stores and manages keys and certificates and is used by the trusted cloud infrastructure to verify the integrity and authenticity of all smartphone apps and medical devices.

Ensuring continuous operation: The third protective layer ensures systems always receive the most recent data for immediately changing device operation based on patient requirements. This can be difficult when solutions depend on cloud connectivity for a handheld device or a smartphone that may experience communications service lapses. There are three basic approaches to solving this problem. The first is a software app that runs in the iOS or Android OS background, stays in the background and harvests IoT device data without further user intervention whenever the device is in proximity to the smartphone. The second, hardware-based approach is a small-form-factor bridge that uses two communications protocols (one to interact with the IoT device, usually featuring only personal area coverage, and another to communicate to the cloud), and can be configured either for continuous operation or for use only when the primary IoT-to-cloud path is unavailable. The third approach protects legacy equipment such as MRI machines and other wired Ethernet medical systems that have been the source of most hospital hacks: this hardware gateway connects to the Ethernet network and is placed in front of this vulnerable medical equipment to provide a separate channel for communicating only with authenticated devices.

These multiple layers of safety and security can be implemented in a modular fashion using third-party software developer’s kits (SDKs), at significantly lower cost than building solutions from scratch and with much more flexibility. In most cases, achieving adequate security adds only a few pennies to the cost of an insulin pump or other connected-health system. Security can also be retrofitted into an existing solution and its infrastructure as needed, enabling solution providers and their customers to continuously improve how they manage cybersecurity risks as today’s threats grow and evolve.