Select Language

Privacy-Preserving Password Cracking: Ein Protokoll zur sicheren Hash-Wiederherstellung

Analyse des 3PC-Protokolls, das es Dritten ermöglicht, Passwort-Hashes zu knacken, ohne den Hash oder Klartext preiszugeben, unter Verwendung von Prädikatsverschlüsselung und Köder-Hashes.
strongpassword.org | PDF-Größe: 4,6 MB
Bewertung: 4.5/5
Ihre Bewertung
Sie haben dieses Dokument bereits bewertet
PDF-Dokumentendeckblatt - Privacy-Preserving Password Cracking: Ein Protokoll für sichere Hash-Wiederherstellung

Inhaltsverzeichnis

1. Einführung

Passwörter bleiben trotz branchenweiter Bestrebungen hin zu passwortlosen Lösungen die dominierende Form der Benutzerauthentifizierung. Die Speicherung von Passwort-Hashes ist gängige Praxis, doch das Testen ihrer Stärke durch Cracking ist ressourcenintensiv. Die Auslagerung dieser Aufgabe an Drittanbieter-Server birgt erhebliche Datenschutzrisiken, da sowohl der Hash-Digest als auch der wiederhergestellte Klartext offengelegt werden. Dieses Papier stellt das Privacy-Preserving Password Cracking (3PC)-Protokoll vor, das es einem Client ermöglicht, die Rechenleistung eines Dritten für das Hash-Cracking zu nutzen, ohne den Ziel-Hash oder das resultierende Passwort preiszugeben.

2. Das 3PC-Protokoll

Das 3PC-Protokoll wurde entwickelt, um das Vertrauensproblem beim Outsourcing von Passwort-Cracking zu lösen. Seine Kerninnovation besteht darin, dass eine dritte Partei die rechenintensive Arbeit übernehmen kann, ohne etwas über die tatsächlichen Daten des Kunden zu erfahren.

2.1 Core Mechanism & Predicate Function

Das Protokoll basiert auf dem Konzept der Prädikatenverschlüsselung, angepasst für Hash-Funktionen. Der Client sendet den Ziel-Hash $H(p)$ nicht direkt. Stattdessen sendet er einen Anonymitätsmenge die den echten Hash zusammen mit $k-1$ sorgfältig konstruierten Köder-Hashes enthält. Die Rolle des Drittanbieterservers besteht darin, zu knacken alle Hashes in diesem Set unter Verwendung eines bereitgestellten Passwortwörterbuchs oder Regelsatzes.

Der Schlüssel ist die Prädikatfunktion $f$. Der Server bewertet ein Kandidatenpasswort $p'$ gegen jeden Hash im Anonymitätsset. Die Funktion ist so definiert, dass $f(H(p'), H_i) = 1$ genau dann, wenn $H(p')$ mit dem Hash $H_i$ im Set übereinstimmt. Der Server gibt die Menge der Kandidatenpasswörter zurück, die $f=1$ für beliebig Hash in the Menge, ohne zu wissen, für welchen spezifischen Hash (echt oder Köder) eine Übereinstimmung gefunden wurde.

2.2 Decoy Hash Generation & Anonymity Set

Die Erzeugung plausibler Köder ist entscheidend für die Sicherheit. Köder-Hashes müssen für den Server nicht von den echten Hashes zu unterscheiden sein. Das Papier schlägt vor, Köder aus einer Verteilung zu generieren, die dem Ausgaberaum der Ziel-Hashfunktion (z.B. NTLM, SHA-256) entspricht. Dies gewährleistet $k$-Anonymität für den echten Hash. Der Client verwaltet plausible deniability, da selbst der Client nach der Übermittlung des Sets kryptografisch nicht beweisen kann, welcher Hash das ursprüngliche Ziel war.

Key Insights

  • Privatsphäre durch Unauffälligkeit in einer Menge: Die Sicherheit ergibt sich daraus, den echten Hash unter Täuschungselementen zu verbergen, nicht aus der traditionellen Verschlüsselung des Hashs selbst.
  • Verlagerung der Rechenlast: Der Overhead des Clients besteht in der Erzeugung des Anonymitätssatzes; der aufwändige Teil von Brute-Force-/Wörterbuchangriffen wird vollständig ausgelagert.
  • Constant-Time Lookup Promise: Das Protokoll verspricht, dass die Suchzeit unabhängig von der Größe des Anonymitätssatzes $k$ ist und nur durch die Server-IOPS begrenzt wird.

3. Technical Implementation & Analysis

3.1 Mathematische Grundlage

Die Sicherheit des Protokolls kann probabilistisch modelliert werden. Sei $S$ der Anonymitätssatz der Größe $k$, der einen echten Hash $H_r$ und $k-1$ Köder-Hashes $H_{d1}...H_{d(k-1)}$ enthält. Unter der Annahme perfekter Köder beträgt die Wahrscheinlichkeit, dass der Server nach Beobachtung des Satzes und der Cracking-Ergebnisse den echten Hash korrekt errät, höchstens $1/k$.

Der Informationsverlust $\mathcal{L}$ gegenüber dem Server kann mittels Min-Entropie quantifiziert werden: $\mathcal{L} \leq -\log_2(1/k) = \log_2(k)$ Bits. Der Client kann den Verlust durch Anpassung von $k$ steuern. Die Auswertung der Prädikatfunktion für einen Kandidaten $p'$ über alle $k$ Hashes kann als Vektor dargestellt werden: $\vec{R} = [f(H(p'), H_1), f(H(p'), H_2), ..., f(H(p'), H_k)]$. Ein Treffer auf der beliebig Position liefert $p'$ an den Client zurück.

3.2 Performance & Scalability

Das Papier argumentiert, dass der primäre Engpass nicht die kryptografischen Operationen sind, sondern die Input/Output-Operationen pro Sekunde (IOPS) des Crack-Setups des Servers (z. B. GPU/FPGA-Speicherbandbreite). Da der Server jedes Kandidatenpasswort gegen alle $k$ Hashwerte testen muss, steigt der Arbeitsfaktor theoretisch linear an ($O(k)$). Durch die Nutzung effizienter Stapelverarbeitung auf paralleler Hardware kann die effektive Verlangsamung jedoch minimiert werden, was sich dem behaupteten "konstantzeitigen" Nachschlagen für praktische $k$-Werte annähert.

4. Experimental Results & Chart Description

Die Autoren implementierten einen Proof-of-Concept auf einer FPGA-Architektur. Obwohl spezifische Leistungsdaten im bereitgestellten Auszug nicht detailliert beschrieben werden, behauptet das Papier, die Machbarkeit des Protokolls zu demonstrieren.

Hypothetisches Leistungsdiagramm (basierend auf der Protokollbeschreibung): Ein Liniendiagramm würde wahrscheinlich die "Effektive Knackgeschwindigkeit" auf der Y-Achse (z.B. Hashes/Sekunde) gegenüber der "Anonymitäts-Set-Größe (k)" auf der X-Achse zeigen. Die Kurve für einen traditional attack auf einen einzelnen Hash wäre eine hohe, flache Linie. Die Kurve für das 3PC protocol würde einen Rückgang mit steigendem k zeigen, aber die Steigung wäre aufgrund optimierter Stapelverarbeitung auf FPGA/GPU weniger steil als eine naive lineare Projektion. Eine dritte Linie könnte die "Theoretische Obergrenze (IOPS-Limit)" darstellen, die als Asymptote für die 3PC-Kurve fungiert.

5. Analysis Framework Example Case

Szenario: Ein freiberuflicher Penetration-Tester (Client) extrahiert einen NTLM-Hash vom System eines Kunden. Die Passwortrichtlinie ist bekannt: 9-stellige alphanumerische Mischung. Dem Tester fehlt die GPU-Leistung für eine zeitnahe Entschlüsselung.

Anwendung des 3PC-Protokolls:

  1. Client-Einrichtung: Der Tester setzt einen Privatsphärenparameter, z.B. $k=100$. Der echte NTLM-Hash ist $H_{real}$. Die Client-Software erzeugt 99 kryptografisch plausible Täuschungs-NTLM-Hashes und bildet so den Anonymitätssatz $S$.
  2. Server-Engagement: Der Tester sendet $S$ an einen kommerziellen Cracking-Dienst (Server) mit der Anfrage, alle Hashes unter Verwendung eines Wörterbuchs und von Regeln für 9-stellige alphanumerische Passwörter zu knacken.
  3. Server-Verarbeitung: Der Server führt seine Cracking-Tools aus. Für jedes generierte Kandidatenpasswort berechnet er dessen NTLM-Hash und prüft in einem Batch-Vorgang auf Übereinstimmung mit allen 100 Hashes in $S$.
  4. Ergebnisrückgabe: Der Server gibt eine Liste aller übereinstimmenden Passwörter zurück. beliebig Hash in $S$. Es wird nicht angegeben, welcher Hash übereinstimmt.
  5. Client-Filtering: Der Tester kennt den ursprünglichen Hash $H_{real}$. Er berechnet den Hash jedes zurückgegebenen Passworts, um dasjenige zu identifizieren, das mit $H_{real}$ übereinstimmt, und stellt so das Zielpasswort wieder her. Die anderen zurückgegebenen Passwörter entsprechen geknackten Ködern und werden verworfen.
Der Server erfährt nur, dass einer von 100 Hashes dem Tester gehörte, aber nicht welcher, und sieht viele geknackte Passwörter, ohne deren Relevanz zu kennen.

6. Core Insight & Analyst's Perspective

Kernaussage: Das 3PC-Protokoll ist ein cleverer, pragmatischer Hack, der eine grundlegende Einschränkung der Kryptographie – die Einweg-Eigenschaft von Hash-Funktionen – in ein Datenschutzmerkmal verwandelt. Es erkennt an, dass es beim Knacken von Passwörtern nicht darum geht, die Prozess aber um das zu verbergen Ziel und das Ergebnis innerhalb des inhärenten Rauschens des Prozesses. Es geht hier weniger um "unbrechbare" Kryptografie, sondern vielmehr um strategische Informationsverschleierung, ähnlich dem Prinzip, wie Mixnetzwerke wie Tor den Ursprung einer Nachricht in der Menge verbergen.

Logischer Ablauf: Die Logik ist schlüssig, beruht jedoch auf einer kritischen, oft übersehenen Annahme: der Fähigkeit, perfekt ununterscheidbare Köder zu erzeugen. Wenn der Server echte Hashes statistisch von Ködern unterscheiden kann (z.B. basierend auf der Häufigkeit in früheren Datenschutzverletzungen oder Mustern bei der Hash-Erzeugung), bricht das $k$-Anonymitätsmodell zusammen. Die Erweiterung der Prädikatsverschlüsselung auf Hash-Funktionen in der Arbeit ist neuartig, aber die reale Sicherheit hängt mehr von der Qualität des Ködererzeugungsalgorithmus ab als von der Prädikatfunktion selbst.

Strengths & Flaws: Seine Stärke liegt in der direkten Anwendbarkeit auf eine echte, unterversorgte Nische (datenschutzbewusste Pentester) und seinem relativ geringen kryptografischen Overhead für den Client. Ein großer Nachteil, wie bei vielen datenschutzbewahrenden Systemen, ist das trust-but-verify Paradox. Der Kunde muss dem Server vertrauen, dass er das Protokoll korrekt ausführt und den Prozess nicht manipuliert (z.B. durch Protokollierung von Zwischenzuständen zur Korrelation von Zeitabläufen). Im Gegensatz zu fortschrittlichen kryptografischen Protokollen wie Fully Homomorphic Encryption (FHE), die eine stärkere theoretische Garantie bieten, aber unpraktisch langsam sind (wie in frühen Implementierungen wie Gentrys bahnbrechender Arbeit zu sehen), tauscht 3PC absolute kryptografische Sicherheit gegen praktische Effizienz ein. Dies ist ein legitimer technischer Kompromiss, der jedoch klar kommuniziert werden muss.

Umsetzbare Erkenntnisse: Für Sicherheitsteams ist dieses Protokoll ein praktikables Werkzeug für sichere Passwortüberprüfungen, insbesondere wenn Compliance-Vorschriften (wie die DSGVO) die Weitergabe sensibler Hashwerte einschränken. Der unmittelbare nächste Schritt ist die Implementierung und Überprüfung des Moduls zur Generierung von Ködern. Für Forscher besteht die nächste Herausforderung darin, das Protokoll gegen aktive Serverangriffe abzuhärten und es mit anderen Privacy-Enhancing Technologies (PETs) zu integrieren. Es geht in der Zukunft nicht nur darum, das Knacken privat zu halten, sondern darum, eine Reihe von datenschutzbewahrenden Sicherheitsoperationen aufzubauen, ähnlich der Entwicklung von einfacher Verschlüsselung zu Zero-Knowledge-Beweisen in Authentifizierungsprotokollen. 3PC ist ein vielversprechender erster Schritt in diese Richtung für die offensive Sicherheit.

7. Future Applications & Research Directions

  • Compliance-gesteuerte Sicherheitsaudits: Ermöglicht es regulierten Branchen (Finanzen, Gesundheitswesen), strenge Passwortstärketests über Mitarbeiterkonten hinweg durchzuführen, ohne jemals Passwort-Hashes preiszugeben – selbst nicht gegenüber internen Audit-Teams – und unterstützt so die Einhaltung von GDPR/CCPA.
  • Federated Hash Analysis: Mehrere Organisationen könnten gemeinsam zu einer Entschlüsselungsaktion gegen ein Passwort-Leak eines gemeinsamen Bedrohungsakteurs (z. B. einer Ransomware-Gruppe) beitragen, ohne dass ein Teilnehmer seine eigenen internen Hashes preisgibt oder die der anderen einsehen kann.
  • Integration mit Password Breach Alerting Services: Benutzer könnten einen aus ihren Passwort-Hashes abgeleiteten Anonymitätssatz an einen Dienst wie "Have I Been Pwned" übermitteln, ohne den eigentlichen Hash preiszugeben, und so die Privatsphäre bei der Überprüfung auf Datenlecks verbessern.
  • Forschungsrichtung - Post-Quanten-Resilienz: Untersuchung der Sicherheit des Protokolls in einem Post-Quanten-Kontext. Während Hash-Funktionen selbst quantenresistent sein können, müssen die Mechanismen zur Erzeugung von Ködern und die Prädikatfunktionen im Hinblick auf Quanten-Angreifermodelle analysiert werden.
  • Forschungsrichtung - Aktive Angreifermodelle: Die Erweiterung des Sicherheitsmodells, um aktiv böswillige Server zu berücksichtigen, die vom Protokoll abweichen (z. B. durch Einführung von Seitenkanälen), ist für die praktische Anwendung von entscheidender Bedeutung.

8. References

  1. Bonneau, J., Herley, C., van Oorschot, P. C., & Stajano, F. (2012). The quest to replace passwords: A framework for comparative evaluation of web authentication schemes. IEEE Symposium on Security and Privacy.
  2. FIDO Alliance. (2022). FIDO: Die Zukunft schneller, sicherer, passwortloser Anmeldungen. https://fidoalliance.org/
  3. Gentry, C. (2009). Ein vollständig homomorphes Verschlüsselungsschema (Doktorarbeit, Stanford University). (Zum Vergleich von Techniken zur Wahrung der Privatsphäre in der Datenverarbeitung).
  4. NIST. (2020). Digital Identity Guidelines (NIST Special Publication 800-63B).
  5. Weir, M., Aggarwal, S., de Medeiros, B., & Glodek, B. (2009). Password cracking using probabilistic context-free grammars. IEEE Symposium on Security and Privacy.
  6. Zhao, F., & Halderman, J. A. (2019). Messung der Auswirkung der Passwortstärke auf RatenangriffeUSENIX Security Symposium.