Public Key Infrastructure for Device Security

Introduction

The discussion on cybersecurity, risk and assessment highlighted the use of NIST framework for cybersecurity. For medical devices, the FDA references it and highlight these two main areas to address in their guidance for design:

• Identify and Protect – Limit access to trusted users only Ensure trusted content
• Detect, Respond, Recover

Device manufacturing usually building some custom hardware together with embedded software or firmware. Unless the device has a very short lifespan, it is essential to support a field update of the software/firmware.

Field Updates

Field updates are possible in two ways; a service technician visit or automated Over-The-Air (OTA).  In the first case, the technician visits the customer site and plugs his or her computer to connect to the device and install a new version of firmware. In the later case of OTA, the device reaches out to a server and pulls down a new version of firmware and performs an automatic. This might require an initial command by a local user at the device (i.e. similar to a Windows update prompting a user to perform the update).

The table below highlights the difference between the two use cases. This is important to highlight because it shows the nuances in designing with appropriate security from the outset.

Use Case	Client/master device	Server/slave device
Field Update	Service technician computer	Device
Automated OTA	Device	OTA server

In the first case, the service technician computer is the client which is initiating the connection to the device being updated. In the automated OTA, it’s the opposite case where the device initiates the connection to the OTA server.

From NIST framework to secure connectivity

In either of the two use cases, it’s important to read the line Identify and Protect – Limit access to trusted users only Ensure trusted content. What does this mean in practice? Here is a good way to think about it.

Here are some options that do not limit security over Ethernet.

• FTP with no authentication
• Telnet with no authentication
• HTTP with no authentication

OK. That’s very easy. Let’s think about it some more. What are some options that are a step up from this? FTP or Telnet with a password. No one uses or should use these approaches anymore because the passwords are sent in the clear over the network.

Thinking more we can easily start to add SSH, SFTP, SCP as other options. These are better than FTP and Telnet but do they really limit access to only trusted people. They rely on username/password or public/private keypair. How are these credentials kept secure and how do we prevent someone copying this information in a public forum or a employee taking this information after leaving a company.

PKI as the solution

The answer is that PKI. In this case, the device is issued with a certificate from a private root or intermediate Ceritificate Authority (CA). Usually it’s an intermediate CA which is created from the root.

The service technician laptop is also issued with a certificate from the same intermediate CA or another intermediate CA which both chain up to the same root CA. The reason for having different intermediate CAs is that it’s possible to have different expiry periods for different certificates and also different Extended Key Usage (EKU) values.

For example, the certificate expiration can be set to a longer period (e.g. greater than the typical lifetime of the device) versus service technician certificates which can be short-lived. Similarly, for the device to perform both use cases above it would need to have EKU set to both client and server authentication.

The advantage of certificates is that are built with a trust hierarchy. They have features to limit access both through their issuance and revocation through the use of Certificate Revocation Lists (CRL).