ladar / sedutil

Use sedutil for setting up and using self encrypting drives (SEDs) that comply with the TCG OPAL 2.00 standard. This includes the requisite pre-boot authentication image.
https://trustedcomputinggroup.org/work-groups/storage/
80 stars 24 forks source link

SEDutil Future with Secure Boot - a Potential Option is Available Now #22

Open ChubbyAnt opened 3 years ago

ChubbyAnt commented 3 years ago

Windows 11 requires secure boot. Thus, for those who use SEDutil for preboot OPAL unlocking, we need a path for a secure boot compatible PBA.

Relax and Recover (https://github.com/rear/rear) is a backup and restoration utility that wraps in SEDutil in a rescue image and PBA. With great difficulty I have been able to get the rescue image working with secure boot and SEDutil, but I have not yet successfully managed to get the slimmer rear PBA working correctly. After trying many iterations to make rear work correctly, I ultimately succeeded in getting the rescue image to work with NVME and SATA SEDs by building rear in Debian 10.

It looks like a reasonable path forward to develop a Secure Boot enabled PBA for SEDutil is to use rear rescue image as a base with stripped out unnecessary rear packages.

The great news is that today rear is a working secure boot option for SEDutil PBA unlocking.

See also https://github.com/ChubbyAnt/sedutil/issues/37

ladar commented 2 years ago

Hi @ChubbyAnt I've done a little bit of experimentation with secure booting. Assuming your computer is using a *nix operating system, you can use the mokutil CLI tool to generate and load your own personal secure boot key, and configure your system to trust only your own personal secure boot key. I've gotten this work but I don't understand what I did well enough to write a guide for others to follow. I considered distributing a signed PBA image, but it would still require the user to load the associated public key onto their system, without removing the keys their system uses to boot the operating system. Yes, there is life beyond the PBA.

One of the big problems is you put a system into a specific developer mode so it will accept new boot keys. Then boot into the operating system, and submit the key using mokutil and then subsequently reboot and authorize the key that was submitted just submitted. Then exit out of developer mode so attackers can't repeat this process to add their own keys.

And even after all that, I'm not fully convinced the secure boot keys shipped with the system have been disabled (UI don't think they can be removed, because they are part of the ROM firmware image).

If I understand how things stand today, the Linux distros use the Windows secure boot key to bootstrap to bootstrap a subkey specific to that distro. Microsoft decided to facilitates this. Of course that means there are now a large number of vendors/distros who can securely boot arbitrary code on any computer that hasn't been locked down.

I'm just making a wild donkey guess, but the pool of stock semi (in)secure systems probably includes (almost) every computer on the planet which isn't owned by NSA, or provided by the NSA to another agency like the FBI/private contractor, and designated for a use or purpose that results in handling classified file(s).

schlomo commented 10 months ago

Hi, I'm the author of https://github.com/rear/rear and also using OPAL disks... Happy to help with anything ReaR related