Commandes OpenSSL

J'ai toujours du mal à me rappeler de la syntaxe de certaines commandes openssl. Je fais donc un petit mémo pour me rappeler de certaines d'entre elles que j'utilise fréquemment. J'en rajouterai progressivement.

Commandes d'encodage

Pour encoder une suite d'octets avec openssl, il faut utiliser la commande enc. Il est possible par exemple d'encoder grâce à cette commande un texte en base64.

# Encodage du texte toto en base64
$ echo -n toto | openssl enc -base64
dG90bw==

# Decodage du texte dG90bw== encodé en base64
$ echo dG90bw== | openssl enc -base64 -d
toto

Il est à noter que pour le désencodage, openssl attend une chaîne de caratères terminée par un retour chariot. Il ne faut donc pas utiliser l'option -n de la commande echo (qui supprime ce caractère de fin). Si dans l'encodage par contre, on rajoute un retour chariot alors ce dernier sera aussi encodé par la commande.

Commandes de chiffrement asymétrique

Le chiffrement asymétrique est à la base des systèmes de PKI. La particularité de ces algorithmes est que la clef utilisée pour chiffrer le message n'est pas la même clef utilisée pour le déchiffer. Les exemples suivant utilisent l'algorithme RSA accessible via la commande rsautl de openssl.

# Chiffrement avec la clef publique RSA<
$ echo toto | openssl rsautl -encrypt -inkey private.pem
$ echo toto | openssl rsautl -encrypt -inkey public.pem -pubin

Ici le fichier private.pem contient le couple clef publique/clef privée. Le fichier public.pem ne contient que la clef publique. Ici seul la clef publique est utilisée dans le chiffrement (le déchiffrement se fera donc avec la clef privée). La sortie ici n'est pas affichée car rien ne dit qu'elle ne contient que des caractères imprimables. Il faudrait pour cela encoder cette sortie en base64 par exemple pour l'afficher.

# Déchiffrement avec la clef privée RSA
$ echo $to_decrypt | openssl rsautl -decrypt -inkey private.pem

La variable $to_decrypt contient ici le texte chiffré.

Commandes de chiffrement symétrique

Les algorithmes de chiffrement symétrique s'opposent aux algorithmes de chiffrement asymétrique car ils utilisent la même clef pour chiffrer et déchiffrer. La commande enc de openssl (qui permettait aussi l'encodage) permet ce type de chiffrement.

# Chiffrement en AES 256 mode CBC
$ echo toto | openssl enc -aes-256-cbc -K $SKEY -iv $IV -salt

# Dechiffrement en AES 256 mode CBC
$ echo $to_decode | openssl enc -aes-256-cbc -K $SKEY -iv $IV -d

La clef servant au chiffrement/déchiffrement se trouve dans la variable $KEY. Elle doit mesurer 32 octets (car AES 256 bits) et être codée en hexadécimal (donc 64 caractères). Le vecteur d'initialisation $IV utilisé dans ce mode de chiffrement doit faire 16 octets codé en hexadécimal (donc 32 caractères).

Commandes de calcul d'empreinte

Pour plus d'informations sur les fonctions permettant le calcul d'empreinte veuillez vous référer à cet autre billet que j'ai écrit. La commande openssl permettant le calcul d'empreinte s'appelle dgst. Les algorithmes disponibles dans openssl sont nombreux : MD4, MD5, SHA-1, RIPEMD160...

# Calcul d'une empreinte SHA-1
$ echo -n toto | openssl dgst -sha1
0b9c2625dc21ef05f6ad4ddf47c5f203837aa32c

# Calcul d'une empreinte MD5
$ echo -n toto | openssl dgst -md5
f71dbe52628a3f83a77ab494817525c6

La sortie de ces commandes est encodée en hexadécimal.

Commandes de génération de clefs asymétriques

La commande openssl pour générer des clefs asymétriques (RSA) est genrsa. La paire de clef générée peut ou non être chiffrée pour plus de protection.

# Génération d'un couple de clef de 2048 bits
$ openssl genrsa -out keys.pem 2048
Generating RSA private key, 2048 bit long modulus
.............................+++
.................+++
e is 65537 (0x10001)

# Génération d'un couple de clef de 4096 bits qui sera chiffré en triple DES
$ openssl genrsa -des3 -out keys.pem 4096
Generating RSA private key, 4096 bit long modulus
...........++
........................................................................................................................++
e is 65537 (0x10001)
Enter pass phrase for key:
Verifying - Enter pass phrase for key:

La pass phrase demandée servira au chiffrement de la paire de clef. A chaque utilisation de cette clef, cette pass phrase sera demandée. Le fichier résultat ici nommé keys.pem contient le couple de clef généré, c'est à dire la clef privée et la clef publique.

Extraction de la clé publique

Comme dit précédemment, lors de la génération de clés asymétriques, la clé publique et la clé privée sont contenues dans le même fichier. Pour extraire seulement la clé publique de ce fichier voilà la commande.

# Extraction de la clé publique du fichier contenant les deux clés
$ openssl rsa -in keys.pem -out public.pem -outform PEM -pubout
writing RSA key

Commandes relatives aux certificats

Openssl permet de faire toutes les opérations basiques que l'on peut effectuer sur des certificats : création de certificats auto signés, création d'une demande de certificat, signature d'un certificat...

# Création d'un certificat auto signé
$ openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095

Un certificat permet de certifier une clef publique. Cette clef est contenue dans le fichier nommé privkey.pem (contenant aussi la clef privée comme vu plus haut). Dans le cas d'un certificat autosigné, la clef privée sera utilisée pour signer le certificat. Dans notre exemple, le certificat sera valide pendant 1095 jours. Plusieurs autres informations seront demandée comme le pays relatif au certificat, l'état, la ville, l'entreprise, la section et surtout le common name.

# Création d'une demande de certificat
$ openssl req -new -key privkey.pem -out cert.csr

Le certificat obtenu ici n'est pas directement utilisable car il n'est pas signé. Il faudra donc le faire certifier par une autorité de certification de type Verisign, Thawte...

Fonctions de Hachage

Aujourd'hui alors que je lisais le document d'un collègue parlant de la nouvelle attaque permettant de faire un rogue CA à partir de la vulnérabilité du MD5, je réalise que j'ai de nombreuses lacunes sur les fonctions de hachage. Ce billet permet donc de faire une petite introduction sur ces fonctions.

Une fonction de hachage qu'est ce que c'est ? C'est une fonction qui prend en entrée une donnée et qui calcule son empreinte, un petit peu comme l'empreinte digitale d'un doigt. Cette empreinte est une suite d'information caractéristique de la donnée initiale.

Les fonctions de hachage sont à sens unique, ce qui veut dire qu'à partir de l'empreinte, il est impossible de revenir aux données initiales. En d'autres termes, si x représente les données et f() une fonction de hachage, alors il n'existe pas de fonction f-¹() permettant à partir de f(x) de revenir x.

Ceci est assez simple à comprendre. Supposons que notre fonction f() ait comme sortie une empreinte de 128 bits (donc 2¹²⁸ empreintes différentes). Si on calcule f(x) pour x allant de 0 à 2¹²⁸ (donc 2¹²⁸+1 valeurs différentes), il y aura au minimum deux f(x) identiques pour deux x différents.

L'autre particularité importante de la fonction de hachage et qu'il est très difficile de trouver une valeur y qui a comme caractéristique que f(y) = f(x) pour x différent de y. Dans le cas idéal, il faudrait brute forcer la valeur de y (c'est à dire tester en moyenne 2¹²⁸/2=2¹²⁷ possibilités) pour trouver un f(y) = f(x) pour un x donné. Le "pour un x donné" est très important car si x n'est pas fixé, d'après le paradoxe des anniversaires, trouver n'importe quel couple x,y tel que f(x) = f(y) ne revient à faire "que" 2⁶⁴ opérations (racine carré de 2¹²⁸).

Ok tout ça c'est bien beau mais à quoi servent ces fonctions ? Ces fonctions sont très utilisées en informatique et particulièrement en sécurité. Les algorithmes MD5, SHA... sont des fonctions de hachages.
On trouve souvent le résultat de ces fonctions à coté de fichier que l'on veut télécharger par exemple. Ce résultat permet de s'assurer que le fichier en notre possession est bien conforme. Il suffit de calculer le md5 du fichier que l'on possède. Si les md5 sont les mêmes, on a bien la même version (et on ne possède pas a priori une version vérolée, excepté bien entendu si le pirate a pu modifier le site web et le md5 affiché).
Une autre utilité est par exemple l'utilisation pour stocker des mots de passe. On ne stocke plus le mot de passe, mais le hash du mot de passe. De cette façon si un pirate s'empare du fichier (ou accède à la base de données), il ne s'empare plus du mot de passe, mais seulement de son hash (et comme il est impossible de remonter aux données initiales...). La vérification de ce dernier se faisant du coup en comparant le hash de la chaîne fournie avec la valeur stockée.
Enfin un autre exemple d'utilité est la signature numérique. Quand quelqu'un vous envoie un fichier, il calcule l'empreinte de ce fichier et chiffre cette dernière avec sa clef privé. A la réception, il ne vous reste plus qu'à déchiffrer la signature grâce à la clef publique de l'émetteur et à la comparer avec l'empreinte du fichier. Si c'est la même, alors vous êtes sûrs que le fichier envoyé n'a pas été modifié par une tierce personne, car seul l'émetteur a pu chiffrer l'empreinte (seul détenteur de la clef privé).

Maintenant que se passe-t'il quand la fonction de hachage n'est pas idéale ? On ne peut bien entendu toujours pas remonter aux données pour les raisons évoquées précédemment, mais par contre la difficulté pour trouver un y tel que f(y) = f(x) peut être réduite. C'est ce qui s'est produit pour le md5, puis plus tard pour SHA-1 qui réduit la complexité pour trouver une collision de 2⁸⁰ itérations (car le SHA-1 produit une sortie de 160 bits) à 2⁶⁹ en Février 2005, puis de nouvelles recherches ont prouvé qu'il était encore possible de faire mieux.

Jusqu'à présent les failles découvertes permettaient de simplifier le calcul pour trouver un couple x,y tel que f(x) = f(y). Chose intéressante bien entendu, mais beaucoup moins que trouver un y tel que f(y) = f(x) pour un x donné. Cela reste un premier pas vers le cassage total de l'algorithme.

Aujourd'hui les recherches en cryptanalyse sur le MD5 montrent qu'il est possible de trouver un y tel que f(y) = f(x) avec seulement une partie de x fixée. Alors vous allez dire que ca casse pas trois pattes à un canard quand il s'agit du mot de passe. Dans ce cas là c'est vrai qu'une bonne atttaque par dictionnaire (ou par rainbow tables) sera toujours plus intéressante, mais dans certains cas cela peut avoir des conséquences beaucoup plus génantes.

Attaque ChopChop

Premier article que j'écris en rapport avec la norme 802.11 plus connue sous le nom de WiFi. Pour bien comprendre cet article il est conseillé d'avoir déjà des connaissances sur le fonctionnement du protocole WEP (Wired Equivalent Privacy). Je vais parler d'une attaque relativement connue qui s'appelle l'attaque ChopChop qui a déjà fait ses preuves notamment contre le protocole WEP et qui depuis peu a été utilisé pour mettre en évidence les faiblesses du protocole TKIP (Temporal Key Integrity Protocol). Ce billet est le premier d'une série qui a pour objectif justement d'expliquer cette faille dans TKIP.

Historique

En 2004, alors que le WEP est déjà cassé depuis officiellement 2001, Korek publie la première version d'un outil appelé chopchop qui permet de décrypter n'importe quel paquet chiffré sans connaître la clef^[1] WEP. Un nouveau coup dur pour le WEP qui n'en n'avait vraiment pas besoin. Ce n'était ni le premier et encore moins le dernier. Cette attaque probablement moins connue que les attaques FMS ou encore PTW (car elle ne permet pas de trouver la clef WEP) revient sur le devant de la scène grâce à la présentation de Erik Tews faite à la PacSec sur les faiblesses du protocole TKIP.

Fonctionnement de l'attaque

Pour commencer un tout petit rappel sur le fonctionnement du WEP s'impose. Très grossièrement chaque paquet est constitué de deux parties : les données et le CRC32^[2] qui permet d'assurer l'intégrité de ces données. Le tout est ensuite envoyé à l'algorithme de chiffrement WEP c'est à dire RC4 : le paquet chiffré envoyé sur le réseau est le résultat du xor entre la concaténation du message et de son CRC32 et le keystream qui est fonction de la clef WEP et du vecteur d'initialisation courant. Si D est le message en clair, ICV l'opération de CRC32 (Integrity Check Value), C le message chiffré, K la clef WEP, IV le vecteur d'initialisation courant et || l'opérateur de concaténation alors ce que je viens d'écrire peut se résumer de cette façon :

C = RC4(IV || K) xor (D || ICV(D))

Ici tout ce qui est en vert est connu par une personne qui n'a pas la clef et qui écoute le réseau et tout ce qui est en rouge est inconnu.

Le CRC32 a à la base était écrit pour assurer l'intégrité des données et en aucun cas pour assurer leur sécurité. L'attaque ChopChop va donc utiliser plusieurs faiblesses de cet algorithme pour injecter des données sur le réseau.

Si l'on souhaite injecter des données dans le réseau à partir d'un paquet chiffré capturé alors nous avons les relations suivantes :

C = RC4(IV || K) xor (D || ICV(D)) est le paquet capturé.

D' représente les données que l'on va injecter dans le réseau tel que : D' = D xor Mod

Nous avons donc :

C' = RC4(IV || K) xor (D' || ICV(D'))

Ici comme nous ne connaissons pas D, nous ne connaissons pas non plus D'.

D' || ICV(D') = (D || ICV(D)) xor (Mod || ICV'(Mod)) ou ICV' est un CRC32 modifié

donc

C' = RC4(IV || K) xor (D || ICV(D)) xor (Mod || ICV'(Mod))

C' = C xor (Mod || ICV'(Mod))

Cette relation montre qu'à partir d'un paquet chiffré valide, il est possible d'injecter n'importe quelle modification de ce paquet. C' qui était inconnu est en définitif seulement fonction d'élément connu.

L'attaque ChopChop utilise une autre vulnérabilité du CRC32. Si le message C est tronqué de son dernier octet de données, le message devient donc invalide car le CRC32 ne correspond plus. Cependant si on xor C avec une certaine valeur Mod, alors le paquet redevient valide. Une démonstration mathématique^[3] montre que Mod ne dépend que de la valeur en clair de l'octet tronqué.

On peut donc écrire que Mod = f(X) où X est la valeur en clair de l'octet tronqué.

L'attaque coule maintenant de source. Etant donnée qu'il y a 256 valeurs possibles pour X, il suffit de toutes les tester.

On prend donc notre paquet capturé C, on lui enlève le dernier octet de données. On prend comme hypothèse que la valeur non chiffrée X de cet octet tronqué est 0 et on génère notre modification :

C' = C xor f(x) avec x=0

On envoie C' et si C' est rejoué par l'Access Point alors c'est que notre paquet C' était valide, donc notre hypothèse sur X était bonne. On vient donc de trouver un octet en clair de C (donc un octet de D), et donc un octet du keystream utilisé pour chiffrer cet octet. Si le paquet C' n'est pas rejoué par l'Access Point, alors c'est que notre paquet C' n'est pas valide, donc notre hypothèse sur X était fausse. On retente en incrémentant X, jusqu'à que le paquet C' soit rejoué. En moyenne il faudra donc envoyer 128 paquets pour décrypter un octet.

La suite est évidente, on réitère la même méthode pour trouver tous les octets de D, donc octet par octet.

Outils Implémentant l'attaque

Le premier outil implémentant cette attaque est bien entendu la preuve de concept de Korek.

Le deuxième outil est aireplay-ng de la très célèbre suite aircrack-ng. N'hésitez pas à vos référer à cette page pour la mise en oeuvre de chopchop avec aireplay.

Liens

Voilà une liste de liens qui m'ont permis d'écrire cet article, n'hésitez pas à me corriger si vous avez trouvé des erreurs !

chopchop (Experimental WEP attacks)
Thread initial de Korek sur la preuve de concept. Le contenu du fichier zip que l'on peut avoir directement ici contient plein d'informations très utiles, notamment le fichier DOC.

ChopChop Theory
L'explication de l'attaque faite par le site aircrack-ng

Byte-Sized Decryption of WEP with Chopchop, Part 1
Byte-Sized Decryption of WEP with Chopchop, Part 2
Explications supplémentaires sur le fonctionnement de l'attaque.

Fameuses faiblesses de tkip
Pourquoi c'est pourri le wep part-2
L'explication du fonctionnement de ChopChop sur le blog de Cédric Blancher qui est une mine d'informations sur la sécurité des réseaux WiFi entre autres.

Notes

[1] C'est ici un pléonasme ! Décrypter veut dire trouver le texte en clair à partir du texte chiffré sans la clef.
[2] Le CRC32 comme son nom l'indique fait 32 bits, soit 4 octets.
[3] Cette démonstration mathématique se trouve dans le fichier DOC de la preuve de concept de Korek chopchop-0.1.zip.