Security and Vulnerabilities of MPC

Overview

Multi-Party Computation (MPC) is a robust cryptographic technique that distributes trust by allowing multiple parties to jointly compute a function over their inputs without revealing them, eliminating the need for a single entity to hold the complete private key. MPC is at the center of a novel design that combines shared signing, delegated key management, and context-aware identity protection. But MPC is not bulletproof. It brings complexity, and complexity introduces new attack surfaces, implementation vulnerabilities, and coordination threats. This section looks very closely at the vulnerabilities inherent in generic MPC systems. It then illustrates how security architecture, specifically its Delegated Key Management System (DKMS) and Throttled Identity Protocol (TIP), reduces those risks.

Despite its strong theoretical foundations, Multi-Party Computation (MPC) is not immune to real-world security incidents. Over the last several years, multiple high-profile bugs, disclosures, and academic attacks have demonstrated that vulnerabilities in MPC implementations are not only possible, they are often subtle, hard to detect, and devastating when exploited. By examining these past failures, we gain essential insight into the importance of rigorous verification, reliable synchronization, and cautious dependency management. Below are several real-world cases that have reshaped how security architects think about MPC design and implementation.

Figure 1: MPC Failures Timeline

GG-20 Attacks (2020; 2023): Exploiting Lack of Verifiable Key Generation

A landmark academic paper published in 2020, known colloquially as the GG-20 Attack, demonstrated how key generation in threshold ECDSA can be compromised if parties do not perform verifiable proofs during the Distributed Key Generation (DKG) phase. By injecting rogue keys without proper verification mechanisms like zero-knowledge proofs, malicious participants could bias the key material and retain secret knowledge about the final output leading to eventual backdoor access.

Besides this, the Alpha-RAY attack (2023) targets the GG20 threshold ECDSA protocol, exploiting a weakness in the range proof mechanism. It allows a malicious party to gradually leak secret key information during signing, potentially recovering the full private key over multiple protocol runs.

This attack crystallized a critical realization:

• MPC protocols without verifiable computation are incomplete.

• DKG phases must be hardened with cryptographic proofs of correctness, not just functional outcomes.

Liquid Exchange Hack (2021): Breach of MPC Signing Infrastructure

In August 2021, Japanese cryptocurrency exchange Liquid suffered a major security breach resulting in the theft of over $90 million in digital assets. The attackers compromised the exchange’s MPC-based warm wallet infrastructure, gaining unauthorized access to the systems responsible for transaction signing.

While the underlying multi-party computation (MPC) cryptography remained intact, the breach was made possible through infrastructure-level vulnerabilities, likely involving weak access controls or exploited signing workflows. The incident highlighted critical risks in the operational security of MPC-based systems.

Key takeaways from this incident:

• Attackers don’t need to break MPC math; they can exploit the infrastructure (nodes, workflows, APIs) that governs when and how signatures are generated.

• Warm wallets carry persistent risk even with MPC. They are vulnerable to compromise if infrastructure, access controls, or monitoring are weak.

• Poorly enforced or overly permissive signing policies create a single point of failure.

• Even with strong cryptography like MPC, poor infrastructure security and human error remain major vulnerabilities. Secure key management must be supported by solid operational practices and system hardening.

ZenGo Bug (2022): Nonce Reuse Due to Faulty Synchronization

In 2022, a vulnerability in the ZenGo MPC wallet was publicly disclosed, revealing a critical bug in how nonces were handled during ECDSA signing. The issue stemmed from improper synchronization across the devices participating in the MPC signing flow. Due to unexpected race conditions and lack of replay protection, the same nonce could be reused across different signing sessions. As a result, an attacker observing two signatures with the same nonce could reconstruct the full private key undermining the entire MPC scheme.

This incident highlighted:

• The fragility of nonce generation in distributed environments.

• The importance of state tracking and strong session binding in MPC flows.

• The need for deterministic and verifiable nonce coordination mechanisms.

Fireblocks Disclosure (2023): Incompatible Libraries Leading to Predictable Signatures

In 2023, Fireblocks disclosed a critical bug in one of their internal MPC implementations, caused by the use of inconsistent versions of cryptographic libraries across participant nodes. Specifically, differing interpretations of ECDSA nonce generation logic led to predictable signature components. This incompatibility introduced subtle entropy leakage, which in some configurations could be exploited to recover private keys.

Key takeaways from this case:

• Library version mismatches can silently corrupt the assumptions of cryptographic protocols.

• Signature determinism, if not fully verified across implementations, can create side-channel opportunities.

• CI/CD integrity checks and dependency audits are not optional in MPC deployments they are foundational.

• Security must be layered during initialization, not only during signature generation.

Multichain Insider Exploit: When MPC meets centralized key custody

On July 7, 2023, attackers gained access to key shares controlling Multichain’s MPC (Multi-Party Computation) wallet. Using these key shares, they drained over $100 million in crypto assets. Although Multichain used MPC wallets, control over the private keys was effectively centralized, meaning that only a limited number of people or systems had the authority to sign transactions. This made the system vulnerable to insider threats or key compromise.

This incident highlighted:

• Centralization Risks in MPC Setups

• Effective multi-layer approvals, transparency, and monitoring are essential to prevent misuse of privileged access within blockchain infrastructure.

• Operational Security is as Important as Cryptography

Binance TSS Library Incident (2024): Billions at Risk from an Unaudited MPC Library

One of the most controversial examples of institutional overtrust was the use of an unaudited open-source Threshold Signature Scheme (TSS) library by Binance in its MPC infrastructure, allegedly responsible for managing billions of dollars in user funds. Although no exploit was publicly reported, security researchers raised serious concerns:

• Lack of formal verification or code audit.

• Unclear trust model and inconsistent documentation.

• Risks of relying on cryptographic primitives that were never peer-reviewed or fuzz-tested at scale.

This case underscored:

• Auditing is non-negotiable for systems holding real-world economic value.

• MPC's perceived security is only as strong as the weakest dependency in its stack.

• Institutional due diligence must extend beyond performance benchmarks to include reproducibility, resilience, and formal security properties.

Identified Weaknesses of MPC Systems

Every incident reinforces the necessity of a defense-in-depth approach: verifiable key generation, strict nonce control, dependency validation, behavioral enforcement layers like TIP, and robust key access abstraction like DKMS. The stakes are too high to rely on theoretical guarantees alone.

MPC doesn’t fail because of cryptography. It fails because of:

1. Bad implementation choices.

2. Lack of verification.

3. Overtrust in internal infrastructure.

4. Neglected edge cases.

Every incident reinforces the necessity of a defense-in-depth approach: verifiable key generation, strict nonce control, dependency validation, behavioral enforcement layers like TIP, and robust key access abstraction like DKMS. The stakes are too high to rely on theoretical guarantees alone.

Despite its promise of distributed trust and cryptographic resilience, MPC systems are not immune to critical vulnerabilities, especially when protocol design, implementation practices or operational controls fall short. At both the protocol and system level, flaws such as mismanaged nonces, improper quorum logic, and weak randomness can completely undermine the security guarantees of MPC. These issues are often amplified by the complexity of coordination among distributed nodes and the absence of verification mechanisms like zero-knowledge proofs. When combined with infrastructure-level oversights, like cloud-centralized key shares or insecure recovery flows, the result is an expanded attack surface with multiple high-risk entry points for adversaries. Additionally, the risk of insider compromise, insufficient auditing, and insecure recovery logic that reintroduces centralized failure points further weakens system resilience.

Figure 2: The layers that are exposed to attacks

Protocol-Level Bugs and Design Flaws

• Nonce Mismanagement in ECDSA/EdDSA: Reuse or miscounting nonces can leak the whole private key. In MPC, joint generation of nonces with bad randomness or desynchronization can lead to catastrophic leakage.

• Deterministic Signing Failure: Non-deterministic signature schemes (e.g., random nonces) allow for fault injection or selective replay attacks if attackers can influence or manipulate the randomness.

• Faulty Quorum Logic: Failing to dynamically update quorum membership or configuring threshold logic improperly (e.g., incorrect t-of-n calculation) will result in signing failure or unauthorized signing.

• Unverified Key Generation: Without zero-knowledge proofs or verifiable computation in decentralized key generation protocols, rogue key attacks are possible.

• Insecure Recovery Mechanisms: Recovery mechanisms lacking strong cryptographic proofs or validation (e.g. social recovery without MPC-based verification) can expose key material to malicious recovery participants.

• Message Reordering or MITM Attacks: Lack of message ordering guarantees or strong peer authentication allows attackers to reorder, replay, or spoof critical messages within MPC execution.

Figure 3: The common MPC vulnerabilities

Generic MPC Implementation Structural Flaws

• Static Quorums are deterministic and more susceptible to attacks.

• Single-Device Failure Risk, specifically with multiple shares being on one compromised device.

• Cloud-Hosted Key Shares introduces central risk vectors (subpoenas, insider threat, full compromise).

• Timing Attacks and Side Channels may leak secret information during execution.

Delegated Key Management System (DKMS)

The Delegated Key Management System (DKMS) offers programmatic abstraction of key operations and access control. Rather than statically assigning MPC keys to users or devices, DKMS delegates permission to conditionally perform key operations by potentially interested delegates.

Figure 4: Delegated Key Management System

DKMS Functions:

• Abstracts control of key shares behind programmable access controls.

• Facilitates conditional delegation, e.g., session-based access, identity scoring, device fingerprints.

• Supports social recovery or rotation through multi-stakeholder governance.

DKMS Security Benefits:

• Prevents unilateral signing even with compromised nodes.

• Enables detection of threshold drift and emergency circuit breakers.

• Acting as an identity-aware policy enforcement layer before signing.

DKMS transforms raw MPC into programmable, auditable access governance, significantly reducing risks around fixed quorum assumptions.

Throttled Identity Protocol (TIP)

Throttled Identity Protocol (TIP) is a contextual enforcement layer that is designed to throttle or block identity-sensitive operations before they hit the MPC core. TIP sits at the session layer, inspecting behavior patterns, device metadata, and user consistency.

User request → goes through filters → MPC gets a "clean" request → signs.

Figure 5: The architecture diagram shows how TIP sits above DKMS, and DKMS sits before the MPC core

Role in the Stack

User Session → TIP → Behavioral Monitor → DKMS Policy → MPC Execution

TIP is positioned as a pre-signing firewall, rejecting risky or unusual activity before it can affect quorum behavior or trigger MPC computation.

TIP Capabilities

• Rate Limiting & Throttling against unusual request rates.

• Anomaly Detection by behavioral entropy scoring.

• Replay and Injection Protection of session IDs and signing requests.

• Botnet Mitigation by correlating geolocation and device fingerprinting information.

Threat Mitigation

Threat	TIP Countermeasure
Replay Attacks	Session scoring & timestamp validation
Credential Stuffing	Multi-layer verification & session lockouts
Insider Abuse	Behavioral deviation alerts
Scripted Automation	Entropy detection & velocity throttling

Limitations of TIP

• TIP is based on contextual metadata, which poses potential privacy issues.

• Aggressive heuristics may produce false positives in extreme edge cases.

• Device fingerprinting can be evaded with sophisticated spoofing tools.

Defense-in-Depth: Full Stack Hardening of MPC

MPC uses multi-layered defenses to well-known attack surfaces:

• t-of-n Threshold Schemes ensure security even if some nodes are compromised.

• Verifiable Computation (e.g., ZK proofs during signing).

• Ephemeral Session Shares no permanent key storage.

• Remote Attestation e.g., SGX attestation of MPC enclaves.

• Behavioral Anomaly Detection integrated with TIP and DKMS.

• Key Rotation & Circuit Breakers for forward secrecy and threat containment.

• Audit Trails for governance review and forensics.

Figure 6: Decentralized Multi-Chain Operations within a secure MPC (Multi-Party Computation) architecture

Threat Models Addressed in MPC

MPC’s security assumptions are grounded in realistic adversaries:

Adversary Type	Description
Passive (Honest-but-Curious)	Nodes follow protocol but try to extract side-channel info.
Active (Malicious)	Nodes deviate from protocol intentionally.
Adaptive	Attacker manipulates nodes over time.
Colluding Nodes	Nodes group attempt unauthorized signing.
Infrastructure Attackers	Exploit CI/CD pipelines, update channels, or logs.
Governance Threats	Bribery, phishing of operators, or rogue proposals.

Attack Surface Mapping

Layer	Threat Vectors
Protocol Layer	Misconfigured thresholds, nonce desync, insecure randomness
Communication Layer	MITM, message reordering, replay
Infrastructure Layer	Container leaks, build pipeline tampering
Governance Layer	Insider collusion, delegate corruption, vote manipulation

Summary

Multi-Party Computation (MPC) represents a powerful cryptographic approach for eliminating single-point-of-failure risks, but numerous real-world incidents (GG-20 Attack, ZenGo Bug, Fireblocks Disclosure, Binance TSS Incident, Liquid Exchange Hack, Multichain Insider Exploit) prove that theoretical security alone is not enough.

The key problems arise from:

• Lack of verification during key generation (e.g. without zero-knowledge proofs),

• Poor nonce management and deterministic signing vulnerabilities,

• Dependence on untrusted libraries without CI/CD verification and formal audits,

• Excessive trust in infrastructure, especially when using cloud-hosted shares or unaudited MPC/TSS libraries.

• Centralization Risks in MPC Setups

• Poor infrastructure security and human error remain major vulnerabilities

While MPC provides a groundbreaking foundation for decentralized key control and secure signing, it also introduces a layered and non-trivial attack surface from protocol-level vulnerabilities like nonce mismanagement and faulty quorum logic to infrastructure threats and behavioral anomalies. The security of MPC systems is only as strong as their weakest link.

To address these risks, modern MPC stacks incorporate a defense-in-depth architecture, combining secure threshold cryptography with advanced access governance mechanisms. Delegated Key Management Systems (DKMS) enforce policy-based control over key usage, while the Throttled Identity Protocol (TIP) actively monitors and blocks anomalous or high-risk signing behavior at the session level. Together, DKMS and TIP create a programmable security perimeter around the MPC engine understanding users, reacting to context, and adapting to evolving threats.

Building secure MPC-based systems is not just about cryptographic correctness. It requires operational control, auditability, user identity awareness, and anticipating real-world attacker strategies, making the implementation a well-defended digital fortress resilient from within, watchful at the edges, and responsive to every behavioral signal.

For the design of the Crypto Processor Decentralized MPC module, this chapter confirms the following recommendations and decisions:

• Mandatory verification of Distributed Key Generation (DKG): implement zero-knowledge proofs during the key generation phase to eliminate rogue-key attacks.

• Deterministic and synchronized nonce management: use deterministic nonce generators with provable coordination between MPC nodes.

• Strict CI/CD dependency audit: all libraries, MPC/TSS implementations, and build toolchains must undergo dependency pinning, reproducible builds, and formal audits before production deployment.

• Integration of DKMS and TIP layers: TIP (Throttled Identity Protocol) and DKMS (Delegated Key Management System) provide a defense-in-depth architecture to prevent logical and behavioral attacks even before the MPC layer is invoked.

• Defense-in-depth approach: MPC security will be multi-layered, not solely based on the mathematical guarantees of the protocol.

Broader value for Crypto Processor

This analysis of MPC weaknesses confirms that our TIP + DKMS design with programmable controls, behavioral scoring, and cryptographic verification of the DKG phase is not merely an innovation but a necessary prerequisite for enterprise-grade security.