Archive for the ‘liens’ Category

Anonymisation/dissimulation des liens

Samedi, mars 10th, 2018

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.

Blockchain et nebule – Le cas de la messagerie

Jeudi, mars 8th, 2018

Suite de l’article Blockchain et nebule.

La blockchain ne permet pas juste de manipuler de l’argent. Une forme de blockchain avec une portée réduite peut se retrouver dans la messagerie. Lorsqu’un message est transmis à des destinataires, ceux-ci vont marquer le message comme lu lorsqu’ils vont l’ouvrir les uns après les autres. On considère ici cette marque de lecture comme publique. Si un message est référencé par une empreinte et que les marques de lectures référencent cette empreinte, alors nous avons une chaîne de blocs indirecte. Un message ne référence pas le message précédent comme cela se fait avec un bloc, mais chaque message est vu et validé collectivement dans une période de temps (idéalement) réduite. Cette validation par les destinataires scelle les messages dans le temps et la chaîne est constituée par l’enchaînement des messages dans le temps, dans une conversation. Il est possible grâce à ce mécanisme de détecter les tentatives de suppression ou d’insertion de messages.

Cette façon de marquer les messages et de les figer dans le temps est une base de travail possible pour l’implémentation de l’équivalent d’une blockchain via les mécanismes de nebule et surtout avec ses restrictions. Ce mécanisme peut permettre un fonctionnement local là où la blockchain nécessite impérativement un consensus global et une cohérence mondiale.

L’utilisation de l’entité maître du temps kronos ne permet de résoudre qu’une partie du problème.

Revers Polish Notation

Samedi, mars 3rd, 2018

Le mécanisme décrit dans l’article Copier/coller et marquage pourrait être avantageusement réutilisé par un module d’application afin de mettre en place une pile. Cette pile pourrait ensuite être manipulée via un langage de type Revers Polish Notation (RPN ou RPL). En plus des opérations de base de manipulation de la pile, d’autres opérations pourraient être ajoutées par l’application ou par chaque modules présents. Par exemple le module de gestion des liens pourrait ajouter des opérations sur les liens dont la copie d’un lien (pile niveau 1) en remplaçant le hash source du lien par un nouvel objet (pile niveau 2). Etc…

Copier/coller et marquage

Samedi, mars 3rd, 2018

Dans les différentes applications sont hérités des classes de la bibliothèque nebule un équivalent du copier/coller. C’est un équivalent parce que cela ne fonctionne pas tout à fait pareil.

Copier un objet que l’on collerait ailleurs pourrait se rapprocher de copier un fichier mais cela ne veut rien dire dans nebule parce qu’un objet copié… ne donnerait que l’objet lui même. Seul une transformation (dérivation) donne un nouvel objet à part entière, aussi infime soit la transformation.

De même, un couper/coller n’a pas plus de sens parce que cela reviendrait à retirer un objet pour le remettre au même endroit.

Quand on parle d’endroit d’un objet, techniquement c’est son emplacement de stockage. Mais pour l’utilisateur d’une application cela peut vouloir dire que c’est l’usage de l’objet qui est copié. On copie donc un usage, c’est à dire plus ou moins un lien, d’un objet pour en faire autre chose. Par exemple on peut vouloir faire apparaître l’objet dans plusieurs endroits différents d’une arborescence.
Pour répondre à cette usage sans usurper la fonction de copier/coller, il a été introduit depuis quelques temps dans les applications la notion de marquage. Marquer un ou plusieurs objets permet ensuite d’y faire référence plus tard ailleurs dans l’application, ou dans une autre application. Ainsi, un objet dans une arborescence peut être marqué puis peut être utilisé dans la messagerie pour le transmettre à quelqu’un.

Le marquage peut contenir des objets, y compris sous forme d’entités de groupes ou de messages, et/ou des liens. L’application qui permet l’usage des objets et liens doit faire le tri de ce qui est utilisable pour elle entre les différents types d’objets et les liens.

Il peut être possible de parler d’un vrai copier/coller ou couper/coller d’un objet non pas localement mais entre plusieurs instance de nebule, c’est à dire entre plusieurs serveurs. Le copier/coller reviendrait à une duplication de l’objet sur une autre instance. Le couper/coller reviendrait à dupliquer un objet sur une autre instance puis à supprimer l’objet localement, par exemple pour faire de la place.

Blockchain et nebule

Mercredi, janvier 31st, 2018

C’est une première réflexion sur la blockchain et une implémentation avec les mécanismes de liens mis en place par nebule.

La, ou plutôt, les blockchains sont en plein essor et représentent non seulement un avenir proche pour échanger de l’argent mais aussi un avenir pour tout ce qui aujourd’hui nécessite un tiers de confiance. Les tiers de confiances peuvent être imposés ou choisis. Une blockchain permet de ne plus déprendre d’un tiers de confiance mais en conservant certains rôles remplis par un tiers de confiance. On ne se contente pas de remplacer le tiers de confiance, on sécurise même ses rôles en réduisant (voir supprimant) tous les abus de position dû à la place privilégiée du tiers de confiance.

La blockchain permet une validation globale et expose toutes les transactions à la vue de tous. Cette notion de globale implique en fait un réseau global : l’Internet.
Cette nécessité de la présence de l’Internet est potentiellement problématique. Rien ne permet d’affirmer que l’Internet survivra à moyen terme. Une fragmentation peut survenir brusquement. Et si l’Internet se retrouve fragmenté, il sera très difficile, sinon impossible, de le réunifier de nouveau. La gestion de l’information tel qu’elle est portée par nebule permet de survivre à un isolement des réseaux, l’ensemble est résilient à une fragmentation de l’Internet… même si ce ne sera pas aussi facile, rapide et fluide qu’aujourd’hui.

La blockchain permet de graver une information. L’information est une transaction financière, une transmission d’un bien réel ou virtuel. Cela veut dire une impossibilité d’annuler une opération, une transaction.
Avec nebule, les liens qui peuvent matérialiser une transaction peuvent être annulés soit par l’entité qui les émet, soit par soi-même. Si cette propriété de suppression de lien est problématique, il faudra définir un nouveau type de lien non annulable. Mais il est peut-être possible de trouver un processus présentant le même résultat tout en utilisant des liens annulables. Et il faut que celui-ci soit capable de fonctionner de façon globale tout en étant résilient à une fragmentation partielle ou forte du réseau.

Chargement de liens

Samedi, janvier 6th, 2018

Les applications génèrent par elles-même les liens dont elles ont besoin pour répondre aux usages des utilisateurs.

Il est possible de transmettre des liens qui ne peuvent être générés localement. C’est le cas des mises à jours d’applications.
Pour cela, il existe deux méthodes et deux moyens. Le code correspondant à été ré-écrit dans la bibliothèque nebule.

Pour qu’un lien soit traité, il faut que les trois soit validées :

  1. permitWrite : permet d’écrire des objets ou des liens.
  2. permitWriteLink : permet d’écrire des liens.
  3. permitUploadLink : permet de charger des liens.

Les deux méthodes sont :

  • le transfert d’un lien individuel ;
  • le transfert d’un fichier contenant (potentiellement) plusieurs liens.

Les deux moyens sont deux possibilités de transmettre les liens :

  • via l’application upload directement ;
  • via le module module_upload de l’application sylabe.

Lors du chargement d’un lien, quelque soit la méthode ou le moyen, le lien est d’abord vérifié structurellement.
Ensuite la vérification de la signature du lien et de son signataire répond à un processus plus complexe dépendant de deux options et de l’état de connexion d’une entité :

  1. permitPublicUploadLink : permet de charger des liens signés sans qu’une entité en cours ne soit déverrouillée, quelque soit le signataire.
  2. permitPublicUploadCodeMasterLink : permet de charger des liens signés par le maître du code (bachue) sans qu’une entité en cours ne soit déverrouillée.
  3. $this->_unlocked : variable qui donne l’état de déverrouillage de l’entité en cours d’utilisation, càd qu’une entité est connectée.

Si l’entité locale est déverrouillée, le transfert d’un lien devient une action légitime de l’entité. Tous les liens signés sont écrits si ils sont valides (structure et signature). Tous lien non signé est ré-écrit et signé par l’entité en cours; puis écrit.

Cette ré-écriture de lien est une ré-appropriation du lien. Est-ce que cette ré-appropriation peut poser problème ?

Messages et protection

Jeudi, novembre 30th, 2017

Une protection des messages basés les objets et liens de nebule peut être mise en place. Cette protection ne vise pas à dissimiler la présence d’un message mais à dissimuler son contenu. La dissimulation de la présence d’un message, plutôt nommée offuscation, est un autre sujet à part entière.

Mais cette protection peut ne pas être efficiente et elle peut se retrouver mise à mal du fait du fonctionnement même des liens de chiffrement (type k). Le lien de chiffrement va associer l’empreinte du message en clair avec l’empreinte du message chiffré. Hors un message de petite taille va avoir une forte probabilité avec le temps d’être (re-)créé par ailleurs et donc de dévoiler le contenu d’un message protégé. Et même pour un message plus conséquent, si il est partiellement ou complètement redécoupé en sous-objets via des liens de subdivision (type s), peut voir une partie de son contenu protégé dévoilé. La subdivision peut être par ailleurs légitime dans le cas d’un pré-découpage par mots pour la recherche sur mots clés.
La protection doit donc être adaptée dans le cas de la messagerie.

L’ajout d’un sel avant chiffrement ne résout pas le problème puisqu’il ne masque pas le lien entre le texte clair et chiffré. Par contre il est peut-être possible de pré-saler l’objet à chiffre et ne le reconnaître que sur son empreinte pré-salée.
A travailler…

PFS sans connexion

Lundi, mai 22nd, 2017

La confidentialité persistante (Perfect Forward Secrecy – PFS pour les intimes) permet lors d’échanges entre personnes via un support protégé d’oublier le contenu des échanges précédents. Lorsqu’elle est bien implémentée, il est impossible de pouvoir reconstituer les échanges précédents d’une « conversation », y compris pour les personnes concernées.

Lors de la compromission du moyen de communication, seules les conversations en cours sont accessibles. Les précédentes conversations sont définitivement inaccessibles y compris pour un adversaire qui aurait enregistré tous les échanges chiffrés et obtiendrait par la force le compte d’un utilisateur.

La meilleur méthode pour arriver à ce résultat est d’utiliser un secret de session partagé entre les personnes qui communiques, négocié en début de conversation et volontairement oublié en fin de conversation. La négociation peut être faite notamment via un échange de type Diffie-Hellman (DH).

La PFS a donc principalement deux contraintes. Il faut échanger un secret temporaire avec ses correspondants. Et il faut que ce secret soient privés, c’est à dire stockés uniquement en interne sur les machines destinataires.

De par sa conception acentrée et potentiellement non directement inter-connecté, nebule ne permet pas la mise en place directe d’une forme de PFS. Fondamentalement, nebule permet de gérer de l’information et non des connexions. La non connexion directe entre les correspondants empêche une négociation préalable instantanée d’un secret partagé type DH. Ensuite, toute la protection de la partie privée des entités repose sur le chiffrement des objets et l’offuscation des liens, mais tous les liens et objets ainsi protégés sont partagés publiquement et donc enregistrables. Il n’est pas possible de se baser sur ces mécanismes de protection pour la PFS.

Il existe peut-être un moyen d’implémenter une PFS sûr dans nebule mais au prix d’un grand nombre d’objets à synchroniser, à voir…

Entité multi-rôles

Jeudi, avril 20th, 2017

D’un point de vue robustesse et sécurisation des clés cryptographiques, il est recommandé de séparer les rôles des différentes clés utilisées. Une clé crypto ne doit avoir qu’un seul usage, c’est à dire un seul rôle. Dans l’implémentation des entités dans nebule, les entités étant des clés cryptographiques avec de multiples rôles, il va falloir les scinder.

Les rôles les plus fréquents sont :

  1. L’authentification. C’est utilisé pour le déverrouillage des entités.
  2. La signature. Tous les liens sont signés.
  3. Le chiffrement. Il intervient dans la protection des objets et la dissimulation des liens.

Toutes les clés liées à des rôles peuvent être rattachées à une clé cryptographique asymétrique principale et reliées à celle-ci par des liens. Il est possible par la suite d’étendre sans problème les rôles comme par exemple les rôles d’autorités locales.

La segmentation des clés par rôles impose la gestion de multiples clés pour une entité, notamment lors de la synchronisation sur différents supports. Mais elle permet en cas de compromission d’une clé de limiter l’étendu des dégâts.

Modification de l’ordre de prise en compte des propriétés d’un objet

Jeudi, mars 30th, 2017

Je reprends progressivement le développement de nebule pour corriger le bugg de klicty et améliorer dans sylabe le module correspondant.
Et je tombe sur un problème non dans l’implémentation mais dans la façon dont on prend en compte les propriétés d’un objet, ou plutôt l’ordre de prise en compte lorsque cela est fait plusieurs fois. C’est à dire, quel propriété retient-on en priorité lorsqu’il y a plusieurs liens d’un objet vers plusieurs propriétés.
Le problème n’a pas une solution difficile en soi mais le fait qu’il concerne une brique importante de nebule me freine à le modifier sans plus de réflexion. Les implications que cela engendre peuvent être très importantes dans pleins d’endroits du code de la bibliothèque de nebule et des applications. (suite…)

Entités de recouvrement – configuration

Samedi, décembre 10th, 2016

Suite des articles Entités de recouvrement et implémentation.

L’objet de référence de définition des entités de recouvrement est l’objet contenant :

nebule/objet/entite/recouvrement

De nouvelles options permettent de gérer la prise en compte des entités de recouvrement par la bibliothèque nebule en PHP :

  1. permitRecoveryEntities (boolean, critical) : commutateur global d’activation des entités de recouvrement via les liens des autorités strictement locales. Par défaut à false.
  2. permitRecoveryRemoveEntity (boolean, careful) : commutateur qui permet à une entité de supprimer le partage de la protection d’un objet avec une entité de recouvrement. Par défaut à false.
  3. permitInstanceEntityAsRecovery (boolean, critical) : commutateur de définition de l’entité instance locale comme entité de recouvrement. Outrepasse les liens. Par défaut à false.
  4. permitDefaultEntityAsRecovery (boolean, critical) :commutateur de définition de l’entité par défaut comme entité de recouvrement. Outrepasse les liens. Par défaut à false.

Toutes les options sont en lecture seule, c’est à dire que les liens d’options ne sont pas pris en compte. Au besoin, ces options doivent être modifiées dans le fichier d’environnement.

A false, par défaut, la première option désactive complètement la détection des entités de recouvrement et le mécanisme de partage de protection des objets pour les entités de recouvrement.

La deuxième option, si à true, permet à une entité de supprimer le partage de protection à une entité de recouvrement particulière. Cette action doit être faite après la protection, réalisée systématiquement, et sur tous les objets protégés un par un. Cette option va faire disparaître le bouton de suppression de partage de protection dans les affichages, mais elle est aussi vérifiée lors de la suppression effective du partage de protection d’un objet si l’utilisateur tente la suppression de force.

Le lien de déclaration d’une entité de recouvrement a la forme :

  • action : f
  • source : entité instance locale, par exemple = 3af39596818c1229d7a3d08b9f768622903951305df728609a68a2957f7f3882
  • cible : entité de recouvrement, par exemple = 19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57
  • méta : objet de référence de recouvrement

La désactivation est un lien de type x.

Les liens doivent être signés de l’entité instance locale ou de l’entité par défaut en fonction des options de permission.

Entités de recouvrement – implémentation

Jeudi, décembre 8th, 2016

Dans le précédent article sur les Entités de recouvrement qui date de plus de 6 mois, il était question de l’implémentation du mécanisme dans le code. Jusque là la liste des entités de recouvrement était renvoyée vide.
Ce mécanisme peut être une contrainte légale dans certains pays mais ce peut être aussi un moyen d’assurer plus sereinement la disponibilité des données sans remettre en question significativement la confidentialité de celles-ci. Sa portée est strictement local et ne doit pas devenir un comportement global sous peine de rompre la confiance dans l’ensemble du code de nebule.

La prochaine version de la bibliothèque nebule en PHP intègre le code nécessaire à la détection des entités marquées localement comme entités de recouvrement et le code qui se charge de dupliquer la protection des objets pour ces entités.

La définition des entités de recouvrement est purement locale et est attachée à l’entité instance locale. La détection d’entité de recouvrement se fait sur un lien de type f entre chaque entité définie comme entité de recouvrement et l’entité instance locale. Le champ méta du lien est l’objet de référence contenant nebule/objet/entite/recouvrement. Seuls les liens des autorités strictement locales sont pris en compte, c’est à dire à l’exception du puppetmaster, du maître de la sécurité et du maître du code.

La duplication de la protection se fait au niveau de la fonction (unique) de protection d’un objet setProtected(). Afin d’éviter la suppression du partage de protection avec une entité de recouvrement, la fonction cancelShareProtectionTo() ne supprime pas ce partage si l’entité est dans la liste des entités de recouvrement.
Afin de ne pas perturber l’utilisateur, les applications affichent tous les partages de protection mais n’affichent pas le bouton correspondant pour ces entités de recouvrement.

Les applications option, sylabe et klicty permettaient déjà l’affichage des entités de recouvrement même si elle était vide. Ces affichages ont été améliorés afin d’afficher en plus l’entité autorité locale qui a activé l’entité comme entité de recouvrement. Le but est d’avoir un mécanisme qui peut être contraignant et indiscret mais dont le fonctionnement doit être ouvert et loyal pour maintenir la confiance de l’utilisateur.
L’application option est maintenant le centre de gestion des entités de recouvrement. Il est possible, lorsque l’on déverrouille l’entité instance de serveur, d’ajouter ou de retirer des entités à la liste. Les autres entités ne peuvent faire que de l’affichage. Si un lien est généré par une autre entité, il est ignoré.

Renforcement de la lecture des objets

Jeudi, novembre 17th, 2016

Dans la bibliothèque nebule en PHP orienté objet et dans certaines applications, un certain nombre de fonctions lisent le contenu des objets soit directement soit via la fonction getContent() de l’instance Object des objets. Toutes les lectures de contenus d’objets et de liens se font via la classe io de la bibliothèque et non directement par des fonctions de PHP de lecture de flux, de lecture directe. Les fonctions de la classe io ne font pas d’opérations cryptographiques, donc aucune vérification n’est possible à ce niveau.

Dans la bibliothèque se trouve aussi la fonction checkConsistency() pour vérifier le contenu d’un objet. Deux différences existent entre les deux fonction :

  1. La fonction getContent() lit des données et vérifie si l’empreinte est bonne sauf si l’objet est trop grand. Si l’objet est trop grand, un argument $permitTruncate permet de ne pas rejeter le contenu de l’objet si il est trop grand. Pour les petits objets la vérification se fait dans tous les cas. La limite d’un objet petit ou grand est définie par l’option ioReadMaxData. Si l’empreinte ne correspond pas, le contenu n’est pas conservé et un contenu vide est renvoyé à la fonction appelante. La fonction checkConsistency() ne renvoie pas de données mais vérifie juste l’empreinte, le résultat booléen renvoyé et négatif ou positif.
  2. La fonction getContent() ne supprime pas un objet si l’empreinte n’est pas bonne. La fonction checkConsistency() vérifie l’empreinte et, si l’empreinte n’est pas bonne, supprime l’objet via une fonction de la classe io.

Il est difficile de prendre une décision de suppression d’un objet parce que peut-être que l’algorithme de prise d’empreinte n’est pas reconnu par la machine sur laquelle tourne l’instance serveur. En cas d’absence de possibilité de vérification comme un type d’empreinte inconnu ou un objet trop grand, il faut renvoyer un contenu vide ou résultat négatif mais il ne faut pas supprimer l’objet. Quoique dans un mode paranoïaque, il faut peut-être prévoir de supprimer tout objet non vérifiable, à voir.

Pour commencer l’argument $permitTruncate n’a pas de raison d’être, il est contre productif parce qu’il affaibli l’ensemble du système. Il va être supprimé et les applications qui affichaient un objet avec un message comme quoi l’objet est trop gros vont afficher un message d’erreur sans le contenu.

Ensuite, la fonction getContent() fait appel à une fonction privée _getProtectedContent() pour lire le contenu d’un objet protégé. Elle va maintenant sous-traiter aussi la lecture des objets non protégés à une fonction privée _getUnprotectedContent(). Cette nouvelle fonction sera très similaire à la fonction checkConsistency() mais renverra un contenu complet ou vide au lieu d’un résultat booléen. Et bien sûr l’objet sera supprimé en cas d’empreinte invalide. Et la fonction _getProtectedContent() utilisera la fonction _getUnprotectedContent() pour la lecture de tous les objets accessibles non protégés.

La suppression de l’argument $permitTruncate va poser un gros problème pour l’affichage des gros objets. Ceux-ci via le navigateur peuvent être affiché dans certains cas parce que le navigateur les télécharge sur le serveur web pour les afficher au fur et à mesure. C’est le cas des vidéos non protégées. Une des options pour résoudre ce problème est peut-être d’utiliser le lien de type s jusque là inexploité par la bibliothèque…

Propriété d’un objet et référence par rapport à un objet

Lundi, octobre 31st, 2016

Il y a deux liens très proches dans leurs formes. Le lien qui attribut une propriété à un objet et le lien qui désigne un objet par rapport à un objet de référence.

Le lien d’affectation d’une propriété à un objet :

  • type : l
  • source : un objet.
  • cible : l’objet de l’attribut.
  • méta : objet de référence du type d’attribut.

Le lien de désignation d’un objet par rapport à un objet de référence :

  • type : f
  • source : l’objet de départ.
  • cible : l’objet recherché.
  • méta : objet de référence

Leur forme est assez proche. Mais plus encore la recherche du résultat tourne autour de l’objet cible dans le contexte de l’objet méta, elle est strictement identique au type de lien près.

Et pourtant ce ne sont pas les mêmes liens parce que ce n’est pas le même usage.

Le lien d’affectation d’attribut définit une propriété de l’objet source alors que le lien de désignation par référence n’est pas une propriété mais un usage de l’objet source. Il y a donc bien une raison de séparer le type de ces deux formes de liens, et d’avoir deux fonctions distinctes de recherche.

Objet de référence contre suivi du graphe des mises à jours

Vendredi, octobre 21st, 2016

Le bootstrap retrouve l’application et la librairie nebule à utiliser en suivant des liens. Actuellement, il suit le graphe des mises à jours de l’application sélectionnée et celui de la librairie nebule.

Mais il est possible dans ce cas d’utiliser une autre méthode de suivi des liens pour retrouver la dernière version des applications et de la librairie.

La recherche par les graphes permet de suivre les liens de type u d’objets en objets jusqu’à arriver en bout de branche de l’arborescence des mises à jours. Évidement, il faut tenir compte des liens de type x de suppression de liens. Et il faut aussi que l’objet en bout de branche soit disponible sinon on remonte la branche en sens inverse…
La méthode est efficace mais elle est très longue a jouer.

Il est possible de faire plus simple pour un résultat identique dans notre cas.

La structure de recherche de la dernière version d’un objet a dans notre cas un cheminement complètement sous contrôle. Il n’est pas nécessaire de gérer une profondeur de recherche de plus de un niveau, même avec des liens de mise à jour. En ne fonctionnant plus que sur un seul niveau il est tout à fait possible de n’utiliser que des liens de type f depuis un objet de référence.
Et en plus il est possible de ne plus à devoir gérer les liens de suppression de liens. Un nouveau lien remplace automatiquement le précédent lien. Si il faut supprimer le lien de la dernière mise à jour, il suffit de rejouer à une date plus récente le lien de la version précédente.

Et ainsi il y a gain du nombre d’objets parcourus et gain de temps de traitement sur les quelques liens qui restent.

Cette méthode va être mis en place dès que possible dans le bootstrap.

Objet virtuel avec rôle

Vendredi, septembre 16th, 2016

Jusque là, la très grande majorité des objets créés ont ou ont eu un contenu et donc une empreinte numérique unique leur correspondant. Cela a été le cas pour les images utilisées comme icônes dans sylabe par exemple.

Le problème par exemple avec l’usage direct de l’objet d’une icône fait que si on veut la mettre à jour ou tout simplement en utiliser une autre à la place il faut faire un lien de mise à jour. Or ce lien de mise à jour n’a pas de contexte, c’est à dire de champs méta dans le lien. Ainsi la mise à jour s’applique partout alors que ce n’était pas forcément le but recherché.

La solution est de ne pas faire référence directement à une image que l’on veut utiliser dans une application mais à un objet intermédiaire. Cet objet n’a même pas besoin d’avoir un contenu, il est virtuel puisque son empreinte est créé de toute pièce sans contenu. Et du fait du fonctionnement de nebule, il n’aura probablement jamais (dans un temps raisonnable) de contenu correspondant à son empreinte.

Ainsi, on ne référence plus dans une application des icônes mais des objets intermédiaires. Et les icônes à utiliser n’ont plus à être des liens de mise à jour u mais deviennent naturellement des liens de dérivation f avec comme champs méta l’objet intermédiaire ou l’objet de l’application. Je pense que l’objet intermédiaire est le mieux comme champs méta.

Comme l’empreinte de cet objet virtuel est purement indicative, on peut lui mettre n’importe quelle valeur de n’importe quelle taille. Il est cependant raisonnable de choisir une taille assez conséquente et différente des tailles usuelles des empreintes, c’est à dire différent de 64, 128, 224, 256, 384, 512, 768, 1024, 2048, 4096, etc…
Chaque application peut utiliser les mêmes valeurs pour ces objets intermédiaires ou choisir par exemple une valeur préfixe identique suivi de valeurs aléatoires jusqu’à avoir une taille raisonnable.

Entités de recouvrement

Dimanche, février 28th, 2016

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

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

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

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

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

Intégration des groupes dans la librairie php – suite

Dimanche, février 21st, 2016

Suite à l’intégration des groupes dans la librairie php, l’ensemble est fonctionnel et stable dans la librairie ainsi que dans klicty.

Intégration des groupes dans la librairie php

Lundi, février 1st, 2016

Suite à la définition des groupes, l’intégration a commencé dans la librairie php orienté objet.

L’intégration est profonde puisque les groupes sont gérés comme des objets spécifiques comme c’était déjà le cas pour les entités. Une classe dédiée ainsi que tout un tas de fonctions leurs sont dédiés et personnalisés.

Les applications sylabe et klicty vont intégrer progressivement les groupes, notamment dans un module adapté.

Dans le même temps, un groupe fermé étant uniquement constitué de liens d’une seule entité (et cela doit être vérifié), le filtre social est en cours de mise en place. Ainsi, il est possible de restreindre la prise en compte des liens suivant ces filtres sociaux :

  • self : liens de l’entité ;
  • strict : liens de l’entité et des entités autorités locales ;
  • all : toutes les entités, mais avec un classement par pondération des entités.

L’activation du filtre social et donc de la possibilité de le choisir dans le code à nécessité un revue de tout le code de la librairie et des applications. Il reste à vérifier les modules de sylabe.

Définition des groupes

Jeudi, janvier 14th, 2016

Dans le cadre de la recherche sur l’implémentation des groupes dans nebule, voir 1 2 3 4 5, deux nouveaux objets réservés ont été ajoutés :

  • nebule/objet/groupe
  • nebule/objet/groupe/ferme

Le groupe

Il a été décidé de rattacher explicitement le groupe aux objets, et donc aussi aux entités notamment. Mais la notion de groupe peut être vu comme plus globale.

Si on reprend par exemple l’objet réservé nebule/danger, les objets qui lui sont liés deviennent de fait un groupe des objets à éviter. Il suffit donc de lier un objet à un autre objet pour créer un groupe. Cependant cela n’est pas très pratique puisque l’on ne peut rechercher que des groupes pré-définis à l’avance et communément acceptés. Cela marche bien pour quelques groupes avec des fonctions biens précises et universellement reconnues, et pas plus.

Fondamentalement, le groupe est la définition d’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. Le groupe met en relation des objets vis-à-vis d’une référence. C’est la référence qui identifie le groupe. Dans le cas de notre objet réservé nebule/danger, c’est cet objet réservé qui est la référence du groupe. Par simplification, l’objet de référence peut être assimilé comme étant le groupe.

Tout objet peut ainsi devenir la référence d’un groupe. Cela n’est pas sans poser un gros problème pratique. Puisque tout objet peut être un groupe, comment fait-on pour s’y retrouver dans l’immensité des groupes disponibles ?
Pour simplifier le problème, nous allons considérer les liens comme étant des groupes directs ou explicites. Et nous allons considérer les relations de deux liens ou plus comme étant des groupes indirectes ou implicites. Ces groupes indirectes sont centrés sur un et un seul objet de référence. Si nous prenons par exemple comme référence l’objet réservé nebule/objet/type, nous avons un groupe indirecte qui va contenir tous les objets de même type mime.

Nous allons à partir de maintenant considérer comme groupe uniquement les groupes indirectes.

Mais cela fait encore beaucoup trop de possibilités en pratique pour que la notion de groupe n’ai un intérêt pour gérer les objets. Nous allons en plus restreindre la notion du groupe, et donc son exploitation dans nebule, à l’objet vers lequel un lien explicite est créé avec les objets. Ce lien explicite est un lien de type l avec comme objet meta l’objet réservé nebule/objet/groupe ou nebule/objet/groupe/ferme.

Groupe ouvert ou fermé

L’exploitation des objets d’un groupe nécessite de pouvoir lire et vérifier les liens qui unissent les objets au groupe. Ces liens peuvent être générés par différentes entités, le traitement social des liens déterminera pour une entité donnée quels sont les objets reconnus dans le groupe ou pas. Ce processus est avant tout un traitement pour reconnaitre ou non les objets d’un groupe ouvert.

Pour un groupe fermé, la reconnaissance des objets du groupe n’est plus déterminée par le traitement social des liens. Ne sont reconnus les objets comme appartenant au groupe fermé que ceux dont le lien est signé par l’entité qui a créé le groupe. Dans le cas d’un groupe fermé, les liens générés par une autre entité pour ajouter des objets au groupe ne sont pas pris en compte.

Si il est possible de créer un groupe ouvert avec un objet de référence donné, le même objet de référence peut aussi servir pour un groupe fermé. Dans ce cas, lors du traitement, le groupe ouvert et le groupe fermé apparaissent comme deux groupes distincts. Si plusieurs entités créent des groupes ouverts avec le même objet de référence, un seul groupe est affiché et regroupe tous les groupes ouverts. Si plusieurs entités créent des groupes fermés avec le même objet de référence, il faut exploiter et afficher tous les groupes fermés comme des groupes indépendants.

Un groupe fermé doit toujours être accompagné son l’entité créatrice lors de l’affichage.

Groupe public ou privé

La distinction entre un groupe public et un groupe privé, c’est la visibilité de celui-ci pour les entités tierces. Si tous les liens qui relient les objets au groupe sont dissimulés, alors le groupe est privé et seuls les entités qui peuvent voir ces liens ont accès au groupe.

Cependant, si une partie des liens ne sont pas dissimulés ou si ils sont rendus publics, alors le groupe devient partiellement public.
Les liens, même dissimulés, sont complètement manipulables par toute entité qui y a accès, ainsi en terme de sécurité on peut dire qu’un groupe privé est un groupe public qui s’ignore. Mais ce n’est pas forcément un problème, si une entité A crée un groupe fermé et privé, alors le fait qu’une autre entité B crée un même groupe (même référence) ouvert et public ne rend pas pour autant public le groupe de l’entité A.

Groupe actif ou passif

Un groupe est par défaut passif. Il devient actif lorsqu’il devient capable de réaliser des actions, c’est à dire de signer des liens. Le seul objet capable de signer un lien est une entité, ainsi un groupe actif est un groupe dont l’objet de référence est une entité.

Si le secret de cette entité de référence du groupe n’est connu que d’une seule autre entité (entité maitresse) alors c’est un groupe actif fermé. Si cette entité de référence du groupe a plusieurs entités maitresses alors c’est un groupe actif ouvert.

Un groupe actif ouvert peut aussi être privé si tous ses liens sont dissimulés. Il devient semi-public ou public si une des entités maitresse dévoile tout ou partie des liens du groupe. De la même façon, une entité peut ajouter d’autres entités au groupe, c’est à dire partager le secret de l’entité de référence du groupe. En terme de sécurité, un groupe actif ouvert privé est souvent un groupe actif ouvert public qui s’ignore.

De fait, toute entité piratée devient un groupe actif ouvert, même si le secret de l’entité n’est pas rendu public.

Groupe d’entités

Un groupe d’entité est un groupe dans lequel on ne considère que les objets qui sont des entités. Les autres objets sont ignorés. Lorsque ce groupe n’est plus vu comme un groupe d’entités, tous les objets sont pris en compte et les entités sont gérés comme des objets. La distinction se fait donc uniquement sur le type d’objet que l’on attend du groupe au moment de l’exploiter.

Graphe de groupes

Lorsque l’on a un groupe qui est lié à un autre groupe, comme doit-on l’interpréter ?
Cela crée un graphe de groupes. Il est possible soit d’ignorer les sous-groupes dans un groupe ou au contraire de résoudre le graphe pour en exploiter tous les objets. Dans le cas de la résolution du graphe, on retombe sur les problèmes classiques de la résolution d’un graphe.

Le graphe de groupe peut aussi dans certains cas avoir un traitement convenu. Cela peut être appliqué à la gestion des options ou des droits dans une application. On va ainsi lier des groupes d’entités avec des groupes d’options et/ou des groupes de droits. Dans ce cas on ne parcours le graphe que de façon simple et non ambigüe.

Nœud

La notion de nœud est concurrente de la notion de groupe. Sauf usage nouveau et différencié, le nœud va disparaitre de nebule.