Skip to main content

Seal / Unseal Lifecycle

The seal/unseal mechanism ensures that technical personnel cannot access cryptographic material. Even with full root access, the cosigner remains inert until unsealed by designated key holders.

State Machine​

States​

StateMnemonic in EnclaveMPC OperationsWebSocket
UNINITIALIZEDNoDisabledDisconnected
SEALEDNo (encrypted on disk)DisabledDisconnected
UNSEALINGNo (partial shares)DisabledDisconnected
READYYes (enclave memory)EnabledConnected

How Unsealing Works​

  1. The cosigner starts in SEALED state — the mnemonic is encrypted on disk
  2. The mnemonic is split using Shamir Secret Sharing into 3 shares (2-of-3 threshold)
  3. Two of three designated key holders submit their password-derived key shares
  4. The cosigner reconstructs the mnemonic in enclave memory
  5. The cosigner transitions to READY and connects to the Coordinator

The cosigner only signs transactions in READY state.

Key Holder Authentication​

Key holders authenticate using Ed25519 challenge-response:

  1. Key holder requests a challenge from the cosigner
  2. Cosigner generates a random 32-byte challenge (5-minute expiry, single-use)
  3. Key holder signs the challenge with their Ed25519 private key
  4. Key holder submits the signed challenge along with their unseal password
  5. Cosigner verifies the signature and processes the share inside the enclave

Rate Limiting​

Unseal attempts are rate-limited per key holder to defend against brute-force attacks:

  • 5 failed attempts trigger a lockout
  • Lockout uses exponential backoff: 1 min → 2 min → 4 min → ... up to 1 hour max
  • A successful unseal resets the counter
  • All attempts (success and failure) are audit-logged with key holder ID and IP address

When Re-Sealing Occurs​

The cosigner automatically returns to SEALED state on:

EventResult
Process restartSEALED
Server rebootSEALED
Software upgradeSEALED
Explicit seal commandSEALED
Unauthorized reshare attemptSEALED + disconnect

After re-sealing, two key holders must unseal again before the cosigner can participate in signing.

:::note Emergency Seal In case of emergency, any authorized operator can return the cosigner to a sealed state immediately. To resume operations, 2-of-3 key holders must unseal again. :::

Unsealing: Step by Step​

Prerequisites​

Each unseal key holder needs:

  • Unseal application — desktop app or browser extension (provided during onboarding)
  • Password — the 32-character string from setup, stored in a password manager
  • Encrypted share file — backup of the share received during setup
  • OpenGPG — for decrypting the initial password share file
  • KeePassXC or 1Password — for storing the unseal password

Process​

  1. Import the cosigner entry into the unseal application (or add manually)
  2. Verify the cosigner status is displayed
  3. Submit your share — the application handles authentication and password delivery
  4. Check that the share was accepted by the cosigner
  5. Wait for the second key holder to submit their share

Once 2 of 3 shares are submitted, the cosigner transitions to READY and begins signing operations.

Security Properties​

  • Separation of duties — infrastructure operators (who deploy and maintain the cosigner) are distinct from key holders (who can unseal it). Neither role alone can access secrets.
  • No persistent plaintext — the mnemonic only exists in enclave memory while READY. It is never written to disk in plaintext.
  • Password-derived keys — unseal shares are protected with Argon2id (t=3, m=64MiB, p=4), making brute-force impractical.
  • 2-of-3 threshold — a single compromised key holder cannot unseal the cosigner.
  • Cloning protection — copying the cosigner's disk produces a sealed, non-functional instance that requires an unseal ceremony from the key holders.

See Also​