Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ChubbyAnt opened this issue Jul 9, 2021 · 2 comments
Open

Comments

@ChubbyAnt
Copy link

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 ChubbyAnt/sedutil#37

@ladar
Copy link
Owner

ladar commented Mar 30, 2022

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
Copy link

schlomo commented Jan 30, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants