The IoT (Internet of Things) is becoming part of our everyday life. We’re developing audio equipment that can use voice commands to process complex operations, light switches that schedule operations based on observed functionality over time, and even devices that we can use to automatically order supplies based on our consumption habits.

While the IoT definitely has some cool front-facing implementations, it’s having an even more important impact on the medical device industry. Tests that once took an incredible amount of time in multiple labs can now be processed using single, small devices, wirelessly connecting results to healthcare providers. The usability of such medical technology can significantly improve the quality of care.

There is, unfortunately, a dark side of connected medical devices. Because of their power, letting device data and permissions slip into the wrong hands can have dangerous consequences. Today, we’re going to address the stakes of security in healthcare IoT, and describe how to properly mitigate potential vulnerabilities. We’ll offer some encoding methodologies as well as some advice on encryption as we unravel the complexity behind these tiny but mighty tools.

Medical IoT Is Promising – And Dangerous

Consider, for a moment, the industrial revolution. New ways to craft textiles, mine ore, and process materials were invented and implemented across the world, representing a major shift in technological ability. These technologies were leveraged to increase the quality of life for millions of people, and presented the world with new avenues for exploration, development, scientific development, and consumerism.

With this, however, came some massive negatives. Maiming and other damage to workers was common, pollution became a national health concern, and what began as a system for consumerist production quickly turned exploitive and damaging to the very people whose lives the revolution promised to make better.

The IoT is not yet as ubiquitous as the industrial revolution, but there are many parallels between the topics. Like the revolution, the IoT has the potential to greatly impact society. It could result in some hefty exposure of private information, expose vital processes in government and healthcare, and even reduce national security.

One only needs to look at some common biomedical applications of the IoT to see both the extreme promise and the extreme danger of such implementations.Implantable Myoelectric Sensors are now being implemented using wireless communication to allow amputees free control over their prosthetics. These sensors can in theory be disrupted, rendering control of these limbs not to the user, but to an attacker.

Pacemakers can now include near-field communication or wireless chips to allow for configuration and setting tweaks. If an attacker were to utilize this method of contact, the pacemaker could be turned off, or even have its voltage or frequency increased to dangerous levels.

This is not simply “scaremongering,” either – in August of 2017, a major American pacemaker manufacturer issued an open letter to doctors who had implanted a specific range of popular pacemaker devices. 465k patients implanted with this pacemaker were considered at risk of having their devices utilized for nefarious purposes. The company stated in their letter:

“If there were a successful attack, an unauthorized individual (i.e., a nearby attacker) could gain access and issue commands to the implanted medical device through radio frequency (RF) transmission capability, and those unauthorized commands could modify device settings (e.g., stop pacing) or impact device functionality.”

While the medical IoT industry is certainly nascent, all possible threats should be addressed from the onset. The benefits of adopting these pieces of equipment are major – but the chance of them failing, or worse yet, being used for illicit purposes, should give adoptees pause.

That’s not to say we should abandon such devices completely. To harken back to our comparison, it could be argued that the industrial revolution as a whole had a net positive effect on society. However, we should consider the repercussions of disruptive technological advancements, and prepare accordingly.

Forming a Good Solution

Now that we’ve considered potential vulnerabilities in the IoT medical device industry, let’s look at some solutions for securing them. As opposed to securing other elements of the IoT, there are some unique caveats when it comes to connected biomedical device security.

First and foremost, we know that our solution must be small. This means lightweight in terms of codebase as well as the systems that drive it. On a typical medical device, physical space is at a premium, and as such, there’s no real room for traditional drives or other large-capacity solutions. Typically, we’re looking more at flash and solid state storage solutions, which will invariably have reduced physical storage amounts.

Likewise, our solution must be efficient within the limitations of the system. Just as physical space is at a premium, so too is processing power limited by the amount of wattage that can be pushed from the device. Accordingly, we need to have an efficient set of solutions that will allow us to leverage the capabilities of relatively low-power devices for efficient and effective processing.

In terms of functional requirements, we have two major ones. First and foremost, our solution needs to be revocable in some way. Most of our security concerns are regarding attackers performing replay attacks or man-in-the-middle attacks. While it might be alluring to go with “hard coded” solutions, these ultimately are not technically revocable. Having your API depend on a hard-coded piece of information solely can result in a lack of security and increased vulnerability.

The second of these technical requirements is that our solution must work within the network environment. While our APIs might be custom built for specific functionality amongst specific devices, they cannot operate in a bubble. To obtain a secure connection, they must be designed to work with open standards and commonly expected network devices. In theory, we should also allow devices to pass their trust amongst other networked devices, although this is less important than ensuring that they function in a networked environment in the first place.

Encoding Methodologies

With all of this in mind, we can start approaching specific security techniques. First off, we need to consider exactly how we’re going to encode our data. Encoding the data generated from our IoT devices will not in and of itself create a secure data chain, but at the very least, it will enable these efforts.

JWTs and CWTs

Using a JWT, or JSON Web Token, is quickly becoming commonplace amongst APIs, especially in the IoT. This is for good reason, as the JWT schema delivers on all of our requirements in some powerful ways.

 Part of the appeal behind the JWT is that it’s an extremely mobile encoding scheme. Because a JWT is relatively small, this data can be pushed through a variety of methods, including HTTP headers and POST parameters. The JWT itself is composed of a Header, the Payload, and a Signature, and through the utilization of base64 encoding, delivers quite a small package for what is being encoded.

Another aspect of the JWT schema is that the package itself is self-contained, and includes everything that the server could want to know about the user and the data being delivered. This saves devices from having to contact the internal database over and over again, which reduces processing requirements and overhead.

Finally, and perhaps most important, the JWT signs its contents using either a secret (utilizing HMAC) or by using the public/private key paradigm (utilizing RSA). It also can support Javascript Object Signing and Encryption, or JOSE, under RFC 5717 to secure JWT traffic.

Another good option is actually intimately related to JWT, but is possibly more useful for smaller IoT devices. A CWT, or CBOR Web Token, is just a JWT encoded in Concise Binary Object Representation. By shifting to a binary-centric solution, a lot of the bulk introduced through JSON encoding is tossed out, resulting in a much faster, smaller package transport setup.

It should be noted that both JWTs and CWTs grant a certain amount of security by assuring integrity through the use of signatures, but they do not in and of themselves created a secure token. Security is handled separately, specifically through something like OAuth 2.0. This is a common misconception behind JWTs and, accordingly, CWTs, and should be dispelled.

Operational Methodologies

Perhaps the most significant way we can secure medical IoT devices is by configuring them with the end goal in mind. First and foremost, we must limit the scope of data collection. While having a singular powerhouse IoT device is certainly attractive, collecting too much data on a single device only expands the attack surface and results in a situation in which the JWT, CWT, or other encoded data packet dramatically bloats beyond what is acceptable.

Limiting this packet size can also be done by determining what is sent between devices. A hub processing center can take a lot of data, but when daisy-chaining devices together in a workflow, the amount of data sent from device to device must be considered. While size is an issue here, so too is the susceptibility to man-in-the-middle attacks.

Additionally, the type of device-to-device communication used, and how this is processed within the API needs to be considered. NFC (Near-Field Communication) is an attractive option, especially for low power devices, but it does require some additional circuitry on the main device and additional code in the library for your API. Bluetooth and WiFi are generally easily supported using standard modules and drivers, but both are susceptible to MITM, snarfing, etc. in certain configurations.

Encryption Methodologies

The specific encryption methodologies you use will largely be dependent on your chosen operational methodologies, but they bear some discussion in this space. Your choice of encryption broadly ranges between symmetric algorithms and asymmetric algorithms.

Symmetric algorithms use the same key for both encryption and decryption. While this is faster, there can be significant security concerns in some implementations, as breaking only one end of the coded message will expose the entirety of the message. Asymmetric algorithms, on the other hand, use different keys for encryption and decryption. While this is slower, security is increased due to the nature of how the key is handled — either side could be exposed without breaking the entire system. This garners greater amounts of security, but has the obvious downside of speed and relative size in the codebase.

Adopting a hybrid methodology can be very effective at bridging the positives and negatives in encryption. In such a methodology, we would see the public key implemented to encrypt the symmetric key. While it might seem counterintuitive that the hybrid key would be quicker than an asymmetric key alone, the process of encryption and decryption is much smaller, as it is only decoding a singular symmetric key rather than the entirety of the message and contents for encryption/decryption under the PKI schema.

In terms of actual algorithms, there are a few options. AES is relatively lightweight, but at smaller key sizes, can be broken. Camellia is generally considered equal to AES, and is given equal standing in international uses, but is less well-recognized in the United States.

It should be noted that AES is still being rapidly developed for IoT-specific applications. Tohoku University Research Group and NEC Corporation published an AES application in 2016 that uses 50% less energy, resulting in a much smaller and more efficient circuit.

RSA has long been considered the top asymmetric algorithm, and it’s what drives the PKI infrastructure core. While it’s extremely secure, it does suffer from speed issues. Some faster implementations do exist, such as NTRUEncrypt, which has been acknowledged by RSA labs staff as faster than RSA itself. Unfortunately, NTRUEncrypt has only very recently moved into the public domain, and since it’s immature in open source usage, it’s generally considered untested.

Final Thoughts

IoT devices, and the APIs that power them, bring unexpected powers and have use cases throughout the world. In the realm of medical devices, they represent a bright new future in healthcare treatment, remote patient monitoring, and personal data curation.

That being said, we should not be so ready to adopt these technologies without first addressing the security concerns and issues inherent to the API space as it currently exists. Only once we understand these threats and devise cohesive strategies to mitigate them, as well as evolve our algorithms to be smaller and more efficient, will we be able to truly rely on these devices without fear.

What do you think is the best way to secure a medical IoT device? Let us know in the comments below. We’d also love to know what you think of the biomedical IoT field and the burgeoning APIs that support them.