> There's a checkbox to encrypt the disks when installing some linux distros.
While I'm not going to defend moving around unencrypted disks it is not as simple as that.
The difficult part is not the encryption. The difficult part is the key management of the encryption. You need to solve issue like ensuring you don't lose access to the keys (and thereby access to the data), securely providing keys to people and machines that need access, dealing with key revocation when people leave the company, etc.
Though I guess in this case using a simple (long enough) passphrase instead of some form of keys could have saved them from this particular threat.
When I ran a cloud provider, we used a hardware security module on storage systems which had public/private key pair which could be used to decrypt the header on the disk which contained a copy of the symmetric cipher key. Each header had the symmetric cipher key encrypted with multiple different public keys, including a fallback whose private key only existed in on paper in a vault.
Each system could reach out to other storage systems to ask them to use their private key to decrypt the header (for example if their hardware security module had failed), but in some configurations this would require an operator to intervene to enter in passphrase to unlock the hardware security module to authorize the action.
This means that:
1. The symmetric cipher key could always be recovered, even from paper backup
2. Having physical access to a disk or any set of disks did not allow you to read the data
3. Having physical access to a disk and a hardware security module did not allow you to read the disk (unless you knew the passphrase, which was always present, and user set)
4. Having physical access to disks, servers, and hardware security module may not allow you to read the data (in the more secure configuration where passphrases were not cached on disk -- but this meant that rebooting required an operator to manually enter the password at boot)
5. The set of valid public keys could be changed frequently (this was indeed automated and only the set of currently active hardware security modules could decrypt the current disk header)
Of course you could always short circuit this by making a copy of the symmetric key when you did have access (e.g., `dmsetup table --showkeys`) but without putting some more hardware in the fast/hot path that was unavoidable. The symmetric key could not easily be changed, without rewriting the entire disk (though since it was a storage system designed to accommodate multiple failures, this wasn't that hard, but we didn't do it automatically)
The hardware security modules we used were FIPS 140-2 validated and physically connected to the racks (though it would be possible to cut them away). It would also be possible to spy on the APDUs sent to the modules to capture the decrypted data, since there was not mutual authentication (it was in the works though).
This is exactly why most of us are more than happy to pay a premium to AWS, GCP, and Azure. They reduce all what you listed to a handful of checkboxes for us plebs. You have to have a few discussions about how you as an org will manage your keys, and you're a couple of terraform files away for having access to this (budget notwithstanding).
This is the level of redundancy/backups/processes the large cloud providers have. It's not just "hey is this encrypted" – it's "what happens, how do you retire a drive, are the modules FIPS 140-2 compliant, how do we physically secure our HSMs?" etc
It's just so much more than "hey Digital Ocean is 50% cheaper"
AWS's egress bandwidth charges still feel criminal though.
Well, a lot of laptops these days have TPMs that can store disk encryption keys. BitLocker on Windows, or an exotic dm-crypt setup on Linux.
However for a server, the chance of a thief getting a disk and the HSM at the same time is low; and you really don't want to have to enter a password every boot. So the HSM design delivers some benefits worth having.
Whereas for a laptop, you can easily type in a password; and the chance of a thief snatching the disk and TPM at the same time is basically 100%. So there hasn't been a big push among Linux users to start using the TPM.
It was all made out of parts with standardized interfaces, so components could be consumer equipment.
I also used the same software on my laptop to encrypt it. It's nothing fancy, just using the dm-crypt kernel module and any kind of hardware security module that talks PKCS#11 (which is all of them); On my laptop I just used my existing smartcard (which I used to login to the system and remote systems).
The disk header was just text occupying the first 4MiB of the disk in 2 circular buffers similar to LVM (though 2 copies for redundancy).
Purism will sell you a setup with the Librem laptop and hardware key, which has some verification of the system firmware as well as, presumably, supporting disk decryption. I'm not sure how much extra that gives you over fairly generic hardware tokens with LUKS encryption. Apparently LUKS2 supports FIDO2 keys, which may be the cheapest.
I thought any of these providers always encrypted with their own key whether you encrypted on top of that or not. But I guess not.
Yet another reason to just stick with the big providers. They seem to have pretty serious compliance needs and encrypt no matter what. (Yet you should still encrypt your assets, but I believe they all encrypt their volumes anyway and have pretty strict policies on how to dispose this kind of hardware)
While I'm not going to defend moving around unencrypted disks it is not as simple as that.
The difficult part is not the encryption. The difficult part is the key management of the encryption. You need to solve issue like ensuring you don't lose access to the keys (and thereby access to the data), securely providing keys to people and machines that need access, dealing with key revocation when people leave the company, etc.
Though I guess in this case using a simple (long enough) passphrase instead of some form of keys could have saved them from this particular threat.