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

Premiers liens signés en v2.0

Les deux premiers liens dans la nouvelle forme en v2.0 viennent d’être signés :

nebule:link/2:0_0:020210714/l>88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>5d5b09f6dcb2d53a5fffc60c4ac0d55fabdf556069d6631545f42aa6e3500f2e.sha2.256>8e2adbda190535721fc8fceead980361e33523e97a9748aba95642f8310eb5ec.sha2.256_88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>79bf4029cf6ee77b0f9db987fcb59c53434a8f2e36773d7a427ec869de04698ddb044bfe08d963732dec237ef56b03f003f4bcc491e293c0b6a7396a351b10e319aa80984bd5d7c0c812cd6a91a296d55ace2e6e6d266dd06c83f21814e272793e75e23cb8f70911ba845885f9e41636466b74e6a7f7e1c174e612776981e645273ac59410ab39606feb20102cf28834aa054008bb35191573189bb0266875dd82cbf12dc64d0eb77acf59e18c8336583faac32755450c00d559398fbd078871fcd9097ac476f67010a9d728a00860f1e34f66bd32b64093b834fcce2bf028193335ebedd1ae27e29df3b8184360bee9dbc707135c54ef48d3efc096b32ba33681925afb8d4e7d4f91598f4d250eb9d27b96762727610a87317892033e84e6e7198837a10ef5e8582ecb98d6aef00e7b4ef2d536cb2063b476d21a8abaf6678462e329bf08bb9159ec4a7358b1e6b15252bd1acf471eb43895edc4caaee58e9d1fcd36cd21b7fc45fb43443c3408de80c1aa3d8c45c71071bfebbfa0c82f747e97f0668d628a3bb5f18cf105b5c16ac14fa61730fdf97342add718ee6c55cf576b060027ce5dfd3651349ff3163011f58cdc2140ea3ef9d2bfefe1d105498722b6ff3c0993aaffa0f0625e5bd2503cf289ec3e694b43616134d1a938dfe1d050b4106f466b23c2dc446e7f1d96a942aaa73c694a8434bdf549fde985ff939142.sha2.512
nebule:link/2:0_0:020210714/l>88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>970bdb5df1e795929c71503d578b1b6bed601bb65ed7b8e4ae77dd85125d7864.sha2.256>5312dedbae053266a3556f44aba2292f24cdf1c3213aa5b4934005dd582aefa0.sha2.256_88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256>58ca04cc43fc46c7a5176f2ff8f93754da9cfaabff2f12a3c9e6453d3dd3eeedd0208477f9e62c085a6f32583a127467696d7af980fe18a85a7951a6deea6372ca9f0c965d0a08fa159f241a680d5dba69449acb03043fc8021b93a2e34a1c3fb93385250f5ebf7a457fd38f2c6b1e500614f19b37bd37416342ddd94385ec2f5185fddde6d803fc1f89dabe6aebcd55490688cdbe5c779ae2b81d7a4b65c57fd6b35b6ad0fb20881f12c04e34a1730e254530a9c69fdaa9c1ef76fa6248a6e22417e25758837c7378f97af5c3d2cfe88fe9711ba705e2d017fe7ff4c97cbb44600e0d7b32e1c2f97467d8e79d48fc5d6dbd3d581bb831582be7f1a918609cd4a64e4d621bababaddde6da3621f24220ed7dc2ae585fe9b7f9cd71fe18a1a75778c54bdf1e7ad066e10c36e7fb2a4577f9d1bc7be1f80363d1a3e58e34ee4971ccd0a8a8b45665b1234909104558cb210ea402cb7822e3f4c5e1095c4f6a8a86b432b7c77028c76d38dd171a009dd7b251f74ea112739b91cfd8a6c665546bb984dc2fd1f59212a59f84154556bcdfade82c1b049e91a1befa45f2511f02123aa3f7718b0c64aeca984eb70cb9841e933603221765899384e1d3467cb31071ae3071e741f9689735a7e0c8cf7e202b926260067112fec8b24f991a6b35868fbb3653f2be774574d87e1a0fe9222774f6ede5b38c8393d72ff866faa40c5b706f.sha2.512

Ces deux liens concernent l’entité puppetmaster et sont ceux posés par défaut lors du premier lancement du bootstrap, lorsqu’il n’y a encore rien d’autre.

Ils sont la particularité d’avoir une signature faite sur un hash à 512bits.

P̩rim̬tre fonctionnel bootstrap Рlibpp

Jusque là le bootstrap intégrait une bibliothèque PHP procédurale (libpp) de nebule héritée et remaniée avec le temps mais ayant gardée tout ce qui était fonctionnel.

Or pour le bootstrap certaines fonctionnalités n’ont pas d’utilisé. Et comme il va falloir réécrire et revoir en grande partie cette bibliothèque, c’est le bon moment pour la simplifier. Et on va commencer par supprimer les parties sans utilité.

Au niveau cryptographie, seul la génération et la vérification des liens est utile. Le chiffrement d’objets n’a pas de raison d’être présent. La dissimulation de liens n’a pour l’instant pas d’utilité non plus.

La gestion des attributs d’objets n’a pas d’utilité mais il faut garder la capacité à suivre les mises à jours d’un objet et être capable d’aller chercher des mises à jour. Mais afin de réduire la complexité, seul le HTML sera utilisable.

Les liens supportés seront mono-registre et mono-cœur.

Le travail fait avant par la bibliothèque de nebule en bash permettait de générer un nouveau puppetmaster. Cela va devenir une nouvelle fonction dans le périmètre du bootstrap, et donc de la libpp. Il faut donc conserver la capacité de générer de nouvelles entités et de générer des liens.

Une autre partie qui va être intégrée au bootstrap, c’est la possibilité de faire les mises à jours des applications. Il faut donc que le bootstrap soit capable de parler avec le reste du monde. Seul le HTTP sera pris en compte pour ça. Et cela concerne aussi les entités.

Tout le reste fera partie de la bibliothèque en PHP orienté objet (libpoo).

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…

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

Reprise du bootstrap en programmation procédurale

Depuis une semaine, le code du bootstrap en PHP procédural est en cours de refonte complète. La base utilisée était assez ancienne, elle datait d’avant le passage à la programmation orientée objet.

Ce travail correspond presque à une ré-écriture de zéro du bootstrap. L’inconvénient de cette version c’est qu’il sera pls difficile d’utiliser la librairie nebule sur autre chose qu’un système de fichier, par exemple une base de données. Mais le gros avantage c’est que la maintenance de la librairie est fortement simplifiée par rapport à sa version orientée objet. En effet le bootstrap nécessite quelques ajustements et notamment la désactivation de certaines fonctionnalitées. Ce serait trop compliqué de garder deux librairies orientées objets en parrallèle.

Cette nouvelle version introduit cependant quelques nouveautées :

  • Le changement de puppetmaster est complètement fonctionnel.
  • La version de librairie utilisée avec une application est mémorisée pour cette application (le temps de la session PHP) jusqu’à demande d’activation des mises à jours ou fermeture de la session par l’utilisateur.
  • En plus de l’instance de l’applicaiton proprement dite, on mémorise aussi dans la session PHP les instances des classes d’affichage Display, d’action Action et de traduction Translate pour gagner en performance.

La page du bootstrap est en cours de mise à jour pour suivre cette évolution.

C’est cette version qui sera désormés utilisé pour les nouvelles versions des applications.

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.

Auto-installation depuis le bootstrap

Le bootstrap est en cours de modification pour pouvoir être posé tout seul sur un nouveau serveur. Il crée dans ce cas l’environnement nécessaire à son fonctionnement et télécharge ce qui manque.

Le but est ici de simplifier au maximum l’installation. Il restera ensuite à changer l’application par défaut, mais c’est un autre problème…

20150926 nebule_bootstrap_-_2015-09-27_00.43.11
Le bootstrap en cours de création de son environnement de travail.

Il reste à faire la partie qui génère une nouvelle entité pour l’instance locale. Par défaut c’est le puppetmaster, mais il n’y a pas de raison que ce soit lui partout. Avec la génération de cette entité, il sera affiché le mot de passe pour que son propriétaire puisse se l’approprier.

Liens marqués entre le puppetmaster et les autres entités

Il y a quelques jours, le puppetmaster a été réveillé pour générer de nouveaux liens. De nouveaux objets de nebule sont maintenant reconnus comme des objets à usage réservé :

  • nebule/objet/entite/maitre/securite
  • nebule/objet/entite/maitre/code
  • nebule/objet/entite/maitre/annuaire
  • nebule/objet/entite/maitre/temps

Et il permettent de désigner via un lien de type f les différentes entités qui ont les rôles correspondants.

Le code de la librairie nebule en php et le bootstrap s’en servent désormais pour retrouver les entités avec ces rôles.

CF : sylabe – Avancement

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…

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…

Gestion de bachue

L’entité bachue existe depuis un certain temps en tant que telle. Mais il est difficile de diffuser dans de bonnes conditions les objets et liens qu’elle signe. De bonnes conditions sont ici à interpréter comme conditions de sécurité et facilité d’exploitation.

Cette entité est matérialisée par une clé RSA en deux parties, une publique et une privée. La clé privée doit être manipulée avec précaution dans un environnement strictement contrôlé. La perte ou la divulgation de la clé privée remettrait en question tout ce qui a été diffusée par cette entité, surtout si c’est du code. En terme de sensibilité, elle est en troisième position derrière puppetmaster et cerberus.
Les technologies employées actuellement ont toutes des vulnérabilités en ligne à certains moments. Si ces vulnérabilités peuvent être comblées, il n’en demeure pas moins une petite période de temps pendant lequel elles deviennent à la fois publiques et non encore comblées. Le problème est pire encore avec les vulnérabilités non publiques (0-days) contre lesquelles une machine unique ne peut pas avoir de défense efficace. Donc la machine qui héberge l’entité bachue, la machine hôte, ne peut être laissée connectée sur un réseau externe.
Tout ce qui est manipulé par nebule supporte sans aucun problème les transferts via le réseau ou via des supports amovibles et est manipulable sur des systèmes d’exploitations différents. Il est aisé de travailler avec des stations non connectées et de diffuser simplement l’information via des relais en ligne même plus faiblement protégés.
Chaque machine à un rôle strictement définit avec des règles de gestion en conséquences. Toutes les machines ne sont pas installées avec le même système d’exploitation et toutes les machines ne reposent pas sur la même architecture matériel. Des machines tournent notamment avec un processeur SUN SPARC ou un processeur PowerPC en plus des classiques processeurs Intel/AMD 32bits ou 64bits. Microsoft Windows a été écarté pour sa forte présomption (impossible à démontrer ou à réfuter) de compromission par des entités étatiques.

Voici le schéma de principe retenu actuellement pour la gestion des objets et liens par bachue :

20140301 sync bachue

1 – La station de développement est unique mais pourra s’étendre à plusieurs machines. C’est une machine assez classique et qui sert à bien d’autres choses que nebule. C’est actuellement le principal point de faiblesse, le principal point d’entrée d’une attaque.

1->2 РDepuis la station de d̩veloppement, on exporte les liens et objets associ̩s sur une cl̩ USB vers la station h̫te bachue.

2 – La station hôte est la seule et unique machine sur laquelle sera déverrouillée l’entité bachue. C’est la machine la plus critique du dispositif. Les seuls vecteurs d’attaque sont la clé USB et un accès physique frauduleux.
Toutes les clés USB insérées sont systématiquement nettoyées. Le nettoyage consiste en la suppression de tout fichier autre que le fichier ‘l’ ou ce qu’il y a dans le dossier ‘o’. Le fichier ‘l’ ne doit contenir que des caractères imprimables. Le dossier ‘o’ ne doit pas contenir de sous dossiers. Les fichiers du dossier ‘o’ doivent avoir une empreinte valide.
Si les liens sont ceux attendus, ils sont signés par l’entité.
Cette station ne se met pas à jour régulièrement des correctifs de sécurité. Ce processus est réalisé à la main si nécessaire. La machine est préparée pour résister aux deux vecteurs d’attaques connus.

2->3 РLes nouveaux liens sont export̩s par la m̻me cl̩ USB vers le serveur relais.

3 – Le serveur relais contient une copie de ce que l’entité bachue partage publiquement. Il n’est pas très critique puisqu’une compromission serait facilement détectée dans les liens et objets. La suppression de certains objets ou liens serait facilement réparable. Ce serveur est protégé derrière un pare-feu qui bloque toute tentative de connexion depuis Internet vers le serveur ainsi que toute connexion non référencée depuis le serveur vers Internet.
Toutes les clés USB insérées sont systématiquement nettoyées. Le nettoyage consiste en la suppression de tout fichier autre que le fichier ‘l’ ou ce qu’il y a dans le dossier ‘o’. Le fichier ‘l’ ne doit contenir que des caractères imprimables. Les liens dans le fichier ‘l’ doivent être de bachue uniquement et leurs signatures sont vérifiées. Le dossier ‘o’ ne doit pas contenir de sous dossiers. Les fichiers du dossier ‘o’ doivent avoir une empreinte valide.
Ce serveur se tient automatiquement à jour de correctifs de sécurité directement sur Internet.
Les nouveaux objets sont ajoutés aux objets déjà présents. Les nouveaux liens sont insérés dans les fichiers de liens via la librairie nebule.

3->4 – L’ensemble des objets et liens sont synchronisés vers le serveur miroir public avec rsync encapsulé dans ssh.

4 – Le serveur miroir est un serveur web disponible en permanence sur Internet. Il n’est pas critique dans sont contenu puisque toutes modifications des objets ou liens seront immédiatement rejetées par les autres entités. Il n’est que peut critique en terme de disponibilité puisque les objets et liens peuvent être diffusés par d’autres entités. Il n’est pas critique non plus en terme de sensibilité des données qu’il partage puisque toutes les données sont soit librement publiables soit chiffrées.
Ce serveur se tient automatiquement à jour de correctifs de sécurité directement sur Internet.

4->5 РChaque entit̩ peut venir consulter les liens et objets sur le serveur miroir public.

5 РLa station cliente est autonome. Elle g̬re ses propres processus et assure sa propre protection.

Activation de l’annuaire d’entités asabiyya

Introduction

L’entité annuaire asabiyya se charge de parcourir régulièrement les entités qu’elle connaît à la recherche de nouvelles localisations d’entités et de nouvelles entités.

Elle est validée par puppetmaster.

Description

Toutes les entités ne connaissent pas toutes les autres entités, et encore moins leur localisation à tout instant. Le rôle de l’annuaire est de référencer des ressources ainsi que leurs emplacements. Ici les ressources sont des entités et leurs emplacements sont leurs localisations sur le réseau numérique.

L’annuaire est dans nebule la première étape du lien social entre toutes les entités.

L’entité annuaire asabiyya se met à jour à intervalle régulier. Aujourd’hui, l’intervalle est de une heure. Pour cela, elle commence par récupérer chez toutes les entités qu’elle connaît les liens de l’objet nebule/objet/entite/localisation . Ensuite, à partir de ces liens qu’elle parcourt, elle recherche uniquement les liens spécifiant une localisation d’entité et en extrait l’identifiant de l’entité ainsi que l’identifiant de la localisation. L’objet de chaque entité ainsi identifiée (c’est à dire la clé publique) est téléchargé si sont type-mime est application/x-pem-file. Pour les localisations, c’est à la fois les liens et l’objet contenant la localisation qui sont téléchargés si le type-mime de l’objet est text/plain. Le type-mime étant un lien, le fait de synchroniser en premier les liens d’un objet permet de connaître sont type-mime sans le télécharger. Continuer la lecture de Activation de l’annuaire d’entités asabiyya

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 :

Entit̩ annuaire РMise en ligne

Comme annoncé dans le post sur l’entité annuaire, une entité vient d’être créée :

4e72933c991c2bb27415cfeff02e179b9a3002934e472142c4f612e3893e46e1

Elle se nomme asabiyya et est localisée en http://asabiyya.nebule.org/ et http://asabiyya6.nebule.org/ (IPv6).

Le script qui va lui permettre l’auto-découverte des autres entités n’est pas encore en place, mais il devrait être assez rapide à faire. Il s’agit en fait de parcourir toutes les entités déjà connues en cherchant l’objet contenant nebule/objet/entite/localisation (0f183d69e06108ac3791eb4fe5bf38beec824db0a2d9966caffcfef5bc563355).

On constate visuellement dans les liens la différence entre une clé RSA de 2048 bits et une autre clé RSA de 4096 bits, celle de puppetmaster. La signature est deux fois plus longue et donc les liens ont une taille qui double presque.

Hash et type des objets – suite

Suite à la décision de modifier deux objets de base niveau, hash function et mime-type, les premières répercussions ont été faites sur puppetmaster, cerberus et kronos.

De fait, les premiers liens de type x ont été générés. C’est à dire que ce sont les premiers liens qui permettent la suppression d’autres liens précédemment créés.

Cela se voit sur le graph de l’objet entité de puppetmaster :

C’est un peu fouillis parce que le précédent lien supprimé est remplacé par un nouveau lien dont l’objet meta est différent. Il faudra améliorer le tracé de ces liens…

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!

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…).