SED-based Hardware Encryption Support

[yezi86001]

SED-based hardware encryption has better performance,although governmental backdoors cannot be avoided. Maybe this feature could be added and users who don't care about governmental backdoors could choose whether use it or not while encrypting system and non-system partitions/drives.
VeraCrypt could present some security alerts while enabling hardware encryption.

[dartraiden]

Not only backdoors. See https://techcrunch.com/2018/11/05/crucial-samsung-solid-state-drives-busted-encryption/ (due to Crucial engineering errors, the encryption key did not depend on the user's password).

Also, if PC do not power cycle the SED-encrypted drive at reboot (which happens very often with SSD), the drive will not be locked after reboot. So attacker just hit Reboot and you will be pwned.

[alt3r-3go]

@yezi86001, SED is a whole other story compared to what VeraCrypt does, essentially (simplifying) you don't need VC at all with SED. So it's kind of meaningless to have such support (other than it could serve as a provisioning UI, but that's too much work for too small gain, IMHO).

[ghost]

If you really don't want to use software encryption and instead want to use the SED functionality and are willing to take the risk that some (not all!) SEDs implement that functionality in an unsecure way, then actually there are good reasons to implement SED provisioning support in VC.

Some background information to support my argument:
Many (maybe all?) computer manufacturers offer (paid) support to reset and/or decrypt your SED (even without losing your data) in case you have forgotten your password for your SED encrypted drive. The only thing you have to do is to send the serial number of your computer (called "Service Tag", "Machine Number" etc.) and a proof of ownership (invoice with your name on it for example) to the manufacturer. A couple of hours or days later the manufacturer sends you a special generated password that unlocks your SED.
(Google it, you'll find the corresponding support documents on many manufctuter's websites.)

How they probably do that:
Enabling the SED functionality is usually done by going to the UEFI (or BIOS on older machines) of your computer and setting a drive password, thereby encrypting your drive. Doing this the computer sets the "ATA user password" with the custom password you provided.
But some other areas inside the SED (maybe the "ATA master password") are filled with a special password that is automatically generated by the computer (maybe derived from the serial number of your computer). This is beyond the user's control.
So in case you forget your SED's "ATA user password", this must be what enables the manufacturer to unlock or decrypt your SED. Probably they use some sort of company internal/secret "Key Generator" in combination with the serial number of your computer to generate an unlocking password for your SED.
They can even unlock your UEFI/BIOS in case you have forgotten that UEFI/BIOS access password, too. This UEFI/BIOS unlock password can also be used to unlock the SED, at least this works with my computer on boot.

Security implications:
This means that there are indeed ways of unlocking/decrypting your SED even without your password, which is of course a security issue. It has happened in the past that those company's "Key Generators" have been leaked into the internet.

Solution: use TCG Opal - but not all TGC Opal products
TCG Opal is a solution to this problem, because the software package that uses the TCG Opal standard manages the passwords and accesses/provisions the SED by itself, thereby circumventing the computer's UEFI (or BIOS). Because of this the UEFI (or BIOS) cannot set its own secret password into the SED.

Bad idea: proprietary TCG Opal solutions
BitLocker, for example, is Microsoft's way of implementing TCG Opal and SED support into Windows. The problem here (and with other proprietary software products, too) is that it is proprietary code that cannot be reviewed and therefore not fully trusted.

Good idea: open source TCG Opal solutions
For example "sedutil" (formally "msed") by Drive-Trust-Alliance

• https://github.com/Drive-Trust-Alliance/sedutil/wiki/Encrypting-your-drive
• SEDutil future with Secure Boot - a Potential Option is available Drive-Trust-Alliance/sedutil#366
• https://vxlabs.com/2015/02/11/use-the-hardware-based-full-disk-encryption-your-tcg-opal-ssd-with-msed
• SEDutil Future with Secure Boot - a Potential Option is Available Now ChubbyAnt/sedutil#37

VeryCrypt SED support using TCG Opal
The problem is that the mentioned open source solutions are very few (I know only this one) and kind of hard to use for the average computer user. If TCG Opal functionality would be implemented into VeryCrypt (maybe even in a user friendly way), then VC would be the ultimate encryption tool.
Maybe the VC developers could fork "sedutil" and and take it a step further by implementing it into VC's pre boot environment (PBE). So maybe they wouldn't have to start from scratch.

[dartraiden]

Ultimate encryption tool that leaves the drive decrypted on hot reboot :D Just press the hardware Reboot button and the disk stay unlocked.
This is a defect included in the OPAL specification. The disk is locked when power is lost, but reboot is not considered as power outage.

This is an easy way to shoot yourself in the foot for an inexperienced user.

[ghost]

Let the users choose what they want:
a) software encryption at the cost of performance impact, or
b) full performance hardware encryption at the cost of security in some cases.

Computers in a safe environment (like a laptop in the home office room) are pretty safe in there. And if the users want to take their laptops outside, they have to be aware that they need to put to hibernation mode or shut it off - just don't let it running when you're away from the computer: this gives attackers no chance to do a hot reboot. If the users choose option b) then they have to be aware of that. Don't underestimate the users, they can be responsible enough to do that.
(By the way: This is a security practice that everyone should be aware of, even when software encrypting with VC. Because this prevents cold boot attacks like freezing the memory with ice spray and then make a memory dump.)

To the reboot problem: Many computers and Opal implementations can be set to require a UEFI/BIOS password or Opal password even on hot reboot with no power cycle/lock command to the SSD. My BitLocker hardware encryption (Microsoft calls it "eDrive") asks for a password every time when I reboot my computer. No matter if it is a "hot" or "cold" boot. So this can be implemented in VC as well and would make it safe.

This is the problem with all Opal implementations; and also with activating/managing the SED functionality with the computer's UEFI/BIOS and not with Opal.

But the main advantage of impelmenting Opal in VC would be that it would give users the option to use a trusted Opal implementation, if they so wish. (Instead of untrusted closed source ones like BitLocker or hard to use open source ones like sedutil).

[eclipsek20]

I genuinely hope this gets implemented, really like veracrypt, however the performance is it's Achilles heel.

[UtilFunction]

Cryptsetup also seems to have added an option to make use of OPAL encryption or both hardware and software encryption in combination. Would be nice if Veracrypt also supported this.