Archive for the ‘Cryptographie’ Category

Prise d’empreinte homomorphique

Vendredi, juillet 11th, 2014

Les objets manipulés par nebule sont identifiés, et donc référencés, par leurs empreintes respectives. Ces empreintes sont cryptographiques afin de pouvoir s’assurer que c’est bien le bon objet, afin de pouvoir avoir confiance dans l’intégrité de son contenu. Il est possible dans un seul cas d’avoir plus d’une empreinte par objet, c’est si celles-ci sont calculées avec des algorithmes différents (cf Collisions d’empreintes multi-algorithmique).

Cependant, si la propriété cryptographique des empreintes est indispensable à la confiance, elle entraîne un manque de souplesse dans le référencement des objets. Rien dans la valeur de l’empreinte ne trahis une partie de son contenu. L’empreinte cryptographique reflète uniquement l’intégralité de l’objet. On ne peux pas s’en servir pour retrouver des objets proches dans leur contenu. Tout au plus peut-on vérifier si deux objets sont identiques… ce qui n’a pas d’intérêt puisque dans ce cas c’est tout simplement le même objet.

Sub-division d’objet

La première solution pour résoudre ce problème est d’utiliser des sous-parties d’un objet comme des objets propres, et de les identifier comme tels. Le lien de type s permet justement de lié l’objet principal à ses morceaux.

C’est notamment ce qui est fait dans les logiciels de Paire-à-Paire (P2P – Peer to Peer). Pour qu’un fichier puisse être téléchargé depuis de multiples sources, celui-ci est pré-découpé en morceaux de taille identique pré-définit. Chaque morceau à une empreinte propre et peut être vérifié à la réception. Chaque morceau est téléchargé sur une et une seule source, mais plusieurs morceaux sont téléchargés simultanément depuis plusieurs sources. On augmente ainsi le débit réel de réception du fichier voulu même si les sources ont individuellement un faible débit d’émission. Évidemment, si chaque morceau est valide, le fichier dans son ensemble ne peut qu’être valide.

Une recherche sur mot clé peut avantageusement tirer partie de ce système puisqu’une recherche se fera uniquement sur l’empreinte du morceau correspondant à la recherche. Toute la difficulté est de bien choisir ces morceaux.

Pour du texte, c’est facile. Pour une recherche sur des images ou des vidéos, c’est déjà beaucoup moins évident. Mais quoique l’on trouve, c’est toujours une liste d’objets qui contiennent cette petite sous-partie même si le reste n’a absolument aucun rapport.

Empreinte homomorphique

Une autre solution consiste à essayer de trouver des objets qui ont le plus de contenu en commun. Ce serait une sorte de représentation miniature du contenu de l’objet. On veut quelque chose qui se rapproche plus de l’empreinte des doigts de pieds. On regarde d’abord que cela à bien la forme d’un pied, puis on regarde plus en détail certaines parties morphologiques pour déterminer si les deux pieds sont proches.

On pourrait partir sur le système de sous-découpage utilisé par le P2P. Chaque objet est découpé en petits morceaux de taille identique. Ainsi, si deux objets ont un ou des morceaux en commun, on pourra en déduire que ceux-ci sont proches.
Mais cette méthode pose un problème. Si on prend un objet et que l’on en fait une copie avec pour seule différence un caractère supplémentaire dans le premier bloc de données, alors tous les blocs seront vus comme différents alors que les objets ont clairement des parties communes.
On pourrait imaginer essayer d’optimiser la méthode en travaillant sur des blocs de tailles variables. Mais quels critères adopter pour ajuster les tailles de blocs en fonction des données ?

Je propose une méthode comme base de réflexion à défaut pour l’instant d’être adoptée.
Si on regarde le travail d’un logiciel de compression de données, on constate qu’il recherche les occurrences multiples de données dans l’ensemble d’un document. Il le fait sans tenir compte de la sémantique de ce qu’il trouve. Ainsi des mots très proches sémantiquement ne seront pas agrégés parce que différents. Ensuite, le logiciel de compression fait un classement statistique pour déterminer les occurrences multiples qu’il serait avantageux de réduire. Une phrase qui apparaît quelques fois permet une bonne optimisation. Un mot qui apparaît plusieurs permet aussi un gain de place facile.
Si on reprend le même principe d’analyse, même sans tenir compte de la sémantique des mots, on peut s’attendre à ce que les plus grandes occurrences de mots ou de phrases représentent le ou les sujets du document. C’est ce que fontnotamment les moteurs de recherches (Google, Bing, Yahoo…) lorsqu’ils moulinent les pages web, mais avec l’analyse sémantique en plus.
L’empreinte homomorphique est constituée des 20 premières occurrences redondantes avec leur poids respectifs. L’occurrence peut être représentée par une petite empreinte (CRC) de façon à avoir une taille fixe, mettons 16 caractères hexadécimaux. Le poids peut être représenté en pourcentage sur 4 caractères hexadécimaux (entre 0000 et ffff).
Vue comme ça, l’empreinte générée n’est plus tout à fait homomorphique et n’a pas de propriétés cryptographique.On obtient une empreinte homomorphique de 400 caractères hexadécimaux.

Ainsi, plusieurs documents parlants d’un même sujet ont de fortes chances d’avoir une même empreinte parque bien que différents ils auront les mêmes occurrences redondantes.

Un certain nombre de données annexes vont figurer dans les données utilisées pour la comparaison. Par exemple on peut retrouver les en-têtes internes des documents bureautique. Il faut peut-être pré-filtrer les documents en fonction de leur type pur. Par exemple, un simple fichier texte et un fichier complexe de traitement de texte se verront expurgés de tout ce qui est en-tête et données internes, puis on en gardera que les caractères imprimables convertis en minuscule, sans ponctuation…

Conclusion

Une empreinte homomorphique peut être utilisée avantageusement en complément de l’empreinte cryptographique. Elle n’a d’intérêt que pour des objets ayant suffisamment de contenu. Il faut prévoir un seuil minimum en dessous duquel elle n’est pas calculée. Cette empreinte homomorphique est liée à l’objet par un lien de type l avec comme objet méta « nebule/objet/homomorphe ». Cet objet à usage réservé est ajouté à la documentation.

Mais dans tous les cas, en l’absence de propriétés cryptographique, une empreinte homomorphique ne doit pas être utilisée dans les liens. L’usage n’est pas le même, on fait soit de l’intégrité, soit du référencement.

Détournement de liens de mise à jour

Vendredi, janvier 17th, 2014

La mise en place dans sylabe du code nécessaire à la résolution du graphe des mises à jours d’un objet montre que l’on peut créer une sorte de raccourci d’objet.

Ce détournement ne pose à priori pas de problème puisqu’il sera impossible de créer un objet avec cette empreinte réduite et que toute tentative se traduira par un rejet de l’objet lors de la vérification d’intégrité.

OpenSSL et la cryptographie – suite

Mardi, janvier 14th, 2014

Le code de sylabe, en php, est corrigé pour répondre au problème d’interopérabilité du chiffrement.
CF Avancement

Le code en bash doit encore être corrigé.

Abandon de certains liens lors du chiffrement

Lundi, janvier 13th, 2014

Maintenant que l’IV est utilisé par défaut avec une valeur nulle, il n’a plus à être précisé. Le lien qui était généré vers l’objet nebule/objet/encode/InitialVector pour le préciser n’a plus de raison d’être utilisé.

Il en est de même pour la clé de session. L’objet de la clé de session apparaît naturellement dans les deux liens de chiffrement. Il n’est donc pas nécessaire de re-préciser que c’est une clé de session. Il n’est d’ailleurs pas utilisé dans le processus de déchiffrement. Le lien vers nebule/objet/encode/SessionKey ne sera donc plus généré.

Et de fait, l’objet nebule/objet/encode n’a plus d’utilité non plus. La documentation de nebule v1.1 est mise à jour en conséquence. On supprime ces objets réservés :

  • nebule/objet/encode
  • nebule/objet/encode/InitialVector
  • nebule/objet/encode/SessionKey

OpenSSL et la cryptographie – suite

Vendredi, janvier 10th, 2014

Voici la suite sur les problèmes d’implémentations de la cryptographie symétrique tel que décris dans OpenSSL et la cryptographie et Interopérabilité du chiffrement(blog sylabe).
Après quelques tests sur le chiffrement symétrique avec la commande openssl et son équivalent en php, j’ai trouvé les bonnes implémentations pour obtenir le même chiffre à partir des mêmes valeurs en entré.

Il y a à la fois une erreur dans l’implémentation de openssl dans nebule en bash, et une autre erreur d’implémentation de openssl dans sylabe en php.

BASH

En bash, la commande openssl enc était appelée avec l’option -kfile alors qu’il faut utiliser l’option -K.
Il faut en plus utiliser l’option -nosalt pour ne pas ajouter de sel et donc notamment avoir un objet chiffré de taille strictement identique à l’objet en clair.

Voici une courte implémentation qui marche, dans le cadre d’emploi de nebule exclusivement :

#!/bin/bash
nebule_symalgo="aes-256-ctr"
iv='00000000000000000000000000000000'
echo -n "477fd3f3a32dc5de70cf13d1e46d8663f5f23873826572ea8359064b6d63c60c2d76f29a5e34fac2aebb157975517ef23110f4a5e415d9d0408f6fe7b9fe17bdd6bbb2df3fb819ecbd5216835ecccc559e7eb84e0517e92538d9a81fec333498a64b90df3429abe857ba1666fc93b24509e63d05fd619da9eef12c8d70dbacca" > /tmp/bdata
key='8fdf208b4a79cef62f4e610ef7d409c110cb5d20b0148b9770cad5130106b6a1'
openssl enc -e -$nebule_symalgo -in "/tmp/bdata" -out "/tmp/bcode" -K $key -iv $iv -nosalt -p
sha256sum /tmp/bcode

PHP

En php, la commande openssl_encrypt recevait la clé de chiffrement hexadécimale alors qu’il faut la transmettre sous forme binaire.
Par défaut, aucun sel n’est utilisé.
Enfin, l’IV peut avoir une valeur nulle contrairement à ce qu’affirme la documentation. Ce doit être une erreur de traduction. La valeur de doit pas avoir une taille nulle.

Voici une courte implémentation qui marche, dans le cadre d’emploi de nebule exclusivement :

<?php
$nebule_symalgo = 'aes-256-ctr';
$data="477fd3f3a32dc5de70cf13d1e46d8663f5f23873826572ea8359064b6d63c60c2d76f29a5e34fac2aebb157975517ef23110f4a5e415d9d0408f6fe7b9fe17bdd6bbb2df3fb819ecbd5216835ecccc559e7eb84e0517e92538d9a81fec333498a64b90df3429abe857ba1666fc93b24509e63d05fd619da9eef12c8d70dbacca";
$hiv='00000000000000000000000000000000';
$iv=pack("H*", $hiv);
$hkey="8fdf208b4a79cef62f4e610ef7d409c110cb5d20b0148b9770cad5130106b6a1";
$key=pack("H*", $hkey);
$cryptobj=openssl_encrypt($data, $nebule_symalgo, $key, OPENSSL_RAW_DATA, $iv);
$hashcryptobj=hash('sha256', $cryptobj);
echo "E=$hashcryptobjn";
?>

WatchDox

Vendredi, janvier 3rd, 2014

Un article de Wired parle de WatchDox, une (relativement) nouvelle solution de partage de données incluant une protection au niveau de la donnée elle-même.

En résumé, c’est un système type nuage (cloud computing) qui s’interface avec la suite Office de Microsoft et la visionneuse de PDF de Adobe. L’utilisation est donc assez pratique pour qui est full Microsoft, mais aussi assez bridée de fait.
Le véritable intérêt, et ce qui le démarque de la concurrence, c’est que la protection de la donnée se fait au niveau de la donnée elle-même. Ce n’est pas géré de façon globale sur un serveur par des droits génériques et hérités mais qui ne s’appliquent que sur le serveur.
Il est notamment possible d’interdire la retransmission d’un document ou son impression, et plus encore. Cela ressemble beaucoup comme ça à ce que permet le PDF si on utilise les outils de Adobe, justement…
Il y a aussi une fonctionnalité de traçage des consultations. Chaque destinataire légitime d’un document peut l’ouvrir. Le propriétaire, l’expéditeur, sait qui l’a consulté et quand.

Au début, je me dis que j’ai enfin quelque chose qui ressemble à nebule, une gestion et une sécurisation des documents pensées au niveau du document lui-même. Il va être possible de confronter les principes sous-jacents à nebule avec quelque chose de proche…

L’enchantement ne dure pas longtemps. Pour remettre tout de suite le contexte de WatchDox, la société n’est pas encore rentable avec 10M$ de revenus annuels.
Ensuite, oui on gère des droits de diffusion au niveau de chaque documents. Mais on est finalement loin de nebule dans le fonctionnement. La donnée est chiffrée et taguée avec des droits. Ces droits sont des droits dits faibles parce qu’ils vont à l’encontre d’une règle simple : toute information que l’on transmet, on en perd irrémédiablement le contrôle.
Alors, ou est l’ambiguïté ? C’est simplement que cette solution repose sur le programme qui gère les données. La cryptographie permet de s’assurer que la donnée ne sera pas volée en cours de transmission, mais la sécurité des restrictions de (re)partage des données ne tient que sur le programme. De plus, bien que l’on puisse imaginer un cache local des données chiffrées, il faut impérativement être connecté pour exploiter les données et ainsi permettre à la traçabilité de fonctionner.
Cela veut dire qu’il est impossible de rendre publique le code du programme ou même son fonctionnement. Sinon il deviendrait possible de concevoir un programme pour manipuler les données en récupérant (légitimement) la clé de chiffrement mais aussi par exemple en permettant d’outrepasser les restrictions de partage.
Cela exclu aussi de fait toute standardisation ou interopérabilité de cet outil à d’autres produits plus ouverts, une implémentation libre par exemple.

Cette solution ne peut donc prétendre interdire la perte d’information, c’est conforme à la théorie. D’ailleurs, l’article reconnaît qu’il est toujours possible de voler l’information qui s’affiche à l’écran, même en mode paranoïaque. Elle permet quand même d’augmenter sensiblement la difficulté du vol d’information. Il reste à voir comment la gestion des droits va se passer au bout de quelques années et avec plusieurs centaines de milliers de documents…
Il reste la partie chiffrement des données dans le nuage qui peut sérieusement justifier la mise en place d’une solution comme WatchDox. Mais quelle confiance peut-on avoir en un système pour lequel on ne peut espérer obtenir le fonctionnement réel, et donc sur lequel aucun audit de sécurité sérieux et impartial ne peut être mené ?

OpenSSL et la cryptographie

Dimanche, décembre 15th, 2013

La mise en place du chiffrement/déchiffrement dans sylabe, l’implémentation de nebule en php, révèle quelques problèmes et spécificités de OpenSSL.

Lorsque il a fallu déchiffrer avec la commande openssl les objets chiffrés depuis sylabe, ça n’a pas marché.

Les objets chiffrés par sylabe, qui utilise openssl dans php, peuvent être déchiffrés par sylabe. Les objets chiffrés par nebule en bash, qui utilise la commande openssl, peuvent être déchiffrés via la même commande en bash. Le point commun est l’utilisation de la librairie openssl. Mais en pratique un objet chiffré dans sylabe que l’on essaye de déchiffrer avec la commande openssl (via nebule en bash) retourne une erreur ‘Bad Magic Number’. Et l’inverse ne marche pas non plus. Ah, c’est moche…

Salage

Le problème ici est lié à l’utilisation d’un ‘salage’ (salt). Cette valeur est générée aléatoirement par openssl pour complexifier le mot de passe de chiffrement et réduire les attaques par dictionnaire de mots de passe pré-hashés (rainbow-table). Le sel est une valeur publique contrairement au mot de passe, et doit impérativement être envoyé avec le fichier chiffré. Le salage est un renforcement de la procédure de chiffrement et non du mot de passe lui-même. Pour que le sel soit transmit avec les données chiffrées, openssl ajoute un petit entête aux données chiffrées avec notamment la valeur du sel. Il en résulte une petite augmentation de la taille du fichier des données chiffrées de 16octets. Or, la librairie openssl utilisée dans php ne génère pas de sel, les données chiffrées et non chiffrées ont la même taille.

Quelle solution apporter ?

Il est possible de gérer cet entête de fichiers chiffrés dans le code php. Cela entraîne une augmentation de la complexité du chiffrement/déchiffrement mais permet de conserver un comportement commun avec les objets actuellement générés en bash. Cette compatibilité ‘commune’ n’est pas universelle puisqu’elle n’est pas gérée par la librairie openssl dans php, et donc peut-être pas non plus dans d’autres environnements.
On peut aussi ne pas permettre d’utiliser un entête particulier et de gérer le salage de la même façon que l’IV. Cette solution casse la gestion des objets chiffrés actuels mais surtout complexifie les liens de chiffrement.
Une autre solution serait de ne pas utiliser le salage du tout. Une option de openssl le permet : -nosalt. Cela permet d’avoir un chiffrement plus simple et des objets chiffrés plus propres, et donc une implémentation plus universelle du chiffrement. On va cependant à l’encontre des recommandations faites par les développeurs de OpenSSL. Et on ré-ouvre potentiellement par dictionnaire pré-calculés.

Mais a-t-on vraiment besoin du salage ?

Le salage permet en fait de renforcer la sécurité de mots de passes potentiellement faibles ou à la limite de l’attaque par force brute.
Le chiffrement des objets dans nebule impose l’utilisation d’une clé de session aléatoire. Si l’espace des valeurs des clés de sessions est aléatoire et suffisamment grand, une attaque par dictionnaire est impossible. C’est impossible parce qu’il est dans ce cas précis impossible de pré-calculer et encore moins de stocker dans un dictionnaire l’intégralité des valeurs possibles. Un espace des valeurs de clé suffisamment grand peut se comprendre par une entropie correspondant à 128bits et plus.

Le script bash référence de nebule génère actuellement une clé de session de 64octets de valeurs hexadécimales, soit 256bits d’entropie réelle. Le code php de sylabe génère actuellement une clé de session de 128octets aléatoires, soit 1024bits d’entropie réelle.

Donc, le salage va être volontairement supprimé dans le chiffrement des objets tel que mis en place dans nebule.

Semence

Un problème similaire existe avec l’IV (Initial Vector, vecteur initial ou semence).

Lorsque l’on réalise un chiffrement symétrique, celui-ci se fait typiquement par blocs de données. Ce découpage peut entrer en interférence, en quelque sorte, avec les données à chiffrer. Si ces données sont répétitives suivant la taille du bloc ou un multiple, alors les blocs de données chiffrées correspondantes vont être identiques. Et cette répétition est détectable et fourni des informations sur le contenu non chiffré…
Pour remédier à ce problème, il existe différentes méthode d’organisation du chiffrement (pour le même algorithme de chiffrement) que l’on appelle modes d’opération. Certains modes introduisent un chaînage entre des blocs contiguës pour camoufler les données répétitives. D’autres modes mettent en place d’un compteur par bloc qui sera combiné avec les données pour forcer un peu de variabilité entres blocs répétitifs.
Il reste cependant à traiter le premier bloc. Pour cela on utilise l’IV qui est soit la première valeur pour le chaînage soit la première valeur du compteur en fonction du mode d’opération. Parce que sinon ce premier bloc, chiffré avec le même mot de passe, donnera le même bloc chiffré et donc trahira un début de données identique entre plusieurs fichiers chiffrés. L’IV est une valeur publique contrairement au mot de passe, et doit impérativement être envoyé avec le fichier chiffré.

Mais a-t-on vraiment besoin de cet IV ?

Comme dans le cas du salage, l’utilisation de d’une clé de session aléatoire et différente pour chaque objet fait que, même pour un contenu identique dans les premiers blocs, cela donnera des blocs chiffrés différents.

Donc, le vecteur initial va être volontairement supprimé dans le chiffrement des objets tel que mis en place dans nebule.

Premier problème suite à ça, l’instruction en php openssl_encrypt nécessite un paramètre IV non nul…

Comment rester sécurisé face à la NSA

Dimanche, septembre 22nd, 2013

En visitant le blog de Bruce Schneier, je suis tombé sur un long et intéressant article : How to Remain Secure Against the NSA
Je vais me concentrer sur les 5 points, traduits ici :

  1. Caché dans le réseau. Implémentez des services cachés. Utilisez TOR pour protéger votre anonymat. Oui, la NSA cible les utilisateurs de TOR, mais cela est efficace sur eux. Moins vous serez à découvert, plus vous serez en sécurité.
  2. Chiffrez vous communications. Utilisez TLS. Utilisez IPsec. Encore une fois, bien qu’il soit vrai que la NSA cible les communications chiffrées (et ils connaissent peut-être des failles spécifiques contre ces protocoles), vous serez bien mieux protégés que si vous communiquez en clair.
  3. Prenez pour acquis que, bien que votre ordinateur puisse être compromis, cela nécessite du travail et représente un risque pour la NSA (donc il ne l’est probablement pas). Si vous avez quelque chose de vraiment important, utilisez un transfert par un moyen déconnecté. Depuis que j’ai commencé à travailler avec les documents de Mr Snowden, j’ai acheté un nouvel ordinateur qui n’a jamais été connecté à internet. Si je veux transférer un fichier, je chiffre le fichier sur l’ordinateur sécurisé puis l’emmène à pied jusqu’à mon ordinateur sur internet, sur une clé USB. Pour déchiffre quelque chose, j’inverse le processus. Cela ne doit pas être infaillible, mais suffisamment bon.
  4. Soyez méfiants envers les logiciels de chiffrement commerciaux, spécialement des grands éditeurs. Mon avis, c’est que la plupart des produits de chiffrement des grandes entreprises US ont des portes dérobées pour la NSA, et il est probable que les entreprises étrangères fassent de même. Il est prudent de considérer que les équipements étrangers aient aussi des portes dérobées pour une puissance étrangère. Il est plus facile pour la NSA de placer une porte dérobée dans un logiciel à sources fermées que dans un autre aux sources ouvertes. Les systèmes reposants sur un important secret sont vulnérables à la NSA, que ce soit pour leurs activités légales ou plus clandestines.
  5. Essayez d’utiliser des algorithmes de chiffrements dans le domaine public qui nécessitent d’être compatibles avec d’autres implémentations. Par exemple, il est plus difficile pour la NSA de placer une porte dérobée dans TLS que dans BitLocker. Parce que tous les implémentations de TLS doivent être compatibles entre elles alors que BitLocker ne doit être compatible qu’avec lui-même, donnant à la NSA plus de libertés pour apporter des changements. Et parce que BitLocker est propriétaire, il est beaucoup moins probable que ces changements soient découverts. Préférez la cryptographie symétrique plutôt que la cryptographie à clé publique. Préférez les systèmes conventionnels à logarithmes discrets plutôt que les systèmes à courbes elliptiques. Ces derniers ont des constantes que la NSA influence dès qu’elle le peut.

Petite remarque sur ce qui semble une incohérence. Il cite au point 4 d’essayer d’utiliser des logiciels à sources ouvertes. Et il dit utiliser plus bas un ordinateur sous M$ Windows : « And I’m still primarily on Windows, unfortunately. Linux would be safer. »
L’aveu est franc. Je pense que l’explication est simple, il se sent plus à même de sécuriser un système qu’il connaît bien plutôt qu’un système inconnu. Ça se défend.

Confrontons donc maintenant le projet nebule et ces cinq points :

  1. Le projet nebule, une fois diffusé, peut être hébergé partout sur le réseau. Par défaut, les entités ont des emplacements connus. Mais rien n’empêche une entité d’avoir un emplacement dont l’objet contenant est chiffré, et l’URL d’une forme difficile à deviner même si on connaît le serveur. Par contre, si les objets et liens d’une entité sont échangés avec une autre entité, elle se retrouve à découvert sur d’autres emplacements. Ceci ne devrait cependant arrivé que si des liens relient ces objets aux deux entités. Le chiffrement des objets la seule parade définitive, ce qui est logique. L’anonymisation tel que proposé par TOR n’a pas de sens dans nebule.
  2. Dans nebule, on a le choix. Rien n’empêche de chiffrer toutes les informations vitales et de placer les liens suspects dans des objets chiffrés. Ce dernier point n’est pas encore implémenté mais est prévu et est techniquement réalisable. Utiliser TLS est recommandé au risque de révéler les liens et objets échangés, et donc d’affaiblir l’anonymisation.
  3. Le risque de l’ordinateur compromis est assez actuel malheureusement. Tant qu’un système ne sera pas intégralement nébulisé, le projet nebule n’apportera pas grand chose à ce niveau. On peut cependant profiter de la signature native des objets contre la modification malveillante. Par contre, nebule permet assez facilement de faire des échanges à sens unique, via des relais d’isolation, et via des supports amovibles. Et le chiffrement peut être entièrement réalisé sur un ordinateur isolé, même à destination d’une autre entité.
  4. Pour résumer, il faut utiliser des logiciels open sources et qui ne sont pas restreints à un seul éditeur dans leur utilisation. Le projet nebule par dès le début avec un choix d’utilisation par défaut de logiciels libres (et open sources). Ceux retenus sont très utilisés, et donc très régulièrement vérifiés. L’inter-opérabilité avec d’autres systèmes et implémentations est aussi à ce prix.
  5. Le début a les mêmes réponses que pour le point 4. Il est impossible de gérer des entités avec la cryptographie symétrique. La cryptographie asymétrique est irremplaçable. Mais il ne faut pas utiliser ces algorithmes pour faire des choses pour lesquels ils ne sont pas prévus. Par contre, si l’algorithme à logarithmes discrets est principalement utilisé aujourd’hui, tout algorithme peut être utilisé en parallèle ou en remplacement. Cela n’a pas d’importance structurelle forte. Le projet nebule s’appuie sur la cryptographie asymétrique pour les signatures et chiffrements (pour les clés de sessions).

Liens :
https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html

Mise à jour – librairie bash de référence

Vendredi, mai 24th, 2013

L’entité bachue diffuse depuis ce soir une nouvelle version de la librairie bash de référence. Elle est disponible ici :

0c2bd920ba6efa6fdb72718bd5d606cd56c95956d8e3e8c6e1f8562d56820853 (contenu)

Cette mise à jour apporte la fonction de déchiffrement complète nebObjUnEnc pour extraire un objet en clair d’un autre objet chiffré. Cela tient compte de la clé de session et de l’entité destinataire, c’est à dire celle qui détient la clé privée (et son mot de passe).

Cela donne par exemple (dans une console bash) pour la commande

nebObjUnEnc 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 /home/steph/temp/

les logs :

2013-05-24T23:23:48+0200 2  -nebObjUnEnc REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 /home/steph/temp/
2013-05-24T23:23:48+0200 2  -nebObjUnEnc PATH /home/steph/temp/
2013-05-24T23:23:48+0200 3  -nebReadObjLinks REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 4  _l_lsx REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 5  _l_ls1 REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 2  -nebObjUnEnc FOUND 2919ec018c34e16115b6edccd6cd8f5ba4fc43b2f81a74b05a6a6b2b7b10c1203495bc16302448e0f765f996b20dcfdaa603d498ca3677d1c4edc89d00ff78ee0b08afea86599b9dd7d3b906eabd03e95fcedb6a061a845880734dbd96ce
2013-05-24T23:23:48+0200 2  -nebObjUnEnc SESSION KEY fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 3  -nebReadObjLinks REQ fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 4  _l_lsx REQ fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 5  _l_ls1 REQ fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 2  -nebObjUnEnc FOUND 8081c51cffa6f2e56f0f2b087cfaf0cf58eb04470e232d3051153d12e536b803a17dbb2d2d32d1816abfe405beac973193ce3ec4116a5588a03fe7a120170cf19160ccb6a2d131711c30d18eb120326972b147baddbd008837f271c401f5
2013-05-24T23:23:48+0200 2  -nebObjUnEnc SESSION KEY ENC cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 4  -nebReadObjTypeMime REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 5  -nebFindObjType REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c nebule/objet/type
2013-05-24T23:23:48+0200 6  _l_lsx REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 7  _l_ls1 REQ cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c
2013-05-24T23:23:48+0200 5  -nebFindObjType TYPE f0fff2e398c34a5cde5006bd1d964226ddee18a7550e552a4e49536607792d7a
2013-05-24T23:23:48+0200 4  -nebReadObjTypeMime FIND application/x-encrypted/rsa
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc OBJ TYPE application/x-encrypted/rsa
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc DECODE cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c 6a4b7f1100b87044b21f0300eb5c8b627e440e6c239b7dc64767dc16fab38719
2013-05-24T23:23:48+0200 3  -nebAsymUnEnc DECODED cf3ba5ec5c63e3fa3f2aaa4e4005f11134afe1bf1c10cf0b349c303adb3a0a4c -> fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 3  -nebObjUnEnc DECODED KEY
2013-05-24T23:23:48+0200 4  -nebSymUnEnc REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0
2013-05-24T23:23:48+0200 5  -nebReadObjTypeMime REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 6  -nebFindObjType REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 nebule/objet/type
2013-05-24T23:23:48+0200 7  _l_lsx REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 8  _l_ls1 REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 6  -nebFindObjType TYPE f67ae5bf11f82e1037ee44aa79fab49dd4d7c4f66e6efb3f9a157193b1e20f9a
2013-05-24T23:23:48+0200 5  -nebReadObjTypeMime FIND application/x-encrypted/aes-256-cbc
2013-05-24T23:23:48+0200 4  -nebSymUnEnc OBJ TYPE application/x-encrypted/aes-256-cbc
2013-05-24T23:23:48+0200 4  -nebSymUnEnc ALGO aes-256-cbc
2013-05-24T23:23:48+0200 5  -nebFindObjType REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 nebule/objet/encode/InitialVector
2013-05-24T23:23:48+0200 6  _l_lsx REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 7  _l_ls1 REQ 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800
2013-05-24T23:23:48+0200 5  -nebFindObjType TYPE 4dcabd9342f9d1da7703e050a8887c4d87b06dcea7426d9c0d099bacf763656e
2013-05-24T23:23:48+0200 4  -nebSymUnEnc IV 4dcabd9342f9d1da7703e050a8887c4d87b06dcea7426d9c0d099bacf763656e
2013-05-24T23:23:48+0200 4  -nebSymUnEnc DECODE aes-256-cbc 7c81a9adf7596b0ea7a7460e1676558a7d2148c0a619f57edff0dc748d744800 fd375403d263355facc8bfe0393c3182358675ee24826f11911a3e6a6040e9a0 IV=739c43201f51033e5826db9572bde317
2013-05-24T23:23:48+0200 4  -nebSymUnEnc DECODED IN 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:48+0200 4  -nebSymUnEnc MOVED TO PRIV
2013-05-24T23:23:48+0200 4  -nebObjUnEnc DECODED OBJ
2013-05-24T23:23:48+0200 5  -nebReadEntityFName REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:48+0200 6  -nebFindObjType REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e nebule/objet/nom
2013-05-24T23:23:48+0200 7  _l_lsx REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:48+0200 8  _l_ls1 REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 6  -nebFindObjType TYPE f3ca40a0f58333a71523ebe390a71240432eaa5572f4a466d4ed8030b91f0e20
2013-05-24T23:23:49+0200 5  -nebReadEntityFName FIND 201305201327.e837349285b6a040f41bc5371d58c0a7.www.tar
2013-05-24T23:23:49+0200 5  -nebReadEntitySName REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 6  -nebFindObjType REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e nebule/objet/suffix
2013-05-24T23:23:49+0200 7  _l_lsx REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 8  _l_ls1 REQ 0af75abec49fb5769b2431464657f419a2e9e28859b584a3c662c89ae87f1f1e
2013-05-24T23:23:49+0200 6  -nebFindObjType TYPE b06912c7bb9360d220e0a7a25449b9012b35f891f4d748cc0f3f0615c1ec48d7
2013-05-24T23:23:49+0200 5  -nebReadEntitySName FIND bz2
2013-05-24T23:23:49+0200 4  -nebObjUnEnc FILENAME 201305201327.e837349285b6a040f41bc5371d58c0a7.www.tar.bz2
2013-05-24T23:23:49+0200 4  -nebObjUnEnc MOVED TO /home/steph/temp/

Et le fichier /home/steph/temp/201305201327.e837349285b6a040f41bc5371d58c0a7.www.tar.bz2 est bien créé.

Mise à jour – librairie bash de référence

Lundi, mai 20th, 2013

L’entité bachue diffuse depuis ce soir une nouvelle version de la librairie bash de référence. Elle est disponible ici :

e7694b8923bfd02d601ddf8235463ceecc0d6913b7d046157107864d0944feb8 (contenu)

C’est une correction de bugg mineur pour la fonction de chiffrement nebAsymEnc . Le bugg entraînait la génération de liens ayant une signature valide mais ayant manifestement une syntaxe invalide.
Les liens invalides, validés jusqu’à présent par l’entité émettrice ainsi que par toutes les autres entités les ayant téléchargés, n’ont pas été nettoyés. Le nettoyage aura lieu lorsque la fonction nebCheckAll sera complète.

Chiffrement et protection des objets

Lundi, mai 6th, 2013

L’entité bachue diffuse depuis ce soir un correctif de la librairie nebule de référence pour bash. C’est l’objet 8906d6148799bc807f2d87566125d02163c6f567c2497b564fbdb19b26156b75 (contenu).

Ce correctif fait suite à la découverte d’un comportement anormal lors du chiffrement asymétrique.

La fonction nebReadObjTypeMime (appelée par la fonction nebObjEncX) permet de déterminer notamment si l’objet entité destinataire à qui on souhaite chiffrer l’objet est bien une clé RSA. La clé RSA est assumé aujourd’hui comme clé publique.
La première action généralement réalisée avec un fichier à chiffrer (ou non), c’est de le nébuliser. C’est à dire de le convertir en objet nebule avec un certain nombre de caractéristiques traduites en liens. Cet objet nébulisé est par défaut placé en espace publique (accessible en ligne dans les objets).
Suite à une modification, la fonction nebReadObjTypeMime ne renvoyait plus aucune valeur de type mime. Ainsi, dans la fonction nebObjEncX, l’entité n’étant pas/plus reconnu comme entité, le chiffrement ne se faisait pas.
Si le processus de chiffrement était interrompu, la fonction nebSymEnc n’était pas appelée. Or, l’une des première action de cette fonction est de déplacer l’objet à chiffrer de l’espace public vers l’espace privé (non accessible en ligne). Sans cette fonction, l’objet à chiffrer se retrouvait ainsi en espace public alors qu’il aurait dû être chiffré puis supprimé.

Le correctif a consisté à :

  1. corriger la fonction nebReadObjTypeMime pour qu’elle retourne une valeur correcte ;
  2. modifier la fonction nebObjEncX pour déplacer tout de suite l’objet à chiffrer, et donc mieux le protéger.

En attendant de trouver la source de cette erreur, il m’a fallu nettoyer à la main les objets qui auraient dû être chiffrés. Ces objets étant pour certains déjà répliqués sur d’autres machines par les entités robots…

CF : 2d0468b3153a1a43861ada08cc0a209df138f581df61b8ebc4cf022ee3d83aef

Openssl sous Centos

Vendredi, mai 3rd, 2013

Un des robots tourne sous CentOS release 5.9 (Final).

La version de openssl est la OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008. Elle ne permet pas d’utiliser certaines options de la commande rand pour générer des données aléatoires en hexadécimale. Sauf que je l’utilise intensément… pour générer des IV de chiffrement et pour générer des noms de fichiers temporaires.
Donc, le chiffrement ne marchera pas bien en l’état. Et des buggs sont à prévoir dans certaines fonctions…

Pour info, Debian Linux 6.0.7 dispose d’une version un peu datée aussi, la OpenSSL 0.9.8o 01 Jun 2010. Deux ans de différence, ça se sent… mais c’est suffisant pour mes besoins.
Heureusement, on est en 2013 est openssl est packagé en version 1.0.1e.

Chiffrement fonctionnel vers une entité tierce

Mercredi, avril 3rd, 2013

Le chiffrement est fonctionnel vers une entité tierce. Toujours sans pré-compression des données.

Cela donne ce type de graphe pour le chiffrement de multiples objets vers une entité :

CF :
Chiffrement fonctionnel
Chiffrement et type mime
Chiffrement et vecteur initial
Chiffrement et compression
Introduction à la cryptographie

Chiffrement fonctionnel

Lundi, mars 25th, 2013

Le chiffrement est fonctionnel pour l’instant uniquement à destination de l’entité qui le génère, et sans pré-compression des données.

Cela donne ce type de graphe :

Chiffrement et type mime

Dimanche, mars 24th, 2013

Suite de la réflexion sur l’Introduction à la cryptographie.

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, je gratte un peu ce qui se rapproche le plus de mon besoin.

Il se trouve qu’il existe le type mime application/octet-stream un peu fourre tout pour les contenus… binaires. Mais il est standardisé en l’état.
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.
Bref, 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.

Chiffrement et vecteur initial

Mardi, mars 5th, 2013

Dans l’Introduction à la cryptographie, le vecteur initial (IV) était définie comme était égale à la clé de session. Bien sûr, de fait, le vecteur initial n’était plus publiable comme on le fait habituellement.

Après consultation du fonctionnement du mode CTR (CounTeR), je me rends compte qu’il n’est peut-être pas opportun d’avoir l’IV identique à la clé de chiffrement. La première étape du chiffrement consiste en un ou exclusif (XOR) entre l’IV et la clé de chiffrement. Cela donne une clé pour ce tour égale à 0.
CF Wikipedia.org – Mode_d’opération (cryptographie).

Donc, un IV est ajouté. Il est lié à l’objet chiffré pour pouvoir déchiffrer celui-ci. Par défaut, sa valeur est aléatoire. Du fait du fonctionnement du mode CTR, l’IV s’incrémente à chaque bloc chiffré.

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

Chiffrement et compression

Mardi, mars 5th, 2013

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 maximal. Si un algorithme de compression arrive à compresser 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. CF Introduction à la cryptographie.
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.

Introduction à la cryptographie

Lundi, février 11th, 2013

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…

(suite…)

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/

Nommage des objets avec tag de hashage

Jeudi, octobre 4th, 2012

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.