Safety vs security

It is important to distinguish safety from security concepts.

 On one hand, medical devices must ensure patient safety while ensuring specific performances. Safety risk control measures shall be implemented to reduce safety risks to an acceptable level for users and patients and be as robust as possible against failures that may lead to harm of various severities. Safety focuses on protection of users and patients’ health.

 On the other hand, medical devices must ensure software security. Security risk control measures shall be implemented to reduce security risks associated with malicious use of the device features. Security focuses on protection of data and software systems.

 Therefore, if you do not treat those two aspects properly you may develop safe but unsecure devices or secure but unsafe devices.

In the worst case, an insufficient security level can lead to a major safety risk (unexpected remote access to a life supporting device, upload of an unsafe treatment, etc.), which may create critical effects on the patient (inappropriate treatment received, death, etc.). Strong safety and security risk control measures shall be implemented to make this situation impossible or highly improbable.

 Debiotech recommends to:

• Make the distinction between safety and security in your risk management processes and files.
• Implement strong safety risk control measures and verify their efficacy and effectiveness. As much as reasonably possible use non software risk control measures to avoid introducing software components with high-risk classification.
• Implement strong security risk control measures and verify their efficacy and effectiveness.

Figure 1. Simple illustration of security and safety concepts

Good practices before applying security risk management

To minimize your development work when applying a security risk management process, you need to start minimizing software weaknesses at the beginning of your development. This can be achieved by reducing as much as possible the attack surface of your system. In this chapter multiple concepts allowing you to start early on with good software security practices will be developed. Most of those concepts impact your software and hardware architecture and are therefore important to consider in the early stages of your development.

Controlled use of Third-Party components (SOUP, OTS, OS)

Operating Systems (OS), Software of Unknown Pedigree (SOUP), Off-The-Shelf (OTS) components and your own code must only use strictly necessary features. The more protocols, drivers or libraries are used, the higher the risk of introducing vulnerabilities.

A quick look at the Common Vulnerabilities and Exposures databases searching for “Linux Kernel” will return many CVEs related to specific drivers that are not necessarily required on your device. This demonstrates that you should limit the use of OS drivers to the strict minimum and block or deactivate unnecessary OS features from your system.

Nowadays, many very useful libraries are available; however, very few of them have been developed following a development process compliant with medical regulations. It is not forbidden to use them, but you should carefully consider the amount of work that will be needed to integrate such libraries in your system. To avoid this additional and complex work of verifying and validating external libraries, you should strongly limit their use and only use them when it is relevant for performance and robustness objectives. These components must be isolated as much as possible from safety-critical components.

Debiotech recommends to:

• Limit as much as possible the use of SOUP
• Limit as much as possible the use of protocols and drivers associated with the operating systems of your system,
• Deactivate software communication features that you do not need.

Smart use of cryptography

Most of the connected devices need to use strong cryptography algorithms to secure authentication, data storage, data communication and sometimes remote computing. Cryptography is a highly expert field requiring very specific skills and expertise. It is rarely the core of your team expertise, and you should just accept it. Do not try to write your own cryptography algorithms; use state-of-the-art available solutions instead. Well-tested solutions exist for all languages. In embedded systems, “openssl” for Linux devices or “mbedTLS” for bare-metal devices are good choices that will provide all needed features.

Be careful, using a bug-free library does not mean that bug-free cryptography will be written. The documentation must be followed to use the functions as they are intended to and for the algorithm to be correctly used (e.g., a common mistake is to use a fixed initialization vector for AES encryption).

Finally, be aware that algorithms may become obsolete because a flaw is discovered, or because it becomes too weak in comparison to the increase of computational power. Only algorithms that are considered safe for the next coming years must be used. The FIPS 140-2 Algorithm Lists can be checked to know which algorithms are approved.

Confidential computing

If you are using remote computing, you should consider using confidential computing for your remote computing server. Data encryption for storage and transmission is now relatively popular. However remote or cloud-based computing is usually decrypting data before processing it, so data can be accessible and readable at the processor level. This can make your data accessible by attackers or by the provider of your remote server infrastructure. New secure computing technology exists (as for example the ones provided by: IBM, Microsoft Azure, Google, Intel and Cysec) and it allows to render the entire data chain confidential: from storage to computing, including transmission.

Remove compilation warnings

When developing your software, you might have the tendency to ignore warnings in your build summary. Debiotech highly recommends fixing them systematically and quickly. They are the sign of weaknesses of your code that might not directly impact the performance of your device but might reduce its robustness and security. In addition, Debiotech recommends using compilation options that protect against stack overflow and certain Return-oriented programming (ROP) attacks when available.

Use of static code analyzer

It is recommended (UL-2900-2) to make use of static code analysis to reduce software weaknesses like, for instance, the use of predictable random number seed, the use of buffer above its limit, unmanaged processor exceptions, allow the use of corrupted code, or allow the unexpected use of sensitive data (patient data, treatment data or encryption keys).

Never trust external inputs

Every data external to the application must be checked before being processed. This includes, but is not limited to, data files stored on disk, user input and data coming from external communication channels (Wi-Fi, Bluetooth, …). For the developers, it means that special care must be taken while handling this data:

• Input files must be authenticated using cryptographic signatures,
• User input must be checked. Some basic principles must be followed:
  • Check data length before copying it into buffers to prevent buffer/stack overflows,
  • Use regex if a specific pattern for input is expected,
  • Sanitize your inputs to prevent SQL injection.
• Always authenticate the peer before exchanging data. Secure protocols must always be used (e.g., Transport Layer Security (TLS) 1.2 at least for network communications)
• All the code impacted by external input must be identified and tested. Fuzzing tools like American Fuzzy Lop (AFL)may help in this process.

Figure 2. AFL tool screenshot

Use of hardware security features

Where possible, use hardware encryption capability on the communication port and specific and secure storage hardware components is recommended.

Pay attention to memory management

Memory management is critical in many applications. Programs that allow dynamic memory allocation without protection may be dangerous as they can lead to errors such as information disclosure or arbitrary code execution if not handled properly. Developers must be aware of the problems related to memory leak, double free, stack management, or dangling pointer dereference. Special care must be taken when using dynamic memory. Prefer usage of smart pointers and test the code to detect memory-related errors (using an instrumentation framework like Valgrind may help).

Figure 3. IDE integrated Valgrind tool illustration

Identify and protect sensitive data

Medical devices and most embedded systems store their data in embedded MMC (eMMC), or other type of flash memories, in an unencrypted form. Keep in mind that even if the memory is soldered to the device, it is easy to read/write/modify its content by soldering a couple of wires.

Figure 4. eMMC memory (image from sparkfun SD Sniffer)

It is often not feasible to encrypt the entire disk for performance reason, but all personal health information (PHI) and secrets (e.g., tokens used to access web APIs) must be encrypted. The cryptographic keys must be stored securely in a dedicated area of the microcontroller if it provides anti-tamper protection, or in a Secure Element (SE). A SE highly improves the device security by providing safe storage, secure key generation and more. Another alternative is to strictly limit the PHI stored on the device.

Figure 5. A SE memory (image: ATECC508A from Microchip)

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

Authors

	Rémi Charrier Business Development Director r.charrier@debiotech.com
		João Budzinski R&D Director j.budzinski@debiotech.com
	Laurent Colloud Software Project Manager l.colloud@debiotech.com
		Gilles Forconi Software Quality Manager g.forconi@debiotech.com

Next steps

Debiotech is glad to have the opportunity to share its knowledge with innovative companies from the MedTech industry. Your feedbacks on this publication are welcome and will be used to update it or to create new publications on topics you care about.

Continue your education on medical device development by:

• Accessing Debiotech historic publications: https://www.debiotech.com/news-grid/
• Following Debiotech on LinkedIn to be notified on new publications: https://www.linkedin.com/company/debiotech-sa
• Contacting us to ask a question or request personalized support: contact@debiotech.com

Debiotech would be proud to be your partner and support you with:

• Medical device design & development services:
  • Software: Digital Health, Firmware, Embedded, SaMD
  • Electronics: Design, Verification and Validation
  • Mechanics: Design for micro-fabrication & fluidics systems
  • Supply chain development and optimization

• Support in medical innovation management:
  • Market analysis and segmentation
  • IP management
  • Business plan consolidation
  • Partnership development