Because of this, we recommend obtaining an existing and well known (D)TLS library to add to your CIP Security software. From cost and license to size and performance, there are several things to consider when choosing the proper library for your software. There are many (D)TLS libraries available from different vendors and sources, but we will discuss four specific ones:
- mbed TLS
- Inside Secure TLS Toolkit (Formerly MatrixSSL)
As far as reputation goes, these four are all well-known and widely used, so you know they offer your company the possibility of being a good building block to help you create a secure product. They are also all written in C and, for that reason, easy to integrate into the environment most EtherNet/IP products are developed in.
This isn’t a direct comparison of the four libraries, but rather a reference point to know what different things to consider when choosing a (D)TLS library.
OpenSSL and mbed TLS: What to Expect from a Free (D)TLS Library
OpenSSL is one of the most popular libraries, plus it’s free and open-sourced. Because anyone can view the code of this (D)TLS library, security-related issues with it have a better chance of being discovered sooner. Dual-license libraries use the same idea, making the libraries free to use as long as the source code they’re integrated in is also published publicly.
However, in most cases, this is not an acceptable license for companies building products using CIP Security, because they don’t want the full source code of their product to be public. They require a commercial library instead of a free one. But there are still other considerations when it comes to a free (D)TLS library. Aside from OpenSSL, mbed TLS is another free library option.
With support also comes documentation, and OpenSSL has plenty of well-written documentation that’s easy to access and use once you get the library up and running. However, it doesn’t provide good introduction documentation to get started and set up. Comparably, mbed TLS provides extensive documentation on how to get set up and get started, in addition to documentation for using the library.
(D)TLS libraries should have a defined procedure that effectively deals with vulnerabilities. This vulnerability management process should include procedures for how to deal with Common Vulnerability and Exposures (CVE). Both OpenSSL and mbed TLS list the CVEs that affect certain versions of their libraries and in what versions these CVEs have been addressed.
The memory footprint of the (D)TLS library is of high importance. Some libraries are specifically designed for embedded devices, and they generally consume less memory—both non-volatile memory and RAM—than libraries designed to run on a desktop computer. OpenSSL is a library designed to be used for a computer and can’t be configured to have a lower memory footprint. Therefore, it has a high footprint, whereas mbed TLS has a low one. However, since OpenSSL is used in more capable and higher performant devices, the memory footprint likely won’t be an issue.
A smaller (D)TLS library designed to be used in an embedded system, like mbed TLS, is written in a way where it’s possible to run without an operating system underneath. However, if you are using an operating system, it should provide all the APIs and libraries that OpenSSL expects, to make it easy to integrate. If the product doesn’t have an operating system or just has a simple RTOS without standardized system calls and libraries, then it would likely make it easier if you use the smaller libraries intended for embedded systems, such as mbed TLS as well as Inside Secure TLS Toolkit and wolfSSL, which are discussed in the next section.
Inside Secure TLS Toolkit and wolfSSL: Commercial Considerations
Commercial (D)TLS libraries are paid licenses that make it possible to sell your CIP Security product without having to disclose its full source code. Inside Secure TLS Toolkit and wolfSSL both offer commercial licenses, though they are also dual-license libraries with a free option available.
These commercial libraries provide professional support that either comes from the vendor or distributor of the library. Both Inside Secure TLS Toolkit and wolfSSL have useful documentation on how to port, setup, and get started. They also come with easy example applications for both clients and servers. The API documentation varies a lot between the libraries but, overall, both are easy to understand.
Vulnerability management processes are integrated into wolfSSL. This means it has a record of all the CVEs that affect it and allows users to check if the issue has been addressed. This way users of the library can see that the makers actively update and correct issues and vulnerabilities in the library.
Inside Secure TLS Toolkit and wolfSSL are designed for embedded devices, so they have a low memory footprint. These embedded libraries don’t make use of an operating system’s infrastructure, and often can be configured to run in an environment with no operating system whatsoever. They generally provide an effortless way to enable and disable functionality, so they can be tailored and configured in the most effective way for CIP Security.
1) Vulnerability Management
(D)TLS libraries should incorporate some form of vulnerability management, as well as the ability to report possible issues to improve their vulnerability management process. There should also be a way to subscribe to updates and changes in the library, so vulnerability fixes are received quickly, instead of forcing users to go check for updates on the library’s website.
There are requirements and key items that (D)TLS libraries must support for implementing CIP Security over EtherNet/IP. This is what you need to look for:
- TLS must be at least version 1.2
- (D)TLS must be at least version 1.2
- Cipher suite requirements as mandated by the specification
- Allows the use of pre-shared keys or X.509 certificates for endpoint authentication
- Allows use of either RSA or ECC public/private key pairs
- Provides data encryption (in addition to data integrity), or data integrity only (null encryption)
Performance is extremely important to implement CIP Security. To implement the TLS protocol, the (D)TLS library needs to perform several supporting cryptography operations and message digest operations. The (D)TLS library can either be ported to use the hardware accelerators or to use code that executes on a microcontroller. This can dramatically improve performance and decrease the memory footprint.
When comparing the performance of mbed TLS on a microcontroller system, using Cortex-M3, to a system running an application processor, using dual Cortext-A8, results showed that the raw processing power of the application processor made a significant difference in performance.
Integrating a (D)TLS Library into Your CIP Security Software
Consider every aspect of (D)TLS libraries we discussed, but also determine your own needs when it comes to CIP Security and do a thorough investigation of what is available. You can review our comparison graph of the four libraries for a quick overview of our recommended considerations:
To learn more about CIP Security, including more in-depth information on (D)TLS library considerations, download our Practical Guide for CIP Security Device Developers: