Key Hierarchy and Bootstrapping
The Tricryption Key Server (kS) protects data under a four-level key hierarchy. Each level is encrypted by the level above it, so that compromising any single key — even a large set of them — never exposes the layer that guards it. The top of the hierarchy never touches the key database (KDB); it lives in a protector-secured container that the kS unlocks only at startup.
This page describes the four levels, the role-specific Master Keys, the System Protector variants that guard them, and the boot sequence the kS runs to bring itself online.
The four levels
| Level | Key | Role | Where it lives |
|---|---|---|---|
| 1 (bottom) | Session Key | Encrypts one data element | Wrapped in the KDB |
| 2 | System Key | Wraps Session Keys and their links | Wrapped in the KDB |
| 3 | Master Key | Wraps System Keys; signs records; anchors trust | Master Key Container (off-database) |
| 4 (top) | System Protector | Secures the Master Key Container | External (LSA / passphrase / token set / HSM) |
The defining property: a key is never stored alongside the data it protects, and never stored in the clear. Session Keys are wrapped by System Keys, System Keys by Master Keys, and the Master Keys themselves are sealed inside a container that only the System Protector can open.
Session Keys
A Session Key is the symmetric data-encrypting key. There is one Session Key per encrypted data element, making them by far the most numerous keys in the system.
- Algorithm: AES-256 by default; AES-192 and AES-128 are selectable.
- Identity: each Session Key carries a unique Key ID drawn from the cryptographic provider's RNG.
- Wrapping: the Session Key is encrypted under a randomly selected System Key. Its Key ID is encrypted under a different, also randomly selected System Key.
- The Tricryption Tag (T-tag): the encrypted Key ID, prefixed with the System Key ID and the System ID, forms the T-tag. The client-held ciphertext plus its T-tag is a Linked Envelope — the data and the means to find its key, with the key itself nowhere in sight.
Because two independently chosen System Keys wrap the key and its link, an attacker who recovers one System Key learns neither the Session Key nor which KDB row it resolves to.
See Key Management Process for how Session Keys and T-tags move through the encrypt and decrypt flows, and TEKey for the SDK surface that generates them.
System Keys
System Keys wrap the Session Keys. They are created when a Tricryption system is set up and are comparatively few and long-lived.
- Algorithm: AES-256 by default; AES-192 and AES-128 selectable, as with Session Keys.
- Count: 100 System Keys by default, configurable during setup. An administrator can add more at any time.
- Selection: at encrypt time the kS picks System Keys at random — one to wrap the Session Key, another to wrap its Key ID. Spreading load across a pool of System Keys limits how much is exposed if any one of them is ever compromised.
- Wrapping: each System Key is itself encrypted under a Master Key, and its ID under another Master Key; both ciphertexts are stored in the KDB.
Master Keys
The Master Keys are a fixed set of role-specific keys. Unlike Session and System Keys, they are not stored in the KDB — they live exclusively inside the Master Key Container (see below). Each Master Key has one job:
| Master Key | Role |
|---|---|
| System-Key Encryption Key | Encrypts the System Keys |
| System-Key-ID Encryption Key | Encrypts the System Key IDs |
| HMAC Key | Signs KDB records (the per-record integrity signature) |
| SRP Key | Anchors SRP (native) authentication material |
| Internal-CA private key | Private key of the kS's internal System certificate authority |
| KS internal-certificate private key | The kS's private key for its internal-CA-issued certificate |
| KS external-certificate private key | The kS's private key for its external-CA certificate (used for cross-kS trust) |
The HMAC Key is the integrity backbone of the KDB: every record carries an HMAC signature produced by this key, so any tampering with a stored key, ACL, or principal record is detectable. The internal-CA and certificate keys anchor the kS's identity and its cross-kS trust relationships; see Key Server Architecture.
The Master Key Container
All Master Keys are sealed together in the Master Key Container — an encrypted configuration object that lives off-database. The KDB holds encrypted System Keys, encrypted Session Keys, ACLs, principals, trust, and audit records, but it never holds the Master Keys. Opening the container is the privileged act that the System Protector governs and that the boot sequence performs.
System Protectors
The System Protector secures the Master Key Container. It is the one secret that is not protected by another Tricryption key — instead it is anchored to an external trust root. Protectors are documented here functionally: by what they do, not by any platform-specific storage detail.
| Protector | How the container is secured |
|---|---|
| Windows | The container key is secured via the Windows Local Security Authority (LSA) / OS key store. |
| Password | The container key is derived from a passphrase using a password-based key-derivation function (PBKDF). |
| Shared-secret | A k-of-m threshold scheme (Shamir/Lagrange): the secret is split across m tokens, and any k of them must be presented at startup to reconstruct it. |
| HSM | The Master Key Container is held and unlocked via a hardware security module (HSM) through a vendor-neutral, in-process PKCS#11 module (the vendor library is named in the kS configuration). |
Exactly one protector is active for a given kS, chosen at setup to match the deployment's trust model — OS-anchored (Windows), operator-anchored (Password), quorum-anchored (Shared-secret), or hardware-anchored (HSM).
KS boot sequence
The kS holds no usable keys at rest — everything is sealed behind the System Protector. Bootstrapping is the sequence that unlocks the hierarchy from the top down. The flow below describes an HSM-protected deployment with OpenSSL as the cryptographic module (the most involved case); other protectors follow the same shape, substituting their own unlock step for the HSM exchange.
- Load the cryptographic module. The kS initializes its crypto provider — OpenSSL 3.0.
- Load the PKCS#11 module. The kS loads the HSM vendor's PKCS#11 library in-process (the library path is set in the kS configuration) and opens an authenticated PKCS#11 session. There is no TLS on this leg from the product's side — if the HSM is network-attached, any network transport is implemented inside the vendor library and is opaque to the kS.
- Fetch the System Protector Secret and the Master Key Container. The secret is a 64-byte random value stored as a private PKCS#11 object; the container is an encrypted configuration object.
- Derive the protector key and decrypt the container. An AES-256 system protector key is derived from the secret via PKCS#5 v2 (PBKDF), and used to decrypt the Master Key Container.
- Load the Master Keys from the decrypted container into the cryptographic module.
- Fetch the encrypted System Keys from the KDB.
- Decrypt and load the System Keys. With the System Keys live, the kS can unwrap Session Keys on demand — the kS is now operational.
The sequence above uses the HSM as the protector (it holds the secret and container) and OpenSSL as the cryptographic module (it performs the key operations). A variant exists in which the HSM serves as both protector and cryptographic module, performing the key operations in hardware.
Remote Engine self-protection
A Remote Engine (rE) performs encryption close to the data, on behalf of the kS, and so it too must protect itself at rest. The rE is secured with a key it obtains from the kS — its protection is rooted in the central key hierarchy rather than in a local store. This is how the rE protects itself; it is not a general-purpose kS protector. For where the rE sits in the request path, see Key Server Architecture.
Related pages
- Key Management Process — the encrypt / decrypt round-trip these keys participate in.
- Key Server Architecture — the server that runs this boot sequence and serves keys.
- Key DB Structure — where the encrypted System and Session Keys, ACLs, and signatures are stored.