Red Hat Bugzilla – Bug 591836
RFE: Fedora should support LUKS keys on external devices for volume decryption
Last modified: 2013-04-09 07:26:46 EDT
Description of problem:
I (and many other people) would like full-disk encryption (minus /boot) that's protected by a unique and cryptographically strong key, and we'd like to be able to do it without special hardware. As with all password/passphrase systems, the current passphrase method lends itself to either:
a) using a weak passphrase that's easy to remember
b) using a strong passphrase that's sufficiently hard to remember that you use it in many places
While it's not as secure as a smart card, storing a key on a USB stick that can be easily separated from the computer provides two-factor security, and also allows for other use cases (like server boot keys) when a passphrase is not used.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start anaconda
2. attempt to create an encrypted volume
Anaconda prompts for a passphrase, but does not allow the LUKS key to be stored in a user-configurable location.
Fedora keeps up with the recent flood of data-protection laws and makes two-factor authentication and server encryption possible.
Under F9, I had little difficulty moving swap, /home, and /var to an encrypted volume group, and hacking the initscripts to unlock them with a LUKS key on a USB stick. For international travel I could simply mail the USB stick ahead of me and pass through customs without worry, without having to wipe my laptop. The built-in passphrase-based LUKS encryption in more recent releases, while easier to configure, is less convenient.
The same technique is also useful for servers, if there is no passphrase on the LUKS key. As long as the USB stick is in the system, it boots and works fine with no human intervention, but if for any reason the physical security of the system is in doubt (contractors in the server room, server relocation, BSA raids, etc.) it can be removed, doing no harm to the running system, but preventing physical access attacks which require (re)boots. Some governments now *require* that certain kinds of data be encrypted on disk, even in fortified data centers, so it would be nice to be able to satisfy such requirements with a feature built into the OS, rather than forcing administrators to hack something together or pay someone else lots of money.
Having hacked together something like this in the past, and having the benefit now of LUKS awareness in anaconda and other related packages, I'm happy to actually implement this feature myself, but I'd like some discussion of design details before I start, given the fragile nature of cryptography implementations.
I do not think you need inmplement anything crypto related there.
You can have already passphrase in separate file, you can even use plain device (just there is trick to use -s to limit bytes read in cryptsetup).
If you want the whole LUKS header separate, I have already bug #554119
(I will probably implement it in cryptsetup even without dm-loop in kernel soon.)
So the main problem is that it should react to uevents when adding/removing device with key/passphrase.
Someone used luksSuspend & luksResume through udev events, IOW the system frozes encrypted disk if device with key is removed. It was not implemented properly, but the idea is nice - see my comments there:
The low level tools probably support this, but the higher-level code (crypttab, init scripts, anaconda, GNOME) needs much improvement.
(In reply to comment #2)
> The low level tools probably support this, but the higher-level code (crypttab,
> init scripts, anaconda, GNOME) needs much improvement.
Based on my success hacking up Fedora 9's initscripts to do this for all but root (since I needed the post-initrd initscripts), I'm certain the low-level tools are sufficient. All we need is a little work in anaconda to set it up, and dracut to actually do it.
It is explicitly *not* my intent to do something like luksSuspend/luksResume. I only want a boot key to mitigate physical access attacks and create an authentication factor that is not at risk of being weak or reused due to the frailties of human memory. Also, in the server case, where there's no passphrase, it makes it possible to ensure that the filesystems are unlocked only on a normal boot, and not by a livecd being used to steal data. As annoying and impractical as it might be to do something like this on a server, data protection laws in some jurisdictions are starting to require annoying and impractical crypto setups for systems that hold personal information, so we might as well make it as painless as possible.
Just please note that "coldboot" attacks (scan memory for key after forced reboot) are very easy, so it is not enough to just remove usb key.
(We cannot rely on fact that server wipes memory after reboot here.)
So if the use scenario is: In case of expected problems with physical security - switch off server, remove USB key (in advance!). Then it should help.
If attacker has access to server while encrypted partition is activated, attacker can get the key other way.
(In reply to comment #4)
> Just please note that "coldboot" attacks (scan memory for key after forced
> reboot) are very easy, so it is not enough to just remove usb key.
> (We cannot rely on fact that server wipes memory after reboot here.)
> So if the use scenario is: In case of expected problems with physical security
> - switch off server, remove USB key (in advance!). Then it should help.
> If attacker has access to server while encrypted partition is activated,
> attacker can get the key other way.
I agree that cold boot attacks are still a problem, but mitigating them is beyond the scope of this feature. That's something that needs to be addressed in dm-crypt, and probably needs hardware help (TPM?) for a complete fix.
> I agree that cold boot attacks are still a problem, but mitigating them is
> beyond the scope of this feature. That's something that needs to be addressed
> in dm-crypt, and probably needs hardware help (TPM?) for a complete fix.
(Yes, this is quite out of scope of this BZ :-)
There is no complete fix if encryption is performed by main CPU (key must appear somewhere in memory or cpu register at least - even TPM here not enough).
Anyway, when there is some sensible way how to use TPM, dm-crypt can try to support it.
Btw that's why I mentioned luksSuspend/Resume - this temporiarily removes key from memory, so you can still get some plaintext from memory dump in coldboot (cached pages) but not volume key.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.
More information and reason for this action is here:
One question would be whether systemd's crypttab support adds the proper dependencies such that having /mnt/<label>/blah/blah/key as a path to a keyfile in crypttab properly orders the device after that mount. (There could be other ways to do this, of course.)
If this is going to be looked at, please remember to include TPM as an option. ie instead of installing the key to a USB device, "push" it into the TPM module and automatically API that back out at boot-time. We use it on our Win7 laptops and with the Intel i5/i7 CPUS (built-in AES chips), you don't even realise the disk is encrypted. Seriously - for the majority of the world this is as good as it needs to get. I'd love to see the same option for dm-crypt
IBM has a doc on how to do it - nasty :-)
Wouldn't that only prevent against disk removal attacks, not full-lapto-theft attacks?
It should be fairly easy to add "RequiresMountsFor=" dependencies to the generated cryptsetup services for the key files. That way storing crypto keys on USB keys could be implemented nice and racefree.
This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
(In reply to comment #8)
> One question would be whether systemd's crypttab support adds the proper
> dependencies such that having /mnt/<label>/blah/blah/key as a path to a
> keyfile in crypttab properly orders the device after that mount. (There
> could be other ways to do this, of course.)
THis is implemented in F19 now.