fulcio - A New Kind of Root CA For Code Signing

fulcio is a free Root-CA for code signing certs - issuing certificates based on an OIDC email address.

fulcio only signs short-lived certificates that are valid for under 20 minutes.

Status

Fulcio is a work in progress. There's working code and a running instance and a plan, but you should not attempt to try to actually use it for anything.

The fulcio root cert running on our public instance (https://fulcio.sigstore.dev) is currently:

We WILL change this and add intermediaries in the future.

Build for development

After cloning the repository:

$ make

There are other targets available in the Makefile, check it out.

API

The API is defined via OpenAPI, defined here.

Transparency

Fulcio will publish issued certificates to a unique Certificate Transparency log (CT-log). That log will be hosted by the sigstore project.

We encourage auditors to monitor this log, and aim to help people access the data.

A simple example would be a service that emails users (on a different address) when ceritficates have been issued on their behalf. This can then be used to detect bad behavior or possible compromise.

CA / KMS support

Google Cloud Platform Private CA

The public fulcio root CA is currently running on GCP Private CA with the EC_P384_SHA384 algorithm.

You can also run with your own GCP Private CA, by passing in a parent and google as the CA

go run main.go serve --ca googleca  --gcp_private_ca_parent=projects/myproject/locations/us-central1/certificateAuthorities/myproject

FuclioCA (PKCS11)

fulcio may also be used with a pkcs11 capable device such as a SoftHSM. You will also need pkcs11-tool

To configure a SoftHSM:

Create a config/crypto11.conf file:

{
"Path" : "/usr/lib64/softhsm/libsofthsm.so",
"TokenLabel": "fulcio",
"Pin" : "2324"
}

And a config/softhsm2.conf

directories.tokendir = /tmp/tokens
objectstore.backend = file
log.level = INFO

Export the config/softhsm2.conf

export SOFTHSM2_CONF=`pwd`/config/softhsm2.cfg

Start a SoftHSM instance

softhsm2-util --init-token --slot 0 --label fulcio

Create keys within the SoftHSM

pkcs11-tool --module /usr/lib64/softhsm/libsofthsm.so --login --login-type user --keypairgen --id 1 --label FulcioCA  --key-type EC:secp384r1

Note: you can import existing keys and import using pkcs11-tool, see pkcs11-tool manual for details

Create a root CA

Now that your keys are generated, you can use the fulcio createca command to generate a Root CA. This command will also store the generated Root CA into the HSM by the delegated id passed to --hsm-caroot-id

fulcio createca --org=acme --country=UK --locality=SomeTown --province=SomeProvince --postal-code=XXXX --street-address=XXXX --hsm-caroot-id 99 --out myrootCA.pem

Run FulcioCA

fulcio serve --ca fulcioca --hsm-caroot-id 99

⚠️ A SoftHSM does not provide the same security guarantees as hardware based HSM Use for test development purposes only.

NOTE

FuclioCA has only been validated against a SoftHSM. In theory this should also work with all PCKS11 compliant HSM's, but to date we have only tested against a SoftHSM.

Other KMS / CA support

Support will be extended to the following CA / KMS systems, feel free to contribute to expedite support coverage

Planned support for:

AWS CloudHSM
Azure Dedicated HSM
YubiHSM

Security Model

Fulcio assumes that a valid OIDC token is a sufficient "proof of ownership" of an email address.
To mitigate against this, Fulcio uses a Transparency log to help protect against OIDC compromise. This means:
- Fulcio MUST publish all certificates to the log.
- Clients MUST NOT trust certificates that are not in the log.
As a result users can detect any mis-issued certificates.
Combined with rekor's signature transparency, artifacts signed with compromised accounts can be identified.

Revocation, Rotation and Expiry

There are two main approaches to code signing:

Long-term certs
Trusted time-stamping

Long-term certs

These certificates are typically valid for years. All old code must be re-signed with a new cert before an old cert expires. Typically this works with long deprecation periods, dual-signing and planned rotations.

There are a couple problems with this approach:

It assumes users can keep acess to private keys and keep them secret over log periods of time
Revocation is hard and doesn't work well

Fulcio's Model

Fulcio is designed to avoid revocation, by issuing short-lived certificates. What really matters for CodeSigning is to know that an artifact was signed while the certificate was valid.

This can be done a few ways:

Third-party Timestamp Authorities (RFC3161)
Transparency Logs
Both (Fulcio's Model)

RFC3161 Timestamp Servers

RFC3161 defines a protocol for Trusted Timestamps. Parties can send a payload to an RFC3161 service and the service digitally signs that payload with its own timestamp. This is the equivalent of posting a hash to Twitter - you are getting a third-party attestation that you had a particular piece of data at a particular time, as observed by that same third-party.

The downside is that users need to interact with another service. They must timestamp all signatures and check the timestamps of all signatures - adding another dependency and set of keys they must trust (the timestamp servers). We could provide one for free, but if people don't trust the clock in our transparency ledger they might not trust another service we run.

Transparency Logs

The rekor service provides a transparency log of software signatures. As entries are appended into this log, rekor periodically signs the full tree along with a timestamp.

An entry in Rekor provides a single-party attestation that a piece of data existed prior to a certain time. These timestamps cannot be tampered with later, providing long-term trust. This long-term trust also requires that the log is monitored.

Transparency Logs make it hard to forge timestamps long-term, but in short time-windows it would be much easier for the Rekor operator to fake or forge timestamps. To mitigate this, Rekor's timestamps and tree head are signed - a valid Signed Tree Head (STH) contains a non-repudiadable timestamp. These signed timestamp tokens are saved as evidence in case Rekor's clock changes in the future. So, more skeptical parties don't have to trust Rekor at all!

Why Not Both!?!?!?

Like usual, we can combine timestamp servers and transparency logs to do a bit better.

Third-party timestamp authorities provide signatures for pieces of data, which includes a timestamp. Rekor can interact with these third-party TSAs automatically, allowing users to skip this step. Rekor can get its own STH (including the timestamp) signed by one or many third-party TSAs regularly.

Each timestamp attestation in the Rekor log provides a fixed "fencepost" in time. Rekor, the client and a third-party can all provide evidence of the state of the world at a point in time. Fenceposts every ten minutes protect all data in between. Auditors can monitor Rekor's log to ensure these are added, shifting the complexity burden from users to auditors.

Security

Should you discover any security issues, please refer to sigstores security process

Info

Fulcio is developed as part of the sigstore project.

We also use a slack channel! Click here for the invite link.

Joker72655561/fulcio