CryptoConsolidationEval

Historical content
This page is retained as a historical record. The described consolidation effort is no longer pursued by the Fedora project. We work towards integrating the various libraries to the operating system, for applications to behave consistently, independent of the crypto implementation.

Crypto Consolidation

Background

One of the strengths of the open source model is the ability to have multiple competing solutions for the same problem in the eco-system, which causes each to refine the other. This same strength is a disadvantage when it comes to customers. The continuing Gnome versus KDE debate is one example. The existence of two different desktops causes healthy competition between the two, however the customer will only really want to run one desktop.

We have a similar situation with cryptographic libraries. There are 3 main libraries used by applications to do various cryptographic operations and a dozen or so minor libraries. Each library has it's own focus, strengths and weaknesses, and each have contributed to it's own niche in the open source eco system. However, having multiple security libraries create burdens on distributions and customers. These burdens include:

• Lack of shared keys. Since each toolkit stores keys, certificates, and trust in their own format, customers are forced to import and export keys on their own to share them. In some instances, there are no easy tools for transporting keys to the other toolkits.
• Maintenance issues. When new attacks are discovered against various protocols or algorithms, customers and distributors have to make sure they patch each and every toolkit that implements that protocol or algorithm.
• Export. Distributors need to get export licenses for their products. Use of cryptography is a major question in export. Fedora base products currently require 30 pages of documentation for their export filings.
• FIPS-140. In order to get certain certifications, products show they are FIPS compliant. Currently there are only 2 open source toolkits that have acquired FIPS-140 certification.

These requirements have drove major commercial OS's to consolidate on their own crypto interfaces. Both Mac and Windows provide OS-level cryptographic libraries that all of their applications use. What is needed is the ability to enable a single library for all the open source applications in a distribution.

For more information on the rational of why we want a consolidated crypot interface and how we expect to get there see FedoraCryptoConsolidation and CryptoConsolidationScorecard.

OpenSSL

Is one of the most well know cryptographic library in the open source community. It supplied the first open source implementation of SSL, and is the base SSL engine for many open source products. Version 0.9.7j of open SSL FIPS 140-2 level 1 validated (released as version fips-1.1.1), a major acheivement for an open source project.

OpenSSL itself is a toolkit of cryptographic primitives. It has support for cracking open OCSP responses, CRL's, looking up certificates, etc. This gives applications the flexibility to implement a wide range of protocols and solutions. Unfortunately it also places the burden of these operations on the application itself. This means each and every application that uses openSSL must supply implementations for these more macro functions.

The use of these primitives also restricts the class of hardware that can be supported by pure openSSL applications. FIPS-140-2 Level 3 hardware, for instance, must supply their own version of openSSL which uses it's own engine in order to

OpenSSL has been ported to a number of platforms, usually using unix/linux compatibility tools.

OpenSSL uses an attribution license.

NSS

NSS is the oldest and most complete cryptographic library, supporting not only SSL, but also S/MIME. NSS has a complete database abstraction layer and PKCS #11 support built in. It has had PKCS #11 support for more than 10 years. This support has been used in the field with both simple smart cards and complexed high assurance hardware accelerators, and handles on the fly insertion and removal of tokens. NSS is able to use key and certificate stores other than it's own using plug in modules, including Microsoft's CAPI on windows, Mac's Keyring on Mac, and even PEM files.

NSS has been FIPS 140 level 2 validated 4 times, twice as an open source project.

NSS operates at more abstract layer, allowing applications to override builtin functions when necessary, but providing base common implementations for these functions. NSS 3.12, for instance, is adding libpkix support. Once complete, existing applications automatically start handling pkix valid paths when validating certificates without modifying the application itself.

NSS guarantees binary compatibility against older versions of the library. It's the only crypto library that uses export symbol versioning so automatic version dependencies work.

NSS uses NSPR as and OS abstraction layer and as an IO module. NSPR allows NSS to interface with the host OSs native support for things like files and threads. On linux, however, this means NSPR brings in libpthreads, even though NSS only needs the thread locking.

NSS uses a tri-license: MPL/GPL/LGPL making it the most flexible library from a license perspective.

gnuTLS

gnuTLS is the newst library. Strictly speaking, gnuTLS is a TLS library, not a generic cryptographic library, but on implementation of TLS on top of libgcrypt. gnuTLS

• supports the latest version of TLS
• supports open source extensions to TLS

gnuTLS does not support any other protocols, most notably S/MIME.

gnuTLS is licensed under the LGPL.

Conclusions

Of the libraries, NSS is the only one that can be made to work with all of our applications, is both FIPS certified and has an open source friendly license. It does have some issues we need to address (removing the NSPR dependency on pthreads, for example), but these issues are smaller than trying to bring one of the other libraries up to the level we need to support all of our applications.

Not every open source project have the same requirements we have, so often one of the other crypto library may be the better choice for that particular project. Our plan is not to try to force open source projects to convert to NSS, but to provide patches which allow their package to be bi-lingual. To aid in this we have started a compat library (["nss_compat_ossl"] ) with allows openSSL applications to convert to using NSS with minimal invasion.

Links

Here are some links to related pages:

1. Crypto Consolidation Scorecard to keep track work in progress
2. Fedora Bugzilla query for all consolidation packages
3. SSL library comparission on cURL site
4. Wikipedia TLS library comparission