All of my PCs have encrypted data volumes, going back to about 2005, when I had a laptop with all of my personal stuff on it stolen. I had a backup, but having all my stuff out there (had to change a lot of passwords quickly) was… awful. From then on, encryption was a must.
Linux has an excellent set of encryption tools that let any user encrypt just about anything, and the overhead is not bad with modern CPUs, which have specialized instructions for AES encryption. This is software encryption, managed by the OS.
Software encryption works well, but it’s not perfect. While it is not a huge thing, it puts additional load on the CPU, which translates to more power consumption, and thus shorter battery run times. It can also impose a speed penalty. Neither of these are very severe on a newer CPU, which has built-in CPU instructions that accelerate encryption and decryption, but they’re there.
Some SSDs come with self-encryption ability. These drives are always encrypting on the fly during writes, and decrypting on the fly on reads. If you don’t enable the encryption function, this just goes on silently in the background, and the drive acts exactly like a non-SED.
Self-encrypting SEDs show no performance or power usage penalty compared to similar drives without SED capability. The most efficient NVMe drives you can buy are those from the SK HynixP31/P41 series, and they are also among the fastest. These drives are self-encrypting, but they are more efficient and faster than most non-SEDs. That means that enabling the self-encryption mode on these drives will not impose any power consumption or speed penalty!
There are a couple of different ways to enable the encryption on a SED. The older is to simply set the ATA password on the drive in the PC BIOS/UEFI. On a class 0 SED, this will enable locking of the drive. On an ordinary (non-SED) drive, you may also be able to set the ATA password, but that will just make the drive refuse to function without the password. The data on the drive will be unencrypted and vulnerable to data recovery.
Not all BIOSes or UEFIs work with Class 0, especially desktops, and especially when using NVMe SSDs.
My Xenia laptop uses Class 0 with NVMe, but my Dell XPS does not, as the ATA password is not part of the NVMe spec. This does not stop Dell from offering a feature that goes beyond the spec, but they have chosen not to.
Some SEDs are not limited to Class 0 encryption. Most or all of the recent Samsung consumer SSDs have Opal functionality as well as Class 0 (but only one can be used at a time). Opal is more flexible and configurable than Class 0, and does not depend on a BIOS/UEFI feature that may or may not exist, but is generally more involved to set up.
The SK Hynix drives mentioned above use Class 0 or TCG Pyrite. Pyrite is a subset of the TCG Opal standard, and is a spec for access control, similar to the ATA password, meaning that a drive will refuse to work until it gets the correct password, but the data itself is not required to be encrypted. The SK Hynix implementation does add encryption to Pyrite, just as Class 0 drives add encryption to the ATA password, but there are others that do not. Opal, on the other hand, is always encrypted if the drive is locked.
I really like the SK Hynix P41 SSD, but the Pyrite standard is not supported by the TCG (Trusted Computing Group) Opal software. That was why I bought a Samsung 980 Pro SSD rather than put the P41 in it (after I returned the Xenia 14 for which I had bought the P41). The P41 is faster and more efficient on power, but I have to use software encryption with it, and when I do that, the faster and more efficient drive is slower and less efficient.
The base TCG software is a pretty spartan affair, and it has not received very much development over the last few years. The default way of booting a PC using the TCG software makes the boot take much longer, as it boots, asks for the password, then does a warm reset, reboots, and then loads your OS. Worse, the software does not permit S3 sleep mode on the PC. S3 mode cuts the power to the drive, which will cause it to lock, and the software has no means to unlock the drive at any time other than when booting.
Fortunately, the TCG software is open source, so others have forked it and added functionality that TCG should (but hasn’t) added themselves. One such fork is the TCG Opal RootFS. By following the instructions the author provides, consisting mostly of cutting and pasting commands into the terminal, the user is promised an Opal setup for Ubuntu that boots just as fast as before (not counting the time it takes you to enter the password!) and that allows S3 sleep too.
I was using OpenSUSE Tumbleweed on my XPS as the primary OS when I began this. The aforementioned instructions are for Ubuntu and related distros only; they will not work on others without modification, and I don’t know enough about the differences between initramfs-tools (used by Ubuntu) and Dracut (used by OpenSUSE) to be able to translate them. I have an idea of what it involves, but these kinds of things can be fraught with problems even when you are using the OS you are supposed to, so for this I went with my Neon installation on the XPS, which is closely related to Ubuntu 22.04.
I followed the instructions exactly, and I was rewarded on the first try with an Opal setup that “just works,” no muss and no fuss. I boot the PC, it asks me for the password/passphrase for the drive, I enter it, and it boots up and works. If I boot with a live USB drive (so the drive never gets unlocked), the data on the entire drive except for /boot is unreadable. When it is running, the OS has no idea the data is encrypted, and has no need to know that. If I put the unit to sleep (though I must note that this particular laptop cannot do S3 sleep, only S2idle as it is called in Linux), it works; I wake it up, it works.
If anything should ever happen and I have to manually unlock the drive rather than just boot it up and let it prompt me for the password, that’s pretty simple too. As with LUKS, any live session can be used to unlock it once you know the password, though it is not as convenient. You can unlock the drive and have it remain in that state for as long as you want, then enable locking again when you want to.
This setup is mainly aimed at providing at-rest protection, as is the LUKS setup I had before. Additional steps are needed to make it a well-rounded setup that a knowledgeable attacker could not easily bypass. That’s what I was after, and it works really well.
On the negative side, if it really is one, is that the password prompt is in TTY text mode, and is not very pretty. The author has commented that he would like to improve that and make it use the same Plymouth (graphical) appearance that the LUKS setup does, but this is not something that bothers me personally. It works,,, that is what matters to me.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
