Security → Threat model

Threat model

This is a working threat model, not an exhaustive one.

Threat	Assumptions	Mitigation	Residual risk
Stolen Client or Agent device (hardware theft)	Attacker has full disk/filesystem access to the stolen Device.	Per-Device ECDSA P-256 identity key, verified by signed nonce on every connection. Hardware-backed (TPM/CNG/Secure Enclave) key storage is on by default on Linux and Windows, opt-in on macOS; see Device identity.	Materially lower when hardware-backed key storage is active, since the key is not exportable by copying files. When software-key fallback is in effect (macOS default, or any platform where hardware backing failed/was disabled), a copied key store can impersonate the Device. Admins can see which mode each Device reported (a "Key storage" column in the Devices list shows 🔒 TPM or 📄 File), but this is self-reported by the Device at registration time and not cryptographically verified by the server.
Copied application state (no hardware access)	Attacker copies application config/data directories without physical device access.	Hardware-backed keys (TPM/CNG/Secure Enclave) cannot be exported this way; only a lookup marker is stored on disk.	No residual risk when hardware-backed storage is in effect. Full residual risk under software-key fallback (see above), since the raw private key is a plain file.
Compromised Agent host	Attacker gains code execution on a Device running a TunnelCrib Agent.	Agent only forwards traffic to its own advertised, approved Services; the Bridge/Relay restricts the session to port-forwarding only, with no shell/exec/PTY.	An attacker with Agent-host code execution can still reach whatever the Agent's own advertised Services can reach locally. TunnelCrib does not add protection against a fully compromised Agent host.
Compromised Relay	Attacker controls the machine running `tunnelcrib-bridge` (TunnelCrib-hosted or Private Relay).	Per-session ephemeral keys limit blast radius to sessions active during compromise; Bridge is restricted to forwarding only, no shell/exec/PTY. The Client and Agent additionally run a second, inner SSH session end-to-end through the Bridge's two channels, mutually authenticated and host-key-pinned the same way as a Direct Tunnel; see Relay visibility.	Low for Service payload confidentiality: a compromised Bridge only ever forwards an opaque, already-encrypted inner SSH stream it holds no key material for, so it cannot decrypt Service traffic even with full code execution on the Relay host. A compromised Bridge can still observe connection metadata (source IPs, byte counts, timing, which Agent a session was for) and could deny/disrupt the session, but not read or inject Service payload.
Compromised Central Server	Attacker controls the Python control-plane process.	The Central Server never terminates or forwards Service traffic; it only ever handles registration, nonce verification, and signaling.	An attacker could authorize illegitimate Tunnels between already-registered Devices, or deny service, but cannot directly read Service traffic from the control plane alone.
Malicious organization admin	A legitimate admin account is used to grant excessive access.	Organization boundary and per-Client, per-Service Agent-access policy limit what any granted access can reach.	Fine-grained approval workflows and admin action audit trails for policy changes are on the roadmap; today, prevention of admin over-grant relies on organizational process, not TunnelCrib enforcement.
Replay of a captured registration handshake	Attacker records a prior nonce/signature exchange.	Nonce is server-generated per connection attempt; a replayed signature over an old nonce will not match a new challenge.	Low, assuming nonce generation is unpredictable and not reused by the server.
Tunnel hijacking mid-session	Attacker attempts to inject into or take over an established Tunnel.	Per-session SSH client-key and host-key pinning is independent of the transport-level address exchange, so a hijacked or spoofed network path cannot be authenticated as the legitimate peer.	Low for the SSH layer itself; depends on the underlying tier (UDP/TCP/Relay) not being separately compromised.