Moms ∩ Cypherpunks: On the practical difficulties of building an accessible yet secure wallet system

Transcript

[Music] [Music] [Music] Hey everyone. Um, today I want to talk a little bit about embedded what and and their security, what they're the best system from for on boarding new users

and what the security challenges are and and how we can solve them. So I'm Norwap the founder of happy chain and and one of the thing we built is the happy wallet which is one such embedded wallet. So very quickly I'll explain web three versus two boarding which is a quick motivation for why we care about this at all. Some problems with existing embedded wallet uh how we go from social login for something like Google and Twitter to an onchain account and then various attack vectors uh against embedded wallets and how we can defend against them.

So um when you on board a web tree user imagine a user has never used crypto at all doesn't have a wallet doesn't have funds anything looks something like a diagram here they're going to connect click the button hopefully the interface will tell them if you don't have wallet install a wallet so they'll do that they have to understand what a seat phrase is they have to pick a password they have to secure a seat phrase so that hackers don't get it but also so they don't lose use it. And then there's this whole other thing. They got to get cast token which first of all figure out how because unlike installing a wallet uh instructions are usually not really um included. So they might open a

centralized exchange account or they might be lucky and have in the wallet directly a credit card on ramp. So then they put their payment details and then comes a part that could have been a third screen which is if the chain that they're trying to on board is not supported by the credit card and RAM or by the centralized exchange they got to figure how to bridge and that's a whole another issue. So um you know in marketing they call this a funnel. This is the funnel from hell. Nobody makes out the other side. Maybe some people do if they think they're going to get very very rich. Uh on the other hand on web two app you connect you have your classical O with Google, Twitter, Facebook whatever. Uh if the app is paid you put your credit cards in and you're done. So that's very

simple. Now we have something in web three that lets us do that and these are the embedded wallets. Um you might be familiar with privy. Um there's capsule I think it's called par web three off third web open force. There's a there's a lot of people doing this. Uh okay so are we done? Can we stop the presentation? No, we can't because these things have security issues. So the classical issue with embedded wallet today is that they fully trust the app. They create an account for every app. First of all, that's not ideal from a usability perspective.

But uh the reason they do this is that the app is completely trusted and it it's really really dumb. The issue is this little thing on the on the right of the screen. It's a model, right? Displays within the app. And models are nice. They always work. They are fast. They're snappy. They look good. Um, but if I'm a bad guy and this displays on my app, I can just paint over the the signing part. So, this is a bad example because it doesn't say what you signed in the first place. So, this is already insecure. But say it said um mint free NFT. Well, maybe that's what I painted on top. And then underneath it's going to drain all my funds. and I click sign thinking yay free NFT but actually I lose all my money. Uh so it's called

clickjing and so that's one of the reason why apps must be trusted. Uh and because of that it's kind of fine if you do it just for one app because you cannot trust the app anyway. But if you go to multiple apps a single malicious app can drain all your funds. So you absolutely can't do that. Uh so the solution is popups. You know little popup on the right. This is from the happy wallet. We're not the best designers but this is what we got. Um, pop-ups, they they suck, right? Like browsers sometimes block them. Sometimes they go under your browser window. If you're using Safari, you're going to have a bad time. Safari. Um, but they're secure, which is why Google uses them and everyone uses them for Google

off. If you look at Google off, you never have a little model. It's always a popup or a full redirect flow. And there's a reason for that. Uh, how do we how do we solve that specific issue? uh we can use something called session keys which is the best of buzzworth. You trust apps but only with a limited scope of uh interaction. So the app is able to make transaction to a target contract. Maybe there's spending limits uh things of that nature and then since you trust the app you don't even need the model. You can just let the app do the transactions.

Something similar that has been proposed by Coinbase is to sub accounts. So in this case you create more accounts but they're hierarchically under the main account and they get permissions from it. It's pretty much the same thing ultimately. So um something that's important when you think about the social device uh the social login system is how do we go from my Google account to an onchain account right to an address that's on chain and can make transactions. you use cryptography uh you use multi-party computation to generate a private key and then you split it into multiple shares and we're going to classify these shares in three buckets.

Uh so there's many many ways to do this. I'm going to present what I think is one of the best system and and is that's implemented by some of the providers. So in this system you split them in three buckets. There's a device share that lives on your device. It's kind of device 2FA. There's a backup share you keep safe somewhere and then there's an o share that lives on someone's server. So if I'm I'm having my wallet the happy wallet then uh I'm going to put this is my server. You can also decentralize that with a network. It's not necessary but it's a nice extra little touch. Let's say and then what you do is you need two out of these three factors. You need one share of two out of these three factors to be able to sign. And then there's two schemes. there's TSS that

stands for threshold signing scheme. Um and so in that mode the the various parties so it's going to be you and the O server are going to come together to sign a transaction and the nice thing about the TSS is that the key is never reconstructed in memory in anyone's device. The other one is called SSS is Shamir secret sharing and in that one you the user are going to reconstruct the key on the client should still be secure. So both of those are fine. Um yeah the nice thing about this is if me the wallet provider is malicious I cannot do anything um by myself because I only have one share and you need two.

If you lose your device you can still you know use the backup share and the O share to recuperate. If you lose your Google account, same thing. You still have two shares. If you lose your backup, you can make a new one. So, this solves a lot of UX issues that we have with traditional wallets as well, right? Where you lose your MetaMask account and your seat phrase, you're kind of Um, hello. Little problem here. Oh, I think it just went to sleep. So, what? Yeah, important thing. Many providers don't do this. um they only have two shares or one uh or some of them what they do is really funny is they have a backup share but then they

have it on server themselves and they will often say yeah well it's a third party provider um we can't touch it but you can still have to trust uh that they're not lying on that uh someone's going to ask about pass key of course so I got to talk about them pass keys on the nice side they can be verified on chain so you know that's okay right now it requires high gas pre-ompile, but I think this is all going to be solved. Um, we personally don't use it in the app wallet. And the reason is the UX is not very good. It's especially not good cross device. So, if you have an um a Mac and an iPhone, probably works. If you have Chrome, both device probably works. Everyone else is going to have maybe a bit of a hard time

to synchronize things. Um, so what you would do is authorize multiple pass keys, but it's a little bit more work. um versus the the split um private key scheme that we had before. Uh you're back to a self-custody model where you can just lose your pass key um just like you can lose your wallet and it's even worse because you don't have the the little paper with the seed phrase and it's really hard to export out these keys and reimpport them other places. um there's just many many report problem and the reality is it just kind of doesn't work some of the time and as someone that's making a product I would think if something doesn't work 2% of the time it's not acceptable I think pass keys in practice are actually much worse than that um but they are a nice backup a way to do backups backup share

um that that could be a good use I think for for pass keys uh and I think they'll get there eventually but today not really um okay so this I cannot touch on this and I'm going to skip quickly. Uh basically the two out of three model is really nice. H but you the one that's complicated is the backup key because you don't want as you on board a user to be like hey there's a backup where do you want to put it? Um you just want the user to get started as as fast as possible. So there's two ways to to sort of help with that. Uh one is you don't do a backup and you add it later when user puts money in his wallet.

Um the other one is you do the centralized approach but you only do it temporarily. So you will keep the backup uh with the O provider and then whenever user has value you will tell them hey secure your wallet and then you delete the the previous one and you add a new one. um many ways to do backups. And then something to pay attention to if a user logged in with Google, don't let them save the backup on Google Drive because now you're back as if someone takes over the Google account, they can access everything. Okay, so how can we attack embedded wallets? Um there's many ways.

You can take over the DNS address. This is the domain. You can take over the server. You can poison its dependencies. And you can inject scripts. Um so browser extensions in your browser they can inject script in any page you visit. Um and that then cause some issues compared to browser extension like MetaMask and Phantom they have much less of these issues. They basically just have the supply chain attacks. Um DNS and server if it's well done it's not an issue. I don't know exactly how it's implemented in practice during you know when it runs. Uh it's definitely an issue in install but that means uh someone takes over the the Google uh Chrome store. So um you know it should be okay hopefully.

Uh DSI Jack says um when someone takes over your domain basically. So an example of an attack that you can look up is DNS cache poisoning. The problem is uh as you serve the wallet it's an embedded wallet right? So you do a fetch from a server to get the wallet code. um that code can access the device share and it can request signing from the O share um because you've performed authentication with Google and the user doesn't suspect anything. So basically can sign anything. So there's a thing called DNS stack for DNS security where um the root domain so say you're mywallet.com the com will sign your domain. There's a bunch of issues with that and anyway um there there's a better way to do this but like

one interesting way would be I have a private key on my server and then the app so the you know the thing that runs in the user browser will sign the key from will check a signature from the key of the server um you know all this doesn't matter if you your DNS register account is compromised because then the attacker can just point to the main he wants and uh it all looks So the big one is uh what if someone takes over your server? You should you should try that this never happens. This is like the worst that can happen to you as you all know.

But there are solutions and they also interestingly protect against you the W provider being malicious. So if your code is open source people can audit the code and they can use this approach I'm going to describe to make sure that you're not uh serving them malware. So basically what you do has to do with the architecture of these wallets. So there's the app which is something made by a third party and the app's going to use your software development kit, your SDK to um embed your wallet and that's going to then fetch when the app is uh serving the wallet code. So you have two parts. You have SDK and that that's typically going to be npm package and you have your wallet code. So basically what you do is you put a hash of the

wallet code inside the SDK and when you fetch the wallet code the SDK will verify that the code um matches the hash. Um so this is is really nice in terms of security but uh it it limits what you can do with your wallet because when you want to update your wallet not only do you have to update the the wallet code that you're serving but you you also have to update the SDK and people have to update it in their apps. So one solution you can do is sort of limit this approach to only the critical code that has access to signing logic and then let the rest uh update independently. Do providers this today? I don't know. I have reasonable doubts having seen some of the practices but um it would be interesting to find out.

So supply chain attacks is when you've read software use dependencies written by other people probably code you haven't read or audited. Uh, and this code could in some way um trigger signing. So in JavaScript, it's not true generally that anybody that runs code can can call any code, but they can do still a lot of things that could let them do that eventually. Um, an example of this is something called ambient authority where they can change the global. So the array class that you use to create an array you can change all the methods in that and then via that way when your trusted code creates an array. It does all kinds of nefarious things like uh saving all the data you

put there like signatures changing the content of the arrays. Um thankfully there are solutions and and here I got to shout out Aguric and Metamas that done really good work on this. Um, there's this thing called SCS, which is a framework that really locks down the the globals and makes sure that basically foreign code cannot interfere with your code. I don't really have time to go into this, but I really recommend this this video called Harden JavaScript by Chris Coell. Um, it it really does a good job of explaining what the issue is and then how you can fix it.

Um, you know, this lockdown stuff might be a lot of work. So again you can minimize by just applying this to the critical section of your code. And another thing that's important is all the code that runs can access local storage. So never store secrets in the browser local storage. Um so in conclusion what security is a hydra with many heads and embedded wallets they add a lot of security concerns uh just because of the nature that every time you visit a web page you're hitting the server instead of installing something once and then um using the same code over but they unlock the best on boarding for new users and honestly even for existing users the fact that you can use these

three types of factor to recover from losses of various accounts is a really nice property. Um, so we have solutions. Uh, let's just make sure that that we all use them and free pitch at the end. So, um, what we're doing at Happy, what we're doing is we're building this um, blockchain platform for gaming with the idea of onboarding web two players and web two builders into making web three games. Um, turns out VCs don't want to fund that. But the main thing we built is the wallet, right? And the reason we did that is because the first slide of this presentation, um, nobody's gonna install MetaMask and go to Coinbase to just play a little web game, right? Just wouldn't

have. So, we had to build a wallet on board users. And it turns out it's a lot more valuable than that. And it applies to a bunch of things like DeFi, right? You could go to a DeFi app and um from the D5 app if you never use um you know crypto you log in with social and then you top up from your credit card right in the wallet and then you can use D5 app and all the while you've been staying on the on the DeFi app web page. Um so that's we're building and then of course we we got to make that stuff secure. It's sort of our selling point is that this is a wallet you can use on multiple apps and it is secure. So that's why we're thinking very hard about that stuff. Some of what I talked about we've already implemented, a lot

we have not. Um, but yeah, so if you're interested to know more, just uh just let me know. And uh I think we have time for questions. So if there's any questions, feel free to shoot. [Music]