Unveiling the Salt Server Architecture of zkLogin by Mysten Labs

Mysten Labs unveils the salt server architecture behind zkLogin, ensuring secure and private identity management for Web3 applications.

Mysten Labs has unveiled the salt server architecture for its zkLogin authentication mechanism, ensuring secure and private identity management for Web3 applications.

The architecture, described in a recent post on The Sui Blog, is designed to maintain the integrity and privacy of user identities in the Web3 space.

zkLogin is a Sui primitive that offers a trustless, secure, and user-friendly authentication mechanism for Web3. It allows developers to integrate familiar Web2 login methods, such as Google or Facebook, to enable users to effortlessly create and manage Sui addresses.

A critical component of zkLogin is the salt server, which generates, stores, and provides a unique salt value whenever a transaction is initiated. This salt value ensures that onchain addresses can't be traced back to the user's Web2 credentials.

At Mysten Labs, the salt server operates in a secure computing environment to protect the master seed, which is used in combination with the user's JSON Web Token (JWT) to derive a reproducible salt value per user per app. The protection of the master seed is crucial to maintaining the separation of Web2 identities from Sui addresses.

To achieve this, the salt server runs within isolated, trusted compute environments like AWS Nitro Enclaves, ensuring that the master seed is safeguarded from both internal and external threats.

Mysten Labs also highlights the use of trusted compute infrastructure to host the salt server, with options such as Azure Confidential Computing, GCP Confidential VMs, and AWS Nitro Enclaves, which provide isolated computing environments. In this case, Nitro Enclaves were chosen for their ability to run the server in an isolated environment with container attestation, allowing access only over TCP directly through to the service's endpoints.

The master seed, generated only once, is created in a secure, isolated environment to ensure its randomness and security. The seed is then encrypted and stored in a secrets store, accessible only by the enclave identity. This process ensures that no administrator or external party can access the plaintext secret.

The salt server uses the seed to generate salt values for each transaction request, maintaining the confidentiality of the user's Web2 credentials.

To mitigate the risk of seed loss, Mysten Labs has implemented a seed recovery plan using Unit 410's Horcrux utility. This method involves splitting the seed into multiple encrypted shards, which are stored redundantly in various remote servers.

These shards can be decrypted using a subset of the shards, ensuring that the master seed can be securely recovered in a disaster scenario.

The salt server architecture at Mysten Labs is designed to strike a balance between security and operational flexibility. While the use of Nitro Enclaves provides robust protection, it also introduces operational challenges, such as managing network proxies and maintaining a constrained environment.

As Mysten Labs continues to develop and expand its zkLogin implementation and other Web3 constructs, the architecture will be refined to meet the evolving needs of the ecosystem.

The broader goal is to ensure that Web3 applications can integrate user-friendly and secure authentication mechanisms, empowering users to easily and safely participate in the decentralized web.

The above is the detailed content of Unveiling the Salt Server Architecture of zkLogin by Mysten Labs. For more information, please follow other related articles on the PHP Chinese website!