Was ist Zero-Knowledge-Verschlüsselung? Ein einfacher Leitfaden
Zero-Knowledge-Verschlüsselung bedeutet, dass der Anbieter nicht auf deine Daten zugreifen kann.
Zero-Knowledge-Verschlüsselung ist eine anbieterblinde Architektur, bei der der Dienst nicht über den Schlüssel verfügt, der zum Entschlüsseln gespeicherter Benutzerinhalte erforderlich ist. Im Gegensatz zur Standard-Cloud-Verschlüsselung, bei der der Anbieter den Inhaltsschlüssel kontrolliert, kann die clientseitige Verschlüsselung diesen Schlüssel auf den Geräten der Nutzer halten. Eine rechtliche Anfrage, ein Einbruch oder ein Insider kann dennoch dazu führen, dass Chiffretext, Kontodaten, Verkehrsdaten oder andere vom Anbieter gespeicherte Metadaten offengelegt werden. Die Leitlinien von NIST zur Schlüsselverwaltung machen die Schlüsselverwahrung zum Kern der Zugriffsfrage, aber die Client-App, das Betriebssystem und das entsperrte Gerät bleiben Teil der Vertrauensgrenze.
Wie Zero-Knowledge-Verschlüsselung funktioniert
Die einfachste Analogie: ein Hoteltresor, bei dem nur du die Kombination einstellst und das Hotel sie nie erfährt. Wenn du die Kombination vergisst, kann das Hotel den Tresor nicht für dich öffnen. Das ist kein Fehler im Design. Das ist das Design.
In technischen Begriffen funktioniert Zero-Knowledge-Verschlüsselung durch drei Schritte:
Schlüsselableitung auf dem Gerät. Der Benutzer stellt Anmeldeinformationen wie ein Kennwort, eine Passphrase oder ein Muster bereit. Eine passwortbasierte Schlüsselableitungsfunktion kombiniert es mit einem Salt, um einen Schlüssel auf dem Gerät des Benutzers zu erzeugen. Ein gut getrenntes Design kann diesen Schlüssel verwenden, um einen zufälligen Inhaltsverschlüsselungsschlüssel freizuschalten, anstatt jede Datei direkt mit den menschlichen Anmeldeinformationen zu verschlüsseln.
Verschlüsselung vor der Übertragung. Alle Daten werden auf dem Gerät mit dem abgeleiteten Schlüssel verschlüsselt, bevor sie das Gerät für den Cloud-Speicher oder das Backup verlassen. Die verschlüsselte Ausgabe (Chiffretext) wird hochgeladen.
Der Anbieter erhält keinen Klartext-Inhaltsschlüssel. Inhaltsschlüssel sind während der Verwendung notwendigerweise im Speicher des Clients vorhanden und können auch lokal oder remote in authentifizierten verschlüsselten Umschlägen gespeichert werden. Der Anbieter kann Chiffretext und verpackte Schlüssel speichern, ohne das zum Öffnen erforderliche Benutzergeheimnis zu besitzen. Konto-, Datenverkehr-, Datensatzgröße- und Timing-Metadaten bleiben möglicherweise weiterhin sichtbar.
Die entscheidende Einschränkung: Wenn der Benutzer alle gültigen Anmeldeinformationen und Wiederherstellungspfade verliert, ist der verschlüsselte Inhalt nicht mehr zugänglich. Eine Wiederherstellung kann es weiterhin geben, die Schlüsselverwahrung muss jedoch erklärt werden. Wenn ein E-Mail-Reset allein lesbare Inhalte ohne eine Genehmigung des alten Geräts, eine Wiederherstellungsphrase, einen Wiederherstellungsschlüssel oder ein gleichwertiges vom Benutzer gehaltenes Geheimnis wiederherstellt, hat der Anbieter einen effektiven Weg zurück zum Klartext beibehalten.
Zero-Knowledge-Verschlüsselung vs. andere Arten von Verschlüsselung
Der Begriff „Verschlüsselung“ erscheint in Marketingmaterialien für fast jeden Cloud-Dienst. Die Unterschiede zwischen den Typen sind erheblich.
| Typ | Wer hält den Schlüssel | Anbieter kann Daten lesen | Übersteht Anbieter-Verstoß | Beispiel |
|---|---|---|---|---|
| Keine Verschlüsselung | N/A | Ja | Nein | Dropbox (Standard-Stufe) |
| Verschlüsselung während der Übertragung (TLS) | Anbieter | Ja (im Ruhezustand auf ihren Servern) | Nein | Google Fotos |
| Serverseitige Verschlüsselung im Ruhezustand | Anbieter | Ja (sie hält den Entschlüsselungsschlüssel) | Teilweise | iCloud (Standard) |
| Ende-zu-Ende-Verschlüsselung der Plattform | Client-Geräte und Kontowiederherstellungssystem | Nicht über den normalen Dienstpfad | Hängt von Client, Wiederherstellung und Metadaten-Offenlegung ab | iCloud mit erweitertem Datenschutz |
| Anbieterblinde, clientseitige Verschlüsselung | Client- und benutzergesteuerter Wiederherstellungspfad | Kein vom Anbieter gehaltener Klartext-Inhaltsschlüssel | Inhalte können verschlüsselt bleiben; Metadaten und Geheimtext können weiterhin offengelegt werden | Verschlüsselte Tresor- und Backup-Systeme |
Die Unterscheidung zwischen „Verschlüsselung im Ruhezustand“ und „Zero-Knowledge-Verschlüsselung“ ist die am häufigsten verwechselte. Mit Verschlüsselung im Ruhezustand verschlüsselt der Anbieter deine Daten auf seinen Servern mit von ihm kontrollierten Schlüsseln. Dies schützt vor physischem Diebstahl der Server-Hardware. Es schützt nicht vor dem Anbieter, der deine Daten liest, einer Regierungsvorladung nach Daten und Schlüsseln oder einer Insider-Bedrohung.
Bei der anbieterblinden clientseitigen Verschlüsselung erhält der Dienst den Klartext-Inhaltsschlüssel nicht über das dokumentierte Protokoll. Gespeicherter Chiffretext kann für diesen Anbieter undurchsichtig bleiben, während die Client-Software, der Wiederherstellungspfad, die Kontometadaten und der Softwarebereitstellungskanal weiterhin Vertrauen und Überprüfung erfordern.
Warum Zero-Knowledge-Verschlüsselung wichtig ist
Datenpannen betreffen jährlich Milliarden von Datensätzen
Das Identity Theft Resource Center meldete im Jahr 2023 3.205 Datenkompromittierungen in den Vereinigten Staaten, von denen etwa 353 Millionen Menschen betroffen waren. Wenn ein Anbieter über Inhaltsschlüssel verfügt, kann ein Einbruch dazu führen, dass sowohl gespeicherte Daten als auch ein Pfad zu deren Entschlüsselung offengelegt werden. Anbieterblinde Verschlüsselung trennt diese beiden Dinge: Ein Servereinbruch kann weiterhin Chiffretext und Metadaten offenlegen, nicht jedoch einen vom Anbieter gehaltenen Klartext-Inhaltsschlüssel. Das Erraten von Anmeldedaten und die Kompromittierung des Clients bleiben getrennte Risiken.
Rechtlicher Zwang ist eine reale Bedrohung
Anbieter können zur Offenlegung der von ihnen gespeicherten Daten verpflichtet werden. Ein anbieterblindes Design kann diese Reaktion auf Chiffretext und verfügbare Konto-, Verkehrs-, Abrechnungs- oder Dienstmetadaten beschränken, da der Anbieter nicht über den Klartext-Inhaltsschlüssel verfügt. Ob eine andere Partei Benutzeranmeldeinformationen erhalten, einen Client ausnutzen oder die Offenlegung erzwingen kann, ist eine andere Frage. Apple hat den erweiterten Datenschutz für iCloud mit iOS 16.2 als optionale Erweiterung der Ende-zu-Ende-Verschlüsselung für iCloud-Daten eingeführt.
„Vertrau uns“ ist keine Sicherheitsarchitektur
Die serverseitige Verschlüsselung basiert auf vom Anbieter kontrollierten Schlüsseln und Richtlinien. Anbieterblinde Verschlüsselung ändert die Schlüsselverwahrung, sodass dem dokumentierten Dienstpfad ein Klartext-Inhaltsschlüssel fehlt. Das ist eine stärkere architektonische Grenze, aber ihre Stärke hängt immer noch von korrektem Client-Code, authentifizierter Softwarebereitstellung, solider Wiederherstellung, sicheren Geräten und einer Implementierung ab, die der Spezifikation entspricht.
Der NIST-Standard hinter der Kryptographie
AES-GCM wurde vom National Institute of Standards and Technology in SP 800-38D (2007) standardisiert. AES selbst wurde 2001 von NIST in einem öffentlichen Wettbewerb ausgewählt. Die „256“ in AES-256 bezieht sich auf einen 256-Bit-Schlüssel. Eine vollständige Suche über einen gleichverteilt zufälligen Schlüssel ist rechnerisch nicht durchführbar, aber ein menschliches Passwort oder Muster kann weitaus weniger Entropie liefern, selbst wenn eine Schlüsselableitungsfunktion 256 Bit ausgibt.
GCM (Galois/Counter Mode) fügt authentifizierte Verschlüsselung hinzu, was bedeutet, dass der Entschlüsselungsprozess jede Manipulation des Chiffretexts erkennt. Wenn ein einzelnes Bit der verschlüsselten Daten geändert wird, schlägt die Entschlüsselung fehl, anstatt korrumpierte Ausgabe zu produzieren.
PBKDF2 (Passwortbasierte Schlüsselableitungsfunktion 2), angegeben in RFC 8018, wandelt einen von Menschen bereitgestellten Berechtigungsnachweis durch wiederholte pseudozufällige Funktionsaufrufe in Schlüsselmaterial fester Länge um. Weitere Iterationen erhöhen die Kosten jedes Rateversuchs. Sie fügen einem vorhersehbaren Muster oder Passwort keine Entropie hinzu, sodass die Auswahl der Anmeldeinformationen und die Offline-Verifizierung weiterhin wichtig sind.
Wie Vaultaire die Anbieter-Schlüssel-Trennung implementiert
Vaultaire ist ein clientseitig verschlüsselter Tresor für iPhone. Im Sinne des Produkts, das oft als „Zero Knowledge“ vermarktet wird, besteht die engere dokumentierte Behauptung darin, dass Wraxle weder Klartext-Tresorinhalte noch die zum Entschlüsseln erforderlichen Schlüssel erhält. So funktionieren die Implementierung und die verbleibenden Vertrauensgrenzen auf jeder Ebene.
Schlüsselableitung. Der Benutzer zeichnet ein Muster auf einem 5x5-Raster mit 25 Punkten. PBKDF2-HMAC-SHA512 kombiniert diese Sequenz mit einem geräteweiten Keychain-Salt über 600.000 Iterationen, um einen 256-Bit-Tresorschlüssel abzuleiten. Der Tresorschlüssel authentifiziert den verschlüsselten Index und verpackt einen separaten zufälligen 256-Bit-Hauptschlüssel. Wiederherstellungsinformationen, einschließlich des Musters, werden in einer AES-GCM-verschlüsselten Keychain-Datenbank gespeichert, anstelle von Klartextdateien oder einem Vaultaire-Konto.
Dateiverschlüsselung. Jede importierte Datei wird mit AES-256-GCM unter dem zufälligen Hauptschlüssel verschlüsselt. CryptoKit erstellt authentifizierte Sealed Boxes mit neuen Nonces, und das Streaming-Format leitet für jeden geordneten Block eine eindeutige Nonce ab.
Metadatenverschlüsselung. Dateinamen, MIME-Typen, Datumsangaben, Indexdatensätze und Miniaturbilddaten sind ebenfalls mit AES-256-GCM geschützt. Vaultaire verwendet ChaCha20 nicht für Tresormetadaten.
Schlüsselverwaltung. Vaultaire speichert sein Geräte-Salt und die verschlüsselte Wiederherstellungsdatenbank als gewöhnliche generische Passwortelemente im iOS-Keychain mit der Zugriffsklasse WhenUnlockedThisDeviceOnly. Von Mustern abgeleitete Tresorschlüssel und zufällige Hauptschlüssel werden im App-Speicher über CryptoKit verarbeitet. Durch das Sperren wird der aktive Schlüsselstatus gelöscht, aber Swift und iOS garantieren nicht, dass jede vorübergehende Kopie überschrieben wird.
Tresorerkennung. Die normale Benutzeroberfläche zeigt keine Tresorliste an. Das Speicherformat legt ein Speicherverzeichnis pro Tresor an. Wer Zugriff auf den App-Container hat, kann daher die Tresore zählen, obwohl die Verzeichnisnamen keine Muster, Namen oder Klartextinhalte preisgeben. Sieh dir die vollständige Sicherheitsarchitektur und Erklärung der Musterverschlüsselung an.
Wie man erkennt, ob eine App wirklich Zero-Knowledge-Verschlüsselung verwendet
Beginne mit drei Schnelltests und überprüfe dann die veröffentlichte Architektur:
Der Passwort-Vergessen-Test. Wenn das Zurücksetzen per E-Mail allein lesbare Daten wiederherstellt, frag, welcher vom Anbieter bereitgestellte Mechanismus den effektiven Inhaltsschlüssel wiederhergestellt hat. Vom Benutzer gehaltene Wiederherstellungsphrasen, die Genehmigung alter Geräte und vom Anbieter kontrollierte Zurücksetzungen sind unterschiedliche Konzepte.
Der Neugerätetest. Wenn ein neues Gerät lesbare Inhalte wiederherstellt, ermittle das Geheimnis oder das vertrauenswürdige Gerät, das es autorisiert hat. Allein die Kontoanmeldung deutet auf einen vom Anbieter kontrollierten Wiederherstellungspfad hin; eine Wiederherstellungsphrase und verschlüsselte Sicherungsdatensätze können die Trennung von Anbieter und Schlüssel gewährleisten.
Der Kontotest. Eine E-Mail-Adresse oder Telefonnummer verknüpft die Identität mit Dienstmetadaten, beweist jedoch nicht allein, dass der Anbieter Inhalte entschlüsseln kann. Untersuche die Schlüsselhierarchie, das Wiederherstellungsdesign, den Clientcode oder das Client-Audit, die Metadatenrichtlinie und ob authentifizierter Chiffretext Offline-Anmeldeinformationsprüfungen zulässt.
Bei diesen Tests handelt es sich um Filter, nicht um einen Sicherheitsnachweis. Eine kohärente Spezifikation sollte den Inhaltsschlüssel, den Entsperrschlüssel, Salts, Ableitungsparameter, das authentifizierte Verschlüsselungsformat, Nonce-Regeln, Wiederherstellungsumschläge, den lokalen geheimen Speicher, Cloud-Metadaten und den Punkt benennen, an dem Klartextschlüssel vorhanden sind. Eine unabhängige Überprüfung ist ein stärkerer Beweis als ein Produktetikett.
Häufig gestellte Fragen
Ist Zero-Knowledge-Verschlüsselung dasselbe wie Ende-zu-Ende-Verschlüsselung?
Sie überschneiden sich, sind aber nicht identisch. Ende-zu-Ende-Verschlüsselung (E2EE) bedeutet, dass Daten auf dem Gerät des Absenders verschlüsselt und nur auf dem Gerät des Empfängers entschlüsselt werden. Zero-Knowledge-Verschlüsselung bedeutet, dass der Anbieter nicht auf die Daten zugreifen kann. Ein Dienst kann E2EE sein ohne Zero-Knowledge zu sein, wenn der Anbieter zu einem Zeitpunkt Zugang zu den Schlüsseln hatte. Zero-Knowledge-Verschlüsselung ist der strengere Standard.
Was passiert, wenn ich mein Passwort bei Zero-Knowledge-Verschlüsselung verliere?
Wenn alle gültigen Anmeldeinformationen und der Wiederherstellungsumschlag verloren gehen, sind deine Daten dauerhaft unzugänglich. Ein vom Anbieter gesteuerter Reset oder Generalschlüssel würde die Anbietergrenze schwächen, daher muss die Wiederherstellung separat konzipiert werden. Vaultaire nutzt eine Wiederherstellungsphrase, entweder eine erzeugte Phrase aus neun Wörtern oder eine eigene aus mindestens sechs Wörtern, deren abgeleiteter Wiederherstellungsschlüssel einen verschlüsselten Tresorschlüsselumschlag öffnet. Durch die Phrase wird der Schlüssel nicht neu generiert oder codiert, und für die Wiederherstellung auf einem neuen Gerät sind auch die entsprechenden verschlüsselten CloudKit-Datensätze erforderlich.
Können Strafverfolgungsbehörden auf Zero-Knowledge-verschlüsselte Daten zugreifen?
Ein Anbieter muss möglicherweise gespeicherten Chiffretext und die von ihm gespeicherten Konto-, Verkehrs-, Abrechnungs- oder Dienstmetadaten offenlegen. Ohne einen vom Anbieter gehaltenen Klartext-Inhaltsschlüssel kann dieser Anbieter seinen normalen Dienstpfad nicht zum Entschlüsseln des Inhalts verwenden. Die Ausnutzung von Geräten, die Entdeckung von Anmeldeinformationen, Wiederherstellungskopien und die erzwungene Offenlegung sind separate Wege, deren Rechtmäßigkeit und Wirksamkeit je nach Gerichtsbarkeit und Sachverhalt variieren.
Ist Zero-Knowledge-Verschlüsselung langsamer als reguläre Verschlüsselung?
Die Stärke von AES-256-GCM hängt nicht davon ab, wer den Schlüssel in der Hand hat. Die passwortbasierte Ableitung verursacht beim Entsperren zusätzliche Arbeit und ihre Dauer hängt vom Algorithmus, der Anzahl der Iterationen, dem Gerät und der Implementierung ab. Anwendungen sollten diese Kosten für unterstützte Hardware messen und die Reaktionsfähigkeit gegen die Kosten abwägen, die für jeden Offline-Rateversuch anfallen.
Bedeutet Zero-Knowledge, dass die App überhaupt keine Daten sammelt?
Nicht unbedingt. Der Begriff bezieht sich auf die Inhaltsschlüsselgrenze des Anbieters, nicht auf jeden Datenfluss. Eine App kann weiterhin Kontodaten, Analysen, Absturzberichte, IP-Adressen, Datensatzgrößen, Timing oder andere Dienstmetadaten verarbeiten. Für Vaultaire ist kein Identitätskonto erforderlich. Seine App-Analyse und Absturzdiagnose sind standardmäßig aktiviert und können mit „Fehler anonym teilen“ in den Einstellungen deaktiviert werden. Die Richtlinie für dokumentierte Ereignisse schließt Tresorinhalte, Muster, Phrasen und Entschlüsselungsschlüssel aus. Die Datenschutzrichtlinie beschreibt die aktuellen Erfassungs- und Aufbewahrungsregeln.
Wie vergleicht sich Zero-Knowledge-Verschlüsselung mit Apples erweitertem Datenschutz für iCloud?
Apples erweiterter Datenschutz für iCloud (Advanced Data Protection, ADP), eingeführt in iOS 16.2, erweitert die Ende-zu-Ende-Verschlüsselung um zusätzliche iCloud-Kategorien und verwendet das Apple-Kontowiederherstellungsmodell. Vaultaire verschlüsselt den Tresorinhalt auf dem Gerät und erfordert kein Vaultaire-Identitätskonto; iCloud-Backup (standardmäßig aktiviert), Synchronisierung und Freigabe nutzen clientseitig verschlüsselte CloudKit-Datensätze im Apple-Konto des Benutzers. Vaultaire bietet auch mustergetrennten Tresorzugriff und Zwangsmodus, mit den darin beschriebenen Speicher- und Wiederherstellungsgrenzen Dokumentation zur glaubhaften Abstreitbarkeit.
Zusammenfassung
Zero-Knowledge-Verschlüsselung versteht man am besten als Aussage über die Trennung von Anbieter und Schlüssel: Der Dienst verfügt nicht über den Klartextschlüssel, der zum Entschlüsseln gespeicherter Inhalte erforderlich ist. Das ist stärker als die serverseitige Verschlüsselung mit vom Anbieter kontrollierten Schlüsseln, es ist jedoch keine Aussage darüber, dass Schlüssel nur im Speicher vorhanden sind, dass Metadaten verschwinden oder dass jede Kompromittierung von Clients und Geräten verhindert wird. Beurteile das Produkt anhand seiner Schlüsselhierarchie, des Wiederherstellungsdesigns, der Implementierung und der unabhängigen Überprüfung.