Migrating the coldest EOAs

Transcript

[Music] So hi everybody and thanks to thanks for coming to my talk on 7702 called migrating the coldest EOS. Uh so I'm Nicolola Becca uh co-founder of Ledger one of the eight and now creating something new called Zenox. Uh we are optimizing cryptographic libraries and tools for the ecosystem. So well first to be very very honest uh I lied uh because I thought that the state of the industry would be very different when I created my slides. Uh so I was just a little bit optimistic.

The good news is that we have some implementation of 7702 for hardware wallets. Uh ledger is the first one. So it's just a coincidence. Um so Ledger already but it's not integrated in wallets yet. On keystone I have a PR which has been accepted and on treasor I have a PR which is still pending. Um so I will change a little bit the topic of the talk and we'll speak about 7702 security a little bit more generally and design choice for hardware wallets. So if you think that that matches your expectation you can stay otherwise I won't take it badly if you leave. Uh so first maybe what is 7702 I will do a very very uh short summary because there has been already a talk in the in Monro a little bit before so if you want you

can look at the zerit talk. Uh the main idea is that you have an EOA, you can turn your EOA into a smart wallet. So basically, you will point to the code of an already deployed smart wallet and your EO will gain the capacity to execute this code. Uh the thing to remember is that the EOA can still originate TX. So it behaves both as a smart contract and as an EOA, which means that if you want to migrate, for example, you can still use it as an EOA. So you can migrate gradually. Um the delegation is permanent uh but it can be changed and it can be revoked and today 7702 is live on mainet uh with a petra update. So as a 7th of May how does it work in details? There is a new

transaction type which is created called type four with an authorization list here and the authorization list uh has the address of the delegate a known signature. Here you will think okay so where do I find the address of my EOA? If you want to find the address of the EOA that created the authorization, you have to do an EC recover with a signature. The signature here, the algorithm, the signature is given there. You will see that we are doing a kak of something that is very very specific. So we are adding a magic prefix and then we are adding part of the data and coded as RLP which means that it cannot be signed by a regular wallet. We'll see why it's important in the next slides. Uh common things when you do that. So when you use

7702 uh you will always note that there are very fine prints in the specification which are good to remember. So here the authorization list is process before the execution portion of the transaction begin but after the standard nons is incremented. That was a bit long to read. Uh but this basically means that if you are self delegating you should set the nons to nons plus one which is not obvious uh when you look at it. And something else uh you can run into some issues with the storage when you are delegating. Why? uh first because you can run into conflicts. Uh let's say you delegate to one contract, you delegate to another contract, they use the same storage slot. Uh they are not initialized, you can run into bugs or worse, you can run into security issues. Uh 7201 can help with that, but

the contract of course has to use this storage uh hints and you can run into that's a new problem, a potential waste of space. So if you delegate to several contracts, of course, the storage of your EO is still being used. So you will end up with waste in your storage because we don't have destructors. Uh so maybe the opportunity to run defrag for smart contracts but yeah at the moment it doesn't exist. So there is not really a solution for that. I would say it's up to the contract to clean up if you want to change the authorization. If we want to look quickly at the state of 7702 support today we have nine chains supporting it. Actually uh 10 chains because I forgot about their quit. Uh I looked at their talk. Uh so they have 7702 and nice cats on their

chain. So it's cool. Um we have five wallets supporting it. So on buyer, metam mask, OKX, trust, unis swap, uh few hardware wallets as I mentioned, a lot of embedded wallets. So they are not in this uh they are not in this document and about 24 dabs. So we have more and more dabs supporting. We don't we have a few major dabs. We don't have the biggest one. I would say we don't have a we don't have I don't think we have curve. Uh so well there is progress here and we will have to define what support means because support is kind of a confusing term here. It just means that the DAP is ready to support new wallet extensions defined in EIP5792 that we will speak about in a few minutes.

Now let's look at the use cases. It's where things look interesting because it's absolutely not what you would imagine. You'll see that most delegation are issued by unis swap. So that looks confusing because unis swap is a DAP. So I think actually those delegations are coming from unis swap mobile wallet. So when you are both an unbed wallet and a DAP 7702 can let you make good things and metamas comes a close second but you see very low. Uh as we would expect the most delegation are on the chain where it's the cheapest to issue transactions. So that's not really a surprise. Uh but the surprise maybe comes here. You will see that looking at the different uh value in the dashboard. uh the most the best use case for 7702 today is crime.

So well it's a it's a common meme uh but we'll see I don't think it's true. So we are not actually doing crime. So why do we come to this very very surprising result um because we have a lot of private keys compromised over time and if we look just as a very simple PRNG uh compromise so if your PRNG is 32 bytes of entropy you get automatically four billion vulnerable keys. So that was the key that was the case with the trustwlet um problem on on desktop. So it's super convenient to use 7702 to auto sweep the east if you are a bad guy because before 7702 you had to watch the chain uh for any incoming transaction and then you had to fight between boats between bots

after 772 you can just delegate in your contract to a sweeper. So you can say okay if I receive some if I will just send it somewhere else and you don't have anything else to do and then you can automatically steal you don't have to fight anymore. So that's why I think it's very opportunist uh a lot of people are just delegating to known um compromise addresses because it doesn't cost much and the reward can be can be large. uh to to fight against this winter mutinator scan added automatically this small text uh in the contract that are um affected. So you know that if at some point you are delegated or you see this contract well it's uh it's bad news. Um myself I did a small CTF experiment. So just after the

launch of Pectra I put 7.702 USDC uh that were easy to sweep uh if you reverse the contract. So you still you still have to reverse the contract. The good news is that it took one month uh to be caught and actually I think it was caught by an attacker that hacked another protocol. So I I don't think it was done automatically. Uh it was very easy to hack once you see the code. You see? Oops. Oops. Oops. Sorry. Because uh it was basically you could just call the transfer function with the address of the USDC and you would get it. Uh I didn't put 7702 uh,000 because well I'm a bit cheap but it was enough. And someone managed still someone managed to it after one month. So you have the transaction here. You can maybe see who is the attacker if you're interested. Uh

the other side of this which is good news is that it can be used for asset recovery because if you can do this delegate thing uh it means you can send transaction without sending ease uh to the affected contract. So you don't need uh to fight against bots uh to recover assets. And here we have already an implementation that has been done uh by SE 911 leader PF. Uh and we have so uh on GitHub something you can use if you want to recover a rec if you want to do a recovery of something that is a bit complex like ESC20 tokens or staked assets. Um you have a framework that is going to help you. Of course, uh we can still revert. I mean, it can help you.

And for attackers who want to fight you, they can still try to redlegate the contract to something else. But for the good guys, it's easier. Um and just yeah, because I like when things happen right before a presentation, I have seen actually an authorization race uh happening on a real blockchain. So on mainet, you can see here bots fighting for different delegations. So trying first in one block then the second one then two blocks after then well uh they tried this for a bit I think after they got tired of it. Uh but basically you had people trying to put their delegation in the same address because the private key was compromised and well at some point someone might be winning if this address is receiving more or it can just be wasted hopefully. Um a few questions you can ask about 7702 from a

security point of view. So are you at risk signing a malicious authorization? Uh the good news if you've seen the signature it's a very specific signature so it can't be signed by a wallet uh unless the wallet supports 7702 or some specific cases that I will speak about. So if your wallet supports ETH sign without adding a message prefix then well it could be compromised because well you could be signing an authorization you don't want to sign and something else uh because we have clear signing we have blind signing I suggested to coin vibe signing uh vibe signing being well okay I'm just signing a hash I don't even know what I'm signing absolutely no context of this then in that case of course you could end up signing an authorization and you

could end up well delegating your account to something that can drain you. So hopefully we don't have many wallets supporting this. Uh I would say those are mostly NFT cards. But I don't want to name any vendor because I think I think my screen is too small. So that's good. Uh but let's say that if you are a hardware valid wallet vendor and you think that putting large u pictures in Paris suburbs rather than passing transaction on your card is a good idea. It's not than just well with 7702. It's a demonstration of that. Um, next question we can ask, are we solving magically everything with 7702? Of course not. Uh, it's a way, it's a pass before we have native account abstraction. So before we could skip

relegating contracts with 7701. The main use case today of 7702 is to move towards account abstraction for EOA. So preserve the history of your account because you can have a lot of stuff you care about. You can care about your transaction history. You can care about your soul bond NFTs, whatever. Um we can have some more exotic use cases where people will be using 7702 to deploy contracts without uh without knowing the private key. So you can actually make a cryptographic proof that you don't own the private key that was used to de to create the contract. So something called prep. If you're interested you can look into it. Uh and but since the EO still exists another thing is that there are a

few use cases that are very interesting that we can do. For example, we can't create a 101 safe uh which is quite a common security practice for key rotation uh because if you do this since the EOA can still originate transactions is completely useless because if your private key is compromised but people can still use it to well to originate transactions and DAB support is really essential. So now we will look at what hardware wallets actually can do what are the choice they can do and what DAP support exactly means. Regarding hardware wallets and smart accounts, they make things very very complicated.

There is one thing I like to say about hardware wallets is that they we can apply um the notion of plastic roaming that we have with SIM cards. You could switch signers very easily before. So you could just say okay, I'm taking a wallet front end. I'm taking my hardware wallet and everything is going to behave the same way because the specification are the same because one transaction is one transaction. With account abstraction, with smart accounts, it's pretty different. Two accounts can define transactions in a very different way and in the end the signer would need to understand who to sign them in order to well in order to be able to switch from one wallet to another. So actually a contract action can be a burden for hardware wallet and for all kind of external smart signers.

So the providers decided to make a shopping list. Um we have several items there. The first one is that we can't delegate to anything uh which seems quite reasonable. So we have a strong control of the delegates. We only want a basic set of features. So we only want batching. We only want sponsoring. We'll see what this is. Uh we would like the smart the smart account to avoid breaking clear signing as much as possible. Uh sometimes it's already difficult to verify uh all kind of cold data on the hardware wallet. So we don't want to make it worse actually. And another strong thing item in the shopping list was to reuse existing delegates. So not create specific contracts for the hardware wallet. So let's see what we can do with that.

Batching is super simple. Batching just means that you are going to send several transaction in one transaction. Uh typically you would use that to not do the approve and swap dance or you would put the approve and the swap in the same transaction and it's very important in my opinion to design your contract to work with that because another option could be to do the batching in an external contract. This is what safe did for example. The problem with this is that you have to call this contract with a delegate call because you need to operate with the same storage as the calling contract. So it it can lead to a lot of problems as as we have seen with by bit. But a large reason of why the by bit hack was successful in my opinion is because it was easy to do delegate calls

with a safe. So better design it in the contract directly. There is one protocol to do that uh one specification called 7821 which specifies a very simple batching mechanism with AI.enode which is also self-sufficient. So DAPs can call the interface and can see uh if the contract is going to support this method of batching. So it doesn't but it doesn't support signing. So it just designs how to do the batching. So hardware wallet could use that. I mean if you have a contract compliant with it then the cool data is easy to pass. Um then with 4337 so with 4337 it doesn't specify batching directly. So important thing to remember 4337 only specify how

what makes a user code valid. So then batching can be done with a lot of different mechanisms. And for example, we have one contract supporting ABIN code which is the basic contract of 4337 which is called uh simple um B account and B account also supports signing with 437 u with entry point V8. It supports signing with EIP712 um which is already passed by hardware wallet. So we have a nice way of looking at all the user app. Uh if this seems a little bit obscure to you because you're not familiar with 437, I will redirect you to the zerquit call uh the zerit um zerit talk which went into this with a little bit more details because I am

quite short on time unfortunately. Uh then sponsoring what is sponsoring? You want the user to avoid paying for gas or at least avoid paying for gas in native tokens. This exists for a while. I mean before 4337 we have we had native we have uh meta transactions. Then for what 4337 did is that it standardized sponsoring in a decentralized way. So that we that is what was introduced with the pay master logic. So here the idea of the pay master is that you will validate the transaction and then the pay master can sponsor can pay gas for the transaction for you. Again I'm going quickly on that because unfortunately I don't have a lot of time to talk about a abstraction. And regarding DAP support, so if a DAP want to support batching and

sponsoring, the option they have is either to take a shortcut with 7821 or to support the fully IP 5792 with wallets and calls. With wallets and calls, you can do batching. You can also do sponsoring. So which is uh sponsoring in both ways. So the wallet can specify a perm or the DAP can specify a perm. One thing that I thought interesting, so I didn't verify it myself because the D gen one is not yet available, but I saw it in a conference. Um, they are using 4337 in the back, but they are hiding it to the front, which means that for the DAP, um, the wallet looks like IA. So there is absolutely no integration to do. It works with all DAPs, but in the end, um, this embedded wallet will

sponsor transaction through a pay master. So you end up with something that looks like an away, but can pay gas for the user. So I think it's a I think it's an interesting use case. I don't know how scalable it is because you would have to sponsor a lot of transactions. Uh but if you want that support, it's a it's a nice way to do it in my opinion. Um a very quick review of popular delegate contracts that were chosen uh to be integrated into hardware wallets and in the end that choice was made by which standard part can we reuse. So we ended up with Metam Mask and the default account of ERC4337. Why? because we had standard batching that we could have a shortcut if we wanted and we had clear signing. So clear signing is the most important thing for a hardware wallet. Uh we we thought that

the first two were maybe a little bit more complex or didn't have clear signing. So my preferred choice today if I have to reuse something would be to reuse either the metamas delegator or the base account of 4337. If you want to test with ledger devices uh which are the first devices which which with with ah sorry which you can test today uh if you need to if you want to test a new delegate first you can build the ledger application the iter application change a white list so something that is quite easy to do I mean you have the github reference of the application but if you are using already one of the supported contracts then it's easy uh and to use it with your DAP with your wallet sorry you need to integrate with a piece of software

called the Ledger device management kit. And again here I point you to the specification because you have already a list of what you can do to sign a delegation. Once you sign a delegation with your ledger, you would have to form the uh the transaction. So the type four transaction in order to send it but this is left uh to do for your wallet. Um maybe I have one minute so I will go extremely quickly on that. If we want to go beyond some IDs uh and some ID still security oriented that I thought might be interesting. How could you recover your wallet if you lose your seal? You could imagine recovering it with a proof of your passport with a proof of your Gmail account. And something else you could add some extra security to your wallet. So have a web free firewall directly embedded into your wallet and

for example reject the transaction if the transaction has been pointed to be something going directly through a fishing address or a doainer. Who would you do that? The answer, you would do it with ZK. So I think it's kind of an answer to everything at the moment. Uh why is it good today? Why could you do it? Because you have good frameworks that let you compute ZK proof locally. Uh which means that since you can compute them locally, they are always available and you have good privacy. So if you want, for example, to verify your email address, you want to do this locally. You don't want to delegate it uh to something else.

uh I pointed to a framework that lists different zero knowledge proof framework that you can run directly on your computer so called mop pro if you're interested you can look at it and well it looks like an idea but I think actually it would be good to implement and if someone wants to play with that during the aceton during this global why not I think I still have 20 seconds so I can just say thank you uh this is my Twitter account when it's not suspended you can send me questions and that's it thank Thank you. [Applause]