Whitepaper zu Sicherheit und Datenschutz (Übersicht)Appendix
Anhang: Index der Anspruchs-IDs (Single Source of Truth)
Dieser Anhang ist die zentrale Informationsquelle für alle Anspruchs-IDs im Whitepaper. Jeder Anspruch verfügt über eine eindeutige, stabile Kennung und einen Anker und wird in einer einzigen Zeile mit einem dargestellt Statement and Evidence. Beweise verweisen nur auf wiederholbar überprüfbare maßgebliche Referenzen (Kapitelanker oder Status-/Drittanbieter-Berichtseinstiegspunkte) und nicht auf Screenshots oder neu gehostete Inhalte.
Wartungsregeln
- MUST: Anspruchs-IDs sind eindeutig und stabil; Einmal veröffentlicht, werden sie niemals wiederverwendet.
- MUST: Die Beweise jedes Anspruchs müssen wiederholbar überprüfbar sein (Kapitelanker oder maßgebliche Einstiegspunkte Dritter).
- MUST: Aussagen dürfen nur behaupten, was die Beweise belegen; Vermeiden Sie die Sprache der „absoluten Sicherheit“.
- SHOULD: Wenn sich Implementierungs- oder Richtlinienänderungen auf einen Anspruch auswirken, notieren Sie dies im Änderungsprotokoll und verknüpfen Sie die betroffenen Anspruchs-IDs.
Kapitel 1–4 (Umfang, Bedrohungsmodell, Architektur, AuthZ)
SCOPE-01
Statement: Das Dokument definiert klar die innerhalb des Geltungsbereichs liegenden und außerhalb des Geltungsbereichs liegenden Risiken sowie die Grenzen der Systemsicherheit. Evidence:1.3， 1.4
THREAT-01
Statement: Das Bedrohungsmodell umfasst Netzwerkangriffe, nicht autorisierte Downloads, speicher-/serverseitige Leseversuche und browserseitige Angreifer. Evidence:2.2
BOUNDARY-01
Statement: Vertrauensgrenzen trennen die Verantwortlichkeiten klar zwischen Client, Server, Objektspeicher und externer Umgebung. Der Server DARF NICHT CEK erhalten. Evidence:2.4
FAILCLOSE-01
Statement: Bei einem Authentifizierungsfehler oder einem inkonsistenten Kontext muss das System ausfallen und darf keinen teilweisen Klartext ausgeben. Evidence:2.5
ARCH-01
Statement: Kerndatenobjekte sind klar getrennt: Verschlüsselte Blöcke, Manifest- und Prüfdaten sind voneinander isoliert. Evidence:3.2
FLOW-UP-01
Statement: Der Upload-Ablauf umfasst das Erstellen einer Transfer-ID und das Ausstellen kurzlebiger Zugriffstoken (suchbasierter Sitzungstoken) mit strengen Umfangs- und Ablaufkontrollen. Evidence:3.3
FLOW-DL-01
Statement: Downloads analysieren das URL-Fragment, um CEK zu erhalten; Manifest- und Chunk-Lesevorgänge verwenden Token mit unterschiedlichem Gültigkeitsbereich. Authentifizierungsfehler werden nicht geschlossen. Evidence:3.4， 2.5
AUTH-TOKEN-01
Statement: Kurzlebige Zugriffstoken sind serverseitige Sitzungstoken (suchbasiert), die ablaufen und zur Zugriffskontrolle auf Chiffretext und Manifeste verwendet werden. Evidence:4.2
AUTH-SCOPE-01
Statement: Token werden durch Bereiche wie read_manifest / read_chunk / upload_chunk getrennt und streng validiert. Evidence:4.3， 4.4， 3.4
AUTH-PAID-01
Statement: Bezahlte Benutzer melden sich über einen einmaligen magischen Link an und erhalten einen langlebigen, vom Client gehaltenen Token für senderseitige Verwaltungsaktionen. Evidence:4.1， 3.5
REVOKE-01
Statement: Der Absender kann den Zugriff widerrufen: Durch das Löschen einer Übertragung oder das Entfernen von Dateien werden Downloads vorzeitig ungültig und ein späterer Zugriff wird verweigert. Evidence:4.5
AUDIT-01
Statement: Prüfdaten wie Download-Anzahl und Fortschritt sind nur für den Absender und nicht für den Empfänger sichtbar. Evidence:4.6， 3.5
LOG-01
Statement: Client- und Serverprotokolle/Telemetriedaten enthalten keine CEK, URL-Fragmente oder ableitbares Schlüsselmaterial. Evidence:4.7， 10.2
Kapitel 5 (Kryptographie und Schlüsselverwaltung)
CRYPTO-ZK-01
Statement: CEK wird nur im Browser generiert und über das URL-Fragment verteilt; Der Server generiert niemals einen vollständigen Download-Link, der CEK enthält. Evidence:5.3.1， 5.3.2
CRYPTO-ZK-02
Statement: Der Server empfängt/speichert/protokolliert keinen CEK; Objektspeicher speichert nur verschlüsselte Blöcke. Evidence:5.0， 5.5.1
CRYPTO-E2EE-01
Statement: Chunks verwenden AES-128-GCM; Der Authentifizierungsfehler muss fehlschlagen und darf keinen teilweisen Klartext ausgeben. Evidence:5.4.2， 5.8.4
CRYPTO-CHUNK-01
Statement: chunkSize ist auf 16 MB (16777216) festgelegt. Evidence:5.4.1， 5.8.1
CRYPTO-NONCE-01
Statement: IV wird als noncePrefix(8B)||uint32_be(chunkIndex) abgeleitet und darf sich nicht unter demselben CEK wiederholen. Evidence:5.4.3， 5.8.1
CRYPTO-AAD-01
Statement: AAD ist an transferId + fileId + chunkIndex gebunden und über EncodeAAD_v1 codiert. Evidence:5.4.4
CRYPTO-CLIENT-01
Statement: Download-/Entschlüsselungsseiten laden keine Skripte von Drittanbietern; Client-Protokolle/Telemetriedaten enthalten keine Fragmente oder Schlüsselmaterial. Evidence:5.6， 10.2
CRYPTO-TLS-01
Statement: Siteweites HTTPS wird erzwungen; Die TLS-Konfiguration ist über öffentliche Berichte von Drittanbietern überprüfbar. Evidence:5.1.2， /status#tls-configuration
Kapitel 6–7 (Datenlebenszyklus/Abwehr gegen Missbrauch)
LIFECYCLE-01
Statement: Ablauf und vom Benutzer initiierte Löschung lösen eine Bereinigung aus; Der Widerruf wird unterstützt, um Downloads vorzeitig ungültig zu machen. Evidence:6.2， 6.3， 4.5
ABUSE-01
Statement: Die Missbrauchsabwehr nutzt Ratenbegrenzung und abgestufte Kontrollen, ohne die Zero-Knowledge-Grenze zu überschreiten. Evidence:7.2， 7.4
Kapitel 8–9 (Datenschutz / Web-Sicherheit und -Isolation)
PRIVACY-01
Statement: Die Zero-Knowledge-Definition und die Verpflichtungen sind explizit: CEK wird nur auf dem Client generiert und verwendet; Der Server kann den Schlüssel nicht wiederherstellen. Evidence:8.1
PRIVACY-02
Statement: Datenschutzauswirkungen von URL-Fragmenten (Kopieren/Einfügen, Referrer-Leaking, Protokollierung) werden durch Abhilfemaßnahmen dokumentiert. Evidence:8.2， 10.2
WEB-01
Statement: Wichtige Seiten erzwingen strenge CSP- und Ressourcengrenzen, um das Einschleusungs- und Clickjacking-Risiko zu reduzieren. Evidence:9.1， 9.3
WEB-HEADERS-01
Statement: Die Basislinie der Sicherheitsheader kann anhand öffentlicher Berichte von Drittanbietern überprüft werden. Evidence:/status#security-headers
WEB-OBS-01
Statement: Die Website kann über öffentliche Best-Practice-Scans von Drittanbietern überprüft werden. Evidence:/status#http-observatory
Kapitel 10–12 (Protokollierung und IR/Offenlegung von Sicherheitslücken/Beweise)
OBS-01
Statement: Die Beobachtbarkeit folgt einem Minimalprinzip, das nur Betriebs-/Sicherheitsanforderungen abdeckt und Aggregations-/Sampling-Strategien verwendet. Evidence:10.1
IR-01
Statement: Es wird ein Prozess zur Reaktion auf Sicherheitsvorfälle definiert (Schweregrad, Eindämmung, Postmortem, Behebung und öffentliche Bekanntmachung). Evidence:10.4
VDP-01
Statement: Es gibt einen Prozess zur Offenlegung von Schwachstellen, der Probleme priorisiert, die sich auf die Zero-Knowledge-Grenze auswirken könnten. Evidence:11.2
EV-01
Statement: Auf der Statusseite werden Beweiseingangspunkte von Drittanbietern zusammengefasst. Beweise verweisen auf maßgebliche Quellen und verdeutlichen die Grenzen der Anwendbarkeit. Evidence:12.2， 12.6