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.
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.
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.
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).
The token issued by the OpenID provider is transformed into a certificate that cryptographically binds the identifier in OpenID Connect to the public key. The user then uses the generated key to sign any data, and these signatures can later be verified for association with the identifier in OpenID Connect. OpenPubKey uses ephemeral keys with a limited lifetime — keys are generated during login via OpenID and deleted upon session termination with the OpenID provider.
An example algorithm for creating a signature using OpenPubKey:
- Login using an OpenID provider (Google, GitHub, Microsoft, etc.).
- Request an identification token from the OpenID provider.
- Return the token, signed by the provider's key and including a 'nonce' field with arbitrary data sent during the request (the SHA3 hash of the public key is transmitted).
- Use the received token as a certificate on the user's side, containing key data.
- Attach the token to the signature, similar to a certificate.
Verification involves checking whether the attached token is signed by the OpenID provider and verifying the validity of the digital signature against the resource using a public key. This ensures that the resource is signed with the identifier from the certificate, and this is confirmed by the signature of the OpenID provider. For example, the signer may obtain a token signed by the Google OpenID provider, indicating that they are verified as bob@gmail.com and use the public key 0x54A5…FF. Then, upon receiving a message signed with the same key, the signer can use the token signed by the provider to verify that the key for bob@gmail.com is 0x54A5…FF and that the message was indeed signed by bob@gmail.com.
The simplification of the architecture has been achieved through certain compromises (for instance, dependence on external OpenID providers and lack of a change log with hierarchical hashing), which may be acceptable in some situations and not in others. To reduce reliance on OpenID providers, the compromise or actions of whose staff could damage the system (for example, a hacked provider could issue a fake key to a third party), it is proposed to use an additional, but not mandatory, link called MFA-Cosigner (Multi-Factor Authentication Cosigner) for multi-factor authentication (the token should be signed not only by the main provider but also by an independent authentication service that confirms the user).
Among the weaknesses of OpenPubKey, there is also the presence of external information that can be used to track activity over a long period and independently of renaming (reusing an identifying token instead of a new certificate). Direct binding to OpenID Connect keys during verification excludes the server-side but significantly complicates implementation on the client side and leaves more room for maneuvers when carrying out attacks (attack surface) on the client, for example, due to the client's responsibility for key rotation. The absence of a change log does not allow the client to track potential key leaks.
Source: opennet.ru
