Security → Device identity
Device identity
Every registered Device — a TunnelCrib Client install or a TunnelCrib Agent install — has its own ECDSA P-256 keypair, generated once and used to prove possession of that Device's identity on every subsequent connection. P-256 was chosen specifically because it can be hardware-backed on every platform TunnelCrib targets; Ed25519 cannot, so it is not used for Device identity.
What is implemented today
- ECDSA P-256 keypair generation per Device role (
client or agent).
- Nonce-challenge / signed-response registration: the Central Server issues a nonce, the Device signs it with its private key, and the server verifies the signature against the previously registered public key before accepting the connection.
- Hardware-backed key storage: TPM 2.0 on Linux (via
tss-esapi), CNG/Platform Crypto Provider on Windows, and Secure Enclave on macOS (via the Keychain access-control APIs). When a key is generated on hardware-backed storage, the private key never leaves the TPM/Enclave and cannot be exported by copying application files.
- The hardware-backed key is used for real cryptographic operations end-to-end, not just registration: the same key signs the registration nonce and authenticates the device's live SSH Tunnel connections, routed through a custom signer that calls into the TPM/CNG/Secure Enclave API instead of ever loading the raw private scalar into process memory.
- Automatic software-key fallback: if hardware-backed key generation fails (no TPM present, TPM busy, Secure Enclave unavailable, etc.), TunnelCrib falls back to a software-file-backed key in the local user configuration directory rather than failing to register.
- Separate, per-session SSH host-key and client-key pinning on top of the registration handshake (see Architecture).
Hardware-backed by default on every platform
- Linux, Windows, and macOS: hardware-backed keys (TPM 2.0 / CNG / Secure Enclave) are attempted by default, with an operator-configurable override to force software keys on any platform.
- macOS Secure Enclave: the access-control policy used does not require Touch ID or a passcode prompt (the TunnelCrib Agent runs headless), but the key is only usable while the device is unlocked at least once per boot.
- If hardware-backed generation fails (no TPM/Secure Enclave present, e.g. a VM or older hardware), TunnelCrib automatically falls back to a software keypair on any platform.
Key storage is visible in the admin console
Each Device self-reports whether its key is tpm- or software-backed at registration time, and this is surfaced per-Device in TunnelCrib admin's Devices view (Key storage column), so an administrator can see at a glance which Devices have hardware-backed keys versus a software fallback.
What this means today
Precise, current language: TunnelCrib Device identity uses an ECDSA P-256 key, verified by signed nonce challenge on every connection, backed by TPM/CNG/Secure Enclave hardware by default on Linux, Windows, and macOS, with an automatic software-key fallback when hardware backing isn't available.
