Full Disk Encryption (LAPTOP users only)

[Hu]

If you do not have a backup mechanism for opening the drive, yes. I was looking only at the perspective of enabling unattended boot. For recovery in the event of a drive failure, you would also want to have a separate copy of the key file (preferably stored off site), or have the drive also accept a password you memorize.

[eccerr0r]

Anyone actually do this? :D

What do people do for servers in this case, assuming the main reason for encryption is for ensuring used drives do not contain recoverable data? Or do they just bite the bullet and password or keep a USB key with the encryption key on it (and eat the USB key if it fails... which isn't too bad as a 8MB USB key will be plenty big)?

I figure that for the server theft paranoia case, 2FA is needed (password protection with key on another drive) or perhaps password is sufficient, just that automated boot won't be possible.

[steve_v]

eat the USB key

For the record, micro-SD cards (in a USB-key reader perhaps) are much easier to chew. They also taste like chicken.

[pa4wdh]

What do people do for servers in this case, assuming the main reason for encryption is for ensuring used drives do not contain recoverable data? Or do they just bite the bullet and password or keep a USB key with the encryption key on it (and eat the USB key if it fails... which isn't too bad as a 8MB USB key will be plenty big)?

My server is partially encrypted. The regular root is unencrypted so it can boot unattended. Nothing useful runs there, other stuff runs in containers which use encrypted lv's for storage.

For the encryption i use LUKS and a keyfile. The keyfile is password protected and stored on a Corsair PadLock2 USB stick with a 9-digit PIN. The stick is actually 8GB but i use just a few KB.
As an emergency backup i also have the keyfile printed in base64 format including a hash for the full file and for every line (and a small script to generate them) so it easier to spot/correct errors (which will be there when you manually type base64 ). This backup is in my car, so not physically close to the server. And yes, i did try the emergency procedure

[Leonardo.b]

On my laptop I have an encrypted partition for my personal files. I might do full disk encryption out of simplicity, but I never bothered to change.

I think USB pendrive have some magnetic component inside.
If you eat magnets, they may stick together inside your body, stuck somewhere, and kill you.
I don't raccomand this.
To eat an SD card should be much safer, IMHO.

[pjp]

One compromise approach for servers would be that the server has Full Disk Encryption for all the regular Linux data filesystems, and each drive has one unencrypted partition containing the keys for drives other than itself. Then any one drive in isolation cannot be used to recover data, but given an encrypted drive and its key-holding partner, the encrypted drive can be unlocked unattended. This guards against the warranty replacement / failed drive scenario decently well, assuming you only ever have one drive fail at a time. It provides no protection if the server is stolen in full.

One more security based argument in favor of separate file systems. I find it sad that decision makers have used the original need of disk space to side-step the security advantage of separate file systems.

What do people do for servers in this case, assuming the main reason for encryption is for ensuring used drives do not contain recoverable data?

Unrelated to disk security, I have seen web servers that required a password / passphrase to continue booting.

[eccerr0r]

Unrelated to disk security, I have seen web servers that required a password / passphrase to continue booting.

I do recall this issue when I first tried setting up an SSL server. I recall SSL keys should be password protected...hence leading to require a password to start webservers. Of course subsequently this really isn't always necessary, but then FDE might be helpful...

... which then leads me to wonder, yes I really should encrypt all my disks regardless of portability, not for physical theft but rather for what happens to the disk when I dispose of them due to their demise... Alas this will require me to upgrade my computing infrastructure first to AES capable machines, so I don't see this happening anytime soon. There will be a few machines that will have it that I don't need its compute bandwidth.

What would be nice if there was a low cost block cipher that still could provide some challenge to a passerby but does not need to be "military grade"...

[szatox]

a low cost block cipher that still could provide some challenge to a passerby but does not need to be "military grade"

Somehow this brought XXTEA, Rumba and Salsa to my mind. Maybe chacha...

Those use xor and rotations, which are 1-step operations in any cpu. AFAIR aes uses s-boxes too, which are very fast in hardware, but slow down software implementations.
Some of those are implemented in linux kernel too.
I haven't tried them, but could do the trick.

[eccerr0r]

was looking at some cryptsetup benchmark results and they are all very similar, except if you have AES-NI instructions then AES is much faster... Would be nice if there was one that was significantly faster, but I suppose the algorithms presented are all "military grade" (thought some were candidates for AES?) so that doesn't help much.

BTW when saying 1-step, it's one step per byte (unless when possibly using sse/mmx and of course aes-ni instructions) so it's still multiplied out by the number of bytes being worked with, and the cache misses caused by the extra code and the key that the cipher needs to constantly check...

[Hu]

... which then leads me to wonder, yes I really should encrypt all my disks regardless of portability, not for physical theft but rather for what happens to the disk when I dispose of them due to their demise... Alas this will require me to upgrade my computing infrastructure first to AES capable machines, so I don't see this happening anytime soon.

You might be better off planning to not use encryption, but to physically destroy the drive when you are ready to dispose of it. If it leaves your house in small enough pieces, it's unlikely anyone will salvage even unencrypted data from it. This obviously voids any hope at a warranty return, but if you are keeping hardware long enough that you still have AES-free machines, you are probably beyond the warranty period anyway.

[eccerr0r]

Alas I view objects as want not - waste not. I know there are people out there that enjoy destroying things to little pieces, including using these things as target practice, etc. While some of these devices do get so old that their value is near zero, it's not exactly zero - even with the device nonfunctional. I'd be happy to give people drive heads or spindle motor or circuit board they could use to salvage another drive - as long as they don't try to recover my data on the disk.

There's still a nice chunk of high grade aluminum (the chassis -- how many beer cans could you make with a 3.5" disk chassis?) and neodymium "rare earth metals" in the drive, which are still valuable as long as it's not contaminated by mixing with other stuff like the steel cover. People can have the drive for recycling, as long as the data on the drive cannot be recovered.

[Hu]

In that case, you would need to disassemble the drive yourself and hand out the non-data portions to deserving recipients, but retain the platters for destruction - or just retain them until they become so old that any data on them is no longer relevant to anyone.

[eccerr0r]

Maybe the first time I see any indication of the drive will fail soon...encrypt it.

[skiwarz]

Maybe the first time I see any indication of the drive will fail soon...encrypt it.

That works for spinning disks, but what about SSDs?

[dbtx]

For those that do any kind of ecncryption: Be aware that sleep functions of laptops make it useless. The encryption keys are in memory and are either kept there or are even written to disk in case of suspend-to-disk. Both of them defeat the purpose of FDE.

The fork at https://github.com/Heavenser/bliss-initramfs fixed the original's inability to resume from hibernation onto encrypted swap. It apparently wasn't even a major undertaking; it only needed to not be overlooked.

For a long time I used it in a banged-up Toshiba Satellite from 2009 with only 2 core 2GHz Athlon II M300, 4GB DDR2, and spinny rust. The en/decryption overhead didn't seem to make everything noticeably worse; bloat, especially modern WWW bloat, did that.

[eccerr0r]

SSDs I'm not sure about what to do. Luckily most of the SSDs I have already expired their warranties so I have to eat them when they die.

Also, fortunately, SSDs have zero valuable components when they die, unlike hard drives...

---

As for an Athlon II x2, funny, I also set up a box specifically with a cryptoroot over RAID. Yes I feel a bit of sluggishness when I use it, but it's not nearly as bad as the Celeron 1200. The Athlon II is a significantly faster machine, however; though probably my expectations from the Athlon cryptoroot is just to exceed that of the Celeron 1200, which is not very hard to do...

[sublogic]

For those that do any kind of ecncryption: Be aware that sleep functions of laptops make it useless. The encryption keys are in memory and are either kept there or are even written to disk in case of suspend-to-disk. Both of them defeat the purpose of FDE.

The fork at https://github.com/Heavenser/bliss-initramfs fixed the original's inability to resume from hibernation onto encrypted swap. It apparently wasn't even a major undertaking; it only needed to not be overlooked.

Thanks for the pointer. bliss-initramfs looks lighter than genkernel.

(For the record, genkernel handles resuming from encrypted swap as well. It scans logical volumes, opens the crypt_root, and scans LVs again. If you gave a "resume=" option pointing to a swap on an encrypted LV it just works.)

[dbtx]

(For the record, genkernel handles resuming from encrypted swap as well. It scans logical volumes, opens the crypt_root, and scans LVs again. If you gave a "resume=" option pointing to a swap on an encrypted LV it just works.)

I think that was why I was looking at genkernel some years ago, but I found that fork and was able to keep using bliss. IIRC the dealbreaker was that genkernel apparently didn't and doesn't support using a detached LUKS header embedded in the initrd. Now that I think of it again, it probably wouldn't be insanely difficult to add.

[sublogic]

[ ... ] IIRC the dealbreaker was that genkernel apparently didn't and doesn't support using a detached LUKS header embedded in the initrd. Now that I think of it again, it probably wouldn't be insanely difficult to add.

That's correct. I don't see any support for detached headers.

The genkernel /init is a little . . . convoluted, for my use case. But It does what I need.

[forrestfunk81]

Using encrypted disks on my machines since almost 15 years now. And I never had significant performance issues.

Some years ago I started moving my EFI partition with kernels and initramfs to USB. That adds a second factor to the authentication (besides the encryption password).

My only machine without full disk encryption is a virtual server. I thought about setting up an initramfs with basic network support and sshd to decrypt the disk. I will probably do it next time when switching to a bigger storage.

[eccerr0r]

I haven't tried FDE with my AES-NI capable machines but my core2 machines do hide the additional CPU consumption a bit, but indeed I can feel the slowdown if I'm streaming bytes to/from the disk. All earlier machines it's a huge performance hit (my 1.2GHz P3 (Celeron) is significantly impeded by the encryption).

One of my laptops does support AES-NI and is a candidate for FDE though Win7 would not be very compatible with cryptsetup... however my SSD would not like it as it depends on compression for speed and reducing blocks written.

[SiberianSniper]

My laptop has AES-NI and the encryption layer overhead hasn't been noticeable to me. Sure, it's a "portable workstation", but I'm not running anything too crazy on in.

The setup I use is *almost* FDE. The /boot partition is unencrypted, and I have a custom ramdisk to show a motd, set the keyboard rate (it sometimes registers key presses double if I don't), ask for the decryption passphrase, and run nyancat if it's entered incorrectly three times. The remainder of the drive is all one / partition on luks. I have a second drive for more user data, and it has two luks passphrases, one being a random-data file stored in /root so it can be mounted automatically, the other being one I know in case the first drive fails. This might not be the perfect setup, but it was pretty straightforward to build and has been more than adequate for me for the last few years.

[xgivolari]

Secure Boot + Unified Kernel / Initramfs image measured into the TPM + LUKS FDE with AES-NI + kernel lockdown because why not Although at the moment, the TPM decrypts my disk automatically at boot if the value of PCR 0 + 7 matches because I'm too lazy to enter two passwords I only use password-based decryption when I'm traveling or similar.

[duxsco]

On my laptop, I use unified kernel images, secure boot, measured boot (systemd-cryptenroll with TPM 2.0 pin), FDE and btrfs/mdadm RAID.

My disk layout looks basically like:

Code: Select all

PC∕Laptop──────────────────────────┐
└── ∕dev∕sda                       └── ∕dev∕sdb
    ├── 1. EFI System Partition        ├── 1. EFI System Partition
    ├── 2. MDADM RAID 1                ├── 2. MDADM RAID 1
    │   └── LUKS                       │   └── LUKS
    │       └── Btrfs                  │       └── Btrfs
    │           └── rescue             │           └── rescue
    ├── 3. LUKS                        ├── 3. LUKS
    │   └── MDADM RAID 1               │   └── MDADM RAID 1
    │       └── SWAP                   │       └── SWAP
    └── 4. LUKS ("system" partition)   └── 4. LUKS ("system" partition)
        └── Btrfs raid1                    └── Btrfs raid1
            └── subvolume                      └── subvolume
                ├── @binpkgs                       ├── @binpkgs
                ├── @distfiles                     ├── @distfiles
                ├── @home                          ├── @home
                ├── @ebuilds                       ├── @ebuilds
                ├── @root                          ├── @root
                └── @var_tmp                       └── @var_tmp

[oxensepp]

For me, a unencrypted system is out of question.
Still using Sakaki's encryption setup on laptop and desktop.
I like the fact of needing the USB key AND a passphrase to decrypt the system. (have two USB keys so I can eat one and still boot the machine...)

Of course I noticed that the sakaki tools are long outdated. I am searching an alternative. Is there really nothing similar?
The gentoo handbook does not cover encryption at all, does it?