How We Minimized the Attack Surface: MPC and 4-Eye Control in TKeeper

Let's be direct. In security, the math rarely gets broken. What gets broken is application logic, infrastructure, and people.

If you're building fintech, a crypto exchange, or any high-stakes enterprise system, you have keys that control money or secure data. Traditional approaches to protecting them are showing their limits.

TKeeper was designed from the attacker's perspective. Here's how we systematically reduced the attack surface.

Step 1: Eliminate the Private Key

If a private key exists in assembled form, it will eventually be stolen.

Traditional KMS solutions store keys in encrypted databases. The encryption is sound, but the key that protects the key has to live somewhere. Follow that chain far enough and you find a single secret that, once compromised, unlocks everything. The single point of failure is still there.

HSMs were built to solve exactly this. The key material lives inside tamper-resistant hardware, unreadable by design. And for a long time, this was the best answer available. But HSMs introduce a different problem: they are perimeter-dependent. Once an attacker owns the server that communicates with the HSM, they do not need to extract the key. They just ask the HSM to sign things on their behalf. The hardware stays intact. The damage is identical.

MPC Threshold Schemes eliminate the problem at the root.

In TKeeper, a complete private key never exists anywhere in the system, not in memory, not on disk, not inside any single piece of hardware. The key is cryptographically split into shares distributed across independent nodes. No individual node holds enough information to reconstruct it and no single compromise is sufficient.

The practical consequences:

• No complete key material ever resides in memory on any single machine
• Suspected node compromise triggers instant isolation; remaining nodes perform Key Refresh without ever reconstructing the key
• Unlike HSMs, there is no single target worth compromising. Owning one node yields one share, that is mathematically useless in isolation. An attacker needs t-of-n nodes simultaneously, each isolated across independent environments.
• The approach scales horizontally at a fraction of HSM hardware costs

HSMs solved key readability. MPC solves key existence. That is a categorically stronger guarantee.

Step 2: Hot Path Protection Against Application Compromise

Attackers are pragmatic. They won't attack your cryptography directly. They'll target the application layer that holds SSO credentials and processes transactions automatically.

No system operating in the hot path remains fully invulnerable. High-frequency operations demand low latency, and low latency demands tradeoffs. The goal here is not perfect prevention but rapid containment: detect the breach early, limit what the attacker can reach, and ensure the damage stays controlled.

In crypto infrastructure, hot wallets intentionally hold only as much as current operations require. In conventional systems, the equivalent is keys protecting frequently accessed data.

In both cases, the exposure is real and accepted by design. The accepted outcome is the same too: acknowledge that some data or funds in the hot layer may be at risk, while ensuring that data-at-rest, cold storage, and unrelated key material remain completely out of reach. The attack stays isolated.

The foundation of MPC is already adversarial by design and step 2 builds on top of that. TKeeper enforces strict Principle of Least Privilege, allowing not to grant more access to applications than their operational scope requires. A service handling hot wallet operations gets exactly those keys, and nothing beyond that boundary. A compromised application cannot pivot to warm storage, cold keys, or any unrelated scope.

On top of segmentation, TKeeper maintains audit logs across two independent channels, allowing to detect anomalous behavior surfaces early. By the time an attacker attempts to escalate, the pattern is already visible.

Here we accept the risk of an incident and make everything to prevent escalating and isolate.

Step 3: Warm Path and 4-Eye Control

This is the layer where no automated decision is trustworthy enough. A human must look at the request, understand what is being authorized, and make a conscious approval. Hot path tradeoff described in Step-2 is no longer acceptable.

Hot wallets handle operations. The significant balances sit further back. In crypto infrastructure, once a hot wallet reaches its threshold, funds sweep to warm or cold storage. The stakes at this layer are categorically higher.

The same principle applies to conventional systems, where the equivalent layer holds data exposure of which is irreversible: Root CA certificates, master keys, and production code-signing keys.

But because these operations are infrequent by nature, we have more room to enforce stronger guarantees. 4-eye control is a mandatory requirement that no critical operation proceeds without explicit authorization from multiple independent parties. Whether that is humans reviewing and approving through secure channels, or automation originating exclusively from hardened, attested environments such as HSMs or hardware enclaves. General-purpose application logic never qualifies.

TKeeper implements this through 4-eye control key policies, requiring multi-signature proofs across three industry-standard curves. It is designed to integrate with any existing approval workflow, whether human-driven or hardware-attested:

• NIST P-256 for enterprise environments.

• Secp256k1 for crypto-native teams, where admins can approve operations directly from Web3 wallets.

• Ed25519 for modern systems.

Why This 4-Eye Control Is Very Hard to Bypass

This is the architectural distinction that separates TKeeper from conventional key management systems.

In a standard KMS, approval policies like "requires 2 signatures" live in a database or application logic. A full system compromise means an attacker can simply delete the policy and execute transfers unconditionally. That's it.

At exploit.org, we love to say: a feature is truly well-designed when it fits naturally into the model itself, rather than being bolted on top of it. This is exactly what we achieved here.

Every node in the MPC quorum independently validates security policies before participating in any operation. The policy has no single location. To bypass it, an attacker must compromise t-of-n independent nodes, distributed across separate servers and geographic regions, and convince each to ignore the policy simultaneously. It still fits the threat model of systems based on MPC Threshold Schemes, and they make 4-eye control stronger.

The attack complexity scales with the quorum size. Human 4-eye control is enforced at the level of machine consensus, not application logic.

Summary

Everything with a single point of failure can be broken: a key, a database, an application server.

The combination of MPC, strict RBAC, and decentralized 4-eye control in TKeeper either removes the single point of failure entirely or minimizes the exploitable surface to the point where a successful attack yields no meaningful impact.

To extract value from the system, an attacker must simultaneously compromise multiple independent environments while circumventing both cryptographic guarantees and isolated node consensus.

This architecture was born in crypto, where threshold cryptography and distributed key management saw their earliest real-world adoption. But the threat model it addresses is universal. Any system where key compromise is catastrophic, where authorization must be tamper-proof, and where a single breach cannot be allowed to cascade, fits exactly the problem TKeeper was built to solve.

For your organization, this translates to a clean, auditable, and genuinely secure key management flow, whether you are running a crypto exchange, a financial institution, or an enterprise system where the wrong person signing the wrong thing is simply not an option.