I spent part of this morning revising the submission of an academic paper on the cryptographic protocol behind BastionZero. We were forced to write an extremely short abstract about our protocol, because of space-constraints set by the peer-reviewed academic venue to which we are submitting.
So now we have an ultra-short description of our cryptographic protocol that I figured would be worth sharing here too. Voila!
Engineers inevitably need access to infrastructure targets—like servers, containers, clusters, and databases—so they can respond to incidents and fix services when they break. Bastion hosts are commonly used to facilitate their remote access: a user wishing to access a target is first channeled through the bastion before they jump directly to the target. Since users must traverse the bastion before they can access targets, a bastion is an excellent point to monitor user access and enforce policy, i.e., which user(s) can log into which target(s).
However, bastions come with high operational costs because they need to be continuously patched and highly available. Bastions also present a catastrophic security risk, should they be compromised. This threat is significant, because bastions traditionally rely on a single, all-powerful root of trust, to authenticate users and authorize their access. But if that trust-root is compromised, then all of the infrastructure behind the bastion becomes vulnerable to compromised. The magnitude of this threat is underscored by research showing that remote access is a leading attack vector used by adversaries to infiltrate organizations.
We therefore present MRZAP—a new cryptographic protocol that provides a bastion as a 3rd-party cloud service, such that a compromise of the bastion does not lead to a compromise of any of the infrastructure behind it.
MRZAP (Multi-Root Zero Trust Access Protocol) eliminates the single point of compromise by creating two independent trust-roots. One is the Bastion cloud service, and the other is the organizations' OpenID Connect Identity Provider (eg. Okta, AzureAD, GSuite). With MRZAP, the user chooses a fresh (public, private) key, and then uses OIDC to certify the public key when she performs a single-sign-on (SSO) to the IdP. Then she uses the key to create an authenticated channel from the user (MRZAP client) to the target (MRZAP agent) that transits the Bastion cloud service.
User, running MRZAP client, accesses remote host running MRZAP agent. Bastion monitors access and enforces policy, but cannot access targets itself, or tamper with user sessions. Access is secured by a Zcert certificate which attests to a user's identity and public key. The key creates the MRZAP authenticated channel. Zcert is signed by two trust-roots: (1) the IdP (using OIDC) and (2) Bastion. Before cosigning on the Zcert, Bastion authenticates user via MFA, and checks policy to authorize user access.
Because the channel is authenticated, the Bastion cannot alter communications from user to target. Because the key is certified by the IdP, the Bastion cannot initiate its own connections to the target. This way, the Bastion does not have privileged access to the target. Thus, a compromise of the Bastion does not lead to a compromise of the target. However, because the channel is not encrypted, the Bastion can enforce policy (i.e. stop a user from accessing a given target) and record append-only logs of the actions taken by users, thus realizing the key benefit of bastion hosts.
MRZAP is implemented as a cloud service and supports remote shell, SSH, Kubernetes, database, and webserver targets. The agent and client are open source. MRZAP is fast, adding about ms of round-trip latency, and is used in production by multiple organizations.
That’s all the space we were allowed! To read about the protocol in more detail, see this living whitepaper, or visit the open source repos that host our client and our agent.
In sum, let me leave you with this. With BastionZero, you can have your bastion host, without worrying about securing or maintaining it. That’s because (1) we put your bastion in the cloud, so you don’t have to maintain it, and (2) we developed MRZAP to ensure that a compromise of the bastion does not affect the security of your infrastructure.
See BastionZero in Action
BastionZero connects teams to resources and requires no additional infrastructure to deploy or manage. It is the first—and only—cloud-native solution for trustless access providing multi-root authentication while maintaining zero entitlements to your systems.
With BastionZero, you can reclaim your architecture from over-privileged third parties and ensure that the right people have access to the right resources at just the right time—every time.
Schedule a demo now to see how you can trust less and access more with BastionZero.