Carding 4 Carders
Professional
- Messages
- 2,724
- Reaction score
- 1,588
- Points
- 113
The Linux Foundation, BastionZero, and Docker have introduced a new open-source project called OpenPubKey, which develops a cryptographic protocol of the same name for digitally signing arbitrary objects. The technology was developed as a joint project of BastionZero and Docker to simplify digital signature certification of Docker container images to avoid their substitution and confirmation of the assembly by the declared creator. The project will be developed on a neutral platform under the auspices of the Linux Foundation organization, which will eliminate dependence on individual commercial companies and simplify collaboration with the involvement of third-party participants. The reference implementation of OpenPubKey is written in Go and distributed under the Apache 2.0 license.
OpenPubKey's capabilities are not limited to container images, and the technology can be used to confirm the source of any resource, prevent dependency substitution, and improve the security of distribution channels for data sets. For example, the technology can be used to validate program builds, individual messages, and commits. OpenID-enabled service account is sufficient for signature creators, and consumers can check the attached signatures and confirm their connection with the declared OpenID identifier.
OpenPubKey is similar in purpose to the Sigstore system created by Google and previously transferred to the Linux Foundation, but it differs from it by significantly simplifying implementation, use, and maintenance by eliminating centralized server components responsible for maintaining a public log confirming the authenticity of changes (transparency log) and ensuring the operation of certificate authorities.
OpenID authentication is used instead of deploying your own certificate authorities in OpenPubKey, and the created signatures are linked to existing OpenID Connect providers. In other words, OpenPubkey allows you to link cryptographic keys to specific users, using OpenID Connect providers (IDPs) instead of certificate authorities. The OpenID 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 side (the standard ID Token provided by the provider is used, which allows you to implement OpenPubKey only through changes on the OpenID Connect client side).
The OpenID token issued by the provider is transformed into a certificate that cryptographically binds the ID in OpenID Connect to the user's public key. Then the user uses the linked key to sign any data and these signatures can be further verified for connection with their ID in OpenID Connect. However, OpenIDpubkey uses ephemeral keys with a limited lifetime : keys are generated during login using OpenID and deleted when the session with the OpenID provider ends.
Sample algorithm for creating a signature using OpenPubKey:
* Log in using an OpenID provider (Google, GitHub, Microsoft, etc.).
* Request an identification token from the OpenID provider.
* Returns a token signed with the provider's key and including the "nonce" field with arbitrary data passed during the request (the SHA3 hash of the public key is passed to "nonce").
* Use the received token on the user's side as a certificate that includes key data.
* Attaching a token to a signature, similar to a certificate.
Verification consists of two checks: whether the attached token is signed by the OpenID provider; and whether the digital signature to the resource corresponds to the declared public key marked in the token. These checks allow you to make sure that the resource is signed using the user ID mentioned in the token and this is confirmed by the signature of the OpenID provider. For example, the signer can receive a token signed by Google's OpenID provider with the information that it is verified as bob@gmail.com and uses the public key 0x54A5 ... FF. Further, when processing a message signed with the key 0x54A5...FF, the recipient can use a token signed by the OpenID provider to verify that the user has the following information: bob@gmail.com indeed, the public key is 0x54A5 ... FF and the message was signed by him.
The architecture is simplified by certain trade-offs that are acceptable in some situations and not in others (for example, dependence on external OpenID providers and the absence of a change log with hierarchical hashing). To reduce dependence on OpenID providers whose compromise or personnel actions may discredit the system (for example, hacked providers may issue a fictitious key to a third party), it is suggested to use an additional, but not mandatory, MFA link-Cosigner (Multi-Factor Authentication Cosigner) for multi-factor authentication (the token can be signed not only by the main provider, but also by a third party). and another authentication service that confirms the user). *
One of the weaknesses of OpenPubKey is also the presence of extraneous information that can be used to track activity for a long time and regardless of renaming (repeated use of an identifying token instead of a new certificate). Direct binding to OpenID Connect keys during verification eliminates the server part, but significantly complicates implementation on the client side and leaves more room for maneuver when performing attacks (attack surface) on the client, for example, due to the fact that the client has the task of key rotation. In addition, the absence of a change log does not allow the client to track possible key leaks.
OpenPubKey's capabilities are not limited to container images, and the technology can be used to confirm the source of any resource, prevent dependency substitution, and improve the security of distribution channels for data sets. For example, the technology can be used to validate program builds, individual messages, and commits. OpenID-enabled service account is sufficient for signature creators, and consumers can check the attached signatures and confirm their connection with the declared OpenID identifier.
OpenPubKey is similar in purpose to the Sigstore system created by Google and previously transferred to the Linux Foundation, but it differs from it by significantly simplifying implementation, use, and maintenance by eliminating centralized server components responsible for maintaining a public log confirming the authenticity of changes (transparency log) and ensuring the operation of certificate authorities.
OpenID authentication is used instead of deploying your own certificate authorities in OpenPubKey, and the created signatures are linked to existing OpenID Connect providers. In other words, OpenPubkey allows you to link cryptographic keys to specific users, using OpenID Connect providers (IDPs) instead of certificate authorities. The OpenID 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 side (the standard ID Token provided by the provider is used, which allows you to implement OpenPubKey only through changes on the OpenID Connect client side).
The OpenID token issued by the provider is transformed into a certificate that cryptographically binds the ID in OpenID Connect to the user's public key. Then the user uses the linked key to sign any data and these signatures can be further verified for connection with their ID in OpenID Connect. However, OpenIDpubkey uses ephemeral keys with a limited lifetime : keys are generated during login using OpenID and deleted when the session with the OpenID provider ends.
Sample algorithm for creating a signature using OpenPubKey:
* Log in using an OpenID provider (Google, GitHub, Microsoft, etc.).
* Request an identification token from the OpenID provider.
* Returns a token signed with the provider's key and including the "nonce" field with arbitrary data passed during the request (the SHA3 hash of the public key is passed to "nonce").
* Use the received token on the user's side as a certificate that includes key data.
* Attaching a token to a signature, similar to a certificate.
Verification consists of two checks: whether the attached token is signed by the OpenID provider; and whether the digital signature to the resource corresponds to the declared public key marked in the token. These checks allow you to make sure that the resource is signed using the user ID mentioned in the token and this is confirmed by the signature of the OpenID provider. For example, the signer can receive a token signed by Google's OpenID provider with the information that it is verified as bob@gmail.com and uses the public key 0x54A5 ... FF. Further, when processing a message signed with the key 0x54A5...FF, the recipient can use a token signed by the OpenID provider to verify that the user has the following information: bob@gmail.com indeed, the public key is 0x54A5 ... FF and the message was signed by him.
The architecture is simplified by certain trade-offs that are acceptable in some situations and not in others (for example, dependence on external OpenID providers and the absence of a change log with hierarchical hashing). To reduce dependence on OpenID providers whose compromise or personnel actions may discredit the system (for example, hacked providers may issue a fictitious key to a third party), it is suggested to use an additional, but not mandatory, MFA link-Cosigner (Multi-Factor Authentication Cosigner) for multi-factor authentication (the token can be signed not only by the main provider, but also by a third party). and another authentication service that confirms the user). *
One of the weaknesses of OpenPubKey is also the presence of extraneous information that can be used to track activity for a long time and regardless of renaming (repeated use of an identifying token instead of a new certificate). Direct binding to OpenID Connect keys during verification eliminates the server part, but significantly complicates implementation on the client side and leaves more room for maneuver when performing attacks (attack surface) on the client, for example, due to the fact that the client has the task of key rotation. In addition, the absence of a change log does not allow the client to track possible key leaks.
