Introducing "Speranza": Enhancing software signing with privacy and usability

Chainguard Labs is thrilled to announce the availability of a new preprint, "Speranza: Usable, privacy-friendly software signing," available for review and comment on arXiv. This project aims to balance usability and privacy for software signing techniques that improve software supply chain security.

‍

In this post, we’ll see:

‍

• The problem Speranza solves.

• How Speranza works, including some interesting cryptography.

• How Speranza can be applied to open source package repositories, or to enable enterprise deployments of a technology like Sigstore.

‍

This is research work, and not deployed yet; this post presents a preview of cryptographic techniques that we hope will be commonplace in the software repository of the future (you can skip this one if that’s not the sort of thing you find interesting). Speranza is joint work between Chainguard Labs, Karen Sollins and Kelsey Merrill of MIT CSAIL, and Santiago Torres-Arias of Purdue University.

‍

The problem

The distribution of open software, while a boon for accessibility and innovation, poses potential security risks, especially in software repositories like PyPI or npm. Digital signatures can bolster authenticity and authorization confidence, but long-lived cryptographic keys have well-known usability issues and PGP signatures on PyPI are “worse than useless.”

The Sigstore project is much easier to use: developers sign with digital OpenID Connect (OIDC) identities, like their email addresses. But these emails constitute personally identifiable information (PII), posing a privacy concern for maintainers. I’ve written before about these privacy issues in a general context. Crates.io took steps recently to improve maintainer privacy in a package repository setting (unrelated to software signing), which indicates that this is an important issue to solve to enable the adoption of signing for these repositories. Similarly, enterprises are hesitant to adopt technologies like Sigstore due to concerns about leaking metadata to a public record.

‍

Other techniques aren’t quite up-to-snuff. We can’t just have privacy-sensitive maintainers use pseudonyms, because privacy issues often arise after-the-fact—any maintainer may become privacy sensitive in the future. Redacting this information later can take down packages for users downstream. Automated pseudonyms, like Pairwise Pseudonymous Identifiers (PPIDs) in OpenID Connect, require cooperation from upstream identity providers; further, managing the scope of these identifiers (do I have one per package? one per repository?) introduces new complications. Verifiable random functions (VRFs), like those used in the CONIKS key transparency project, could bring verifiability to pseudonyms, so a certificate authority can’t issue pseudonyms inconsistently. Deployments like npm package provenance sidestep this issue by using machine identities (which aren’t sensitive), but this gives a different kind of security than having authors sign packages.

‍

‍Speranza

‍

"Speranza" (pronounced “spur-on-zuh”, after a pseudonym used by poet Jane Wilde) is our proposed solution to this problem. This innovative approach allows for the verification of software package authenticity while maintaining anonymity for the signers, using a new method of zero-knowledge identity co-commitments.

In the Speranza model, a signer utilizes an automated certificate authority (CA) to generate a new pseudonym each time. The pseudonyms are implemented as Pedersen commitments, which are cryptographically linked to the plaintext email identities but in a way that reveals no information. Then, a signer can use zero-knowledge commitment equality proofs to demonstrate that two commitments represent the same value. This means that they can show that a pair of signatures came from the same identity, without revealing what that identity was or links between any other signatures they’ve created!‍

To verify that the signer had authorization to publish a package, we have the package repository keep a mapping from package names to commitments to the identities of authorized signers. The signer then creates a proof that the identity from the map and the identity for their latest signature are co-commitments.‍

We also use some tricks from key transparency to prevent users from needing to download the package ownership map in its entirety; for details on those, see the paper. ‍

Our proof-of-concept implementation (available on GitHub) demonstrates that the overheads for maintainers (signing) and end users (verifying) are marginal, even for a repository hosting millions of packages. While end users need to learn the authorization policy to verify packages, our approach dramatically reduces the data requirement from a potential 100 MiB to a mere 2 KiB. Additionally, server costs in this system are negligible.‍

Conclusion

Our evaluation indicates that Speranza is not just a theoretical concept but a practical solution, capable of operating on the scale of the largest software repositories in existence today. This work blends robust verification with critical privacy measures to (we hope) enable deployment on real package repositories and in enterprise settings. We invite you to read and share your insights on the paper as we work towards our mission of making software signing both usable and privacy-friendly.‍