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
Tweet

More Decks by Red Hat Livestreaming

Other Decks in Technology

Transcript

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

    View Slide

  2. 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

    View Slide

  3. 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)

    View Slide

  4. 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

    View Slide

  5. 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

    View Slide

  6. But even if artifacts are signed… challenges remain

    View Slide

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

    View Slide

  8. 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

    View Slide

  9. 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)

    View Slide

  10. 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

    View Slide

  11. DEMO

    View Slide

  12. 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

    View Slide

  13. 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?

    View Slide

  14. 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)

    View Slide

  15. … 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

    View Slide

  16. fulcio
    github.com/sigstore/fulcio

    View Slide

  17. 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

    View Slide

  18. rekor
    github.com/sigstore/rekor

    View Slide

  19. 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

    View Slide

  20. 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

    View Slide

  21. 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

    View Slide

  22. cosign
    github.com/sigstore/cosign

    View Slide

  23. 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

    View Slide

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

    View Slide

  25. 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

    View Slide

  26. 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

    View Slide

  27. Plans for non/profit & free service

    View Slide

  28. 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?

    View Slide

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

    View Slide