Wie kann ein Server unsere Geheimnisse speichern und synchronisieren, ohne die Schlüssel zum Lesen zu besitzen? Wir verfolgen, wie Confidex seine Schlüssel erzeugt, sie mit einem Schloss schützt und sie zum Verschlüsseln von Daten und Prüfen von Änderungen nutzt.

Schloss

Nur der Auserwählte kann die Tür öffnen

Matrix Reloaded

Stellen wir uns vor, wir bauen einen virtuellen Tresor, einen vault, um geheime Daten zu speichern. Er muss die Daten nach dem Schließen der Anwendung auf einem Laptop aufbewahren und das Öffnen auf einem anderen Gerät ermöglichen. Dafür braucht der Tresor eigene Schlüssel. Wir müssen sie so speichern, dass eine Kopie der Dateien Außenstehenden weder das Lesen noch das Verändern der Inhalte ermöglicht.

Ein Schloss, ein lock, schützt die Schlüssel: eine kleine verschlüsselte Datei. Zum Öffnen braucht man ein Master-Passwort und den geheimen Code secret_key; beides steht nicht in der Datei selbst. Wir könnten das gesamte Schloss in der Morgenzeitung abdrucken. Die Leser hätten dann eine Kopie, aber die Veröffentlichung würde die privaten Schlüssel nicht offenlegen.

Angenommen, ein Außenstehender erhält diese Datei und erfährt sogar das Master-Passwort. Er kann nun alle Berechnungen wiederholen, die nur das Passwort benötigen. Den Schlüssel zum Öffnen des Schlosses erhält er dadurch jedoch nicht: Auch secret_key fließt in die Berechnung ein. Die Datei enthält keine separate Prüfung des Passworts allein. Zum Öffnen braucht man weiterhin den unbekannten geheimen Code.

Dieser Code stammt aus kryptografisch zufälligen Daten; kein Mensch denkt ihn sich aus. Solange secret_key unbekannt ist, öffnet auch ein richtig erratenes Master-Passwort das Schloss nicht: Dem Angreifer fehlt weiterhin ein zufälliges Geheimnis. Ein schwaches Passwort allein macht eine Serverkopie daher nicht zu einem praktisch angreifbaren Ziel für Wörterbuchangriffe.

Gelangt auch secret_key in die Hände des Angreifers, kann er Vermutungen über das Master-Passwort offline prüfen. Das ist aufwendig, doch die tatsächliche Schwierigkeit hängt von der Stärke des Passworts ab.

Schlüssel

Meine Herren, was machen Schlüssel? Schlüssel... Dinge aufschließen?

Fluch der Karibik – Die Truhe des toten Mannes

Die Anwendung bezieht 32 zufällige Bytes vom kryptografischen Zufallsgenerator des Betriebssystems und bereitet sie zur Verwendung als Schlüssel vor. Diese vorbereiteten Bytes sind der private Master-Schlüssel master_key.

Aus master_key leitet die Anwendung immer dieselben Schlüssel ab: Dieselben Berechnungen mit denselben Bytes liefern dasselbe Ergebnis. Ein Laptop und ein Telefon können deshalb identische Schlüssel wiederherstellen. Um master_key auf einem neuen Gerät zu erhalten, muss die Anwendung zunächst das Schloss mit dem Master-Passwort und secret_key öffnen.

Das erste Paar: Verschlüsselung

Ich bin der Schlüsselmeister.

Geisterjäger

Um Daten verschlüsselt zu speichern, berechnet die Anwendung aus master_key einen öffentlichen Schlüssel: secret_key. Damit lassen sich Daten für den Tresor verschlüsseln; zum Entschlüsseln braucht man master_key.

„Öffentlich“ beschreibt die Rolle dieses Schlüssels im Algorithmus, nicht die Pflicht, ihn an alle weiterzugeben. In Confidex bleibt er beim Benutzer. Er ist zugleich das zweite Geheimnis zum Öffnen des Schlosses, bleibt deshalb lokal und wird nicht über das Netzwerk gesendet. Mit secret_key allein kann jemand Daten für den Tresor verschlüsseln, aber weder entschlüsseln noch Änderungen in dessen Namen signieren.

X25519 ist der Algorithmus, der aus master_key den Schlüssel secret_key berechnet. master_key aus secret_key zurückzugewinnen ist praktisch unmöglich. Ein klassischer Angriff auf einem gedachten Supercomputer mit einer Milliarde Milliarden Kurvenoperationen pro Sekunde würde im Mittel etwa 2,3 Billionen Jahre dauern (Schätzung von SafeCurves).

Das zweite Paar: Signaturen

Das Einzige, was original ist, ist die Unterschrift

Fang mich, wenn du kannst

Das erste Paar hilft, den Inhalt zu verbergen. Nun brauchen wir eine Möglichkeit festzustellen, ob der Eigentümer des Tresors eine Änderung erlaubt hat. Auch der Server muss Signaturen prüfen können, also müssen wir ihm einen öffentlichen Prüfschlüssel senden. Der öffentliche Teil des ersten Paars ist secret_key, den der Server nicht erhalten darf. Deshalb erzeugen wir für Signaturen ein zweites, dauerhaftes Schlüsselpaar.

Statt ein weiteres unabhängiges Geheimnis zu speichern, leiten wir aus master_key einen privaten Signaturschlüssel ab und nennen ihn signing_key. Damit signiert die Anwendung Daten und das Schloss. Andere Geräte und der Server können mit seinem öffentlichen Teil die Signaturen prüfen, ohne den Inhalt zu lesen.

Dieses Paar lässt sich aus demselben master_key wiederherstellen. Die Anwendung leitet daraus einen Ausgangswert ab: 32 Bytes, die den Signaturschlüssel eindeutig bestimmen.

Damit unterschiedliche Aufgaben unterschiedliche Schlüssel erhalten, fließt eine feste Kennzeichnung in die Berechnung ein: hier confidex/vault/ed25519/v1. Derselbe master_key liefert mit derselben Kennzeichnung immer denselben Schlüssel.

Das Master-Passwort kommt in diesen Berechnungen noch nicht vor. Beide Paare hängen von den zufälligen Bytes von master_key ab, nicht von einer durch einen Menschen gewählten Zeichenfolge. Diese Trennung wird später wichtig: Das Passwort schützt den Zugang zu bereits vorhandenen Schlüsseln. Es kann also geändert werden, ohne die Schlüssel selbst zu ändern.

Die Ableitung nutzt eine auf Hashfunktionen beruhende Schlüsselableitungsfunktion: HKDF, HMAC-based Extract-and-Expand Key Derivation Function. Confidex verwendet sie mit SHA-256, daher der Name HKDF-SHA256. Die entstehenden 32 Bytes bilden den Seed für das Ed25519-Paar. Der öffentliche Teil von signing_key verrät secret_key nicht und kann deshalb zur Signaturprüfung an den Server gesendet werden.

Was ist eine Schlossdatei, und was leistet sie?

Öffne die Türen der Kapselbucht, HAL.
Es tut mir leid, Dave. Ich fürchte, das kann ich nicht.

Eine Weltraum-Odyssee

Das Schloss speichert master_key verschlüsselt. Zum Öffnen braucht man das Master-Passwort und secret_key. Der öffentliche Header enthält die Formatversion, die Tresorkennung, den öffentlichen Teil von signing_key, einen Salt und die Parameter der Passwortverarbeitung. Die interne Formatversion wird zusammen mit master_key verschlüsselt.

Beim Erstellen des Schlosses besitzt die Anwendung master_key bereits und berechnet deshalb secret_key vor der Verschlüsselung. Beim Öffnen stellt der Benutzer secret_key separat bereit: In der öffentlichen Kopie des Schlosses fehlt er.

Nach dem Entschlüsseln berechnet die Anwendung mit X25519 den öffentlichen Teil von master_key und verlangt, dass er mit secret_key übereinstimmt. Anschließend stellt sie signing_key wieder her und vergleicht dessen öffentlichen Teil mit dem Schlüssel im Header. Auf diese Weise prüft sich das Schloss selbst.

Um das Erraten des Master-Passworts zu verlangsamen, muss jeder Versuch Zeit und Speicher benötigen. Confidex verwendet Argon2id mit 64 MiB Speicher und drei Durchläufen. Bei der Passwortverarbeitung kommt außerdem ein zufälliger Salt zum Einsatz. Er ist nicht geheim: Er sorgt dafür, dass dasselbe Passwort in verschiedenen Schlössern unterschiedliche Ergebnisse liefert.

Ist secret_key bereits bekannt, verändert die Passwortlänge den Umfang eines Angriffs drastisch. Für 5 zufällige lateinische Kleinbuchstaben gibt es etwa 12 Millionen Kombinationen, für 7 etwa 8 Milliarden und für 12 etwa 95 Billiarden. Der Wechsel von 7 auf 12 Buchstaben vergrößert den Suchraum fast um das 12-Millionenfache. Würde die Suche nach 7 Buchstaben auf einem bestimmten Rechner im Mittel einen Tag dauern, wären es bei 5 etwa zwei Minuten und bei 12 etwa 33.000 Jahre.

Um aus dem Argon2id-Ergebnis und secret_key einen einzigen Schlüssel zu gewinnen, verwenden wir die zuvor eingeführte Funktion HKDF-SHA256 mit der Kennzeichnung confidex/lock/wrap/v1. Das Ergebnis heißt wrapping_key und verschlüsselt das Schloss.

Wir müssen master_key verbergen und vor Manipulation schützen. XChaCha20-Poly1305 verschlüsselt ihn mit wrapping_key und fügt einen Authentifizierungs-Tag hinzu. Der Tag bindet den Geheimtext an den öffentlichen Header: Ein falsches Passwort oder eine Änderung geschützter Bytes lässt das Öffnen scheitern. Der Tag und ein zufälliger Einmalwert, die Nonce, werden zusammen mit dem Geheimtext gespeichert.

Bei jeder Erstellung oder erneuten Verschlüsselung des Schlosses bezieht die Anwendung einen frischen Salt und eine neue Nonce. Der verschlüsselte Inhalt umfasst ein Versionsbyte und die 32 Bytes von master_key; daneben werden eine 24 Byte lange Nonce und ein 16 Byte langer Tag gespeichert. Die Dokumentation des Algorithmus beschreibt den Aufbau.

Nicht übereinstimmende wiederhergestellte Schlüssel können auf ein absichtlich fehlerhaft aufgebautes Schloss oder einen Fehler im erzeugenden Programm zurückgehen. Zufällige beschädigte Bytes werden gewöhnlich schon vorher bei der Tag-Prüfung erkannt.

Der Server besitzt nicht die Geheimnisse, die er zum Prüfen dieses Tags bräuchte. Für die Übertragung des Schlosses fügt die Anwendung daher eine mit signing_key erzeugte Signatur hinzu. Sie umfasst die gesamte fertige Datei einschließlich des öffentlichen Headers und des verschlüsselten Inhalts. Der Server prüft die Signatur und hinterlegt beim ersten Hochladen den vollständigen öffentlichen Teil von signing_key sowie die interne Tresorkennung. Spätere Änderungen prüft er gegen diesen Schlüssel. Das Schloss und die verschlüsselten Daten werden mit demselben signing_key signiert, der aus master_key wiederhergestellt wird.

Der Tresor

Nun können wir das Schloss veröffentlichen. Nur wer secret_key und das Master-Passwort master password kennt, kann master_key lesen. Dagegen kann jeder den öffentlichen Signaturschlüssel aus der Schlossdatei entnehmen und signierte Daten prüfen, ohne den Inhalt des Schlosses oder der Daten zu sehen.

Nehmen wir ein Passwort: SuperPa55worD. Zunächst wollen wir es nur speichern: Nach dem Schließen der Anwendung sollten wir die Schlossdatei und das verschlüsselte Passwort beliebig weitergeben können, ohne dass jemand SuperPa55worD sieht, aber dennoch unsere Urheberschaft prüfen kann. Mit secret_key und dem Master-Passwort master password muss sich die Verschlüsselung umkehren lassen. Ein symmetrisches Verfahren kann mit demselben Schlüssel ver- und entschlüsseln. Da wir diesen Schlüssel nicht speichern, müssen wir ihn mithilfe des Schlosses wiederherstellen können. Wir nennen ihn message_key.

Für jede neue Verschlüsselung gewinnen wir einen eigenen message_key. Wir müssen noch seine Wiederherstellung ermöglichen: Würde der Schlüssel offen neben dem Geheimtext liegen, könnte jeder mit einer Kopie alles lesen.

Aus frischen zufälligen Bytes erzeugt die Anwendung ein temporäres X25519-Paar nur für diese Verschlüsselung: record_key. Anschließend nimmt sie den privaten Teil von record_key und den dauerhaften öffentlichen Tresorschlüssel secret_key und berechnet ein gemeinsames Geheimnis. Eine separate Funktion leitet daraus message_key ab; mit diesem Schlüssel wird unser Passwort verschlüsselt.

Beim Lesen nimmt die Anwendung einen anderen Weg. Sie verwendet master_key und den öffentlichen Teil von record_key. Diese beiden Schlüssel liefern dasselbe gemeinsame Geheimnis. Mathematisch multiplizieren beide Wege denselben Ausgangspunkt auf der Kurve mit zwei privaten Zahlen, nur in anderer Reihenfolge. Die Reihenfolge ändert das Ergebnis nicht. Wir können den Entschlüsselungsschlüssel deshalb wiederherstellen, ohne den privaten Teil von record_key aufzubewahren.

Dieses Geheimnis aus den beiden öffentlichen Schlüsseln zu gewinnen ist praktisch unmöglich: Jeder der beiden Wege braucht den passenden privaten Schlüssel. Aus den öffentlichen Punkten lassen sich die privaten Zahlen, aus denen sie entstanden sind, nicht effizient zurückgewinnen. Dieser mathematische Trick bildet die Grundlage der Tresorsicherheit. Er verhindert aber nicht, dass uns jemand einen anderen Tresor mit unserem daran befestigten Schloss unterschiebt.

Jetzt können wir den Geheimtext zusammen mit dem öffentlichen Teil von record_key speichern. Der private Teil von record_key und der verwendete message_key werden zum späteren Lesen nicht mehr benötigt. Die Anwendung stellt den Entschlüsselungsschlüssel später aus master_key und dem gespeicherten öffentlichen Teil von record_key wieder her. Ein dauerhaftes Tresorgeheimnis kann so viele separat verschlüsselte Werte entschlüsseln; deren jeweiliger message_key wird bei Bedarf wiederhergestellt.

Den Text zu verbergen reicht nicht: Beim Lesen müssen wir auch Manipulation erkennen. Die Verschlüsselung fügt deshalb einen Authentifizierungs-Tag hinzu, einen kurzen Wert, der zusammen mit den verschlüsselten Daten geprüft wird. Scheitert die Prüfung, verwirft die Anwendung das Ergebnis. Sie darf zufälligen oder veränderten Text nicht als erfolgreich entschlüsseltes Passwort anzeigen.

Wir haben einen Aufbau beschrieben, bei dem ein asymmetrisches Paar hilft, ein gemeinsames Geheimnis zu vereinbaren, während message_key den Inhalt verschlüsselt. Das heißt Hybrid Public Key Encryption, kurz HPKE, und ist in RFC 9180 spezifiziert. Confidex verwendet X25519 zur Vereinbarung des Geheimnisses, HKDF-SHA256 zur Schlüsselableitung und ChaCha20-Poly1305 zur Verschlüsselung mit Integritätsprüfung. Hier erhält HKDF das mit record_key und dem Paar von master_key vereinbarte gemeinsame Geheimnis; das ist eine andere Aufgabe als die Ableitung des Ed25519-Seeds. RFC 5869 beschreibt HKDF.

Für die nächste Verschlüsselung erzeugt die Anwendung einen neuen record_key und einen neuen HPKE-Kontext. Wird dieselbe Kombination aus message_key und Nonce wiederverwendet, ist der Schutz des Verfahrens gebrochen. In Confidex werden Schlüssel und Nonce innerhalb von HPKE abgeleitet, für eine Nachricht verwendet und der Kontext anschließend verworfen.

ChaCha20 selbst verwendet einen 256 Bit langen message_key. Um den Umfang eines direkten Angriffs einzuschätzen, stellen wir uns einen fiktiven Supercomputer vor, der pro Sekunde eine Milliarde Milliarden Kandidaten prüft. Die Suche unter 2²⁵⁶ möglichen Schlüsseln würde etwa 1,8 × 10⁵¹ Jahre dauern. RFC 8439 beschreibt den Algorithmus und seine Analyse.

Ein Eintrag

Wir freuen uns?

Pulp-Fiction

Das Passwort ist gespeichert, aber zur Anmeldung an einer Website braucht man gewöhnlich auch einen Benutzernamen und eine Adresse. Manchmal gehört eine Notiz dazu. Speichern wir diese Werte getrennt, muss die Anwendung sich irgendwie merken, dass sie zusammengehören. Legen wir diese „Papiere“ in einen Umschlag. Wir fassen die Felder zu einer Sammlung zusammen und nennen sie einen Eintrag, einen record.

Ein Eintrag kann jede beliebige Kombination von Feldern enthalten. Die Anwendung packt sie in ein Paket, komprimiert es und verschlüsselt alles nach dem gerade beschriebenen Verfahren. Werte, Namen, Typen und Tags der Felder sind geschützt. Auch wenn das Passwort gleich bleibt, entsteht beim Ändern der Website-Adresse eine neue Version des gesamten Eintrags, verschlüsselt mit einem neuen record_key.

Hash-Kette

SOLLTE IHR PROJEKT EINE BLOCKCHAIN VERWENDEN? → NEIN

XKCD 2267

Wer secret_key kennt, kann einen verschlüsselten Eintrag für unseren Tresor vorbereiten. Damit wir ihn nicht für unseren eigenen halten, signiert die Anwendung jede Version mit signing_key. Ohne diesen Schlüssel kann ein Außenstehender keine Version mit einer Signatur erzeugen, die der Server und die anderen Geräte akzeptieren.

Die verschlüsselte Version braucht Begleitinformationen: zu welchem Tresor und Eintrag sie gehört, wann sie geändert wurde und welche Versionen ihr vorausgehen. Daraus entsteht der öffentliche Header. Er enthält nicht das Passwort, braucht aber dennoch Schutz: Sonst könnte jemand die Zugehörigkeit und Beziehungen der Objekte verändern, ohne den Geheimtext anzutasten. Die Anwendung signiert die exakten Headerbytes zusammen mit dem Geheimtext. Änderungen an den signierten Daten machen die Signatur ungültig.

Der Server ähnelt einem Lager für versiegelte Pakete. Er sieht Header, verschlüsselten Inhalt und Signatur, aber nicht das Passwort darin, und weiß, dass es den Empfänger in der Stadt gibt. Er prüft die Signatur gegen den hinterlegten öffentlichen Teil von signing_key und entscheidet, ob er die neue Version annehmen darf. Dafür braucht er weder das Master-Passwort noch secret_key noch irgendeinen privaten Schlüssel. Beim Lesen prüft der Client dieselbe Signatur. Beim Entschlüsseln prüft er dann mit dem HPKE-Authentifizierungs-Tag erneut die Bindung zwischen Inhalt und Header.

Die Signatur schützt auch die Verknüpfungen zwischen den Versionen. Ein SHA-256-Hash der exakten Header- und Geheimtextbytes wird zur Versionskennung. Der Header der nächsten Version enthält die Kennung der vorherigen. Ändern wir ein Website-Passwort, erzeugt und signiert die Anwendung ein neues Objekt mit dieser Verknüpfung. Das alte Objekt und seine Signatur bleiben unverändert. Den Vorgänger auszutauschen und dabei die Signatur der neuen Version zu erhalten, scheitert daher. Nehmen zwei Geräte unabhängige Änderungen vor, bleiben beide Zweige erhalten; eine zusammengeführte Version kann auf beide verweisen.

Erinnern Sie sich an Blockchain? Da ist sie :-).

Mit dem öffentlichen Header lassen sich Verknüpfungen ohne Entschlüsselung prüfen, aber einige Informationen bleiben sichtbar. Der Server kennt die Kennungen, Versionsverknüpfungen, den vom Client übermittelten Änderungszeitpunkt, die Anzahl der Felder und die codierte Größe jedes Feldwerts. Die Verschlüsselung verbirgt den Inhalt des Eintrags, nicht diese Strukturinformationen.

Sync

„Kein Datenleck, ein kostenloses verteiltes Backup.“

Internet-Meme.

Für die Arbeit auf mehreren Geräten müssen Schloss und Eintragsverlauf zwischen ihnen übertragen werden. Das Objektformat ändert sich dabei nicht: Übertragen werden dieselben verschlüsselten Bytes und Signaturen, die auch lokal gespeichert sind.

Für die manuelle Übertragung erstellt die Anwendung ein ZIP-Archiv mit dem Schloss, allen lokal gespeicherten verschlüsselten Eintragsversionen und einer signierten Dateiliste. Weder das Passwort noch secret_key sind enthalten. Auf einem anderen Gerät öffnet die Anwendung zuerst das Schloss, prüft dann die Signaturen, entschlüsselt die Einträge und stellt eine lokale Tresorkopie wieder her. Der Import ist für ein Gerät gedacht, auf dem dieser Tresor noch nicht existiert; er führt den Verlauf nicht mit einer vorhandenen Kopie zusammen.

Ein Sync-Server tauscht Änderungen zwischen arbeitenden Kopien aus. Beim ersten Hochladen empfängt er das signierte Schloss, prüft die Signatur und berechnet aus dem öffentlichen Teil von signing_key die öffentliche Tresoradresse. Anschließend merkt er sich diesen Schlüssel und die Tresorkennung aus dem Header: Damit ist der Tresor auf dem Server registriert. Spätere Änderungen müssen zu dieser Kennung passen und eine Signatur desselben Schlüssels tragen.

Ein neues Gerät braucht die Tresoradresse und secret_key. Die Anwendung fasst beides deshalb mit einer Prüfsumme zu einem Übertragungscode zusammen. Der Benutzer überträgt diesen Code auf das Gerät und gibt das Master-Passwort separat ein; an den Server wird nur die öffentliche Adresse gesendet.

Nach dem Öffnen des heruntergeladenen Schlosses vergleicht die Anwendung die öffentlichen Teile der wiederhergestellten Schlüssel mit secret_key und dem Header und prüft die berechnete Adresse gegen den Übertragungscode. Dann speichert sie den geprüften öffentlichen Teil von signing_key zur Prüfung der Einträge.

Bei der Synchronisierung lädt die Anwendung fehlende Versionen herunter und eigene Änderungen hoch. Der Server prüft Signaturen und Verknüpfungen zu Vorgängerversionen, speichert angenommene Objekte und gibt sie an andere Geräte weiter. Empfangene Daten zu prüfen, sie zu entschlüsseln und Konflikte aufzulösen, ist Aufgabe der Geräte des Benutzers.

Die Registrierung fragt weder nach Namen und E-Mail-Adresse noch nach einem separaten Passwort. Der Server sieht die öffentliche Adresse, den Signaturprüfschlüssel, öffentliche Header, Objektgrößen und Versionsverknüpfungen. Er sieht auch IP-Adressen und Anfragezeitpunkte. Master-Passwort, secret_key, private Schlüssel und Klartextinhalte bleiben auf den Geräten des Benutzers. Jeder, der die öffentliche Adresse kennt, kann die verschlüsselten Objekte herunterladen; zum Lesen braucht man aber die Geheimnisse des Benutzers.

Diese Prüfungen erkennen gefälschte Objekte, beweisen jedoch nicht, dass der Server den vollständigen Verlauf und seinen neuesten Stand gezeigt hat. Er kann einen dem Client unbekannten Zweig verbergen oder einen in sich stimmigen älteren Datenbestand zurückgeben. Eine Signatur bestätigt die Echtheit eines einzelnen Objekts, nicht die Vollständigkeit der Serverantwort. Der Benutzer bemerkt möglicherweise fehlende Änderungen auf einem anderen Gerät, doch ein in sich stimmiger alter Verlauf besteht die Prüfung der Hash-Kette.

Das Master-Passwort ändern

Würde Ihre Heiligkeit also Interesse daran haben, ihr Passwort zu ändern?

Hacker (1995)

Beim Ändern des Master-Passworts wird nur das Schloss neu verschlüsselt; master_key darin bleibt gleich. Einträge, ihre Signaturen, secret_key und die Tresoradresse bleiben deshalb unverändert. Das neue Schloss wird mit demselben signing_key signiert.

Eine alte Schlosskopie lässt sich weiterhin mit dem alten Passwort und demselben secret_key öffnen; ein Passwortwechsel widerruft keine bereits offengelegten Schlüssel.

Das Gesamtbild

Das Schloss schützt master_key, message_key verschlüsselt die Einträge und signing_key erzeugt Signaturen. ZIP-Archive und der Server erhalten verschlüsselte Objekte mit Signaturen.