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: <firstname.lastname@example.org>
- Targeted release: Fedora 14
- Last updated: 2010-07-13
- Percentage of completion: 10%
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.)
- A new kernel interface
- Modifications to major existing user-space crypto libraries to optionally use the new 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).
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. Running existing test suites of cryptographic libraries would be useful as well.
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/ .