For security architects
Threat model and integration patterns
Confium replaces single-key trust with threshold quorum. This page covers the trust model, the integration patterns for each deployment mode, the defense-in-depth story, and the failure modes for every component.
Trust model
A Confium deployment with threshold T-of-N tolerates compromise of up to T−1 parties without losing the ability to produce valid signatures. Equally important: compromise of up to T−1 parties does not let the attacker produce signatures on their own.
The trust assumption: an attacker cannot compromise T or more
parties simultaneously within a single signing session. With
proactive share refresh (Herzberg refresh via
confium-tc-reshare), the window for compromise shrinks
to a single refresh period.
Threat table
| Threat | Defense | Residual risk |
|---|---|---|
| Single-key compromise | No single key exists. Shamir split at generation; never reconstructed. | T parties colluding within one refresh window. |
| Split-view attack on transparency log | Consistency proofs + witness gossip + OTS anchoring. | Adversary controlling log + witnesses + ability to rewrite Bitcoin. |
| Long-term share aggregation | Herzberg refresh re-randomizes shares periodically. | T shares compromised within one refresh window. |
| Side-channel (timing, memory) | Constant-time scalar arithmetic; SecureBytes zeroizes on drop; #![forbid(unsafe_code)]. | Kernel-level rootkit on signer host — use hardware enclaves for highest assurance. |
| Coordinator compromise | Coordinator cannot produce signatures without T party contributions; nonces are unique per session. | Coordinator DoS (availability), not forgery (secrecy). |
| Policy violation (wrong algorithm used) | Confium::Policy is process-global; enforced on every call. | Misconfigured policy at deployment time — audit your manifest. |
| Replay of old session | Per-session nonces; coordinator rejects duplicate session IDs. | None — replay produces detectable hash mismatch. |
Defense in depth for transparency logs
The transparency log is the audit spine of any Confium deployment. Three layers protect against split-view attacks:
Layer 1 (consistency proofs) is necessary but not sufficient — verifiers must communicate to detect divergent heads. Layer 2 (witness gossip) makes that communication automatic. Layer 3 (OTS anchoring) defeats the adversary who controls both log and witnesses by anchoring state in Bitcoin's proof-of-work chain.
See the transparency logs deep dive for the cryptographic details.
Split-view attack walkthrough
The diagram below shows both the attack and the defense in one frame. On the left, a compromised log operator presents two different tree heads to two different verifiers. On the right, witnesses gossip the heads and detect the divergence.
Integration patterns by mode
Mode 1 — Peer-to-peer
Nodes exchange threshold protocol messages directly. No intermediary. The coordinator is a library linked into the application; signers are processes the application can reach over the transport of choice.
- Best for: new distributed systems where you control both ends.
- Failure mode: if too few signers are reachable, signing fails. Use async sessions to tolerate latency.
- Hardening: use
confium-net-quicfor transport encryption + auth; pin signer identities.
Mode 2 — PKI drop-in
Existing PKCS#11, OpenSSL, or JCE consumer talks to a Confium adapter process. The adapter translates each call into a threshold session.
- Best for: migrating existing PKI consumers without rewriting them.
- Failure mode: adapter is a single point of failure unless you deploy it redundantly.
- Hardening: deploy adapter as a sidecar or behind a load balancer; the consumer sees only one logical PKCS#11 socket.
Mode 3 — Sovereign PKI
Custom certificate formats, custom delegation rules, custom archival cadence. Coordinator runs as a long-lived service; signers join and leave over time.
- Best for: institutional PKI where no single stakeholder can be trusted.
- Failure mode: institutional signers may go offline for long periods. Async sessions are mandatory.
- Hardening: attribute-based quorum (e.g. 5-of-9 directors from 3 distinct regions) for resilience against regional compromise.
Coordinator session lifecycle
The coordinator is an availability service, not a secrecy service. Compromising it can denial-of-service the deployment but cannot produce unauthorized signatures — the math requires T party contributions.
Sessions are async. A director in Tokyo can submit their share during their workday; a director in New York submits theirs hours later; the coordinator combines when quorum is reached. Below is a 9-hour session spanning Tokyo, Frankfurt, and New York.
Failure modes and mitigations
Signer loss
If a signer is lost permanently (hardware failure, departed
employee), use confium-tc-reshare to re-share the
secret across the remaining parties plus a new replacement signer.
The secret itself is never reconstructed. The threshold T may
also be adjusted during re-sharing.
Coordinator compromise
Replace the coordinator. The signing key is not on the coordinator — it's split across signers. Re-deploy coordinator from a clean image; resume sessions from the transparency log.
Transparency log compromise
If the log operator goes rogue, witnesses detect divergence via gossip. Switch to a backup log; replay recent tree heads. The OTS anchors in Bitcoin preserve irrefutable history.
Algorithm break
If a classical algorithm (e.g. Ed25519) is broken, deploy a composite-signature update that includes the broken algorithm alongside a post-quantum algorithm. Verifiers that have upgraded accept the composite; verifiers that haven't still accept the classical component (which is what they always accepted).