Linux Foundation Debuts Sigstore Project for Software Signing

The Linux Foundation today announced its launch of Sigstore, a new nonprofit initiative that aims to improve open source software supply chain security by making it easier for developers to adopt cryptographic signing for different components of the software development process.

Sigstore will be free for software providers and developers, who can use it to securely sign software artifacts such as release files, container images, binaries, and bill-of-material manifests. Signing materials are then stored in a tamper-proof public log. The service's code and operation tooling will be fully open source and maintained and developed by the Sigstore community. 

Founding members include Red Hat, Google, and Purdue University. The idea for the service came from Luke Hinds, security engineering lead in Red Hat's Office of the CTO. He pitched the concept to Google software engineer Dan Lorenc, and the two began to work on it. Now the Sigstore project has a "small but agile community" working on its development, Lorenc says.

Software supply chains face security risks. Users are exposed to targeted attacks, as well as account and cryptographic key compromise. Keys are difficult for software maintainers to manage. Software projects often have a list of keys in use, and maintainers must handle the keys of people no longer involved. These public keys are often stored on git repo readme files or websites, where they may be susceptible to tampering and don't securely convey trust. 

Software signing is meant to convey trust. The process of digitally signing software is meant to provide evidence that the code comes from a known developer or software vendor and hasn't been tampered with. This gives users confidence they're using code from a trusted source.

But few open source projects cryptographically sign software artifacts. "We spent almost the last nine months or so talking to different open source maintainers and communities on how they're doing this, if they're not doing this [then] why not, and then user perspective: Do you care if people are signing? How do you know what keys to check against?" Lorenc says.

Their team found "a huge amount lacking in the space," he continues. Most software projects aren't doing anything at all to improve secure software signing. The tool sets many have used in the past require signing one other's keys in person, which doesn't work for remote developers, Hinds adds. Sigstore aims to both ease the adoption, and lower the risk, of software signing.

"When you take on signing, you take on a lot of risk as well, because … you have to protect a private key and this really exposes the risk of a project," Hinds continues. "It's a kind of chicken and egg: The need to sign things to provide assurance to their users, but once they do start to sign things, they up the ante around their attack surface and a possible key compromise."

How It Works
To make the process simple, Sigstore relies on the OpenID authentication protocol to connect certificates to identities. This allows developers to use security controls they already have, such as multifactor authentication, one-time passwords, and hardware token generators. 

Existing signing solutions essentially work to build a whole new identity system, and give users private keys they're responsible for protecting, Lorenc explains. Sigstore "piggybacks off of an existing identity system that everybody already knows how to work with, that's already federated, and already gets all the attention of security professionals at organizations." 

Sigstore users use its tooling to create ephemeral short-lived key pairs. Its public key infrastructure (PKI) service provides a signing certificate following the successful OpenID connect grant. From there, certificates are recorded into a certificate transparency log, and software signing materials go to a signature transparency log, Sigstore explains on its website.

These transparency logs are a public and tamper-proof record of sign-in events, Hinds notes. "By having that available, anybody can audit or monitor these logs for who's signing what. It makes it publicly transparent," he adds. Anyone can perform queries using an artifacts digest or return entries that are signed by a specific public key or email address. 

Because the keys are short-lived, there is no concern about keys potentially being left and vulnerable to compromise, Hinds says. After that, there's nothing left for the developer to manage and all activity is recorded in the log. 

Today marks the launch of the foundation, Hinds says. While the transparency log is fully functional, Sigstore isn't available to developers just yet. As for what developers will be able to sign and store, the team is first aiming for generic release artifacts such as compiled binaries and container images. Later on, they plan to explore other formats and manifest signing.

The team hopes Sigstore will be made available later this year, though an official date has not yet been determined.