Security Cryptography Whatever

Passkeys with Adam Langley

• Deirdre Connolly, Thomas Ptacek, David Adrian • Season 2 • Episode 1

Share episode

Adam Langley (Google) comes on the podcast to talk about the evolution of WebAuthN and Passkeys!

David's audio was a little finicky in this one. Believe us, it sounded worse before we edited it. Also, we occasionally accidentally refer to U2F as UTF. That's because we just really love strings.

Transcript:
https://securitycryptographywhatever.com/2022/08/11/passkeys-with-adam-langley/

Links:


Don't forget about merch! https://merch.securitycryptographywhatever.com/


"Security Cryptography Whatever" is hosted by Deirdre Connolly (@durumcrustulum), Thomas Ptacek (@tqbf), and David Adrian (@davidcadrian)

Deirdre:

Okay. Hello, welcome to security, cryptography, whatever I'm Deirdre.

David:

I'm David

Thomas:

Oh, why you so terrible? I'm Tom.

Deirdre:

And we have our guests today, Adam Langley, uh, who a longtime Googler has worked on a lot of stuff. Hi, Adam, how are you? Uh, um, and we're very happy to have you on today because there's been some news about new, less fishable credentials related to web often that may or may not be referred to as passkeys, big air quotes around. Passkeys do you wanna tell us a little bit about what's going on with quote unquote pass keys that may or may not be a trademark term?

Adam:

uh, sure. Um, what do you wanna know? Like, I, I've got the list of, uh, sort of questions that in are in the dock. Do you want me to go down this? Do you want me to start my, like, I know how many minutes spiel, what got

Deirdre:

got announced at Google IO. Okay.

Adam:

So what got announced at Google IO was, , technically discoverable credential support in the Android platform authenticator. what this means is if you are used to using security keys, you are probably used to using them in a second factor mode. So username password, please touch your security. Key security keys, have long been able to do more than that. Um, if you have a modern Yubikey, they can have, you can have a pin that you need to unlock it. They can have fingerprint readers on them. Uh, they can in fact sort of skip over the, having to enter a username part. You can just say what accounts you got for this website and like pick one and then do the fingerprint. And so the sort of like what you have and what you are, are sort of combined together, you have the security key, and it did a fingerprint read. Now we, we think that people should move beyond the sort of the talk of multifactor. Um, multifactor was sort of a sensible concept in the world where the first factor of the password was so bad. Uh, but if you do want to think in terms of multifactor, right security keys can be several factors. So the flow where the security key is sort of both the username and the verification that's called a discoverable credential in WebAuthN. And so if you want to think about it in the narrowest sense, what we announced was supporting the Android platform, authenticator where, you know, an app or website can just say, sign me in, right. I dunno who the user is. Just do something. Right. And so the, the Android phone can then pop up and say, here are the accounts you've got. Um, would you like to select one and so on and so forth? So not just

Deirdre:

Okay. So this is. Anything that the WebAuthN, the web authentication API, which is a browser API supports right now. And that includes multiple kinds of credentials, right? Not just this, uh, this new thing that apple has talked about recently.

Adam:

this, you think that apple has talked? So what apple has talked about is somewhat the same thing. So they've used the word passkeys as did we at Google IO. And, um, a passkey is a more consumer friendly branding for a WebAuthN credential. Right. Um, and if you ask apple and if you ask us Google, a PA key is sort of a synced WebAuthN credential, it's a WebAuthN credential that's sort of reliable and dependable, and it's always there. But not every, uh, we're not gonna be syncing them everywhere. And probably the term will end up being, you know, a little bit vaguer. And it will probably at least for a while, just sort of like, be another word for WebAuthN credential that involves fewer letters and fewer syllables

Deirdre:

why would you want to sync a web, a WebAuthN credential as opposed to not sync it like which we have been doing since, uh, Fido keys and previously UTF key pairs, uh, we've used have been pretty locked into wherever they were generated.

Adam:

So security security keys have worked pretty well for expert users and enterprises, right? And their model has been hardware bound, private keys, never leave the device so on and so forth. But if you are an expert user, like the advice is to buy two security keys. both register every single one of them on every site you use and keep one of them in a fire safe at all times, um, which is sort of both somewhat expensive for the average user and also really inconvenient. And so if the, uh,

Deirdre:

all over my house.

Adam:

right, and do you remember which one goes where they all go everywhere?

Deirdre:

they all go everywhere. I have to try them

Adam:

then you've actually done pretty well. Um, but you know, if we are trying to take web and broader, we're trying to take it sort of to the, to the wider space, to the regular person, um, like that model doesn't fly, right? So we've gotta have a better answer for how do you survive device loss than own two devices. Uh, and so for, you know, for a regular person, we think syncing and backing up these keys is pretty good. Um, obviously that syncing has to be dealt with carefully. Um, and there's a balance between now, how secure is it versus how likely are you to get locked out?

Deirdre:

mm-hmm

Adam:

But if you consider that for the vast majority of websites right now, um, if you have access to the sort of user's email, then you can be set the password they are in effect delegating their account recovery to the user sort of email provider anyway. Um, well in that world, it probably makes a lot of sense to sort of sync those keys to the email provider. Right. It's almost the same thing was

Thomas:

wait, is that, is that actually true? I had, I had a different question. I was gonna ask, but the The, the thing you're talking about is kind of fresh on my mind right now. Um, so you just, you just said that kind of in a lot of cases, morally, um, you know, account recovery means going back to the email address, but basically account recovery is verifying custody of a Gmail account. How, you know, recovery works on most services. Right. And, and what we're talking about is backing up second factor credentials, right? So I, I believe it, it, it is a norm for password resets, um, to back out, to, you know, verify custody of the Gmail account. Is that, is that universally a norm for second factor credentials? For instance, if you lose the second factor for your Amazon account, you can't just go back to email to verify that you have to actually, you know, send them documents and stuff. I'm just wondering if the model is really the same there. Like if that equivalence is actually valid,

Adam:

So you're right that maybe it's not, but, um, I'm approximating in sort of like two dimensions here. The first dimension is, uh, simple access to the account is generally not enough to get access to the passkeys. Um, so take, for example, apple who have made their announcement and it's all public. Uh, you need to know the pin, I think, of a device in the iCloud key chain circle. In order to recover iCloud key chain, it's more than just getting access to the iCloud account. Um, the second sort of access in which I'm simplifying is that at least for Google, um, our passkeys will have two private keys if requested by the website. Like the first private key is the one that is synced. The one that you like, sort of know, and love from WebAuthN. Um, and the second one will be hardware bound to a given device. So,

Deirdre:

I'm waving my pixel. So

Adam:

yes. Um, so if you are a particularly sensitive website who has sort of, you know, risk analysis and so forth, you can see that not only is this sign attempt coming from someone with access to the passkey, but also it is from a known device. And sort of that additional signal may be enough to convince you that something is, you know, happy and acceptable. Whereas before you would say this isn't odd location, but this used to be signing in sort of, I'm going to reject.

Deirdre:

mm-hmm but if that device from an odd location is verifying with a device bound key, as well as your synced pass key, then you're generally like, oh, well you have both of these things that I, one that I already know of. And one that's my synced.

Adam:

Right. Um, it, it might be a useful input for a risk analysis engine for sophisticated websites. So sort of, those are the two ways in which my sort of glib answer around, well, you have password recovery, therefore it's fine. Um, like maybe a little bit closer to a reality than sort of the,

Thomas:

Gotcha. So I I'm gonna, I'm gonna be super annoying here, cuz like I follow the stuff that we're talking about with passkeys and with WebAuthN and stuff like enough to sort of keep up with it. But my real kind of in my head intuitive understanding of, you know, security keys and advanced credentials is still stuck in the U2F era. Um, so like I followed web off the, to the point of like, okay, it's a better JavaScript API around U2F, but it's basically U2F. Right. Um, but that still kind of leaves me in a head space of these credentials are tiny little things that I'm plugging into USB ports. Right. Like they have no real storage or things like that. So we're, we're, we're talking about things like, um, you know, discoverable credentials that, that implies like a discoverable credential implies that there is per site storage on the key. Right? Like, does that, how does that fit with a YubiKey.

Adam:

So yes, Thomas, you know, uh, you're familiar with the U2F security keys. So the question is sort of like what happened, what happened between then and now? Okay. So U2F security keys, um, U2F referred both to a protocol between, uh, a computer and the security key, and it referred to a web API, which is now mostly gone

Deirdre:

mm-hmm

Thomas:

was the web API, where I, that was the web API, where I would like get the USB message port and then post messages to it.

Adam:

Well, that was a special source from Chrome because Chrome never implemented the U2F web API. What we did was we shipped a hidden extension that you could post message to, and that extension did things in a way sort of isomorphic to the U2F web API. Uh, and so you could sort of polyfill the JavaScript in there and pretend that Chrome implemented this web API. But yes, that is the one, the one that you talk to over post message, um, Firefox actually implemented it properly, but these days sort of it is mostly gone. Um, and it will be like even that hidden extension will be gone from Chrome come next year. so this protocol between the computer and the security., uh, it was a very sort of straightforward wire protocol. Um, it was designed in such a way that security key didn't have to keep any state. And in fact, didn't even have to keep state in memory, right? The computer pulled the security key for everything. Um, and the way the security key didn't keep state is that when it generated a credential, it just sort of encrypted the seed for that private key and handed it back to the computer as the idea of this credential. So all the storage was always offloaded to the server. That sort of developed over the years into, um, CTAP2, which is sort of the follow on protocol from U2F. That's a substantially more complicated protocol. It's throwing CBOR messages back and forth. The security key, like keep track of some state. And as part of CTAP two, one of the things that was added was called resident keys. And as the name sort of suggests that involves the security key storing things

Deirdre:

mm-hmm

Adam:

subsequently renamed that to discoverable credentials because the term resident key was super confusing, but just what discoverable credentials are, are credentials that, uh, you can discover not knowing their ID. You can just ask the security key, like what you got, for example.com.

Deirdre:

Oh,

Adam:

if you have a modern Yubikey, it does that, right? Modern Yubikeys have storage. They, you know, they have some kilobytes and you can create a limited number of these credentials on them. Um, and so sort of that sort of the, the step up to like five years ago, um, where these sort of capabilities started to come to security keys.

Deirdre:

mm-hmm

Thomas:

CTAP is I'm. I'm just gonna ask, you can tell me if I'm wrong. Right. But like CTAP is the thing where the browser is talking to, like, a USB key, right? It's like a device driver almost, right? In my understanding of it. Right. Like nobody really speaks CTAP except the browser and like Yubico or something that's that's is, am I right about that.

Adam:

Yeah. CTAP is the computer to security key protocol that runs over USB or runs over NFC or runs over BLE.

Thomas:

And there's like, there's, CTAP one, which is just U2F there's CTAP two, where they made everything JSON encoded in CBOR

Adam:

yep. Um, it's, it's all CBOR rather than JSON but yeah. CTAP2 is the, the more complicated one. There's a 2.1 and there'll be a 2.2

David:

How does this then relate to the actual, like WebAuthN JavaScript API that like, I think, uh, maybe more developers are familiar with.

Adam:

So the WebAuthN JavaScript API lets you, um, create keys on and get assertions from authenticators where authenticators are a sort of a more abstract concept, but they are generally either realized as security keys. Right? So the browser speaks CTAP to some security, key to be an authenticator or the sort of the browser. Um, in some sense, sort of does it itself on the computer. So windows hello is a WebAuthN authenticator, but it's not a security key. Right. And likewise on, if you run Chrome on Mac, you will see right. You can use touch ID there. Um, and now that sort of PAs keys come in, we're bringing in phones as authenticators,

Deirdre:

Mm-hmm

Adam:

right? So that's the solution to users all having to go out and buy sort of a pair of security keys or Deirdre's case, dozens of them.

Deirdre:

don't know if it's dozens, but it's approaching more than one dozen. How does that differ if at all, between what I can do right now, at least with my Google account, which is register my phone as another, , factor challenge to log into my accounts.google.com uh, origin

Adam:

So, yes, you can do that on accounts.google.com. You can say register your phone and it will send a post messages to the phone and you like pitch. Yes, it's me or no, it's not or something. So it's different in two ways. one is that when you're using a phone security key, you have to show proximity between the two devices.

Deirdre:

right.

Adam:

So an attacker in some random country can try log into your Google account and it'll send a post message to your phone. And if you get confused and hit, yes, then that's it. um, whereas when it's done a security key, right. That the phone has to be close to the computer that's signing in

Deirdre:

mm-hmm

Adam:

the second way is that, um, Google has to know who you are before you can send this post message.

Deirdre:

right.

Adam:

Right. Whereas when you are using the phone as a security key, again, you can just ask the phone. Hey, what account you got for google.com?

Deirdre:

Got it. Okay. So it's not necessarily a phone on which I am logged into Google already. It is just a device of some type that just happens to be a phone that is within like Bluetooth proximity or, you know, Sonic pingable proximity that can talk to my user agent, the browser or whatever. Um, and it can query it for. Credentials for accounts stuck, google.com or whatever other, uh, service that is that you're interacting with.

Adam:

Yeah. Um, and it is Bluetooth in the case of the security key protocol,

Deirdre:

Okay. And only, well, unless it's literally plugged in via USB or Bluetooth. Yeah.

Adam:

the, the literal plugging in the phones via USB is, uh, I don't know if that will hang around. Um, I threw that in there because I was worried about sort of requiring Bluetooth and internet connectivity on both sides. Turns out it never worked on windows because the windows USB stack doesn't work like that. Right. Um, so maybe it'll hang around, but it's like super not discoverable. You have to click quite far down before Chrome will suggest that, um, no, it doesn't work at all on windows, but even on Mac, right. You, you have to go through a few error screens before you'll say, Hey, you know, you could plug your phone in over USB cable. Um, so we'll see if that sticks around. It is sort of a fallback right now in the case that, you know, nothing else works because. You know, login is a pretty core function that if it's not working for you, you can be a bit stuck. Um, but I would say without window support, that didn't work as well as we would've liked. And maybe we should, uh, look again at Bluetooth about whether we can send the data over Bluetooth as well as just the proximity,

Deirdre:

Got it. Cool. has the challenge, the cryptographic challenge response protocol changed since like classic UTF days or the Chrome equivalent of UTF to what is gonna get deployed for pass keys? Um, or could you overview it for us?

Adam:

um, the, the rough answer is no. And in fact, okay, so when you're using a phone in security key, it is CTAP2 that has spoken between the phone and the laptop. So it really is pretending to be a security key. Um, the thing that has changed when you're using a phone is just the transport. Like the, the way the data goes back and forth between them. Um, and we can sort of like, I'm happy to talk about the details of that if you want, but it is still CTAP2. And so it's all the same at that level.

Thomas:

I'm I'm super interested in the details of the transport app. The, the, the big question I had is when can I get rid of all my keys and just use my phone for all this stuff? Like, I'm a, I'm a relatively security sensitive user, but the keys are silly. So, um, yeah, so like the, the actual specific details of how, you know, how we're actually doing CTAP2 with phones is actually super interesting to me.

, Adam:

so as you would've seen in sort of like either Google or apple Apple's demo, you kick off with a QR code, which is sort of only needed the first time you use a phone. If you used a phone before you don't need to do that, but sort of like Denovo with nothing shared the desktop displays, a QR code, you scan that with the phone, the QR code contains a compressed P 2 56 public key and a 16 byte secret key. And so the public key is used to authenticate the laptop. And then the secret key knowledge of that is what authenticates the phone sort of to the laptop. All right. So the phone gets these two keys and it's derives a bunch of stuff and it goes off and talks up to the cloud. It doesn't talk over Bluetooth because we tried real hard for several years to get data communication over Bluetooth working. And it, it never worked right. Um, with the diversity of like different Bluetooth controllers and different phones and so on and so forth, uh, like sending this, the few kilobytes of CTAP two back and forth over Bluetooth, never got to the point where we thought that was a viable product. So the phone is gonna talk to the cloud and say like, Hey cloud, um, I'm gonna be setting up a tunnel. And then the cloud sort of says like, sounds good. And then the phone will start broadcasting a BLE advert. Uh, and that BLE advert contains an identifier for its cloud server, i.e. Like, who'd you go talk to on the internet in order to reach this phone, um, and, um, an n once, right? Uh, a thing that you need to have received to prove that you are close enough to receive this Bluetooth message, right? So

Deirdre:

And that's every time that it is on and trying to be like, hello, I am a, uh, discoverable credential, um, that nonce, n-once changes every time that you, you turn on this session and start behaving as a discoverable credential. Okay.

Adam:

for every QR scan or, or for every time you kick it off without a QR code, yes. It's going to be a new right. A new tunnel, new N once. Um, so the laptop, if it's within range can receive this BLE advert and it actually just like throws the whole BLE advert into H KDF to derive keys. It can find the tunnel server because that was identified in the BLE advert. It can go connect to it and say, you know, please wire us together. Um, and then the laptop has to start off a noise handshake to the phone.

Deirdre:

Yep. Oh,

Adam:

has to, I mean, no need to sort of like reinvent things, right? It is, um, it is NK PSK or K N PSK, um, is it can actually be either depending on sort of details or things, but the, the laptop has to prove knowledge of, uh, the private key whose public key was in the original QR code.

Deirdre:

Yep.

Adam:

And it has to prove, um, the PSK, which is drived by including in that Bluetooth advert. So if you didn't get the Bluetooth advert, right, you, you can't get the correct PSK. And so it sends that to the phone.

Deirdre:

right? This is you get it by piping that through the H KDF and some other stuff.

Adam:

Yeah, the H KDF brings in, um, the secret from the QR code, the BLE advert, some context string and so forth.

Deirdre:

Got it.

Thomas:

So, so, okay. I'm, I'm following all. This is super interesting, right? So like you're using a PSK version of noise so that you can do kind of effectively a channel binding type thing. Um, in this case, just proving the proximity, but it's like, you're, you're trying to establish a context between the phone and the laptop there. I, wire guard also has an optional PSK noise handshake, which I always, I always understood as kind of a post quantum kind of deal there. Like, you know, the PSK part of noise is quantum resistant or whatever, and that's why, and in my head I always had like, okay, well, that's why there's, you know, PSK noise, right, is to do things like that. But also it works like a channel binding mechanism too, which is neat. I hadn't thought about that before. This is the tunnel protocol that we're talking about here, if I'm following this. Right. Right. So like the, uh, the phone talks, the cloud, the laptop talks the cloud, it's it establishes a tunnel between the two of them. And the thing that makes that tunnel secure is that you run the noise protocol over it. Am I wrong about any of.

Adam:

That's all correct. Awesome.

Deirdre:

Awesome.

Adam:

I, I think the way to think about the PSK is that we want to authenticate the laptop to the phone, but these two things have never sort of like been close to each other before the only data exchange was this QR code that was seen by the phone. And hence that goes into a PSK anyway. So the laptop sends its first noise handshake message to the phone and if it all checks out great. And if not, that's the end of the session so that the laptop can't sort of guess the, the N ones, unless it's really lucky, right? It's a bomb article. It only gets one chance. But let's assume it's, everything's happy. Um, like pretty straightforwardly right now we have a noise tunnel between these two devices over which they speak CTAP2. And the, the phone acts very much like a normal CTAP two authenticator and the laptop, just like it was talking to a security key, sends a discover or credential request saying what credentials you got, for example.com. Uh, and then the phone will, you know, on the screen display the account picker and the user can pick one and then do their biometrics. And then back the signature goes, uh,

Thomas:

When, when we're thinking about when, when we're thinking about the laptop's role in this protocol, am I really more properly thinking about the browser? Am I thinking more about like chromium knows to do this? Um, like this doesn't sound like an operating system component. This sounds like, I think the browser knows how to do, huh.

Adam:

it's Chrome right now on some platforms. But if you are running Macs 13, then the platform itself can do this. And then.

Thomas:

the more important question I have in my mind, just cause I wanna be able to do this, you know, tonight, right. Is like, I, I don't, I don't doesn't sound like I would need like a phone OS support for this. Right? Like I could write an app that does all the stuff that we're talking about right now. Oh,

Adam:

uh, that is currently true on Android, but we don't want it to be true if that makes sense. Right. Um, you wouldn't particularly want an app to be able to do this. This is sort of more properly a system feature and on iOS, I don't think you can write an app to do this because the BLE advert has to contain service, data and apps. Can't set service data on

Thomas:

Ooh,

Adam:

that.

Thomas:

I follow completely. And I'm not happy that I follow. Okay. That's that makes sense. Okay. So I really I'm, I'm waiting for this to ship before I'm ever using this.

Adam:

Right. Um, iOS 16 betas will do it. Um, Android can do it today if you know all the secret ways to set the special flags. Uh, but we have not publicized any of that yet.

Deirdre:

makes sense. Uh, but it is it it's coming. It's already been built into iOS 16. You're just waiting for that to actually land on the majority of iOS devices.

Adam:

Right. And in fact, if you do want to play with it today, like you can use a straightforward, like normal Android device today, and it will work in the second factor mode, right? It's not gonna do discoverable credentials, but you can go to Github today and like go into settings to say, add security key. And then when the Chrome dialogue pops up, you can say like add a new Android phone and it will display the QR code and you can like scan the QR code and it should all just work. Or the very least, if it doesn't work, you should let me know.

Deirdre:

Cool. I, I have, I think github.com has been one of the best actual websites that I use that supports the most diversity of, uh, key pair credentials, including like the one that's stored on my secure element on my MacBook laptop. Um, I don't even think google.com or account to google.com. Does that nicely for me? Yeah. Um, kudos to GitHub. I'll just say that.

Thomas:

Now if I'm like web often would call me a relying party, right? Like I'm a service provider, you know, I, you know, I need to, you know, two FA authenticate my users and all that. Right. Like if I'm, if I'm a

Deirdre:

are fly, fly.io.

Thomas:

I mean, I don't wanna drop, you know, plugs for the company I work at. But, but yes.

Deirdre:

Yes.

Thomas:

So if, if I'm, if I'm, I am in fact fly.io, right? Like I don't need to care about any of this. Do I? Right. This just works with the WebAuthN API, right? Like this is all stuff happening under the, I do need to care cuz of the, uh, because of the resident keys thing, it changes the API that I'm using. Right.

Adam:

So mostly you don't need a care and it's standard WebAuthN, and you can set the still called resident key parameter in web Orhan, which gets you discoverable credentials. Uh, and like you can test that today with, uh, you know, a security key that support CTAP2. And it will all sort of, in some ways just work. Um, the ways in which sort of PA keys are bringing new things to the table are a few WebAuthN changes and then a few sort of behavioral expectations on websites. So, all right, let's talk about, um, one of the WebAuthN changes, which is that you will be able to tag a text box on a website with an autocomplete token, which I think is spelled WebAuthN. Um, and then you can create a web author request and you say, uh, mediation Condit. Which is a field that's been in the CRE man spec forever. But what we are interpreting it to mean was don't display UI. And so you have this web Orhan request that doesn't display in a UI that just hangs out there. And if you've tagged this field with autocomplete WebAuthN, the user can click in that field and the auto fill will suggest pass keys.

Deirdre:

Ooh. Ooh. Okay. So either my browser that syncs credentials or has traditionally synced past words and now may sync past keys such as Chrome or safari or whatever, or the password manager in my choice, such as one password can. Automatically autofill pass keys for me, the way that my passwords have traditionally been auto Cool. Hmm

Adam:

So if you are, if you're using Chrome on windows, right, we'll get, um, credentials from windows. Hello. uh, on Android, right? We're gonna get from there. Uh, you can do this sort of on the apple platforms as well. So, so that's, um, that's an example of an actual change to WebAuthN we're making sort of to try and make the transition easier. Um, and on this say, let's say the conceptual side, when you've just signed into a website, using a phone, the website can see that you've signed in using a phone. Like there's a little field that says, like this assertion came from a cross platform authenticator, right? I, the user did not use the laptop themselves. And as a behavioral change, sort of what we are expecting sites to do is see that, and then prompt the user and say, Hey, do you wanna register this local computer? Because that would be easier to sign in next time. Right. It will pop up in the auto fill menu and all that sort of stuff. Um, so there are both some tweaks to web and the spec and some sort of tweaks to the mental model around how you use it. And like when that all comes together with phones sort of acting as authenticators and syncing credentials, right? That is in totality pass keys, but it's a little difficult to explain.

Deirdre:

right. Um, when you were talking previously about setting about the phone as your credential, talking to the cloud, and then basically doing enough key exchange over BLE to set up your noise tunnel, to actually query it over the tunnel in a secure manner. Does that mean that every, uh, web service that you're trying to authenticate to has to set up something that the phone, which doesn't know much about you, it's just operating as a dumb quote, unquote, uh, you know, a discoverable credential device. Like how, how does that work? So the, the web service has something in the cloud that you can like have these devices talk to as like the, the pass through to negotiate this channel. Like, as if I'm trying to deploy like Deirdre connolly.com as like a service that you log into that way. Like, what do I deploy as a web service, uh, person?

Thomas:

don't need to, you don't need to deploy any of that. Right? Like that's the, the cloud stuff is like, I assume Google provides something like that, right? Like it's just a, it's a background.

Deirdre:

thing

Adam:

right?

Deirdre:

iOS thing.

Adam:

Or an IRS thing. So for example, Android phones will use a particular Google service as their tunnel server.

Deirdre:

Got it. Okay. Alright.

Adam:

The, the reason is, um, a trick I haven't sort of mentioned yet, which is that if you've just used a phone via scanning a QR code, the phone can then say to that laptop, it spoke to, Hey, if you want to talk to me again, here's a bunch of keys. Um, don't bother like scanning the QR code. Next time you can just like talk to this same tunnel server and go ask it to contact me. And it knows how.

Deirdre:

Uhhuh. Yeah.

Adam:

so next time when you're on the laptop and you want to use a phone, like, you'll see it listed there. It won't be like, go scan the QR code. It's just like, click the name of the phone.

Deirdre:

You won't even have to like, would you even have to unlock your phone or would it talk to like github.com through the cloud and do the querying for you if it's on and, and talking to the internet?

Adam:

You have to unlock the phone in order to exercise any credentials. Right. So you can't get any signatures without sort of biometrics on the phone.

Deirdre:

Okay.

Adam:

Um, but that means that the tunnel server is a thing that knows how to contact the phones.

Deirdre:

Yes.

Adam:

And So in some sense, like the phone, yeah. The phone owns its tunnel server, right? The phone always picks who its tunnel server is. Um, and right. If you are, if you want Acme corporation phone, it'll be an Acme corporation tunnel service.

Thomas:

Does the, does the tunnel service protocol have a name?

Adam:

um, it was called cable for a long time, which stood for cloud assisted BLE. Um, yeah. Uh, that, wasn't one of my namings. Um, but as you can imagine, little bit confusing to call it cable. Uh, so I think Fido has decided it's going to be called hybrid, um, which is a yeah. Suitably sort of like meaning free word that could be stretched to include anything we

Thomas:

Yep.

Deirdre:

Yeah.

Thomas:

so there's gonna be hybrid V 2.1 and hybrid V 2.2 and wall. Be this confused again in a year.

Adam:

probably we're already at cable V 2.1 right now that's the thing that's actually being used. Um, so it's gonna be called hybrids and that word should be enough to encompass things like even when we start to say, well, we can get rid of the tunnel service and do everything over BLE, if there's sort of a lack of internet connectivity, right. We're just gonna call that hybrid as.

Deirdre:

Okay. Yeah.

Thomas:

All right back to details, right? So we're, we're saying when, so when we're doing the QR code free version of this, like after we've synced once, and then we've told the laptop, you know, here's the set of keys I can do. You can build tunnels with any of these, you know, things anytime you want. And then we'll establish it asynchronously from the cable server back to I'm gonna, by the way, I'm just gonna call it cable from now on, um, from the cable server, the cable server, back to the phone. This is probably a dumb question. Right. But like what's the mechanism for the cable server to get asynchronously back to the phone, just like a push message or

Adam:

Um, so in some sense, the, the hybrid server, I guess I should call that, can use whatever mechanism it wants, right? The protocol doesn't care in practice with Android phones. Yeah. It's a post message. And the message says like, Hey, like wake up, um, here's the tunnel server to connect, to go start your stuff, start sending a BLE advert. Right? Cause there's always a proof of proximity. Right? The BLE dance happens every single. So,

Deirdre:

yep. Even though you only do the, the, the handshake to set up the tunnel over BLE with the QR code, the first time you still turn on the BLE, because you have to establish that the phone is actually near the device that's trying to log in on your behalf.

Adam:

yeah,

Deirdre:

Okay.

Thomas:

like sore a kind of like a cached TLS session. It's not cuz you're doing full noise every time you build a tunnel, I assume, but like it's, it's morally kind of the same thing as just like, you know, you can resume, you know, a tunnel that you had before. That's even as I say it and with a limited amount of knowledge I have about this protocol, I just learned about five minutes ago. I know that's wrong, but you know, roughly, you just, you can remember and establish reestablished tunnels. The, the very important question I have is, um, I. Tail scale, ran into a similar situation like this. Um, you know, with the need to kind of reliably bring up tunnels between people that didn't have direct connectivity. Um, and they came up with their own protocol called DERP and one of the great things about D is that they don't really control it. Um, like they run it, all the servers are theirs, but anybody can establish kind of a DERP you know, session. Like they can build DERP tunnels between each other. you don't even have to use it for tail scale. You could do anything you wanted over them. Can I do that with cable? can I like, can I build like random tunnels between different pieces of software with cable servers and then use them as a message exchange?

Adam:

So the, like the protocol between, a cable server and the outside world is public, but the protocol between the server and the phone, right. Does not have to be right. That's a completely bespoke can be a completely bespoke protocol because the tunnel server and the phone are sort of both run by the same entity. They can authenticate each other talk, whatever, like weird thing they want to. So in general, the answer is no. Gotcha. So the.

Thomas:

Gotcha. So the, the phone to server, the phone to cloud end of this is essentially proprietary. Um, and you, you were saying before, like the Acme phone is gonna talk to an Acme cable server or whatever. And what you're really saying there is that like the whole, that whole part of the picture, like the phone and the cable server, all that, like that's just, each of those is vendors specific.

Adam:

right now, Android, Chrome being open source as they are, you can poke around and you can like figure out what our phone to server protocol is. Um, and yeah, you could probably could set up some tunnels, but I can tell you, the tunnel server is not going to allow many round trips. Like the total amount of data exchange there with this tunnel is capped really low purely because, um, we wrote it with people like you in mind, Thomas, and thought like, how are people gonna abuse this? And so like, all the limits are in there to make it really, really awkward. Uh, and I'm pretty confident that if you need some sort of reflection thing in the cloud DERP is going to be like way more convenient for you. Right. We don't have to be perfect. We just have to be like less convenient than DERP come from

Thomas:

To be, be tighter than DERP. Yes. Okay. That was my question. It was well answered. Thank you very much.

Deirdre:

um, going back to, uh, operating on, um, on Android at least. Uh, can you get creds like discoverable credentials from another Android app? Like custom idp.app could provide a credential or does it must, must it come from, uh, the OS or whatever.

Adam:

today. It must come from the OS. Um, we don't want that to be true for very long. Right. I think what you're asking is would there be an API on Android where other apps could be sort of providers of PA keys? Um, in the same way that they can be providers of password.

Deirdre:

Yeah.

Adam:

Yep. We'd like that to be true. Um, I have nothing to announce specifically today. Um, but I'm, I'm happy to confirm that like we would like that to be true.

Deirdre:

Cool because I would definitely like my, uh, one password or other credentials syncer manager that I am. That is for example, I am running a pixel over here and a MacBook over here and probably some weirdo Linux machine over in the corner. And the only way that I can sync my, uh, credentials and other things across all of them is a independent credential syncing service, uh, which in this case is one password. And it would be great if I could also sync discoverable credentials with 1Password, especially on my Android phone.

Thomas:

And the, the reason that one password can't just go freelance this right now, right? The reason why they can't just plug into this version of the WebAuthN spec that we're talking about right now is that this protocol exchange depends on that, BLE advertisement, right? Like the whole, like the whole thing revolves around. There's a BLE exchange somewhere, um, that we're picking up and using the key, the tunnel that we're building. So you can't just build a tunnel to a random service. You can only build a tunnel to something where you picked up a BLE advertisements. Um, and that's, that's a limit enforced by the browser. Basically like the browser just knows how to do that or, or the platform, right. Either the platform or the browser, or whatever's doing the kind of the laptop side of this, um, Like the, the hits there for the, the hits there for people doing random stuff is they have to pick up BLE advertisements.

Deirdre:

the scenario that this would happen in is say my syncing was broken for my one password, but I had all of my credentials on my device. And I'm trying to log in on my laptop with credentials that are on my one password on my device. And I'm trying to use those to authenticate in my MacBook browser, as opposed to I sync them all in to the one password client that is on my desktop. And I want my desktop to talk to a local copy of these discoverable credentials. Um, whereas the first scenario like the, the, the classic scenario that we already discussed, um, I can understand why that would be harder, but also could want to do that.

Adam:

So the, the story for Deirdre this year is that when you pull out your phone and sign in on your MacBook, the website should notice like, Hey, Deirdre had to pull out her phone to do this sign in. I should prompt her. Do you want to create a PAs key locally on this MacBook? Right? You say like, yes, touch ID done. And so I think it's important to note that, um, an account on a website only has one past word. But it has multiple pass keys. Right? And so you end up with pass keys for the ecosystems that you use to answer Thomas's question. Um, the, the phone advertises over BLE. So the phone is the BLE transmitter. So if today you wanted to write an app on Android that like opened the camera and scan the QR code and like did that side of things. You would need your own tunnel server, but you could do it. Right. So in some sense, like you can do that today. What's gonna be awkward. Is that apps on Android, including Chrome when they do pass key operations are going to call into play services to do that pass key operation and play services is not gonna know anything about like any other app on the phone today.

Deirdre:

Mm. Besides the one that's the app quote unquote, that's built into Android itself. That

Adam:

I mean, it, it is play services itself.

Deirdre:

cool. Um, just because I know that everyone remembers the like classic, what you do with those keys when you are trying to log into an app BLE or no, discoverable credentials or no, what happens when you are trying to attest to your identity on accounts.google.com or whatever, and you have a key pair and like, what happens? Can you please describe how the website challenges you and you attest your identity with a pair of.

Adam:

All right. So the sort classic WebAuthN protocol, the website says, um, that's assume it's second factor because everyone's familiar with that, right? You've entered your username. You've entered your password. The website, like mostly knows who you are is just like double checking. Now it calls web often and says here's a random number and know it's big enough that I'm pretty confident that this random number has never existed in the history of the universe before therefore, anything that sort of encompasses this random number must have been created after the point in time where I just created. right. So we call that the challenge. The website also provides the IDs of the credentials, um, that you have got and registered. Cause it knows who you are. You've already given your password. It looks up in its database like, well, here are the N security keys, um, that Thomas has registered and like here are their IDs. And so we are gonna stuff that in there as well. And then you say to the browser, like, go, go do stuff. Then the browser is gonna like pop up and say like, Hey, please touch your security key or insert it or whatever, or, you know, use your phone. Um, but eventually it's gonna send these IDs to some authenticated device and the authenticated device is gonna look over those IDs and say, don't know that one, don't know that one, ah, that one's from me. Right. In some sense, like I know I AEADs open this credential ID with my global secret key and it authenticates correctly and I get a plain text and that plain text is a seed. Which then I can use to generate a private key. Um, and then I sign some stuff. I sign what the browser asked me to sign and what the browser asked you to sign is that challenge so that, you know, the signature was created in a timely fashion and also, um, a lump of J on from the browser. So the browser will put a whole bunch of context information into this JS O like, what origin are you on? What type of operation is this? And blah, blah, blah. And then all that goes back up to the server, right? That lump of JSON, um, the signature from the authenticator. And now the authenticator knows that. Okay. So the security key was in somehow, somewhere in the world exercised. Um, it knows that this browser believes it's on this origin. So like, if the origin is not, you. Right. Um, then, then that's concerning. Um, it knows a bunch of other context stuff. Like what does the browser think going on? Like the browser says, I think this is a registration, or I think this is a signing operation. Right? So all sorts of context to make sure that, um, that, that everything is, is as it should be and what the website should know from that, um, is that, you know, the user very likely wasn't fished because the user didn't like type some secret in right. The browser put the origin in there. Uh, the browser sort of sent a hash of the origin to the security key, the security key shouldn't have even like done the operation if it wasn't on the right place. Um, and if it's hardware bound yeah. You like, you know, that some physical device was actually just used. And if you've got a fancy security key that does fingerprints and so forth, right. The security key will put a bit, uh, in the thing it signs saying like, Hey, I actually like. So a fingerprint or like the user actually had to enter a pin on the computer to act to authorize this operation.

David:

Does that mean that if you're attacker.com and you know, the ID of a key associated with example.com that you could request a signature with the key from example.com over the attacker.com domain.

Adam:

The rough answer is no. And so here's why there's two levels of protection when you are, um, when you are attacker dot. When you make the Web AuthN request, you have to set something called the RPID, which is essentially a domain name. It's setting your name. Right. Um, and if you are like subdomain.Attacker.com, you can claim the names, subdomain.attacker.com or attacker.com, but not, you know, com and not example.com, right? The browser is not gonna let you claim any of those. Um, the security key is gonna make sure that the credential was registered with an identical R P I D value. So like the credential ID is useless, right? If you cannot assert an R P I D or sorry, the exact R P I D, that it was registered with.

Deirdre:

got it. Mm.

Adam:

Additionally, as I said, the browser is going to put into this, like JSON blob, what's the actual origin that is being used to do this assertion. So, um, subdomain.attacker.com. As I said, it can claim the R P I D attacker dot. And maybe like accounts.attacker.com, like actually register some security keys for real right. Not being malicious. that other SubD domain could use those keys because right. It can assert the RPID attacker.com. But additionally, like you're gonna get the exact origin back from the browser. So there's like two levels of checks. Does the security key even allow this at all? And if it is allowed, like what actual origin was used and then the server can check, it was used on the origin is expected.

Deirdre:

Okay.

Thomas:

this only works on TLS sessions, I assume.

Adam:

The WebAuthN API is only present in secure contexts.

Thomas:

Yep. So no DNS sec is required to provide this assurance.

Adam:

No DNSSEC is involved,

Thomas:

Yes.

Adam:

as far as I'm aware. So.

Thomas:

I got him to say it.

Deirdre:

did you say that the plain, the plain origin that you're trying to interact with is included in the, JSON blob the message that is being signed? I think you also said something about hashing, but it's the plain JSON blob as well.

Adam:

The security gets the hash of the R P I D.

Deirdre:

Got it.

Adam:

But the, the right, um, the, the browser also sends this JSON blob with a whole bunch of information, including the origin in which the action is happening. We,

David:

Okay. So that's how web authen works today. How does that change with pass keys especially now that there's two keys involved you've got the one key that synced via your provider And the one that's bound to the actual authenticator device

Adam:

So when you're doing this with pass keys, things are all mostly the same. Uh, the only difference is you don't have to send down a list of credential IDs. You still can do if you want. So if you are, um, in a context on the website where you are re authenticating a user, like you kind of know who they are, they're still signed in, but it's been 30 days or something or whatever. And your policy says like, we need to, you can send down the list of credential IDs, cuz you already know who the user is, but you don't have to. um, you can just send an empty list, which is the indication of like, I don't know who this person is, like, surprise me. Uh, and so in that configuration, and this isn't like new to pass keys, this is just discoverable credentials. It's been in WebAuthN for years. Right? So in that situation, the website gets all the same information back again, as it did before. Um, but it doesn't like, it doesn't have to send the ID in the first place. It just gets to like discover who the user was. Right. It gets the ID back in some sense, rather than having to send it down in the first place. Uh, so that's sort of the main change when you're doing a pass key flow. Um, there are other changes around, as I mentioned, doing auto complete rather than necessarily sort of doing an explicit model WebAuthN operation. Um, if you are one of these websites that wants the device bound signal as well, So at least with Android, you just send an extension in the request that says, Hey, I'm interested in device bound signal. And if the authenticator supports it, then you get an extension back, which is like, here's my public key. And here's my signature of like the exact same stuff, but signed with this public key. And if you've seen the public key before, great, right. May maybe you have some like historical, uh, records of this device, or maybe it's a brand new device. Maybe you've never seen that key before, um, do with that, what you

Thomas:

So for non device bound keys, like, like thinking only about new, modern, pass key era WebAuthN credentials, the non device bound credentials are essentially all as secure as, you know, essentially Google's IDP, right. As whatever their root of trust is for, you know, storing credentials and stuff. Right? So like the, what I'm thinking about non device bound credentials, I'm thinking about things that are backed up and recoverable from people's cloud accounts. And so. the reality of this is probably that Amazon is not going to do an implementation of WebAuthN where they demand device bound credentials. Right. They're just gonna do WebAuthN and it's all just gonna work. And we're gonna be kind of at a place where most common, you know, most common MFA credentials are recoverable from your cloud provider. Which, as you said earlier, it sounds, it might sound if you're like me right now, a little scary in that kind of the whole point of doing multifactor authentication is not just, you know, having things come down to an email account, route of trust. But really what we're saying is we're delegating to Google or to apple, the job of, you know, recovering accounts. It's not that just having your email account gives you immediate account recovery, it's that, you know, Amazon and Google will trust to run an actual, you know, account recovery credential that you have to deal with with them. That's more than just having access to your email account. Right. And so we're, we're kind of, it sounds like we might be heading towards a world where like having to send affidavits, like notarized affidavits to, you know, Amazon, when you lose your two factor, credentials is not a thing anymore.

Adam:

So I don't think the majority of websites will ever care about this weird extension that lets you get a device bound sort of second key. Right? Cause like the majority of websites are like my local paper who like maybe wants me to sign in to like read the paper or something. But like that's not, you, you don't need like super high security there. They're not running risk analysis, whatever. multifactor, like you can squint at this and look at it in a sort of multifactor perspective. I think multifactor thinking all came out of the fact that the first factor was such trash. Right. And so I would encourage people to consider this sort of as new and like, decide what they think about it without trying to sort of project it into, like, how does this fit in a multifactor world? And does it sort of meet those requirements? And like, I don't know if you're a website, maybe you decide it doesn't and that, like, this is interesting, but it's like one step of your sign in process and like, okay. Um, obviously like we want to try and solve passwords and you should keep in mind, like plenty of people have said that over the decade, right. There's a big pile of corpses labeled, tried to get rid of passwords and we're just like hurling ourselves towards it. Um, and like if you said, I think in three years time, you're gonna be one more calling corpse on the pile you might be. Right. But it seems worth a shot right? Like nobody's happy with passwords. We have all this sort of elaborate ceremony around them and multifactor to sort of like try and paper over their flaws. Uh, so it seems worth trying to get rid of them again. And if a website decides that this isn't enough, maybe they do something more, but maybe this is enough in some cases enough for some users. I don't know. I hope it helps.

Deirdre:

Me too.

Thomas:

as like a, you know, as like an implementer at a relying party. Right. Like, I, I, I can't really, like, I have a diverse set of different, you know, customers with different stacks. I can't assume that I'm gonna be able to use like pass keys for pass keys. Like the whole stack that you just described. Right. Like the, all of it, um, like the whole vision. I can't assume that I'm using pass keys as single factor credentials that replace passwords like tomorrow or this year. Right. It's just my, my, my users won't support it. Right. Um, but, but I do need to do like a sane, modern, you know, second factor credential thing that isn't, you know, TOTP or something like that. Right. and you know, my users do have like immediately the problem of, you know, if, if they're using. you know, a physical device, like a, a security key to do this, and they have to have a key chain of security devices or security keys, and it's a whole mess. Right? So the, the extent to which like, you know, sync, credentials, solve problems like that, like the extent to which that works immediately, like I get the division is for these as single factor credentials. But I think stuck in my head right now is just like, what value can I get out of it as an implementer? Like, I don't know, in the next six months.

Adam:

You can, uh, in fact, without doing anything at all already today, right now, your users should be able to like click register security key on your website and Chrome should offer, add a new Android phone and, and PS, like if you just might display that QR code and scan it with iOS 16, it works. Right. Um, so you should expect somewhere towards the end of the year, the word Android to disappear from that string in the Chrome UI.

Thomas:

Yes.

Adam:

Um, and that yeah, they can use, um, they can use that iPhone or Android phone as that. Worth keeping in mind. If you create a non discoverable credential on Android, it is not backed up. Whereas on an iPhone, all credentials are discoverable, uh, and backed up in iOS 16. So you do have to, um, think a little bit like if you set the required discoverable flag today, the Android phone stop working, um, that would hopefully be fixed when we launched the thing that we said at Google IO, where we demo credentials bought on Android. Uh, but like if you said six months, right. And if you're cast forward six months, probably all this will be together by then and working. So by carefully parsing your question, I think I've managed to find some way in which this helps you.

Thomas:

I, I feel helped that that all makes sense to me. Right. So part, part of my goal as an RP here is just to do, you know, kind of. Saying WebAuthN in a way that can take advantage of this when it's all working together. Right. There's, there's another big part of it where I need to rethink how people log in and, you know, have the, kind of the discoverable flow that we were talking about earlier work. And that's, there's UX work involved in that too. But, um, thankfully I don't have to do any of that work. So I just need to think about like what flags we're setting in, you know, WebAuthN requests.

Deirdre:

I just registered my thing with the QR code on github.com. It just worked. It was really easy. Uh, it was funny because it was Chrome Canary on Android that was asking me for permissions and stuff, not the other chromes that I have on this device, but yeah, it just worked for stable Chrome and a regular pixel, not a beta pixel. So, yay.

Thomas:

Yeah. I mean, to be honest, like the, the past key stuff kind of like when it was announced at WWDC or whatever was the first time I saw it, like my eyes kind of glazed over about it, like, okay, this is just like a, you know, an apple branding over web often, which is just U2F and I haven't thought about it. Like, it's actually super fascinating under the hood. This is all pretty neat stuff. Um, so yeah, I'm thrilled. I, I feel like I have a much better grip on what you guys are up to and, uh, it's cool stuff. Very neat.

Adam:

what it is definitely is super complicated. Like, hence the reason that we're gonna have to like go on podcast like this and talk about it and write lots of documentation. And like explain all the things that I said around our expectations of websites in ways that are written down. And you know, we're not relying on telepathy.

Deirdre:

Yes, because I was just try, because I had no idea about the noise tunnel stuff and I was trying to Google and grep, grep everything I could grep on the internet and I still can't get a hit on any of that. So if there, if that's written down anywhere or will get written down, that'll be super cool to have to point to

Adam:

It's written down in a literate Go program that implements the protocol. Unfortunately, um, it's a pull request in the Fido repo, and Fido is a closed standard organization. So until they publish a review draft, um, it's not anywhere I'm afraid.

Deirdre:

okay. Cause I, I remember all this stuff got announced and I was like, cool, I'm gonna go on fido.org and look up the technical details. And it's like, there are none. And then like I wandered over to the web off and GitHub repository and there were more, but that's okay if there is a public place that this will get documented in the future, that will be very nice to have. to, to wrap up Adam, how did you end up working on this? Cause I know you did curve stuff and you've done TLS stuff, and now you're like the WebAuthN person at Google or something like how did you end up where you are?

Adam:

So like, I don't know, way back when. I used to walk by the, AT&T building in San Francisco where like the first rumors of NSA tapping, everything

Deirdre:

I was gonna say it was at that one with the room where you're not allowed to go in because they split the fiber

Adam:

uh, it was that building. And like, yeah. So I read about the room and so forth and, uh, that seemed bad and unfortunate. And that is what sort of like kicked me off, uh, doing curve stuff and like deploying, uh, ECDHE on google.com and eventually doing BoringSSL and so forth. Um, and so that like kept me amused for some time. And then I think it was the John Podesta phishing. Right. That made me think, oh, okay. Um, maybe TLS is in slightly better shape than when I left it, but there were other security problems in the world. And so we should do something about that too. Uh, and it's been a few years, right? The John Podesta thing was 2016 and here we are six years later. Um, I guess stuff takes a while slash I'm slow.

Deirdre:

Well, it is a. Anything with the web tends to be organizational collaborative, sort of herding cats and getting buy-in not just anything technical or design-wise I guess. Um, that's cool. I had no idea about any of that sort of like motivation stuff. Like I, I, if I were to guess I would've guessed just sort of, like, I thought it was cool and I was interested in it, but, uh, yeah. okay. Anything else you wanna bring up before we, uh, we wrap up

Adam:

uh, no, I think that's everything. I think God help the listeners.

Thomas:

That's our, that's our podcast logline. So God help the listeners. Thank

Adam:

Yeah, you can make that the title of this episode, if you like,

Deirdre:

God help the listener. Uh, we have new merch on merch.securitycryptographywhatever.com. It's cute. It's also in colors other than black. If you like merch from the podcast, um, there is merch on the podcast. Um, Adam Langley. Thank you so much for coming on our little podcast.

Adam:

welcome.