Introduction

Tip

Contact enterprise@exploit.org to find details about Enterprise support

What it is

TKeeper (Threshold Keeper) is a distributed, threshold Key Management System (KMS) for environments where no single machine should have unilateral key authority.

It runs as a network of cooperating peers (“keepers”) and performs protected cryptographic operations using a t-of-n threshold model, requiring participation from at least t distinct peers.

Note

In many traditional key management setups, the private key still has a single point of custody: there is one place where the full key exists and can be used to sign or decrypt. If that storage or runtime environment is compromised, the attacker gets full key authority.

TKeeper avoids that class of risk. The private key is split into shares and is never reconstructed anywhere, including during key generation. As a result, compromising up to t machines is not sufficient to sign or decrypt.

Capabilities

Distributed custody model

• Threshold model (t-of-n) for protected operations.
• Zero-trust posture: no trusted “primary” node for security decisions and all keeper-to-keeper requests are authenticated.
• Distributed Key Generation (DKG) to avoid a single peer generating/holding the full private key.
• No private-key reconstruction (shares + protocol messages only).

Key lifecycle

• Keys are identified by stable logicalId and evolve via integer generation.
• Lifecycle operations: create, rotate, refresh, destroy.

Cryptographic operations

• Threshold signing + signature verification.
• Threshold encryption + decryption.
• Public key retrieval

Access control

• Every request is authenticated and authorized against explicit permission identifiers.
• Permissions can be scoped per key via logicalId namespace + limited * wildcard.

Audit logging and compliance controls

• Signed, tamper-evident audit records.
• Exposable asset inventory

Control Plane UI

• Administrative UI under /ui.
• Token-based access and optional OIDC login (depends on auth configuration).

When to use TKeeper

Use TKeeper when you need cryptographic operations with strong custody guarantees and operational separation, and when trusting a single machine (or operator) is not acceptable.

Problem / requirement	What TKeeper provides
Compromise of one host must not be sufficient to sign or decrypt	Threshold security (t-of-n) with distributed peers
No single operator/system should ever hold the whole private key	DKG + no private-key reconstruction (each keeper stores only its share)
You need clear, versioned key lifecycle operations	logicalId + generation, with create/rotate/refresh/destroy
You need strict access control across operations and keys	Authenticated requests + explicit permission identifiers
You need evidence for security-relevant actions and the ability to verify it	Signed, tamper-evident audit records + verification endpoints

You can also use TKeeper to split trust across organizations (e.g., keepers run by you and by your client) so neither party can unilaterally sign, decrypt, rotate, or destroy keys.

Use cases

Crypto custody and blockchain signing

For exchanges, custodial wallets, treasury, and settlement systems. Threshold signing prevents a single host from authorizing transactions. Crypto support is first-class, including Taproot signing.

TKeeper is supported out-of-box in our blockchain development framework: Finja.

High-risk service signing

For internal signing services, CI/CD signing, license signing, and privileged automation. Quorum signing plus strict permissions prevents one machine or one operator from signing alone.

Encryption with controlled decryption

For backups, exports, configuration bundles, and sensitive payloads. Data can be encrypted/decrypted using ElGamal KEM over the secp256k1 curve.

Split control across environments or organizations

For deployments where keepers run in different zones, regions, or even different organizations. Threshold operations and authenticated keeper-to-keeper communication prevent unilateral sign/decrypt/rotate/destroy.

Audit and compliance-driven operations

For environments that require traceability of security-relevant actions. Signed, tamper-evident audit records provide verifiable evidence.

Versioned key lifecycle for long-lived systems

For platforms that need predictable rotations and safe key changes. logicalId + generation enables create/rotate/refresh/destroy workflows with guardrails around destructive operations.

When TKeeper is not the right tool

TKeeper is a distributed threshold system. If you do not need threshold security, or you prioritize minimal operational complexity over custody guarantees, a single-node or centralized KMS may be a better fit.

Examples:

• Basic secret storage / envelope encryption without quorum operations
• Your threat model accepts a single key risk
• You cannot operate multiple peers reliably (availability, networking, monitoring)

Tip

If you need a general-purpose secrets manager rather than threshold custody, a traditional secrets manager may be a better fit (e.g., HashiCorp Vault).

For enterprises

TKeeper is Apache 2.0 licensed and can be deployed self-managed. For security-critical production deployments, we provide an Enterprise Kit: hands-on implementation and operational support for running TKeeper reliably at scale.

We adapt TKeeper to your requirements and architecture (security boundaries, authentication, approvals, and operational procedures) and provide incident response and security support for production operations.

Contact enterprise@exploit.org for details.

API reference

See OpenAPI Reference

Available SDKs:

Language	URL
Java	Offical Java TKeeper SDK

Note

If you want your SDK to be listed in the list, reach to us at contact@exploit.org