From Fedora Project Wiki

Encrypted Filesystem Support

Summary

Allow users to encrypt filesystems.

Owner

  • Name: PeterJones, DavidZeuthen, KarstenHopp, FlorianLaRoche, DavidLehman, JeremyKatz

Current status

  • Targeted release: Fedora 9
  • Last updated: 2008-04-07
  • Percentage of completion: 100%

Complete

Must Fix

Should Fix

Detailed Description

Support the use of encrypted filesystems for anything other than /boot using cryptsetup and LUKS. This includes install time creation/configuration, as well as integrated support in mkinitrd and initscripts (others?). Currently we are only pursuing support for encrypted devices using cryptsetup/LUKS.

Benefit to Fedora

Users get the added security of having their personal data encrypted. This is of particular importance for laptop users.

Scope

The following packages must be modified:

  • Anaconda must support installing the OS onto an encrypted root filesystem
  • Mkinitrd must support creating an initrd that is able to unlock and boot using an encrypted root filesystem; see Bugzilla #124789
  • Very early in the boot process, some tool provide an internationalized prompt for an encryption key; see this mailing list thread and note that the better startup effort may provide the ability to implement this
  • Mkinitrd's grubby must be able to deal with encrypted partitions; see Bugzilla #124789

Test Plan

  • Verify that encrypted filesystems keep working when device names change
  • Verify that encrypted swap works
  • Verify that encrypted root works
  • Root on partition
  • Root on logical volume
  • Root on software RAID device
  • Boot process and key on removable device
  • Verify that a system with an encrypted root and swap can resume after suspend to disk
  • Verify that all of above can be configured at install time
  • Verify that encryped hotpluggable devices work
  • Verify that passwords entered on non-US keyboards during install (or when system up) work at boot time (I can test on the following, add yours and your name in brackets)
  • DE (AndreasThienemann)
  • SE (Patrick Ernzer)
  • fails on F9 alpha, see Bugzilla #429358
  • Verify that rescue of encrypted installs work

User Experience

Santiago wants to protect the personal data on his laptop from physical theft.

Taru works in an IT department that supports laptops. She wants to be able to deploy a Fedora installation with encrypted root, swap and home partitions.

Dependencies

Several bugs have been referenced above. (current status)

Contingency Plan

Disable the encrypted device support code in anaconda.

Documentation

  • Red Hat Magazine has details about the work done within the Fedora Project to support encrypted disks.
  • a HOWTO about creating an encrypted Physical Volume (PV) using a second hard drive and pvmove
  • man 5 crypttab

Release Notes

Installing to encrypted volumes (including the root) should now be supported. There is no configuration tool for adding/removing keys from volumes at a later time or otherwise doing modification of the encryption.

Notes

There are several potential techniques for obtaining a root filesystem key. These techniques include:

1. Nash can prompt for the password. 2. Both the key and boot partition can exist on a removable USB device; see Bugzilla #124789, Comment #58 and Linux Journal's Encrypt Your Root Filesystem . 3. Nash can prompt for a password that is used to unlock a certificate containing the key to use. 4. The key can be secured with using a TPM chip. This raises the problem of dealing with a TPM chip that breaks. Also, an alternate technique must be provided that does not require TPM hardware.

Note that it may be possible to store keys for non-root encrypted filesystems on an encrypted root filesystems. This ensures that a user only needs to enter one key to unlock any number of encrypted filesystems. The /etc/crypttab support in Fedora already supports this.


Sophisticated Key Management

Not neccesary for first implementation but aspects to keep in mind while designing the first implementation.

Empiric rules (obeying them makes life easier in the long run):

  • Use X.509 certificate-chains: so e.g. unlocking the master-cert for a specific platform (i.e. computer) with a passphrase unlocks all certs for each specific device and hence the devices themselves.
  • Experience shows that a four layered approach is best balanced between expandability and complexity: e.g. organisation -> class of platforms (servers, desktop PCs, laptops etc.) -> specific platform (i.e. computer) -> specific device (e.g. hda1).
  • Do not mix cert-/key-chains for persons and cert-/key-chains for hardware:
  • The former can be utilising a SmartCard
  • The latter can be utilising a TPM
  • Keep user-keyspace and platform-keyspace strictly separated and clearly define linking between the two, if neccesary.
  • Experience shows a three or four layered approach is balanced between expandability and complexity for personal keys as well: e.g. organisation -> class of persons (admins, users, special users) -> specific person.
  • The organisation cerificate can be the same for both certificate chains, creating a bi-parted 4/3 layered certificate tree with a shared root.
  • The organisation cerificate can be either issued by a mini-CA running in the organisation or by an official CA.
  • In the end it is sufficient to be able to use certificates/keys provided by some crypto infrastructure based on e.g. smartcards, TPM etc. satisfying above needs.

Corporate and Government Use

The ability to create and use encrypted partitions, logical volumes and filesystems during installation (i.e., to encrypt everything but /boot) eases creating a fully enrypted OS installation. This is important for many notebook users. In some environments encryption is mandatory.

Of note, the U.S. Government seems interested in widespread use of encrypted disks on laptops. See Protection of Sensitive Agency Information and U.S. Government Contracts 10 Vendors to Secure Mobile Data .

Cryptographic Filesystem Techniques

Preferred Technique

  • dm-crypt adds a crypto target to the device-mapper that provides transparent encryption of block devices using the new Linux 2.6 cryptoapi. dm-crypt doesn't seem to be the right choice when it comes to encryption of home directories on multi-user systems as each user would need his own partition in order to get it encrypted with his own password. Although it is possible to use several different passwords for the same partition with cryptsetup-luks, each password unlocks the whole partition and not only this users files.

After getting input from our sales and consulting teams dm-crypt is the preferred encryption method. Different encryption for each users homedirs on server machines isn't required as access to others users homedirs can be restricted by setting permissions, acls and so on. dm-crypt can do everything that's required on single user systems such as laptops.

Other Techniques

  • eCryptFS is a native Linux filesystem. eCryptFS stores cryptographic metadata in the header of each file written, so that encrypted files can be copied between hosts. It is possible to bind-mount existing directories with distinct passwords to different directories. Users can see each others files in these directories, but as they used different passwords the others files keep encrypted. As eCryptFS uses the stacked filesystems interface it can be used on NFS mounts as well as on local partitions or directories.
  • EncFS provides an encrypted filesystem in user-space by using FUSE. fuse-encfs packages are in F7.
  • Red Hat Magazine on EncFS: http://feeds.feedburner.com/~r/RedHatMagazine/~3/124593282/
  • FUSE isn't a cryptographic filesystem but it makes it possible to implement a fully functional filesystem in a userspace program.
  • Some Laptop manufacturers offer Laptops with encrypted harddisks. This is done in BIOS and maybe some additional hardware. The disadvantage is that the used crypt algorithms are mostly unknown and might be insecure. Another disadvantage is that you can't use the harddisk in another laptop (p.e. if the laptop is replaced/broken) of different brand.
  • Here is an example why trusting hardware encryption might not always be such a good idea.
  • Karel Zak wrote a patch to support cryptsetup directly with mount/swapon/swapoff. It doesn't look like mount can find encrypted devices by their luks-UUID with this patch.
  • A patch for e2fsprogs-1.39 which adds support of LUKS-UUIDs to libblkid. (Included in e2fsprogs-1.40)
  • As one of the usage cases is an IT department rollout, this feature should offer easy integration for using a company/department key in addition to the individual key. An employee might otherwise knowingly or unknowingly encrypt company data that would be inaccessible to the owner of the system.
  • pam_mount is the quite certainly required pam module to encrypt the partition on login (gdm, kdm, ssh, shell, etc.) via the general user login password. The only real situation where it does not work seems to be ssh-pubkey-authentication.

Thanks

Many thanks to Florian v. Samson, BSI for the excellent input.

Retrieved from "https://fedoraproject.org/w/index.php?title=Releases/FeatureEncryptedFilesystems&oldid=474180"