Blockchain et nebule – Le cas de la messagerie

Suite de l’article Blockchain et nebule.

La blockchain ne permet pas juste de manipuler de l’argent. Une forme de blockchain avec une portée réduite peut se retrouver dans la messagerie. Lorsqu’un message est transmis à des destinataires, ceux-ci vont marquer le message comme lu lorsqu’ils vont l’ouvrir les uns après les autres. On considère ici cette marque de lecture comme publique. Si un message est référencé par une empreinte et que les marques de lectures référencent cette empreinte, alors nous avons une chaîne de blocs indirecte. Un message ne référence pas le message précédent comme cela se fait avec un bloc, mais chaque message est vu et validé collectivement dans une période de temps (idéalement) réduite. Cette validation par les destinataires scelle les messages dans le temps et la chaîne est constituée par l’enchaînement des messages dans le temps, dans une conversation. Il est possible grâce à ce mécanisme de détecter les tentatives de suppression ou d’insertion de messages.

Cette façon de marquer les messages et de les figer dans le temps est une base de travail possible pour l’implémentation de l’équivalent d’une blockchain via les mécanismes de nebule et surtout avec ses restrictions. Ce mécanisme peut permettre un fonctionnement local là où la blockchain nécessite impérativement un consensus global et une cohérence mondiale.

L’utilisation de l’entité maître du temps kronos ne permet de résoudre qu’une partie du problème.

R̩organisation des entit̩s sp̩ciales Рinventaire de d̩part

L’organisation actuelle des entités spéciales est assez limitée. On a d’un côté les autorités globales imposées par le code et de l’autre quelques autorités locales aux rôles limités.

Le bestiaire

Premier constat fait depuis un moment, l’entité maître unique puppetmaster est par définition un risque même si pour l’instant c’est la seule façon raisonnable d’avoir une cohérence de l’ensemble. Le but serait d’avoir une entité multi-tête à seuil dont le contrôle est réparti entre plusieurs porteurs. Cette entité n’a que pour mission de désigner les autres entités spéciales globales dont la plus utilisée aujourd’hui est l’entité maître du code bachue. L’entité puppetmaster a un rôle d’autorité et sa portée est globale.

L’entité spéciale cerberus permet de gérer les bannissement d’objets. C’est un peu le rôle de police. L’enfer n’ayant pas encore officiellement ouvert, cette entité n’est pas utilisée mais elle pourrait être très rapidement sollicitée fortement pour tout et n’importe quoi.

L’entité spéciale maître du code bachue est aussi désignée autorité mais est subordonnée au puppetmaster. Son rôle est uniquement de gérer le code sous toutes ses formes.

L’entité spéciale kronos n’a qu’un rôle théorique pour l’instant et n’a que brièvement été utilisée dans des expériences. Cette entité va générer des repères temporels fiables. Mais je pressens qu’elle va devenir incontournable à l’avenir, et peut-être critique pour certains usages.

Enfin, l’entité spéciale asabiyya va être utilisée pour relier les gens avec de la confiance. Elle n’est pas encore utilisée non plus.

Les rôles

On peut distinguer plusieurs catégories d’entités. Les autorités désignes des entités sur des rôles. Les administrateurs font des choix de configuration du code et des applications. Les gestionnaires gèrent des objets, des applications, des entités. Et chaque rôle peut avoir une portée locale ou exceptionnellement globale.

Il existe déjà des méthodes d’organisation qui avaient été retranscrites dans l’article Être relié ou ne pas être. Le modèle RBAC est implémentable par les liens de nebule, le modèle OrBAC semble être moins adapté à nebule parce qu’il sous-entend une une organisation, une structure, qui n’est pas portée par nebule.

La liste de grandes catégories de rôles à compléter peut déjà prévoir l’autorité (authority), la police, l’administrateur (administrator), le gestionnaire (manager), l’entité de recouvrement (recovery)…

L’attribution de rôle est additive, les rôles s’ajoutent à une entité mais il n’y a pas de négation de rôle. Pour les rôles locaux, il est possible de supprimer un rôle d’une entité. Il n’y a pas d’inhibiteur de rôle mais juste un une suppression de lien.

La réflexion continue…

Ajustement des noms de domaines

Tous les noms de domaines liés aux entités de nebule ont été revus. Le puppetmaster est toujours l’entité autorité racine sous laquelle on trouve maintenant les rôles :

  1. security.master.nebule.org
  2. code.master.nebule.org
  3. directory.master.nebule.org
  4. time.master.nebule.org

Chaque nom de domaine correspondant à un rôle est renvoyé vers une entité déterminée, à savoir aujourd’hui dans l’ordre :

  1. cerberus.nebule.org
  2. bachue.nebule.org
  3. asabiyya.nebule.org
  4. kronos.nebule.org

L’idée, c’est que en cas de problème une entité peut être remplacée par une nouvelle. Et c’est pareil dans le code de la librairie nebule en php.

Les adresses en IPv6 ne sont plus fonctionnelles, mais ça reviendra.

Gestion temporelle partielle

Il y a deux façons de gérer le temps et deux façons pour le prendre en compte.

C’est la suite des articles Horodatage, ISO 8601, suite et Marque de temps.

La référence de temps, ou pas

On peut gérer le temps comme étant un prérequis commun à tous les acteurs. Dans ce cas, toutes les machines doivent synchroniser leurs horloges internes sur une source commune. Tout le monde travaille avec la même heure, le même espace temps et la même référence. Ici on ne tient pas compte du fuseau horaire qui est un bricolage de décalage non pas temporel mais sur l’affichage uniquement. Aujourd’hui, l’orientation de tous les systèmes d’informations, c’est la synchronisation globale, c’est à dire la même partout sur la planète.
On pourrait aussi simplement considérer que chaque machine, chaque utilisateur, a un espace temps qui lui est propre. Pas de synchronisations à faire mais se pose alors l’interprétation d’une date donnée par une autre machine. Il faut prévoir un mécanisme de correction du temps des autres machines, par rapport à une référence. On retrouve cette référence commune mais elle peut dans certains cas être soi-même, c’est à dire je suis à la bonne heure et je compense l’heure des autres. En cas d’absence de référence externe, il faut retenir le décalage de chacune des machines avec lesquelles on communique.
Avoir une référence commune implique une communication régulière avec cette référence. Il faut donc une connexion réseau, même partielle. Plus la précision attendue dans la synchronisation est forte, plus les moyens tant en réseau qu’en relais doivent être importants, rapides et fiables. Sur des réseaux isolés ou fortement fragmentés, la synchronisation du temps devient illusoire. Et cela peut arriver partout sur la planète : catastrophe naturelle, guerre, dictature, repli sur elles-même des nations, etc…

Le problème sur la référence de temps n’est pas que théorique. Ce ne serait pas « juste un problème d’affichage ». Beaucoup de protocoles de sécurisation s’appuient aujourd’hui sur le temps et exigent un horodatage assez précis. Lorsque l’on se connecte au site web de sa banque, lorsque l’on renvoie un message signé, lorsque l’on se connecte à un réseau d’entreprise, les jetons de session et autres certificats électroniques ont une durée de vie limitée ou une date d’expiration. Tous ces services impliquent d’avoir un réseau pour fonctionner et peuvent délivrer une référence de temps en même temps que ces services. Par contre, des documents comme les passeports sont aussi émis avec une date d’expiration et il serait difficile de vérifier leur validité sans une référence de temps commune.

Le système de gestion du temps dans nebule est encore aujourd’hui basé sur l’horloge interne de la machine qui exploite les liens. Il utilisera aussi l’entité kronos comme référence. Mais il est prévu de calculer et mémoriser les décalages de temps entre machines. Cette capacité à mémoriser les variations de temps rend l’ensemble plus résilient en cas de catastrophe ou tout simplement de fragmentation volontaire des réseaux. A faire…

Sur un réseau maillé comme sur Internet, la structure globale ressemble à un fractal dans lequel on peut zoomer et retrouver les mêmes formes de connexions entre nÅ“uds de réseau. Un réseau Internet fragmenté serait sûrement toujours maillé et toujours interconnecté, mais la structure globale ressemblerait plutôt à une nébuleuse, c’est à dire sans structure marquée. Dans ce deuxième cas, les synchronisations de temps seraient souvent conflictuelles.
Le postulat que l’on peut simplement synchroniser tout le monde sur une seule et unique référence de temps est une facilité de notre époque. Mais c’est une facilité qui n’est ni évidente ni définitivement acquise.

Prise en compte des événements futurs, ou pas

Avec synchronisation du temps entre les machines ou pas, il peut arriver d’une marque de temps soit dans le futur ou interprétée comme telle. Que fait-on dans ce cas ? Est-ce une erreur de l’émetteur ? Est-ce une erreur de synchronisation ? Est-ce une erreur de zone de temps ? Est-ce un acte malveillant ?
Et c’est pareil pour une date du passé qui ne correspond manifestement pas à l’ère informatique. Est-ce une erreur de référence de temps ?

On peut tenir compte d’une marque de temps problématique et l’interpréter telle quelle vis-à-vis des autres date. Dans le cas d’une suppression de lien marqué dans le futur, cette suppression est valable. Mais, parce qu’elle est dans un futur un peu lointain, il va devenir impossible de réhabiliter ce lien avant cette date puisque sa suppression sera toujours valide temporellement. Il faudrait un nouveau lien plus loin dans le futur qui, lui, empêcherait la suppression avant cette nouvelle date dans le futur… On ne s’en sort pas.

On peut ne pas tenir compte d’une marque de temps invalide et l’écarter du traitement comme étant incohérente. Dans ce cas un lien de suppression dans le futur ne serait plus utilisé avant que notre espace temps ne soit arrivé effectivement à cette date.
Mais dans ce cas la synchronisation de temps ou l’utilisation d’une référence de temps a beaucoup plus d’importance puisque des dates du calendrier arabe, hébraïque, indien, chinois ou copte n’ont pas la même signification. Des événements interprétés comme étant dans le futur seront automatiquement ignorés alors qu’ils sont peut-être valides.

La non prise en compte de liens avec une date dans le futur semble la meilleur solution, mais elle n’est pas encore implémentée dans nebule. A faire…
L’implémentation doit aussi permettre de gérer sereinement les décalages, prévisibles, du temps entre différentes machines même si elles ont la même référence de temps. En dessous de la seconde, une synchronisation globale est illusoire. Avec une connexion à Internet intermittente, une précision de l’ordre de la minute est plausible. Il faut donc prévoir un paramètre afin de définir le décalage maximal de temps que l’on accepte pour des liens dans le futur.

L’utilisation de la norme ISO8601 est indispensable mais pas suffisante. Tous les calendriers n’utilisent pas cette forme et bien sûr n’ont pas la même référence de temps. De plus, si il permet une grande précision, il ne permet pas de manipuler le temps sur ce que l’on appelle le temps long. Il serait intéressant de pouvoir manipuler d’autres calendriers, peut-être avec un préfixe spécifique.

Lien juste à temps

Les liens de nebule n’ont pas vocation à permettre un traitement complexe des données, juste à permettre leur transmission et faciliter le traitement.

Manipuler des données avec des échéances n’est possible qu’en associant un objet contenant une date avec un objet méta spécifique. Le traitement à échéance est réalisé par le programme qui interprète cette forme de lien. Il est facile de réaliser au niveau des liens d’une prise en compte « Ã  retardement » d’un lien. Le modèle pourrait être l’encapsulation d’un lien dans un autre lien d’un type particulier, sur le modèle du lien offusqué. Au lien d’une clé de chiffrement, ce pourrait être une date de prise en compte.
Ce nouveau type de lien est de fait en concurrence avec un lien avec une date dans le futur. Mais cela présenterait quand même quelques avantages. Le premier, c’est que la date pourrait être aussi une période de prise en compte. Mais surtout, là où un lien dans le futur pourrait être supprimé parce que considéré invalide, un lien dédié à cet usage serait beaucoup plus légitime.

Cette idée est encore à réfléchir…

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…

Marque de temps

Le marquage du temps tel que réalisé aujourd’hui ne me convient que moyennement. Ce marquage est fait pour chaque lien et permet de leur donner un sens temporel.

La marque de temps est basée sur une norme reconnue : ISO 8601:2004. Elle est forcément absolue. Éventuellement, ce peut être un simple compteur incrémental.
Mais cette norme est loin d’être universelle. Elle se base exclusivement sur un calendrier grégorien. Donc sa référence de temps est biblique, ce qui a une connotation religieuse pour un sujet technique. Passe encore. De par sa référence et sa gestion du temps le plus grand, l’ordre de grandeur du temps géré est de quelques milliers d’années. En gros, on peut indiquer une date entre -9999 et 9999 années.
Certes, cela laisse de la marge dans nos sociétés modernes où on se préoccupe plus de la nano-seconde que du siècle. Mais les Mayas avaient à leur époque, il y quelques temps déjà, un calendrier pour gérer le temps profond. Leur calendrier était à même de donner une date à la création de la terre (si cela a un sens), et sans référence religieuse. Ils ne pouvaient pas par contre gérer finement le temps à petite échelle, en dessous de la journée…

Lorsque l’on aborde le sujet de la gestion du temps avec de multiples références, il faut penser au moyens de synchronisation de ces horodatages. Il faudra pour ça réactiver l’entité kronos

Il n’y a pas 36 solutions pour améliorer le marquage du temps.
On peut ne plus reconnaître de format de temps standardisé… et tenter de déterminer par la forme de la marque de temps la date indiquée dans sa propre référence de temps. Ce travail, fastidieux, peut être facilité par un lien de définition de la marque de temps utilisée par une entité.
On peut reconnaître par défaut le format ISO 8601 et accepter d’autres formats sous la forme d’un compteur. Ce compteur, dans ce cas doit avoir une forme progressive dans le temps pour pouvoir être interprétée au moins comme compteur à défaut de pouvoir en extraire une date fiable.
On peut reconnaître par défaut le format ISO 8601, accepter le compteur et accepter un indice de formatage spécifique pour des marques de temps autres. Le compteur doit toujours être progressif.
Enfin, on peut ne reconnaître que le compteur et une marque de temps préfixée de sont type. Cette dernière solution intègre à peu près les marques de temps actuellement utilisées dans nebule au format ISO 8601 comme de simples compteurs.

IPv6 et nebule

Il est parfois bien difficile de se préparer à l’avenir et d’abandonner les choses au passé.

Il est une chose qui devrait déjà appartenir au passé, ou du moins être en voie d’extinction, voir entretenu par quelques antiquaires : IPv4 !!!

IPv6, c’est le futur.
Ce devrait même être le présent en fait… mais c’est encore considéré comme le futur. Même en France beaucoup de gens n’ont pas nativement accès à l’Internet en IPv6, leur FAI (ou ISP) ne l’implémente pas. Cela ne veut pas dire forcément de systématiquement l’utiliser, mais juste de pouvoir le faire.

Et pour nebule ?
Bonne nouvelle, l’implémentation en bash fonctionnement indifféremment en IPv4 et IPv6. En fait, c’est parce que cela ne dépend que de l’hôte. Si celui-ci a un accès IPv6, les programmes savent l’utiliser. D’ailleurs, on peut aller plus loin. Si l’hôte n’a que IPv6, ça marche aussi !

Donc, depuis hier soir, toutes les entités importantes de nebule sont accessibles aussi en IPv6 :

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…

Grandes migrations

Toutes les entités étaient accessibles via des liens en nebule.org .

Depuis une semaine, certaines entités ont changé de domaine. Les nouvelles localisations des entités concernées :

Les entités à usage publique restent dans le domaine nebule.org, c’est le cas de :

Ces localisations sont des domaines DNS, et de fait des serveurs http derrière. Cependant, la localisation est certes obligatoire pour retrouver une entité, mais elle n’est pas par nature strictement liée aux noms de domaines. Ni liée au réseau d’ailleurs. Certaines machines ne répondent pas à leur localisation (alpha.nebule.fr), et le type de localisation évoluera plus tard vers d’autres formes (ftp, smtp, xmpp, etc…).