.png)
UPDATE: CyberMed•Cloud is now CypherMed Cloud.
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.
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 problem is magnified for stationary lab instruments that might be installed in an area without reliable and consistent internet access. Thus, if an internet connection is required for authentication, it must be time-shifted to when a mobile device has a solid wireless connection.
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.
A generic solution for device authentication over untrusted and unreliable channels is required for many of the novel strategies of modern medical device companies.
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.
User - the human interacting with the device through the User Application
Master Signing Key Pair - a secure RSA key-pair stored offsite in a secure physical location.
Cloud Signing Key Pair - 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 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:
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 device's 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 a PC, attached via a serial or CAN connection, or 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 themself has been authenticated. Additional care must be taken to guarantee that any commands issued by an authenticated untrusted application could not cause patient harm.
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 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.
Given the above architecture, here are some examples of the protocol inaction.
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 expired (either due to time or number of uses), then the device will not complete the command and will send an unauthorized error. The user application can supply an additional Device Authorization Token to continue the command. The User Application should 'front-load' the acquisition of Device Authentication Tokens, so that it 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.
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
In the event that the Cloud Signing Key Pair is compromised, the Cloud Key Pair Authorization Token must be revoked.
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 their 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.
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 "front-loading" the acquisition of device authentication tokens, so that a 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.
