Skip to main content

Tricryption Key Management Process

Encrypting data is the easy part — any library can do it. The hard part is managing the keys: generating them, storing them safely, controlling who may use them, and keeping them away from the data they protect. Tricryption is built around that problem. This page is the conceptual front door to the technical reference; it explains what the system does and why, then links down into the architecture, key hierarchy, and database that implement it.

Centralized symmetric key management​

Tricryption uses symmetric encryption for data — fast, and well suited to high volume — and solves the key-distribution problem that symmetric ciphers classically have by managing every key centrally at the Tricryption Key Server (kS).

  • Keys are generated, stored, and access-controlled at the kS, never created ad hoc by the clients that use them.
  • Ciphertext stays on the client side — produced by an agent or by a Remote Engine (rE) close to the data. The key that produced it does not stay with it.
  • Every key carries an access-control list (ACL) and per-key usage attributes, so the right to decrypt is a server-enforced policy, not a property of whoever happens to hold the ciphertext.

This inverts the usual exposure: compromising stored ciphertext yields nothing without the kS, and the kS hands back a key only after authenticating the caller and checking policy.

Data and key separation: the Linked Envelope​

The core differentiator is separation of the encrypted data from its key, joined only by an encrypted random link:

  • The ciphertext lives client-side.
  • The key lives wrapped in the key database (KDB).
  • They are tied together by a Tricryption Tag (T-tag) — an encrypted random link that, on its own, reveals neither the key nor which key it points to.

Ciphertext plus its T-tag is a Linked Envelope: it carries everything needed to request decryption and nothing that enables decryption by itself. The T-tag is a protocol-level construct — it travels with the data wherever the data goes, whether that is a database column, a message field, or a client-side object handled through the agent or rE.

Encrypt and decrypt data-flow between the client or Remote Engine, the Key Server, and the key database

The encrypt flow​

A request to protect a data element runs through the kS as follows:

  1. Request. A client asks to encrypt, either directly to the kS or through a Remote Engine (rE).
  2. Generate the Session Key. The kS generates a fresh symmetric Session Key — the data-encrypting key — AES-256 by default.
  3. Generate the link. The kS generates a random link / Key ID that will tie the client-stored ciphertext to its row in the KDB. (Keys and links can be bulk-generated and cached ahead of demand for throughput.)
  4. Wrap and store the key. The Session Key is encrypted under a randomly selected System Key and stored in the KDB together with its ACL.
  5. Wrap the link → build the T-tag. The link is encrypted under a second, different randomly selected System Key; the System Key ID and System ID are prepended to form the T-tag.
  6. Encrypt the data. The Session Key and T-tag are sent to the rE over Tricryption transport security; the rE encrypts the data and destroys its copy of the Session Key.
  7. Store the Linked Envelope. Ciphertext plus T-tag is stored on the client side. The key is never stored with the data.

The two random System Key selections in steps 4–5 are independent, so the key and the link to it are protected by different secrets.

The decrypt flow​

Decryption reverses the round-trip, and it is where policy is enforced:

  1. Present the T-tag. The client sends the T-tag back to the kS.
  2. Authenticate. The kS authenticates the requesting principal (see below).
  3. Authorize. The kS checks the key's ACL and per-key usage attributes — for example, a remaining-use count — before releasing anything.
  4. Return the key. If policy allows, the kS resolves the T-tag to the Session Key and returns it.
  5. Decrypt and destroy. The data is decrypted and the Session Key copy is destroyed once the operation completes.

A caller who holds a Linked Envelope but fails authentication, or whose ACL entry does not permit the operation, gets nothing back.

Authentication and authorization​

The kS authenticates principals before resolving any key. Each authenticated principal type pairs a credential with its protocol:

  • Password (SRP) — username / password, via a first-party SRP-6a implementation using SHA-384.
  • Certificate (X.509) — a client certificate.
  • LDAP (Kerberos) — directory credentials. Availability is build-dependent: Password (SRP) and Certificate (X.509) are the self-authenticating types every kS provides; the directory authenticator is not present in every shipped kS.

A further principal type, Group, is a collection principal: it is not authenticated by a credential or protocol, but is used as a grant target for discretionary access control (DAC) — rights granted to a group are inherited by its members.

Authorization is a separate step from authentication: once a principal is identified, an access check (RBAC / DAC) evaluates the per-key ACL to decide what that principal may do with a given key. See Key Server Architecture for how authentication fits the request lifecycle, and TEACLInfo / TEACLEntry for the ACL surface.

Where to go next​