Security → 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. |