Archive for the ‘objets’ Category

Réflexion sur l’évolution de l’interface web pour nebule – dans klicty

Dimanche, octobre 22nd, 2017

Suite des articles Réflexion sur l’évolution de l’interface web pour nebule, objets, entités et entités 2.

Voici l’évolution en cours de l’interface de klicty.

La vue des entités pour se connecter :

020171022-shot-2017-10-22_18-15-25 (suite…)

Réflexion sur l’évolution de l’interface web pour nebule – entités 2

Jeudi, septembre 7th, 2017

Suite de la réflexion sur l’évolution de l’interface web pour nebule, objets. et entité.

Il y a deux façons d’afficher des objets.

La première ressemble à ce qu’il y avait avant, mais en plus complet. Les boutons d’action sont affichés sous la barre de titre de l’objet :

20170907-shot-2017-09-07_22-19-28

(suite…)

Réflexion sur l’évolution de l’interface web pour nebule – entités

Samedi, septembre 2nd, 2017

Suite de la réflexion sur l’évolution de l’interface web pour nebule et objets.

Le code de génération graphique de l’affichage des objets progresse. La mise en place d’une fonction getDisplayList() permet de gérer beaucoup plus facilement une liste d’objets.

Voici un comparatif d’une liste d’entité avec l’ancienne méthode et la nouvelle :

 20170902-shot-2017-09-02_18-35-52

Et :

20170902-shot-2017-09-02_19-09-22

Réflexion sur l’évolution de l’interface web pour nebule – objets

Mardi, août 29th, 2017

Suite de la réflexion sur l’évolution de l’interface web pour nebule.

Au moyen d’une nouvelle fonction d’affichage dans la bibliothèque nebule, la fonction getDisplayObject(), il est maintenant possible de déléguer plus facilement l’affichage d’une liste d’objets ou d’entités.

Voici l’affichage inséré dans un textes :

20170829-inline

Les différents formats d’affichage en blocs avec une hauteur de 32px, 64px, 128px puis 256px :

20170829-bloc-1

20170829-bloc-2


20170829-bloc-3


20170829-bloc-4

Plusieurs blocs s’assemblent pour remplir toute la largeur disponible en rapport avec leur largeur propre. Les informations internes affichées des blocs sont complètement indépendantes les unes des autre. Cela donne :

20170829-assemblage-bloc

La fonction permet aussi un affichage en liste avec un objet par ligne :

20170829-lignes

Quelques possibilités :

  • Le carré de l’icône peut être remplacé par une image ou masqué.
  • Le carré de la couleur n’est pas modifiable est dépend uniquement de l’ID de l’objet, mais peut être masqué.
  • Le nom de l’objet peut être remplacé par un texte.
  • L’identifiant de l’objet peut être masqué.
  • Les entités ou objets de référence (au dessus du nom) peuvent être masqués et si la liste est trop longue il se réduisent aux carrés de couleur et d’icône, voir juste au carré de couleur.
  • Les icônes de protection, de dissimulation et de verrouillage sont activables (en fond vert) et peuvent être masqués.
  • Les émotions sont calculés automatiquement et peuvent être masquées.
  • Le compteur est personnalisable et peut être masqué.
  • Certains éléments ne peuvent pas être affichés ensemble, surtout quand la place est limitée.
  • Les blocs sont centrés par défaut, leurs assemblages aussi.

Il reste à faire la deuxième partie de ces affichages d’objets, c’est à dire de les rendre utilisables autrement que juste par des liens hypertextes. L’idée est de rendre les carrés de l’icône et de la couleur sensible au clic pour afficher un menu complet des actions sur l’objet. Les actions seront dépendantes des modules via la mise en place de nouveaux points d’accrochage (hooks).

Échange ou téléchargement d’objet et lien de mise à jour

Mardi, juin 6th, 2017

Dans l’article Échange ou téléchargement d’objet, on a vu qu’il y avait deux façons de récupérer le contenu d’un objet. Il y a une deuxième différence qui peut apparaître dans certains cas, c’est la transmission du contenu d’origine ou de celui d’un autre objet si il a été créé un lien de mise à jour de l’objet demandé.

  1. Via un lien web avec comme argument /o/id on télécharge le contenu de l’objet avec comme nom son identifiant id. Les liens de mise à jour ne sont pas utilisés parce que l’empreinte de l’objet est vérifié après téléchargement et que si le serveur envoie un autre objet, fut-il une mise à jour, l’objet sera rejeté.
  2. Via un lien web avec comme argument ?o=id on télécharge le contenu de l’objet avec comme nom le nom déclaré par les liens nebule. Mais dans ce cas les liens de mise à jour sont exploités et le contenu renvoyé par le serveur peut ne pas avoir l’empreinte de l’objet demandé.

La prise en compte des liens de mise à jour est toujours délicate parce que cela peut permettre de substituer un objet par un autre. Cette manœuvre est complètement visible dans les liens et nécessite un bon échantillonnage des liens par rapport à leurs poids sociaux.

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…

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

Échange ou téléchargement d’objet

Mardi, mars 28th, 2017

Un objet peut être récupéré de deux façons.

  1. Via un lien web avec comme argument /o/id on télécharge le contenu de l’objet avec comme nom son identifiant id. L’empreinte est ensuite vérifié pour voir si elle correspond à l’identifiant.
  2. Via un lien web avec comme argument ?o=id on télécharge le contenu de l’objet avec comme nom le nom déclaré par les liens nebule. cela permet de télécharger l’objet sous une forme de fichier classique. On fait ainsi une dé-nébulisation de l’objet. C’est aussi le seul moyen d’avoir accès au contenu protégé hors nebule.

Mais pour un utilisateur, ces deux méthodes ne se valent pas. La première méthode sert à la synchronisation et l’échange d’objets entre programmes et n’a pas pas d’intérêt direct pour l’utilisateur. La seconde lui permet au contraire de reprendre un objet sous une forme classique de fichier.

Actuellement un problème existe dans klicty puisque un objet non protégé peut être téléchargé, c’est le but de l’application, mais c’est fait avec la mauvaise méthode. Donc le fichier téléchargé n’a pas le bon nom. Alors que pour un objet protégé ce problème n’existe pas puisqu’il faut impérativement passer par la deuxième méthode pour avoir accès au contenu non protégé.

La première méthode doit être exclusivement réservée à la synchronisation d’objets.

CF : bootstrap – Arguments en ligne et accès directs

Suppression et oubli

Mardi, décembre 13th, 2016

Comme évoqué il y a déjà un certain temps dans l’article sur Le paradoxe du droit à l’oubli, il n’est pas évident du tout que la suppression pure et simple d’une information soit généralement la meilleur solution.

Pour les individus, l’oubli d’une information est vu soit comme un trouble cognitif soit comme une nécessité. C’est un problème si l’information que l’on avait acquise n’est plus disponible alors que l’on en a grand besoin. Les personnes qui perdent la mémoire perdent toute autonomie. D’un autre côté, se souvenir de tout est aussi un problème. La trop grande quantité d’information sur des évènements sans intérêt perturbe la vie courante.

Dans nebule, la suppression des objets répond à deux besoins. Le premier besoin correspond à la récupération de la place mémoire pour stocker d’autres objets plus récents et à priori plus importants. Et le deuxième permet surtout dans la vie courante de ne pas se surcharger d’informations qui n’ont pas d’intérêt immédiat… voir plus d’intérêt du tout.

Mais cette suppression qui est une manière courante de travailler en informatique n’est elle pas problématique ?
L’oubli est la vraie raison de la suppression des objets. Un autre mécanisme doit être trouvé pour remplacer la nécessité de supprimer des objets. Le retrait des liens attachés à un objet ne supprime pas ces liens mais les enlève de l’usage courant. La pondération des émotions d’un objet et le traitement qu’il en est fait permet de gérer aussi le bannissement dans un contexte social des entités.

Le sujet devra être approfondi avant tout mise en applications…

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 – type hash invalide

Vendredi, novembre 18th, 2016

Dans l’article sur le Renforcement de la lecture des objets, il était question notamment de la possibilité de supprimer ou pas un objet dont on ne peut pas vérifier l’empreinte parce que le type de hash est soit inconnu soit non reconnu.

Lors de l’échec de la récupération du type de hash de l’objet, on essaye tout de suite, si l’option permitSynchronizeLinks est à true, de synchroniser rapidement les liens de l’objet. Puis on essaie de relire le type de hash de l’objet.

Une nouvelle option permitDeleteObjectOnUnknowHash vient d’être ajoutée. Elle a true comme valeur par défaut. Elle n’est pas modifiable par lien, pour changer sa valeur par défaut il faut modifier le fichier des options.
Cette option est critique, elle doit toujours rester par défaut à true !

La nouvelle option est utilisée par la bibliothèque nebule en PHP en programmation orienté objet (library POO) par les fonctions checkConsistency() et _getUnprotectedContent() de la classe Object. La fonction _getProtectedContent() ne prend pas en compte cette option, elle se base uniquement sur _getUnprotectedContent() pour la lecture de l’objet protégé et de la clé de déchiffrement associée.

L’implémentation de l’option est un tout petit peu différent ce que l’on peut attendre. Lorsque l’on recherche le lien du type d’empreinte d’un objet (avec la pondération sociale), si aucun lien n’est trouvé ou si le nom de l’algorithme de prise d’empreinte n’est pas reconnu, alors il y a deux possibilités.
L’option permitDeleteObjectOnUnknowHash est à :

  1. false. Dans ce cas les deux fonctions retournent tout de suite un résultat booléen négatif ou un contenu vide.
  2. true. Comme aucun algorithme n’est trouvé, on utilise l’algorithme définit par défaut et on continue le processus de vérification dans les deux fonctions. Si l’empreinte ne correspond pas avec cet algorithme, l’objet est supprimé. C’est une façon de donner une chance à un objet pour lequel les liens auraient été partiellement synchronisés.

Dans la bibliothèque nebule en PHP en programmation procédurale (library PP), la lecture des objets se fait via les fonctions _o_ls1 et _o_lsx. La deuxième repose en fait sur la première. Et en début de fonction _o_ls1, un appel à la fonction _o_vr permet de vérifier le contenu de l’objet.
La fonction _o_vr ne prend en compte que les objets avec un hash fait avec l’algorithme par défaut, aujourd’hui sha256. L’option permitDeleteObjectOnUnknowHash n’est pas utilisée.

Dans les deux bibliothèques, si c’est l’objet avec d’identifiant 0, alors il est systématiquement supprimé.

Enfin, dans tous les cas, il ne faut surtout pas tenter de vérifier l’empreinte avec tous les algorithmes disponibles, cela reviendrait à permettre une attaque sur le plus faible de ceux-ci…

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 virtuel avec rôle – Suite

Dimanche, septembre 18th, 2016

Suite de l’article sur l’Objet virtuel avec rôle.

En fait ces objets virtuels sont déjà utilisés dans sylabe et klicty mais on se contente actuellement de générer aléatoirement la valeur de l’ID des objets de références. Et la taille des ID est la même qu’une empreinte de 256bits.

C’est utilisé par les groupes, le code va évoluer pour réduire la taille d’aléa utilisé et ajouter une partie fixe ou moins aléatoire. C’est utilisé par les nœuds mais ils vont disparaître. Et c’est utilisé par les arborescences, là aussi le code va évoluer.

La part d’aléa va être réduite à 64bits et un préfixe assez long sera ajouté pour avoir une taille d’ID entre 129 et 191bits.

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.

Nommage d’entité – préfix

Lundi, février 29th, 2016

Le nommage des objets permet d’inclure un préfixe et un suffixe.

Pour les fichiers nébulisés, le suffixe correspond à l’extension du nom de fichier. Cette extension ne fait pas partie du nom.

Pour une entité, le préfixe peut être utilisé pour contenir le titre d’une personne ou un grade. Mais le suffixe n’a pas d’utilité au premier abord. Mais une entité peut disposer de plusieurs entités qui lui sont rattachées. Afin de distinguer l’entité maîtresse des autres entités, le suffixe peut les différencier en leur donnant une distinction ou un rôle précis.

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.

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.

Liens de propriétés d’un objet

Lundi, janvier 11th, 2016

Rien de vraiment nouveau pour ce début d’année 2016.

Via la librairie php, on pouvait récupérer une ou des propriétés d’un objet avec le contenu de ces propriétés, on peut maintenant récupérer juste le ou les liens correspondants. Ainsi il est possible d’extraire facilement d’autres informations sur ces propriétés comme la date ou l’entité créatrice…

Sondages et votes

Vendredi, septembre 11th, 2015

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

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

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

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

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

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

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

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

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

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