Auteur/autrice : webmaster

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

Fin de l’expérience 4

L’expérience 4 est terminé. L’expérience 3 est encore en cours.

Conclusions de l’expérience :

L’entité du robot à été capable de retrouver un emplacement des objets de son entité maître, de synchroniser les liens et de télécharger les objets que l’entité maître lui avait attribué (liens).

L’entité maître ayant ajouté comme localisation le nouvel emplacement généré par le robot, on obtient donc bien un relais.

De plus, s’agissant d’objets en double sur plusieurs emplacement, nous obtenons la base du fonctionnement du P2P, c’est à dire répartition des données à télécharger sur plusieurs serveurs. Il restera cependant à ajouter une fragmentation d’objets pour véritablement permettre le téléchargement d’un objet simultanément sur plusieurs serveurs.

Continuer la lecture de Fin de l’expérience 4

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 .

nous = toi + moi

Ce matin, en me connectant à Facebook sur l’ordinateur commun à nous, je me suis fait la réflexion que certaines choses étaient faites bizarrement. Je suis sur ma session Linux à moi mais dans Firefox, c’est toi Diana qui est connectée à FB…
L’ordinateur est multi-session, mais on ne voit simultanément qu’une seule session, soit moi soit toi. Si tu veux ouvrir ton Firefox avec ta connexion FB, tu dois ouvrir une autre session de l’ordinateur. Le problème est que l’on ne peut pas ouvrir facilement deux navigateur pour deux utilisateurs différents dans la même session, une session à nous.

Continuer la lecture de nous = toi + moi

Tuer l’ordinateur pour le sauver

Un article fort intéressant du New York Times, une biographie du Dr. Peter G. Neumann ainsi que sa vision de la refonte de l’ordinateur et de son environnement.

Voici ma réinterprétation de l’article. Je le trouve très fouillis dans sa forme d’origine. Mais il y a du bon, et même du très bon à retenir.

Mr Neumann fait de la recherche pour le DARPA (USA) sur différents domaines comme la sécurité, cryptographie appliquée, survivabilité des systèmes, fiabilité, tolérance aux erreurs, sûreté, méthodes d’ingénierie logicielle, système dans l’ensemble, application des méthodes formelles, et réduction des risques.

L’article part sur une note d’histoire avec cet accumulation de complexité au cours du temps dans tous les systèmes. Pourtant, les réseaux et systèmes actuels n’ont pas fondamentalement évolués depuis 45 ans. Cette complexité et les failles qui en découlent ne dépendent pas uniquement de la complexité des systèmes, mais aussi de la complexité de leurs interactions. Cela a pour conséquence directe un début d’épidémie de logiciels malveillants et une prise de conscience globale de la cyber-menace. Avec nos systèmes actuels, nous en sommes à boucher les trous de la digue avec nos doigts… pour découvrir qu’au fur et à mesure de nouveaux trous apparaissent.

Continuer la lecture de Tuer l’ordinateur pour le sauver

Compressibilité des liens

Les expériences autour de nebule se font aujourd’hui via des échanges en html. Il pourront se faire plus tard via tout protocole d’échange. indépendamment du stockage des liens, il sera utile de les compresser lors de leur transmission pour gagner de la bande passante réseau. Continuer la lecture de Compressibilité des liens

Autorité temporaire

Quels incidents peut-on rencontrer sur un système d’information reposant sur une cryptographie moderne ?
Et comment peut-on y répondre ?

La cryptographie est un formidable outil mathématique. Ses propriétés sont sans équivalents dans le monde réel et palpable du commun des mortels. A cause de cela, l’outil et ses usages restent abstraits et méconnus pour beaucoup de gens. Mais, loin d’être anecdotique, la cryptographie est présente partout autour de nous, dans tout ce qui est numérique. Et il ne suffit pas d’un bon discours commercial à grand renfort de sigles abstraits suivis de quelques chiffres pour que l’ensemble remplisse son rôle : sécuriser nos données.
On se connecte à un ordinateur, le mot de passe est transformé en hash. On se connecte au site web de la banque, la connexion est sécurisée. On envoie des emails chiffrés et signés. Notre ordinateur vérifie la signature des mises à jours qu’il doit appliquer, idem pour notre box internet. Notre téléphone cellulaire chiffre la conversation avec le réseau opérateur, mais pas avec notre correspondant. La puce de notre carte bancaire valide une transaction chez notre marchant de légumes. Notre réseau wifi est protégé par mot de passe. etc…

Mais au fait, n’y a-t-il vraiment que les données à sécuriser ?
L’utilisateur est au centre de ces données, celles-ci n’ont d’utilité que pour l’utilisateur légitime et pour celui qui pourrait trouver un bénéfice à les exploiter à la place de l’utilisateur légitime.

Continuer la lecture de Autorité temporaire

Avant que nous n’en ayons connaissance

Une étude empirique intéressante de Leyla Bilge et Tudor Dumitras (de chez Symantec) sur les attaques de type zero-day : Before we knew it.

Par rapport à nebule, on peut noter une similitude dans la méthode d’identification des objets. Chaque objet de l’étude est un fichier référencé par une empreinte MD5 et une empreinte SHA2. Si le contenu des fichiers n’est pas conservé, la base de données conserve avec les empreintes le type de fichier, le lien de téléchargement et la date de téléchargement. Un des problème est qu’il n’est pris en compte que les fichiers exécutables Windows, exit donc les exécutables UNIX, les fichiers PDF ou multimédia piégés. Chaque hash de fichier peut apparaître comme téléchargé plusieurs fois à des dates différentes et sur des sites web différents. Et enfin les attaques zero day sont détectées à posteriori de façon plus fiable lorsque un fichier particulier est publiquement reconnu comme néfaste, avec un historique de son exploitation, que des sites sources, mais aussi potentiellement des clients impactés.

On est proche de la réflexion sur l’anti-virus dans nebule. L’une des possibilité pour la ré-utilisation de ces empreintes est de pouvoir marquer certains objets comme néfastes sans avoir à les re-scanner sur chaque station qui les voit passer…

Mais ne rêvons pas, cela ne sera pas suffisant pour supprimer les attaques zero day.

Continuer la lecture de Avant que nous n’en ayons connaissance

Messagerie et réseautage social

Dans la vraie vie, on distingue la messagerie et les flux du réseau social.

A la base, le fonctionnement est similaire. On diffuse un message à un ou plusieurs correspondants, et ceux-ci peuvent répondre à ce message. Il y a cependant quelques différences.

Continuer la lecture de Messagerie et réseautage social