Chez Cloudflare, nous nous engageons à appuyer et à développer de nouvelles technologies de protection de la vie privée qui profitent à tous les utilisateurs d'Internet. En novembre 2017, nous avons annoncé la prise en charge côté serveur du protocole Privacy Pass, un travail réalisé en collaboration avec la communauté universitaire. En résumé, Privacy Pass permet aux clients de fournir une preuve de confiance sans révéler où et quand cette confiance a été fournie. Le protocole a donc pour but de permettre à quiconque de prouver qu'un serveur lui fait confiance, sans que ce serveur puisse pister l’utilisateur par le biais de la confiance qui lui a été accordée.

Techniquement, les clients de Privacy Pass reçoivent des jetons d'attestation de la part d'un serveur, qu'ils peuvent utiliser plus tard. Le client reçoit ces jetons lorsque le serveur estime que ce dernier est digne de confiance, par exemple après s'être connecté à un service ou s'il fait la preuve de certaines caractéristiques. Les jetons utilisés sont indissociables au niveau du chiffrement de l'attestation fournie initialement par le serveur, et ne révèlent donc rien sur le client.

Pour utiliser Privacy Pass, les clients peuvent installer une extension de navigateur open-source disponible sur Chrome et Firefox. Privacy Pass a été téléchargé plus de 150 000 fois dans le monde, dont environ 130 000 fois sur Chrome et plus de 20 000 fois sur Firefox. Cloudflare prend en charge cette extension pour faciliter l'accès des utilisateurs aux sites Web.  Cela vient en complément de travaux antérieurs, y compris le lancement des services oignon de Cloudflare contribuant à améliorer l'accessibilité pour les utilisateurs du navigateur Tor.

La publication initiale a eu lieu il y a près de deux ans, et elle a été suivie d'une publication de recherche présentée au Privacy Enhancing Technologies Symposium de 2018 (et y a remporté un Best Student Paper Award). Depuis, Cloudflare collabore avec la communauté dans son ensemble afin de poursuivre la conception initiale et d'améliorer Privacy Pass. Nous allons vous présenter le travail que nous avons accompli pour développer les applications existantes, en plus du protocole lui-même.

Quelles sont les nouveautés ?

Prise en charge de l'extension de navigateur Privacy Pass v2.0 :

• Configuration du workflow plus facile.

• Intégration avec un nouveau fournisseur de services (hCaptcha).

• Conformité avec l’avant-projet de hachage vers les courbes (hash to curve)

• Possibilité de renouveler les clés en dehors des sorties d'extension.

• Disponible sur Chrome et Firefox (fonctionne mieux avec des navigateurs à jour).

Déploiement d'un nouveau backend de serveur utilisant la plate-forme Cloudflare Workers :

• Opérations de chiffrement effectuées à l'aide d'un moteur V8 interne.

• Fournit l'API de conversion publique pour les jetons Cloudflare Privacy Pass v2.0.

• Disponible en envoyant des requêtes POST à https://privacypass.cloudflare.com/api/redeem. Consultez la documentation pour voir un exemple d’utilisation.

• Seulement compatible avec la version 2.0 de l'extension (vérifiez que vous avez effectué la mise à jour !).

Normalisation :

• La poursuite du développement d’un avant-projet de fonctions pseudo-aléatoires inconscientes (OPRF) dans les groupes d'ordre premier avec CFRG@IRTF.

• Nouveau projet préliminaire spécifiant le protocole Privacy Pass.

Version 2.0 de l’extension

Depuis la sortie, nous avons développé un certain nombre de nouvelles fonctionnalités. Aujourd'hui, nous vous annonçons avec grand plaisir la prise en charge de la version 2.0 de l'extension, la première mise à jour depuis la version originale. L'extension est toujours disponible surChrome et Firefox. Vous devrez peut-être télécharger la version 2.0 manuellement à partir du store si vous avez désactivé les mises à jour automatiques dans votre navigateur.

L'extension est toujours activement en cours de développement et nous considérons toujours que notre prise en charge est en phase bêta. Cela continuera à être le cas à mesure que le projet de spécification du protocole continuera d'être élaboré en collaboration avec toute la communauté.

La mise en œuvre pour les clients utilise l'API WebRequest pour rechercher certains types de requêtes HTTP. Lorsque ces requêtes sont repérées, elles sont réécrites pour inclure certaines données de chiffrement requises pour le protocole Privacy Pass. Cela permet aux distributeurs de Privacy Pass recevant ces données d'autoriser l'accès à l'utilisateur.

Par exemple, un utilisateur peut recevoir des jetons Privacy Pass pour avoir subi certains contrôles de sécurité du serveur. Ces jetons sont stockés par l'extension du navigateur, et toute requête future nécessitant une autorisation de sécurité similaire peut être modifiée pour ajouter un jeton stocké comme un en-tête HTTP supplémentaire. Le serveur peut alors vérifier le jeton client et s'assurer que le client dispose d'une autorisation adéquate pour poursuivre.

Bien que Cloudflare prenne en charge un type particulier de flux de requêtes, il ne faut pas s'attendre à ce que différents fournisseurs de services respectent tous exactement les mêmes caractéristiques d'interaction. L'un des changements les plus importants de la version 2.0 a été la réécriture technique permettant d'utiliser un fichier de configuration central. La configuration est définie dans le code source de l'extension et permet de modifier plus facilement les caractéristiques de navigation qui déclenchent les actions de Privacy Pass. Cela permet d'ajouter de nouveaux flux de requêtes complètement différents en clonant simplement et en adaptant la configuration pour de nouveaux fournisseurs.

Afin de prouver que ce type d'intégration est désormais possible avec d'autres services que Cloudflare, une nouvelle version de l'extension sera bientôt déployée avec la prise en charge du fournisseur CAPTCHA hCaptcha. Les utilisateurs qui résoudront des défis éphémères fournis par hCaptcha recevront des jetons de protection de la vie privée qui seront utilisables sur d'autres sites de clients hCaptcha.

« hCaptcha est axée sur la protection de la vie privée des utilisateurs, et la prise en charge de Privacy Pass est un prolongement naturel de notre travail dans ce domaine. Nous nous réjouissons de travailler avec Cloudflare et d'autres partenaires pour en faire une norme commune et largement adoptée, et nous étudions actuellement d'autres applications. L'ajout de Privacy Pass à notre service distribué dans le monde entier a été relativement simple, et nous avons eu plaisir à travailler avec l'équipe de Cloudflare pour améliorer l'extension open source pour le navigateur Chrome afin que nos utilisateurs puissent en profiter au maximum. »

— Eli-Shaoul Khedouri, fondateur de hCaptcha

Cette intégration de hCaptcha à l'extension de navigateur Privacy Pass fait office de preuve de concept établissant la prise en charge de nouveaux services. Tout nouveau fournisseur souhaitant intégrer l'extension de navigateur Privacy Pass peut le faire simplement en faisant une demande de déchargement dans le référentiel open-source.

À la sortie de la version 1.0 de l'extension, certaines fonctionnalités n'étaient toujours pas en place. Notamment, une validation de la preuve à divulgation nulle de connaissance zéro adaptée pour vérifier que le serveur utilisait toujours la même clé mise en gage. Dans la version 2.0, cette fonctionnalité a été réalisée, ce qui empêche de manière vérifiable un serveur malveillant de tenter de désanonymiser les utilisateurs en utilisant une clé différente pour chaque requête.

Les opérations de chiffrement requises pour le Privacy Pass sont effectuées à l'aide du chiffrement sur les courbes elliptiques (ECC). L'extension utilise actuellement la courbe NIST P-256, pour laquelle nous avons inclus quelques optimisations. Tout d'abord, cela permet de stocker des points de courbe elliptiques dans des formats de données compressés et non compressés. Cela signifie que l'espace de stockage du navigateur peut être réduit de 50 % et que les réponses du serveur peuvent également être réduites.

Deuxièmement, une prise en charge a été ajoutée pour le hachage vers les courbes P-256 à l'aide de la méthode « Shallue-van de Woestijne-Ulas simplifiée » (SSWU) spécifiée dans un avant-projet en cours (https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-03) a été ajouté pour normaliser les encodages pour le hachage vers les courbes elliptiques. La mise en œuvre est conforme aux spécifications de la suite de chiffrement « P256-SHA256-SSWU » dans ce projet.

Ces changements présentent un double avantage : premièrement, ils garantissent que la spécification de hachage vers les courbes P-256 est conforme au projet de spécification. Deuxièmement, ce chiffrement supprime la nécessité d'utiliser des méthodes probabilistes, telles que hachage et incrément. La méthode hachage et incrément présente un risque non négligeable d'échec, et sa durée de vie dépend fortement de l’entrée cachée du client. Bien que la manière de faire un usage abusif des vecteurs d'attaque temporelle ne soit pas claire à l'heure actuelle, l'utilisation de la méthode SSWU devrait réduire le risque d'attaque de l'implémentation et de connaissance de l’entrée du client.

Comme nous l'avons indiqué plus haut, vérifier que le serveur utilise toujours la même clé est un élément important pour garantir le respect de la vie privée du client. Cela garantit que le serveur ne peut pas isoler la base d'utilisateurs et restreindre la sécurité de la confidentialité des clients en utilisant des clés secrètes différentes pour chaque client avec lequel il interagit. Le serveur garantit qu'il utilise toujours la même clé en publiant une mise en gage de sa clé publique à un endroit qui est accessible par le client.

Chaque fois que le serveur délivre des jetons Privacy Pass au client, il produit également une preuve à divulgation nulle de connaissance zéro attestant qu'il a produit ces jetons en utilisant la bonne clé.

Avant que l'extension ne stocke des jetons, elle vérifie d'abord la preuve par rapport aux mises en gage qu'elle connaît. Auparavant, ces mises en gage étaient stockées directement dans le code source de l'extension. Cela signifiait que si le serveur voulait renouveler sa clé, il fallait alors publier une nouvelle version de l'extension, ce qui était inutilement difficile. L'extension a été modifiée pour que les mises en gage soient stockées dans un lieu de confiance auquel le client peut accéder quand il a besoin de vérifier la réponse du serveur. Actuellement, cet emplacement est un référentiel GitHub distinct de Privacy Pass. Pour les personnes intéressées, nous avons fourni une description plus détaillée du nouveau format de mise en gage dans l'annexe A à la fin du présent article.

Mettre en œuvre la prise en charge côté serveur dans Workers

Jusqu'à présent, nous nous sommes concentrés sur les mises à jour côté client. Dans le cadre de la prise en charge de la version 2.0 de l'extension, nous sommes en train d'apporter quelques modifications majeures à la prise en charge côté serveur que Cloudflare utilise. Pour la version 1.0, nous avons utilisé une implémentation en Go du serveur. Dans la version 2.0, nous lançons une nouvelle implémentation serveur qui fonctionne sur la plate-forme Cloudflare Workers. Cette implémentation de serveur n'est compatible qu'avec les versions 2.0 de Privacy Pass, il se peut donc que vous ayez besoin de mettre à jour votre extension si vous avez désactivé les mises à jour automatiques dans votre navigateur.

Notre serveur fonctionnera sur https://privacypass.cloudflare.com, et toutes les requêtes de Privacy Pass envoyées à la périphérie de Cloudflare sont traitées par des scripts Worker qui tournent sur ce domaine. Notre implémentation a été réécrite en Javascript, avec des opérations de chiffrement fonctionnant dans le moteur V8 qui est le moteur de Cloudflare Workers. Cela signifie que nous sommes en mesure de réaliser des opérations de chiffrement hautement efficaces et constantes dans le temps. De plus, nous bénéficions des performances améliorées que nous procure l'exécution de notre code sur la plate-forme Workers, le plus près possible de l'utilisateur.

Premièrement, vous vous demandez peut-être comment nous parvenons à réaliser des opérations de chiffrement dans Cloudflare Workers ? Actuellement, les opérations de chiffrement sont réalisées sur la plate-forme Workers via l'API WebCrypto.  Cette API permet aux utilisateurs de compiler des fonctionnalités telles que le hachage de chiffrement, ainsi que des opérations plus complexes comme les signatures ECDSA.

Dans le protocole Privacy Pass, comme nous le verrons un peu plus loin, les opérations de chiffrement principales sont effectuées par un protocole connu sous le nom de fonction pseudo-aléatoire inconsciente (VOPRF). Ce type de protocole permet à un client d'apprendre les sorties de fonctions calculées par un serveur, sans révéler au serveur quelle était sa véritable entrée. L'aspect vérifiable signifie que le serveur doit également prouver (de manière publiquement vérifiable) que l'évaluation qu'il transmet à l'utilisateur est correcte. Cette fonction est pseudo-aléatoire car la sortie du serveur ne peut être distinguée d'une séquence d'octets aléatoire.

La fonctionnalité VOPRF nécessite qu'un serveur exécute des opérations ECC de bas niveau qui ne sont pas actuellement exposées dans l'API WebCrypto. Nous avons trouvé un équilibre entre les différentes manières possibles de contourner cette exigence. Tout d'abord, nous avons essayé d'utiliser l'API WebCrypto d'une manière non-conventionnelle, en utilisant l'échange de clés EC Diffie-Hellman comme méthode pour effectuer la multiplication par un scalaire dont nous avions besoin. Nous avons également essayé de réaliser toutes les opérations en utilisant JavaScript seul. Malheureusement, aucune des deux méthodes ne s'est avérée satisfaisante du fait qu'elles impliquaient soit une intégration à de grandes bibliothèques de chiffrement externes, soit qu'elles seraient beaucoup trop lentes pour être utilisées dans un environnement Internet performant.

Finalement, nous avons opté pour une solution qui ajoute les fonctions nécessaires à Privacy Pass dans l'interface WebCrypto interne du moteur Javascript V8 de Cloudflare. Cet algorithme imite l'interface de signature/vérification fournie par les algorithmes de signature comme ECDSA. En résumé, nous utilisons la fonction sign() pour délivrer des jetons Privacy Pass au client. verify() peut être utilisée par le serveur pour vérifier les données qui sont récupérées par le client. Ces fonctions sont directement intégrées à la couche V8 et sont donc beaucoup plus performantes et sécurisées (fonctionnement en continu, par exemple) que les alternatives JS pures.

L'interface WebCrypto Privacy Pass n'est pas accessible au public pour le moment. S'il s'avère que l'utilisation de cet algorithme supplémentaire sur la plate-forme Workers suscite suffisamment d'intérêt, nous envisagerons alors de le rendre public.

Ces derniers temps, les fonctions pseudo-aléatoires inconscientes se sont révélées être une primitive très utile pour la mise en place de nombreux outils de chiffrement. En dehors de Privacy Pass, elles sont également incontournables pour la conception de protocoles d'échange de clés authentifiés par mot de passe comme OPAQUE, par exemple. Elles ont également été utilisées dans la conception de PSI, de protocoles de partage de secret protégés par mot de passe et de contrôle d'accès préservant la confidentialité pour le stockage de données privées.

L'écriture du serveur dans Cloudflare Workers signifie que nous fournirons une prise en charge côté serveur du Privacy Pass sur les domaines publics ! Bien que nous ne délivrions de jetons aux clients qu'une fois que nous sommes certains de pouvoir leur faire confiance, tout le monde pourra les utiliser avec notre API sur https://privacypass.cloudflare.com/api/redeem. Au fur et à mesure que nous déploierons la partie « server-side » dans le monde entier, vous pourrez utiliser cette API pour vérifier les jetons Cloudflare Privacy Pass, indépendamment de l'extension de navigateur.

Cela signifie que n'importe quel service peut accepter les jetons Privacy Pass d'un client ayant été délivrés par Cloudflare, et les vérifier ensuite avec l'API de conversion de Cloudflare. En se basant sur le résultat donné par l'API, des services externes peuvent vérifier si Cloudflare a déjà autorisé l'utilisateur par le passé.

Nous pensons que cela profitera à d'autres fournisseurs de services parce qu'ils pourront utiliser l'attestation d'autorisation de Cloudflare dans leur propre processus de prise de décision, sans jamais sacrifier la vie privée du client. Nous espérons que cet écosystème pourra se développer davantage, avec potentiellement plus de services fournissant leurs propres API de conversion publiques. Avec une plus grande diversité des émetteurs de jetons, ces attestations deviendront plus utiles.

En faisant tourner notre serveur sur un domaine public, nous sommes de fait un client de Cloudflare Workers. Cela signifie que nous pouvons également utiliser Workers KV pour nous protéger contre les clients malveillants. Les serveurs doivent notamment vérifier que les clients ne réutilisent pas les jetons pendant la phase de conversion. Les performances de Workers KV dans l'analyse des résultats en font un choix évident pour fournir une protection contre la double dépense à l'échelle mondiale.

Si vous souhaitez utiliser l'API de conversion publique, vous trouverez un manuel d'utilisation sur https://privacypass.github.io/api-redeem. Nous donnons également des exemples de requêtes et de réponses dans l'annexe B qui se trouve à la fin de cet article.

Normalisation et nouvelles applications

Parallèlement aux récents travaux d'ingénierie que nous avons effectués sur la prise en charge de Privacy Passau, nous avons collaboré avec la communauté pour tenter de normaliser à la fois la fonctionnalité VOPRF sous-jacente et le protocole lui-même. Bien que le processus de normalisation des fonctions pseudo-aléatoires inconscientes (OPRF) soit entamé depuis plus d'un an, les récents travaux de normalisation du protocole Privacy Pass ont été motivés par des applications très récentes qui ont été lancées ces derniers mois.

La normalisation des protocoles et des fonctionnalités permet de mettre en place des interfaces interopérables, sécurisées et performantes pour l'exécution des protocoles sur Internet. Les développeurs peuvent ainsi écrire plus facilement leurs propres applications de cette fonctionnalité complexe. Ce processus permet également de bénéficier des conseils utiles d'experts de la communauté, ce qui peut aider à mieux appréhender les risques potentiels pour la sécurité et à les réduire au moment de toute mise en œuvre. Il est permet également de parvenir à un consensus quant aux protocoles les plus fiables, évolutifs et performants pour toutes les applications possibles.

Les fonctions pseudo-aléatoires inconscientes (OPRF) sont une généralisation des VOPRF qui n'exigent pas que le serveur prouve qu'elles ont évalué correctement la fonctionnalité. Depuis juillet 2019, nous travaillons en collaboration avec leCrypto Forum Research Group (CFRG) à l'Internet Research Task Force (IRTF) sur un projet de normalisation d’un protocole OPRF fonctionnant en groupes d'ordre premier. Il s'agit d'une généralisation du cadre fourni par les courbes elliptiques. Il s'agit de la même structure de VOPRF qui a été spécifiée à l'origine par le protocole Privacy Pass et qui est en grande partie basée sur la conception du protocole original dans l'article de Jarecki, Kiayias et Krawczyk.

L'un des récents changements que nous avons apportés au projet est l'augmentation de la taille de la clé que nous envisageons d'utiliser pour effectuer les opérations OPRF côté serveur. Des travaux de recherche existants laissent entendre qu'il est possible de créer des requêtes spécifiques qui peuvent entraîner des fuites de petites portions de la clé. Pour les clés qui ne procurent que 128 bits de sécurité, cela peut poser un problème car une trop grande fuite de bits réduirait la sécurité en-deçà des niveaux actuellement acceptés. Pour y remédier, nous avons augmenté la taille minimale de la clé à 192 bits. Ceci permet d'éviter que cette fuite ne devienne un facteur d'attaque en utilisant toute méthode pratique disponible. Nous reviendrons plus en détail sur ces attaques lorsque nous aborderons nos projets futurs pour le développement des VOPRF.

L'application que nous avons présentée au moment de la prise en charge initiale de Privacy Pass a toujours été conçue comme une démonstration de faisabilité pour ce protocole. Au cours des derniers mois, un certain nombre de nouvelles perspectives ont émergé dans des domaines qui vont bien au-delà de ce qui avait été envisagé précédemment.

Par exemple, l'API trust token, développée par le Web Incubator Community Group, a été proposée comme interface pour utiliser Privacy Pass. Ces applications permettent aux fournisseurs tiers de vérifier qu'un utilisateur a reçu une attestation de confiance de la part de plusieurs entités centrales. Cela permet au fournisseur de décider de la bonne foi d'un client sans avoir à associer un profil de comportement à l'identité de l'utilisateur. L'objectif est d'empêcher toute activité frauduleuse de la part d'utilisateurs en qui l'émetteur central n'a pas confiance. Il serait possible de vérifier les attestations de confiance auprès des émetteurs centraux à l'aide d'API de conversion semblables à celle que nous avons mise en place.

Facebook a également mis au point une application similaire pour lutter contre les comportements malveillants, laquelle est également compatible avec le protocole Privacy Pass. Enfin, d'autres applications relatives à l'accès à des systèmes de stockage privés et à l'établissement de modèles de sécurité et de protection de la vie privée dans les protocoles de confirmation de publicité ont été mises en place.

En gardant à l'esprit les applications ci-dessus, nous avons récemment entamé un travail collaboratif sur un nouveau projet de l'IETF qui définit spécifiquement les fonctionnalités requises fournies par l'ensemble du protocole Privacy Pass. Notre objectif est de développer, aux côtés des plus grands partenaires industriels et de la communauté universitaire, une spécification fonctionnelle du protocole Privacy Pass. Nous espérons ainsi pouvoir concevoir un protocole de couche de base, qui pourra ensuite être utilisé comme une primitive cryptographique dans des applications plus larges qui nécessitent une certaine forme d'autorisation légère. Nous prévoyons de présenter la première version de ce projet lors de la prochaine réunion de l'IETF 106 à Singapour le mois prochain.

Le projet n'en est encore qu'aux premiers stades de développement et nous recherchons activement des personnes qui souhaiteraient participer à l'élaboration des spécifications de ce protocole. Toute aide susceptible de contribuer à ce travail est la bienvenue. Voir la version actuelle du document sur le référentiel GitHub.

Possibilités ultérieures

Enfin, si nous travaillons activement dans l'immédiat sur un certain nombre de pistes différentes, les orientations futures du projet sont encore indéterminées. Nous croyons qu'il existe de nombreuses applications que nous n'avons pas encore envisagées et nous attendons avec impatience de voir dans quelle mesure le protocole sera utilisé à l'avenir. Voici d'autres idées de nouvelles applications et de nouvelles fonctions de sécurisation qui, à notre avis, mériteraient d'être approfondies à l'avenir.

L'un des inconvénients de l'utilisation d'un VOPRF est que les jetons de conversion (redemption tokens) ne sont vérifiables que par le serveur émetteur d'origine. En utilisant une primitive sous-jacente qui permettait de vérifier publiquement les jetons de conversion, n'importe qui pourrait alors vérifier que le serveur émetteur a émis le jeton en question. Ce type de protocole pourrait être élaboré sur la base de systèmes dits de signature aveugle, tels que RSA. Malheureusement, l'utilisation de dispositifs de signature aveugle dans un environnement de navigateur pose des problèmes de performances et de sécurité. Les dispositifs existants (en particulier ceux basés sur RSA) nécessitent des calculs de chiffrement beaucoup plus lourds que ce qui est utilisé dans notre protocole VOPRF.

Les seules structures VOPRF existantes sont des VOPRF pré-quantiques, généralement basées sur des problèmes bien connus dans des groupes tels que l'hypothèse du logarithme discret. Aucune structure VOPRF ne permet de se prémunir contre des agresseurs capables d'exécuter des algorithmes de calcul quantique. Cela signifie que le protocole Privacy Pass n'est considéré comme sécurisé que contre les agresseurs qui utilisent du matériel classique.

Des études récentes laissent penser que l'informatique quantique pourrait arriver plus tôt que prévu. De ce fait, nous estimons que nous devons étudier la possibilité de concevoir des alternatives post-quantiques concrètes de notre boîte à outils de chiffrement actuelle : une tâche de grande importance pour nous et la communauté au sens large. Dans ce cas, l'élaboration d'alternatives post-quantiques performantes pour les structures VOPRF serait un progrès théorique important. À terme, cela aboutirait à un protocole Privacy Pass qui continuerait de donner des autorisations préservant la confidentialité dans un monde post-quantique.

Nous avons déjà dit que les VOPRF (ou simplement les OPRF) sont vulnérables aux petites fuites possibles de la clé. Nous donnerons ici une brève description des attaques proprement dites, ainsi que de plus amples détails sur nos projets de déploiement de suites de chiffrement plus sécurisées pour atténuer les fuites.

Plus précisément, les clients malveillants peuvent interagir avec une VOPRF pour créer ce que l'on appelle un échantillon q-Strong-Diffie-Hellman (q-sDH). Ces échantillons sont créés en groupes mathématiques (généralement dans la définition des courbes elliptiques). Pour tous les groupes, il existe un élément public g au centre de toutes les opérations de type Diffie-Hellman, ainsi qu'une clé de serveur K, qui est généralement simplement interprétée comme un nombre généré de manière aléatoire à partir de ce groupe. Un échantillon q-sDH prend la forme suivante :

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

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

et demande à l'adversaire malveillant de créer une paire d'éléments qui satisfont à (gô(1/(s-K)).s). Un client dans le protocole VOPRF peut créer un échantillon q-SDH en renvoyant simplement le résultat de l'évaluation VOPRF précédente au serveur.

Bien que l'on pense que ce problème est difficile à résoudre, un certain nombre de publications ont déjà montré que le problème est un peu plus facile à résoudre que ce que suggère la taille du groupe (voir par exemple ici et ici). Concrètement, la sécurité des bits impliquée par le groupe peut être réduite jusqu'à log₂(q) bits. Bien que cela ne soit pas immédiatement fatal, même pour les groupes qui devraient garantir 128 bits de sécurité, cela peut entraîner une dégradation de la sécurité, ce qui signifie que le cadre ne sera plus sûr à l'avenir. Par conséquent, tout groupe qui offre une fonctionnalité VOPRF instanciée à l'aide d'une courbe elliptique comme la courbe P-256 ou Curve25519 offre des garanties de sécurité plus faibles que ce qui est recommandé.

Sachant cela, nous avons récemment pris la décision de réduire les suites de chiffrement que nous recommandons pour l'OPRF à celles offrant plus de 128 bits de sécurité par défaut comme norme. Par exemple, Curve448 fournit 192 bits de sécurité. Pour lancer une attaque qui réduirait la sécurité à un montant inférieur à 128 bits, il faudrait envoyer 2^(68) requêtes OPRF client. Cela constitue un obstacle de taille pour tout attaquant, c'est pourquoi nous considérons ces suites de chiffrement comme sécurisantes pour instancier la fonctionnalité OPRF.

Dans un avenir proche, il sera nécessaire de mettre à jour les suites de chiffrement utilisées pour la prise en charge de l'extension de navigateur Privacy Pass en fonction des recommandations de la version actuelle du projet VOPRF. Globalement, grâce à un processus de diffusion plus itératif, nous espérons que la mise en place du Privacy Pass permettra de suivre de plus près le projet de norme actuel au fil de son évolution pendant le processus de normalisation.

Vous pouvez dès à présent installer la version 2.0 de l'extension Privacy Pass dans Chrome ou Firefox.

Si vous souhaitez contribuer au développement de cette extension, vous pouvez le faire sur GitHub. Êtes-vous un fournisseur de services souhaitant intégrer la prise en charge « server-side » pour l'extension ? Dans ce cas, nous aimerions beaucoup vous connaître !

Nous continuerons de travailler avec l'ensemble de la communauté afin de normaliser le protocole, en nous inspirant des applications existantes qui ont été mises au point. Nous sommes constamment à la recherche de nouvelles applications qui pourraient aider à étendre l'écosystème de Privacy Pass au-delà de ses limites actuelles.

Annexe

Voici quelques précisions supplémentaires concernant les sujets que nous avons abordés ci-dessus.

Des mises en gage de clés sont nécessaires pour que le serveur prouve son honnêteté lors de l'utilisation du protocole Privacy Pass. Les mises en gage utilisées par Privacy Pass pour la version 2.0 ont un format légèrement différent de celui de la version précédente.

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

Tout d'abord, la version de la clé du serveur est 2.00, le serveur doit informer le client de la version qu'il entend utiliser dans sa réponse à un client contenant des jetons émis. Cela permet de garantir que le client puisse toujours utiliser les mises en gage (commitment) correctes lors de la vérification de la preuve à divulgation nulle de connaissance zéro que le serveur envoie.

La valeur du membre H est la mise en gage de la clé publique pour la clé secrète utilisée par le serveur. Il s'agit du point de courbe elliptique codé en base64 de la forme H=kG où G est le générateur fixe de la courbe, et k la clé secrète du serveur. Étant donné que le problème du logarithme discret est considéré comme difficile à résoudre, on estime qu'il est difficile de dériver k à partir de H. La valeur d'expiration du membre est une date d'expiration de la mise en gage utilisée. La valeur du sig du membre est une signature ECDSA évaluée à l'aide d'une clé de signature à long terme associée au serveur, et sur les valeurs de H et d'expiration.

Lorsqu'un client récupère la mise en gage, il vérifie qu'elle n'a pas expiré et que la signature est vérifiée à l'aide de la clé de vérification correspondante qui est intégrée à la configuration de l'extension. Si ces contrôles réussissent, il récupère H et vérifie la réponse d'émission envoyée par le serveur. Les versions précédentes de ces mises en gage ne comportaient pas de signatures, mais ces signatures seront validées à partir de la version 2.0.

Lorsqu'un serveur veut changer la clé, il génère simplement une nouvelle clé k2 et ajoute une nouvelle mise en gage pour k2 avec un nouvel identifiant comme par exemple 2.01. Il peut alors utiliser k2 comme clé secrète pour les opérations VOPRF qu'il doit calculer.

L'API de conversion est disponible en HTTPS en envoyant des requêtes POST à https://privacypass.cloudflare.com/api/redeem. Les requêtes adressées à ce point de terminaison doivent indiquer dans leur corps les données Privacy Pass en utilisant la syntaxe JSON-RPC 2.0. Voyons un exemple de requête :

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

Dans ce qui précède, params.data[0] est la donnée d'entrée du client utilisée pour générer un jeton dans la phase d'émission ; params.data[1] est la balise HMAC que le serveur utilise pour vérifier une conversion (redemption) ; et params.data[2] est un objet JSON sérialisé et codé en base64 qui spécifie les paramètres de hachage vers la courbe utilisés par le client. Par exemple, le dernier élément du tableau correspond à l'objet :

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

Ceci indique que le client a utilisé la courbe P-256, avec la fonction de hachage SHA-256, et la méthode SSWU pour hacher la courbe. Cela permet au serveur de vérifier la transaction avec la suite cryptographique correcte. Le client doit lier la demande de conversion à certaines informations fixes, qu'il stocke sous forme de chaînes multiples dans le tableau params.bindings. Par exemple, il pourrait envoyer l'en-tête hôte de la demande HTTP, et le chemin HTTP qui a été utilisé (c'est ce qui est utilisé dans l'extension de navigateur Privacy Pass). Enfin, params.compressed est une valeur booléenne optionnelle (par défaut false) qui indique si la balise HMAC a été calculée sur des encodages ponctuels compressés ou non.

Actuellement, les seules suites de chiffrement prises en charge sont celles de l'exemple ci-dessus, ou les mêmes avec une méthode égale à l'incrément pour la méthode de hachage vers une courbe« hachage et incrément » (hash-and-increment). Il s'agit de la méthode originale utilisée dans la version 1.0 de Privacy Pass, et elle n'est prise en charge que par compatibilité rétroactive. Consultez le manuel fourni pour plus de détails.

Si une demande est envoyée à l'API de conversion et qu'elle est validée avec succès, la réponse suivante vous sera alors renvoyée.

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

Lorsqu'une erreur se produit, vous recevrez une réponse semblable à ce qui suit.

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

Les codes d'erreur que nous fournissons sont sous la forme de codes JSON-RPC 2.0 ; nous décrivons les types d'erreurs que nous fournissons dans la documentation de l'API.