Cet article effectue une analyse comparative du protocole d’autorisation d’accès à des sites requérant une vérification d’âge proposé par le LINC (Laboratoire d’innovation numérique de la CNIL), dit en “double anonymat”, et de Privacy Pass, un protocole similaire développé par l’IETF (Internet Engineering Task Force), avec la contribution de Google, Apple, Cloudflare, Fastly, LIC, Brave Software, The Tor Project, et Mozilla.
Ces deux protocoles sont génériques et n’ont rien de spécifique avec la vérification d’âge. Leur objectif est de prouver à un tiers qu’un utilisateur remplit un certain critère, sans révéler à ce tiers qui est exactement cet utilisateur parmi un groupe d’individus. Ainsi, bien que le protocole proposé par le LINC soit actuellement popularisé dans le cadre du contrôle d’accès aux sites pornographiques, celui-ci ne se limite pas à ce cas d’usage, et d’autres sont possibles (âge, genre, classe de niveaux de revenu, statut de vaccination, etc.) et certains sont même déjà évoqués sur le site du LINC1.
Par exemple, nous pouvons imaginer que cela fonctionne par grand palier selon la législation : 13 ans, 15 ans, 16 ans et 18 ans.
Dans cet article, nous verrons que le protocole proposé par le LINC comporte plusieurs risques pour la vie privée des utilisateurs. Parmi ces derniers, il est notamment question de fuite de données potentiellement caractérisables comme des données de santé, et de la capacité de l’État ou de son représentant à désanonymiser les utilisateurs en cas de collusion de plusieurs parties, de manière plus ou moins discrète.
Cet article est délibérément très technique et s’adresse à un public averti et formé à la cryptographie applicative et à la sécurité des protocoles réseau. La conclusion de l’article devrait être intelligible pour la plupart des lecteurs, mais elle n’aurait aucune valeur scientifique et technique sans le charabia qui la précède. Si vous êtes journaliste, faites-vous assister par un spécialiste de confiance pour vérifier mes dires avant de les reprendre.
Finalement, cet article ne couvre pas les nombreux moyens de contournement de la mesure technique souhaitée par le gouvernement français, au rang desquels les VPN. L’objectif est de discuter des mérites et des défauts des protocoles d’autorisation. Il est fait l’hypothèse (évidemment fantasque) que le monde entier a déployé cette méthode d’autorisation, ou qu’il n’est pas possible d’échapper à ce contrôle d’aucune manière que ce soit. Bienvenue en enfer.
Il n’existe à ce jour pas de papier scientifique ou whitepaper effectuant une description formelle du protocole proposé. Il existe cependant un article publié sur le site du LINC1, et le code source d’un démonstrateur2. Ces deux ressources sont assez anciennes, puisqu’elles ont été publiées en juin 2022, sans changement depuis lors. Si des évolutions ont eu lieu entre temps, ces dernières ne sont pas encore rendues publiques.
Pour résumer ce qui est indiqué dans ces ressources, le protocole du LINC est composé de cinq acteurs ou types d’acteurs :
Il convient de noter que l’Autorité et l’Opener sont des rôles pouvant être assumés par une unique entité ou des entités distinctes. Il est fait l’hypothèse que l’Autorité et l’Opener sont des entités étatiques ou mandatées par l’État français.
Si les termes Origin, Client, Issuer, Autorité et Opener semblent trop abstraits, il semble acceptable de les remplacer mentalement dans le reste de cet article de la façon suivante, tant qu’il reste clair à l’esprit de chacun qu’il ne s’agit que d’exemples :
Pour consulter un site dont l’accès est restreint (noté Origin), celui-ci signale au Client, s’il n’est pas authentifié à l’aide d’un compte précédemment créé sur ce site, qu’une vérification du critère d’accès est requise. Pour cela, l’Origin fournit un “challenge”. Ce challenge consiste en des données permettant à l’Origin de vérifier, à l’issue des différents échanges, que l’autorisation d’accès délivrée a bien été émise pour cette Origin, et nul autre. Il contient également des métadonnées sur la nature du critère qui doit être contrôlé à propos du Client (p. ex. son âge supérieur à 18 ans).
Le Client télécharge ce challenge, puis se connecte auprès d’un Issuer et lui envoie le challenge. Cet Issuer vérifie si le Client remplit le critère. Par exemple, si c’est le site des Impôts, il vérifie à l’aide des informations d’état civil, si l’utilisateur est majeur. Dans le cas où le Client remplit le critère, l’Issuer effectue une opération cryptographique sur le challenge, et renvoie au Client le résultat de cette opération, que nous appellerons preuve.
Le Client télécharge cette preuve, puis il se connecte à nouveau à l’Origin et lui envoie la preuve délivrée par l’Issuer. L’Origin vérifie la validité de cette preuve grâce à des opérations cryptographiques, vérifie que cette preuve est bien fournie pour le challenge qu’il avait initialement fourni à l’utilisateur et vérifie que l’Issuer sélectionné par le Client a toujours la confiance de l’Autorité. Si ces conditions sont réunies, alors l’Origin accorde au Client l’accès à son service.
Le protocole du LINC est affublé du qualificatif de “double anonymat”, car :
l’identité du Client, bien que connue et vérifiée par l’Issuer, reste inconnue de l’Origin. L’Origin n’a connaissance que du fait que l’utilisateur remplit ou non le critère d’admission.
l’identité de l’Issuer reste inconnue de l’Origin. En effet, les mécanismes cryptographiques mis en jeu par le protocole permettent à l’Origin de vérifier les preuves et de vérifier que l’Issuer a toujours la confiance de l’Autorité, sans jamais apprendre l’identité de l’Issuer.
Ce protocole vise donc à se défier des Origin, et à contrôler leur mécanisme d’autorisation d’accès en les privant de toute information d’identification.
En outre, ce protocole vise à ce que l’Issuer ne puisse discerner l’Origin que cherche à visiter le Client.
Protéger l’identité du Client semble une évidence, étant donné qu’avant la mise en place de ce type de contrôle d’accès, l’Origin ignorait tout de l’identité du Client.
Protéger l’identité de l’Issuer semble un peu plus surprenant. Cela permet néanmoins de limiter les risques que l’Origin apprenne des informations à propos de l’identité du Client. Par exemple, si le Client utilise le site des Impôts pour obtenir l’autorisation, alors l’Origin apprend que le Client est imposable (c’est-à-dire “potentiellement monétisable”) en plus de connaitre le critère de majorité.
Il convient de noter que la propriété d’anonymat de l’Issuer n’est pas limitée à l’Origin. En effet, avec les mécanismes cryptographiques mis en oeuvre par le protocole du LINC, il n’est possible pour personne d’autre que l’Opener de savoir qui est l’Issuer. Cela peut paraitre étonnant de prime abord, puisque l’utilisateur sait bien auprès de quel organisme il s’est authentifié pour obtenir la preuve de son admissibilité au critère. Il s’agit ici d’une subtilité du protocole : l’Issuer n’est en réalité pas un organisme unique, mais une clé cryptographique détenue par un organisme. Rien ne permet de garantir à qui que ce soit qu’un organisme ne possède qu’une et une seule clé cryptographique. Pour le dire plus simplement, un organisme peut incarner simultanément plusieurs Issuers à l’insu de tous·tes. Nous reviendrons sur ce point lors de l’analyse des défauts de ce protocole.
Ces informations sont majoritairement tirées du démonstrateur publié sur Github2.
L’Origin génère un challenge comprenant deux informations publiques et une privée. Les informations publiques sont un nonce, et un critère d’âge. L’information privée est la durée de validité du challenge.
Le Client transmet le challenge tel quel à l’Issuer sans aucune modification.
L’Issuer effectue une “signature” grâce à la bibliothèque PBC 3, et génère ainsi une preuve à divulgation nulle de connaissance de sa connaissance de sa clé privée. Il convient de noter que cette clé privée fait partie d’un schéma de signature de groupe4, dont le domaine de confiance est géré par l’Autorité. La seule connaissance de la clé publique du groupe est suffisante pour vérifier la preuve émise par cette clé privée. Une fois cette preuve créée, elle est envoyée au Client.
Le Client transmet tel quel à l’Origin la preuve, sans aucune modification.
L’Origin vérifie que la preuve porte bien sur le challenge/nonce qu’il a initialement délivré à ce Client. Il vérifie que le challenge n’a pas expiré. Il vérifie ensuite la validité de la preuve, grâce à la clé publique de l’Autorité. Il vérifie également dans une liste de révocation fournie par l’Autorité que la clé privée ayant créé la preuve n’a pas été révoquée du domaine de confiance.
Privacy Pass est un protocole d’autorisation d’accès préservant la vie privée du Client développé par l’IETF. Ce protocole a été initialement proposé, en 2017, par Cloudflare dans un objectif de limitation du nombre de CAPTCHA présentés aux Clients naviguant sur des sites protégés par Cloudflare depuis le réseau d’anonymisation Tor. Il a depuis été spécifié sous la forme d’Internet Drafts dont certains sont en passe d’être adoptés en tant que RFC. Il convient donc de noter que les éléments évoqués ci-dessous sont contemporains aux versions en cours d’études par le groupe de travail Privacy Pass WG5.
Privacy Pass est un protocole générique de vérification de critères, bien qu’à l’origine, le critère vérifié par Cloudflare soit limité à “l’intelligence humaine”, ou plus spécifique à la capacité à résoudre un puzzle sensément insoluble par les intelligences artificielles actuelles.
Il convient de noter qu’il existe deux méthodes de génération des jetons d’autorisation d’accès avec Privacy Pass. L’un repose sur un VOPRF (Verifiable Oblivious Pseudo Random Function)6 et des vérifications avec une clé privée. L’autre utilise des signatures et des vérifications à clé publique. Dans le cadre de cet article, nous n’étudierons que la version avec des signatures et vérifications à clé publique, afin de rester dans un cadre relativement comparable au protocole proposé par le LINC.
Privacy Pass est composé de quatre rôles :
Il existe de nombreuses variations dans l’architecture de Privacy Pass. Chaque rôle peut être incarné par des entités distinctes ou plusieurs rôles peuvent l’être par une seule entité. Ainsi les combinaisons de rôle suivantes sont spécifiées :
Lorsqu’un Client tente d’accéder à une Origin requérant un critère spécifique, l’Origin renvoie un ou plusieurs challenges.
Chaque challenge est composé des informations suivantes :
un type de jeton d’autorisation acceptable (en vue de permettre l’agilité cryptographique) ;
le nom d’un issuer pouvant répondre à ce challenge ;
optionnellement, une information de contexte, sous la forme d’une valeur opaque de 32 octets, permettant de restreindre le contexte d’utilisation du jeton d’autorisation ;
optionnellement, le nom de l’Origin ayant produit ce challenge.
L’information de contexte permet notamment de limiter l’utilisation à une Origin particulière, sans pour autant divulguer le nom de cette Origin auprès de l’Issuer. Elle permet aussi d’encoder des restrictions comme l’adresse IP depuis laquelle sera autorisée la présentation du jeton d’autorisation d’accès, ou encore la durée de validité du challenge.
Le Client choisit l’un des challenges, et contacte un Attester qui est en relation avec l’Issuer spécifié dans le challenge sélectionné. L’Attester vérifie si le critère est vérifié par le Client. Si tel est le cas, l’Attester témoignera de cela auprès de l’Issuer. Si l’Attester n’est pas Issuer, alors il faudra qu’une mise en relation des deux rôles soit effectuée, soit par l’intermédiaire du Client qui contactera l’Issuer avec une attestation signée par l’Attester, soit l’Attester contactera directement l’Issuer.
Que ce soit le Client ou l’Attester qui contacte l’Issuer, dans tous les cas, le Client devra fournir des informations additionnelles à destination de l’Issuer :
L’identifiant de la biclé que l’Issuer doit utiliser pour générer le jeton d’autorisation est le condensat SHA-256 de la clé publique de l’Issuer au format SubjectPublicKeyInfo encodée en DER.
La valeur opaque est le résultat d’une opération de masquage (blinding) du condensat du challenge et d’un nonce généré par le Client, et de diverses autres métadonnées protocolaires.
Le Client peut envoyer plusieurs requêtes à l’Issuer (éventuellement par l’entremise de l’Attester) pour une même attestation, afin de pouvoir obtenir plusieurs jetons pour une seule vérification du critère. Pour chaque requête, il sera nécessaire que le nonce du client soit distinct.
L’Issuer vérifie qu’une attestation a été fournie par l’Attester et effectue la signature cryptographique de la valeur opaque qu’il a reçue.
Le Client récupère la/les valeur(s) signée(s) et la/les démasque (unblind).
Le Client envoie ensuite à l’Origin le nonce, la signature démasquée, le condensat du challenge et diverses métadonnées.
L’Origin vérifie alors la signature démasquée contre les différentes données reçues, grâce à la clé publique associée à l’Issuer que le Client a choisi. Si la signature est bonne, alors l’accès est accordé.
Privacy Pass offre une protection raisonnable (mais pas absolue) sur l’identité du Client.
L’Origin ne peut connaitre l’identité du Client, et ce même en cas de collusion avec l’Issuer. Cela est assuré par le mécanisme de masquage, dont seul le Client connait la clé de démasquage et qui rend virtuellement impossible toute connexion entre la requête du Client à l’Issuer et celle qu’il effectue auprès de l’Origin.
L’Origin apprend néanmoins quel Issuer a émis la signature, et il peut donc inférer certaines informations sur l’Attester, si tous les Attesters ne sont pas accrédités par tous les Issuers. Et en connaissant/suspectant quel Attester a été utilisé, l’Origin peut alors inférer une information sur le Client. Pour reprendre l’exemple donné pour le protocole du LINC, si l’Attester est le service des Impôts, et que l’Issuer n’a comme seul Attester ce dernier, alors en sachant que cet Issuer a reçu une attestation du service des Impôts, alors il sait que le Client est imposable.
Privacy Pass prévoit également que le Client puisse vérifier la signature grâce à la clé publique de l’Issuer. Cette vérification de signature doit être couplée à la vérification en ligne7 que la clé publique qu’il connait et utilise pour vérifier la signature est la même que celle à laquelle tous les autres Clients qui auraient recours à cet Issuer, auraient utilisée. Ces deux vérifications permettent de contrecarrer une attaque dite par partitionnement de l’ensemble anonyme (anonymity set partitionning). En effet, sans elles, le Client pourrait avoir reçu une signature effectuée avec une clé privée qui ne serait utilisée par l’Issuer que pour certains Clients. Ces Clients ne feraient alors plus partie de l’ensemble anonyme global, vérifié par la clé publique commune, mais d’un sous-ensemble, distinguable, vérifiable uniquement par une clé publique distincte.
Finalement, la révocation d’un Issuer ne s’effectue pas de manière centralisée ; chaque Origin doit individuellement retirer de sa liste de confiance les Issuers qui ne sont plus de confiance.
Il existe de nombreuses variantes et options dans Privacy Pass, et il ne s’agit ici que d’un portrait partiel, afin des fins de comparaison avec le protocole du LINC. S’il devait il y avoir de nouveaux points de comparaison, à l’aune d’une mise à jour des spécifications de l’un ou l’autre des protocoles, ou si un oubli c’était glissé dans cet article, ce dernier sera mis à jour dès que l’auteur en aura connaissance.
Privacy Pass est conçu de manière à être agile vis-à-vis de ses mécanismes cryptographiques. Cette agilité est encodée grâce aux indicateurs de types de jetons qui ont été évoqués à plusieurs reprises dans la section précédente.
À l’heure où cet article est écrit, il n’existe que deux types de jetons :
Après cette longue présentation des deux protocoles, il est proposé de procéder à l’analyse comparative de ces derniers.
Le protocole du LINC est un protocole interactif. Pour chaque demande d’accès devant être autorisée, le Client doit contacter un Issuer afin d’obtenir une preuve que le critère est rempli.
À l’inverse, Privacy Pass est un protocole qui peut être interactif ou non. Il est ainsi possible de demander à un Issuer implémentant Privacy Pass de multiples jetons d’autorisation pour un même challenge. Le Client n’est alors pas obligé de rentrer en contact avec l’Attester ou l’Issuer à chaque accès à l’Origin, puisqu’il peut être en mesure de disposer de certains jetons “d’avance”.
La nécessité d’interactivité du protocole dit en “double anonymat” fait que le Client se présentera probablement à l’Issuer et à l’Origin avec la même adresse IP. Si cette dernière n’est pas partagée avec une large portion de l’ensemble anonyme (anonymity set), alors il sera possible de déduire l’identité de l’utilisateur et ses habitudes de consommation en cas de collusion de l’Issuer et de l’Origin.
Avec Privacy Pass en mode interactif, le problème est identique. Néanmoins, en mode non interactif, le Client a l’opportunité de moduler son adresse IP, par exemple grâce à un VPN, pour l’unique moment où il collectera l’ensemble de ses jetons d’autorisation.
Avec le protocole du LINC, le challenge fourni par l’Origin est transmis verbatim à l’Issuer. En conséquence, la collusion des deux entités permet d’associer aisément l’identité d’un Client à une activité sur une session sur l’Origin par simple journalisation puis comparaison des challenges émis et reçus.
En outre, même sans collusion, il est possible que l’Issuer puisse découvrir quelle Origin est visitée par le Client grâce à des motifs discernables dans le challenge. Par exemple, dans le démonstrateur développé par le LINC, le challenge est simplement la date du serveur. Il suffira alors de quelques requêtes par quelques Clients pour réussir à discerner l’heure exacte d’un serveur après gommage statistique des latences des requêtes. L’Issuer sera ensuite capable d’identifier de manière totalement passive quel site est consulté par quel Client sur la simple base de l’information volontairement transmise par le Client. Même si le challenge était un nombre aléatoire, il pourrait être possible d’identifier l’Origin si l’Origin n’utilise pas un générateur de nombres aléatoires cryptographiquement sûr. En effet, après un certain nombre de requêtes, il serait possible de retrouver l’état du générateur de nombres aléatoires, et d’ainsi distinguer plusieurs Origin de manière passive9.
Avec Privacy Pass, comme le challenge émis par l’Origin est intégré dans une requête dont le contenu est masqué avant d’être envoyée à l’Issuer, il n’est pas possible de faire ce lien, même en cas de collusion de l’Origin et de l’Issuer. Le Client participe activement au protocole et se défie de l’Origin et de l’Issuer.
Avec le protocole du LINC, la preuve à divulgation nulle de connaissance émise par l’Issuer est transmise verbatim à l’Origin. Comme pour le challenge dans la section précédente, il est possible de relier l’identité du Client à une session sur l’Origin grâce à cette valeur commune.
Avec Privacy Pass, comme dans la section précédente, le démasquage de la réponse de l’Issuer permet de créer une rupture entre les données connues de l’Issuer et celles connues de l’Origin. En conséquence, il n’est pas possible de relier l’identité du Client à une session sur l’Origin par ce biais. Le client participe activement au protocole et se défie de l’Origin et de l’Issuer.
Le protocole du LINC prévoit que seul l’Opener puisse être en mesure de recouvrer quel Issuer a émis une preuve donnée. Cette propriété est délibérée et constitue l’un des deux “anonymats” de ce protocole dit à “double anonymat”. Elle est implémentée grâce à l’emploi d’un mécanisme de signature cryptographique de groupe4, et elle vise notamment à ce que l’Origin ne puisse distinguer l’Issuer.
Hélas, l’Origin n’est pas le seul acteur à ne pouvoir distinguer quel Issuer et plus précisément quelle clé privée d’Issuer a été utilisée pour générer une preuve. Les Clients ne le peuvent pas non plus.
Ainsi, dans le cas où l’Autorité et l’Issuer sont malveillants, il est possible qu’un sous-ensemble de l’ensemble anonyme (c.-à-d. certains Clients) voie ses preuves générées à l’aide de clés privées spécifiques. Ces preuves sont indistinguables de toutes les autres preuves, sauf pour l’Opener qui sera en mesure de singulariser les Clients ayant présenté à l’Origin ces preuves. Il ne semble pas improbable, dans le cas où l’Opener est l’État français qu’une perquisition des serveurs de l’Origin permet d’obtenir des journaux applicatifs contenant ces preuves et leur association à des sessions de navigation.
Privacy Pass, de son côté, peut également mettre en oeuvre des attaques par partitionnement de l’ensemble anonyme, notamment en incitant le Client à recourir à plusieurs Issuers tour à tour. Dans le cas où le Client se conforme à ces incitations, il est alors possible de partitionner l’ensemble anonyme en plaçant le Client à l’intersection des ensembles des Clients étant capables ou incapables d’obtenir des jetons d’autorisation de certains Issuers. Par exemple, un Client pourrait être identifié dans un sous-ensemble anonyme dont ses membres peuvent prouver leur âge grâce à leur banque, et à la sécurité sociale, et jamais via le service des Impôts. Ce sous-ensemble pourrait ainsi correspondre aux jeunes encore rattachés au foyer fiscal de leurs parents/tuteurs. Bien que Privacy Pass spécifie un moyen d’inciter les Clients à fournir des jetons d’autorisation provenant de tel ou tel Issuer plutôt que d’autres, le choix revient au logiciel mis en oeuvre par l’utilisateur de suivre cette incitation ou non. Il est donc possible que certains logiciels implémentant Privacy Pass ne soient pas concernés par cette attaque.
Le protocole du LINC doit et Privacy Pass peut fonctionner en mode interactif. Ce mode de fonctionnement oblige le Client à obtenir une preuve ou un jeton d’autorisation frais auprès d’un Issuer à chaque accès à une Origin. Cette obligation signifie que les Issuers seront en mesure de reconnaitre des habitudes de consommation. Dans le cas des sites pornographiques, ce mode est dangereux puisqu’une personne ayant développé une addiction à la pornographie pourra être identifiée comme telle par un Issuer qui lui remettrait des dizaines des preuves/jetons d’autorisation par jour. Or, les addictions sont des informations de santé10 11.
Un des risques perçus par le mode non interactif où le Client est autorisé à demander plusieurs preuves/jetons d’autorisation pour un unique challenge est la création d’un marché noir des preuves/jetons d’autorisation. En effet, un Client disposant de plusieurs jetons pourrait distribuer ou vendre ces derniers sans que l’Origin ne puisse distinguer si la preuve a bien été produite pour le Client qui la lui présente.
D’une part, il existe une contremesure assez simple, et qui est même recommandée dans la spécification de Privacy Pass : relier le challenge à un attribut de la connexion entre le Client et l’Origin : l’adresse IP du Client ou l’identifiant de la connexion TLS 12 (Transport Layer Security).
Une telle contremesure permettrait de passer en mode non interactif, tout en contrecarrant l’essentiel des risques liés au marché noir.
Ensuite, en admettant que la preuve/le jeton d’autorisation soit bien présenté à l’Origin par le Client l’ayant demandé à l’Issuer, la première chose que fera l’Origin après vérification de l’authenticité de ce jeton sera de créer une session HTTP classique dans laquelle il sera noté que ce Client est autorisé à accéder au contenu du site. La plupart des sites n’appliquent pas de politique de sécurité associant fortement une session HTTP à une session TLS. Un utilisateur malveillant pourra alors revendre non pas son jeton d’autorisation, mais son identifiant de session HTTP. Cette technique de partage de sessions HTTP par la divulgation de l’identifiant de session est bien connu des auditeurs en sécurité, qui la connaisse sous le nom de Session Fixation13. Un tel partage pourrait même être aisément automatisé à grande échelle grâce à une extension navigateur.
L’usage du mode interactif pour le protocole proposé par le LINC dans le cadre de la demande de restriction d’accès aux sites pornographiques par le gouvernement français n’est donc pas pertinent, et constitue au mieux un choix mal informé.
Le problème de double dépense survient lorsqu’une même preuve ou un même jeton d’autorisation peut être utilisé sur plusieurs Origin, alors que le protocole souhaiterait voir la preuve/le jeton consommé et ne plus être réutilisable.
Il existe de nombreuses manières de résoudre ce problème de double dépense. L’une d’entre elles, la plus simple théoriquement et bien souvent la plus difficile à implémenter dans la pratique, est la conception d’un registre commun à l’ensemble des Origin. Ces dernières inscriraient au registre commun les jetons qu’elles auraient dépensés, après avoir consulté ce dernier pour s’assurer qu’une autre Origin ne l’aurait déjà fait. Hélas, cette méthode peut présenter des problèmes de vie privée, puisque ce registre devrait être largement consultable et contiendrait indirectement des statistiques de fréquentation des sites (une donnée métier sensible).
Une autre méthode tient dans la génération de challenges aléatoires, dont la probabilité de collision avec un autre challenge émis par une autre Origin serait négligeable. C’est la méthode recommandée par la spécification de Privacy Pass.
De manière étrange, dans le démonstrateur proposé par le LINC, le challenge n’est pas aléatoire, mais est la sortie d’une fonction monotonique : l’heure du serveur. L’heure ne peut constituer un bon moyen de prévention contre la double dépense, puisque le même challenge peut être alors émis par plusieurs Origin. Il s’agit surement d’une facilité utilisée par le développeur dans le cadre du démonstrateur. Dans une implémentation réelle, il serait néanmoins nécessaire de prévenir la double dépense à l’aide d’un challenge généré à l’aide d’un générateur de nombres aléatoires cryptographiquement sûr.
Dans cet article, nous avons étudié deux technologies pouvant être utilisées à des fins de contrôle d’accès en fonction de critères vérifiés par des tiers. Ces technologies prétendent pouvoir prouver à un tiers qu’un utilisateur remplit ces critères sans dévoiler d’informations personnelles. Les critères peuvent être variés, et sont extensibles : seuil d’âge, genre, niveaux de revenu, statut de santé, etc.
Privacy Pass, un protocole spécifié par un consortium informel sous l’égide de l’IETF, remplit cet objectif, sur le papier et dans certaines conditions d’implémentation.
De son côté, le protocole du LINC dit en “double anonymat” échoue maintes fois à protéger l’identité de l’individu, par erreur de conception ou sous la contrainte du cahier des charges du commanditaire. Cela est dû notamment à l’interactivité du protocole, et au rôle passif de l’utilisateur lors des échanges.
L’interactivité permet de relier nominativement l’utilisateur à une session sur le site qu’il souhaite consulter, et fuite ses fréquences de consultation, ce qui peut être une donnée de santé dans le cas d’une addiction (au jeu, à la pornographie, à l’alcool, etc.). Outre son aspect nocif pour la vie privée de l’utilisateur, cette interactivité se révèle totalement futile dans le combat contre l’émergence de marchés noirs de jetons d’autorisation permettant l’accès à des personnes ne remplissant pas les critères.
La passivité de l’utilisateur dans les échanges, quant à elle, permet de relier également l’identité de l’utilisateur à sa session sur le site visité, et donc potentiellement à ses préférences sexuelles. Elle permet également aux organismes attestant que l’utilisateur remplit un critère donné d’apprendre, dans certaines conditions, quel site est visité.
Finalement, il peut être intéressant de noter que le démonstrateur du LINC comporte une fragilité d’implémentation qui permet d’utiliser les jetons d’autorisations d’accès plusieurs fois, sur plusieurs sites distincts.
https://linc.cnil.fr/fr/demonstrateur-du-mecanisme-de-verification-de-lage-respectueux-de-la-vie-privee ↩︎ ↩︎
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-21 ↩︎ ↩︎
https://datatracker.ietf.org/doc/draft-ietf-privacypass-key-consistency/ ↩︎
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-rsa-blind-signatures-11 ↩︎
https://en.wikipedia.org/wiki/Linear-feedback_shift_register#Uses_in_cryptography ↩︎
https://fr.wikipedia.org/wiki/D%C3%A9pendance_%C3%A0_la_pornographie#ICD-11_(classification_de_l'OMS) ↩︎
https://www.ietf.org/archive/id/draft-ietf-privacypass-auth-scheme-08.html#name-redemption-context-construc ↩︎