Log InOpen Account

Custody

How Fireblocks MPC protects keys

By Abra Research

Published Updated 4 min read

Digital assets are transferred using cryptographic signatures generated with private keys. Whoever can use that key can move the asset, so how a key is created, stored and used to sign is a central part of digital asset security. For the Abra Vault, Abra implemented multi-party computation (MPC) technology developed by Fireblocks. This article explains what MPC is, how it differs from other approaches, and the types of transaction controls the Fireblocks platform supports.

Key takeaways

  • A private key controls a digital asset, so how it is stored and used is central to security.
  • MPC splits one key into encrypted shares that are designed to sign together without being combined.
  • The Fireblocks platform supports governance, policy and whitelist controls that a transaction can be required to clear before signing.
  • Abra implemented MPC technology developed by Fireblocks. MPC secures the keys; it is not custody.

What a private key does

A private key is a long secret number. It produces the digital signature a blockchain needs before it will accept a transaction from a wallet. The blockchain does not check who sent the request, only whether the signature is valid. That makes the key itself the thing to protect: if it is lost, the assets can become inaccessible, and if it is copied, someone else can move them.

Single key, multi-signature and MPC

There are three common ways to set up control of a wallet.

  • Single private key. One complete key signs every transaction. It is simple, but the key is a single point of failure: one place to attack and one thing to lose.
  • Multi-signature (multi-sig). Several complete keys are kept separately, and a transaction needs approval from more than one of them. This removes the single point of failure, but each key is still a full key that has to be secured on its own.
  • MPC. There is one key, but it exists only as encrypted shares held in different places, and a required number of those shares work together to sign.

How MPC signing works

With MPC, cryptographic key shares are generated and maintained across separate parties and systems. When a transaction needs to be signed, a set threshold of shares (described as "m of n", for example two of three) each run their part of a joint calculation. The result is a valid signature. MPC is designed so that the shares are not brought together and the full private key is not assembled on a single device.

MPC is also designed so that one compromised share is not sufficient on its own to sign a transaction. Fireblocks uses its own MPC protocol, MPC-CMP, for this signing.

Single key vs. multi-sig vs. MPC, the types of transaction controls the Fireblocks platform supports, and the key share lifecycle. MPC secures how keys are stored and used; it is not custody.

Controls around a transaction

The Fireblocks platform also supports controls that a transaction can be required to clear before it reaches signing:

  • Workspace governance. The workspace is the top level of a Fireblocks account, with a single owner. Users can be given roles that determine who may approve and sign, and configuration changes can be set to require approval from a quorum of admins.
  • Transaction Authorization Policy (TAP). A rule engine that checks outgoing transactions against configured rules and can allow them, block them or send them for additional approval.
  • Whitelisted addresses. A whitelisted address is a destination that a user with the right privileges has approved. Transfers to addresses outside the whitelist can be blocked by policy.
  • MPC signing. A transaction that clears the configured controls is signed by the required threshold of key shares.

Rules can cover the number of approvals and signers a transaction needs, transaction limits, approved destination addresses and which roles can sign. The controls configured for a specific account are described in the applicable client documentation.

How key shares are managed

Fireblocks and EY have published leading practices for managing key shares at each stage ([report title, year: to confirm]). They describe general practices, not the specific controls of any one account. For the Abra Vault, Abra requests key generation and recovery on behalf of the client.

  • Generation. Key shares are created in a key ceremony whose process and controls are reviewed by an independent third party. Shares for new signers or admins are created only after the workspace owner approves.
  • Storage. Shares are held apart from each other, in cloud infrastructure or in hardware such as a mobile device's secure enclave or a hardware security module (HSM). No single person should have access to every share.
  • Backup and recovery. Soft recovery replaces the share on a lost or inaccessible device while the other shares remain available. Hard recovery rebuilds the key from backup using the owner's recovery passphrase and is reserved for disaster scenarios. Backups are kept in separate locations, and recovery procedures are tested.
  • Monitoring. Activity such as large transactions, permission changes and new key generation is monitored, with alerts on key and policy changes. On-chain balances are reconciled against account records.

What MPC does, and what it does not

MPC is key-storage and signing technology. It is designed to secure how keys are stored and used to sign. It is not custody. Custody depends on the applicable custody arrangement and may change when assets are deployed to venues, protocols or counterparties. Abra Capital Management, LP ("ACM") facilitates the custody solution and provides investment-management services with respect to assets in the account. To see how assets move in and out of the Vault, read How an Abra SMA Vault works.

How an Abra SMA Vault works