Robert Sayle: Get Manufacturers on Board with Digital Certificates

Hey, biomed! Thanks for waiting for me after the change control board meeting IT just had. I wanted to follow up on our discussion of supplicants for medical device cybersecurity because the best way to leverage 802.1X is to use digital certificates.

Why would we do this? Because we can prepare your equipment for authentication through automation, alleviating you from having to assign passwords and IDs as part of your provisioning process. It’ll save you some time and help eliminate any errors that would be introduced through the manual process of entering a device ID and password via a piece of equipment’s human interface.

What’s a certificate? Well, the International Telecommunications Union defines certificates per the X.509 standard as a set of fields used to identify a user or machine that are cryptographically protected. The fields include attributes such as the owner’s common name and any alternate names, the organization unit to which it belongs, the start and end dates that the certificate is valid, and the entity that issued the certificate. These fields are used to identify the device.

A digital signature or hash is added to the certificate to protect its integrity. Upon creation, the certificate authority (CA), or issuer, computes a value using the certificate’s attributes to create a signature that is difficult to hack. Stated another way—the issuer vouches for the device’s identity. When the device presents its certificate for authentication, the receiver uses the certificate’s fields to reproduce the signature. If the authenticator computes the same value given in the certificate, then authentication succeeds.

Yes, there’s a bit of a chicken-and-egg problem here. How do we safely connect a device so we can assign it a certificate? That’s where the manufacturer comes in. When an OEM builds a machine, it should assign a manufacturer installed certificate (MIC). The manufacturer generates and signs MICs using its root certificate. In other words, the MIC becomes a way that we can at least verify that, yes, the device was actually created by the manufacturer.

When provisioning a biomedical device, we can use the MIC for initial authentication and then place it in a secure provisioning segment. Here, we can create rules that allow the device to communicate with your computerized maintenance management system or whatever control software you use to complete setting up the equipment. In addition, we can give it access to enroll with our health system’s CA. Our CA would generate, sign, and send a unique cert to the new device. At this point, the device would have credentials specific to our organization. We can then reprogram it to connect to our biomedical network.

I know, I know—this isn’t something most (if any) of your equipment can do. But if you wouldn’t mind, you can add these requirements to your vetting process when evaluating new gear. Ask your suppliers if their equipment includes MICs and if they support certificate enrollment processes like SCEP (simple certificate enrollment protocol) and OCSP (online certificate status protocol).

Sure, I can help you write these up sometime! My calendar’s up to date. Feel free to propose anytime that works for you, and we’ll get it done.

Robert Sayle, CCIE security emeritus, is a technical solutions architect for Cisco Systems, Inc., in Irvine, CA, and a member of AAMI’s Wireless Strategy Task Force.

, ,


Subscribe to our RSS feed and social profiles to receive updates.

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: