Archive for janvier, 2013

Le lien et la subdivision d’objet

Mercredi, janvier 30th, 2013

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

Mercredi, janvier 30th, 2013

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

Samedi, janvier 26th, 2013

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/

Protocoles (a)symétriques

Samedi, janvier 19th, 2013

Un article sur le sentiment de stagnation de l’innovation (InternetActu.net) amène un commentaire (le premier) sur la symétrie de l’Internet et de ses protocoles.

Le commentaire relève l’asymétrie des acteurs, soit les fournisseurs de services et les clients/consommateurs. Il en découle logiquement des conflits d’intérêts. Le premier se trouve entre le client piégé et le fournisseur de service résolument fermé aux autres fournisseurs de services. Le deuxième conflit est révélé par l’actualité entre Free et Google, entre le transporteur de paquets et le nœud de services.
Cette asymétrie se retrouve dans les protocoles utilisés sur le réseau des réseaux.

La solution proposée serait de déployer des protocoles symétriques. Ceux-ci existent depuis des décennies mais sont peu employés. Ils permettraient de relier directement les gens entre eux sans les intermédiaires bien encombrants que sont les nœuds de services. Et accessoirement, cela assurerait la neutralité du réseau et relancerait l’innovation pris en otage par les grosses sociétés.

Mon avis, c’est que le problème est bien réel mais cette solution me semble un peu superficielle. La façon de la mettre en avant fait un peu… commercial d’ailleurs, même si aucun produit n’est proposé derrière. Bref, comme souvent, c’est une mauvaise solution à un problème mal posé.
Oui le système des brevets est utile, mais complètement détourné de son but originel. A revoir si l’on veut relancer rapidement l’innovation par les petites sociétés. Il devait assurer la diffusion du savoir et des innovations contre des garanties. Il est aujourd’hui la base d’une guérilla juridique pour protéger coûte que coûte des positions commerciales au détriment… de l’innovation.
Oui l’Internet est asymétrique, et on n’y changera pas grand chose tant que la connexion de l’utilisateur restera… asymétrique. J’ai vu que ce problème a été abordé quelque part dans un commentaire comme étant une cause de problème. L’ADSL qui connecte une grande partie des utilisateurs est volontairement asymétrique, mais cela correspond à une optimisation liée aux usages des internautes depuis 15 ans. Ce n’est pas une cause de dissymétrie mais une conséquence. Et donc aucun changement n’est à attendre de ce côté là tant que les usages de l’Internet ne changeront pas.
Non les protocoles asymétriques ne résoudront pas le problème d’asymétrie de l’Internet. Que le protocole soit symétrique ou pas n’a pas d’importance. Bien qu’utilisant des protocoles symétriques, nous savons déjà aujourd’hui parfaitement faire dialoguer deux utilisateurs directement entre eux, le fameux Pair à Pair (P2P). Ce qui à de l’importance c’est l’usage, encore et toujours. Tant que l’on ne proposera pas à Facebook et consorts des alternatives utilisant les propriétés du P2P et potentiellement complètement acentrés, ça ne changera pas.

La translation d’adresse IP (NAT) sera, si elle ne l’est déjà, un plus grand frein à la symétrie des usages de l’Internet. Tant que plusieurs utilisateurs seront cachés derrière une seule adresse IP, ils sera difficile de leur donner un rôle autre que celui de consommateur. Le NAT sert aussi à faire de la sécurité pour les postes cachés, ou plutôt devrait-on dire que ça y contribue un peu (pas plus). Rien que pour ça, IPv6 (sans NAT) devrait être une des plus grosses priorités.

Retour au projet nebule. Celui-ci permet de répondre à l’asymétrie des usages non pas en faisant tomber les nœuds de services ou en rendant le réseau complètement symétrique, mais en redonnant au réseau sa vraie place de transporteur. La symétrie est assurée (ou pas) par les liens entres objets, indépendamment du moyen de transport.

Liens :
http://www.internetactu.net/2013/01/09/vers-une-stagnation-de-linnovation/
http://www.internetactu.net/

Chronographe

Jeudi, janvier 10th, 2013

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

A quoi cela sert-il ? – Rédigé !

Jeudi, janvier 10th, 2013

Un premier texte explicatif sur l’utilité de nebule est rédigé dans une page.

Cette page est disponible sur le blog en haut à gauche.

C’est une résolution de cette nouvelle année, rendre le projet plus lisible.
L’étape d’après sera de le rendre plus visible…
Bonne année 2013 :-)


811ba947111090b4708da62494a84e5cfc13ea60e16dac94a678f395aa42da07