Sicherheits-Whitepaper

Technischer Einblick, wie RocketShare Ihre Dateien mit Zero-Knowledge-Verschlüsselung schützt

Dieses Dokument bietet einen umfassenden technischen Überblick darüber, wie RocketShare Ihre Daten schützt. Es richtet sich an Sicherheitsexperten, Compliance-Beauftragte und alle, die genau verstehen möchten, wie unsere Verschlüsselung funktioniert.

1. Zusammenfassung

RocketShare ist eine Plattform zum Teilen von Dateien mit Zero-Knowledge-Verschlüsselung. Dateien werden clientseitig mit AES-256-GCM verschlüsselt, bevor sie hochgeladen werden, und der Verschlüsselungsschlüssel wird ausschließlich im URL-Fragment eingebettet – einem Teil der URL, den Browser niemals an Server übertragen. Diese Architektur bedeutet, dass RocketShare-Betreiber unter keinen Umständen auf Benutzerdateien zugreifen, sie lesen oder entschlüsseln können, einschließlich rechtlicher Abhöranfragen.

Wichtige Eigenschaften:

  • Zero-Knowledge-Architektur — der Server besitzt niemals Entschlüsselungsschlüssel
  • Ende-zu-Ende-Verschlüsselung — Dateien werden verschlüsselt, bevor sie das Gerät des Absenders verlassen, und nur auf dem Gerät des Empfängers entschlüsselt
  • Keine serverseitige Schlüsselspeicherung — Schlüssel existieren nur im URL-Fragment des Share-Links
  • Automatischer Ablauf und Löschung — Dateien werden nach Ablauf dauerhaft gelöscht

2. Bedrohungsmodell

Wogegen wir schützen

  • Server-Kompromittierung — selbst wenn ein Angreifer vollständigen Zugriff auf unsere Server erhält, bleiben gespeicherte Dateien verschlüsselt und ohne den transferspezifischen Schlüssel unlesbar
  • Netzwerkabfangung — TLS 1.3 schützt Daten während der Übertragung; Verschlüsselungsschlüssel in URL-Fragmenten werden niemals über das Netzwerk gesendet
  • Insider-Bedrohungen — RocketShare-Betreiber haben konstruktionsbedingt, nicht durch Richtlinien, keinen Zugriff auf Dateiinhalte
  • Rechtliche Abhöranfragen — wir können Entschlüsselungsanfragen nicht nachkommen, da wir die Schlüssel nicht besitzen; wir können nur verschlüsselte Blobs und Metadaten bereitstellen

Was außerhalb unseres Bedrohungsmodells liegt

  • Kompromittierte Sender- oder Empfängergeräte — wenn Malware Zugriff auf den Browser des Benutzers hat, könnte sie Schlüssel oder unverschlüsselte Dateien abfangen
  • Abfangen von Share-Links — jeder, der den vollständigen Share-Link (einschließlich des URL-Fragments) erhält, kann die Dateien entschlüsseln; Benutzer müssen Links sicher teilen
  • Browser-Schwachstellen — wir verlassen uns auf die vom Browser bereitgestellte Web Crypto API; Browser-Exploits liegen außerhalb unserer Kontrolle

3. Verschlüsselungsimplementierung

Algorithmus

Alle Dateiverschlüsselungen verwenden AES-256-GCM (Galois/Counter Mode), einen symmetrischen authentifizierten Verschlüsselungsalgorithmus. GCM bietet sowohl Vertraulichkeit als auch Integrität, was bedeutet, dass jede Manipulation des Chiffretexts während der Entschlüsselung erkannt wird.

Schlüsselgenerierung

Verschlüsselungsschlüssel werden clientseitig mit der Web Crypto API des Browsers (crypto.subtle.generateKey) generiert, die auf dem kryptografisch sicheren Pseudozufallszahlengenerator (CSPRNG) des Betriebssystems basiert.

  • Schlüsselgröße: 256 Bit
  • Quelle: Web Crypto API (crypto.subtle.generateKey), basierend auf OS-CSPRNG
  • Geltungsbereich: ein eindeutiger Schlüssel pro Transfer (Datei oder Bündel)

Verschlüsselungsprozess

  1. Der Benutzer wählt Dateien zum Hochladen aus
  2. Ein 256-Bit-AES-Schlüssel wird mit crypto.subtle.generateKey() generiert
  3. Ein eindeutiger 96-Bit-Initialisierungsvektor (IV) wird pro Verschlüsselungsoperation generiert
  4. Dateien werden im Browser mit AES-256-GCM über die Web Crypto API verschlüsselt
  5. Der verschlüsselte Chiffretext wird auf den Server hochgeladen
  6. Das Rohmaterial des Schlüssels wird Base64url-kodiert und im URL-Fragment platziert (#<base64url-key>)

Streaming-Verschlüsselung

Für große Dateien verwendet RocketShare einen Streaming-Verschlüsselungsansatz. Dateien werden in Chunks verarbeitet, um den Speicherverbrauch zu minimieren, wodurch die Verschlüsselung und der Upload von Dateien ermöglicht werden, die den verfügbaren RAM übersteigen.

Jeder Chunk wird mit seinem eigenen zufällig generierten 96-Bit-IV (crypto.getRandomValues) verschlüsselt, wodurch eindeutiger Chiffretext für jeden Chunk gewährleistet wird, selbst wenn sich Dateiinhalte wiederholen.

4. Schlüsselverwaltung

URL-Fragment-Ansatz

Der Entschlüsselungsschlüssel ist im URL-Fragment (dem Teil nach #) eingebettet. Dies ist die kritische Sicherheitseigenschaft des Systems:

  • Browser übertragen niemals URL-Fragmente an Server in HTTP-Anfragen (RFC 3986, Abschnitt 3.5)
  • Das Fragment bleibt vollständig clientseitig — in der Adressleiste des Browsers, im Verlauf und wenn es vom Benutzer geteilt wird
  • Der Server empfängt nur den Pfad und die Query-Parameter, niemals den #...-Schlüsselteil

Schlüssel-Lebenszyklus

  1. Generierung — wird im Browser des Absenders mit CSPRNG erstellt
  2. Verwendung — wird sofort für clientseitige Verschlüsselung verwendet
  3. Einbettung — wird im URL-Fragment des Share-Links platziert
  4. Übertragung — der Benutzer teilt den Link über seinen bevorzugten sicheren Kanal (E-Mail, Messenger usw.)
  5. Entschlüsselung — der Browser des Empfängers liest das Fragment und entschlüsselt die Datei
  6. Keine Speicherung — Schlüssel werden niemals auf dem Server gespeichert; sie existieren nur im Share-Link

Was der Server speichert

Der Server speichert nur:

  • Verschlüsselte Datei-Blobs (Chiffretext)
  • Transfer-Metadaten: Dateiname, Dateigröße, MIME-Typ, Ablaufdatum
  • Transfer-Einstellungen: Download-Limit, Passwortschutz-Hash (falls aktiviert)
  • Account-Daten: E-Mail, Auth-Tokens (nicht mit Dateiverschlüsselung verbunden)

Der Server speichert niemals: Verschlüsselungsschlüssel, unverschlüsselte Dateiinhalte oder Daten, die zur Ableitung des Schlüssels verwendet werden könnten.

5. Datei-Lebenszyklus

Upload

  1. Benutzer wählt Dateien aus → Verschlüsselungsschlüssel wird clientseitig generiert
  2. Dateien werden mit AES-256-GCM im Browser verschlüsselt
  3. Verschlüsselte Blobs werden über TLS 1.3 auf den Server hochgeladen
  4. Server speichert Chiffretext + Metadaten, gibt Transfer-ID zurück
  5. Share-Link wird konstruiert: https://rocketshare.app/d/{id}#{base64url-key}

Speicherung

  • Verschlüsselte Dateien werden auf S3-kompatiblem Objektspeicher in der EU (Amsterdam) gespeichert
  • Dateien werden als undurchsichtige verschlüsselte Blobs gespeichert — der Speicheranbieter kann sie nicht lesen
  • Metadaten werden in PostgreSQL mit Verschlüsselung im Ruhezustand auf dem Datenbank-Volume gespeichert

Download

  1. Empfänger öffnet den Share-Link
  2. Browser extrahiert den Schlüssel aus dem URL-Fragment (wird niemals an den Server gesendet)
  3. Verschlüsselter Blob wird vom Server heruntergeladen
  4. Entschlüsselung erfolgt vollständig im Browser des Empfängers
  5. Unverschlüsselte Datei wird dem Benutzer zum Download präsentiert

Ablauf und Löschung

  • Transfers haben einen konfigurierbaren Ablauf (3 bis 90 Tage je nach Plan)
  • Nach Ablauf löscht eine geplante Bereinigungsaufgabe dauerhaft die verschlüsselten Blobs aus dem Objektspeicher und die Dateidatensätze aus der Datenbank
  • Der Transfer-Metadatensatz (Dateinamen, Größen, Zeitstempel) wird in abgelaufenem Zustand für Abrechnungs- und Audit-Zwecke aufbewahrt, aber alle verschlüsselten Dateidaten werden unwiderruflich entfernt
  • Es werden keine Backups von abgelaufenen Dateidaten aufbewahrt

6. Infrastruktur

Hosting

  • Anwendung: auf Cloudflare Workers (Edge Compute) bereitgestellt
  • Datenbank: PostgreSQL, gehostet in der EU
  • Objektspeicher: S3-kompatibel, EU-Region (Amsterdam)
  • Cache: Cloudflare KV (Key-Value-Store), nur für Sitzungs- und Rate-Limiting-Daten — niemals für Dateiinhalte verwendet
  • CDN: globales Cloudflare-Netzwerk für statische Assets und Edge-Routing

Datensouveränität

Alle Dateispeicher- und Datenbankserver befinden sich innerhalb der Europäischen Union. Wir replizieren Dateidaten nicht außerhalb der EU.

Netzwerksicherheit

  • TLS 1.3 auf allen Verbindungen erzwungen (HTTP und Datenbank)
  • HSTS mit Preloading — Browser werden angewiesen, immer HTTPS zu verwenden
  • HTTP-Sicherheits-Header — CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
  • Kein gemischter Inhalt — alle Ressourcen werden über HTTPS geladen

7. Authentifizierung und Zugriffskontrolle

Benutzerauthentifizierung

  • E-Mail/Passwort — Passwörter werden mit scrypt gehasht (N=16384, r=16, p=1), Mindestlänge von 8 Zeichen erzwungen
  • OAuth — Google und Microsoft SSO über branchenübliches OAuth 2.0 / OpenID Connect
  • Sitzungsverwaltung — sichere HTTP-only-Cookies mit korrekten SameSite-Attributen

Transfer-Zugriffskontrolle

  • Link-basierter Zugriff — jeder mit dem vollständigen Share-Link kann entschlüsseln (der Schlüssel ist in der URL)
  • Optionaler Passwortschutz — Transfers können ein zusätzliches Passwort erfordern; der Passwort-Hash wird serverseitig verifiziert, bevor der verschlüsselte Blob ausgeliefert wird
  • Download-Limits — konfigurierbare maximale Anzahl von Downloads, bevor der Link deaktiviert wird
  • Ablauf — automatischer zeitbasierter Ablauf, nach dem verschlüsselte Dateidaten dauerhaft gelöscht werden

8. Datenminimierung und Aufbewahrung

Prinzip der geringsten Datenmenge

Wir erfassen nur, was für den Betrieb des Dienstes notwendig ist:

  • Account-Daten: E-Mail-Adresse, Name (falls über OAuth bereitgestellt), gehashtes Passwort
  • Transfer-Metadaten: Dateinamen, Größen, MIME-Typen, Zeitstempel, Ablaufdaten
  • Nutzungsdaten: Transferanzahl und genutzter Speicher (für Plan-Durchsetzung)
  • Analytik: anonymisierte Nutzungsmuster über PostHog (EU-gehostet, datenschutzfokussierte Konfiguration)

Was wir nicht erfassen

  • Dateiinhalte (wir können nicht auf verschlüsselte Blobs zugreifen)
  • Verschlüsselungsschlüssel
  • IP-Adressen in Langzeitspeicherung (Zugriffsprotokolle sind kurzlebig)
  • Browserverlauf oder Cross-Site-Tracking-Daten

Aufbewahrung

  • Transfers: verschlüsselte Dateidaten werden automatisch beim Ablauf gelöscht; Transfer-Metadaten werden in abgelaufenem Zustand aufbewahrt
  • Account-Daten: werden aufbewahrt, solange das Konto aktiv ist; werden bei Anfrage zur Kontolöschung gelöscht
  • Zugriffsprotokolle: kurzlebig, nicht über den Request-Lebenszyklus hinaus persistiert

9. Incident Response

Im Falle eines Sicherheitsvorfalls:

  1. Eindämmung — betroffene Systeme sofort isolieren
  2. Bewertung — Umfang und Auswirkungen bestimmen; dank Zero-Knowledge-Architektur legt ein Server-Breach keine Dateiinhalte offen
  3. Benachrichtigung — betroffene Benutzer werden innerhalb von 72 Stunden wie von der DSGVO gefordert benachrichtigt
  4. Behebung — Grundursache beheben, Abwehrmaßnahmen verbessern
  5. Offenlegung — öffentliche Offenlegung des Vorfalls und unserer Reaktion

Sicherheitsprobleme können uns über unsere Responsible Disclosure-Richtlinie gemeldet werden.

10. Einschränkungen und Transparenz

Wir glauben an Transparenz darüber, was unsere Sicherheitsarchitektur schützt und was nicht:

  • Wir können verlorene Links nicht wiederherstellen — wenn ein Benutzer den Share-Link (einschließlich des URL-Fragments) verliert, können die verschlüsselten Dateien nicht entschlüsselt werden. Wir haben den Schlüssel nicht.
  • Link-Sicherheit liegt in der Verantwortung des Benutzers — der Share-Link ist das einzige Zugriffstoken. Wenn er abgefangen wird (z. B. über einen unsicheren Kanal gesendet), kann der Abfangende die Dateien entschlüsseln.
  • CSP mit nonce-basierter Script-Policy — wir verwenden Content Security Policy mit strict-dynamic und nonce-basierten Script-Quellen, was der empfohlene Ansatz für SSR-Anwendungen ist. Inline-Styles erfordern weiterhin unsafe-inline aufgrund von Tailwind CSS.
  • Browser-Vertrauen — unsere Verschlüsselung basiert auf der Web Crypto API. Wenn der Browser kompromittiert ist, sind alle Wetten ungültig.
  • Metadaten-Sichtbarkeit — während Dateiinhalte verschlüsselt sind, sind Dateinamen, Größen und Zeitstempel für betriebliche Zwecke für den Server sichtbar.

Dieses Whitepaper ist aktuell ab Februar 2026. Wir aktualisieren dieses Dokument, wenn sich unsere Sicherheitsarchitektur ändert. Bei Fragen kontaktieren Sie uns.