Key Escrow & Recovery

Some keys, if lost, cannot be recovered from any backup — because the backup holds the same encrypted data. Escrow splits those keys across people you choose, so no single person (including us) can reconstruct one alone, and no single loss is fatal.

Why This Exists

Two keys on your instance are genuinely unrecoverable from a backup if lost — the backup holds the same encrypted data — so escrow splits each across trustees you nominate:

Escrow splits each key into shares and gives one to each trustee you nominate. The Key escrow screen always issues three shares, one to each of three trustees you choose, and any two of them rebuild the key (2 of 3). You choose who the trustees are; the screen does not offer a different number of shares or a different threshold. So one person cannot act alone, and losing one person does not lock you out.

Issuing the shares is itself a two-person step. One administrator asks to arm the issue and a different administrator approves it; the arm is used up by one issue, so issuing again means arming again. Each trustee also needs their own key file, made in the Recovery Kit before you issue. The step-by-step is in Set up backups.

Recovering Without Us

Escrow is worthless if it depends on the thing that died. Trustees can open their shares with an offline Recovery Kit — a single self-contained HTML file that runs in a browser with no network, no server and no Zonitix involvement. If your instance is gone and we are unreachable, the threshold of trustees can still reconstruct the key.

That kit and the off-site backup decryptor are both published for public download, with their SHA-256 hashes, under Recovery Tools. Get them before you need them: a copy that lives only on your instance is no use once the instance is what you lost.

Not The Same Thing: Device Recovery Keys

FileVault and BitLocker recovery keys for laptops are a separate escrow with separate rules, and they are not split across trustees. On Macs a stored FileVault recovery key can also be rotated: on request, after someone reveals it (on by default), or on a schedule of 30, 90, 180 or 365 days (off by default). Rotation is macOS only and not instant — the Mac makes the new key at its next login. The details, and the current status of that feature, are under MDM & Device Operations.

Escrow That Tells You When It Has Gone Stale

An escrow that quietly stops working is worse than none, so the status view derives three things the stored record cannot know by itself:

• Key rotated since issue. The live key is fingerprinted and compared. If it no longer matches, every outstanding share now opens the wrong secret — the escrow is marked stale rather than left looking healthy.
• A trustee has left. Someone who is offboarded still “holds” a share nobody can ask for. Departed trustees are surfaced against the live user directory.
• The drill is overdue. Recovery you have never rehearsed is a hope, not a plan, so the age of the last drill is tracked, and a drill older than 180 days is flagged. Because trustees for these keys hold key files, their private keys never reach the server and the drill cannot run in the app: trustees run it in the offline Recovery Kit.

If something here is not working as you expect, start with When something goes wrong.

What The Server Keeps

Keys are split with Shamir’s Secret Sharing, and each share is sealed to that trustee’s own public key (RSA), which they generate in the Recovery Kit; only the public half is ever pasted into the product. For both keys on this page a passphrase-sealed share is refused: the administrator issuing it would know the passphrase and receive the sealed share, and could rebuild the key alone. Before any share is issued, the split is verified to reconstruct the original — if it does not, nothing is handed out.

• The split. Shamir’s scheme over the field GF(2⁸) with the reduction polynomial 0x11b, applied to each byte of the key with fresh random coefficients. At most 255 shares can be made.
• The trustee’s key. It must be an RSA public key of at least 3072 bits. A key of another type, or a shorter RSA key, is refused with 400.
• The seal. Each share is encrypted with AES-256-GCM under a random 256-bit key and a random 12-byte IV. That key is then wrapped to the trustee with RSA-OAEP using SHA-256. The sealed share carries the first 8 bytes of the SHA-256 of the trustee’s public key, so the Recovery Kit can tell which key file opens it.
• Passphrase sealing, which is refused for the two keys on this page, derives its key with PBKDF2-HMAC-SHA256 at 600,000 iterations over a 16-byte random salt, and needs a passphrase of at least 12 characters.

Issuance is refused with a 403 unless a second administrator has armed it. The arm is consumed atomically by one issue, so two simultaneous requests cannot share it.

Shares are handed out exactly once. Afterwards the server retains only who holds which share, a fingerprint of the key, and drill history. It does not keep the key, the shares, the sealed shares, or any trustee’s private key — keeping sealed shares would not help in the disaster this exists for (that copy dies with the server) and would gather every share in one place, which is precisely what splitting prevents.

Both keys are split inside the compliance service, which holds them, because a key can only be split by a process that holds it, and the raw key is never shipped elsewhere to be divided.

Recording A Test That Was Run Offline

Because the test happens in the Recovery Kit, the server cannot see it, and the key would show as never tested for good. So once the trustees have rebuilt the key offline, an administrator records it: on System → Backups & Recovery, in the Key escrow card, click Record offline test on the key’s row. Tick the trustees who took part (at least the threshold), type the fingerprint the kit showed after rebuilding the key, tick the confirmation and click Record test. You are asked to re-authenticate first.

The server holds no share, so it cannot prove the test: it is stored as recorded by the named administrator, never as verified, and written to the audit log. What the server can check, it does. The fingerprint must equal the one recorded when the shares were issued, otherwise nothing is recorded (400). If the key has been rotated since issue the shares open the old key, so the record is refused (409) until you issue new shares. Fewer trustees named than the threshold is refused (400).

Endpoints And Permissions

Reading the status needs any one of view_reporting, view_finance, manage_compliance or view_system. Every action needs manage_compliance. When issuing, each share must go to a different person. The issue endpoint itself accepts three or more trustees and a threshold that is a whole number from 2 up to the number of trustees (400 otherwise; 2 when omitted). The screen always sends three trustees and a threshold of 2, so a different split is only reachable by calling the endpoint directly.