Introduction

Cette page contient la documentation technique de nebule version 1.3 .

Fondations

Le but du projet nebule, c’est le moteur de gestion des objets. La couche basse qui s’occupe du stockage des objets et liens, et de leur diffusion.

L’interface utilisateur est un programme utilisé pour manipuler ces objets et traduire les liens à l’utilisateur ou les actions de l’utilisateur en liens.

Le projet nebule se concrétise numériquement par trois piliers de base :

  1. l’objet
  2. le lien
  3. la confiance

L’objet et ses dérivés

Objet

Description

L’objet est un agglomérat de données numériques.

Un objet numérique est identifié par une empreinte ou condensat (hash). Cette empreinte doit avoir des caractéristiques propres forte correspondant à des fonctions de prise d’empreinte (hash) cryptographiques. C’est à dire :

  1. L’espace des valeurs possibles est suffisamment grand.
  2. La répartition des valeurs possibles est équiprobable.
  3. La résistance aux collisions est forte.
  4. La fonction utilisée est non réversible.

La fonction de prise d’empreinte actuellement recommandée est sha256. Elle remplie toutes les exigences évoquées ci-dessus. Aucune faille ne permet de remettre en question de façon significative sa résistance et sa non-réversibilité à cours terme.

Pour certains petits besoins spécifiques, la fonction de prise d’empreinte peut être minimaliste, donc rapide et non sécurisée. Cependant, celle-ci doit faire au minimum 2 octets. Les valeurs sur un octets sont susceptibles d’être interprétées, comme la valeur 0 qui ne désigne aucun objet.

Définition

L’objet est identifié par un ID égal à la valeur de son empreinte.

L’indication de la fonction de prise d’empreinte (hashage) est impératif. Elle est défini par le lien :

  • action : l
  • source : ID de l’objet
  • cible : hash du nom de l’algorithme de prise d’empreinte
  • méta : hash(‘nebule/objet/hash’)

Le lien de définition du type est optionnel. Le type est généralement le type mime reconnu de l’objet.

Caractéristiques optionnelles

Les différentes caractéristiques utilisables :

  • nebule/objet
  • nebule/objet/hash
  • nebule/objet/homomorphe
  • nebule/objet/type
  • nebule/objet/localisation
  • nebule/objet/taille
  • nebule/objet/prenom
  • nebule/objet/nom
  • nebule/objet/surnom
  • nebule/objet/prefix
  • nebule/objet/suffix
  • nebule/objet/liens
  • nebule/objet/date
  • nebule/objet/date/annee
  • nebule/objet/date/mois
  • nebule/objet/date/jour
  • nebule/objet/date/heure
  • nebule/objet/date/minute
  • nebule/objet/date/seconde
  • nebule/objet/date/zone
  • nebule/objet/entite
  • nebule/objet/entite/type
  • nebule/objet/entite/localisation
  • nebule/objet/entite/suivi
  • nebule/objet/entite/suivi/seconde
  • nebule/objet/entite/suivi/minute
  • nebule/objet/entite/suivi/heure
  • nebule/objet/entite/suivi/jour
  • nebule/objet/entite/suivi/semaine
  • nebule/objet/entite/suivi/mois
  • nebule/objet/entite/suivi/annee
  • nebule/objet/entite/maitre/securite
  • nebule/objet/entite/maitre/code
  • nebule/objet/entite/maitre/annuaire
  • nebule/objet/entite/maitre/temps
  • nebule/objet/entite/web
  • nebule/objet/entite/web/applications
  • nebule/objet/noeud
  • nebule/objet/emotion
  • nebule/objet/emotion/joie
  • nebule/objet/emotion/confiance
  • nebule/objet/emotion/peur
  • nebule/objet/emotion/surprise
  • nebule/objet/emotion/tristesse
  • nebule/objet/emotion/degout
  • nebule/objet/emotion/colere
  • nebule/objet/emotion/interet
  • nebule/objet/conversation
  • nebule/objet/conversation/ferme
  • nebule/objet/conversation/protegee
  • nebule/objet/conversation/dissimulee
  • nebule/objet/groupe
  • nebule/objet/groupe/ferme
  • nebule/danger
  • nebule/warning
  • nebule/arborescence

Une caractéristique d’un objet est défini par le lien :

  • action : l
  • source : ID de l’objet
  • cible : hash de la valeur de la caractéristique (ex : ‘Dupont’)
  • méta : hash de la caractéristique (ex : ‘nebule/objet/nom‘)

Cette liste est susceptible de s’agrandir avec le temps pour répondre à de nouveaux besoins…

Nommage

Le nommage à l’affichage du nom des objets repose sur plusieurs propriétés :

  1. nom
  2. prénom
  3. surnom
  4. préfixe
  5. suffixe

Ces propriétés sont matérialisées par des liens de type l avec comme objets méta, respectivement :

  1. nebule/objet/nom
  2. nebule/objet/prenom
  3. nebule/objet/surnom
  4. nebule/objet/prefix
  5. nebule/objet/suffix

Par convention, voici le nommage des objets pour l’affichage :

prénom préfixe/nom.suffixe surnom
Les différents nommages sont définis par des liens :

  • action : l
  • source : ID de l’objet
  • cible : hash de la valeur de nommage (ex : ‘Dupont’)
  • méta : hash propriété de nommage (ex : ‘nebule/objet/nom‘)

Groupe

Description

Définition

Le groupe est identifié par un ID unique et en partie aléatoire calculé par concaténation de :

  1. la valeur en hexadécimal : ‘656e7562656c6f2f6a627465632f6e6f6576737274616f690a6e0000′
  2. la valeur du hashage d’une valeur aléatoire (de 128bits minimum recommandé)

Le groupe est un objet caractéristique. Cet objet est reconnu par son type défini par le lien :

  • action : l
  • source : ID de la conversation
  • cible : hash(‘nebule/objet/groupe’)
  • méta : hash(‘nebule/objet/type’)

L’indication de la fonction de prise d’empreinte (hashage) est impératif. Le lien est identique à celui défini pour un objet.

Toutes les autres indications sont optionnelles.

Nommage

Le nommage à l’affichage du nom des groupes repose sur une seule propriété :

  1. nom

Cette propriété est matérialisée par un lien de type l avec comme objets méta :

  1. nebule/objet/nom

Par convention, voici le nommage des groupes :

nom

Conversation

Description

Définition

La conversation est un objet caractéristique. Cet objet est reconnu par son type défini par le lien :

  • action : l
  • source : ID aléatoire entre 129 et 191 bits
  • cible : hash(‘nebule/objet/conversation’)
  • méta : hash(‘nebule/objet/type’)

L’indication de la fonction de prise d’empreinte (hashage) est impératif. Le lien est identique à celui défini pour un objet.

Toutes les autres indications sont optionnelles.

Nommage

Le nommage à l’affichage du nom des groupes repose sur une seule propriété :

  1. nom

Cette propriété est matérialisée par un lien de type l avec comme objets méta :

  1. nebule/objet/nom

Par convention, voici le nommage des groupes :

nom

Entité

Description

L’entité est un objet caractéristique. Elle dispose d’une clé publique, par laquelle elle est identifiée, et d’une clé privée.

Définition

L’indication de la fonction de prise d’empreinte (hashage) ainsi que le type de bi-clé sont impératifs. Le lien est identique à celui défini pour un objet.

Le type mime mime-type:application/x-pem-file est suffisant pour indiquer que cet objet est une entité. Des valeurs équivalentes pourront être définies ultérieurement.

Toutes les autres indications sont optionnelles.

Nommage

Le nommage à l’affichage du nom des entités repose sur plusieurs propriétés :

  1. nom
  2. prénom
  3. surnom
  4. préfixe
  5. suffixe

Ces propriétés sont matérialisées par des liens de type l avec comme objets méta, respectivement :

  1. nebule/objet/nom
  2. nebule/objet/prenom
  3. nebule/objet/surnom
  4. nebule/objet/prefix
  5. nebule/objet/suffix

Par convention, voici le nommage des entités :

préfixe prénom "surnom" nom suffixe

Localisation

Description

Une localisation permet de trouver l’emplacement des objets et liens générés par une entité.

Un emplacement n’a de sens que pour une entité.

Une entité peut disposer de plusieurs localisations. Il faut considérer que toute entité qui héberge l’objet d’une autre entité devient de fait une localisation valide même si cela n’est pas explicitement définit.

Interface

Description

L’interface est une entité.

Application

Description

L’application est une entité.

Annuaire

Description

L’annuaire est une entité.

Relais

Description

Le relais est une entité.

Les liens

Le lien est la matérialisation dans un graphe d’une relation entre deux objets.

Liens d’un objet

Les liens d’un objet sont consultables séquentiellement. Il doivent être perçus comme des méta-données d’un objet.

Les liens sont séparés soit par un caractère espace  » « , soit par un retour chariot « \n ». Un lien est donc une suite de caractères ininterrompue, c’est à dire sans espace ou retour à la ligne.

La taille du lien dépend de la taille de chaque champs.

Chaque localisation contenant des liens doit avoir un entête de version.

Liens dans un objet

Certains liens d’un objet peuvent être contenus dans un autre objet.

Cette forme de stockage des liens permet de les transmettre et de les manipuler sous la forme d’un objet. On peut ainsi profiter du découpage et du chiffrement. Plusieurs liens peuvent être stockés sans être nécessairement en rapport avec les mêmes objets.

Les liens stockés dans un objet ne peuvent pas faire référence à ce même objet.

Tout ajout de lien crée implicitement un nouvel objet de mise à jour, c’est à dire lié par un lien de type u.

Chaque fichier contenant des liens doit avoir un entête de version.

Les objets contenants des liens ne sont pas reconnus et exploités lors de la lecture des liens. Ceux-ci doivent d’abord être extraits et injectés dans les liens des objets concernés. En clair, on ne peux pas s’en servir facilement pour de l’anonymisation.

Entête

L’entête des liens est constitué du texte nebule/liens/version/1.2. Il est séparé du premier lien soit par un caractère espace  » « , soit par un retour chariot « \n ».

Il doit être transmit avec les liens, en premier.

Registre

Le registre du lien décrit la syntaxe du lien :

Signature_HashSignataire_TimeStamp_Action_HashSource_HashCible_HashMeta
Ce registre a un nombre de champs fixe. Chaque champs a une place fixe dans le lien. Les champs ont une taille variable. Le séparateur de champs est l’underscore « _ ». Les champs ne peuvent contenir ni l’underscore « _ » ni l’espace  »  » ni le retour chariot « \n ».

Tout lien qui ne respecte pas cette syntaxe est à considérer comme invalide et à supprimer. Tout lien dont la Signature est invalide est à considérer comme invalide et à supprimer. La vérification peut être réalisée en ré-assemblant les champs après nettoyage.

Le champ Signature

Le champ Signature est représenté en deux parties séparées par un point « . » . La première partie contient la valeur de la signature. La deuxième partie contient le nom court de la fonction de prise d’empreinte utilisée.

La signature est calculée sur l’empreinte du lien réalisée avec la fonction de prise d’empreinte désignée dans la deuxième partie. L’empreinte du lien est calculée sur tout le lien sauf le champs signature, c’est à dire sur « _HashSignataire_TimeStamp_Action_HashSource_HashCible_HashMeta » avec le premier underscore inclus.

La signature ne contient que des caractères hexadécimaux, c’est à dire de « 0 » à « 9 » et de « a » à « f » en minuscule. La fonction de prise d’empreinte est notée en caractères alpha-numériques en minuscule.

Le champ HashSignataire

Le champ signataire désigne l’objet de l’entité qui génère le lien et le signe.

Il ne contient que des caractères hexadécimaux, c’est à dire de « 0 » à « 9 » et de « a » à « f » en minuscule.

Le champ TimeStamp

Le champ TimeStamp est une marque de temps qui donne un ordre temporel aux liens. Ce champs peut être une date et une heure au format ISO8601 ou simplement un compteur incrémental.

Le champ Action

Le champ Action détermine la façon dont le lien doit être utilisé.

Quand on parle du type d’un lien, on fait référence à son champ Action.

L’interprétation de ce champ est limité au premier caractère. Des caractères alpha-numériques supplémentaires sont autorisés mais ignorés.

Cette interprétation est basée sur un vocabulaire particulier. Ce vocabulaire est spécifique à nebule v1.2 (et nebule v1.1).

Le vocabulaire ne reconnaît que les 8 caractères l, f, u, d, e, x, k et s, en minuscule.

Action l – Lien entre objets

Met en place une relation entre deux objets. Cette relation a un sens de mise en place et peut être pondérée par un objet méta.

Les liens de type l ne devraient avoir ni HashMeta nul ni HashCible nul.

Action f – Dérivé d’objet

Le nouvel objet est considéré comme enfant ou parent suivant le sens du lien.

Le champs ObjetMeta doit être vu comme le contexte du lien. Par exemple, deux objets contenants du texte peuvent être reliés simplement sans contexte, c’est à dire reliés de façon simplement hiérarchique. Ces deux mêmes textes peuvent être plutôt (ou en plus) reliés avec un contexte comme celui d’une discussion dans un blog. Dans ce deuxième cas, la relation entre les deux textes n’a pas de sens en dehors de cette discussion sur ce blog. Il est même probable que le blog n’affichera pas les autres textes en relations si ils n’ont pas un contexte appartenant à ce blog.

f comme fork.

Action u – Mise à jour d’objet

Mise à jour d’un objet dérivé qui remplace l’objet parent.

u comme update.

Action d – Suppression d’objet

L’objet est marqué comme à supprimer d’un ou de tous ses emplacements de stockage.

d comme delete.

Le champs HashCible peut être nuls, c’est à dire égal à 0. Si non nul, ce champs doit contenir une entité destinataire de l’ordre de suppression. C’est utilisé pour demander à une entité relaie de supprimer un objet spécifique. Cela peut être utilisé pour demander à une entité en règle générale de bien vouloir supprimer l’objet, ce qui n’est pas forcément exécuté.

Le champs HashMeta doit être nuls, c’est à dire égal à 0.

Un lien de suppression sur un objet ne veut pas forcément dire qu’il a été supprimé. Même localement, l’objet est peut-être encore présent. Si le lien de suppression vient d’une autre entité, on ne va sûrement pas par défaut en tenir compte.

Lorsque le lien de suppression est généré, le serveur sur lequel est généré le lien doit essayer par défaut de supprimer l’objet. Dans le cas d’un serveur hébergeant plusieurs entités, un objet ne sera pas supprimé si il est encore utilisé par une autre entité, c’est à dire si une entité a un lien qui le concerne et n’a pas de lien de suppression.

Action e – Équivalence d’objets

Définit des objets jugés équivalents, et donc interchangeables par exemple pour une traduction.

Action c – Chiffrement de lien

Ce lien contient un lien chiffré. Il permet d’offusquer des liens entre objets et donc d’anonymiser certaines actions de l’entité.

Le champs HashSource fait référence à l’entité destinataire du lien, celle qui peut le déchiffrer. A part le champs de l’entité signataire, c’est le seul champs qui fait référence à un objet.

Le champs HashCible ne contient pas la référence d’un objet mais le lien chiffré et encodé en hexadécimal. Le chiffrement est de type symétrique avec la clé de session. Le lien offusqué n’a pas grand intérêt en lui même, c’est le lien déchiffré qui en a.

Le champs HashMeta ne contient pas la référence d’un objet mais la clé de chiffrement du lien, dite clé de session. Cette clé est chiffrée (asymétrique) pour l’entité destinataire et encodée en hexadécimal.

Lors du traitement des liens, si une entité est déverrouillée, les liens offusqués pour cette entité doivent être déchiffrés et utilisés en remplacement des liens offusqués originels. Les liens offusqués doivent être vérifiés avant déchiffrement. Les liens déchiffrés doivent être vérifiés avant exploitation.

Action k – Chiffrement d’objet

Désigne la version chiffrée de l’objet.

Action s – Subdivision d’objet

Désigne un fragment de l’objet.

Ce champ nécessite un objet méta qui précise intervalle de contenu de l’objet d’origine. Le contenu de l’objet méta doit être de la forme x-y avec :

  • x et y exprimé en octet sans zéro et sans unité ;
  • x strictement supérieur à zéro ;
  • y strictement inférieur ou égal à la taille de l’objet (lien vers nebule/objet/taille) ;
  • x inférieur à y ;
  • sans espace, tabulation ou retour chariot.
Action x – Suppression de lien

Supprime un ou plusieurs liens précédemment mis en place.

Les liens concernés par la suppression sont les liens antérieurs de type l, f, u, d, e, k et s. Ils sont repérés par les 3 derniers champs, c’est à dire sur HashSource_HashCible_HashMeta. Les champs nuls sont strictement pris en compte.

Le champ TimeStamp permet de déterminer l’antériorité du lien et donc de déterminer sa suppression ou pas.

C’est la seule action sur les liens et non sur les objets.

Le champ HashSource

Le champ HashSource désigne l’objet source du lien.

Le champ signataire ne contient que des caractères hexadécimaux, c’est à dire de « 0 » à « 9 » et de « a » à « f » en minuscule.

Le champ HashCible

Le champ HashCible désigne l’objet destination du lien.

Le champ signataire ne contient que des caractères hexadécimaux, c’est à dire de « 0 » à « 9 » et de « a » à « f » en minuscule.

Il peut être nuls, c’est à dire représentés par la valeur « 0 » sur un seul caractère.

Le champ HashMeta

Le champ HashMeta désigne l’objet contenant une caractérisation du lien entre l’objet source et l’objet destination.

Le champ signataire ne contient que des caractères hexadécimaux, c’est à dire de « 0 » à « 9 » et de « a » à « f » en minuscule.

Il peut être nuls, c’est à dire représentés par la valeur « 0 » sur un seul caractère.

Lien simple

Le registre du lien simple a ses champs HashCible et HashMeta égaux à « 0 ».

Il ressemble à :

Signature_HashSignataire_TimeStamp_Action_HashSource_0_0

Lien double

Le registre du lien double a son champ HashMeta égal à « 0 ».

Il ressemble à :

Signature_HashSignataire_TimeStamp_Action_HashSource_HashCible_0

Lien triple

Le registre du lien triple est complètement utilisé.

Il ressemble à :

Signature_HashSignataire_TimeStamp_Action_HashSource_HashCible_HashMeta

La confiance

La confiance n’est pas quelque chose de palpable, même numériquement. Cela tient plus de la façon de concevoir les choses et le fait de faire en sorte que l’ensemble soit solide. L’ensemble doit être cohérent et résistant. On doit pouvoir compter sur ce que l’on a.

La confiance est donc sous-jacente aux objets et aux liens.

Les objets et les liens doivent tous être signés. Toute modification devient impossible si l’on prend le temps de vérifier les signatures.

En l’absence de nouvelle découverte mathématique majeure, les algorithmes cryptographiques nous permettent aujourd’hui une offuscation forte et une prise d’empreinte fiable. C’est le chiffrement et la signature.

La confiance dans l’objet

L’intégrité et la confidentialité des objets est garantie non pas par une méta-donnée mais par les mathématiques qui animent les algorithmes cryptographiques.

L’objet est référencé par une empreinte cryptographique. L’empreinte d’un objet doit être vérifiée lors de la fin de la réception de l’objet. L’empreinte d’un objet devrait être vérifiée avant chaque utilisation de cet objet. Un objet avec une empreinte qui ne lui correspond pas doit être supprimé. Lors de la suppression d’un objet, les liens de cet objet sont conservés.

La confiance dans le lien

L’intégrité des liens est garantie non pas par une méta-donnée mais par les fonctions mathématiques utilisées par les algorithmes cryptographiques.

La signature du lien est obligatoire. La signature doit être réalisée par le signataire. La signature englobe tout le lien à l’exception d’elle-même. Un lien avec une signature invalide ou non vérifiable doit être ignoré et supprimé.

Toute modification de l’un des champs entraîne l’invalidation de tout le lien.

L’empreinte du signataire est inclue dans la partie signée, ainsi il ne peut être modifier sans invalider tout le lien. On ne peut ainsi pas usurper une autre entité.

Fonctionnement

L’objet

Le lien

L’entité

Une entité est un objet contenant une clé cryptographique publique. Cette clé permet de vérifier les liens signés par cette entité.

Création d’une entité

La première étape consiste en la génération d’un bi-clé (public/privé) cryptographique. Ce bi-clé peut être de type RSA ou équivalent. Aujourd’hui, seul RSA est reconnu.

On extrait la clé publique du bi-clé. Le calcul de l’empreinte cryptographique de la clé publique donne l’identifiant de l’entité. On écrit dans les objets (o/*) l’objet avec comme contenu la clé publique et comme id son empreinte cryptographique.

On extrait la clé privée du bi-clé. Il est fortement conseillé lors de l’extraction de protéger tout de suite la clé privée avec un mot de passe. On écrit dans les objets (o/*) l’objet avec comme contenu la clé privée et comme id son empreinte cryptographique (différente de celle de la clé publique).

A partir de maintenant, le bi-clé n’est plus nécessaire. Il faut la supprimer avec un effacement sécurisé.

Pour que l’objet soit reconnu comme entité il faut créer les liens correspondants.

  • Lien 1 :
    • Signature du lien par la clé privée de la nouvelle entité ;
    • Identifiant de la clé publique ;
    • Horodatage ;
    • Lien de type l ;
    • Identifiant de la clé publique ;
    • Hash de l’algorithme de hash utilisé pour le calcul des empreintes ;
    • Hash de ‘nebule/objet/hash’.
  • Lien 2 :
    • Signature du lien par la clé privée de la nouvelle entité ;
    • Identifiant de la clé publique ;
    • Horodatage ;
    • Lien de type l ;
    • Identifiant de la clé privée ;
    • Hash de l’algorithme de hash utilisé pour le calcul des empreintes ;
    • Hash de ‘nebule/objet/hash’.
  • Lien 3 :
    • Signature du lien par la clé privée de la nouvelle entité ;
    • Identifiant de la clé publique ;
    • Horodatage ;
    • Lien de type l ;
    • Identifiant de la clé publique ;
    • Hash de ‘application/x-pem-file’.
    • Hash de ‘nebule/objet/type’.
  • Lien 4 :
    • Signature du lien par la clé privée de la nouvelle entité ;
    • Identifiant de la clé publique ;
    • Horodatage ;
    • Lien de type l ;
    • Identifiant de la clé privée ;
    • Hash de ‘application/x-pem-file’.
    • Hash de ‘nebule/objet/type’.
  • Lien 5 :
    • Signature du lien par la clé privée de la nouvelle entité ;
    • Identifiant de la clé publique ;
    • Horodatage ;
    • Lien de type f ;
    • Identifiant de la clé privée ;
    • Identifiant de la clé publique ;
    • 0.

C’est le minimum vital pour une entité. Ensuite, d’autres propriétés peuvent être ajoutées à l’entité (id clé publique) comme sont nom, son type, etc…

Si le mot de passe de la clé privée est définit par l’utilisateur demandeur de la nouvelle entité, il faut supprimer ce mot de passe avec un effacement sécurisé.

Si le mot de passe de la clé privée a été généré, donc que la nouvelle entité est esclave d’une entité maître, le mot de passe doit être stocké dans un objet chiffré pour l’entité maître. Et il faut générer un lien reliant l’objet de mot de passe à la clé privée de la nouvelle entité.

Stockage

Support

Enregistrement

Lecture

Échanges

Moyens et supports d’échange

Il est possible de télécharger des objets et des liens avec différents protocoles. Le plus simple étant le http. Le protocole et le serveur distant doivent être capable de transmettre une requête et de renvoyer en sens inverse une réponse.

Côté serveur, c’est à dire la machine qui fait office de relais des objets et liens, tout ne peut pas être demandé. Les requêtes doivent être triviales à traiter, ne pas nécessiter de forte puissance de calcul ni d’empreinte mémoire démesurée. Une avalanche de requêtes diverses ne doit pas mettre à plat le serveur.

protocole neb://

Ce protocole sera conçu ultérieurement. Tous les échanges se font actuellement via le protocole http://

L’ajout d’un nouveau protocole nécessite de le faire reconnaître par les serveurs. Un serveur web classique devrait pouvoir répondre assez facilement à ce genre de requêtes. Mais il faut aussi modifier les logiciels clients actuels, si tant est que l’on souhaite se baser sur les logiciels clients existants.

Requêtes/réponses

Comportement au téléchargement d’objets

Comportement global (téléchargement sans localisation précisée) :

  1. Si l’empreinte de l’objet demandé est 0, on quitte le processus de téléchargement.
  2. Si l’objet existe déjà dans le répertoire public des objets, on quitte le processus de téléchargement.
  3. Si l’objet existe déjà dans le répertoire privé des objets, on quitte le processus de téléchargement.
  4. Si l’objet n’a pas de lien dans le répertoire public des liens, on quitte le processus de téléchargement.
  5. Si l’objet n’a pas de lien dans le répertoire privé des liens, on quitte le processus de téléchargement.
  6. On se réfère à l’objet 0f183d69e06108ac3791eb4fe5bf38beec824db0a2d9966caffcfef5bc563355 (« nebule/objet/entite/localisation ») pour trouver la localisation de toutes les entités connues.
  7. On parcourt les différentes localisations une à une (cf comportement local) pour essayer de télécharger l’objet demandé jusqu’à en obtenir une copie valide si c’est possible.

Comportement local (téléchargement sur une localisation précise) :

  1. Si l’empreinte de l’objet demandé est 0, on quitte le processus de téléchargement.
  2. Si l’objet existe déjà dans le répertoire public des objets, on quitte le processus de téléchargement.
  3. Si l’objet existe déjà dans le répertoire privé des objets, on quitte le processus de téléchargement.
  4. Si l’objet n’a pas de lien dans le répertoire public des liens, on quitte le processus de téléchargement.
  5. Si l’objet n’a pas de lien dans le répertoire privé des liens, on quitte le processus de téléchargement.
  6. On télécharge un objet sur une localisation précise vers le répertoire public des objets.
  7. Si il est vide, on supprime l’objet.
  8. Si l’empreinte est invalide, on supprime l’objet.

Comportement au téléchargement de liens

Cryptographie sur les liens

Le chiffrement permet de dissimuler des liens. Il est optionnel.

20150627-nebule-schema-crypto-lien-c

Cryptographie sur les objets

Le chiffrement permet de cacher le contenu des objets. Il est optionnel.

Ce chiffrement doit être résistant, c’est à dire correspondre à l’état de l’art en cryptographie appliquée. On doit être en mesure de parfaitement distinguer l’objet en clair de l’objet chiffré, même si le second est dérivé du premier.

Deux étapes de chiffrement

Les entités sont des objets contenant le matériel cryptographique nécessaire au chiffrement asymétrique. Cependant, le chiffrement asymétrique est très consommateur en ressources CPU (calcul). On peut l’utiliser directement pour chiffrer les objets avec la clé publique d’un correspondant, mais cela devient rapidement catastrophique en terme de performances et donc en expérience utilisateur. D’un autre côté, le chiffrement symétrique est beaucoup plus performant, mais sa gestion des clés de chiffrement est délicate. Pour améliorer l’ensemble, il faut mixer les deux pour profiter des avantages de chacun.

Ainsi, on va aborder le chiffrement en deux étapes distinctes.

Pour la compréhension des schémas, ne pas oublier que les propriétés des objets sont elles-mêmes des objets…

Étape chiffrement symétrique

Le chiffrement d’un objet peut prendre du temps, surtout si il est volumineux. On va donc privilégier le chiffrement symétrique qui est assez rapide. Nous avons besoin pour ce chiffrement de deux valeurs.

La première valeur est une clé de chiffrement. Elle est dite clé de session. La longueur de celle-ci dépend de l’algorithme de chiffrement utilisé. Par exemple, elle fait 128bits pour l’AES. Elle est générée aléatoirement. C’est cette valeur qui va permettre le déchiffrement de l’objet et doit donc rester secrète. Mais il faut pouvoir la partager avec ses correspondants, c’est ce que l’on verra dans la deuxième étape.

La seconde valeur est ce que l’on appelle une semence ou vecteur initial (IV = Initial Vector). Elle est utilisée dans la méthode de chiffrement sur plusieurs blocs, c’est à dire lorsque l’on chiffre un objet dont la taille dépasse le bloc, quantité de données que traite l’algorithme de chiffrement. Par exemple, le bloc fait 128bits pour l’AES, tout ce qui fait plus que cette taille doit être traité en plusieurs fois. Comme IV, je propose d’utiliser l’identifiant de l’objet à chiffrer, c’est à dire le hash de cet objet. Cela simplifie la diffusion de cette valeur qui n’a pas à être dissimulée.

L’objet source que l’on voulait à l’origine protéger peut maintenant être marqué à supprimer. Il pourra être restauré depuis l’objet dérivé chiffré et la clé de session.

Sur le schéma ci-dessous, la partie chiffrement symétrique est mise en valeur. On retrouve l’objet source en clair qui est ici une image de type JPEG. En chiffrant cet objet, cela génère un nouvel objet. Le chiffrement est matérialisé par un lien de type K. Ce lien associe aussi un objet contenant la clé de session. Le nouvel objet est de type AES-CTR, par exemple. Cela signifie qu’il est chiffré avec le protocole AES et la gestion des blocs CTR (CounTeR). L’objet contenant la clé de session est de type texte.

20130209-nebule-schema-crypto-sym

Étape chiffrement asymétrique

Suite à la première étape de chiffrement, nous nous retrouvons avec un objet chiffré et un objet contenant la clé de session. Si le fichier chiffré est bien protégé (en principe) et peut donc être rendu public, l’objet avec la clé de session est au contraire bien embarrassant. C’est là qu’intervient le chiffrement asymétrique et les clés publiques/privées.

Le système de clés publiques/privées va permettre de chiffrer l’objet contenant la clé de session avec la clé publique d’une entité. Ainsi on permet à cette entité, c’est à dire le destinataire, de récupérer la clé de session avec sa clé privé et donc de lire l’objet source. Et plus encore, en re-chiffrant cette même clé de session avec d’autres clés publiques, ce qui génère autant d’objets de clés chiffrés, nous permettons à autant de nouvelles entités de lire l’objet source.

Le créateur de l’objet chiffré doit obligatoirement faire partie des entités destinataires si il souhaite pouvoir déchiffrer l’objet source plus tard. Sinon, il passe intégralement sous le contrôle d’une des entités destinataires.

Sur le schéma ci-dessous, la partie chiffrement asymétrique est mise en valeur. On retrouve l’objet en clair qui est ici la clé des session. En chiffrant cet objet, cela génère un nouvel objet. Le chiffrement est matérialisé par un lien de type K. Ce lien associe aussi un objet contenant la clé publique d’une entité. Le nouvel objet est de type RSA.

20130209-nebule-schema-crypto-asym

Ensemble du processus de chiffrement

Évidemment, ce schéma de chiffrement ne ré-invente pas la roue. C’est une façon de faire assez commune, voire un cas d’école. Mais il est ici adapté au fonctionnement particulier de nebule et de ses objets.

Il y a deux points à vérifier : – Partager l’objet chiffré et permettre à une autre entité de le voir, c’est aussi lui donner accès à la clé de session. Rien n’empêche cette entité de rediffuser ensuite cette clé de session en clair ou re-chiffrée à d’autres entités. Cependant, la clé de session est unique et n’a pas de valeur en dehors de l’objet chiffré qu’elle protège. De même, l’objet source peut toujours être re-chiffré avec une nouvelle clé de session et d’autres clés publiques. On retombe sur un problème commun, insoluble et le même constat : on perd automatiquement le contrôle de toute information que l’on diffuse à autrui. – L’empreinte (hash) de la clé de session est publique. Peut-être que cela affaiblie le chiffrement et donc la solidité de la protection des objets. A voir…

Par commodité, je pense qu’il serait intéressant de lier explicitement l’entité destinataire et l’objet chiffré.

Voici le schéma de l’ensemble :

20130209-nebule-schema-crypto

Chiffrement et vecteur initial

Pour la plupart des modes de chiffrements symétriques, un vecteur initial (semence ou IV) est nécessaire. Il est lié à l’objet chiffré pour permettre le déchiffrement de celui-ci. Par défaut, sa valeur est aléatoire.

Si pas précisé, il est égale à 0.

Du fait du fonctionnement du mode CTR (CounTeR), l’IV s’incrémente à chaque bloc chiffré.

Chiffrement et compression

Il est préférable d’associer de la compression avec le chiffrement.

La compression des données déjà chiffrées est impossible, non que l’on ne puisse le faire, mais le gain de compression sera nul. L’entropie détermine la limite théorique maximum vers laquelle un algorithme de compression sans pertes peut espérer compresser des données. Quelque soit l’entropie des données d’origine, une fois chiffrées leur entropie est maximale. Si un algorithme obtient une compression des données chiffrées, il faut sérieusement remettre en question la fiabilité de l’algorithme de chiffrement. CF Wikipedia – Entropie de Shannon.

A cause de l’entropie après chiffrement, si on veut compresser les données il est donc nécessaire de le faire avant le chiffrement.

Ensuite, il faut choisir l’algorithme de compression. On pourrait forcer par défaut cet algorithme, pour tout le monde. C’est notamment ce qui se passe pour le HTML5 avec le WebM ou le H.264… et c’est précisément ce qui pose problème. En dehors des problèmes de droits d’utilisation à s’acquitter, c’est une facilité pour l’implémentation de cette compression par défaut dans les programmes. Cela évite de devoir négocier préalablement l’algorithme de compression. Mais si il est difficile de présenter des vidéos en plusieurs formats à pré-négocier, ce n’est pas le cas de la plupart des données. On perd la capacité d’évolution que l’on a en acceptant de nouveaux algorithmes de compression. Et plus encore, on perd la capacité du choix de l’algorithme le plus adapté aux données à compresser. Il faut donc permettre l’utilisation de différents algorithmes de compression.

Cependant, si l’objet à chiffrer est déjà compressé en interne, comme le PNG ou OGG par exemple, la compression avant chiffrement est inutile. Ce serait une sur compression qui bien souvent n’apporte rien. Le chiffrement n’implique donc pas automatiquement une compression.

Lors du chiffrement, l’objet résultant chiffré est lié à l’objet source non chiffré par un lien k. Il est aussi marqué comme étant un objet de type-mime correspondant à l’algorithme de chiffrement, via un lien l. Pour marquer la compression avant chiffrement, un autre lien l est ajouté comme type-mime vers l’algorithme de compression utilisé. Ce lien n’est ajouté que dans le cas d’une compression réalisée en même temps que le chiffrement.

La seule contrainte, c’est l’obligation d’utiliser un algorithme de compression sans perte. L’objet, une fois décompressé doit être vérifiable par sa signature. Il doit donc être strictement identique, aucune modification ou perte n’est tolérée.

Chiffrement et type mime

Il n’existe pas de type mime généralistes pour des fichiers chiffrés. Comme les objets chiffrés ne sont liés à aucune application en particulier.

Il faut aussi un moyen de préciser l’algorithme de chiffrement derrière. Une application aura besoin de connaître cet algorithme pour déchiffrer le flux d’octets. En suivant la rfc2046, il reste la possibilité de créer quelque chose en application/x-...

Voici donc comment seront définis les objets chiffrés dans nebule :

  • application/x-encrypted/aes-256-ctr
  • application/x-encrypted/aes-256-cbc
  • application/x-encrypted/rsa

Etc…

En fonction de l’algorithme invoqué, on sait si c’est du chiffrement symétrique ou asymétrique, et donc en principe si c’est pour une clé de session ou pas.

Résolution de conflits

Comment se comporter face à un objet que l’on sait (lien k) chiffré dans un autre objet mais qui est disponible chez d’autres entités ? Si on est destinataire légitime de cet objet, on ne le propage pas en clair. On ne télécharge pas la version en clair. On garde la version chiffrée.

Groupes

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 ambiguë.