The Linux Foundation, BastionZero, and Docker introduced a new open project called OpenPubKey, which develops the namesake cryptographic protocol for certifying digital signatures of arbitrary objects. This technology has been created as a joint project by BastionZero and Docker to simplify the certification of Docker container images with digital signatures, preventing tampering and confirming the build by the declared creator. The project will evolve on a neutral platform under the auspices of the Linux Foundation, eliminating dependence on individual commercial companies and facilitating collaboration with third-party participants. The reference implementation of OpenPubKey is written in Go and is distributed under the Apache 2.0 license. <\/p>\n
The capabilities of OpenPubKey go beyond just container images; the technology can be applied to confirm the origin of any resource, preventing dependency tampering and enhancing the security of data distribution channels. For instance, the technology is applicable for certifying software builds, individual messages, and commits. Signature creators only need to have an account with a service that supports OpenID, while consumers are given the ability to verify attached signatures and confirm their connection to the declared OpenID identifier. <\/p>\n
In its purpose, OpenPubKey resembles the system Sigstore created by Google and previously handed over to the Linux Foundation, but it differs substantially by simplifying implementation, usage, and maintenance, removing centralized server components responsible for maintaining a public log verifying changes' authenticity (transparency log), and ensuring the operation of certificate authorities. <\/p>\n
Instead of deploying their own certificate authorities, OpenPubKey uses authentication with OpenID technology and links created signatures to existing OpenID Connect providers. In other words, OpenPubKey allows cryptographic keys to be tied to specific users, using OpenID Connect providers (IdPs) instead of certificate authorities. The technology is fully compatible with existing OpenID providers such as GitHub, Azure\/Microsoft, Okta, OneLogin, Keycloak, and Google, and does not require changes on their part (it uses the standard ID Token provided by the provider, allowing OpenPubKey to be implemented solely through changes on the OpenID Connect client side). <\/p>\n
The OpenID token issued by the provider is transformed into a certificate that cryptographically binds the identifier in OpenID Connect to a public key. The user then uses the generated key to sign any data, and these signatures can later be verified against the identifier in OpenID Connect. In OpenPubKey, ephemeral keys are used, with a limited lifespan \u2014 keys are generated during login using OpenID and deleted when the session with the OpenID provider ends. <\/p>\n
An example algorithm for creating a signature using OpenPubKey: <\/p>\n
Verification consists of checking whether the attached token was signed by the OpenID provider and verifying the correctness of the digital signature to the resource against the public key, allowing confirmation that the resource is signed using the identifier from the certificate and this is confirmed by the OpenID provider's signature. For example, the signer can obtain a token signed by Google's OpenID provider stating that they are verified as bob@gmail.com and uses the public key 0x54A5\u2026FF. Subsequently, upon receiving a message signed by the same key, they can use the signed token from the provider to verify that bob@gmail.com \u2014 0x54A5\u2026FF truly signed the message. <\/p>\n
The simplification of architecture has been implemented through certain compromises (for example, the reliance on external OpenID providers and the lack of a change log with hierarchical hashing), which may be acceptable in some situations and not in others. To reduce dependence on OpenID providers, whose compromise or actions can discredit the system (for instance, a hacked provider can issue a fake key to a third party), it is suggested to use an additional, but not mandatory, link called MFA-Cosigner (Multi-Factor Authentication Cosigner) for multi-factor authentication (the token must be signed not only by the main provider but also by an independent authentication service confirming the user). <\/p>\n