HackMDThis document is a technical description of Web3Auth's MPC infrastructure and its interactions with applications. Its a high-level document, Web3Auth reserves the right to make changes to this document as needed.
It is part of a set of documents that describes Web3Auth, others that maybe helpful include:
Introduction
With the growth of cryptographic applications, key management has become increasingly important. Mismanagement of private keys often results in considerable financial loss, and as usage of private keys become increasingly mainstream key loss and misuse will become even more prevalent and costly.
Many existing non-custodial key management solutions present users with trade-offs between security, convenience, and redundancy. For example, backing up your key increases redundancy during key loss, but reduces security if that backup is stolen. Multisig wallets provide a balance of all three, but are more costly to deploy, are less private, and are not cross-chain.
The Web3Auth is non-custodial key management infrastructure powered by MPC that acts as an multi-factor account that solves these problems. In order to achieve its goals of serving the global Web3 market, the network needs to meet the following design goals:
- Seamless non-custodial key management user experiences
- Compatible with existing authentication methods and blockchain ecosystems
- Performant globally, and scalable as necessary
Definitions of utilized schemes and concepts
We provide definitions of concepts and schemes which we use later on.
Shamir Secret Sharing (SSS) and Verifiable Secret Sharing (VSS)
Shamir's secret sharing scheme is a polynomial threshold \((t,n)\) secret sharing scheme where a dealer divides a secret into \(n\) multiple shares and each participant is given a share by evaluating a polynomial of order \(t\). To reconstruct the secret, \(t+1\) shares are required. Verifiable secret sharing refers to Shamir secret sharing schemes where even in the presence of malicious dealers, there is a well-defined secret that the participants can later reconstruct.
SSS is a base fundemental in a lot of MPC cryptography and in Web3Auth's infrastucture. More can be read here.
Distributed Key Generation (DKG)
Distributed key generation was introduced by Pedersen, and the key idea involves using \(n\) parallel runs of SSS or VSS to ensure that there is no dealer who knows the secret. We generally use a varient of Async Verifiable Secret Sharing in our DKG.
Proactive Secret Sharing (PSS)
Proactive secret sharing allows participants to "refresh" shares, so that all participants receive new shares, but the secret remains unchanged. This allows the secret sharing to be secure against mobile adversaries who may be able to compromise all participants over the lifetime of the secret (eg. adversary hacks a random participant's server every month).
We refer the user to a proactive secret sharing scheme that supports dynamic sets of participants, which we use for share refresh.
Threshold Signature Schemes (TSS)
Threshold signature schemes refer to signing schemes that allow a qualified set of parties involved in a secret sharing scheme to generate a signature on a message without reconstructing the private key. The most well-known signature scheme is GG19 and an implementation can be found here. In particular Web3Auth supports and utilizes GG19, GG20, its EDDSA variants, and DKLS19.
Image Not Showing
Possible Reasons
|
|---|
User Personal Key Architecture
Web3Auth manages its user keys in a distributed manner utilizing different factors(or shares) that users manage including user's devices, private inputs, backup locations and cloud service providers. As long as a user has access to 2 out of n (2/n) of these shares, they will be able to access their key. This distributedly secure key is called the \(TSSKey\).
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
One of the lost functionalities of a distributedly secure key is the loss of efficient encryption/decryption capabilities. For that reason, we use an optimised dual key structure for managing keys: the \(TSSkey\) that is used for signing transactions that is never reconstructed, and a \(metadataKey\) for managing metadata (which is reconstructed). Using this setup allows us to get the security of threshold signatures when it's necessary for signing transactions, but still leverage the faster performance of key reconstruction for updating and reading private user metadata.
Image Not Showing
Possible Reasons
|
|---|
Metadata
User metadata is strictly supplementary and only helps to facilitate and govern user flows. In particular, metadata does not leak information about the shares of the private key being used to sign transactions.
Metadata uses an encrypted storage layer that serves as a persistent data store for storing encrypted information about the user's keys (eg. public key, preferences, device information, thresholds etc). This information is stored in a replicated fashion across the set of nodes that are involved in facilitating the user login.
During operation, when the user has threshold shares, they can read and write to metadata. Writing to metadata requires encrypting the data and signing it with the shares / private key.
Web3Auth's Infrastructure Highlevel Overview
Web3Auth's infrastucture is designed to manage a factor of a key for hundreds of millions of users. It utilizes a distributed security model that is inspired from Apple's iCloud and other highly performant distributed systems. The design of it revolves around achieving high guarantees for:
- A distributed multi-setup security model
- Close to 100% uptime
- Upscales and downscales to cater to spikes in load
In order to meet these objectives, Web3Auth's Infra is designed to be a set of nodes.
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
Web3Auth Infrasturcture secures a factor of a users key
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
Architecture of a Node
t of n Distributed Model for Security and Uptime
These nodes operate in a t of n security model, a user's factor (share) is further split into sub-shares and secured individually by each of these nodes. Threshold(t) number of nodes are able to sign signatures for users.
In order to compromise this setup, one must compromise a total t of n setups. Similarly in order for the services to go down, n-t setups must go down (i.e. 2 nodes in a 3/5 setup). This is on a technical level very unlikley.
Regionally available services
Signatures and login services are often expected to be low-latency sub 1.5s interactions from the user. To achieve that level of latency, each node operates clusters of instances in regions across the world. This includes operations in US-east, west, Singapore, South America, Africa, Europe east and west and ultimately is flexible.
Horizonally scalable for billions
In each node, in each regional cluster, there runs an orchestration layer that operates multiple services. Services are spun up and down in different regions to cater to the load necessary for global applications.
These clusters is orchistracted via a master coordinator that communicates with different nodes to understand the load that they should be receiving and coordinate on a distributed level.
Load expectation via Verifiers
Verifier contracts define the relationship between infrastructure and applications. It contain information about authentication parameters, as well as supported methods for users. It acts as a long standing agreement between the application and nodes, and serves as a central point of reference for wallet front-ends that implement the user transaction functionality. It is also in charge of the submission and validation of user transactions (which is dependent on the authentication protocol parameters).
Detailed User Interactions
Below we describe the main interactions with the user:
- SessionRequest | A user's intial interaction/login
- KeygenRequest | Key generation/setup for a user
- ThresholdSignRequest | Usage of the user's assigned key/s
- Reshare/Revoke | Changing the parameters of a user's account setup, in a distributed manner
SessionRequest
Session request is the intial interaction that any user does with a node before interacting with further interactions. Its not unsimilar to standard authentication to backend services, but does include a commit vs reveal phase to prevent against front-running attacks from other nodes.
The result of the session request is a token, that in combination with the session key is used to interact with the infra from there on out.
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
SessionRequests are specific to different applciations and are agnostic to most implementations of authentication, including but not limited to OAuth2.0, OIDC, ECJWTs and most forms of FIDO.
Key generation & importing keys
Keys can be distributedly generated OR imported into the ecosystem. Below describes the former interactoin with users where after session authentication, key generation is conducted with a series of round interactions:
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
This is done differently for the import of a key. When importing a key, the nodes interact with one another to do a DKG seperate from the user, the user then retrives the public key for this distributed secret, and creates a second share with respect to it on the client side.
Threshold Signature Scheme (TSS)
The TSS key is made up of two sections:
- shared information (eg. public key, share commitments, theshold, unique identifiers)
- local information (eg. TSS key share).
The shared information is stored on metadata and replicated, whereas the local information is kept locally on the user's device. This ensures that metadata for shared operations can be easily replicated and accessed without computationally expensive calls, while for local operations the TSS key shares never leave the local context.
Constructing a threshold signature requires a session token which we can get via the session request. This then allows us to set up a threshold signature session. The threshold signature session consists of and offline signing phase and an online signing phase (GG20, GG19, Doerner19).
The offline signing phase consists of 6 rounds of interaction between the device and nodes and can be pre-computed before the transaction signing request is received. The online signing phase requires the transaction to be present and is non-interactive.
This means that although the threshold signature generation takes a substantial amount of time, most of it can be precomputed via a background process, before the user even needs to sign a transaction. When the user decides to sign a message in the online phase, only one round of noninteractive communication is required, which is very fast (<0.2 seconds).
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
Resharing and revokability
Users can reshare current secrets kept with the node set. This is done via Proactive Secret Sharing, in particular the variant used here is PSS via AVSS an async method of doing so.
Below describes the interaction, between user and nodes in this particular transaction. You'll find its quite similar to key generation in its rounds, they are similar schemes:
Offline revokability is also something that is inherited from the inital version of tKey. How its implemented is similar as well, only difference being in the above interaction the key is never reconstructed on a front-end context. For reference, the snippet from the tkey doc is reiterated here:
Using metadata for share resharing and revokability
Utilizing the storage layer, we are able to generate new shares for all devices, regardless if they are online or offline. This allows us to remove devices from the sharing, allow the user to change their security questions and/or adjust their security threshold. The key concept here is utilizing published Share commitments as encryption keys to retrieve shares on the most updated SSS polynomial.
This is illustrated from a 2/4 SSS sharing \(f(z)\) with shares \(s_a, s_b, s_c, s_d\) kept on 3 user devices and the service provider. Let \(g\) be a generator of a multiplicative subgroup where the discrete log problem is assumed hard to solve. During initialization of the key we create share commitments \(g^{s_a}, g^{s_b}, g^{s_c}, g^{s_d}\) to be stored on the storage layer. These share commitments are analgous to public keys derived from the share scalars.
Given the user loses device D holding \(s_d\), and wants to make that share redundant. He/she first reconstructs their key on device A. We utilize a public key based encryption scheme (eg. ECIES).
The user generates a new 2/3 SSS polynomial \(h(z)\) on the same \(\sigma\) with shares \(s_1, s_2, s_3\) and encrypts the newly generated shares for each respective share commitment, except for the lost \(g^{s_d}\) commitment.
\[\text{for }i = \{1,2,3\} \text{ and } v = \{a,b,c\} \\ encrypt(s_iu,g^{s_v}) \Rightarrow c_{nv} \\ \text{where } nv = \{1a,2b,2c\}\]
\(c_{nv}\), the resulting ciphertext from the encryption, is then stored on the storage layer for retrieval on other devices.
On login to device B, the user retrieves \(c_{2b}\) is able to use \(s_b\) to decrypt the new \(s_2\) and reconstruct their key with \(s_1\) derived from the service provider in a similar fashion. Using the \(h(z)\) allows \(s^d\) to also be deprecated as a share.
Resharing allows us to share a key on a new polynomial with a different degree/threshold, allowing us to also increase a user's security/factor devices or inputs to reconstruct thier key as they require it. This can be incrementally done as needed.
Cryptographic and blockchain support (compatibility and implementations)
Web3Auth supports most popular blockchains & elliptic curves out there. In particular, out of the box the infrastucture supports all chains on:
secp256k1| Ethereum (EVM) chains, Bitcoin, Polygon & other L2s, etc…ed25519| Solana, Polkadot, NEAR
For other elliptic curve/chain support, feel free to ask/request as we may already support them.
Distributed Key Generation & Pro-active Secret Sharing Scheme References
There are many schemes and variants for DKGs and PSSs out there, we in particular use an asynchronous variant, Kate12, derived from Asynchronous Verifiable Secret Sharing (AVSS), Cachin02.
TSS & Signature References
TSS schemes often vary in their approach to creating shared cryptographic material in a distributed manner. We support the popular GG19, GG20, EDDSA, and DKLS19. In result supporting the ecdsa signature standard on both elliptic curves.
Its worth noting that the TSS signing is largely decoupled from Web3Auth's infrastucture to allow us to be agnostic to TSS implementation. These include other signature schemes, which arguably are much more convienent. Notably, but non-exhaustively, Web3Auth supports:
- ECDSA or its ElGamal variants
- EDDSA or its Schnorr variants
- BLS, Stark (coming soon)
Image Not Showing
Possible Reasons
|
|---|
Privacy, User Data and Compliance
Web3Auth's takes a conservative approach to data collection. The only required stored data is a relationship of an anonymised identifier from the OAuth or JWT that is pegged up into the infrastucture.
This is often the required sub field on the JWT RFC, which applications have the option of storing outright or storing a Hashed value of sub. This relationship is first created on initial key generation/assignment and later utilized to authenicate the specific public key and session token to the user's end device.
Security Extensions
By limiting the base transaction types and functionality we can limit the complexity of the system and thus provide better guarantees on safety and liveness. The aforementioned functionality is sufficient for generic threshold cryptography operations.
However, we fully intend to extend the capabilities of our system to support other interesting use cases. We make provisions for these types of extended functionality using "extensions" that reuse the existing interfaces that have already been defined.
Additional verification / checks
Additional dynamic transaction verification / message validation can be done during the SessionRequest or SignRequest phase by each one of the nodes to reduce the impact of phishing attacks or scams. Smart contract wallet rules like spending limits can also be implemented in this way.
User defined access structures
Although the default nodeset is defined by the application, the user may want to control this access. One way we can provide this functionality is by implementing a proxy contract in front of the parameter lookups that happen at the start of SessionRequest, with this proxy contract being user-controlled.
