The Future of Passkeys and Digital Wallets: From Authentication to Credential Protection [Introductory]

Hi, I'm John Bradley from Yubico and I also moonlight at Cirrus Identity. So, Cirrus started as a joint venture between research and education community for DC4UPilot and Yubico and a number of other participants.

So, we're the crazy people trying to understand wallets for the social good. So, I agree with pretty much everything in the previous presentation.

But, you know, I look at everything, you know, as most people know, I look at everything as a key management problem. If you look at any problem hard enough, it comes down to how did you manage the keys.

So, I'm going to take a look at this from some of a more, a bit of a more technical point of view, which will also reinforce why you probably don't want to be a wallet provider, at least for EIDAS wallets in the near term. You know, as somebody who's trying to be an EIDAS wallet provider, but at least we understand why it's a stupid idea. And why is there nothing on the...

So, I can see it here, which was what was confusing me. Okay, now we have it. Thank you.

So, we have, as I say, you know, we're trying to do it not to monetize users. We're trying to do this because we have a notion of social good. And we don't think that, you know, if you take a two-party model where the government is the identity provider and knows where you're using your IDs, like France Connect and various other EID systems. If you take that and break that up into a three-party model to protect people, having the government both run the wallet and be the issuer and potentially be the verifier, you haven't actually achieved very much. That you need separation of duty.

So, the person who runs the wallet shouldn't be the person who's issuing the EID, shouldn't be the verifier. So, we believe that we have to come up with a flexible wallet solution that can be deployed in areas where people don't even necessarily have cell phones. We started off from the proposition of how do students use a shared computer in a library? Because that may be the only computing device that they have.

So, we started off looking at it a bit differently from the other folks who, you know, Google and Apple look at it as a way of selling more phones, to put it bluntly. You know, the phone providers believe every person should have a wallet on a phone and if you want two wallets, you need two phones. And more phones, more good.

So, especially outside of Europe, probably there's more than one phone per person. I believe the statistic is actually quite high in Germany for the number of handsets that each individual has, but that isn't true in Gaza and Africa and various other places. And even those handsets aren't necessarily smart handsets that we're used to in Europe or North America.

So, we're also working on coming up with ways to, we have basic selective disclosure in MDocs. We're working with a number of groups such as Google with Longfellow, the German government PSI on PBS, one of the authors on the BLS signatures document.

So, we're looking at different aspects to figure out how to make wallets practical and scalable and capable of being instantiated on any device that the person might have access to. And to do that, we're relying heavily on standards. One of them is Fido pass keys, OpenID standards, OpenID for VCI, OpenID for VP, etc. And the great test suite that OpenID Foundation has developed, which is helping us get to some of this interoperability. Early on in the pilots, every country had their own non-interoperable interoperability suite, which absolutely drove us crazy.

And what we were expected to interrupt against changed every few weeks and had in a lot of cases, France had different requirements from other countries and even different large-scale pilots in different countries also had different requirements. So, getting down to a single interoperability suite that we can all agree on is a big benefit.

So, we also have ISO working group 10 from mobile drivers licenses, which there's harmonization stuff. We do have competing standards from ISO and OpenID and W3C at the moment. And there is work on trying to reduce the optionality that we have.

So, hopefully we can get down to a world where we have to support less things, which will make being a wallet provider easier. So, I want to talk a bit about some of the underlying principles of what makes a wallet. What makes this three-party system actually work and where some of our expenses come from.

So, we have issuers, wallets, and something that we don't talk about very often, wallet cryptographic devices. Remember, I said I was fixated on keys.

So, the wallet cryptographic device is where your keys live and are managed. So, in the great life cycle of credentials, a wallet decides it wants to get a credential from an issuer.

So, a PID. The first thing it does is actually talk to a wallet cryptographic device. There's a wallet cryptographic. There's WSCDs, WSCAs, probably all the gibberish that you didn't get, could never figure out from the ARF. But wallet says, make me a key pair. Cryptographic device says, okay, here's a key pair. The wallet then says, issuer, give me a credential. Here's the public key that I want it bound to.

So, you don't want, when this guy issues a credential, you don't want it being able to leave the wallet. The only place that can wield the credential towards a verifier needs to be that wallet that it was issued to. That's fundamental in EIDAS.

So, the issuer binds the key pair to the key that the wallet cryptographic device has. Then we start off with verifier requesting a credential. And to be able to present it, the wallet, oh, my slides didn't build properly. The wallet goes to the secure cryptographic device and says, okay, sign a presentation of this verifiable credential. It then goes back, that goes back to the wallet and it gets presented with the final arrow.

So, there's a bunch of interactions that happen here between the cryptographic device and the wallet. So, that WSCD for PIDs and QEAs needs to be Common Criteria Certified, EAL5+, which anybody who's been through the Common, how many people here have done Common Criteria Certification? My condolences.

Yeah, we all. It's both painful and expensive. The worst of both worlds. And the bigger the thing that you're trying to certify, the more expensive and the more time consuming. And this can take years.

So, as a result of that, I believe, I say that there are no phones in Europe that are certified under Common Criteria. That isn't strictly speaking true. There are two. Both models of Samsung phones that are super expensive and nobody actually has in their hand, unless you happen to be working for NATO or something.

So, there are no, at least there are no phones that normal people have that actually meet the requirement. So, you may have a secure element in your phone, but for the purposes of a PID, you can't actually use it.

So, what everyone in Europe is doing at the moment is using remote WSCDs. So, you buy, go to a vendor, Talus. There's a number of them, which I think is two vendors for HSMs. And then you find a billion dollars and you write them a check for several, many racks of HSMs, which you then rent a data center for. And you're into a fair, I'm sure that the German wallet team will be happy to regale you with the expenses that they are potentially incurring for scaling wallets.

So, it's really cheap as long as nobody actually uses it. So, ironically, EI-DAS wallets may be a victim of their own success that once you get enough of the population using it, the budget will run out and there won't be enough performance and then everybody will stop using it because they won't work anymore. It is a very real possibility.

So, in our wallet, so we are looking at, there is a standard that we've been working on in Sweden with DIG for remote WSCDs. So, we'd like to standardize that so that there doesn't necessarily need to be a one-to-one relationship between the wallet provider and the cloud security device provider. It should be infrastructure, you should be able to go to, you should be able to have an arm's length provider that provides the cloud infrastructure where you need it for that security device and be able to plug it into an arbitrary wallet with all of the security guarantees put in place.

But you shouldn't, the security device shouldn't necessarily have to be, come from the same vendor as the wallet. Wallet providers should be able to have a market of those things so that it's plausible.

And, you know, in some cases it may be that the government who's issuing the PIDs needs to foot the bill for the cloud HSM because that will be the most expensive thing. The wallet infrastructure, separate from that, actually isn't all that bad.

You know, there are costs and development costs like any software, but it's not mind-numbingly expensive. So, one of the things that we're doing is, because we have this widely deployed passkey infrastructure with the ability to do encryption, etc., we're initially starting off using passkeys to authenticate to the cloud HSM.

So, when you do your authentication to the wallet, you unlock your passkey provider, which then can be used to authenticate to the cloud service to do the cryptographic operations. Now, it gets worse.

So, you've gone and spent your billion dollars. So, this is a chart which somebody who works for a major financial institution who happens to have access to a lot of HSMs probably shouldn't have given us.

So, if you know your HSMs, you could probably work out which one it was by the performance, but I'm not going to name the company for their protection. So, over here we have the performance for RSA. The blue one is a local connection.

So, normally HSMs are used between a computer and the HSM in a data center. That's what they're designed for, but we're planning on using it from a mobile phone. How many people have tested HSMs for remote access from mobile phones?

Well, this person decided to, since they had access to a bunch of HSMs and a bunch of fancy software for analyzing performance, and the blue one is what happens. So, this is 2K RSA, 4K RSA, and ECDSA P256, which is the common signatures that we're doing.

So, you can get, I believe that the HSM is rated at 2,000. You can really get about 1,800 signatures per second, transactions per second, on a locally attached network. As soon as you go to 5G, that drops to about 500.

So, after you actually get your initial deployment done, you realize you probably needed to buy four times the unimaginably expensive HSMs that you originally needed, four times the data center, etc. So, we think that a lot of people will get to a medium number of, you know, start deploying and all of a sudden starting to hit with cloud HSMs. They're going to start hitting walls and needing to spend a lot more money to scale that infrastructure, if it's even possible.

So, the thing that's saving us now is that nobody's using it. If we're successful, this will be a problem.

So, you say, well, John, what do you plan to do about it? Well, the answer from my mind is it's a key management problem.

Okay, we got a secure device that is managing your authentication key. Let's move the WSCD into the authentication device so that it can both manage the proof keys for presenting your credentials and do your authentication.

So, when you go to present a credential, you have to authenticate. So, in that same operation, you may as well do the signature for doing the proof of possession.

So, you don't need to add complexity, have more operations. You can actually streamline it and do, instead of doing just one authentication operation, shipping it off, having it validated, just do it all inside that secure WSCD environment.

So, we're making our proposal and I already have security keys that actually do this. What we've done is we've moved the WSCD functionality so you can run your authentic, your cryptographic environment as part of the FIDO WebAuthn flow.

So, that then essentially means as you transition people using the wallets from using cloud HSMs into having their, essentially, their own cryptographic devices, you distribute the cryptographic devices super, it's way cheaper to give everybody a five dollar cryptographic device that they use in conjunction with their phone, can plug into their computer, have the wallet instantiated anywhere they happen to be, than to scale all of the cloud infrastructure. So, initially, our problem is going to be certification.

So, while technically we can, we have done demos, we do have the Cirrus software, which there will be soon. Ubico is releasing keys that support it. Cirrus is releasing a wallet that supports it. It's going to take probably until the cloud infrastructure falls over for governments to say, yeah, we should probably expedite the common criteria certification for FIDO authenticators.

Now, I expect that multiple, it won't just be Ubico that supports this. It's an open W3C standard. We expect that Apple, Google, Talus, other vendors that we've talked to will also incorporate that into their authenticators.

So, you may be using an authenticator that's built into your phone, but they can then get that common criteria certified because it's a much smaller boundary than trying to certify the entire phone. I'm going to quickly, in my final minute, as I see I'm counting down, I'm going to be hooked off the stage. In order to reduce the load for the issuers, right now, in order to prevent correlation, every presentment has to have a different key pair, has to have a different instance of your PID generated by the issuer, which is a big signing workload for the issuers.

What we're working with these zero-knowledge techniques in the wallet and even in the browser instances of these wallets, being able to do that, we may get an order of magnitude reduction in the costs for the issuers, which a lot of the governments are interested in. So, rather than issuing a batch of 10 credentials that can be used 10 locations, what we can do is cryptographically issue one, which can be used any number of locations.

So, you only have to refresh it once a week or once a month, whatever. The refresh timeline is you don't have to refresh it, get a new batch every time you run out of presentments.

So, we can both increase the privacy by doing things like range proofs and selective disclosure. Also, pseudonyms are going to be super important for anti-abuse.

So, some of these cryptographic techniques that we're working with a number of the organizations with will be very important to make the credentials actually appropriately privacy preserving and more useful in different situations like age verification. None of that stuff actually generates money for the wallet provider, which is why we're the crazy we're doing it for the social good folks. But hopefully, we can push this along and at least be a good example that other wallet providers and governments will follow. And I think I'm down to zero.

So,