seal

How it works

Markdown

The pieces

Every part of Seal, who runs it, and what each one can and can't see.

Only two pieces can open a blob, the enclave and the key guardian. Both run in hardware TEEs, and you can check their code. Everything else carries encrypted or signed data that those two check.

Click a piece to see what it does.

Enclave

Runs
Seal runs one for you, or you run your own in your Azure network. Either way inside an AMD SEV-SNP chip.
Does
Seals, opens blobs, checks each app's identity against your grants, adds the key to requests, masks it in responses and signs telemetry.
Sees
Your keys, while it uses them. Nothing outside the chip can look in, including its host.
Talks to
, (key added), (keys), (state in, telemetry out)
Trust
Trusted code, checked: your SDK verifies its fingerprint on every connection.
FigureClick any piece to see what it does and whether you need to trust it. Lit lines are its connections.

How a secret gets sealed#

seal secret checks the enclave's attestation first. Then it encrypts your key on your machine, to a key only that enclave holds. The enclave sends back a blob, and you store it wherever you like. Seal doesn't store blobs. See Sealing a secret.

How a request flows#

session(blob) checks the enclave, then proves your app's identity, such as its Azure managed identity. The enclave checks it against your grants.

Your code calls the SDK's local URL with a stand-in key. The enclave swaps in the real key, calls the upstream and masks the key in the response. See Using a blob.

How replicas stay current#

A replica keeps nothing on disk. While it runs:

  • At boot it proves its build to the key guardian and gets your tenant's keys.
  • Every 30 seconds it fetches your tenant's signed state and checks it. A removed grant cuts open sessions within about 30 seconds.
  • Every 5 seconds it signs and ships a batch of telemetry.

If it can't get a fresh state for 24 hours (the default), it stops serving. Every call then fails with Unavailable.

Who runs it, and do you trust it#

Your app and the SDK
Who runs itYou
Trust it?It's yours. Seal assumes it can be taken over.
Enclave replica
Who runs itSeal, or you in your Azure network
Trust it?Its code, which your SDK checks. Not its host.
Front door
Who runs itSeal
Trust it?No. It sees only encrypted traffic.
Key guardian
Who runs itSeal
Trust it?Its released code, and Microsoft's Key Vault.
Control plane
Who runs itSeal
Trust it?No. Everything it serves is signed.
Transparency log and witnesses
Who runs itSeal runs the log. Witnesses are meant to be independent.
Trust it?No. You check the signatures.
Registrar
Who runs itSeal
Trust it?Only to create your tenant. A look-alike tenant opens none of your blobs.
Console
Who runs itSeal
Trust it?No. It holds no admin keys.
CLI
Who runs itYou
Trust it?It checks everything with keys built into it.
Upstream
Who runs itYour provider, or you
Trust it?As much as before Seal.

What you trust#

  • The hardware. AMD SEV-SNP chips in Azure confidential containers, and their attestation. See Enclaves and attestation.
  • The released code. Each enclave and guardian release builds reproducibly, needs two of three release keys and waits in the public log first. See Releases and the log.
  • Microsoft's Key Vault. It releases the guardian's master key only to the guardian's exact build.

The rest can stop things working, for example by switching off a replica. None of it can read your key or grant access. See What an attacker gets.