Getting training on a specific topic seems to provide an opportunity for further education. This means that once you demonstrate expertise in a particular skill, you will likely face more challenges related to it. So be careful what you work with.
Many years ago I had to figure out how to implement the IHE ATNA profile. I have invested quite a bit of time into this project and have become quite an expert at diagnosing TLS issues and configuring Tomcat to support IHE Audit Trail and Node Authentication Profile (ATNA). I first wrote about my experience on the IHE ATNA FAQ.
Java has come a long way since then. When I first wrote the ATNA FAQ, I think I was using JDK 1.4 or 1.5, which did not significantly support TLS 1.0. Now Java has increased its JDK version from 11 to 21. For reasons explained below, I’ll only use 11 in this post (I use JDK 17 for other development).
I’m currently working on fully integrating FIPS-certified encryption into a Java application I’m working on (it’s already integrated for inbound and outbound communications, which I have other uses for). The application runs on JDK 11 in a Spring Boot 1.5 Java application running inside a Docker container on Alpine Linux and has already used Bouncy Castle for cryptographic activities. As I’ll explain in a later post, getting all the details right in that environment is tricky. This is just an introduction to help people understand more about the requirements that need to be met.
Anyone who uses Java and TLS will be familiar with the Legion of the Bouncy Castle (BC) cryptographic library. And if you’ve been working on health information exchange development, you’re probably also aware of NIST FIPS 140-2. Some of you may have used BC in FIPS-compliant mode (or may have had to enable FIPS on Windows servers or elsewhere in your Java code).
There hasn’t been much interest in using FIPS-certified encryption (except in government cloud environments on AWS or Azure), and not much in pure Java software implementations. The reason for using certified cryptographic modules is to ensure that the encryption is secure, and the reason for using FIPS-compliant mode is to prevent the use of other insecure cryptographic functions. This is an essential requirement for systems where potential impacts to confidentiality, integrity, or availability are at least moderate concerns. In the healthcare field, I believe we can all agree that this is at least as important when exchanging medical data. Additionally, the lesser-known FIPS 199 has a federal standard for the term “moderate.”
The straight BC library that supports cryptography is not a NIST certified module. This is an additional step that requires testing by a NIST NVLAP certified laboratory, just as ONC certification is performed by an accredited laboratory. Instead, you should use the FIPS certified version of the Bouncy Castle library. These libraries are largely compatible with non-certified libraries, but they are missing some of the functionality that those libraries have. Because frankly, these features cannot be authenticated. It definitely supports encryption, but may use ciphers that are considered insecure.
The BC FIPS library is currently NIST certified for up to JDK-11. If you look at BC’s roadmap for FIPS-certified modules, you’ll see that the first BC FIPS releases to support JDK versions higher than 11 are 126.96.36.199 and 2.0, both of which should support JDK 17. 2.0 streams are being submitted through testing using: FIPS 140-3, 188.8.131.52 has been tested to FIPS 140-2 requirements. The first NC FIPS 1.x release to be tested on the 140-3 is 1.0.3. FIPS 140-2 is still the minimum requirement for many government agencies (those classified as FIPS Moderate), but those agencies will require FIPS 140-3 certified modules in the near future. There will be no FIPS 140-2 certified products after 2026 (certification expires), and all new products currently being certified are currently being certified under FIPS 140-3.
The Bouncy Castle FIPS module is available for free download through Maven, but the latest and greatest code base is only available to contract holders.
There are other vendors that offer NIST-certified cryptographic modules for Java, but Legion of the Bouncy Castle is probably the best known and most widely used by other respected software vendors (e.g. RedHat, Oracle, etc.). Some Java implementations use OpenSSL, another popular encryption package. I prefer to use pure Java solutions whenever possible, so OpenSSL is not my favorite option. It’s also difficult to configure in Tomcat (I’m not saying Bouncy Castle is easy, but it’s not that hard).
I’ve been bored to tears with the requirements I have to work with and the solution I’ve chosen (BC-FIPS), so future posts will go into more detail on the implementation details, which may result in more Java-based healthcare IT applications. I will take on this view. It would be great if one day all encryption in Health IT was performed by cryptographic modules that were rigorously tested and refused to implement insecure protocols (e.g. SSL, TLS 1.0 or 1.1). However, implementing such encryption will remain difficult until it becomes much easier in Java (and other) applications.