The challenges of non-custodial embedded wallets
DeFi Security Summit 2024 · 9 Nov 2024 · 12:02
Thibault de Lacheze-Murel of Dfns explains how non-custodial embedded wallets give email or passkey onboarding while keeping ownership and decentralized trust. He covers the common designs, including Shamir secret sharing and multi-party computation with a key share held in the browser, and the recovery flow used when a user changes device. The talk then points out the security risks this creates and the mitigations open to wallet providers and dApps.
Speakers
Topics
From DeFi Security Summit 2024, hosted by DeFi Security Summit.
Transcript
can you can you hear me okay yeah uh yeah so I'm I'm tibo and today I'm going to talk about um embedded wallet security so uh what is an embedded wallet uh the goal of uh embedded wallet product is to improve the web three onboarding experience um to like remove the friction of having to write down a list of word and like secure it in order to secure your phone and instead to um like get closer to what we have in in web2 which is you can um create a wallet by click of a of a button and you can like recover your account uh recover your wallet if you
lose if you lose your credential but we we still want to have the web three guarantees which is like ownership creating non-custodial wallet and decentralized Trust so in term of um of UI um you we we start to see more and more on decentralized application so it's like whenever you click the like usual connect wallet button you have like your metamask open Wallet wallet connect experience and then we start to see like enter your email to create an embedded wallet or like just scan your face uh scan your fingerprint and uh you're going to be able to create a wallet so
that's that's the experience that you're exposed to when you uh go through the embedded wallet flow so how is it implemented um most of the time for the decentralized trust you have some cryptographic protocol like Shamir secret sharing or multi party computation where um the private key uh doesn't live in one place but instead you have multiple key Shar that are used to perform a valid signature and uh we also see like more and more pass keys uh that are used in order to create um embedded wallets so for ownership whenever you have like Sam secret sharing or multi party computation I
mean not always but usually you have like one keare that is push on the client side and that lives on the on the browser local storage another type of implementation that we see is um you have like the anent private key that is decoupled from the credential uh that you use in order to interact with uh with your wallet and that creates like a dual security layer or we also see a mix of of the two where you have like some client credential that are that does not represent the onchain private key but that are used to unlock some specific onchain operation that usually require some like specific or blockchain protocol um yeah some support at at the uh blockchain
level um the star folks are doing some great things about that so you should um talk with them if you want to learn more about it um so how how does that look um usually when when you have like um the embedded wallet experience you have three parties you have the clients that interact with the DAP and then whenever you click like the connect wallet button you're going to interact with the embedded wallet provider which is another party so as a user you're going to authenticate to the DAP it's us usually like a standard web to Authentication and whenever you click the embedded the connect wallet button you're going to like the user experience
of the embedded wallet is going to be uh loaded um through an iframe or through or or or through a new um a new window and uh you're going to be able like to enter your email authenticate with the embedded wallet provider and then create a wallet and and you going to have a like a local share that is generated on your on your local browser um and then you can leverage that to perform a signature uh in addition to that usually uh we see an implementation of another flow at the same time which is a recovery flow implementation and so it's used to like recover access to your wallet in case you lose your credential or in case you uh like change device so
like if you go from like desktop to mobile since you have a share that is like generated uh locally um um when you go to another device you don't have this share anymore so you need a way to like recover access to your wallet so how is it done uh what we've seen in production is that um during the wallet creation you have the embedded wallet provider that's going to share the authentication token with a decentralized application this will usually be set as a as a cookie and uh so whenever you you change uh uh device uh you're going to authenticate with the decentralized
application and then the decentralized application is going to return the embedded wallet authentication token that's fine you're going to use this token to authenticate with the wallet provider and then you'll be able to like generate a new uh like perform a key share refresh and generate a new um new shares and so get B get access back to your wallet okay um that looks fine but if it's not done properly this can create some issue so as I said you have two step you have like the embedded we provider that's going to share the authentication token with a decentralized application and by the way can you see all the text oh yeah okay
that's fine uh and then you as a client you're going to use this authentication token to authenticate with the embedded wallet provider and then uh like perform a key refresh and and get back into your wallet so uh if it's done just like this the first problem is that the embedded wallet provider is going to share an authentication token with a decentralized application and this authentication token usually I mean in some implementation lives as a as a cookie under the dab domain and so then um this cookie uh can be and we've seen that we've seen that in production uh sometimes it's the only thing that that is needed in order to
perform the key refresh operation so to authenticate with a world provider and perform a key refresh operation so in other words uh that means that the security of your onchain private key is as strong as the security of your authentication token so um that's the first problem the second problem is that this authentication token is shared with a decentralized application so in other words the decentralized application has access to all the secret that is needed in order to recover your onchain private key so they become uh sometimes without even um knowing it like a custodian of of your wallet because they can just access your
private key also cookie are notoriously very difficult to secure they can live on like different data store under your infrastructure sry data dog and and all of that and so remember this now lives under the decentralized application infrastructure and so it's difficult to secure is difficult to understand who has access to it so like putting all of that together I was able to like write a simple script that takes as the input this authentication token that now you get whenever you authenticate to the decentralized application and um you can just like pass that to this script this script is going to make few API call to the wallet provider and then it's going to recover
your private key okay so now you may Wonder um this experience looks cool uh but how do I know if I'm interacting with a secure system or not so you actually have a very simple way of of checking that is whenever you expose on the decentralized application to the embedded wallet experience you can just open your uh console under like the application tab uh so you will usually see like multiple storage that are dedic to the DAP that's fine you don't have to touch those and then you will see some local storage that belongs to the eded wallet provider so under the eded wallet provider domain
cookie and storage so what you want to do is you want to clear those storage so like you simulate that you change device or that you don't have the authentication token anymore then you just refresh the page and uh if you see that the wallet is loaded again without you as a user having to input any secret that means that uh the DAP has all the information that is needed to like recover access to your wallet without uh uh any information from you and so you you're that's a problem you you're not like interacting with a secure implementation so now if you ever want to like develop an embedded wallet
experience my advice for secure implementation is so like two things the first thing is to to leverage as much as possible publicly cryptography so you want the client to have um like a private key it's not not necessarily linked to the like Unchained private key but as a private key and you as a embedded web provider you only have the public key and you only use this public key to validate authentication uh we've seen some embedded wallet provider like using top to secure access to their system uh that's not advised because OTP is based on a shared secret and so that means the embedded wallet provider has all the information that they need to
like fake access to your wallet and um you won't be able to prove that it's not you that access your wallet because this is based on a shared secret so always use public cryptography so that only the client can perform some signature to authenticate to your system like webon and pass key again are great implementation of that um and also another um um um advice is to not expose the onchain private key inside the client uh like browser local storage because um um then when you lose your device or when you go from one device to another you need to perform a key refresh operation that's very sensitive
operation so advice would be to use a credential to decouple uh the security of the credential from the security of the onchain private key okay that's it thank you very much uh what we can say is that when we look into that we encounter various flood operation in production we reported the issue to like the wallet provider uh each time and so we we've seen some mitigation that have been deployed following our report so that's great but we still have some insecure implementation in production and so um one last thing is I'm talking with a lot of people that perform like smart contract security audit security firm that are like
dedicated to Smart contract uh there is a a lot of things to do on the infrastructure side as well and and all these like offchain uh system that interact with the blockchain and uh yeah there is a lot of like Improvement that can be done and things to do so don't don't hesitate to go look around that because that's that's an interesting area as well thank you very much [Applause]