Threat model

The architecture has three concentric trust classes. The secret kernel is the innermost: it holds key shares and enforces permit lifecycle, it is HSM-backed or software-backed depending on the deployment profile, and it is the only component that ever handles raw secret material. The execution runtime is the outer layer: it orchestrates sessions, drives the DVM score, forwards peer facts, evaluates policy, and records evidence — but it never sees raw shares or nonces. The relay is fully untrusted: it forwards authenticated envelopes and is assumed to be a potential adversary.

The kernel and runtime communicate over an authenticated local channel (mTLS, vsock, or BLAKE3 MAC depending on profile). The relay sits outside this boundary — its compromise is explicitly in scope, and the system's security properties hold under a network adversary who controls all relay traffic.

If fewer than t nodes are compromised, the attacker cannot reconstruct the signing key or produce a valid signature without legitimate co-signers. Key shares never exist together — each peer holds exactly its own share, encrypted at rest inside the secret kernel boundary, and the threshold computation produces only a public result. Compromising t−1 nodes leaves the key intact.

This is the primary guarantee. A hosted cloud peer, a server-side breach of one node, or a compromise of the relay all fall within this guarantee. The threat model assumes network-level adversaries who can observe, delay, replay, or modify transport traffic. Authenticated envelopes with roster-pinned hashes prevent message forgery or substitution even under a fully controlled network.

The aggregator collects partial results and emits the final output. A compromised aggregator cannot produce a valid signature alone — it needs t independent signers to cooperate. It can attempt to equivocate by sending different values to different peers, but equivocation is detected mid-protocol and recorded as a PoisonedSessionWitness. It can delay or drop messages, producing timeout evidence. It can serve as one of the t signers, giving it one share's contribution — nothing more.

The aggregator is not a trusted coordinator in the cryptographic sense. The DVM score assigns it a role in the protocol, but its authority over the output is bounded by the same threshold that bounds any other peer.

The relay is explicitly untrusted. A compromised relay can observe message metadata (timing, volume, participant identities), drop messages (producing timeout evidence and PendingRemote state), replay old messages (detected by sequence binding and roster hash in the envelope), and inject noise. It cannot read authenticated message content, forge valid peer envelopes, or inject valid ingress facts.

Operating under a malicious network provider or cloud relay is in scope and keeps the signing guarantee intact. The relay's architectural role is pure forwarding; no security property depends on its integrity or confidentiality.

The policy plane controls whether operations are admitted and whether results are published. A compromised policy plane can block operations (denial of service) or permit operations it should not (authorization bypass). It cannot produce signatures independently — it holds no key material. A frozen or compromised policy plane blocks new sessions but does not expose existing key shares.

The separation between policy and execution is structural: policy failures affect authorization scope, not the cryptographic boundary. An operation that bypasses policy still needs t legitimate signers with valid step permits from their respective secret kernels.

At-threshold compromise: if exactly t nodes are simultaneously controlled by an attacker, the key can be reconstructed. The threshold guarantee is t−1 resilience. Key refresh and resharing are the operational response when a node's trust class changes. Physical coercion of custodians holding encrypted export fragments is outside the cryptographic threat model — it requires independent organizational controls.

Side-channel attacks on HSM hardware (power analysis, fault injection, timing) are outside the software threat model; HSM-backed deployments inherit the HSM vendor's certification and attack surface. Denial-of-service at the network layer below the relay and social engineering attacks against operators are organizational controls, not protocol controls.