On August 19th, Japanese cryptocurrency exchange Liquid announced that it was hacked, with the perpetrators stealing about $97 million in crypto and transferring it to four different wallets. Liquid made this statement about the hack via Twitter:

Liquid explains on their website that they utilize “a combination of cold wallets and MPC [multi-party computation]” to manage digital assets. As Liquid says that their “warm wallets were compromised” in their tweet, some may assume that this means that the hackers broke into Liquid’s MPC algorithm. 

However, we believe it is highly unlikely that the hackers were able to break into the MPC algorithm itself. Rather, the hack that occurred was more likely possible due to other aspects of the exchange’s security configuration.

In this blog post, we’ll walk you through some recommendations for anyone working with MPC to avoid a similar occurrence:

Secure transaction and workflow authorizations within hardware

Liquid uses a combination of MPC and cold wallets to secure digital assets – a configuration which we have found to be one of the most secure and efficient possible methods. 

However, this hack shows that it is critical to secure every attack vector – including workflow and transaction authorizations. It’s best to secure all policies within hardware-isolated enclaves. 

For example, Fireblocks secures all signing and approval policies using SGX hardware. Policy rules are signed by a quorum of admins and encrypted within SGX; the engine is implemented inside of the SGX enclave and the code cannot be modified. This prevents both hackers and even insiders (such as IT administrators) from modifying the implemented rules or the logic of the policy engine.

MPC shares should be truly distributed

In order to realize the full security benefits of MPC, MPC shares must be truly distributed. 

What exactly does this mean? 

Simply put, true distribution refers to distributing key shares between 2 or more organizations where there is a high level of segregation between the networking infrastructure and the access control to each one of the shares. 

This means that a setup in which one organization distributes their MPC shares across several locations – even if they’re quite far away from each other physically – could be insufficient for keeping hackers out. 

On the other hand, in a setup where the MPC is truly distributed across organizations that do not share servers or infrastructure, a compromise is much less likely to be possible. One solution to this is to store a share of the MPC with an enterprise cloud provider.

To take it one step further, Fireblocks stores our users’ MPC shares within SGX hardware-isolated enclaves hosted by two different cloud providers: Microsoft Azure and IBM Cloud. In all cases, key shares are distributed so that no one (not Fireblocks, not the customer, nor any individual cloud provider) has access to the entire key. 

***

Ready to learn more about designing a multi-layer security system to secure your digital assets? Read our security whitepaper to learn everything you need to know about our multi-layer security philosophy.