Aller au contenu | Aller au menu | Aller à la recherche

Random, l'émission aléatoire !

mardi 7 décembre 2010

Bref historique du retrait de l'algorithme de chiffrement A5/2 de GSM, par Harald Welte

Ce texte est la traduction en langue française de l’article A brief history on the withdrawal of the A5/2 ciphering algorithm in GSM de Harald Welte (voir Wikipédia), réalisée par DecereBrain dans le cadre de l’émission Random #029 du 5 décembre 2010. L’article original est publié selon les termes de la licence Creative Commons BY-NC, et son auteur a eu la gentillesse de nous autoriser à traduire son article, à en lire la traduction à l’antenne et à diffuser la traduction sur le site Web de l’émission. Qu’il en soit remercié. Cette traduction est également publiée sous licence Creative Commons BY-NC.

Following is a French translation of the article A brief history on the withdrawal of the A5/2 ciphering algorithm in GSM by Harald Welte (translation by DecereBrain for the Random #029 radio show, which took place the 5th of December, 2010). The original article is published in Creative Commons BY-NC licence, and the author gently gave us the right to translate his article, to read the translation on air, and to publish the translation on the radio show website. We would like to thank him for that. Just like the original article, this translation is published under the Creative Commons BY-NC terms and conditions.

Bref historique du retrait de l’algorithme de chiffrement A5/2 de GSM

J’ai récemment voulu apprendre quand et comment A5/2 a été retiré à la fois des réseaux et des téléphones GSM. Malheureusement, il n’existait aucun article disponible en ligne traitant de ce sujet. Je me suis donc lancé dans la lecture de dizaines de rapports de rencontres et d’autres documents que j’ai pu trouver en ligne afin de retracer l’histoire de ce qui s’est passé.

Si vous ne voyez pas du tout ce dont il est question ici, l’algorithme de chiffrement A5/2 fut utilisé dans certain réseaux GSM jusque dans les années 2005-2007.

A5/2 a été défini comme un algorithme de sécurité par l’obscurité qui fut conçu, dans le plus grand secret, à la fin des années 1980. Il fut intentionnellement rendu plus faible que son frère A5/1 (qui était déjà faible). L’idée était de ne vendre des équipement A5/2 qu’aux pays du bloc de l’Est, alors que le chiffrement A5/1, un peu moins faible, était destiné à être utilisé dans les pays d’Europe de l’Ouest.

A5/2 a fait l’objet d’une ingénierie inverse, et fut dévoilé à la fin des années 1990. Il a beaucoup retenu l’attention de cryptographes tels que Ian Goldberg et David A. Wagner. Dans un papier datant de 1999, ils s’attendaient déjà à ce qu’on puisse le casser en temps réel.

Il a fallu plusieurs papiers pour qu’en août 2003 les parties prenantes des systèmes GSM (ETSI/3GPP/GSMA) finirent par réaliser qu’il y avait un problème. Et le problème était pire que ce qu’ils pensaient : puisque la génération des clés A5/1 et A5/2 était la même, une downgrade attack (NdT : une downgrade attack, ou attaque par version rétro-compatible, est une attaque qui force la victime à utiliser un protocole moins sécurisé mais dont le support est conservé pour raison de compatibilité) semi-active peut être utilisée afin de casser rétroactivement des appels enregistrés chiffrés en A5/1. L’unique solution à ce problème était de supprimer A5/2 de tous les équipement afin de s’assurer que l’attaque par downgrade ne soit plus possible.

À partir de 2004, les groupes de travail liés à la sécurité de 3GPP et GSMA pensèrent à retirer A5/2. Les années suivantes, il convainquirent leurs entités respectives (3GPP, GSMA) et leurs membres (opérateurs, fabricants d’équipement) de corriger ce problème.

Depuis cette époque, on savait qu’utiliser la même génération de clé pour des algorithmes différents permet des attaques par downgrade. Mais la génération de clé pour l’algorithme A5/3, nouveau à l’époque, resta encore la même. À présent que A5/1 a été cassé ces dernières années, même si les opérateurs déploient A5/3, le même modèle d’attaque sur A5/1 peut être réutilisé.

J’ai rédigé une frise chronologique sur le site security.osmocom.org (qui est toujours quasiment vide). En voici quelques extraits :

  • Il aura fallu attendre de 1999 à 2007 pour voir apparaître une correction à ce trou de sécurité béant. Osez appeler ça une réaction à un incident !
  • Les opérateurs nord-américain anonymes (et le PTCRB) furent les plus ardents opposants à la suppression du support de A5/2 de leurs réseaux. C’est particulièrement étrange dans la mesure où les opérateurs US auraient toujours dû avoir accès à A5/1.
  • Puisqu’un cassage de l’algorithme A5/1 (sensé être plus sécurisé) était déjà anticipé à l’époque, les spécifications de A5/3 furent publiées en 2002. Cinq ans plus tard (2007), il n’y avait virtuellement aucun support pour A5/3 parmi les constructeurs d’équipements GSM.
  • Il fallut attendre janvier 2009 pour que la GSMA commence à discuter du test de A5/3 avec les constructeurs de téléphones mobiles.
  • Il fallut attendre novembre 2009 pour voir un test d’interopérabilité entre équipements réseau A5/3 et téléphones A5/3.

Et que pouvons-nous apprendre de tout ceci ?

  • Les constructeurs d’équipements GSM et les opérateurs de téléphonie mobile n’ont montré aucun intérêt à la corrections de trous béants dans leurs systèmes de sécurité.
  • Avant cette première attaque sur A5/2, ils n’avaient jamais réfléchi à des procédures pour la mise à jour de leur système entier avec de nouveaux systèmes de chiffrement (c’est-à-dire un planning pro-actif en cas d’incident).
  • Même après le désastre A5/2, ils n’ont strictement rien appris du tout. Le même problème d’attaque par downgrade de A5/1 vers A5/2 se pose à nouveau aujourd’hui avec des attaques par downgrade de A5/3 vers A5/1. Et tout cela se passe avant même que les opérateurs aient commencé à utiliser A5/3, qui est déjà vieux de 7 ans, dans leurs réseaux de production.
  • Le groupe de travail sur la sécurité de 3GPP a suivi de très près les menaces réelles à l’encontre de la sécurité de GSM, y compris il y a dix ans. On peut le vérifier par exemple dans la Recommandation Technique 33.801. Mais personne n’a voulu l’écouter !
  • Des problèmes similaires se posent pour les algorithmes d’authentification. Il aura fallu attendre 12 ans entre les premières attaques concrètes sur COMP128v1 et le moment où GSMA chercha à le retirer.