Logo

Chapter 2 Threat Model & Trust Boundaries

This chapter establishes a shared threat model and trust boundary vocabulary: what assets we protect, what attackers can do, which assumptions must hold, and how the system MUST fail closed on authentication or parameter mismatch.

Document metadata

Whitepaper version
v1.0
Last updated
2026-01-14

2.1 Asset inventory

  • Content confidentiality: plaintext file bytes and decryption keys (CEK) MUST be protected.
  • Content integrity: ciphertext and metadata MUST be tamper-evident (AEAD authentication).
  • Access control: short-lived access tokens, sender login tokens, and revocation state.
  • Availability: ability to upload, download, and resume transfers under common network conditions.

2.2 Attacker model

  • Network attacker: can observe, delay, drop, and replay traffic; cannot break modern TLS/AEAD cryptography.
  • Web attacker: can craft malicious links, try XSS/CSRF, and attempt UI injection/prompt injection.
  • Abuse actor: can automate uploads/downloads to exhaust quotas, scrape content, or amplify traffic.
  • Server-side adversary is assumed not to have the CEK; if CEK is leaked (e.g., link shared), confidentiality is lost by design.

2.3 Security assumptions

  • Clients execute trusted code (no malicious extensions/malware); otherwise zero-knowledge cannot protect the endpoint.
  • URL fragments (#...) are not transmitted to the server via HTTP requests under standard browser behavior.
  • Cryptographic primitives (AES-GCM, SHA-256, TLS) are used correctly and are not broken.

2.4 Trust boundaries

  • Client boundary: encryption/decryption and CEK management happen only in the client.
  • Edge/API boundary: server validates tokens and serves ciphertext/manifest; MUST NOT learn CEK.
  • Object storage boundary: stores ciphertext chunks and manifests; treated as untrusted for confidentiality.

2.5 Fail-closed principle

  • On token failure, parameter mismatch, or AEAD authentication failure, the system MUST fail closed.
  • MUST NOT output partial plaintext when integrity checks fail.
  • Error messages and logs SHOULD minimize sensitive data and MUST NOT include URL fragments, CEK, or derivable materials.