[tor-dev] sigstore for improving verification of downloads?

[axel simon]

Hello all,

I've been a Tor user for a long time, have helped a bit with translation at times, and been working on issues related to freedom and the Internet for a while (as part of La Quadrature du Net), but i'm writing today with my work hat on, as a member of the security team at Red Hat's office of the CTO.

We recently announced a new project called sigstore [1], which could be summarised as "Let's Encrypt, but for software provenance and code signing".

If you want to read other people explain it better than me, i found these two articles did a good job:
- https://www.darkreading.com/application-security/linux-foundation-debuts-sigstore-project-for-software-signing/d/d-id/1340360
- https://www.zdnet.com/article/linux-foundation-announces-new-open-source-software-signing-service/

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.
Work is currently under way with the Ruby and WebAssembly communities to help them use sigstore to sign their stuff, and more generally the project has been well received so far.

The whole system is, of course, free and open source and i might add, welcomes new contributors. [3]
We also have a chat, if anyone is into that kind of thing. [4]

Interested in your thoughts, critiques etc. 

Thanks and hope this is helpful!

axel

1. Jointly with Google and Purdue University, https://sigstore.dev
2. https://certificate.transparency.dev/
3. https://github.com/sigstore
4. https://join.slack.com/t/sigstore/shared_invite/zt-mhs55zh0-XmY3bcfWn4XEyMqUUutbUQ

-- 
axel simon
axel at redhat.com // axel+tor at axelsimon.net