Kapitel 1 Übersicht und Sicherheitsumfang

Dieses Kapitel definiert den Zweck des Whitepapers, die normative Sprache und die Terminologie und legt die Sicherheitsziele und Randbedingungen von FileBolt fest. Eine klare Trennung zwischen Risiken im Geltungsbereich und Risiken außerhalb des Geltungsbereichs verhindert Missverständnisse darüber, was das System garantieren kann.

Dokument-Metadaten

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

Zurück zu: Whitepaper zu Sicherheit und Datenschutz (Übersicht)

1.0 Zweck

  • Das Sicherheitsdesign und die Vertrauensgrenzen von FileBolt für Nutzer und Prüfer beschreiben.
  • Erläutern, wie Vertraulichkeit und Integrität beim Hochladen, Speichern und Herunterladen geschützt werden.
  • Überprüfbare Nachweis-Links und Claim-IDs für Prüfung und Reproduzierbarkeit bereitstellen.

1.1 Normative Sprache und Begriffe

  • Normative Schlüsselwörter: MUSS / SOLLTE / KANN (entspricht MUST / SHOULD / MAY, Verwendung im Stil von RFC 2119).
  • CEK: Content Encryption Key (Inhaltsverschlüsselungsschlüssel); 16 Byte (128 Bit); einer pro Datei.
  • E2EE / Zero-Knowledge: Verschlüsselung und Entschlüsselung erfolgen auf dem Client; der Server verarbeitet nur Chiffretext und öffentliche Parameter und DARF den CEK NICHT erhalten.
  • transferId / fileId / chunkIndex: Kennungen für Übertragung, Datei und Chunk-Index.
  • manifest: öffentliche Parameter, die zum Herunterladen, Zusammensetzen und Entschlüsseln benötigt werden (z. B. cryptoVersion, chunkSize, Zuordnung); DARF den CEK NICHT enthalten.
  • Kurzlebiges Zugriffstoken: serverseitiges Sitzungstoken (Lookup-basiert), das den Zugriff auf Chiffretext und Manifest autorisiert; läuft konstruktionsbedingt ab.

1.2 Sicherheitsziele

  • Vertraulichkeit: Der Server DARF im Zero-Knowledge-Modell NICHT in der Lage sein, Nutzerinhalte zu entschlüsseln.
  • Integrität: Manipulationen MÜSSEN erkannt werden; ein AEAD-Authentifizierungsfehler MUSS zum Abbruch führen (Fail-Closed).
  • Zugriffskontrolle: Der Zugriff auf den Chiffretext MUSS durch eng begrenzte, ablaufende Token geschützt werden; Absender MÜSSEN den Zugriff widerrufen können.
  • Nachprüfbarkeit: minimale, für den Absender sichtbare Zustellnachweise bereitstellen und dabei die Offenlegung sensibler Daten minimieren.

1.3 Im Geltungsbereich

  • Zero-Knowledge-/E2EE-Grenze und Schlüsselbehandlung (URL-Fragment-Modell).
  • Parameter für chunkweise Verschlüsselung und Authentifizierung (cryptoVersion=v1).
  • Tokenbasierte Autorisierung für Upload, Download und Manifest-Abruf; Semantik des Widerrufs.
  • Web-Sicherheits-Baseline für Download- und Entschlüsselungsseiten (CSP, keine Skripte von Drittanbietern).

1.4 Außerhalb des Geltungsbereichs

  • Kompromittierte Endgeräte: Malware, bösartige Browser-Erweiterungen oder gerootete Geräte.
  • Absichtliche Weitergabe von Links durch Nutzer, Social Engineering oder Fehlkonfiguration.
  • Inhaltsscans auf Serverseite (nicht vereinbar mit striktem Zero-Knowledge-Inhaltsschutz).