Exploring the Salt Server Architecture of zkLogin by Mysten Labs


Rongchai
Wang


Aug
16,
2024
05:00

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

Exploring the Salt Server Architecture of zkLogin by Mysten Labs

Mysten
Labs
has
introduced
a
robust
salt
server
architecture
for
its
zkLogin
authentication
mechanism,
focusing
on
maintaining
the
integrity
and
privacy
of
user
identities
in
the
Web3
space,
according
to

The
Sui
Blog
.

zkLogin
and
Salt
Servers

zkLogin
is
a
pioneering
Sui
primitive
offering
a
trustless,
secure,
and
user-friendly
authentication
mechanism
for
Web3.
It
allows
developers
to
enable
users
to
sign
on
with
familiar
Web2
credentials,
such
as
Google
or
Facebook,
to
create
and
manage
Sui
addresses
effortlessly.
A
critical
component
of
zkLogin
is
the
salt
server,
which
generates,
stores,
and
supplies
a
unique
salt
value
whenever
a
transaction
is
initiated.
This
salt
value
ensures
that
onchain
addresses
cannot
be
traced
back
to
the
user’s
Web2
credentials.

Operational
Security
at
Mysten
Labs

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
master
seed’s
protection
is
paramount
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.

Trusted
Computing
Systems

Mysten
Labs
employs
trusted
compute
infrastructure
to
host
the
salt
server.
Options
like
Azure
Confidential
Computing,
GCP
Confidential
VMs,
and
AWS
Nitro
Enclaves
provide
isolated
computing
environments.
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.

Seed
Generation
and
Usage

The
master
seed,
generated
only
once,
is
created
in
a
secure,
isolated
environment
to
ensure
its
randomness
and
security.
The
seed
is
encrypted
and
stored
in
a
secrets
store,
accessible
only
by
the
enclave
identity.
This
process
prevents
any
administrator
or
external
party
from
accessing
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.

Seed
Recovery

To
mitigate
the
risk
of
seed
loss,
Mysten
Labs
employs
a
seed
recovery
plan
using
Unit
410’s
Horcrux
utility.
This
method
involves
splitting
the
seed
into
multiple
encrypted
shards,
stored
redundantly
in
various
remote
servers.
These
shards
can
be
decrypted
using
a
subset
of
the
shards,
ensuring
that
the
master
seed
can
be
recovered
securely
in
a
disaster
scenario.

Trade-offs
and
Future
Considerations

The
salt
server
architecture
at
Mysten
Labs
is
designed
to
balance
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.
Mysten
Labs
remains
committed
to
upholding
high
security
standards
as
it
continues
to
develop
and
expand
its
zkLogin
implementation
and
other
Web3
constructs.

This
architecture
showcases
Mysten
Labs’
dedication
to
solving
foundational
problems
in
the
Web3
space,
ensuring
that
their
systems
are
secure
and
privacy-preserving,
bringing
the
benefits
of
Web3
to
a
broader
audience.

Image
source:
Shutterstock

Comments are closed.