Logo

Kapitel 3 Systemarchitektur und Datenfluss

Dieses Kapitel beschreibt die übergeordneten Systemkomponenten und den durchgängigen Datenfluss für Upload, Download und Absenderverwaltung. Der Schwerpunkt liegt darauf, was verschlüsselt wird, welche Metadaten erforderlich sind und wie Zugriffskontrolle und Widerruf durchgesetzt werden.

Dokumentmetadaten

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

3.1 Komponenten

  • Client: teilt Dateien in Chunks auf, verschlüsselt/entschlüsselt und verwaltet den CEK im URL-Fragment.
  • API/Edge: stellt Tokens mit begrenztem Geltungsbereich aus und validiert sie; liefert Manifest und Chiffretext-Chunks aus.
  • Objektspeicher: speichert verschlüsselte Chunks und Manifeste; wird hinsichtlich der Vertraulichkeit des Klartexts als nicht vertrauenswürdig behandelt.
  • Statusspeicher: verfolgt den Transferstatus (Upload-Fortschritt, Ablauf, Widerruf) mit minimalen Metadaten.

3.2 Datenobjekte

  • Manifest: öffentliche Parameter, die zum Abrufen und Zusammensetzen der Chunks erforderlich sind (cryptoVersion, Chunk-Größe/-Anzahl, Zuordnung); DARF den CEK NICHT enthalten.
  • Chunk: verschlüsseltes Dateistück (Chiffretext) plus minimale Metadaten (Länge/ETag), adressiert über (transferId, fileId, chunkIndex).
  • Status: serverseitiger Datensatz für Autorisierung, TTL, Widerruf und Wiederaufnahmefähigkeit.

3.3 Upload-Ablauf

  1. Der Client erstellt einen Transfer und erhält ein kurzlebiges Upload-Token mit begrenztem Geltungsbereich, das an transferId gebunden ist.
  2. Der Client erzeugt den CEK pro Datei lokal, teilt Dateien in Chunks fester Größe auf und verschlüsselt jeden Chunk mit AEAD.
  3. Der Client lädt Chiffretext-Chunks parallel hoch; Wiederholungsversuche sind pro Chunk idempotent.
  4. Der Client lädt das Manifest hoch (nur öffentliche Parameter). Der Server markiert den Transfer als READY, sobald die erforderlichen Teile vorliegen.

3.4 Download-Ablauf

  1. Der Empfänger öffnet den Freigabelink. Das URL-Fragment (CEK-Material) verbleibt im Browser und wird nicht an den Server gesendet.
  2. Der Client ruft das Manifest mit einem Download-Token mit begrenztem Geltungsbereich ab und ermittelt den Chunk-Plan.
  3. Der Client lädt Chiffretext-Chunks herunter (optional parallel), prüft die AEAD-Authentifizierung und setzt dann die Klartextdatei zusammen.
  4. Bei Fehlern setzt der Client fort, indem er nur fehlende Chunks anfordert; Integritätsfehler MÜSSEN im Fail-Closed-Modus enden.

3.5 Absenderverwaltung & Audit-Ablauf

  • Absender authentifizieren sich für Verwaltungsvorgänge mit einem langlebigen Anmelde-Token (auf dem Client gespeichert).
  • Verwaltungs-APIs ermöglichen es, Transfers aufzulisten, Zustellnachweise abzurufen und Transfers zu widerrufen/zu löschen.
  • Audit-Daten sind so konzipiert, dass sie nur für den Absender sichtbar sind; Empfängern werden sie standardmäßig nicht angezeigt.

3.6 Sichtbarkeit & Minimierung

  • Server und Speicher verarbeiten nur Chiffretext und notwendige öffentliche Parameter; ohne den CEK können sie Inhalte nicht entschlüsseln.
  • Logs und Analysen SOLLTEN minimiert werden und DÜRFEN KEINE URL-Fragmente oder CEK-Material enthalten.
  • Die Erhebung von Metadaten SOLLTE zweckgebunden sein (Zustellnachweis, Missbrauchsprävention und Betriebszuverlässigkeit).