Auteur/autrice : webmaster

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

Lien de bannissement ?

Aujourd’hui, bannir un objet, et non son usage, revient à lier cet objet à un autre objet convenu contenant ‘nebule/danger‘. Mais la recherche de bannissement d’un objet peut être un peu longue alors qu’elle doit être systématique avant toute utilisation d’un objet.

Il serait peut-être judicieux de créer un type de lien spécifique au bannissement d’un objet. Comme ce lien n’a besoin que du champs source, le champs destination peut être soit le type de bannissement soit la sévérité. Ce type de lien doit bien sur rester sensible au lien de suppression de lien, au cas où ce bannissement soit abusif ou inopportun et qu’il faille l’annuler.

A voir…

Messagerie et transfert fondamental d’information

Comme cité dans l’article sylabe – Emulation de messagerie, l’implémentation de certaines fonctionnalités de la messagerie pose problème.

Tout lien f est potentiellement un message. Cette façon de voir est plus fondamentale, plus propre et plus proche de la gestion de l’information. Malheureusement, elle pose quelques problèmes pour certaines fonctionnalités classiques de la messagerie telle que nous l’utilisons tous aujourd’hui. Les problèmes de fonctionnalités ne sont pas graves mais peuvent être perturbants.

Pour commencer, comment marquer un message comme lu puisque cela revient à faire un lien d’un lien, ce que ne permet pas nebule.
Nous sommes ici dans un fonctionnement attendu de la messagerie dans laquelle chaque message est important et doit donc être lu. Ce comportement est différent du message de réseau social qui n’a pas forcément d’importance et n’est pas destiné à être lu impérativement. On distingue le message destiné à la masse des gens, même si elle peut être très limitée, du message destiné spécifiquement à un individu. La notion d’importance dans l’attente de lecture du message dépend surtout du nombre de destinataires.
Il ne faut pas non plus penser que le spammer s’attend à ce que tout le monde lise ses messages. C’est du rêve mais ce genre de message est très peu lu et est donc envoyé en masse pour compenser ce manque d’importance ou d’intérêt.

Ensuite, lorsque l’on marque comme supprimé un message, c’est que l’on supprime explicitement le lien f qui fait que c’est un message. Si on souhaite annuler cette suppression, la théorie dans nebule veut que l’on recrée un lien mais avec une date plus récente. Or si la date est plus récente, cela altère l’information de la date du message. Ensuite, c’est l’entité qui à reçu le message qui génère le nouveau lien à une date plus récente, et non l’entité d’origine. On perd donc la provenance du message. Ce n’est pas acceptable dans ces conditions de permettre la restauration d’un message.

Il est probable que l’on revienne plus tard à une implémentation plus universelle et fondamentale dans la façon de reconnaître ce qu’est un transfert d’information, un message.

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…

Cosignature – orientation

Dans la continuité de la réflexion sur la cosignature et suite.

Une des possibilités que doit permettre la cosignature, c’est que l’on puisse créer une signature (ou assimilé) valide alors que les différentes personnes (et leurs entités) ne sont pas réunies en même temps au même endroit pour réaliser cette signature commune.

Le système classique pour résoudre la cosignature consiste en la répartition du secret suivant le schéma de seuil de Shamir.

Cette solution de partage du secret n’est pas suffisante pour deux raisons.

Pour commencer, cela veut dire que l’on n’a toujours qu’un seul secret mais qu’il est répartit, dilué, entre plusieurs entités. Lorsque l’on veut faire une signature, il faut réunir un minimum de ces entités au même endroit pour accéder au secret qui permettra la signature. A ce moment, le secret est extrêmement vulnérable.
Il faut réaliser une sorte de cérémonie des clés pour cela.

Enfin, la génération du secret est réalisé par un seul équipement et ensuite répartit. Il faut ici aussi une cérémonie des clés avec tous les porteurs d’une partie du secret. Si il n’est pas possible de réunir tout le monde, une partie du secret doit être transmis de façon sûr vers le porteur concerné. Mais il ne peut pas dans ce cas garantir par lui-même que personne n’a copié sa partie du secret. Et surtout il ne peut garantir que personne n’a volé le secret complet lors de la cérémonie des clés.

Donc, il faut que chaque porteur génère sa partie de clé, on génère un bi-clé qu’il garde, et dont il peut garantir la confidentialité. Ensuite, il reste à réaliser le mécanisme intermédiaire qui permet, en ne connaissant que les clés publiques des porteurs, de valider une pseudo signature réalisée par chacun des porteurs. Une pseudo signature qui n’impose une présence ni spatial ni temporelle des porteurs.

Liens :
– https://fr.wikipedia.org/wiki/Partage_de_cl%C3%A9_secr%C3%A8te_de_Shamir
– http://www.kilomaths.com/2010/07/partage-de-secret/

Sync flood

La possibilité de transmettre un objet à une entité de façon protégé ou non se fait via la possibilité pour une entité (destinataire) de se synchroniser sur les les autres serveurs. Elle récupère ce qu’on lui transmet. Et elle peut en même temps synchroniser tous les objets dont elle aura besoin.

Ici, la synchronisation signifie la récupération des informations (et du contenu) de sa propre entité mais aussi des autres objets sur des serveurs distants.

Une attaque possible est le débordement de la synchronisation (Sync Flood) par une grande quantité de liens qui font références à un des objets synchronisés.

Ce débordement peut être fait directement par une entité que l’on connaît ou indirectement par l’intermédiaire d’un relais, même si l’entité source des liens n’est pas reconnu par l’entité destinataire.

Il faudra donc prévoir dans les fonctions de synchronisation des mécanismes de limitation du nombre de liens synchronisés. Ces limitations peuvent être différentes en fonction du type de lien. Et en fonction du type de lien, on peut ne garder que les premiers ou que les derniers liens téléchargés. Par exemple, il vaut mieux ne garder que les premiers liens de type l alors que l’on privilégiera les derniers liens de type f, u ou x. Il faut aussi mettre un quota sur le nombre total de liens que l’on accepte de télécharger pour éviter un engorgement de la mémoire.

Un débordement réussi peut entraîner un fort ralentissement dans l’affichage et le traitement des objets concernés.

Libervia

Dans les projets qui ont un peu les mêmes but que nebule, voici le projet Salut à Toi. Un financement participatif est en cours pour Libervia, une interface web de SàT. Libervia est à SàT ce que sylabe est à nebule.

L’ensemble fonctionne par dessus le protocole XMPP et son système d’extensions XEP. Le programme réutilise un protocole solide et ouvert. Mais il est dépendant de serveurs sur internet. Un client peut facilement changer de serveur en cas de problème mais son adresse reste attachée au serveur d’origine et elle est donc perdu lors du changement. Ce protocole d’échange permet à tout le monde de créer son propre serveur et d’échanger avec tout le monde.

Le chiffrement et l’anonymisation sont des propriétés liées au protocole utilisée, ouvert et connu. Rien à dire.

On peut aussi mettre en place un serveur non relié à internet, mais il n’y a aucun mécanisme de partage de données entre ce serveur isolé et le reste des serveurs, hors copié/collé à la main par fichiers. C’est sur ce point que nebule présente un avantage, il permet de transférer des données via des passerelles (air gap) tout en conservant les informations annexes aux données comme les actions ou les destinataires par exemple.

Cosignature – suite

Suite de l’article sur la Cosignature.

La notion de groupe est intéressante puisque pour l’instant, si le groupe a été définit dans sa ou ses formes, il n’a pas été définit dans son implémentation.

Cette implémentation peut rejoindre la notion de cosignature. En étendant la notion d’entité à autre chose que des bi-clés cryptographiques, notamment à un fichier de description du groupe et de la validité de sa signature (équivalente), on crée implicitement un groupe. Ce groupe hérite de par ses propriétés internes d’une capacité de signature et de vérification. Comme ce n’est pas un bi-clé cryptographique, il n’y a pas d’objet de clé privée. L’objet définissant le groupe n’est pas suffisant en lui-même pour signer des liens, il doit se reposer sur les ‘vraies’ entités qui composent le groupe.

Par exemple, la forme du fichier définissant un groupe de 3 entités peut être un objet contenant :

[Members]
88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea
01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4
19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57
[Signe]
(88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea . 01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4)
+
(19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57 . 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea)
+
(01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4 . 19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57)
[Timestamp]
2015-05-28T22:20:13+0200

La signification du groupe, c’est que les membres sont 3 et que la signature d’un lien par deux des trois entités est valide comme étant celle du groupe ( (1 et 2) ou (2 et 3) ou (3 et 1) ).

Ce n’est qu’un exemple…

Cosignature

Une réflexion depuis quelques temps porte sur la cosignature (cf Les entités et le code / Redéfinition de puppetmaster). Et elle est toujours d’actualité. Le but est de permettre d’avoir une entité unique mais dont la clé privée soit répartie en plusieurs morceaux, chaque morceau sous la responsabilité d’une personne différente. On doit avoir plusieurs entités qui peuvent communément, et non individuellement, signer pour l’entité unique.

Le problème peux être résolu en ayant un mécanisme qui valide la signature de l’entité unique par la présence d’un nombre pré-définit de signatures d’entités pré-validées. On n’a plus dans ce cas une entité mais un groupe d’entités dont la cosignature est reconnue comme signature du groupe. Dans ce cas, la notion d’entité s’étend et ne sous-entend plus seulement un objet avec une clé cryptographique mais un objet qui constitue un groupe d’entités avec des règles de fonctionnement.

Jusqu’ici, je n’ai trouvé que des solutions matériels avec un seul bi-clé cryptographique conservé dans une puce et dont l’usage est contraint par l’authentification de plusieurs personnes physiques. Ce n’est pas satisfaisant puisque toutes les personnes doivent être présentes au même endroit au même moment pour activer la clé privée. Les solutions de cosignatures que j’ai trouvé se contentent de gérer de multiples signatures d’un document mais sans gérer cette notion de communauté.

Description de la création d’une nouvelle entité.

La ré-implémentation de la génération d’une nouvelle entité est en cours dans sylabe.

Une nouvelle partie apparaît dans la documentation de référence sur la création d’une entité : Wiki – Documentation nebule v1.2 – Création d’une entité

On y trouve la procédure de référence à implémenter et notamment tout ce qui concerne la manipulation des clés cryptographiques asymétriques et mots de passes.

Gestion locale et globale des paramètres

Pour l’instant, les paramètres de configuration de nebule et de sylabe se font via un fichier de configuration sur le serveur.

Il sera possible plus tard de permettre la configuration de certains paramètres de façon globale, c’est à dire via un objet dédié.
Tous les paramètres ne pourront pas être globaux, à définir.

Comme d’habitude, le contenu pourra être public et/ou privé.

On peut déjà prévoir qu’un paramètre public sera mal défini et surchargé par le même paramètre mais privé. C’est une forme de défense par déception.

Gestion du lien de suppression de liens

Le lien de type x permet de supprimer des liens marqués à des dates antérieures.

En dehors de la gestion du temps et de la forme de la marque, comment doit se comporter le code lorsqu’un lien x à la même date qu’un autre lien ?

Dans l’ancienne librairie nebule en php procédurale, le code considérait l’autre lien comme supprimé. C’est à dire que le lien x est plus fort que les autres lors du traitement.

On peut réfléchir à des problèmes qui pourraient survenir, à la marge, sur la gestion des liens.
Cela présente cependant un avantage de conserver ce fonctionnement. Si dans l’interface on souhaite supprimer un lien, soit on utilise la date en cours, soit on précise la date du lien à supprimer. Dans ce dernier cas, si le lien à été régénéré par un autre moyen juste quelques secondes après, voir moins, le nouveau lien ne sera pas supprimé. Ce qui est plus logique.

Authentification et mot de passe

Dans la version précédente, procédurale, de la librairie nebule en php, l’authentification était gérée via des variables de la session. On retrouvait l’ID de l’entité en cours ainsi que l’ID de la clé privée associée et le mot de passe (si déverrouillé) de cette clé privée.

Les anciennes variables :
– $_SESSION['nebule_publ_entite']
– $_SESSION['nebule_priv_entite']
– $_SESSION['nebule_pass_entite']

Dans la nouvelle version de la librairie, en programmation orientée objet, la première variable qui référence l’entité en cours d’utilisation est toujours nécessaire.
Par contre, la variable qui référence la clé privée est encore utilisé mais n’est déjà plus vraiment indispensable puisque l’instance (l’objet au sens programmation) de l’entité contient la référence à l’ID de sa clé privée. Cet ID de clé privée est pré-calculée lors de l’initialisation de l’instance et est accessible par une fonction publique. Il est même possible que cette variable de session pour la clé privée disparaisse à terme faute d’usage.
Enfin, la variable contenant le mot de passe de la clé privée, elle, disparaît définitivement. Elle n’était renseignées que lorsque l’entité était déverrouillées. Désormès, le mot de passe, lorsque fourni, est stocké dans l’instance de l’entité en cours. Cette instance référence ainsi la clé privée et le mot de passe associé. Ce mot de passe est bien sûr vérifié lors de son enregistrement puisque c’est la seule et unique condition pour considérer l’entité comme déverrouillée, que le mot de passe soit valide sur la clé privée.

En terme de sécurité du code, c’est plus propre. Le mot de passe ne peut être consulté directement par un module malveillant comme avec une variable de session par essence globale et donc accessible partout. Cependant, le mécanisme n’est pas parfait puisqu’une lecture brute de l’instance permet d’en extraire le contenu… et donc le mot de passe. Il faudra trouver un mécanisme pour renforcer ça…
L’usage d’un sel pour le mot de passe est en cours de réflexion sachant qu’il faudra dans ce cas créer un lien pour le rendre publique. C’est un renforcement de la sécurité du mot de passe mais potentiellement une source de panne.

En terme de gestion des entités, c’est plus facile si on change vers une entité que l’on maîtrise puisque les mots de passe des entités esclaves sont accessibles et peuvent être pré-injectés dans les entités correspondantes. Et puis en cas de bascule vers une de ces entités esclaves, le retour à l’entité maîtresse est plus facile aussi puisque le mot de passe pourra rester dans celle-ci.

En terme d’évolution, il est déjà prévisible qu’une forme avancée d’un usage multi-entité verra le jour. CF Entités multiples. La pré-initialisation des mots de passes de toutes les entités sous contrôle (entités esclaves) rendra cet usage beaucoup plus facile. Pour rappel, cet usage multi-entité permettra au choix soit d’utiliser une et une seule entité à un instant donné mais de pouvoir immédiatement et facilement changer d’entité, soit d’utiliser simultanément tout ou partie des entités sous contrôle. Dans ce dernier cas, les actions seront par contre faites avec une seule entité pré-definie pour cela.

Voici la structure de la classe Entity :

class Entity extends Object
{
	const ENTITY_MAX_SIZE = 16000;
	const ENTITY_PASSWORD_SALT_SIZE = 128;
	const ENTITY_TYPE = 'application/x-pem-file';

	private $_publicKey = '';
	private $_privateKeyID;
	private $_privateKey = '';
	private $_privateKeyPassword;
	private $_privateKeyPasswordSalt;
	private $_issetPrivateKeyPassword = false;
	private $_faceCache = array();

	public function __construct(nebule $nebuleInstance, $id);
	public function __destruct();
	public function __toString();
	private function _loadEntity($id);
	private function _createNewEntity();
	private function _verifyEntity($entity);
	public function getType();
	public function getKeyType();
	public function getPublicKeyID();
	public function getPublicKey();
	private function _findPublicKey();
	public function getPrivateKeyID();
	private function _findPrivateKeyID();
	private function _findPrivateKey();
	public function setPrivateKeyPassword($passwd);
	public function unsetPrivateKeyPassword();
	public function checkPrivateKeyPassword();
	public function changePrivateKeyPassword($newpasswd);
	public function getFullName();
	public function getLocalisations();
	public function getLocalisation();
	public function getFaceID($size=400);
}

Gestion du temps et anonymisation

L’horodatage des liens est important pour leur interprétation. C’est particulièrement vrai pour démêler les suppressions. L’horodatage est placé dans les liens, ce qui veut dire que ce n’est pas l’objet qui est daté mais son usage.

On traite ici la suite des articles Horodatage, suite, Gestion temporelle partielle, Transfert de liens et de confiance, et cela entrera dans l’Etude du temps.

Vis-à-vis de l’anonymisation des entités, et surtout des personnes derrières, la gestion du temps nécessaire à l’horodatage peut poser problèmes.

Le problème c’est la synchronisation sur une source unique. Utiliser deux ou trois source réduit le problème mais uniquement de façon linéaire. Cette source unique sera régulièrement consultée et donc verra la source des demandes, notamment d’un point de vu adresses sur le réseau. Mais qui dit demande de synchronisation de temps ne veut pas dire présentation de l’entité qui le demande. La corrélation peut être faite après coup en comparant les marques de synchronisation de temps d’une entité avec les logs de connexion. Le risque ici est de récupérer la localisation d’une entité. Pour beaucoup de personnes, la connexion à son système d’information se résume à son ordinateur à la maison, son téléphone/tablette et à son travail. Avec la connexion depuis le domicile, on peut casser assez facilement l’anonymisation.

L’utilisation de plusieurs moyens informatiques pas forcément synchronisés entre eux en terme de temps introduit des problèmes pour calculer un décalage de temps et une dérive éventuelle. Dans ce cas, la relation entre entité et localisation ou entre entité et individu est plus dure à obtenir, mais pas impossible.

On peut utiliser la même entité source de synchronisation de temps mais en passant par des relais. Il faut dans se cas récupérer les dernières marques de l’entité de gestion du temps et le rejouer. En passant par une entité intermédiaire, on casse la corrélation possible entre les connexions et les marques de temps. C’est au prix d’une moins grand précision dans le calcul du décalage de temps.

Si on utilise un système de synchronisation des machines, tel que NTP, les machines se synchronisent sur des références de temps cohérentes. Noyé dans la masse des connexions, les synchronisations d’une entité ne permettent pas de lever son anonymat. Malheureusement, cela ne fonctionne que si les machines sont en réseau. Tout au plus peut-on se contenter d’une synchronisation irrégulière et espacée dans le temps. Dans ce cas, l’absence de marques de temps d’une entité ne permettra pas de calculer son décalage, et donc on en sera réduit à supposer qu’elle est à peu près à l’heure.

Dans tous les cas, il est possible d’utiliser en même temps une synchronisation précise par NTP et un calcul de décalage de temps. Des machines synchronisées devraient avoir un décalage proche de 0. Pour ne pas affaiblir l’anonymat des utilisateurs, il est préférable d’avoir une synchronisation NTP et d’utiliser les marques de temps mais horodatées sur son heure propre. Les marques de temps seront récupérées aléatoires chez les entités connues.

La gestion du temps va générer un trafic propre tant en réseau qu’en terme d’objets et de liens. Il faudra prévoir un nettoyage fréquent et à court terme de ces objets et liens avant qu’ils ne saturent les échanges entre entités.

Enfin, cela n’a peut-être pas trop d’importance à première vue mais c’est quand même une entorse à l’anonymisation, générer des marques de temps régulières pour permettre les synchronisations ne peut se faire que lorsque l’entité est déverrouillée. C’est à dire que l’on a des marques de temps que quand on est connecté, ce qui trahi les heures de présence effective mais aussi fait office de marqueur de présence. La parade est de ne faire des marques synchronisation de temps que… de temps en temps. Cette parade se fait au prix d’une perte de précision dans le calcul du différentiel de temps, surtout avec des machines multiples.

La sécurité des suppressions de données

Le piratage de Sony Pictures a provoqué une véritable onde de choc dont les ramifications sont parfois inattendues. L’article The Security of Data Deletion de Bruce Schneier fait l’apologie d’une stratégie ‘agressive’ de suppression des données obsolètes dans les entreprises. Puisqu’il n’est pas possible de garantir la confidentialité des données d’une entreprise, même une parmi les plus grosses, il est préférable de supprimer ces données lorsqu’elles sont obsolètes.

On peut aussi parler de l’intégrité puisque si un pirate a réussi à récupérer quelques téraoctets de données sans se faire prendre, il a tout aussi bien pu en altérer au passage. Si la cryptographie peut nous aider à ce niveau pour signer les données et messages, elle ne pourra pas grand chose si les postes utilisateurs, leurs programmes et donc leurs clés sont compromises…

Mais revenons à la politique de suppression des données. Parler de politique agressive est un peu exagéré. La notion d’agressivité sous-entend de supprimer dès que possible une donnée lorsqu’elle n’est plus utilisé. Il est fait référence dans l’article à ce que l’on transmettait par téléphone avant l’informatique, les informations annexes que l’on ne notaient pas finissaient par être rapidement oubliées, au pire déformées… ou au mieux sujettes à confirmation.

Si la messagerie instantanée est assez informelle, la messagerie classique est beaucoup plus formelle, surtout en entreprise. On est dans ce dernier cas assez loin de la conversation libre par téléphone.

Une entreprise ne peut pas non plus supprimer sans discernement ses données sous prétexte qu’à un instant donné elles n’ont plus d’utilité. Ces données, c’est la mémoire de l’entreprise. Les supprimer c’est supprimer la mémoire de l’entreprise, une des choses les plus importantes puisque c’est l’accumulation de son savoir faire, de son savoir sur ses clients et ses racines. Supprimer les données anciennes d’une entreprise, c’est comme supprimer la mémoire à long terme des individus, c’est catastrophique pour eux et pour la société dans son ensemble.

Ce parallèle avec l’individu n’est pas anodin. La capacité d’une entreprise c’est la somme des individus qui la composent démultiplié par le patrimoine technique.
Et le parallèle peut aller plus loin. L’individu ne retiendra pas tout d’une conversation téléphonique. Des informations annexes seront perdus parce que non mémorisées par l’un ou l’autre des interlocuteurs. Ensuite, avec le temps, chaque interlocuteur va oublier certaines informations pas très importantes, progressivement. Au final, après un grand laps de temps, il ne subsistera de la conversation téléphonique que l’essentiel de l’information. Il faut donc bien de la même façon supprimer les données éphémères d’une entreprise mais il ne faut pas tout supprimer. Avec le temps, seul doit subsister l’essentiel des informations du passé. Les idées doivent être résumées et les informations techniques doivent être épurées de leurs pré-calcul et des données annexes.
Comme fil conducteur, on peut essayer d’avoir la vision d’un historien sur le passé de l’entreprise pour savoir ce qui a de l’intérêt ou pas. Et ainsi, naturellement, toutes les conversations hors champs vont disparaitre.

Tel que déjà définit précédemment pour le projet nebule, les données doivent pouvoir être supprimer automatiquement après un certain délai ou conservées explicitement. Une pondération appliqué aux objets déterminera le délai de conservation, ou plutôt de non-suppression. Et un seuil déterminera à partir de quelle pondération un objet sera à garder définitivement. Ce seuil peut évoluer avec le temps et faire disparaitre après coup des objets qui initialement étaient au dessus du seuil de suppression. La pondération reflète l’importance des objets, positivement ou négativement.

Pour finir, n’est-il pas plus simple d’être respectueux dans ses messages même à usage interne ? A défaut d’empêcher le vol d’information, au moins on évite déjà les propos embarrassants, une charge de moins dans la réparation des dégâts. Mais quelque part, cela reflète un état d’esprit dans l’entreprise, une certaine culture des individus qui la composent… bref, pas très sain…

Entités multiples

Dans la suite des réflexions sur Entités multiples, gestion, relations et anonymat, le développement de la librairie nebule en php continue en tenant compte de cette possibilité.

En gérant le mot de passe d’une entité dans l’objet (php) de cette entité, on peut avoir plusieurs entités déverrouillées à un instant donné. Et comme plusieurs entités sont potentiellement déverrouillées, lorsque l’on consulte un objet chiffré, il ne faut plus seulement regarder si l’entité courante est déverrouillée et donc peut le lire, mais il faut regarder dans tous les destinataires si une des entité n’est pas déverrouillée aussi. Une seule suffit pour déchiffrer l’objet et afficher son contenu.

Il faut cependant faire attention à ce que l’entité courante ait bien l’accès à l’objet chiffré avant de permettre son utilisation parce que cela dévoilerait immédiatement le lien de parenté entre les deux entités. Il est imaginable de basculer immédiatement d’entité courante sur une action de ce genre.

Si on souhaite une bascule complète sur une entité esclave sans interférence d’autres entités, il suffit de vider le mot de passe de tous les objets (php) des entités que l’on ne souhaite plus voir. Cela inclut aussi l’ancienne entité courante qui peut avoir été préalablement sauvegardée avec sont mot de passe pour une restauration ultérieure.

Une des applications de cette capacité multi-entité, c’est le cumule d’entité lors d’un Changement d’identifiant d’entité. Il est possible, le temps de migrer les liens, de pouvoir continuer à consulter les objets de l’ancienne entité tout en utilisant la nouvelle entité.

Arborescence virtuelle

Dans nos systèmes d’information actuels, le rangement des fichiers dans une arborescence est non seulement classique mais fondamentale et souvent incontournable. L’autre forme de rangement est d’utiliser une base de données.

Il est possible avec nebule de simuler une arborescence mais virtuelle et uniquement constituée d’objets et de liens.
CF Wiki РR̩flexion Рanalyse des applications РSyst̬me de fichiers

Un arborescence commence par une racine, par exemple ‘/‘. Dans cette racine on va trouver des fichiers, des sous-dossiers et des fichiers dans les sous-dossiers.
Chaque fichier a nativement un nom ou au pire un identifiant unique. Les fichiers vont avoir en plus un ou des liens pour les positionner dans l’arborescence à un ou plusieurs endroits.
Chaque dossier est constitué de l’objet contenant son nom. Cet objet de nommage est lié au dossier parent par un lien, lui-même relié à son dossier parent… jusqu’à la racine.

Le nom des objets ne pose pas de problème, il risque juste de changer d’une entité à l’autre. Le nom d’un dossier peut par contre avoir deux formes, mais on ne doit en gérer qu’une seule.
Soit le nom d’un dossier ne contient que sont nom et pas l’ensemble de l’arborescence. Dans ce cason peut avoir n’importe quel nom, y compris des noms avec le caractère séparateur de dossiers ‘/’. Mais si on souhaite mettre deux dossiers avec le même nom dans deux branches différentes de l’arborescence, il y a conflit sur le nom et donc mélange des fichiers enfants.
Soit le nom d’un dossier contient l’ensemble de l’arborescence. On résoud les problèmes de conflit. Et on n’accepte pas des noms de dossiers avec le caractère séparateur de dossiers. C’est la meilleur solution.

Comme il est possible que plusieurs entités créent plusieurs arborescences différentes ou en reconnaîssent plusieurs, il faut un objet unique de référence de cette arborescence. L’objet contenant ‘/’ doit dans ce cas être lié à l’objet de référence, et il en est de même pour tous les objets de l’aborescence.
Ainsi, comme pour l’émulation de commentaires dans le blog, les objets on des liens entre eux avec comme contexte un objet de référence. Les mêmes liens peuvent tout à fait être reproduire intégralement ou partiellement avec un autre objet de référence et ne pas entrer en conflit.

On obtient, du fait même de la base nebulisée, des comportements spécifiques sur l’arborescence.
Par exemple dans une arborescence de fichiers d’une société, le chef pose un nouveau fichier dans un sous-dossier. Tout le monde dans la société va voir ce nouveau fichier. Un des employé ‘copie’ le fichier ailleurs dans l’arborescence, tout le monde voit le nouveau fichier. Si il le modifie, il crée un objet de mise à jour et les deux fichiers sont mis à jours. Cela est intéressant puisque tous les emplacements sont tenus à jours mais cela peut déjà poser problème puisque l’on ne voulait peut-être pas tout mettre à jour. Il faut donc bien distinguer la mise à jour et le dérivé.
Prenons un autre cas. Un des employé modifie le nom du fichier créé par le chef. tout le monde voit la modification. Le chef décide d’annuler le nouveau nom, de redonner le nom d’origine au fichier. Tout le monde va voir le fichier revenir à son nom d’origine… sauf peut-être celui qui avait renommé le fichier puisque la gestion sociale des liens va peut-être décider que personne ne peut annuler son opération, même si le chef est son supérieur hiérarchique dans la société.

Cette arborescence virtuelle sera ajoutée pour expérimentation à sylabe. Comme ce n’est pas quelque chose de vraiment natif dans la philosophie de nebule, l’implémentation se fera sous forme d’un module.

On peut ensuite, sur cette base, aller plus loin avec par exemple inotify. Pour un dossier spécifié et ses sous dossiers, tout changement sur un dossier ou un fichier serait immédiatement nébulisé et synchronisé vers un serveur local ou distant.

Avancement

La librairie nebule en bash évolue. Ça faisait longtemps…

Comme un nouveau fichier nebule.env est utilisé par la librairie nebule en php, en place de l’ancien env_nebule.php, il était naturel que ce fichier serve aussi à la librairie en bash. Ce fichier évolue pour intégrer des options spécifiques au bash. Certaines options sont spécifiques au php et d’autres, comme la crypto, sont communes.

Le gros changement ‘est surtout que les options ne sont plus des variables. Il est possible d’extraire directement une option de configuration au moment de l’utiliser, mais il est aussi possible d’en faire une variable, comme avant. C’est cette dernière solution qui est utilisée pour l’instant, par facilité.

Cette nouvelle version de la librairie nebule en bash sera prochainement diffusée par bachue…