seal

Security

Markdown

What an attacker gets

Pick an attacker, from someone with root on your server to Seal itself, and see what they can and can't do.

Only the enclave holds your key in readable form, and only uses it on the sealed destination. An attacker can still use the key through the enclave, deny service or see metadata.

Can

  • Read the blob, the stand-in key and the app's identity
  • Make requests through the enclave as your app, while they hold the server

Can't

  • Get the key itself
  • Send it anywhere but the sealed destination
  • Use the blob as another app
  • Keep access once you remove the grant

Do thisUse cloud identities, least-privilege keys and network rules. Remove the grant and the access ends.

FigurePick who you're worried about. The key itself never leaves the chip in any of these cases.

Root on your app server#

Someone takes over your app's machine. Seal is built for this.

Can

  • Read the blob and your app's identity.
  • Make requests as your app, doing anything the key allows at the upstream.
  • Use copied credentials elsewhere until they expire, unless a network rule blocks them.

Can't

  • Get the key. The enclave masks it in responses.
  • Send it anywhere but its sealed destination.
  • Keep going within about 30 seconds of you removing the grant.

What to do. Limit the key's permissions upstream, seal with --deny, and on a breach run seal revoke app.

Root on the enclave's host#

Whoever controls the cloud account a replica runs on, Seal's or yours.

Can

  • Stop or delete the replica.
  • See who connects, when and how much.
  • Control its network, so network rules don't stop them.

Can't

  • Read the enclave's memory.
  • Open a shell or attach a debugger.
  • Find a key on disk. There's none.

What to do. Run several replicas, each listed in SEAL_ENDPOINT.

Seal's servers or staff#

Seal itself, someone who broke into Seal, or Seal's cloud admins.

Can

  • Withhold your state until replicas fail closed, or replay an old one within the freshness window.
  • Read your telemetry, unless you set telemetry readers.
  • Create a look-alike tenant. It opens none of your blobs.

Can't

  • Read your keys, or forge your state or telemetry.
  • Grant anyone access.
  • Ship a leaky enclave without it sitting in the public log first.

What to do. Set telemetry readers and run seal status --log now and then. See Releases and the log.

Your console account#

Someone signs in as you, copies your seal login token, or Seal serves a malicious console page.

Can

  • See what you see and propose changes.
  • Stop Seal's replica, as an owner or manager.
  • With a malicious page, show you one change and get your passkey to sign another.

Can't

  • Sign a change. The console holds no admin keys.
  • Apply a widening change before the pending window ends.
  • Hide a change from the log or the CLI watching it.

What to do. Set a pending window and run seal changes --watch yourself.

A stolen admin key#

Someone copies a key file or takes over a passkey's account.

Can

  • Submit changes alone, with a threshold of 1.
  • Narrow access at once, such as removing your apps.
  • With a threshold of 1, propose an admin list your other admins can't cancel.

Can't

  • Apply a widening change before the pending window ends.
  • Submit anything alone with a threshold of 2.
  • Read a sealed key.

What to do. Keep two admin keys on different devices, with a threshold of 2.

Hardening checklist#

  • Give each key the smallest upstream permissions, and seal with --deny for key-management paths.
  • Use cloud identities with seal grant network rules.
  • Keep two admin keys and a threshold of 2.
  • Set a pending window.
  • Run seal changes --watch.
  • Seal with --expires.
  • Set telemetry readers.
  • Seal with the CLI, not the console.