[BUIDL ASIA 2024 Builder Stage] Passkeys, Biometrics for the next generation of wallets, the Good...

Transcript

hey guys how yall doing on a nice Soul morning or afternoon at this point in time hope you guys had a good lunch um I'm Zen I want the co-founders wether off and here today I'm here to talk about past Keys just a quick show of fans who here knows about past Keys already and kind of like familiar with it and more or less most of us over here and um who's also familiar with like a c abstraction I imagine most people also kind of like familiar with this as well fantastic fantastic so um today I'm going to be talking about past keys and uh how you can get that user experience through account abstraction and integrating that with smart Wallets on ch um the we're going

to everybody kind of knows what pass keys are um they basically have a fantastic user experience on um on uh on desktop as well as Mobile in that especially if you're in the Apple ecosystem uh it just kind of works with Touch ID as you can kind of like see here um and then you can log in and you can access it's a form of authentication that allows you to access more stuff now in web 2 um pass keys are typically used as a second factor of authorization uh and in but in web 3 people have been experimenting using it as a first factor into different wallets and different accounts and to help you

hold and manage a crypto um because pys have nice properties that will go into a little bit deeper um so uh it's it's it's popular it's not just uh in web 3 that pasis are popular it's a pho thing which um it's a it's a pho it's it's a it's a standard that's being pushed out by the pho Alliance which means that large Brands like you know Apple Google uh Microsoft are all implementing it in some ways and forms um and today what we're going to do is we're going to go through first off uh a little bit more of how a py construction might work with account obstruction we'll go through a little bit of just uh exercise of just

architecturally how it works and then we're going to go into us as web through office a w as a service um in in in the ecosystem we've been powering quite a few of these py experiences on different applications so we're going to be going through some of uh the Goods the bads and uglies of p keys on these different applications how have the experiences been has it been perfect in production or not uh and so on so forth so first off this is what a past Keys architecture looks like um this is just stolen from the weth and site right uh and I'm just going to walk through

this super quickly right so pys have three main well realistically actually two main stakeholders it's really really just the relying party sver and then the end users device but the end users device can be broken down into two different components the browser and then the authenticator the authenticator the browser is is your browser everybody's familiar with that the authenticator though is basically an implementation and it can it's agnostic and how it can be implemented but an implementation of a storage mechanism that houses a public private keypad and this public private kead has several different forms you can use p255 or you can use SCP 256 uh R1 but you cannot use

SCB 256 K1 uh which is the um which is the litic cve that ethereum and Bitcoin and many other popular blockchains typically use so although we can sign signatures and authenticate with keys it is specifically not compatible with uh with with with ethereum natively or any of that right um now if we walk through the flow the authentication flow is really quite simple uh the Rel the relaying party server which you can think of is a normal dap or whatever uh issues a challenge this challenge is then uh relay to the users browser and the use

client side it's relayed down through an the web auth API um into uh the relaying parties uh authenticator the authenticator basically signs creates a new keypad necessary uh if it existing keypad just basically signs and then you have your new public private keypad and credential ID and then uh they just relay this information including the signed attested object back to the relaying party server and then at step six the relaying party server basically just verifies that so how might we combine this with account abstraction how might what would um a straightforward way of doing so

would be because we can't just rely on that signature because it's on a different curve type so how might we integrate it into um a onchain smart contract which verifies it uh this is kind of off the top of uh a a kind of a simple implementation right a naive implementation rather bit and um everything's the same from step one all the way down to step six right however after step six um instead of just verifying it on our server and just keeping it there we then relay this same signature on chin and then we either do a user op or just have a verifier on the

smart contract level that verifies SCP uh R1 signatures um and uh and we just verify the contents of that signature uh as kind of a user wish to interact of something and we're done and that just kind of allows um pys with some form of onchain verification uh to indicate user operations now this is a naive implementation um can anybody spot what is wrong with this implementation we just naively do this if we just sign for example if we have a if the if the challenge that we're

issuing is something like hey I want to send 10 usdc uh to xXx wallet uh and we sign on that on the hardware Enclave in Step 2 through 4 and then we relay that onchain and the onchain uh the onchain smart contract verifies that signature to send 10 usdc can anybody SP what is wrong with this very naive implementation uh okay so uh in particular um in particular the main

problem with just signing something that's like saying like hey I just want to give 10 usdc to Bob for example is that um uh is that the the SCP R1 signature now replicates a user intention to do something and if the signature object indicates the user attention to do something and this signature is onchain and uh in the in public um it's a very uh you you basically become susceptible to replay attacks right you um you you become susceptible to replay

attacks in that uh in that like um for example if I want to send 10 usdc to Bob um and and and and Bob chooses to receive 10 usdc i i as Bob can go onchain get that signature that you already signed and just infinitely Replay that to instead of getting $10 get $20 $30 $40 $50 um uh now how do we fix this does anybody know no anybody care to take a guess can be anything how do we fix this renty attack

or this replay attack fres Cheng sorry prast fresh challenges yeah that that that's uh that's that that is the way to do it um fresh challenges are basically signing on something fresh each time which can be a Nots and incremental Nots right so the smart contract level definitely needs a Nots that constantly increments on each user op um and uh so that each signature is only ever valid once on chain and can only ever be propagated once ultimately now um so that's a nice way of implementing uh pass keys on account obstruction this implementation kind of

roughly works there a lot of nuances to think about like what consists of these up how you register what an interaction is how you make it generalizable instead of not um and they fantastic implementations of p keys on chain on GitHub uh Doo is one of them that's definitely great um along with a couple of others and uh and if you guys want to dig in deeper there uh however now I'm going to share a little bit more about um our experiences with p keys at web off and with applications that have kind of integrated it um the good of p keys has definitely been that applicate uh users are becoming more and more

comfortable with it in this room uh you know about 60 to 70% of people you all of you knew what P keys were and P keys is just something that came out like you know February last year so it's been barely out um large companies are starting to implement it we're starting to see it across the board on on for example on Google logins on Microsoft logins on Apple on GitHub and so on so forth so everybody is getting more familiar with p keys that's for sure the user experience is also great and pass Keys is almost kind of like a non-custodial authentication or a touch on that a little bit more but like using Touch ID to access uh access something instead of having to enter your password

and constantly is a fantastic user experience as well as the fact that you're using a public private P had to sign on your behalf is great in terms of security as well um what we've seen is that with have seven different apps that have integrated pass Keys uh with web through off um and that we looked into uh pass Keys typically see a 57% conversion rate meaning somebody who starts the pass key uh goes on your site chooses Pass key right completes the past key experience 57% of the time which and and it gets access to which is better than seed phrases seed phrases and metam mouse tend to be at about 20 to

25% um but it's not better than like your standard Google Apple login just yet standard Google Apple login typically see conversion rates at about 60 to 70% depending on the application but these are definitely a lot of the good things which pass Keys have going for it the bad is that we've actually found that users lose pass Keys um and this is is not a small percentage of users uh this is like above 1 to 2% of your user base will lose their P key within a month or two months at this point in time um uh the reason being reason being most Apple users actually have a very

very good experience because Apple is very much kind of like a close ecosystem of safari everything works with natively on your iPhone to your Mac but if you are are crossplatform um if you're doing for example um if you're a chrome user on Mac or Chrome user on iOS if you are uh Android and you're using Safari for example I don't know for what reason but if you are um you you face a lot of compatibility issues um sometimes you can't the users can't see the pass key sometimes they don't know where it is uh they can't retrieve it back um all the versions of Chrome and all the Android

versions uh because because you know iOS forces you to update each and every time it's a little bit pis work typically more there but Androids tend to have a longer and wider version spread across uh different phones um and because of that sometimes pis are not just support are just not supported sometimes when people there there was one bug where somebody erased their passwords like removed their cash and then the pass Keys disappeared as well and and Theos were removed right so users like this will improve as time goes on I have the absolute confidence that it will improve but if you're implementing something within the next two to three months and you're looking

to implement P casys I would highly uh consider I I will highly consider that right um there also uh just extra costs for interactions and onchain verification um uh with some of the new upgrades and some l2s it's a little bit it's it's much better now but before that on polygon it would cost about 12 to 15 cents per signature verification and use all um so that is an additional cost that you would have to bear uh now so the bad was a little bit more on the lowlevel stuff right on the high level stuff is the ugly right what's pass keys look great on the onset but what what the problems with its

implementations um so number one pass Keys weren't uh okay so the first thing is that um P keys is for those of you who have been following the authentication standards is actually an evolution of web Oren which was a FAL standard before which was basically public private keypads on your Hardware Enclave on your phone that is used to sign and authenticate users um however pass Keys evolved on web and pass keys are now actually backed up on keychain or iCloud and similarly on Google it's backed up with your Chrome with with your Google

account essentially p uh web then or in its initial implementation of pis pys used to be non-custodial because it's on your Hardware phone it's on your it's with you it's physical but now because people want greater access more usage um the standard of p is allow for it to really be backed up on the cloud and what that means is that you know we are just basically uh increasing our dependency on Google and apple that's fine for most cases I think a lot of people don't really care about that that's just not not not the nicest thing right not the not not not not not what it was set out to do initially the second thing is um the web off end

standard and pass cues equivalently require a a application specific server to issue the challenge meaning that if two people set up two applications ask you to set up a pass key um the both applications have application a has Pass Key a application B has Pass Key B application B can't see Pass Key a and application um a can't see pasy B so it's application sculpt and the reason why that's the case is for security purposes um it's for user privacy purposes and so on so forth but in web 3 what this means is that if your you have

your account abstracted wallet right um and it's dependent on a particular signature a particular Pass key signature if the relaying server goes down and can no longer issue your browser challenges right you just no longer can sign and no longer can access uh your wallet um and that's um another risk of basically if if the DAT goes down you won't be able to access your account abstracted wallet so given some of these implementation limitations we have some recommendations right uh and uh by no means are these set in stone but we do

recommend typically um implementing Tas keys not as the sole factor to your account abstracted wallet as one of the factors yes as a nice usable Factor absolutely but as the only Factor would not recommend it because that just means that 2% two to 3% of the users will lose their keys in two to three months at this point um we also recommend doing it as a lot of the web um to folk if you guys have logged into GitHub recently l or log to Google recently ask you to set up pass keys or binance you know um it's a standard login initially and Then

followed by pass Keys as a second factor to access your account uh and that gives you the best of both worlds because if you lose your past key you can still fall back to that previous account last but not least we highly recommend that you restrict um we highly recommend that you restrict your implementations to specific OSS and browser uh types so if you're on iOS only allow it on Safari if you're on Android only allow it on Chrome and Edge if you're on Windows similarly so um this is because you uh P keys also have a lot of red routes in the uiux like sometimes it presents to you a nice

screen to select that but sometimes it asks you to like like like put in a security key like a UB key um so there are red routes especially when the browsers can't detect the OS level capabilities um and the OS level authenticators so we highly recommend that you restrict it to for example as I said Safari Mac Android Chrome and that's about it so that's all for my presentation um I can take a couple of questions if I have time absolutely thank you so much Zen um if someone in the has questions but yeah Hi how are you doing hello I'm good um

I'm really sad to miss the first part of the talk but I'm just wondering that I'm not sure why we have to use the relayer servers to create the challenge because um what if we can just use the hash of the message on the challenge like the api. incode pack what user want to do so the main thing restricting that is uh you can actuallyit the challenge there's there's a whole bulk of things that you can edit in the challenge but um the thing issu the challenge is specific is specific to domain so the web auth Ander API that's implemented on let's say Chrome or Safari or whatsoever basain

yeah URL specific so if you just issue it from another domain you just can't access the same set of pass Keys that's it it's just it's implemented on the browser level that's the Restriction m I see thank you thank you are there any other questions if not you can reach out to me here on Twitter and um our P keys module and SDK is currently in Early Access we have uh seven daps already building on it but it's it's it's actively getting more mature and we'd be pushing it out um we'd be looking to actively push it out more if you guys are keen on building P keys and keen on on improving your user experiences do let us know I

would love to work with you guys thank you