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

Tracé de graphes objets/liens, mise en pratique 5

Le côté tri-polaire des liens est difficile à mettre en évidence. Voici ce que cela peut aussi donner :

Quelque chose d’important cependant. C’est certes l’objet a6b4edb371e864e4d17754188166f981f9a9a78e11273c7d8c87b4363c20af9d, mais surtout le graph correspond à l’objet vu par l’entité 975571a8a470a6d975662e284f5ef1bd0396c06b31a2207b81bef2e24c5bf0c5. Désormais, on ne peut plus parler d’un objet sans faire référence au moins implicitement à une entité puisque chaque entité aura sa propre représentation de cet objet.

Gestion de programmes

Lors des expériences, il est apparut qu’il était assez facile de diffuser des programmes, dans notre cas des pages web en php, comme des objets à part entière.

Il faut deux choses.

La première c’est qu’il faut une page web de bootstrap (marche pied). C’est cette page qui va déterminer si il existe une page à afficher dans les objets, et la lancer. La page en question doit être un dérivé (lien F) de l’objet « nebule/objet/entite/webaccess/firstofall », et être de mime-type « application/x-php ».

Et il faut que le programme en question puisse se mettre à jour. Ce peut être fait en suivant les liens de mise à jour d’objet (lien U) du programme en question. On peut aussi suivre les nouveaux liens de l’objet « nebule/objet/entite/webaccess/firstofall » d’une autre entité. Ne reste plus qu’à téléchager le nouvel objet et mettre à jour sont propre objet « nebule/objet/entite/webaccess/firstofall ».

Continuer la lecture de Gestion de programmes

Nommage des objets avec tag de hashage

Suite à l’article sur le Marquage du hashage qui faisait déjà référence à l’article sur les Collisions d’empreintes multi-algorithmique, la conclusion est qu’il faut marquer les empreintes des objets avec la fonction de hashage.

Cependant, cela ne va pas dans le bon sens. On ajoute de l’information là où elle n’est pas directement utile.

Pour la signature d’un lien (le premier champ du lien), il est préférable de pouvoir immédiatement disposer de la référence à l’algorithme de hashage. Celui-ci est utilisé en même temps que le lien, et surtout pour le vérifier.

Pour un objet, sa signature a de très très très faibles chances d’être commune à celle d’un autre objet avec la même fonction de hashage. On peut considérer la collision comme impossible en pratique. Il en est de même vis à vis d’une autre fonction de hashage, sauf si cette dernière est cryptographiquement faible. Exit les fonctions de hashage faibles tel MD5 et compagnie. D’un point de vue sécurité, il n’y a donc pas lieu de marquer l’objet avec la fonction de hashage.

Mais le besoin pour les gros fichiers reste entier. Ce marquage de l’objet peut être tout simplement un lien vers le nom de la fonction de hashage. Ce lien sera utilisé au besoin lors de la vérification de l’objet source.

L’objet meta correspondant au lien est « hash function« . Ce lien doit être présent.

Marquage du hashage

Se posait la question des collisions d’empreintes multi-algorithmique. Cette question a deux réponses.

La première, c’est que le calcul nécessaire à la recherche d’empreintes nécessite d’être refait pour chaque algorithme. On ne retire pas de la complexité puisque le calcul fait par un algorithme n’est pas réutilisable pour un autre. C’est, si je ne me trompe pas, la notion (mathématique) de groupe des algorithmes qui le garantie. La robustesse de l’ensemble est donc équivalente à celle de l’algorithme le plus fragile.

La deuxième réponse concerne le calcul et re-calcul des empreintes pour les très gros objets. Aujourd’hui, un objet correspond souvent à un fichier tel qu’on l’utilise sur différents supports ou via différents moyens de diffusions. A l’avenir, il est fortement probable qu’un fichier soit représenté par plusieurs objets dont chacun aura un rôle précis et très épuré, et donc plus petit. Ainsi un objet peut être très volumineux et donc nécessité un gros effort de calcul de son empreinte. Le faire une fois, la première fois, déjà c’est long. Le refaire régulièrement pour vérifier qu’il n’est pas endommagé va encore augmenter l’effort. Si en plus on ajoute qu’il faut refaire ce calcul pour plusieurs algorithmes différents, et donc relire plusieurs fois l’objet volumineux…

Donc, il faut ajouter l’algorithme de hashage utilisé devant chaque empreintes. Et il faut mettre à jour tous les programmes pour qu’ils en tiennent compte.

SHA256?

Quelle est la solidité de l’algorithme de hash SHA256?

Le site www.ecrypt.eu.org (ECRYPT II) diffuse un document D.SPA.17.pdf (sans licence apparente) récapitulant les propriétés d’algorithmes cryptographiques et de pratiques. Ce document récapitule les travaux sur ces algorithmes et méthodes, et évalue la solidité de ceux-ci.

Le site www.keylength.com référence les recommandations de différents organismes gouvernementaux et notamment celles de l’ANSSI. Les recommandations de l’ANSSI sont disponibles dans le document RGS_B_1.pdf.

Conclusion, SHA256 est adapté à l’utilisation que l’on en fait aujourd’hui dans nebule.

Continuer la lecture de SHA256?

Premier lien entre deux entités

Pour les besoins de l’expérience 4, les deux entités suivantes ont été liées :
– 975571a8a470a6d975662e284f5ef1bd0396c06b31a2207b81bef2e24c5bf0c5
– bca2c25e6564af173a65bf88b8bb1f91cb9c4f5e9ddaf96b8775206543be56c8

La première entité est gérée par un humain, la seconde par un robot. Ce robot à besoin de savoir à quel endroit il peut télécharger les objets et liens de l’autre entité.

Continuer la lecture de Premier lien entre deux entités

NÅ“uds

Le nÅ“ud est la rencontre de plusieurs chemins convergents/divergents. Cette rencontre est matérialisé par une liaison forte entre ces différents chemins.

La nébuleuse des objets a besoin d’une architecture locale avec des points de convergence forts. Ce sont des nÅ“uds. Ils permettent d’architecturer, d’organiser les liens entres objets, et donc de canaliser les partages d’informations.

Implémentation de liens sécurisés

Une première implémentation en shell bash a été réalisée pour la lecture et l’écriture de lien sécurisés.

Ces liens sont dits sécurisés parce qu’ils sont signés par une entité, et donc leur intégrité et leur provenance peuvent être vérifiés. Si la signature est invalide, ils sont simplement ignorés.

Voir l’implémentation de référence en bash.

Exemple de résultats (empreintes tronquées à 16 caractères) :
sha256:03e7785a6-975571a8a470a6d9-20120914182239-L-975571a8a470a6d9-970bdb5df1e79592-93d4a5f3ef1fc5c8
sha256:2ec7df2b9-975571a8a470a6d9-20120914182239-L-975571a8a470a6d9-7c512aaa1c5e3837-a6b4edb371e864e4
sha256:86d8d0f2f-975571a8a470a6d9-20120914182240-F-6a4b7f1100b87044-975571a8a470a6d9
sha256:2c7911d50-975571a8a470a6d9-20120914182240-L-975571a8a470a6d9-37d22e047bd0173f-703c4a9a2573f76a
sha256:90952b31d-975571a8a470a6d9-20120914182241-L-975571a8a470a6d9-69eb5187e4469dfd-93d4a5f3ef1fc5c8
sha256:3ed5b8f4c-975571a8a470a6d9-20120914182242-L-975571a8a470a6d9-6bf6ae23819cd0d1-0e87632cd46bd490
sha256:0626480c2-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-4b9a7f50c0bb198c-911f9ec89c20f340
sha256:51b955e0b-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-3514acf61732f662-5ef523ac47dae4aa
sha256:01bcc6d09-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-8527a891e2241369-b5977b836b445eaf
sha256:58a62c5ab-975571a8a470a6d9-20120914182243-L-975571a8a470a6d9-4ec9599fc203d176-dc80905e9df6dac2
sha256:bf51f9067-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-785f3ec7eb32f30b-28cdd20eaf134a05
sha256:553af0cc7-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-aea92132c4cbeb26-9d64d711a2a1123e
sha256:162bfc0c5-975571a8a470a6d9-20120914182244-L-975571a8a470a6d9-caa1aedb2a6ce96b-c0f059214d078968

OpenSSL plutôt que GPG!

Suite aux problèmes pour exploiter gpg2, et après quelques essais avec openssl, décision est prise de basculer vers ce dernier.

Ci-dessous, quelques opérations de base nécessaires au bon fonctionnement de nebule, et notamment pour l’expérience 3.

Continuer la lecture de OpenSSL plutôt que GPG!

GPG ou OpenSSL?

Mes machines Linux disposent de différents algorithmes de hashage, de chiffrements symétriques et asymétriques. Mais l’utilisation de ces algorithmes n’est pas directement possible facilement (pour moi).

J’ai essayé pendant un certain temps de générer des entités avec des clés PGP (via gpg2). Mais je me heurte souvent à son manque de souplesse. C’est prévu pour chiffrer des fichiers et pas autre chose. On peut chiffre à la volé depuis la ligne de commande et via un pipe, mais la signature fait plusieurs lignes de texte en base-64, il est très difficile dans ce cas d’extraire la signature proprement dite en hexadécimal… et inversement de la ré-assembler pour la vérifier…

Bref, je me tourne aujourd’hui plutôt vers openssl qui permet à priori des manipulations cryptographiques de façon plus souple. Le format de stockage de clés qui me plaît le plus est le PEM.

On va voir jusqu’où on peut aller… Continuer la lecture de GPG ou OpenSSL?

Tracé de graphes objets/liens, mise en pratique 4

Les couleurs sont cette fois-ci directement dépendantes des objets qu’elles représentes. Les 6 premiers chiffres hexadécimales sont directement utilisés comme code couleur RVB.

Manque toujours le réarrangement des objets.

Exemple pour l’objet d8f74db1ba545040eb60a52b477cdd55958cc518ed788d05db92a89b16efde07 (une entité) :


(Lien)

Continuer la lecture de Tracé de graphes objets/liens, mise en pratique 4

Collisions d’empreintes multi-algorithmique

On peut utiliser de multiples algorithmes pour calculer l’empreinte des objets. Certains algorithmes sont plus résistants, plus fiables ou plus sürs que d’autres. Cette résistance est représenté par l’impossibilité (relative) d’inverser la fonction algorithmique, c’est à dire de retrouver l’objet source à partir de l’empreinte. Il en découle l’impossibilité (relative aussi) de calculer une collision dans les empreintes entre deux objets, c’est à dire de calculer un objet qui a une empreinte précise, par exemple la même empreinte qu’un autre objet pré-existant. Ces impossibilités sont relatives parce qu’il sera toujours possible dans le pire des cas (pour l’attaquant) de tester toutes les combinaisons possible afin de trouver une collision, mais cela lui prendra un temps tel que c’est jugé équivalent à impossible dans l’état actuel de nos connaissances mathématiques et de nos moyens informatiques.

Première conclusion, inutile de s’attarder sur des algorithmes de prise d’empreinte triviales comme CRC qui n’ont pour vocation que de permettre une vérification extrêmement rapide de données transmises (par exemple sur la couche TCP sur IP). Ces algorithmes ne sont pas prévus pour résister aux collisions volontaires.

Seconde conclusion, rappel de principes de base en sécurité informatique, on ne doit pas utiliser des algorithmes qui sont reconnus non fiables ou pour lesquels on est sur le point de réussir des collisions. Exit donc MD5, SHA0 et SHA1 par exemple.

Jusque là, on reste en territoire connu. SHA256 est encore aujourd’hui reconnu comme sür et ne semble pas présenter de faiblesse à moyen terme. Il peut servir sans risque intrinsèque aux premières expériences nécessitant un bon niveau de sécurité. D’autres algorithmes connus sont susceptibles d’être utilisés dans un futur proche.

Mais que ce passe-t-il si on mélange plusieurs algorithmes différents pour le calcul d’empreinte ?
Ne risque-t-on pas d’affaiblir non pas les algorithmes mais le système dans son ensemble ?

En présentant un objets sous différentes empreintes générées par des algorithmes différents, ne risque-t-on pas d’affaiblir un ou plusieurs algorithmes ?

De façon plus générale, si une faille importante est découverte dans un algorithme et que celui-ci n’est plus jugé sür, quelles conséquences pour l’ensemble du système ?