Introduction à la cryptographie

Une avancée importante reste encore à faire. Elle est en théorie tout à fait réalisable et indispensable. Mais la mise en pratique doit se faire avec soin. Cette avancée, c’est le chiffrement des objets.

Ce chiffrement est optionnel. Il 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.

Ceci est une proposition de travail.

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, on mixe les deux. On essaie de profiter des avantages de chacun tout en réduisant les défauts.

Ainsi, on va aborder le chiffrement en deux étapes distinctes. Voici le schéma de l’ensemble que l’on va décomposer.

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

Continuer la lecture de Introduction à la cryptographie

Le lien et la subdivision d’objet

Un lien particulier avec pour action ‘s‘ permet de faire de la subdivision d’objet. A quoi cela sert-il ?

Il y a deux usages possibles de cette action.

Le premier usage est de permettre de scinder un objet volumineux en une multitude de morceaux, une multitude d’objet plus petits. Ces objets dérivés peuvent avoir des tailles identiques ou non. Ils doivent impérativement être non recouvrants et parcourir l’intégralité de l’objet parent.
En scindant un objet volumineux, il peut être transféré par morceaux vers différents emplacement (d’autres entités). Et donc une autre entité peut simultanément télécharger les multiples morceaux à des emplacements différents. Une fois tous les morceaux rassemblés, l’objet parent, l’original, peut être reconstitué.
C’est une des techniques nécessaires au fonctionnement du P2P par exemple.

Le deuxième usage, c’est de ne faire qu’un seul objet dérivé d’un objet parent plus grand. Cet objet dérivé fonctionne alors comme un extrait de l’objet parent. On ne peut pas reconstituer l’intégralité de l’objet parent à partir de l’objet dérivé.
Bien sûr, plusieurs extraits d’un objet peuvent être faits. Et un extrait plus petit encore peut être retiré d’un autre extrait. Rien ne limite le nombre d’objets dérivés. Rien ne garanti leur non-recouvrement ni qu’ils parcourent l’intégralité de l’objet parent.
L’usage peut par exemple être l’extrait d’une citation dans un livre, un extrait d’une musique, etc…

Actuellement, une subdivision est référencée par un objet contenant une et une seule ligne de type x-y. Mais peut-être serait-il intéressant de permettre plusieurs lignes de type x-y, cela créant un extrait contenant directement la concaténation des différents extraits d’un objet. Quel usage ?

Chronographe : 20 jours après

Le chronographe expérimental est lancé depuis maintenant 20 jours et quelques heures (CF Chronographe).
Il tourne toujours.

L’accès via le web est impossible. La page de bootstrap avait déjà été modifiée pour supporter un grand nombre de liens. La visualisation de l’entité est impossible via la page gnav.php . Il faut modifier le robot pour qu’il ne lie pas les traces de temps avec sa propre entité mais avec l’objet contenant "nebule/objet/entite/suivi".

En regardant de plus près, il faut une vingtaine de secondes pour lister tous les fichiers contenants des liens. Il y en a plus de 29000…
C’est encore exploitable, mais peut-être faudrait-il dans ce cas répartir les objets dans des sous-répertoires et alléger le système de fichiers qui n’est pas vraiment prévu pour ça. Le robot ne semble pas ralentir dans son fonctionnement malgré tout, c’est que les fichiers restent accessibles dans un temps raisonnable.

Le robot est recréé ce soir avec quelques correctifs.
kronos.nebule.org

Yubikey et la double authentification

Une des bêtes noires de la sécurité des utilisateurs et de leurs informations sur l’Internet est le mot de passe. Ou plutôt devait-on dire la multitude de mots de passes et de comptes utilisateurs qui vont avec.

Chaque service web nécessite un compte utilisateur pour être utilisé, normal. Ce qui est moins normal, c’est que cette identification reste assez strictement localisée au service en question. A part quelques tentatives qui n’ont remportée qu’un succès d’estime, chaque service gère jalousement ses utilisateurs. Il en résulte un multitude de comptes utilisateurs différents avec potentiellement autant de mots de passes.
La gestion de l’identité sur l’Internet est un vrai problème. La gestion des mots de passes associés encore plus. Même si l’on met le même mots de passe partout, il faut régulièrement le retaper. Et bien sûr, avec un mot de passe unique, on devient vulnérable au premier service qui ne sécuriserait pas correctement ceux-ci.

Yubico propose une solution basé sur le mot de passe à usage unique (OTP – One Time Password). L’ensemble fonctionne sur le principe de ‘ce que je connais‘ et ‘ce que j’ai‘. La double authentification repose donc sur deux moyens combinés de prouver son identité. On doit fournir les deux ou prouver que l’on détient les deux.

  1. Ce que je connais‘, c’est typiquement un nom d’utilisateur et un mot de passe.
  2. Ce que j’ai‘, c’est un objet dont je dispose. Cet objet doit être capable de prouver sa présence de façon numérique. C’est ici la YubiKey.
  3. Ce que je suis‘, c’est le plus dur à obtenir… puisque c’est généralement ce que l’on cherche.

La clé YubiKey branchée en USB émule un clavier et envoie un mot de passe OTP lorsque l’on appuie sur un bouton de la clé. Ce mot de passe unique est dérivé de l’identifiant de la clé, d’un numéro de séquence, d’une empreinte CRC et de divers autres champs. Le tout est converti en caractères imprimables et envoyé comme si il était tapé sur un clavier.
Ce OTP est transmis au serveur en même temps que le nom d’utilisateur et éventuellement un autre mot de passe (double authentification). Le serveur le transmet au YubiCloud pour vérification et attend une réponse positive ou négative sur la validité de l’OTP pour donner l’accès au service à l’utilisateur… ou pas.
L’OTP change à chaque fois et ne peut être rejoué. Il peut donc être divulgué une fois utilisé.
La YubiKey peut être volée, sans le compte à utiliser (ou le deuxième mot de passe) elle est inutilisable.
Si double authentification, le mot de passe peut être volé (keylogger), il n’est pas utilisable sans la YubiKey à côté.

Une des propriétés intéressante de cet implémentation, c’est que l’on peut voir l’ensemble comme la transmission de messages chiffrés (symétrique) entre la YubiKey et la YubiHSM. Toutes les clés connaissent l’unique (ou pas loin) mot de passe secret de chiffrement. On fait confiance au matériel (les clés USB) pour savoir garder le secret.

Le système est de loin préférable à la simple authentification par mot de passe. Mais il n’en présente pas moins des problèmes :

  1. Une petite polémique est apparue sur la robustesse réelle du système. Un CRC16 permet de vérifier la validé du paquet. Ce CRC est inclus dans les données chiffrées et couvre donc 128-16=112bits. En jouant des paquets au hasard, il y a 1/(2*2^16) chances que la signature du CRC16 soit cohérente avec le reste. Si l’on compte qu’il faut statistiquement parcourir la moitié des valeurs pour en trouver une bonne, cela donne une probabilité de 1/(2^16). Cependant, dans les données chiffrées, il y a aussi le champ private identity de 6 bytes=48bits. Ce champs étant vérifié comme nul ou valide par les serveurs, la probabilité remonte à 2*1/(2^(16+48)) soit 1/(2^63). Ce qui sauve les meubles c’est que l’attaque doit passer par le réseau, la solidité réelle de l’ensemble est de 2^63 et non de 2^128…
  2. Il faut la coopération active des services qui authentifient les utilisateurs. La méthode d’authentification doit être modifiée pour supporter la vérification de l’OTP en liaison avec le YubiCloud, l’infrastructure qui valide réellement l’authentification. Pour les personnes qui gèrent elles-même leurs blogs ou autres services, c’est un réel gain. Mais pour un gros acteur de l’Internet c’est plutôt une ingérence sur un sujet sensible que sont les utilisateurs et tout ce qu’ils rapportent. Cela à donc autant de chance d’être adopté que d’autres solutions par le passé comme OpenID, faible.
  3. La solution nécessite une connectivité vers l’Internet et le YubiCloud pour valider l’authentification. Impossible donc de travailler hors-ligne. Il y a 5 serveurs dans le monde, c’est déjà pas mal mais c’est aussi encore trop peu pour résister à un DDOS ciblé. Et en cas d’absence de connexion prolongée aux serveur, tous les services associés sont eux-aussi paralysés. On a un point de défaut unique.
  4. Comment va se comporter l’ensemble lorsque le compteur anti-rejeu va boucler ? La clé ne marchera plus. La taille du compteur est de 15bits=32768 utilisations (avec branchement de la clé).
  5. Volontairement, la YubiKey ne peut être mise à jour. La clé est accessible en lecture seule, ce qui empêche la diffusion de virus et réduit la surface d’attaque de celle-ci. Mais que se passera-t-il quand, inévitablement, une faille sera trouvée sur cette clé ? Poubelle.

D’autres questions restent en suspend. L’analyse rapide de la documentation sur le site web de Yubico ne permet pas d’y répondre.

  1. Clé unique de chiffrement AES entre toutes les clés YubiHSM ? Ou une clé AES par YubiHSM ? Ce système de clés secrètes interdit notamment toute concurrence avec les mêmes clés. Utiliser la cryptographie asymétrique plutôt que symétrique aurait permit bien plus de choses et relevé la sécurité à plus long terme.
  2. Et si un serveur d’authentification du YubiCloud répond toujours OK même si les OTP sont invalides ? Quelle est la robustesse de l’infrastructure du YubiCloud ? La liaison entre les API côté clients et les serveurs API Validation Servers est chiffrée avec une clé partagée. Les serveurs KSM avec leurs YubiHSM sont indépendants des API Validation Servers. Mais si la clé AES semble bien protégée dans les YubiHSM, je n’ai pas vu de mécanisme de signature de la réponse.
  3. Yubico ne semble pas aimer la cryptographie symétrique, elle n’est employée nulle part. Dans un contexte entièrement centralisé autour de quelques serveurs, la cryptographie symétrique appliquée à tous les échanges reste cependant acceptable. Mais on en revient à une critique précédente, cela renforce l’unicité du point de défaillance de ces serveurs.

Qu’en penser ?
Toute la sécurité repose sur la/les clés AES des YubiHSM, la robustesse de la clé YubiKey et sur l’implémentation du chiffrement de l’OTP. La solution semble viable à court terme. Trop de défauts la condamne malheureusement à long terme.
Bref, c’est mieux que de se reposer uniquement sur le user/password, mais il faudra l’abandonner sans regrets au premier signe de faiblesse.

Liens :
http://www.yubico.com/
http://www.wired.com/wiredenterprise/2013/01/google-password/all/
http://www.yubico.com/products/yubikey-hardware/
- http://static.yubico.com/var/uploads/pdfs/YubiKey_manual-2.0.pdf
http://www.yubico.com/wp-content/uploads/2012/10/YubiCloud-OTP-Validation-Service-v1.1.pdf
http://www.schneier.com/blog/archives/2013/01/googles_authent.html
http://gonzague.me/yubico-yubikey#axzz2IzWaf5Dr
https://bitcointalk.org/index.php?topic=85648.msg943612#msg943612
http://openid.net/

Chronographe

Une nouvelle entité vient d’être mise en ligne : kronos

C’est un chronographe, il mesure le temps.
Et il le signe !

Toutes les minutes, l’objet 09531c684ca8804f671250db6d20403745f3e9c156eb1fad80945b9a4030105a est mis à jour avec en dernier la trace du temps.
Cet objet s’appelle ‘nebule/objet/entite/suivi/m00‘, la minute 0 du temps passé.
Le temps a dans nebule un écoulement linéaire et exponentiel. Il est linéaire pour des périodes de temps du même ordre de grandeur. Il est exponentiel lorsque l’on change d’ordre de grandeur.

Il y a encore quelques erreurs résiduelles dans les objets générés parce que le moteur de nebule et en cours de ré-écriture complète… et que c’est actuellement un peu buggé…
Mais l’idée est là et surtout : ça marche :-)

nebule et la donnée massive

Juste un petit article en écho à celui sur le RDF. C’est surtout le moyen d’introduire sur le blog les catégories :

Ceux-ci sont inclus dans la catégorie des réflexions.

Ainsi le blog de nebule peut commencer à être référencé sur ces mots clés, notamment.

Liaison secrète – suite

La réflexion sur la possibilité d’insérer des liens dans des objets (cf Liaison secrète) pose quand même un problème.

Comment vont être utilisés dans la vraie vie les liens insérés dans l’objet ?

Il faut en effet voir comment vont être pris en compte ces liens. Seront-ils ajoutés par certaines entités aux liens des objets concernés ? Ce qui du coup leur fait perdre leur caractère confidentiel, et donc l’intérêt du chiffrement de l’objet contenant ces liens. Et si ils ne sont pas ajoutés au reste des liens des objets concernés, comment vont faire ces entités pour exploiter ces liens ?

Deux réponses sont possibles.

La première est de déchiffrer l’objet pour extraire les liens et les stocker temporairement dans un emplacement strictement privé… et faire en sorte de les traiter en même temps que les liens naturellement attachés aux objets, c’est à dire aux liens publics. Cela nécessite à chaque déverrouillage d’une entité que celle-ci déchiffre tous ces objets pour en récupérer les liens, et de les supprimer systématiquement à chaque verrouillage. C’est facile et réalisable avec peu d’objets de ce type. Mais seront-ils si peu nombreux ? C’est loin d’être évident. Donc ce n’est pas une solution.

L’autre solution est de permettre d’insérer dans les liens un nouveau lien qui ferait référence à un autre objet comme contenant des liens. Cet objet peut ensuite être reconnu comme contenant des liens et être exploité en même temps que les liens normaux, c’est à dire non chiffrés. cette solution semble plus réaliste et viable que la première. Cependant, elle nécessite la mise en place d’un mécanisme pour les traiter spécifiquement.

Ne faut-il pas créer un nouveau type de lien dédié à ce problème ?
En l’état, le problème peut être résolu plus tard sans remettre en cause toute l’architecture des liens de nebule.

Liaison secrète

Jusque là, je considère toujours les liens comme des informations si ce n’est publique, au moins sans grand besoin de protection rapprochée.

Les informations confidentielles, les données que l’on souhaite protéger, sont dans des objets chiffrés.

N’est-ce pas une erreur fondamentale?

Aujourd’hui, une tendance forte est en train de s’imposer, le big data.

Ce terme regroupe les données caractérisées par les 4 V :
– Volume
: les données saturent les espaces de stockage classiques et nécessitent (ou imposent) un stockage répartit sur le réseau.
– Variété
: les données sont de nature hétérogènes et de sources différentes.
– Vélocité
: les données doivent être traitables (capture/stockage/analyse/partage) avant de devenir obsolètes.
– Variabilité
: l’interprétation des données est variable en fonction du traitement demandé et en fonction du temps.

Par abus de langage (commercial), ce terme est souvent utilisé pour désigner l’exploitation des traces des utilisateurs (clients) de services web pour déterminer leur profil et leur proposer des produits ou des publicités ciblés. Ce n’est en fait qu’une utilisation des big data, mais loin d’être la seule. On peut considérer que nebule est une méthode de gestion de big data notamment.

Ce qu’il faut retenir ici, c’est que les données sont des cibles pour les commerciaux, mais aussi et surtout les liens entre ces données. Et ces mêmes liens et données peuvent intéresser de la même façon des états ou le grand banditisme, le terrorisme, le lobbing, etc…

D’un autre côté, il ne faut pas trop fantasmer non plus sur les gains générés. Une société ne doublera pas son chiffre d’affaire juste en se penchant sur ses bases clients.

Jusque où la non protection des liens peut être préjudiciable?
Je n’ai pas de réponse définitive aujourd’hui.

Il peut être apporté plusieurs réponses.

La première réponse est de décréter que les liens sont publics et à considérer comme tel. Et donc de prendre ses dispositions si cela peut poser problème. C’est un peu extrêmement laxiste.

L’autre extrême, c’est de considérer par défaut les liens comme confidentiels, et donc de les chiffrer. Cela entraîne directement une forte augmentation de la puissance de calcul nécessaire à la manipulation de ces liens. De plus, cela limite grandement les possibilités de diffusion ou rediffusion de ces liens, ce qui est le but à atteindre.

Cette deuxième réponse me paraît un peu schizophrène. Elle perturbe par défaut les échanges entre entités. Il me semble que toute communication vers l’extérieur d’une entité implique implicitement une prise de risque. Ce risque doit être mesuré et assumé.

Une troisième réponse est possible entre ces deux extrêmes. Il est possible de commencer par restreindre par défaut la consultation des objets et liens associés aux seules entités que l’on connaît, que l’on a validé. C’est faisable lors des requêtes en imposant une signature de l’entité demandeuse sur sa requête, et en implémentant un mécanisme anti-rejeux des requêtes. Ainsi les objets chiffrés ne sont déchiffrables que par les entités disposant de la clé, et les liens ne sont visibles que des entités que l’on connaît. Il faut accepter qu’une entité que l’on connaît diffuse nos liens à d’autres entités y compris des entités que l’on a pas validé.

Et pour les liens à cacher à tout prix, on peut les placer dans un objet dédié, objet que l’on chiffrera dans la foulé. Pour cela, un type d’objet est créé : nebule/objet/liens

Liens :
http://fr.wikipedia.org/wiki/Big_data
Big data et concept des 4 V

Evenement unique multiple

Je fais une erreur depuis quelques temps dans les scripts. Le concept de base est bon mais l’implémentation est mauvaise.

En effet, lors de l’ajout d’un lien à un objet, si celui-ci existe déjà, il n’est pas ajouté. C’est un doublon.

Mais j’implémentais la vérification d’unicité du lien sur les champs Action, HashSource, HashDestination et HashMeta. Ce qui signifie que tout lien précédent disposant de ces quatre champs invalide le nouveau lien. Pourtant ce n’est pas tout à fait le même, même si il lie exactement les mêmes objets dans le même ordre et avec la même action. Ce lien peut être fait par une autre entité, rien de grave, quoique ça dépend du sens. Mais il peut être aussi généré avec une autre date, ce qui à une signification particulière = c’est le même lien volontairement refait plus tard…

L’exemple qui permet simplement de valider cette réflexion sur la multiplicité de ces liens, c’est la possible désactivation de lien.
Soit un lien L. Il peut y avoir un lien intermédiaire X (de type x) dans le temps qui invalide la première instance du lien L. Et on peut recevoir un deuxième lien L’ identique dans l’action demandé sur les même objets, et ce sans forcément avoir reçu le lien intermédiaire X de désactivation. Si l’on ne tient pas compte de la date, cela entraîne une désactivation du lien L’ à posteriori alors qu’il avait été volontairement refait après…

Une autre raison, si on se place sur un comportement plus sociale, on peut avoir répondu plusieurs fois la même chose à quelqu’un… mais à des moments différents.

Protocole d’échange HTTP

Tous les objets et liens sont échangeables via différents protocoles sous-jacent connus, en attendant un protocole en propre. Ces échanges peuvent utiliser par exemple la messagerie SMTP, XMPP, mais aussi le HTTP. C’est sur ce dernier que l’on va commencer.

Celui-ci nécessite un serveur web classique et un peu de programmation côté serveur.

Nous devons pouvoir permettre le téléchargement d’objets et de liens par n’importe quel utilisateur partout dans le monde. Les objets sont référencés naturellement par leurs empreintes. Il en est de même pour les liens d’un objets, c’est juste la façon de les traiter qui différera côté client.

Une première difficulté, c’est de restreindre simplement le téléchargement libre de la plupart des objets et des liens. Sauf si c’est une entité volontairement publique, seule une partie des objets et des liens sont relayés à tout le monde alors que la plupart ne le seront qu’avec les entités connues. Contrairement au chiffrement, ce verrouillage ne doit pas être considéré comme une sécurité pour gérer la confidentialité des données. Cela doit être vu comme une façon de réguler les échanges entre entités.

Le tag d’objet nebule/objet/public est créé pour désigner les objets accessibles sans identification. Pour les autres objets, cette identification préalable est obligatoire. La seule exception, c’est si c’est une entité volontairement publique comme un annuaire.

Comme l’échange d’objet peut potentiellement se faire sans échange (par exemple en SMTP), elle doit pouvoir être envoyée lors de la requête HTTP. Elle doit prouver l’identité du demandeur de façon forte et interdire le rejeu. Elle ne doit pas solliciter l’utilisation de la clé privé de l’entité serveur. Un relais d’objet ainsi tenir compte du tag pour gérer les objets qu’il héberge sans en être la source.

Les requêtes doivent pouvoir passer par un flux en clair, c’est à dire non encapsulé dans du TLS.

Une requête doit contenir :
– entité destination
– type demandé, objet ou liens
– empreinte objet
– entité demandeuse
– signature

Par exemple : http://localisation.net/?o=HashObjet&s=HashEntitéDemandeuse-HashEntitéDestination-Signature

C’est un début de réflexion…
A compléter…

Fragmentation d’objets

Un des processus pas forcément nécessaire mais assez important avec le P2P, c’est le sous-découpage des fichiers.

Un serveur diffuse des petits morceaux de fichiers bien référencés mais sans nécessairement avoir tous les fragments. Un client télécharge des fragments différents. Chaque fragments en cours de téléchargement le sont à partir d’autant de serveurs différents. Cela permet d’accumuler progressivement tous les fragments d’un fichier pour le reconstituer à la fin. Et cela permet aussi de télécharger un fichier plus rapidement que si il était téléchargé sur un seul serveur dont la bande passant en upload est bridée.

La fragmentation est déjà possible avec le système de liens actuels de nebule. Mais la gestion de cette fragmentation pourrait être améliorée si on créait un lien spécifique pour désigner les fragments d’un objet. Ce serait le septième type de liens. L’échange des objets dans nebule s’en trouverait amélioré.

L’idée est intéressante, à voir…

Horodatage ISO 8601

L’un des problèmes actuels avec les liens, c’est que le caractère tiret « – » est utilisé comme séparateur. Hors, il est aussi utilisé par le format d’horodatage universel tel que définit dans la norme ISO 8601. Celle-ci utilise aussi le caractère spécial deux-points « : ».

Il faut donc modifier le séparateur de champs du registre des liens. Le protocole des liens nebule passe en version v1.1 avec un nouveau séparateur de champs.

Toutes les expérimentations en cours vont progressivement migrer…

RDF

Fort des premières réflexions et expériences, il est maintenant possible pour moi de regarder ce qui se fait déjà. On trouve sur Wikipedia des articles intéressants sur le web sémantique, le Web 3.0, les métadonnées, le web des données et l’Internet des objets.

L’ensemble est chapeauté par le web sémantique et sa pile (Semantic Web Stack). On parle aussi de Web 3.0 bien que ce terme semble être un terme commercial fourre-tout comme le fut le Web 2.0.

Le point centrale semble être le Resource Description Framework (RDF). Ce n’est pas un format de données ou protocole d’échange, mais plutôt un guide de fonctionnement des relations entre différentes URI. Différents protocoles se chargent de décrire les implémentations pratiques. Le XML via RDF/XML est un format d’échange de ces relations, tout comme N3, Turtle, RDFa ou FOAF. Le XML et l’URI sont marqués comme des références, c’est l’héritage du W3C.

Semantic Web Stack
Semantic Web Stack, la pile du web sémantique (source Wikipedia)

Tout ça c’est bien beau, avec plein de schémas, de liens entre les articles, de termes pompeux, d’explications vagues… mais à quoi ça sert?
Ah rien en fait! Non, quand même pas :-)
On trouve surtout des informations plus intéressantes et intelligibles sur les sites de référence des différents protocoles.

Continuer la lecture de RDF

Empilement de liens

Dans les expériences nebule menées jusque là, les liens ont toujours été attachés aux objets concernés. Et dans une arborescence n’était pris en compte que les liens générés par l’entité maître de cette arborescence. Ainsi les liens générés par une autre entité se sont retrouvés dans une sous arborescence rattachée à cette autre entité. Une arborescence globale découle de l’entité maître et de toutes les entités qu’elle connaît.

De cette façon de procéder résulte une organisation très propre des entités, objets et liens. Cependant, celle-ci n’est pas optimale.

Ainsi, les objets peuvent se retrouver stocké à plusieurs endroits différents de l’arborescence globale. Les liens symboliques sous UNIX/Linux résolvent en pratique ce problème et permettent de ne garder qu’un seul point de stockage par objet, mais ce n’est pas très sexy intellectuellement parlant.

De même, des liens concernant mon entité propre par exemple sont stockés dans l’arborescence de mon entité. Mais il en existe aussi dans une sous arborescence d’une autre entité qui dispose d’une copie de mon entité et a fait ses propres liens sur moi…

Comme le stockage des objets le suggère, il paraît plus opportun de ne créer qu’une seule arborescence très limitée en profondeur. Tout se retrouve au même niveau. Cela résout la dispersion des objets et rassemble près de l’objet tous les liens de toutes les entités que l’on connaît.

Si je souhaite voir tous les liens d’un objet, et donc aussi tout ce que les autres entités en ont fait, la lecture est plus rapide.

Si je souhaite ne voir que mes liens, je filtre sur le champs signataire des liens. Ça ne pose pas de problème.

A quelle entité appartient l’arborescence? Le problème existait déjà, il faut maintenir une valeur particulière désignant sans ambiguïté l’entité maître. Ce peut être un fichier ou une réponse type à une requête standardisée. Cette valeur doit être consultable par tout le monde, elle permet l’initialisation d’un échange plus sécurisé, plus intime, entre serveurs.

Cela introduit cependant une petite différence pour les entités non-maîtres. Elles apparaissaient avant avec une URL pointant dans une sous arborescence de l’URL de l’entité maître. Elles apparaissent maintenant au même niveau. Ainsi, toute entité que l’entité maître connaît peuvent utiliser l’URL de l’entité maître comme nouvelle localisation et améliorer la diffusion de ses propres liens sur le mode P2P.

Identification/authentification sur l’internet des objets

Un interview de R.Haladjian revient sur l’Internet des objets.

L’internet des objets, c’est en gros la capacité d’interagir à distance avec des objets de notre environnement, et à ces objets de communiquer sur le réseau de façon autonome.

Une des remarques concerne la connectivité en IPv6. Ils sont revenus à IPv4 parce que « par exemple une prise électrique disposait d’un serveur et n’importe qui ayant obtenu l’adresse de cette prise électrique pouvait la pinger pour l’allumer et l’éteindre à distance. Il fallait donc mettre un pare-feu pour empêcher l’accès… Donc finalement il est plus intéressant de rester en IPV4 avec un DHCP qui distribue des adresses« .
Il est étonnant que l’on revienne à une solution dont on sait pertinemment qu’elle ne supportera pas la mise à l’échelle (de l’internet, et donc du monde) des objets connectés sur le réseau (internet). On se contente d’une vision de ces objets à courte distance, en gros de l’ordre de grandeur de la maison.
Ce recul est je pense une mauvaise réponse à un problème mal posé. Le problème concerne l’identification de qui peut dans l’exemple allumer/éteindre la lampe. Si il n’y a pas d’identification, c’est normal que tout le monde puisse le faire, une adresse IP n’est pas à considérer comme un secret même en IPv6. Mais mettre en place une identification/authentification forte sur les méthodes actuelles est fastidieux pour un grand nombre d’objets. Le problème est d’ailleurs déjà un problème commun sur les ordinateurs résidentiels. Donc parce que l’on ne sait pas mettre en place une identification correcte, on bride l’ensemble du système.
Je n’ai pas regardé comment est faite l’identification/authentification sur leurs objets. Mais cette remarque m’incite à penser qu’elle n’est pas innovante, et donc pas à la hauteur. Et, en regardant du côté de nebule, le problème semble du coup beaucoup plus facile à résoudre…

Il y a un autre aspect de l’internet des objets, c’est la gestion des objets physiques inertes d’un point de vue numérique. Ils sont reconnus par un identifiant unique, mais ils n’interagissent pas. C’est l’exemple du code barre sur les articles à vendre d’un magasin, ou la puce RFID qui les remplacera, ou la plaque d’immatriculation d’une voiture. La vision primaire de l’internet des objets avec des étiquettes collées partout me semble ubuesque : le monde deviendrait une poubelle recouverte d’étiquettes en tout genre que plus personne ne regarderait…
Pour nebule, ces identifiants numériques, quel qu’en soit leur forme ou norme, sont encodés dans des objets avant de pouvoir être liés et donc gérés. On peut même penser qu’ils seront attaché virtuellement à des positions géographiques.

Liens :
http://mobile.clubic.com/technologies-d-avenir/actualite-528965-leweb-12-haladjian-pere-nabaztag-internet-objets.html
http://fr.wikipedia.org/wiki/Internet_des_objets
http://fr.wikipedia.org/wiki/Web_3.0

L’internet des objets et les objets de l’internet

Les objets physiques qui peuplent notre environnement habituel ont une caractéristique particulière, ils sont uniques. On peut certes faire une copie, voire reproduire un objet en plusieurs millions d’exemplaires, chaque objet restera unique avec sa matière propre et ses défauts propres. Chaque objet peut être ainsi assemblé, remodelé ou refondu dans un autre objet, cela n’a aucun impact sur ses congénères.

Et les objets du monde numérique?
Ceux-ci ont l’équivalent d’une forme propre comme un objet physique. On peut distinguer un objet numérique d’un autre par cette forme que l’on appellera plutôt empreinte, mais aussi par sa localisation. La localisation est souvent représenté par un identifiant dans une arborescence ou sur un réseau, c’est un classement humanisé et peu fiable. Ainsi cette dualité de l’objet dans l’espace numérique a une conséquence importante immédiate, le même objet exactement peut exister simultanément en plusieurs endroits. Il faut donc considérer que chaque emplacement de l’objet reçoit une copie exacte de l’objet, c’est à dire sans altération, sinon cela devient un autre objet.

Continuer la lecture de L’internet des objets et les objets de l’internet

Messagerie et réseautage social – Suite

– Draft –

L’article précédemment posté sur la messagerie et réseautage social terminait sur un problème à première vue dans nebule pour permettre de distinguer le message vers plusieurs utilisateurs et le message du réseau social limité à ses amis.

Reseautage

Economie de l’attention

Offuscation des liens

Connexion anonyme ou identifiée?

gestion de l’identité, clé de session, clé d’échange près partagée par entités.

 

Corruption d’objet

On peut imaginer que les objets que l’on télécharge sont corrompus sur le serveur distant ou qu’ils sont corrompus lors du transfert.

Il faut systématiquement vérifier en fin de téléchargement que l’empreinte correspond bien à l’objet téléchargé, ça tombe bien c’est justement la façon dont il est référencé dans nebule.

Si l’objet est corrompu, on le supprime. Il sera re-téléchargé une prochaine fois.

On peut imaginer faire lier l’objet corrompu à un nÅ“ud dédié pour ces objets invalides. Ainsi un robot refait régulièrement les téléchargements de ces objets jusqu’à la réussite… ou l’échec définitif. Une fois correctement téléchargé et vérifié, le lien de cet objet peut être simplement marqué comme supprimé. Et tout rentre dans l’ordre :-)

Je pense donc je suis

La création d’un objet, et par extension d’une entité, est un peu chaotique actuellement. L’attribut type-mime est calculé le premier, puis le lien vers la clé privée, puis la localisation, puis la date et l’heure, et enfin l’algorithme cryptographique utilisé.

Pourtant, il y a un ordre établit naturel :
– objet
– entité (objet particulier qui peut signer)
– utilisateur (entité qui permet à un humain d’interagir, IHM)
– relais (entité qui relaie des informations sur des entités)

Il serait donc souhaitable de donner cet ordre pour les premiers liens d’une entité :
1) algorithme cryptographique de hash = c’est un objet
2) calcul du type mime, clé publique = c’est une entité
3) lien vers clé privée
4) localisation = voila où on peut trouver l’entité
5) etc…

Et il faut ajouter une marque de la version du protocole utilisé avant les liens. Actuellement, c’est nebule en version 1.0 .