Logo

Kapitel 3 Systemarchitektur und Datenfluss

In diesem Kapitel werden die übergeordneten Systemkomponenten und der End-to-End-Datenfluss für Upload, Download und Absenderverwaltung beschrieben. Der Schwerpunkt liegt darauf, was verschlüsselt wird, welche Metadaten erforderlich sind und wie Zugriffskontrolle und -sperrung durchgesetzt werden.

Dokumentmetadaten

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

3.1 Komponenten

  • Client: Chunks Dateien, verschlüsselt/entschlüsselt und verwaltet CEK im URL-Fragment.
  • API/Edge: gibt bereichsbezogene Token aus und validiert sie; stellt Manifest- und Chiffretext-Blöcke bereit.
  • Objektspeicher: speichert verschlüsselte Blöcke und Manifeste; werden aus Gründen der Vertraulichkeit im Klartext als nicht vertrauenswürdig behandelt.
  • Staatsladen: Verfolgt den Übertragungsstatus (Upload-Fortschritt, Ablauf, Widerruf) mit minimalen Metadaten.

3.2 Datenobjekte

  • Manifest: öffentliche Parameter, die zum Abrufen und Zusammenstellen von Chunks erforderlich sind (cryptoVersion, Chunk-Größe/Anzahl, Zuordnung); DARF KEIN CEK enthalten.
  • Chunk: verschlüsseltes Dateistück (Chiffretext) plus minimale Metadaten (Länge/Etag), adressiert durch (transferId, fileId, chunkIndex).
  • State: serverseitiger Datensatz für Autorisierung, TTL, Widerruf und Wiederaufnahmebarkeit.

3.3 Upload-Ablauf

  1. Der Client erstellt eine Übertragung und erhält ein kurzlebiges, bereichsgebundenes Upload-Token, an das gebunden ist transferId.
  2. Der Client generiert lokal pro Datei CEK, teilt Dateien in Blöcke fester Größe auf und verschlüsselt jeden Block mit AEAD.
  3. Der Client lädt Chiffretextblöcke parallel hoch; Wiederholungsversuche sind pro Block idempotent.
  4. Der Client lädt das Manifest hoch (nur öffentliche Parameter). Der Server markiert die Übertragung als BEREIT, wenn erforderliche Teile vorhanden sind.

3.4 Download-Flow

  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 mithilfe eines bereichsbezogenen Download-Tokens ab und bestimmt den Blockplan.
  3. Der Client lädt Chiffretextblöcke herunter (optional parallel), überprüft die AEAD-Authentifizierung und stellt dann die Klartextdatei zusammen.
  4. Bei Fehlern fährt der Client fort, indem er nur fehlende Chunks anfordert. Integritätsfehler MÜSSEN geschlossen ausfallen.

3.5 Absenderverwaltung und Prüfablauf

  • Absender authentifizieren sich für Verwaltungsvorgänge mithilfe eines langlebigen Anmeldetokens (auf dem Client gespeichert).
  • Verwaltungs-APIs ermöglichen das Auflisten von Übertragungen, das Überprüfen von Zustellungsnachweisen und das Widerrufen/Löschen von Übertragungen.
  • Prüfdaten sind so konzipiert, dass sie nur für den Absender sichtbar sind. Es wird den Empfängern standardmäßig nicht angezeigt.

3.6 Sichtbarkeit und Minimierung

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