I know you can do FDE with LUKS but would prefer a more enterprise solution where I can store a recovery key centrally that a user can’t remove.
- A novice user fatfingering `cryptsetup luksRemoveKey`? Sounds extremely unlikely.
- A determined user trying to deliberately destroy information? A lot of things are easier, e.g. `dd if=/dev/zero of=/dev/sda` to `shred important_document.pdf`.
The only thing that would protect against most accidental-destruction scenarios is not giving the users root access, and then you don't have to worry about users removing LUKS keys anyway.
The keys for the drives are stored on an encrypted USB key, and the key for the encrypted USB key is stored on the root SSD.
I wanted something where i could boot unattended, and at the same time i wanted the possibility to destroy the keys and render the disks useless.
I have an encrypted backup of the keys, stored outside of the encrypted disk arrays.
Bonus points if it's possible to install to a partition in existing FDE container (saves a /home backup-restore external drive round trip).
> I know you can do FDE with LUKS but would prefer a more enterprise solution where I can store a recovery key centrally that a user can’t remove.
luks
>what do you use to manage
cryptsetup
>prefer a more enterprise solution...
You have exotic needs, I doubt there is any open source solution that fits, you have to write your own.
You can start by reading this arch page: https://wiki.archlinux.org/index.php/dm-crypt/System_configu...
The PR started 3 years ago: https://github.com/zfsonlinux/zfs/pull/4329
Its purpose is to protect data at rest, and if you keep it available in its unencrypted form, you're not gaining anything from it.
Regular users can't mess with LUKS settings.
> a more enterprise solution where I can store a recovery key centrally that a user can’t remove.
The enterprise solution is to not give users administrative privs.
[0] https://github.com/agherzan/yubikey-full-disk-encryption
Not that it will prevent any dedicated user with root rights from locking you out of the data if they wish to. It just raises friction from a simple luksRemoveKey
Use whonix itself and read the privacy guides in its wiki if you are concerned with privacy beyond FDE.
Now I want to put in a larger hard drive and clone the current drive on to it. Without disk encryption I could use clonezilla or other tools. With disk encryption enabled I can't seem to do anything to clone.
What is a solution?
prepare an encrypted partition in the new disk and mount both origin and destination with cryptsetup.
now use clonezilla to clone the partitions, not the drives.
You might be able to do a fresh install (same version) and then copy over it with your existing installation. You'd have to mount both partitions.
alternativly, clonezilla should be able to back up your partition if you cryptsetup open it but I've never used clonezilla so I don't know for sure
Back everything up first.
- Boot to a live disk.
- DD the disk from the first sector to the end of /boot over to the new disk.
- open your preferred partitioning tool to fix the GPT (as no backup GPT will be present on the second disk)
- remove the partition denoting crypto-vol1 from the second disk - note the first sector
- add a new partition starting from the original start of crypto-vol1 to the end of the disk
- FSCK the partition /boot sits on
- create a second crypto volume on the new partition on the second disk
- create a single Physical volume on Crypto-Vol2.
- add the PV to the same Volume Group as the PV containing Crypto-Vol1
- PV Move everything from Crypto-Vol1 -> Crypto-Vol2
- extend your logical volumes to the desired length with lvextend, and complete the work with your filesystem's resize tool
At this point all your data is present on the new disk
From here you'll want to mount the filesystems and chroot into the system - you'll need to edit /etc/crypttab replacing the entry for Crypto-Vol1 with the UUID for Crypto-Vol2. Then you'll need to regenerate your initramfs to load the new crypttab. This will allow you to boot from the system on the new disk.
I've likely forgotten something here - It's quite an involved process - but not impossible.
A user who wants to destroy data can do so regardless. Storing a key centrally only guards against accidental loss of the key.
The tricky bit is if GRUB breaks (hint: GRUB looks for every opportunity to break. If it can break, it will) and you have to chroot into an encrypted LUKS partition. That's where your average user will be SOL. Not sure how the recovery process would work for Bitlocker or FileVault.
Could anybody comment on the convenience of Linux encryptions (eg. LUKS)? In Windows, encryption is totally transparent to users (I need only to type the account password). I wouldn't mind typing in two passwords, other users on the systems not so much.
There are more automated ways to do the conversion now. Here's the first one I found while searching for my own blog posts above: https://www.johannes-bauer.com/linux/luksipc/
You have to decrypt the hard drive to reach the login screen, and other users would have to do the same as well. You don't need to share any of those two passwords, since LUKS has up to 8 password slots I believe.
With transparent encryption, Windows decrypts the disk at boot using the TPM. Prior to login the disk is already mounted (decrypted).
It provides an easy way for enterprise to say, "yes- we have FDE".
Edited to add: The best I could find was this discussion: https://www.reddit.com/r/sysadmin/comments/5fllep/whats_the_...
So, then, after installation, yes, I could see how that would be a nightmare. I have never attempted it!
If one cares about SecureBoot then this package automates everything: https://github.com/andreyv/sbupdate (it's setup only once and works later without supervision).
Not really. OEM installs have it, but Windows 10 Home doesn't. If you're on an OEM install and decrypt the hard drive once, you won't be able to re-encrypt it without paying for a Pro upgrade. That mistake costs $100.