Logo

Whitepaper zu Sicherheit und Datenschutz (Übersicht)Kapitel 5

Kapitel 5 Kryptographie und Schlüsselverwaltung

In diesem Kapitel werden die Ende-zu-Ende-Verschlüsselung (E2EE) und die Zero-Knowledge-Grenze von FileBolt beschrieben und spezifiziert cryptoVersion=v1 Parameter, Codierungsregeln, Fehlermodi und Client-Einschränkungen. Schlüssel werden auf dem Client generiert und verwendet; Der Server und der Objektspeicher verarbeiten nur Chiffretextblöcke und erforderliche Metadaten.

5.0 Zusammenfassung

  • Das System DARF KEINE Entschlüsselungsschlüssel (CEK) empfangen, speichern oder protokollieren. CEK-Material wird nur im URL-Fragment übertragen (# Teil), der in HTTP-Anfragen nicht an den Server gesendet wird.
  • Verschlüsselung verwendet AES-128-GCM (AEAD). Jede Datei verwendet einen unabhängigen CEK (16 Byte). Die Chunk-Größe ist fest (z. B. 16 MB).
  • v1 IV-Konstruktion: IV = noncePrefix(8B) || uint32_be(chunkIndex)(4B). AAD binds transferId, fileId, und chunkIndex um Kontextaustausch und Wiedergabe zu verhindern.
  • Server-Tokens steuern nur den Zugriff auf Chiffretext und verfallen; Sie gewähren keine Entschlüsselungsfunktion.

5.1 Transportverschlüsselung (TLS)

5.1.1 Sicherheitsziel

  • Verhindern Sie das Abhören und Manipulieren von Upload-/Download-/API-Links.
  • Schützen Sie Token und Chiffretext während der Übertragung.

5.1.2 Sicherheitsrichtlinie

  • Das System MUST Alle Seiten und APIs nur über HTTPS bereitstellen.
  • Das System SHOULD bevorzugen Sie TLS 1.3 und unterstützen Sie TLS 1.2 nach Bedarf; Schwache Protokolle/Verschlüsselungen MÜSSEN deaktiviert werden.
  • Das System MUST Aktivieren Sie HSTS mit einem angemessenen Preis max-age.

5.2 Chunk-Verschlüsselung (AES-128-GCM)

5.2.1 Designhinweise

  • Dateien werden in Blöcke fester Größe aufgeteilt; Jeder Block wird unabhängig verschlüsselt, um parallele Übertragung und Wiederaufsetzbarkeit zu unterstützen.
  • Die AEAD-Authentifizierung schützt die Integrität. Jeder Authentifizierungsfehler MUSS fehlschlagen.

5.2.2 Sicherheitsrichtlinie

  • Jede Datei MUSS einen eindeutigen CEK (16 Byte) verwenden.
  • IV MUSS pro (Datei, chunkIndex) eindeutig sein. v1 verwendet noncePrefix + chunkIndex encoding.
  • AAD MUSS (transferId, fileId, chunkIndex) enthalten, um Chiffretext an seinen Kontext zu binden.

5.3 Zero-Knowledge-Link-Modell

5.3.1 Wichtige Einschränkungen

  • CEK (oder Ableitungsmaterial) DARF nur im URL-Fragment enthalten sein und DARF NICHT in Abfrageparametern oder Headern enthalten sein.
  • Der Server DARF KEINE Fragmente protokollieren; Protokolle MÜSSEN bereinigt werden, um eine versehentliche Erfassung zu vermeiden.
  • Die Referrer-Richtlinie SOLL den Verlust von Fragmenten über die ausgehende Navigation verhindern (siehe Kapitel 9).

5.4 Schlüsselgenerierung und -handhabung

  • Schlüssel MÜSSEN mit einem kryptografisch sicheren RNG (WebCrypto) generiert werden.
  • Schlüssel SOLLTEN nur im Speicher aufbewahrt und gelöscht werden, wenn sie nicht mehr benötigt werden.
  • Clients DÜRFEN CEK NICHT an für den Server sichtbaren Orten speichern (z. B. Cookies, Abfrageparameter).

5.5 Kodierung und Parameter

  • cryptoVersion=v1 identifiziert Algorithmensuite und IV/AAD-Regeln.
  • Das Manifest MUSS erforderliche öffentliche Parameter (Chunk-Größe/-Anzahl, NoncePrefix, FileId-Zuordnung) enthalten, DARF jedoch KEIN CEK enthalten.

5.6 Fehlermodi (Fehler geschlossen)

  • Bei einem Entschlüsselungsfehler oder einem AEAD-Authentifizierungsfehler MÜSSEN Clients den Vorgang abbrechen und DÜRFEN KEINEN teilweisen Klartext ausgeben.
  • Bei Parameterkonflikten (transferId/fileId/chunkIndex) MÜSSEN Clients nicht geschlossen werden und SOLLTEN einen umsetzbaren Fehler melden.

5.7 Zugehörige Anspruchs-IDs