Optimizing Medical Device Security

A Comparison of DDS, TLS and DTLS Security Standards

**Please note that with the April 2024 release of Connext Professional 7.3 LTS, the functionalities formerly comprising Connext Secure are now available as an optional component to Connext Professional, named Security Extensions.

In September 2022, the FBI reported that 53% of connected medical devices in hospitals have known critical vulnerabilities. Their findings uncovered systematic security failures resulting from poor engineering: Many devices were not “initially designed with security in mind – due to a presumption of not being exposed to security threats.” 

New regulatory scrutiny of medical device submissions is aimed at changing this. The latest FDA guidance for device manufacturers recommends securing interoperability for the device from end-to-end. This includes ensuring secure architectures and identification of risks and controls across interfaces, use cases, and operational states of the system. 

What’s the best way then, to bridge innovation, connectivity and security without adversely affecting performance? How can secure connectivity be addressed and incorporated into device design? What are best practices for secure software communication approaches and technologies to enable innovative, and flexible medical applications that are also secure by design? And what does the Data Distribution Service (DDS^™) standard bring to the table?

Some of those answers are in a research paper¹ entitled A comparative evaluation of security mechanisms in DDS, TLS and DTLS, which compares TLS / DTLS standards against the DDS-Security^™ standard. 

The paper explores the five basic pillars of data security:

• Confidentiality: Assurance that information is not disclosed to unauthorized individuals, processes, or devices.
• Integrity: Assurance that data has not been altered since creation time.
• Authenticity: Security measure(s) designed to establish the identity of a transmission, message, or originator.
• Access Control: Mechanism that enables an authority to control access to areas and resources in a given physical facility or computer-based information system.
• Availability: Assurance that data and resources are accessible and available to authorized users when needed.

This blog post summarizes the conclusions of the white paper. Let’s start by defining the terms.

TLS / DTLS

TLS (Transport Layer Security), based on TCP, was originally published in 1999. DTLS  (Datagram Transport Layer Security), based on UDP, was published in 2006. Their most recent release was published in 2018. They are used by most middlewares to ensure data security. TLS and DTLS are cryptographic protocols that provide secure communication over a network, with TLS being designed for stream-oriented connections, and DTLS for datagram-based connections.

At a high level, both TLS and DTLS provide a level of confidentiality, integrity and authenticity. However, DTLS lacks availability mechanisms since it is implemented over UDP, and TLS achieves some level of availability thanks to the reliability of TCP. Both TLS and DTLS lack granular, data-centric access control mechanisms.

DDS Security

DDS is a proven standard based on a data-centric, publish-subscribe approach to communications. The nature of DDS is decentralization, which provides high reliability and low latency. In combination with Quality of Service (QoS), DDS becomes a powerful framework for communication that can easily adapt to the user's needs.

DDS Security provides an extra layer of security and specifically addresses the 5 pillars mentioned above.

A Comparison of DDS Security and TLS / DTLS

For the first three pillars (Confidentiality, Integrity, Authenticity) both TLS / DTLS and DDS Security make use of the same state of the art mechanisms. DDS Security has a fine-grained, data-centric approach, whereas TLS / DTLS have a channel-centric approach (all or nothing). The divergence comes from the other two pillars:

• Availability – DTLS does not address end-to-end availability, and TLS achieves some level of availability thanks to the reliability of TCP. DDS Security enables different mechanisms for availability, even over UDP. The inherently decentralized architecture of DDS — along with extensive Quality of Service (QoS) features for reliable communications — help to ensure the availability of data access across connected systems, enabling resilient and recoverable dataflows.
• Access Control – TLS / DTLS does not provide granular, data-centric access control mechanisms. With DDS Security, however, through a security overlay (Permissions and Governance documents), you can easily specify access rights for all the participants of the communication. This allows for new systems to be added to the network (with the correct permission files), share keys based on the signed permissions, and begin receiving protected data without any other changes to the network or endpoints.

With the flexibility of DDS, users can achieve low latency, low overhead and simultaneous data exchange between a large number of participants. With TLS / DTLS, the developer must manage the connections and the de/serialization. With DDS Security, the user does not need to manage any of that.

The five pillars above - Confidentiality, Integrity, Authenticity, Access Control and Availability - provide the protective aspects for a connected MedTech device or system. It’s important, however, to also consider one more criteria when choosing the communication layer: Performance. MedTech devices require rapid access to real-time data. When using TLS / DTLS, the transmitted data is encrypted, which results in high CPU utilization, thus slowing down other vital operations. DDS Security provides granularity, offering the ability (through Permissions and Governance documents) to encrypt only selected data, such as patient information or heart rate. This streamlines dataflow and offers CPU and bandwidth gains.

Benchmark Report

RTI has created a benchmark using RTI Connext^® Secure (which is built on DDS) to show a comparison of TLS and Connext's UDPv4 over WAN (Real-Time WAN transport). Highlights of the benchmark include:

• The latency of encrypted data remains constant under 100 ms even for larger, encrypted payloads (5 MB) when using Connext^®. When using TLS, however, the latency goes up to hundreds of milliseconds.
• Connext doubles the throughput for smaller, encrypted payloads compared to TLS. For larger, encrypted payloads, the factor is over 6x.

Another key difference between TLS / DTLS and DDS Security is multicast. Multicast helps you scale your system better by sending every message only once in a 1-to-many scenario. This is not possible with TLS / DTLS, but it is possible with DDS Security.

Figure 1. Multicast use on Connext Secure vs. TLS / DTLS. (source: RTI Connext Secure documentation)

Conclusion

Before choosing the communications for connected medical devices, system architects need to carefully weigh a number of factors. While TLS / DTLS address confidentiality, integrity and authenticity, they don't provide the necessary mechanisms to address availability and access control. DDS-Security provides the necessary data protection and the flexibility for future-forward medtech development across the five security pillars, making it stand up to threats while maintaining the necessary performance for interconnected devices.

Epilogue: Can RTI Help Users Obtain FDA Certification?

As a zero-trust software framework, Connext Secure can help meet the FDA certification criteria thanks to addressing the five cybersecurity pillars. This table provides a further overview of the different Connext Secure features that address the FDA regulatory guidance. In addition, the RTI Professional Services Team offers a number of training, system planning and security assessment features to help customers tackle this important requirement. Customers succeed with Connext.

Source: ¹Technische Hochschule Ostwestfalen-Lippe University of Applied Sciences and Arts (November 2018)

About the Author

Fran Porcel is a Staff Application Engineer at RTI, working for the RTI Professional Services Team in the San Francisco Bay Area. With over seven years at RTI, Fran is a Subject Matter Expert in Medical Software. He trains RTI's customers on the usage of Connext daily, while also helping them architect Connext in their systems. He's also helped customers who have successfully been approved by the FDA.