Every design decision in TucDesk prioritizes security over convenience.
This page explains the why behind TucDesk's security model in plain English. For protocol specs, cipher suites, key derivation, and audit chain implementation details, see the Security Architecture reference.
Identity Layer
Each agent generates an ED25519 identity keypair using crypto/rand. The private key stays local. Registration requires an EdDSA signature over a timestamped payload, and rendezvous verifies the signature against the public key.
Session Key Derivation
Operators and agents generate X25519 ephemeral keys for each session. HKDF with SHA-256 and label tucdesk-session-v1 derives the AES-256-GCM key. Session keys are not persisted, logged, or recoverable after disconnect.
Nonce Management
AES-256-GCM messages use monotonically increasing counters per session direction. A replay window rejects reused nonces and evicts old entries with an LRU + TTL strategy.
Relay Security
The relay forwards UDP/TCP ciphertext. It has no session keys, no plaintext logs, and no ability to decrypt terminal or command data.
Operator Authentication
Operators use EdDSA-signed JWTs containing team_id, email, role, and expiry. Sensitive actions also require signed operator proof bound to the request context.
Audit Integrity
Sensitive actions write signed audit records with actor, team, target, policy result, command context, and timestamp. Exports can be checked without trusting the relay path.
| Layer | Control |
|---|---|
| JWT team scope | team_id comes from signed claims, never from request body or URL. |
| Agent lookup | Targets are looked up with team_id in SQL and rendezvous registry checks. |
| ACL decision | Mode, allowlist, blocklist, tag, and time-window rules evaluate before connect. |
| Approval gate | High-risk command execution waits for explicit human confirmation. |
The problem with the VPN model
A traditional VPN flattens the network boundary. Once a device is inside the tunnel, it can usually see far more than the one machine it needed. That means a single compromised credential or laptop exposes everything behind the perimeter — file shares, databases, and hosts that had nothing to do with the original task.
How TucDesk is different
TucDesk treats every agent as its own cryptographic principal. Each session is end-to-end encrypted between exactly two endpoints with ephemeral keys, so compromising the relay, the server, or even an operator machine does not expose session content for other agents. There is no flat network to move laterally across — only individually authenticated, individually encrypted sessions.
actor
Captured in immutable audit output and exportable for incident review.
action
Captured in immutable audit output and exportable for incident review.
timestamp
Captured in immutable audit output and exportable for incident review.
team_id
Captured in immutable audit output and exportable for incident review.
session_id
Captured in immutable audit output and exportable for incident review.
policy_result
Captured in immutable audit output and exportable for incident review.
| Data | Cloud | Self-hosted |
|---|---|---|
| Session content | E2E encrypted; relay has no plaintext | E2E encrypted; your relay has no plaintext |
| Recordings | Encrypted at rest in R2 | Encrypted in your MinIO/S3 |
| Audit logs | TucDesk Postgres, signed | Your Postgres, signed |
| Runtime visibility | Usage and billing metadata | None for TucDesk at runtime |
Report security issues to security@tucnow.com. The coordinated disclosure window is 90 days. Scope includes the agent, API, dashboard, rendezvous, TURN relay, installers, and mobile server-profile flow.
Security that starts at the protocol level.
ED25519 identity, AES-256-GCM sessions, and signed audit chains are not features you enable — they are the foundation every connection is built on.
Responsible disclosure: security@tucnow.com · 90-day window