BT

Facilitating the spread of knowledge and innovation in professional software development

Contribute

Topics

Choose your language

InfoQ Homepage News Linux Foundation Sigstore Aims to Be the Let's Encrypt of Code Signing

Linux Foundation Sigstore Aims to Be the Let's Encrypt of Code Signing

This item in japanese

Bookmarks

Backed by the Linux Foundation, Sigstore aims to provide a non-profit service to foster the adoption of cryptographic signing by open source projects to make the software supply chain more secure.

The main issue Sigstore attempts to tackle is the difficulty of knowing the origin of a piece of software, or how it was built. This becomes especially tricky when that software is included in a larger project, paving the way to external attacks. As Google security engineers Kim Lewandowski and Dan Lorenc put it introducing the initiative,

Installing most open source software today is equivalent to picking up a random thumb-drive off the sidewalk and plugging it into your machine.

Supply-chain attacks are a real thing, as multiple cases of malicious packages injected into popular packaging systems, such as RubyGems, NPM, and others, show. Possibly the most impactful recent supply-chain attack was the SolarWinds breach, that affected thousands of customers, including US government agencies.

Eric Brewer, Rob Pike and others at Google have recently stressed the importance of a multifaceted approach to vulnerabilities in open source based on three ideas: know, prevent, fix.

Open source likely makes more use of dependencies than closed source, and from a wider range of suppliers; the number of distinct entities that need to be trusted can be very high. This makes it extremely difficult to understand how open source is used in products and what vulnerabilities might be relevant. There is also no assurance that what is built matches the source code.

While it is in principle possible for an organization to inspect and verify all of their dependencies, since they are available in the open, this is usually not practical, considering that for example Kubernets has about 1,000 dependencies, they say.

One piece of the strategy to tackle this problem is having developers sign their artifacts, including tarballs, container images, binaries, and so on.

To this aim, Sigstore will enable the generation of ephemeral short-lived key pairs that will be used to generate a signing certificate using Sigstore PKI service along with an OpenID connect grant. Sigstore ensures also all certificates are stored certificate transparency log and software signing materials are sent to a signature transparency log.

Sigstore’s transparency logs can act as a source of provenance, integrity, and discoverability. Being public and open anyone can monitor sigstore’s transparency logs for occurrences of their software namespace being used, perform queries using an artifact’s digest, return entries signed by a specific email address, public key, etc.

The team behind Sigstore considered the possibility of using blockchain, but ruled it out due to a number of practical limitations to that approach, including the fact that blockchains often use a centralized entry point for canonicalization, auth, etc. Furthermore, consensus algorithms are susceptible to majority attacks anyway.

Sigstore is still in its infancy as a project, with the transparency log, named 'rekor', being the most advanced component, while the WebPKI and client signing tooling are still at a prototype-level. For more information, you can check the project Slack workspace.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT