Logo

Kapitel 2 Bedrohungsmodell und Vertrauensgrenzen

In diesem Kapitel wird ein gemeinsames Vokabular für Bedrohungsmodell und Vertrauensgrenzen festgelegt: welche Schutzgüter wir schützen, was Angreifer tun können, welche Annahmen gelten müssen und wie das System bei Authentifizierungs- oder Parameterabweichungen im Fehlerfall geschlossen bleiben (Fail-Closed) MUSS.

Dokumentmetadaten

Whitepaper-Version
v1.0
Zuletzt aktualisiert
2026-01-14

2.1 Inventar der Schutzgüter

  • Vertraulichkeit der Inhalte: Klartext-Dateiinhalte und Entschlüsselungsschlüssel (CEK) MÜSSEN geschützt werden.
  • Integrität der Inhalte: Chiffretext und Metadaten MÜSSEN Manipulationen erkennbar machen (AEAD-Authentifizierung).
  • Zugriffskontrolle: kurzlebige Zugriffstoken, Anmeldetoken der Absender und Widerrufsstatus.
  • Verfügbarkeit: die Möglichkeit, Übertragungen unter üblichen Netzwerkbedingungen hochzuladen, herunterzuladen und fortzusetzen.

2.2 Angreifermodell

  • Netzwerkangreifer: kann Datenverkehr beobachten, verzögern, verwerfen und erneut einspielen; kann moderne TLS-/AEAD-Kryptografie nicht brechen.
  • Web-Angreifer: kann bösartige Links erstellen, XSS/CSRF versuchen sowie UI-Injection/Prompt-Injection unternehmen.
  • Missbrauchsakteur: kann Uploads/Downloads automatisieren, um Kontingente zu erschöpfen, Inhalte abzugreifen oder den Datenverkehr zu verstärken.
  • Es wird angenommen, dass der serverseitige Gegner den CEK nicht besitzt; wird der CEK offengelegt (z. B. weil der Link geteilt wird), geht die Vertraulichkeit konstruktionsbedingt verloren.

2.3 Sicherheitsannahmen

  • Clients führen vertrauenswürdigen Code aus (keine bösartigen Erweiterungen/Malware); andernfalls kann Zero-Knowledge den Endpunkt nicht schützen.
  • URL-Fragmente (#...) werden bei Standardverhalten des Browsers nicht mit HTTP-Anfragen an den Server übertragen.
  • Kryptografische Primitive (AES-GCM, SHA-256, TLS) werden korrekt eingesetzt und sind nicht gebrochen.

2.4 Vertrauensgrenzen

  • Client-Grenze: Ver- und Entschlüsselung sowie die Verwaltung des CEK finden ausschließlich im Client statt.
  • Edge-/API-Grenze: Der Server prüft Token und liefert Chiffretext/Manifest aus; er DARF den CEK NICHT erfahren.
  • Objektspeicher-Grenze: speichert Chiffretext-Blöcke und Manifeste; wird hinsichtlich der Vertraulichkeit als nicht vertrauenswürdig behandelt.

2.5 Fail-Closed-Prinzip

  • Bei einem Token-Fehler, einer Parameterabweichung oder einem AEAD-Authentifizierungsfehler MUSS das System den Vorgang abweisen (Fail-Closed).
  • Wenn Integritätsprüfungen fehlschlagen, DARF KEIN teilweiser Klartext ausgegeben werden.
  • Fehlermeldungen und Protokolle SOLLTEN sensible Daten minimieren und DÜRFEN KEINE URL-Fragmente, keinen CEK und keine daraus ableitbaren Materialien enthalten.