by:
Daniel Beard

CyberMed Cloud Secure Device User Authentication Over Unreliable Channels

The Problem

As modern medical devices explore new user interaction and connectivity schemes, novel technical problems arise. With strategies like rent-to-own, pay-per-use, or subscription it is no longer acceptable to assume that anyone with physical access to a medical device is an authorized user. The device or application needs to authenticate a potential user with the cloud to verify that they have the appropriate permissions to use the device.

Cloud permission to log into device
Initial Login
User Interaction after Login

It cannot be assumed that the device has a consistent and reliable internet connection at all times. Denying a legitimate user or patient access because of a temporary internet outage is rarely an acceptable scenario. This unreliability magnifies for stationary lab instruments that might be installed in an area without internet access permanently. Thus, if an internet connection is required for authentication, it must be time-shifted to when a mobile device has a solid wireless connection.

Use device wiith and without good internet connection
Internet Scenarios

In addition, since there is a clear financial motivation for subverting the authentication scheme, and the device manufacturer doesn't control the communication channel to the authentication server, a solution must continue to work over channels with a malicious man-in-the-middle.

Man-in-the-middle malicious actor
Malicious Actor - Man-in-the-middle

A generic solution for device authentication over untrusted and unreliable channels is required for many of the novel strategies of modern medical device companies. 

Solution

The solution proposed in this paper assumes some security basics are in place. We will define these assumptions and the components of the system below.

Assumptions

  • The physical device has not been altered by a Malicious Actor. This is the same assumption naturally made for any current medical device. 
  • Private keys and user passwords are kept secret. This is an industry standard assumption.
  • Each physical device can be uniquely identified by a UUID
  • Each user can be uniquely identified by a UUID
  • Each physical device has a unique public/private key pair
  • Each user has a unique public/private key pair
  • All communication is done over a secure and authenticated channel (e.g. TLS)

Components

User

The human interacting with the device through the User Application.

Master Signing Key Pair

The Master Signing Key Pair is a secure RSA key-pair stored offsite in a secure physical location. 

Cloud Signing Key Pair

A Cloud Signing Key Pair is a secure RSA key-pair stored in the cloud server. It is the actual key used for minting and signing new Device Authentication Tokens. It is granted this authorization through a Cloud Key Pair Authorization Token

Cloud Key Pair Authorization Token

A serialized (e.g. JSON, XML) dictionary of key value pairs that contains:

  • A numerical ID for this token
  • The public key of an authorized Cloud Signing Key Pair
  • The end date of this authorization
  • The current revocation list

A SHA256 hash of this serialized token is signed with the private key of the Master Signing Key Pair.

Revocation List

Each device will keep its own revocation list of numerical IDs. Any Cloud Key Pair Authorization Token with an ID that is in the list will be treated as if it were expired. No tokens signed by a key with an ID in the revocation list will be accepted by the device. 

Device Authentication Token

A serialized (e.g. JSON, XML) dictionary of key value pairs that contains:

  • The UUID for this specific token
  • The date the token was generated
  • The UUID of the device that this token authorizes
  • The number of 'authorized uses'
  • The UUID of the user that owns this token 
  • The public key of the above user
  • The expiration date of this token

A SHA256 hash of this serialized token is signed with the private key of the Cloud Signing Key Pair.

Device

The trusted device manufactured and distributed by a trusted party. At time of manufacture a copy of the Master Signing Key Pair's public key will be entered into the devices trusted keys list. 

User Application

The untrusted application that will command the device and request access on behalf of a user. This application could be built into the device itself, via a touchscreen or other user interface. It could also be a remote application of aPC attached via a serial or CAN connection, or a a smart phone app talking wireless over Bluetooth. Since this application could be remote to the device, it is untrusted. This paper only deals with authenticating the user to be able to run commands. The User Application remains untrusted, even after the user himself/herself has been authenticated. Additional care must be taken to guarantee that any commands issued by an authenticated untrusted application could not cause patient harm.  

Setup

In order to mint new Device Authorization Tokens that will be trusted by the device, the cloud server must have a Key Pair Authorization Token. The Master Key Pair should be on a physically, or logically separate medium, and only connected to the cloud server for a short period of time. This process will need to be repeated when either the Cloud Key Pair Authorization Token expires, or if there was a breach in the cloud server that enabled attackers to grab the current Cloud Key Pair private key. 

Generating a Cloud Keypair Authorization Token
Generating Cloud Key Pair

Protocol Examples

Typical Protocol Interaction

Given the above architecture, here are some examples of the protocol inaction.

Typical User Authorization

In the typical scenario, the User Application will attempt to command the device. All commands must be signed with the public key of the authorized user. If the user has no Device Authorization Tokens on the device, or if that user's tokens on the device have been expired, either due to time or number of uses, then the device will not complete the command and send an unauthorized error. The user application can supply an addition Device Authorization Token to continue the command. The User Application should 'front-load' the acquisition of Device Authentication Tokens, so that is has one or more tokens immediately ready to give to the device. In the case of an unreliable connection, the device will be usable until the User Application runs out of valid Device Authentication Tokens. It will then need to wait until it gets internet access to request more tokens from the cloud. 

Initial User Interaction

When the device is first powered on, it won't trust the Cloud Signing Key Pair. At Manufacture time, the only public key put in its trusted store was the Master Signing Key Pair. This means that it will not trust any Device Authorization Tokens signed by the Cloud Key Pair until it has been given the appropriate Cloud Authorization Token. See the diagram below for an example exchange 

Initial Interaction

Revocation

In the event that the Cloud Signing Key Pair is compromised, the Cloud Key Pair Authorization Token must be revoked.

Weaknesses

There are a few important weaknesses to this solution. First, it only offers secure authentication if the above assumptions are held true. If the device itself has been compromised in any way, it could be ordered to ignore security checks. Similarly, if a user leaks his password, or if the Cloud Authorization Private key is leaked, then a Malicious Actor could mint their own access tokens with the user's credentials or the trusted private key. These risks can be mitigated with strong physical security at the device side, and strong digital security on the server side. Secondly, this scheme does not address patient harm from authorized actions. If a malicious User Application obtained a valid access token from a user's username and password, it can perform all authorized commands, and use any valid arguments to those commands. This risk can be mitigated with standard risk mitigation procedures, such as those defined in IEC 62304, by separating the safety critical parts of the system, and performing sanity checks on all arguments.  

Summary

The need to authenticate users for medical devices via the cloud while still providing access to the internet is becoming a common scenario for many medical device applications. This can be handled by the 'front-loading' the acquisition of device authentication tokens, so that user has one or more tokens immediately ready to give to the device. In the case of an unreliable connection, the device will be usable until the User Application runs out of valid Device Authentication Tokens, at which point internet access to request more tokens from the cloud will be necessary.

CEO of Promenade Software Frances Cohen
https://www.linkedin.com/in/danielibeard
About Promenade Software

Promenade Software, Inc. specializes in software development for medical devices and other safety-critical applications.
Promenade is ISO 13485 and 9001 certified.

American Systems registrar
Contact

Promenade Software, Inc.
16 Technology Drive, Suite 100
Irvine, CA 92618, U.S.A.
email: info@promenadesoftware.com
phone: (949) 333-4634
Contact Form

© 2020 Promenade Software, Inc.