Features/CryptographyInKernel

From FedoraProject

< Features(Difference between revisions)
Jump to: navigation, search
(Release Notes)
(dropped from Fedora 14 re: https://fedorahosted.org/fesco/ticket/444)
 
(8 intermediate revisions by 2 users not shown)
Line 2: Line 2:
  
 
== Summary ==
 
== 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.
+
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 or include their own implementations of the algorithms.
  
 
== Owner ==
 
== Owner ==
Line 9: Line 9:
  
 
== Current status ==
 
== Current status ==
* Targeted release: [[Releases/14 | Fedora 14 ]]  
+
* Targeted release: [[Releases/? | Fedora ?]]  
 
* Last updated: 2010-07-13
 
* Last updated: 2010-07-13
* Percentage of completion: 10%
+
* Percentage of completion: 80% of the minimum we'd like to do for Fedora 14 (not counting porting all existing user-space libraries); not yet accepted upstream.
  
 
== Detailed Description ==
 
== Detailed Description ==
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 small process initializing a wrapping key used for long-term storage run on system start
 +
* 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 42: Line 47:
  
 
== Documentation ==
 
== Documentation ==
Not much yet. Upstream pages for the existing implementation are at http://home.gna.org/cryptodev-linux/ .
+
[http://fedorapeople.org/gitweb?p=mitr/public_git/cryptodev-linux.git;a=blob;f=crypto.4;h=e907e2f7742bda407ae2bea12b397632e5cd7ec5;hb=documentation ioctl interface man page] describes the low-level interface; most applications should use the implementation through one of the existing crypto libraries, or through the new <ncrypto.h> library, not directly.
 +
 
 +
Upstream pages for the existing implementation are at http://home.gna.org/cryptodev-linux/ .
  
 
== 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 ==
Line 51: Line 62:
  
  
[[Category:FeatureReadyForWrangler]]
+
[[Category:FeaturePageIncomplete]]
 
<!-- When your feature page is completed and ready for review -->
 
<!-- When your feature page is completed and ready for review -->
 
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
 
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
 
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
 
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
 
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
 
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Latest revision as of 21:49, 3 August 2010

Contents

[edit] Cryptography in the kernel

[edit] 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 or include their own implementations of the algorithms.

[edit] Owner

[edit] Current status

  • Targeted release: Fedora ?
  • Last updated: 2010-07-13
  • Percentage of completion: 80% of the minimum we'd like to do for Fedora 14 (not counting porting all existing user-space libraries); not yet accepted upstream.

[edit] 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.

[edit] 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.

[edit] Scope

  • A new kernel interface for user-space
  • An user-space library encapsulating access to the kernel interface
  • A small process initializing a wrapping key used for long-term storage run on system start
  • As much as time allows, modifications to major existing user-space crypto libraries to optionally use the new kernel interface.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] Documentation

ioctl interface man page describes the low-level interface; most applications should use the implementation through one of the existing crypto libraries, or through the new <ncrypto.h> library, not directly.

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

[edit] 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.

[edit] Comments and Discussion