Sigstore - "Let's Encrypt for Code Signing"

Stumbled onto this the other day and I hadn't read about it before. It looks like it's still very early development. But I'm curious what other folks in this space think about the idea.

As the maintainer of an open source ACME client, I would love to be able to sign my packages so that people downloading them know they're official and haven't been tampered with. But it hasn't been worth the cost to purchase and maintain a publicly trusted code signing cert. This sounds like it would be a solution to that problem.

I'm guessing there will be naysayers with the same basic argument that they have for free TLS certs. BaD gUyS wIlL jUsT sIgN tHeIr MaLwArE.

3 Likes

As the author of an open source ACME client myself, I don't see anything stopping us from creating a hash of each version of our released code signed with a private key for which we provide the public key on our websites. Then again, if users are downloading the code directly from the website alongside the public key, this seems a bit like overkill since the only reasonable way I can see that an attacker could tamper with the code would be to act as a MITM for both elements.

This concept seems to harken back to the days of shareware distribution in the 90's...

Yeah, I thought most package managers used GPG or at least https already; I'm not sure exactly what this is supposed to add? I'm clearly missing something of what the problem statement is that this is trying to solve.

1 Like

@griffin That process would depend on also retrieving the public key of the private key you've used for the signing of the hash. And the idea behind sigstore is that it's backed by a single publically available root certificate in stead of every developer requiring to generate their own signing keypair which somehow needs to be distrbuted to every user.

Putting the public key next to the file to be checked is quite useless: if the package isn't safe then the public key next to it isn't also.

1 Like

I suppose it depends on how your software is distributed. With CertSage being a single, interpreted code file downloaded directly from sources I trust (like the official website) rather than from a third-party repository, my case is rather simple. Honestly, the cryptography involved in the download and subsequent upload are enough to thwart a MITM attack in my case.

I see third party distribution (that's possibly unauthorized/modified) as possibly the biggest issue. Shareware back in the day was often supplemented with viruses and nonsense when distributed over random floppies and BBSs.

Exactly, it's things like Linux distro package repositories or in my case something like PowerShell Gallery. Even though it's Microsoft run, it's basically no different than a shareware site. Anyone can publish a package there. So if I wasn't already publishing my module there, someone could very easily take my code, alter it, and publish a fake/malicious version there and most users don't have the expertise to compare the files they got with the files from the official Github repo.

The goal is that the package itself is signed in such a way that no matter where you get it from, you can be sure it came from me and not an attacker.

1 Like

I know that GoG (Good Old Games) posts MD5 hashes of their packages on their website and often has distribution through torrents.

This makes me think of the Google "Pray" Store... you better pray that's the authentic app you just downloaded...

:pray:

:rofl:

But if anybody can post anything, and anybody can get a free code signing certificate, how would a random user know if they want to download the "real" or the "fake" versions, that both are signed? Are users going to be talking about code publishers by the public key hashes? I don't understand how this project is solving a key distribution problem any better than is already done by the GPG-based Linux package managers. There's clearly something to it if Google's putting their weight behind it, but they haven't conveyed to me effectively what it is that they're doing differently or better.

1 Like

Until an attacker repackages your stuff with their "goodies" inside and the user doesn't know the difference between the authentic package and the "repacked" version. Unless the distribution infrastructure supports an "identification" program that maps each package to a verifiable source (that every user can verify for themselves with little effort), it's kindof a lost cause.

Exactly.

To me, the question comes down to this:

How can I trust that this package of Posh-ACME I've just downloaded (or, better yet, will download) was in fact packaged by Ryan Bolger?

When someone comes to this community and clicks on your profile based on years of posting evidence as backed by respected community members (especially Let's Encrypt staff), they know with whom they're dealing and can easily verify the official GitHub repository of Posh-ACME via clicking the link in your user profile. There's so much verifiable extension of trust there.

This is very subjective though and doesn't lend itself well to automation.

Okay, after reading through a bit more on sigstore

I think the entire point is that it makes keys that are associated with an OpenID provider. So you can validate that some code your downloaded was actually built by, say, the owner of a specific Github account. I'm not quite sure what benefit that gives over just having https links to download releases from Github directly, but maybe after being distributed through package managers and the like it can be handy to try to still tie the code back to the original Github developer? Or something like that? Maybe?

1 Like

That still seems to assume that the person verified through OpenID (as is the same issue with unemployment systems with ID.me) is in fact the right "version" of the person.

For full disclosure, my professional development background is in biometric authentication and identification. :grin: We of this industry live and breathe identity conundrums.

I statistically proved a few years back that in any given city of 1M+ people, I can find about 20 people who share "matching" fingerprints with you according to the federal fingerprint matching system in case you need an alibi for something... :upside_down_face:

Yeah, the hard part of any cryptography is "does the key I have actually belong to the entity I think it does", and now that I've read through it I think the entire point of Sigstore is just to try to offload that part to OpenID, and thus assuming that means that it's a solved problem. I can kind of see how that might be helpful for some cases, and maybe Google specifically ran into many of those cases? Their announcement's focus on "Supply Chain Integrity" implies to me that they're really trying to solve issues of large corporate organizations and tracking all their usage of open source software, rather than the issues of individual users.

1 Like

Wasn't Keybase originally designed to solve some of that cryptographically provable identity across disparate sites issue?

1 Like

My own takeaway from this is that it's a new system to simplified and augment a few existing systems, and is focused on the transparency aspect.

Larger scale Open Source projects already have a few levels of code signing - from source code signatures you can manually verify, to package installers for linux distros that require a GPG key import/trust.

These keys become "trusted" because uses are told to trust them when reading the official installation docs, but their existence is relatively unknown outside of that context. A GPG key might be tied to an email address, but it's association to the email address is just claimed - it's not validated or verified. You can't necessarily look up a key's provenance, or see everything that it's been attached to.

That's where this system comes in: i) their keys are validated, and verified to be attached to an OpenID resource; ii) the transparency system logs everything signed by that key.

Right now this offers a secondary layer to map over existing systems, but it is building the framework to better integrate and unify all these systems together.

Yes. My first startup FindMeOn did the exact same thing in 2006 too – we allowed people to claim and verify social identities and cryptographic keys, then used that to build cross-platform social networks.

The first innovation in this space that I know of, was the "Web Of Trust" PGP Keyserver that was either from IBM or Bell Labs in the 90s -- everyone would sign the public keys of all their contacts, and the server could build and traverse a social graph based on trust settings.

2 Likes

And Let's Encrypt's root is trusted because operating systems and browsers include them in their default trust store, but its existence is relatively unknown by most users. Which I think would be analogous to whatever GPG keys are trusted by your Linux distro package manager by default.

Okay; I can see how that would be useful. So the transparency isn't just around the existence of a key, but around every version of code that's been signed? So that would allow me to determine that when I install a package, it's by the same owner that has signed the previous n versions that I had already used, and in addition hadn't been used to sign code not in the public list of versions that then might be confused for it?

Oh, I certainly understand that existing systems have their flaws, I just wasn't seeing what benefits this process was trying to add. Thanks for helping make it a bit clearer.

1 Like

Yes! And as a Platform or Network Maintainer, you might use this information to incorporate a key into the trust store you operate, so it starts to streamline the entire ecosystem.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.