This video is number nine of the Zero Trust Authentication Master Class series.  

Transcription

I'm Jasson Casey, I'm the CTO at Beyond Identity, and we're going to keep continuing this series on how to build secure access. So, I recently introduced this concept called Platform Authenticator, right? 

And so let's just refresh our memory. So what is a platform authenticator? Well, the first thing that we should know is we shamelessly just borrowed this term from the W3C's definition inside of WebAuthn because it existed and it was great. And what it basically said is, you know what? 

A platform authenticator is any authenticator that lives on the device that someone is actually on, trying to connect to another service. And there's a bunch of other things this doc says, but it was very, very description. So, that is a key point of our architecture. Our platform authenticator lives on the device that someone's trying to do something from. 

There's really two reasons for that. Number one, we're going to manage the secure enclave and take charge of a lot of the operations I was talking about before. But the other thing is, by being on the device that someone's actually operating from, it gives us an ability to start to comment on that zero-trust framework that we were talking about earlier. 

Remember, we were talking about what's the operation someone's trying to do or the resources trying to drive? Who is the identity that's trying to drive that operation? And what is the resource or the asset they're trying to drive that operation from? Or more specifically, what is the criticality of the operation, and given the criticality of the operation, can we establish enough trust in the device and enough trust in the identity that the device is hosting to allow the operation to kind of proceed, right? 

So, this really is kind of the box that we're trying to establish, right? Can we build this box up large enough to actually satisfy the risk of the operation? So, again, platform authenticator lives on the device someone's operating from. Part of it is so we can run the authentication flow that we talked about and eliminate some of those vulnerabilities we were talking about yesterday, right? 

The asymmetric crypto shrinks the surface area, the enclave shrinks the surface area even more. By having a platform authenticator on the device, we're actually able to verify not just both sides of the TLS connection, but also the application layer that runs on top. And by doing both of those things in one go, we're able to kind of eliminate that class of vulnerability from the man-in-the-middle phish that we described in the other section. 

But in addition to that, when I bring back this zero-trust framework, I've talked a lot about how to build trust in the identity, but I haven't talked at all about how to build trust in the resource. By being on the platform authenticator, we can scrutinize the resource, and we can help the architecture or the framework really decide, is the resource trustworthy enough to allow the operation to continue. 

Okay. So, the platform authenticator as a big box is interesting, but we kind of have to break it down a little bit more. So, how do we break it down? Well, so the first thing that we want to understand is there's lots of different types of hardware, right? We talked about the enclave types, we talked about TPM2, we talked about T2, we talked about ARM's TrustZone. 

I'm not going to write these all out. Hopefully, you can kind of see that there's a lot down here, right? So the first thing that our platform authenticator has to do is it kind of has to establish this abstraction layer. And we call this kind of our crypto abstraction layer. And, again, not crypto in blockchain, but crypto as in cryptography. 

In addition to that, you know, there's a lot of different operating systems that people actually use in both their work and personal life, right? We've got the big ones, Windows, Mac OS, iOS, Android, but then we've got things like Linux. We've got things like ChromeOS, etc. So, we also need kind of an operating system abstraction layer, if you will, in terms of asking questions about the resource. 

Are the security controls on the resource strong enough for the criticality of what something's trying to do? So, all of this then builds out to...we call this our trust library. And our trust library kind of encapsulates this function. It is universal. 

And what we mean when we say universal is it runs on any OS and any hardware. We will always use the underlying secure element that exists. In the off case that a cryptographic element doesn't exist, we'll emulate a cryptographic element so the operations all look the same, but the level of trust of that emulated secure element obviously is as low as it can. 

And we'll introduce a concept in a little bit to where you can have controls on deciding, again, for the criticality of what's happening, what level of trust do you actually require, right? So, and we do run into use cases where customers have a certain level of operation where the criticality is low, and so they don't need a lot of trust. And so emulated TPM2 is totally fine in that environment. 

So, we have our trust library. On top of our trust library is...you can think of it really as a common abstractions. It's basically like helper functions and whatnot. So when you use our secure customer libraries, you're actually kind of interfacing at this level. 

And then finally, we build our application. This is our platform authenticator that you know as the Beyond Identity Authenticator that logs you into things. So, this is kind of the component architecture of it all. Everything that I've talked about in the previous sections really kind of are focusing on this part and this part, right? 

How do I switch from shared secrets to asymmetric crypto, right? How do I do that in a way where I'm anchoring the keys and I have guarantees of surface area? And how do I do this with common protocols to kind of plug into things? So, now let's put this platform authenticator into action and see what authentication actually looks like. So, let's have Alice. 

And let's say Alice wants to log into Slack. But Alice's business runs Okta as their SSO. And they use Beyond Identity. So, as we learned yesterday, and I'm going to take an OIDC flow, the first thing that happens when Alice tries to get access is she gets this redirection. 

And this redirection is saying, "Hey, I've delegated authentication to Okta to let you log me in, so go to Okta." So, she'll go to Okta. And our integration with Okta is actually not too dissimilar from Okta's integration with Slack. If Slack were delegating to Okta, then Okta would delegate to us. 

And, in fact, I think it's called Delegate Identity in Okta's config. But regardless, from a protocol perspective, Okta is the client, and we are the auth service. And so as you...sure you kind of guessed it, here's another redirect. This thing comes to Beyond Identity, right? So, this is the get login, if you will, right? 

And, you know, we don't really know anything about Alice at this point. We don't even know that it's Alice. So, we send back a challenge. And this is where our platform authenticator gets involved. And so what our platform Authenticator does is it signs the challenge with Alice's key, one of Alice's private keys. 

We call this the challenge response. And so we will verify that signature. And, again, I'm obviously trivializing, there's more things here, but you kind of have to get the basic flow. And let's assume that, you know, we want to proceed. The answer is yes. We send back a form of redirection, again, with that code. And that code, you can think of that code as, like, a magic ticket, Willy Wonka style, basically saying, "Go back to Okta, present this code." 

And then Okta on the back end will come talk to us, saying, "Someone presented this code, who is it?" And we'll give them back an ID token. And then the same thing will happen with Slack. And Okta will come back and present an ID token. Then, of course, Alice is logged in to Slack. 

So, couple of interesting things to point out here. We plugged in to an existing enterprise architecture. We plugged in to that existing enterprise architecture using OIDC. 

We authenticated Alice really right here, and we authenticated Alice using asymmetric crypto, or more specifically, a DSA process. 

Right? So, this shrank our surface area. We also did it with a key that was in a secure enclave, right? So, data at motion is not a problem. Data at rest is really just the enclave. So, the attack has to be against the enclave. We could introduce additional factors if we want, and I'll show you in the next section, we'll introduce a policy engine on how you can really kind of turn the dial around this operation and kind of get increasing or decreasing levels of assurance on identity and resource. 

But for now, let's just kind of think about it as a simpler system. And the other thing that I didn't really highlight too much, but it's kind of interesting, is this challenge right here in this challenge-response because it's conducted by our Platform Authenticator. The Platform Authenticator is verifying that the challenge, in fact, came from Beyond Identity. 

The Platform Authenticator is proving the response is coming from a Platform Authenticator built by Beyond Identity, signed by Alice's key. This is happening at the TLS and at the application level over the TLS. So we're actually also hammering at that man-in-the-middle phishing scenario that we talked about in the previous section on MFA. 

So, we're taking a huge number of vulnerabilities, and we're really just taking them off the table. Whoops. Technically, it should have been an X, but you get the point. So, in the next section...this is good, but this really is only talking about this part of our three-dimensional kind of objective. Given the operation, how do we establish enough trust in the identity and the resource to allow the operation to continue? 

There's one more motivating component that we need to introduce to really answer that question in a much more interesting way. It involves this part of the architecture. It also involves a policy engine in the Beyond Identity Cloud, and that's when things become a bit more real. And until next time.

We'll pick up on that in the next section of how we actually do that.