Security Is a Must

Fig. 2 - Security must not only be built into the device, it must also be able to work with Internet security protocols to ensure security from sensor to cloud.

Perhaps one of the most demanding aspects of medical device design and one that requires detailed attention from developers is security. It is hard to sufficiently emphasize the importance of security in the medical device arena. There are, of course, federal regulations such as HIPAA that mandate patient privacy. In addition, these devices may end up being used in a variety of network environments from home-based Internet connections communicating with cloud servers and ultimately to doctors and specialists to connection inside various hospital wireless networks. Devices must be able to negotiate secure connections that not only protect data, but also guard against hacking and malicious access. As horrid as it may sound, there is even a definite need to protect pacemakers against hacking. And of course, security must be maintained across different communication levels from sensor to cloud (see Figure 2).

One should quite naturally expect security support in the form of security-critical software components such as secure mail or secure SMTP along with secure Web pages or HTTPS for implementing layered security strategies. Secure management — SNMP v3 — can be used to secure both authentication and transmission of data between the management station and the SNMP agent along with an encrypted file system. Additional protocols for graphics functionality along with camera and video support set the developer up with a rich selection of options for the entire range of possible medical applications.

As important as such security support is, however, there is one crucial aspect that is often missed and that involves the actual internal design of an RTOS and the way it manages memory. A potential hazard for sensitive medical devices is connected to the fact that many RTOSs feature POSIX compatibility with Linux, especially in terms of their API. This, of course, has the advantage that many developers are familiar with it and a large amount of existing code, including open source, can be acquired and adapted for use in embedded applications.

The other thing that usually comes along with POSIX/Linux compatibility, however, is its memory management, which supports dynamic loading where the code can be loaded into RAM and then run under control of the operating system. Linux relies on protection of the OS to make sure that user programs cannot gain control of which programs are to be run. How-ever, that protection can sometimes be breached, and so dynamic loading involves definite dangers when used in critical embedded systems like medical devices.

Many RTOS implementations can also be breached because they are large and complex, and it only takes one small security hole to get privileged access or access to physical memory and bypass the entire security mechanism. Since the malware code must executed from the target device, it must therefore be loaded into that device's memory.

Using a different memory model can offer a much higher grade of security for embedded connected devices. In such a model, all code executes from Flash memory so in order for code to be loaded in so that it can execute, it must also be placed in Flash, which is much more difficult than putting it into RAM. Flash-based code is a single linked image so that when it executes, it just executes from that image. There is no swapping of code in from RAM. RAM is of course used for temporary storage of variables and stacks such as used for context switching, but all instructions execute from Flash.

Prototyping platforms consist of RTOS, communications components, and supported peripheral (including sensors) drivers. Also shown a selection of processor boards such as the STM32F4 (l) and STM32F7 (r) boards from STMicroelectronics.

This means that no external program can be loaded into device memory to be executed even under control of the OS because the code must be executed from Flash and the only way to modify that Flash image is to upload an entirely new image, presumably one that includes the malware along with the regular application code. Getting ahold of a copy of the Flash-based application in order to modify and upload it is extremely difficult if not impossible.

And the remote field upgrade feature should also be a program on the device that uses encryption. If the image to be loaded is encrypted, it can only be decrypted if it is signed with the proper key, which is owned by the owner of the code and the device and kept separately from the device. In other words, you can't get the decryption key by hacking the device. Code that isn't properly signed is simply thrown away. The upshot is that even if a hacker could breach the password/user name barrier, he will not be able to modify the code in the device in any useful way.

Start with a Solid Platform

Developing systems of this variety and complexity from scratch would, of course, be a thankless task. Developers should seek a stable and versatile platform consisting of a choice of supported MCUs and hardware devices along with an RTOS environment tailored for very small systems and with a host of supported drivers, software modules, and protocols. Many vendors now offer board-level prototyping development kits that allow developers to verify proof-of-concept before making a potentially expensive commitment to a specific solution.

Due to the wide variety of medical devices and their support systems such as in-home gateways, cloud connectivity, and more, wide support for different processors and their families is important to support later product enhancement and expansion. Support for a standard API like POSIX makes it easier to bring in new team members as well as open source code. And the ability to start adding value from day one will go a long way toward a successful project.

This article was written by Kim Rowe, CEO of Rowebots, Ltd. Waterloo, ON, Canada. For more information, Click Here.