Threat Model

What DRIVUNO is designed to protect against

• Provider staff reading user files or messages
  Content is encrypted client-side before upload. The server never receives keys.
• Database leaks
  Database contains ciphertext, sealed key envelopes, and minimal operational metadata. Plaintext content is not present.
• Storage backend compromise
  Object storage holds opaque encrypted blobs. Sealed file keys live in a separate scoped table.
• Lawful access for plaintext content
  We cannot produce material we do not possess. We can only hand over ciphertext and account metadata.
• Server-side scanning, AI analysis, or moderation
  There is no plaintext on the server to scan. We do not, and architecturally cannot, run content analysis on user files.
• Cross-tenant data leaks via RLS misconfiguration
  Every table is scoped by owner_id / recipient_id; sensitive RPCs are SECURITY DEFINER with explicit revocations. Audited regularly.
• Public share URL leaks (server-side)
  The share decryption key lives in the URL fragment and is never sent to the server.
• Offline password cracking of public shares
  Share-password checks require a server-side proof derived with Argon2id and are rate-limited; an attacker who intercepts the sealed envelope alone still cannot brute-force it offline at meaningful speed.
• A malicious or compromised subprocessor
  Subprocessors only ever handle ciphertext, sealed envelopes, or minimal operational metadata for the services they provide — none has a path to plaintext content or master keys. See the subprocessor registry.
• A stolen or lost device
  Auto-lock on inactivity, a PIN with progressive lockout, and in-memory key wipe on lock limit what a thief can do with a device before it's locked. Geo-anomaly detection flags sessions opened from unexpected locations.
• Abuse of the account-recovery flow
  Recovery factors are checked against a server-side proof rather than a directly reusable secret, and recovery attempts are rate-limited to slow down brute-force or social-engineering attempts against the flow itself.
• A compromised API key
  API keys are scoped to specific actions, stored server-side only as hashes, and can be revoked immediately. Because the API surface exposes metadata and lifecycle events only, a compromised key cannot be used to read decrypted content.
• IP exposure during P2P calls
  Rooms audio/video and screen-share default to a standard peer-to-peer mode, with relay and strict privacy modes available to reduce or eliminate direct IP exposure between participants.

What DRIVUNO does not fully protect against

• Endpoint malware on the user's device
  Keyloggers, infostealers, and remote-control malware can capture passwords and master keys at unlock time. No web cryptography defends against this.
• Malicious or compromised browser extensions
  Extensions with access to the page can read decrypted content. We minimize exposure but cannot eliminate it.
• Phishing of password and recovery factors
  If a user is tricked into entering both their password and a recovery code on an attacker's site, the attacker can unlock the account.
• Screenshots and physical photos of the screen
  Once content is rendered to a screen, an external camera can capture it. Watermarks are deterrence, not prevention.
• Active manipulation of a delivered frontend build
  If an attacker can swap or alter our JavaScript bundle, they can exfiltrate keys before encryption. We mitigate with strict CSP, self-hosted assets, code review, and reproducible builds — these reduce, not eliminate, risk.
• Loss of all recovery factors
  We deliberately have no backdoor. A user who loses their password, Recovery Key, and secondary channels cannot be helped.
• Password reuse across sites
  If a user reuses their DRIVUNO password and another site leaks the password in plaintext, brute force becomes the attacker's bottleneck. The Argon2id work factor is calibrated to be expensive even then, but we cannot reverse a leaked password.
• Sophisticated targeted endpoint attacks
  Targeted state-level malware on the user's device defeats all client-side cryptography. Sensitive operations should run on hardened devices.

Phase 10 hardening — what we are doing about the residual risks

The cryptography neutralizes the server. The biggest remaining risk is the client — the JavaScript your browser executes. We treat this as the most important class of threat for a zero-knowledge product and address it on several fronts.

• Recovery Key freshness Shipped
  Recovery Keys older than 365 days trigger a soft in-app reminder to rotate. The previous key is invalidated as soon as a new one is generated. Limits exposure if a stored copy is ever leaked.
• Admin second-factor reminder Shipped
  Admin accounts without a passkey or TOTP factor see a persistent banner in the operator console. Enforcement remains soft to avoid locking the sole admin out of their own infrastructure; hard enforcement with multi-admin recovery is on the roadmap below.
• Release transparency log Shipped
  Every release is published with date, channel, and release notes at /security/releases. High-stakes users can compare what their browser loads against the published list.
• Fail-closed key authentication (malicious-server model) Shipped
  The cheapest attack against any end-to-end encrypted service is not breaking the cipher — it is handing your device the wrong public key, so you encrypt for the attacker yourself. This is the flaw that broke several competitors in the 2024 ETH Zurich review. Every path in DRIVUNO that seals key material for someone else — Team Drive folder keys, Rooms attachments, mailbox messages, intra-DRIVUNO shares, Live Clone shares — now refuses to run unless the recipient key is resolved through the trust layer. There is no fallback to the key the API handed us: an unverifiable key aborts the operation instead of silently downgrading it.
  • Self-signed bundles. Each key bundle carries an Ed25519 self-signature. A bad signature is rejected outright.
  • Downgrade detection. If a contact was ever seen with a signed key, a later unsigned key for the same contact is refused — the server cannot strip signatures to weaken a peer.
  • Local pin mirror. Fingerprints are mirrored into device-local storage. An attacker with full database control who deletes the server-side pin still faces a client that remembers the old key and blocks the change until a human verifies the safety number.
  • Append-only ledger cross-check. Before trusting a first-seen key, the client checks it against the insert-only key history log. A key that never appears there is rejected.
• Failed verification is a refusal, not a warning Shipped
  Several end-to-end encrypted products detect a bad signature or a modified asset and then show a notice while continuing to operate. A warning the user can click past is not a control. In DRIVUNO, verification failure stops the operation:
  • Code integrity. On every page load the browser re-hashes the JavaScript actually executing in the tab against the published build manifest. A chunk whose hash differs, or any same-origin script the manifest never listed, blocks the vault from unlocking — the master key is never derived, so a backdoored bundle has nothing to steal. If the verdict lands while a session is already open, the vault locks itself and zeroes the keys.
  • Key signatures. An invalid Ed25519 self-signature, a changed fingerprint, or a stripped signature aborts the operation instead of proceeding with a warning.
  • AEAD tags. XChaCha20-Poly1305 is an authenticated mode: a modified ciphertext fails to open. There is no unauthenticated decryption path and no “decrypt anyway” fallback.
  • False positives are bounded. Being offline, a cache miss, or a preview build with no manifest yields “unverified”, not “tampered”, and never blocks. Only a positive mismatch refuses — locking someone out of their own data over a CDN hiccup would be a self-inflicted outage, not security.
• Length padding on stored content (Padmé) Shipped
  Encryption hides content; it does not hide size, and exact lengths are a fingerprint. Message subjects and bodies are now padded to Padmé buckets (Nikitin et al., PETS 2019) inside the AEAD before they are stored, so the server only ever observes a bucketed length. Padmé caps the overhead at about 12 % while collapsing the set of distinguishable sizes to O(log log n) — strictly better than power-of-two padding, which can double storage for the same effect. Reading stays backward-compatible: content written before padding decrypts unchanged.
• Subresource Integrity (SRI) on JS chunks Roadmap
  Browser-enforced SRI hashes on every dynamic chunk would move the check above from “detected before your key is derived” to “the chunk never executes at all”. Not shipped yet — the current Vite pipeline does not emit per-chunk integrity attributes for TanStack Start SSR-rendered preloads. The runtime manifest check covers the same attack today, and additionally catches injected scripts that SRI alone would not, so we are pursuing SRI as a build-tooling change rather than a half-working stopgap.
• Stricter CSP in Report-Only mode Shipped
  Every response now carries a second Content-Security-Policy-Report-Only header that forbids unsafe-inline for styles and requires Trusted Types for DOM-sink scripts. The browser does not block — it only reports violations to our collector. This lets us measure the real cost of promoting the policy to enforced before we ship a change that could break the UI.
• CSP without unsafe-inline for styles (enforced) Roadmap
  Promoting the Report-Only policy above to enforced requires migrating our component library's runtime style injections to per-request nonces. Tracked on the security roadmap.
• Public bug-bounty program Shipped
  Scope, rewards (€50–€5,000+), and safe-harbor terms are published at /security/bug-bounty. Reports go to security@drivuno.com.
• External penetration test Planned
  Independent review by a reputable cryptography firm is planned once the bounty program has had time to surface obvious issues.