Overview

Multi-party computation (MPC) is a cryptographic technology that allows multiple parties to use their own secret information to solve a computation problem without ever sharing their secret information with the other parties. Fireblocks developed the MPC-CMP protocol that applies this concept to blockchain-based ECDSA and EdDSA signatures used by all blockchains. MPC-CMP removes the concept of a single private key.

Such a key is never gathered as a whole–not during the first creation of the wallet or during the actual signature. MPC-CMP follows a set of steps to guarantee that there is never a single point of compromise of the private key:

1. Individual secrets are randomized by each of the three endpoints–either servers or mobile devices. Those secrets are never shared with each other.
2. The individual endpoints engage in a decentralized wallet creation protocol in which they compute the public key (wallet address) that corresponds to the set of individual private shares.
3. When a signature on a blockchain transaction is requested, all three of the endpoints engage in a distributed signature process. During this process, each one of the endpoints individually validates the transaction and policy before signing the transaction.

MPC-CMP is an open protocol available in public repositories. It has completed several cycles of academic review and was accepted and presented at the NIST 2020 and ACM CCS 2020 conferences.

Threshold signature protocols

A threshold signature is a type of digital signature where the underlying secret material, such as a private key, is divided into several shares. Each share is held by a different member of the group. In order to create a valid signature, the required number of shares must be combined.

With threshold signatures, the minimum required number of people must agree in order to sign a message. This can be helpful in scenarios where it is important to have multiple people approve an action.

Naive secret sharing

In a naive secret-sharing scheme, the original secret is simply divided into shards and distributed to participants. A certain number of shards are then required to reconstruct the original secret.

With naive secret-sharing protocols, malicious actors improve their chances of cracking the entire password by gaining access to just one of the shards since they would then have a portion of the actual password.

Additive Secret Sharing

Additive Secret Sharing (more commonly known as Shamir Secret Sharing with full threshold t=n) is a more sophisticated method for dividing a secret into multiple unique shares. This method shares similarities with Shamir Secret Sharing. However, Additive Secret Sharing only allows shares to be combined using simple addition operations, making the process more efficient than Shamir Secret Sharing. With Additive Secret Sharing, no other operations can be used to combine the shares.

In a signature threshold mechanism that requires 3-of-3 and uses Additive Secret Sharing, a malicious actor gains no advantage in cracking the underlying secret by gaining access to one or two key shares. In this instance, knowing two key shares does not give any mathematical or statistical leverage for cracking the third key share.

In contrast to naive secret sharing, Additive Secret Sharing can provide perfect secrecy. In cryptography, perfect secrecy refers to a situation where it is theoretically impossible for an attacker without the entire set of key shares for completing the threshold signature to learn any information about the secret. Even if the attacker has unlimited computational resources and knows everything about the encryption algorithm used, the secret remains secure. Further, a single participant holding a single key share does not have any knowledge of the underlying secret.

With MPC-CMP's implementation of Additive Secret Sharing, the secret itself never exists–even during the key generation ceremony!

MPC-CMP vs. Multi-Sig

The MPC-CMP private key protection layer, like Multi-Signature wallets, eliminates the risk of a single point of failure by ensuring the private key is never stored on one device at any time, protecting against both external hackers and insiders. MPC-CMP also allows transactions to require multiple authorizers before signing regardless of each user’s physical location.

Operationally, this is a significant advantage over Multi-Sig due to MPC's inherent flexibility. Unlike Multi-Sig, MPC-CMP technology can be updated. MPC-CMP was designed to address new requirements of the digital asset space that emerge as new institutions enter the ecosystem. MPC-CMP was designed to be future-proof.

Significantly, deleting a user's MPC-CMP key shares from a device does not stop operations or impact other MPC-CMP devices. Additional MPC users and key shares can be created as needed. All Multi-Sig wallets are restricted by the original signing rules, even if a user can't sign transactions for any reason.

• MPC-CMP is universally composable, guaranteeing strong security properties for any implementation out of the box. Universally composable cryptographic protocols are important to the practical implications of new cryptography since they remain secure even when arbitrarily composed with other protocols.
• MPC-CMP allows fully air-gapped signing.
• While MPC (GG18) requires eight rounds of communication to fully sign a message, MPC-CMP only requires four rounds, three of which can be pre-processed.
  • The above means that MPC-CMP is 800% faster than the common MPC protocol.
• The last signature round of MPC-CMP can be done offline by scanning QR codes to pass data between co-signers. This enables a true offline air-gapped wallet.
• MPC-CMP allows for a distributed process of a message signature without having a single point of compromise at any stage of the key shares’ lifetime.

Key ceremony security practices

Fireblocks uses hardware random number generators (HRNGs) to exponentially provide the most random entropy for creating the private key shares. Unlike older methods of key generation, which may have been manual, the Fireblocks platform fully automates the private key creation process. No manual steps are required. If the MPC key generation process fails, the key was not created. 

With MPC, each party generates its part of the private key share separately to produce an extended key of the workspace. The key shares are always held independently. For signing transactions, each key share creates a signature without revealing the private key to the other parties, and the signatures from each key share are combined together.

This process ensures that the extended private key is never constructed in a single environment. Therefore, the extended private key is not saved anywhere because no single party should have access to the full private key nor is it ever formed in one place. The only exception is Workspace Key Backup and Recovery where the key shares are encrypted and backed up in a recovery package for disaster scenarios. Learn more about our security standards here.

Each individual MPC key share is randomized within a hardware isolated component using the above NIST SP 800-90A compliant random number generator (Intel RDRAND), eliminating the possibility of weakening the protocol implementation.

MPC-CMP improves upon previous MPC protocols by providing:

• Minimal latency.
• Offline signatures.
• Proactive security.
• Universal composability.
• Accountability through identifying bad parties.

The following diagram depicts a standard user onboarding to a Fireblocks workspace with signing permissions.

Furthermore, the diagram below shows a high-level overview of a transaction signing process (zoomed in to show the MPC-CMP signing part of the process):

Wallets on the Fireblocks platform are multi-signer wallets. Therefore, they require a set of independent co-signers, each holding a private key share, to participate in the signing process.

More specifically, signing on Fireblocks requires participation by a threshold of co-signers owned by Fireblocks and a threshold of co-signers owned by the customer. None of the parties (neither Fireblocks nor the customer) can sign a transaction alone.

The two co-signing components are:

1. The customer:  The customer uses a set of mobile devices or SGX servers, each owned and operated by different team members. The mobile device stores the key shares in secure storage and in an encrypted manner. For instance, on iOS, they are stored in the Keychain. Extraction of the keys requires multiple factors used for a combination of authentication and decryption:
   • “Something you remember” (PIN code) and
   • “Something you are” (touch ID or face ID) or “something you have” (Yubikey NFC).
2. Fireblocks: Fireblocks uses a set of secured (SGX) server co-signers. These co-signers are used as safeguards in case the keys owned by the customers are compromised. They protect the wallet by logically enforcing a security policy, such as a transaction amount threshold or destination address integrity.

Initially, a single mobile user (the Owner of the workspace) is invited to set up a wallet together with all Fireblocks co-signers. At the end of this step, the Owner and the Fireblocks co-signers can sign a transaction together.

The following diagram is an abstraction of the logical co-signer structure and the key structure after this first step:

Then, the system triggers Fireblocks co-signers and the Owner’s mobile device to add the other signing users defined for that wallet. This structure requires a single manual interaction by the Owner for each user being added, reducing the number of interactions compared to more general access structures.

The following diagram is an abstraction of the logical co-signer structure and the key structure after a second group was added: