Broken-by-Design/posts/double-anonymat.md

---
title: "Protocole d'autorisation par \"double anonymat\" pour la vérification d'âge respectueuse de la vie privée"
slug: proto-authz-porn
authors: "Florian Maury"
description: "Analyse comparative du protocole en double anonymat proposé par le LINC dans le cadre de la vérification de l'âge des utilisateurs, notamment de sites pornographiques en France, et de Privacy Pass"
date: 2023-02-23T00:11:00+00:00
type: posts
draft: false
layout: "singletoc"
categories:
- privacy
tags:
- privacy
- france
- security
- authz
- porn
lang: fr
---

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 LINC[^articlelinc].

[^articlelinc]: https://linc.cnil.fr/fr/demonstrateur-du-mecanisme-de-verification-de-lage-respectueux-de-la-vie-privee

> 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.

## Description informelle du protocole du LINC

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 LINC[^articlelinc], et le code source d'un
démonstrateur[^source_demonstrateur]. 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.

[^source_demonstrateur]: https://github.com/LINCnil/SigGroup

### Description informelle des acteurs

Pour résumer ce qui est indiqué dans ces ressources, le protocole du LINC est
composé de cinq acteurs ou types d'acteurs : 

* l'utilisateur et son navigateur (appelé Client dans le reste de cet article) ;
* le site requérant une vérification de l'âge du Client (appelé Origin dans le reste de
  l'article, pour faciliter la comparaison avec Privacy Pass ;
* des tiers certificateurs (appelés Issuers dans le reste de l'article) ;
* l'Autorité qui maintient à jour une liste de tiers certificateurs de confiance ;
* l'ouvreur (appelé Opener dans le reste de l'article) qui peut désanonymiser
  un tiers certificateur à partir d'une signature (nous reviendrons sur ce
  point).

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 :

* Client : l'utilisateur ; vous, moi ;
* Origin : un site pornographique, un débit de boisson, un site de jeu
  d'argent, un site de réservation pour un évènement (concerts, etc.) ;
* Issuer : le site des Impôts ;
* Autorité : l'État français ;
* Opener : l'État français.

### Description informelle des échanges

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.

### Description des propriétés de sécurité

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.

### Description des mécanismes cryptographiques mis en oeuvre

Ces informations sont majoritairement tirées du démonstrateur publié sur
Github[^source_demonstrateur].

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 [^pdc], 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 groupe[^groupsig], 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.

[^pdc]: https://crypto.stanford.edu/pbc/
[^groupsig]: https://fr.wikipedia.org/wiki/Signature_de_groupe

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.

## Description de Privacy Pass

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 WG[^ppwg].

[^ppwg]: https://datatracker.ietf.org/wg/privacypass/documents/

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)[^voprf] 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.

### Description des acteurs de Privacy Pass

Privacy Pass est composé de quatre rôles :

* Client : l'utilisateur et son navigateur ;
* Origin : le site web requérant la vérification du critère ;
* Attester : une entité en charge de vérifier le remplissage du critère par le
  Client ;
* Issuer : l'entité délivrant la preuve admissible par l'Origin que le Client
  remplit un certain critère, selon l'Attester.

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 :

* Origin + Attester + Issuer ;
* Origin + Issuer ;
* Attester + Issuer.

### Description des échanges

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 :

* le type de jeton d'autorisation acceptable par l'Origin et par lui-même ;
* l'identifiant tronqué à un octet de la biclé que l'Issuer doit utiliser pour
générer le jeton d'autorisation ;
* une valeur opaque.

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é.

### Description des propriétés de sécurité

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 ligne[^onlineverif] 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.

[^onlineverif]: https://datatracker.ietf.org/doc/draft-ietf-privacypass-key-consistency/

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.

### Description des mécanismes cryptographiques mis en oeuvre

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 : 

* 0x0001 : VOPRF[^voprf] (P-384, SHA-384)
* 0x0002 : Blind RSA[^blindrsa] (2048 bit)

[^voprf]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-voprf-21
[^blindrsa]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-rsa-blind-signatures-11

## Considérations de sécurité et de vie privée

Après cette longue présentation des deux protocoles, il est proposé de procéder
à l'analyse comparative de ces derniers.

### Lien entre identité du Client et session sur le site de l'Origin

#### Adresse IP de l'utilisateur

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.

#### Challenge

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 passive[^breaklfsr].

[^breaklfsr]: https://en.wikipedia.org/wiki/Linear-feedback_shift_register#Uses_in_cryptography

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.

#### Preuve

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.


#### Partitionnement de l'ensemble anonyme

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 groupe[^groupsig], 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.

### Futilité de l'interactivité comme méthode de prévention du marché noir

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é[^inserm] [^addictporn].

[^inserm]: https://www.inserm.fr/dossier/addictions/
[^addictporn]: https://fr.wikipedia.org/wiki/D%C3%A9pendance_%C3%A0_la_pornographie#ICD-11_(classification_de_l'OMS)

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 [^context] (Transport Layer Security).

[^context]: https://www.ietf.org/archive/id/draft-ietf-privacypass-auth-scheme-08.html#name-redemption-context-construc

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
Fixation[^sessfix]. Un tel partage pourrait même être aisément automatisé à
grande échelle grâce à une extension navigateur.

[^sessfix]: https://en.wikipedia.org//wiki/Session_fixation

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é.

### Problème de la double dépense

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.

## Conclusion

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.