# Passkeys : the good, the bad, the ugly by Nicolas Bacca | Devcon SEA

- Speakers: [Nicolas Bacca](https://streameth.org/speakers/nicolas-bacca)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 25:29
- Watch: https://streameth.org/watch/yt-TEjNSr8jjUI
- YouTube: https://www.youtube.com/watch?v=TEjNSr8jjUI

## Description

Passkeys are the new hype for easy onboarding, but it's a quite old protocol that has been hijacked for crypto purposes. We'll dig through the standard history, the potentially misleading security expectations, and see how to reverse engineer an implementation to validate its soundness

Speaker(s): Nicolas Bacca
Skill level: Intermediate
Track: Security
Keywords: Security, Account Abstraction, TEE

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] okay uh so Makai everybody uh today we'll be talking about pasis we'll be talking about security and memes as well so you'll see it will be entertaining I hope I'll be going fast because I have a lot of slides so don't sleep um so first you might be wondering what you are doing in this room uh why are we talking about identity and access management protocol Pho means fast identity online so why are we here it looks very complex server blocks client blocks a lot of stuff we don't do with ethereum but uh if we are dents like we all are we don't really care about all the part on the server we care about the fact that with pass Keys we can generate keys on a web browser and this is very interesting for us because we like keys of course um so next slide yes so if I want to go through a presentation of the pho protocol in one slide I would say that Pho is an Authentication Protocol uh you have a registration phase where you will create a key you will bind it to a web origin and then you have an authentication phase where you will get a challenge you will sign it and so you can verify that you are in the right place uh we have recent gas optimization that allow us to run the pho protocol on chain which is why it's interesting and there a lot of abstraction going in Pho so a lot of different implementation of this protocol going on um why this is interesting again we got a go tier ux on mobile with a abstraction with pass keys if you have not tried it already I will suggest trying the coinbase smart wallet which is very impressive uh but you get something that is very close to web to experience you just use your Biometrics and you are you have a wallet this wallet is self custodial so you can pretty much do whatever you want and well it's super it's super easy to create an account on mobile with pass Keys uh on desktop it's a bit different but it's standard as well so it's good because you have a common interface you have a QR you can redirect to your mobile uh if you have an Android phone you can just avoid scanning the QR every time you can scan it once and then it will be recognized automatically but it's proprietary so it's not a great interface but at least it's standard on all the implementation so you have a way to connect your desktop to your mobile and it's not too confusing let's say um regarding a web developer the experience is pretty standardized pretty simple as well because this was acquired by web 10 by the w3c sorry under the name web 10 so you pass common parameters when you register like the user information the key type the challenge so two API super simple I've been going through this very very quickly because we are not yet at the interesting part the interesting part is going to start now because you are all wondering where the key is stored we say we have keys but well where is it stored this is the real question and unfortunately to answer this we have to go through a very very large bit of History so I will be just doing this uh the pho story starts in 2013 with two protocols the universal second factor and Universal authentication Factor um Universal second factor is the best known and both protocol are mostly State class stateless meaning that all credentials are not saved uh in the device credentials are generated in the device saved on the server so the device can be used to generate an infinite number of credentials uh it was supported launched initially by Google and ubo 2014 this is a real commercial launch with two devices uh UB key and one device uh on which I worked on if you look at it you might recognize the early Ledger design very similar 2018 f 2 is launched pH 2 introduces something new it's basically a fusion between newf and UF and introduces a concept of resident or discoverable credential those credential are stored into the device so this completely changes the state of the protocol because now it goes State full 2019 Weber 10 uh is launched by w3c so it's basically Pho but acquired by w3c and at the same time on Android you have the strong box API which appears and it is the equivalent of the secure Enclave on iOS devices so very secure place to store keys and Android got pH 235 I think you are getting a trend there uh we get ios support in 2020 and we see that Pho starts to be supported in devices which are very secure so it all looks very good at the moment because we have dedicated device with secure Hardware to support Pho we have it in phones with strong security and in 2022 things start changing because we shared we get a shared announcement from Google Apple and Microsoft saying this protocol looks nice we are going to support it a lot more and usually when you get this kind of announcement it's the beginning of assimilation and this assimilation has a name Pas keys so well first thing we can say in 20123 it starts with uh the introduction of thinkable credentials um so show that can be synced to to different devices uh either with a propriatary scheme or password manager um so here's the illustration is a big Temple because we are in Bangkok temples are called wat so this is wat for I didn't visit it yet but yeah what uh and in 2024 the pho Alliance finally uh performed the general rebounding iron pass keys so no pasy is just describing a phyto credential and we'll start a specification uh to make the synchronization a bit less proprietary so we might ask ourselves what is a syncable credential because if we search for this in the documentation we won't find any reference to it uh that's because the proper name for it is Multi-Device credential so that's one thing and if we want to Define it we can say it's a discoverable or resident credential in the context of a smartphone but the only way to know if a credential is really um thinkable is to look at the answers that you get when you register it uh you will get a flag which is called backup eligibility if it's set to one then the credential can be synced so it's something on top of the spec not super easy to to to get the real problem starts now because we have several security misconceptions in Pho um the first one is that well Pho protects against fishing not malware so we can't really expect that Pho is going to be good to protect against malware but at the same time it is implemented on secure devices so we have strong uh we we we think that the key is going to be strongly protected because this is the way that Pho was defined then we can ask what is the consequence of introducing thinkable credentials to this and to get even worse when you look at the implementation on Pho by crypto people um we abuse it routinely because Pho is only designed for authentication when you use it to sign transaction we can't really verify what we are signing and if we lose a key the impact is going much more important for crypto than it is for authentication because you can always revoke an account and you can't revoke a transaction on the blockchain then Pho is designed to be bound by the web origin if we want to build a common web wallet we are going to break this property by Design so we have to hack around it but it's a hack around the specification and just to say that we have been abusing this protocol for a long time I'm not specially proud of it but just mentioning it I used youf to communicate between Ledger and metamask and sorry and my wallet in 2016 because there was no way to communicate because a browser between a browser and a USB device so it was used as a tunnel at that time short break maybe why secure Hardware is important secure Hardware is important because it will protect the key against malware any hardware does that but secure Hardware is supposed to do it better then it will protect the key against physical attacks physical attacks are the last line of of Defense when an attacker has access to a device you always think that your key is lost SEC is supposed to protect you against this but even more importantly secure Hardware will protect you against passive attacks passive attacks meaning trying to obtain the key by listening to what the ship is doing by listening to electromagnetic radiation power differences that kind of thing and the only way to really protect against this is by using dedicated Hardware because even if you use the best open source Library like lipc P 2666 K1 here um it needs to be customized to your chip to avoid leaking information so if you're not working with secure Hardware you're going to have problems that's basically you are just one speculation speculative leak away from losing the key for example so what is phyo security model for non seekable credentials they cannot be extracted by malware this is very important the authentication is always done at The Enclave level The Enclave is basically in charge it's holding the key it's doing the authentication if you want to do something with the Enclave you have to authenticate this cannot be bypassed so the malware cannot a very strong malware that manage to modify the canel of the device can fully into signing something but it would have to do it every time and it can't do anything else now let's think about some hypothesis for the synchronization the first one would be the good hypothesis in that case we think we imagine that there is a Hardware security module sitting at Google and apple and this Hardware security module is doing a synchronization protocol between two enclaves in that case the security model doesn't change the credential is never exposed everything is good at least it doesn't change uh now the bad synchronization hypothesis in that case the key is still owned by The Enclave but you have a way to put it into the application processor to start the synchronization mechanism in that case a malware could be able to extract the key but after prompting The Enclave to start the synchronization protocol and finally uh the ugly synchronization hypothesis where The Enclave might not even be used anymore the keys in the application processor everything is in the clear and then a malware could be able to extract the key and the malware doesn't need to be as sophisticated as in the previous cases and unfortunately the only way to know uh what the implementation is is to reverse it so we are going to do this uh first on iOS so iOS to do this we need to act as a malware iOS is a bit difficult to jailbreak as you know so I made a reference to a recent jailbreak to show you how complex this is uh but since we can synchronize uh we can jailbreak an older iOS device and see what happens so for that we are going to use the Checkmate bug uh which is quite powerful and allow us to break to jailbreak a lot of older iPhones I use P Rin for that but you might want to use another exploit it's a bit hard to run but well you will manage to run it if you want then we can D the keychain we have some information about the keychain at Apple uh but here the first first thing that we notice is that there is no security property that says that the credential needs to be authenticated every time it's basically authenticated at unlock when the device is unlocked and then it's not going to be locked again so we see a first problem here then digging into it dumping the kitchen itself we get more information uh we got a first uh attempt that was done on an older version of iOS a description of what the kitchen looks like uh we basically we have items in the kitchen which are um defined by a metadata and the secret itself the metadata and secret are W by a key which is handled by the platform so you need to have the device in order to deip this and you have an in you have an additional IND Direction level for metadata so you have an extra key uh which will be deied by the platform as well but the scheme is the scheme is always metadata in secret protected by a key basically so there is a small difference between two item version and basically uh knowing this you can fix uh what is on the internet today and you can make it dump um the recent items because protocol buffers is very easy to describe I mean it's self describing so you can modify this when you look at the decrypted item you'll see that the value the length of the value is 65 bytes plus 32 starting with 04 if you have played with key you think that okay this might just be the public key and the private key concatenated um you can verify it by dumping the key verifying that the public key Associated to the private key is the right one and it is the right one so this means we have a way to decrypt a malware has a way to decrypt the kit can steal it and it's fully unol by by the application processor on iOS um on Android we can do the same thing uh it's much easier to jailbreak an Android phone because you can just unlock the bootloader install magic and you're magist ma Magis and you're done and to look at the application we'll use a framework called Freda uh which will let us introspect the application and inject code to understand what um the program is doing first question it's very s it's very clear on iOS where the kitchen is on Android not that much so we want to know where we are and for that we are going to look at the logs we see that we see a lot of logs referring GMS for Google mobile services looks like a good place to place to start so we instrument it to instrument it we'll just use the signature API in Java and we will ask for the class that is being used because that way we can dig further and we can try to know exactly what is happening so we do that with GMS we see finally the name of the class and we can find some information about that class on the internet uh we see that it's a wrapper to another class so we still don't know if the credential is handled by the secure onclave or on the device but at least we can dig further so we start instrumenting again and this time we will dump the key so we will assume that if we have the right class we can cast it and we can ask it to Dum the key and it works so we can Dum the key we can Dum the key we can verify it's the right private key it matches the public key which means that on Android and iOS we have verified that the key is unol by the application processor as a bonus on Android so it's yet another yet another big wat here uh we get the key before the user authentication which means that there is a catch mechanism that is loading the key and user authentication is just there basically to make you think that it's secure but it's not really it's not really secure uh finally looking at an external password manager here we have absolutely no expectation um so it's good um I did the example with bit Warden you can see when you dump it that the credential is listed as a public key uh bad news it's not a public key of course it's a private key so we can just dump it look at it look at the private key verify that it matches the public key exactly the same thing so if you expected some security by saving your pass key to a passform manager you have known which is completely the expected result so to summarize this is where we are today on smartphones we have to choose between secure credentials or back synchron or backup credentials which might not be a right a good thing because you want both so the pass keys are under by the application processor it's there easy to extract by a malware when the device is unlocked and there are physical attacks applicable which is probably the worst part because something might be able to dump those keys at a later stage so user pres enforcement is not really linked to usage of the key and ninka pass Keys things doesn't change there they are still very secure so we can wonder who did we get there um one one way to say that that well we have conflicting rules between the vendors so Google says that you can inject a key into the enclave and apple says that this is absolutely forbidden you cannot inject a key Into The Enclave so this might be the reason why the Enclave were not modified and not used in that case and all agree that the key cannot be exported from The Enclave so that's another good reason why it's not implemented that way uh so Pho says Pho introduced um some Enterprise some difference between Enterprise and customer pass keys so this can be another sign that things are not get very very well uh if we wonder what will happen in the future it's not going to change much because here we have a draft regarding the synchronization protocol which is which does not describe how the key is used uh if we want to add a trust on core to the key so if you want if we want to link a device Bond Pass key to the key there were a few extension to do that and they were finally dropped and in the end well if we want a better ux for pasis um this is also going to be dropped so we had three possible Improvement protocols that were dropped so we can't think we can think that this is not going to change much uh if you are disappointed by platform authenticator you can always rely on external pasy implementations so I listed a few Open Source One the good news is that you can use your favorite hardw wallet if you want um the application is open source and you get a backup Pass key so it can be another option what happens on chain well I have one minute so maybe I will I will go over there very fast cartridge initiated the move on stocket so paskis are now very popular because we have been running several optimizations in order to be able to verify pasis and chain very efficiently uh I have a few canel I have listed a few canels that you can use to check to to use with Pass key so zero da safe core or coinbase smart wallet uh here's the main difference I will just look at who they using Pas key you make no difference with a common credential on zero Dev on safe core Pass Key are are supported but but discourage if you look at the specification safe core will tell you it's better to associate the pace key with a the pass key with a regular credential and if you want to run it on coinbase Smart wallet they support Pass Key they also support regular signatures and they will pumpt you and tell you yeah you might might want to use a recovery key so the answer to the maybe burning question should we should we drop P keys in my opinion no because they still offer the best way to onboard people but we have to think about the threat model and we have to code accordingly and one thing we can do since we have Smart contracts uh we can associate less privilege to pass keys that are not U that are syncable because since we know that syncable P keys are way less secure than pass keys that are handled by the device we can use them with kotas we can use them for example for Less M for less amount of assets and then we have something that is acceptable but the most important thing is to know the threet and act accordingly we are finished so I will just let you with one last meme for the road um this is the difference between 2014 and 2024 we get rid of password by storing in password managers might not be the best ID I will let you decide you can reach me on Twitter and there will be code on GitHub to describe all this so that you can run it on your own device and you can know if at some point the implementation gets better and well the less ugly solution for the synchronization is being picked thank you all right thank you so much Nicholas that was a very entertaining as well to see some memes on the slide so I really enjoy that um we do have a couple of questions for you I hope you don't mind so the first question is is bit Warden not safe generally or just for managing pass Keys uh so bit Warden is is he safe for password manager but you don't expect the same security to handle password and to handle keys so that's why I think it's important to store keys in Hardware because if you consider that a key is a password you lose a lot of security so bit Wen is reasonably safe for a password manager but of course you can extract anything you want from it because this is the way they work all right there's one that's not a question but thank you for making that Big W pun it was brilliant yeah thank you thank you next is do you think intentional intentional security lowering of the standard could be a dual I don't like oh yeah yeah yeah I see I see the reference so thanks for making it no I think it is sorry I got the direction wrong sorry so no no I don't think I don't think it is I don't think it was uh I don't think it was pushed by the government I think it was really Choice uh to make the ux easier and to make it well easier again to not lose private Keys um so the defin definitely is a fuse was a driver for that in my opinion all right and next question is what do you think of spending limits permission management what should I use as yeah so I think I think spending limits and permission management are definitely a good way to deal with that and what should I use as a wallet so I will just speak about wallet Frameworks so not necessarily not necessarily wallets but for wallet Frameworks any we framework that will support this is good so you can there are a lot of them I I Nam three of them and I think the three of them are good to manage pass keys and to manage additional permissions on top of them all right so there's four people who voted this well that was depressing what to do uh what to do not panic so that's the most important part keep using Pas key just think about using them well using them is knowing this and use them knowing that they are pretty easy to extract by mware if they are synchronized so just yeah it's not the end of the world we just have to be more careful all right the next one is Hardware UB Keys would be relatively secure yeah they are absolutely secure but using uh using your smartphone to store a key that will not be syn that will not be thinkable is also very secure but then you can't back up it so it's always a choice all right and next question is what are your what are options for non-s syncable Pass Key exactly the same you have to pass it as being non-discoverable when you create the key but you can use the smartphone and in that case uh you are on an old style I would say phyto credential all right and let me just check okay so next top voed question is do you think pass keys are easy enough oh it keeps moving do you think pass keys are easy enough to to use for normal users even as an advanced user I have sometimes lost access to pass key and had to jump through hoops to recover account yes I think I think they will be I think they are in in regular cases uh it might be a bit a bit rough on the edges at the moment because the protocol is still very new I mean pasy synchronization is only one years one years old one two years old uh so I think it will get better and ultimately uh all the all the big firms want to push it so it will definitely get better all right we have a few more seconds to answer this last question if you turn off uh syncing Pas keys on iOS are they safe again they are still on your device so the problem here is that if you if you created the pass key as syn cable and you turn off synchron Pass Key synchronization you get a pass key that is stored in the application processor and which is not synchronizable so basically you get the worst of both world sorry well actually we have a few more seconds maybe you want want to answer also uh what's the future of secure chip how do you feel Java card in general oh I hope there will be secure chips that are more secure more sorry more open in the future and Flash BS is doing a lot of a lot of research in that so it's good uh Java card is outdated uh that's one of the reason why I decided to start Ledger because I wanted to have U native code running on a smart card so that's my general take so I javac card is good as considering that the basically the only thing that you can can back