Was ist Zero-Knowledge-Verschlüsselung? Ein einfacher Leitfaden
Zero-Knowledge-Verschlüsselung bedeutet, dass der Anbieter nicht auf Ihre Daten zugreifen kann.
Bei der Zero-Knowledge-Verschlüsselung handelt es sich um eine anbietergebundene 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 diese Funktion auf Benutzergeräten aufrechterhalten. Eine rechtliche Anfrage, ein Verstoß oder ein Insider kann dennoch dazu führen, dass Chiffretext, Kontodaten, Verkehrsdaten oder andere vom Anbieter gespeicherte Metadaten offengelegt werden. Die Schlüsselverwaltungsrichtlinien von NIST stellen die Schlüsselverwahrung in den Mittelpunkt des Zugriffs, 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 Sie die Kombination einstellen und das Hotel sie nie erfährt. Wenn Sie die Kombination vergessen, kann das Hotel den Tresor nicht für Sie ö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 weiterhin bestehen, 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 Servicepfad | Hängt von Client, Wiederherstellung und Metadaten-Offenlegung ab | iCloud mit erweitertem Datenschutz |
| Provider-blinde, 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 durchsickern | 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 Ihre 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 Ihre 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 Verstoß dazu führen, dass sowohl gespeicherte Daten als auch ein Pfad zu deren Entschlüsselung offengelegt werden. Durch die Provider-blinde Verschlüsselung werden diese Vermögenswerte getrennt: Bei einem Serververstoß können immer noch Chiffretext und Metadaten offengelegt werden, nicht jedoch ein vom Provider gehaltener Klartext-Inhaltsschlüssel. Das Erraten von Anmeldedaten und die Kompromittierung von Kunden 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 2011 Advanced Data Protection eingeführt iOS 16.2 als optionale Erweiterung der Ende-zu-Ende-Verschlüsselung für iCloud Daten.
„Vertrau uns" ist keine Sicherheitsarchitektur
Die serverseitige Verschlüsselung basiert auf vom Anbieter kontrollierten Schlüsseln und Richtlinien. Durch die Provider-blinde Verschlüsselung wird die Schlüsselverwahrung geändert, 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, Soundwiederherstellung, 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 standardisiert SP 800-38D (2007). 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 umfassende Suche über einen einheitlich 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 8018wandelt einen von Menschen bereitgestellten Berechtigungsnachweis durch wiederholte pseudozufällige Funktionsaufrufe in Schlüsselmaterial fester Länge um. Weitere Iterationen erhöhen die Kosten jeder Schätzung. 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 einer geräteweiten Keychain Salt für 600.000 Iterationen, um einen 256-Bit-Tresorschlüssel abzuleiten. Der Tresorschlüssel authentifiziert den verschlüsselten Index und umschließt einen separaten zufälligen 256-Bit-Hauptschlüssel. Wiederherstellungsinformationen, einschließlich des Musters, werden in einem gespeichert AES-GCM verschlüsselt Keychain Datenbank anstelle von Klartextdateien oder einem Vaultaire-Konto.
Dateiverschlüsselung. Jede importierte Datei wird mit verschlüsselt AES-256-GCM unter dem zufälligen Hauptschlüssel. CryptoKit erstellt authentifizierte, versiegelte Boxen mit neuen Nonces, und das Streaming-Format leitet für jeden bestellten Block eine eindeutige Nonce ab.
Metadatenverschlüsselung. Dateinamen, MIME Typen, Datumsangaben, Indexdatensätze und Miniaturbilddaten sind ebenfalls geschützt AES-256-GCM. Vaultaire verwendet ChaCha20 nicht für Tresormetadaten.
Schlüsselverwaltung. Vaultaire speichert seine Geräte-Salt- und verschlüsselte Wiederherstellungsdatenbank wie gewohnt iOS Keychain Mit generischem Passwort geschützte Elemente WhenUnlockedThisDeviceOnly Barrierefreiheitsklasse. Von Mustern abgeleitete Tresorschlüssel und zufällige Hauptschlüssel werden im App-Speicher verarbeitet CryptoKit. Durch das Sperren wird der aktive Schlüsselstatus gelöscht, aber Swift und iOS unterstützen keine Garantie, dass jede transiente Kopie überschrieben wird.
Tresorerkennung. Die normale Benutzeroberfläche zeigt keine Tresorliste an. Das lokale Format speichert genau eine verschlüsselte Indexdatei für jeden Tresor, und der Wartungscode kann diese Dateien aufzählen. Jemand mit App-Container-Zugriff kann daher verschlüsselte Indizes zählen, obwohl die Dateinamen keine Muster, Namen oder Klartextinhalte preisgeben. Sehen Sie sich das Ganze an Sicherheitsarchitektur und Erklärung der Musterverschlüsselung.
Wie man erkennt, ob eine App wirklich Zero-Knowledge-Verschlüsselung verwendet
Beginnen Sie mit drei Schnelltests und überprüfen Sie dann die veröffentlichte Architektur:
Der Passwort-Vergessen-Test. Wenn das Zurücksetzen per E-Mail allein lesbare Daten wiederherstellt, fragen Sie, 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, identifizieren Sie das geheime oder 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. Untersuchen Sie 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 Ihre Daten dauerhaft unzugänglich. Ein vom Anbieter gesteuerter Reset oder Master-Schlüssel würde die Grenzen des Anbieters schwächen, daher muss die Wiederherstellung separat konzipiert werden. Vaultaire generiert eine benutzerdefinierte Phrase mit 9 separaten 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 ist auch die entsprechende Verschlüsselung erforderlich CloudKit Aufzeichnungen.
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?
AES-256-GCM Die Leistung 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 jede Offline-Vermutung 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. Vaultaire benötigt kein Identitätskonto und sagt, dass seine einwilligungsbasierten Analysen Tresorinhalte, Muster, Phrasen und Entschlüsselungsschlüssel ausschließen; Es ist Datenschutzrichtlinie beschreibt die aktuellen Erhebungs- und Aufbewahrungsregeln.
Wie vergleicht sich Zero-Knowledge-Verschlüsselung mit Apples Advanced Data Protection?
Apples 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 hält den Tresorinhalt standardmäßig lokal und erfordert kein Vaultaire-Identitätskonto; optionale Sicherung, Synchronisierung und Freigabe nutzen clientseitig verschlüsselt CloudKit Datensätze im Apple-Konto des Benutzers. Vaultaire bietet auch mustergetrennten Tresorzugriff und Zwangmodus, mit den darin beschriebenen Speicher- und Wiederherstellungsgrenzen plausible Leugnbarkeitsdokumentation.
Zusammenfassung
Die wissensfreie Verschlüsselung lässt sich am besten als Anspruch auf Trennung von Anbieter und Schlüssel behandeln: 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 kein Anspruch darauf, dass Schlüssel nur im Speicher vorhanden sind, dass Metadaten verschwinden oder dass jede Kompromittierung von Clients und Geräten verhindert wird. Beurteilen Sie das Produkt anhand seiner Schlüsselhierarchie, des Wiederherstellungsdesigns, der Implementierung und der unabhängigen Überprüfung.