The problem
An encrypted server stops at boot until something supplies the disk key. Each of the usual answers gives something up:
- Someone at the console. Works until the server is three time zones away at 0300.
- A TPM chip that unlocks automatically. No person needed — which also means the server unlocks itself wherever it is powered on.
- A stored key. Now the secret lives somewhere other than with the people accountable for it.
- Automatic network unlock. Convenient. It also means being on the right network is enough to unlock the disk.
CryptKēpr is designed to answer that prompt remotely and, by default, only when a person holding an authorized hardware key says yes. Any exception is a per-server opt-in, and it is logged.
How it works
This section describes the design. See Status below for what works today.
One rule. A managed server at rest holds only encrypted data. By default, unlocking it takes a hardware key and PIN, physically present, in a person’s hands, and nothing that is always online can unlock the fleet on its own. An offline recovery passphrase, kept under your own controls, covers disaster recovery.
The main parts.
- The appliance runs the directory, policy, audit log, and web console. It holds disk secrets only in encrypted form — no place to keep a usable disk secret, and no way to accept one.
- The operator agent runs on an authorized person’s workstation. By default it is the only place a disk secret is decrypted, and only with that person’s hardware key, its PIN, and a physical touch for each decryption. The secret sits in memory for the moment of unlock; it is never written to disk.
- The server agent runs on each managed server, installs the boot-time unlock helper, and carries out key changes safely.
The appliance never connects to your servers. Server actions run from the operator’s workstation, with the operator’s own credentials. A compromised appliance holds no usable disk secret and cannot open connections to your servers. It is still a high-value system, and a briefing covers what an attacker could attempt through it.
Admin rights alone can’t decrypt. Authority and custody are kept apart. The system blocks any direct grant that would give one person both the authority to approve access and the ability to unlock.
Key changes don’t lock you out. No old key is removed until its replacement has been tested on that disk. Every disk also keeps an offline recovery passphrase.
Actions taken through the appliance are on the record. The audit log is tamper-evident: append-only and hash-chained, with optional signed checkpoints. Reading the log is logged too.
What it doesn’t do. CryptKēpr does not protect a server from someone who already controls an authorized operator’s workstation at the moment of unlock, controls the running server, or can tamper with the server’s boot chain. Briefings cover the full threat model.
Who it’s for
- Organizations running encrypted, high-security systems on their own hardware.
- Teams that can’t leave disk keys with a vendor, a cloud provider, or an always-online service.
- Security programs that need separation of duties and a tamper-evident audit trail.
- Disconnected and air-gapped networks — CryptKēpr is designed to run without internet access.
Straight answer: if your servers run in a public cloud and you trust the provider, use the provider’s built-in encryption. CryptKēpr is designed for servers you run yourself, where no outside party should hold the keys.
Status
In development. CryptKēpr is not available for purchase or deployment, and no release date has been announced. The current development build targets full-disk-encrypted Linux (LUKS) systems; the architecture is designed to extend to other high-security and clandestine platforms. Descriptions reflect the current design and development build, may change before release, and are not a commitment or an offer.
Request a briefing
Briefings are currently limited to U.S. organizations and U.S. persons. Email works on networks that block web forms, so start there. Include your organization and role, roughly how many systems you need to protect and where (bare metal, virtualized, disconnected), and the problem you need solved.
Unclassified inquiries only. Do not send classified information, CUI, or other controlled information.