Logo

Whitepaper zu Sicherheit und Datenschutz (Übersicht)Kapitel 5

Kapitel 5 Kryptographie und Schlüsselverwaltung

Dieses Kapitel beschreibt die Ende-zu-Ende-Verschlüsselung (E2EE) und die Zero-Knowledge-Grenze von FileBolt und legt die cryptoVersion=v1-Parameter, Kodierungsregeln, Fehlermodi und Einschränkungen für den Client fest. Schlüssel werden auf dem Client erzeugt und verwendet; der Server und der Objektspeicher verarbeiten nur Chiffretext-Chunks und die erforderlichen Metadaten.

5.0 Zusammenfassung

  • Das System DARF Entschlüsselungsschlüssel (CEK) NICHT empfangen, speichern oder protokollieren. CEK-Material wird ausschließlich im URL-Fragment (dem Teil nach #) übertragen, das in HTTP-Anfragen nicht an den Server gesendet wird.
  • Die Verschlüsselung verwendet AES-128-GCM (AEAD). Jede Datei verwendet einen eigenen CEK (16 Byte). Die Chunk-Größe ist fest (z. B. 16 MB).
  • v1-IV-Konstruktion: IV = noncePrefix(8B) || uint32_be(chunkIndex)(4B). Die AAD bindet transferId, fileId und chunkIndex, um Kontexttausch und Replay zu verhindern.
  • Server-Tokens steuern nur den Zugriff auf den Chiffretext und laufen ab; sie verleihen keine Entschlüsselungsfähigkeit.

5.1 Transportverschlüsselung (TLS)

5.1.1 Sicherheitsziel

  • Abhören und Manipulation auf Upload-, Download- und API-Verbindungen verhindern.
  • Tokens und Chiffretext während der Übertragung schützen.

5.1.2 Sicherheitsrichtlinie

  • Das System MUSS alle Seiten und APIs ausschließlich über HTTPS bereitstellen.
  • Das System SOLLTE TLS 1.3 bevorzugen und bei Bedarf TLS 1.2 unterstützen; schwache Protokolle/Chiffren MÜSSEN deaktiviert werden.
  • Das System MUSS HSTS mit einem sinnvollen max-age aktivieren.

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

5.2.1 Entwurfshinweise

  • Dateien werden in Chunks fester Größe aufgeteilt; jeder Chunk wird unabhängig verschlüsselt, um parallele Übertragung und Wiederaufnahme zu unterstützen.
  • Die AEAD-Authentifizierung schützt die Integrität; jeder Authentifizierungsfehler MUSS im Fail-Closed-Modus enden.

5.2.2 Sicherheitsrichtlinie

  • Jede Datei MUSS einen eigenen CEK (16 Byte) verwenden.
  • Der IV MUSS pro (Datei, chunkIndex) eindeutig sein. v1 verwendet die Kodierung aus noncePrefix + chunkIndex.
  • Die AAD MUSS (transferId, fileId, chunkIndex) enthalten, um den Chiffretext an seinen Kontext zu binden.

5.3 Zero-Knowledge-Link-Modell

5.3.1 Zentrale Einschränkungen

  • Der CEK (oder Ableitungsmaterial) MUSS ausschließlich im URL-Fragment übertragen werden und DARF NICHT in Query-Parametern oder Headern enthalten sein.
  • Der Server DARF Fragmente NICHT protokollieren; Logs MÜSSEN bereinigt werden, um eine versehentliche Erfassung zu vermeiden.
  • Die Referrer-Richtlinie SOLLTE verhindern, dass Fragmente über ausgehende Navigation preisgegeben werden (siehe Kapitel 9).

5.4 Schlüsselerzeugung & -handhabung

  • Schlüssel MÜSSEN mit einem kryptografisch sicheren Zufallszahlengenerator (WebCrypto) erzeugt werden.
  • Schlüssel SOLLTEN nur im Arbeitsspeicher gehalten und gelöscht werden, sobald sie nicht mehr benötigt werden.
  • Clients DÜRFEN den CEK NICHT an für den Server sichtbaren Orten ablegen (z. B. in Cookies oder Query-Parametern).

5.5 Kodierung & Parameter

  • cryptoVersion=v1 kennzeichnet die Algorithmen-Suite sowie die IV-/AAD-Regeln.
  • Das Manifest MUSS die erforderlichen öffentlichen Parameter (Chunk-Größe/-Anzahl, noncePrefix, fileId-Zuordnung) enthalten, DARF aber den CEK NICHT enthalten.

5.6 Fehlermodi (Fail-Closed)

  • Bei einem Entschlüsselungsfehler oder einem AEAD-Authentifizierungsfehler MÜSSEN Clients abbrechen und DÜRFEN KEINEN teilweisen Klartext ausgeben.
  • Bei Parameterabweichungen (transferId/fileId/chunkIndex) MÜSSEN Clients im Fail-Closed-Modus abbrechen und SOLLTEN einen umsetzbaren Fehler melden.

5.7 Zugehörige Claim-IDs