Cryptography in the kernel
The kernel implementation of cryptographic algorithms will be made available to user-space programs, so that they do not need to handle encryption keys directly.
- Name: Miloslav Trmač
- Email: <email@example.com>
- Targeted release: Fedora 14
- Last updated: 2010-07-13
- Percentage of completion: 10% of all we'd like to do; 30% of the minimum we'd like to do for Fedora 14.
The kernel cryptographic algorithm implementation ("kernel crypto") will be made available to user-space programs (current plan is to add a
/dev/crypto device). This allows user-space programs to use the FIPS-validated cryptography implementation, and to move all private and secret keys to the kernel. If possible, existing cryptography libraries will be extended to support using kernel crypto, probably not by default (e.g. only when running in FIPS mode, or when manually configured to use the kernel crypto).
The kernel crypto will be, if necessary, extended to allow moving as much crypto implementation to the kernel as possible.
Benefit to Fedora
When private and secret keys are stored in the kernel, and suitably configured, it is not possible to retrieve the keys even by applications that are using them to perform cryptographic operations. Thus a compromise of the application, or any other application running as the same user, does not compromise the keys. For example, an exploit of httpd would not allow the attacker to copy the SSL private key from the machine. (The attacker could still modify the running server to alter responses to incoming SSL requests, but only as long as the exploited httpd is running.)
Moving the crypto implementation to the kernel also allows reliable auditing of the crypto (e.g. auditing of all processes that use the SSL private key).
Separation of private and secret keys and the crypto algorithm implementation from user-space programs is also required by the proposed FIPS PUB 140-3 and will be required by the US government.
- A new kernel interface for user-space
- An user-space library encapsulating access to the kernel interface
- A new user-space component for long-term key storage (or at least initializing a wrapping key used for the long-term storage).
- As much as time allows, modifications to major existing user-space crypto libraries to optionally use the new kernel interface.
How To Test
After enabling the kernel crypto implementations in user-space (e.g. enabling FIPS mode), test cryptography. Particular aspects to test are SSL (using all affected user-space implementations) and password verification. A test suite of the kernel interface is being developed, and existing test suites of cryptographic libraries will be very useful for validating the modified implementation.
Using kernel crypto is not planned by default, so there should be no impact on most users. Users enabling kernel crypto may need to import existing long-term private or secret keys (SSL private keys in particular) into a different key storage mechanism.
The major dependency is upstream acceptance of the kernel interface.
This feature does not depend on other Fedora features. Packages that depend on user-space crypto libraries should not need to be changed.
If major problems arise with the user-space modifications, they can be reverted. The additional kernel interface should not by itself break anything, but it can be of course reverted as well.
Not much yet. Upstream pages for the existing implementation are at http://home.gna.org/cryptodev-linux/ .
(Additions and other changes to these notes are highly likely.)
The kernel implementation of cryptographic algorithms is available to user-space programs, so that they do not need to handle encryption keys directly and the keys are protected from user-space exploits. [If implemented: Applications using SSL/TLS through [list of libraries] automatically take advantage of this feature.]
To enable the kernel implementation, run the system in FIPS mode.