612 lines
33 KiB
Markdown
612 lines
33 KiB
Markdown
|
---
|
||
|
|
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.
|