Table of Contents:
Private keys (and, to some extent, seed phrases) can be daunting to manage for non-tech-savvy users. And, even for knowledgeable ones, the perspective of securely storing keys forever might be overwhelming, even if they embrace the idea of self-custody. This specific need created a market of its own, leading to the development of different tools.
The most popular way to solve this problem is via Wallet-as-a-Service (WaaS) solutions, allowing users to create wallets directly embedded in dApps, manageable through their Web 2.0 accounts (X, Facebook, email, etc). However, most WaaS tools rely on Shamir’s Secret Sharing (SSS) for key management, a system that, as we’ll explore, fails to meet the robustness requirements that such a sensitive task requires.
In this article, we’ll dive into the dangers and vulnerabilities of SSS, explore the common misconception that this technology relies on Multi-Party Computation (MPC), and compare SSS with MPC-TSS (Threshold Signature Scheme) approaches.
First of all, what is Shamir’s Secret Sharing?
Shamir's secret sharing (SSS) is an algorithm for distributing private information (a "secret") by breaking it into shares and distributing them among a group of participants. SSS ensures that a signature cannot happen unless a quorum of the group provides their shares to be computed, reconstructing the secret.
Initially an innovative solution, SSS mathematically divides the secret into shares, which ensures that the secret can be reassembled only when a given number of shares are combined (the “threshold”) but, crucially, never inferred from any share. Thanks to this, the risk of a potential attack is minimized –although, as we’ll see below, this is not true of all use cases.
Risks and benefits of SSS
Some of SSS’ strengths are its information-theoretic security, minimal requirements, extensibility (new participants can always be added), dynamism (its security can be enhanced without changing the secret, constructing new shares for participants), and flexibility. On the other hand, its weaknesses include:
- Non-verifiability: When the secret is reconstructed from its individual shares, there is no built-in mechanism to verify the authenticity or correctness of each share. This means that, e.g., in a 3/5 threshold, if all five users participate, two could provide altered shares without the reconstruction failing, not notifying the others about the altered shares..
- Single points of failure: The secret must exist in whole at its generation and again every time it is reassembled. This opens attack vectors, as an attacker could focus on the reconstruction points to take possession of the secret or attempt to attack the storage entity.
Crucially, the second risk above is what makes SSS dangerous for managing cryptographic keys and safeguarding users’ assets. Activities such as users signing transactions require frequent usage, radically increasing the attack opportunities and potential reward for an attacker. By attacking the endpoints, an attacker could obtain a user’s private key, even unbeknownst to them, resulting in high risk. Crucially, because of the way the secrets are generated and reconstructed, SSS makes it very easy for the developers themselves to access the users’ keys.
Why is SSS not an MPC solution?
As you possibly picked up from the title of this article, there is a common misconception wherein SSS gets conflated with Multi-Party Computation (MPC). However, it’s important to know that while MPC is safe as an overall solution, its combination with SSS does not result in any benefits for users.
MPC is a subfield of cryptography that allows multiple parties to compute a function together over a series of inputs while keeping said inputs private. The essence of MPC is to allow the computation of sensitive data without revealing a user’s inputs to other parties involved in the computation. This has applications in scenarios where privacy or confidentiality is paramount, such as voting systems, processing of medical records, etc.
SSS, conversely, is a tool for secure storage and retrieval of information, not for processing or manipulating information privately. The use cases for both solutions are generally different, and while SSS can be integrated as a component in an MPC system, secrets are still reconstructed on the client side, making this combination inadequate for the purpose of private key management.
Combining SSS with KMS
Another commonly seen mechanism for private key management is using a KMS (Key Management System) along with SSS, constituting solutions referred to as KMS+SSS.
A KMS is a solution for storing and managing cryptographic keys. It is an environment in which encrypted private keys are stored and secured (in whole, usually). KMS mechanisms use encryption standards and controlled access mechanisms for security. This results in a convenient implementation at the cost of custodial and centralization risks since users do not have sole control of their keys, which are stored (usually in whole) by a centralized third party. As such, KMS+SSS can be seen as even riskier than typical SSS implementations.
Comparing SSS to MPC-TSS (Multi-Party Computation with Threshold Signature Schemes)
Threshold Secret Sharing (TSS) is a cryptographic method where a secret is simultaneously generated and separated into multiple shares. As such, the secret as a whole is never fully present, even at generation. With TSS, a given number of shares (a threshold, e.g. 3/5) can be computed together to generate a signature without the secret ever being reconstructed.
MPC-TSS ensures that the secret is never present at a single location nor held by any entity. TSS is also flexible, as the threshold can be adjusted based on the desired level of security and trust. Keys can also be refreshed in a distributed manner. Combining MPC and TSS enhances the security and privacy of the computation process. It is particularly useful wherever data sharing and privacy-preserving computations are critical, making it ideal for managing cryptographic keys. MPC-TSS provides essential features for managing private keys securely and flexibly.
The below table showcases the strengths and weaknesses of different private key management systems:
Particle Network’s MPC-TSS system for private key management
Particle Network provides a 2/2 advanced TSS approach that ensures that the private keys’ security is never concentrated in a single location or entity throughout its lifecycle. This method involves distributedly generating two independent shares, stored separately, ensuring that each share reveals nothing about the full key, even upon signature generation. Of these shares, one is stored locally by the user, and the other by Particle’s Trusted Execution Environment. All cryptographic operations are executed without combining these shares, maintaining key integrity.
Particle also opens the possibility for the user to create a Master Password, used to encrypt their local key fragment, thereby further increasing security by introducing an encryption layer on top of the initial social login. This allows users to safely restore their wallets across devices with full security. The system's robustness is also reinforced by a continuous key share refresh mechanism, enhancing security and making an attack virtually impossible.
Shamir's Secret Sharing is commonly used for private key management by Wallet-a-a-Service solutions but falls short in terms of robustness and security. This makes its usage dangerous for managing cryptographic keys.
Its major drawback in this particular use case is due to the need to reconstruct the secret upon signatures, which recurringly opens attack verticals. Contrary to common belief, SSS isn't a Multi-Party Computation solution; it's more about secure storage than private computation.
In the context of cryptographic key management, combining SSS with MPC itself or Key Management Systems does not necessarily make the solution safer. In the latter case, it also adds custodial and centralization risks.
In contrast, Multi-Party Computation with Threshold Signature Schemes (MPC-TSS) offers a secure alternative. This method, utilized by solutions like Particle Network, replaces the key with distributed shares, ensuring that no single entity has complete access without ever reconstructing the secret for signatures. Particle Network's approach, which combines a 2/2 TSS with a continuous key share refresh mechanism and an optional Master Password, provides a robust, secure, and user-friendly solution for private key management, especially in contexts where security and flexibility are paramount.
Particle Network's Modular Smart Wallet-as-a-Service solutions are 100% free for developers and teams. If you have any inquiries about integrating with us, feel free to book a meeting with one of our agents!
About Particle Network
Particle Network is building the Intent-Centric Access Layer of Web3. Particle's Modular Smart Wallet-as-a-Service tools allow developers to tap into MPC-TSS and social logins to enable self-custodial, dApp-embedded wallets accessible through users' Web2 accounts. This also allows them to leverage ERC-4337 account abstraction, enabling a seamless experience with maximum flexibility. Similarly, Particle Network has already released the first-ever account abstraction protocol for the Bitcoin ecosystem, BTC Connect. Particle's next evolutionary steps include the introduction of Omnichain Abstraction, a Confidential zkStack, and the Intent Fusion Protocol, elevating users' experience within dApps and paving the way for mass Web3 adoption.