WIP: feat: signature via remote server #228

2023-09-26T14:19:46Z

RaitoBezarius commented

2023-09-26 14:19:46 +00:00

(Migrated from github.com)

This PR is composed of ~four changes:

generalization of signature schemes in the tool
generalization of how to assemble stubs in the shared library
a remote signature server that sends you signed stub in exchange for signature requests
an implementation inside lzbt-systemd of remote signing

This enables moving the local signature to another server… or even maybe a hardware security token!

In the future, the server can ask for attestations or any kind of things to give the signed stub.

This PR is composed of ~four changes: - generalization of signature schemes in the tool - generalization of how to assemble stubs in the shared library - a remote signature server that sends you signed stub in exchange for signature requests - an implementation inside lzbt-systemd of remote signing This enables moving the local signature to another server… or even maybe a hardware security token! In the future, the server can ask for attestations or any kind of things to give the signed stub.

cole-h (Migrated from github.com) reviewed

2023-10-01 00:52:44 +00:00

rust/tool/server/README.md

					
				@ -0,0 +26,4 @@

				- `POST /sign-stub`: assembles a signed stub based on the stub parameters sent, 200 OK with a signed binary as body, 400 with a plaintext error if failed.

				- `POST /sign-store-path`: assembles a signed binary based on the store path sent, 200 OK with a signed binary as body, 400 with a plaintext error if failed.

				- `GET /verify`: verify that the binary sent is signed according to the current keyring, returns a JSON `{ signed: bool, valid_according_to_secureboot_policy: bool }`, a signed binary can be invalid for the current Secure Boot policy, the two attributes represents this fact.

cole-h (Migrated from github.com) commented

2023-10-01 00:52:32 +00:00

- `POST /verify`: verify that the binary sent is signed according to the current keyring, returns a JSON `{ signed: bool, valid_according_to_secureboot_policy: bool }`, a signed binary can be invalid for the current Secure Boot policy, the two attributes represents this fact.

```suggestion - `POST /verify`: verify that the binary sent is signed according to the current keyring, returns a JSON `{ signed: bool, valid_according_to_secureboot_policy: bool }`, a signed binary can be invalid for the current Secure Boot policy, the two attributes represents this fact. ```

RaitoBezarius (Migrated from github.com) reviewed

2023-10-01 00:58:00 +00:00

rust/tool/server/README.md

					
				@ -0,0 +26,4 @@

				- `POST /sign-stub`: assembles a signed stub based on the stub parameters sent, 200 OK with a signed binary as body, 400 with a plaintext error if failed.

				- `POST /sign-store-path`: assembles a signed binary based on the store path sent, 200 OK with a signed binary as body, 400 with a plaintext error if failed.

				- `GET /verify`: verify that the binary sent is signed according to the current keyring, returns a JSON `{ signed: bool, valid_according_to_secureboot_policy: bool }`, a signed binary can be invalid for the current Secure Boot policy, the two attributes represents this fact.

RaitoBezarius (Migrated from github.com) commented

2023-10-01 00:58:00 +00:00

thx you madman

blitz commented

2023-10-15 13:57:25 +00:00

(Migrated from github.com)

I would need some high-level information about the security model here. If people still need to protect the credentials to access this server, which signs everything, why not just given them the private keys themselves? The only advantage I can see now is that the server can log what it signed.

RaitoBezarius commented

2023-10-15 14:08:47 +00:00

(Migrated from github.com)

Let's discuss it tomorrow :)

Le dim. 15 oct. 2023, 14:57, Julian Stecklina @.***> a
écrit :

I would need some high-level information about the security model here. If
people still need to protect the credentials to access this server, which
signs everything, why not just given them the private keys themselves? The
only advantage I can see now is that the server can log what it signed.

—
Reply to this email directly, view it on GitHub
https://github.com/nix-community/lanzaboote/pull/228#issuecomment-1763397175,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACMZRHGN5RL37PQ6FGNORTX7PTVDAVCNFSM6AAAAAA5HZ5HT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRTGM4TOMJXGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

Let's discuss it tomorrow :) Le dim. 15 oct. 2023, 14:57, Julian Stecklina ***@***.***> a écrit : > I would need some high-level information about the security model here. If > people still need to protect the credentials to access this server, which > signs everything, why not just given them the private keys themselves? The > only advantage I can see now is that the server can log what it signed. > > — > Reply to this email directly, view it on GitHub > <https://github.com/nix-community/lanzaboote/pull/228#issuecomment-1763397175>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AACMZRHGN5RL37PQ6FGNORTX7PTVDAVCNFSM6AAAAAA5HZ5HT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRTGM4TOMJXGU> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

RaitoBezarius commented

2023-10-30 12:22:23 +00:00

(Migrated from github.com)

This will have to wait until I have some time to fix the merge conflicts. Closing in the meantime, do not delete the branch.

This will have to wait until I have some time to fix the merge conflicts. Closing in the meantime, **do not delete the branch**.