Anonymisation/dissimulation des liens

Il y a déjà une série d’articles en 2012 sur la Liaison secrète (et suite), puis en 2014 sur l’Anonymisation de lien (et correction du registre de lien), et enfin en 2015 sur la Dissimulation de liens, multi-entités et anonymat et l’Exploitation de liens dissimulés.

On trouve dès 2015 un schéma d’implémentation d’un lien dissimulé (offusqué) et le mécanisme cryptographique utilisé :

20150627-nebule-schema-crypto-lien-c

Mais la mise en pratique ne suit pas alors que la bibliothèque nebule en php orienté objet est prête à reconnaître les liens dissimulés.

Parce qu’en pratique, il ne suffit pas juste de générer ces liens et de les lire, il faut aussi les stocker de manière à pouvoir les retrouver tout en gardant des performances acceptables lors du passage à l’échelle.

Comme l’anonymisation attendue nécessite la mise en place d’un minimum de déception vis-à-vis d’un adversaire, il n’est pas possible de stocker les liens dissimulés dans les liens des objets concernés. Cela casserait presque immédiatement la confidentialité du lien dissimulé parce que les objets ont souvent chacun des rôles propres et donc des places privilégiées dans les liens qui servent aux usages de ces objets.

Les deux seules informations que l’on ne peut dissimuler sans bloquer le transfert et l’exploitation des liens dissimulés, c’est l’entité signataire et l’entité destinataire (si différente). Donc le stockage ne peut se faire que de façon connexe à des deux entités. Si ce n’est pas le cas les liens ne pourront pas être retrouvés et utilisés lorsque nécessaire.

Prenons le cas d’une entité qui décide de dissimuler la grande majorité de son activité, elle va donc dissimuler tous les liens qu’elle génère (ou presque). Là où habituellement le stockage des liens aurait été réparti entre tous les objets concernés, du fait de la dissimulation ils vont tous se retrouver attachés à un même objet, l’entité signataire. Cela veut dire que pour extraire un lien de cette entité il va falloir parcourir tous les liens. Cela peut fortement impacter les performances de l’ensemble.
Et c’est aussi sans compter le problème de distribution des liens parce que l’on les distribue aujourd’hui que vers les objets source, cible et méta… et non sur les entités signataires. L’entité destinataire est dans ce cas naturellement desservie directement, est-ce un problème si l’entité signataire ne l’est pas ?
Une autre méthode pourrait consister à créer un objet de référence rattaché à l’entité et spécifiquement dédié à recevoir les liens dissimulés. Mais les liens dissimulés ne contenant pas cette objet de référence, on doit créer un processus plus complexe pour la distribution des liens tenant compte des entités signataires et destinataires.
On peut aussi mettre tous les liens chiffrés dans les liens d’un objet c puisque c’est le type de lien après dissimulation. Mais cela veut dire que tous les liens dissimulés de toutes les entités se retrouvent au même endroit. On ne fait que déplacer le problème de la longue liste des liens à parcourir.
Enfin on peut rester sur une des premières idées qui consiste à stocker des liens dissimulés non plus dans la partie du stockage dédié au liens mais directement dans un objet. Le défaut de cette méthode est qu’à chaque nouveau lien dissimulé généré, il faut refaire un nouvel objet avec une novelle empreinte… et donc un nouveau lien pour le retrouver.

On rejoint le problème de la persistance des données dans le temps, de leurs objets et liens associés. Une solution déjà proposée, mais non implémentée, consiste à organiser un nettoyage par l’oubli des objets et des liens dans le temps en fonction d’une pondération.

Pour commencer à expérimenter, les liens dissimulés seront stockés uniquement avec l’entité destinataire. Cela ne remet pas en cause la distribution actuelle des liens. On verra à l’expérience comment gérer un flux massif de liens et son impact sur les performances.

Attribuer des propriétés aux autres entités

Je viens de voir que dans Google Plus on peut ajouter des coordonnées à une autre personnes. Celles-ci restent confidentielles, c’est à dire juste connues de soi-même… et de Google. C’est un peu intrusif quand même puisque Google peut connaître les coordonnées d’une personne alors qu’elle ne les a pas volontairement publiées.

Dans nebule, on peut faire la même chose puisque l’on dérive d’une entité une propriété. Mais on en reste maître et, si les liens sont masqués, cela reste complètement privé. Même l’entité qui en fait l’objet ne le sait pas. La différence, c’est que on est le seul ‘strictement’ à connaître cet ajout de propriété et cela n’apparaît pas dans une base de donnée d’une grande société que l’on ne maîtrise pas.

Exploitation de liens dissimulés

Dans l’article sur la Dissimulation de liens, multi-entités et anonymat, on a vu comment implémenter des liens dissimulés dans d’autres liens.

Ici, on va apporter quelques précisions pratiques.

Déjà, un lien dissimulé va apparaître avec une entité signataire et une entité destinataire du lien. On a vu que c’était le minimum vital pour que cela fonctionne et que l’on puisse partager les liens même si cela implique de travailler sur les entités pour parfaire l’anonymisation. Il y a le cas particulier du lien dissimulé pour soi-même, dans ce cas l’entité signataire est aussi l’entité destinataire.

Lorsque l’on regarde les liens d’un objet, on va voir tous les liens non dissimulés. Si une entité est déverrouillée, il faut en plus parcourir tous les liens de type c de l’objet de l’entité pour en extraire les liens dissimulés relatifs à l’objet que l’on regardait. Dans le cas de multiples entités esclaves d’une entité maîtresse, il faut faire de même pour extraire tous les liens dissimulés pour toutes les entités accessibles. Il faut veiller dans ce cas à ce que l’interface montre clairement qui est l’entité concernée pour éviter toute confusion de l’utilisateur.

Dissimulation de liens, multi-entités et anonymat

La dissimulation de lien tel que prévu dans nebule n’est que la première partie permettant l’anonymisation des échanges entre entités.

Voir les articles précédents :
Liaison secrète et suite ;
Nouvelle version v1.2, Anonymisation de lien et correction du registre ;
Lien de type c, précisions ;
Entités multiples, gestion, relations et anonymat et Entité multiples ;
Nébuleuse sociétale et confiance – Chiffrement par défaut

Cette dissimulation d’un lien se fait avec un lien de type c. On a bien sûr dans le registre du lien visible l’entité qui génère ce lien, l’entité signataire. Et on a l’entité destinataire qui peut déchiffrer ce lien dissimulé et en extraire le vrai lien. Et comme dans la version publique de ce lien on a à la fois l’entité source et l’entité destinataire qui sont visibles, il n’y a pas d’anonymat. Ce type de lien permet juste de dissimuler l’usage d’un objet.

2015.06.27 lien c

Un lien dissimulé ne peut pas contenir un autre lien dissimulé. On interdit donc les multi-niveaux de liens dissimulés qui seraient un véritable calvaire à traiter.

Un lien peut être dissimulé pour soi-même. C’est à dire que l’entité signataire est aussi l’entité destinataire.

Si un lien doit être dissimulé pour plusieurs destinataires, il faut générer un lien pour chaque destinataire. La seule façon de réduire le nombre de liens pour un grand nombre de destinataires est d’utiliser la notion de groupe disposant de son propre bi-clé. Ce type de groupe est pour l’instant purement théorique.

Ce maintien comme public des entités sources et destinataires est une nécessité au niveau du lien, c’est une des bases de la confiance dans les liens. Pour que le lien puisse être validé et accepté par une entité ou retransmit par un relais, l’identification des entités est incontournable. Et donc avec l’identification nous avons aussi l’imputabilité et la non répudiation.

Si on veut assurer de l’anonymat pour les entités, puisque l’on ne peut pas travailler au niveau du lien, il faut travailler au niveau de l’entitié. On va dans ce cas travailler sur la notion de déception, c’est à dire faire apparaître des entités pour ce qu’elles ne sont pas ou tromper sur la nature des entités.
L’idée retenu consiste, pour chaque entité qui souhaite anonymiser ses échanges avec une autre entité, à générer une entité esclave avec laquelle elle n’a aucun lien. Ou plutôt, le lien d’entité maîtresse à entité esclave est un lien dissimulé pour l’entité maîtresse uniquement. Ici, personne à par l’entité maîtresse ne peut affirmer juste sur les liens que l’entité esclave lui est reliée.
Lorsque l’on veut échanger de façon anonyme, on transmet à l’entité destinataire l’identifiant de l’entité esclave, et vice versa. Cette transmission doit bien sûr être faîte par un autre moyen de communication ou au pire par un seul lien dissimulé.

L’anonymisation complète est donc la combinaison des liens de dissimulation de liens et d’une capacité multi-entités des programmes.

La dissimulation est en cours d’implémentation dans sylabe en programmation php orienté objet. Mais le plus gros du travail sera à faire dans la librairie nebule puisque c’est elle qui manipulera les liens et présentera ceux-ci à l’application, c’est à dire sylabe, dans une forme exploitable. L’application n’a pas à se soucier de savoir si le lien est dissimulé, elle peut le lire ou elle ne peut pas. Tout au plus peut-elle afficher qu’un lien est dissimulé pour information de l’utilisateur.
La capacité multi-entités de sylabe est maintenant beaucoup plus facile à gérer en programmation php orienté objet. Mais il reste à implémenter la génération des entités esclaves avec dissimulation de leur entité maîtresse.

Une autre dimension n’est pas prise en compte ici, c’est le trafic entre les serveurs pour les échanges d’informations. Il faudra faire attention à la remontée possible aux entités maîtresses par leurs échanges.

Enfin, pour terminer, aujourd’hui c’est la course au chiffrement par défaut de tous les échanges pour tout un tas de programmes et services sur Internet. Ce chiffrement par défaut est bon pour l’utilisateur en général. Et il masque dans la masse les échanges pour qui la confidentialité est critique. Ainsi il ne suffit plus d’écouter le trafic chiffré pour retrouver ses ennemis.
Mais cette logique est perverse. Le chiffrement par défaut est une aberration, un remède de cheval posé en urgence faut de mieux. Nous avons besoin d’échanger aussi des choses publiquement, comme sur un forum ou dans la presse. Nous ne devrions pas avoir des outils de communication tout chiffré et d’autres tout public, chaque outil devrait permettre les deux et clairement indiqué ce qui est protégé de ce qui ne l’est pas…

Gestion locale et globale des paramètres

Pour l’instant, les paramètres de configuration de nebule et de sylabe se font via un fichier de configuration sur le serveur.

Il sera possible plus tard de permettre la configuration de certains paramètres de façon globale, c’est à dire via un objet dédié.
Tous les paramètres ne pourront pas être globaux, à définir.

Comme d’habitude, le contenu pourra être public et/ou privé.

On peut déjà prévoir qu’un paramètre public sera mal défini et surchargé par le même paramètre mais privé. C’est une forme de défense par déception.