# Self-encrypting drives vs. software encryption **URL:** \ **Category:** General Topics\ **Created:** [November 14, 2023, 3:46am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031 "2023-11-14T03:46:04Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![LiKenun](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/likenun/32/17119_2.png) [@LiKenun](https://community.frame.work/u/LiKenun)\ **Post date:** [November 14, 2023, 3:46am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/1 "2023-11-14T03:46:04Z")
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. ---
**Author:** ![kuro68k](https://avatars.discourse-cdn.com/v4/letter/k/a698b9/32.png) [@kuro68k](https://community.frame.work/u/kuro68k)\ **Post date:** [November 14, 2023, 9:11am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/2 "2023-11-14T09:11:32Z")
@LiKenun there are two things that the BIOS needs to support. 1. 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). 2. 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. ---
**Author:** ![Jorg\_Mertin](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/jorg_mertin/32/47951_2.png) [@Jorg\_Mertin](https://community.frame.work/u/Jorg_Mertin)\ **Post date:** [November 14, 2023, 9:27am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/3 "2023-11-14T09:27:37Z")
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. ---
**Author:** ![kuro68k](https://avatars.discourse-cdn.com/v4/letter/k/a698b9/32.png) [@kuro68k](https://community.frame.work/u/kuro68k)\ **Post date:** [November 14, 2023, 9:54am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/4 "2023-11-14T09:54:26Z")
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. ---
**Author:** ![LiKenun](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/likenun/32/17119_2.png) [@LiKenun](https://community.frame.work/u/LiKenun)\ **Post date:** [December 10, 2023, 5:56pm UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/5 "2023-12-10T17:56:15Z")
> [@kuro68k](#): > > 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). 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. > [@TCG OPALv2 support](http://community.frame.work/t/tcg-opalv2-support/39689/11): > > you have to know your threat model. If your concern is theft or over-reach then it’s highly effective. 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](https://blog.cloudflare.com/speeding-up-linux-disk-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](https://www.tomshardware.com/news/windows-software-bitlocker-slows-performance), 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? ---
**Author:** ![kuro68k](https://avatars.discourse-cdn.com/v4/letter/k/a698b9/32.png) [@kuro68k](https://community.frame.work/u/kuro68k)\ **Post date:** [December 11, 2023, 5:36am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/6 "2023-12-11T05:36:48Z")
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. ---
**Author:** ![LiKenun](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/likenun/32/17119_2.png) [@LiKenun](https://community.frame.work/u/LiKenun)\ **Post date:** [December 11, 2023, 1:32pm UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/7 "2023-12-11T13:32:41Z")
> [@kuro68k](#): > > 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. ---
**Author:** ![Adrian\_Joachim](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/adrian_joachim/32/9949_2.png) [@Adrian\_Joachim](https://community.frame.work/u/Adrian_Joachim)\ **Post date:** [December 11, 2023, 1:40pm UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/8 "2023-12-11T13:40:08Z")
> [@LiKenun](#): > > 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. 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. ---
**Author:** ![kuro68k](https://avatars.discourse-cdn.com/v4/letter/k/a698b9/32.png) [@kuro68k](https://community.frame.work/u/kuro68k)\ **Post date:** [December 12, 2023, 5:50am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/9 "2023-12-12T05:50:26Z")
It should work between AMD64 and ARM, but I have not tried it. ---
**Author:** ![tiberious726](https://avatars.discourse-cdn.com/v4/letter/t/e68b1a/32.png) [@tiberious726](https://community.frame.work/u/tiberious726)\ **Post date:** [December 25, 2023, 6:12am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/10 "2023-12-25T06:12:39Z")
OPAL isn’t worth the time to set up: [VU#395981 - Self-encrypting hard drives do not adequately protect data](https://kb.cert.org/vuls/id/395981/) 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. ---
**Author:** ![kuro68k](https://avatars.discourse-cdn.com/v4/letter/k/a698b9/32.png) [@kuro68k](https://community.frame.work/u/kuro68k)\ **Post date:** [December 25, 2023, 8:18am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/11 "2023-12-25T08:18:56Z")
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. ---
**Author:** ![LiKenun](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/likenun/32/17119_2.png) [@LiKenun](https://community.frame.work/u/LiKenun)\ **Post date:** [January 2, 2024, 4:21am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/12 "2024-01-02T04:21:06Z")
> [@tiberious726](#): > > an attacker can swap your drive while your machine is S3 suspended with one with a compromised firmware that records your key hash 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? ---
**Author:** ![kuro68k](https://avatars.discourse-cdn.com/v4/letter/k/a698b9/32.png) [@kuro68k](https://community.frame.work/u/kuro68k)\ **Post date:** [January 2, 2024, 5:06am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/13 "2024-01-02T05:06:07Z")
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. ---
**Author:** ![tiberious726](https://avatars.discourse-cdn.com/v4/letter/t/e68b1a/32.png) [@tiberious726](https://community.frame.work/u/tiberious726)\ **Post date:** [January 2, 2024, 8:49pm UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/14 "2024-01-02T20:49:57Z")
> [@LiKenun](#): > > If the threat model is “SSD sold on eBay with master key intact,” OPAL is fine, no? 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:](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8835339) and [VU#395981 - Self-encrypting hard drives do not adequately protect data](https://www.kb.cert.org/vuls/id/395981) . 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](https://www.apacer.com/en/product/industrial-product/industrialsearch/industrial_ssd/ssd_specialty/fips-tcg-series) here’s the cert: [Cryptographic Module Validation Program | CSRC](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4386) Not sure if it would fit in the framework with the physical protections tho ---
**Author:** ![kuro68k](https://avatars.discourse-cdn.com/v4/letter/k/a698b9/32.png) [@kuro68k](https://community.frame.work/u/kuro68k)\ **Post date:** [January 3, 2024, 1:59am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/15 "2024-01-03T01:59:22Z")
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. ---
**Author:** ![tiberious726](https://avatars.discourse-cdn.com/v4/letter/t/e68b1a/32.png) [@tiberious726](https://community.frame.work/u/tiberious726)\ **Post date:** [January 3, 2024, 5:04am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/16 "2024-01-03T05:04:16Z")
> [@kuro68k](#): > > Samsung drives are known to be decently secure. Known by whom? See pages 9-12 (journal pages 80-83) of that pdf linked in my previous post. ---
**Author:** ![kuro68k](https://avatars.discourse-cdn.com/v4/letter/k/a698b9/32.png) [@kuro68k](https://community.frame.work/u/kuro68k)\ **Post date:** [January 3, 2024, 5:57am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/17 "2024-01-03T05:57:35Z")
Samsung fixed them and later audits found nothing. But again, if your threat model doesn’t include technically advanced adversaries… ---
**Author:** ![Jorg\_Mertin](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/jorg_mertin/32/47951_2.png) [@Jorg\_Mertin](https://community.frame.work/u/Jorg_Mertin)\ **Post date:** [January 3, 2024, 8:53am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/18 "2024-01-03T08:53:32Z")
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?). ---
**Author:** ![kuro68k](https://avatars.discourse-cdn.com/v4/letter/k/a698b9/32.png) [@kuro68k](https://community.frame.work/u/kuro68k)\ **Post date:** [January 3, 2024, 9:45am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/19 "2024-01-03T09:45:24Z")
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. ---
**Author:** ![Jorg\_Mertin](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/jorg_mertin/32/47951_2.png) [@Jorg\_Mertin](https://community.frame.work/u/Jorg_Mertin)\ **Post date:** [January 3, 2024, 10:01am UTC](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031/20 "2024-01-03T10:01:45Z")
> [@kuro68k](#): > > Which is great, but don’t forget the massive performance hit you take. 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: - Dual boot setup Windows/Linux. - Linux full disk encryption. Linux partitions have: /, /home (so I have my private data encrypted). For video editing, I tend to create a 20GBytes Ram Filesystem to process temporary stuff in here. When finished, I sync the content to the encrypted FS. - Windows - whatever. Using it for gaming only. So no biggy. Usually, a good strategy takes care of most issue. You need of course to have the knowledge to handle it. [Next page](https://community.frame.work/t/self-encrypting-drives-vs-software-encryption/43031.md?page=2)