Beyond Private Key Security: Cosigners and Advanced Policy Engines - DeFi Security Summit 2025

Transcript

Can you hear me now? Okay, cool. Hi everyone. Um, my name is Ron Vart. I'm a solutions engineer at Blockade. Um, what I want to walk you through today, you see, you see the headline, right? Private beyond private key security, advanced transaction screening policy engines. Um so really what I want to talk to you about today is you know it's obvious how uh uh private key security is important right but uh we think that it's not enough and there are things that uh you should be worried about and that's the the topic of my um workshop.

Uh I'll walk you through a few slides uh and also show you a few demos uh along the way. Um, this is uh actually not me. It's my face on a on an AI body. I don't remember the last time I I wore a suit. Uh, so u uh kind of a of a funny image for me. Um, okay. Um, so if you don't mind, I'm going to start with a question uh with a rate of raise of hands. Uh how many of you uh have a setup with a single private key?

Um thank you for raising your hand. Um how many of you use a multi-ig wallet or an MPC wallet as well? Very nice. Uh and I'm also uh sure that you know some people would would also raise their hands if they had a custom or hybrid uh setup as well. Um so um you know there's there's many many different setups. All of those setups really represent uh a different step in the life cycle of of teams, right? As team evolves, as they grow, they they would initially start from a single key setup. Uh but as they have, you know, more assets in in their wallets, uh they will switch to more

advanced setups with a multi-IG or an MPC. Um, sorry. Forgive me for a second. >> Okay. Sorry. Uh, yeah. So, I'm going to state the obvious here. Uh, you know, a single key setup is not great, right? If if something happens with a with a single C key setup, one compromise basically uh is going to result in total loss and obviously we don't want to we don't want to have that. Uh transactions

on blockchains are immutable. Uh if you lost your assets, you most likely lost your assets. Nothing you can do about it. Um and an example of that is uh BTC Turk, right? So BDC Turk, it's actually interesting within the the the span of less than the 14 month uh they had two incidents that were very similar. First one on June of 2024 uh a a key uh leakage uh uh led to them losing about $55 million. Uh so so there was a a hot wallet, they lost the key or someone uh was able to obtain the key for that hot wallet and basically drained all the funds and you know you

would think that something like that uh would would create you know more better security better setup for for the next time but unfortunately uh it happened to them again uh at August of of this year. uh very similar. Someone was able to put their hands on a private key for for their hot wallet and was able to steal uh another $48 million. So a total of over $100 million uh were stolen in in just over a year. So that's you know super critical obviously and and it's not like they're not uh you know advanced or sophisticated. They are one of the biggest uh exchanges in uh Turkey. They have a big team. uh but they were hacked twice uh in the same

manner. So so how do you solve this problem? Right? Solving this problem is by using a multi-IG or an NPC wallet. Multi-IG such as uh uh safe or an APC wallet such as maybe uh Fireblocks, Fortify, uh squads and and many many uh others uh help you solve that that problem of of a single point of failure, right? Because there's no key to be leaked. uh you would have to get all the keys from all the signers and that makes it a lot harder uh to to obtain than than just a single key. However, those uh uh setups uh are not immune to to drains, right? So, if you're thinking

about a setup like that, if you don't mind me asking, is anyone here uh you know, does anyone here feel completely secure with their setup? Do they know uh for every transaction that they're about to sign on an MPC or or a multi-c, do they know exactly what that transaction is going to do? >> I'm sorry. Exactly.

>> You described you described, you know, several different problems with this setup, right? So, uh when you look at the data, it's not very clear, right? You you see cold data, you don't necessarily know what it means. Uh people could be socially engineered into signing things that that they don't necessarily uh understand. So, so yes, you might have an MPC or a multi-seek, but that doesn't mean that those transactions uh are safe. Uh and uh uh the reality is that existing wallet infrastructures like that are are just not enough because you know 70% of recent hacks were targeting multi-IG and NPC wallets. That's a very big number.

two out of three uh signers uh do not really know the outcome of transactions that they approve. They they they might be able to sign a a transaction, but they usually sign based on trust, right? They someone they know uh proposed this transaction. So they say, okay, if if that's the guy who proposed, yeah, I can I can sign this transaction. It's fine. But then more than $4 billion dollars uh uh were were lost in multi-ig and MPC wallet attacks just in the last uh two years.

Um so so obviously you know super critical and the biggest example of that is of course the the bybit hack. Uh what happened in the BBIT hack is that the the uh attackers were able to compromise the safe uh UI, the user interface. Uh and and when they did that, what happened is they were able to propose a transaction and for the signers the UI looked completely okay, right? The the UI looked benign. It was a transaction they were expecting to see. No problem with that. So they signed it. But behind the scenes, the transaction was completely different, right? The call data of the transaction was something completely uh completely different. And

um um uh when they signed it, they actually signed a transaction that cost by bit $1.5 billion. Uh so so obviously by using a multi-IG, they had multiple signers, but uh the transaction was malicious and uh drained their wallet. So, if I I'm going to uh hop out of u of this presentation for a second just to show you what that uh might look like. I have a safe wallet set up here uh with a lot of funds as you can see.

Uh but uh I have it uh connected to a um sorry to a uh um a testing DAP that we have and in this testing DAP at the bottom here I have uh a transaction that I can generate that uh that basically shows a uh proxy uh implementation upgrade just like what happened with the bybit hack. Right? So if I click send here, uh you can see at the top uh how uh the safe wallet is uh blinking.

So this is what this looks like for a signer um that would have seen it on the buy bit hack. Uh and and this actually is the actual safe UI. This is not a hacked UI, right? It's very hard to understand what this transaction is doing. you can't really tell. So if I'm a signer, even if my UI is not hacked, I'm looking at this, I see call data, I see a bunch of numbers and and characters and what what does that mean? Right? It's very hard to understand what it means. Uh so so so it's not a simple task for a signer to decide should I sign this transaction or not. Right?

So let's go back to uh the presentation. um and talk about you know the the stages of a transaction approval workflow. Normally in a transaction approval workflow we have three different stages. We have the the stage where a transaction is being proposed. We have the stage where a policy is checking those transactions and if that uh uh is done policy checks are completed uh we have the the stage of reviewing and signing uh the transaction.

The first step that where where transaction is is proposed is usually the the the most dangerous uh step. It's it's where the vulnerability is is greatest. Someone on your team is suggesting a new transaction. It might be uh using the safe UI. It might be uh you know um using a a DAP interface or something along those lines. But they're proposing a new transaction. What happens there is uh that that it exposes you to a major gap. And that gap is the transaction manipulation gap. In the transaction manipulation gap, uh if there's an attacker, an attacker can very easily do things like tamper with with uh call data. uh they can be uh you

know swapping uh destination addresses, they can do you know social engineering like like you mentioned earlier um and they they they can uh introduce different uh back doors to to contract calls. All of those things are uh are are a big problem uh because um the UI will not necessarily show you uh um what's happening with the transaction. you won't be able to necessarily understand what that transaction is doing. Uh and and uh it it opens you up to uh to an attack. Um the second uh step of uh um of the the approval process is the policy check.

Within the policy uh check uh there's there's a couple of gaps. The first gap is uh that the policy checks are static while transactions are dynamic. Right? So when you're checking a transaction versus a policy and your policy is looking at u uh maybe is this going to a destination address that I whitelisted uh or not that's not necessarily enough. Um so so you have to do something that that is more um uh meaningful and and actually look at the dynamic result of a given transaction and not just on the static data that you're getting with a

transaction. Um, and uh to show you an example of what what that uh might look like. Um I have my uh sorry I have um the unis swap uh v2 router here on etherscan and I want to show you what in in the contract of the um sorry of the v2 router there's a bunch of different um uh uh sorry functions and and those functions in in all of the swap functions if I expand any one of them one uh parameters that you would see is the two address. What does the two address do? So imagine you're swapping,

right? If you're doing it through the unis swap UI, the swap will go back to your own address, right? You're swapping uh tokens from your address to back to your own address. But if you're not using the unis swap UI and you're basically making a call to the unis swap uh um contract when you're structuring the trans the transaction uh on the unis swap contract you can use a function on the swap interface on one of the swap functions that will actually uh you can use the the two parameter and and swap into a different address. So attackers will take advantage of things like that and and unis swap is not the only one right many different protocols allows you to do the same thing. Uh it's a it's it's not uh uh a vulnerability of unis

swap. It's a feature. uh but attackers will take advantage of that right because I might be whitelisting in my policy the the unis swap uh router uh thinking that okay I'm swapping only through un unis swap and that's true but the transaction itself might eventually end up in uh in an attacker's uh address um so so um so policies uh are important but unfortunately they're not uh they're not enough so let me switch back to to the deck. Uh so that's the really the the first gap that comes up with uh um with policy engines.

And the second gap is um the second gap is is policy fragmentation. So think about you you you raised your hand when when I asked if you have a single uh a single key setup and also a multi-IG uh setup or MPC setup and that's very common, right? Many teams would have multiple different solutions, right? They might have a safe setup and a fire block setup and a squad setup. Right? So if you have all of those setups and you want to enforce policies across all of them, some of them has policy engines themselves, but uh they don't have uh you you won't have a unified policy engine that will cover all of your uh setups at one place. So that so so policy fragmentation is

another gap because it creates uh the the possibility of of of mishaps, right? someone is configuring a certain policy in one place but forgets to configure it uh on the other. Um and then finally uh the last step is uh is the signing right. So when a user is uh reviewing and about to sign a a transaction uh what happens is they normally open their wallet they see uh a transaction show up. They might look at the the safe UI like we we've we've seen with the the example I showed uh with the by bit hack, but it doesn't necessarily make sense. It's not an easy task to

understand what a transaction is doing. Uh so many of the signers will actually sign based on uh uh their familiarity with the person who's proposing their transaction and trust that person that transaction is legitimate. Uh which means they're basically blind signing. So they don't have visibility into what a transaction is doing and and it's very hard for them to make uh a decision on on that transaction. So these four gaps uh exist in almost any approval flow, right? So um operational uh workflow is it's it's a balancing act. People care about three things mainly speed, security and

compliance. Uh so uh because of this reality uh we need to think about how are we going to be able to solve the this problem right what's the solution to to this challenge so let's talk about what a good solution uh should actually look like so there are four different building blocks uh that are uh that that uh creates a best-in-class uh transaction security solution. The first building block uh is simulation and I'm going to talk about all of them uh all all of those that you see uh on the screen. You need to have uh simulation and validation for every transaction. So the transaction goes through a full

simulation. It goes through a validation engine. You need to have uh policy enforcement that goes across all of your solutions and also actually looks at the the the result of a of a transaction and not uh just at the basic uh static data from a transaction. And you need to have a good threat intelligence engine and let's drill down into each one of those. [snorts] So when you're thinking about simulation um you know one of the key things about simulation is uh that that you don't want to just look at the user intent.

You want to actually simulate the the uh transaction itself uh and um um and see what actually happens with the transaction. Uh so um um you you want to do a a full transaction uh execution in a sandbox in order to um uh see the the outcomes of a transaction because there are attacks today uh that are uh time of check time of use attack. So basically the simulation result will be completely different than the actual transaction uh when when you sign it. So you want to be able to bypass those as well. uh you want to introspect every participant of the transaction whether it's the caller

uh the delegates uh the contracts every component of the transaction needs to be uh uh looked at. Um you want to uh trace the the full value of the the transaction across uh all of those calls. Uh what assets um uh are moving where? And then finally uh you want to make sure that your simulation supports all of those advanced uh uh use cases that exist right so EIP712s permits C ports uh etc etc uh because if you don't support those you can't really simulate and uh we what we see from our data is that over 80% of transactions today's are actually uh offchain signatures uh transactions.

So that's uh simulation and then the second building block is is validation. What validation does it basically uh wants to check two different things. The first thing that that that it wants to check is um uh does this transaction exhibit any kind of uh behaviors that are uh typically associated with attacks. Uh so for example uh if you have any kind of uh approval farming or uh addresses that look alike or compromised addresses etc. All of those things are are just normal things that are associated uh with attacks. And then you also want to make sure that the transaction um does not intersect with something that is

dangerous. Right? So things like uh you know wallet drainers uh uh or uh um um uh AML uh uh addresses etc. So all of those things are are also super critical and you and you need to to uh to validate all of those as part of the uh validation uh step. Um and then the last thing it uh um the last component of of of the top uh set is the policy enforcement. When you're thinking about policy enforcement, we talked about it uh um before. Uh your policy enforcement is something that you want to have uh that is based on the

actual simulation of a transaction. Right? when you're not basing your policy enforcement on the simulation of a transaction, uh what's going what's going to happen is that um uh uh uh you're going to miss things. Uh and and the example I gave you was one of them with the whitelisting address. Um that that is basically um uh if if you're whitelisting the the the the V2 router of unis swap, an attacker can still use the v2 router. it will pass policy enforcement and uh allow the uh the end user uh the allow the attacker to to receive the funds. Uh but then also you want to make sure that the policy enforcement is across all of your

different solutions, right? So it's not just um uh across uh safe or or uh across u um you know squads but it covers all of them uh in the same uh place. So, so basically um instead this this component of policy enforcement is is uh asking it's not asking is it safe. It's asking is this is this something that's permitted for us in our setup? Is this something that we want uh to allow um I want to show uh a quick example of what that might might look like uh in in a setup. So, uh, policy enforcement or or an example for a policy that does

something, uh, like what I said, right? So, so this is this is the blockade platform. I'm going to get into more into that at the end, but but this uh, in this specific case, what I'm showing here is what we call a gaining address policy. the gaining address policy. What that does is basically looks at the simulation result of a transaction and understands from the simulation which addresses are actually gaining from this transaction. Right? So it's not just looking at is it going to the V2 router but is it go is the is the funds ending up in the addresses I want them to end up is in. So, so if an attacker is manipulating the cold data and sending a

transaction that will go through the V2 router but end up in their own wallet instead of of the wallets I care about, if I have the gaining address uh um policy configured, I'm going to catch that and protect myself from from something like that. Um the last component of uh those four uh thing four building blocks uh for for transaction security is the threat intelligence. And when you're thinking about threat intelligence, it's it's essentially the brain behind the the transaction uh uh validation uh engine.

Uh and what it does is it tells you if any of the addresses, contracts, tokens or any uh any other components are known to be malicious. It helps you identify patterns and and different um behaviors uh that don't look uh dangerous uh on their own but could be uh dangerous uh in in the uh context of a transaction. Uh so threat intel is is is a critical component like I said uh and and what it does is it's a it allows the validation layer to basically says to bas basically say this transaction has a a behavior uh that is uh strange and we've seen this exact pattern in in you know 20,000 uh

other transactions um uh across the ecosystem. this is malicious and you should be careful uh not to interact with it and and uh blockades uh intelligence uh engine is uh is is extremely strong right the thread intelligence engine uh for blockade processes more than 500 million transactions uh every month uh it looks at attacker behavior in real time we see transactions that are not even making it on chain at all um and it gives us the ability to uh protect uh end users and identify u all all of those uh malicious behavior uh many times even before the

first user has been attacked. Uh so the last component uh that is also very important is the ability to integrate seamlessly into your existing solutions right that the the integration uh architecture is is critical because what you want to make sure is that the integration is very simple but also it doesn't really change any of your existing setup. uh you want to continue using your your multi-igs and MPCs as you did without having to make any configuration changes or or uh any uh uh updates to it. Uh it it helps uh if

basically create zero trust because you don't have to trust um your your signers, you don't have to trust uh the front end and and you don't really have to trust any assumptions. It helps you validate, simulate, and make sure that every transaction uh works uh as expected. It gives you control um uh it it uh um it allows you to override decisions uh when you feel like you need the uh the the override option and it validates uh raw raw coal data and not just the wallet UI. it doesn't really um um it doesn't rely on the UI uh at all.

Uh so I'm going to pause here for a minute uh for for questions uh before I switch to to showing you a demo of the system. Any any questions from anyone? Okay, cool. So let me show you uh let me exit this uh presentation and uh switch to a quick demo. Um so I'm going to cancel this. We don't need this transaction anymore.

And uh I want to connect I'm going to connect my wallet to to unis swap. Okay.

So uh so go back to unis swap and uh and let's see see what that looks like. Okay. So, I'm uh I'm going to do two different uh transactions.

My wallet is on base. So, I'm going to do I'm going to do like uh a swap from USDC uh to maybe uh ETH, you know, something basic. Click get started, review and sign. So let me see. Okay. So, we have we have this transaction coming in.

I'm going to sign it. Confirm it on MetaMask. And I want to show you something that just happened. I'm going to drag another window here. So this is my slack channel for alerts uh that come in from uh the blockade cosigner. What we see here is that I got once the transaction was uh proposed uh in unis swap. Uh I can see that transaction has been found by cosigner.

So the blockade cosigner identified that there's a new transaction and uh notified me on slack that the transaction uh there's a new transaction that was proposed and then sorry and then you can see I have another message transaction has been approved by cosigner. So the cosigner also approved this transaction uh uh to be signed. So basically uh and you also saw that the screen changed behind me on on unis swap I'm sorry on safe. So now this transaction uh can be uh executed. If I go to Oh, sorry. Let me close this.

If I go to to this view, you can see that this this is uh has been this has been confirmed and I have two out of two signers, right? two out of two signers because the first signer was me when I signed it through MetaMask and the second one was the blockade co-signer and you can see how uh so so this transaction is basically ready to be uh executed. Uh now the second uh uh thing I want to show is some a very similar use case but in this case uh what I will do is I will use a different token.

So this token is a malicious token I know about uh and you can see in unis swap it has a red a red exclamation mark. The reason why it has a a red exclamation mark is because unis swap is also using blockade. One of our other services is the the token scanning service and unis swap is using token scanning to uh to scan every token. Uh and they will tell you that this is uh dangerous. So if I click this uh token now you can see malicious token detected uh and you can see powered by blockade over here. I'm going to ignore it and show and and continue. So, I'm continuing with this token and I'm hoping it will get a route for this token because it might have been

rugg pulled already. Okay, no routes available. So, so in the case of this specific token, um I won't be able to show you what it looks like in a co-signer because the Let me see if I can find a different one. Okay, let's see about this one.

Okay, since I know that this is happening sometimes because the malicious tokens uh are not available for a long time, especially rugpool tokens, which is what I wanted to show you. Uh, let me grab instead something else. Okay, I'm just grabbing a malicious address. I'm uh, again, a malicious address I know about. And instead of doing it through unis swap, I'll just do a new transaction and and transfer try

to transfer tokens to this address. Uh so I'm going to do send tokens, paste the address and do whatever right? Click next. And you see that there is a risk detected. Right? This is also something that uh is powered by blockade, but we're uh we we want to help you protect against the use cases where blockade might not be in in the UI. Blockade might not be or maybe the UI has been um uh compromised. So, I'm just going to click continue here and sign a transaction.

So, I signed the transaction. Uh, let's go to the queue. You see there's one out of two signers here. And if I switch to my um to my transaction to to my uh view here in uh there we go. We have two messages that came in. So, you can see transaction has been found again. And then below it the transaction has been uh has been rejected by uh by cosigner. Um so this is how the cosigner works right it helps you protect your uh your multi-ig and npc wallet uh by identifying problematic uh transactions and basically blocking

them. So in this case in this transaction it's not never going to show to change from one out of two to two out of two. It it will not be able to to execute I will not be able to execute the transaction. And if I want to see more details about this transaction, uh I can always click on uh view scans and that will take me to the blocket platform. And in the blocket platform, I'd be able to see all of the transactions uh hopefully with the Wi-Fi here. uh we don't see we don't see the malicious transaction yet but maybe if I uh just do you know last seven days or something like that we'll see okay we do

have the the malicious transaction here so if I click on this malicious transaction you can see uh the full details of what's happening right so this helps you overcome the the problem of blind signing it it shows you exactly what's happening. It shows you the full uh call data as well, but it shows you what uh what was the reason for blocking this transaction. You can see that this has an address that has malicious activity. It shows you a transaction graph. In this case, it's a very simple transfer, right? So, but you see that I'm transferring uh funds into this malicious address. And it shows you the simulation result. You can see what was sent and what is being received. In this

case, nothing is being is being received. It's a it's a simple transfer of uh some tokens. Um but it gives you the visibility that you're lacking in many other use cases so that you can then say okay I understand what's going on here uh and and make a a sound decision on whether you you want to continue with a transaction uh or not. So uh so so so basically uh provides you with with everything you need to make uh the decision. And that's uh that's true for both malicious and benign transactions, right? So the benign transaction uh I had before. Uh this is the the transaction and unis swap. You can see the exact same details here. And actually if I maximize uh this graph,

you'd be able to also see uh you know all of the call functions involved. So it's not just the transfer itself. It's everything uh in this case it's the permit. It's everything related to to a given transaction that that we give you visibility into. Now on top of that comes the the policy engine that I described earlier. I showed you uh briefly uh one example of the um of a policy that is possible. Uh but if I go into the policy engine uh you'd be able to see you know existing policy and then existing policies but then configure your own policies. The policies can can be as advanced as you need them to be, right? It's not necessarily uh um you

know simple like you know don't go above a certain uh value but it could also be you know super advanced like for this event uh uh this parameter should not be over x. Uh same for function calls uh you can set your destination address uh policies which are like whitelist uh policy but also the gaining address policies that uh that I uh described earlier. So it gives you a lot of uh visibility and control uh over everything that's happening with your uh multi-IG and and and MPC. Um so to summarize

uh if you want to secure your multi-c and NPC wallets uh we obviously recommend the blockade cosigner uh which uh gives you best-in-class simulation engine uh which simulates uh the actual transaction not just based on the the user intent simulates all of the advanced use cases the AP P712s and such. Um it it gives you the the full context and the outcome of a transaction so you can u not sign blindly. Um it it gives you the policies that that we've discussed and uh automated control workflows. So basically you can integrate us into your multi-seant NPC and that uh uh will then automatically either approve or reject a transaction

to help your uh um human signers uh make the sound decisions that that they need. Um so that's it. Uh this is what I had to share with you today. Hopefully this was uh uh helpful and again any any questions I'm happy to answer. [applause] Thank you. Did you have a question? Yeah.

>> Thank you for the talk first. >> Yeah, absolutely. >> I wanted to ask you. >> Yeah. When you add blockage signer, it's like just you have to add a transaction on the multi adder as signer on the safe. >> Mhm. >> That's what's how do you add cosigner by blockade to your booty? >> Mhm. >> Just it's like remove signer and add ser. >> Yeah, great question. And so the question was how how how do you add the blockade cosigner as an additional signer to to safe uh and the answer it's it's very simple. You basically uh you configure it on the on the blockade

platform. We we explain how to do that. It's it's it's very simple. All you have to do is give us your uh your safe address. Once it's configured on the blockade side you you get an address for the co-signer and you add that address in your safe UI as an additional assigner. You can change the threshold. uh you know maybe you have three out of five so you can change it to four out of six. We also have a more advanced setup that allows you to to make the blockade signer a mandatory serer. Uh so there are many different uh options but it but all of them are are very simple to to integrate. Yeah, >> for each side the cosigner has only one address for all safes that we want to to

add or every time we want to add the cosigner will generate a new address. >> Yeah. So, so the question was uh does cosigner cover all of the the safes uh with one address or is it going to be a separate address for each uh safe? And the answer is yes, it's going to be separate address for each safe. So, each safe will have its own co-signer uh and it's uh yeah, that's how it works. >> I'm sorry. >> Okay. Yeah, we can we can definitely talk later. Happy happy to discuss.

Okay. Thank you everyone. [applause]