New post: Understanding the Identity of a CI Platform

Author: richardfan1126

content/understanding-the-identity-of-a-ci-platform.md

@@ -0,0 +1,62 @@
++++
+title = "Understanding the Identity of a CI Platform"
+date = "2024-12-15"
+tags = ["sigstore", "security", "identity", "clients", "devops"]
+draft = false
+author = "Richard Fan (@richardfan1126)"
+type = "post"
++++
+
+_This post is based on a talk on SigStoreCon Supply Chain Day 2024. Checkout the [recording](https://youtu.be/-GkfNeE_7us?si=cqAj60-zwJp0n66Z) on sigstore YouTube channel_
+
+### TL;DR
+
+When verifying a sigstore keyless signature, solely relying on the Subject Alternative Name (SAN) is sometimes unreliable, especially when the signature is generated by a CI platform. This post talks about a [security research] where [GitHub reusable workflow](https://docs.github.com/en/actions/sharing-automations/reusing-workflows) can be misused to generate signatures bearing SANs of another entity.
+
+Verifying additional [Fulcio certificate extensions](https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md) (e.g., Source Repository URI) is a way to ensure the real source of a CI-generated signature, but supports from different sigstore clients are not unified. sigstore users, both software maintainers and users, need to pay attention to using Fulcio certificates to verify software sources.
+
+### Picking the right SAN is difficult
+
+One of the main features of sigstore is keyless signing, where sigstore clients use the signing entities' OIDC token to [exchange a signing certificate](https://docs.sigstore.dev/certificate_authority/oidc-in-fulcio/). Despite Fulcio mapping most of the CI platform OIDC token attributes into the certificate as extensions, we still need to pick the most suitable attribute to be the signer's primary identity (or SAN).
+
+#### GitHub Actions SAN
+
+One of the examples to showcase the difficulties is GitHub Actions. Fulcio uses `job_workflow_ref` as [the SAN of GitHub Actions workflow](https://docs.sigstore.dev/certificate_authority/oidc-in-fulcio/#github).
+
+From GitHub [documentation](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows#how-the-token-works-with-reusable-workflows), `job_workflow_ref` refers to the **called workflow** in a reusable workflow scenario.
+
+The problem now is: There are 2 workflows (**caller** and **called**) involved, and Fulcio certificate SAN can only describe one of them. And now, sigstore chooses to describe the **called** workflow by using the `job_workflow_ref` claim.
+
+In my [security research], I demonstrated how a random GitHub user can call the reusable workflow in the `argoproj/argo-cd` repository, generate a signature bearing its identity, and ultimately pass the `cosign verify` check. This scenario is possible because Fulcio certificate SAN only describes the **called** workflow, but not the **caller** workflow, where the real software source code comes from.
+
+### Checking certificate extensions
+
+The solution to this problem is straightforward: Checking the certificate extensions.
+
+Fulcio's certificate includes many other OIDC claims as certificate extensions. When verifying sigstore signatures, we can add more conditions based on those extensions.
+
+E.g., we can add the following flag into the `cosign verify` command to verify the GitHub source code repository:
+
+```bash
+--certificate-github-workflow-repository "argoproj/argo-cd" 
+```
+
+When designing the signature verification procedure, read the [Mapping OIDC token claims to Fulcio OIDs](https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md#mapping-oidc-token-claims-to-fulcio-oids) in addition the official documentations of each CI platform. This way, we can understand which certificate extensions best fit our requirements.
+
+#### Clients support status
+
+Unfortunately, verifying certificate extensions is not fully supported by all sigstore clients. Below is the table of the current support status _(As of 12th Nov 2024)_
+
+| Not Supported     | Only for GitHub         | New OID scheme                                               |
+|-------------------|-------------------------|--------------------------------------------------------------|
+| sigstore-js       | [sigstore-python (CLI)] | [sigstore-java]                                              |
+| sigstore-rs       | [cosign]                | [sigstore-python (API)]                                      |
+| sigstore-ruby     |                         | sigstore-go<br>(Using function [`NewCertificateIdentity()`]) |
+| policy-controller |                         |                                                              |
+
+[security research]: https://blog.richardfan.xyz/2024/08/02/reusable-workflow-is-good-until-you-realize-your-identity-is-also-reusable-by-anyone.html
+[sigstore-python (CLI)]: https://github.com/sigstore/sigstore-python/tree/0ac33eeaeb62ca466cef2708ca1dd5864382a008?tab=readme-ov-file#signatures-from-github-actions
+[sigstore-java]: https://github.com/sigstore/sigstore-java/blob/cc82dd21b8bbb32624790efa0d169f093b348ef8/sigstore-java/src/test/java/dev/sigstore/fulcio/client/FulcioCertificateMatcherTest.java#L53-L66
+[cosign]: https://github.com/sigstore/cosign/blob/main/doc/cosign_verify.md#options
+[sigstore-python (API)]: https://github.com/sigstore/sigstore-python/blob/0ac33eeaeb62ca466cef2708ca1dd5864382a008/test/unit/verify/test_policy.py#L173
+[`NewCertificateIdentity()`]: https://github.com/sigstore/sigstore-go/blob/aff64448eb1f85271fc4753b3ba016e15d9bbfa4/pkg/verify/certificate_identity.go#L150