Breaking Multi-Party Computation: How Protocol-Level Flaws Exfiltrate Private Keys

TLDR: Researchers at Black Hat 2023 demonstrated that many popular Multi-Party Computation (MPC) wallet implementations are vulnerable to private key exfiltration due to protocol-level flaws. By manipulating inputs and exploiting improper handling of aborts, an attacker can force a wallet to leak its key shares bit-by-bit. This research affects major custodians and open-source libraries, highlighting that even advanced cryptographic primitives are only as secure as their implementation.

Multi-Party Computation (MPC) is often touted as the silver bullet for securing digital assets. By splitting a private key into shares distributed across different parties, the theory goes that no single point of failure exists. If one device is compromised, the attacker only gains a useless fragment of the key. However, the research presented at Black Hat 2023 by the Fireblocks team proves that this "silver bullet" is frequently misfired at the protocol level.

The core issue isn't the underlying math of MPC, but how developers implement the interactive protocols required to sign transactions. When these protocols fail to account for malicious behavior during the signing process, they can be coerced into leaking the very secrets they are designed to protect.

The Mechanics of the Leak

The researchers focused on three specific attack vectors targeting the Lindell17 and GG18/GG20 protocols. The most critical finding is that these protocols often lack sufficient zero-knowledge proofs (ZKPs) to verify that each party is following the protocol correctly.

In a standard MPC signing flow, parties exchange partial signatures. If a malicious party—or an attacker controlling a compromised node—sends a malformed partial signature, the protocol should ideally abort. However, if the implementation doesn't handle this abort state correctly, or if it allows the attacker to observe the result of the failed signature, it creates a side-channel.

By crafting a partial signature that depends on a specific bit of the victim's key share, an attacker can observe whether the resulting transaction signature is valid or invalid. If the signature validates, the attacker learns that the bit was a zero; if it fails, the bit was a one. By repeating this process 256 times, the attacker can reconstruct the entire private key share.

Exploiting the Implementation

The researchers released proof-of-concept code for Lindell17, GG20, and a DIY protocol used by various custodians. The exploit flow is surprisingly straightforward for a researcher familiar with the target codebase.

For the GG20 protocol, the attack targets the "Multiplication to Addition" (MtA) phase. The MtA operation is designed to transform multiplicative shares into additive shares. If the implementation fails to enforce a ZKP range proof on the inputs, an attacker can inject a malicious value.

# Example of the brute-forcing logic used to extract bits
for i in range(256):
    malicious_partial_sig = craft_input(target_bit=i)
    if verify_signature(malicious_partial_sig):
        key_share[i] = 0
    else:
        key_share[i] = 1

This isn't a theoretical vulnerability found in a vacuum. The researchers successfully used these exploits against two vendor production environments to exfiltrate their own test keys. The impact is absolute: once the key share is exfiltrated, the attacker can sign any transaction without the victim's consent, effectively bypassing the security guarantees of the MPC setup.

Real-World Implications for Pentesters

If you are auditing a crypto wallet or a custody solution, stop looking only at the UI or the API endpoints. You need to look at the MPC library integration. Check if the implementation uses OWASP A02:2021 – Cryptographic Failures as a baseline, but go deeper.

Ask the development team: "Does your implementation enforce ZKPs for every round of the signing protocol?" If the answer is "no," or if they rely on a custom, "simplified" protocol, you have a high-probability finding. During an engagement, focus on the interaction between the client and the server during the signing phase. Can you inject arbitrary values? Does the server provide feedback on failed signatures that could be used as an oracle?

The Path to Remediation

Defending against these attacks requires moving away from "trust-based" implementations. The primary mitigation is the mandatory inclusion of ZKPs for every step of the protocol. Specifically, implementations must verify the "well-formedness" of the inputs provided by every participant.

If you are a developer or a security lead, ensure your MPC library is not just a collection of math functions but a hardened protocol implementation. Check the recent commits on your dependencies. For instance, the BitGo TSS library and other open-source projects have already seen patches to include these necessary proofs. If your stack hasn't been updated in the last twelve months, you are likely running code that is fundamentally broken.

Cryptographic protocols are notoriously difficult to implement correctly. The transition from academic paper to production code is where most security failures occur. As MPC becomes more common in institutional custody, the focus must shift from the strength of the underlying elliptic curve to the integrity of the interactive signing process. If the protocol doesn't prove that every party is playing by the rules, assume they are cheating.