Sigstore can be thought of as a Let's Encrypt for code, providing certificates to digitally sign code and tools to automate verification.
Google unveiled through a blog post, the announcement of the formation of the first stable versions of the components that make up the project sigstore, which is declared suitable for creating working deployments.
For those who are unaware of Sigstore, they should know that this is a project that has the purpose of developing and providing tools and services for the verification of software using digital signatures and maintaining a public registry that confirms the authenticity of the changes (transparency registry).
With Sigstore, developers can digitally sign application-related artifacts such as release files, container images, manifests, and executables. The material used for the signature is reflected in a tamper-proof public record which can be used for verification and auditing.
Instead of permanent keys, Sigstore uses short-lived ephemeral keys that are generated based on the credentials verified by the OpenID Connect providers (at the time of generating the keys necessary to create a digital signature, the developer is identified through the OpenID provider with an email link).
The authenticity of the keys is verified by a centralized public registry, which allows you to make sure that the author of the signature is exactly who they say they are, and that the signature was formed by the same participant who was responsible for earlier versions.
The preparation of Sigstore for implementation is due to versioning of two key components: Rekor 1.0 and Fulcio 1.0, whose programming interfaces are declared stable and henceforth retain compatibility with previous versions. The components of the service are written in Go and are released under the Apache 2.0 license.
The component Rekor contains a registry implementation to store digitally signed metadata that reflect information about projects. To ensure integrity and protection against data corruption, a Merkle Tree structure is used in which each branch verifies all underlying branches and nodes via joint hash (tree). By having a final hash, the user can verify the correctness of the entire operation history, as well as the correctness of past states of the database (the root check hash of the new state of the database is calculated considering the past state). A RESTful API for checking and adding new records is provided, as well as a command line interface.
The component fulcius (SigStore WebPKI) includes a system for creating certification authorities (root CA) that issue short-lived certificates based on authenticated email via OpenID Connect. The lifetime of the certificate is 20 minutes, during which the developer must have time to generate a digital signature (if the certificate falls into the hands of an attacker in the future, it will already be expired). Also, the project develops the Cosign toolkit (Container Signing), designed to generate signatures for containers, verify signatures and place signed containers in OCI (Open Container Initiative) compliant repositories.
The introduction of Sigstore allows to increase the security of software distribution channels and protect against attacks targeting library and dependency substitution (supply chain). One of the key security issues in open source software is the difficulty of verifying the source of the program and verifying the build process.
The use of digital signatures for version verification is not yet widespread due to difficulties in key management, public key distribution, and revocation of compromised keys. For verification to make sense, it is also necessary to organize a reliable and secure process for the distribution of public keys and checksums. Even with a digital signature, many users ignore verification because it takes time to learn the verification process and understand which key is trusted.
The project is being developed under the auspices of the nonprofit Linux Foundation of Google, Red Hat, Cisco, vmWare, GitHub, and HP Enterprise with the participation of OpenSSF (Open Source Security Foundation) and Purdue University.
Finally, if you are interested in being able to know more about it, you can consult the details in the following link.