Sign of the primes: Linux Foundation serves up free code-signing service • The Register
Sign of the primes: Linux Foundation serves up free code-signing service
Cryptographic software assurance backed by Google, Red Hat, Purdue U
Thomas Claburn in San Francisco Tue 9 Mar 2021 // 17:00 UTC SHARE
The Linux Foundation, with the support of Google, Red Hat, and Purdue University, is launching a service called sigstore to help developers sign the code they release.
Signing code involves associating a cryptographic signature with a specific digital artifact – release files, container images, and binaries – so that the person using the software can check the code's signature to verify that the release is authentic and hasn't been altered by someone along the way.
"Sigstore enables all open source communities to sign their software and combines provenance, integrity and discoverability to create a transparent and auditable software supply chain," said Luke Hinds, security engineering lead in Red Hat's office of the CTO, in a statement.
Sigstore aims to provide that service in a way that makes the process easier for developers, so they don't have to deal with the key management issues that arise when signing code on one's own or as part of a project with multiple maintainers.
"The tools that are available for developers to cryptographically sign the authenticity of software are just not up to the job," said Hinds in an interview with The Register. "They're not really applicable in the current situation that we find ourselves in."
Sigstore has been designed as a free, non-profit service, along the lines of ISRG's Let's Encrypt, which has vastly improved access to TLS/SSL certificates.
rip
Let's Encrypt completes huge upgrade, can now rip and replace 200 million security certs in 'worst case scenario'
READ MORE
"A lot of it's inspired by Apple's model around signing and Microsoft has a similar one," said Dan Lorenc, a software engineer on Google's open source team. "We're trying to combine that with the Let's Encrypt style approach of automatically granting and managing short-lived keys."
Lorenc as an example cited a developer working on a Node.js app who wanted to publish it to npm, the Node Package Manager registry. You would run a command to sign your app, your browser would open and you'd complete the OpenID Connect (OIDC) authentication flow and two-factor authentication check to obtain an authorization token. A certificate would be automatically issued to your OIDC email address and it would then be uploaded to npm.
Hinds said the only bits of data that get stored are the signature used to sign the digital artifact, the email address associated with the OIDC login, the public key, and the digest (the output of a hash function) of the component signed.
"There's no need to store private keys on somebody else's infrastructure," said Hinds. "That's the really nice thing about this: The keys are generated and then they're immediately discarded. They can't be used again."
There's no need to store private keys on somebody else's infrastructure
Sigstore is based on X.509 PKI and transparency logs, which provide a way to check on signatures that have been issued.
Asked how sigstore will deal with potential abuse, Hinds said the service is set up for auditing.
"We don't want to block the bad stuff coming in because the signature signing system is backed by a technology called a transparency log, which is where all of the signatures, and who signed what, is stored," he said.
This allows anyone, via an API that's provided, to audit signatures. In fact, Hinds expects software companies will integrate this capability into their own security monitoring services.
"Once it's available, security researchers can start to really scrutinize this, and look at what's happening," he said, imagining that it might be used for detecting typosquatting or other suspicious patterns
Cryptographic software assurance backed by Google, Red Hat, Purdue U
Thomas Claburn in San Francisco Tue 9 Mar 2021 // 17:00 UTC SHARE
The Linux Foundation, with the support of Google, Red Hat, and Purdue University, is launching a service called sigstore to help developers sign the code they release.
Signing code involves associating a cryptographic signature with a specific digital artifact – release files, container images, and binaries – so that the person using the software can check the code's signature to verify that the release is authentic and hasn't been altered by someone along the way.
"Sigstore enables all open source communities to sign their software and combines provenance, integrity and discoverability to create a transparent and auditable software supply chain," said Luke Hinds, security engineering lead in Red Hat's office of the CTO, in a statement.
Sigstore aims to provide that service in a way that makes the process easier for developers, so they don't have to deal with the key management issues that arise when signing code on one's own or as part of a project with multiple maintainers.
"The tools that are available for developers to cryptographically sign the authenticity of software are just not up to the job," said Hinds in an interview with The Register. "They're not really applicable in the current situation that we find ourselves in."
Sigstore has been designed as a free, non-profit service, along the lines of ISRG's Let's Encrypt, which has vastly improved access to TLS/SSL certificates.
rip
Let's Encrypt completes huge upgrade, can now rip and replace 200 million security certs in 'worst case scenario'
READ MORE
"A lot of it's inspired by Apple's model around signing and Microsoft has a similar one," said Dan Lorenc, a software engineer on Google's open source team. "We're trying to combine that with the Let's Encrypt style approach of automatically granting and managing short-lived keys."
Lorenc as an example cited a developer working on a Node.js app who wanted to publish it to npm, the Node Package Manager registry. You would run a command to sign your app, your browser would open and you'd complete the OpenID Connect (OIDC) authentication flow and two-factor authentication check to obtain an authorization token. A certificate would be automatically issued to your OIDC email address and it would then be uploaded to npm.
Hinds said the only bits of data that get stored are the signature used to sign the digital artifact, the email address associated with the OIDC login, the public key, and the digest (the output of a hash function) of the component signed.
"There's no need to store private keys on somebody else's infrastructure," said Hinds. "That's the really nice thing about this: The keys are generated and then they're immediately discarded. They can't be used again."
There's no need to store private keys on somebody else's infrastructure
Sigstore is based on X.509 PKI and transparency logs, which provide a way to check on signatures that have been issued.
Asked how sigstore will deal with potential abuse, Hinds said the service is set up for auditing.
"We don't want to block the bad stuff coming in because the signature signing system is backed by a technology called a transparency log, which is where all of the signatures, and who signed what, is stored," he said.
This allows anyone, via an API that's provided, to audit signatures. In fact, Hinds expects software companies will integrate this capability into their own security monitoring services.
"Once it's available, security researchers can start to really scrutinize this, and look at what's happening," he said, imagining that it might be used for detecting typosquatting or other suspicious patterns
