Catégorie : Cryptographie

Premiers liens signés en v2.0

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

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

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

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

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.

P̩rim̬tre fonctionnel bootstrap Рlibpp

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

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

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

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

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

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

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

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

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.

Structure du lien à quatre champs objets

Suite de l’article Lien à quatre champs objets.

La présence d’un champs de lien supplémentaire reste à la réflexion très tentant.

Un lien à quatre champs peut avoir simplement la même structure que le le lien actuel en ajoutant un champs à la fin. Cependant il peut être intéressant, vu l’expérience sur les liens actuels, de changer significativement la structure du champs et notamment son ordre. Ce ré-ordonnancement permettrait aussi de résoudre d’autres problèmes plus accessoires.

L’un des problèmes aujourd’hui vu comme accessoire est le non typage algorithmique (hash) des empreintes des objets. Ce non typage se retrouve dans les champs des liens. On pourrait préciser celui-ci en fin de hash pour le stockage des objets et aussi dans les liens.

Un autre problème est plus conceptuel dans la structure des liens. On définit les champs source, destination et méta comme un triptyque sujet-complément-verbe. Mais la partie signature ne respecte pas cette philosophie. Et il se trouve aujourd’hui que la réflexion qui a mené la signature à être en début de lien n’a jamais été utilisée en pratique.

Enfin, une des dernières réflexions en cours concerne la multi-signature cumulative (cosignature). elle est possible avec le lien actuel moyennant une adaptation mineure du registre des liens. Mais cette nouveauté pourrait être améliorée et fiabilisée avec un nouveau registre qui l’inclut dès la conception.

Identification de cosignataires

Suite de l’article Cosignature – méthode de surcharge des signatures.

Si la surcharge de signature dans le champs signature ne pose pas de problème, la désignation des entités signataires successives et leur ordre est plus complexe.

La première méthode proposée consistait à placer pour commencer l’ID de la pseudo entité co-signataire puis à concatèner successivement et dans l’ordre de signature les ID des entités signataires.

Mais si cela paraît suffisant pour retrouver les identifiants des différents signataires, la méthode n’est pas propre parce que l’on a un tas par défaut non structuré des entités signataires, informe. Et il peut être difficile de savoir que le lien est sur-signé en l’absence de signe clair.

Il est plus judicieux d’introduire un séparateur dans le champs signataire. La présence du séparateur implique automatiquement que le lien est sur-signé. Mais cela impose de revoir le code de validation et de traitement des liens.

Il est aussi possible de considérer les consignataires comme un groupe. Cependant la pseudo entité co-signataire ne peut pas être utilisée comme groupe parce que toutes les entités la constituant n’ont pas forcément signé le lien et ensuite parce que l’ordre de sur-signature n’est pas forcément cohérent avec l’ordre des entités, et le respect de l’ordre de vérification des signatures est indispensable. On peut imaginer aussi créer un groupe enfant du groupe de fait constitué par la pseudo entité co-signataire mais cela veut dire en pleine vérification des liens de synchroniser et lire un objet, donc conceptuellement de remonter d’un niveau. Donc ce n’est pas applicable.

Cosignature et validation de transactions

Un mécanisme de cosignature fonctionnant sur le principe de quota peut être une réponse possible à la validation de transactions dans un groupe fermé d’entités. La difficulté est que chaque entité peut ne pas reconnaître la même composition du groupe du fait du traitement social des liens du groupe. Mais si le groupe est explicitement définit dans l’objet de groupe avec le quota attendu, alors cela devient jouable…

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.

Billets et entité

La réflexion continue autour d’une implémentation d’une monnaie virtuelle.

L’idée que le billet électronique est une entité, donc un bi-clé cryptographique, est intéressante à étudier. Cela permet de le rendre autonome mais il faut dans ce cas considérer que sa clé privée devient publique ou connue de plusieurs autres entités, ce qui revient au même. On ne peut donc pas supprimer la nécessité de gérer la confiance via un tier de confiance ou une chaîne de blocs pour consolider le graphe des transactions.

Mais si ce billet électronique est constitué de la chaîne des entités du billets, alors on a un mécanisme d’anonymisation.

Double offuscation de lien ou entités de session

L’un des problèmes fondamentaux des liens offusqués aujourd’hui est que l’on doit maintenir impérativement la liaison entre l’entité signataire du lien et une entité destinataire. C’est le seul moyen de permettre à l’entité destinataire de « recevoir » des liens d’une entité source signataire.

Mais cette liaison marque un échange entre deux entités, ce qui déjà dévoile quelque chose que l’on ne voudrait pas forcément voir apparaître publiquement. Il faut pouvoir anonymiser cette liaison.

Pour éviter le marquage de cette relation entre deux entités, il y a deux voies possibles utilisant des entités intermédiaires.

La première solution, pas forcément très élégante, est de faire une double dissimulation des liens. Le premier niveau de dissimulation fait intervenir les deux entités précédentes. Le second niveau va sur-dissimuler le lien mais cette fois-ci avec une entité signataire neutre. Chaque entité de la liaison échange génère et échange préalablement une entité neutre qu’ils s’approprient par des liens dissimulés (pour eux-même). Il faut un mécanisme d’échange préalable des entités neutres de la même façon que l’on échangerait préalablement un secret partagé.
Mais cette méthode ne marche pas avec la dernière modification de la structure du lien dissimulé qui impose au lien dissimulé le signataire du lien non dissimulé.

On peut cependant conserver la notion d’entités neutres dédiées à une échange entre deux entités. Pas besoin de sur-dissimulation, il faut juste être capable d’associer une entité neutre à l’entité d’un correspondant. Nous avons dans ce cas des entités neutre pouvant faire office d’entités de session en complément/remplacement d’une clé de session.

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…

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.

Empreintes des références et lien d’équivalence

Les algorithmes cryptographiques utilisés aujourd’hui sont voués un jour ou l’autre, à longue échéance on préfère, a expirer et être remplacés.

C’est notamment le cas des algorithmes de prise d’empreinte, dites fonctions de hash. Aujourd’hui on utilise généralement sha256 ou sha512, c’est à dire des dérivés de sha2. Mais sha3 arrive et va inexorablement pousser sha2 vers la sortie.

L’évolution de ces algorithmes répond à un problème de sécurité. Mais il est des cas où ils ne sont pas utilisés pour leur sécurité. Par exemple le hash d’un objet définissant une référence se soucie peu de la sécurité de son hash. Ce qui est utilisé c’est la valeur du hash et non du texte à l’origine du hash. Et le hash d’une référence est toujours utilisé dans un lien, donc protégé par une signature.
Dans le cas des références nous allons donc utiliser un algorithme fixe, arbitrairement ce sera sha256, soit une fonction sha2 produisant 256 bits de hash.

Cela n’est pas anodin, ce n’est pas juste une simplification du code. C’est aussi une accélération potentielle pour l’avenir puisqu’il ne sera pas nécessaire de rechercher des objets par référence en se basant sur de multiples empreintes de la référence. Et cela veut dire qu’il faut éviter aussi de d’utiliser le lien d’équivalence pour gérer des équivalences de références.

Entit̩ multi-r̫les Рcompromission et divergence

Suite des articles Entité multi-rôles et suite, Nommage d’entité – préfix, Entités multiples, Changement d’identifiant d’entité et Entités multiples, gestion, relations et anonymat.

La segmentation d’une entité en plusieurs entités avec des rôles différents va nécessiter un peu de travail. La notification du rôle dans le préfixe de nommage des entités ne semble pas opportune.

Lors du changement de mot de passe d’une entité, la clé publique ne changeant pas, l’entité reste référencée par le même identifiant, c’est à dire l’empreinte de l’objet de la clé publique. Par contre l’objet de la clé privée va changer, il faut donc un lien pour retrouver cette nouvelle clé privée. Ce n’est pas encore implémenté mais ici rien de compliqué.
Ça va se compliquer avec le problème de diffusion de l’objet de la nouvelle clé privée afin que l’utilisateur puisse l’utilisé pour s’authentifier sur une autre instance serveur. Là on a l’utilité de permettre facilement la synchronisation d’une entité en préalable à une authentification.

Il y a cependant un problème majeure de sécurité des entités. en effet les anciennes clés privées restent toujours présentes et permettent toujours de déverrouille l’entité. Il ne suffit pas de faire une suppression de l’objet concerné, cela n’a que peu de chance de fonctionner face à un attaquant.
Il est possible de générer une nouvelle entité avec sa propre clé publique, ou de tout le cortège d’entités dans le cas du multi-entités. On peut même imaginer ne changer que l’entité d’authentification. Puis on fait des liens pour dire à tout le monde que l’entité a été mise à jour et marquer le lien de parenté. Cela veut malheureusement dire qu’il faut refaire tous les liens avec la nouvelle entité. Peut-être est-ce l’occasion de faire du ménage et oublier des choses…

Quelque soit le mécanisme, il ne protège pas de la compromission d’une entité par un attaquant. Celui-ci peut réaliser une mise à jours de l’entité qui sera vu comme légitime par les autres entités. La récupération de l’entité est possible puisqu’elle existe toujours mais comment vont se comporter les autres entités lorsque l’on va faire une deuxième mise à jours d’entité… en concurrence avec la première. Il y a peut-être un moyen de faire jouer le côté social des relations entre entités et de volontairement créer un challenge entre les deux mises à jours de l’entité et toutes les entités tierces.
Ou alors on accepte la survivance simultané de ces deux entités qui vont progressivement diverger avec le temps. Là aussi un tri social pourra se faire mais plus naturellement.

La solution à ce problème peut être l’usage d’une entité faisant autorité et capable d’imposer une mise à jour d’entité en particulier. Mais on essaie de se débarrasser des autorités encombrantes ce n’est pas pour les réintroduire au premier coup de froid.
Il existe une autre forme d’autorité, ce peut être une entité à soi mais que l’on n’utilise pas au jours le jour et stockée à la maison au chaud. Les cambriolages étant encore un risque contemporain cette entité de recouvrement peut être dupliquée en d’autres lieux. Évidement son vol ne doit pas permettre de prendre le contrôle de l’ensemble.

Il restera toujours le vol sous contrainte. Mais ça on ne peut rien y faire de toute façon.

L’hégémonie d’un mécanisme unique de gestion des identités est un problème puisque une fois ce mécanisme corrompu il n’existe plus de recours pour récupérer son identité.

Ce problème n’a pas vraiment de solution complète et pas encore d’orientation précise pour gérer les conflits. Il reste encore du travail de réflexion…

Anonymisation/dissimulation des liens

Il y a déjà une série d’articles en 2012 sur la Liaison secrète (et suite), puis en 2014 sur l’Anonymisation de lien (et correction du registre de lien), et enfin en 2015 sur la Dissimulation de liens, multi-entités et anonymat et l’Exploitation de liens dissimulés.

On trouve dès 2015 un schéma d’implémentation d’un lien dissimulé (offusqué) et le mécanisme cryptographique utilisé :

20150627-nebule-schema-crypto-lien-c

Mais la mise en pratique ne suit pas alors que la bibliothèque nebule en php orienté objet est prête à reconnaître les liens dissimulés.

Parce qu’en pratique, il ne suffit pas juste de générer ces liens et de les lire, il faut aussi les stocker de manière à pouvoir les retrouver tout en gardant des performances acceptables lors du passage à l’échelle.

Comme l’anonymisation attendue nécessite la mise en place d’un minimum de déception vis-à-vis d’un adversaire, il n’est pas possible de stocker les liens dissimulés dans les liens des objets concernés. Cela casserait presque immédiatement la confidentialité du lien dissimulé parce que les objets ont souvent chacun des rôles propres et donc des places privilégiées dans les liens qui servent aux usages de ces objets.

Les deux seules informations que l’on ne peut dissimuler sans bloquer le transfert et l’exploitation des liens dissimulés, c’est l’entité signataire et l’entité destinataire (si différente). Donc le stockage ne peut se faire que de façon connexe à des deux entités. Si ce n’est pas le cas les liens ne pourront pas être retrouvés et utilisés lorsque nécessaire.

Prenons le cas d’une entité qui décide de dissimuler la grande majorité de son activité, elle va donc dissimuler tous les liens qu’elle génère (ou presque). Là où habituellement le stockage des liens aurait été réparti entre tous les objets concernés, du fait de la dissimulation ils vont tous se retrouver attachés à un même objet, l’entité signataire. Cela veut dire que pour extraire un lien de cette entité il va falloir parcourir tous les liens. Cela peut fortement impacter les performances de l’ensemble.
Et c’est aussi sans compter le problème de distribution des liens parce que l’on les distribue aujourd’hui que vers les objets source, cible et méta… et non sur les entités signataires. L’entité destinataire est dans ce cas naturellement desservie directement, est-ce un problème si l’entité signataire ne l’est pas ?
Une autre méthode pourrait consister à créer un objet de référence rattaché à l’entité et spécifiquement dédié à recevoir les liens dissimulés. Mais les liens dissimulés ne contenant pas cette objet de référence, on doit créer un processus plus complexe pour la distribution des liens tenant compte des entités signataires et destinataires.
On peut aussi mettre tous les liens chiffrés dans les liens d’un objet c puisque c’est le type de lien après dissimulation. Mais cela veut dire que tous les liens dissimulés de toutes les entités se retrouvent au même endroit. On ne fait que déplacer le problème de la longue liste des liens à parcourir.
Enfin on peut rester sur une des premières idées qui consiste à stocker des liens dissimulés non plus dans la partie du stockage dédié au liens mais directement dans un objet. Le défaut de cette méthode est qu’à chaque nouveau lien dissimulé généré, il faut refaire un nouvel objet avec une novelle empreinte… et donc un nouveau lien pour le retrouver.

On rejoint le problème de la persistance des données dans le temps, de leurs objets et liens associés. Une solution déjà proposée, mais non implémentée, consiste à organiser un nettoyage par l’oubli des objets et des liens dans le temps en fonction d’une pondération.

Pour commencer à expérimenter, les liens dissimulés seront stockés uniquement avec l’entité destinataire. Cela ne remet pas en cause la distribution actuelle des liens. On verra à l’expérience comment gérer un flux massif de liens et son impact sur les performances.

Modification des sources d’aléa – implémentation

Suite à l’article Modification des sources d’aléa, la fonction getPseudoRandom a été modifiée dans la bibliothèque PHP orienté objet de nebule pour ne plus consommer du tout de ressource d’aléa mais en gardant une entropie forte.

La génération se fait depuis une graine qui est la concaténation de la date, de l’heure en micro-secondes, du nom de la bibliothèque, de la version de la bibliothèque et enfin de l’identifiant de l’instance locale du serveur. La graine dépendant donc surtout de l’heure avec une grande précision et est spécifique à chaque serveur.

La graine sert à générer via une fonction de hash l’état du compteur interne. Comme la taille du hash est fixe, une boucle permet d’alimenter la sortie en dérivant successivement l’état du compteur interne. À chaque tour de la boucle, l’état du compteur interne est dérivé en calculant le hash de lui-même. À chaque tour de la boucle, on concatène à la sortie le hash de l’état du compteur interne concaténé à une valeur fixe. L’état du compteur interne n’est jamais directement sorti et il est effacé en fin de génération de fonction.

Le bootstrap utilise aussi une génération pseudo aléatoire pour la création notamment d’identifiants temporaires. La bibliothèque PHP procédurale intégrée au bootstrap a aussi été modifiée. Elle fonctionne sur le même principe décrit ci-dessus. Une nouvelle fonction __pr est créée et les fonctions ne nécessitant par un aléa fiable ont été modifiées.

La fonction de hash actuellement utilisée pour la dérivation du compteur interne et la fonction sha256. Comme on attend pas de propriété cryptographique forte dans cette fonction, n’importe quelle fonction de hash peut faire l’affaire.

Ce sera disponible dans la prochaine version diffusée de la bibliothèque de nebule.

Modification des sources d’aléa

La bibliothèque nebule en PHP orienté objet présente deux fonctions de génération d’aléa dans la classe dédiée à la cryptographie.

Les fonctions :

  • public function getPseudoRandom($size=32)
  • public function getStrongRandom($size=32)

La première fonction getPseudoRandom permet de générer un aléa correct mais pas fiable, c’est à dire de qualité mais pas pour un usage cryptographique sûr. Il va servir principalement pour générer des identifiants d’objets de références.

La seconde fonction getStrongRandom permet de générer un aléa beaucoup plus fiable, c’est à dire réellement non prédictible, pour un usage cryptographique sûr. Cependant cet aléa est précieux parce que sa génération prendre du temps et peut consommer des ressources, ce qui limite la quantité de bon aléa que l’on peut demander à un instant donné. Il doit donc être réservé strictement à des usages requérant un aléa fiable.

Or, la fonction getPseudoRandom fait appel à la même fonction interne openssl_random_pseudo_bytes que getStrongRandom, ce qui veut dire qu’elle consomme de l’aléa précieux alors que ce n’est pas nécessaire.

Cette fonction getPseudoRandom va être modifiée pour générer un aléa correct mais non fiable à partir de la date/heure et une préparation via une ou plusieurs fonctions de hachage. Elle ne devra en aucun cas être utilisée comme source pour générer des mots de passes de session ou de protection des objets, etc… nécessitant un aléa de qualité cryptographique.