We have been working to write up the cryptographic protocols which BastionZero uses to offer remote access. As part of this effort, we recently released a draft of our protocol, OpenPubkey: Augmenting OpenID Connect with User held Signing Keys. BastionZero uses OpenPubkey to cryptographically bind your public key to your identity at an OpenID Provider like Google. Read on to learn how our advancement in cryptographic signatures allows us to offer a new way to provide OpenID Connect multi-factor authentication (MFA).
OpenPubkey Summary:
OpenPubkey adds user generated cryptographic signatures to OpenID Connect (OIDC), the de facto standard of Single Sign-On (SSO) on the web. It offers a significant security upgrade over regular OpenID Connect. With OpenPubkey users can now sign messages and requests under their SSO identity without adding any trusted parties beyond what is required for OpenID Connect. OpenPubkey is fully compatible with existing OpenID Providers without any changes to the OpenID Provider. When used with MFA, it eliminates OpenID Providers as a single point of compromise.
OpenPubkey Transforms Authentication on the Web
OpenPubkey enables users to cryptographically sign messages with their identity. Our approach to providing this long-awaited functionality has a number of advantages:
- Ease of use: OpenPubkey offers a simple and compatible method for employing cryptographic signatures on the web, eliminating typical usability issues.
- Invisible: As most users already have accounts with OpenID Providers, OpenPubkey integrates so smoothly into existing user workflows that it is invisible to users.
- Ephemeral secrets: Users' public keys and signing keys are ephemeral, generated upon login and deleted upon logout, eliminating the security risks and headaches of long-lived secrets and keys.
- Full Compatibility with OpenID Connect: OpenPubkey is so compatible with existing OpenID Providers that they cannot even tell that OpenPubkey is being used. BastionZero has been using a version of this OpenPubkey for several years to offer secure access to servers, Kubernetes and other infrastructure.
- No permission required: Anyone can deploy OpenPubkey.
How OpenPubkey works
We are going to use Google as our example OpenID Provider, but OpenPubkey is currently being used with other OpenID Providers, including Microsoft, Okta, OneLogin, etc.
When you click an OpenID button such as: “Sign In With Google”:
- The client, often JavaScript running in your browser, sends a random value, called a nonce, to Google. This kicks off the OpenID Connect authentication.
- Google authenticates your identity based on your current session with Google and then signs an ID Token under Google’s Signing Key. This ID Token says who you are according to Google: “This user is Alice@gmail.com”. This ID Token includes the nonce, i.e., the random value your client sent.
- You can use this ID Token to authenticate to a webapp. The webapp knows this ID token was issued by Google because it can check that the ID Token was signed by Google. Google's public keys can be found here.
- Once the webapp verifies Google’s signature, it is convinced of your identity. That is, it believes Alice is Alice@gmail.com because Google said so in the ID Token.
OpenPubkey augments OpenID Connect so that not only does Google specify your identity in the ID Token, but it also includes your public key in the ID Token. Your public and signing keys are generated when you click the “Sign In With Google'' button. The public key is then included in the nonce value sent to Google. Since the nonce now includes your public key, the ID Token now functions like a certificate, binding together the user’s identity and the user’s public key.
For example, consider receiving the following ID Token signed by Google: "Alice@gmail.com's public key is 0x43E5…FF". If you then get a message signed under that same public key 0x43E5…FF which says: “I, Alice@gmail.com, would like to open a connection to the server xyz.abc.net," you can use the ID Token to verify Alice’s Pubkey is actually “0x43E5…FF” and then verify that the message you received was actually signed by Alice.
At a high level this is how BastionZero works: the server which a user wishes to access, checks the name and public key of the user based on the ID Token.
In BastionZero we developed the Zero-Trust Command Line Interface (ZLI) to act as the OpenPubkey client. The ZLI is a native application which is open source. Companies and users don’t need to trust us, they can just read the code.
Eliminating the OpenID Provider as a Single Point of Compromise
OpenID Connect trusts OpenID Providers to accurately attest to user identities. If a malicious party obtained Google's Signing Key, they could falsely claim to be Alice and link their evil public key to Alice’s identity. As cryptographers, it is in our nature to eliminate Single Points of Compromise (SPoCs) like this. Let’s look at how we address this.
OpenPubkey introduces an additional party called the MFA-Cosigner, which authenticates users using Multi-Factor Authentication (MFA). This results in two independent signed statements about Alice's identity:
- ID Token Signed by Google: "Alice@gmail.com's public key is 0x43E5…FF"
- ID Token signed by the MFA-Cosigner:
"I, the MFA-Cosigner, independently authenticated Alice@gmail.com, and her public key is 0x43E5…FF"
If an MFA-Cosigner is used then security remains intact even if the OpenID Provider (Google) is malicious or compromised. Likewise, if an MFA-Cosigner is compromised and the OpenID Provider is not, security is still maintained. This is because a server should not accept a user unless both Google and the MFA-Cosigner agree on the user’s identity and public key.
While OpenPubkey can function without the MFA-Cosigner, the inclusion of the MFA-Cosigner significantly enhances security compared to using OpenID Connect or OpenPubkey alone.
For a deeper discussion of OpenPubkey's security, refer to the OpenPubkey paper.
