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…

Cosignature – orientation

Dans la continuité de la réflexion sur la cosignature et suite.

Une des possibilités que doit permettre la cosignature, c’est que l’on puisse créer une signature (ou assimilé) valide alors que les différentes personnes (et leurs entités) ne sont pas réunies en même temps au même endroit pour réaliser cette signature commune.

Le système classique pour résoudre la cosignature consiste en la répartition du secret suivant le schéma de seuil de Shamir.

Cette solution de partage du secret n’est pas suffisante pour deux raisons.

Pour commencer, cela veut dire que l’on n’a toujours qu’un seul secret mais qu’il est répartit, dilué, entre plusieurs entités. Lorsque l’on veut faire une signature, il faut réunir un minimum de ces entités au même endroit pour accéder au secret qui permettra la signature. A ce moment, le secret est extrêmement vulnérable.
Il faut réaliser une sorte de cérémonie des clés pour cela.

Enfin, la génération du secret est réalisé par un seul équipement et ensuite répartit. Il faut ici aussi une cérémonie des clés avec tous les porteurs d’une partie du secret. Si il n’est pas possible de réunir tout le monde, une partie du secret doit être transmis de façon sûr vers le porteur concerné. Mais il ne peut pas dans ce cas garantir par lui-même que personne n’a copié sa partie du secret. Et surtout il ne peut garantir que personne n’a volé le secret complet lors de la cérémonie des clés.

Donc, il faut que chaque porteur génère sa partie de clé, on génère un bi-clé qu’il garde, et dont il peut garantir la confidentialité. Ensuite, il reste à réaliser le mécanisme intermédiaire qui permet, en ne connaissant que les clés publiques des porteurs, de valider une pseudo signature réalisée par chacun des porteurs. Une pseudo signature qui n’impose une présence ni spatial ni temporelle des porteurs.

Liens :
https://fr.wikipedia.org/wiki/Partage_de_cl%C3%A9_secr%C3%A8te_de_Shamir
http://www.kilomaths.com/2010/07/partage-de-secret/

Sync flood

La possibilité de transmettre un objet à une entité de façon protégé ou non se fait via la possibilité pour une entité (destinataire) de se synchroniser sur les les autres serveurs. Elle récupère ce qu’on lui transmet. Et elle peut en même temps synchroniser tous les objets dont elle aura besoin.

Ici, la synchronisation signifie la récupération des informations (et du contenu) de sa propre entité mais aussi des autres objets sur des serveurs distants.

Une attaque possible est le débordement de la synchronisation (Sync Flood) par une grande quantité de liens qui font références à un des objets synchronisés.

Ce débordement peut être fait directement par une entité que l’on connaît ou indirectement par l’intermédiaire d’un relais, même si l’entité source des liens n’est pas reconnu par l’entité destinataire.

Il faudra donc prévoir dans les fonctions de synchronisation des mécanismes de limitation du nombre de liens synchronisés. Ces limitations peuvent être différentes en fonction du type de lien. Et en fonction du type de lien, on peut ne garder que les premiers ou que les derniers liens téléchargés. Par exemple, il vaut mieux ne garder que les premiers liens de type l alors que l’on privilégiera les derniers liens de type f, u ou x. Il faut aussi mettre un quota sur le nombre total de liens que l’on accepte de télécharger pour éviter un engorgement de la mémoire.

Un débordement réussi peut entraîner un fort ralentissement dans l’affichage et le traitement des objets concernés.

Libervia

Dans les projets qui ont un peu les mêmes but que nebule, voici le projet Salut à Toi. Un financement participatif est en cours pour Libervia, une interface web de SàT. Libervia est à SàT ce que sylabe est à nebule.

L’ensemble fonctionne par dessus le protocole XMPP et son système d’extensions XEP. Le programme réutilise un protocole solide et ouvert. Mais il est dépendant de serveurs sur internet. Un client peut facilement changer de serveur en cas de problème mais son adresse reste attachée au serveur d’origine et elle est donc perdu lors du changement. Ce protocole d’échange permet à tout le monde de créer son propre serveur et d’échanger avec tout le monde.

Le chiffrement et l’anonymisation sont des propriétés liées au protocole utilisée, ouvert et connu. Rien à dire.

On peut aussi mettre en place un serveur non relié à internet, mais il n’y a aucun mécanisme de partage de données entre ce serveur isolé et le reste des serveurs, hors copié/collé à la main par fichiers. C’est sur ce point que nebule présente un avantage, il permet de transférer des données via des passerelles (air gap) tout en conservant les informations annexes aux données comme les actions ou les destinataires par exemple.