Graphe des entités autorités

Afin d’organiser une certaine intendance autour de la diffusion du code des applications, un certain nombre d’entités sont nécessaires.

Le modèle utilisé est assez classique est simple, c’est un schéma de parenté. Il peut être amené à évoluer dans le futur.

La structure du graphe reconnue est la suivant :

  • Le maître du tout (puppetmaster)
    • Les autorités de la sécurité
    • Les autorités du code
    • Les autorités du temps
    • Les autorités de l’annuaire

Une évolution est en cours d’intégration avec la nouvelle version des liens. Si l’entité qui chapeaute toutes les autres est unique, chaque groupe d’autorités n’est plus seulement une entité mais devient un groupe d’entités à pouvoir identique.

Il est à prévoir que le maître du tout deviendra aussi, un jour, des autorités globales. Mais la forme n’est pas encore défini.

Chaque entité ici considérée doit être un objet entité EID (Entity ID) valide avec lien de type, un lien de nommage et un lien de localisation (URL web).

D’un point de vue sémantique, on quitte progressivement la notion de maître historique pour aller vers la notion d’autorité. Outre le rapport à l’esclavage, on est soumis au maître, on se soumet à l’autorité.

Le puppetmaster est un EID qui peut être remplacé. Il va faire référence par des liens dédiés vers les différents d’autorités au moyen de RID dédiés :

  • Autorités de la sécurité
    • a4b210d4fb820a5b715509e501e36873eb9e27dca1dd591a98a5fc264fd2238adf4b489d.none.288
  • Autorités du code
    • 2b9dd679451eaca14a50e7a65352f959fc3ad55efc572dcd009c526bc01ab3fe304d8e69.none.288
  • Autorités du temps
    • bab7966fd5b483f9556ac34e4fac9f778d0014149f196236064931378785d81cae5e7a6e.none.288
  • Autorités de l’annuaire
    • 50e1d0348892e7b8a555301983bccdb8a07871843ed8f392d539d3d90f37ea8c2a54d72a.none.288

C’est à dire que tout EID désigné par un de ces RID (l>RID>EID), et signé par le puppetmaster, devient une autorité dans le groupe considéré.

Entit̩ multi-r̫les Рcompromission et divergence

Suite des articles Entité multi-rôles et suite, Nommage d’entité – préfix, Entités multiples, Changement d’identifiant d’entité et Entités multiples, gestion, relations et anonymat.

La segmentation d’une entité en plusieurs entités avec des rôles différents va nécessiter un peu de travail. La notification du rôle dans le préfixe de nommage des entités ne semble pas opportune.

Lors du changement de mot de passe d’une entité, la clé publique ne changeant pas, l’entité reste référencée par le même identifiant, c’est à dire l’empreinte de l’objet de la clé publique. Par contre l’objet de la clé privée va changer, il faut donc un lien pour retrouver cette nouvelle clé privée. Ce n’est pas encore implémenté mais ici rien de compliqué.
Ça va se compliquer avec le problème de diffusion de l’objet de la nouvelle clé privée afin que l’utilisateur puisse l’utilisé pour s’authentifier sur une autre instance serveur. Là on a l’utilité de permettre facilement la synchronisation d’une entité en préalable à une authentification.

Il y a cependant un problème majeure de sécurité des entités. en effet les anciennes clés privées restent toujours présentes et permettent toujours de déverrouille l’entité. Il ne suffit pas de faire une suppression de l’objet concerné, cela n’a que peu de chance de fonctionner face à un attaquant.
Il est possible de générer une nouvelle entité avec sa propre clé publique, ou de tout le cortège d’entités dans le cas du multi-entités. On peut même imaginer ne changer que l’entité d’authentification. Puis on fait des liens pour dire à tout le monde que l’entité a été mise à jour et marquer le lien de parenté. Cela veut malheureusement dire qu’il faut refaire tous les liens avec la nouvelle entité. Peut-être est-ce l’occasion de faire du ménage et oublier des choses…

Quelque soit le mécanisme, il ne protège pas de la compromission d’une entité par un attaquant. Celui-ci peut réaliser une mise à jours de l’entité qui sera vu comme légitime par les autres entités. La récupération de l’entité est possible puisqu’elle existe toujours mais comment vont se comporter les autres entités lorsque l’on va faire une deuxième mise à jours d’entité… en concurrence avec la première. Il y a peut-être un moyen de faire jouer le côté social des relations entre entités et de volontairement créer un challenge entre les deux mises à jours de l’entité et toutes les entités tierces.
Ou alors on accepte la survivance simultané de ces deux entités qui vont progressivement diverger avec le temps. Là aussi un tri social pourra se faire mais plus naturellement.

La solution à ce problème peut être l’usage d’une entité faisant autorité et capable d’imposer une mise à jour d’entité en particulier. Mais on essaie de se débarrasser des autorités encombrantes ce n’est pas pour les réintroduire au premier coup de froid.
Il existe une autre forme d’autorité, ce peut être une entité à soi mais que l’on n’utilise pas au jours le jour et stockée à la maison au chaud. Les cambriolages étant encore un risque contemporain cette entité de recouvrement peut être dupliquée en d’autres lieux. Évidement son vol ne doit pas permettre de prendre le contrôle de l’ensemble.

Il restera toujours le vol sous contrainte. Mais ça on ne peut rien y faire de toute façon.

L’hégémonie d’un mécanisme unique de gestion des identités est un problème puisque une fois ce mécanisme corrompu il n’existe plus de recours pour récupérer son identité.

Ce problème n’a pas vraiment de solution complète et pas encore d’orientation précise pour gérer les conflits. Il reste encore du travail de réflexion…

Entit̩ multi-r̫les Рsuite

Suite de l’article sur les Entité multi-rôles.

La gestion de multiples clés cryptographiques asymétriques dépendantes d’une seule clé principale impose des contraintes lors de la synchronisation d’entité mais il n’est pas difficile à mettre en place.

La première idée serait de protéger les mots de passe des clés secondaires avec la clé primaire. Mais cette clé primaire a avant tout le rôle d’authentification, elle ne doit donc pas servir à faire du chiffrement.

La seconde idée consiste à dériver (PBKDF) les mots de passe des clé secondaires du mot de passe de déverrouillage de la clé primaire. Ainsi la clé primaire ne sert qu’à l’authentification. Cela implique aussi que la modification du mot de passe de la clé primaire force le changement de mot de passe de toutes les clés secondaires associées.

La dérivation des mots de passe peut prendre en compte la partie publique de la clé primaire et de la clé secondaire concernée. Elle peut aussi prendre en compte, en plus, l’ID dans nebule du rôle associé. Une implémentation complète devra être proposée.

Entité multi-rôles

D’un point de vue robustesse et sécurisation des clés cryptographiques, il est recommandé de séparer les rôles des différentes clés utilisées. Une clé crypto ne doit avoir qu’un seul usage, c’est à dire un seul rôle. Dans l’implémentation des entités dans nebule, les entités étant des clés cryptographiques avec de multiples rôles, il va falloir les scinder.

Les rôles les plus fréquents sont :

  1. L’authentification. C’est utilisé pour le déverrouillage des entités.
  2. La signature. Tous les liens sont signés.
  3. Le chiffrement. Il intervient dans la protection des objets et la dissimulation des liens.

Toutes les clés liées à des rôles peuvent être rattachées à une clé cryptographique asymétrique principale et reliées à celle-ci par des liens. Il est possible par la suite d’étendre sans problème les rôles comme par exemple les rôles d’autorités locales.

La segmentation des clés par rôles impose la gestion de multiples clés pour une entité, notamment lors de la synchronisation sur différents supports. Mais elle permet en cas de compromission d’une clé de limiter l’étendu des dégâts.

Entités multiples

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é.

Changement d’identifiant d’entité

On avait déjà vu qu’une entité pouvait être amenée à changer d’identifiant, donc en fait de clé publique et de clé privée. On avait vu que renouveler son entité n’est pas un problème facile à résoudre de façon satisfaisante, c’est à dire vraiment sécurisée et facile pour l’utilisateur.

Du point de vue interface, la nouvelle entité change aussi de couleur propre. Donc on ne peut pas demander à l’utilisateur par ailleurs de se fier à cette couleur propre des objets puisqu’elle va changer complètement à chaque mise à jour de ceux-ci. C’est ici que se fait sentir le besoin d’une référence d’objet stable dans le temps quelque soit les mises à jours, mais cette référence est par nature source de conflit d’une entité à l’autre et surtout elle est impossible à sécuriser.

Le problème est plus simple si l’entité est dépendante d’une autre entité, d’une entité maitresse. A condition que cette entité maitresse soit publiquement déclarée, comme le puppetmaster, il est possible de vérifier de façon sûr qu’une entité à changé de clé privée. CF Entités multiples, gestion, relations et anonymat

Par contre, une entité autonome ou assimilée ne peut pas se reposer sur une entité supérieure. Il faut prévoir un mécanisme qui permette à l’utilisateur d’une entité lambda de valider automatiquement ou manuellement la mise à jour d’une autre entité. Cela ne veut pas dire que l’autre entité ne changera pas d’identifiant, mais que cet identifiant ne sera pas reconnu tant que l’entité lambda n’aura pas validé (pour elle) son changement.

Pour le changement d’une entité qui potentiellement remet gravement en question la sureté de fonctionnement, une acceptation inconditionnelle de la mise à jour serait catastrophique. Il peut être utile dans ce cas particulier de générer un lien d’annulation de l’opération, mais un lien qui n’est pas actif, c’est à dire qui n’est pas diffusé. Ce lien de type x, serait affiché à l’utilisateur et serait donc valide mais pas pris en compte parce que non diffusé avec les autre liens.

Si on prend le cas spécifique de puppetmaster, cette entité valide des entités esclaves ayant des rôles près-définis. On retrouve notamment l’entité bachue qui diffuse les mises à jours logiciels liées au projet nebule. La compromission d’une telle entité poserait de graves problèmes de sécurité pour toutes les entités. Sa mise à jour vers une nouvelle entité serait dans ce cas obligatoire.
Mais ce problème pourrait être plus restreint dans la mesure où une fausse entité bachue serait générée et diffusée à des entités tierces. Si, par un autre moyen, on arrive à convaincre les entités tierces à l’utiliser en place de la vraie entité bachue, ces entités seront à considérer comme compromises. Le lien d’annulation serait alors le seul moyen pour ces entités de pouvoir revenir en arrière, faisant immédiatement un bond en arrière en terme de versions de logiciels, revenant à une version validée par l’entité bachue légitime.
Sauf que cela ne marche que si l’on peut enregistrer le lien de suppression hors du système nébulisé ou hors d’atteinte. Ce qui sera une vraie difficulté sur des systèmes entièrement nébulisés. Aujourd’hui, avec les systèmes d’informations actuels, on s’en sort en régénérant une nouvelle identité à l’utilisateur ou en nettoyant son compte. Peut-être faudra-t-il dans un premier temps garder ce fonctionnement avant d’aller vers quelque chose de plus ouvert…

Entités multiples, gestion, relations et anonymat

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…

Les entités et le code

La remise en forme du code de nebule en php orienté objet amène son lot de questions.

Les entités de nebule

Les entités principales de nebule ont actuellement des noms mais ne sont reliées à leurs fonctions respectives que par leur usage dans le code.

Pour que ce soit plus clair dans le code, le nom est un peu trop hermétique. Je le remplace donc par un nom contenant directement le rôle. Ainsi, kronos par exemple s’appellera toujours kronos mais sera mémorisé dans une variable nommée time master. Et il en est ainsi pour toutes les entités qui ont un rôle dans nebule :

  • puppetmaster, ne change pas de nom, c’est l’entité qui chapeaute toutes les autres, le maître ;
  • cerberus, hérite du rôle et du nom security master, le maître de la sécurité ;
  • bachue, hérite du rôle et du nom code master, le maître du code ;
  • asabiyya, hérite du rôle et du nom directory master, le maître de l’annuaire ;
  • kronos, hérite du rôle et du nom time master, le maître du temps.

Les possibilités de gestion pour l’utilisateur

La sécurisation du code amène aussi des questions sur l’organisation de la gestion de certaines parties de la sécurité. Notamment, jusqu’où peut-on permettre l’ajout de droits à une entité normale ?

Cette entité peut vouloir utiliser des extensions externes au code d’origine tel que diffusé par bachue. Cela peux se faire en relation avec la définition d’autorités locales. L’ajout d’une traduction de l’interface en est un bon exemple. L’entité bachue peut aussi diffuser ou permettre la diffusion de plusieurs codes utilisables par une entité.

Plus on donne de droits à un utilisateur, plus il risque de se faire corrompre par un code malveillant. Il faut trouver un juste milieu. Le code et la gestion du bootstrap doit rester la plus saine possible dans tous les cas.

Redéfinition de puppetmaster

L’entité puppetmaster est celle qui contrôle toutes les autres, donc qui contrôle tout. C’est le point fort de la hiérarchie des entités, et aujourd’hui la moins vulnérable. Mais c’est aussi l’entité qui présente le plus grand risque pour l’ensemble puisqu’elle est unique et que sa compromission serait fatale à tout l’ensemble.

C’est le même problème que le système de certificats présente aujourd’hui. Quoique, c’est pire encore pour le système de certificats puisqu’il existe beaucoup d’autorités de certifications racines et que la compromission d’un seule casse la confiance de tout le système. Dans l’ensemble, ce système de certificats est bien fait à part cette horreur de monstre à têtes multiples. Un vrai trou conceptuel dans la sécurité. Les gouvernements et le grand banditisme l’ont déjà corrompu depuis quelque temps à leur avantage.

Pour l’entité puppetmaster, l’idée est de partir en sens inverse. Au lieu de divulguer cette entité à de multiples personnes et organismes dont l’intégrité et l’honnêteté sont loin d’être garanties, on ne diffuse qu’une partie du pouvoir de l’entité puppetmaster. Une personne seule ne doit pas pouvoir utiliser l’entité. Chaque lien doit être validé, et donc signé, par un corpus de plusieurs clés représentant l’entité. Par exemple, on peut partir sur dix sous-clés de l’entité, associées deux à deux.

On peut implémenter la vérification du quotas de sous-clés ayant signées un même lien. Mais cette façon de faire est un droit faible puisqu’il ne repose que sur du code. On peut, j’espère, trouver une implémentation mathématique permettant de mettre en place une signature unique combinaison de plusieurs clés.

Il faut aussi résoudre un problème organisationnel et non technique. En combien de parties découpe-t-on l’entité ?
Dans notre exemple dix sous-clés associées deux à deux, on a un pouvoir de la clé maître répartie en cinq couples de clés. Chaque clé d’un couple a le pouvoir du couple. Le couple ici fait référence au couple humain. Et le cinq peut faire référence à tout un tas de choses…
Est-ce la meilleur répartition ? Celle-ci doit-elle répondre à une organisation physique ? Philosophique ? Spirituelle ? Mystique ? etc…

Lien de type f, précisions

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

Le nouvel objet est considéré comme enfant ou parent suivant le sens du lien.

Le champs HashMeta doit être vu comme le contexte du lien. Par exemple, deux objets contenants du texte peuvent être reliés simplement sans contexte, c’est à dire reliés de façon simplement hiérarchique. Ces deux mêmes textes peuvent être plutôt (ou en plus) reliés avec un contexte comme celui d’une discussion dans un blog. Dans ce deuxième cas, la relation entre les deux textes n’a pas de sens en dehors de cette discussion sur ce blog. Il est même probable que le blog n’affichera pas les autres textes en relations si ils n’ont pas un contexte appartenant à ce blog.

CF : Documentation_-_nebule_v1.2 – Action_f_-_Dérivé_d’objet

Ajout d’émotions sur des objets – suite 4

L’ajout des émotions sur les objets n’en finit pas d’arriver… Le code est un peu délicat à manipuler. Certaines choses doivent s’afficher dans certaines conditions et à certains endroits en fonction de l’objet que l’on regarde. C’est la suite de l’article Ajout d’émotions sur des objets – suite 3.

Les émotions supportées sont encore sujet à discussion, mais leur fonctionnement est maintenant stable.
Les émotions doivent être considérées comme des groupes, donc les objets que l’on marque avec ces émotions appartiennent en quelque sorte aux groupes d’émotions en question.
On parle ici des émotions, mais la mécanique est exactement la même pour les avis. Seul l’affichage peut varier un peu.

Quelques règles de fonctionnement :

  1. Une émotion est représentée sur un objet par un lien de type ‘f‘ de l’émotion vers l’objet, méta à ‘0‘.
  2. Une émotion sur un objet dérivé lié à l’objet en cours est un lien de type ‘f‘ de l’émotion vers l’objet dérivé avec comme méta l’objet en cours.
  3. Une émotion sur un objet dérivé, donc avec un contexte, n’apparaît pas dans le mode affichage de l’objet, même si on est sur l’objet dérivé en question.

Cela donne par exemple ce genre de vue en mode navigation :

shot-2014-04-22_20-44-57

On remarque que toutes les lignes qui disent que l’objet est de type image/jpeg ont l’émotion ‘J'approuve‘. C’est fait en une seule fois. C’est le même lien derrière qui dit que l’on approuve que l’objet soit de ce type, indépendamment de qui le dit.

Si on se place sur l’objet du milieu dans la petite conversation en cascade, on peut observer ça :

shot-2014-04-22_20-50-34

On voit que les autres commentaires sont fait dans le contexte d’un objet spécifique, un autre objet surtout. On voit aussi qu’une émotion est placée sur l’un des commentaire, cette émotion est cependant dans le contexte de l’objet en cours, ce commentaire, et non dans le contexte de l’objet dans lequel à lieu la discussion. Si on regarde l’affichage précédent, cette émotion n’apparaît pas.

Auto déploiement répliqué d’un code

La librairie nebule de référence en php gère maintenant les liens de mise à jour d’objets conformément à la méthode décrite dans l’article sur la Résolution d’un graphe de relations de mise à jour.

Cette fonctionnalité qui paraît au premier abord peu utile tous les jours est en fait primordiale pour diffuser de façon sécurisée les mises à jours de logiciels. Le premier programme à en bénéficier est sylabe. La diffusion du code sous forme d’objet a déjà commencé : Gestion des versions de sylabe – mise en ligne

Ainsi, le code de sylabe va pouvoir être très facilement tenu à jour avec la toute dernière version. Mais cela va aussi grandement simplifier l’installation puisque le code de bootstrap va être capable d’aller automatiquement récupérer immédiatement la dernière version de sylabe avant de permettre son utilisation.

Nous arrivons dans le projet nebule à un point de singularité. Alors que jusque là, les fichiers mais aussi les entités (les utilisateurs) avaient été intégrés à nebule sous forme d’objets, le code de nebule restait lui en dehors des objets. Maintenant, le code de gestion des liens et objets devient lui aussi un objet géré par des liens comme tout objet.

Le code sera initialement signé et diffusé par l’entité bachue. Tout entité à jour deviendra à son tour point de redistribution du code.

Résolution d’un graphe de relations de mise à jour

L’utilisation des liens de mise à jour d’objets est utilisé dans des cas biens spécifiques mais revêt une grande importance par exemple dans la mise à jour de programmes. Cela a notamment des implications sur la sécurité des programmes gérés sous forme d’objets.

Les liens de mise à jour n’ont pas de contraintes et peuvent donc créer des graphes de liens entre objets de forme quelconque. Cependant, l’usage de ces liens dans nebule nécessite que pour un objet donné on obtienne un unique autre objet. Cet objet doit être disponible puisque l’on est dans le cas d’un usage, c’est à dire de son utilisation immédiate.

La résolution d’un graphe de liens permet d’obtenir l’identifiant un objet dérivé unique et disponible pour un objet de départ en tenant compte de la validité des liens. Cette résolution est spécifique à nebule et se fait sous forme arborescente en ne tenant compte de des liens descendants et non bouclés.

Table des matières :

  1. Lien de mise à jour
  2. Remplacement de lien de mise à jour
  3. Mise à jour arborescente
  4. Gestion des objets manquants
  5. Résolution des boucles

Cette méthode de résolution va maintenant être expérimentée grandeur nature dans sylabe pour la gestion des versions des programmes. Continuer la lecture de Résolution d’un graphe de relations de mise à jour

Renouveler son entité

Pour l’instant, les entités sont figées. Mais il faudra prévoir de changer leurs mots de passes et de les migrer vers de nouvelles entités au besoin.

Le changement de mot de passe nécessite de régénérer l’objet de clé privé qui change. Il faut évidemment préalablement déverrouiller l’entité, donc sa clé privée. Une fois le mot de passe changé, il faut lier la nouvelle clé privée à la clé publique puis supprimer le lien de l’ancienne clé privé. Il faut marquer à supprimer l’objet de l’ancienne clé privée.

Dans le cas d’une migration d’entité, c’est un peu plus complexe. Ce besoin répondra souvent suite à un problème de compromission ou de corruption d’entité.
Il faut générer une nouvelle entité autonome. Faire un lien de mise à jour de l’ancienne entité vers la nouvelle. Dans la mesure du possible, ce lien de mise à jour doit être signé à la fois par l’ancienne et la nouvelle entité. Puis l’objet de la clé privée de l’ancienne entité doit être marqué à supprimer à la fois par l’ancienne et la nouvelle entité.
Si l’entité avait été corrompue, c’est à dire qu’il était impossible de la déverrouiller, c’est un vrai problème. Dans ce cas, les liens de mise à jour d’entité et de suppression de clé privée ne pourront être signés par l’ancienne entité. rien ne permet de distinguer une opération légitime suite à un problème d’une tentative de détournement par une autre entité. Il peut tout au plus être possible de regarder si l’entité génère de l’activité, donc qu’elle n’est pas corrompue.
En cas de compromission de l’entité, on peut faire une mise à jour vers une nouvelle entité. Mais celui qui a volé la clé privée de l’entité peut le faire aussi de son côté. Il est difficile dans ce cas de déterminer qui est la véritable nouvelle identité et pas une usurpation… Peut-être le côté sociale, comportemental, d’une entité peut nous aider à posteriori?

Appartenance et/ou propri̩t̩ Рsuite

Suite de Appartenance et/ou propriété.

En regardant le code de sylabe et notamment la façon dont on traduit les liens, on voit une énorme instruction switch pour trier les liens de type l. Ce tri est fait par rapport à l’objet méta. Les liens sans objet méta (càd égale à 0) apparaissent donc comme des exceptions qu’il faut gérer dans un autre sous switch.

D’un autre côté, les liens de type f sont triés plus naturellement par l’objet source. Cela n’a donc pas d’importance si l’objet méta est nul.

Donc, c’est un lien de type f qui sera maintenant à utiliser pour désigner un nÅ“ud. Cela devient un groupe à part entière.

Tous les liens de type l avec un objet méta nul sont marqués comme périmés. Il n’y a plus de moyen de désigner explicitement un objet comme ‘objet‘, ‘entité‘ ou ‘objet de suivi spécifique‘. Et il n’y a pas vraiment besoin.
Il est ajouté dans la documentation nebule v1.1 que les liens de type l ne devraient avoir ni un objet méta nul ni un objet destination nul.

Appartenance et/ou propriété

Il se pose un dilemme aujourd’hui dans la définition de ce qu’est un nÅ“ud. Non sur la nature de celui-ci mais plutôt sur la façon dont le nÅ“ud est désigné comme tel.

Le même genre de problème se pose aussi pour une entité mais de façon un peu plus simple.
Une entité est capable de signer, c’est donc avant tout une clé cryptographique asymétrique (RSA uniquement aujourd’hui dans nebule). C’est aussi plus spécifiquement la clé publique, celle que l’on diffuse, donc celle par laquelle on est connu et reconnu. Au delà de ses propriétés mathématiques internes, elle est reconnu par la forme de son contenu et plus généralement par son type mime : ‘application/x-pem-file‘. Malheureusement, le fichier PEM, qu’il contienne la clé publique ou la privée ou les deux, a toujours le même type mime. Il est impossible de distinguer l’une ou l’autre naturellement par le type mime, il faut regarder le contenu pour pouvoir prendre une décision sur la nature de la clé.
Cela paraît compliqué comme ça, mais le problème est finalement facile à résoudre. Pour savoir si c’est une entité, il suffit de regarder si l’objet a le bon type mime puis de lire la première ligne du fichier (moins de 30 caractères). On peut vouloir ajouter un lien pour dire explicitement que cet objet est une entité. Mais quel doit être ce lien? Un lien de type l pour attribuer un attribut à l’objet? Ou un lien de type f pour dire que l’objet fait parti (dérivé) du groupe des entités?

Il y a le même problème avec le nÅ“ud. Celui-ci n’a pas de type mime à proprement parler, ce peut être du texte comme une image. Il peut être tentant d’ajouter un lien pour définir explicitement un objet comme étant un nÅ“ud. Dans ce cas, la recherche des nÅ“uds est facilité puisqu’il suffit de regarder les liens vers l’objet ‘nebule/objet/noeud‘. On en revient cependant aux mêmes questions. Quel doit être ce lien? Un lien de type l pour attribuer un attribut à l’objet? Ou un lien de type f pour dire que l’objet fait parti (dérivé) du groupe des entités?
Il s’ajoute un autre problème. Nous n’avons pas besoin en théorie de ce lien pour caractériser un nÅ“ud. Il suffit que le nÅ“ud ai au moins un liens de type f pour lequel il est à la fois l’objet source et l’objet méta. Mais pour retrouver les nÅ“uds, cela oblige à parcourir tous les objets. Bref, ce n’est pas réalisable en pratique pour un usage commun. Nous devons donc ajouter un lien qui explicite la nature de nÅ“ud de l’objet.

Les deux type de liens sont équivalents pour résoudre ce problème. Le type l est plus simple. Le type f permet quand à lui de voir la notion de nÅ“ud comme un groupe. Est-ce qu’il y a un intérêt à gérer les nÅ“uds dans un groupe?
L’usage seul nous permettra de déterminer quel est le meilleur type de lien…

RSE ou RSE ?

En recherchant la définition de l’acronyme RSE, je tombe sur deux définitions… Problème assez récurrent en fait avec les acronymes puisque n’importe qui peut en inventer et les utiliser sur la place publique à son bénéfice.

D’un côté j’ai une belle page bien fournie sur Wikipédia et une page gouvernementale officielle parlant de Responsabilité Sociétale des Entreprises :
Responsabilit̩ Soci̩tale des Entreprises РWikip̩dia
Qu’est-ce-que la responsabilité sociétale des entreprises – Ministère du développement durable
On y parle donc de responsabilité des entreprises, de développement durable, de gestion de risques, des impacts environnementaux et sociaux, enjeux, investissements, outils, normes, médiatisation, aspects juridiques, etc…

De l’autre un article sur 01net.com qui surfe sur la vague des révélations sur PRISM, ce qui n’est pas un mal en soi :
Le RSE : un lanceur d’alerte en entreprise – 01net
On retrouve bien en fin d’article un paragraphe sur le RSE, l’environnement et les risques. Mais RSE, répété à l’envie tout au long de l’article, désigne ici Réseau Social d’Entreprise. En gros un simili Facebook restreint au périmètre de l’entreprise.
Mais n’y a-t-il pas déjà un terme pour cette fonctionnalité? Oui, c’est le groupe de travail (groupware). Ah oui, c’est vrai, le créneau sur ce nom est déjà bien plein. D’un autre côté, la RSE ne doit pas plaire à beaucoup de chef d’entreprises. Bref, Voila typiquement un article à visée commerciale…

Mais ce post n’est pas là pour critiquer l’article. Les acronymes posent un problème de gestion de leurs définitions. Celles-ci ont rarement une portée globale, elles n’ont souvent qu’une définition de portée locale ou régionale. C’est cette absence de centralisation qui, à priori, serait la source des conflits.

Comment vont se comporter les acronymes dans nebule?
Reprenons le cas de la RSE. En pratique, c’est l’objet cec7b8a511f6d30def09266e7595f1dd9a301b3ba868444d2b14236dccc127b1. Aujourd’hui, cet objet n’existe sur aucune machine supportant nebule, mais si il était créé ce serait avec cette empreinte (sha256).

Premièrement, cet objet peut être marqué par des liens de type subdivision s. Il est en effet possible avec ce type de lien de savoir qu’un texte, un article de presse par exemple, contient cet acronyme. Cela facilite la recherche.
Cet exemple d’acronyme est trop petit mais le principe reste valable, le même article de presse peut être téléchargé morceaux par morceaux par ses abonnés. C’est un fonctionnement de type P2P. Chaque morceau connu peut être téléchargé à des endroits différents, puis l’article de presse peut être reconstitué. En pratique, on accélère donc les échanges d’objets.

Ensuite, L’objet de l’acronyme peut aussi être marqué par des liens de type dérivation f. Ces liens peuvent renvoyer vers d’autres objets contenant la ou les définitions de l’acronyme.
C’est un intérêt pour résoudre les conflits autour des définitions d’acronymes. En effet, chaque lien est signé par une entité, donc on sait qui en est l’initiateur. Et comme toute entité gère individuellement ses propres relations de confiances, la définition d’un acronyme sera donc dépendante des entités à qui on fait confiance, mais aussi en fonction de leur niveaux de confiance relatifs.
Donc, si on a une forte confiance en l’état, ce sera la RSE. Si on a une grande confiance en l’auteur de l’article de 01net, alors ce sera le RSE. Si on est chef d’entreprise, il y a de fortes chances que ce soit la RSE de toute façon…

Le weblog et la relation d’objets – 2

Suite de la réflexion sur le weblog et la relation d’objets.

La première expérience avec sylabe sur une arborescence d’objets liés montre qu’il faut privilégier les liens de type dérivation f dans cet usage. Le lien de type l permet avec un objet méta de déterminer la relation entre deux objets dans l’arborescence. Mais c’est déjà ce que fait le lien de type dérivation f sans objet méta. Et si l’emplacement de l’objet méta est utilisé, il n’est du coup pas possible de définir ce que l’on peut appeler un contexte. C’est à dire de définir que les deux objets sont dans une arborescence bien délimitée et non tout le temps liés.

Ensuite, des liens de type dérivation f peuvent être utilisés sans objet méta afin de définir un objet dérivé d’un autre de façon générale. La différence, c’est que sans objet méta, le lien n’est pas utilisé dans l’affichage d’une arborescence d’objets. Mais cela n’empêche pas qu’ils soient utilisés pour améliorer l’affichage de certains objets spécifiques dans la représentation de l’arborescence. Ainsi, une arborescence d’images de grandes tailles gagnera à voir chaque image remplacée une à une par une versions réduite. C’est plus adaptée à l’affichage d’un navigateur web par exemple. La version réduite de chaque image étant liée à l’image originale par un lien de dérivation f.

Cette façon de faire résout les cas de gestion d’un article dans plusieurs nœuds et de gestion d’un article à plusieurs endroits dans le même nœud.

Reste à définir le cas de la gestion d’un nœud sous un autre nœud.

Le weblog et la relation d’objets

La mise en application des objets et liens nebule dans sylabe montre qu’un aspect important de la relation entre les objets a été sous-estimé.

Prenons l’exemple d’un blog ou d’un fil de discussion sur FB (en autres). Un utilisateur publie un article, un texte en fait. A cet article, tous les utilisateurs (ou presque) peuvent répondre, c’est à dire attacher à l’article un nouvel article. Ce nouvel article est aussi un texte, mais il est subordonné à l’article initial.
On peut ainsi ajouter une infinité d’articles subordonnés à l’article initial ou subordonnés les uns aux autres.

Première remarque à priori. L’article initial, celui de plus haut niveau, a tout intérêt à être déclaré comme étant un nÅ“ud. Mais ça n’est pas obligatoire en fait.

Ensuite, le lien entre l’article initial et les articles qui lui répondent est un lien créant une hiérarchie. Les liens nebule de type l ou f peuvent répondre à ce besoin.

La réflexion est cependant incomplète. Il faut tenir compte de :
– la gestion d’un article dans plusieurs nÅ“uds ;
– la gestion d’un article à plusieurs endroits dans le même nÅ“ud ;
– la gestion d’un nÅ“ud sous un autre nÅ“ud.

A suivre…

Le maître des poupées et le gardien de l’enfer

1/Le maître des poupées

Le maître des poupées, alias puppetmaster, vient de révoquer son ancienne incarnation :

63864e42204080051f524d5be0171920e0117a0e83d2131ac506ce3cbff7f1f4

Contrairement à ce qui avait été annoncé, c’est un lien de type d qui à été utilisé, et non un lien de type u. Ceci pour un problème de sécurité. Ainsi son ancienne incarnation ne peut pas révoquer ce type de lien… et ressusciter.
Le détail ici : puppetmaster.nebule.org/l/63864e42204080051f524d5be0171920e0117a0e83d2131ac506ce3cbff7f1f4

D’autres anciennes incarnations ont elles aussi été révoquées, à la fois pour la clé publique et la clé privée :
70668497b6a0ad481aa7e0c08131bc0d0be40cd7dde30a7de8613290d7c35543 puppetmaster (priv)
9e85d7d25af97760f8611b85c2765912606c7eec8307dc58c7782e34cc373c18 cerberus (pub)
905296b7070b8e7d601d9509893683d072bb22083006a9e545ceaf0228787c8c cerberus (priv)
d756efe28847a3723639aed49a40f08c22a576ff3f002750a18ad6a192717621 kronos (pub)
5f951d41db3b18001fbc8baf895d84cb4d460a6143b273b4f5b2d0e9b0d5c67b kronos (priv)

Dans le même temps, puppetmaster a reconnu plusieurs nouvelles entités :
01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4 cerberus cerberus.nebule.org
abdbaa31e404463ecc644f1eecdeb9b5f94428eb140fa5c66a7687ee96ed47aa kronos kronos.nebule.org
975571a8a470a6d975662e284f5ef1bd0396c06b31a2207b81bef2e24c5bf0c5 stéphane stephane.nebule.fr
Voir le détail ici : puppetmaster.nebule.org/l/88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

2/Le gardien de l’enfer

Le gardien de l’enfer, alias cerberus, vient d’être régénéré en tant que :

01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4
cerberus.nebule.org

Il est reconnu par puppetmaster. cf Cerberus et la mise en quarantaine d’objets.

Pour son rôle spécifique, il dispose de deux objets spécifiques :
nebule/danger
nebule/warning

Actuellement, les enfers n’ayant pas encore officiellement ouverts, cette entité est au chômage.
Seul le temps nous dira pour combien de temps…

Autorité temporaire : le maître des poupées

Une entité avait été généré en novembre 2012. Elle avait pour rôle de simuler une autorité de haut niveau. Voir l’article Autorité temporaire.

Le bi-clé de cette entité n’ayant pas été généré et manipulé dans des conditions spartiates de sécurité, il était difficile d’avoir pleinement confiance en cette entité.
Il fallait donc régénérer une nouvelle entité de façon plus propre.

Une machine a été installée de façon renforcée, et est prévue pour être manipulée hors réseau.
Tous les systèmes ont leurs faiblesses, et ont donc un besoin récurrent de mise à jour. Le système le moins vulnérable face à l’absence prolongée de mises à jours, c’est OpenBSD. C’est aussi actuellement le système le moins vulnérable par défaut. La non utilisation du réseau réduit très fortement les problèmes potentiels. Il est cependant possible, en cas de nécessité, de réaliser une mise à jour manuelle.
Le disque dur est partiellement chiffré.

Cette machine a donc permit de générer une nouvelle entité racine.
Ce rôle est toujours temporaire. Il ne se justifie que pour coller à un modèle de sécurité actuel, basé sur des autorités racines de confiance. On ne peut faire confiance à une entité que si elle est validée par l’entité racine. Cependant, ce modèle de sécurité n’a pas vocation à subsister en l’état. Soit il y aura d’autres autorités racines, soit elles disparaîtront toutes.

Puppetmaster, le nouveau maître des poupées est identifié comme :

88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

Et il reprend l’emplacement de l’ancien puppetmaster :

http://puppetmaster.nebule.org/

Pour l’instant, puppetmaster ne reconnaît aucune autre entité. Ce sera fait bientôt. Et le nouveau puppetmaster réformera (lien u) aussi officiellement l’ancien puppetmaster.
Le maître des poupées est mort, vive le maître des poupées!