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

Support remote unlocking (and possibly attestation) #10

Open
ghost opened this issue Oct 3, 2019 · 4 comments
Open

Support remote unlocking (and possibly attestation) #10

ghost opened this issue Oct 3, 2019 · 4 comments
Labels
help wanted Extra attention is needed

Comments

@ghost
Copy link

ghost commented Oct 3, 2019

Ladar,

You are probably the most likely person to succeed with keeping a fork alive. One thing that is missing would be DHCP/RARP (sufficiently secured) based networking with SSH for remote unlocking.

One small caveat is that we might need to significantly update the PBA. I would like some form of integrity checking as an optional mechanism for other partitions (ex. GPG pubkey stored, automatically check for .sig files corresponding to kernel images and EFI executables, and perform a quick sanity check of these). This relies on the assumption that the PBA is inviolable, so it is not great. Think of it as a poor man's coreboot+Heads...

@oom-is
Copy link

oom-is commented Oct 21, 2019

I'm trying to understand your use case/intent for "DHCP/RARP (sufficiently secured) based networking with SSH for remote unlocking".

Are you looking for the equivalent of what some COTS tools offer, where the unlock would proceed automagically if the Sedutil-managed device boots up in the "correct" network environment where it would be able to (attempt to) SSH to a remote server and retrieve credentials?

@ladar
Copy link
Owner

ladar commented May 1, 2020

@oom-is I think @vogelfreiheit is looking for something like what you get using Dropbear SSH and LUKS. Where PBA launches an SSH server, thus allowing the user to login remotely over SSH, enter the device password, and thus unlock the boot device. It's handy for datacenters, etc.

As for me personally, I want the exact opposite. One of several reasons I refused to use any of the commercial SED options was because all of the products with Linux support were designed to be centrally managed. WinMagic sold a standalone version, but it was limited to Windows. And like I said, only their centrally managed product offered Linux support. I also didn't like the lack of code transparency, but that was a separate issue.

In fact one of the changes included in my fork was disabling DHCP support. That said, I'd be willing to accept a pull request which adds network support, provided it's optional, and doesn't impinge upon the use of a standalone setup, which would remain the default.

As for:

I would like some form of integrity checking as an optional mechanism for other partitions (ex. GPG pubkey stored, automatically check for .sig files corresponding to kernel images and EFI executables, and perform a quick sanity check of these).

In theory the PBA is inviolable, at least in theory, without knowing the device admin password. That said, what you're basically asking for is secure boot support, because without that, someone could sneak a fake PBA into the boot order ahead of the legitimate version.

I did enough research to realize it's possible to sign the PBA/recovery boot images, and give them secure boot support, but the process was tricky, and poorly documented. The short version is it would require generating a secure boot key/pair, then installing that public key onto a given system, followed by signing the process for signing the PBA/recovery images.

That would at least protect the PBA, but if you want to ensure control is only handed off to your OS, you'd need to use a custom key for that as well. That should protect the entire chain. Technically the last step is optional, but without it, a secure boot setup will trust the default key that comes with your system. And that secure boot key is controlled by Microsoft. Non-Microsoft systems generate signing keys, which are then counter signed by Microsoft to create a chain of trust.

If we added Linux chain loading support, you could do some of the integrity checking you describe, but that's another project, and wouldn't be a substitute for ensuring the PBA booted securely.

This was a ramble, but, @vogelfreiheit if you have the time and skills to figure out how to setup secure boot properly PLEASE send me the details. I'd love to sign the default images, and/or add instructions to this repo so that others can create their own custom secure boot keys. Doing so would make it impossible for bad guys, to phish your password by inserting a malicious PBA ahead of the proper version.

@ladar ladar added the help wanted Extra attention is needed label May 1, 2020
@ladar ladar assigned ladar and ghost and unassigned ladar May 1, 2020
@Jip-Hop
Copy link

Jip-Hop commented Apr 24, 2021

I'd love remote unlocking capability for my home server. For when I'm away from home and the server restarts after a power outage. It would be handy if I can remotely unlock and continue the boot process. But also just for convenience so I wouldn't need to have a keyboard (and monitor) attached during boot. I'm trying to make my own PBA image with sedutil-cli included. It'll be based on Tiny Core Linux with a Python script to serve an unlock page over HTTPS so I can unlock it from my LAN (or VPN) using a web browser.

@Jip-Hop
Copy link

Jip-Hop commented May 14, 2021

My remote-unlockable PBA is published: sedunlocksrv-pba.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants