NÅ“ud – nouvel identifiant

La notion de nœuds dans nebule a évoluée avec le temps.

Le nÅ“ud servait avant pour désigner un point d’entrée afin de chercher certaines informations. C’était un objet, donc un contenu, et donc un identifiant (OID), défini à l’avance et que l’on pouvait retrouver facilement. Il était marqué en tant que tel. Puis il est devenu progressivement un objet virtuel, c’est à dire avec comme identifiant une empreinte aléatoire et donc sans contenu connu.

Maintenant, le nÅ“ud devient un objet virtuel clairement identifié en tant que tel, c’est à dire que si son identifiant (NID) est toujours aléatoire, le suffixe d’algorithme de prise d’empreinte démontre tout de suite que ce n’est pas une empreinte.

Un objet a pour identifiant OID (Object ID) :

88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea.sha2.256

Ici, le contenu est bien connu, c’est une entité connu. On voit que l’empreinte est faite avec l’algorithme sha256, c’est à dire de la famille sha2 avec une taille de 256bits.

L’identifiant NID (Node ID) d’un nÅ“ud va ressembler mais avec une taille et un suffixe différent :

a4b210d4fb820a5b715509e501e36873eb9e27dca1dd591a98a5fc264fd2238adf4b489d.none.288

Le suffixe est de la famille none et la taille est plus… variable. Ici la taille est de 288bits, soit 72octets. Cette forme est maintenant normalisée.

Attention cependant, il y a une taille minimum de la valeur des NID que le code va accepter. La course aux NID les plus petits n’est pas forcément une bonne idée.

Le nÅ“ud n’ayant pas de contenu, sont nom doit être au besoin explicitement définit par un lien de nommage vers un objet contenant le nom attendu.

Autour des NID, on va retrouver un graphe de OID ou autres NID. Ce graphe va dépendre de ce que l’on attend du NID mais celui-ci reste bien un point d’entrée privilégié dans le graphe global des données.

Enfin, il faut comprendre que c’est ici une façon de marquer explicitement un nÅ“ud dans son identifiant mais que tout objet est en soi un nÅ“ud et peut être utilisé comme tel. Un OID peut être considéré comme un NID avec un contenu.

Structure de donnés des liens v2:0

  • L : BH_BL_BS
    • BH : RF/RV
      • RF : APP:TYP
        • APP : nebule
        • TYP : link
      • RV : VER:SUB
        • VER : 2
        • SUB : 0
    • BL : RC/RL/RL…
      • RC : MOD>CHR
      • RL : REQ>NID>NID>NID…
        • REQ
        • NID : hash.algo.size
    • BS : RS/RS…
      • RS : NID>SIG
        • EID : hash.algo.size
        • SIG : sign.algo.size

BH_BL_BS

RF/RV_RC/RL/RL_RS/RS

APP:TYP/VER:SUB_MOD>CHR/REQ>NID>NID>NID/REQ>NID>NID>NID_EID>SIG/EID>SIG

nebule:link/2:0_0>020210308124933/l>hash.sha2.256>hash.sha2.256>hash.sha2.256_hash.sha2.256>sign.algo.size/hash.sha2.256>sign.algo.size

Structure

Fichiers

Pour chaque nœud va être associé un certain nombre de liens. Ces liens sont stockés, par nœuds, sous forme de fichiers dans le dossier des liens /l . Dans chaque fichiers, les liens sont séparés par un espace ou un retour chariot. Le retour chariot est à privilégier.

Liens

Chaque liens d’un fichier est composé de :

  • BH (blockhead) : Bloc d’entête.
  • BL (blocklinks) : Bloc de liens.
  • BS (blocksigns) : Bloc de signatures.

Chaque type de bloc est obligatoire et ne doit être présent qu’une seule fois. Lles blocs doivent être ordonnés BH, BL puis BS. Le séparateur inter-blocs est _ . Un lien a donc la forme :

BH_BL_BS

Blocs

Dans chaque bloc on va trouver des registres :

  • RF (regform) : Registre de forme. Bloc BH. Unique. Début.
  • RV (regversion) : Registre de version. Bloc BH. Unique.
  • RC (regchrono) : Registre de chronologie. Bloc BL. Unique. Début.
  • RL (reglink) : Registre du lien. Bloc BL. Multiple.
  • RS (regsign) : Registre de signature. Bloc BS. Multiple.

Les registres sont dédiés à des blocs particuliers. Tous les registres dédiés à un bloc doivent être présents dans le bloc. Certains registres doivent être unique dans leur bloc, d’autres peuvent être multiples. Certains registres sont forcément présent en début de bloc.

La structure des blocs est fixe même si certains registres peuvent être multiples :

  • BH : RF/RV
  • BL : RC/RL/RL/RL…
  • BS : RS/RS/RS…

Le séparateur inter-registres est / .

Registres

Certains registres vont contenir des éléments dans un ordre définit :

  • APP : application. Registre RF. Unique. Début.
  • TYP : type de contenu. Registre RF. Unique.
  • VER : version majeur. Registre RV. Unique. Début.
  • SUB : sous-version. Registre RV. Unique.
  • MOD : mode d’utilisation de la marque chronologique. Registre RC. Unique. Début.
  • CHR : valeur de la marque chronologique. Unique. Registre RC.
  • REQ : requête d’action sur le lien. Registre RL. Unique. Début.
  • NID (Node ID) : identifiant de nÅ“ud (ou de l’objet). Registre RL. Multiple dans RL.
  • EID (Entity ID) : identifiant de l’entité signataire. Registre RS. Unique dans RS. Début dans RS.
  • SIG (sign) : valeur de la signature. Unique. Registre RS.

La structure des registre est fixe même si certains éléments peuvent être multiples :

  • RF : APP:TYP
  • RV : VER:SUB
  • RC : MOD>CHR
  • RL : REQ>NID>NID>NID…
  • RS : EID>SIG

Le séparateur inter-éléments est > ou : en fonction du registre concerné.

Éléments

Les blocs et registres sont structurants de l’information. Les éléments sont contenants de l’information.

  • APP = « nebule ».
  • TYP = « link ».
  • VER = « 2 ».
  • SUB = « 0 ».
  • NID : l’identifiant de nÅ“ud ou d’objet = hash.algo.size
    • hash = valeur de l’empreinte.
    • algo = famille d’algorithme utilisé pour le calcul de l’empreinte.
    • size = taille de l’empreinte
  • EID : l’identifiant de l’entité signataire = hash.algo.size
    • hash = valeur de l’empreinte.
    • algo = famille d’algorithme utilisé pour le calcul de l’empreinte.
    • size = taille de l’empreinte
  • SIG : signature
    • sign = valeur de la signature
    • algo = famille d’algorithme utilisé pour le calcul de l’empreinte avant signature.
    • size = taille de l’empreinte

Vérifications

La vérification d’un lien se fait en trois étapes. La première étape va vérifier que le type et la version sont supportés. La seconde étape va permettre de vérifier la structure complète. La dernière va prendre les blocs BH et BL avec leur séparateur et vérifier la/les signature/s.

L’application qui exploite les liens va garder chaque registre de lien décomposé avec les entités signataires. Les signatures non reconnues seront ignorées.

Limites

Il y a un certains nombre de limites dans les quantités acceptables des registres et éléments que peuvent contenir un lien ainsi que de la taille des contenus. Ces limites ne sont pas définies dans le lien et ne sont pas dépendantes de la version du lien mais dépendent du paramétrage de l’application qui lit le lien.

Lien, structure et nomenclature

La structure des liens est en cours de révision. La structure que l’on doit utiliser se doit d’être une représentation d’un arbre le plus équilibré possible afin d’accélérer le traitement et de permettre une réutilisation de code.

La structure de base est répartie en trois parties successives appelées blocs. Le premier est le bloc entête de version qui a pour rôle de définir la façon de traiter l’ensemble. Le second est le bloc des registres de liens. Le dernier est le bloc des signatures. Ces blocs sont obligatoires, sont non interchangeables et sont uniques. Les blocs sont séparés par le caractère _ .

La référence au bloc de la blockchain n’est pas anodine, le second bloc pourra contenir plusieurs liens que l’on pourrait appeler transactions. Il est dans ce cas facile d’ajouter dans ce bloc un lien vers le bloc précédent.

La partie la plus petite de cet arbre est appelée élément. Un élément peut être un identifiant d’objet, un horodatage, un champs action ou un identifiant de version. Cet élément est manipulé directement sans traitement. Il peut cependant être subdivisé soit avec un . soit avec un - . Le premier séparateur sert dans les identifiants d’objets afin de distinguer la valeur de l’empreinte et en extension l’algorithme utilisé.

Ce début de nomenclature n’est cependant pas clôt. L’ensemble des blocs ne peut plus être nommé lien au sens propre du graphe. Et il faut définir la forme du contenu du bloc de liens ainsi que du bloc des signatures.

Graphe et nomenclature

Dans nebule, les liens entre les objets forment ce que l’on nomme un graphe orienté.

Dans les graphes, un lien (ligne ou arête) relie deux objets (nÅ“uds ou points). Dans nebule, les liens relient potentiellement plusieurs objets simultanément. Mais ce n’est pas incompatible avec la théorie. On relie principalement un objet source et un objet destination. L’objet d’opération (ou méta) peut être vu comme une sorte de coloration du lien. Et si un quatrième objet est présent, l’objet de contextualisation, il va surtout servir à réduire les liens que l’on prend en compte à instant donné, c’est plus comme un filtre.

Il ne semble pas opportun de renommer les objets et liens dans nebule. Cependant, il existe des objets un peu particuliers qui n’ont pas de contenu. Leur identifiant n’est pas généré par rapport à un contenu mais est directement généré, souvent aléatoirement. Par construction, ce genre d’objets ne devraient pas pouvoir être rattaché à un contenu. Au pire, même si un contenu était découvert pour l’un de ces objets, n’étant pas attendu il ne devrait pas être utilisé. Ces objets sans contenus par construction seront désormais appelés nÅ“uds. En construisant un identifiant de nÅ“ud qui ne correspond en taille à aucun algorithme de hash, on s’assure qu’il ne sera jamais associé à un contenu. Si la taille de son identifiant correspond à un algorithme de hash, peut-être que ce nÅ“ud est en fait un objet dont on n’a pas eu le contenu.

Structure de liens et RDF

L’étude de la structure de liens à quatre champs objets (quoi quatre champs) crée un parallèle avec la structure du RDF et le bloc des blockchains.

La possibilité de permettre plus de trois champs dans la partie registre du lien crée de nouvelle possibilités certes à la marge mais qui peuvent avoir une utilité. Le premier est d’apporter un contexte à une opération entre source et destination. D’ailleurs, le champ méta devrait s’appeler opérateur. Et comme une opération peut avoir plusieurs contextes possibles le nombre de champs peut dépasser 4. Il faut cependant mettre une limite aux nombres de champs acceptables dans un lien.

signature_signataire_date_action_source_cible_opération_contexte

Mais plutôt que d’ajouter des champs, ou en plus, il est possible de prévoir de gérer deux registres de liens dans un même lien. Voir d’en gérer beaucoup plus. On s’approche là de la mise en forme d’un bloc chère aux crypto-monnaies. Dans cette forme, une partie commune contient la signature et la référence de temps. L’action doit rester associé au cÅ“ur du registre de lien. L’action permet aussi de marque un lien dissimulé et donc de le traiter comme tel. Cela nécessite de modifier la forme du lien

signature_signataire_date/action_source_cible_opération_contexte/action_source_cible_opération_contexte

Sous cette forme nous pouvons rejoindre la forme RDF en permettant la réutilisation de champs par indexation. Par exemple lien second cÅ“ur de lien peut référencer les objets 1 et 2, ou 1 et 4 du premier cÅ“ur de lien. Cela abrège l’écriture, prend moins de place mais complexifie la lecture.

signature_signataire_date/action_source_cible_opération/action_2_1_opération
signature_signataire_date/action_source_cible_opération_contexte/action_1_cible_opération_4

Une autre approche est de mieux délimiter le cÅ“ur de lien afin d’ajouter d’autres informations autour. Il n’y a pas une grande quantité d’information à ajouter, ce peut être de multiples signatures, notamment dans un système de cosignature à seuil. Et, à force d’ajouter des choses dans l’enregistrement des liens, il devient utile de placer une version. Les propriétés exploitables du lien seront directement liées à la version donnée. On arrive ainsi à trois types de blocs dans un lien : la version, les registres de liens et les signatures. Là encore la forme du lien enregistré se complexifie pour permettre de retrouver toutes ces parties sans ambiguïté. Et notamment, chaque partie doit être identifiée avec un préfixe, sauf la version si elle est placé avant le reste. La partie horodatage quand à elle doit aussi faire partie de ce qui est signé, dont elle migre vers les cÅ“urs de liens.

(version)(lien/date_action_source_cible_opération)(lien/date_action_source_cible_opération_contexte/action_1_cible_opération_4)(signe/signature_signataire)(signe/signature_signataire)

Il faut cependant veiller à la défendabilité de la structure ainsi créée. Les signatures sont indépendantes les unes des autres et chaque signature doit couvrir la version et tous les cÅ“urs de liens pris dans le même ordre. Jusque là la vérification des liens se faisait après reconstitution de chaque champs et nettoyage afin d’éviter une tentative de contournement. Ce nettoyage préliminaire peut être maintenu même si il sera plus gourmand en temps de calcul.

Cette forme apporte un nouvel intérêt. Puisque les signatures sont séparée, elles deviennent dissociables. Cela veut dire que l’on peut fusionner plusieurs liens identiques mais avec des signataires différents et donc gagner en place.

Oubli, nettoyage et suppression des liens

Suite des articles Nettoyage des liens et suite, et Suppression et oubli. Le sujet est déjà ancien et il y a eu quelques réflexions sur les objets mais rien de concert n’a été mis en place. Cette absence d’implémentation s’explique parce que la gestion des relations sociales dans les liens n’est pas assez avancée. Le but est double, gérer le stockage et améliorer les performances.

Cependant il est possible de continuer la réflexion notamment sur les liens qui n’ont pas les mêmes contraintes que les objets. La gestion des liens dissimulés dans des fichiers de liens spécifiquement nommés a créé une brèche dans le nommage strict des fichiers de liens. Une première tentative avait commencée avec le stockages de liens anciens dans des fichiers de liens avec un chaînage au fichier d’origine mais n’avait pas abouti du fait de plusieurs problèmes.

Aujourd’hui il est possible de gérer les liens suivant deux méthodes, l’ancienneté et/ou le surnombre. Et cela va trouver une solution dans deux type d’actions, la suppression ou la mise à l’écart dans des fichiers d’archivage datés dédiés. Il faut une option d’activation de l’oubli des liens, une option de sélection de la méthode et option de sélection de l’action. On peut envisager d’utiliser les deux méthodes simultanément.

Pour la méthode de l’ancienneté, il faut distinguer quel type de lien on doit garder disponible immédiatement. Cela veut dire des options par types de liens pour dire l’ancienneté maximale attendue. La notion de sociabilité des liens et intéressante aussi parce qu’il suffit de garder un seul lien signé par l’entité ayant le plus gros score social.

Pour la méthode du surnombre, il faut aussi distinguer le type de lien parce que certains liens sont indispensables au bon fonctionnement d’un objet. Pour chaque type de liens, on garde les liens les plus récents à concurrence du nombre autorisé. Il faut une option par type de liens de définition du nombre à garder pour chaque types. Peut-être faut-il prévoir une gestion sociale afin de pondérer l’ordre des liens et de garder les liens les plus pertinents.

Certains objets ont des rôles importants comme les codes des applications. Ils sont assez facile à gérer parce que les liens sont signés d’une autorité maîtresse du code. Cela va peut-être nécessiter la création d’un nouveau type social mixant strict et réputation pour les gérer encore plus facilement.

Pour l’action de suppression c’est facile, il suffit de ré-écrire le fichier des liens d’un objet en ne gardant que ceux désirés. Les autres liens sont oubliés et perdus localement. Il n’y a pas de mécanisme de corbeille, si besoin il faut basculer sur l’action de mise à l’écart.

Pour l’action de mise à l’écart, on ré-écrit les liens désirés dans le fichiers des liens de l’objet et on écrit les autres liens dans un autre fichier avec un nommage spécial. Ce nommage commence par l’identifiant de l’objet et se voit ajouter une marque de temps et une valeur aléatoire. L’identifiant permet de relier les liens contenus à l’objet concerné. La marque de temps permet de remonter dans le temps progressivement en cas de besoin. La valeur aléatoire empêche la récupération à distance des liens anciens. Le datage se fait à la journée, reste à choisir la base de temps utilisée.

La mise à l’écart de liens avec un horodatage permet un nettoyage facile à posteriori des liens anciens. Et cela permet aussi localement d’activer une utilisation des liens plus anciens sur la sélection d’une date de départ mais au prix de performances dégradées. Ce paramètre de recherche temporelle doit être un argument de l’URL des applications et doit être contrôlé par une option d’autorisation pour une entité déverrouillée ou non.

Ensuite il y a deux stratégies pour rechercher et traiter les fichiers de liens trop gros et/ou avec des liens trop anciens. Soit on fait une recherche globale systématique à intervalle régulier ou lorsque que les performances baissent. Soit on met en place lors de la lecture des fichiers de liens des détecteurs à seuils afin de détecter à l’usage les fichiers de liens nécessitant un nettoyage, et on les traitent immédiatement ou à intervalle régulier.

Désanonymisation contrôlée des liens

De la même façon que l’on a implémenté des entités de recouvrement pour récupérer les objets protégés, il serait peut-être utile de pouvoir mettre en place des entités de recouvrement des liens dissimulés.

Transcodage et translation

Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle, transcodage, Transcodage des liens dissimulés et Anonymisation des fichiers transcodés, il était apparu un problème avec le contenu des fichiers transcodés.

Le transcodage des identifiants des objets pour lesquels on dissimule des liens permet de stocker ces liens dans des fichiers non directement associés à l’identifiant de l’objet concerné. C’est en fait une translation d’identifiant.

Ces objets ‘virtuels’ translatés doivent pouvoir être partagés par transfert ou synchronisation sans risquer de dévoiler l’association entre l’identifiant en clair et l’identifiant translaté.

Le système de translation aujourd’hui mis en place est basé sur une clé unique de translation par entité. Cette translation doit être une fonction à sens unique, donc à base de prise d’empreinte (hash), y compris lorsqu’une ou plusieurs translations sont connues. Enfin, la translation doit être dépendante de l’entité qui les utilise, c’est à dire qu’une même clé peut être commune à plusieurs entités sans donner les mêmes translations.

Cosignature – méthode de surcharge des signatures

Dans la continuité de la réflexion sur la cosignature, suite et orientation, voici une première réflexion sur un méthode alternative.

Une autre méthode est possible afin de remplir de rôle de co-signataires multiples à seuil sans répartition d’un unique secret saucissonné entre plusieurs entités ni nécessité de colocalisation spatial et temporel des entités signataires.

Le point de départ est un objet contenant la liste des combinaisons possibles de cosignatures, c’est à dire les différentes associations de signatures d’entités reconnues valides. La syntaxe de définition de ces associations peut prendre différentes formes. Soit on écrit toutes les associations des entités signataires possibles, soit on écrit les identifiants des entités signataires et la règle de quota attendu.

La signature d’un lien nécessite de s’accorder sur le champ de la valeur de la signature et sur le champ de l’entité signataire.

Le cÅ“ur de la méthode est de réaliser une surcharge progressive des signatures des différentes entités co-signataires jusqu’à obtenir le quota d’une combinaison valide. Cette surcharge est une sur-signature progressive du lien par les entités. Une première entité signe le lien, une seconde entité signe la valeur de la signature de la première, une troisième signe la valeur de la signature de la seconde, etc…
La signature n’étant pas une opération commutative, la vérification de la signature finale doit être vérifiée en réalisant les opérations successives de vérification de signatures avec les clés publiques des entités, mais en sens inverse des signatures. Le cas de tailles de clés différentes n’est ici pas traité.

Comme on réalise une sur-signature progressive et que l’ordre est important, il faut que cet ordre des entités signataires apparaisse quelque part. Il faut aussi que l’on fasse apparaître l’identifiant (ID ou hash) de la pseudo entité co-signataire. Pour cela on va utiliser le champ signataire. On place pour commencer l’ID de la pseudo entité co-signataire puis on concatène successivement et dans l’ordre de signature les ID des entités signataires.

Ce mécanisme nécessite à priori la réunion des différents signataires, ou d’une partie suffisante, afin de réaliser la signature du lien. Il est cependant possible de constituer progressivement la cosignature en sur-signant la signature commune et en s’ajoutant à l’entité signataire finale. Nous répondons bien dans ce cas à une cosignature sans colocalisation spatial ni temporel.

Liens hypertexte et insertions

Liens hypertexte

Le lien hypertexte a fait le succès de l’Internet en permettant depuis un document HTML de pointer vers d’autres documents HTML, ou d’autres ressources, et sur d’autres serveurs à travers tout l’Internet. C’est tellement pratique que d’autres programmes reprennent le même principe, par exemple les outils de bureautique qui permettent de pointer vers des fichiers externes sur le réseau ou localement sur la machine.

Le lien hypertexte ou ses équivalents utilisent une balise dans le texte du document. Cette balise est interprétée par le programme exploitant le document pour l’utilisateur. Et à la place de la balise on montre à l’utilisateur un contenu descriptif sur la destination comme un texte ou une image.

Dans les objets manipulés par nebule, il est possible d’ajouter une balise propre à nebule. Cette balise ne peut pas être la même que pour un document HTML parce que les objets peuvent ne pas être exploités via une page web. La balise doit se déclarer comme balise nebule et faire référence à un objet avec un élément de remplacement. Dans le cas de l’application sylabe, la balise sera remplacée par un lien HTML pointant vers l’objet mais sur le même serveur web.

Ici pas de nécessité de localisation dans la balise parce que la cible, un objet, est une URI et non une URL. Et le protocole n’est pas précisé parce que c’est le programme qui génère l’affichage qui va se charger de choisir le moyen de renvoie, HTTP, FTP, SMTP, XMPP, etc…

Insertions

Mais de la même façon, une balise peut être utilisée pour non plus renvoyer l’utilisateur vers une ressource externe mais plutôt pour inclure une ressource dans l’affichage présenté à l’utilisateur d’un objet. On obtient ainsi plusieurs contenus affichés en même temps par l’intermédiaire d’un seul objet maître.

C’est ce qui est fait par exemple dans l’inclusion de parties dans une page d’un Wiki.

Cela veut dire que les objets contenus doivent être présents sur le serveur pour permettre un affichage complet. Dans le cas contraire il devra être montré clairement à l’utilisateur qu’une partie du contenu manque.

Chaque objet peut avoir une mise à jour. Il est judicieux pour un même objet maître de ne pas suivre les liens de mise à jour des objets contenus. Mais il est possible de générer et de suivre les mises à jour de l’objet maître intégrant celles des objets contenus.

Protection des objets – les origines

Le problème de protection des objets de faible taille, tel que décrit dans l’article Protection et faible entropie, n’a pas de solution simple ou élégante. Peut-être qu’il est temps de se questionner sur la pertinence de la façon dont est assurée la protection des objets, de revoir les réflexions à l’origine de la protection des objets.

D’ailleurs, dans le même ordre d’idée, il faudra peut-être aussi se poser des questions par rapport à la dissimulation des liens qui crée un problème différent mais sans solution simple, performante et élégante.

A l’origine, l’usage de la protection des objets n’avait pas été vu avec autant de cas d’usages. L’idée était de pouvoir dissimuler le contenu d’une objet tout en continuant de le tracer, c’est à dire de l’identifier par son empreinte. Il semblait peu utile de dissimuler des choses aussi simple que « oui » ou « non ».
La capacité de pouvoir tracer devait aussi permettre de pouvoir bannir un objet en se basant sur son empreinte en claire. Une fois protégé un objet a une infinité d’empreintes possibles, donc il devient non traçable en pratique.
L’idée était aussi de pouvoir vérifier que le contenu protégé que l’on recevait d’une autre entité correspondait bien au contenu en clair attendu. Ceci avait pour but de ne pas ce retrouver avec un code offensif une fois déprotégé en lieu et place d’un objet anodin. Dans ce cas un contenu offensif peut être écarté rapidement par un simple lien de mise en liste d’exclusion.

Le problème vient du fait que le lien de protection de type k, en particulier le lien de chiffrement symétrique, fait l’association entre la valeur claire et la valeur chiffrée de l’information. En disposant de l’empreinte de l’information en claire on peut, si la valeur totale de son entropie est faible (ou si, déduit des parties prévisibles, la valeur totale résiduelle de l’entropie de l’information est faible), on peut dans ce cas recalculer l’information.
Il est théoriquement possible que le recalcule de l’information en claire donne une autre information ayant la même empreinte. Mais l’espace des valeurs calculables étant inférieur à la taille de l’empreinte des objets, càd la valeur totale de l’entropie de l’information recalculée en rapport avec la valeur totale de l’entropie d’une empreinte, et en considérant l’algorithme de prise d’empreinte cryptographique suffisamment robuste, il est très peu probable (de l’ordre de l’inverse de la taille des empreintes) de trouver une autre information de même empreinte. Ce serait même très inquiétant pour l’algorithme de prise d’empreinte cryptographique.

En parcourant le code et les cas d’usages actuels, il apparaît que l’on fait déjà indistinctement référence à un objet en clair ou protégé en utilisant son empreinte pour son contenu en clair ou protégé. Le code se charge de remettre dans le bon sens les deux identifiants.
Ne faire référence que à la partie protégée ne pose pas plus de problème que ça dans les usages actuels puisque l’on a juste besoin d’un identifiant.
Il est alors possible de recalculer l’empreinte, donc l’identifiant, du contenu en clair, et donc de pouvoir potentiellement le confronter à lien de mise en liste d’exclusion.

Le temps est encore à la réflexion mais la solution est peut-être là…

Protection des objets – faible entropie

Les messages que l’on protège peuvent être courts ou peuvent être dans certains cas facilement recalculés lorsque la seule partie variable du contenu a une faible entropie. C’est un problème général qui prend tout son sens dans la messagerie.
Le lien de chiffrement relie le hash de l’objet en clair avec le hash de l’objet chiffré. c’est indispensable si on veut pouvoir retrouver le contenu d’un objet en clair sans avoir à parcourir l’intégralité des hashs des objets protégés. C’est pour éviter le problème que l’on a avec l’implémentation des liens dissimulés.

Nous sommes dans le cas d’un modèle MAC-then-encrypt-then-MAC. Il faut trouver un moyen de renforcer l’entropie des objets protégés. Jouer sur le salage ou l’IV du chiffrement ne résout pas le problème puisque le problème vient du MAC avant chiffrement.
Et ce problème ne concerne pas des objets dont le contenu a une entropie supérieure à 128 bits et qui ne sont pas prédictibles. Il n’est pas utile, voire contre productif, de systématiser une solution de renforcement de l’entropie des objets protégés.

Il y a peut-être deux solutions. La première serait d’ajouter au contenu un aléa que l’on serait capable de retirer lors de l’exploitation de l’objet, comme du bourrage (padding). La seconde serait d’opérer sur l’objet une valeur d’un autre objet et de ne pas lié l’objet initial mais uniquement l’objet opéré. Cependant cette seconde méthode parait assez fragile en l’état.

La suite au prochain épisode…

Liens de classification des objets

Les objets que l’on affiche dans les applications sont déjà affublés de certains marquages, même si ils ne sont pas encore tous fonctionnels.

Par exemple, un objet peut être marqué comme dangereux et donc son contenu masqué par défaut. Cependant, les enfers n’ayant toujours pas ouverts, ce marquage n’est pas utilisé.

D’un autre côté, un objet protégé se verra affublé d’un message d’avertissement pour prévenir que son contenu ne doit pas être affiché en public. Ou dans certains cas comme sur les messages, c’est un indicateur qui donne l’état de protection d’un message.

Mais il est un autre type de message qu’il peut être utile de délivrer à un utilisateur. Au delà du fait qu’un objet est protégé, cette protection se justifie sûrement par rapport à la sensibilité du contenu de l’objet. Il est alors légitime de préciser une classification du contenu de l’objet dans certaines circonstances.

Cela permet d’avoir aussi une liste des informations importantes et de les tracer plus facilement.

C’est ce que font les militaires pour marquer les documents sensibles et classifiés. C’est ce que font les industriels pour marquer leurs secrets industriels.

La difficulté ici c’est qu’il n’y a pas de marquage type. Chacun emploie ses propres références de marquages. Il faut donc permettre cette souplesse. De plus, les marques doivent s’additionner et non se remplacer.

On peut imaginer un nouvel objet réservé destiné à gérer les marquages et qui servirait comme champ méta dans les liens de marquage. Les liens de marquages, type l, feront le lien entre l’objet à marquer et un objet de marquage via l’objet de référence.
Peut-être que l’objet de marquage sera lui-même aussi un objet de référence de ce marquage en particulier. Ceci permet de gérer des attributs liés au marquage comme un nom long, un nom court, une couleur, etc…

L’étape suivante sera ensuite de faire apparaître les marquages autours des objets. Est-ce géré comme les messages d’information actuels ? Est-ce géré différemment pour être clairement différencié ? Comme sera géré le multi-marquage ?

Enfin, comme ce système de marquage aura un impact sur les performances, il sera activable au besoin mais pas par défaut.

Pour l’instant c’est une idée non encore implémentée…

Relais d’authentification sans partage de secret

Dans l’article sur les relais d’authentification, on a vu qu’il était possible très simplement de déverrouiller une entité sur un serveur distant en rejouant l’authentification. Mais cela implique de transmettre le mot de passe de cette entité. Et cela veut dire aussi que la clé privée est déverrouillée sur le serveur distant.

Il est théoriquement possible de réaliser un mécanisme d’authentification sans partage de secret. Dans ce cas une instance déverrouillée sur un serveur distant ne disposerait ni du mot de passe ni de la clé privée de l’entité. Il faut donc implémenter un mécanisme qui permette au serveur distant de venir interroger le serveur local avec la session de l’entité en cours. Le mot de passe de l’entité étant stocké dans le cache de la session PHP, il serait impossible au serveur distant de l’obtenir. Mais il peut dans ce cas accéder aux objets protégés et notamment aux secrets de chiffrement des objets. Pour les liens dissimulés c’est par contre plus complexe.

Avec un tel relai il est possible de se connecter sur un serveur distant sans divulguer son mot de passe tout en disposant de l’accès aux objets protégés et à la possibilité de signer des liens.

Un serveur distant compromis pourrait le temps de la session accéder aux objets protégés. Mais une fois la session fermée, dans la fenêtre du navigateur sur le serveur local, aucun autre objet protégé ne pourrait plus être ouvert. Au minimum, tous les nouveaux objets protégés ne seraient pas accessibles. Pour les plus anciens… ça dépend du temps d’ouverture de la session…

Création d’objet et dissimulation des liens

Lors de la création d’un objet, quel qu’il soit, génère au minimum un lien de définition du hash de l’empreinte. Sauf que la création par défaut de liens peut perturber voir anéantir la dissimulation de la création de l’objet.

Certains liens peuvent être dissimulés au moment de la création ou à posteriori, mais le lien de l’empreinte doit rester visible sous peine de perturber la vérification des objets. Il est possible cependant d’anti-dater le champ date de ce lien pour lui retirer toute référence à une plage temporelle de création. Mais il restera et sera un marque d’association du créateur de l’objet si par ailleurs l’objet a un lien d’usage non dissimulé, y compris d’une autre entité.

Le lien d’annulation de suppression d’un objet est moins critique, si dissimulé il fonctionnera toujours.

Les autres liens définissants des propriétés de l’objet peuvent être aussi dissimulés sans problème.

Le code de la bibliothèque nebule en php intègre ces modifications pour les objets, les groupes et les conversations. Seules les entités ne sont pas concernées, leurs contenus ne pouvant être protégés, dissimuler les liens n’a pas de sens.

Penser à supprimer le lien de l’empreinte reviendrait à faire apparaître l’algorithme dans le lien… et donc à changer significativement la forme des liens et le fonctionnement de nebule.

Non vérification crypto et lecture seule – Centre de données et répartition

Suite de l’article sur la Non vérification crypto et lecture seule.

Le problème des très gros objets peut être résolu avec un fonctionnement segmenté de l’application. D’un côté on a l’application principale qui structure et délivre des informations aux utilisateurs, par exemple la page de diffusion des vidéos. Et de l’autre un serveur uniquement dédié au stockage des objets volumineux.

L’application principale peut fonctionner classiquement sur une ou plusieurs instances et faire référence à du contenu, y compris volumineux, hébergé sur un autre serveur. Le contenu est constitué d’objets parfaitement référencés par leurs empreintes et dont l’usage est définit par des liens. On ne fait là qu’exporter le problème des gros objets.

Un serveur uniquement dédié au stockage des objets volumineux va devoir résoudre le problème de la vérification des objets volumineux sans avoir à se poser de question sur leurs pertinences. La pertinence des données, ce sont les applications qui la gère avec les liens. Ce serveur devient ainsi un centre de distribution de données (CDN) dont la stratégie de vérification peut être adaptée. Et là, l’usage des instances sur ces serveurs étant très restreint en fonctionnalité, il est possible d’alléger la vérification des objets. La vérification peut ne plus être systématique avant un téléchargement par un client mais peut être préprogrammée périodiquement lors de faibles sollicitations. Cela veut dire qu’il faut faire confiance à un serveur qui, peut-être, n’est pas entièrement sous contrôle. Il reste possible bien sûr de vérifier la validité des objets après téléchargement.

Reste un petit engrenage à ajouter là dedans. Il faut que la ou les applications, dans des instances différentes, soient capable non seulement de manipuler la référence d’un objet volumineux sans l’avoir effectivement à portée, mais soient aussi capable de faire pointer l’utilisateur sur le bon point de stockage de l’objet volumineux. C’est à dire qu’elles soient capable de désigner le bon centre de données au bon moment.
Pour cela, soit chaque application dispose d’une configuration définissant quel (unique) centre de données utiliser pour les objets dont la taille (défini par un lien de propriété) est supérieure à une limite de vérification. Soit l’application crée un lien (de propriété) définissant pour chaque objet volumineux sur quel centre de données il est disponible. La première solution est la plus simple, la seconde est la plus souple, et les deux peuvent cohabiter.

L’air de rien, le lien définissant sur quel centre de données est disponible un objet volumineux, la deuxième solution, existe déjà. Pour une entité il est possible de définir un lien avec pour objet méta ‘nebule/objet/entite/localisation‘ afin de donner des points de présences d’une entité. Cet objet méta réservé, non utilisé aujourd’hui, pourrait être abandonné et directement remplacé par l’objet méta ‘nebule/objet/localisation‘ plus générique. Ça tombe bien, ce dernier existe déjà… ne reste maintenant qu’à l’implémenter dans le code…

Non vérification crypto et lecture seule

Dans la réflexion de créer une application dédiée à la manipulation de photos et de vidéos se pose invariablement la question des vidéos HD, FHD et UHD. La taille de ce genre de vidéo, pour conserver une qualité de restitution optimale, est assez conséquente.

Le problème ici dans nebule c’est la vérification systématique de la validité du contenu d’un objet manipulé, c’est à dire le re-calcul de son empreinte cryptographique. Si la librairie nebule mémorise le temps d’une session un objet vérifié, dans un cache, ce qui peut déjà présenter un problème de sécurité, il faut cependant toujours faire cette prise d’empreinte au moins une fois.
Par exemple l’empreinte SHA256 d’un fichier de 1,6Go va nécessiter environ 30s sur un disque dur à plateaux normal. La consommation de temps vient principalement de la lecture du support et non du calcul cryptographique. Et la prise d’empreinte cryptographique est un calcul relativement simple…

Il peut en être de même avec les liens qui nécessitent une vérification de signature de type RSA ou équivalent. Ce calcul en cryptographie asymétrique est beaucoup plus long rapporté à la quantité de données. Si un lien ne faire que quelques kilo-octets tout au plus, le nombre de liens à vérifier pour un seul objet peut être potentiellement gigantesque. Au cours du développement des applications de nebule il n’est pas rare de devoir nettoyer à la main les liens de la bibliothèque parce qu’il y en a plus de 80.000 … soit systématiquement 80.000 lien à lire et à vérifier. Là aussi un cache des liens déjà validés dans la session est en place pour accélérer le travail mais ce n’est pas toujours suffisant.

Une possible résolution de ce problème peut être de changer de disque et de passer sur SSD, ou de nettoyer sévèrement les liens utilisés. Mais ces deux cas sont extrêmes et pas toujours réalisables.

Une autre solution peut être envisageable dans le cas de machines de relais ou de partage d’informations en particulier. Comme on l’a vu dans l’article Frontal et relai d’information verrouillé en écriture, il est possible d’avoir des serveurs en lecture seule en activant l’option de lecture seule ou en figeant le système de fichiers. Cela pose des contraintes particulières sur la synchronisation des objets et des liens et sur le fait qu’ils doivent être vérifiés à un moment ou à un autre. Dans ce cas on peut coupler une option de non vérification des objets et des liens avec une option de lecture seule.
Avec cet exemple une entité peut toujours d’authentifier afin d’accéder à du contenu protégé mais ne pourra réaliser aucune action.

On peut imaginer aussi que l’application de mise à jour (upload) peut être autorisée à mettre à jours des liens et des objets en les vérifiant et ainsi avoir un serveur partiellement en lecture seule.

Donc il serait possible d’avoir un serveur de relai d’information en lecture seule uniquement mais avec un fonctionnement accéléré.
Ceci n’est pas implémenté actuellement.

Définition des groupes

La gestion des groupes est entièrement revue et corrigée dans la bibliothèque nebule en PHP orienté objet et dans les applications (sylabe, klicty, messae).
Une fois les applications mises à jour, les groupes existants disparaîtront.

Cet article invalide la définition de groupe telle que définit dans l’article Définition des groupes du 14/01/2016.

Cette implémentation des groupes sera aussi utilisée pour les conversations contenant des messages.

OG / Groupe

Le groupe est un objet définit comme tel, c’est à dire qu’il doit avoir un type mime nebule/objet/groupe.

Fondamentalement, le groupe est un ensemble de plusieurs objets. C’est à dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Mais la définition du groupe doit être plus restrictive afin que celui-ci soit utilisable. Pour cela, dans nebule, le groupe n’est reconnu comme tel uniquement si il est marqué de son type mime. Il est cependant possible d’instancier explicitement un objet comme groupe et de l’utiliser comme tel en cas de besoin.

Le groupe va permettre de regrouper, et donc d’associer et de retrouver, des objets. L’objet du groupe va avoir des liens vers d’autres objets afin de les définir comme membres du groupe.

Un groupe peut avoir des liens de membres vers des objets définis aussi comme groupes. Ces objets peuvent être vus comme des sous-groupes. La bibliothèque nebule ne prend en compte qu’un seul niveau de groupe, c’est à dire que les sous-groupes sont gérés simplement comme des objets.

Continuer la lecture de Définition des groupes

Frontal et relai d’information verrouillé en écriture

Le mécanisme de transmission d’objets et de liens dans nebule permet de distribuer de façon sûr l’information.

Mais le serveur qui héberge des informations et l’application qui manipule ces informations peuvent tous deux être attaqués afin de corrompre ou supprimer ces informations.

Cette capacité de relais fiable de l’information peut être exploité pour maintenir ‘au chaud’ la source de certaines information et n’exposer publiquement que des relais. On peut même avoir plusieurs couches concentriques de relais, ce qui se rapproche beaucoup du chaînage de proxys web. Mais si le cheminement de l’information s’apparente à des sauts entre relais, chaque relai peut être vu individuellement comme un serveur frontal de partage de l’information. Le rôle de frontal l’empêche de relayer automatiquement une attaque, celle-ci doit d’abord compromettre le serveur frontal avant de pouvoir espérer continuer vers la source de l’information.

Enfin, il est possible de faire transiter de 3 façons différents l’information entre source et relais :

  1. le serveur relai va chercher régulièrement de l’information à synchroniser sur la source (ou un autre relai) ;
  2. le serveur source va synchroniser via une connexion montante, et l’application upload, l’information ;
  3. le serveur source va synchroniser l’information en synchronisant le système de fichier, c’est à dire l’intégralité de l’instance nebule.

Afin de renforcer la robustesse d’une instance de serveur nebule, il est possible d’utiliser l’option de verrouillage globale en écriture. Si cette option est forcée dans le fichier de configuration de l’instance, elle ne peut être modifiée via nebule. Mais si cette option interdit au moteur de la bibliothèque nebule d’écrire quoi que ce soit, cela n’empêche pas le serveur web lui même, une application ou un module compromis, d’écrire. Il est aussi possible de rendre impossible l’écriture des objets et liens en changeant les droits sur le système de fichier contenant la page web. Dans ce cas, seule la synchronisation complète via le système de fichier permet de transmettre l’information.

Ainsi, pour l’entité bachue, maître du code, le serveur qui reçoit le nom de domaine, et donc les connexion, est un frontal qui n’a pas de lien réseau direct vers la source, c’est à dire l’entité bachue elle-même.

Le passage par support amovible (air gap) interdit toute attaque directe de l’entité source.

Référencement par défaut

Suite des articles Références d’images, Propriété d’un objet et référence par rapport à un objet et Objet de référence contre suivi du graphe des mises à jours.

La recherche par référence se fait par rapport à un contexte. Ce contexte est définit par le champ méta des liens.

Pour les images, le contexte est définit par un objet contenant ‘nebule/objet/image/reference‘, soit l’ID 1ca96e517fc6ccca45080244c594dd777dc5d3bde0f872f961c28a4e9749ba82.

Pour la bibliothèque nebule en php, le contexte est définit par un objet contenant ‘nebule/objet/interface/web/php/bibliotheque‘, soit l’ID 4297b53cfab1fc41f7820a47d1c21fbf7d0ab83a5ee4f94331c1e0ba1cbb99cf.

Pour les applications, le contexte est définit par un objet contenant ‘nebule/objet/interface/web/php/applications‘, soit l’ID e0150ff815bd5343034ff025624d20f723e2293842ab4eaedabda1ea5790e66b.

Etc…

Mais il n’y a pas que des usages dans des contextes techniques qui sont à prendre en compte. On peut permettre à l’utilisateur de gérer ses références. Pour cet usage un objet de référencement ‘nebule/reference‘ est dédié, soit l’objet 7339ea8fd26c67c3857ca94f9bac47d3841a3b75e799609720b8cc739732a161. La version publique actuelle de sylabe ne le reconnaît pas encore mais c’est le cas dans la version en cours de développement.

La reconnaissance des liens pour les références ne va pas être faite tout à fait de la même façon en fonction de l’usage. On doit être plus restrictif sur les références concernant les applications que pour celles de l’utilisateur. On va se base sur un calcul social de tri différent.

Et pour faciliter la gestion des références par l’utilisateur, un module dédié est en cours de développement. Il est dédié aux utilisateur donc il se base par défaut sur l’objet de référencement dédié aux utilisateurs mais peut très bien se baser sur d’autres objets de référencement.

Enfin, un lien de référence pourra être dissimulé.