Protection des objets – les origines

Le problème de protection des objets de faible taille, tel que décrit dans l’article Protection et faible entropie, n’a pas de solution simple ou élégante. Peut-être qu’il est temps de se questionner sur la pertinence de la façon dont est assurée la protection des objets, de revoir les réflexions à l’origine de la protection des objets.

D’ailleurs, dans le même ordre d’idée, il faudra peut-être aussi se poser des questions par rapport à la dissimulation des liens qui crée un problème différent mais sans solution simple, performante et élégante.

A l’origine, l’usage de la protection des objets n’avait pas été vu avec autant de cas d’usages. L’idée était de pouvoir dissimuler le contenu d’une objet tout en continuant de le tracer, c’est à dire de l’identifier par son empreinte. Il semblait peu utile de dissimuler des choses aussi simple que « oui » ou « non ».
La capacité de pouvoir tracer devait aussi permettre de pouvoir bannir un objet en se basant sur son empreinte en claire. Une fois protégé un objet a une infinité d’empreintes possibles, donc il devient non traçable en pratique.
L’idée était aussi de pouvoir vérifier que le contenu protégé que l’on recevait d’une autre entité correspondait bien au contenu en clair attendu. Ceci avait pour but de ne pas ce retrouver avec un code offensif une fois déprotégé en lieu et place d’un objet anodin. Dans ce cas un contenu offensif peut être écarté rapidement par un simple lien de mise en liste d’exclusion.

Le problème vient du fait que le lien de protection de type k, en particulier le lien de chiffrement symétrique, fait l’association entre la valeur claire et la valeur chiffrée de l’information. En disposant de l’empreinte de l’information en claire on peut, si la valeur totale de son entropie est faible (ou si, déduit des parties prévisibles, la valeur totale résiduelle de l’entropie de l’information est faible), on peut dans ce cas recalculer l’information.
Il est théoriquement possible que le recalcule de l’information en claire donne une autre information ayant la même empreinte. Mais l’espace des valeurs calculables étant inférieur à la taille de l’empreinte des objets, càd la valeur totale de l’entropie de l’information recalculée en rapport avec la valeur totale de l’entropie d’une empreinte, et en considérant l’algorithme de prise d’empreinte cryptographique suffisamment robuste, il est très peu probable (de l’ordre de l’inverse de la taille des empreintes) de trouver une autre information de même empreinte. Ce serait même très inquiétant pour l’algorithme de prise d’empreinte cryptographique.

En parcourant le code et les cas d’usages actuels, il apparaît que l’on fait déjà indistinctement référence à un objet en clair ou protégé en utilisant son empreinte pour son contenu en clair ou protégé. Le code se charge de remettre dans le bon sens les deux identifiants.
Ne faire référence que à la partie protégée ne pose pas plus de problème que ça dans les usages actuels puisque l’on a juste besoin d’un identifiant.
Il est alors possible de recalculer l’empreinte, donc l’identifiant, du contenu en clair, et donc de pouvoir potentiellement le confronter à lien de mise en liste d’exclusion.

Le temps est encore à la réflexion mais la solution est peut-être là…

Protection des objets – faible entropie

Les messages que l’on protège peuvent être courts ou peuvent être dans certains cas facilement recalculés lorsque la seule partie variable du contenu a une faible entropie. C’est un problème général qui prend tout son sens dans la messagerie.
Le lien de chiffrement relie le hash de l’objet en clair avec le hash de l’objet chiffré. c’est indispensable si on veut pouvoir retrouver le contenu d’un objet en clair sans avoir à parcourir l’intégralité des hashs des objets protégés. C’est pour éviter le problème que l’on a avec l’implémentation des liens dissimulés.

Nous sommes dans le cas d’un modèle MAC-then-encrypt-then-MAC. Il faut trouver un moyen de renforcer l’entropie des objets protégés. Jouer sur le salage ou l’IV du chiffrement ne résout pas le problème puisque le problème vient du MAC avant chiffrement.
Et ce problème ne concerne pas des objets dont le contenu a une entropie supérieure à 128 bits et qui ne sont pas prédictibles. Il n’est pas utile, voire contre productif, de systématiser une solution de renforcement de l’entropie des objets protégés.

Il y a peut-être deux solutions. La première serait d’ajouter au contenu un aléa que l’on serait capable de retirer lors de l’exploitation de l’objet, comme du bourrage (padding). La seconde serait d’opérer sur l’objet une valeur d’un autre objet et de ne pas lié l’objet initial mais uniquement l’objet opéré. Cependant cette seconde méthode parait assez fragile en l’état.

La suite au prochain épisode…

Sondages et votes

Dans un article La Suisse pourrait imposer l’open-source pour le vote électronique de Numerama, il est de nouveau question de la mise à disposition du code source du programme sous forme de logiciel libre.

L’avenir du vote électronique ne fait aucun doute, seule sa réalisation pose problème aujourd’hui. Beaucoup de débats comparatifs et contradictoires ont lieux vis-à-vis de la pertinence du vote électronique et de la confiance que l’on peut apporter aux machines de vote et au processus dans son ensemble. Ces débats peuvent paraître très conservateurs mais ils sont néanmoins nécessaires puisque le vote est un acte fondamental de nos démocraties, c’est le moyen d’expression de chacun d’entre nous.

La confiance en ce genre de machine de vote et du code qui l’anime ne peut être assurée sans l’ouverture du code à minima en lecture. Il faut aussi connaître précisément l’environnement de compilation et d’exécution pour le code soit parfaitement reproductible. Et bien sûr, il faut être sûr ce c’est bien ce code qui a été utilisé et pas un autre.
Invoquer le secret industriel sur du code pour un processus parfaitement connu et un enjeu majeur de démocratie, c’est particulièrement malhonnête. Tout au plus une société éditrice peut-elle demander un droit de paternité et une restriction de commercialisation à son seul bénéfice. Mais il suffit à l’état qui fait la commande du code de demander, et payer, explicitement la libre diffusion ou la libéralisation complète du code.

Le code doit être capable dans son ensemble de permettre la centralisation des votes, l’anonymisation des électeurs ainsi que la vérification en temps réel et à postériori du décompte des votes. L’authentification de l’utilisateur devrait être le principal problème mais il apparaît que c’est en fait le décompte et sa vérification qui interpellent le plus souvent les détracteurs du vote électronique.

Un vote a un point de départ dans le temps et une fin à partir de laquelle le décompte des votes est considéré comme définitif.

L’anonymisation est aussi un problème pour la vérification de conformité du vote à postériori puisqu’elle casse le lien sûr entre le votant et le vote unitaire. On peut ainsi affirmer que le votant à voté (il a posé un papier et signé le paraphore) mais on ne peut pas le prouver à postériori (était-ce vraiment lui).
La capacité de multi-entité et la dissimulation de liens dans nebule permettent de résoudre ce problème.

Voici un scénario possible de vote avec les objets et liens de nebule :

  1. Pour un vote, une entité maîtresse du vote est générée. Elle est explicitement reconnue par les autorités comme telle. Son seul rôle est de générer les jetons de vote et de les attribuer aux électeurs.
  2. L’entité maîtresse du vote va générer autant d’objets jetons qu’il y a de votants. Ces jetons sont aléatoires et n’ont pas de relation directes avec les électeurs. Chaque jeton est en fait la partie publique d’un bi-clé cryptographique (RSA par exemple). La clé privée de chaque jetons est protégé par un mot de passe stocké dans un objet protégé par et pour l’entité maîtresse (dans un premier temps).
  3. Le jeton est en fait l’entité qui réalisera le vote via la clé privée. Chaque vote peut être vérifié par rapport au jeton, c’est à dire la clé publique.
  4. Pour chaque objets de clés privées de chaque jetons, l’entité maîtresse va partager le secret de chiffrement de l’objet contenant le mot de passe. Le lien entre objet chiffré et objet non chiffré est dissimulé, c’est à dire que c’est un lien de type c masquant le vrai lien.
  5. La clé privée de l’entité maîtresse est détruite. Il n’est ainsi plus possible de retrouver l’intégralité des relations en les jetons et les électeurs mais il est possible de vérifier que tous les électeurs ont reçus un lien dissimulé et de vérifier tous les jetons réalisant le vote.
  6. Pour un vote, une entité de décompte du vote est générée. Elle est explicitement reconnue par l’entité maîtresse Son seul rôle est de recueillir et de valider les votes. La période de vote démarre.
  7. L’électeur, c’est à dire l’entités votantes, va récupérer auprès de l’entité maîtresse du vote l’intégralité des jetons et des clés privées associées (et pas juste son jeton). Il va ainsi obtenir tous les liens dont le lien dissimulé le concernant. Via le lien dissimulé, il va savoir quel est la clé privée du jeton que l’entité maîtresse lui a attribué. Disposant de cette information il peut déprotéger à son profit l’objet contenant le mot de passe de la clé privée du jeton.
  8. L’électeur, mettant à profit la clé privée du jeton, peut réaliser un ou plusieurs votes, seul le dernier est pris en compte. Le vote consiste en un lien entre le jeton et le choix de vote dans le contexte de l’entité de décompte du vote (champs méta).
  9. L’entité de décompte du vote vérifie régulièrement auprès de tous les électeurs la présence de liens dont elle est le contexte. au fur et à mesure de la récupération des liens, elle se les approprie (signature du lien de vote).
  10. A la fin de la période de vote, la clé privé de l’entité de décompte du vote est détruite. Plus aucun vote ne peut être ajouté, modifié ou supprimé. Les votes comptabilisés sont ceux qui ont été signés par l’entité de décompte du vote.
  11. L’électeur qui souhaite rendre publique son vote a juste à prouver qu’il dispose du jeton en utilisant sa clé privée pour autre chose que le vote en relation avec sa véritable entité. Il peut aussi révéler le lien dissimulé que lui avait généré l’entité maîtresse du vote.

Un des aspects des liens dissimulés est qu’il est possible de les dissimuler pour plusieurs entités. Ainsi il est possible de générer une entité d’audit du vote à qui l’entité maîtresse partagera les liens dissimulés, de façon également dissimulé.L’entité d’audit devient capable à postériori de vérifier la bonne association entre jetons de vote et électeurs sans être elle-même capable d’émettre de nouveaux jetons.

Le sondage est moins contraignant et surtout peut être à choix multiples.

Cryptographie et clé de session

Dans nebule, à chaque fois que de la cryptographie intervient avec des entités d’un côté et du contenu de l’autre, on utilise de la cryptographie asymétrique et de la cryptographie symétrique.

La clé de session est l’un des éléments importants. Elle assure en quelque sorte le lien entre l’entité et le contenu. Le contenu peut être soit un objet soit un lien. La clé de session, c’est le mot de passe de la cryptographie symétrique pour chiffrer/déchiffrer le contenu. La clé de session est chiffrée/déchiffrée avec respectivement la clé publique ou la clé privée d’une entité.

La clé de session est le pivot du processus de chiffrement. Elle aurait pu être intégrée au contenu chiffré, ce qui nécessite une extraction pour le déchiffrement. Mais au titre de pivot, dans nebule elle est volontairement mis en avant et isolée plutôt que cachée comme une banale donnée technique.

Lors du processus de chiffrement d’un objet, la clé de session est un objet à part entière et lui aussi chiffré avec une clé privée d’entité.

20130209 nebule - schema crypto

Lors du processus d’offuscation d’un lien, son chiffrement en fait, la clé de session aurait pu aussi être fusionnée dans le registre avec le champ contenant le lien chiffré LienChiffré. Mais au contraire, elle occupe un champ à part entière CléSession.

Signature_Signataire_TimeStamp_c_EntitéCible_LienChiffré_CléSession

Cette sanctuarisation de la clé de session entraîne apparemment une plus grande complexité des processus de chiffrement. Cependant, cela apporte une grande simplification dans la gestion des objets chiffrés, mais rien pour la gestion des liens offusqués. Si un objet chiffré doit être partagé avec plusieurs entités, une clé de session différente entraînerait la nécessiter de rechiffrer l’objet source pour tous les destinataires, càd le chiffrement symétrique et asymétrique. Avec une clé de session autonome, il suffit juste de la rechiffrer pour tous les destinataires la clé de session, donc juste opération de chiffrement asymétrique. Pour un petit objet, le gain est négligeable, mais il ne l’est pas pour un gros objet (plusieurs fois la taille de la clé de session).
Je rappelle que le chiffrement asymétrique est beaucoup plus gourmand en ressources processeur et en mémoire que le chiffrement symétrique.

On peut aussi imaginer que la clé de session soit réutilisée pour le chiffrement de plusieurs objets ou de plusieurs liens. Si c’est pour une seule entité, cela permet de ne réaliser le chiffrement asymétrique qu’une seule fois. Cela crée une sorte de groupe d’objets ou de liens, ceux-ci regroupés par leur clé de session commune. Il est aujourd’hui possible d’envisager deux cas où plusieurs objets ou plusieurs liens pourraient utiliser la même clé de session :

  1. La diffusion d’objets très fortement liés entre eux et qui auraient tout intérêts à « voyager » ensembles. Idem pour des liens fortement couplés comme lors de la nébulisation d’un objet.
  2. L’utilisation de matériels peu performants pour lesquels il serait incontournable de n’avoir à calculer qu’un seul chiffrement asymétrique pour plusieurs objets et/ou plusieurs liens.

Il faut cependant garder à l’esprit que ces deux cas entraînent un risque sur la divulgation de ces objets et liens. Si un seul d’entre eux est retransmit pour autrui, c’est à dire que sa clé de session est repartagée, alors c’est tous les autres qui sont de fait divulgués. Ces exceptions doivent être évitées à tout prix ou toujours utilisées avec intelligence et extrêmes précautions.

Une clé de session doit toujours être robuste et utilisée pour un seul objet ou un seul lien.

OpenSSL et la cryptographie – suite

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";
?>

OpenSSL et la cryptographie

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

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

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éé.

Chiffrement et type mime

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

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

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

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

Ce chiffrement est optionnel. Il doit être résistant, c’est à dire correspondre à l’état de l’art en cryptographie appliquée. On doit être en mesure de parfaitement distinguer l’objet en clair de l’objet chiffré, même si le second est dérivé du premier.

Ceci est une proposition de travail.

Deux étapes de chiffrement

Les entités sont des objets contenant le matériel cryptographique nécessaire au chiffrement asymétrique. Cependant, le chiffrement asymétrique est très consommateur en ressources CPU (calcul). On peut l’utiliser directement pour chiffrer les objets avec la clé publique d’un correspondant, mais cela devient rapidement catastrophique en terme de performances et donc en expérience utilisateur. D’un autre côté, le chiffrement symétrique est beaucoup plus performant, mais sa gestion des clés de chiffrement est délicate. Pour améliorer l’ensemble, on mixe les deux. On essaie de profiter des avantages de chacun tout en réduisant les défauts.

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

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

Continuer la lecture de Introduction à la cryptographie

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?

Réflexion – stabilité de l’identifiant

Je bouquine un livre en ce moment :
« Gestion des identités » de OCTO Technology, ISBN:978-2-9525895-1-2, avril 2007, www.octo.com

Au cours du développement de l’Identifiant Unique Personnel (IUP), il est noté que trois contraintes doivent absolument être respectées.
L’IUP doit être :

  1. unique (strictement lié à une personne) ;
  2. inaliénable (ne peut être réattribué à une autre personne) ;
  3. stable (dans le temps).

En référençant un utilisateur (une entité) par un bi-clé cryptographique, respecte-t-on ces contraintes?

Continuer la lecture de Réflexion – stabilité de l’identifiant