“Keyless” Software Signing & Transparency for the Masses! sigstore

Developers Build systems (CI, Compliers) Code reviewers package Code Dependency Consumers Artifact (container,.) Software supply chains..are not ideal! ● Replay / freeze attacks ● Compromised keys ● Account Compromise ● Swapped hashes ● Compromise of build systems ● Easy reconnaissance (open configuration) ● Typosquatting ● Maintainer account takeover 430% increase in supply chain attacks from 2019 through 2020 [1] [1] 2020 State of the Software Supply Chain Report, Sonatype

Who is signing code today? Critical Projects System Signing tools Trust Model Linux Kernel PGP Mostly TOFU (trust on first use) Node.js Core PGP PKs in git repo (insecure) Kubernetes Python PGP Keys on website (insecure) OpenSSL PGP Keys on website (insecure)

Who is signing code today? Package Managers System Signatures Cert Systems In Use PyPI Optional PGP Rarely NPM No NA 0% Maven Central Required PGP/x509 100% Containers Proprietary PGP/x509 Rarely Go N/A Ruby Optional x509 Rare Crates.io No No No

Signing artifacts helps security… but is challenging Verifies integrity of content (signature cannot be verified if even 1 bit is altered) Provides non-repudiation (i.e. the entity that possesses the private key can not state that they did not sign the artifact if private key is actually secret) Authentication: if a private key is conceptually bound to an identity, the sender of signed messages can be assumed If signature includes a (third-party signed) timestamp, consumers can have greater assurances of when the artifact was signed Managing security of private keys is difficult and expensive Security standards are complicated and difficult to understand and apply correctly UX of commonly used tools leaves much to be desired (e.g. pgp) Revocation is inconsistently done by software developers Existing mappings of identity → key pairs have shortcomings or cannot be trusted at all

But even if artifacts are signed… challenges remain

Imagine a world where signing & key management is greatly simplified…. and transparency reigns supreme sigstore introducing….

What is sigstore? “Umbrella brand” launched under Linux Foundation that refers to: A collection of modular FOSS projects that can be deployed independently or together to simplify software signing & transparency Cloud native by default, runs on Kubernetes A free, publicly auditable public-good service (e.g. Let’s Encrypt) available to all developers to sign artifacts, based on the same FOSS projects

sigstore project decoder ring Fulcio: CA issues code signing certificates based on OIDC identity Rekor: signature transparency log - append-only, immutable Cosign: container signing tool And more under development (e.g. Maven plugin, Rubygem signer, in-toto integration, public log monitors, swiss-army-knife tooling, etc)

sigstore architecture fulcio: CodeSigning CA Developer fulcio: CodeSigning Cert Transparency Log Authenticate with OIDC; prove possession of private key Return CodeSign Certificate Publish Cert to Log Monitor log for certs Sign and Publish Artifacts Signed Artifact rekor: Signature Transparency Log Publish signatures End Users Users find and download signed artifact Check signature is in Log Trust Root (policy) Bootstrapped off of Key Transparency Check that signing party is in trust root Monitor log tbd: Deprecation / Policy Transparency Log Monitor log Publish release information OIDC Provider Verify signed ID token from configured OIDC provider +S

DEMO

Built on proven, scalable transparency logs & merkle trees { "Type": { "ns": "rekord", "version": "0.1", "spec": "https://github.com/projectrekor/rekor/rekord_spec.txt" “URL": "https://example/release/my_release.tar.gz", "SHA": "SHA256", "PublicKey": "PUBLIC_KEY", "Signature": "SIG" } Hash A e908u09u093408yd { "Type": { "ns": "rekord", "version": "0.1", "spec": "https://github.com/projectrekor/rekor/rekord_spec.txt" “URL": "https://example/release/my_release.tar.gz", "SHA": "SHA256", "PublicKey": "PUBLIC_KEY", "Signature": "SIG" } Hash B dhu09u0d9u90fsu { "Type": { "ns": "dd", "version": "0.1", "spec": "https://github.com/asdd/rekor/rekord_spec.txt" “URL": "https://example/release/asd.tar.gz", "SHA": "SHA256", "PublicKey": "PUBLIC_KEY", "Signature": "SIG" } Hash C s09u09u09jupojde { "Type": { "ns": "asddasd", "version": "0.1", "spec": "https://gi/rekord_spec.txt" “URL": "https://example/release.tar.gz", "SHA": "SHA256", "PublicKey": "PUBLIC_KEY", "Signature": "SIG" } Hash D 56gf9u09u309u9w Hash(A+B) a7a9u09usdfdr434tfd Root Hash (AB+CD) 09us09ud09jupoij3p49sd Hash(C+D) 848jf0s099409f08us ● Used in git, blockchain, and certificate transparency systems ● Append-only, “immutable” ● Changing a leaf would mean that the hash stored at its parent would be incorrect, as well as the path all the way to the root of the tree ● SHA256 is relatively computationally inexpensive

Transparency Logs helps answer questions like: Is someone else using my private key to sign artifacts? Acme’s credentials / keys were hacked / leaked / lost; what is the blast radius? Who (all) has signed this release / artifact / binary / .. / .. ? Is everyone else seeing the same artifact as me (targeted attack)? How can we be really sure an audit source is tamper resistant?

Before Certificate Transparency ... CA pls sign. I am bigbank.com CSR Signed Cert Hey!, we’re good! Hey CA, bigbank.com. We good right? Website admin Browser Eugh! Everyone is trusting the CA! Sure, let me do some checks..(TXT record)

… With Certificate Transparency CA Hey, pls sign. I am bigbank.com Sure, let me do some checks.. CSR Signed Cert OK, we’re good. Here you go.. Certificate Transparency Log Cert chain Hey CA, bigbank.com. We good right? Hey CTL, you got bigbank.com right? (Expect-CT) Nope! Hey, got any new bigbank.com stuff? Website admin Browser Yup! Hey, we never requested that?? This is NOT good! Monitor

fulcio github.com/sigstore/fulcio

fulcio architecture fulcio: CodeSigning CA Developer fulcio: CodeSigning Cert Transparency Log Authenticate with OIDC; prove possession of private key Return CodeSign Certificate Publish Cert to Log OIDC Provider Verify signed ID token from configured OIDC provider “Keyless”: ephemeral key pair - private key is held in memory only long enough to generate code-signing certificate and sign the actual artifact, and then can be discarded Email address & issuer of OIDC token is included in Code Signing Cert to attest to keyholders’ identity Code signing cert is published to a certificate transparency log that proves that: during the validity period of the OIDC token AND code signing certificate, the person presenting the OIDC token possessed the private key that corresponds to the public key in the certificate

rekor github.com/sigstore/rekor

rekor architecture Developer Sign and Publish Artifacts Signed Artifact rekor: Signature Transparency Log Publish signatures Rekor only inserts records into its transparency log with signatures that it verifies Artifacts are not stored in the transparency log; only the digest, signature & code signing cert/public key REST API allows appending to the log, and getting consistency/inclusion proofs Public-good instance can be publicly monitored (signed tree hashes are stored in public bucket) +S

rekor Manifest Schema (Basic version) ● Default type is the default manifest format for entries in the log ● All supported types are version controlled (allowing format changes with specific validations / handling for user-customized manifests) { "type": "rekord", "apiVersion": "0.0.1", "spec": { "signature": { “format": "pgp", "URL": "https://example/release/my_release.tar.gz.sig", “publicKey": { “url": "https://example/keys/public_key.pgp" }, }, “data”: { "url": "https://example/release/my_release.tar.gz", "hash": { “algorithm”: “sha256”, “value”: "83jfj8we89903uhejw88…" } } } } Multiple PKI formats supported (PGP, x509, minisign) Signature, public key, and content can be provided inline (base64 encoded) or referenced via URL

rekor: Extensible by design Pluggable PKI interface: ● X509 ● GPG ● SSH ● Minisign ○ Plans to add further signing systems. Pluggable supply chain formats: ● Plan to support OCI/Notary V2 signatures as a first-class type (when ready) for container transparency ● Designed to work with TUF/In-Toto ● RPM Signature Transparency /Build auditing ● DBOM/SBOM

cosign github.com/sigstore/cosign

cosign architecture Generates ephemeral key pair (or uses KMS or an existing key pair if specified); Requests code signing certificate from fulcio Downloads container manifest from registry, generates signature Uploads signature, public key (and certificate chain) to container registry as OCI image manifest object Creates entry in rekor for the signed container Container registry cosign rekor: Signature Transparency Log fulcio: CodeSigning CA

Focus Areas for sigstore Roadmap github.com/sigstore/community

Container signing & integration with Kubernetes: Admission controllers that enforce only running signed & policy-compliance containers Schedulers that only run trusted containers on trusted nodes Integrations with containerd, podman/buildah/skopeo Improve and formalize integration with policy frameworks like OPA Drive adoption across OSS community (package managers, popular projects, etc) Areas for innovation / integration

Roadmap at: https://github.com/sigstore/community/blob/main/ROADMAP.md Currently in soft launch for the public-good service https://api.rekor.dev/ https://fulcio.sigstore.dev/ https://sigstore.dev/swagger/ We are ‘kind of’ live

Plans for non/profit & free service

Summary: sigstore 100% open source code; tooling / operations Already under soft launch / active development Free to use / non profit / public good service (run under the LF) Current members include: You?

Questions? github.com/sigstore sigstore.dev slack.sigstore.dev