Chainguard Unveils Speranza: A Novel Software Signing System
Chainguard Labs, the company behind Sigstore code signing, in collaboration with MIT CSAIL and Purdue University researchers, has unveiled a new preprint titled “Speranza: Usable, privacy-friendly software signing.” It describes how to balance usability and privacy in software signing techniques. The result, they hope, will augment software supply chain security.
Why is this a problem? Because as it is, there’s no guarantee that the person signing the code is actually the authorized author. “Digital signatures can bolster authenticity and authorization confidence, but long-lived cryptographic keys have well-known usability issues, and Pretty Good Privacy (PGP) signatures on PyPI [Python Package Index], for example, are “worse than useless.”
That’s because PGP isn’t really a standard. In PyPI‘s case, “many are generated from weak keys or malformed certificates.” In short, there is no ultimate source of trust for PGP signatures. We need more.
In addition, the Sigstore’s keyless signing flow exposes your email with every signature. For a variety of reasons, not everyone wants their name attached to a signed code artifact.
Where Speranza Comes in
That’s where the Speranza project comes in. It takes a novel approach to this problem, by proposing a solution that maintains signer anonymity while verifying software package authenticity.
It does this by incorporating zero-knowledge identity co-commitments. Zero-knowledge is a blockchain cryptographic approach. It reveals that a piece of hidden information is valid and known by the prover with a high degree of certainty.
In the Speranza model, a signer uses an automated certificate authority (CA) to generate a new pseudonym each time. These pseudonyms are manifested as Pedersen commitments. While these are cryptographically linked to plaintext email identities, they don’t reveal any further identity information. Using a zero-knowledge approach, they still, however, assure you that there’s a real, legitimate user behind the code’s signature.
Adding another layer to the process, the signer uses the zero-knowledge commitment equality proofs to show that two commitments denote the same value. Thus, you can be sure a pair of signatures originated from the same identity, all while keeping that identity and any links between other signatures concealed.
Got all that? I hope so because that’s as clear as I can make it.
Sperenza Can Be Trusted
Pragmatically speaking, Speranza-based signatures can be trusted. That is not the case with many current signature approaches. Or, for example, the npm package provenance sidesteps this issue by using machine identities, but this doesn’t help with author signature privacy issues.
The proposed Speranza approach also requires a package repository to maintain the mapping from package names to commitments to the identities of authorized signers. This allows the signer to create proof that the identity from the map and the identity for their latest signature are co-commitments. The project also employs techniques from key transparency to alleviate the necessity for users to download the entire package ownership map.
The Speranza Rust proof-of-concept implementation shows that the overheads for maintainers (signing) and end users (verifying) are minimal, even for repositories hosting millions of packages. The system dramatically reduces data requirements, and server costs are negligible.
In conclusion, Speranza represents a feasible, practical solution that has the potential to operate on the scale of the largest software repositories currently in existence. By successfully marrying robust verification with crucial privacy measures, it aims to enable deployment on real package repositories and in enterprise settings.
Read the paper, give the code a try, and let the Speranza let you know what you think. This is still a work in progress.
