Catégorie : confiance

Monnaies, transactions et individus

Il existe deux méthodes pour gérer les échanges de valeurs entre deux entités, ou individus.
La première consiste à suivre des objets définis comme de la monnaie et de faire des transactions de réattribution de ces objets entre entités. Le solde pour une entité est l’addition de la valeur tous les objets de monnaie en possession de l’entité.
La seconde consiste à suivre pour chaque entité un indicateur de balance de la valeur dont dispose chaque entité. Le solde est à lecture immédiate et toute transaction consiste en la soustraction d’une valeur sur un compte couplé à l’addition de la même valeur sur un autre compte.

La seconde méthode ne fonctionne pas ou très mal dans le cadre d’une cryptomonnaie sans intermédiaire de confiance, c’est à dire sans une banque pour centraliser le compteur des valeurs des comptes. La transmission de valeur devient complètement impossible sans échange avec l’intermédiaire de confiance.
Mais la première méthode n’est pas forcément mieux loti. Elle permet dans le monde réel un échange de billets sans passer par un intermédiaire de confiance. Mais dans le monde informationnel (dit aussi virtuel ou numérique), la propriété d’unicité spatial et temporel n’existe plus. Et donc il faut sceller à la vue de tous une transaction avec un intermédiaire de confiance. Celui-ci peut être une chaîne de blocs, ça ne fait que décaler l’intermédiaire de confiance vers le code et ses concepteurs.

Continuons sur la réflexion d’une cryptomonnaie.
On voit aujourd’hui plusieurs acteurs étatique ou organisationnels générer de la monnaie virtuelle et/ou revendiquer sa régulation. L’extrême limite de cette pratique serait que tout le monde puisse générer sa propre monnaie… et donc qu’il y ai des taux de change entre les monnaies de tous les individus.

Chaque individu et chaque robot peut justifier d’une certaine quantité de travail par unité de temps, par exemple on peut supposer que l’humain dispose de 16 heures d’activité par jours. Dans ces 16 heures, on va réduire à 8 heures la part allouable à autrui. Mais cette capacité de travail n’a pas de valeur directe, ce n’est pas parce que l’on a une capacité de travail de 8 heures par jour que l’on va travailler 8 heures par jour. Cependant, chaque individu peut générer chaque jours une valeur, comme une monnaie, qui représente la capacité de travail journalier. Appelons la monnaie temporelle.
Il reste encore à donner de la valeur à cette monnaie temporelle.
D’un autre côté nous retrouvons des entreprises, regroupement d’individus, qui utilisent le temps de travail disponible des individus sur un patrimoine constitué d’outils de travail ou de données afin de transformer des objets, et donc d’ajouter de la valeur. Nous pourrions associer la monnaie temporelle des différents employés avec une sorte de monnaie patrimoniale afin de dégager une monnaie véhiculant de la valeur, laquelle monnaie serait rétrocédée en partie aux employés.
Comment seraient représentées ces différentes monnaies dans un système d’information ?

La réflexion n’est pas terminée…

Lien de transaction

La réflexion continue autour d’une implémentation d’une monnaie virtuelle sur la base de nebule, donc une crypto-monnaie.

Dans ce cadre, une transaction peut/doit devenir notamment devenir immuable et définitive. Si il serait possible de mettre en place un tel mécanisme et algorithme avec des liens supprimables, il serait cependant plus judicieux et clair de disposer d’un lien explicitement non supprimable. Cela renforce la confiance dans le mécanisme. Ce serait un lien de transaction, type t ?

Cependant cela demande à modifier des parties critiques des algorithmes de traitement des liens… et les alourdis un peu…

Et comment gère-t-on l’oubli volontaire de ces liens ?

Relais d’authentification

Il est théoriquement possible depuis une instance d’une entité déverrouillée sur un serveur, local, de demander à ouvrir une nouvelle instance sur un autre serveur, distant. Cette authentification peut simplement être faite en rejouant le mot de passe de l’entité du serveur local. Il faut que le serveur distant connaisse l’entité et dispose de l’objet de la clé privée accessible avec le mot de passe. La nouvelle instance serait alors ouverte dans un nouvel onglet du navigateur.

Cela implique la transmission du mot de passe. Il faut impérativement passer par une connexion chiffrée (TLS) avec authentification (certificat) du serveur distant afin de protéger le transit du mot de passe.

Cela implique aussi que le serveur distant va connaître le mot de passe de l’entité, au moins le temps de la session. Il faut donc avoir autant confiance dans le serveur distant qu’en le serveur local.

Il est cependant possible aussi de transmettre le mot de passe d’une sous-entité vers le serveur distant. Ainsi on peut penser centraliser sur un serveur/périphérique local une entité maîtresse et ses sous-entité, et utiliser certaines sous-entités exclusivement sur des serveurs distants, y compris des serveurs de faible confiance.

Cela veut dire que l’on doit pouvoir associer une localisation avec une entité.

En fait, cela est très simple à réaliser. Il suffit de générer un lien HTTP vers le serveur distant avec en argument l’application, l’entité et le mot de passe… le tout dans un nouvel onglet.

Et en ajoutant dans le lien HTTP un mode et une vue il est même possible de chaîner l’authentification vers un troisième serveur. On a dans ce cas un niveau de relai d’authentification et un peu de dissimulation.

Ceci n’est pas implémenté. Suite au prochain épisode…

Blockchain, billets et valeur

Dans la réflexion sur l’implémentation d’un équivalent de blockchain dans nebule, il apparaît un problème qui n’est pas vraiment technique.

La blockchain permet de transmettre des billets électroniques sous la forme de transactions dans des blocs. Avec nebule, on peut utiliser les liens comme transactions et des objets prenants le rôle de billet électroniques, ou utiliser des objets de transactions pour des objets portants de la valeur. Dans les deux cas on peut le faire avec un mécanisme assurant de la confiance dans les transactions.

Chaque billet est porteur d’une valeur. Cette valeur n’est pas fixe, c’est juste une convention, et elle va dépendre de plusieurs paramètres. Le volume de billets pouvant évoluer avec le temps, à la hausse, la valeur de chaque billet va naturellement baisser juste du fait de l’augmentation des billets pour une valeur globale constante. Cette valeur monétaire peut évoluer aussi dans le temps avec les transactions d’achat ou de revente des billets eux-même, indépendamment de la valeur d’origine qu’ils représentaient.

Or si cette valeur monétaire peut évoluer dans le temps, elle doit malgré tout être initialisée à un moment. On passe par exemple d’un objet physique ayant une valeur d’usage à une monnaie qui transporte cette valeur initiale. Il y a une sorte d’échange de valeur entre un objet physique et un objet virtuel. Mais comment vas-t-on faire pour générer des billets décentralisés de façon à permettre l’échange de valeur ? Les billets doivent-ils pré-exister ?

Blockchain et nouveau lien

Suite des articles sur la Blockchain et nebule, Le cas de la messagerie et la Réputation d’entité et chaînage.

Le problème de n’avoir que des liens annulables dans nebule, rapporté à une émulation du fonctionnement d’un équivalent de la blockchain, c’est que l’entité initiatrice d’une transaction peut invalider la transaction ou au contraire elle peut se voir contraindre la transaction par un groupe coalisé.

Une solution serait de créer un nouveau type de lien spécifiquement non annulable, c’est à dire non soumis à l’action du lien de type x. Mais ce cas particulier va ralentir le traitement de la lecture et de la vérification des liens là où elle doit être la plus optimale. Mais bon la force de l’usage fait peut-être loi.

Une autre solution pourrait être de se baser sur un objet de transaction. Dans ce cas nous n’avons plus un objet servant de jeton de valeur avec la résolution des liens pour suivre ses évolutions mais un objet de transaction faisant en interne référence à un autre objet jeton de valeur. Dans ce cas, la suppression d’un objet répliqué étant beaucoup plus illusoire, si d’autres entités signent cet objet comme une transaction il est possible de la retrouver même si l’initiateur de la transaction le supprime. Cette méthode pose cependant un problème, quel lien doit être utilisé afin de propager l’objet de la transaction, et donc la transaction elle même, tout en permettant la création de confiance ?

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

Pondération et structure hiérarchique

Suite de la gestion de la pondération.

Dans une structure ou une organisation hiérarchique, forme courante d’organisation, une autorité peut être amenée à déléguer son pouvoir à un autre individu. C’est le cas notamment lors d’une vacance.

Rapporté à une entité dans nebule, une entité a qui on donne une forte pondération, à qui on fait confiance, sera toujours prioritaire sur une autre de moins forte pondération. Comment permettre une vacance ? Est-ce que l’on peut mettre en place une forme de délégation de pondération ? Est-ce que ce lien de délégation est simplement annulé en fin de vacation ?

Cela pose aussi question sur la forme de la pondération. Elle est normalement globale. Mais ne faut-il pas gérer une pondération par rôle en plus ? Doit-il être géré comme une pondération avec un contexte social ?

Bugg d’affichage des autorités globales dans option

Il y a un petit problème dans l’affichage des autorités globales dans l’application option. Par exemple ici :

https://sylabe.com/?a=21215100000000…0000000212151&view=gauth
shot-2017-06-02_19-51-13

Mais une partie de l’affichage est bon est correspond bien à l’entité bachue qui gère le code. Un petit tour par le bootstrap permet de s’en assurer :

https://sylabe.com/?b
shot-2017-06-02_19-57-13

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

Entités de recouvrement

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

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

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

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

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

Sondages et votes

Dans un article La Suisse pourrait imposer l’open-source pour le vote électronique de Numerama, il est de nouveau question de la mise à disposition du code source du programme sous forme de logiciel libre.

L’avenir du vote électronique ne fait aucun doute, seule sa réalisation pose problème aujourd’hui. Beaucoup de débats comparatifs et contradictoires ont lieux vis-à-vis de la pertinence du vote électronique et de la confiance que l’on peut apporter aux machines de vote et au processus dans son ensemble. Ces débats peuvent paraître très conservateurs mais ils sont néanmoins nécessaires puisque le vote est un acte fondamental de nos démocraties, c’est le moyen d’expression de chacun d’entre nous.

La confiance en ce genre de machine de vote et du code qui l’anime ne peut être assurée sans l’ouverture du code à minima en lecture. Il faut aussi connaître précisément l’environnement de compilation et d’exécution pour le code soit parfaitement reproductible. Et bien sûr, il faut être sûr ce c’est bien ce code qui a été utilisé et pas un autre.
Invoquer le secret industriel sur du code pour un processus parfaitement connu et un enjeu majeur de démocratie, c’est particulièrement malhonnête. Tout au plus une société éditrice peut-elle demander un droit de paternité et une restriction de commercialisation à son seul bénéfice. Mais il suffit à l’état qui fait la commande du code de demander, et payer, explicitement la libre diffusion ou la libéralisation complète du code.

Le code doit être capable dans son ensemble de permettre la centralisation des votes, l’anonymisation des électeurs ainsi que la vérification en temps réel et à postériori du décompte des votes. L’authentification de l’utilisateur devrait être le principal problème mais il apparaît que c’est en fait le décompte et sa vérification qui interpellent le plus souvent les détracteurs du vote électronique.

Un vote a un point de départ dans le temps et une fin à partir de laquelle le décompte des votes est considéré comme définitif.

L’anonymisation est aussi un problème pour la vérification de conformité du vote à postériori puisqu’elle casse le lien sûr entre le votant et le vote unitaire. On peut ainsi affirmer que le votant à voté (il a posé un papier et signé le paraphore) mais on ne peut pas le prouver à postériori (était-ce vraiment lui).
La capacité de multi-entité et la dissimulation de liens dans nebule permettent de résoudre ce problème.

Voici un scénario possible de vote avec les objets et liens de nebule :

  1. Pour un vote, une entité maîtresse du vote est générée. Elle est explicitement reconnue par les autorités comme telle. Son seul rôle est de générer les jetons de vote et de les attribuer aux électeurs.
  2. L’entité maîtresse du vote va générer autant d’objets jetons qu’il y a de votants. Ces jetons sont aléatoires et n’ont pas de relation directes avec les électeurs. Chaque jeton est en fait la partie publique d’un bi-clé cryptographique (RSA par exemple). La clé privée de chaque jetons est protégé par un mot de passe stocké dans un objet protégé par et pour l’entité maîtresse (dans un premier temps).
  3. Le jeton est en fait l’entité qui réalisera le vote via la clé privée. Chaque vote peut être vérifié par rapport au jeton, c’est à dire la clé publique.
  4. Pour chaque objets de clés privées de chaque jetons, l’entité maîtresse va partager le secret de chiffrement de l’objet contenant le mot de passe. Le lien entre objet chiffré et objet non chiffré est dissimulé, c’est à dire que c’est un lien de type c masquant le vrai lien.
  5. La clé privée de l’entité maîtresse est détruite. Il n’est ainsi plus possible de retrouver l’intégralité des relations en les jetons et les électeurs mais il est possible de vérifier que tous les électeurs ont reçus un lien dissimulé et de vérifier tous les jetons réalisant le vote.
  6. Pour un vote, une entité de décompte du vote est générée. Elle est explicitement reconnue par l’entité maîtresse Son seul rôle est de recueillir et de valider les votes. La période de vote démarre.
  7. L’électeur, c’est à dire l’entités votantes, va récupérer auprès de l’entité maîtresse du vote l’intégralité des jetons et des clés privées associées (et pas juste son jeton). Il va ainsi obtenir tous les liens dont le lien dissimulé le concernant. Via le lien dissimulé, il va savoir quel est la clé privée du jeton que l’entité maîtresse lui a attribué. Disposant de cette information il peut déprotéger à son profit l’objet contenant le mot de passe de la clé privée du jeton.
  8. L’électeur, mettant à profit la clé privée du jeton, peut réaliser un ou plusieurs votes, seul le dernier est pris en compte. Le vote consiste en un lien entre le jeton et le choix de vote dans le contexte de l’entité de décompte du vote (champs méta).
  9. L’entité de décompte du vote vérifie régulièrement auprès de tous les électeurs la présence de liens dont elle est le contexte. au fur et à mesure de la récupération des liens, elle se les approprie (signature du lien de vote).
  10. A la fin de la période de vote, la clé privé de l’entité de décompte du vote est détruite. Plus aucun vote ne peut être ajouté, modifié ou supprimé. Les votes comptabilisés sont ceux qui ont été signés par l’entité de décompte du vote.
  11. L’électeur qui souhaite rendre publique son vote a juste à prouver qu’il dispose du jeton en utilisant sa clé privée pour autre chose que le vote en relation avec sa véritable entité. Il peut aussi révéler le lien dissimulé que lui avait généré l’entité maîtresse du vote.

Un des aspects des liens dissimulés est qu’il est possible de les dissimuler pour plusieurs entités. Ainsi il est possible de générer une entité d’audit du vote à qui l’entité maîtresse partagera les liens dissimulés, de façon également dissimulé.L’entité d’audit devient capable à postériori de vérifier la bonne association entre jetons de vote et électeurs sans être elle-même capable d’émettre de nouveaux jetons.

Le sondage est moins contraignant et surtout peut être à choix multiples.

Dissimulation de liens, multi-entités et anonymat

La dissimulation de lien tel que prévu dans nebule n’est que la première partie permettant l’anonymisation des échanges entre entités.

Voir les articles précédents :
РLiaison secr̬te et suite ;
– Nouvelle version v1.2, Anonymisation de lien et correction du registre ;
РLien de type c, pr̩cisions ;
РEntit̩s multiples, gestion, relations et anonymat et Entit̩ multiples ;
– Nébuleuse sociétale et confiance – Chiffrement par défaut

Cette dissimulation d’un lien se fait avec un lien de type c. On a bien sûr dans le registre du lien visible l’entité qui génère ce lien, l’entité signataire. Et on a l’entité destinataire qui peut déchiffrer ce lien dissimulé et en extraire le vrai lien. Et comme dans la version publique de ce lien on a à la fois l’entité source et l’entité destinataire qui sont visibles, il n’y a pas d’anonymat. Ce type de lien permet juste de dissimuler l’usage d’un objet.

2015.06.27 lien c

Un lien dissimulé ne peut pas contenir un autre lien dissimulé. On interdit donc les multi-niveaux de liens dissimulés qui seraient un véritable calvaire à traiter.

Un lien peut être dissimulé pour soi-même. C’est à dire que l’entité signataire est aussi l’entité destinataire.

Si un lien doit être dissimulé pour plusieurs destinataires, il faut générer un lien pour chaque destinataire. La seule façon de réduire le nombre de liens pour un grand nombre de destinataires est d’utiliser la notion de groupe disposant de son propre bi-clé. Ce type de groupe est pour l’instant purement théorique.

Ce maintien comme public des entités sources et destinataires est une nécessité au niveau du lien, c’est une des bases de la confiance dans les liens. Pour que le lien puisse être validé et accepté par une entité ou retransmit par un relais, l’identification des entités est incontournable. Et donc avec l’identification nous avons aussi l’imputabilité et la non répudiation.

Si on veut assurer de l’anonymat pour les entités, puisque l’on ne peut pas travailler au niveau du lien, il faut travailler au niveau de l’entitié. On va dans ce cas travailler sur la notion de déception, c’est à dire faire apparaître des entités pour ce qu’elles ne sont pas ou tromper sur la nature des entités.
L’idée retenu consiste, pour chaque entité qui souhaite anonymiser ses échanges avec une autre entité, à générer une entité esclave avec laquelle elle n’a aucun lien. Ou plutôt, le lien d’entité maîtresse à entité esclave est un lien dissimulé pour l’entité maîtresse uniquement. Ici, personne à par l’entité maîtresse ne peut affirmer juste sur les liens que l’entité esclave lui est reliée.
Lorsque l’on veut échanger de façon anonyme, on transmet à l’entité destinataire l’identifiant de l’entité esclave, et vice versa. Cette transmission doit bien sûr être faîte par un autre moyen de communication ou au pire par un seul lien dissimulé.

L’anonymisation complète est donc la combinaison des liens de dissimulation de liens et d’une capacité multi-entités des programmes.

La dissimulation est en cours d’implémentation dans sylabe en programmation php orienté objet. Mais le plus gros du travail sera à faire dans la librairie nebule puisque c’est elle qui manipulera les liens et présentera ceux-ci à l’application, c’est à dire sylabe, dans une forme exploitable. L’application n’a pas à se soucier de savoir si le lien est dissimulé, elle peut le lire ou elle ne peut pas. Tout au plus peut-elle afficher qu’un lien est dissimulé pour information de l’utilisateur.
La capacité multi-entités de sylabe est maintenant beaucoup plus facile à gérer en programmation php orienté objet. Mais il reste à implémenter la génération des entités esclaves avec dissimulation de leur entité maîtresse.

Une autre dimension n’est pas prise en compte ici, c’est le trafic entre les serveurs pour les échanges d’informations. Il faudra faire attention à la remontée possible aux entités maîtresses par leurs échanges.

Enfin, pour terminer, aujourd’hui c’est la course au chiffrement par défaut de tous les échanges pour tout un tas de programmes et services sur Internet. Ce chiffrement par défaut est bon pour l’utilisateur en général. Et il masque dans la masse les échanges pour qui la confidentialité est critique. Ainsi il ne suffit plus d’écouter le trafic chiffré pour retrouver ses ennemis.
Mais cette logique est perverse. Le chiffrement par défaut est une aberration, un remède de cheval posé en urgence faut de mieux. Nous avons besoin d’échanger aussi des choses publiquement, comme sur un forum ou dans la presse. Nous ne devrions pas avoir des outils de communication tout chiffré et d’autres tout public, chaque outil devrait permettre les deux et clairement indiqué ce qui est protégé de ce qui ne l’est pas…

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…

Affichage de la couleur d’un objet

Une des orientations actuelles dans les interfaces graphiques centrées sur nebule, c’est de représenter les objets par leurs identifiants et pour chacun par des carrés de couleur spécifiques. Chaque objet a sa couleur propre calculée par rapport aux 6 premiers digits de son identifiant.

2014.11.11 21h03 ecran

Mais du point de vue de l’interface visuelle, si la représentation de l’identifiant équivoque d’un objet est indispensable, sa place encombrante n’est ni ergonomique ni pratique ni vraiment sécurisante à elle seule. Garder systématiquement la place pour un nombre hexadécimal de 128 caractères au minimum, fut-il l’objet en cours de consultation, c’est encombrant. L’ergonomie en prend un coups puisque l’on doit grader un grand espace variable pour une information certes importante mais peu pertinante pour l’utilisateur la plupart du temps. Enfin, puisqu’il est illusoire de penser pouvoir mémoriser l’intégralité des identifiants que l’on utilise pour les vérifier, à part quelques cas spécifiques l’affichage des identifiants des objets n’amène pas directement de sécurité pour l’utilisateur. Le problème de mémorisation est le même que pour les mots de passes multiples, passé un certain nombre, très restreint, cela affaiblie la sécurité de l’ensemble.

Il est tentant de remplacer purement et simplement l’affichage de l’identifiant d’un objet juste par son carré de couleur propre. Cela entraînerait l’impossibilité de vérifier immédiatement si l’objet que l’on visualise est le bon. On peut savoir avec la couleur si l’objet est celui que l’on attend. Mais la représentation des couleurs ne dépasse pas 24 bits d’information. C’est à dire qu’en ajouter plus que les 24 bits n’est pas perceptible par l’oeil humain. Ainsi, la couleur est un moyen de tri rapide mais pas un moyen de sécurité.

Le problème de ne pas pouvoir vérifier immédiatement et de façon sûr un objet est déjà un problème en soit mais peut être comblé par l’usage des liens. Par contre, la gestion des entités et notamment la reconnaissances de nouvelles entités uniquement sur leurs couleurs propres est un vrai problème de sécurité. Il est facile de générer une nouvelle entité ayant la même couleur propre. Avec 24 bits à respecter, cela ne présente pas une grande difficulté. L’identification d’une nouvelle entité doit dans tout les cas être parfaitement sécurisée, donc elle doit être basée sur l’intégralité des identifiants.

Il faut donc soit conserver l’affichage de l’identifiant des objets, même partiel(tant qu’il est suffisamment grand). Soit il faut trouver une méthode alternative de représentation simple des objets tout en conservant un espace de valeur correct.

Au moins deux méthodes peuvent être envisagées, liste non exhaustive.

On peut utiliser un petit pictograme de plusieurs couleurs successives calculées à partir de l’identifiant d’un objet. Le prictograme peut disposer d’un espace de valeurs suffisamment grand tout en étant facilement mémorisable.

On peut imaginer qu’une entité spécifique utiliser certaines valeurs choisies au hasard parmi tous les digits des identifiants pour calculer les couleurs propres des objets. Comme il faut 6 digits hexadécimaux pour constituer une couleur, ceux-ci sont choisis non pas au début des identifiants mais à l’intérieur. ce choix doit être aléatoire, secret pour l’entité et non recalculable par une entité tierce. Dans ce cas, la couleur affichée pour un même objet serait différente pour chaque entité qui consulte cet objet.

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

N̩buleuse soci̩tale et confiance РChiffrement par d̩faut

La relation entre les êtres humains est resté assez stable dans son contenu mais à beaucoup évolué dans sa forme avec la technique. Le la taille d’un village, d’une tribu, la dimension du réseau social d’un individu a fortement grandi et a cessé de coller à sa zone géographique proche. Mais il n’a pas forcément grossi pour autant, il ne s’est que dilaté. Il garde d’ailleurs une forme nébuleuse dense au centre et distendu en périphérie.
Le téléphone a accéléré la vitesse de transmission des informations et de fait a permis d’étendre encore plus la portée des échanges, et donc l’influence des individus. Cette extension a fini par atteindre sa taille limite, celle du monde.
Mais les échanges d’informations ne se limitent pas à l’influence, politique, des autres. On y retrouve des choses qui n’ont pas grand intérêt à première vue comme la correspondance familiale ou la propagation de la culture. Cependant, ces deux exemple ont une importance profonde dans l’identité de l’individu d’une part et de la société d’autre part.
Le réseau social individuel n’est plus depuis longtemps calqué sur son influence physique directe. Si il n’est pas évident de parler de réseau social d’un groupe d’individus, ou société, on peut quand même se raccrocher à son influence directe. Et l’influence des sociétés ne sont que rarement exactement calquées sur leurs influences physique directe, c’est à dire sur les frontières d’un pays.
Une société ne doit pas être vue comme une forme nébuleuse unique de relations sociales mais comme une forme nébuleuse sociétale composée d’une multitudes de formes nébuleuses entremêlées. Une société est composée d’une multitude de formes nébuleuses individuelles avec quelques structures communes, mais surtout, pour les individus, avec une majorité de liens au sein de la nébuleuse sociétale. Le nationalisme ou communautarisme, du point de vue du réseau social, sont des tentatives pour imposer des structures uniques fortes et donc de forcer la nébuleuse sociétale à se scinder en de multiples formes sous-sociétales. Il existe une multitude de formes sous-sociétales susceptibles de développer une forme de communautarisme puisqu’il est en pratique impossible d’avoir une nébuleuse individuelle approchant la forme nébuleuse sociétale dans son ensemble. Le nationalisme use de sa forme de nébuleuse sociétale pour revendiquer une influence physique y compris hors des frontières de l’état qui le définit à l’origine.
Le réseau Internet est un support d’information, il permet de diffuser la connaissance à tout un chacun. Mais ce n’est pas sont seul rôle, il permet aussi de relier les individus. C’est à dire qu’il sert de support universel à la forme nébuleuse des relations sociales d’un individu. Nous avons encore des échanges sociaux directs entre individus, instantanés, mais ils ne sont plus ni exclusifs ni même nécessaires ou systématiques.
Le projet nebule se doit donc de faciliter le partage de l’information, de la connaissance, mais il se doit aussi de faciliter les échanges sociaux entre individus. Le projet nebule doit être capable de coller au plus prêt de la nébuleuse de l’information d’un individu, mais aussi de la nébuleuse de son réseau social.

La messagerie telle qu’elle a commencée était un message manuscrit sur un support papier ou équivalent et pouvait mettre plusieurs mois pour arriver à destination… quand ça arrivait…
Aujourd’hui, un message traverse le monde en quelques secondes avec une très grande probabilité d’arriver à destination. Le plus long, c’est maintenant d’attendre que le destinataire ouvre son message. Tout le monde fait confiance à la messagerie électronique et à une bonne confiance dans les échanges postaux nationaux et internationaux.

Et puis il y eu Edward SNOWDEN.

La confiance, c’est la capacité du système à fonctionner tel que l’on s’attend à ce qu’il fonctionne et à être résistant aux tentatives de détourner son fonctionnement.
Là, subitement, on a une grosse crise de confiance. On se dit qu’on ne va peut-être pas laisser tous ses Å“ufs dans le même panier. Le projet nebule peut sous cet éclairage paraître un peu trop intrusif et exclusif (des autres).

Cette crainte vis-à-vis du projet nebule est à la fois recevable, et non recevable.
Le projet sylabe, annexe de nebule, est une implémentation suivant les paradigmes actuels en terme d’échange de l’information, et surtout en terme de concentration de l’information. Il est conçu volontairement dès le début pour centraliser les données sur un serveur de l’Internet. C’est cette concentration sur une machine que l’on ne maîtrise pas qui pose de gros problèmes aujourd’hui. C’est cette concentration sur des machines chez des grosses sociétés au USA qui permet à la NSA (entre autres) de violer l’intimité numérique des individus sans raison valable. Et c’est fait de telle façon que les individus gardent confiance dans cette concentration de leurs données.

Mr SNOWDEN a cassé la confiance que nous avions dans la concentration de nos données, la confiance pour ces grosses sociétés américaines, et la confiance dans l’Internet même. Il a montré que quelque chose ne fonctionnait pas bien. Mais il l’a fait pour que ça s’améliore, pour que nous fassions les efforts nécessaires pour reconstruire l’Internet et la confiance que l’on attend de lui.

Le projet sylabe est donc un reliquat de ce passé. Mais il apporte quand même quelque chose pour le futur. Il centralise les données mais contient les graines de leur décentralisation complète.
Si tout le monde n’est pas prêt aujourd’hui à installer un serveur pour héberger ses données, on y arrive quand même de façon détournée. Certains installent des boîtiers NAS, c’est déjà une forme de réappropriation de ses données. Toutes les maisons ont une box qui fait office de centre multimédia, de NAS. La domotique arrive tout doucement (depuis 20 ans). Ainsi, une instance sylabe pourra être un jour implémentée facilement dans un boîtier pour non seulement héberger nos donnés mais aussi pour nous permettre d’échanger avec nos amis.
Le projet sylabe, une fois implanté ailleurs que sur des serveurs centralisés permettra la mise en place complète de la vision de la nébuleuse de nos informations, complètement décentralisée mais centrée sur nous.

Il reste à traiter le problème de l’anonymat. C’est en cours de définition et d’implémentation.
Cet objectif à part entière, dans le contexte actuel, nécessite qu’une entité puisse nativement et par défaut chiffrer tous ses objets et offusquer tous ses liens, ou presque tous. Cette possibilité sera intégrée rapidement dans le projet sylabe.

Prise d’empreinte homomorphique

Les objets manipulés par nebule sont identifiés, et donc référencés, par leurs empreintes respectives. Ces empreintes sont cryptographiques afin de pouvoir s’assurer que c’est bien le bon objet, afin de pouvoir avoir confiance dans l’intégrité de son contenu. Il est possible dans un seul cas d’avoir plus d’une empreinte par objet, c’est si celles-ci sont calculées avec des algorithmes différents (cf Collisions d’empreintes multi-algorithmique).

Cependant, si la propriété cryptographique des empreintes est indispensable à la confiance, elle entraîne un manque de souplesse dans le référencement des objets. Rien dans la valeur de l’empreinte ne trahis une partie de son contenu. L’empreinte cryptographique reflète uniquement l’intégralité de l’objet. On ne peux pas s’en servir pour retrouver des objets proches dans leur contenu. Tout au plus peut-on vérifier si deux objets sont identiques… ce qui n’a pas d’intérêt puisque dans ce cas c’est tout simplement le même objet.

Sub-division d’objet

La première solution pour résoudre ce problème est d’utiliser des sous-parties d’un objet comme des objets propres, et de les identifier comme tels. Le lien de type s permet justement de lié l’objet principal à ses morceaux.

C’est notamment ce qui est fait dans les logiciels de Paire-à-Paire (P2P – Peer to Peer). Pour qu’un fichier puisse être téléchargé depuis de multiples sources, celui-ci est pré-découpé en morceaux de taille identique pré-définit. Chaque morceau à une empreinte propre et peut être vérifié à la réception. Chaque morceau est téléchargé sur une et une seule source, mais plusieurs morceaux sont téléchargés simultanément depuis plusieurs sources. On augmente ainsi le débit réel de réception du fichier voulu même si les sources ont individuellement un faible débit d’émission. Évidemment, si chaque morceau est valide, le fichier dans son ensemble ne peut qu’être valide.

Une recherche sur mot clé peut avantageusement tirer partie de ce système puisqu’une recherche se fera uniquement sur l’empreinte du morceau correspondant à la recherche. Toute la difficulté est de bien choisir ces morceaux.

Pour du texte, c’est facile. Pour une recherche sur des images ou des vidéos, c’est déjà beaucoup moins évident. Mais quoique l’on trouve, c’est toujours une liste d’objets qui contiennent cette petite sous-partie même si le reste n’a absolument aucun rapport.

Empreinte homomorphique

Une autre solution consiste à essayer de trouver des objets qui ont le plus de contenu en commun. Ce serait une sorte de représentation miniature du contenu de l’objet. On veut quelque chose qui se rapproche plus de l’empreinte des doigts de pieds. On regarde d’abord que cela à bien la forme d’un pied, puis on regarde plus en détail certaines parties morphologiques pour déterminer si les deux pieds sont proches.

On pourrait partir sur le système de sous-découpage utilisé par le P2P. Chaque objet est découpé en petits morceaux de taille identique. Ainsi, si deux objets ont un ou des morceaux en commun, on pourra en déduire que ceux-ci sont proches.
Mais cette méthode pose un problème. Si on prend un objet et que l’on en fait une copie avec pour seule différence un caractère supplémentaire dans le premier bloc de données, alors tous les blocs seront vus comme différents alors que les objets ont clairement des parties communes.
On pourrait imaginer essayer d’optimiser la méthode en travaillant sur des blocs de tailles variables. Mais quels critères adopter pour ajuster les tailles de blocs en fonction des données ?

Je propose une méthode comme base de réflexion à défaut pour l’instant d’être adoptée.
Si on regarde le travail d’un logiciel de compression de données, on constate qu’il recherche les occurrences multiples de données dans l’ensemble d’un document. Il le fait sans tenir compte de la sémantique de ce qu’il trouve. Ainsi des mots très proches sémantiquement ne seront pas agrégés parce que différents. Ensuite, le logiciel de compression fait un classement statistique pour déterminer les occurrences multiples qu’il serait avantageux de réduire. Une phrase qui apparaît quelques fois permet une bonne optimisation. Un mot qui apparaît plusieurs permet aussi un gain de place facile.
Si on reprend le même principe d’analyse, même sans tenir compte de la sémantique des mots, on peut s’attendre à ce que les plus grandes occurrences de mots ou de phrases représentent le ou les sujets du document. C’est ce que fontnotamment les moteurs de recherches (Google, Bing, Yahoo…) lorsqu’ils moulinent les pages web, mais avec l’analyse sémantique en plus.
L’empreinte homomorphique est constituée des 20 premières occurrences redondantes avec leur poids respectifs. L’occurrence peut être représentée par une petite empreinte (CRC) de façon à avoir une taille fixe, mettons 16 caractères hexadécimaux. Le poids peut être représenté en pourcentage sur 4 caractères hexadécimaux (entre 0000 et ffff).
Vue comme ça, l’empreinte générée n’est plus tout à fait homomorphique et n’a pas de propriétés cryptographique.On obtient une empreinte homomorphique de 400 caractères hexadécimaux.

Ainsi, plusieurs documents parlants d’un même sujet ont de fortes chances d’avoir une même empreinte parque bien que différents ils auront les mêmes occurrences redondantes.

Un certain nombre de données annexes vont figurer dans les données utilisées pour la comparaison. Par exemple on peut retrouver les en-têtes internes des documents bureautique. Il faut peut-être pré-filtrer les documents en fonction de leur type pur. Par exemple, un simple fichier texte et un fichier complexe de traitement de texte se verront expurgés de tout ce qui est en-tête et données internes, puis on en gardera que les caractères imprimables convertis en minuscule, sans ponctuation…

Conclusion

Une empreinte homomorphique peut être utilisée avantageusement en complément de l’empreinte cryptographique. Elle n’a d’intérêt que pour des objets ayant suffisamment de contenu. Il faut prévoir un seuil minimum en dessous duquel elle n’est pas calculée. Cette empreinte homomorphique est liée à l’objet par un lien de type l avec comme objet méta « nebule/objet/homomorphe ». Cet objet à usage réservé est ajouté à la documentation.

Mais dans tous les cas, en l’absence de propriétés cryptographique, une empreinte homomorphique ne doit pas être utilisée dans les liens. L’usage n’est pas le même, on fait soit de l’intégrité, soit du référencement.

Modes de traitement

Le projet nebule en lui-même donne un cadre stricte dans la forme des objets et des liens. Mais il ne donne que des orientations sur le traitement, c’est à dire l’interprétation, de ces objets et surtout de leurs liens.

Il existe aujourd’hui trois stratégies dans le traitement des objets et des liens.

Le mode ouvert

C’est la façon la plus simple d’utiliser les objets et les liens puis qu’aucune vérification n’est réalisée.

Cela implique pour commencer que les empreintes des objets ne sont pas vérifiées. Ces empreintes sont donc de pures URI avec un faible attachement au contenu des objets qu’elles référencent. Cette considération entre en conflit avec l’un des fondements du projet nebule puisque l’empreinte est strictement attaché à un objet, son contenu en fait, et que toute modification de cet objet entraîne implicitement la création d’un nouvel objet avec une empreinte propre.

Les liens ne sont pas vérifiés, ce qui veut dire que leur provenance, n’étant pas assurée, ne peut pas être non plus utilisée. Ainsi, les liens sont vus sont leur forme la plus réduite, c’est à dire la forme équivalente RDF avec la date et l’action.

Le traitement s’en trouve extrêmement accéléré. Il est pas contre impossible d’établir un échange digne de ce nom ne serait-ce qu’entre deux entités. Les notions de propriétés public et privée n’ont pas de fondement dans ce cas. On ne peut envisager ce fonctionnement que sur un périmètre restreint d’un centre de calcul et dédié à une tâche unique. On peut tout au plus envisager une passerelle vers le monde extérieur qui vérifierait scrupuleusement les entrées et signerait les sorties.

Ce mode de traitement n’est pas recommandé dans le cadre du projet nebule.

Le mode social

La prise en compte du côté social implique que l’on tienne compte de l’émetteur des liens, et donc de la validité de ceux-ci. A l’opposé du mode ouvert, cette façon de procéder est la plus complexe et la plus lente. Mais c’est aussi la plus intéressante.

Chaque objet et chaque lien utilisé est scrupuleusement vérifié. Comme nous sommes dans un environnement social, c’est à dire avec de multiples entités, nous devons procéder à un tri des liens en fonction de leur provenance. Les objets sont vérifiés mais leur usage dépend exclusivement de leurs liens, et donc notamment des émetteurs de ces liens.

Lorsque deux actions sont contradictoires, il faut tenir compte de l’environnement sociale et plus seulement du facteur temporel. Il y a des différences dans la confiance que l’on accorde aux autres entités, et donc dans les liens quelles génèrent. Le tri des liens est réalisé suivant une pondération qui reflète la relation avec les entités émettrices. C’est une pondération en tout point sociale et est attachée aux entités.

L’offuscation de liens permet de cacher ou de tromper une entité sur la vraie pondération qu’on lui accorde. Mais il fait garder à l’esprit que plus elle est discordante plus elle a de chance d’être découverte ou au minimum de provoquer de la confusion.

Une pondération peut aussi être envisageable sur les objets. Cela permet en augmentant la pondération de réduire proportionnellement l’influence des autres entités sur un objet précis.

Enfin, une pondération peut être réalisée sur le type de lien et éventuellement en fonction d’un des objets référencés par un lien.

Ici, pour le projet nebule, clairement tout est quasiment à faire. La pondération des entités n’est pas encore formalisée. La pondération des objets et théorique. Et la pondération sur le type de lien n’est qu’une prévision par rapport aux modèles actuels.

Le traitement des objets et des liens, déjà ralentis par les vérifications de base, est encore plus complexe du faire des calculs de pondérations, et donc plus lent encore.

Ce mode de traitement est celui adopté par la librairie nebule de référence en php. Par extension, c’est aussi le mode de traitement utilisé dans le projet sylabe.

Le mode strict

La prise en compte du côté social est partielle, elle a même une forme exclusive. On se situe à mi chemin entre le mode ouvert et le mode social en terme de complexité.

Chaque objet et chaque lien utilisé est scrupuleusement vérifié. Contrairement au mode social, la prise en compte des entités n’est pas globale mais au contraire exclusive. On ne reconnaît que les liens de certaines entités précises. Afin de simplifier encore plus le traitement, il n’y a pas de priorisation ou de pondération dans l’exploitation des liens. Si plus d’une entité est reconnu, toutes ont le même poids et donc le même pouvoir de décision dans l’utilisation des objets. On attend ici des décisions rapides, fiables et reproductibles dans un environnement large mais avec un groupe très restreint d’objets et de liens à prendre en compte. Tout le reste est ignoré.

C’est un fonctionnement de type paranoïaque. Les notions de propriétés publique et privé sont assurées mais les échanges avec d’autres entités sont très limités et potentiellement conflictuels parce que non pondérés, non régulés. Ce fonctionnement est tout indiqué pour gérer la sécurisation de certains outils informatiques comme le déploiement de code.

Le cas le plus représentatif est par exemple la reconnaissance des entités puppetmaster, bachue et cerberus dans la validation de la librairie nebule de référence en php mais aussi du code du projet sylabe.

Ce mode de traitement est utilisé par le bootstrap en php et la librairie nebule de référence en bash. Le bootstrap ne reconnaît que les objets de bachue ou de l’autorité locale moyennant un bannissement de cerberus et sous la supervision de puppetmaster.

Gestion de la pondération

Cela fait longtemps que la pondération est en réflexion et en attente d’implémentation. Par exemple Mémoire fini, Objets privés et fonctionnement interne, RSE et Nettoyage des liens.

La cryptographie s’occupe de la sûreté de fonctionnement.

La pondération permet de gérer l’importance des objets et donc notamment des entités.
La pondération appliquée à des entités permet de gérer la confiance. Cette gestion de la confiance est en fait synonyme de la gestion de la sécurité.

Cependant, la pondération elle-même doit être exclu de la relation de confiance, c’est à dire que l’on ne doit pas tenir compte de la pondération définit par les autres entités même si on leur fait confiance. Sinon il y a danger !
Si elle est acceptée malgré tout, la confiance sur la pondération des autres entités doit être strictement délimitée et le danger pour l’utilisateur doit être clairement affiché. En fait, elle ne devrait jamais être utilisée…

Comment rester sécurisé face à la NSA

En visitant le blog de Bruce Schneier, je suis tombé sur un long et intéressant article : How to Remain Secure Against the NSA
Je vais me concentrer sur les 5 points, traduits ici :

  1. Caché dans le réseau. Implémentez des services cachés. Utilisez TOR pour protéger votre anonymat. Oui, la NSA cible les utilisateurs de TOR, mais cela est efficace sur eux. Moins vous serez à découvert, plus vous serez en sécurité.
  2. Chiffrez vous communications. Utilisez TLS. Utilisez IPsec. Encore une fois, bien qu’il soit vrai que la NSA cible les communications chiffrées (et ils connaissent peut-être des failles spécifiques contre ces protocoles), vous serez bien mieux protégés que si vous communiquez en clair.
  3. Prenez pour acquis que, bien que votre ordinateur puisse être compromis, cela nécessite du travail et représente un risque pour la NSA (donc il ne l’est probablement pas). Si vous avez quelque chose de vraiment important, utilisez un transfert par un moyen déconnecté. Depuis que j’ai commencé à travailler avec les documents de Mr Snowden, j’ai acheté un nouvel ordinateur qui n’a jamais été connecté à internet. Si je veux transférer un fichier, je chiffre le fichier sur l’ordinateur sécurisé puis l’emmène à pied jusqu’à mon ordinateur sur internet, sur une clé USB. Pour déchiffre quelque chose, j’inverse le processus. Cela ne doit pas être infaillible, mais suffisamment bon.
  4. Soyez méfiants envers les logiciels de chiffrement commerciaux, spécialement des grands éditeurs. Mon avis, c’est que la plupart des produits de chiffrement des grandes entreprises US ont des portes dérobées pour la NSA, et il est probable que les entreprises étrangères fassent de même. Il est prudent de considérer que les équipements étrangers aient aussi des portes dérobées pour une puissance étrangère. Il est plus facile pour la NSA de placer une porte dérobée dans un logiciel à sources fermées que dans un autre aux sources ouvertes. Les systèmes reposants sur un important secret sont vulnérables à la NSA, que ce soit pour leurs activités légales ou plus clandestines.
  5. Essayez d’utiliser des algorithmes de chiffrements dans le domaine public qui nécessitent d’être compatibles avec d’autres implémentations. Par exemple, il est plus difficile pour la NSA de placer une porte dérobée dans TLS que dans BitLocker. Parce que tous les implémentations de TLS doivent être compatibles entre elles alors que BitLocker ne doit être compatible qu’avec lui-même, donnant à la NSA plus de libertés pour apporter des changements. Et parce que BitLocker est propriétaire, il est beaucoup moins probable que ces changements soient découverts. Préférez la cryptographie symétrique plutôt que la cryptographie à clé publique. Préférez les systèmes conventionnels à logarithmes discrets plutôt que les systèmes à courbes elliptiques. Ces derniers ont des constantes que la NSA influence dès qu’elle le peut.

Petite remarque sur ce qui semble une incohérence. Il cite au point 4 d’essayer d’utiliser des logiciels à sources ouvertes. Et il dit utiliser plus bas un ordinateur sous M$ Windows : « And I’m still primarily on Windows, unfortunately. Linux would be safer. »
L’aveu est franc. Je pense que l’explication est simple, il se sent plus à même de sécuriser un système qu’il connaît bien plutôt qu’un système inconnu. Ça se défend.

Confrontons donc maintenant le projet nebule et ces cinq points :

  1. Le projet nebule, une fois diffusé, peut être hébergé partout sur le réseau. Par défaut, les entités ont des emplacements connus. Mais rien n’empêche une entité d’avoir un emplacement dont l’objet contenant est chiffré, et l’URL d’une forme difficile à deviner même si on connaît le serveur. Par contre, si les objets et liens d’une entité sont échangés avec une autre entité, elle se retrouve à découvert sur d’autres emplacements. Ceci ne devrait cependant arrivé que si des liens relient ces objets aux deux entités. Le chiffrement des objets la seule parade définitive, ce qui est logique. L’anonymisation tel que proposé par TOR n’a pas de sens dans nebule.
  2. Dans nebule, on a le choix. Rien n’empêche de chiffrer toutes les informations vitales et de placer les liens suspects dans des objets chiffrés. Ce dernier point n’est pas encore implémenté mais est prévu et est techniquement réalisable. Utiliser TLS est recommandé au risque de révéler les liens et objets échangés, et donc d’affaiblir l’anonymisation.
  3. Le risque de l’ordinateur compromis est assez actuel malheureusement. Tant qu’un système ne sera pas intégralement nébulisé, le projet nebule n’apportera pas grand chose à ce niveau. On peut cependant profiter de la signature native des objets contre la modification malveillante. Par contre, nebule permet assez facilement de faire des échanges à sens unique, via des relais d’isolation, et via des supports amovibles. Et le chiffrement peut être entièrement réalisé sur un ordinateur isolé, même à destination d’une autre entité.
  4. Pour résumer, il faut utiliser des logiciels open sources et qui ne sont pas restreints à un seul éditeur dans leur utilisation. Le projet nebule par dès le début avec un choix d’utilisation par défaut de logiciels libres (et open sources). Ceux retenus sont très utilisés, et donc très régulièrement vérifiés. L’inter-opérabilité avec d’autres systèmes et implémentations est aussi à ce prix.
  5. Le début a les mêmes réponses que pour le point 4. Il est impossible de gérer des entités avec la cryptographie symétrique. La cryptographie asymétrique est irremplaçable. Mais il ne faut pas utiliser ces algorithmes pour faire des choses pour lesquels ils ne sont pas prévus. Par contre, si l’algorithme à logarithmes discrets est principalement utilisé aujourd’hui, tout algorithme peut être utilisé en parallèle ou en remplacement. Cela n’a pas d’importance structurelle forte. Le projet nebule s’appuie sur la cryptographie asymétrique pour les signatures et chiffrements (pour les clés de sessions).

Liens :
– https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html