PADION
KMS · Key Management
Envelope · mTLS · Rotation · Audit
Key management that used to be scattered across products now lives in one place. Every cryptographic operation is delegated to PADION Crypto; the KMS is responsible only for the life of a key and the evidence of it.
Envelope Encryption
The KEK itself never leaves by any path. A caller receives the plaintext DEK once, then keeps only the envelope.
Systems that adopt encryption usually end up holding their own keys. Every product stores them somewhere different, rotates them on its own schedule, and when someone asks "who used this key, and when?" there is no single place that can answer. That is where compliance work tends to stall — the data is encrypted, but you cannot prove it.
PADION KMS brings those keys together. Generation, storage, wrapping, rotation, destruction, access control and audit are governed by one policy, and consuming products request keys rather than store them.
It also implements no cryptography of its own. Every cryptographic operation is a call into PADION Crypto, and that boundary is checked on every build. Splitting key management from cryptographic implementation is not a convenience — it is what makes the scope of validation unambiguous.
The caller receives a plaintext DEK once and keeps only the envelope. The KEK never leaves. An envelope describes its own key and version, so decryption needs no bookkeeping on the client side.
One logical key holds both classical and post-quantum material. Envelopes are wrapped twice, so both must break before anything opens — and the transition happens gradually, without re-encrypting everything.
Rotation intervals and crypto-periods are enforced as policy. Rotation activates a new version and leaves the old one decrypt-only — existing data does not have to be re-encrypted.
An HMAC hash chain detects tampering; periodic signed anchors detect deletion — a chain alone cannot tell you that a record is missing. A copy also streams to an off-host file, so it survives losing the database.
The top-level key is sealed to a TPM (file and environment injection are also supported; HSM is a pluggable slot). For the day the appliance dies, k-of-n escrow splits recovery so no single person can restore it alone.
Grants can only point at principals that exist in a registry — a typo never becomes a grant that silently matches nobody. Permissions are split per operation (read, wrap, unwrap, export) and can be bound to source address ranges.
Services connect with a client certificate (mTLS); JWT principals are verified through gatekeeper. The days left and the consequence of expiry for the server, client-CA and peer certificates are surfaced in the console, API and startup logs — catching the silent expiry where services keep running but keys quietly stop.
A product asks for a data key and receives the plaintext DEK together with an envelope. The plaintext is used and discarded; only the envelope is stored next to the data.
Send the envelope back and the KMS reads which key and version it belongs to before returning the plaintext DEK. Callers never track key versions themselves.
After rotation new envelopes use the new version while existing envelopes still open under the old one. There is no downtime window for bulk re-encryption.
Destruction is scheduled, not immediate. There is deliberately no path from active straight to destroyed — erasing key material cannot be undone, and the KMS cannot know where data wrapped with that key still lives. A reversal window (30 days by default) stands first, and it can be cancelled within it.
Finance · Public sector
Answer "who used this key, when, and from where" with a record where both tampering and deletion are detectable. An auditor who does not trust the KMS can verify the signed anchors independently with the public key alone.
Database encryption
External database engines such as MariaDB receive actual key material in the format they expect. Exportability is fixed at creation time as a key purpose, requires its own grant, and every export is audited.
Personal data
National ID and card numbers are replaced by surrogates that carry no information about the original. Encryption means holding something unreadable; tokenisation makes a system one that does not handle the data.
External interop
When a counterparty dictates the algorithm and IV, an envelope format cannot be imposed. That purpose is isolated on its own so those keys never mix with envelope keys.
The KMS does not even generate its own random numbers. Every cryptographic operation is a call into the module, and that boundary is enforced on every build — importing a standard-library cryptographic primitive fails the build outright.
Crypto
Cryptographic operations
Random · symmetric ciphers · key wrapping · KDFs · hashing · signatures
KMS
The life of a key
Generation · storage · rotation · destruction · access control · audit · redundancy
Boundary check
Enforced at build time
Reach for a primitive directly and the build fails
The split exists because the scope of validation has to be unambiguous. If cryptographic code is scattered, nobody can say where validated code ends — and without that answer there is nothing for an evaluation to assess.
Current status. PADION KMS is under development, and PADION Crypto is a KCMVP validation candidate with certification pending — not yet certified. The KMS is designed with Common Criteria evaluation in mind but holds no certification today. Please ask us directly about certification timelines when evaluating adoption.
So a two-node deployment is supported — but the nodes share no runtime state. The moment they do, that shared component becomes the new single point of failure.
Data plane
Issuing DEKs, opening envelopes and read queries work regardless of the peer. If one node dies, cryptographic service continues.
Control plane
Creating, rotating, destroying keys and changing grants succeed only when both nodes have them. No key exists on one side only — such a key shows up later as "some requests just fail".
Whether both nodes hold the same RootKEK is checked continuously via a check value (KCV). If it diverges the control plane closes — a key created in that state would open on one side only.
Form Factor
Install it on-premises as software, or take it as two appliances. The appliance is not packaging — the assumptions this product rests on only hold when the environment is controlled.
TPM sealing
The top-level key is bound so that only that machine can unseal it. On a shared VM with no TPM, that protection simply is not there.
Clock and ceremony
The process refuses to start on a skewed clock, and the RootKEK is injected only through an escrow ceremony. Both need a known environment.
Two nodes by design
Sharing no runtime state was designed around two separate machines from the start.
⚠️ This is not an HSM. The cryptographic module is software (PADION Crypto); we claim no hardware acceleration and no physical tamper-resistance rating. HSM integration is a pluggable slot, left open.
| Cryptographic module | PADION Crypto — zero lines of cryptography in the KMS (boundary check as a build gate) |
|---|---|
| Algorithms | AES-256-GCM · ARIA-256-GCM · AES/ARIA KeyWrap · ML-KEM-768 · hybrid KEM |
| Key purposes | Envelope (WRAP) · export (TDE) · external interop — fixed at creation |
| Lifecycle | active → rotated → expired → pending destroy → destroyed · old versions stay decrypt-only |
| Root of trust | TPM sealing · file · environment injection (HSM as a pluggable slot) · k-of-n escrow |
| Audit | HMAC hash chain + signed anchors (hybrid signature) + off-host file copy |
| Authentication | Client certificates (mTLS) · gatekeeper OIDC (ES256) · console accounts |
| Authorisation | Principal registry · grants per key × operation · source address ranges |
| Redundancy | Two nodes · no shared runtime state · control plane applied on both |
| Deployment | On-premises software or two appliances · single linux/amd64 binary + module shared library · MariaDB |
| PADION integration | Supplies keys to gatekeeper · datakeeper · flowmanager |
KMS is the foundational security stage (03) of the data flow — keys must be ready before authentication and authorization. It is where the products that handle data hand over the keys they used to keep themselves, and the cryptography performed with those keys happens inside PADION Crypto.
PoC · migrating existing keys · TDE integration · reviewing audit requirements.
