Is FIDO Ready for Enterprise Deployment?

Hi. So you'll see some of those themes and questions that you've been asked asking their echo throughout this presentation and some carrying on from Graham as well. So this really is all about what my customers are asking me.

So I'm, I'm the Chief Product Officer for a a software vendor. We specialize in credential management. We do that for very high assurance, so government, military, aerospace and defense. They sort of protect military helicopter plans, track new nuclear material, that sort of thing. So if those people have got a complicated authentication experience, their CISO doesn't care. They just wanna lock it down. So this is from the absolute highest levels of assurance.

What we are finding is that the standards that drive those customers are changing and they're being pushed to use fishing resistant multifactor authentication everywhere, not just within the organization for every employee, but also down the supply chain and PKIs fishing resistant. But it's very difficult to deploy absolutely everywhere. Doesn't work so well on your iPad. How do I control that down my supply chain when I'm not in control of their onboarding policies?

So that's what our customers are starting to look at and if you look through the standards and the specification, PKI and Fido are really two, the only, really the only two technologies that gives you proper phishing resistance. There's an asymmetric key, there's a private key on the device, public key outside the device. I'm digitally signing an authentication attempt with that private key. I couldn't even share a secret there if I needed to or if I wanted to. Unlike one time passwords that can get phished passwords that can get fished. So Fido absolutely takes the security box.

However, it comes from the consumer world, unlike some of the other technologies that tended to come from the enterprise world. Fido grew up in the consumer world.

It's, it's all about faster identity online. The the closing, the acronym there. So I have a private key on the device, I have a public key. Each relying party has its own public key. So if I'm logging onto my bank or my network provider or an e-commerce site, each of those has its own public private keeper and they don't know anything about each other. There's nothing there to bind those to the individual. And that's great in the consumer world. I don't want my e-commerce provider knowing anything about my banking credentials.

However, that's not how enterprises work. I probably log onto about seven or eight applications every day when I'm working in my company and I use the same credential to do all those. I don't want a credential for each end application. It becomes unmanageable. I also don't want to put those policy decisions directly into that end application. I've got an identity and access management infrastructure. I've invested in it. I've spent a lot of time and money on it.

Optum, Microsoft, fro Ping, wherever I'm using there. Or for the smaller medium enterprises, perhaps just an authentication server, I want to know who's using that credential. There's no point in me having a credential that says I'm Bill Gates. If I'm not Bill Gates, I need to bind it to a person and I also need to manage its life cycle. So I need to know when it was issued, who issued it, does it expire, people lose it, how do I replace it? And I need all of that centrally in an audit cuz when I come along and get audited, who can access this nuclear material?

I need to be able to prove all that. So these are the expectations of our customers that have come from the P K I world and they're now trying to apply those to fi. So that's really what the rest of this presentation is. These are the questions that our customers are asking us. How do I do this with fider? Can I make F work in the enterprise? So to start with looking at that single credential for multiple applications, and this is very a model, very similar to the one that Andreas and Dennis have applied as they deployed there.

So what we have in the center is that identity provider that provides authentication access control to multiple backend applications. Down the bottom we have the user with their FI credential. So we have Web off N, which does the browser piece. We have c a which deals with the how does this device talk to my FI token if it's an external one. On the left hand side we have a couple of environments, and this is actually based on the live, a live customer requirement of ours. I just can't name them. So we have one environment that's protected by active directory.

That's a combination of Azure and active directory on premise. So there there's a plugin, active directory federation services plugin that sends requests into that central structure. The other is more of a storefront environment and that happens to protected by Octa. Octa happens to support open Id connect. So really what we are doing here is we are using Fido to authenticate into the identity provider and then we're using more standards based federated protocols Open. Id connect for example to in integrate into that backend infrastructure.

So the end user experience here is I look at the application I'm trying to access that will pass me into Okta. Okta says, okay, this is using this particular identity provider. I'll pass over authentication to that, which then authenticates the person with fi. So we're still doing the full fishing resistant private public key signing of the authentication attempt. Once that identity provider is confident that person is who they're claim to be, then it will allow them into the backend applications. So that's providing the access management, that's providing the session management there.

So that's how yes you can put FI Fit Fighter into that environment, but not by putting Fido into each end application as you would in the consumer world. Otherwise you'll end it with multiple credentials and access decisions outside of your policy person binding. How do we know who's got that credential? Now that's not really part of the Fido specification, but this is where my world of credential management comes in. So job of a credential management system is to make sure that the right person gets the right credential that's done to the organization's policy. All of that is audited.

So we know the level of identity assurance. Is this person a low level? They've just come straight from active directory. Have we done additional background checks against them at the highest level? Have we done background checks? Have we scanned identity documents to have a very high level of assurance before we issue them a credential? Then there's the checks on the the the authenticator itself and the these are options you can choose. Do I do an attestation check? Do I just trust it's a fighter credential and that's enough?

Do I want to make sure it's a UBI key hardware backed with a FIPs level of crypto on that device? So these are choices you can make at that point.

And again, that's the job of the credential management system to make sure the device is meeting the policy. Do I want to enforce user presence? So enforce a pin as opposed to just touch to sign. And there are two ways of doing this and and this is partly because the infrastructure is still changing in this space. So the credential management system can act as an identity provider, it can act as a FI authentication server.

So you can for example, hook this up to your access control solution that doesn't support Fido and by those federated protocols it can then call into that credential management system that's issued the Fido token and it will provide that Fido authentication. Most of our larger customers are using an item infrastructure that they've invested very heavily in Okta for Ping for example.

In in those examples, for some of them, not all of them, it's possible that the credential management system can do its job, check all the policy, check the user binding, et cetera, and pass those FI credentials into that relying party. So for example, you can check the person, you can check the policy, you can check the device, you can then write onto that Fido authenticator, the name of the relying party, Okta in this case into that Fido credential. So it'll only work with that Octa environment and then you can pass those credentials into Okta.

So you can combine the worlds of credential management and strong authentication with your IAM provider. A lot of our customers are looking at combining PKI and, and this gives them that capability so they can have a single point of issuance and management and share the credentials with the identity provider lifecycle management.

So again, most of our customers have deployed P K I to some of their organization. They're now looking at how do I add FI to that? So with P K I, you get a lifetime, you issue a certificate, it might last a year, it might last three years and it expires. You don't get that with fider. Some of our customers, the US Senate for example, issue a new round of employees credentials that last for that period of tenure. When the senate's sitting, they have to expire after that. You don't get that with Fido. You get a private and public key. It's up to the relying party to work out when that expires.

But you can do that within the identity provider. So in that identity provider, be it cms, be an i a solution, you can set expiry dates there. So as long as you're authenticating to that provider, it can decide that credentials no longer valid updates.

Again, there aren't really, there isn't really a concept of an update within fider. You've got a key in it either works or it doesn't. But if there's an issue, you can reissue the device, you can reissue new keys against the same device. So you do have some of those capabilities. Unlock is missing from Fider. So with a smart card, with a bank card, you put your pin in a number of times incorrectly, it locks the device. You can't use it until you can securely unlock it. There is no unlock mechanism in Fider. There's no way to come and unlock that device as part of the current spec.

But that's not a huge problem because you can simply just issue another credential. So as long as you can make that process straightforward, you can get around that problem. Suspend and resume. People go on maternity leave, paternity leave, you might want to suspend their credential for three months.

Again, Fido is just an authentication protocol. All it does is tell you if this person is who they claim to be, doesn't have any the rules around it. So the place to put those is in that I a system you can suspend, you can resume within there.

Same for, same for revocation. Somebody's left the organization. You want to revoke that credential with fi, that's very much about removing the public key from the account. So it's no longer trusted and can't be used to authenticate.

So again, what most of our customers are looking at doing is not putting that in the end application but centralizing that into an identity and access management infrastructure. So for example, we've got a user, they happen to be an active directory. We've issued them a PKI credential and a FI credential. As soon as that account gets disabled in active directory, we will pick that up.

We will revoke both of those credentials either in the PKI by sending a revocation message, which goes up to the C or within our own product at ticketing as a FI authentication server or sending that message to Okta to remove that private key. So yes, these are possible auditing reporting. So who has which credential? Very important for some of our high assurance customers, they get audited every year if they can't prove who can access the systems.

If they're doing things like tracking nuclear material, letting people into air traffic control towers, they, they absolutely need to know who's got these credentials. And if you don't think that's important, just look at Colonial Pipeline. Who got hacked with a compromised credential that was a dormant account. That user hadn't worked there for a long time. So this keeping on top of who's got active credentials is really important.

So again, that's the job of a credential management system. When it expires, who is issued to, who approves it? All of the lifecycle events around it in assigned and verifiable audit trail. That's the job of the credential management system. There's an example here in two cases. So the top one is PKI credential. That's what's been happening for the the last 20 years. The one below that is a Fido credential and the eagle eye amongst you will spot that the Fido token in that case is grayed out. Why is it grayed out? It's grayed out because today we don't know what device it's on.

We might know it's on a genuine UBI FIPs device. We get that from device attestation, but we don't know which physical device it's on. And that's what I'll talk about on the next slide. So the the top device in this case, think of that as a smart card, has a serial number. We know these credentials are on that specific device, which allows organizations to provide more management around it. And we can track that at the point of issuance. At the point of usage. For example, out the box, you don't get that in F. If I'm using FI to log into my bank, why do they care which specific device it's on?

I could have bought any F device from Amazon, I could have just used my phone. They don't need to know that. But enterprises quite like knowing that and my green buttons start working. There we go. So that's where enterprise attestation comes in. I don't think it's a great term. Doesn't really mean much to people. Device attestation, which is built into the five spec, is it a genuine UBI key hardware device? Is it an iPhone? What device am I using? Enterprise Attestation really gives that device a serial number. So it allows you to say, not only is it a UBI key, it's this specific UBI key.

Why do people care? And and importantly, this is, this is new, it's not really rolled out yet. Nobody's really deployed this yet. Vendors are starting to work on it. We're starting to work on it with some of the, the F manufacturers to look at how we deploy this. But it starts to give you possibilities. Is it one of our customers who's looking at doing this, said, I need to know it's one of my devices. I don't want anybody just turning it with any random fider device off the street. I can see some nods. So how do I do that?

I, I've got this particular batch of devices and I, I integrate those with inventory control. I know where they are, I know where they're deployed. So this gives you that capability. It gives you the founding for that capability. If you have a serial number, you can start to import batches of serial numbers and say, well that one's definitely one of mine. I know it's one of these types of devices, but I also know it's one of mine. You can start to track it. You can start to track where it's used. This credential was issued in this location onto this device.

It's now being used in this other location. It starts to bind a person to the device. How am I doing timewise Graham, just a little bit over that.

Okay, I shall try and speed up. I'm very nearly there. So it starts to introduce more management possibilities that you get with PKI that you don't out the box get with fi briefly pass keys. I think we talked about this earlier. So pass keys if you can share them between devices. If you are moving away from passwords, pass keys are great. They'll make you more secure. If you are at the pki, super high level of assurance, you probably don't want to use pass keys because they're shareable between devices. You want to use a single device Pasky that you can't actually extract from that device.

Final word. There are very few standards in this area. Even if you look at NS two, gdpr, hipaa, none of these really give you particular technology standards. They say you should follow best practice and assess your risks. One that does in this area is the US government fits to a one standard. So tracking over to the right and side sp hundred 63 B talks about digital identity guidelines. Over on the right it talks about authenticator assurance levels. Number of our customers are looking at this as a good blueprint, a good start point to look at authentication.

Fido, how do I use it? How secure do I need to be? So if there's one takeaway from this, I would urge you have a look at those standards. Read them if you don't need to implement them. Exactly. They're a great place to start. Final summary slide.

Yes, Fido can be highly secure if you use credential management IDPs that Fido enabled, you can start to get enough management over it. The fact that the devices support pki otp Fido means they can be very flexible. You can start looking at your physical access and standards based is great. It means I can roll them out to devices without having to roll out hardware and software. But some negatives. Enterprise attestation really isn't there yet. Supporting item components varies. Some support it, some don't. Doesn't lend itself to every use case. Offline.

Log on for Windows desktop signing not great examples for Fido and think about pass keys. So apologies if I went slightly over, but if you need to talk anymore, always happy to talk. Just get hold of me. Thank you. Thanks. Thanks. Thanks Ellen.