Fedora Crypto Consolidation

Not up-to-date
The crypto consolidation effort is no longer pursued. We work towards making the OS consistent independently of the crypto implementation used by applications and this page is preserved for historical reasons. Note that our later features - Features/SharedSystemCertificates and Packaging:CryptoPolicies - allow consolidation of the CA certificate store and crypto policies on the main crypto libraries we ship.

Fedora Crypto Consolidation - Background

Wouldn't it be neat if you could obtain a digital certificate from a CA using Firefox, and then immediately turn around and use it to ssh to another machine? Wouldn't you like to be able to turn off SSL2 in a central control panel, and be guaranteed that all apps on your desktop would obey that decision? Wouldn't it be cool if every app noticed that you inserted a smart card, and immediately took advantage of it for crypto operations like signing email or setting up IPSec connections? When customers asked if Fedora or its derivatives were FIPS 140 validated, wouldn't it be great to answer an unqualified "Yes"?

Of course it would!

We have an opportunity to address the above issues and to exhibit leadership in the area of open source security by embarking on an effort to consolidate and rationalize the cryptography in Fedora. This document discusses some of the issues with our current situation, and presents a roadmap for making the above wishful thinking into reality.

Present situation

Cryptographic services within the Linux platform are provided by many different packages. These packages attempt to do the same, or similar tasks but are incompatible with one another. Having multiple options causes confusion for ISV developers and complicates legal tasks such as security and export compliance filings. Operating systems from other vendors such as Microsoft and Apple were either designed around a single cryptographic framework or transitioned to one a number of years ago.

The following sections describe the present situation in more detail.

Current libraries

Fedora ships with numerous cryptographic libraries, including:

1. NSS
2. OpenSSL
3. libgcrypt
4. GnuTLS
5. Kernel
6. libcrypt.so (from glibc)
7. libssh2
8. nettle
9. python-crypto
10. BeeCrypt

Further, there is cryptography in the release that does not rely on any of these well-known packages.

Examples:

1. The Samba source tree includes Heimdal, which includes implementations of AES, DES3, etc.
2. The MIT krb5-devel package includes libdes425.so.

This level of complexity has a number of costs that we need to manage, including code maintenance, and support.

Today, since there is no generally agreed upon central crypto library, developers building new apps use the crypto library they have heard most about, or already know. This is a reasonable thing to do, but contributes to the fragmentation of the overall system.

Most apps end up using their own key/credential stores and lack integration with other apps that might benefit from a shared approach.

Apps tend to present their own security UI and manage their own preferences and settings. This means UI between apps is inconsistent, which drives up training, IS training costs, etc. There is no way to “Turn off SSL2 for all apps” in Fedora, or any way to “Use the corporate OCSP server for all apps” with a single click.

FIPS 140

Products that perform cryptographic operations must be formally validated against the FIPS 140 specifications in order to be sold to the US Government. In addition, some businesses use FIPS 140 as a measure of quality of a given technology.

NSS has been awarded FIPS 140 certificates many times.

FIPS validation is also expensive and time consuming. The time it takes to get validations have also been steadily increasing. Multiplying the cost of these validations over even a handful of toolkits would be prohibitive.

Red Hat sponsored validation of NSS, OpenSSL, Kernel, libgcrypt, and OpenSSH in Red Hat Enterprise Linux 5 and 6.

Other Operating Systems

Other operating systems already have some degree of crypto consolidation that meets many of our high level goals.

Apple Mac OS X

Apple's cryptographic framework uses CDSA interfaces, wrapped by more Mac-like interfaces. They use OpenSSL for TLS, and NSS for S/MIME.

OSX apps inherit not only fixes and enhancements in core cryptography, but also fixes and enhancements in UI. Apple has shown how Microsoft Word can take advantage of new smart card technologies and UI simply by upgrading the OS.

The Macintosh has had a centralized keychain for storing application passwords since at least 1994.

Microsoft Windows XP, Vista

Microsoft has probably gone the furthest in achieving the vision of having a single, well-integrated library that all applications can take advantage. Their Cryptographic API (CAPI) is part of core OS, providing cryptography, key management, smartcard support, common UI, etc.

Feature Descriptions

This section lists the features required to simplify and rationalize the cryptography in Fedora.

Medium Term Goals

The libraries that should be preferred instead of arbitrary other crypto stacks are (in the order of the preference):

1. NSS
2. GNUTLS (with nettle as crypto backend, but nettle never used directly by applications)
3. OpenSSL
4. libgcrypt

Future Goals

The future high-level goals should be simple to express (even if the work required is not small):

1. There will be one set of FIPS-validated libraries that all apps in Fedora use for all user-space cryptographic operations
2. Kernel crypto will be separate, but will require integration with user-space crypto keys and preferences. The kernel will need to use a user's private keys (possibly on a smartcard) to set up an IPSec session, for example.
3. There will be one keystore per OS user, shared between applications.
4. There will be a system-wide keystore that will allow admins to set up global support for trusted root certificates (such as the corporate root).
5. Apps will share common configuration settings. If you turn off SSL2, it is off for all apps.
6. There will be one UI framework for error messages, certificate management, key-ring management, password entry, etc.
7. There will be a simple way of entering into "FIPS mode" where only FIPS 140 specified and mandated cryptography is possible. This feature will be primarily used by U.S. Government customers, and some financial industry customers.

Shared databases (key and cert)

Applications need to share certificate and key stores for performing crypto operations. They also need to share certificate stores (including smartcards) for trust.

Examples include:

1. Get a cert using Firefox, use it in SSH
2. Plug in a smartcard, use it to decrypt your hard drive and to sign email
3. Use it to login to your corporate VPN
4. Use your cert to login to a web server
5. Mark your corporate root as trusted, and all apps then trust that root.

Shared configurations

Some configurations should apply to all apps on the system (at least by default). For example:

1. Turning specific cipher suites on/off
2. Turning on/off RSA, MD5, etc.
3. Turning OCSP on/off
4. Setting the OCSP proxy server
5. Setting behavior when the current time is past the nextUpdate time in a CRL (run anyway, disallow connections, etc.)

Applications should be able to inherit these global settings.

These settings should have GUI and CLI interfaces. They should also be in a flat file that can be edited by hand if needed.

Planning for this is still in progress.

Common UI framework

The OS needs to provide a common high-quality user interface for crypto-related tasks (including certificate/token management and prompting about bad SSL certificates) that all applications will use. This will be consistent with OSX and Windows and will reduce development complexity, user training, and support costs. Improvements to the UI can be shipped as a single update, and the improvements will be visible in all applications.

Currently, each application is left to to provide its own UI. Firefox and Thunderbird are using Mozilla PSM (source), a relatively complete and mature package that includes the certificate manager and "Add Security Exception" dialogs. In other applications, the crypto UI tends not to receive the same level of attention and is inferior or nonexistent.

One option would be to standardize on PSM. This would go nicely with the choice of NSS.

Microsoft Vista has an important feature that is closely related to their Cardspace technology. When the user visits a web site that asks for a Cardspace card, the UI changes such that the card selector takes over the UI. Microsoft has made it impossible for normal userspace apps to replicate this behavior. Today, this type of feature isn't possible using X-Windows. There are efforts to create such a trusted path, and we'll need to evaluate them.

Plan Forward

Technology selection

To accomplish the goals of this effort, we will be using the NSS crypto libraries. NSS has been awarded FIPS 140 certificates four times, It is used in client applications like Firefox and Thunderbird, and in server applications such as Fedora Directory Server.

Beyond FIPS 140 validation, we're going to rely on NSS for smart card support, hardware security modules (HSM) support for SSL acceleration and key protection, S/MIME, and OCSP support. Those feature either are less mature in the other toolkits, or don't exist. That's not to say that those toolkits are bad, only that they don't meet the needs of this effort.

Other toolkits such as OpenSSL and GnuTLS have some of these features, but none matches the all the requirements of this project (see CryptoConsolidationEval for more info).

Packages to NSS-enable

1. Apache: Done (mod_nss )
2. PAM pkcs11: Done (pam_pkcs11 0.6 )
3. stunnel
4. CURL: Done
5. wget
6. python bindings: Done python-nss
7. RPM
8. OpenLDAP client SDK and server (done for Fedora 14 and later)
9. Samba
10. MIT Kerberos (in process)
11. NetworkManager
12. OpenOffice
13. postfix
14. tog-pegasus

A complete list of packages and the current state of NSS enabling can be found on the CryptoConsolidationScorecard.

Conversion Tools

One method of porting an application to NSS is to do a direct conversion of openSSL calls to NSS calls manually. One example of this is the conversion of the Apache module mod_ssl to mod_nss. Another example is libcurl which recently accepted a compile-time option to use NSS. This library already had an abstraction layer that supported openSSL and gnuTLS so adding another option was straightforward.

This direct conversion method requires a certain level of familiarity with both the openSSL API and more importantly, familiarity with NSS. The two APIs are similar but take very different approaches to some key areas such as certificate and key management and Certificate Revocation Lists (CRLs). Without knowing how these work in NSS can make a direct port difficult.

To address the shortcomings of the direct conversion method we've started work on a source-code level compatibility library, nss_compat_ossl. This library implements portions of the openSSL API using NSS. The purpose is to limit changes within the target application. It is not expected that no changes will be required in the target application. You can find more information on this library at nss_compat_ossl. The use of the compatibility library has the added advantage of creating a simplier module for upstream suppliers to accept. Not every upstream project would have the same needs a distribution, and may have valid reasons for continuing to want to use other crypto libraries.

NSS Changes

NSS is currently adding 2 new major features: PKIX processing and shared database support .

Once PKIX is complete, all NSS applications will be able to process modern PKI changes based on bridge CA's. These PKIs have been running inside academia and governments for 6-7 years now and are starting to spread into industry. Proprietary OS's have been able to handle PKIX chains for quite a while, but up until now, only very specialized open source applications have been able to use such chains.

Shared database support is a major component in impementing a common world where all your certificates are available to every application. It illustrates the power of using a single toolkit.

Conversion to NSS will automatically add these features to those applications that convert.

Links

Here are some links to related pages:

1. Crypto Consolidation Evaluation
2. Crypto Consolidation Scorecard to keep track work in progress
3. Fedora tracking bug
4. SharedCertStore discussion on OpenSuse wiki
5. Debian-Devel discussion on Crypto Consolidation