Citation de: alf084 le Aujourd'hui à 13:35:36

Tu fais référence aux réglementations telles que l'obligation de conserver l'historique du trafic des abonnés pendant 12 mois ?

Je serais curieux de voir à quoi cela ressemble et quel niveau de détails ils ont 

Il faut pouvoir remonter au client si on te fournit IP source + port source.

Concrètement, il n'y a rien à garder quand l'IP est fixe, par contre, il peut y avoir des logs important pour les connexions derrière un CG-Nat.

Je suis en pleine réflexion pour définir ma stratégie de contournement face à ce contrôle numérique qui s'accélère à grand pas.

Pour moi les actions se limitent à un contrôle de l'age sur des plateformes néfastes pour des mineurs (l'Arcom va devoir faire une liste) et le blocage de site de piratages (principalement IP TV).

Il n'y a pas d'autres choses et pour la riposte graduée pour piratage en ligne, c'est la fin (le Conseil d'État a jugé illégal le traitement des données personnelles utilisé par l'Arcom pour traquer le piratage).

Il n'y a aucune volonté d'aller au-delà des problématiques concernant les mineurs (réseaux sociaux toxiques / sites pornographiques), piratage et blocage des appels / sms frauduleux.

Il n'y a aucune volonté d'aller au-delà des problématiques concernant les mineurs (réseaux sociaux toxiques / sites pornographiques) et piratage.

Sans vouloir enfiler mon "tinfoil hat", c'est une porte ouverte à beaucoup trop de chose et ce pourquoi les internautes Européen commencent à hausser le ton.

Il y a surement une très bonne volonté derrière de protection des mineurs, et peut-être même que dans une monde parfait, c'est en effet l'unique raison, mais encore une fois, sans jouer les complotistes, c'est assez facile de deviner d'autres intentions derrières ou, tout du moins, en ouvrir la possibilité. Une fois qu'on a les datas accessible, pourquoi ne pas les utiliser?

Si Mr X décide de payer et utiliser un VPN pour naviguer sur un site abc.com, il a possiblement (en réduisant au plus simple) deux raison:

- Le site est tout simplement innaccessible/bloqué dans son pays (pour x raisons)
- Il ne veut pas de traces de son passage sur un site/service. Qu'il y n'est aucunes traces, que cela soit en local, côté fournisseur, ou côté du site en lui même.

Pour cela, Mr X peut même payé son accès vpn en cash, crypto et j'en passe et même le fournisseur de VPN est incapable de savoir qui il est.

A partir du moment ou l'on demande a Mr X de donner un scan de son identité, tout s'éfondre.

La méthode du double anonymat permet de certifier à un site (ou un VPN si cela devrait être utilisé pour les VPN, ce qui n'est que spéculation pour le moment) sans donner d'autre information autre que la classe d'age (ex : +18 ans).

Confier ces fonctions à des acteurs différents rend possible une triple protection de la vie privée :
- celui qui fournit la preuve d’âge connaît l’identité de l’internaute mais ne sait pas quel site celui-ci consulte ;
- celui qui transmet la preuve d’âge au site peut connaître le site ou service que l’internaute consulte mais ne connaît pas son identité (dans la solution « idéale » développée plus bas, la preuve d’âge transite par l’utilisateur, ce qui permet un compartimentage entre les acteurs) ;
- le site ou service connaît l’âge de l’internaute (ou juste sa majorité) et sait qu’il consulte ce site, mais ne connaît pas son identité ni, dans certains cas, le service de vérification de l’âge utilisé.
Source : CNIL Vérification de l’âge en ligne : trouver l’équilibre entre protection des mineurs et respect de la vie privée

Le protocole repose principalement sur un concept cryptographique appelé « signature de groupe ». En termes cryptographiques, cette primitive permet à un utilisateur de signer anonymement au sein d’un groupe. Le terme « anonymement » est à prendre au sens cryptographique ici, au sens RGPD on parlerait de pseudonymat.

Étant donné une signature générée par un membre du groupe, il est impossible (hormis pour une autorité) de savoir quel membre l’a généré. Pour construire une telle primitive, nous combinons deux blocs fondamentaux en cryptographie :

- d’un côté des signatures numériques (qui permettent à quelqu’un de certifier une donnée et à quiconque de vérifier ensuite ce certificat) ;

- et de l’autre des preuves à divulgation nulle de connaissance (dites Zero-Knowledge ou ZK), qui permettent de prouver la connaissance d’un secret sans pour autant révéler ce dernier.

Grâce à la combinaison de ces primitives, une autorité peut générer une clé publique, ajouter des membres au groupe, en leur fournissant un certificat, valide sous la clé principale du groupe, de leur propre clé publique. Ensuite, les membres du groupe vont pouvoir signer des challenges à l’utilisateur, et ce dernier va pouvoir prouver qu’il possède une signature d’un challenge, par quelqu’un appartenant au groupe. De cette façon, les preuves ZK garantissent à la fois le pseudonymat de l’autorité qui a signé (via la propriété de ZK) et le fait que celle-ci est bien membre du groupe (via la propriété dite de soundness, c’est-à-dire que personne ne peut faire une fausse preuve). Ainsi, le site fournisseur de service est sûr de la validité de l’âge de l’utilisateur sans pour autant savoir qui l’a certifié.

Les schémas ci-dessous permettent de comprendre comment la preuve de faisabilité fonctionne :

Pour la personne, cette fonctionnalité puisse être « à sa main » :



Plus généralement, sur l’écosystème : les différents acteurs en présence et le système de gouvernance nécessaire à son fonctionnement.



Source : Laboratoire d'inovation Numériques de la Cnil, le 16 juin 2022 par Olivier Blazy, Jérôme Gorin, Martin Biéri et Côme Brocas

Pour donner un exemple de prestataire tiers de confiance, Yoti ID est en mesure de transmettre une classe d'age (exemple +15 ans) et uniquement cette information à un site qui le demande. Ton identité n'est pas dévoilée au site qui en fait la demande et Yoti ID ne sait pas sur quel site tu t'authentifies.

Bien sûr, cela nécessite d'avoir confiance dans Yoti ID, mais d'autres acteurs vont arriver.

Merci Vivien de l'explication d'un des procédé (je me doute qu'il va surement y'avoir plusieurs acteurs) mais c'est je pense aussi, sans jouer les complotiste encore une fois, très beau sur le papier et tout parfait, mais en vrai?

Quand on lis tous les soucis depuis que la vérification d'age est intégré dans d'autre pays/service, c'est très très loins de ce schéma parfait..

Ouais alors le double anonymat ça me fait bien rire... Je viens d'essayer vite fait un site qui utilise justement Yoti pour la vérification d'âge... Et l'identité du service est tranquillement passée à Yoti via le header "Referer".

Yoti fait payer le service, donc il faut forcément qu'il sache qui fait la demande.

La solution de la CNIL isole un minimum en passant par l'utilisateur, ce qui peut aussi éviter certains bugs d'implémentation (mais c'est plus contraignant).
Là le tiers certifié ne connait pas le service demandeur, donc il ne peut rien lui facturer : soit c'est gratuit, soit c'est l'utilisateur qui paye.

Mais même en vérifiant ces échanges indirects :
 - le challenge généré par le service : à part s'il est très court, il pourrait cacher des informations (identifiant du service ou du compte) qu'un tiers complice pourrait lire
 - signature du challenge : si c'est un partenaire unique type Yoti (et pas au choix de l'utilisateur), le service et le tiers pourraient s'être mis d'accord sur une signature plus courte (et des données chiffrées ajoutées derrière, l'ensemble aurait la taille de la signature attendue)

Donc pour faire mieux, par exemple :
 - l'utilisateur reçoit "challenge" du service
 - il choisit un nombre aléatoire "random", et calcule challenge2 = hash(challenge . random) : challenge2 n'est ni choisi par l'utilisateur (impossible de réutiliser des anciens challenges déjà signés), ni par le service (impossible d'y cacher des informations)
 - l'utilisateur transmet uniquement challenge2 au tiers, qui le signe
 - l'utilisateur vérifie la signature (exactement comme le service le ferait) pour s'assurer qu'elle ne comporte pas de données supplémentaires
 - l'utilisateur transmet challenge, random, et la signature de challenge2 au service (qui peut donc identifier le challenge qu'il avait donné, calculer challenge2 puis vérifier la signature)
Dans ce cas, ça me semble sécurisé, tant que le service et le tiers n'ont pas de canal d'échange parallèle (ce qui peut être limité en laissant le choix du tiers à l'utilisateur, comme proposé par la CNIL).