Sprechen Sie über PAKE

Lassen Sie uns nun über Informationssicherheit sprechen. Diese Veröffentlichung ist dem Start des Kurses „Kryptografische Informationssicherheit“ gewidmet , der am 30. Mai beginnt. Lass uns gehen.

Erste Regel von PAKE: Sprich niemals über PAKE. Die zweite Regel von PAKE besagt, dass die erste Regel Unsinn ist, da PAKE oder Password Authenticated Key Exchange (rus. Schlüsselaustausch mit Passwortauthentifizierung) eine der nützlichsten Technologien ist, die praktisch nirgendwo verwendet wird. Es sollte wo immer möglich implementiert werden, aber nicht so einfach.




Um zu verstehen, warum wir über Unsinn sprechen, schauen wir uns ein echtes Problem an.

Angenommen, ich arbeite mit einem Server, auf dem Benutzerkennwörter gespeichert sind. Es gibt eine traditionelle Methode zum Speichern: Hashing jedes Benutzerkennworts und Speichern des Ergebnisses in einer Kennwortdatenbank. Es gibt viele Ideen, wie man mit dem Hash-Prozess umgeht. Die heute am häufigsten verwendete Empfehlung besteht darin, eine speicherharte Kennwort-Hashing-Funktion (z. B. scrypt oder argon2 (mit einem eindeutigen Salt ) für jedes Kennwort) zu verwenden und dann das Hash-Ergebnis zu speichern. Es gibt unterschiedliche Meinungen darüber, welche Hash-Funktion verwendet werden soll und ob sie einen geheimen Wert (genannt "Pfeffer" ) verwenden kann, aber im Moment werden wir nicht darüber sprechen.

Unabhängig davon, welchen Ansatz Sie wählen, haben alle diese Lösungen eine Achillesferse:
Wenn der Benutzer zurückkehrt, um die Site zu betreten, muss er weiterhin sein (offenes) Passwort an den Server senden, damit er die Überprüfung durchführen kann .

Diese Notwendigkeit kann zu unangenehmen Konsequenzen führen, wenn Ihr Server jemals kompromittiert wird oder wenn Ihre Entwickler einen dummen Fehler machen. Anfang letzten Jahres hat Twitter beispielsweise alle Benutzer (und diese 330 Millionen!) Aufgefordert , Kennwörter zu ändern, da sich herausstellte, dass das Unternehmen Textkennwörter (nicht gehasht) gespeichert hat.

Derzeit widerspricht das Problem der Anmeldung in keiner Weise den Vorteilen des Passwort-Hashing. Sie müssen jedoch eine bessere Lösung finden: eine, bei der das Kennwort niemals im Klartext an den Server gesendet wird. Das kryptografische Tool, mit dem wir dies erreichen können, ist PAKE und insbesondere ein neues Protokoll namens OPAQUE, das wir am Ende dieses Artikels behandeln werden.

Was ist PAKE?

Das PAKE-Protokoll, das zuerst von Bellovin und Merritt vorgeschlagen wurde, ist eine spezielle Art von Schlüsselaustauschprotokoll . Schlüsselaustauschprotokolle (oder „Schlüsselvereinbarungen“) sollen den beiden Parteien (nennen wir sie Client und Server) helfen, sich mithilfe der Kryptografie mit öffentlichem Schlüssel auf einen gemeinsam genutzten Schlüssel zu einigen. Die frühesten Schlüsselaustauschprotokolle (zum Beispiel der klassische Diffie-Hellman ) waren nicht autorisiert, was sie anfällig für Angriffe wie Man-in-the-Middle machte . Eine Besonderheit der PAKE-Protokolle besteht darin, dass sich der Client mit einem Kennwort beim Server authentifiziert. Aus offensichtlichen Gründen wird davon ausgegangen, dass das Kennwort oder sein Hash dem Server bereits bekannt ist, was eine Überprüfung ermöglicht.

Wenn das alles wäre, wären PAKE-Protokolle einfach zu erstellen. Was PAKE jedoch wirklich nützlich macht, ist, dass es auch einen Client-Passwortschutz bietet. Eine ernsthaftere Garantie kann wie folgt formuliert werden: Nach einem Versuch, in das System einzutreten (erfolgreich oder erfolglos), sollten Client und Server nur wissen, ob das Clientkennwort mit dem vom Server erwarteten Wert übereinstimmt, und keine weiteren Informationen mehr. Dies ist eine ziemlich gute Verteidigung. Tatsächlich unterscheidet sich dies nicht von dem, was wir von einem Null-Offenlegungsnachweis verlangen.

Eine idealisierte Darstellung des PAKE-Protokolls. Die Eingabe von beiden Seiten beinhaltet eine gewisse Zufälligkeit, die hier nicht gezeigt wird. Der Lauscher muss den gemeinsam genutzten geheimen Schlüssel K nicht herausfinden, der selbst zufällig ist und nicht vom Passwort abhängt.

Das offensichtliche Problem bei PAKE ist natürlich, dass viele Entwickler das Protokoll „Schlüsselaustausch“ überhaupt nicht ausführen möchten! Sie möchten nur sicherstellen, dass der Benutzer das Passwort kennt.

Das Tolle an PAKE ist, dass der Anwendungsfall "Nur Anmelden" ziemlich einfach auszuführen ist. Angenommen, ich habe ein Standard-PAKE-Protokoll, mit dem sich Client und Server auf einen gemeinsamen Schlüssel K einigen können. Wenn er das richtige Kennwort kennt (und nur in diesem Fall), müssen wir lediglich eine einfache Überprüfung implementieren, die beide Parteien erhalten haben der gleiche Schlüssel. (Dies kann beispielsweise erfolgen, wenn die Parteien damit eine kryptografische Funktion berechnen und die Ergebnisse überprüfen.) Daher kann PAKE auch dann nützlich sein, wenn Sie nur das Kennwort überprüfen möchten.

SRP: PAKE, welche Zeit selbst vergessen hat

Das PAKE-Konzept scheint einen offensichtlichen Sicherheitsvorteil gegenüber dem naiven Ansatz zu bieten, den wir heute verwenden, um auf den Server zuzugreifen. Und die Methoden selbst sind alt, in dem Sinne, dass PAKE seit 1992 bekannt ist! Trotzdem sah ihn das Licht nie. Warum passiert das?

Es gibt mehrere offensichtliche Gründe. Das offensichtlichste hängt mit den Einschränkungen des Internets zusammen: Es ist viel einfacher, ein Passwortformular auf einer Webseite zu platzieren, als ausgefallene Kryptografie in einem Browser zu implementieren. Diese Erklärung reicht jedoch nicht aus. Selbst native Anwendungen implementieren PAKE selten für Anmeldevorgänge. Eine weitere mögliche Erklärung bezieht sich auf Patente , obwohl die meisten bereits abgelaufen sind. Für mich gibt es zwei wahrscheinliche Gründe, warum ich PAKE nicht habe:

• Mangel an hochwertigen PAKE-Implementierungen in gängigen Sprachen, was die Verwendung schwierig macht;
• Kryptografiespezialisten vermitteln die Essenz und den Wert ihrer Arbeit nicht schlecht, so dass die meisten Menschen nicht einmal wissen, dass PAKE überhaupt existiert.

Trotz der Tatsache, dass ich sagte, dass PAKE jetzt nicht verwendet wird, gibt es immer noch Ausnahmen von den Regeln.

Es gibt ein großartiges Protokoll, das 1998 von Tom Wu entwickelt wurde (nicht zu verwechseln mit Tim Wu) und das als „SRP“ (kurz für „Secure Remote Password“) bezeichnet wird. Tatsächlich handelt es sich nur um ein dreistufiges PAKE mit einigen zusätzlichen Funktionen, die in den ersten Arbeiten nicht implementiert wurden. Soweit ich weiß, unterscheidet sich SRP darin, dass es das häufigste PAKE-Protokoll der Welt ist. Ich werde zwei Beweise für diese Aussage geben:

1. SRP wurde als TLS-Chiffriersuite standardisiert und in Bibliotheken wie beispielsweise OpenSSL implementiert, obwohl niemand es besonders zu verwenden scheint.
2. Apple nutzt SRP in seinem iCloud Key Vault in großem Umfang

Die zweite Tatsache an sich könnte SRP zu einem der am häufigsten verwendeten kryptografischen Protokolle der Welt machen. Die Anzahl der Geräte, die Apple stempelt, ist so groß. Und es gibt nichts lustiges.

Die Tatsache, dass die Industrie die SRP akzeptiert hat, ist sicherlich gut, aber andererseits und nicht sehr. Meistens, weil SRP allein nicht die beste PAKE-Implementierung ist, obwohl jede PAKE-Empfehlung cool ist. Ich dachte, ich würde in den Dschungel der Diskussionen über SRP gehen, aber diese Rede zog sich bereits hin und ich schweife von der Geschichte über ein wirklich gutes Protokoll ab, über das wir weiter unten sprechen werden. Wenn Sie immer noch an der Diskussion über SRP interessiert sind, habe ich sie hierher gebracht .

Lassen Sie mich anstelle dieser unnötigen Details eine kurze Zusammenfassung meiner Gedanken zu SRP schreiben:

1. SRP macht einige Dinge richtig. Erstens müssen Sie im Gegensatz zu früheren Versionen von PAKE das unformatierte Kennwort nicht auf dem Server speichern (oder gleichwertig einen Hash, der von einem Angreifer anstelle eines Kennworts verwendet werden könnte). Stattdessen speichert der Server einen "Verifizierer", bei dem es sich um eine Einwegfunktion des Kennwort-Hash handelt. Dies bedeutet, dass ein Angreifer aufgrund eines Kennwortdatenbanklecks einen Benutzer nur dann nicht sofort ersetzen kann, wenn er keine weiteren kostspieligen Wörterbuchangriffe ausführt. (Der technische Name hierfür lautet "asymmetrisch" PAKE.)
2. Es gibt bessere Nachrichten, die aktuelle Version von SRP (v4 v6a) wurde noch nicht gehackt!
3. Allerdings (lassen Sie sich von den Entwicklern nicht beleidigen) ist die Architektur des SRP-Protokolls völlig verrückt und seine früheren Versionen wurden mehrmals gehackt - weshalb wir jetzt Version 6a haben. Außerdem beweist der "Sicherheitsnachweis" im ursprünglichen Forschungsartikel eigentlich nichts .
4. SRP basiert derzeit auf einer ganzzahligen (endgültigen) Arithmetik, und aus verschiedenen Gründen (siehe Abschnitt 3 oben) kann seine Architektur eindeutig nicht auf eine elliptische Kurve übertragen werden . Dies erfordert mehr Bandbreite und Berechnung, sodass SRP die vielen Leistungsverbesserungen, die wir in Add-Ons wie Curve25519 entwickelt haben, nicht nutzen kann.
5. SRP ist anfällig für Pre-Computing-Angriffe, da es das Salz des Benutzers an jeden Angreifer weitergibt, der eine SRP-Sitzung initiieren kann. Dies bedeutet, dass ich Ihren Server nach Ihrem Salt fragen und ein Wörterbuch mit potenziellen Kennwort-Hashes erstellen kann, bevor der Server kompromittiert wird.
6. Trotz all dieser Mängel ist SRP extrem einfach und enthält auch Arbeitscode. Darüber hinaus verfügt OpenSSL über Arbeitscode, der sogar in TLS integriert ist, was die Implementierung relativ einfach macht.

Von all diesen Punkten ist letzterer mit ziemlicher Sicherheit für den (relativ) hohen kommerziellen Erfolg verantwortlich, den SRP gegenüber anderen PAKE-Protokollen erzielt hat. Er ist nicht perfekt, aber echt. Dies wollte ich Experten für kryptografische Sicherheit vermitteln.

OPAQUE: PAKE neue Generation

Als ich vor einigen Monaten anfing, über PAKE nachzudenken, musste ich feststellen, dass die meisten vorhandenen Implementierungen eher schlecht abschnitten. Entweder hatten sie Probleme, wie z. B. in SRP, und der Benutzer musste das Kennwort (oder das effektive Kennwort) auf dem Server speichern, oder dem Angreifer wurde das „Salz“ angezeigt, sodass der Angriff vor der Berechnung ausgeführt werden konnte.

Anfang letzten Jahres enthüllten Jarecki, Kravczyk und Xu der Welt ein neues Protokoll namens OPAQUE . Es hat eine Reihe von wesentlichen Vorteilen:

1. Es kann auch dann implementiert werden, wenn Probleme mit Diffie-Hellman und diskreten Logarithmen auftreten. Dies bedeutet, dass es im Gegensatz zu SRP mithilfe effektiver elliptischer Kurven leicht instanziiert werden kann.
2. Noch besser: OPAQUE enthüllt einem Angreifer kein Salz. Er löst dieses Problem, indem er "Saltful PRF" verwendet, um das Salt mit dem Passwort zu kombinieren, sodass der Client das Salt nicht erhält und der Server das Passwort nicht erhält.
3. OPAQUE funktioniert mit jeder Passwort-Hashing-Funktion. Da alle Hashing-Arbeiten auf dem Client ausgeführt werden, kann OPAQUE den Server tatsächlich entlasten und den Onlinedienst freigeben, um beispielsweise extrem umfangreiche Sicherheitseinstellungen zu verwenden, z. B. die scrypt mit viel RAM zu konfigurieren.
4. In Bezug auf Nachrichtenanzahl und Exponenten unterscheidet sich OPAQUE nicht wesentlich von SRP. Da es jedoch mit effizienteren Parametern implementiert werden kann, wird es wahrscheinlich viel effizienter arbeiten.
5. Im Gegensatz zu SRP verfügt OPAQUE über angemessene Sicherheitsnachweise (in einem sehr starken Modell).

Es gibt sogar einen Internet-Entwurfsvorschlag für OPAQUE, den Sie hier lesen können. Leider weiß ich im Moment nichts über die Qualität der Code-Implementierung, außer dass es bereits mehrere mögliche Implementierungen gibt. Ich hoffe, dass dieses Problem bald behoben ist.
Das vollwertige OPAQUE-Protokoll ist unten aufgeführt. Im Rest dieses Abschnitts werde ich darüber sprechen, wie es funktioniert.

Problem 1: Salz geheim halten. Wie oben erwähnt, besteht das Hauptproblem bei früheren Versionen von PAKE darin, dass Salt vom Server auf den Client übertragen werden muss (immer noch nicht authentifiziert). Auf diese Weise kann ein Angreifer vor dem Rechnen Angriffe ausführen, bei denen er anhand der empfangenen Daten ein Wörterbuch erstellen kann.

Das Problem hierbei ist, dass Salt normalerweise zusammen mit dem Kennwort an eine Hash-Funktion (z. B. Verschlüsselung) übergeben wird. Intuitiv muss jemand diese Funktion berechnen. Wenn es sich um einen Server handelt, sollte der Server ein Kennwort sehen, das jede Bedeutung zunichte macht. Wenn dies ein Kunde ist, braucht er Salz.

Theoretisch können Sie dieses Problem umgehen, indem Sie die Kennwort-Hashing-Funktion mithilfe des sicheren Zwei-Parteien-Berechnungsprotokolls (2PC) berechnen . In der Praxis sind solche Lösungen mit ziemlicher Sicherheit ineffektiv, vor allem, weil Kennwort-Hashing-Funktionen komplex und zeitaufwändig sind. Dies erhöht die Komplexität jedes 2PC-Systems erheblich.

OPAQUE umgeht dies wie folgt. Es hinterlässt einen Passwort-Hash auf der Clientseite, zeigt ihn jedoch nicht an. Stattdessen wird ein spezielles Zwei-Wege-Protokoll namens Vergessliches PRF verwendet, um ein anderes Salt zu berechnen (nennen wir es salt2), sodass der Client salt2 in einer Hash-Funktion verwenden kann, aber nicht auf das ursprüngliche Salt zugreifen kann.

Es funktioniert ungefähr so:

Der Server speichert "salt" und der Client hat password.salt2 = PRF (salt, password). Dies wird zwischen dem Client und dem Server mithilfe eines Protokolls berechnet, bei dem der Client das Salt niemals erkennt und der Server das Kennwort kennt. Der Client erhält salt2K = PasswordHash (salt2, Passwort) - und all dies wird auf dem Client berücksichtigt.

Die eigentliche Implementierung von vergesslichem PRF kann unter Verwendung mehrerer Gruppenelemente und Exponenten erfolgen. Noch besser ist, wenn der Client das falsche Passwort eingibt, erhält das Protokoll einen Dummy-Wert „salt2“, der nichts über den tatsächlichen Wert von salt aussagt.

Problem 2: Beweis, dass der Client den richtigen Schlüssel K erhalten hat. Natürlich hat der Client im Moment den Schlüssel K erhalten, aber der Server hat keine Ahnung, was es ist. Der Server weiß auch nicht, ob dies der richtige Schlüssel ist.

Die OPAQUE-Lösung basiert auf der alten Idee von Gentry, Mackenzie und Ramzan . Wenn sich ein Benutzer zum ersten Mal am Server anmeldet, generiert der Server einen zuverlässigen öffentlichen und privaten Schlüssel für das Protokoll der sicheren Vereinbarung (z. B. HMQV) und verschlüsselt den empfangenen privaten Schlüssel unter K zusammen mit dem öffentlichen Schlüssel des Servers. Die resultierende authentifizierte Verschlüsselung (und der öffentliche Schlüssel) werden in der Kennwortdatenbank gespeichert.

C = Verschlüsseln (K, geheimer Clientschlüssel | öffentlicher Schlüssel des Servers)


Vollversion des OPAQUE-Protokolls, Auszug aus dem Artikel .

Wenn sich der Client mithilfe des OPAQUE-Protokolls authentifizieren möchte, sendet ihm der Server den gespeicherten C- Code. Wenn der Client in der ersten Phase das richtige Passwort eingegeben hat, kann er K erhalten und diese Chiffre entschlüsseln. Ansonsten ist es nutzlos. Mit einem kabelgebundenen geheimen Schlüssel kann er jetzt ein Standardvereinbarungsprotokoll mit einem authentifizierten Schlüssel ausführen, um den Handshake abzuschließen. (Der Server überprüft die Eingabe der Clients, indem er sie mit seiner Kopie des öffentlichen Schlüssels des Clients vergleicht. Der Client führt dasselbe aus.)

Lassen Sie uns jetzt alles zusammenfügen. Alle diese Schritte können zu einem Protokoll kombiniert werden, das die gleiche Anzahl von Schritten wie SRP aufweist. Wenn Sie die Überprüfungsschritte nicht beachten, sieht es wie im obigen Protokoll aus. Im Prinzip besteht die Idee nur aus zwei Nachrichten: eine vom Client und die zweite wird an den Server zurückgesendet.

Der letzte Aspekt der Arbeit von OPAQUE ist, dass es gute Sicherheitsnachweise gibt, die uns sagen, dass das resultierende Protokoll als sicher angesehen werden kann, wenn wir einen oder mehrere diskrete Logarithmen in einem zufälligen Orakelmodell verwenden, was anscheinend eine Standardannahme ist findet in den Einstellungen statt, mit denen wir arbeiten.

Fazit

Kurz gesagt, wir verfügen über eine zuverlässige Technologie, die die Verwendung von Kennwörtern erheblich vereinfacht und es uns ermöglicht, diese effizienter zu handhaben - mit vielen Hashing-Parametern und einer hohen Arbeitsbelastung auf der Clientseite. Warum wird das nicht überall verwendet? Vielleicht wird sich in den nächsten Jahren alles ändern. Die Zeit wird zeigen.

Gemäß der etablierten Tradition warten wir auf Ihre Kommentare und laden Sie ein, den Tag der offenen Tür zu besuchen, der am 27. Mai von unserer Lehrerin, Kryptoanalytikerin Elena Kirshanova , abgehalten wird .