Thought Leadership

Building A Modern Authentication Architecture

Written By
Published On

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

Transcription

So, I'm Jasson Casey, I'm the CTO here at Beyond Identity. And we are continuing our series just talking about how would we actually build up an authentication architecture in an access architecture, that really kind of covers a lot or addresses a lot of the problems that we've built out, as well as takes more of a zero trust focus. 

And again, what zero trust really means is kind of, you can't really trust the environment you're operating in. You kind of have to bootstrap and prove everything up. So we introduced this concept of a secure element before, right? And so a secure element, we basically said it's basically like a little mini-processor that can do basic cryptographic operations, create keys, and secure memory. There's a few other concepts we're going to have to introduce before we can then kind of build upon this secure element to actually start to build out an access architecture. 

So I think we already proved how asymmetric crypto versus passwords solves a lot of problems around data in motion. It just eliminates them completely in terms of data at rest. It shrinks the surface area and we use a secure enclave. We further shrink that surface area to really just be the enclave itself. But there's a few other properties that we need to develop. 

So prior, we talked about multi-factor is really kind of having three dimensions and, you know, there's a lot of different data points on those dimensions that you can take. But ultimately it boils down to knowledge factors, possession factors, and inherent factors. So I want to kind of show how a secure enclave can actually map into each of these dimensions. 

So let's start with possession because that's kind of the most obvious, right? So in terms of a possession, if I'm using a [inaudible] enclave with a key that's physically locked in the enclave, then only if I possess that enclave can I actually use that key, right? 

So what does that actually mean? Well, when I have these processors and I want to kind of create a key, right? Generate a key pair, remember how I said they're these parameters that kind of go into that function? Well, it turns out I can create a couple different types of keys. What I really want to do though is I want to create signing keys because that's what we're all about. And I want to create a signing key that is pinned in this processor. 

As in it can't be copied out, right? Because unless you tell it when you create the key, certain keys can be copied out of the enclave just because there's, you know, these chips were built for lots of interesting applications. So the first thing we want to do is we want to say the key is penned, right? The next thing that we actually want to do is we want to say, "Hey, we want a signing key." 

And then there's other authorization policies that we can kind of build in there, right? We can say things like...we can introduce a guard. So I want to create a key with what's called an HMAC policy, i.e., every time someone says, "I want to use this key to sign a stream of data," they actually have to provide an unlock if you will. 

They have to prove that they can complete the HMAC protocol to allow the key to get used. So this turns out to be a really important primitive or building block to attack the knowledge and the inheritance for its to multi-factor. But first, let's just complete the possession. So if I create a key that's penned, right? It's going to create two things. 

It's going to create the key pair and then it's going to generate a certificate, right? And that certificate is going to be a description about the key, right? It's going to talk about the algorithm, it's going to talk about the number of bits. It's going to have a copy of the public key. It's also going to say that, "Hey, this key is pinned." And if we use some of these other things, it's going to say, "This key has an HMAC guard with some additional data." 

And then of course it's going to get signed. Now, in most enclaves, what's actually signing this is not the key that's getting created, but there's a little hierarchy in the enclave. And at the top of a hierarchy, we'll pick on TPM for a minute, is this thing called the EK, the endorsement key. And this is actually a key that is coming from the manufacturer of the enclave. 

But again, there's a lot of details here and we're going to run out of time. So I'm generalizing a little bit, but there's basically a hierarchy that signs this, that you include in your kind of root of trust. So if you trust the manufacturer of a TPM, there's a way for you to build trust that this particular certificate is produced inside of a TPM manufactured by that company. 

And anyone can prove they can use this key and they have to...it means they have to prove they can use the HMAC, and then, of course, you know these properties are there. So whenever someone uses a key and shows the certificate according to that key, and I see the property penned, I know I have possession, right? 

So that's kind of how I solved that one. Now let's talk about knowledge because that's pretty easy. Well, if I can introduce an HMAC guard on a key, clearly I can introduce a password again if I wanted to or a local pen and use that as the HMAC unlock. So it's not just possession of the secure enclave and access to it, but I'd have to prove some piece of knowledge that's necessary to actually get the secure enclave to use this particular key. 

So I could actually check off a knowledge factor. And then in terms of inherence, an HMAC is just a string, right? So let's say that I take a photo of your face and I can extract, you know, a feature vector, right? Essentially it is just a vector or bits of data that kind of describe your face uniquely. 

And if I can do this in a stable way, stable means, you know, I changed the lighting conditions, I changed the angle, I still get the same feature vector, then there's no reason I can't run this through a hashing function and use that as the input to an HMAC. So now I have a construction for essentially a biometric where the biometric never actually leaves the endpoint. 

But proof of inherent of the biometric does actually can follow, right? So secure enclaves give us a lot of interesting properties. I am taking a little bit of liberties to kind of try and have a simpler explanation. Honestly, I could probably talk for a couple hours on all of the details and I'd love to, but that's going to be another series. And we can reconstruct each dimension of MFA with this enclave. 

We can have certain guarantees of the keys never leaving the enclave. I guess one other thing that I should point out any of you that are computer engineers, electrical engineers will kind of quickly hit on the fact that there may be secure memory in this device, the secure enclave, but there clearly can't be a lot of it. So what happens when you run out? 

And it turns out, you know, we take a play out of the playbook of operating systems, right? You know, clearly, if you look at your running operating system, there's more memory in use than is actually plugged into the machine, right? With virtual memory. And we do a similar thing here. So remember, if I have a key an encryption key that's pinned in here, I can actually use that to encrypt another key and then essentially store that encrypted key offboard and it can be created in such policy where it can only ever be decrypted in a pen fashion in the secure enclave. 

And it's only allowed to go out if it's actually encrypted by a key that follows under a hierarchy that itself is penned. And so this is how you can take a small amount of physical memory and expand it into a large amount of virtual memory with the same levels of protection that actually exist on this enclave. So now we have enough of the building blocks for us to introduce the next topic, which is the Platform Authenticator, which forms the basis...Authenticator, which forms the basis of the Beyond Identity architecture, right? 

So the Platform Authenticator, it lives on Alice's laptop because that's where she's doing the interesting thing. We want to be on that machine. And it is going to provide authentication services, and is going to do that by managing the secure enclave, right? 

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

Get started with Device360 today
Weekly newsletter
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.

Building A Modern Authentication Architecture

Download

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

Transcription

So, I'm Jasson Casey, I'm the CTO here at Beyond Identity. And we are continuing our series just talking about how would we actually build up an authentication architecture in an access architecture, that really kind of covers a lot or addresses a lot of the problems that we've built out, as well as takes more of a zero trust focus. 

And again, what zero trust really means is kind of, you can't really trust the environment you're operating in. You kind of have to bootstrap and prove everything up. So we introduced this concept of a secure element before, right? And so a secure element, we basically said it's basically like a little mini-processor that can do basic cryptographic operations, create keys, and secure memory. There's a few other concepts we're going to have to introduce before we can then kind of build upon this secure element to actually start to build out an access architecture. 

So I think we already proved how asymmetric crypto versus passwords solves a lot of problems around data in motion. It just eliminates them completely in terms of data at rest. It shrinks the surface area and we use a secure enclave. We further shrink that surface area to really just be the enclave itself. But there's a few other properties that we need to develop. 

So prior, we talked about multi-factor is really kind of having three dimensions and, you know, there's a lot of different data points on those dimensions that you can take. But ultimately it boils down to knowledge factors, possession factors, and inherent factors. So I want to kind of show how a secure enclave can actually map into each of these dimensions. 

So let's start with possession because that's kind of the most obvious, right? So in terms of a possession, if I'm using a [inaudible] enclave with a key that's physically locked in the enclave, then only if I possess that enclave can I actually use that key, right? 

So what does that actually mean? Well, when I have these processors and I want to kind of create a key, right? Generate a key pair, remember how I said they're these parameters that kind of go into that function? Well, it turns out I can create a couple different types of keys. What I really want to do though is I want to create signing keys because that's what we're all about. And I want to create a signing key that is pinned in this processor. 

As in it can't be copied out, right? Because unless you tell it when you create the key, certain keys can be copied out of the enclave just because there's, you know, these chips were built for lots of interesting applications. So the first thing we want to do is we want to say the key is penned, right? The next thing that we actually want to do is we want to say, "Hey, we want a signing key." 

And then there's other authorization policies that we can kind of build in there, right? We can say things like...we can introduce a guard. So I want to create a key with what's called an HMAC policy, i.e., every time someone says, "I want to use this key to sign a stream of data," they actually have to provide an unlock if you will. 

They have to prove that they can complete the HMAC protocol to allow the key to get used. So this turns out to be a really important primitive or building block to attack the knowledge and the inheritance for its to multi-factor. But first, let's just complete the possession. So if I create a key that's penned, right? It's going to create two things. 

It's going to create the key pair and then it's going to generate a certificate, right? And that certificate is going to be a description about the key, right? It's going to talk about the algorithm, it's going to talk about the number of bits. It's going to have a copy of the public key. It's also going to say that, "Hey, this key is pinned." And if we use some of these other things, it's going to say, "This key has an HMAC guard with some additional data." 

And then of course it's going to get signed. Now, in most enclaves, what's actually signing this is not the key that's getting created, but there's a little hierarchy in the enclave. And at the top of a hierarchy, we'll pick on TPM for a minute, is this thing called the EK, the endorsement key. And this is actually a key that is coming from the manufacturer of the enclave. 

But again, there's a lot of details here and we're going to run out of time. So I'm generalizing a little bit, but there's basically a hierarchy that signs this, that you include in your kind of root of trust. So if you trust the manufacturer of a TPM, there's a way for you to build trust that this particular certificate is produced inside of a TPM manufactured by that company. 

And anyone can prove they can use this key and they have to...it means they have to prove they can use the HMAC, and then, of course, you know these properties are there. So whenever someone uses a key and shows the certificate according to that key, and I see the property penned, I know I have possession, right? 

So that's kind of how I solved that one. Now let's talk about knowledge because that's pretty easy. Well, if I can introduce an HMAC guard on a key, clearly I can introduce a password again if I wanted to or a local pen and use that as the HMAC unlock. So it's not just possession of the secure enclave and access to it, but I'd have to prove some piece of knowledge that's necessary to actually get the secure enclave to use this particular key. 

So I could actually check off a knowledge factor. And then in terms of inherence, an HMAC is just a string, right? So let's say that I take a photo of your face and I can extract, you know, a feature vector, right? Essentially it is just a vector or bits of data that kind of describe your face uniquely. 

And if I can do this in a stable way, stable means, you know, I changed the lighting conditions, I changed the angle, I still get the same feature vector, then there's no reason I can't run this through a hashing function and use that as the input to an HMAC. So now I have a construction for essentially a biometric where the biometric never actually leaves the endpoint. 

But proof of inherent of the biometric does actually can follow, right? So secure enclaves give us a lot of interesting properties. I am taking a little bit of liberties to kind of try and have a simpler explanation. Honestly, I could probably talk for a couple hours on all of the details and I'd love to, but that's going to be another series. And we can reconstruct each dimension of MFA with this enclave. 

We can have certain guarantees of the keys never leaving the enclave. I guess one other thing that I should point out any of you that are computer engineers, electrical engineers will kind of quickly hit on the fact that there may be secure memory in this device, the secure enclave, but there clearly can't be a lot of it. So what happens when you run out? 

And it turns out, you know, we take a play out of the playbook of operating systems, right? You know, clearly, if you look at your running operating system, there's more memory in use than is actually plugged into the machine, right? With virtual memory. And we do a similar thing here. So remember, if I have a key an encryption key that's pinned in here, I can actually use that to encrypt another key and then essentially store that encrypted key offboard and it can be created in such policy where it can only ever be decrypted in a pen fashion in the secure enclave. 

And it's only allowed to go out if it's actually encrypted by a key that follows under a hierarchy that itself is penned. And so this is how you can take a small amount of physical memory and expand it into a large amount of virtual memory with the same levels of protection that actually exist on this enclave. So now we have enough of the building blocks for us to introduce the next topic, which is the Platform Authenticator, which forms the basis...Authenticator, which forms the basis of the Beyond Identity architecture, right? 

So the Platform Authenticator, it lives on Alice's laptop because that's where she's doing the interesting thing. We want to be on that machine. And it is going to provide authentication services, and is going to do that by managing the secure enclave, right? 

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

Building A Modern Authentication Architecture

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

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

Transcription

So, I'm Jasson Casey, I'm the CTO here at Beyond Identity. And we are continuing our series just talking about how would we actually build up an authentication architecture in an access architecture, that really kind of covers a lot or addresses a lot of the problems that we've built out, as well as takes more of a zero trust focus. 

And again, what zero trust really means is kind of, you can't really trust the environment you're operating in. You kind of have to bootstrap and prove everything up. So we introduced this concept of a secure element before, right? And so a secure element, we basically said it's basically like a little mini-processor that can do basic cryptographic operations, create keys, and secure memory. There's a few other concepts we're going to have to introduce before we can then kind of build upon this secure element to actually start to build out an access architecture. 

So I think we already proved how asymmetric crypto versus passwords solves a lot of problems around data in motion. It just eliminates them completely in terms of data at rest. It shrinks the surface area and we use a secure enclave. We further shrink that surface area to really just be the enclave itself. But there's a few other properties that we need to develop. 

So prior, we talked about multi-factor is really kind of having three dimensions and, you know, there's a lot of different data points on those dimensions that you can take. But ultimately it boils down to knowledge factors, possession factors, and inherent factors. So I want to kind of show how a secure enclave can actually map into each of these dimensions. 

So let's start with possession because that's kind of the most obvious, right? So in terms of a possession, if I'm using a [inaudible] enclave with a key that's physically locked in the enclave, then only if I possess that enclave can I actually use that key, right? 

So what does that actually mean? Well, when I have these processors and I want to kind of create a key, right? Generate a key pair, remember how I said they're these parameters that kind of go into that function? Well, it turns out I can create a couple different types of keys. What I really want to do though is I want to create signing keys because that's what we're all about. And I want to create a signing key that is pinned in this processor. 

As in it can't be copied out, right? Because unless you tell it when you create the key, certain keys can be copied out of the enclave just because there's, you know, these chips were built for lots of interesting applications. So the first thing we want to do is we want to say the key is penned, right? The next thing that we actually want to do is we want to say, "Hey, we want a signing key." 

And then there's other authorization policies that we can kind of build in there, right? We can say things like...we can introduce a guard. So I want to create a key with what's called an HMAC policy, i.e., every time someone says, "I want to use this key to sign a stream of data," they actually have to provide an unlock if you will. 

They have to prove that they can complete the HMAC protocol to allow the key to get used. So this turns out to be a really important primitive or building block to attack the knowledge and the inheritance for its to multi-factor. But first, let's just complete the possession. So if I create a key that's penned, right? It's going to create two things. 

It's going to create the key pair and then it's going to generate a certificate, right? And that certificate is going to be a description about the key, right? It's going to talk about the algorithm, it's going to talk about the number of bits. It's going to have a copy of the public key. It's also going to say that, "Hey, this key is pinned." And if we use some of these other things, it's going to say, "This key has an HMAC guard with some additional data." 

And then of course it's going to get signed. Now, in most enclaves, what's actually signing this is not the key that's getting created, but there's a little hierarchy in the enclave. And at the top of a hierarchy, we'll pick on TPM for a minute, is this thing called the EK, the endorsement key. And this is actually a key that is coming from the manufacturer of the enclave. 

But again, there's a lot of details here and we're going to run out of time. So I'm generalizing a little bit, but there's basically a hierarchy that signs this, that you include in your kind of root of trust. So if you trust the manufacturer of a TPM, there's a way for you to build trust that this particular certificate is produced inside of a TPM manufactured by that company. 

And anyone can prove they can use this key and they have to...it means they have to prove they can use the HMAC, and then, of course, you know these properties are there. So whenever someone uses a key and shows the certificate according to that key, and I see the property penned, I know I have possession, right? 

So that's kind of how I solved that one. Now let's talk about knowledge because that's pretty easy. Well, if I can introduce an HMAC guard on a key, clearly I can introduce a password again if I wanted to or a local pen and use that as the HMAC unlock. So it's not just possession of the secure enclave and access to it, but I'd have to prove some piece of knowledge that's necessary to actually get the secure enclave to use this particular key. 

So I could actually check off a knowledge factor. And then in terms of inherence, an HMAC is just a string, right? So let's say that I take a photo of your face and I can extract, you know, a feature vector, right? Essentially it is just a vector or bits of data that kind of describe your face uniquely. 

And if I can do this in a stable way, stable means, you know, I changed the lighting conditions, I changed the angle, I still get the same feature vector, then there's no reason I can't run this through a hashing function and use that as the input to an HMAC. So now I have a construction for essentially a biometric where the biometric never actually leaves the endpoint. 

But proof of inherent of the biometric does actually can follow, right? So secure enclaves give us a lot of interesting properties. I am taking a little bit of liberties to kind of try and have a simpler explanation. Honestly, I could probably talk for a couple hours on all of the details and I'd love to, but that's going to be another series. And we can reconstruct each dimension of MFA with this enclave. 

We can have certain guarantees of the keys never leaving the enclave. I guess one other thing that I should point out any of you that are computer engineers, electrical engineers will kind of quickly hit on the fact that there may be secure memory in this device, the secure enclave, but there clearly can't be a lot of it. So what happens when you run out? 

And it turns out, you know, we take a play out of the playbook of operating systems, right? You know, clearly, if you look at your running operating system, there's more memory in use than is actually plugged into the machine, right? With virtual memory. And we do a similar thing here. So remember, if I have a key an encryption key that's pinned in here, I can actually use that to encrypt another key and then essentially store that encrypted key offboard and it can be created in such policy where it can only ever be decrypted in a pen fashion in the secure enclave. 

And it's only allowed to go out if it's actually encrypted by a key that follows under a hierarchy that itself is penned. And so this is how you can take a small amount of physical memory and expand it into a large amount of virtual memory with the same levels of protection that actually exist on this enclave. So now we have enough of the building blocks for us to introduce the next topic, which is the Platform Authenticator, which forms the basis...Authenticator, which forms the basis of the Beyond Identity architecture, right? 

So the Platform Authenticator, it lives on Alice's laptop because that's where she's doing the interesting thing. We want to be on that machine. And it is going to provide authentication services, and is going to do that by managing the secure enclave, right? 

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

Building A Modern Authentication Architecture

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

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

Transcription

So, I'm Jasson Casey, I'm the CTO here at Beyond Identity. And we are continuing our series just talking about how would we actually build up an authentication architecture in an access architecture, that really kind of covers a lot or addresses a lot of the problems that we've built out, as well as takes more of a zero trust focus. 

And again, what zero trust really means is kind of, you can't really trust the environment you're operating in. You kind of have to bootstrap and prove everything up. So we introduced this concept of a secure element before, right? And so a secure element, we basically said it's basically like a little mini-processor that can do basic cryptographic operations, create keys, and secure memory. There's a few other concepts we're going to have to introduce before we can then kind of build upon this secure element to actually start to build out an access architecture. 

So I think we already proved how asymmetric crypto versus passwords solves a lot of problems around data in motion. It just eliminates them completely in terms of data at rest. It shrinks the surface area and we use a secure enclave. We further shrink that surface area to really just be the enclave itself. But there's a few other properties that we need to develop. 

So prior, we talked about multi-factor is really kind of having three dimensions and, you know, there's a lot of different data points on those dimensions that you can take. But ultimately it boils down to knowledge factors, possession factors, and inherent factors. So I want to kind of show how a secure enclave can actually map into each of these dimensions. 

So let's start with possession because that's kind of the most obvious, right? So in terms of a possession, if I'm using a [inaudible] enclave with a key that's physically locked in the enclave, then only if I possess that enclave can I actually use that key, right? 

So what does that actually mean? Well, when I have these processors and I want to kind of create a key, right? Generate a key pair, remember how I said they're these parameters that kind of go into that function? Well, it turns out I can create a couple different types of keys. What I really want to do though is I want to create signing keys because that's what we're all about. And I want to create a signing key that is pinned in this processor. 

As in it can't be copied out, right? Because unless you tell it when you create the key, certain keys can be copied out of the enclave just because there's, you know, these chips were built for lots of interesting applications. So the first thing we want to do is we want to say the key is penned, right? The next thing that we actually want to do is we want to say, "Hey, we want a signing key." 

And then there's other authorization policies that we can kind of build in there, right? We can say things like...we can introduce a guard. So I want to create a key with what's called an HMAC policy, i.e., every time someone says, "I want to use this key to sign a stream of data," they actually have to provide an unlock if you will. 

They have to prove that they can complete the HMAC protocol to allow the key to get used. So this turns out to be a really important primitive or building block to attack the knowledge and the inheritance for its to multi-factor. But first, let's just complete the possession. So if I create a key that's penned, right? It's going to create two things. 

It's going to create the key pair and then it's going to generate a certificate, right? And that certificate is going to be a description about the key, right? It's going to talk about the algorithm, it's going to talk about the number of bits. It's going to have a copy of the public key. It's also going to say that, "Hey, this key is pinned." And if we use some of these other things, it's going to say, "This key has an HMAC guard with some additional data." 

And then of course it's going to get signed. Now, in most enclaves, what's actually signing this is not the key that's getting created, but there's a little hierarchy in the enclave. And at the top of a hierarchy, we'll pick on TPM for a minute, is this thing called the EK, the endorsement key. And this is actually a key that is coming from the manufacturer of the enclave. 

But again, there's a lot of details here and we're going to run out of time. So I'm generalizing a little bit, but there's basically a hierarchy that signs this, that you include in your kind of root of trust. So if you trust the manufacturer of a TPM, there's a way for you to build trust that this particular certificate is produced inside of a TPM manufactured by that company. 

And anyone can prove they can use this key and they have to...it means they have to prove they can use the HMAC, and then, of course, you know these properties are there. So whenever someone uses a key and shows the certificate according to that key, and I see the property penned, I know I have possession, right? 

So that's kind of how I solved that one. Now let's talk about knowledge because that's pretty easy. Well, if I can introduce an HMAC guard on a key, clearly I can introduce a password again if I wanted to or a local pen and use that as the HMAC unlock. So it's not just possession of the secure enclave and access to it, but I'd have to prove some piece of knowledge that's necessary to actually get the secure enclave to use this particular key. 

So I could actually check off a knowledge factor. And then in terms of inherence, an HMAC is just a string, right? So let's say that I take a photo of your face and I can extract, you know, a feature vector, right? Essentially it is just a vector or bits of data that kind of describe your face uniquely. 

And if I can do this in a stable way, stable means, you know, I changed the lighting conditions, I changed the angle, I still get the same feature vector, then there's no reason I can't run this through a hashing function and use that as the input to an HMAC. So now I have a construction for essentially a biometric where the biometric never actually leaves the endpoint. 

But proof of inherent of the biometric does actually can follow, right? So secure enclaves give us a lot of interesting properties. I am taking a little bit of liberties to kind of try and have a simpler explanation. Honestly, I could probably talk for a couple hours on all of the details and I'd love to, but that's going to be another series. And we can reconstruct each dimension of MFA with this enclave. 

We can have certain guarantees of the keys never leaving the enclave. I guess one other thing that I should point out any of you that are computer engineers, electrical engineers will kind of quickly hit on the fact that there may be secure memory in this device, the secure enclave, but there clearly can't be a lot of it. So what happens when you run out? 

And it turns out, you know, we take a play out of the playbook of operating systems, right? You know, clearly, if you look at your running operating system, there's more memory in use than is actually plugged into the machine, right? With virtual memory. And we do a similar thing here. So remember, if I have a key an encryption key that's pinned in here, I can actually use that to encrypt another key and then essentially store that encrypted key offboard and it can be created in such policy where it can only ever be decrypted in a pen fashion in the secure enclave. 

And it's only allowed to go out if it's actually encrypted by a key that follows under a hierarchy that itself is penned. And so this is how you can take a small amount of physical memory and expand it into a large amount of virtual memory with the same levels of protection that actually exist on this enclave. So now we have enough of the building blocks for us to introduce the next topic, which is the Platform Authenticator, which forms the basis...Authenticator, which forms the basis of the Beyond Identity architecture, right? 

So the Platform Authenticator, it lives on Alice's laptop because that's where she's doing the interesting thing. We want to be on that machine. And it is going to provide authentication services, and is going to do that by managing the secure enclave, right? 

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

Book

Building A Modern Authentication Architecture

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

Download the book

By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.