Anaconda/Features/Encrypted Boot IPA key Management

From FedoraProject

< Anaconda | Features(Difference between revisions)
Jump to: navigation, search
(Created page with '= Anaconda Encrypted Boot IPA key Management = == Summary == Provide enterprise-class key management support for encrypted devices == Owner == * Name: [Dave Lehman] / [Milos...')
 
(Detailed Description)
Line 14: Line 14:
 
== Detailed Description ==
 
== Detailed Description ==
  
Unclear how we're handling this; need input from security side. I believe initial plan is to expand cryptsetup-luks for admin key, then possibly add LVM changes to move encryption there.
+
Miroslav is waiting for upstream acceptance of some cryptsetup changes, to avoid filing bugs that don't have the initial step as a dependency. 
 +
* Add one or two very small packages ("volume_key" or "volume_key-python", perhaps "volume_key-libs") to the installation image
 +
* Add two kickstart options (he will post a pykickstart patch)
 +
* Use the functionality provided by the volume_key* package to load a certificate from the network, and to store encryption keys or passphrases in a file after creating an encrypted volume.
 +
  He expects the necessary code in anaconda to be < 100 lines.
 +
* Add system-config-kickstart support for the new kickstart options; integrate with other planned changes to the storage configuration GUI, blocked on those.
 +
* Add FirstAidKit support for recovering access to encrypted voluems using the stored encryption keys
  
 
== Target Audience ==
 
== Target Audience ==

Revision as of 17:10, 7 July 2009

Contents

Anaconda Encrypted Boot IPA key Management

Summary

Provide enterprise-class key management support for encrypted devices

Owner

  • Name: [Dave Lehman] / [Miloslav Trmac]

Current status

  • Completed in F11: 50% - cryptsetup-luks changes appear to be in
  • remaining work for this feature will land by F12 beta (~2009-07-28)

Detailed Description

Miroslav is waiting for upstream acceptance of some cryptsetup changes, to avoid filing bugs that don't have the initial step as a dependency.

  • Add one or two very small packages ("volume_key" or "volume_key-python", perhaps "volume_key-libs") to the installation image
  • Add two kickstart options (he will post a pykickstart patch)
  • Use the functionality provided by the volume_key* package to load a certificate from the network, and to store encryption keys or passphrases in a file after creating an encrypted volume.
 He expects the necessary code in anaconda to be < 100 lines.
  • Add system-config-kickstart support for the new kickstart options; integrate with other planned changes to the storage configuration GUI, blocked on those.
  • Add FirstAidKit support for recovering access to encrypted voluems using the stored encryption keys

Target Audience

Enterprise customers want a means by which they can guarantee access to the data on encrypted block devices in employees' systems. This way they still have a way in if the user changes the device's keys/passphrases.


Product Variants / High Level Use Cases

Relevant to desktops/laptops particularly, but depending upon implementation may be interesting for other products as well e.g. to support encrypted databases, medical records protection.

Hardware Architectures

All


Third-Party Dependencies

No

Bugzilla Numbers

   * See Bug 458392 - [RFE] luks: add support for admin keyslot for the prereq from an anaconda POV
   * Bug 488718 - (encrypted_LVM) Support for encrypted LVs in LVM2 & key management (tracker) for a description of work in progress