This submit is authored by Hayden Blauzvern and initially appeared on Sigstore’s weblog. Sigstore is a brand new commonplace for signing, verifying, and defending software program. It’s a venture of the Linux Basis.
Builders, package deal maintainers, and enterprises that want to undertake Sigstore might already signal revealed artifacts. Signers might have current procedures to securely retailer and use signing keys. Sigstore can be utilized to signal artifacts with current self-managed, long-lived signing keys. Sigstore gives a easy consumer expertise for signing, verification, and producing structured signature metadata for artifacts and container signatures. Sigstore additionally gives a community-operated, free-to-use transparency log for auditing signature era.
Sigstore moreover has the flexibility to make use of code signing certificates with short-lived signing keys sure to OpenID Join identities. This signing method gives simplicity as a result of lack of key administration; nonetheless, this can be too drastic of a change for enterprises which have current infrastructure for signing. This weblog submit outlines methods to ease adoption of Sigstore whereas nonetheless utilizing current signing approaches.
Signing with self-managed, long-lived keys
Builders that preserve their very own signing keys however need to migrate to Sigstore can first swap to utilizing Cosign to generate a signature over an artifact. Cosign helps importing an current RSA, ECDSA, or ED25519 PEM-encoded PKCS#1 or PKCS#8 key with cosign import-key-pair –key key.pem, and may signal and confirm with cosign sign-blob –key cosign.key artifact-path and cosign verify-blob –key cosign.pub artifact-path.
Advantages
Builders can get accustomed to Sigstore tooling to signal and confirm artifacts.
Sigstore tooling will be built-in into CI/CD pipelines.
For signing containers, signature metadata is revealed with the OCI picture in an OCI registry.
Signing with self-managed keys with auditability
Whereas sustaining their very own signing keys, builders can enhance auditability of signing occasions by publishing signatures to the Sigstore transparency log, Rekor. This enables builders to audit when signatures are generated for artifacts they preserve, and in addition monitor when their signing key’s used to create a signature.
Builders can add a signature to the transparency log throughout signing with COSIGN_EXPERIMENTAL=1 cosign sign-blob –key cosign.key artifact-path. If builders want to use their very own signing infrastructure whereas nonetheless publishing to a transparency log, builders can use the Rekor CLI or API. To add an artifact and cryptographically confirm its inclusion within the log utilizing the Rekor CLI:
rekor-cli add –rekor_server https://rekor.sigstore.dev
–signature
–public-key
–artifact <url_to_artifact|local_path></url_to_artifact|local_path>rekor-cli confirm –rekor_server https://rekor.sigstore.dev
–signature
–public-key
–artifact <url_to_artifact|local_path></url_to_artifact|local_path>
Along with PEM-encoded certificates and public keys, Sigstore helps importing many various key codecs, together with PGP, Minisign, SSH, PKCS#7, and TUF. When importing utilizing the Rekor CLI, specify the –pki-format flag. For instance, to add an artifact signed with a PGP key:
gpg –armor -u consumer@instance.com –output signature.asc –detach-sig package deal.tar.gzgpg –export –armor “consumer@instance.com” > public.keyrekor-cli add –rekor_server https://rekor.sigstore.dev
–signature signature.asc
–public-key public.key
–pki-format=pgp
–artifact package deal.tar.gz
Advantages
Builders start to publish signing occasions for auditability.
Artifact customers can create a verification coverage that requires a signature be revealed to a transparency log.
Self-managed keys in identity-based code signing certificates with auditability
When requesting a code signing certificates from the Sigstore certificates authority Fulcio, Fulcio binds an OpenID Join id to a key, permitting for a verification coverage primarily based on id reasonably than a key. Builders can request a code signing certificates from Fulcio with a self-managed long-lived key, signal an artifact with Cosign, and add the artifact signature to the transparency log.
Nonetheless, artifact customers can nonetheless fail-open with verification (permit the artifact, whereas logging the failure) if they don’t need to take a tough dependency on Sigstore (require that Sigstore providers be used for signature era). A developer can use their self-managed key to generate a signature. A verifier can merely extract the verification key from the certificates with out verification of the certificates’s signature. (Observe that verification can happen offline, since inclusion in a transparency log will be verified utilizing a continued signed bundle from Rekor and code signing certificates will be verified with the CA root certificates. See Cosign’s verification code for an instance of verifying the Rekor bundle.)
As soon as a shopper takes a tough dependency on Sigstore, a CI/CD pipeline can transfer to fail-closed (forbid the artifact if verification fails).
Advantages
A stronger verification coverage that enforces each the presence of the signature in a transparency log and the id of the signer.
Verification insurance policies will be enforced fail-closed.
Id-based (“keyless”) signing
This ultimate step is added for completeness. Signing is completed utilizing code signing certificates, and signatures should be revealed to a transparency log for verification. With identity-based signing, fail-closed is the one choice, since Sigstore providers should be on-line to retrieve code signing certificates and append entries to the transparency log. Builders will not want to take care of signing keys.
Conclusion
The Sigstore tooling and infrastructure can be utilized as an entire or modularly. Every separate integration can assist to enhance the safety of artifact distribution whereas permitting for incremental updates and verifying every step of the mixing.
