cryptosec

Attaques et failles

Un peu de cryptanalyse et quelques failles à éviter

Généralités :
Il est difficile de dresser un panorama de la cryptanalyse ou des attaques sur les logiciels. Ce sont des domaines très éclectiques, qui bougent très rapidement. Chaque attaque est en général très liée au sujet de l’attaque : l’algorithme, le protocole, le logiciel... Ca ressemble plus à de l’artisanat qu’à de l’industrie, dans le sens que l’on refait rarement deux fois la même chose. Il n’y aura donc sur cette page que le principe de quelques attaques présentées de façon succincte, pour donner une idée.
Dans tous les cas on n’examine que les systèmes qui se conforment aux principes de Kerckhoff, qui stipulent que l’attaquant connaît tous les détails de l’algorithme : ils peuvent être considérés comme des principes de base pour la conception d’algorithmes et de cryptosystèmes, le contraire de la sécurité par l’obscurité.
Le but est de trouver la clé, ce qui est parfois équivalent à trouver le chiffré, mais souvent plus ambitieux.

Attaque ou l’on essaye de deviner le texte clair (en asymétrique) :
L’attaquant dispose d’un texte chiffré et choisit un texte clair. Il chiffre ce texte clair à l’aide de la clé publique de la victime, dans le cas d’un algorithme à clé publique. En comparant le résultat avec le texte chiffré dont il dispose, il peut déterminer si sa supposition était correcte.
La victime de ce type d’attaque peut s’en prémunir en ajoutant aux données qu’il chiffre des bits aléatoires. Ce procédé permet de se prémunir d’autres types d’attaques, comme celle exploitant le fait qu’un groupe d’utilisateurs partagent la même valeur de e pour RSA par exemple.

Cryptanalyse différentielle :
Cette méthode récente (1990) est une attaque à texte clair choisi, initialement faite sur le DES. On choisit deux textes clairs avec des différences connues (l’opérateur étant le XOR), puis on analyse l’évolution des différences entre les textes chiffrés avec une même clé à chaque ronde. En regardant les différences finales entre les paires de textes chiffrés on donne diverses probabilités aux clés testées. En affinant, on arrive à la clé la plus probable.
Cette attaque est d’autant plus efficace que le nombre de rondes est réduit (sur 8 au lieu de 16 pour le DES ça marche pas mal).
Evidemment, les détails sont un peu plus compliqués. Voir les bouquins pour plus de détails.
La NSA, avec une dizaine d’années d’avance sur la recherche publique, connaissait ce type d’attaque. DES, que la NSA à contribué à concevoir (notamment les tables-S) avait notamment été protégé contre cette attaque.
Il est à noter que cette attaque nécessite un nombre impressionnant de couples clairs/chiffrés... ce qui la rend infaisable dans la plupart des cas réels.

Cryptanalyse linéaire :
Je n’ai pas regardé le sujet d’assez près. Ce qu’en dit Schneier c’est qu’elle "utilise des approximations linéaires pour décrire l’action d’un algorithme de chiffrement par blocs". La conception du DES ne le protège pas particulièrement contre cette attaque, encore plus récente que la différentielle.
Le nombre de textes clairs connus requis est faramineux, et rend aussi cette attaque malaisée dans le réalité.

Recherche exhaustive
C’est la méthode la plus répandue : on prend un couple clair/chiffré, et on essaye toutes les clés jusqu’à trouver la bonne.
Pour un DES simple (clé de 56 bits), on trouvera en moyenne la bonne clé au bout de 2^55 essais.
Cette attaque n’est efficace que dans le cas ou toutes les clés sont équiprobables : dans le cas de la factorisation ou de l’exponentiation modulaire (RSA ou Diffie-Hellman), ce n’est certainement pas l’attaque la plus efficace, parce ce que tous les éléments de l’espace des clés n’ont pas la même probabilité d’être des clés.
Trouver des couples clairs/chiffrés n’est pas si compliqué qu’il y parait : les entêtes des fichiers chiffrés, ou les premiers termes d’un protocole de communication sont souvent connus.
Pour la taille des clés et la recherche exhaustive, voir la FAQ de Thomas Pornin.
Pour la meilleure attaque contre le DES pour le moment, voir http://www.eff.org/descracker(ils ont construit une machine dédiée pour 250000 $ qui trouve une clé DES-56 en moins de 3 jours, et en 22 h 15 m accompagnée de 100000 PC sur internet...)
Pour les meilleures attaques contre RSA (qui ne sont pas des recherches exhaustives...), voir http://www.rsasecurity.com/rsalabs/challenges/factoring/faq.html

Attaques contre la conception des systèmes cryptographiques...
Les algorithmes au coeur d’un système cryptographique peuvent être sûrs et bien conçus, mais la façon de les agencer et de s’en servir peut être source de failles de sécurité. Nombre de sociétés, dont la crypto et/ou la sécurité n’est pas le métier, ne se privent par exemple pas de récupérer sur internet des sources libres d’algorithmes (fonctions de chiffrement par blocs, fonctions de chiffrement asymétrique, fonctions de hachage...) et des les implémenter rapidement, sans vérifications, conformément au business plan qui veut toujours que le produit aurait du sortir avant-hier...

Quelques points qui peuvent par exemple être considérés :

- Le choix des algorithmes est-il judicieux ? (par exemple, prendre des algorithmes secrets ou faits "maison" prive de l’analyse de la communauté cryptographique, et l’algorithme contient peut-être des faiblesses qui pourraient rapidement être détectées...)

- Les générateurs pseudo-aléatoires sont-ils sûrs et bien implémentés ? (les prochaines générations de processeurs devraient en contenir des physiques)

- Les cas particuliers sont-ils écartés ? (clés faibles, protocoles initialisés à "algo = NULL"... ça arrive)

- Tous les tests nécessaires ont-ils été effectués ? (conformité aux spécifications, résistance, comportement face à des valeurs d’entrée originales...)

- Est-on sûr que les valeurs aléatoires ne sont jamais réutilisées ?

- La gestion des clés est-elle bien faite (non réutilisées, effacées de façon sûre...)

- Les tailles de clés utilisées sont-elles conformes aux besoins de sécurité et cohérentes (entre asymétrique et symétrique par exemple) ?

- Les fichiers temporaires sont-ils toujours efficacement "nettoyés" en cas de chiffrement (par réécriture multiple par exemple) ?

- Les protections par mot de passe sont-elles bonnes (imposition possible de règles strictes, bonne implémentation, activée par défaut...)

- Comment réagit le système en cas de plantage de la machine au cours d’une opération cryptographique ? Les erreurs sont-elles bien gérées ? (j’ai vu des logiciels qui laissaient des copies temporaires en clair sans en avertir l’utilisateur)

- Les protocoles et formats (IPSec, SSL, S/MIME...) sont-ils correctement choisis, implémentés et utilisés ?

- Les environnements sont-ils sûrs et homogènes ? (à quoi bon protéger un site web par SSL sur le port 443 si le même contenu est accessible sans trop de difficultés sur un autre port...?)

- Les interfaces graphiques ne présentent-elles pas des failles fonctionnelles (des erreurs de configuration que pourrait faire l’utilisateur par exemple) ?

- ...

Attaques contre les systèmes obscurs
La vanité, la peur de révéler des secrets de conception, l’urgence ou l’ignorance pousse souvent des entreprises commerciales à tenir leurs sources et spécifications secrètes. Cela prive leurs algorithmes de l’analyse de la communauté cryptographique... et entraîne parfois de grosses bévues. Parmi les meilleurs exemples de cette calamiteuse "sécurité par l’obscurité" sont les algorithmes de chiffrement des GSM (A5/1) et celui des DVD (DeCSS DVD).


 
cryptosec
15 avril 2002

 
 
 
 
 
Partager sur Twitter  |  Partager sur LinkedIn
 

Afficher les commentairesMasquer les commentaires


 
modération a priori

Ce forum est modéré a priori : votre contribution n’apparaîtra qu’après avoir été validée par un administrateur du site.

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Creative Commons - BY - NC - ND

Tous les textes, images et sons de cryptosec sont publiés selon les termes de la licence Creative Commons - Attribution - Pas d’Utilisation Commerciale - Pas de Modification - 3.0