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)

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