SECURITY ARCHITECTURE
Zero-trust.End-to-end.Auditable.

Every design decision in TucDesk prioritizes security over convenience.

AGENT IDENTITY

ED25519 β€” generated once, stored locally

There is no central credential store. Each agent is a cryptographic principal defined by a keypair that never leaves its host.

  • β€’ED25519 keypair generated locally at agent install time using a cryptographically secure RNG.
  • β€’The public key becomes the permanent, immutable agent identity across all sessions.
  • β€’The private key never leaves the agent host β€” it is not transmitted during registration.
  • β€’Registration requires a valid ED25519 signature over a nonce and timestamp.
  • β€’Replay protection: the rendezvous server maintains an LRU + TTL window for registration nonces.
  • β€’Reinstalling the agent generates a new keypair and a new identity β€” there is no credential to recover.

Why ED25519

ED25519 provides 128-bit security with compact 32-byte keys and 64-byte signatures. Signing and verification are fast and constant-time, which eliminates timing side-channels that affect RSA and some ECDSA implementations. The key material is not exportable from the agent process.

SESSION ENCRYPTION

X25519 ECDH β†’ HKDF β†’ AES-256-GCM

Every session derives fresh key material. Relay nodes and rendezvous servers see only ciphertext.

  • β€’X25519 ECDH key exchange between operator key material and agent key material at session start.
  • β€’Shared secret is processed through HKDF-SHA256 with the label tucdesk-session-v1.
  • β€’Session key is ephemeral β€” it exists in memory only and is discarded on disconnect.
  • β€’AES-256-GCM authenticates and encrypts every terminal frame before it enters the transport layer.
  • β€’Each frame carries a unique nonce; nonce reuse is prevented by a monotonic counter.
  • β€’Forward secrecy: compromise of a long-term key does not compromise past session ciphertext.

Forward secrecy

Because session keys are ephemeral and derived fresh for every connection, a future compromise of any long-term key cannot decrypt past sessions. The X25519 exchange happens in-memory and is discarded immediately after key derivation completes.

TRANSPORT

UDP hole-punch β†’ TURN relay fallback

TucDesk connects through NAT without port-forwarding. When direct path succeeds, the relay is not in the data path at all.

  • β€’P2P UDP hole-punch: operator and agent negotiate a direct path via the rendezvous server.
  • β€’TURN relay fallback: when direct path fails, traffic routes through the relay as ciphertext only.
  • β€’TucLink Direct carries PTY frames via ICE DataChannel β€” powered by pion/webrtc.
  • β€’Relay nodes are architecturally untrusted β€” they cannot distinguish or modify session content.
  • β€’STUN/TURN credentials are short-lived and scoped to a single session negotiation.
AUDIT TRAIL

Every sensitive action is signed

Every action is written to a chained, server-signed audit log. Modification of any entry breaks the chain.

  • β€’Every action produces an audit entry: actor identity, target agent, action type, timestamp, session ID.
  • β€’Each entry is signed by the server using its ED25519 key at write time.
  • β€’Entries are chained: each entry includes the hash of the previous entry.
  • β€’Any modification to a historical entry breaks the chain signature and is immediately detectable.
  • β€’The chain and signatures are exportable for offline verification by SIEM tools.
  • β€’Session recordings (asciinema format) are signed before upload to tenant-prefixed S3 paths.

Compliance evidence

The signed audit chain satisfies SOC2 CC6.1 (logical access controls) and CC7.2 (monitoring). Session recordings encrypted before S3 upload satisfy requirements for data-at-rest encryption. The chain export format is designed for SIEM ingestion without post-processing.

AUTHENTICATION

JWT rotation, Support PIN, MCP OAuth/PKCE

Human operators, support technicians, and AI agents each have a dedicated authentication flow with minimal standing privilege.

  • β€’JWT access tokens with short expiry (15 minutes default).
  • β€’Refresh token rotation: each use issues a new refresh token and invalidates the previous.
  • β€’Refresh token family tracking detects theft: a reused invalidated token revokes the entire family.
  • β€’MCP clients authenticate with OAuth 2.0 + PKCE β€” no long-lived secrets in AI agent processes.
  • β€’Support PIN: SHA-256 hashed, time-limited, scoped to specific agent or tag, single-use by default.
COMPARISON

TucDesk vs VPN vs SSH jump host vs Teleport

PropertyTucDeskVPNSSH Jump HostTeleport
Identity modelED25519 per agentNetwork boundaryShared SSH keyCertificate authority
Credential exposureNone β€” keypair localVPN credentialsSSH private keyCA certificate
Audit trailSigned, tamper-evidentVariesVariesYes
Session recordingSigned asciinemaNoNoYes
AI agent accessMCP OAuth/PKCENoNoLimited
NAT traversalP2P + TURN relayRequires VPN gatewayRequires jump hostProxy tunnel
Forward secrecyYes β€” X25519 ECDHDepends on configDepends on configYes
Self-hostedFull feature parityYesYesLimited OSS
LicenseProprietary (TucLink is MIT)VariousN/AApache 2.0 (OSS)
VULNERABILITY DISCLOSURE

Responsible disclosure

Email security@tucdesk.app with a description, reproduction steps, and severity assessment. We acknowledge within 24 hours and provide a remediation timeline within 72 hours of triage. Good-faith researchers are protected β€” we do not pursue legal action for responsible disclosure.