Sigstore for Whonix?
Since normal people don’t understand signing keys, signatures or how to check things properly – and those that do often don’t bother – this could be useful for Whonix in the future.
It would help to overcome the first major obstacle to running the platform i.e. confirming that what is being downloaded and due to be installed is the legitimate platform to begin with. It looks like people would just need to check the binary against “transparency logs” to check it is legitimate.
And the element of ephemeral keys would also reduce the risk posed by someone compromising developer keys etc. Maybe you could express interest or look into it?
https://lists.torproject.org/pipermail/tor-dev/2021-April/014544.html
[tor-dev] sigstore for improving verification of downloads?
We recently announced a new project called sigstore [1], which could be summarised as “Let’s Encrypt, but for software provenance and code signing”.
…
In any case, the idea is to provide a public good service, heavily inspired by Let’s Encrypt, that lets developpers sign packages, containers, code artifacts in general, and lets user verify them in a simple way.
It’s still early days, but the aim is to make it a lot easier to verify the integrity of software, and to do better and easier than “here’s a binary, here’s an .asc detached PGP signature, here’s a page that says that 0xBLA is our public key”, which as we know is a procedure most users simply don’t follow.
To avoid the pains of key management (and the nasty targets keys quickly become), sigstore uses ephemeral signing keys (which don’t ever touch the disk), publishes the signature in a first transparency log, and discards the key after signature.
The other part of the system, which connects a signing key to an entity, is based on issuing a certificate to the signer which contains their email address and their pubkey, if they can prove control of the email address using OpenID Connect. This certificate is then stored in a second transpararency log, which provides a second root of trust, directly inspired by the Certificate Transparency project [2].
Using both transparency logs (signatures and certificates), one can then verify that a binary download is the expected one, and that is was signed by someone who controls an email address. Tools are being built to do this automatically, and in a repeatable way.
The idea is also to make it easy for developers to monitor the certificate transparency log for their email, which could alert them to untowards actions, if a new certificate pops up for something they never signed.
The OpenID Connect part is designed to allow for both large ID providers (like Github or Google) and bring-your-own.As i was saying, it’s still early days, but it’s coming along nicely and in my mind, Tor (and TAILS) are projects that would very much benefit from sigstore, hence this email.
…
- Jointly with Google and Purdue University, https://sigstore.dev
- https://certificate.transparency.dev/
- sigstore · GitHub
- Slack