Salt servers are fundamental to zkLogin, ensuring the integrity and privacy of user identities. This architecture protects the critical link between Web2 credentials and Sui addresses, maintaining a secure and seamless authentication experience.
What Is zkLogin and Why Salt Matters?
zkLogin is a native feature of Sui, offering a trustless, reliable, and user-friendly authentication mechanism in Web3. It enables developers to create smooth onboarding experiences by allowing users to create and manage Sui addresses using familiar Web2 credentials like Google or Facebook.
When signing a transaction for a zkLogin address, a unique salt value must be provided. This salt represents the OAuth or Web2 credentials linked to the Sui address and is essential for ensuring that on-chain addresses cannot be traced back to the user’s Web2 identity. Salt servers generate, store, and provide this salt value each time a transaction is initiated.
Developers have multiple options for generating and storing this salt, whether client-side or server-side. However, protecting the salt—and the master key mnemonic used to derive it—is critical for maintaining user privacy.
How Salt Servers Work
At Mysten Labs, our salt server uses a master key mnemonic combined with the user’s JSON Web Token (JWT) to derive a repeatable, unique salt value per user and per application. This process includes validating the JWT from the provider.
Here’s a step-by-step breakdown:
- A user enters their Web2 credentials into a zkLogin-enabled application.
- The application requests a JWT from the authentication provider.
- The JWT is sent to the salt server to retrieve the salt value.
- The salt is used to generate the zkLogin proof and compute the user’s Sui address deterministically.
This ensures the user’s address can be calculated from their token without revealing the connection between the two.
Core Security Goals for Salt Servers
Protecting the master key mnemonic involves three primary objectives:
- Secure Generation: The key must be generated in a safe, automated manner without human involvement.
- Isolation: The key should be inaccessible to anyone inside or outside Mysten Labs.
- Protection from Side-Channel Attacks: The system must guard against external exposure via service or cloud provider vulnerabilities.
If the key is only visible to the salt server—and no other person or system—we can be confident in its confidentiality and the validity of the hash mapping from JWT to on-chain address.
Implementing Trusted Computing
To meet these goals, we use trusted computing infrastructure. While hardware security modules (HSMs) or trusted platform modules (TPMs) offer robust hardware-level security, they introduce a single point of failure. Losing access to the hardware means losing the master key permanently.
We chose a balanced approach using AWS Nitro Enclaves, which provides an isolated computational environment through container attestation. Nitro Enclaves allow us to:
- Run the server in an isolated environment.
- Restrict network access to only essential endpoints.
- Use existing container images and build tools.
Other major cloud providers offer similar solutions, such as Azure Confidential Computing and GCP Confidential VMs.
Generating the Master Key Mnemonic
The master key mnemonic is permanent and irreversible, so its generation occurs only once. We prioritize automation to eliminate human involvement and potential vulnerabilities.
Inside the Nitro Enclave, we:
- Generate randomness to create the mnemonic.
- Encrypt the mnemonic using a cryptographic key.
- Store the key in a secret storage accessible only by the Enclave.
- Split the key into encrypted fragments for recovery purposes.
A simplified shell script within the Enclave handles this process:
./generate-random-seed > seed.json
secrets-store put -name SEED -file seed.jsonNetwork access is tightly controlled using a vsock proxy, allowing inbound traffic only through a single application port and outbound traffic solely to OAuth providers for JWT validation and monitoring gateways.
Key Recovery Plan
Despite robust protections, storing secrets with a single cloud provider carries risks. We implement a recovery plan using Horcrux, a tool based on Shamir’s Secret Sharing scheme.
The process involves:
- Splitting the mnemonic into encrypted fragments.
- Encrypting each fragment with hardware keys held by team members.
- Storing fragments redundantly across multiple remote servers.
This ensures geographical distribution and rapid, secure recovery in case of disaster.
Trade-offs and Considerations
Our salt server architecture differs significantly from typical services due to its security constraints. Key trade-offs include:
- Operational Complexity: Running services in Nitro Enclaves adds operational challenges.
- Network Attack Surfaces: Each network proxy introduced to the Enclave represents a potential attack vector. We minimize this by limiting traffic to essential endpoints.
- Simplicity Over Features: The salt server must remain simple. Integrating new tools or communications with other services requires careful consideration of security implications.
We maintain a strictly limited environment to protect this critical component of zkLogin.
Best Practices for Secure Salt Management
For developers implementing salt servers, consider the following:
- Use Trusted Environments: Leverage confidential computing options like enclaves or HSMs.
- Automate Key Generation: Eliminate human involvement in critical processes.
- Implement Redundant Recovery: Use secret-sharing schemes for disaster recovery.
- Monitor Network Access: Restrict inbound and outbound traffic to only necessary endpoints.
👉 Explore secure key management strategies
Frequently Asked Questions
What is a salt value in zkLogin?
A salt is a unique value used to ensure that a Sui address generated via zkLogin cannot be linked back to the user’s Web2 credentials. It is essential for maintaining privacy.
Why is the master key mnemonic so important?
The master key mnemonic is used to derive the salt value. If compromised, it could reveal the link between Web2 identities and Sui addresses, violating user privacy.
How does Nitro Enclaves enhance security?
Nitro Enclaves provide an isolated computational environment, ensuring that the master key mnemonic is inaccessible to anyone—including cloud providers and internal administrators.
Can I run a salt server without trusted hardware?
While possible, it increases risk. Trusted computing environments like enclaves or HSMs are recommended for protecting sensitive keys.
What happens if the master key is lost?
Without a recovery plan, losing the master key means permanent loss of access to derived salts. Using secret-sharing schemes ensures recoverability.
Is zkLogin compatible with all OAuth providers?
zkLogin supports major OAuth providers like Google and Facebook. Adding new providers requires validating JWTs and integrating with the salt server.
Conclusion
zkLogin’s salt server architecture is designed with security as the top priority. By combining trusted computing environments like AWS Nitro Enclaves with robust key management and recovery practices, Mysten Labs ensures that user identities remain private and secure.
This approach demonstrates a commitment to maintaining the highest security standards while bringing the benefits of Web3 to a broader audience. As the ecosystem evolves, we continue to innovate in ways that prioritize user safety and cryptographic verifiability.