Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Secure your Open Source Supply Chain with Sigstore

Secure your Open Source Supply Chain with Sigstore

Bob Callaway and Ivan Font of Red Hat will introduce a new project called 'sigstore' that was recently launched under the Linux Foundation. Sigstore aims to empower software developers to easily and securely sign software artifacts such as release files, container images, binaries, bill of material manifests and more. Signing materials are then stored into a tamper resistant public log. They'll show a demo of the system working in OpenShift to sign container images and integrated into a build pipeline with Tekton and Open Policy Agent.

YouTube: https://youtu.be/yKrbUGSwrEw
Speakers: Bob Callaway and Ivan Font (Red Hat)
Host: Karena Angell (Red Hat)

Red Hat Livestreaming

March 30, 2021

More Decks by Red Hat Livestreaming

Other Decks in Technology


  1. 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
  2. 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)
  3. 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
  4. 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
  5. Imagine a world where signing & key management is greatly

    simplified…. and transparency reigns supreme sigstore introducing….
  6. 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
  7. 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)
  8. 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
  9. 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
  10. 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?
  11. 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)
  12. … 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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?