Catégorie : annuaire

Application d’authentification et gestion des entités déverrouillables

La gestion des entités déverrouillables sur une instance de serveur est pour l’instant rudimentaire. Toute entité qui réussi à poser une clé publique et une clé privée sur l’instance peut se connecter. Il serait intéressant de pouvoir restreindre ces entités à un groupe connu et alimenté par les autorités locales. Ce groupe pourrait être vu comme un annuaire. On peut imaginer aussi un mécanisme de cooptation. Et on peux imaginer un bannissement sur liste noire même si cette méthode doit être couplée à un autre mécanisme.

Dans la lignée de la réflexion, il pourrait être intéressant de déléguer l’authentification à une application dédiée avec retour à l’application d’origine si ça se passe bien.

Réputation d’entité et chaînage

Le système de chaîne de blocs tel que abordé dans les articles Blockchain et nebule et Le cas de la messagerie ne peut être implémenté dans nebule.

Cependant la réflexion sur un mécanisme proche en terme de fonctionnalité ouvre tout un champs de possibles. Cela permet notamment d’introduire de la confiance là où à priori il n’y en a pas.

Il est ainsi envisageable de gérer la réputation des entités non pas dans des blocs mais par de multiples signatures de liens de réputations (positifs ou négatifs) par diverses entités. C’est le même mécanisme que la pondération. Le problème dans ce cas est la non prise en compte de liens d’entités que l’on ne connaît pas. L’annuaire est peut-être un facilitateur à ce niveau pour le cas d’entités inconnues.
Une nouvelle entité devrait commencer par se déclarer auprès d’un annuaire. Depuis l’annuaire cette nouvelle entité aurait accès aux autres entités, mais pas immédiatement puisque n’étant connue d’aucune entité, tout dialogue serait impossible. Le mécanisme dans l’annuaire peut prévoir une sorte de mise en relation entre entités qui ne se connaissent pas. Les premières entités rencontrées pourraient être des modérateurs. Ensuite, en fonction de la réputation acquise auprès des premières entités il serait possible pour la nouvelle entité de commencer à solliciter, toujours via l’annuaire, de nouvelles entités plus ‘timides’. Un mauvais comportement de la nouvelle entité dès le début entraînera rapidement un bannissement.
Pour éviter les bannissement abusifs par coalition, parce qu’il faut considérer qu’on ne peut pas plaire à tout le monde, il faut comprendre que le bannissement ne sera effectif que pour les entités ayant émis une réputation négative et toutes autres entité qui leurs font confiance. Mais la nouvelle entité sera toujours reconnue par les entités ayant émis une réputation favorable.

Nous devons dès maintenant considérer que, à moyen terme, l’intelligence artificielle sera à même de tromper, mieux que les humains, les barrières de filtrage anti-robots. Les techniques actuelles fonctionnent encore mais leurs méthodes sont déjà vouées à l’échec. Et puis l’important n’est pas de filtrer des robot qui peuvent être légitimes, mais plutôt d’isoler les sources d’actes malveillants. Et là nous ne sommes plus dans la détection du qui suis-je mais dans la détection comportementale. On peut imaginer aussi que des entités (humains ou robots) se comportent correctement un certain temps afin de monter en estime et traverser des barrières comportementales mais dans le but de s’attaquer à une cible de haute valeur, dans ce cas le prix en temps de création est élevé.

Transfert de liens et de confiance

Les réseaux fragmentés posent des problèmes plus importants que le maintient de la cohérence du système d’horodatage. CF Gestion temporelle partielle.

Certains protocoles de sécurisation des échanges deviennent bancales sans synchronisation de temps. Mais il y a plus grave. La cohérence du temps entre plusieurs machines peut être négligé sur une courte période, les horloges ne vont pas dériver exagérément et il y a peu de change que des certificats expirent. Par contre, il devient difficile de transmettre de nouveaux contacts avec un grand niveau de confiance. les relations de confiance sont souvent dépendantes de services centralisés, services qui ne sont plus forcément joignables. Ces services ont le rôle d’annuaires globaux. Il faut dans ce cas faire confiance aux seuls intermédiaires que l’on a sous la main, et que l’on connaît (au moins dans nebule). On doit utiliser des entités comme des annuaires locaux.

Dans ce cas, il est peut-être utile de voir si la définition d’un nouveau type de lien ne pourrait pas répondre à ce besoin. Ce serait un lien signé par une entité que l’on connaît et qui transmettrait un lien d’une autre entité, inconnue. Un lien serait encapsulé dans un autre de la même façon que pour un lien offusqué. La validité et la pondération du lien de l’entité inconnue seraient les mêmes que si le lien venait de l’entité connue. Ce serait une forme de relais de liens.

Ce type de lien aura peut-être aussi une utilisé pour les annuaires d’entités. Cela pourrait faciliter la mise en relation entre deux entités qui ne se connaissent pas.

Mais, c’est aussi un risque qui faut analyser. On commence dans ce cas à prendre en compte des liens d’une entité que l’on ne connaît pas et que l’on ne peut directement vérifier. Il faut voir ça comme si l’entité qui fait le relais des liens s’appropriait elle-même le lien. Cette entité peut diffuse des liens invalides, c’est à dire dont la signature est invalide, sans que l’on puisse le vérifier. L’affiche de ces liens ou leur interprétation doit être peut-être adapté pour montrer cette particularité…

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…

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

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.

Entité annuaire

L’annuaire a deux fonctions principales. La première est de référencer toutes les instances connues d’un certain type de ressource. La deuxième est de transmettre une localisation (physique ou numérique) pour chacune des instances concernées. Le type de ressource, le type de localisation ou le caractère privé de l’annuaire ont une incidence sur l’exploitation d’un annuaire mais ne remettent pas en cause significativement son fonctionnement.

Dans nebule, un annuaire permet de référencer des entités ainsi que leur localisation numérique.

Une entité va être créée pour répondre à ce besoin. Cette entité aura le nom de Asabiyya (cf wikipedia).

Relais et liens

Comment mettre à jour le contenu d’un relais?

Par principe, le relais (ou proxy) se contente de copier des objets. Mais aussi, de fait en tant qu’entité, en les copiant, il propose ces objets en diffusion (au téléchargement).

Quel est l’intérêt?
Cela permet à une entité source, par exemple un humain, de générer des objets et de les faire diffuser par des entités relais qu’il contrôle. Ainsi, il peut ne pas être en permanence accessible (volontairement ou pas). Ses objets restent accessibles si les relais le sont. Plusieurs relais peuvent diffuser les mêmes objets, on ajoute de la redondance et on cumule la bande passante de téléchargement pour quelqu’un qui télécharge un de ces objets, à la manière du P2P (peer to peer).

Continuer la lecture de Relais et liens