Re: [opensuse] Whole disk encryption?
This describes how to have encrypted /boot with single passphrase unlock (rather than twice, once for GRUB and once for Linux). It uses a key file which is on the encrypted volume. http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ The problem at the moment on openSUSE is it seems you can't have non-LVM LUKS volumes (just standard partitions). That poses a problem for encrypted Btrfs, so I wonder how that's supposed to work? The GRUB crypto work seems solid, even grub-mkconfig appears to recognize it's on a LUKS volume, and sets up the grub.cfg correctly. It makes the unencrypted, separate /boot seem antiquated. And also in a Btrfs context where we want /boot snapshot along with /lib/modules so they're in parity, is kinda important. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Mon, 29 Jun 2015 16:01:08 -0600 Chris Murphy <lists@colorremedies.com> пишет:
This describes how to have encrypted /boot with single passphrase unlock (rather than twice, once for GRUB and once for Linux). It uses a key file which is on the encrypted volume. http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
It is Arch specific, dracut does have cryptdevice option.
The problem at the moment on openSUSE is it seems you can't have non-LVM LUKS volumes (just standard partitions). That poses a problem for encrypted Btrfs, so I wonder how that's supposed to work?
The GRUB crypto work seems solid, even grub-mkconfig appears to recognize it's on a LUKS volume, and sets up the grub.cfg correctly. It makes the unencrypted, separate /boot seem antiquated. And also in a Btrfs context where we want /boot snapshot along with /lib/modules so they're in parity, is kinda important.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Two comments here: - UEFI and OPAL 2.0 FDE drives support, and hibernation (generic) - OpenSUSE, Btrfs and dm-crypt encryption support a. I'm still surprised there isn't an open source UEFI program that supports OPAL drives. But aside from that it seems like the TCG should have long ago commissioned this work to get support either baked into all UEFI firmware, or include it on OPAL drives as an EFI binary. Pretty much all of Samsung's SSD's these days are OPAL compliant FDE drives. This means they always encrypt, out of the box. They merely are unlocked by default, so computer facing we don't see the cyphertext that's actually the way data is is encoded on the drive's flash. The other problem we have is lack of kernel support for FDE drives in case of hibernation, is my understanding. The drive is locked in hibernation so there needs to be some mechanism to unlock the drive and reload the hibernation image in an OS agnostic way and then resume. So right now, hardware FDE on Linux just isn't workable. There is an open source project for OPAL support in user space to use these drives strictly as data drives though. And that's still beneficial, especially seeing as it's always on encryption. b. Maybe this has come up on the Factory list (I'm not subscribed)? There really needs to be installer and GRUB support out of the box to support plain partitions being LUKS encrypted with Btrfs on top. This means the installer needs to support creating the layout, but also configuring keyfile (or whatever alternate option is preferred) so that the user doesn't have to enter a passphrase twice at boot time (once for GRUB once for dracut/plymouth whatever). And even more user friendly is better security integration between the DE, passwd and LUKS. There should be an option for a the user passphrase to be one of the LUKS keyslots so that it's possible for a single passphrase to be used for both disk encryption and login, so the user can change their password once and it can instantly be used to either unlock the volume (at boot time) as well as login to their user account. Even more ideal would be shifting user login to early boot to capture login+password data which is then authenticated behind the scenes twice for the two different cases of unlocking the encrypted volume, as well as logging in: that way the user experience is the appearance of being asked for login+passphrase information once to arrive at their desktop. Otherwise encryption just adds barriers that for most users makes it tedious and annoying and prone to error. Naturally separate passphrases for LUKS key slot and user login would still be an option. But by default it's better UI/UX and thus compliance improves and overall security improves if this is default behavior. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Andrei Borzenkov -
Chris Murphy