SECURITY ARCHITECTURE

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

Every design decision in TucDesk prioritizes security over convenience. This page documents the cryptographic and access-control model.

identityED25519

handshakeX25519 ECDH

key derivationHKDF-SHA256

payloadAES-256-GCM

relay visibilityciphertext only

CRYPTOGRAPHIC PROTOCOL

The data path is encrypted before transport

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.

ACCESS CONTROL

Policy evaluates before session creation

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.

AUDIT TRAIL