Whitepaper zu Sicherheit und Datenschutz (Übersicht)Anhang
Anhang: Index der Claim-IDs (Single Source of Truth)
Dieser Anhang ist die einzige maßgebliche Quelle für alle Claim-IDs im Whitepaper. Jede Aussage (Claim) hat eine eindeutige, stabile Kennung und einen Anker und wird in einer einzigen Zeile mit einer Aussage und einem Beweis dargestellt. Beweise verweisen nur auf wiederholbar überprüfbare maßgebliche Referenzen (Kapitelanker oder Einstiegspunkte zu Status- bzw. Drittanbieterberichten) und nicht auf Screenshots oder erneut gehostete Inhalte.
Wartungsregeln
- MUST: Claim-IDs sind eindeutig und stabil; einmal veröffentlicht, werden sie nie wiederverwendet.
- MUST: Die Beweise zu jeder Aussage müssen wiederholbar überprüfbar sein (Kapitelanker oder maßgebliche Einstiegspunkte Dritter).
- MUST: Aussagen dürfen nur behaupten, was die Beweise belegen; vermeiden Sie Formulierungen von „absoluter Sicherheit“.
- SHOULD: Wenn Änderungen an der Implementierung oder an Richtlinien eine Aussage betreffen, halten Sie dies im Änderungsprotokoll fest und verlinken Sie die betroffenen Claim-IDs.
Kapitel 1–4 (Umfang, Bedrohungsmodell, Architektur, AuthZ)
SCOPE-01
Aussage: Das Dokument definiert klar, welche Risiken im Geltungsbereich liegen und welche nicht, sowie die Sicherheitsgrenze des Systems. Beweis:1.3， 1.4
THREAT-01
Aussage: Das Bedrohungsmodell umfasst Netzwerkangriffe, nicht autorisierte Downloads, speicher-/serverseitige Leseversuche und browserseitige Angreifer. Beweis:2.2
BOUNDARY-01
Aussage: Vertrauensgrenzen trennen die Verantwortlichkeiten klar zwischen Client, Server, Objektspeicher und externer Umgebung; der Server DARF den CEK NICHT erhalten. Beweis:2.4
FAILCLOSE-01
Aussage: Bei einem Authentifizierungsfehler oder einem inkonsistenten Kontext muss das System geschlossen fehlschlagen (Fail-Closed) und darf keinen Teil-Klartext ausgeben. Beweis:2.5
ARCH-01
Aussage: Die zentralen Datenobjekte sind klar getrennt: verschlüsselte Chunks, Manifest und Audit-Daten sind voneinander isoliert. Beweis:3.2
FLOW-UP-01
Aussage: Der Upload-Ablauf umfasst das Erstellen einer transferId und die Ausgabe kurzlebiger Zugriffstoken (Lookup-basierte Sitzungstoken) mit strikten Kontrollen von Geltungsbereich und Ablauf. Beweis:3.3
FLOW-DL-01
Aussage: Downloads lesen das URL-Fragment aus, um den CEK zu erhalten; das Lesen von Manifest und Chunks verwendet Token mit unterschiedlichem Geltungsbereich; Authentifizierungsfehler führen zu Fail-Closed. Beweis:3.4， 2.5
AUTH-TOKEN-01
Aussage: Kurzlebige Zugriffstoken sind serverseitige Sitzungstoken (Lookup-basiert), die ablaufen und zur Zugriffskontrolle auf Chiffretext und Manifeste dienen. Beweis:4.2
AUTH-SCOPE-01
Aussage: Token sind nach Scopes wie read_manifest / read_chunk / upload_chunk getrennt und werden streng validiert. Beweis:4.3， 4.4， 3.4
AUTH-PAID-01
Aussage: Zahlende Nutzer melden sich über einen einmalig verwendbaren Magic Link an und erhalten ein langlebiges, auf dem Client gehaltenes Token für Verwaltungsaktionen auf der Absenderseite. Beweis:4.1， 3.5
REVOKE-01
Aussage: Der Absender kann den Zugriff widerrufen: Das Löschen eines Transfers oder das Entfernen von Dateien macht Downloads vorzeitig ungültig und verweigert jeden späteren Zugriff. Beweis:4.5
AUDIT-01
Aussage: Audit-Daten wie Download-Anzahl und Fortschritt sind nur für den Absender sichtbar, nicht für den Empfänger. Beweis:4.6， 3.5
LOG-01
Aussage: Client- und Server-Logs/-Telemetrie enthalten weder den CEK noch URL-Fragmente noch daraus ableitbares Schlüsselmaterial. Beweis:4.7， 10.2
Kapitel 5 (Kryptographie und Schlüsselverwaltung)
CRYPTO-ZK-01
Aussage: Der CEK wird nur im Browser generiert und über das URL-Fragment verteilt; der Server erzeugt nie einen vollständigen Download-Link, der den CEK enthält. Beweis:5.3.1， 5.3.2
CRYPTO-ZK-02
Aussage: Der Server empfängt, speichert und protokolliert den CEK nicht; der Objektspeicher speichert nur verschlüsselte Chunks. Beweis:5.0， 5.5.1
CRYPTO-E2EE-01
Aussage: Chunks verwenden AES-128-GCM; ein Authentifizierungsfehler muss geschlossen fehlschlagen (Fail-Closed) und darf keinen Teil-Klartext ausgeben. Beweis:5.4.2， 5.8.4
CRYPTO-CHUNK-01
Aussage: chunkSize ist fest auf 16 MB (16777216) gesetzt. Beweis:5.4.1， 5.8.1
CRYPTO-NONCE-01
Aussage: Der IV wird als noncePrefix(8B)||uint32_be(chunkIndex) abgeleitet und darf sich unter demselben CEK nicht wiederholen. Beweis:5.4.3， 5.8.1
CRYPTO-AAD-01
Aussage: Die AAD ist an transferId + fileId + chunkIndex gebunden und wird über EncodeAAD_v1 kodiert. Beweis:5.4.4
CRYPTO-CLIENT-01
Aussage: Download- und Entschlüsselungsseiten laden keine Skripte von Drittanbietern; Client-Logs/-Telemetrie enthalten weder Fragmente noch Schlüsselmaterial. Beweis:5.6， 10.2
CRYPTO-TLS-01
Aussage: HTTPS wird auf der gesamten Website erzwungen; die TLS-Konfiguration ist über öffentliche Berichte von Drittanbietern überprüfbar. Beweis:5.1.2， /status#tls-configuration
Kapitel 6–7 (Datenlebenszyklus/Abwehr gegen Missbrauch)
LIFECYCLE-01
Aussage: Ablauf und vom Nutzer ausgelöstes Löschen lösen eine Bereinigung aus; ein Widerruf wird unterstützt, um Downloads vorzeitig ungültig zu machen. Beweis:6.2， 6.3， 4.5
ABUSE-01
Aussage: Die Missbrauchsabwehr nutzt Ratenbegrenzung und abgestufte Kontrollen und arbeitet, ohne die Zero-Knowledge-Grenze zu verletzen. Beweis:7.2， 7.4
Kapitel 8–9 (Datenschutz / Web-Sicherheit und -Isolation)
PRIVACY-01
Aussage: Definition und Zusagen zu Zero-Knowledge sind ausdrücklich festgehalten: Der CEK wird nur auf dem Client generiert und verwendet; der Server kann den Schlüssel nicht wiederherstellen. Beweis:8.1
PRIVACY-02
Aussage: Die Datenschutzfolgen von URL-Fragmenten (Kopieren/Einfügen, Referrer-Leaks, Protokollierung) sind samt Gegenmaßnahmen dokumentiert. Beweis:8.2， 10.2
WEB-01
Aussage: Wichtige Seiten erzwingen eine strikte CSP und klare Ressourcengrenzen, um das Risiko von Einschleusung und Clickjacking zu verringern. Beweis:9.1， 9.3
WEB-HEADERS-01
Aussage: Die Baseline der Sicherheits-Header ist über öffentliche Berichte von Drittanbietern überprüfbar. Beweis:/status#security-headers
WEB-OBS-01
Aussage: Die Website kann über öffentliche Best-Practice-Scans von Drittanbietern geprüft werden. Beweis:/status#http-observatory
Kapitel 10–12 (Protokollierung und IR/Offenlegung von Sicherheitslücken/Beweise)
OBS-01
Aussage: Die Beobachtbarkeit folgt dem Minimalprinzip, deckt nur betriebliche und sicherheitsrelevante Anforderungen ab und nutzt Aggregations- und Sampling-Strategien. Beweis:10.1
IR-01
Aussage: Ein Prozess zur Reaktion auf Sicherheitsvorfälle ist definiert (Schweregrad, Eindämmung, Postmortem, Behebung und öffentliche Bekanntmachung). Beweis:10.4
VDP-01
Aussage: Es gibt einen Prozess zur Offenlegung von Schwachstellen, der Probleme priorisiert, die die Zero-Knowledge-Grenze betreffen könnten. Beweis:11.2
EV-01
Aussage: Die Statusseite bündelt Einstiegspunkte zu Beweisen von Drittanbietern; die Beweise verweisen auf maßgebliche Quellen und stellen die Grenzen der Anwendbarkeit klar. Beweis:12.2， 12.6