Archive for the ‘anonymisation’ Category

Sondages et votes

Vendredi, septembre 11th, 2015

Dans un article La Suisse pourrait imposer l’open-source pour le vote électronique de Numerama, il est de nouveau question de la mise à disposition du code source du programme sous forme de logiciel libre.

L’avenir du vote électronique ne fait aucun doute, seule sa réalisation pose problème aujourd’hui. Beaucoup de débats comparatifs et contradictoires ont lieux vis-à-vis de la pertinence du vote électronique et de la confiance que l’on peut apporter aux machines de vote et au processus dans son ensemble. Ces débats peuvent paraître très conservateurs mais ils sont néanmoins nécessaires puisque le vote est un acte fondamental de nos démocraties, c’est le moyen d’expression de chacun d’entre nous.

La confiance en ce genre de machine de vote et du code qui l’anime ne peut être assurée sans l’ouverture du code à minima en lecture. Il faut aussi connaître précisément l’environnement de compilation et d’exécution pour le code soit parfaitement reproductible. Et bien sûr, il faut être sûr ce c’est bien ce code qui a été utilisé et pas un autre.
Invoquer le secret industriel sur du code pour un processus parfaitement connu et un enjeu majeur de démocratie, c’est particulièrement malhonnête. Tout au plus une société éditrice peut-elle demander un droit de paternité et une restriction de commercialisation à son seul bénéfice. Mais il suffit à l’état qui fait la commande du code de demander, et payer, explicitement la libre diffusion ou la libéralisation complète du code.

Le code doit être capable dans son ensemble de permettre la centralisation des votes, l’anonymisation des électeurs ainsi que la vérification en temps réel et à postériori du décompte des votes. L’authentification de l’utilisateur devrait être le principal problème mais il apparaît que c’est en fait le décompte et sa vérification qui interpellent le plus souvent les détracteurs du vote électronique.

Un vote a un point de départ dans le temps et une fin à partir de laquelle le décompte des votes est considéré comme définitif.

L’anonymisation est aussi un problème pour la vérification de conformité du vote à postériori puisqu’elle casse le lien sûr entre le votant et le vote unitaire. On peut ainsi affirmer que le votant à voté (il a posé un papier et signé le paraphore) mais on ne peut pas le prouver à postériori (était-ce vraiment lui).
La capacité de multi-entité et la dissimulation de liens dans nebule permettent de résoudre ce problème.

Voici un scénario possible de vote avec les objets et liens de nebule :

  1. Pour un vote, une entité maîtresse du vote est générée. Elle est explicitement reconnue par les autorités comme telle. Son seul rôle est de générer les jetons de vote et de les attribuer aux électeurs.
  2. L’entité maîtresse du vote va générer autant d’objets jetons qu’il y a de votants. Ces jetons sont aléatoires et n’ont pas de relation directes avec les électeurs. Chaque jeton est en fait la partie publique d’un bi-clé cryptographique (RSA par exemple). La clé privée de chaque jetons est protégé par un mot de passe stocké dans un objet protégé par et pour l’entité maîtresse (dans un premier temps).
  3. Le jeton est en fait l’entité qui réalisera le vote via la clé privée. Chaque vote peut être vérifié par rapport au jeton, c’est à dire la clé publique.
  4. Pour chaque objets de clés privées de chaque jetons, l’entité maîtresse va partager le secret de chiffrement de l’objet contenant le mot de passe. Le lien entre objet chiffré et objet non chiffré est dissimulé, c’est à dire que c’est un lien de type c masquant le vrai lien.
  5. La clé privée de l’entité maîtresse est détruite. Il n’est ainsi plus possible de retrouver l’intégralité des relations en les jetons et les électeurs mais il est possible de vérifier que tous les électeurs ont reçus un lien dissimulé et de vérifier tous les jetons réalisant le vote.
  6. Pour un vote, une entité de décompte du vote est générée. Elle est explicitement reconnue par l’entité maîtresse Son seul rôle est de recueillir et de valider les votes. La période de vote démarre.
  7. L’électeur, c’est à dire l’entités votantes, va récupérer auprès de l’entité maîtresse du vote l’intégralité des jetons et des clés privées associées (et pas juste son jeton). Il va ainsi obtenir tous les liens dont le lien dissimulé le concernant. Via le lien dissimulé, il va savoir quel est la clé privée du jeton que l’entité maîtresse lui a attribué. Disposant de cette information il peut déprotéger à son profit l’objet contenant le mot de passe de la clé privée du jeton.
  8. L’électeur, mettant à profit la clé privée du jeton, peut réaliser un ou plusieurs votes, seul le dernier est pris en compte. Le vote consiste en un lien entre le jeton et le choix de vote dans le contexte de l’entité de décompte du vote (champs méta).
  9. L’entité de décompte du vote vérifie régulièrement auprès de tous les électeurs la présence de liens dont elle est le contexte. au fur et à mesure de la récupération des liens, elle se les approprie (signature du lien de vote).
  10. A la fin de la période de vote, la clé privé de l’entité de décompte du vote est détruite. Plus aucun vote ne peut être ajouté, modifié ou supprimé. Les votes comptabilisés sont ceux qui ont été signés par l’entité de décompte du vote.
  11. L’électeur qui souhaite rendre publique son vote a juste à prouver qu’il dispose du jeton en utilisant sa clé privée pour autre chose que le vote en relation avec sa véritable entité. Il peut aussi révéler le lien dissimulé que lui avait généré l’entité maîtresse du vote.

Un des aspects des liens dissimulés est qu’il est possible de les dissimuler pour plusieurs entités. Ainsi il est possible de générer une entité d’audit du vote à qui l’entité maîtresse partagera les liens dissimulés, de façon également dissimulé.L’entité d’audit devient capable à postériori de vérifier la bonne association entre jetons de vote et électeurs sans être elle-même capable d’émettre de nouveaux jetons.

Le sondage est moins contraignant et surtout peut être à choix multiples.

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

Samedi, août 22nd, 2015

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

Mardi, août 11th, 2015

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

Samedi, juin 27th, 2015

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 du temps et anonymisation

Mardi, février 10th, 2015

L’horodatage des liens est important pour leur interprétation. C’est particulièrement vrai pour démêler les suppressions. L’horodatage est placé dans les liens, ce qui veut dire que ce n’est pas l’objet qui est daté mais son usage.

On traite ici la suite des articles Horodatage, suite, Gestion temporelle partielle, Transfert de liens et de confiance, et cela entrera dans l’Etude du temps.

Vis-à-vis de l’anonymisation des entités, et surtout des personnes derrières, la gestion du temps nécessaire à l’horodatage peut poser problèmes.

Le problème c’est la synchronisation sur une source unique. Utiliser deux ou trois source réduit le problème mais uniquement de façon linéaire. Cette source unique sera régulièrement consultée et donc verra la source des demandes, notamment d’un point de vu adresses sur le réseau. Mais qui dit demande de synchronisation de temps ne veut pas dire présentation de l’entité qui le demande. La corrélation peut être faite après coup en comparant les marques de synchronisation de temps d’une entité avec les logs de connexion. Le risque ici est de récupérer la localisation d’une entité. Pour beaucoup de personnes, la connexion à son système d’information se résume à son ordinateur à la maison, son téléphone/tablette et à son travail. Avec la connexion depuis le domicile, on peut casser assez facilement l’anonymisation.

L’utilisation de plusieurs moyens informatiques pas forcément synchronisés entre eux en terme de temps introduit des problèmes pour calculer un décalage de temps et une dérive éventuelle. Dans ce cas, la relation entre entité et localisation ou entre entité et individu est plus dure à obtenir, mais pas impossible.

On peut utiliser la même entité source de synchronisation de temps mais en passant par des relais. Il faut dans se cas récupérer les dernières marques de l’entité de gestion du temps et le rejouer. En passant par une entité intermédiaire, on casse la corrélation possible entre les connexions et les marques de temps. C’est au prix d’une moins grand précision dans le calcul du décalage de temps.

Si on utilise un système de synchronisation des machines, tel que NTP, les machines se synchronisent sur des références de temps cohérentes. Noyé dans la masse des connexions, les synchronisations d’une entité ne permettent pas de lever son anonymat. Malheureusement, cela ne fonctionne que si les machines sont en réseau. Tout au plus peut-on se contenter d’une synchronisation irrégulière et espacée dans le temps. Dans ce cas, l’absence de marques de temps d’une entité ne permettra pas de calculer son décalage, et donc on en sera réduit à supposer qu’elle est à peu près à l’heure.

Dans tous les cas, il est possible d’utiliser en même temps une synchronisation précise par NTP et un calcul de décalage de temps. Des machines synchronisées devraient avoir un décalage proche de 0. Pour ne pas affaiblir l’anonymat des utilisateurs, il est préférable d’avoir une synchronisation NTP et d’utiliser les marques de temps mais horodatées sur son heure propre. Les marques de temps seront récupérées aléatoires chez les entités connues.

La gestion du temps va générer un trafic propre tant en réseau qu’en terme d’objets et de liens. Il faudra prévoir un nettoyage fréquent et à court terme de ces objets et liens avant qu’ils ne saturent les échanges entre entités.

Enfin, cela n’a peut-être pas trop d’importance à première vue mais c’est quand même une entorse à l’anonymisation, générer des marques de temps régulières pour permettre les synchronisations ne peut se faire que lorsque l’entité est déverrouillée. C’est à dire que l’on a des marques de temps que quand on est connecté, ce qui trahi les heures de présence effective mais aussi fait office de marqueur de présence. La parade est de ne faire des marques synchronisation de temps que… de temps en temps. Cette parade se fait au prix d’une perte de précision dans le calcul du différentiel de temps, surtout avec des machines multiples.

Entités multiples

Mardi, décembre 23rd, 2014

Dans la suite des réflexions sur Entités multiples, gestion, relations et anonymat, le développement de la librairie nebule en php continue en tenant compte de cette possibilité.

En gérant le mot de passe d’une entité dans l’objet (php) de cette entité, on peut avoir plusieurs entités déverrouillées à un instant donné. Et comme plusieurs entités sont potentiellement déverrouillées, lorsque l’on consulte un objet chiffré, il ne faut plus seulement regarder si l’entité courante est déverrouillée et donc peut le lire, mais il faut regarder dans tous les destinataires si une des entité n’est pas déverrouillée aussi. Une seule suffit pour déchiffrer l’objet et afficher son contenu.

Il faut cependant faire attention à ce que l’entité courante ait bien l’accès à l’objet chiffré avant de permettre son utilisation parce que cela dévoilerait immédiatement le lien de parenté entre les deux entités. Il est imaginable de basculer immédiatement d’entité courante sur une action de ce genre.

Si on souhaite une bascule complète sur une entité esclave sans interférence d’autres entités, il suffit de vider le mot de passe de tous les objets (php) des entités que l’on ne souhaite plus voir. Cela inclut aussi l’ancienne entité courante qui peut avoir été préalablement sauvegardée avec sont mot de passe pour une restauration ultérieure.

Une des applications de cette capacité multi-entité, c’est le cumule d’entité lors d’un Changement d’identifiant d’entité. Il est possible, le temps de migrer les liens, de pouvoir continuer à consulter les objets de l’ancienne entité tout en utilisant la nouvelle entité.

Entités multiples, gestion, relations et anonymat

Mercredi, octobre 8th, 2014

On peut raisonnablement penser que chaque personne, sauf problème, a une personnalité unique. Et donc qu’une personne a un comportement unique et un réseau sociale unique.

Mais la réalité n’est malheureusement pas aussi simple.
Ne prenons que l’exemple de l’individu employé dans une société. Cet environnement est à considéré comme différent de l’environnement de vie normal, c’est à dire chez soi, dans la vie privée. Au travail, nous avons des « amis imposés par l’employeur » qui forment un réseau social souvent fortement découplé du réseau social privé. Nous avons aussi des attitudes différentes, en phase avec les attitudes que l’entreprise attend de nous. Nous sommes en short à la maison, avachi devant la télévision alors que l’on est en costume 3 pièces au travail, bien assit devant son ordinateur. Les réseaux sociaux ainsi que les échanges avec les autres individus évoluent avec l’environnement dans lequel on se situe. Chacun de nous est unique mais chacun de nous adopte une pseudo-identité variable dans l’espace et le temps. Enfin, on mélange rarement les informations de ces différentes pseudo-identités. On parle rarement en détail de sa journée de travail avec des amis le weekend autour du barbecue.
Sur un réseau social numérique, comme Facebook ou Google+, imposer une identité unique est donc une vision réductrice de l’individu humain. En cherchant à n’avoir que des identités réelles des individus, on se coupe de toutes leurs identités annexes. Et une relation de travail fait typiquement d’une identité annexe.

On ne s’attardera pas ici plus longtemps sur la justification des entités multiples mais plutôt sur la technique et les possibilités que cela ouvre.

Les premières expériences avec les identités dans nebule montrent qu’un individu peut, bien évidemment, avoir plusieurs entités différentes. Chaque entité peut avoir une « vie » propre, c’est à dire un réseau social à part. Une entité peut mettre en place des entités esclaves, elles sont dans ce cas parfaitement autonomes. Elles restent autonomes même si elles sont tenues par une entité maitresse.
L’entité puppetmaster est le premier exemple d’entité maitresse. Il y a dans ce cas une idée de validation forte. On peut avoir d’autres types de relations entre entité maitresse et entités esclaves. On peut avoir des cas où la validation serait au contraire réduite voir dissimulée, dans les cas où l’anonymat est recherché.

Vis-à-vis de l’interface homme-machine, la notion même d’entités multiples n’est pas triviale. Sur nos systèmes d’information actuels, sur nos ordinateurs, téléphones, tablettes, etc… il est courant de disposer de plusieurs comptes utilisateurs. Mais on ne peut utiliser simultanément qu’un seul compte à la fois. Tout au plus peut-on changer temporairement d’identité (élévation de privilèges par exemple). Chaque action se fait sous une et une seule identité.
Si on utilise plusieurs comptes de messagerie ou comptes de réseaux sociaux numériques, il faut quitter un compte pour pouvoir accéder à un autre.

Dans une interface exploitant nebule, il est cependant possible de travailler de la même façon ou différemment.
On peut disposer de plusieurs entités et se connecter à une et une seule entité à un instant donné.
On peut aussi se connecter à une entité maitresse et basculer, immédiatement après, vers une des entités esclaves. C’est déjà fonctionnel dans sylabe. Il est même possible de revenir facilement vers l’entité maitresse pour éventuellement repartir sur une autre entité esclave. Ainsi on évolue dans des environnements isolés via des entités autonomes. De plus, la relation entre l’entité maitresse et les entités esclaves peut être masqué (offusqué).
Mais il est possible d’aller plus loin. On peut tout à fait imaginer exploiter simultanément plusieurs entités. Cela permet d’avoir une vue synthétique de plusieurs réseaux sociaux ainsi que des échanges associés. Le cloisonnement dans ce cas est invisible pour la consultation tout en restant potentiellement très fort entre chaque entités. En pratique, on pourrait voir les activités de tous les « amis » de toutes les entités esclaves que l’on contrôle même si chaque entité esclave n’a strictement aucun rapport ou aucun lien avec les autres entités esclaves. Il faut par contre définir une entité avec laquelle on agit par défaut, au risque de casser le cloisonnement des entités par des liens inappropriés. On peut même imaginer que des interactions avec un réseau social particulier se fassent avec l’entité esclave attaché au réseau en question, on conserve ainsi le cloisonnement des entités mais pas celui de l’information. En somme, c’est un peu ce que l’on fait déjà avec un logiciel client messagerie et plusieurs comptes de messagerie…

Facebook et l’anonymat

Mercredi, octobre 8th, 2014

Les positions bougent aussi du côté de Facebook. Dans la suite de l’article précédent sur Google+ et l’anonymat, c’est au tour du premier réseau social de faire des concessions sur la possibilité de créer des comptes anonymes… dans une certaine mesure.

Depuis le 1er octobre, il est possible d’utiliser un pseudonyme. Tout n’est pas encore permit mais l’avancée est de taille alors que la vie privée n’était clairement pas la priorité de Facebook. Et l’anonymat était même malvenu jusque là pour inciter les internautes à avoir de vraies relations d’amitié. Il était aussi quand même plus intéressant pour les publicitaires de disposer d’informations fiables sur les utilisateurs…

Depuis peu, une nouvelle messagerie est en cours d’élaboration, par Facebook, pour permettre des échanges volontairement anonymes. Un vrai retournement… ou une opportunité commerciale de plus…

CF :
http://www.lemonde.fr/economie/article/2014/10/02/les-pseudonymes-finalement-autorises-sur-facebook_4498801_3234.html
http://www.lemonde.fr/pixels/article/2014/10/08/facebook-va-lancer-une-application-permettant-des-echanges-anonymes_4502637_4408996.html

Téléchargement et pondération – activation

Mardi, août 19th, 2014

Suite aux réflexions sommaires de Téléchargement et pondération, la mise en place commence dans le code de la librairie.

Cependant, le fait de créer par défaut un lien de pondération pour une localisation peut poser problème. Les liens générés peuvent être exploités comme des traces de l’activité d’une entité. C’est une façon de savoir quand une personne, à qui appartient l’entité, est connectée et de suivre les connexions dans le temps.

Il y a deux parades à ça. La première, interdire par défaut les synchronisations sauf si c’est explicitement demandé. La deuxième, c’est de ne pas ajouter automatiquement la pondération aux localisations lors des synchronisations.

La première solution est plutôt à gérer du côté d’une application de type sylabe.

La seconde solution est à intégrer dans la librairie php sous la forme d’une option.

Nébuleuse sociétale et confiance – Chiffrement par défaut

Mercredi, juillet 16th, 2014

La relation entre les êtres humains est resté assez stable dans son contenu mais à beaucoup évolué dans sa forme avec la technique. Le la taille d’un village, d’une tribu, la dimension du réseau social d’un individu a fortement grandi et a cessé de coller à sa zone géographique proche. Mais il n’a pas forcément grossi pour autant, il ne s’est que dilaté. Il garde d’ailleurs une forme nébuleuse dense au centre et distendu en périphérie.
Le téléphone a accéléré la vitesse de transmission des informations et de fait a permis d’étendre encore plus la portée des échanges, et donc l’influence des individus. Cette extension a fini par atteindre sa taille limite, celle du monde.
Mais les échanges d’informations ne se limitent pas à l’influence, politique, des autres. On y retrouve des choses qui n’ont pas grand intérêt à première vue comme la correspondance familiale ou la propagation de la culture. Cependant, ces deux exemple ont une importance profonde dans l’identité de l’individu d’une part et de la société d’autre part.
Le réseau social individuel n’est plus depuis longtemps calqué sur son influence physique directe. Si il n’est pas évident de parler de réseau social d’un groupe d’individus, ou société, on peut quand même se raccrocher à son influence directe. Et l’influence des sociétés ne sont que rarement exactement calquées sur leurs influences physique directe, c’est à dire sur les frontières d’un pays.
Une société ne doit pas être vue comme une forme nébuleuse unique de relations sociales mais comme une forme nébuleuse sociétale composée d’une multitudes de formes nébuleuses entremêlées. Une société est composée d’une multitude de formes nébuleuses individuelles avec quelques structures communes, mais surtout, pour les individus, avec une majorité de liens au sein de la nébuleuse sociétale. Le nationalisme ou communautarisme, du point de vue du réseau social, sont des tentatives pour imposer des structures uniques fortes et donc de forcer la nébuleuse sociétale à se scinder en de multiples formes sous-sociétales. Il existe une multitude de formes sous-sociétales susceptibles de développer une forme de communautarisme puisqu’il est en pratique impossible d’avoir une nébuleuse individuelle approchant la forme nébuleuse sociétale dans son ensemble. Le nationalisme use de sa forme de nébuleuse sociétale pour revendiquer une influence physique y compris hors des frontières de l’état qui le définit à l’origine.
Le réseau Internet est un support d’information, il permet de diffuser la connaissance à tout un chacun. Mais ce n’est pas sont seul rôle, il permet aussi de relier les individus. C’est à dire qu’il sert de support universel à la forme nébuleuse des relations sociales d’un individu. Nous avons encore des échanges sociaux directs entre individus, instantanés, mais ils ne sont plus ni exclusifs ni même nécessaires ou systématiques.
Le projet nebule se doit donc de faciliter le partage de l’information, de la connaissance, mais il se doit aussi de faciliter les échanges sociaux entre individus. Le projet nebule doit être capable de coller au plus prêt de la nébuleuse de l’information d’un individu, mais aussi de la nébuleuse de son réseau social.

La messagerie telle qu’elle a commencée était un message manuscrit sur un support papier ou équivalent et pouvait mettre plusieurs mois pour arriver à destination… quand ça arrivait…
Aujourd’hui, un message traverse le monde en quelques secondes avec une très grande probabilité d’arriver à destination. Le plus long, c’est maintenant d’attendre que le destinataire ouvre son message. Tout le monde fait confiance à la messagerie électronique et à une bonne confiance dans les échanges postaux nationaux et internationaux.

Et puis il y eu Edward SNOWDEN.

La confiance, c’est la capacité du système à fonctionner tel que l’on s’attend à ce qu’il fonctionne et à être résistant aux tentatives de détourner son fonctionnement.
Là, subitement, on a une grosse crise de confiance. On se dit qu’on ne va peut-être pas laisser tous ses œufs dans le même panier. Le projet nebule peut sous cet éclairage paraître un peu trop intrusif et exclusif (des autres).

Cette crainte vis-à-vis du projet nebule est à la fois recevable, et non recevable.
Le projet sylabe, annexe de nebule, est une implémentation suivant les paradigmes actuels en terme d’échange de l’information, et surtout en terme de concentration de l’information. Il est conçu volontairement dès le début pour centraliser les données sur un serveur de l’Internet. C’est cette concentration sur une machine que l’on ne maîtrise pas qui pose de gros problèmes aujourd’hui. C’est cette concentration sur des machines chez des grosses sociétés au USA qui permet à la NSA (entre autres) de violer l’intimité numérique des individus sans raison valable. Et c’est fait de telle façon que les individus gardent confiance dans cette concentration de leurs données.

Mr SNOWDEN a cassé la confiance que nous avions dans la concentration de nos données, la confiance pour ces grosses sociétés américaines, et la confiance dans l’Internet même. Il a montré que quelque chose ne fonctionnait pas bien. Mais il l’a fait pour que ça s’améliore, pour que nous fassions les efforts nécessaires pour reconstruire l’Internet et la confiance que l’on attend de lui.

Le projet sylabe est donc un reliquat de ce passé. Mais il apporte quand même quelque chose pour le futur. Il centralise les données mais contient les graines de leur décentralisation complète.
Si tout le monde n’est pas prêt aujourd’hui à installer un serveur pour héberger ses données, on y arrive quand même de façon détournée. Certains installent des boîtiers NAS, c’est déjà une forme de réappropriation de ses données. Toutes les maisons ont une box qui fait office de centre multimédia, de NAS. La domotique arrive tout doucement (depuis 20 ans). Ainsi, une instance sylabe pourra être un jour implémentée facilement dans un boîtier pour non seulement héberger nos donnés mais aussi pour nous permettre d’échanger avec nos amis.
Le projet sylabe, une fois implanté ailleurs que sur des serveurs centralisés permettra la mise en place complète de la vision de la nébuleuse de nos informations, complètement décentralisée mais centrée sur nous.

Il reste à traiter le problème de l’anonymat. C’est en cours de définition et d’implémentation.
Cet objectif à part entière, dans le contexte actuel, nécessite qu’une entité puisse nativement et par défaut chiffrer tous ses objets et offusquer tous ses liens, ou presque tous. Cette possibilité sera intégrée rapidement dans le projet sylabe.

Google+ et l’anonymat

Mercredi, juillet 16th, 2014

Dans un article, le réseau social Google+ revient sur les restrictions de nommage de ses utilisateurs. Il va maintenant être possible de choisir des pseudonymes de façon à profiter du réseau social en ligne tout en permettant un certain anonymat.

Il était temps…

L’étape suivant serait de permettre à tout utilisateur de pouvoir nativement créer des pseudonymes partiellement autonomes. L’idée est en cours de mise en place sur le projet sylabe. La condition du succès est bien sûr que qu’un pseudonyme puisse avoir une vie propre, ses propres relations et groupes (cercles sur G+) et que l’on bascule de façon équivoque de l’entité principale vers un pseudonyme. C’est un bon moyen de répondre à des besoins d’anonymisation tout en facilitant la gestion de l’anonymisation par les vrais utilisateurs.
Il faudra aussi déterminé si un pseudonyme apparait clairement comme tel dans les utilisateurs ou si sa vraie nature reste cachée pour préserver son efficacité.
Bien sûr, il faudra garder à l’esprit que monsieur Google aura accès à toutes les entités, que ce soit les vrais utilisateurs ou leurs pseudonymes. Cela répond dans ce cas aux problèmes légaux pour pouvoir remonter, sur décision d’un juge, à la personne physique derrière un pseudonyme.

Lien de type c, précisions

Mercredi, juillet 9th, 2014

La documentation a été complétée pour le lien de type c :

Ce lien contient un lien chiffré. Il permet d’offusquer des liens entre objets et donc d’anonymiser certaines actions de l’entité.

Le champs HashSource fait référence à l’entité destinataire du lien, celle qui peut le déchiffrer. A part le champs de l’entité signataire, c’est le seul champs qui fait référence à un objet.

Le champs HashCible ne contient pas la référence d’un objet mais le lien chiffré et encodé en hexadécimal. Le chiffrement est de type symétrique avec la clé de session. Le lien offusqué n’a pas grand intérêt en lui même, c’est le lien déchiffré qui en a.

Le champs HashMeta ne contient pas la référence d’un objet mais la clé de chiffrement du lien, dite clé de session. Cette clé est chiffrée (asymétrique) pour l’entité destinataire et encodée en hexadécimal.

Lors du traitement des liens, si une entité est déverrouillée, les liens offusqués pour cette entité doivent être déchiffrés et utilisés en remplacement des liens offusqués originels. Les liens offusqués doivent être vérifiés avant déchiffrement. Les liens déchiffrés doivent être vérifiés avant exploitation.

CF : Documentation_-_nebule_v1.2 – Action_c_-_Chiffrement_de_lien

Anonymisation de lien – correction du registre

Mercredi, juin 11th, 2014

Voici une petite correction suite à l’article sur l’Anonymisation de lien.

Tant que l’on en est encore dans la mise en place du code pour gérer le lien de type c, une petite modification est réalisée sur le registre de ce type de lien.

Si on regarde la philosophie dans l’ordre des champs du registre des liens, l’objet méta est souvent une sorte d’opérateur entre deux objets. Cet objet méta peut souvent être vu comme annexe ou de valeur nulle dans certains cas. Le lien de type k contient notamment une entité destinataire qui peut consulter l’objet, et une clé de session chiffrée. On a ici le choix pour l’objet méta entre l’entité et la clé de session. J’opte pour la clé de session.

Voici donc le nouveau registre de lien de type c :

Signature_Signataire_TimeStamp_c_EntitéCible_LienChiffré_CléSession

 

Anonymisation de lien

Vendredi, juin 6th, 2014

MàJ 11/06/2014 : le registre de lien a été changé : Anonymisation de lien – correction du registre

Dans la version 1.2 de nebule, le nouveau lien de type c a pour rôle d’anonymiser les actions des entités. Cette anonymisation doit permettre de cacher la relation entre l’entité d’un côté et ses actions sur des objets de l’autre. Il faut donc cacher non seulement le type de lien mais aussi que le lien relie ces objets. C’est la suite des articles liaison secrète et suite de fin 2012.

Il faut malgré tout permettre la libre diffusion des liens générés pour que ceux-ci soient transmis sur un réseau public et ouvert notamment via des entités relais. Cette transmission est assurée par le fait que l’entité signataire apparaît en clair puisqu’il faut être capable de vérifier la signature du lien.

L’anonymisation consiste en l’offuscation du vrai lien dans un lien caractéristique, le lien de type c. Le vrai lien, celui qui a un intérêt, est chiffré et intégré au lien de type c. Pour que la vérification des liens soit la plus simple possible, elle ne doit pas gérer le lien offusqué différemment. Le registre du lien doit donc être identique aux autres liens à l’exception de l’action et ce registre doit passer les mêmes tests de validation.

Si le lien offusqué mentionne l’entité signataire, il doit peut-être pouvoir être lisible par une autre entité. C’est le cas si l’on souhaite partage un lien de la même façon que l’on pourrait souhaiter partager un objet. Il faut donc que le lien offusqué fasse aussi référence à l’entité destinataire. L’entité destinataire, ou entité cible, qui peut être la même que l’entité signataire, sera positionnée dans le registre en 5ème position. Cette place est habituellement occupée par l’objet source.

Il faut prévoir une clé de session (un mot de passe) pour chiffrer le lien (chiffrement symétrique) parce que celui-ci n’a pas forcément une taille adéquate pour le chiffrement asymétrique. La clé de session chiffrée doit être encodé en hexadécimal. La clé de session chiffrée sera positionnée dans le registre en 6ème position. Cette place est habituellement occupée par l’objet destinataire.

Enfin, le lien offusqué, chiffré, doit être encodé en hexadécimal. Le lien offusqué sera positionné dans le registre en 7ème position.

Voici donc le registre de lien de type c :

Signature_Signataire_TimeStamp_c_EntitéCible_CléSession_LienChiffré

Le lien à offusquer est chiffré (symétrique) avec la clé de session et ajouté en position 7. La clé de session est chiffrée (asymétrique) avec la clé publique de l’entité cible et ajoutée en position 6. L’entité cible est ajoutée en position 5.

On ne peut dans ce cas pas offusquer la relation entre l’entité signataire et l’entité cible. La présence de la première entité est indispensable pour vérifier la signature du lien. La présence de la seconde entité est nécessaire pour que le lien puisse lui parvenir et lui indiquer que le lien la concerne. Le reste du lien est complètement offusqué.

Lors du traitement des liens d’un objet, Il faut à la fois consulter les liens de l’objet mais aussi consulter les liens offusqués attachés à l’entité courante. Ensuite seulement peut se faire le nettoyage des liens marqués supprimés.
On remarquera que cette façon de procéder permet bien sûr de ne pas révéler certains liens, mais aussi de marquer secrètement comme supprimés des liens alors qu’ils sont encore publiquement reconnus comme valides. Dans le même ordre d’idé, on peut camoufler un objet sous un type mime assez banal mais offusquer un lien dévoilant sa vraie nature. Un vrai terrain de jeux de cache cache en perspective !

Il reste un autre aspect de l’anonymat. Il peut être nécessaire de permettre des échanges entre deux entités sans qu’il n’y ai de lien entre elles, même de liens offusqués. Ce problème peut être résolu avec la génération d’entités esclaves le temps de quelques échanges. Il n’est pas possible dans ce cas de rattache directement ces entités esclaves à notre entité principale ni d’héberger cette entité sur son serveur personnel sous peine de dévoiler immédiatement la relation entre les deux. Il faut aussi prévoir un mécanisme pour que des entités puissent attendre des liens d’entités inconnues tout en étant capable de vérifier ces liens. Une fois le contact établit, il devient aisé, via l’offuscation de liens, de prouver sa véritable identité, c’est à dire de faire un lien entre entité esclave et entité maître. Il y a encore de la recherche à faire à ce niveau…

Modification de la librairie php vers la version 1.2 des liens

Dimanche, mai 18th, 2014

La librairie en php intègre maintenant les spécificités de la version 1.2 lors de l’écriture des liens par la fonction _l_wr.

L’écriture des liens se fait aussi sur l’entité signataire avec la prise en compte de la spécificité du lien de type c lors de l’écriture. Lorsque c’est un lien de type c, seule l’objet de l’entité signataire du lien reçoit le lien. Ce fonctionnement risque encore de changer en fonction des réflexions autour de ce type de lien.

Mise en place de la nouvelle version dans la librairie php

Jeudi, mai 15th, 2014

Le code de la librairie en php génère maintenant les entêtes de liens en version 1.2.

Cela n’a pas d’autre influence aujourd’hui. C’est déclaratif.

Le code sera adapté rapidement pour ajouter les liens au suivi des entités. Puis plus tard l’offuscation des liens sera implémentée.

Cela n’a pas d’impact sur le comportement de sylabe notamment.

Nouvelle version nebule v1.2 – lien de type c

Samedi, mai 10th, 2014

Comme nouveauté de la version 1.2, il y a la possibilité d’offusquer les liens afin de renforcer l’anonymisation des entités.

Pour cela, un nouveau type de lien vient d’être ajouté à la documentation : Action c – Chiffrement de lien
Autrement dit, c’est un lien de type c.

Il n’est pas encore pris en compte dans le code. Sa forme exacte n’est pas encore figée.

Nouvelle version nebule v1.2

Jeudi, mai 8th, 2014

Ça faisait quelques temps que ça mijotait. Voici donc venir la nouvelle version de nebule. Nous passons à la version 1.2 .

Une nouvelle page technique sur le wiki vient d’être créée : Documentation – nebule v1.2

Les ajout prévus pour cette nouvelle version :

  1. Modifier le comportement dans le tri des liens par rapport aux objets concernés. Désormais un objet aura aussi en liens attachés ceux qui contiennent le champs signataire=objet. En pratique, cela ne concerne que les entités. Le gain attendu est de faciliter la diffusion des actions des entités.
  2. Permettre l’offuscation de liens par la mise en place d’un nouveau type d’action. Le gain attendu est de renforcer l’anonymisation.

Tous les codes vont progressivement être modifiés pour intégrer cette version.