Web3Auth MPC Architecture

This document provides an in-depth exploration of the technical architecture of the MPC-based SDKs, this includes the tKey MPC SDK and CoreKit MPC SDK (a rundown of our SDKs here).

The only difference between the SSS-based SDKs and MPC SDKs are that during usage/login MPC SDKs do not reconstruct user private keys.

While the tKey MPC SDK, supports multiple configurations like 2/n, 2/2 flows, this documentation, for simplicity, focuses on a 2/3 setup.

Overview of 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 Schemes Used

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 Schemes Used

TSS schemes often vary in their approach to creating shared cryptographic material in a distributed manner. We support the popular EDDSA, and DKLS19. In result supporting the ecdsa signature standard on both elliptic curves.

It's 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)

📝 For other signature or elliptic curve or chain support, feel free to ask or request if we support them

User Key Overview

Web3Auth uses tKey MPC to manage user wallets in a distributed fashion, leveraging various factors or shares managed by users, including their devices, private inputs, backup locations, and cloud service providers. As long as a user can access 2 out of n (2/n) of these shares, they can access their key. This distributedly secure key is called the $TSSKey$.

One of the lost functionalities of a distributedly secure key is the loss of efficient encryption/decryption capabilities. As such the TSSKey is supported by another cryptographic key that's main purpose is to manage metadata pertaining to the user's account, the metadataKey. 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 TSSKey being used to sign transactions.

TSS Key

The user's setup starts by distributedly key generating (DKG) a 2 out of 3 (2/3) sharing, $f_0(x) = a_0 + a_1x$, with three shares: $f_0(1), f_0(z_1), f_0(z_2)$ where $z_1,z_2 \in \mathbb{Z}_q$.

1. $f_0(z_1)$ "ShareA" is managed by Web3Auth infrastructure: This share is kept and managed by OAuth authentication flows in a distributed security model.
2. $f_0(1)$ "ShareB" is stored on the user's device: Implementation is device and system specific. For example, on mobile devices, the share could be stored in device storage secured via biometrics.
3. $f_0(z_2)$ "ShareC" is a backup share: An extra share to be kept by the user, possibly kept on a seperate device, downloaded or based on user input with enough entropy (eg. password, security questions, hardware device etc.).

The Metadata Key

This key's storage process mirrors that of the TSSKey, with the primary difference being that the metadataKey is always reconstructed and used for encryption/decryption tasks. It's based on the fundamental Shamir’s Secret Sharing scheme and initially generated on the user's front-end. Readers can further reference tKey v1 flows used by the metadataKey in our SSS Infrastructure Documentation.

Other components

Factor Keys

Factor keys enable refreshing, setting up multiple keys, deletion, and rotation capabilities on the TSSKey. They are randomly generated across various user-controlled locations or factors, such as their phone, chrome extension, cloud, or assisting third parties. Primarily used for data encryption/decryption, these keys provide a constant secret in different locations as shares to the TSSKey and/or metadataKey may rotate. They represent a storage point with a public address that we can encrypt data blobs for.

User 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.

Flows

This segment goes through some of the interactions on a deeper level.

Components

• Web3Auth Infrastructure: Web3Auth infrasturcture provides a user-specific share/factor based on some form of attestation from the user. This attestation could come in the form of an OAuth login from an existing account, a traditional email account login, or even biometrics. It also serves as a persistent data store for storing encrypted metadata, we also call this the metadata layer in following diagrams.

• User device: tKey is dependent on user devices to store shares. The base flow accomodates a single device, but users can use multiple devices to increase the threshold once they have an initial setup. Access to device storage on the user's device is implementation specific. For example, for native applications on mobile, they can make use of the device keychain.

• Backup factor/share: This is generally not used during normal operation, and is intended for use in key recovery / share refresh if the user loses his/her device or shares.

Key initialization

A key is initialized upon a user-triggered action (eg. login to nodes). We then attempt to retrieve associated metadata for the user. If none exists, the user is a new one and we generate a corresponding SSS 2/3 polynomial with its respective key and shares. If it exists, we decrypt the metadata using the nodes $encKey$ and read the metadata to verify user information and associated secret sharing parameters.

We select a polynomial $f(z)$ over $Z_q$ where: $f(z) = a_1z + \sigma$

• $f(0) = \sigma$ denotes the private key scalar to be used by the user
• $a_1$ is a coefficient to $z$
• $f(z_1),f(z_2)$ and $f(z_3)$ are ShareA, ShareB and ShareC respectively

ShareA is stored on the user’s device, ShareB stored on Web3Auth Infrastructure, and ShareC dependent on user input or handled as a recovery share.

Key Usage, Access and Signing

If a user has logged in previously, he/she access their key by accessing ShareB via a session token handshake and utilzing it with ShareA on the user’s current device using to sign Threshold Signaures.

Threshold Signature Scheme (TSS)

The TSS signing requires information from 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 an 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).

Expanding the Number of Shares (Adding a Device)

In the case of a new device the user needs to conduct a Proactive Secret Sharing, a refresh scheme to generate a new factor in a distributed manner. This example goes through the setup on a new user’s device with an existing device in hand. This can also be conducted with a user’s backup factor, ie.e ShareC.

Share resharing and revocability

Utilizing the metadata 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 nodes. 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 metadata layer. These share commitments are analogous 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 metadata 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 nodes 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 their key as they require it. This can be incrementally done as needed.