Was ein Cloud-Anbieter, der Sync-Client und der Inhaltshash noch sehen, wenn Sie eine unverschlüsselte Datei hochladen

In den Cloud-Ordner ziehen ist keine Tresortür – Sie übergeben Klartext

Viele behandeln den privaten Cloud-Speicher wie den Tresor zu Hause: Die Datei liegt noch „in meinem Konto“, also kann sie niemand anderes öffnen. Nach dem Ablegen haben diese Bytes den Ordner auf dieser Platte verlassen. Sie werden ein Objekt, das der Anbieter speichert, synchronisiert, dedupliziert und oft für die Vorschau indexiert. Steuererklärungen, Ausweisscans, SSH-Privatschlüssel, Datenbankdumps und ungeschwärzte Kundentabellen gehören nicht im Klartext in ein fremdes Speicher- und Suchsystem.

HTTPS schützt nur vor Mithören auf dem Weg. Es entscheidet nicht, in welcher Form das andere System die Datei ablegt, wer die Schlüssel hält, was der Sync-Client auf diesem Rechner cached oder ob ein Freigabelink Chiffretext oder wiedergewonnenen Klartext liefert. Die vorige Notiz hat eine verwandte Übergabe beschrieben: Ein Schlüssel im Modell-Chat landet in Verlauf und Aufbewahrung. Eine unverschlüsselte Datei im Cloud-Ordner ist dieselbe Klasse von Exposition. Empfängerin oder Empfänger ist nicht mehr der Modell-Anbieter, sondern der Speicheranbieter samt Sync-, Vorschau- und Deduplizierungspfaden. Vor dem Upload ist die Frage nicht „ist dieser Cloud-Dienst schlau“, sondern „steht in dieser Kopie etwas, das dieses Gerät nicht im Klartext verlassen darf“.

Diese Notiz bleibt bei AWS S3, Google Drive / Google Cloud und iCloud, weil diese Anbieter die Schichten in prüfbarer Sprache beschreiben. Ein Verbraucherlaufwerk schreibt selten ebenso deutlich, wer die Schlüssel hält. Das technische Modell ist trotzdem meist dasselbe: TLS auf dem Weg, Verschlüsselung im Ruhezustand mit Schlüsseln beim Anbieter, darüber Miniaturansichten, Volltextsuche oder Deduplizierung. Wechseln Sie das Produkt, gehen Sie die Sicherheitsseite jener Firma erneut durch. Übertragen Sie SSE-S3 oder „standardmäßiger Datenschutz“ nicht auf eine andere Marke.

HTTPS, Ruhezustand und Zero-Knowledge sind drei verschiedene Schlösser

Wer „ist der Cloud-Speicher verschlüsselt“ als Ja-oder-Nein hört, lässt mindestens drei Schichten weg. Die erste ist die Transportverschlüsselung. Browser oder Sync-Client schicken Bytes über TLS. Der Weg dazwischen sieht keinen Klartext. Diese Schicht ist fast überall an und ist das Einzige, was das Schloss in der Adresszeile wirklich verspricht.

Die zweite ist die Verschlüsselung im Ruhezustand – serverseitige Verschlüsselung. AWS definiert S3-Server-Side Encryption klar: Die Daten werden am Ziel vom empfangenden Dienst verschlüsselt; S3 verschlüsselt beim Schreiben auf Festplatten in AWS-Rechenzentren und entschlüsselt, wenn Sie auf das Objekt zugreifen. Seit dem 5. Januar 2023 nutzen alle neuen Uploads standardmäßig SSE-S3 (von Amazon S3 verwaltete Schlüssel). Der Algorithmus ist AES-256, jedes Objekt bekommt einen eigenen Schlüssel, AWS rotiert den Wurzelschlüssel. Solange die Anfrage authentifiziert und berechtigt ist, „unterscheidet sich der Zugriff auf verschlüsselte und unverschlüsselte Objekte nicht“. Eine vorab signierte URL gilt für beide gleich. Auch die Objektliste trennt nicht nach Verschlüsselung. Mit anderen Worten: Diese Schicht schützt eine gestohlene Festplatte. Sie bedeutet nicht „AWS kann Ihre Datei nicht öffnen“.

Googles öffentliche Formulierung für Drive ist ähnlich: Dateien, die Sie hochladen oder in Docs, Sheets und Slides anlegen, sind „während der Übertragung und im Ruhezustand mit AES-256 verschlüsselt“. Zusätzliche Vertraulichkeit verlangt die clientseitige Verschlüsselung von Workspace – und dafür ein Arbeits- oder Schulkonto, das eine Administration eingeschaltet hat. Erst nach diesem Schalter schreibt Google „Google kann Ihre Dateien nicht entschlüsseln“. Die Standardschicht tut das nicht. Die Standard-Verschlüsselung im Ruhezustand von Google Cloud ist direkter: Google besitzt und verwaltet die Schlüssel der Standardverschlüsselung. Bleiben Sie dabei, halten Sie diese Schlüssel nicht und steuern Sie die Rotation nicht.

Apple trennt Standard und Option. Der Überblick zur iCloud-Datensicherheit schreibt: Der standardmäßige Datenschutz ist die Konto-Voreinstellung; Daten werden verschlüsselt, die Schlüssel liegen in Apple-Rechenzentren, damit Apple bei der Wiederherstellung helfen kann. Nur ein Teil der Kategorien ist standardmäßig Ende-zu-Ende verschlüsselt. Die Sicherheitsübersicht nennt Zahlen: 15 Kategorien sind immer Ende-zu-Ende, darunter Gesundheit und iCloud-Schlüsselbund. Der optionale erweiterte Datenschutz hebt das auf 25 und nimmt iCloud-Backup, Fotos, Notizen und iCloud Drive hinzu. Schalten Sie den erweiterten Datenschutz aus, lädt das Gerät die nötigen Schlüssel wieder auf Apple-Server. Der Standard heißt nicht „Apple kann Dateien in iCloud Drive ebenfalls nicht öffnen“.

Was der Anbieter noch tun kann, wenn er die Schlüssel hält

Dass der Anbieter entschlüsseln kann, ist keine Drohung, sondern die Voraussetzung dafür, dass die Standardfunktionen überhaupt funktionieren. Online-PDF-Vorschau, Miniaturansichten von Fotos, OCR, Volltextsuche und „nach Typ sortieren“ brauchen irgendwo einen Server, der den Inhalt sieht – oder mindestens einen Klartext-Index, der daraus abgeleitet wurde. Google schreibt die Kosten der clientseitigen Verschlüsselung in dieselbe Hilfeseite: Verschlüsselte Docs, Sheets und Slides lassen sich in den Mobil-Apps nicht bearbeiten, nehmen keine Drive-Kommentare an, haben keine Spracheingabe und verlieren mehrere Add-ons; verschlüsselte Editor-Dateien enden bei 100 MB; die Versionshistorie behält höchstens 100 Versionen. Diese Grenzen haben einen konkreten Grund: Der Server hält keinen Schlüssel mehr, der Klartext öffnet.

AWS beschreibt die andere Seite ebenso klar. Teilen Sie ein Objekt per vorab signierter URL, sieht der Zugriff der Gegenseite aus wie bei einem unverschlüsselten Objekt. SSE-S3 macht aus „wer den Link geöffnet hat“ kein „nur Chiffretext“. Es stoppt „wer eine Festplatte mitgenommen hat“. Ein gestohlenes Konto, ein geleakter Freigabelink, ein Abruf durch die Unternehmensadministration und eine rechtmäßige Anfrage laufen alle über „berechtigten Zugriff“. Die Standard-Verschlüsselung im Ruhezustand lässt diesen Weg durch.

Verbraucherlaufwerke legen noch eine Schicht darüber: den Sync-Client. Die Datei erscheint zuerst im lokalen Sync-Ordner und wird dann hochgeladen. Selbst wenn die Cloud später im Ruhezustand verschlüsselt, können dieser Rechner, ein zweiter angemeldeter Rechner zu Hause und Offline-Caches auf dem Telefon je eine Klartextkopie behalten. Ein geschlossener Browser-Tab löscht keine Datei, die bereits im Sync-Ordner liegt.

Sync-Cache, Vorschau, Inhaltshash und Freigabelink sind extra Kopien

Wer „Upload abgeschlossen“ als „nur eine Kopie, in der Cloud“ hört, übersieht Kopien auf beiden Seiten. Die erste ist die Arbeitskopie des Sync-Clients: Upload-Warteschlange, Wiederholungs-Cache und Reste eines Versionskonflikts. Die zweite ist eine abgeleitete Datei, die der Server für die Vorschau baut: Miniaturansicht, umcodiertes Video, OCR-Text. Die liegen oft getrennt vom Original. Das Löschen des Originals nimmt die Ableitung nicht immer im selben Moment mit.

Die dritte Kopie ist ein Inhaltshash. Viele Cloud-Dienste hashen die ganze Datei oder jeden Block und nutzen den Digest für Deduplizierung und einen sofortigen Upload: Der Client schickt zuerst den Hash; hat der Server ihn schon, reisen die Bytes nicht noch einmal. Für eine unverschlüsselte Datei ist das bequem. Es räumt zugleich ein, dass „derselbe Klartext im System nur einmal liegt“. Laden Sie ein unverschlüsseltes Installationspaket oder ein öffentliches PDF hoch, kann der Server allein am Hash bestätigen, dass Sie es besitzen. Laden mehrere Schreibtische denselben internen Vertrag hoch, speichert die Deduplizierung weiter ein Klartextobjekt. Verschlüsseln Sie zuerst auf diesem Gerät, nutzt jeder Lauf ein frisches Salt und einen frischen IV; der Chiffretext hasht anders, die Deduplizierung trifft nicht. Das ist kein Fehler. Es ist die direkte Folge von „der Anbieter sieht den Inhalt nicht“.

Apple beschreibt eine Variante davon sogar unter erweitertem Datenschutz. Derselbe iCloud-Überblick hält fest, dass ein Teil der Metadaten unter standardmäßigem Datenschutz bleibt: Prüfsummen von Datei- und Fotodaten helfen Apple, Speicher zu deduplizieren und zu optimieren. Für iCloud Drive gehören dazu „die Roh-Byte-Prüfsummen des Dateiinhalts und der Dateiname“. Ende-zu-Ende-Verschlüsselung am Dateikörper ist nicht dasselbe wie „Apple sieht niemals einen Fingerabdruck der Bytes“. Behandeln Sie jeden Hinweis „bereits in der Cloud“ oder „sofortiger Upload“ gleich: Ein Hash-Treffer ist eine Aussage über den Inhalt, nicht nur über Ihr Konto.

Die vierte Kopie ist ein Freigabelink oder ein Teambereich. Ist der Link draußen, gilt meist „wer den Link hält, holt die Datei“. Zusammen mit dem vorigen Abschnitt: Die Standard-Verschlüsselung im Ruhezustand schreibt einen Download nicht auf „nur Chiffretext“ um. Was im anderen Browser aufgeht, ist wiedergewonnener Klartext. Ein „Cloud-Link“ im Gruppenchat und das Anhängen der Datei selbst haben unterschiedliche Oberflächen. Ob Klartext Ihr Konto verlassen hat, ist oft dieselbe Antwort.

Warum ein ZIP mit Passwort oft keine clientseitige Verschlüsselung ist

„Erst zippen, Passwort drauf, dann hochladen“ klingt nach clientseitiger Verschlüsselung. Fragen Sie zuerst, welches ZIP-Verfahren Sie wirklich genutzt haben. Klassische PKWARE-Verschlüsselung (ZipCrypto) ist eine Stromchiffre. 1994 schrieben Eli Biham und Paul Kocher in A Known Plaintext Attack on the PKZIP Stream Cipher, das Verfahren sei schwach und solle keine wertvollen Daten schützen: Etwa 13 bis 40 Byte komprimierten bekannten Klartexts – oder grob 30 bis 200 Byte am Anfang einer unkomprimierten Datei – stellten die interne Schlüsselrepräsentation auf einem damaligen PC in Stunden wieder her. Moderner Code senkt die Schwelle. bkcrack dokumentiert die Wiederherstellung ab mindestens 12 Byte bekanntem Klartext (davon mindestens 8 aufeinanderfolgend). Das stellt den internen Zustand wieder her und öffnet den Rest des Archivs – und andere Einträge mit demselben Passwort. Die Passwortlänge hilft bei diesem Angriff nicht. Ziel ist der Schlüsselstromzustand, nicht das Erraten Ihrer Passphrase.

Auch wenn das Packprogramm auf AES wechselt, kann ein ZIP Dateinamen, Verzeichnisstruktur und unverschlüsselte Eintragskommentare im Archivkopf lassen. Dateilisten, Suche und „Typ“-Filter im Cloud-Speicher lesen genau diese Metadaten. Wer „das Archiv hat ein Passwort“ als „die Cloud sieht nur Rauschen“ liest, übersieht Kopf und schwaches Verfahren.

Ein häufiger Betriebsfehler: Das verschlüsselte Archiv und eine readme.txt mit dem Passwort liegen im selben Ordner und werden gemeinsam synchronisiert. Schloss und Schlüssel gehen an dieselbe verwahrende Stelle. Weder Ruhezustands-Verschlüsselung noch das ZIP-Passwort retten diesen Fall.

Was sich ändert, wenn Sie zuerst auf dem Gerät verschlüsseln

Clientseitige Verschlüsselung hat einen engen Test: Klartext wird Chiffretext, bevor er das Gerät verlässt; die Passphrase, aus der der Schlüssel entsteht, geht nicht an den Speicheranbieter; der Anbieter kann die Datei im Normalbetrieb nicht öffnen. Google beschreibt die clientseitige Verschlüsselung von Workspace als „Ende-zu-Ende und zwischen Clients“ und schreibt „Google kann Ihre Dateien nicht entschlüsseln“. Das ist eine Extra-Schicht, die eine Administration einschaltet. Es ist nicht der Standard eines persönlichen, kostenlosen Drive. Selbst verschlüsseln und dann hochladen geht dieselbe Grenze. Die Schlüssel bleiben in Ihrer Passphrase und auf Ihrem Gerät. Sie hängen nicht davon ab, ob ein bestimmter Cloud-Dienst einen Schalter für clientseitige Verschlüsselung mitliefert.

Ein prüfbarer Weg im Browser ist Web-Crypto-AES-GCM, kein selbst gebautes XOR. Die Hinweise von MDN zu AesGcmParams passen zu NIST SP 800-38D: Unter einem Schlüssel muss der IV jedes Mal eindeutig sein; die Spezifikation empfiehlt einen 96-Bit-IV (12 Byte); der IV muss nicht geheim sein und darf im Klartext neben dem Chiffretext liegen. NIST betont die Eindeutigkeit stark: Die Wiederverwendung eines IV unter demselben Schlüssel kann Fälschungen erlauben, und diese Anforderung ist fast so wichtig wie das Geheimhalten des Schlüssels. Das Authentifizierungs-Tag ist standardmäßig 128 Bit (16 Byte). Eine falsche Passphrase oder ein veränderter Chiffretext soll geschlossen scheitern, nicht verstümmelten Klartext ausgeben.

MakePwd setzt diese Grenze unter Datei verschlüsseln um: AES-256-GCM in Blöcken im aktuellen Tab, eine Passphrase gestreckt mit PBKDF2-HMAC-SHA256 und 100.000 Iterationen, pro Datei ein frisches 16-Byte-Salt, pro Block ein frischer 12-Byte-IV, Ausgabe als IV + Chiffretext + 16-Byte-Tag. Eine Datei darf höchstens 5 GB groß sein. Der Standardblock ist 1 MB, damit die ganze Datei nicht auf einmal im Speicher liegt. Die Ausgabe ist .lock oder .enc, dasselbe Binärformat. Datei und Passphrase werden nicht hochgeladen. Alle Werkzeuge öffnen ohne Konto, und es gibt keinen Passworttresor, der die Passphrase für Sie verwahrt. Die Seite beantwortet „kann das Chiffretext werden, bevor es den Browser verlässt“. Sie lädt die Datei nicht in Ihren Namen zu einem Cloud-Dienst.

Sofort prüfen: Der Canary darf nicht in die Upload-Warteschlange

Ein Slogan „nichts wird hochgeladen“ beweist sich nicht selbst. Teilen Sie die Prüfung in zwei Hälften. Zuerst: Hat der Verschlüsselungsschritt Klartext als Geschäftsdaten geschickt? Dann: Ist das Objekt, das Sie dem Cloud-Speicher geben, wirklich Chiffretext?

1. Legen Sie eine Textdatei mit einem Satz an, der in echter Arbeit nicht vorkommt, etwa canary-cloud-20260902-only-once. Der Dateiname darf den Canary ebenfalls tragen. Nutzen Sie eine einmalige lange Passphrase, kein wiederverwendetes Passwort.
2. Öffnen Sie die Seite zum Datei-Verschlüsseln im Browser. Öffnen Sie die Entwicklertools, wechseln Sie zu Network und aktivieren Sie Preserve log. Datei wählen, Passphrase eingeben, .lock herunterladen. Den Canary in den Filter einfügen: Er darf weder in der Anfragezeile noch im Body noch in Analytics erscheinen. Die Passphrase ebenfalls nicht.
3. Öffnen Sie die heruntergeladene .lock in einem Hex-Viewer oder Editor. Der Kopf soll eine feste Magie zeigen, nicht den Canary-Satz. Eine falsche Passphrase soll scheitern und darf keine verstümmelte Klartextdatei schreiben.
4. Wollen Sie trotzdem eine Kopie in Ihrem eigenen Cloud-Speicher, laden Sie die .lock hoch, nicht das Original. Nach dem Upload die Cloud-Vorschau durchsuchen: Lesbarer Fließtext darf nicht erscheinen. Legen Sie die Passphrase nicht in denselben Sync-Ordner.

Die erste Hälfte – Anfragezeile, Body, Analytics – ist dieselbe Prüfung wie in Im Browser verschlüsseln: so prüfen Sie, dass Klartext das Gerät nicht verlassen hat. Diese Notiz ergänzt den vierten Schritt: Sobald das Objekt den Browser verlässt, wechselt die Schicht von „lokale Web Crypto“ zu „behandelt der Cloud-Speicher das als Klartext“. Der Canary darf nur in dem Original vorkommen, das Sie behalten haben. Erscheint er in der Cloud-Vorschau oder in einem Hinweis auf Deduplizierung, haben Sie weiter eine unverschlüsselte Kopie hochgeladen.

Die Grenze an einer Dateiverschlüsselung üben, die ohne Konto öffnet

Wollen Sie „zuerst Chiffretext, dann selbst entscheiden, wohin“, müssen Sie sich nicht registrieren und die Datei nicht an MakePwd übergeben. Öffnen Sie Datei verschlüsseln, wählen Sie eine wegwerfbare kleine Datei, verschlüsseln Sie sie mit einer langen zufälligen Passphrase, laden Sie die .lock herunter und durchsuchen Sie Network wie oben. Muss eine Person die Passphrase merken oder erhalten, ziehen Sie mit dem Passwortgenerator eine zufällige Zeichenkette von 6–128 Zeichen (Standard 16; unter 8 gilt als schwächer) und schicken Sie sie einmal per Einmal-Link, statt sie in denselben Cloud-Ordner zu legen wie den Chiffretext. Der Schlüssel des Einmal-Links liegt im URL-#-Fragment. Die Leseseite ist für Empfängerinnen und Empfänger öffentlich.

Datei verschlüsseln ersetzt nicht den Schalter für clientseitige Verschlüsselung eines Cloud-Dienstes und verspricht nicht, wie das andere Produkt Chiffretext auf Schadsoftware prüft oder Dateinamen liest. Der .lock-Kopf trägt den ursprünglichen Dateinamen, der Cloud-Speicher kann den Namen also weiter sehen. Muss der Name selbst unsichtbar bleiben, benennen Sie die Datei vor dem Verschlüsseln bedeutungslos um. Eine vergessene Passphrase lässt sich aus dem Chiffretext nicht zurückholen. Bewahren Sie sie an einem Ort auf, den Sie kontrollieren.

Häufige Fragen

Der Cloud-Speicher schreibt „verschlüsselt“ – kann der Anbieter meine Dateien trotzdem öffnen?

Unter der Standard-Verschlüsselung im Ruhezustand in der Regel ja. AWS schreibt: Serverseitige Verschlüsselung verschlüsselt beim Schreiben auf die Festplatte und entschlüsselt beim Zugriff; eine berechtigte Anfrage behandelt verschlüsselte und unverschlüsselte Objekte gleich. Google verwahrt die Schlüssel der Standardverschlüsselung selbst. Apples standardmäßiger Datenschutz legt die meisten Schlüssel in eigenen Rechenzentren ab, damit Apple bei der Wiederherstellung helfen kann. Das ist eine andere Schicht als „der Anbieter kann nicht entschlüsseln“.

Reicht ein ZIP mit Passwort vor dem Upload?

Klassisches ZipCrypto reicht nicht. Biham und Kocher zeigten 1994: Schon etwa ein Dutzend Byte bekannten Klartexts stellen den internen Schlüsselzustand wieder her; die Passwortlänge hilft dabei nicht. Auch ein AES-Archiv kann Dateinamen und Verzeichnisstruktur im Klartext lassen. Soll der Cloud-Speicher nur Chiffretext sehen, muss die authentifizierte Verschlüsselung auf diesem Gerät fertig sein.

Funktionieren Deduplizierung und Online-Vorschau noch, wenn ich zuerst verschlüssele?

Gegen die Originalbytes in der Regel nicht. Die Deduplizierung vergleicht einen Inhaltshash; derselbe Klartext mit neuem Salt und IV hasht anders. Vorschau, Miniaturansicht und OCR brauchen Klartext. Das ist der erwartete Preis: Sieht der Anbieter den Inhalt nicht, kann er auch keine Vorschau bauen.

Darf die Passphrase im selben Cloud-Ordner liegen wie die .lock-Datei?

Nein. Chiffretext und Passphrase im selben Konto und demselben Sync-Ordner geben Schloss und Schlüssel an dieselbe verwahrende Stelle. Legen Sie die Passphrase in einen Passwortmanager oder schicken Sie sie einmal per Einmal-Link. Eine vergessene Passphrase lässt sich aus der .lock-Datei nicht zurückholen. Das ist die Grenze einer Zero-Knowledge-Sicherung, kein Fehler.

Drei Dinge vor dem nächsten Upload

Erstens: Das Schloss in der Adresszeile und das Wort „verschlüsselt“ decken den Weg und eine gestohlene Festplatte. Sie decken nicht den Anbieter, eine Administration oder wer einen Freigabelink hält. Zweitens: Sync-Cache, Vorschaubleitungen, Inhaltshashes und Freigabelinks können je eine Kopie behalten; ein unverschlüsselter Upload setzt Klartext auf diese Pfade. Drittens: Soll der Cloud-Speicher nur undurchsichtige Bytes sehen, verschlüsseln Sie auf diesem Gerät mit AES-256-GCM zu .lock / .enc, schicken Sie die Passphrase über einen anderen Kanal und suchen Sie danach in Network und in der Cloud-Vorschau nach dem Canary.

Ist die nächste Frage, ob der Verschlüsselungsschritt Klartext als Geschäftsdaten geschickt hat, lesen Sie Im Browser verschlüsseln: so prüfen Sie, dass Klartext das Gerät nicht verlassen hat. Muss eine Person die Passphrase erhalten, die den Chiffretext öffnet, lesen Sie Warum ein URL-Fragment hinter der Raute ein passender Ort für einen Schlüssel ist – und wann dieser Schutz wegfällt und Was bleibt auf dem Server, nachdem ein Einmal-Link einmal gelesen wurde. Diese Notiz zieht nur eine Linie, die Sie in eine Schlussfolgerung schreiben können: was nach dem Hochladen einer unverschlüsselten Datei in einen Verbraucherspeicher noch bleiben kann.