Docs · Guides
Software custody
What encrypted-at-rest software custody defends against, and what it does not.
How keys are stored
- AES-256-GCM, a data encryption key per key.
- The DEK is wrapped by a key encryption key held outside the database.
- The record's binding — organization, project, principal, version — is authenticated as additional data on both layers, so a row edited to point at another tenant fails to decrypt rather than signing for them.
- There is no export API, and none may be added.
What it defends against
- A stolen database dump — ciphertext whose key is somewhere else.
- A copied data volume — likewise.
- An edited row — the binding is authenticated, so substitution fails closed.
- A compromised Gateway — it can ask for signatures over a closed set of operations, and cannot read a key.
What it does not defend against
Root on the Custody host. During one signing operation the private key exists in that process's memory, and anybody who can read that memory can read the key while it is there. That is the assurance level, stated plainly. This is SOFTWARE CUSTODY and it is not an HSM.
Fail-closed behaviour
| Fault | What happens |
|---|---|
| Wrong KEK | Signing is refused as decryption_failed. No signature is produced or recorded. |
| Missing KEK secret | The service does not start. |
| Unreadable KEK path | The service refuses at startup and names the KEK, so an operator sees it rather than an approver. |
| Corrupted ciphertext | Refused. The authentication tag does not verify. |
| Custody unreachable | A transport failure. Never a quieter signature from somewhere else. |