Informal security chat with our host Reece Guida, VP of Product Strategy Husnain Bajwa, and Beyond Identity's Founding Engineer Nelson Melo on deploying PKI-based MFA.

Transcription

Reece Guida

Hey, welcome to another episode of "Cybersecurity Hot Takes." It's me, your host extraordinaire Reece Guida. And today we're joined with Nelson. Nelson, who are you? Come on. 

Let the people know. 

Nelson

Hey everybody. I'm Nelson, founding engineer at Beyond Identity. 

Reece

And who's the other guy? 

HB

I'm HB. I am product strategy here at Beyond Identity. 

Reece

And tragically, sadly, I'm filled with remorse to say that Jasson can't be here today. He is down in Mexico with our friends World Wide Technology. So let's kick it off. So as we all know, Halloween was four days ago. But to me, that wasn't the most exciting thing that happened four days ago. No. 

The best thing that happened about Halloween day was CISA releasing new guidance titled, "Implementing Phishing-Resistant MFA." And in there, they kind of had a hot take of their own. Let me see the words that they used exactly. I actually have it up in front of me right now. They said when they were talking about phishing-resistant technology, they mentioned PKI-based MFA. 

And they said, "Successfully deploying PKI-based MFA requires highly-mature identity management practices." That's a hot take. And I know that we have a hot take of our own to respond to that. Who wants to kick it off and address that head-on? 

Nelson

It's funny because we… go ahead, HB. 

HB

I was going to say that the other thing that's part of that PKI-based section in CISA's guidance is that they suggest that PKI-based solutions are less widely available. And I think that that's an interesting interpretation for any technology that is 30 years old and has billions of daily users across many different types of use cases. 

So I understand… - Sorry, I didn't mean to cut you off. Maybe they just are talking about it in terms of ease of use because from what I understand, PKI has some baggage, right? 

Reece

That's where illustrious Nelson came up with the very idea for the company out of that problem. So I guess I'll let Nelson talk to that. 

Nelson

So it's funny because that's right. We're kind of working on a different company on a different problem, and it came as a mandate from the founder of that company, which happens to be Jim Clark, the same founder of Beyond Identity, that we could not use passwords as an authentication mechanism. 

And we scratched our head for a second and figured, all right, so what do we do? And if you're not going to use passwords, you have to use asymmetric cryptography in some way. So, he wanted to implement this in CA, essentially said, "Hey, we're going to go find an HSM and we're going to go code a certificate authority in whatever language you want to choose. 

Figure out a way that I can move them around if I need to. If my server at home that holds all the infrastructure that runs this stuff goes down, I want to be able to unplug it from that server and plug it somewhere else and that machine should have an identity now. So I started looking around and YubiKeys have a part of enclave where you can store certificates. MacOS offered a way to use those certificates straight from the YubiKey, and that gave us a couple of ideas. 

So three years later, we're running this whole thing with hundreds of certificates, one being signed every couple of minutes. And we started thinking, hey, this seems hard, but now that we understand the basic concepts, it's kind of just you know how to sign something, you know what kind of claims you're going to put on that certificate. 

Is there a lot more that we need to learn about certificate authorities and how to run them that may have been falling? But it also occurred to us that we maybe didn't need to run that as a centralized service. If each house needed to know how to authenticate its users, could we run the signing of the certificates themselves in the user side and have everybody have their own certificate authority rather than distributing those certs as a central component? 

So it came as a light bulb moment and started thinking about it, ended up implementing it, and that kind of idea took off, and we started Beyond Identity based on that. 

Reece

What a whirlwind romance with PKI and certificate authorities? Such a romantic beginning for us. But how does the PKI kind of tie into phish resistance? Like, what about PKI makes it worthy of a mention in that conversation? Because I think a lot of people, their minds would go to FIDO. 

And HB, correct me if I'm wrong. I believe the memo does call out FIDO as well, but what does PKI have to do with this? 

HB

It offers the two major varieties of phish-resistant cryptographic authentication that are available. So it calls out the FIDO2 WebAuthn approach and it calls out PKI-based solutions. So fundamentally, if you can establish an encrypted channel from a service being authenticated all the way to its authenticator and use public key cryptography, the asymmetric key promises of the technology, both in FIDO and PKI-based solutions are similar and it's the conveyance of the public and private keys and the associated metadata and information that differs. 

So both of these solutions, because of that cryptographic foundation, solve for a lot of issues that come up with manual entry or knowledge factor or shared secret-based technologies. 

But to Nelson's point, the whole thing, like where he was looking at, it's hilarious to me they call them houses, like, you know, these mansions, palaces, whatever these companies specialized in supporting were being supported with a CA that was running on a Raspberry Pi. 

The idea of having these multimillion-dollar art and wine collections protected with a little $75 Raspberry Pi sitting in the corner is just a hilarious image to me. And yeah, so coming up from that and thinking about how to build something that's decentralized, it feels really obvious when you hear about it, but that's just a reflection of what an innovation it is to be able to leverage all of these secure enclaves across all of these common devices in a single sort of framework. 

So maybe, Nelson, you could speak to sort of what these challenges are with building a PKI-based solution. Like, how you came to what the software would need to be and what type of platforms it would need to support in order to be able to address this commonly-used services and infrastructure argument. 

Nelson

Yeah. So, what was interesting is, when we started, we were kind of dealing with Macs and iPhones almost exclusively because it's what that type of user population prefers, but very quickly, we need to figure out how to sign on Android and on Linux. 

And the number of platforms that needed to support key creation exploded very quickly. But the primitives and the ability for those libraries to be built to abstract the platform that's signing, kind of use those as an enclave and create a general notion of an enclave and then create an AES 256 key type or an RSA key type. 

Those primitives are present in all of those. They're pretty universal. So if you have those primitives, you can sign certificates, you can sign jots, you can sign C-board messages, which is what CTAP and WebAuthn use. So it becomes a toolkit that's pretty useful in general cryptography and nobody had created that. 

So, Mike and some other folks started working on it and pretty quickly came to something that was applicable, and building that into a native iOS application or a Mac application or a Windows application was pretty trivial after that. 

Reece

It's interesting to hear you say nobody had created that. And that kind of takes me back to the guidance coming from CISA. They're like, you need a sophisticated identity and access management team to be able to do this. So what is it going to take to kind of redeem PKI in the public eye? That way people are like, "PKI, do." 

You know, not something that they want to avoid. 

Nelson

It's funny, because every time you speak about PKI, most folks think about [inaudible] and CAT cards in the government use case. But I remember Microsoft used to have a CAT card for VPN access, and I don't know if they still do that, but for a long time they used to have that physical possession factor as the only authentication mechanism for a VPN. 

I'm sure… We don't talk to many companies that use that system anymore, but I'm sure there's tons of them out there that use cards or certificates in some way that are deployed via MDMs. And they have to run infrastructure, they have to run their own PKIs. I don't think it's only the federal government that does it. 

HB

And to your point, Reece, I think what ends up needing to happen for PKI to become relevant is that the PKI needs to become invisible, similar to how the FIDO needs to become invisible. 

The fact that today you still need to understand WebAuthn in order to do an implementation of FIDO, and you need to understand, like, what CTAP is providing you. And you have to understand a very specific definition of what represents an authenticator. These are difficult problems and they are problems that don't need to exist. 

What people need to have are credentials that are safely stored, unexportable, tamper-proof to the maximum level possible, and universally applicable to whatever services they're authenticating to. 

And if FIDO provides some level of universality, obviously, it's great to use FIDO. But the reality is that today you have to link these things together using one or two steps and you have to depend on very specific implementations at the browser level, or the OS level, or the integrating SSO bridge. 

And so for all of these kinds of things, bringing these capabilities together, figuring out how to make every operating system behave consistently across all of the possible use cases, I think it's really important. 

Nelson, you've been working a lot on our customer identity stuff, so you've been exposed a lot to WebAuthn. What would you say, like, when the topic of WebAuthn comes up with a suggestion that it's mature technology that's widely available, how would you characterize that for the enterprise use cases? 

Like, I understand for the customer use cases, some of the applicability, but even there, is it truly universal? 

Nelson

Most folks have no idea. I was talking to a financial institution a couple of weeks ago and I was coming from Authenticate, the FIDO conference, steeped in that world for a week, and now jumping into a call with someone who never heard of passkeys, has no idea what WebAuthn is. It was kind of jarring. So. 

Yeah. Yeah. I was like, "Okay, now how do I explain passkeys to someone who's never heard of WebAuthn?" It was very interesting. But folks have that problem, and I don't think many of them already recognize that solutions for the problem of phishable credentials, account compromise, bad passwords. There are solutions in the market that can help them address that. 

And until you bring it up and actually walk them through the use cases, they have no idea. 

HB

- Yeah. So I think to me, that's a really important thing for us to remember is that when you look at a lot of these technologies and they're described at these fundamental levels, like building block levels, describing something as PKI-based authentication or FIDO-based authentication, it's very much describing, like, a narrow attribute of enabling technology. 

Like, these are phishing-resistant enablers, not phishing-resistant solutions. 

Reece

Hot take. 

HB

And when you're trying to create a phishing-resistant solution, you have to take into account the higher-level goals that you're trying to achieve. And within enterprises, those stem from your IDP and SSO choices. And building universality means supporting native applications, supporting Web applications, and various infrastructure and administrator use cases, as well as virtual desktop infrastructure. 

That stuff requires this solution concept. And I think ultimately, customers are well served when they think about a phishing-resistant solution instead of a phishing-resistant enabler. Ideally, we'd like customers to never have to think about these things. 

We rely on PKI and nowhere in our… We've built a distributed PKI. The patent is with Nelson and it's an incredible idea, it's a powerful idea, and nowhere in our product is PKI mentioned. And I think that that's a testimonial to the success of the implementation. 

Reece

That is a way to end it, I think. And I think the dust is kind of going to come off of PKI. CISA put it out there. I think more people are going to pay attention to it. I think that people might look at, "Oh, only sophisticated identity teams can do this," and kind of take that as a challenge and be like, " Oh, yeah, yeah, watch me." 

So I'm excited to see how this conversation develops, not just enabling phish resistance, but achieving phish resistance pretty easily. Thanks for tuning in, everybody. We're going to put the link to this CISA memo in the description. It's called "Implementing Phishing-Resistant MFA," if you want to Google it in the meantime. 

See you next time. Like and subscribe or else. Bye-bye.