DICOM Part 15 Security and Medical Device Software

DICOM Part 15 Security 🔗

DICOM version 3.0, finalized in 1992, offered no security extensions for applications
running on open networks. By 1999, as malware attacks on institutions gained notoriety, safeguarding personal health information (PHI) and personally identifiable information (PII) was no longer just the responsibility of IT departments. If you’re a programmer with questions about Part 15, we can help.

Use of encrypted channels under DICOM 🔗

The standard actually talks about three use-cases:

1. SYSLOG-TLS, the protection of confidential data in the audit trail
2. S/MIME, the protection of confidential data over email and SIP
3. DICOM-TLS, the protection of confidential data in transit between network services

It does not offer guidance on related security topics:

Domain name lookups are neither confidential nor trustworthy on an open network 🔗

This is only relevant if DICOM connections made across the open Internet are expected to meet confidentiality rules. If you require this, then you're probably more interested in tunneling a VPN between two hosts or networks. The DICOM working group is still in draft stage about this, but SaMD use-cases expect both ends of that tunnel to use a secure domain name (DNS) server.

Unsophisticated denial-of-service attacks can impair any service on an open network 🔗

Because networking infrastructure can deliver far more connection attempts than our software can handle, automated attacks can focus unspecific traffic on any publicly-available service. Public sites rely on reactionary firewall rules blocking IP addresses and subnets -- often, with cloud services, which can geographically redistribute those focal points, you won't even notice DoS attacks.

Key management 🔗

The hardest problem in cryptography. As mathematicians agonize over the computational infeasibility of brute-force attacks on their cryptosystems, comparatively little ink is spilled distinguishing good key practices from bad ones. In fact, the prominent NIST SP 800-57 won't even get into the design and testing of ways to store keys. You will mostly see people worrying about FIPS-140 revisions 1, 2, and 3 when their software needs to interact with hardware security modules. So, unsurprisingly, DICOM Part 15 specifically calls key management out-of-scope.

Why am I bringing it up? Because certificate management is, in part, key management. The ways that our systems change when certificates expire or become revoked are key management problems, and in-scope when talking about TLS. This article won't cover backup and destruction of keys.

Encryption at rest 🔗

In the US, HIPAA and HITECH (rather than FDA regulations) legalize the need for best practices guarding PHI/PII. It reads like a legislative reaction to the fallout of a lost or stolen laptop. Unlike the DICOM standard, it offers no advice on PHI in-flight.

Some background 🔗

The important middle protocols on a hospital network are TCP/IP, TLS, and on top of those, DICOM -- Digital Imaging and Communications in Medicine. Medical devices (including software-as-a-medical-device) connect reliably via TCP -- Transmission Control Protocol -- passing imagery and metadata in three kinds of formats:

• proprietary structures (difficult to debug)
• emerging open structures (easy to debug RESTful session-based protocols like DICOMweb)
• legacy open structures (DICOM binary, what your application already speaks)

DICOM Part 15 builds TLS -- Transport Layer Security -- version 1.2 into the
connections between clinical services, bringing these security concepts into
medical imaging:

• End-to-end protection from eavesdropping
• Authenticated encryption
• Certificate-based trust

But these come with overhead: while the amount of CPU is vanishingly small, expect quite a bit of design and maintenance, with some FDA-recommended attention to [between-release patching]. So, as of 2022, some major equipment still speaks DICOM without implementing Part 15. Yet, automated ransomware attacks prove that no institution is resourced to fully protect its network.

What does it mean to comply with DICOM 2022 for audit messages transmitted on the network? 🔗

SYSLOG is a venerable network-wide log centralization protocol. It has no
special considerations for medical imaging. Kept as simple as possible for the twenty years between its adoption and eventual standardization, it only exists to move log messages (in the forensic context, evidence) to a central log server. DICOM requires encryption be implemented on the channel between medical equipment and the destination of auditing messages. As noted above, the DICOM working group is still drafting this. For example, RFC 5425 states that TLS 1.2 is required to be supported for SYSLOG, specifically TLS_RSA_WITH_AES_128_CBC_SHA, yet DICOM doesn't mention that RFC.

SYSLOG is a good place to introduce TCP. Very early in UNIX networking history, log entries were sent over connection-less UDP protocol. On early hardware, programmers worried about the overhead of keeping stateful TCP connections open. TCP provides these benefits over UDP:

• Congestion control. Since SYSLOG is capable of producing an unlimited stream,
  TCP offers guardrails for traffic on the rest of the network.
• Reliable transmission or reliable notification of failure, where UDP is
  capable of dropping packets invisibly. SYSLOG itself has special
  dispensations for systems where this is only desirable some of the time.

NOTE: If you need a version of TLS earlier than 1.2, DICOM draft 2022b is ambiguous about whether you can downgrade if still consistent with RFC 5424.

What does it take to comply with DICOM 2022b over email? 🔗

NOTE: DICOM 2022b lumps both email and SIP under S/MIME. I'm leaving SIP out of this, it's exotic but we might come back to it if an application of SIP in healthcare appears on the horizon.

S/MIME is an IETF standard to introduce security elements as email attachments. Early email lacked an option for attachments, which is now universally called MIME. S/MIME is optional and not deployed widely. S/MIME uses certificates to authenticate the sender, and end-to-end encryption to ensure confidentiality. Surprisingly, it took off inside corporations (where workforce-wide adoption requires software to adapt), not among the general public (where people can choose to adapt to software, and the advantages of S/MIME could defeat the low barrier to unsolicited spam messages).

S/MIME is a good place to introduce certificates -- it shares X.509 certificates with TLS. Arriving with in the late 80s, X.509 noticeably predates web browsers and TLS. The design characteristics of certificates are:

• Simple to validate
• Difficult to forge
• By signing a certificate, you confer trust in it
• Only some certificates may sign other certificates
• The hierarchy is strict

X.509 certificates are ubiquitous and unlikely to be obsoleted anytime soon. Some of the design choices with X.509 will be important later:

• A binary format represented in ASN.1, which is then base64 encoded into text. This is the PEM format common to Apache.
• Programmers commonly understand that, in text form, a concatenation of certificates is valid and called a "chain"
• Since the certificates demonstrate cryptographic trust in a heirarchy, chains are useful for reinforcing trust. In practice, that's the only use for certificate chains.

While the web contains many good articles on the specialization of X.509 chains for use between web servers and browsers, S/MIME and binary DICOM use neither. If your application sends email, DICOM compliance usually adds three functions beyond routine email:

• Platform support for arranging S/MIME content.
• Interfacing with a public-key infrastructure (a directory service) to acquire the certificates of email recipients.
• Protecting the integrity of attachments with a cryptographic hash. DICOM permits you to calculate the hash either before or after applying encryption. The best practice is to sign after encryption.

If your application receives email, in addition to the above:

• Check certificates for validity, and check certificate trust against a root.
• Handle exceptions in a way that alerts the user of leakage of PHI

The design of email systems does not enjoy a good reputation and S/MIME is no different. There are plenty of well-researched problems with X.509 and even more with S/MIME.

DICOM-TLS 🔗

Coinciding with the deprecation of TLS versions 1.0 and 1.1, DICOM now wraps TLS 1.2 only. Some legacy equipment and operating systems are incapable of TLS 1.2; you don't have a lot of options to improve those. Here's how to spot them -- in 2013, the standard mandated a small subset of enciphering options for TLS connections:

Generation	What this is called to DICOM 2013 and 2018	What this is called to OpenSSL
Legacy	TLS_RSA_WITH_3DES_EDE_CBC_SHA	DES-CBC3-SHA
Preferred	TLS_RSA_WITH_AES_128_CBC_SHA	AES128-SHA

In 2022, these are no longer future-proof and the DICOM standard has shown good judgment to abrogate its opinions on ciphersuites. You'll see three generations of DICOM security implementations:

• No TLS implementation at all
• TLS 1.1 or lesser
• TLS 1.2 or later

Appendix: An example public-key infrastructure 🔗

This is a minimal example using standard tools; just enough to setup an
environment for automated tests. The command-line tool that accompanies the OpenSSL library is used widely.

If you're implementing this for yourself, here are some tips not found very
widely online:

• Use an OpenSSL config file for each participant. If using release v1.1 or
  later, some config can be shared using an "include" directive. This file is
  more convenient than command-line options like days and, especially,
  extensions. There are some warts to this format:
  • In some fields, you cannot mix semicolons and commas.
  • Debugging OpenSSL config file syntax is a mix of C error messages and some hints about which line in the config file is troublesome.
  • Unless you use the config argument, the default system openssl.cnf file is pulled in. You don't want this. You want to check a config file into source control and work as independently from the test-running system as possible.
• Match the certificate authority in your testing to what you expect from
  hospital IT, rather than general values for serving public web sites. These are different use cases.
  • Feel free to generate expired certificates, certificates with 365-day
    expiry, certificates with 900 year expiry. Perhaps the greatest
    benefit/cost to this appendix is knowing what your app does with an expired
    certificate.
• You can build your own version of OpenSSL for testing that implements weak and deprecated ciphers:
  • This is mostly useful when your service is speaking with a legacy system,
  • Especially useful when you need to determine which SSL error messages are benign (due to deprecated ciphers) versus malignant (evidence of security problems).
  • Note that modern OpenSSL builds turn off deprecated features, so compiling it yourself might be the only way to interface a legacy product with a more modern server.