Breaking MPC Wallets And Digital Custodians

TS Shock: Breaking MPC Wallets And Digital Custodians

Speakers: Huu Giap Nguyen (Verichains); Anh Khoa Nguyen (Verichains)

Conference: HITB Phuket

YouTube: https://www.youtube.com/watch?v=1ks2jcS7UE4

Overview

In this compelling talk titled "TS Shock: Cracking MPC Wallets and Digital Custodians for Billions of Profits," Verichains researchers Huu Giap Nguyen and Anh Khoa Nguyen unveil critical vulnerabilities discovered within popular implementations of Threshold Signature Schemes (TSS) based on the GG8 and GG20 protocols. These protocols are fundamental to Multi-Party Computation (MPC) architectures widely adopted by modern digital asset custodians, MPC wallets, and decentralized bridges. The presentation meticulously details how these design and implementation flaws can be exploited to perform complete private key extraction, thereby compromising the security of vast sums of digital assets.

The core of the research exposes weaknesses in the DLN proof (Discrete Logarithm of H base H1 mod N) — a zero-knowledge proof component crucial for the security of these TSS protocols. By forging these proofs, a single malicious party can inject compromised parameters into the key generation and signing processes, ultimately leading to the recovery of the collective private key. This subverts the foundational security model of T-of-N (threshold) systems, where multiple parties are required to cooperate for any malicious action. The implications are profound, as these vulnerabilities affect numerous open-source libraries and, more alarmingly, systems currently operating in production, securing billions in assets.

The talk serves as a stark reminder of the immense challenges and inherent dangers in implementing complex cryptographic protocols. It highlights how even seemingly minor optimizations or overlooked encoding ambiguities can introduce catastrophic security flaws, emphasizing the critical need for rigorous cryptographic review, standardization, and meticulous engineering practices in the rapidly evolving landscape of blockchain and digital asset security.

Background

▶ Watch: Introduction: Cracking MPC wallets and digital custodians (0:00)

The foundation of the vulnerabilities discussed lies in Multi-Party Computation (MPC), a cryptographic primitive enabling multiple parties to jointly compute a function over their private inputs while keeping those inputs confidential. A key application of MPC in the digital asset space is the Threshold Signature Scheme (TSS). In a TSS, a digital signature is jointly generated by a threshold T out of N parties, where each party holds only a share of the private key. Crucially, the full private key is never explicitly constructed at any point, enhancing security by eliminating a single point of compromise. For ECDSA (Elliptic Curve Digital Signature Algorithm), a widely used signature algorithm in cryptocurrencies, specific TSS protocols like GG8 and GG20 (proposed by Goather and Janaro) are prevalent. These protocols have seen multiple revisions and are extensively used in production environments.

The GG8/GG20 protocols are built upon several intricate sub-protocols. At a high level, the signing process relies on the Multiplicative Triple Accumulation (MTA) subprotocol. In an MTA, two parties, say Alice and Bob, each possessing a private value (A and B respectively), jointly compute an output (Alpha and Beta) such that A * B = Alpha + Beta. The critical aspect here is that Alice's 'A' and Bob's 'B' must remain private. To achieve this, these values are typically encrypted using techniques like homomorphic encryption, which allows computations on encrypted data.

For the MTA to function securely, the private values A and B must fall within a specific numerical range. This is enforced by a Range Proof. A key component of this range proof is ensuring a specific mathematical relationship: H1 must be in a multiplicative subgroup generated by H2, meaning H1 = H2^E for some secret exponent E. To prove knowledge of this E without revealing it, a zero-knowledge proof is employed. This is where the DLN proof (Discrete Logarithm of H base H1 mod N) comes into play.

The DLN proof is initially an interactive protocol between a prover (who knows E) and a verifier (who wants to confirm E's existence). The prover selects a random value R, computes H = H2^R, and sends H to the verifier. The verifier then generates a challenge C and asks the prover to reveal R or R + E (simplified). The verifier checks the consistency. For practical, non-interactive applications, the Fiat-Shamir heuristic is applied, where the challenge C is derived by hashing public values. This transforms the interactive proof into a non-interactive one, making it suitable for program integration. The security of this non-interactive DLN proof hinges on the unforgeability of C and the sufficient number of iterations (typically 80 or more) to prevent guessing. The "TS Shock" attacks specifically target weaknesses in the implementation of this critical DLN proof, ultimately compromising the entire TSS scheme.

Key Findings

▶ Watch: Introducing TS Shock: Private key extraction attacks (8:09)

The Verichains research uncovered fundamental implementation weaknesses within the DLN proof component of popular GG8/GG20-based TSS libraries. These weaknesses allow a malicious actor to forge DLN proofs, thereby subverting the cryptographic assurances that underpin MPC wallets and digital custodians. The core discovery is that the enforcement relation (H1 must be H2 raised to some secret power E) can be bypassed, enabling the injection of malicious parameters into the signing process. This, in turn, facilitates the complete private key extraction.

The researchers identified three distinct attack vectors, collectively dubbed "TS Shock," each exploiting a different facet of these implementation flaws:

1. Alpha Shuffle: Exploits ambiguous encoding schemes used for cryptographic values, allowing for manipulation of challenge bits.
2. C Split: Leverages an optimization attempt that uses a larger challenge space but eliminates necessary proof iterations, making the scheme vulnerable to partial key recovery.
3. C Gas: Targets implementations that reduce the number of DLN proof iterations, making brute-force guessing of challenge bits feasible.

A particularly alarming finding is that only one malicious party is required to execute these attacks. This directly undermines the fundamental security model of threshold signatures, which assumes that a threshold of T honest parties must be present to prevent compromise. Furthermore, the attacks are designed to be stealthy; the protocol does not abort when under attack, meaning a compromise can occur without immediate detection by honest parties.

The impact of these findings is widespread and severe. The vulnerabilities were discovered in numerous open-source implementations, which form the backbone for many MPC solutions. More critically, these vulnerable libraries are actively being used in production by prominent MPC wallets, digital asset custodians, and decentralized bridges. This means that billions of dollars worth of digital assets are potentially exposed to these private key extraction attacks, highlighting a systemic risk within the broader blockchain ecosystem.

Technical Deep Dive

▶ Watch: C-Split Attack: Optimisation leading to weakness (13:30)

The TS Shock attacks fundamentally compromise the integrity of the DLN proof, which is crucial for ensuring the soundness of the MTA subprotocol within GG8/GG20 TSS. By forging this proof, a malicious party can inject carefully crafted parameters, ultimately leading to the leakage of secret values and the full private key.

Attack Vectors

1. Alpha Shuffle:

• Vulnerability: This attack exploits an ambiguous encoding scheme used for cryptographic values, specifically related to the representation of Alpha0 and Alpha1 in the challenge. The problem arises when a delimiter byte, intended to separate distinct values, can also be interpreted as part of a value itself. This encoding flaw, despite being highlighted in a 2019 audit, persisted in some implementations where length-prefixing was added but the underlying ambiguity remained.
• Exploitation: The malicious party guesses the pattern of zero and one bits in the challenge C. For instance, if guessing two zero bits out of four, the attacker sends a dummy value composed of Alpha0, Alpha0, Alpha1, Alpha1. Upon receiving the actual challenge bits (e.g., 1001), the attacker counts the number of zeros. If it matches the guess (two zeros), they reorder the sent Alpha values (e.g., Alpha1, Alpha0, Alpha0, Alpha1) to match the observed challenge pattern. Since the underlying cryptographic values are the same, this reordering effectively forges the DLN proof, convincing the verifier that a valid proof has been supplied for the chosen H1 and H2.

1. C Split:

• Vulnerability: This attack targets an optimization where a larger challenge space is used, but the critical DLN proof iterations are eliminated. This was an attempt to improve efficiency without a rigorous security proof. The mathematical basis for the attack lies in the equation log C. While log itself might not exist in the defined field (e.g., if log = 1/E and E has no inverse), if C is chosen such that it is divisible by E, then log C becomes a valid number. The implicit assumption that log itself must be valid is broken.
• Exploitation: The attacker uses the Fiat-Shamir heuristic, where C = hash(public_values). By brute-forcing the hash function, the malicious party can select C to be a small number (e.g., 30-50 bits, depending on computing power) that divides E. This allows the calculation of log * C even when log (the discrete logarithm 1/E) does not exist in the field. The result of this calculation is a partial private value, X mod E. To recover the full private key X, the attacker must collect multiple such partial values from different signing ceremonies. These partial values are then combined using a lattice attack, similar to the non-SAGE attack on ECDSA, to reconstruct the complete private key.
• Optimization for Brute-Force: The brute-force search for C can be accelerated using GPUs for parallel hashing, or by leveraging specialized hardware accelerators for common hash functions like SHA-256.

1. C Gas:

• Vulnerability: This is a simpler attack that exploits a reduction in the number of DLN proof iterations. Instead of the recommended 80 or more iterations, some implementations might use significantly fewer (e.g., 1, 5, or 10).
• Exploitation: With a reduced number of iterations, the probability of successfully guessing the challenge bits C increases dramatically. For k iterations, the probability of a successful guess is 1 / 2^k. If k is small, brute-forcing becomes trivial, allowing the attacker to forge the DLN proof.

Private Key Leakage Mechanism

Once the DLN proof is forged, the malicious party can inject arbitrary H1 and H2 parameters, breaking the intended H1 = H2^E relation. This allows for manipulation of the equation Z = H1^X * H2^Row mod N, where X is the other parties' private value. The goal is to leak X.

• Basic Leakage: If the protocol allows, the simplest approach is to set H2 = 1. The equation simplifies to Z = H1^X, from which X can be recovered by solving a discrete logarithm problem (DLP).
• Advanced Leakage: A more robust technique involves setting H1 = H2^E where E is carefully chosen to divide the order of H1. By defining F = order(H1) / E and powering both sides of an intermediate equation by F, the terms involving H1^(order(H1)) effectively become 1. This ultimately simplifies the equation to H2^(Row * F) = Z', allowing Row to be recovered modulo E.
• Discrete Logarithm Problem (DLP) Reduction: To make the final discrete logarithm computation feasible, the malicious party crafts the modulus N (specifically N_theta, derived from the public key N) such that solving the DLP becomes easy. This can be achieved by making N_theta a square, ensuring phi(N_theta) is a smooth number (meaning its prime factors are small), or by choosing N_theta = P * Q_theta where P is a very small prime. This reduces the DLP to a solvable form.

Attack Flow

1. Key Generation: The malicious party generates specific H1, H2, N_theta parameters tailored to one of the identified vulnerabilities. They then broadcast these malicious parameters along with a forged DLN proof. Due to the vulnerability, honest parties accept these compromised parameters.
2. Signing Process: During any subsequent signing ceremony, the malicious party receives the intermediate value Z = H1^X * H2^Row mod N_theta, where X is the secret share of other honest parties.
3. Recover X: Leveraging the malicious parameters and the DLP reduction techniques, the malicious party can now compute and recover X for each Z they observe.
4. Combine and Recover Private Key: By collecting enough X values (especially in the case of C Split requiring multiple partial values), the malicious party combines them to reconstruct the full private key.
5. Exfiltrate Assets: With the full private key in hand, the attacker can then sign transactions to transfer all associated assets to their own control.

This detailed breakdown illustrates how seemingly minor cryptographic implementation flaws or unproven optimizations can lead to a complete compromise of sophisticated security protocols designed to protect digital assets.

Demo / Proof of Concept

▶ Watch: Major Affected Vendors and Libraries Revealed (23:40)

The Verichains team developed working Proofs of Concept (PoCs) for their TS Shock attacks against several prominent MPC implementations, demonstrating the real-world feasibility and devastating impact of these vulnerabilities.

ImgBank Library Demo

The first demonstration targeted the ImgBank library, showcasing the private key extraction process in a simulated environment.

• Setup: A 2-of-6 party threshold signature scheme was established. The malicious actor was designated as "Party number zero." A server was configured to collect values from the malicious party and inject them into the protocol.
• Execution: The system initiated random signing ceremonies. During these ceremonies, the malicious party injected its carefully crafted, compromised parameters. The server continuously monitored the process, checking if the private key had been successfully recovered.
• Details: For the PoC, the E value (involved in the C Split attack) was set to a small 16 bits. This choice, while making the demo faster, meant that more signatures needed to be collected to gather enough partial private values to reconstruct the full key via a lattice attack.
• Verification: Upon successful recovery of a private key, the system calculated the corresponding public key and compared it against the original, known public key. A match confirmed the complete and accurate private key extraction. This demo effectively illustrated the mechanics of the C Split attack.

Thorchain Network PoC

A more impactful demonstration involved the Thorchain Network, a decentralized cross-chain liquidity protocol that acts as a digital asset custodian.

• Setup: The Verichains team set up a local Thorchain node with a simulated balance of assets, deploying a smart contract to replicate the network's environment. One malicious party was introduced into an otherwise honest network.
• Execution: A normal swap transaction was initiated to trigger the threshold signing process, which is a core operation on Thorchain. As the malicious party participated in the signing, it captured the necessary messages and used the TS Shock vulnerabilities to recover the private key.
• Impact: With the recovered private key, a "train service" (a script) was used to send all the assets from the compromised Thorchain wallet to the malicious actor's wallet. The demo showed the asset balance being drained to zero. The researchers reported this vulnerability to Thorchain, who subsequently halted their mainnet to address the issue. The team estimated that if the PoC had gone live on the mainnet, it could have resulted in the exfiltration of 180 million USD. This PoC highlighted the devastating financial consequences of these vulnerabilities in a real-world, high-value environment.

Keep Network PoC

The final demonstration targeted the Keep Network (now part of the Threshold Network), which also utilizes TSS for bridging and other functionalities.

• Setup: A local Keep Network node was created, and smart contracts for a bridge were deployed on a private testnet. A malicious node was then run.
• Execution: The malicious node initiated a key generation process. During this phase, it injected its malicious H1, H2, and N parameters, which were then broadcast and accepted by other parties due to the vulnerability. The system then waited for a "heartbeat" event, which acts as a periodic signing operation. Once this occurred, the malicious node collected the necessary data and successfully recovered the private key.
• Outcome: The PoC demonstrated the ability to recover the private key from the Keep Network, showcasing the applicability of TS Shock to another widely used MPC platform.

Across all three demonstrations, a consistent and alarming theme emerged: the ability of a single malicious party to completely compromise the threshold signature scheme and extract the private key, often without the honest parties being aware of the compromise.

Defensive Implications

▶ Watch: Conclusion: Dangers of complex crypto implementation (32:30)

The "TS Shock" vulnerabilities underscore several critical defensive implications for the security community, developers, and organizations relying on MPC and TSS protocols:

1. Complexity of Cryptographic Implementation: The talk vehemently stresses that implementing new and complex cryptographic protocols like MPC and TSS is an extremely challenging task. It is not a trivial engineering problem that can be handled by an average developer. It requires a rare blend of deep cryptographic understanding and meticulous software engineering expertise. Even minor mistakes or misinterpretations can lead to catastrophic security flaws, as demonstrated by private key extraction.

1. Optimization Without Proof is Dangerous: A key lesson from the C Split and C Gas attacks is the peril of optimizing cryptographic protocols without rigorous security proofs. Developers often attempt to improve performance by reducing iterations or altering challenge spaces. However, if these changes are not accompanied by formal cryptographic proofs demonstrating that the security properties remain intact, they can inadvertently introduce severe vulnerabilities. Cryptographic protocols are designed with specific parameters for a reason; deviating from them without thorough justification is a high-risk endeavor.

1. Need for Standardization: The speakers highlighted that while GG8/GG20 were proposed in 2018, there is still no widely adopted standardization for MPC and TSS protocols, unlike established libraries such as OpenSSL for TLS. This lack of a common, rigorously vetted standard library or specification leads to a fragmented ecosystem where different implementations introduce their own interpretations, encoding schemes, and optimizations. This diversity, while sometimes fostering innovation, significantly increases the attack surface and the likelihood of discovering implementation-specific vulnerabilities. Standardization would provide a common, secure baseline.

1. Emerging Cryptographic Primitives are Risky: MPC, TSS, homomorphic encryption, and zero-knowledge proofs are relatively new and active areas of cryptographic research. As such, the security properties of these primitives and their complex interactions are still being fully explored. It is highly probable that more vulnerabilities, both theoretical and implementation-specific, remain undiscovered. This calls for extreme caution and a continuous, proactive security posture when deploying systems based on these technologies.

1. Criticality of Audits and Reviews: The fact that these vulnerabilities were discovered by an external security firm (Verichains) underscores the absolute necessity of thorough and continuous security audits by specialized cryptographic and security experts. While some libraries undergo audits (e.g., by Kudelski), the persistence of these flaws indicates that audits must be even more comprehensive, focusing not just on high-level design but also on low-level implementation details, encoding, and the impact of optimizations.

1. Open Source vs. Closed Source: The researchers primarily focused on open-source implementations. They acknowledged that assessing closed-source MPC providers is difficult. However, the underlying vulnerabilities are protocol-level or common implementation patterns, suggesting that closed-source systems are likely equally, if not more, vulnerable if they adopted similar design choices or optimizations without sufficient cryptographic expertise. Organizations using closed-source MPC solutions should demand transparent and verifiable security attestations regarding these known classes of vulnerabilities.

In summary, securing MPC wallets and digital custodians requires a paradigm shift towards extreme caution, rigorous cryptographic engineering, adherence to established (or soon-to-be-established) standards, and continuous, in-depth security analysis to mitigate the inherent risks of deploying cutting-edge, complex cryptographic systems.

Key Takeaways

• Fundamental Vulnerabilities in TSS: Popular GG8/GG20-based Threshold Signature Scheme (TSS) implementations are susceptible to critical private key extraction attacks due to flaws in their underlying DLN proof mechanisms.
• Multiple Attack Vectors: The "TS Shock" research identified three distinct attack vectors—Alpha Shuffle, C Split, and C Gas—exploiting ambiguous encoding schemes, dangerous optimizations, and insufficient proof iterations, respectively.
• One Malicious Party is Sufficient: A single malicious participant can compromise the entire T-of-N security model, extract the collective private key, and exfiltrate assets without triggering protocol abortions or immediate detection.
• Widespread Production Impact: These vulnerabilities affect numerous widely used open-source libraries and are present in production systems, including prominent MPC wallets, digital asset custodians, and decentralized bridges, securing billions of dollars in value.
• Caution with Cryptographic Implementation and Optimization: Implementing complex cryptographic protocols requires deep expertise, and any optimization must be rigorously proven secure. Deviating from established protocol parameters without formal cryptographic analysis can introduce catastrophic security weaknesses.
• Urgent Need for Standardization and Audits: The lack of a common standardization for MPC/TSS protocols contributes to implementation diversity and vulnerability. Continuous, in-depth security audits by specialized firms are essential to identify and mitigate risks in this evolving cryptographic landscape.

About the Speaker(s)

Huu Giap Nguyen and Anh Khoa Nguyen are security researchers from Verichains, a company specializing in blockchain security. Their work focuses on discovering and analyzing critical vulnerabilities within complex cryptographic systems, particularly those underpinning digital asset infrastructure. Through their presentation on "TS Shock," they shared their extensive research into the security of Multi-Party Computation (MPC) wallets and digital custodians, providing detailed technical insights into the private key extraction attacks they developed. Verichains has made their research publicly available, including whitepapers, slides, and proof-of-concept repositories, demonstrating their commitment to enhancing the security of the broader blockchain ecosystem.