The Landscape of Cybersecurity, Medical Devices and the FDA in 2023

Medical Device Cybersecurity Guidance for Industry

In the Internet of Things (IoT) security space, medical device makers have struggled to keep up with the ever-increasing need to implement integrated security features in their designs. The hacking community has grown to a point where any average firmware engineer can attack any type of device and spoof its identity or change its vital functions. The Ponemon Institute is reporting that the health care industry is by far the highest-risk industry with respect to emerging threats and vulnerabilities; this is not simply projected, but based off real and legitimate attacks. In a recent survey, of the medical organizations interviewed who reported a breach in the past two years, 88% said at least one connected device was a contributing factor to the breach. This medical device security problem has been noted but not seriously considered.

But there is hopefully a turning point in front of us. In the US, in April 2022, the FDA issued its highly anticipated draft guidance on medical device security for public comments. The draft provides guidance on security for embedded devices in the medical field and associated premarket submissions. In other words, the FDA recommends original equipment manufacturers to establish a secure product development framework to improve product robustness and implement foundational security requirements. The document includes development, release, support and decommissioning. In June 2022, the US Congress introduced “a bipartisan legislation to strengthen cybersecurity for medical devices.” Ironically, in late September 2022, the bill containing cybersecurity for medical devices took out the cybersecurity section and only left the user fee section. The FDA draft is a huge step forward to protect the integrity and the safety of patients leveraging IoT medical devices. Three years ago, the CTO of a company shared this story with me. The company specializes in embedded firmware developments. The son of the CTO was suffering from heart deficiencies and was provided with a pacemaker. After some studies, the CTO realized that the functions of the pacemaker regulating the heart could be altered or stopped which would lead to the death of his son. That is how terrible reality looked a few years ago for security on medical devices. There have been slow improvements, but both medical device makers and the FDA need to step up and move this change process along at a quicker pace. For example, imagine how one can scale this attack to many individuals. Experts are looking forward to progress in legislating cybersecurity for medical devices in the near future.

Let's take a look at what is inside the draft proposed by the FDA. The document is broken down into three main sections and appendixes. The first section talks about general principles to instruct how and why cybersecurity should be part of device safety and quality system regulations, how to design for security, why providing transparency is important and submission documentation. In the second main section, the FDA proposes the secure product development framework to manage security risks and examine one of the most important first steps to take for security: the risk assessment or the threat model. In that same section, they also discuss security architectures—more precisely, they review implementation of security controls, security architecture views, global system views, multi-pattern harm views, updatability and patchability and various security use cases. Finally, the FDA closes that section with testing for cybersecurity. In the third and last section, the FDA discusses the transparency of cybersecurity and labeling recommendations for devices with cybersecurity risks with associated vulnerability management plans.

The appendix section deserves significant attention for the embedded system architects. This is where technical concepts and use cases are described but they remain high level. That section is where you will find authentication, authorization, cryptography code data, execution integrity confidentiality event detection, logging resiliency and recovery firmware and software updates. So, it looks like most of the foundations are covered, but let me summarize that in embedded security engineer language.

For years, Microchip has been consistently emphasizing the necessity to implement security functional practices right from the start of your design. It’s good to see the FDA document reflects the basic ones.

Here are the security practices recommended for implementation by the FDA:

• Authentication: this is the first item on the FDA list for good reason. Without strong authentication, there is no foundation in your security model. How do you achieve it? Generally speaking, you will have a symmetric key pair to authenticate an ecosystem of accessories/disposables or a public/private key pair and associated certificate chain that will connect your medical device to the network. The private key (or the symmetric key) is the most important information to isolate from the firmware of your device which will likely contain bugs and be accessible. So, the FDA recommends placing the cryptographic key inside a tamper proof secure key storage similar to the CryptoAuthentication™ security ICs. Here is what the FDA actually says:

There are other very important concepts in this authentication paragraph such as:

• Authenticating connections to a server: that’s a given—the device must trust the cloud and vice versa. That’s mutual authentication over a network, which we discuss extensively in this TLS blog post. The Trust Platform Design Suite (TPDS) offers various TLS implementation code examples for AWS IoT, Microsoft Azure with bare metal 32-bit microcontrollers or Azure RTOS PKCS#11.
• Authenticating each session: while it’s a healthy practice, it could impact your power budget for battery-powered devices. Here, the combined usage of hardware crypto accelerators with secure key storage offers a very low sleep current like the 30nA typical sleep current from the ATECC608 TrustFLEX.
• User authentication to permit privileged device access to administrators, technicians and others: that’s where the ATECC608 TrustFLEX integrates a use case called private key attestation. This will authorize a child private key to become part of the ecosystem only after the TLS has been authenticated. That child private key would represent a newly authorized user to do something.
• Firmware update and associated permissions: here we will refer to public key attestation where a parent public key will allow a child public key to exist and be used to verify firmware signatures. The TrustFLEX ATECC608 or TA100 will perform the appropriate cryptographic verification and set permissions to do so according to your threat model.
• Default passwords: here again, you can leverage the notion of key attestation to avoid default passwords.
• Anti-replay: this is used to avoid hackers injecting or making changes in packets that travel from a source to a destination
• Verifying the authenticity of information: this is where you might consider signing a message and verifying it in your embedded system to prove it is trusted. The CryptoAuthentication ICs are set up to handle message authentication encrypted or not. Alternatively, you could implement message authentication code (MAC) using a symmetric and the associated crypto-accelerator. Teaser: have you heard about MACsec?

The other sections of the appendix have their own importance. The endless challenge with security standards is they state conceptually what to do but not how to do it. So, let’s try continuing to illustrate at a high level what each section could mean from a technology usage standpoint:

• Authorization: this notion ties into the authentication section where we discussed privileges. Now the FDA has introduced the principle of least privilege. How do you implement it? Trusted Execution Environments (TEEs) start to show their value. It’s all about setting up rights and permissions adequately between the trusted zone and the application zone to manage the critical code. But keys are still vulnerable and here again the CryptoAuthentication ICs are a viable way to implement rights and permissions. The PIC32CM LS60 offers a combination of TrustZone with secure storage subsystem solution all in one microcontroller. On the other hand, did you know the TA100 can implement an architecture of privileges between the various memory slots managed by a PKI, all that within the secure boundary of the secure authentication IC itself? Assume that among three slots, you want one to be the grand parent authority, the second the parent and the third one the child. The TA100 is the perfect device to implement such a scheme and much more advanced ones. Below is another abstract of the FDA document:

• Cryptography: the FDA recommends using standard cryptographic algorithms. They are continuously tested and updated by public organizations leveraging a large community of testers and don’t allow downgrades of the cryptographic protocol.  
• Code, data and execution integrity: cryptographic keys will verify the integrity of the data but not the validity. You need to validate that “all data originating from the external sources is well-formed and compliant” with the specification or protocol. In other words, validate that the data makes sense.
• Confidentiality: this ties into the authentication and authorization notions previously discussed. If the cryptographic keys are not kept confidential on the hardware, “unauthorized use/abuse” becomes possible and could lead to potential fatal situations for the patient. So we must protect the keys in the hardware.

• Event detection and logging: “event detection capabilities and logs should include storage capabilities so that forensic discovery may later be performed.”
• Resiliency and recovery: these provide methods of retention and recovery of trusted default device configuration. How do you plan to achieve that without a secure key storage to trust your keys?
• Firmware and software update: this item seems obvious, but we still find IoT devices today with no Over-the-Air (OTA) update capabilities. There are several cloud services companies out there that will offer a code signing service (AWS, Microsoft Azure for the IaaS and KeyFACTOR, Kudelski for SaaS)—but then you will need the equivalent C-code agent that will run on your microcontroller. The controller architecture will differ widely depending on your choice of core. Once you are ready to update your device firmware, think about how critical the public key that will verify that new code became. As part of your threat model, what can someone do with the public key authorizing the code update? Well, the person could control your OTA update. As such, the attack can inject unwanted code.  Now think about how code updates should tie into the user privilege previously established. That takes us back to leveraging the CryptoAuthentication ICs to help your security architecture to implement all that together while protecting your keys.

In conclusion, a good way to meet the FDA requirements is to isolate the cryptographic keys in certified secure key storage ICs such as The CryptoAuthentication ICs. It will cover a lot of the use cases mentioned in the FDA document and its code examples are mostly available in the Trust Platform Design Suite (TPDS)—make sure to download it. Here is a list of code examples with various hardware in TPDS:

• TLS Mutual Authentication
• Private key attestation to user authentication
• Public key attestation to help with firmware authorization
• OTA Firmware update
• Secure boot signature verification with a protected public key

One CryptoAuthentication IC can securely store the cryptographic keys to most, if not all, of the mentioned use cases by the FDA. Once the keys are segregated from the code, contract manufacturers and operators, depending on your product and your threat model, you might want to look at your code and how you manage permission to access it, update it and use it. That’s where a combination of trusted execution environment with isolated secure key storage comes in play. Our PolarFire^® FPGA multizone security and TrustZone microprocessors/microcontrollers are designed to isolate critical code from non-critical code. They have the associated permissions leveraging third-party software solutions. However, the cryptographic needs to be outside the TEE and inside the CryptoAuthentication ICs.

The FDA has established a good foundation for embedded security for medical devices and Microchip has the technology to help you meet the proposed standards.

When it comes down to going to production and through the FDA process, we recommend looking into our medical design partners such as DornerWorks and many others.

Dornerworks says: “When guiding our customers to a safe, effective and secure connected medical device solution, DornerWorks engineers rely on ICs from Microchip to ensure a robust and resilient security profile, so that our customers can confidently and successfully complete their FDA submissions.“

Sources:

1. https://www.fda.gov/media/119933/download
2. https://www.fiercehealthcare.com/health-tech/cyberattack-revolving-doors-medical-devices-put-patients-crossfire
3. https://www.scworld.com/analysis/fda-bill-passes-without-cybersecurity-requirements-for-medical-devices