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.

---

This transcript has been edited for length and clarity.

Deirdre: Okay. Hello! Welcome to Security, Cryptography, Whatever! I’m Deirdre.

David: I’m David.

Thomas: Oh, why do you sound so terrible? I’m Tom.

Deirdre: And we have our guest today, Adam Langley, a longtime Googler who has worked on a lot of stuff. Hi, Adam, how are you? We’re very happy to have you on today because there’s been some news about new, less phishable credentials related to WebAuthn 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 Passkeys?

Adam: Uh, sure. Um, what do you wanna know? Do you want me to start my, like, I know how many minutes spiel?

Deirdre: What got announced at Google IO?

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 Security keys have long been able to do more than that. If you have a modern Yubikey, you can have a pin that you need to unlock it.

They can have fingerprint readers on them. They can in fact sort of skip over the having to enter a username part. You can just say “What accounts do you have 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. Multifactor was a sensible concept in the world where the first factor of the password was so bad. But if you do want to think in terms of multifactor, 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 support in the Android platform authenticator where, you know, an app or website can just say, sign me in. I dunno who the user is. Just do something. The Android phone can then pop up and say, here are the accounts you’ve got. Would you like to select one and so on and so forth.

Deirdre: Okay. So this is something 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: So what apple has talked about is somewhat the same thing. So they’ve used the word “Passkeys” as did we at Google IO. A passkey is a more consumer-friendly branding for a WebAuthN discoverable credential. If you ask Apple and if you ask Google, a passkey is sort of a synced WebAuthN credential. It’s a WebAuthN credential that’s reliable and dependable, and it’s always there. But we’re not gonna be syncing them everywhere. And probably the term will end up being, you know, a little bit vague. 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 WebAuthN credential, as opposed to not sync it, like what we have been doing since FIDO keys and previously UTF key pairs. We’re used to having them be 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, register both on every site you use and keep one of them in a fire safe at all times. Which is sort of both somewhat expensive for the average user and also really inconvenient.

Deirdre: I have Yubikeys all over my house.

Adam: Right, and do you remember which one goes where?

Deirdre: They all go everywhere, or I have to try all of them.

Adam: Then you’ve actually done pretty well. Um, but you know, if we are trying take it to the web and broader, we’re trying to take it sort of to the, to the wider space, to the regular person, 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.

So for, you know, for a regular person, we think syncing and backing up these keys is pretty good. Obviously that syncing has to be dealt with carefully. 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, if you have access to the sort of user’s email, then you can reset the password, they are in effect delegating their account recovery of the user to the email provider anyway.

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.

Thomas: Wait, is that actually true? I had, I had a different question. I was gonna ask, but the the thing you’re talking about is kind of fresh on my mind right now. So you just said that kind of in a lot of cases, morally, you know, account recovery means going back to the email address. That basically account recovery is verifying custody of a Gmail account. That’s how recovery works on most services. Right. And what we’re talking about is backing up second factor credentials, right? So I believe it is a norm for password resets to verify custody of the Gmail account. 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 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, I’m approximating in sort of like two dimensions here. The first dimension is simple access to the account is generally not enough to get access to the passkeys. So take, for example, Apple, who have made their announcement and it’s all public. 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. The second sort of axis 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. And the second one will be hardware bound to a given device.

Deirdre: I’m waving my pixel.

Adam: So yes. 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. 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, is like maybe a little bit closer to a reality.

Thomas: Gotcha. So I’m gonna be super annoying here, because I follow the stuff that we’re talking about with passkeys and with WebAuthN and stuff enough to sort of keep up with it. But my in my head intuitive understanding of security keys and advanced credentials is still stuck in the U2F era.

So I followed WebAuthN, to the point of, “Okay, it’s a better JavaScript API around U2F”, but it’s basically U2F. Right. 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 talking about things like discoverable credentials. 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. U2F referred both to a protocol between a computer and the security key, and it referred to a web API, which is now mostly gone

Deirdre: mm-hmm

Thomas: 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. 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 PostMessage. Firefox actually implemented it properly, but these days it is mostly gone. And it will be likely that even the hidden extension will be gone from Chrome come next year.

So this protocol between the computer and the security key. It was a very sort of straightforward wire protocol. 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 polled the security key for everything. 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 CTAP2, which is sort of the follow-on protocol from U2F. It’s a substantially more complicated protocol. It’s throwing CBOR messages back and forth. The security key, has to keep track of some state.

And as part of CTAP2, 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: We subsequently renamed that to discoverable credentials because the term resident key was super confusing, but discoverable credentials are just credentials that you can discover without knowing their ID.

You can just ask the security key, “What you got for example.com?”.

Deirdre: Oh!

Adam: If you have a modern Yubikey, it does that. Modern Yubikeys have storage. They have some kilobytes of storage and you can create a limited number of these credentials on them. And so that sort of steps up to like five years ago, when these sort of capabilities started to come to security keys.

Deirdre: mm-hmm

Thomas: CTAP2 is, I’m just gonna ask, you can tell me if I’m wrong. But like CTAP2 is the thing where the browser is talking to a USB key, right? It’s like a device driver almost, right? In my understanding of it, nobody really speaks CTAP except the browser and like Yubico or similar. 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 CTAP2, where they made everything JSON encoded in CBOR

Adam: Yep. 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 WebAuthN JavaScript API that I think maybe more developers are familiar with.

Adam: So the WebAuthN JavaScript API lets you create keys on and get assertions from authenticators, where authenticators are a sort of a more abstract concept, but they are generally realized as security keys. So the browser speaks CTAP to some security key to be an authenticator of some sort in the browser.

In some sense, it sort of does it itself on the computer. So Windows Hello is a WebAuthN authenticator, but it’s not a security key. And likewise, if you run Chrome on Mac, you can use Touch ID there. And now that passkeys come in, we’re bringing in phones as authenticators.

Deirdre: Mm-hmm

Adam: 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: I don’t know if it’s dozens, but it’s approaching more than one dozen. How does all 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 to log into accounts.google.com.

Adam: So, yes, you can do that on accounts.google.com. You can register your phone and it will send messages to the phone and you pick if it’s me or 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 message to your phone. And if you get confused and hit, yes, then that’s it. Whereas when it’s done with security key, right. Then the phone has to be close to the computer that’s signing in

Deirdre: mm-hmm

Adam: The second difference is that, Google has to know who you are before you can send this 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, sonic pingable proximity, that can talk to my user agent, the browser or whatever. And it can query it for Credentials for accounts to google.com or whatever other service it 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 literal plugging in the phones via USB, I don’t know if that will hang around. 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. So maybe it’ll hang around, but it’s super not discoverable. You have to click quite far down before Chrome will suggest that. It doesn’t work at all on windows, but even on Mac, you have to go through a few error screens before Chrome will say, “Hey, you know, you could plug your phone in over USB cable.”

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. But I would say without Windows 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 cryptographic challenge response protocol changed since the classic U2F days, or the Chrome equivalent of U2F, to what is being deployed for passkeys? Could you overview it for us?

Adam: The rough answer is no. And in fact, 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. The thing that has changed when you’re using a phone is just the transport. The way the data goes back and forth between them.

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. The, big question I had is when can I get rid of all my keys and just use my phone for all this stuff? I’m a relatively security sensitive user, but the security keys are silly. 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’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 de nouveu with nothing shared, the desktop displays a QR code and you scan that with the phone. The QR code contains a compressed P-256 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 to the laptop. 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 never worked right. With the diversity of different Bluetooth controllers and different phones and so on and so forth, sending the few kilobytes of CTAP2 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 “Hey cloud, I’m gonna be setting up a tunnel.” And then the cloud says sounds good. And then the phone will start broadcasting a BLE advert. And that BLE advert contains an identifier for its cloud server, i.e. who you woudl go talk to on the Internet in order to reach this phone. And a nonce. A thing that you need to have received to prove that you are close enough to receive this Bluetooth message.

Deirdre: And that’s every time that it is on and trying to be like, “Hello, I am a discoverable credential!”, and that nonce changes every time that 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 new. 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 “Please wire us together.” And then the laptop has to start off a Noise handshake to the phone.

Deirdre: Yep. Oh, nice.

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

Deirdre: Yep.

Adam: And it has to prove the PSK, which is drived from data 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: You get it by piping that through the HKDF and some other stuff.

Adam: Yeah, the HKDF brings in the secret from the QR code, the BLE advert, some context string and so forth.

Deirdre: Got it.

Thomas: So, okay. I’m following all this. This is super interesting, You’re using a PSK version of noise so that you can do effectively a channel-binding type thing. In this case, just proving the proximity, but you’re trying to establish a context between the phone and the laptop. Wireguard also has an optional PSK noise handshake, which I always understood as kind of a post-quantum deal there. Like, you know, the PSK part of Noise is quantum-resistant, and that’s why in my head I always had PSK noise 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, So the phone talks to the cloud, the laptop talks to the cloud, and 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 that?

Adam: That’s all correct. Awesome.

Deirdre: Awesome.

Adam: 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 been close to each other. The only data exchange was this QR code that was seen by the phone. And hence that goes into a PSK.

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 the laptop can’t guess the, the nonce unless it’s really lucky. It only gets one chance. But let’s assume everything’s happy.

Now we have a noise tunnel between these two devices over which they speak CTAP2. And the phone acts like a normal CTAP2 authenticator, and the laptop, just like it was talking to a security key, sends a discover credential request saying “what credentials you gotfor example.com?”

Then the phone will display on the screen the account picker and the user can pick one and then do their biometrics. And then back the signature goes.

Thomas: 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 like “Chromium knows how to do this?” This doesn’t sound like an operating system component. This sounds like the browser.

Adam: It’s Chrome right now on some platforms. But if you are running MacOS 13, then the platform itself can do this.

Thomas: The more important question I have in my mind, just cause I wanna be able to do this tonight, is that it doesn’t sound like I would need phone OS support for this. I could write an app that does all the stuff that we’re talking about right now.

Adam: That is currently true on Android, but we don’t want it to be true if that makes sense. 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 iOS.

Thomas: Ooh.

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

Adam: Right. The iOS 16 betas will do it. Android can do it today if you know all the secret ways to set the special flags. But we have not publicized any of that yet.

Deirdre: Makes sense. But it is coming. It’s already been built into iOS

1. 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, you can use a straightforward, normal Android device today, and it will work in the second factor mode. It’s not gonna do discoverable credentials, but you can go to Github today and go into settings to add a security key. And then when the Chrome dialogue pops up, you can say “Add a new Android phone” and it will display the QR code and you can 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 think github.com has been one of the best actual websites that I use that supports the most diversity of key pair credentials, including the one that’s stored on my secure element on my MacBook laptop. I don’t even think google.com or accounts.google.com does that nicely. Kudos to GitHub. I’ll just say that.

Thomas: Now, WebAuthN would call me a relying party. I’m a service provider. I need to 2FA authenticate my users and all that. Right. Like if I’m,

Deirdre: You are Fly, fly.io.

Thomas: I mean, I don’t wanna drop plugs for the company I work at. But yes.

Deirdre: Yes.

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

Adam: So mostly you don’t need a care and it’s standard WebAuthN. You can set the still-called “resident key” parameter in WebAuthN, which gets you discoverable credentials. You can test that today with a security key that support CTAP2. And it will, in some ways, just work.

The ways in which passkeys are bringing new things to the table are a few WebAuthN changes and then a few behavioral expectations on websites. So, all right, let’s talk about 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.

And then you can create a WebAuthN request and you set mediation: "conditional". Which is a field that’s been in the WebAuthN spec forever. But we are interpreting it to mean “don’t display UI”. And so you have this WebAuthN 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 autofill will suggest pass keys.

Deirdre: Ooh. Ooh. Okay. So now, either my browser that syncs credentials or has traditionally synced passwords but now may sync passkeys (such as Chrome or Safari or whatever), or the password manager in my choice, such as 1Password, can automatically autofill passkeys for me, in the same way that my passwords have traditionally been autofilled. Cool!

Adam: So if you’re using Chrome on Windows, we’ll get, credentials from Windows Hello. On Android, we’re gonna get credentials from there. You can sort of do this on Apple platforms as well. So that’s an example of an actual change to WebAuthN we’re making sort of to try and make the transition easier.

And on this 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. There’s a little field that says this assertion came from a cross-platform authenticator. The user did not use the laptop themselves.

And as a behavioral change, what we are expecting sites to do is see that flag, and then prompt the user and say, “Hey, do you want to register this local computer? Because then it would be easier to sign-in next time.” It will pop up in the autofill menu and all that sort of stuff. So there are both some tweaks to WebAuthN and the spec, and some sort of tweaks to the mental model around how you use it.

And when that all comes together with phones acting as authenticators and syncing credentials? That is in totality passkeys, but it’s a little difficult to explain.

Deirdre: Right. 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 web service that you’re trying to authenticate to has to set up something with phone? It doesn’t know much about you, it’s just operating as a discoverable credential device.

How does that work? So the web service has something in the cloud that these devices talk to as a passthrough to negotiate this channel? If I’m trying to deploy passkeys on deirdreconnolly.com, what do I deploy as a web service operator?

Thomas: You don’t need to. You don’t need to deploy any of that, right? The cloud stuff is, I assume Google provides something like that, right? Like it’s just a background thing.

Adam: Right.

Deirdre: Or an 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 a trick I haven’t 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. Don’t bother scanning the QR code. Next time you can just talk to this same tunnel server and go ask it to contact me.” And it knows how.

Deirdre: Uh-huh. Yeah.

Adam: So next time when you’re on the laptop and you want to use a phone, 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: Would you even have to unlock your phone or would it talk to github.com or something through the cloud and do the querying for you if it’s on and talking to the internet?

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

Deirdre: Okay.

Adam: 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, the phone owns its tunnel server, right? The phone always picks who its tunnel server is. If you are on an Acme corporation phone, it’ll be an Acme corporation tunnel service.

Thomas: Does the tunnel service protocol have a name?

Adam: It was called CaBLE for a long time, which stood for cloud-assisted BLE. That wasn’t one of my namings. But as you can imagine, it’s a little bit confusing to call it cable. So I think FIDO has decided it’s going to be called Hybrid, which is a suitably sort of like meaning-free word that could be stretched to include anything we want.

Thomas: Yep.

Deirdre: Yeah.

Thomas: So there’s gonna be Yybrid V2.1 and Hybrid V2.2 and we’ll all be this confused again in a year.

Adam: Probably we’re already at CaBLE V2.1 right now. That’s the thing that’s actually being used. So it’s gonna be called Hybrid and that word should be enough to encompass things like, even when we start to say “Can we get rid of the tunnel service and do everything over BLE, if there’s a lack of internet connectivity?”. We’re just gonna call that hybrid as well.

Deirdre: Okay. Yeah.

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

Adam: 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, wake up, 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 time.

Deirdre: Yep. Even though you only do 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: Sort of like a cached TLS session. It’s not, because you’re doing full Noise every time you build a tunnel, I assume. But it’s morally kind of the same thing as resuming 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 can remember and establish reestablished tunnels. The very important question I have is: Tailscale ran into a similar situation like this, with the need to kind of reliably bring up tunnels between people that didn’t have direct connectivity.

And they came up with their own protocol called DERP, and one of the great things about DERP is that they don’t really control it. Like they run it, all the servers are theirs, but anybody can establish a DERP session. They can build DERP tunnels between each other. You don’t even have to use it for Tailscale.

You could do anything you wanted over them. Can I do that with CaBLE? Can I build random tunnels between different pieces of software with CaBLE servers and then use them as a message exchange?

Adam: So the protocol between a CaBLE server and the outside world is public, but the protocol between the server and the phone, does not have to be. That can be a completely bespoke protocol because the tunnel server and the phone are both run by the same entity.

They can authenticate each other, and talk whatever weird thing they want to. So in general, the answer is no. Gotcha.

Thomas: Gotcha. So the, the phone to server, the phone to cloud end of this is essentially proprietary. And like you were saying before, the ACME phone is gonna talk to an ACME CaBLE server or whatever. And what you’re really saying there is that whole part of the picture, the phone and the CaBLE server, all that, each of those is vendor 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. 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. The total amount of data exchange there with this tunnel is capped really low purely because we wrote it with people like you in mind, Thomas, and thought “How are people gonna abuse this?”

And so all the limits are in there to make it really, really awkward. And I’m pretty confident that if you need some sort of reflection thing in the cloud, DERP is going to be way more convenient for you. We don’t have to be perfect. We just have to be like less convenient than DERP.

Thomas: You just need to be tighter than DERP. Yes. Okay. That was my question. It was well answered. Thank you very much.

Deirdre: Going back to, operating on Android at least. Can you get discoverable credentials from another Android app? Could custom idp.app provide a credential? Or must it come from the OS or whatever?

Adam: Today, it must come from the OS. 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 providers of passkeys, in the same way that they can be providers of password.

Deirdre: Yeah.

Adam: Yep. We’d like that to be true. I have nothing to announce specifically today. 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 1Password or other credential syncer manager that I am running to. I am running a Pixel over here and a MacBook over there and probably some weirdo Linux machine over in the corner. And the only way that I can sync my credentials and other things across all of them is a independent credential syncing service, which in this case is 1Password.

And it would be great if I could also sync discoverable credentials with 1Password, especially on my Android phone.

Thomas: And the reason that 1Password can’t just go freelance this right now, 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 revolves around a BLE exchange somewhere, that we’re picking up and using the key from in 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. And that’s a limit enforced by the browser.

Basically like the browser just knows how to do that, or the platform. Either the platform or the browser, or whatever’s doing the kind of the laptop side of this. The bits are there people doing random stuff, but they have to be able to pick up BLE advertisements.

Deirdre: The scenario that this would happen in is: say my syncing was broken for my 1Password, 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 1Password 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 1Password client that is on my desktop.

And I want my desktop to talk to a local copy of these discoverable credentials. Whereas the first scenario, the classic scenario that we already discussed, I can understand why that would be harder, but also could want to do that.

Adam: So 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 an account on a website only has one password. But it has multiple passkeys. And so you end up with passkeys for the ecosystems that you use.

To answer Thomas’s question, 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. So in some sense, you can do that today. What’s gonna be awkward, is that apps on Android, including Chrome when they do passkey operations, are going to call into Play Services to do that passkey operation and Play Services is not going to know anything about any other app on the phone today.

Deirdre: Mm. Besides the one that’s “built” into Android itself.

Adam: I mean, it is Play Services itself.

Deirdre: Cool. Just because I know that everyone remembers the classic, what you do with those keys when you are trying to log into an app, BLE or not, discoverable credentials or not. 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 keys?

Adam: All right. So the sort classic WebAuthN protocol. Assume it’s second factor because everyone’s familiar with that. You’ve entered your username. You’ve entered your password. The website, mostly knows who you are and is just double checking. Now it calls WebAuthN and says here’s a random number, and 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 it. So we call that the challenge. The website also provides the IDs of the credentials that you have got and registered. Because 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 that Thomas has registered and and here are their IDs.

And so we are gonna stuff that in there as well. And then you say to the browser, go do stuff. Then the browser is going to pop up and say, “Hey, please touch your security key or insert it or whatever” or you know, use your phone. 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.” I know I use my AEAD to open this credential ID with my global secret key, and it authenticates correctly and I get a plaintext and that plaintext is a seed, which I can then use to generate a private key. 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 a lump of JSON from the browser.

So the browser will put a whole bunch of context information into this JSON 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, and the signature from the authenticator.

Okay. So the security key exercised somewhere in the world. It knows that this browser believes it’s on this origin. If the origin is not right, then that’s concerning. It knows a bunch of other context stuff, like what does the browser think is going on? The browser says, “I think this is a registration”, or “I think this is a signing operation”.

So all sorts of context to make sure that everything is as it should be, and what the website should know from that, is that the user very likely wasn’t phished because the user didn’t type any secrets in. The browser put the origin in there. The browser sent a hash of the origin to the security key. The security key shouldn’t have even done the operation if it wasn’t on the right place.

And if it’s hardware-bound, yeah. 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, the security key will put a bit in the thing it signs saying “Hey, I actually did a fingerprint or 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 attacker.com. 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. And if you are like subdomain.attacker.com, you can claim the names, subdomain.attacker.com or attacker.com, but not com and not example.com.

The browser is not going to let you claim any of those. The security key is going to make sure that the credential was registered with an identical RPID value. So the credential ID is useless if you cannot assert the exact RPID that it was registered with.

Deirdre: Got it. Mm.

Adam: Additionally, as I said, the browser is going to put into this JSON blob the actual origin that is being used to do this assertion. So, subdomain.attacker.com. As I said, it can claim the RPID attacker .com. And maybe accounts.attacker.com actually registered some security keys for real. Not being malicious. That other subdomain could use those keys because it can assert the RPID attacker.com. But additionally you’re going to get the exact origin back from the browser. So there’s two levels of checks. Does the security key even allow this at all? And if it is allowed, what was the actual origin used, and then the server can check it was used on the origin it is expecting.

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 DNSSEC 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 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 key gets the hash of the RPID.

Deirdre: Got it.

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

David: Okay. So that’s how WebAuthN works today. How does that change with passkeys 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 passkeys, things are all mostly the same. The only difference is you don’t have to send down a list of credential IDs. You still can if you want. So if you are in a context on the website where you are reauthenticating a user, where you kind of know who they are already. They’re still signed in, but it’s been 30 days or something or whatever, and your policy says we need to reauthenticate. You can send down the list of credential IDs, because you already know who the user is. But you don’t have to. You can just send an empty list, which is the indication of “I don’t know who this person is, surprise me.” And so in that configuration, this isn’t new to passkeys, this is just discoverable credentials.

It’s been in WebAuthN for years. So in that situation, the website gets all the same information back again, as it did before. But it doesn’t have to send the ID in the first place. It just gets to 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.

So that’s sort of the main change when you’re doing a passkey flow. There are other changes around, as I mentioned, doing autocomplete rather than necessarily sort of doing an explicit model WebAuthN operation. 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 the exact same stuff, but signed with this public key.” And if you’ve seen the public key before, great. Maybe you have some like historical records of this device, or maybe it’s a brand new device. Maybe you’ve never seen that key before.

Thomas: So for non device-bound keys, thinking only about new, modern, passkey-era WebAuthN credentials, the non device-bound credentials are essentially all as secure as Google’s IDP, right? As whatever their root of trust is for, you know, storing credentials and stuff. So like the, when 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. They’re just going to do WebAuthN and it’s all just going rto work. And we’re going to be at a place where most common MFA credentials are recoverable from your cloud provider. Which, as you said earlier, it might sound a little scary in that kind of the whole point of doing multifactor authentication is not having things come down to an email account root of trust. But really what we’re saying is we’re delegating to Google or to Apple, the job of recovering accounts.

It’s not that just having your email account gives you immediate account recovery, It’s that, Apple and Google we will trust to run an actual, account recovery process and that you have to deal with them. A process that’s more than just having access to your email account. And so we’re, it sounds like we might be heading towards a world where having to send notarized affidavits to 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? Because the majority of websites are like my local paper who maybe wants me to sign in to read the paper or something. But 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 thing and decide what they think about it without trying to project it into how it fits in a multifactor world.

And does it sort of meet those requirements? I don’t know, if you’re a website, maybe you decide it doesn’t and that this is interesting, but it’s only one step of your sign in process. And okay. Obviously, we want to try and solve passwords, and you should keep in mind, plenty of people have said that over the last decade. There’s a big pile of corpses labeled, “tried to get rid of passwords” and we’re just like hurling ourselves towards it. If you said, I think, in three years time, you’re going to 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 try and paper over their flaws. 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 an implementer at a relying party, I have a diverse set of different customers with different stacks. I can’t assume that I’m gonna be able to use like passkeys for passwords. Like the whole stack that you just described.

Like the whole vision. I can’t assume that I’m using passkeys as single factor credentials that replace passwords like tomorrow, or this year. Right. It’s just my users won’t support it. But I do need to do a sane, modern, second-factor credential thing that isn’t TOTP or something like that? My users do have like immediately the problem of if they’re using a physical device, like a security key to do this, then they have to have a key chain of security devices or security keys, and it’s a whole mess. So the extent to which credentials, solve problems like that, and the extent to which that works immediately. Like, I get the vision 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? In I don’t know, the next six months?

Adam: You can, 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 PS, if you display that QR code and scan it with iOS 16, it works. 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: 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, and backed up in iOS

1. So you do have to think a little bit, like if you set the required discoverable flag today, and the Android phone stopped working. That would hopefully be fixed when we launched the thing that we said at Google IO, where we demo credentials synced on Android.

But 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 in that all makes sense to me. So part, part of my goal as an RP here is use WebAuthN in a way that can take advantage of this when it’s all working together. There’s another big part of it where I need to rethink how people log in and have the discoverable flow that we were talking about earlier work.

And there’s UX work involved in that too. But, 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. It was funny because it was Chrome Canary on Android that was asking me for permissions and stuff, not the other Chrome’s 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, the pass key stuff when it was announced at WWDC or whatever was the first time I saw it, my eyes kind of glazed over about it. Like, okay, this is just like an Apple branding over WebAuthN, which is just U2F and I haven’t thought about it.

It’s actually super fascinating under the hood. This is all pretty neat stuff. So yeah, I’m thrilled. I feel like I have a much better grip on what you guys are up to and it’s cool stuff. Very neat.

Adam: What it is definitely is super complicated. Hence the reason that we’re going to have to go on podcasts like this and talk about it and write lots of documentation. And 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 had no idea about the Noise tunnel stuff and I was trying to Google and grep everything I could grep on the Internet and I still can’t get a hit on any of that. So if it’s there, if that’s written down anywhere or will get written down, that’ll be super cool to have and be able to point to.

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

Deirdre: Okay. Because 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 there are none. And then I wandered over to the WebAuthN 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.

Deirdre: To wrap up Adam, how did you end up working on this? 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: I don’t know, way back when. I used to walk by the, AT&T building in San Francisco where 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: It was that building. 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 ECDHE on google.com and eventually doing BoringSSL and so forth. And so that kept me amused for some time.

And then I think it was the John Podesta phishing. Right. That made me think, oh, okay. 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. And it’s been a few years, right? The John Podesta thing was 2016 and here we are six years later.

I guess stuff takes a while, slash I’m slow.

Deirdre: Well, it is hard. Anything with the web tends to be organizational collaborative, sort of herding cats and getting buy-in, not just something technical or design-wise. That’s cool. I had no idea about any of that motivation. If I were to guess I would’ve guessed I thought it was cool and I was interested in it.

Anything else you wanna bring up before 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 you.

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

Deirdre: God help the listener. We have new merch on merch.securitycryptographywhatever.com. It’s cute. It’s also in colors other than black. If you would like merch from the podcast, there is merch from the podcast.

Adam Langley. Thank you so much for coming on our little podcast.

Adam: Welcome.