Design for the Compromised Signer: Bounding Blast Radius in Smart Accounts

Transcript

[music] [music] Come here. Do you all hear me? Well, yeah. Perfect. Good afternoon everyone. I'm Dave. Uh I'm a product lead at SAFE. And today more than ever, I think we all understand uh why it's so important to think about compromised signers. I'm just going to take you through that in 5 minutes. I mean when I designed this slide it was 2 something billion but just like last week we saw uh the actual biggest problem u hack. So since 2022 we've seen 8.7 billion uh hacked not because they because of vulnerabilities bugs or other

things. It's because of some sort of way to get access to your keys and then sign transactions and just drain your wallets. Right? So you had Binance a few days ago signatures were taken uh by bit last year again social engineering some sort of injection in front end uh and and it goes on like the list goes on where hackers get access to the keys and once they have access to the keys they're able to like control your funds. Um so today I'm going to take you through how can we build something when you assume your signing key is already compromised. So the signing key you use is already in the hands of an attacker.

So then the one question we can ask ourselves is like in case the key is already given to the hacker then what can our account still do and how can it be useful? [clears throat] Maybe a quick show of hands like how many of you have heard of multiigs? Okay. Amazing. Amazing. So um the way it happens is on the first level uh you have the interface. So you're shown something like this is your transaction. And I think Michael before just kind of showed uh try to present how you see the transaction. You want to understand this and there are a lot of hacks on this level where the signer sees something else. they might sign a different payload and and as as this goes in you take the signature the multisig checks the signature and checks like okay I've

got three signatures five signatures and once of once these signatures happen the transactions executed [clears throat] right and once something is executed we go into this irreversible land of your funds have left your wallet and there's no way to go and get it back today I want to talk about onchain guard or I'm just going to call it policies now where after your signatures have been uh so you've met your threshold, we can still read the call data and with these policies you can refuse these actions protecting you from any kind of attacks from the hackers. So I'm going to take you through like two scenarios that you probably see in in your everyday.

So let's take the first scenario, right? So you have a multisig with five owners and you need three signatures for you to execute any kind of transaction. And let's say just one of these keys have been compromised. [clears throat] I think there's been a hack at Beantock where one of the key was compromised and the hacker was able to propose a transaction well and the team members just thought is their routine uh signing ceremonies and like just sign these transactions and allowed it to happen and they lost I think $18 million because they just thought okay this is coming from one of my teammates and let's approve these transactions. So in this case, what the hacker can do is they can [clears throat] propose a transfer uh and because you've set some sort of policy that blocks transactions

that don't go out to other addresses. So you've set a policy where you limit where your transactions can go to. So when the hacker tries to send uh a transfer out, your policy would just refuse it. So then the hacker can try to change or remove the policy. And in this case, your team will quickly realize something is off and they would just remove the signer because the key your team still cons your team still has three keys. They control it and they can just remove and rotate the signer. And for a situation like this, I think the multisig already solves for it. You don't necessarily need a policy. But the policy can allow like lax behavior to still catch such things. I think this is this is what is probably what every uh

we all should focus on is imagine your hacker has three keys right so the whole threshold of your multisig is actually compromised and they can do anything they want with your wallet and and this is like the worst case scenario where you like say this is game over for us and in this case let's say now the hackers get access to your multisc they have all three keys and they can propose any transaction and they try to like move funds out to their their wallets In this case, the policy would just block you because you've not configured a policy on where you want to take the money out. You can only take the money out to like two or three addresses you've allowed. So, the only other option the hackers have now is try to add a new policy or change the policy.

And every policy the hacker is trying to add because the team also has the three signing keys. So, both of you have the three signing keys. So, you just keep reaching a deadlock. So you try to propose a policy, the hackers will cancel. The hackers try to change the policy, you would cancel and you get you get into a deadlock here. So the funds cannot actually leave your safe. But there's one thing that can still work, right? So the only thing that can still work is let's say you've set a policy where you can move the funds out to a safe you control. And in this case, when you know your three keys are compromised as a team, you can just propose a transaction that the policy still allows and you can move all your funds out to a safety control to an EOA to whatever thing you still

control. So, keeping control of all your funds uh and everything else being blocked. Uh yeah, I I went a little over time. Sorry. And all of this is done on chain. So, there's nobody who needs to be online. Uh no other service that you depend on. and you can configure your policies on chain. Thank you. >> Thank you very much. It was very inspiring talk and please uh submit your questions. Here's the QR code for that. And we will uh have time for uh one or two questions. So uh we are still not seeing um any question in the app. So let me just check.

No questions. In that case maybe I can uh ask something. Uh so uh the screen can lie. We have seen that. So from all of the options like what is uh what is the easiest for users? What do you think? >> Uh what is easiest for users? Yeah, [laughter] >> I mean I don't >> think about users, you know, all the time.

Um I I think I think I think like it should be easy enough for users to not have to define a lot of policies per se on what can happen or not but have every policy still be checked at the execution and if something is caught malicious uh you can stop it and I think with policy engine you could also configure a setting where [clears throat] you can have an independent body you can have a decentralized set of validators checking your transaction action and still blocking.

>> We have one question from the audience. So let's answer that. How to be uh prepared myself from malicious wallet is drainer like inferno or angel drainer who are dominant in market who sells services in the internet. That is a question from the audience. So let's answer that. >> Yeah. Yeah. Uh I I think that's that's probably the harder uh pro thing to answer, right? like we've we have all this technology and all of these solutions but the humans are still very um irrational and unknowns and to I think every company should set up their own systems um have multiple levels of uh controls roles

policies and make sure like one person cannot or one system can access and control like uh multiple keys. >> Okay. >> Yeah. Just build better systems. I I I guess that's that's it. >> Thanks for answering very much. Uh >> [music]