From Fedora Project Wiki
(Update, taking ideas from https://fedoraproject.org/wiki/Features/DevCrypto)
Line 20: Line 20:
== Benefit to Fedora ==
== 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.)
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.                                                                                                                                       


== Scope ==
== Scope ==
* A new kernel interface
* A new kernel interface for user-space
* Modifications to major existing user-space crypto libraries to optionally use the new kernel interface.
* 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).
* 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 ==
== 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.
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.


== User Experience ==
== User Experience ==
Line 45: Line 50:


== Release Notes ==
== Release Notes ==
'''fixme''' The kernel implementation of cryptographic algorithms is available to user-space programs, so that they do not need to handle encryption keys directly.
(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.


== Comments and Discussion ==
== Comments and Discussion ==

Revision as of 21:24, 14 July 2010

Cryptography in the kernel

Summary

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.

Owner

Current status

  • Targeted release: Fedora 14
  • Last updated: 2010-07-13
  • Percentage of completion: 10%

Detailed Description

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.

Scope

  • 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.

User Experience

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.

Dependencies

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.

Contingency Plan

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.

Documentation

Not much yet. Upstream pages for the existing implementation are at http://home.gna.org/cryptodev-linux/ .

Release Notes

(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.

Comments and Discussion