Can anyone confirm if the Framework 16 works with TCG Opal v2 self encrypting drives?
To work the BIOS needs to support sending the right commands, and not block sending control commands by locking drive at boot.
While it’s not a hard requirement, it is helpful if the BIOS allows the user to load their own keys for SecureBoot, so that the Linux based pre-boot environment that unlocks drives can work with SecureBoot turned on.
The most common tool for working with self encrypting drives (SEDs) is sedutil.
Sure. Yes, I want to use SED. It offers decent security at no cost to performance.
I usually use Samsung SSDs. They perform well and I have found them to be reliable. Above all, their SED support is really good and actually works.
I have also had decent results with Crucial SSDs. They seem to come with eDrive enabled from the factory.
You have to be somewhat careful with other drives, especially Intel ones. They can be bricked by trying to enable SED. Samsung and Crucial have never had that issue. My advice is to turn it on as soon as you get the drive, and if it bricks just return it under warranty. Broken firmware that bricks is probably why some manufacturers stopped supporting SED.
You can use them out of the box with sedutil. You can also use Samsung Magician to enable eDrive, which is needed for Bitlocker support. It’s called something like “prepare drive for encryption”. Once enabled you have to do a fresh install of Windows, and then enable hardware encryption in the Group Policy Editor.
The main issue with Bitlocker is that it only works for the boot drive. If you enable hardware encryption on a second drive, when you sleep or hibernate the machine, upon waking it the drive will be inaccessible. Worse still, writing to the drive will corrupt data on it. It’s a truly craptacular effort from Microsoft.
Sedutil does not support sleep, but it does support hibernation, so I use that. The other issue with sedutil, more of an issue with OPALv2, is that drives are not re-locked on reboot, only on power cycle. Not really an issue for threats like theft, only if someone is able to take the machine while it is booted up.
I’ve heard a lot of good things about Samsung and Crucial SSDs, especially regarding self-encryption and you confirmed them once again.
But when it comes to the availability of self-encrypting SSD, most of retail available solutions are M.2 2280 drives. When looking for M.2 2230 SEDs, one should look for SSDs primarily available to systems integrators who purchase their components directly from drives manufacturers.
That means most FW16 users will hardly be able to get their hands on SED for its secondary SSD slot. Do you know a way to easily purchase an M.2 2230 SED?
Also do you have any particular drive model in mind, in M.2 2230 format and for your own use or are you planning to use only the primary M.2 2280 SSD slot of the FW16?
With sedutil-cli, you are encrypting with passwords that are run through an algorithm before being sent to the SSD, unless you are using the -n flag which will send the password exactly as provided on the command line.
Which one should the BIOS support? It’s possible that with cryptsetup supporting OPAL in the near future, that there are multiple incompatible ways of deriving the actual encryption key from the typed password, and the BIOS would not know which method was used.
@LiKenun there are two things that the BIOS needs to support.
For sedutil it just needs to support the PBA, which is a cut down Linux kernel with basic SATA and NVMe support. You can sign it so that you can use it with SecureBoot, assuming you can load your own keys into the UEFI (as required to support SecureBoot with Windows).
For BitLocker the BIOS also needs to support a certain command that is needed by the Windows pre-boot environment for eDrive. These days it’s pretty common to support it, but not guaranteed.
From past experience, the builtin encryption into drives is something I will not go into, as too many had backdoors in the past. Dunno about the current ones, but I won’t start searching for these.
What’s I’d like to see though, is that the encryption hardware could be used by cryptsetup/luks or so.
While there have been some issues with hardware encryption, you have to know your threat model. If your concern is theft or over-reach then it’s highly effective. If you are up against sophisticated attackers then use something like VeraCrypt.