Unterstützung der neuesten Version des Privacy-Pass-Protokolls

Bei Cloudflare unterstützen und entwickeln wir Datenschutztechnologien, von denen alle Internetnutzer profitieren. Im November 2017 haben wir die serverseitige Unterstützung für das Privacy-Pass-Protokoll bekanntgegeben. Diese Entwicklung erfolgte in Zusammenarbeit mit der akademischen Community. Einfach ausgedrückt, kann ein Client mit Privacy Pass seine Vertrauenswürdigkeit nachweisen, ohne offenzulegen, wo und wann dieser Beweis erbracht wurde. Ziel des Protokolls ist letztlich, dass jeder Nutzer beweisen kann, dass ein Server ihm vertraut, ohne dass der Server den Nutzer über den zugewiesenen Vertrauensbeweis zurückverfolgen kann.

Technisch gesehen funktioniert das so: Privacy-Pass-Clients bekommen Bestätigungstoken von einem Server, die dann später eingelöst werden können. Diese Token werden zur Verfügung gestellt, wenn ein Server den Client als vertrauenswürdig erachtet. Das kann zum Beispiel der Fall sein, wenn er sich bei einem Dienst angemeldet oder bestimmte Merkmale nachgewiesen hat. Die eingelösten Token können kryptographisch nicht mit der ursprünglich vom Server bereitgestellten Bestätigung verknüpft werden. Sie verraten also nichts über den Client.

Für den Privacy Pass kann auf einem Client eine Open-Source-Browsererweiterung installiert werden, die es für Chrome und Firefox gibt. Weltweit wurde der Privacy Pass schon über 150.000 Mal heruntergeladen, davon etwa 130.000 Mal die Chrome-Version und über 20.000 Mal die Firefox-Version. Die Erweiterung wird von Cloudflare unterstützt, um Websites für Nutzer besser zugänglich zu machen. Sie ergänzt frühere Entwicklungen, zum Beispiel Cloudflares Onion-Dienste für bessere Zugänglichkeit für Nutzer mit dem Tor-Browser.

Die erste Veröffentlichung liegt fast zwei Jahre zurück. Danach folgte eine Forschungspublikation, die auf dem Privacy Enhancing Technologies Symposium 2018 vorgestellt wurde (und dort den Best Student Paper Award erhielt). Seitdem arbeitet Cloudflare mit der Community daran, den Privacy Pass auf der Grundlage des ursprünglichen Designs zu verbessern. Wir werden darüber sprechen, welche Arbeit wir neben dem eigentlichen Protokoll in die Weiterentwicklung der vorhandenen Implementierungen gesteckt haben.

Unterstützung für die Browsererweiterung Privacy Pass v2.0:

• Einfachere Workflow-Konfiguration.

• Integration eines neuen Dienstleisters (hCaptcha).

• Konformität mit dem Hash-to-Curve-Entwurf.

• Möglichkeit der Schlüsselrotation außerhalb der Erweiterungsversion.

• Verfügbar in Chrome und Firefox (funktioniert mit den neuesten Browser-Versionen am besten).

Einführung eines neuen Server-Backends auf der Plattform Cloudflare Workers:

• Ausführung kryptografischer Operationen mit der internen V8-Engine.

• Bereitstellung einer öffentlichen API zur Einlösung der Token für Cloudflare Privacy Pass v2.0.

• Verfügbar über POST-Anfragen an https://privacypass.cloudflare.com/api/redeem. Für Anwendungsbeispiele siehe Dokumentation.

• Nur kompatibel mit der Version 2.0 der Erweiterung (prüfen Sie, ob Sie das Update haben!).

Standardisierung:

• Weiterentwicklung des Entwurfs für oblivious pseudorandom functions (OPRFs, „vergessliche Pseudozufallsfunktionen“) in Prime-Order-Gruppen mit CFRG@IRTF.

• Neuer Entwurf der Spezifikation des Privacy-Pass-Protokolls.

Seit der letzten Version haben wir an einer Reihe neuer Funktionen gearbeitet. Heute können wir stolz bekanntgeben, dass Version 2.0 der Erweiterung unterstützt wird – das erste Update seit der ursprünglichen Version. Die Erweiterung ist weiterhin für Chrome und Firefoxverfügbar. Möglicherweise müssen Sie die Version 2.0 manuell aus dem Store herunterladen, wenn Sie die automatischen Updates in Ihrem Browser deaktiviert haben.

Die Erweiterung wird weiterhin aktiv entwickelt und die Unterstützung ist immer noch in der Beta-Phase. Dies wird vorerst auch so bleiben, denn der Entwurf der Protokollspezifikation wird in Zusammenarbeit mit der Community fortgeschrieben.

Die Client-Implementierung nutzt die WebRequest API zur Suche nach bestimmten Typen von HTTP-Anfragen. Solche Anfragen werden umgeschrieben und um einige kryptografische Daten ergänzt, die für das Privacy-Pass-Protokoll erforderlich sind. Dadurch können Privacy-Pass-Anbieter, die diese Daten erhalten, den Zugriff für den Nutzer autorisieren.

Nehmen wir an, ein Nutzer erhält Privacy-Pass-Token für einige Sicherheitsprüfungen auf dem Server. Diese Token werden von der Browsererweiterung gespeichert, und jede zukünftige Anfrage, für die eine ähnliche Sicherheitsfreigabe notwendig ist, kann mit einen zusätzlichen HTTP-Header mit einem gespeicherten Token ergänzt werden. Der Server kann dann anhand des Client-Tokens überprüfen, ob der Client die richtige Berechtigung besitzt.

Cloudflare unterstützt zwar einen bestimmten Typ von Anfrageabläufen, man kann jedoch unmöglich erwarten, dass sich verschiedene Dienstanbieter genau an die gleichen Interaktionsmerkmale halten. Eine der wichtigsten Änderungen in der Erweiterungsversion 2.0 war eine technische Änderung dahingehend, dass nun eine zentrale Konfigurationsdatei verwendet wird. Die Konfiguration ist im Quellcode der Erweiterung spezifiziert. Mit ihr können Browsereigenschaften, die Privacy-Pass-Aktionen auslösen, einfacher modifiziert werden. So können neue, völlig unterschiedliche Anfrageabläufe aufgenommen werden. Dazu wird die Konfiguration für einen neuen Anbieter einfach geklont und angepasst.

Um zu zeigen, dass solche Integrationen jetzt auch mit anderen Diensten als Cloudflare möglich sind, wird bald eine neue Erweiterungsversion ausgeliefert, die vom CAPTCHA-Anbieter hCaptcha unterstützt wird. Nutzer, die von hCaptcha bereitgestellte Aufgaben lösen, bekommen private Token, die auf Websites anderer hCaptcha-Kunden eingelöst werden können.

„Schwerpunkt bei hCaptcha ist die Privatsphäre der Nutzer. Dass wir Privacy Pass unterstützen, ist für uns in diesem Bereich eine natürliche Ergänzung. Wir freuen uns darauf, es in Zusammenarbeit mit Cloudflare und anderen auf breiter Basis als Standard zu etablieren, und prüfen derzeit weitere Anwendungsmöglichkeiten. Es war relativ einfach, Privacy Pass in unserem weltweit verteilten Dienst zu implementieren. Die gemeinsame Arbeit mit dem Cloudflare-Team an der Verbesserung der Open-Source-Browsererweiterung für Chrome hat uns Freude gemacht, und unsere Nutzer werden davon profitieren.“

— Eli-Shaoul Khedouri, Gründer von hCaptcha

Die Integration von hCaptcha in die Privacy-Pass-Browsererweiterung dient als Proof-of-Concept für weitere neue Dienste und deren Unterstützung. Neue Anbieter, die ebenfalls eine Integration in die Privacy-Pass-Browsererweiterung anstreben, können hierfür einfach ein Pull Request an das Open-Source-Repository richten.

Bei der Freigabe der Erweiterungsversion 1.0 waren bestimmte Funktionen noch nicht implementiert. Dazu gehörte die ordnungsgemäße Validierung des Zero-Knowledge-Beweises zur Feststellung, ob der Server immer denselben festgelegten Schlüssel verwendet. In der Version 2.0 ist diese Funktionalität enthalten. Dadurch wird in überprüfbarer Form verhindert, dass ein böswilliger Server Nutzer durch Einsatz verschiedener Schlüssel für jede Anfrage deanonymisieren kann.

Die für Privacy Pass erforderlichen kryptografischen Operationen werden mit elliptischer Kurvenkryptografie (elliptic curve cryptography, ECC) ausgeführt. In der Erweiterung wird derzeit die Kurve NIST P-256 eingesetzt, für die wir noch einige Optimierungen aufgenommen haben. Erstens können wir dadurch Kurvenpunkte einer Ellipse in komprimierten und unkomprimierten Datenformaten speichern. Der Speicherbedarf des Browsers kann dadurch um 50 % reduziert und auch die Serverantworten können verkleinert werden.

Zweitens wurde die Hashwertberechnung auf der P-256-Kurve mit der sogenannten „Simplified Shallue-van de Woestijne-Ulas“-Methode (SSWU) eingebaut. Sie ist in einem noch laufenden Entwurf (https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-03) zur Standardisierung von Codierungen für die Hashwertberechnung auf elliptischen Kurven spezifiziert. Die Implementierung ist konform mit der Spezifikation der Chiffriersuite „P256-SHA256-SSWU-“ in diesem Entwurf.

Diese Änderungen haben gleich zwei Vorteile. Erstens ist die Spezifikation der P-256-Hashwertberechnung auf der Kurve konform mit der Spezifikation im Entwurf. Zweitens sind durch diese Chiffriersuite probabilistische Methoden wie Hash-and-Increment nicht mehr erforderlich. Die Hash-and-Increment-Methode ist mit einer nicht nur geringfügigen Fehlerwahrscheinlichkeit verbunden, und die Laufzeit ist stark von der versteckten Clienteingabe abhängig. Es ist zwar nicht klar, wie man Timing-Angriffsvektoren derzeit missbrauchen könnte, aber durch die SSWU-Methode wird die Implementierung weniger angreifbar und die Clienteingabe ist nicht so leicht zu ermitteln.

Wie oben erwähnt, muss überprüft werden, ob der Server immer denselben Schlüssel verwendet, damit die Privatsphäre des Clients gewährleistet werden kann. Dadurch wird sichergestellt, dass der Server die Nutzerbasis nicht aufteilen und die Privatsphäre des Clients beeinträchtigen kann, indem er für jeden Client, mit dem er interagiert, unterschiedliche geheime Schlüssel verwendet. Der Server gibt an einem für den Client zugänglichen Ort ein sogenanntes Commitment für einen öffentlichen Schlüssel bekannt und garantiert so, dass er immer denselben Schlüssel verwendet.

Jedes Mal, wenn der Server Privacy-Pass-Token an den Client ausgibt, erzeugt er auch einen Zero-Knowledge-Beweis dafür, dass er diese Token mit dem richtigen Schlüssel erstellt hat.

Bevor die Erweiterung Token speichert, überprüft sie zunächst den Beweis anhand des bekannten Schlüssel-Commitments. Zuvor wurden diese Commitments direkt im Quellcode der Erweiterung gespeichert. Das führte dazu, dass eine neue Erweiterungsversion herausgegeben werden musste, wenn der Schlüssel eines Servers rotiert werden sollte, eine unnötige Komplikation. Die Erweiterung wurde so geändert, dass die Commitments an einem vertrauenswürdigen Speicherort gespeichert werden, auf den der Client zugreifen kann, wenn er die Serverantwort überprüfen muss. Derzeit handelt es sich bei diesem Speicherort um ein separates GitHub-Repository für Privacy Pass. Für Interessierte haben wir eine ausführlichere Beschreibung des neuen Commitment-Formats in Anhang A am Ende dieses Beitrags bereitgestellt.

Bisher haben wir uns auf clientseitige Updates konzentriert. Im Rahmen der Erweiterungsversion 2.0 führen wir einige wichtige Änderungen an der serverseitigen Unterstützung durch, die Cloudflare verwendet. Für Version 1.0 haben wir eine Go-Implementierung des Servers verwendet. In Version 2.0 führen wir eine neue Serverimplementierung ein, die in der Plattform Cloudflare Workers ausgeführt wird. Diese Serverimplementierung ist nur mit v2.0-Releases des Privacy Pass kompatibel, sodass Sie möglicherweise Ihre Erweiterung aktualisieren müssen, wenn Sie automatische Updates in Ihrem Browser deaktiviert haben.

Unser Server wird unter https://privacypass.cloudflare.com ausgeführt werden, und alle Privacy-Pass-Anfragen an die Cloudflare-Edge werden von Worker-Skripts verarbeitet, die auf dieser Domain ausgeführt werden. Unsere Implementierung wurde in JavaScript neu geschrieben, wobei die kryptografischen Operationen in der V8-Engine ausgeführt werden, auf der auch Cloudflare Workers betrieben wird. Dies bedeutet, dass wir hocheffiziente und zeitlich konstante kryptografische Operationen durchführen können. Darüber hinaus profitieren wir von der verbesserten Leistung durch die Ausführung unseres Codes in der Workers-Plattform, also so nah wie möglich am Nutzer.

Nun fragen Sie sich vielleicht, wie wir es schaffen, kryptografische Operationen in Cloudflare Workers zu implementieren. Derzeit werden kryptografische Vorgänge in der Workers-Plattform über die WebCrypto-API unterstützt. Mit dieser API kann man Berechnungen für kryptografisches Hashing ebenso durchführen wie kompliziertere Vorgänge, etwa ECDSA-Signaturen.

Wie wir unten erläutern, werden im Privacy-Pass-Protokoll die wichtigsten kryptografischen Operationen von einem Protokoll ausgeführt, das als überprüfbare vergessliche Pseudozufallsfunktion (verifiable oblivious pseudorandom function, VOPRF) bezeichnet wird. Mit so einem Protokoll kann ein Client von einem Server berechnete Funktionsausgaben erhalten, ohne dem Server die eigentliche Eingabe zu verraten. Dass es „überprüfbar“ ist, bedeutet, dass der Server außerdem (in einer öffentlich überprüfbaren Weise) nachweisen muss, dass die an den Nutzer übergebene Berechnung korrekt ist. Eine solche Funktion ist pseudozufällig, denn die Serverausgabe ist nicht von einer zufälligen Folge von Byte zu unterscheiden.

Für die VOPRF-Funktionalität muss ein Server ECC-Operationen auf niedriger Ebene ausführen, die derzeit nicht in der WebCrypto-API verfügbar gemacht werden. Wir haben die Möglichkeiten abgewogen, diese Bedingung zu umgehen. Zuerst haben wir versucht, die WebCrypto-API in einer nicht standardmäßigen Weise zu verwenden. Dazu haben wir EC-Diffie-Hellman-Schlüsselaustausch als Methode für die benötigte skalare Multiplikation verwendet. Wir haben auch versucht, alle Operationen in reinem JavaScript zu implementieren. Leider waren beide Methoden unbefriedigend. Entweder hätten sie eine Integration in große externe Kryptografiebibliotheken bedeutet oder sie wären für eine performante Internetumgebung viel zu langsam.

Letztendlich haben wir uns für eine Lösung entschieden, bei der die Funktionen für Privacy Pass in die interne WebCrypto-Schnittstelle der Cloudflare-V8-Javascript-Engine aufgenommen werden.. Dieser Algorithmus imitiert die Sign/Verify-Schnittstelle, die von Signaturalgorithmen wie ECDSA bereitgestellt wird. Kurz gesagt, wir verwenden die Funktion sign(), um Privacy-Pass-Token an den Client auszugeben. Mit verify() wiederum kann der Server Daten überprüfen, die vom Client eingelöst werden. Diese Funktionen werden direkt in der V8-Schicht implementiert und sind daher wesentlich leistungsfähiger und sicherer (z. B. zeitlich konstant) als reines JavaScript.

Die WebCrypto-Schnittstelle in Privacy Pass ist derzeit nicht für die öffentliche Nutzung verfügbar. Wenn sich herausstellt, dass es genügend Interesse an diesem zusätzlichen Algorithmus in der Workers-Plattform gibt, machen wir ihn möglicherweise öffentlich.

In jüngster Zeit haben sich VOPRFs als sehr nützliches Primitiv für viele kryptografische Werkzeuge erwiesen. Neben dem Privacy Pass sind sie auch für die Erstellung von mit Passwort authentifizierten Schlüsselaustauschprotokollen wie OPAQUE unerlässlich. Sie wurden auch bei der Entwicklung privater Schnittmengen, passwortgeschützter Protokolle mit gemeinsamem Schlüssel und datenschutzerhaltender Zugriffskontrolle für private Datenspeicherung verwendet.

Den Server in Cloudflare Workers zu schreiben bedeutet, dass wir die serverseitige Unterstützung für Privacy Pass auf einer öffentlichen Domain bereitstellen! Wir geben Token zwar nur an Clients aus, wenn wir sicher sind, dass wir ihnen vertrauen können, aber mit unserer öffentlichen Einlöse-API kann jeder diese Token bei https://privacypass.cloudflare.com/api/redeem einlösen. Wenn wir die serverseitige Komponente weltweit eingeführt haben, können Sie mit dieser API Privacy-Pass-Token von Cloudflare unabhängig von der Browsererweiterung überprüfen.

Jeder Dienst kann also von Cloudflare ausgestellte Privacy-Pass-Token von einem Client akzeptieren und sie dann mit der Einlöse-API von Cloudflare überprüfen. Mit dem von der API zurückgegebenen Ergebnis können externe Dienste überprüfen, ob Cloudflare den Nutzer in der Vergangenheit autorisiert hat.

Wir glauben, dass andere Dienstanbieter davon profitieren werden, denn sie können die Autorisierungsbestätigung von Cloudflare in ihren eigenen Entscheidungsprozessen nutzen, ohne irgendwelche Kompromisse bei der Privatsphäre des Clients zu machen. Wir hoffen, dass dieses Ökosystem weiter wachsen wird und mehr Dienste mit eigenen öffentlichen Einlöse-APIs entstehen. Wenn die Vielfalt bei den Ausstellern zunimmt, nimmt auch der Nutzen dieser Bestätigungen zu.

Dadurch, dass unser Server auf einer öffentlichen Domain läuft, sind wir praktisch selbst Kunde des Cloudflare-Workers-Produkts. Somit können auch wir Workers KV zum Schutz vor böswilligen Clients nutzen. Insbesondere muss ein Server überprüfen, ob ein Client während der Einlösungsphase ein Token wiederverwendet. Die Performance, die Workers KV bei der Analyse von Lesevorgängen bietet, macht es zur ersten Wahl für den globalen Schutz vor Doppelnutzung.

Wenn Sie die öffentliche Einlöse-API verwenden möchten, finden Sie unsere Dokumentation dafür unter https://privacypass.github.io/api-redeem. In Anhang B am Ende dieses Beitrags finden Sie außerdem einige Beispiele für Anfragen und Antworten.

Parallel zu unseren jüngsten Entwicklungsarbeiten zur Unterstützung des Privacy Pass haben wir mit gemeinsam mit der Community versucht, die zugrundeliegende VOPRF-Funktionalität und auch das Protokoll selbst zu standardisieren. Die Standardisierung für vergessliche Pseudozufallsfunktionen (OPRFs) ist nun seit über einem Jahr im Gang, aber die jüngsten Bemühungen, das Privacy-Pass-Protokoll zu standardisieren, gehen auf ganz neue Anwendungen zurück, die in den letzten Monaten entstanden sind.

Die Standardisierung von Protokollen und Funktionen ist eine wichtige Möglichkeit, interoperable, sichere und leistungsstarke Schnittstellen für die Ausführung von Protokollen im Internet zu schaffen. So können Entwickler leichter eigene Implementierungen dieser komplexen Funktionalität schreiben. Zu diesem Prozess gehören auch hilfreiche Peer Reviews von Experten in der Community, durch die potenzielle Sicherheitsrisiken besser zutage treten, die bei jeder Implementierung entschärft werden sollten. Außerdem hat er den Vorteil, dass man sich auf die zuverlässigsten, skalierbarsten und leistungsfähigsten Protokollentwürfe für alle möglichen Anwendungen einigen kann.

Vergessliche Pseudozufallsfunktionen (oblivious pseudorandom functions, OPRFs) sind eine Verallgemeinerung von VOPRFs, bei denen der Server nicht nachweisen muss, dass er die Funktionalität ordnungsgemäß ausgewertet hat. Seit Juli 2019 arbeiten wir gemeinsam mit der Crypto Forum Research Group (CFRG) der Internet Research Task Force (IRTF) an einem Entwurf zur Standardisierung eines OPRF-Protokolls, das in Prime-Order-Gruppen arbeitet. Dies ist eine Verallgemeinerung der Fassung mit elliptischen Kurven. Es ist die gleiche VOPRF-Konstruktion, die ursprünglich durch das Privacy-Pass-Protokoll spezifiziert wurde. Sie beruht vor allem auf dem ursprünglichen Protokollentwurf aus der Abhandlung von Jarecki, Kiayias und Krawczyk.

Eine unserer jüngsten Änderungen des Entwurfs besteht darin, den Schlüssel zu vergrößern, den wir für die Durchführung von OPRF-Operationen auf der Serverseite benutzen möchten. Untersuchungen legen nahe, dass man spezifische Abfragen erstellen kann, durch die kleine Anteile des Schlüssels „durchsickern“ können. Bei Schlüsseln mit nur 128 Bit Sicherheit kann dies ein Problem sein, denn wenn zu viele Bits durchsickern, nimmt die Sicherheit auf ein derzeit nicht mehr akzeptables Niveau ab. Um dem entgegenzuwirken, haben wir die Mindestschlüsselgröße effektiv auf 192 Bit erhöht. Dadurch kann dieses Durchsickern nicht mit praktikablen Methoden zu einem Angriffsvektor gemacht werden. Wir besprechen diese Angriffe später ausführlicher, wenn es um unsere zukünftigen VOPRF-Entwicklungspläne geht.

Die Anwendung, die wir bei der ursprünglichen Privacy-Pass-Unterstützung demonstriert haben, war immer als Proof-of-Concept für das Protokoll gedacht. In den letzten Monaten sind viele neue Möglichkeiten entstanden, die weit über das hinausgehen, was bisher angedacht war.

So wurde zum Beispiel die von der Web Incubator Community Group entwickelte Trust Token API als Schnittstelle für die Verwendung von Privacy Pass vorgeschlagen. Mit diesen Anwendungen können Drittanbieter bei einer Reihe zentraler Aussteller überprüfen, ob ein Nutzer eine Vertrauensbestätigung erhalten hat. So kann der Anbieter die Ehrlichkeit eines Clients beurteilen, ohne ein Verhaltensprofil mit der Identität des Nutzers verknüpfen zu müssen. Ziel ist es, betrügerische Aktivitäten von Nutzern zu verhindern, denen die Gruppe der zentralen Aussteller nicht vertraut. Mit ähnlichen Einlöse-APIs, wie wir sie vorgestellt haben, könnte man Vertrauensbestätigungen bei zentralen Ausstellern überprüfen.

In einer separaten Arbeit von Facebook wird eine ähnliche Anwendung zur Verhinderung betrügerischen Verhaltens vorgestellt, die auch mit dem Privacy-Pass-Protokoll kompatibel sein könnte. Außerdem sind weitere Anwendungen in den Bereichen Zugang zu privatem Speicher und Sicherheits- und Datenschutzmodelle in Werbebestätigungen entstanden.

Ein neuer Entwurf

Unter Berücksichtigung der oben genannten Anwendungen haben wir vor Kurzem mit der Gemeinschaftsarbeit an einem neuen IETF-Entwurf begonnen, in dem insbesondere die erforderliche Funktionalität des Privacy-Pass-Protokolls als Ganzes festgelegt wird. Unser Ziel ist es, zusammen mit Partnern aus der erweiterten Branche und der akademischen Gemeinschaft eine funktionierende Spezifikation des Privacy-Pass-Protokolls zu entwickeln. Wir hoffen, so ein Grundlagenprotokoll entwerfen zu können, das dann als kryptografisches Primitiv in breiteren Anwendungen verwendet werden kann, für die eine Art einfache Autorisierung benötigt wird. Wir haben vor, die erste Version dieses Entwurfs im nächsten Monat beim IETF-Meeting 106 in Singapur vorzulegen.

Der Entwurf befindet sich noch am Anfang seiner Entwicklung und wir suchen aktiv nach Personen, die diese Protokollspezifikation mitgestalten möchten. Wir sind für jede Hilfe bei diesem Prozess dankbar. Im GitHub-Repository finden Sie die aktuelle Version des Dokuments.

Während wir aktiv an einer Reihe verschiedener Wege arbeiten, sind die zukünftigen Richtungen für das Projekt noch offen. Wir glauben, dass es viele Anwendungen gibt, die wir noch nicht in Betracht gezogen haben, und wir sind gespannt, wo das Protokoll in Zukunft verwendet wird. Hier einige weitere Ideen für neuartige Anwendungen und Sicherheitseigenschaften, die wir für die Zukunft für sinnvoll halten.

Eine VOPRF hat den Nachteil, dass Einlösetoken nur vom ursprünglichen Ausgabeserver überprüft werden können. Wenn wir ein Primitiv als Grundlage verwenden würden, mit dem Einlösetoken öffentlich verifiziert werden könnten, konnte jeder überprüfen, ob das jeweilige Token vom ausstellenden Server stammt. Ein solches Protokoll könnte zusätzlich zu sogenannten blinden Signaturschemata wie Blind RSA entwickelt werden. Leider gibt es Leistungs- und Sicherheitsbedenken bei der Verwendung blinder Signaturschemata in einer Browserumgebung. Vorhandene Schemata (insbesondere RSA-basierte Varianten) erfordern kryptografische Berechnungen, die viel schwergewichtiger sind als die Konstruktion in unserem VOPRF-Protokoll.

Die bisherigen VOPRF-Konstrukte existieren in Prä-Quanten-Umgebungen, in der Regel basierend auf dem Schwierigkeitsgrad bekannter Probleme in Gruppenumgebungen wie der Annahme zum diskreten Logarithmus. Es sind keine VOPRF-Konstrukte bekannt, die Sicherheit gegen Gegner bieten, die Algorithmen auf Quantencomputern ausführen können. Dies bedeutet, dass das Privacy-Pass-Protokoll nur gegen Gegner als sicher gelten kann, die klassische Hardware einsetzen.

Jüngste Entwicklungen deuten darauf hin, dass Quantencomputer früher kommen könnten, als bisher angenommen. Daher glauben wir, dass es für uns und die ganze Community sehr wichtig ist, praktische Post-Quanten-Alternativen für unser aktuelles kryptografisches Toolkit zu entwickeln. In diesem Fall wäre die Entwicklung performanter Post-Quanten-Alternativen für VOPRF-Konstrukte ein wichtiger theoretischer Fortschritt. So bekämen wir ein Privacy-Pass-Protokoll, das auch in einer Post-Quanten-Welt eine die Privatsphäre schützende Autorisierung bieten kann.

Wir haben bereits erwähnt, dass VOPRFs (oder einfach OPRFs) anfällig sind, wenn schon geringe Schlüsselanteile durchsickern. Hier beschreiben wir in aller Kürze die tatsächlichen Angriffe und unsere Pläne zur Implementierung von Chiffriersuiten mit höherer Sicherheit und weniger Lecks.

Insbesondere können böswillige Clients durch Interaktion mit einer VOPRF eine sogenannte Diffie-Hellman-Stichprobe der Stärke q (q-sDH) erzeugen. Solche Stichproben werden in mathematischen Gruppen erstellt (normalerweise in der elliptischen Kurvenumgebung). Für jede Gruppe gibt es ein öffentliches Element g, das für alle Operationen des Diffie-Hellman-Typs von zentraler Bedeutung ist, außerdem den Serverschlüssel K, der normalerweise nur als zufällig generierte Zahl aus dieser Gruppe interpretiert wird. Eine q-sDH-Stichprobe hat folgende Form:

( g, g^K, g^(K^2), … , g^(K^q) )

( g, g^K, g^(K^2), … , g^(K^q) )

und verlangt vom böswilligen Gegner, ein Elementepaar zu erstellen, das (g^(1/(s+K)),s) entspricht. Ein Client könnte im VOPRF-Protokoll dadurch eine q-SDH-Stichprobe erstellen, dass er das Ergebnis der vorherigen VOPRF-Berechnung einfach an den Server zurücksendet.

Dieses Problem gilt zwar als schwer zu knacken, aber aus mehreren vergangenen Arbeiten geht hervor, dass das Problem etwas einfacher lösbar ist, als man aufgrund der Größe der Gruppe annehmen würde (siehe z. B. hier und hier). Konkret ausgedrückt kann die von der Gruppe implizierte Bitsicherheit um bis zu 2(q) Bit reduziert werden. Das ist zwar nicht sofort fatal, auch nicht für Gruppen mit 128 Bit Sicherheit, aber es kann zu einem Verlust an Sicherheit führen. Dieses Verfahren ist also nicht mehr zukunftssicher. Bei Gruppen, die VOPRF-Funktionalität bereitstellen und mithilfe einer elliptischen Kurve wie P-256 oder Curve25519 instanziiert werden, fällt die Sicherheit also geringer aus als eigentlich garantiert.

Vor diesem Hintergrund haben wir jüngst beschlossen, standardmäßig nur noch Chiffriersuiten mit mehr als 128 Bit Sicherheit für die OPRF-Nutzung zu empfehlen. Curve448 bietet beispielsweise 192 Bit Sicherheit. Für einen Angriff, der die Sicherheit auf weniger als 128 Bit reduziert, müssten vom Client 2^(68) OPRF-Abfragen ausgeführt werden. Das ist eine erhebliche Zugangsbarriere für jeden Angreifer, deshalb betrachten wir diese Chiffriersuiten für die Instanziierung der OPRF-Funktionalität als sicher.

In naher Zukunft müssen die in unserer Unterstützung der Privacy-Pass-Browsererweiterung verwendeten Chiffriersuiten auf den Stand der Empfehlungen des aktuellen VOPRF-Entwurfs gebracht werden. Wir hoffen, dass die Privacy-Pass-Implementierung durch einen stärker iterativen Freigabeprozess besser mit dem aktuellen Standardentwurf und seiner Weiterentwicklung während des Standardisierungsprozesses mithalten kann.

Sie können Version 2.0 der Privacy-Pass-Erweiterung jetzt in Chrome oder Firefox installieren.

Wenn Sie zur Entwicklung dieser Erweiterung beitragen möchten, können Sie dies auf GitHub tun. Sind Sie selbst Dienstanbieter und möchten serverseitige Unterstützung für die Erweiterung integrieren? Dann wären wir sehr daran interessiert, von Ihnen zu hören!

Wir werden bei der Standardisierung des Protokolls weiter mit der Community zusammenarbeiten. Die schon entwickelten und verfügbaren Anwendungen sind uns Motivation genug. Wir sind immer auf der Suche nach neuen Anwendungen, mit denen das Privacy-Pass-Ökosystem über seine aktuellen Grenzen hinaus ausgeweitet werden kann.

Hier einige zusätzliche Details zu den oben behandelten Themen.

Schlüssel-Commitments sind notwendig, damit der Server im Rahmen des Privacy-Pass-Protokolls beweisen kann, dass er ehrlich handelt. Die von Privacy Pass in der Version 2.0 verwendeten Commitments haben ein etwas anderes Format als in der vorherigen Version.

"2.00": {
  "H": "BPivZ+bqrAZzBHZtROY72/E4UGVKAanNoHL1Oteg25oTPRUkrYeVcYGfkOr425NzWOTLRfmB8cgnlUfAeN2Ikmg=",
  "expiry": "2020-01-11T10:29:10.658286752Z",
  "sig": "MEUCIQDu9xeF1q89bQuIMtGm0g8KS2srOPv+4hHjMWNVzJ92kAIgYrDKNkg3GRs9Jq5bkE/4mM7/QZInAVvwmIyg6lQZGE0="
}

Die Version des Serverschlüssels ist zunächst 2.00. Der Server muss den Client darüber informieren, welche Version er in der Antwort auf einen Client verwenden möchte, die ausgestellte Token enthält. Dies wird deshalb so gemacht, damit der Client zur Prüfung des Zero-Knowledge-Beweises vom Server immer die richtigen Commitments verwenden kann.

Der Wert des Attributs H ist das öffentliche Schlüssel-Commitment für den vom Server verwendeten geheimen Schlüssel. Dies ist, codiert in base64, ein elliptischer Kurvenpunkt der Form H=kG, wobei G der feste Generator der Kurve und k der geheime Schlüssel des Servers ist. Da man annimmt, dass das diskrete Logarithmusproblem schwer zu lösen ist, gilt es als schwierig, k von H abzuleiten. Der Wert des Attributs expiry ist ein Ablaufdatum für das verwendete Commitment. Der Wert des Attributs sig ist eine ECDSA-Signatur. Sie wird mit einem Langzeitsignaturschlüssel, der mit dem Server verknüpft ist, und über die Werte von H und expiry berechnet.

Wenn ein Client das Commitment abruft, überprüft er, ob es nicht abgelaufen ist und ob die Signatur mithilfe des entsprechenden Überprüfungsschlüssels bestätigt werden kann, der in die Konfiguration der Erweiterung eingebettet ist. Wenn diese Prüfungen erfolgreich sind, ruft er H ab und überprüft die vom Server gesendete Antwort mit der Ausstellung. Frühere Versionen dieser Commitments enthielten keine Signaturen, aber ab Version 2.0 werden diese Signaturen validiert.

Wenn ein Server den Schlüssel rotieren möchte, generiert er einfach einen neuen Schlüssel k2 und fügt ein neues Commitment für k2 mit einem neuen Bezeichner wie 2.01 an. Er kann k2 dann als geheimen Schlüssel für die VOPRF-Operationen verwenden, die er berechnen muss.

Die Einlöse-API ist über HTTPS verfügbar. Man sendet dazu POST-Anfragen an https://privacypass.cloudflare.com/api/redeem. Bei Anfragen an diesen Endpunkt müssen die Privacy-Pass-Daten mithilfe der JSON-RPC-2.0-Syntax im Hauptteil angegeben werden. Beispiel für eine solche Anfrage:

{
  "jsonrpc": "2.0",
  "method": "redeem",
  "params": {
    "data": [
      "lB2ZEtHOK/2auhOySKoxqiHWXYaFlAIbuoHQnlFz57A=",
      "EoSetsN0eVt6ztbLcqp4Gt634aV73SDPzezpku6ky5w=",
      "eyJjdXJ2ZSI6InAyNTYiLCJoYXNoIjoic2hhMjU2IiwibWV0aG9kIjoic3d1In0="
    ],
    "bindings": [
      "string1",
      "string2"
    ],
    "compressed":"false"
  },
  "id": 1
}

Erläuterung: params.data[0] sind die Client-Eingabedaten, die in der Ausstellungsphase zum Generieren eines Tokens verwendet werden; params.data[1] ist das HMAC-Tag, mit dem der Server eine Einlösung überprüft; params.data[2] ist ein JSON-Objekt, als Zeichenfolge codiert im base64-Format, das die vom Client verwendeten Hash-to-Curve-Parameter angibt. Das letzte Element des Arrays entspricht beispielsweise folgendem Objekt:

{
    curve: "p256",
    hash: "sha256",
    method: "swu",
}

Dieses Objekt gibt an, dass der Client die Kurve P-256 mit der Hashfunktion SHA-256 und die SSWU-Methode zum Hashing auf der Kurve verwendet hat. Dadurch kann der Server die Transaktion mit der richtigen Chiffriersuite überprüfen. Der Client muss die Einlöseanfrage an einige feste Informationen binden, die als mehrere Zeichenfolgen im Array params.bindings gespeichert werden. Beispielsweise könnte der Host-Header der HTTP-Anfrage und der verwendete HTTP-Pfad gesendet werden (dies wird in der Browsererweiterung für den Privacy Pass verwendet). params.compressed schließlich ist ein optionaler boolescher Wert (Standardeinstellung „false“), der angibt, ob das HMAC-Tag über komprimierte oder unkomprimierte Punktcodierungen berechnet wurde.

Die einzigen unterstützten Chiffriersuiten sind derzeit das obige Beispiel sowie das gleiche mit „method“ gleich „increment“ für die Hash-and-Increment-Methode des Hashings auf einer Kurve. Dies ist die ursprüngliche Methode, die in Version 1.0 des Privacy Pass verwendet wird; sie wird nur zur Abwärtskompatibilität unterstützt. Weitere Informationen finden Sie in der bereitgestellten Dokumentation.

Beispielantwort

Wenn eine Anfrage an die Einlöse-API gesendet und erfolgreich überprüft wurde, wird folgende Antwort zurückgegeben.

{
  "jsonrpc": "2.0",
  "result": "success",
  "id": 1
}

Wenn ein Fehler auftritt, sieht die Rückgabe ungefähr so aus:

{
  "jsonrpc": "2.0",
  "error": {
    "message": <error-message>,
    "code": <error-code>,
  },
  "id": 1
}

Die von uns bereitgestellten Fehlercodes werden als JSON-RPC-2.0-Codes angegeben. Die Fehlertypen, die wir verwenden, sind in der API-Dokumentation dokumentiert.