Bug 591836
| Summary: | RFE: Fedora should support LUKS keys on external devices for volume decryption | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Chris Snook <chris.snook> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 18 | CC: | agk, dcantrell, gmazyland, jhaar, johannbg, lpoetter, lvm-team, metherid, mitr, notting, plautrba, systemd-maint |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-04-09 11:26:46 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Chris Snook
2010-05-13 10:47:04 UTC
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: http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/4132 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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 :-) http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/topic/liaai/tpm/liaaitpm_pdf.pdf 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping (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. |