Logo

Whitepaper zu Sicherheit und Datenschutz (Übersicht)Kapitel 11

Kapitel 11: Offenlegung von Sicherheitslücken und Sicherheitsupdates

FileBolt fördert die verantwortungsvolle Offenlegung und schafft Vertrauen durch vorhersehbare Mechanismen für Behebung und Kommunikation. Zugleich müssen sich die Sicherheitsfunktionen weiterentwickeln können: darunter Web-Sicherheitsrichtlinien, serverseitige Authentifizierungsmechanismen sowie Implementierungen der Ende-zu-Ende-Verschlüsselung und der Protokolle (z. B. Upgrades von cryptoVersion). Dieses Kapitel beschreibt die öffentlichen Kontaktkanäle, die Bearbeitungsabläufe sowie die Grundsätze für die Veröffentlichung von Korrekturen und Bekanntmachungen und erläutert die Strategien für versionierte Weiterentwicklung und Einstellung.

11.0 Zusammenfassung

  • MUSS: Öffentliche Kanäle für die Meldung von Schwachstellen bereitstellen (z. B. security.txt und Support-E-Mail).
  • SOLLTE: Verschlüsselte Übermittlungswege (z. B. einen PGP-Schlüssel) bereitstellen, damit Details sicher übermittelt werden können.
  • SOLLTE: Einen klaren Rhythmus für Reaktion und Behebung (SLA/Zielfristen) festlegen und bei Bedarf über die Statusseite kommunizieren.
  • MUSS: Schwachstellen, die Zero-Knowledge-Zusagen beeinträchtigen können (XSS, Supply-Chain-Injection, Leckage von Log-Fragmenten), mit höchster Priorität behandeln.
  • MUSS: Versionierte Weiterentwicklung (cryptoVersion) umsetzen und Strategien für Kompatibilität, Migration und Einstellung festlegen.

11.1 Kanäle und Kontakt für die Meldung von Schwachstellen

11.1.1 Öffentliche Anlaufstellen

  • MUSS: Meldekanäle für Schwachstellen, Ablaufdatum und Richtlinienlinks in /.well-known/security.txt bereitstellen.
  • MUSS: Eine erreichbare E-Mail-Adresse für Sicherheitskontakte bereitstellen (z. B. support@filebolt.net oder eine eigene Adresse security@filebolt.net).
  • SOLLTE: Kurze Hinweise und Richtlinien zur Einreichung auf der Seite Sicherheit und Datenschutz bereitstellen.

11.1.2 Verschlüsselte Übermittlung und Umgang mit sensiblen Informationen

  • SOLLTE: Einen öffentlichen PGP-Schlüssel (oder Gleichwertiges) bereitstellen, damit Forschende Details zur Reproduktion sicher übermitteln können.
  • MUSS: Intern die Sichtbarkeit von Schwachstellendetails nach dem Prinzip der geringsten Rechte durchsetzen und sie nur gegenüber Personen offenlegen, die sie für die Behebung benötigen.
  • MUSS: Forschenden untersagen, Klartext von Nutzern, CEK, URL-Fragmente oder ableitbares Schlüsselmaterial in Berichte aufzunehmen; falls dies versehentlich geschieht, MUSS das Team es als sensiblen Vorfall behandeln und die Weitergabe begrenzen.

11.2 Reaktionsfristen und Kommunikationsgrundsätze

Die Fristen hängen von der Teamgröße und der Komplexität ab, das Projekt SOLLTE jedoch einen vorhersehbaren Zielrhythmus bieten und zeitnah kommunizieren, wenn Ziele verfehlt werden. Empfohlene Ziele (je nach Realität anpassbar und unter /security oder in security.txt veröffentlicht):

  • Erste Reaktion: z. B. Eingang innerhalb von 48 Stunden bestätigen und eine Tracking-ID vergeben.
  • Erste Bewertung: z. B. Einstufung des Schweregrads und Bewertung des Auswirkungsumfangs innerhalb von 7 Tagen abschließen.
  • Veröffentlichung der Korrektur: Fortschritt je nach Schweregrad; P0/P1 werden bei Behebung und Veröffentlichung vorrangig behandelt.

SOLLTE: Während der Bearbeitung die nötige Kommunikation aufrechterhalten (z. B. reproduziert/nicht reproduziert, weitere Informationen erforderlich, voraussichtliches Behebungsfenster) und keine ausnutzbaren Details öffentlich machen.

11.3 Offenlegungsprozess

  1. Eingang: Angaben zum Bericht, Schritte zur Reproduktion, Auswirkungen und Kontakt der meldenden Person erfassen; Verantwortliche zuweisen und Nachverfolgung einrichten.
  2. Verifizierung: In einer isolierten Umgebung reproduzieren; Auswirkungsumfang, Ausnutzbarkeit und betroffene Komponenten (Frontend/Backend/Edge/Speicher) bewerten.
  3. Behebung: Patch umsetzen, Test-/Regressionsfälle hinzufügen und bei Bedarf Schutzregeln ergänzen (WAF/Rate Limit/Verschärfung von Richtlinien).
  4. Veröffentlichung: Canary-Release ausrollen und wichtige Kennzahlen überwachen; vollständige Veröffentlichung, nachdem keine Regression und keine neuen Risiken festgestellt wurden.
  5. Bekanntmachung: Auswirkungen, Inhalt der Korrektur und gegebenenfalls erforderliche Maßnahmen der Nutzer öffentlich erläutern, ohne die Angriffsfläche zu vergrößern.

Bei kritischen Schwachstellen oder Ereignissen mit großen Auswirkungen auf Nutzer SOLLTEN Ereignis-Updates oder Post-Mortems über /status veröffentlicht werden, abgestimmt auf den IR-Prozess aus Kapitel 10.

11.4 Schwachstellen, die die Zero-Knowledge-Grenzen betreffen

Der Kern der Zero-Knowledge-Zusage ist: Der Server kann nicht auf den CEK zugreifen, und die Umgebung für Download und Entschlüsselung ist möglichst ohne Skripte von Drittanbietern isoliert. Daher MÜSSEN die folgenden Kategorien mit höchster Priorität behandelt werden:

  • XSS / Injection: Möglichkeit, auf Download-/Entschlüsselungsseiten beliebige Skripte auszuführen und Fragmente oder Schlüsselmaterial im Speicher zu lesen.
  • Supply-Chain-Injection: Manipulierte Abhängigkeiten, ausgetauschte Build-Artefakte, CDN-/Edge-Injection, die zu manipulierten Skripten führen.
  • Leckage über Logs/Monitoring: URL-Fragment, CEK, Token oder Klartext werden versehentlich protokolliert und sind zugänglich.
  • Fehlerhafte Richtlinie zum Laden von Ressourcen: Download-/Entschlüsselungsseiten binden Skripte von Drittanbietern ein; gelockerte CSP vergrößert die Ausführungsfläche.

Die Behandlung sollte Folgendes umfassen: sofortige Eindämmung (riskanten Code offline nehmen, Richtlinien verschärfen, den Angriffsvektor sperren), schnelle Veröffentlichung einer Korrektur, rückblickende Analyse der Auswirkungen und in der Bekanntmachung eine klare Aussage dazu, „ob Schlüsselmaterial oder Klartext möglicherweise offengelegt wurde“.

11.5 Sicherheitsupdates und Regressionsprüfung

  • MUSS: Regressionsfälle für sicherheitsrelevante Änderungen einrichten (Authentifizierung, Zugriffskontrolle, CSP, Log-Filterung, Verschlüsselungsabläufe).
  • SOLLTE: Automatisierte Prüfungen für kritische Seiten (Download/Entschlüsselung) durchführen, um sicherzustellen, dass keine Skripte von Drittanbietern geladen werden und die Header-Richtlinien den Erwartungen entsprechen.
  • SOLLTE: Nach der Veröffentlichung einer Korrektur extern überprüfbare Punkte erneut testen (z. B. TLS-/Security-Header-Scans).
  • SOLLTE: Durch Korrekturen eingeführte Kompatibilitätsänderungen (z. B. alte Links/altes Manifest) in der Dokumentation klar festhalten.

Im Einklang mit Kapitel 12: Scans von Drittanbietern prüfen einige Web-Baselines, können aber die Details der vollständigen Zero-Knowledge-/E2EE-Implementierung nicht direkt belegen; daher sollte die Regressionsprüfung sowohl die Protokollimplementierung als auch die sichtbaren Baselines abdecken.

11.6 Versionierung von Protokollen und Kryptografie (cryptoVersion)

Die Verschlüsselungs- und Protokollimplementierung von FileBolt MUSS Versionierung unterstützen, um Algorithmen aktualisieren, Implementierungsfehler beheben und stärkere Isolation einführen zu können. Empfohlen werden explizite Felder (z. B. cryptoVersion), die im Manifest bzw. in den Metadaten gebunden sind.

  • Explizite Version: Jede Übertragung bzw. jedes Manifest MUSS seine cryptoVersion deklarieren, um Algorithmen, Parameter und Kodierungsregeln festzulegen.
  • Keine implizite Ableitung: Der Client MUSS Parsing und Entschlüsselung anhand expliziter Manifestfelder festlegen, nicht durch Raten oder Fallback-Heuristiken.
  • Fail Closed: Bei unbekannten Versionen oder inkonsistenten Parametern MUSS der Vorgang geschlossen fehlschlagen (Fail Closed); es darf nie auf unsichere Modi herabgestuft werden.

11.7 Kompatibilität, Migration und Einstellung

11.7.1 Abwärtskompatibilität

  • SOLLTE: Das Lesen alter Übertragungsversionen während Übergangszeiträumen unterstützen, um die Auswirkungen auf bestehende Links der Nutzer zu minimieren.
  • MUSS: Sicherheitsgrenzen, Einschränkungen und Einstellungspläne für alte Versionen öffentlich benennen.

11.7.2 Migration (unter Wahrung von Zero-Knowledge)

  • SOLLTE: Nutzerseitige Wege zum erneuten Hochladen bzw. erneuten Verschlüsseln bereitstellen, falls eine Migration von der alten auf die neue Version nötig ist.
  • MUSS: Zero-Knowledge während der Migration wahren: Die erneute Verschlüsselung erfolgt auf dem Client, der Server kann weder auf den CEK noch auf Klartext zugreifen.

11.7.3 Einstellung und EOL

  • MUSS: Für Versionen, die nicht mehr als sicher gelten, einen klaren End-of-Life-Zeitplan bereitstellen.
  • SOLLTE: Nutzer in Oberfläche und Dokumentation zum erneuten Hochladen auffordern und ausreichende Migrationsfenster einräumen.
  • MUSS: Nach EOL sollten Clients, die auf eingestellte Versionen stoßen, klar darauf hinweisen und dürfen nicht versuchen, zu entschlüsseln.

11.8 Zugehörige Claim-IDs (reserviert)

Dieses Kapitel behandelt „Kanäle, Abläufe, Versionierung und Einstellung bei der Offenlegung von Schwachstellen“. Die zugehörigen Claim-IDs werden in den Anhang: Hauptliste der Claim-IDs aufgenommen, der die einzige maßgebliche Quelle ist.