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.
Isn’t this the same as the BIOS not supporting it at all? The shadow MBR/PBA feature only exists for the sake of the unaware BIOS by mimicking a regular unencrypted drive. Hence, the need for a reboot after unlocking.
Yup. Most are probably best off focusing on the upper left quadrant (no performance loss with peace of mind from petty theft or loss of SSD).
| Hardware Encryption | Software Encryption | |
|---|---|---|
| Petty Theft/Loss of SSD | No performance loss + peace of mind | Performance degradation + peace of mind |
| Intrusion by Three-Letter Agencies | No performance loss + questionable protection | Performance degradation + peace of mind |
But Cloudflare made some interesting discoveries about software encryption—namely that it’s possible to achieve near zero overhead, as if encryption weren’t even applied. It applies to Linux only currently.
Windows suffers from an (up to) 45% loss of performance (quoting Tom’s Hardware) using Bitlocker software encryption, with drops in random IOPS, latency, and sequential bandwidth. If you already paid for the hardware that is already doing the encryption work, why not take advantage of it?
The other issue with the BIOS doing the drive locking/unlocking is that you can probably only unlock it on a machine from the same manufacturer.
With sedutil it works the same on every machine.
I ran into this very incompatibility problem with Asus and ASRock systems with the encrypted drives’ shadow MBRs turned off.
In a way, sedutil could also be considered another incompatible implementation. Using an x64 PBA, I don’t expect to be able to stick the drive into an Arm machine and have the BIOS prompt me for the password.
But I’m going to agree that I’d rather BIOS not support SED unlocking if it’s going to use its own key derivation on user input. Plus, falling back to using the user input verbatim as key material is poor security practice. IOW, a PBA is the best we can achieve at the moment unless all the different BIOS can standardize on key derivation.
Sedutil at least has e clear and defined way of how it gets from password to key so you could still unlock it from another running os.
I’m personally in the software encryption camp, with aw acceleration the performance hit isn’t really big enough of a problem for me anymore. I was big into opal around the intel 5/6/7th gen era.
It should work between AMD64 and ARM, but I have not tried it.
OPAL isn’t worth the time to set up: VU#395981 - Self-encrypting hard drives do not adequately protect data There is also a spec flaw, where an attacker can swap your drive while your machine is S3 suspended with one with a compromised firmware that records your key hash. No one serious still uses it—it’s still listed for enterprises who haven’t updated their requirements yet (always hard to get a security “feature” removed). Just use LUKS or Bitlocker.
Sedutil doesn’t support S3 sleep anyway.
It’s not perfect, but it’s well beyond the ability of most adversaries you are likely to face to defeat it.
Isn’t the biggest concern with that the fact that somebody has physical access to the hardware? If the threat model is “SSD sold on eBay with master key intact,” OPAL is fine, no?
OPAL is fine unless you are concerned about someone getting to your laptop while it is powered up with the drive unlocked. Even then, either the OS has to be unlocked, or they have to be able to boot an alternative OS, or they have to be able to transplant the drive without powering it down.
Of course even with software encryption, the attacker getting access to the unlocked OS is a risk.
Unfortunately not. Drive makers self-certify their proprietary OPAL systems, no one external validates that they have implemented things correctly, or even that it encrypts the contents at all (excepting special cases like FIPS validated SEDs, but you won’t find these unless you look for them). The TCG just sets the standards, they don’t actually validate that they were followed, at all.
This isn’t a paranoid or academic concern, the whole industry got burned a few years back when it was discovered major drive manufacturers have been failing in exactly this way. The response wasn’t to launch a certification program, but rather that everyone serious switched to software encryption.
Read how egregious the flaws actually were: IEEE Xplore Full-Text PDF: and VU#395981 - Self-encrypting hard drives do not adequately protect data . The vendors provided patches for these exact CVEs, absolutely nothing has been done to give anyone any confidence that similar issues won’t occur.
If I really needed an OPAL drive for some reason (a system without AES acceleration?) I think this would be the only viable option: Industrial Product - Apacer here’s the cert: Cryptographic Module Validation Program | CSRC Not sure if it would fit in the framework with the physical protections tho
That’s not really true. For example, Samsung drives are known to be decently secure.
Again though, if your concern is eBay, the thief won’t look for CVEs on your drive. They will, at most, wipe the system.
Known by whom? See pages 9-12 (journal pages 80-83) of that pdf linked in my previous post.
Samsung fixed them and later audits found nothing.
But again, if your threat model doesn’t include technically advanced adversaries…
From 35 years experience in the field, use opensource software encryption (CryptoLuks and Lineage OS on phones).
That makes the security experts at the airports go nuts for a reason.
Whatever encryption that was created by an “enterprise” class company, they create it and stop maintaining it on the device you have soon after: and that is the main issue.
Use opensource software, if the possibility exists to use some cryptographic extensions, you can. But I always tend to avoid anything that comes in black boxes (TPM?).
Which is great, but don’t forget the massive performance hit you take.
If you are worried about crossing borders, my advice is to wipe the device and install a dummy OS. If you refuse to unlock your real one they can delay you and make your miss your flight/boat. If you need the real OS, transport it some other way that isn’t on your person.
It is not a huge performance hit. Usually current CPU’s have built-in instruction sets to speed up decryption. Back in time when using 800MHz Via C3 cpu’s, built-in aes functions were welcome to speed up encryption functions. Current CPU’s do handle that quite well and in real world env./work you wouldn’t notice.
I do setup my systems in the following way - as with partitioning, it works:
Usually, a good strategy takes care of most issue. You need of course to have the knowledge to handle it.