Security by design for embedded IoMT devices

A deep dive into the U.S. Food and Drug Administration’s healthcare guidelines for Internet of Medical Things (IoMT).

PHOTO COURTESY OF MICROCHIP

The healthcare industry’s increasing reliance on connected devices makes it vulnerable to cyberattacks, ranked second only to small businesses. To counter potential disasters, the U.S. Food and Drug Administration (FDA) has developed guidelines medical device manufacturers can follow to implement security in embedded devices. It covers design through development, product release, post-market support, and decommissioning. Although the information in the FDA guidelines is a must-read for designers, it’s generally written at a high level, most often stating what should be achieved but not how to achieve it. To help medical device designers delve deeper, this article provides some of the missing details.

Since 2014, the FDA has been issuing recommendations concerning cybersecurity for the healthcare industry, each one updating its predecessor to address the rapidly evolving threat landscape. The latest guidelines are contained in “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions: Draft Guidance for Industry and Food and Drug Administration Staff” released in April 2022. It has three main sections:

General principles:

How and why cybersecurity should be part of device safety, quality system regulations, how to design for security, why providing transparency is important, and submission of documentation.

The secure product development framework:

How to manage and assess security risks using a threat model and security architectures that include security controls, global system and multi-pattern harm views, and the need for updates and patches. This section also provides details about testing for cybersecurity.

Cybersecurity transparency:

Conveyed through labeling and establishing vulnerability management plans, it acknowledges users have different abilities to perform mitigation and that solutions should be appropriate for each one.

Xavier Bignalet,
Product Marketing
Manager, Microchip

However, the most useful information for embedded system designers comes at the end, in Appendix 1, including information about authentication, authorization, cryptography, execution integrity, event detection, logging resiliency, and firmware and software updates.

It’s necessary to cover each topic separately to fill in the details missing from the FDA’s broad guidelines.

First, authentication is necessary for a security model to be complete. A public/private key pair and associated certificate chain connects a medical device to a network. The private key needs to be isolated from device firmware that could contain bugs and make keys easily accessible. The FDA recommends placing the cryptographic key inside tamper-proof secure key storage similar to Microchip’s CryptoAuthentication security ICs.

Connections to a cloud server must be authenticated with the device and cloud trusting each other. While authenticating each session is desirable, it can consume a lot of power in battery powered Internet of Things (IoT) devices. A combination of hardware crypto accelerators and secure key storage significantly mitigates this issue as it maintains a very low current on the order of nanoamps in sleep mode.

User authentication allows privileged device access to administrators, technicians, and others, which brings up the notion of key attestation. Such use cases are provided via a predefined configuration of CryptoAuthentication integrated circuits (ICs) leveraging the Trust Platform Design Suite (TPDS) development tool.

Information authenticity is necessary for signing a message and verifying it in the embedded system to prove it’s trusted. Although crypto authentication ICs inherently handle both encrypted or unencrypted message authentication, message authentication code (MAC) using a symmetric and the associated crypto-accelerator can be used as well.

Authorization is another important contribution of the FDA guidelines because it establishes the principle of least privilege, which is setting up rights and permissions between the trusted execution zone and the application zone to manage critical code. Every module can access only the information and resources required for its purpose.

Cryptography’s obviously another essential ingredient in assuring security. The FDA wisely recommends using standard cryptographic algorithms because they are continuously tested and updated by public organizations based on input from a huge community of users. Cryptographic keys will verify the integrity of the data but not the validity, so designers must validate all data originating from external sources is well-formed and compliant with the specification or protocol.

Confidentiality relates to authentication and authorization, and if cryptographic keys aren’t kept confidential in the hardware, unauthorized use becomes possible. Manufacturers should ensure support for the confidentiality of all data whose disclosure could be used by hackers to cause harm to patients. Confidentiality is required in handling and storage of cryptographic keys for authentication because disclosure could lead to unauthorized use/abuse of device functionality.

The FDA document provides information on the proper implementation of authorization and authentication schemes that’ll generally assure confidentiality. However, designers should assess whether this is the case during threat modeling and make necessary changes to systems to ensure appropriate controls are in place.

The FDA also describes event detection and logging, recommending they’re stored so forensic discovery can be conducted. This involves retaining and recovering trusted default device configurations, and designers must determine how this can be achieved using secure key storage.

It’s reasonable to assume all IoT devices available today allow over-the-air (OTA) firmware and software updates, but the truth is many such devices don’t have this ability. Without the proper firmware, system updates can’t be rapidly deployed to address the latest threats. Code updates should also conform to the established user privileges because someone with the public key could control the OTA update and inject unwanted code.

Fortunately, CryptoAuthentication ICs makes the process simple and automated and ensures updates are performed. A single CryptoAuthentication IC can securely store the cryptographic keys to most, if not all, of the use cases noted by the FDA.

 

PHOTO COURTESY OF MICROCHIP

In summary

The FDA’s latest guidelines for medical device manufacturers are comprehensive in their scope and intended to advance the state of the healthcare system’s cybersecurity. They were written in a form that can be inserted into legislation rather than as a “how-to” guide for embedded system designers, which is why the bench-level discussion is contained only in an appendix.

Microchip has spent years developing a trusted ecosystem of safety devices and tools, making it a good place to start before embarking on the journey of developing systems that’ll be included in next-generation medical products.

About the author: Xavier Bignalet is a product marketing manager for Microchip Technology’s security products business unit and can be reached at xavier.bignalet@microchip.com.

Microchip
https://www.microchip.com

April 2023
Explore the April 2023 Issue

Check out more from this issue and find your next story to read.