Catégorie : liens

Entités de recouvrement – configuration

Suite des articles Entités de recouvrement et implémentation.

L’objet de référence de définition des entités de recouvrement est l’objet contenant :

nebule/objet/entite/recouvrement

De nouvelles options permettent de gérer la prise en compte des entités de recouvrement par la bibliothèque nebule en PHP :

  1. permitRecoveryEntities (boolean, critical) : commutateur global d’activation des entités de recouvrement via les liens des autorités strictement locales. Par défaut à false.
  2. permitRecoveryRemoveEntity (boolean, careful) : commutateur qui permet à une entité de supprimer le partage de la protection d’un objet avec une entité de recouvrement. Par défaut à false.
  3. permitInstanceEntityAsRecovery (boolean, critical) : commutateur de définition de l’entité instance locale comme entité de recouvrement. Outrepasse les liens. Par défaut à false.
  4. permitDefaultEntityAsRecovery (boolean, critical) :commutateur de définition de l’entité par défaut comme entité de recouvrement. Outrepasse les liens. Par défaut à false.

Toutes les options sont en lecture seule, c’est à dire que les liens d’options ne sont pas pris en compte. Au besoin, ces options doivent être modifiées dans le fichier d’environnement.

A false, par défaut, la première option désactive complètement la détection des entités de recouvrement et le mécanisme de partage de protection des objets pour les entités de recouvrement.

La deuxième option, si à true, permet à une entité de supprimer le partage de protection à une entité de recouvrement particulière. Cette action doit être faite après la protection, réalisée systématiquement, et sur tous les objets protégés un par un. Cette option va faire disparaître le bouton de suppression de partage de protection dans les affichages, mais elle est aussi vérifiée lors de la suppression effective du partage de protection d’un objet si l’utilisateur tente la suppression de force.

Le lien de déclaration d’une entité de recouvrement a la forme :

  • action : f
  • source : entité instance locale, par exemple = 3af39596818c1229d7a3d08b9f768622903951305df728609a68a2957f7f3882
  • cible : entité de recouvrement, par exemple = 19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57
  • méta : objet de référence de recouvrement

La désactivation est un lien de type x.

Les liens doivent être signés de l’entité instance locale ou de l’entité par défaut en fonction des options de permission.

Entit̩s de recouvrement Рimpl̩mentation

Dans le précédent article sur les Entités de recouvrement qui date de plus de 6 mois, il était question de l’implémentation du mécanisme dans le code. Jusque là la liste des entités de recouvrement était renvoyée vide.
Ce mécanisme peut être une contrainte légale dans certains pays mais ce peut être aussi un moyen d’assurer plus sereinement la disponibilité des données sans remettre en question significativement la confidentialité de celles-ci. Sa portée est strictement local et ne doit pas devenir un comportement global sous peine de rompre la confiance dans l’ensemble du code de nebule.

La prochaine version de la bibliothèque nebule en PHP intègre le code nécessaire à la détection des entités marquées localement comme entités de recouvrement et le code qui se charge de dupliquer la protection des objets pour ces entités.

La définition des entités de recouvrement est purement locale et est attachée à l’entité instance locale. La détection d’entité de recouvrement se fait sur un lien de type f entre chaque entité définie comme entité de recouvrement et l’entité instance locale. Le champ méta du lien est l’objet de référence contenant nebule/objet/entite/recouvrement. Seuls les liens des autorités strictement locales sont pris en compte, c’est à dire à l’exception du puppetmaster, du maître de la sécurité et du maître du code.

La duplication de la protection se fait au niveau de la fonction (unique) de protection d’un objet setProtected(). Afin d’éviter la suppression du partage de protection avec une entité de recouvrement, la fonction cancelShareProtectionTo() ne supprime pas ce partage si l’entité est dans la liste des entités de recouvrement.
Afin de ne pas perturber l’utilisateur, les applications affichent tous les partages de protection mais n’affichent pas le bouton correspondant pour ces entités de recouvrement.

Les applications option, sylabe et klicty permettaient déjà l’affichage des entités de recouvrement même si elle était vide. Ces affichages ont été améliorés afin d’afficher en plus l’entité autorité locale qui a activé l’entité comme entité de recouvrement. Le but est d’avoir un mécanisme qui peut être contraignant et indiscret mais dont le fonctionnement doit être ouvert et loyal pour maintenir la confiance de l’utilisateur.
L’application option est maintenant le centre de gestion des entités de recouvrement. Il est possible, lorsque l’on déverrouille l’entité instance de serveur, d’ajouter ou de retirer des entités à la liste. Les autres entités ne peuvent faire que de l’affichage. Si un lien est généré par une autre entité, il est ignoré.

Renforcement de la lecture des objets

Dans la bibliothèque nebule en PHP orienté objet et dans certaines applications, un certain nombre de fonctions lisent le contenu des objets soit directement soit via la fonction getContent() de l’instance Object des objets. Toutes les lectures de contenus d’objets et de liens se font via la classe io de la bibliothèque et non directement par des fonctions de PHP de lecture de flux, de lecture directe. Les fonctions de la classe io ne font pas d’opérations cryptographiques, donc aucune vérification n’est possible à ce niveau.

Dans la bibliothèque se trouve aussi la fonction checkConsistency() pour vérifier le contenu d’un objet. Deux différences existent entre les deux fonction :

  1. La fonction getContent() lit des données et vérifie si l’empreinte est bonne sauf si l’objet est trop grand. Si l’objet est trop grand, un argument $permitTruncate permet de ne pas rejeter le contenu de l’objet si il est trop grand. Pour les petits objets la vérification se fait dans tous les cas. La limite d’un objet petit ou grand est définie par l’option ioReadMaxData. Si l’empreinte ne correspond pas, le contenu n’est pas conservé et un contenu vide est renvoyé à la fonction appelante. La fonction checkConsistency() ne renvoie pas de données mais vérifie juste l’empreinte, le résultat booléen renvoyé et négatif ou positif.
  2. La fonction getContent() ne supprime pas un objet si l’empreinte n’est pas bonne. La fonction checkConsistency() vérifie l’empreinte et, si l’empreinte n’est pas bonne, supprime l’objet via une fonction de la classe io.

Il est difficile de prendre une décision de suppression d’un objet parce que peut-être que l’algorithme de prise d’empreinte n’est pas reconnu par la machine sur laquelle tourne l’instance serveur. En cas d’absence de possibilité de vérification comme un type d’empreinte inconnu ou un objet trop grand, il faut renvoyer un contenu vide ou résultat négatif mais il ne faut pas supprimer l’objet. Quoique dans un mode paranoïaque, il faut peut-être prévoir de supprimer tout objet non vérifiable, à voir.

Pour commencer l’argument $permitTruncate n’a pas de raison d’être, il est contre productif parce qu’il affaibli l’ensemble du système. Il va être supprimé et les applications qui affichaient un objet avec un message comme quoi l’objet est trop gros vont afficher un message d’erreur sans le contenu.

Ensuite, la fonction getContent() fait appel à une fonction privée _getProtectedContent() pour lire le contenu d’un objet protégé. Elle va maintenant sous-traiter aussi la lecture des objets non protégés à une fonction privée _getUnprotectedContent(). Cette nouvelle fonction sera très similaire à la fonction checkConsistency() mais renverra un contenu complet ou vide au lieu d’un résultat booléen. Et bien sûr l’objet sera supprimé en cas d’empreinte invalide. Et la fonction _getProtectedContent() utilisera la fonction _getUnprotectedContent() pour la lecture de tous les objets accessibles non protégés.

La suppression de l’argument $permitTruncate va poser un gros problème pour l’affichage des gros objets. Ceux-ci via le navigateur peuvent être affiché dans certains cas parce que le navigateur les télécharge sur le serveur web pour les afficher au fur et à mesure. C’est le cas des vidéos non protégées. Une des options pour résoudre ce problème est peut-être d’utiliser le lien de type s jusque là inexploité par la bibliothèque…

Propriété d’un objet et référence par rapport à un objet

Il y a deux liens très proches dans leurs formes. Le lien qui attribut une propriété à un objet et le lien qui désigne un objet par rapport à un objet de référence.

Le lien d’affectation d’une propriété à un objet :

  • type : l
  • source : un objet.
  • cible : l’objet de l’attribut.
  • méta : objet de référence du type d’attribut.

Le lien de désignation d’un objet par rapport à un objet de référence :

  • type : f
  • source : l’objet de départ.
  • cible : l’objet recherché.
  • méta : objet de référence

Leur forme est assez proche. Mais plus encore la recherche du résultat tourne autour de l’objet cible dans le contexte de l’objet méta, elle est strictement identique au type de lien près.

Et pourtant ce ne sont pas les mêmes liens parce que ce n’est pas le même usage.

Le lien d’affectation d’attribut définit une propriété de l’objet source alors que le lien de désignation par référence n’est pas une propriété mais un usage de l’objet source. Il y a donc bien une raison de séparer le type de ces deux formes de liens, et d’avoir deux fonctions distinctes de recherche.

Objet de référence contre suivi du graphe des mises à jours

Le bootstrap retrouve l’application et la librairie nebule à utiliser en suivant des liens. Actuellement, il suit le graphe des mises à jours de l’application sélectionnée et celui de la librairie nebule.

Mais il est possible dans ce cas d’utiliser une autre méthode de suivi des liens pour retrouver la dernière version des applications et de la librairie.

La recherche par les graphes permet de suivre les liens de type u d’objets en objets jusqu’à arriver en bout de branche de l’arborescence des mises à jours. Évidement, il faut tenir compte des liens de type x de suppression de liens. Et il faut aussi que l’objet en bout de branche soit disponible sinon on remonte la branche en sens inverse…
La méthode est efficace mais elle est très longue a jouer.

Il est possible de faire plus simple pour un résultat identique dans notre cas.

La structure de recherche de la dernière version d’un objet a dans notre cas un cheminement complètement sous contrôle. Il n’est pas nécessaire de gérer une profondeur de recherche de plus de un niveau, même avec des liens de mise à jour. En ne fonctionnant plus que sur un seul niveau il est tout à fait possible de n’utiliser que des liens de type f depuis un objet de référence.
Et en plus il est possible de ne plus à devoir gérer les liens de suppression de liens. Un nouveau lien remplace automatiquement le précédent lien. Si il faut supprimer le lien de la dernière mise à jour, il suffit de rejouer à une date plus récente le lien de la version précédente.

Et ainsi il y a gain du nombre d’objets parcourus et gain de temps de traitement sur les quelques liens qui restent.

Cette méthode va être mis en place dès que possible dans le bootstrap.

Objet virtuel avec rôle

Jusque là, la très grande majorité des objets créés ont ou ont eu un contenu et donc une empreinte numérique unique leur correspondant. Cela a été le cas pour les images utilisées comme icônes dans sylabe par exemple.

Le problème par exemple avec l’usage direct de l’objet d’une icône fait que si on veut la mettre à jour ou tout simplement en utiliser une autre à la place il faut faire un lien de mise à jour. Or ce lien de mise à jour n’a pas de contexte, c’est à dire de champs méta dans le lien. Ainsi la mise à jour s’applique partout alors que ce n’était pas forcément le but recherché.

La solution est de ne pas faire référence directement à une image que l’on veut utiliser dans une application mais à un objet intermédiaire. Cet objet n’a même pas besoin d’avoir un contenu, il est virtuel puisque son empreinte est créé de toute pièce sans contenu. Et du fait du fonctionnement de nebule, il n’aura probablement jamais (dans un temps raisonnable) de contenu correspondant à son empreinte.

Ainsi, on ne référence plus dans une application des icônes mais des objets intermédiaires. Et les icônes à utiliser n’ont plus à être des liens de mise à jour u mais deviennent naturellement des liens de dérivation f avec comme champs méta l’objet intermédiaire ou l’objet de l’application. Je pense que l’objet intermédiaire est le mieux comme champs méta.

Comme l’empreinte de cet objet virtuel est purement indicative, on peut lui mettre n’importe quelle valeur de n’importe quelle taille. Il est cependant raisonnable de choisir une taille assez conséquente et différente des tailles usuelles des empreintes, c’est à dire différent de 64, 128, 224, 256, 384, 512, 768, 1024, 2048, 4096, etc…
Chaque application peut utiliser les mêmes valeurs pour ces objets intermédiaires ou choisir par exemple une valeur préfixe identique suivi de valeurs aléatoires jusqu’à avoir une taille raisonnable.

Entités de recouvrement

Le mécanisme de recouvrement des objets protégés et des liens dissimulés est en train d’être doucement mis en place.

D’un point de vue théorique, cela répond à deux problèmes similaires.
En entreprise, et pas que, il est recommandé d’utiliser une ou plusieurs autorités de recouvrement lorsque l’on utilise de la cryptographie pour protéger ses données. Les décideurs le prennent souvent comme une contraite et oublient de mettre en place ce mécanisme de restauration des données chiffrées. Et ce mécanisme est différent de celui de restauration classique alors qu’il est perçu comme étant le même. Résultat, lorsqu’un employé critique vient à manquer, ses données, critiques aussi, deviennent subitement inaccessibles. La disponibilité c’est aussi de la sécurité.
Pour différentes raisons, des états plus ou moins démocratiques peuvent imposer la mise en place d’un mécanisme de déchiffrement des données de leurs concitoyens.

Mais, afin de ne pas rompre la confiance, ce mécanisme doit être loyale, c’est à dire public, transparent et vérifiable.

D’un point de vue pratique, la mise en place comprend deux parties.
Il faut commencer par recenser les entités éligibles comme autorités de recouvrement. Pour l’instant dans le code de la librairie en php, la liste de ces entités est renvoyée vide. Les applications peuvent donc commencer à prendre en compte ces entités pour l’affichage public. C’est le cas dans klicty mais pas encore dans sylabe.
Il faut ensuite, lors de la protection d’un objet ou de la dissimulation d’un lien, dupliquer la protection ou le lien pour chacune des entités de recouvrement. Cela revient simplement à faire un partage de la protection pour un objet protégé en duplicant le lien de type k de chiffrement de la clé de session.

Pour terminer, la librairie n’intégrera pas par défaut d’entité de recouvrement. Si des entités sont définies comme tel, ce sera uniquement par choix (ou obligation) de l’entité responsable du serveur.

Intégration des groupes dans la librairie php

Suite à la définition des groupes, l’intégration a commencé dans la librairie php orienté objet.

L’intégration est profonde puisque les groupes sont gérés comme des objets spécifiques comme c’était déjà le cas pour les entités. Une classe dédiée ainsi que tout un tas de fonctions leurs sont dédiés et personnalisés.

Les applications sylabe et klicty vont intégrer progressivement les groupes, notamment dans un module adapté.

Dans le même temps, un groupe fermé étant uniquement constitué de liens d’une seule entité (et cela doit être vérifié), le filtre social est en cours de mise en place. Ainsi, il est possible de restreindre la prise en compte des liens suivant ces filtres sociaux :

  • self : liens de l’entité ;
  • strict : liens de l’entité et des entités autorités locales ;
  • all : toutes les entités, mais avec un classement par pondération des entités.

L’activation du filtre social et donc de la possibilité de le choisir dans le code à nécessité un revue de tout le code de la librairie et des applications. Il reste à vérifier les modules de sylabe.

Définition des groupes

Dans le cadre de la recherche sur l’implémentation des groupes dans nebule, voir 1 2 3 4 5, deux nouveaux objets réservés ont été ajoutés :

  • nebule/objet/groupe
  • nebule/objet/groupe/ferme

Le groupe

Il a été décidé de rattacher explicitement le groupe aux objets, et donc aussi aux entités notamment. Mais la notion de groupe peut être vu comme plus globale.

Si on reprend par exemple l’objet réservé nebule/danger, les objets qui lui sont liés deviennent de fait un groupe des objets à éviter. Il suffit donc de lier un objet à un autre objet pour créer un groupe. Cependant cela n’est pas très pratique puisque l’on ne peut rechercher que des groupes pré-définis à l’avance et communément acceptés. Cela marche bien pour quelques groupes avec des fonctions biens précises et universellement reconnues, et pas plus.

Fondamentalement, le groupe est la définition d’un ensemble de plusieurs objets. C’est à dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Le groupe met en relation des objets vis-à-vis d’une référence. C’est la référence qui identifie le groupe. Dans le cas de notre objet réservé nebule/danger, c’est cet objet réservé qui est la référence du groupe. Par simplification, l’objet de référence peut être assimilé comme étant le groupe.

Tout objet peut ainsi devenir la référence d’un groupe. Cela n’est pas sans poser un gros problème pratique. Puisque tout objet peut être un groupe, comment fait-on pour s’y retrouver dans l’immensité des groupes disponibles ?
Pour simplifier le problème, nous allons considérer les liens comme étant des groupes directs ou explicites. Et nous allons considérer les relations de deux liens ou plus comme étant des groupes indirectes ou implicites. Ces groupes indirectes sont centrés sur un et un seul objet de référence. Si nous prenons par exemple comme référence l’objet réservé nebule/objet/type, nous avons un groupe indirecte qui va contenir tous les objets de même type mime.

Nous allons à partir de maintenant considérer comme groupe uniquement les groupes indirectes.

Mais cela fait encore beaucoup trop de possibilités en pratique pour que la notion de groupe n’ai un intérêt pour gérer les objets. Nous allons en plus restreindre la notion du groupe, et donc son exploitation dans nebule, à l’objet vers lequel un lien explicite est créé avec les objets. Ce lien explicite est un lien de type l avec comme objet meta l’objet réservé nebule/objet/groupe ou nebule/objet/groupe/ferme.

Groupe ouvert ou fermé

L’exploitation des objets d’un groupe nécessite de pouvoir lire et vérifier les liens qui unissent les objets au groupe. Ces liens peuvent être générés par différentes entités, le traitement social des liens déterminera pour une entité donnée quels sont les objets reconnus dans le groupe ou pas. Ce processus est avant tout un traitement pour reconnaitre ou non les objets d’un groupe ouvert.

Pour un groupe fermé, la reconnaissance des objets du groupe n’est plus déterminée par le traitement social des liens. Ne sont reconnus les objets comme appartenant au groupe fermé que ceux dont le lien est signé par l’entité qui a créé le groupe. Dans le cas d’un groupe fermé, les liens générés par une autre entité pour ajouter des objets au groupe ne sont pas pris en compte.

Si il est possible de créer un groupe ouvert avec un objet de référence donné, le même objet de référence peut aussi servir pour un groupe fermé. Dans ce cas, lors du traitement, le groupe ouvert et le groupe fermé apparaissent comme deux groupes distincts. Si plusieurs entités créent des groupes ouverts avec le même objet de référence, un seul groupe est affiché et regroupe tous les groupes ouverts. Si plusieurs entités créent des groupes fermés avec le même objet de référence, il faut exploiter et afficher tous les groupes fermés comme des groupes indépendants.

Un groupe fermé doit toujours être accompagné son l’entité créatrice lors de l’affichage.

Groupe public ou privé

La distinction entre un groupe public et un groupe privé, c’est la visibilité de celui-ci pour les entités tierces. Si tous les liens qui relient les objets au groupe sont dissimulés, alors le groupe est privé et seuls les entités qui peuvent voir ces liens ont accès au groupe.

Cependant, si une partie des liens ne sont pas dissimulés ou si ils sont rendus publics, alors le groupe devient partiellement public.
Les liens, même dissimulés, sont complètement manipulables par toute entité qui y a accès, ainsi en terme de sécurité on peut dire qu’un groupe privé est un groupe public qui s’ignore. Mais ce n’est pas forcément un problème, si une entité A crée un groupe fermé et privé, alors le fait qu’une autre entité B crée un même groupe (même référence) ouvert et public ne rend pas pour autant public le groupe de l’entité A.

Groupe actif ou passif

Un groupe est par défaut passif. Il devient actif lorsqu’il devient capable de réaliser des actions, c’est à dire de signer des liens. Le seul objet capable de signer un lien est une entité, ainsi un groupe actif est un groupe dont l’objet de référence est une entité.

Si le secret de cette entité de référence du groupe n’est connu que d’une seule autre entité (entité maitresse) alors c’est un groupe actif fermé. Si cette entité de référence du groupe a plusieurs entités maitresses alors c’est un groupe actif ouvert.

Un groupe actif ouvert peut aussi être privé si tous ses liens sont dissimulés. Il devient semi-public ou public si une des entités maitresse dévoile tout ou partie des liens du groupe. De la même façon, une entité peut ajouter d’autres entités au groupe, c’est à dire partager le secret de l’entité de référence du groupe. En terme de sécurité, un groupe actif ouvert privé est souvent un groupe actif ouvert public qui s’ignore.

De fait, toute entité piratée devient un groupe actif ouvert, même si le secret de l’entité n’est pas rendu public.

Groupe d’entités

Un groupe d’entité est un groupe dans lequel on ne considère que les objets qui sont des entités. Les autres objets sont ignorés. Lorsque ce groupe n’est plus vu comme un groupe d’entités, tous les objets sont pris en compte et les entités sont gérés comme des objets. La distinction se fait donc uniquement sur le type d’objet que l’on attend du groupe au moment de l’exploiter.

Graphe de groupes

Lorsque l’on a un groupe qui est lié à un autre groupe, comme doit-on l’interpréter ?
Cela crée un graphe de groupes. Il est possible soit d’ignorer les sous-groupes dans un groupe ou au contraire de résoudre le graphe pour en exploiter tous les objets. Dans le cas de la résolution du graphe, on retombe sur les problèmes classiques de la résolution d’un graphe.

Le graphe de groupe peut aussi dans certains cas avoir un traitement convenu. Cela peut être appliqué à la gestion des options ou des droits dans une application. On va ainsi lier des groupes d’entités avec des groupes d’options et/ou des groupes de droits. Dans ce cas on ne parcours le graphe que de façon simple et non ambigüe.

NÅ“ud

La notion de nœud est concurrente de la notion de groupe. Sauf usage nouveau et différencié, le nœud va disparaitre de nebule.

Liens de propriétés d’un objet

Rien de vraiment nouveau pour ce début d’année 2016.

Via la librairie php, on pouvait récupérer une ou des propriétés d’un objet avec le contenu de ces propriétés, on peut maintenant récupérer juste le ou les liens correspondants. Ainsi il est possible d’extraire facilement d’autres informations sur ces propriétés comme la date ou l’entité créatrice…

Historique des liens générés

Il y avait dans la librairie nebule en php procédural une option permettant de copier au moment de leur écriture les nouveaux liens générés. C’est une forme d’historique qui vient en complément de la possibilité d’écriture des nouveaux liens signés dans les liens de l’entité signataire. Par défaut tout arrivait dans le fichier l/f qu’il fallait bien sûr penser à vider de temps en temps.

Mais cela n’avait pas été ré-implémenté. C’est maintenant fait dans la librairie en php orienté objet. L’option permitHistoryLinksSign permet d’activer cette fonctionnalité et est par défaut à false, soit désactivé.

C’est utile pour le développement puisqu’il suffit de récupérer les derniers liens des programmes en cours de développement pour les faire signer par une autorité de code (bachue). C’est plus facile que d’aller faire la pêche aux liens sur les différents objets concernés.

Sondages et votes

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

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.

Messagerie et transfert fondamental d’information

Comme cité dans l’article sylabe – Emulation de messagerie, l’implémentation de certaines fonctionnalités de la messagerie pose problème.

Tout lien f est potentiellement un message. Cette façon de voir est plus fondamentale, plus propre et plus proche de la gestion de l’information. Malheureusement, elle pose quelques problèmes pour certaines fonctionnalités classiques de la messagerie telle que nous l’utilisons tous aujourd’hui. Les problèmes de fonctionnalités ne sont pas graves mais peuvent être perturbants.

Pour commencer, comment marquer un message comme lu puisque cela revient à faire un lien d’un lien, ce que ne permet pas nebule.
Nous sommes ici dans un fonctionnement attendu de la messagerie dans laquelle chaque message est important et doit donc être lu. Ce comportement est différent du message de réseau social qui n’a pas forcément d’importance et n’est pas destiné à être lu impérativement. On distingue le message destiné à la masse des gens, même si elle peut être très limitée, du message destiné spécifiquement à un individu. La notion d’importance dans l’attente de lecture du message dépend surtout du nombre de destinataires.
Il ne faut pas non plus penser que le spammer s’attend à ce que tout le monde lise ses messages. C’est du rêve mais ce genre de message est très peu lu et est donc envoyé en masse pour compenser ce manque d’importance ou d’intérêt.

Ensuite, lorsque l’on marque comme supprimé un message, c’est que l’on supprime explicitement le lien f qui fait que c’est un message. Si on souhaite annuler cette suppression, la théorie dans nebule veut que l’on recrée un lien mais avec une date plus récente. Or si la date est plus récente, cela altère l’information de la date du message. Ensuite, c’est l’entité qui à reçu le message qui génère le nouveau lien à une date plus récente, et non l’entité d’origine. On perd donc la provenance du message. Ce n’est pas acceptable dans ces conditions de permettre la restauration d’un message.

Il est probable que l’on revienne plus tard à une implémentation plus universelle et fondamentale dans la façon de reconnaître ce qu’est un transfert d’information, un message.

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…

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.

Gestion du lien de suppression de liens

Le lien de type x permet de supprimer des liens marqués à des dates antérieures.

En dehors de la gestion du temps et de la forme de la marque, comment doit se comporter le code lorsqu’un lien x à la même date qu’un autre lien ?

Dans l’ancienne librairie nebule en php procédurale, le code considérait l’autre lien comme supprimé. C’est à dire que le lien x est plus fort que les autres lors du traitement.

On peut réfléchir à des problèmes qui pourraient survenir, à la marge, sur la gestion des liens.
Cela présente cependant un avantage de conserver ce fonctionnement. Si dans l’interface on souhaite supprimer un lien, soit on utilise la date en cours, soit on précise la date du lien à supprimer. Dans ce dernier cas, si le lien à été régénéré par un autre moyen juste quelques secondes après, voir moins, le nouveau lien ne sera pas supprimé. Ce qui est plus logique.

Arborescence virtuelle

Dans nos systèmes d’information actuels, le rangement des fichiers dans une arborescence est non seulement classique mais fondamentale et souvent incontournable. L’autre forme de rangement est d’utiliser une base de données.

Il est possible avec nebule de simuler une arborescence mais virtuelle et uniquement constituée d’objets et de liens.
CF Wiki РR̩flexion Рanalyse des applications РSyst̬me de fichiers

Un arborescence commence par une racine, par exemple ‘/‘. Dans cette racine on va trouver des fichiers, des sous-dossiers et des fichiers dans les sous-dossiers.
Chaque fichier a nativement un nom ou au pire un identifiant unique. Les fichiers vont avoir en plus un ou des liens pour les positionner dans l’arborescence à un ou plusieurs endroits.
Chaque dossier est constitué de l’objet contenant son nom. Cet objet de nommage est lié au dossier parent par un lien, lui-même relié à son dossier parent… jusqu’à la racine.

Le nom des objets ne pose pas de problème, il risque juste de changer d’une entité à l’autre. Le nom d’un dossier peut par contre avoir deux formes, mais on ne doit en gérer qu’une seule.
Soit le nom d’un dossier ne contient que sont nom et pas l’ensemble de l’arborescence. Dans ce cason peut avoir n’importe quel nom, y compris des noms avec le caractère séparateur de dossiers ‘/’. Mais si on souhaite mettre deux dossiers avec le même nom dans deux branches différentes de l’arborescence, il y a conflit sur le nom et donc mélange des fichiers enfants.
Soit le nom d’un dossier contient l’ensemble de l’arborescence. On résoud les problèmes de conflit. Et on n’accepte pas des noms de dossiers avec le caractère séparateur de dossiers. C’est la meilleur solution.

Comme il est possible que plusieurs entités créent plusieurs arborescences différentes ou en reconnaîssent plusieurs, il faut un objet unique de référence de cette arborescence. L’objet contenant ‘/’ doit dans ce cas être lié à l’objet de référence, et il en est de même pour tous les objets de l’aborescence.
Ainsi, comme pour l’émulation de commentaires dans le blog, les objets on des liens entre eux avec comme contexte un objet de référence. Les mêmes liens peuvent tout à fait être reproduire intégralement ou partiellement avec un autre objet de référence et ne pas entrer en conflit.

On obtient, du fait même de la base nebulisée, des comportements spécifiques sur l’arborescence.
Par exemple dans une arborescence de fichiers d’une société, le chef pose un nouveau fichier dans un sous-dossier. Tout le monde dans la société va voir ce nouveau fichier. Un des employé ‘copie’ le fichier ailleurs dans l’arborescence, tout le monde voit le nouveau fichier. Si il le modifie, il crée un objet de mise à jour et les deux fichiers sont mis à jours. Cela est intéressant puisque tous les emplacements sont tenus à jours mais cela peut déjà poser problème puisque l’on ne voulait peut-être pas tout mettre à jour. Il faut donc bien distinguer la mise à jour et le dérivé.
Prenons un autre cas. Un des employé modifie le nom du fichier créé par le chef. tout le monde voit la modification. Le chef décide d’annuler le nouveau nom, de redonner le nom d’origine au fichier. Tout le monde va voir le fichier revenir à son nom d’origine… sauf peut-être celui qui avait renommé le fichier puisque la gestion sociale des liens va peut-être décider que personne ne peut annuler son opération, même si le chef est son supérieur hiérarchique dans la société.

Cette arborescence virtuelle sera ajoutée pour expérimentation à sylabe. Comme ce n’est pas quelque chose de vraiment natif dans la philosophie de nebule, l’implémentation se fera sous forme d’un module.

On peut ensuite, sur cette base, aller plus loin avec par exemple inotify. Pour un dossier spécifié et ses sous dossiers, tout changement sur un dossier ou un fichier serait immédiatement nébulisé et synchronisé vers un serveur local ou distant.