La sécurité des téléphones portables GSM

Tout téléphone portable GSM est équipé d'une carte à puce asynchrone baptisée « SIM » (Subscriber Identification Module), élément essentiel de l'architecture sécuritaire du système. Analyse.

Reposant sur des concepts radicalement différents de ceux adoptés par la communauté bancaire, la robustesse de cette application mondialement populaire ne pouvait pas manquer d'être mise à l'épreuve, tant par des pirates en puissance que par des universitaires aux motivations purement théoriques. Le recul est maintenant suffisant pour commencer à tirer les leçons de cette véritable « enquête publique »?

Identification, authentification, cryptage
Voici donc les trois missions essentielles qui sont dévolues aux cartes SIM que les opérateurs de téléphonie mobile confient à leurs clients, et qui matérialisent les liens contractuels et comptables entre les deux parties. Cela sans oublier un rôle de stockage de très nombreuses données personnelles comme les répertoires de numéros de téléphone, les mini-messages et les paramétrages en tous genres.
Si la plupart des mobiles actuellement en circulation n'étaient pas « verrouillés » (on dit aussi « SIMlockés »), on pourrait en principe s'approprier n'importe quel téléphone GSM en y insérant simplement sa carte SIM personnelle. Un mécanisme relativement simple de code « PIN » permet, facultativement, d'empêcher qu'un téléphone et/ou une carte SIM ne puissent être utilisés par n'importe qui en cas de perte ou de vol.
À côté de cette protection purement locale (off-line), la carte SIM intervient dans des mécanismes sécuritaires beaucoup plus élaborés, car opérant « on-line ». Chaque carte SIM contient ainsi un numéro matricule (IMSI ou « International Mobile Subscriber Identity »), qui l'identifie de façon unique parmi tous les clients de tous les opérateurs du monde entier (plus de 700 millions début 2001). On peut le comparer à un « numéro de compte », puisque c'est lui qui permet de savoir à quel client facturer les communications et autres services rendus.
Comme cet identifiant est transmis, en clair et par radio, le moins souvent possible mais à l'entière discrétion du réseau, le risque d'usurpation ne peut pas être traité par le mépris (les systèmes de radiotéléphonie analogique en ont suffisamment fait les frais !). Une procédure d'authentification cryptographique vient par conséquent doubler ce système d'identification si vulnérable. Celle-ci repose sur le principe « challenge-response », autrement dit sur le concept de chiffrement « zero knowledge proof » (preuve sans connaissance). En clair, il s'agit pour la carte qui a déjà décliné son IMSI, de prouver qu'elle contient aussi une valeur secrète que l'opérateur y a placée, mais sans transmettre celle-ci sur la voie radio.

L'algorithme
En pratique, l'opérateur qui émet une carte SIM y enregistre un IMSI et une clef secrète baptisée Ki, tout en confiant ces deux valeurs à son propre « centre d'authentification ». Tant la carte que le centre d'authentification sont capables d'exécuter un même calcul cryptographique « A3/A8 », dont les opérandes sont Ki (16 octets) et une valeur aléatoire (16 octets également), et qui délivre un résultat tenant sur 12 octets. Lorsqu'un mobile s'annonce au réseau en déclinant son IMSI (faute d'une identité temporaire « TMSI » pouvant en tenir lieu, nous y reviendrons), l'opérateur qui a émis la carte SIM recherche la clef Ki correspondante dans la base de données de son centre d'authentification. Il génère alors une valeur aléatoire de 16 octets (RND), puis la transmet au mobile. La carte SIM exécute l'algorithme à partir de la clef Ki qu'elle contient, et du RND que le mobile vient de recevoir. Les quatre premiers octets du résultat constituent une « signature » baptisée SRES, que le mobile renvoie au réseau. Pendant ce temps, le centre d'authentification exécute le même algorithme à partir des mêmes données, et reconstitue donc bien évidemment le même résultat.

Un second algorithme
Si la signature reçue correspond au SRES calculé localement, alors l'opérateur considère que la carte SIM est authentique, et confirme l'inscription du mobile sur le réseau, avec ou sans restrictions quant aux services qu'il l'autorise à utiliser (cela dépend de la formule tarifaire souscrite).
Les huit derniers octets du résultat du calcul cryptographique sont, pour leur part, baptisés « Kc » et vont servir de « clef de session » à un second algorithme, connu sous l'appellation « A5 ».
Celui-ci est dédié au seul cryptage des communications (parole et données) entre le mobile et le réseau, cela au moins jusqu'à la prochaine demande d'authentification. Il faut savoir que chaque opérateur peut déclencher un processus d'authentification (ou simplement d'identification) aussi souvent qu'il le souhaite, y compris en cours de communication. La fréquence de ces contrôles est très variable d'un opérateur à un autre, un intervalle de temps minimum étant même imposé aux opérateurs de certains pays (au moins toutes les minutes, par exemple, aux Pays-Bas). Il est bien tentant de voir, dans une telle obligation légale, le désir des autorités de pouvoir détecter ou même localiser le plus finement possible les téléphones portables en « veille », qui n'émettraient autrement aucun signal repérable.

Premières constatations
Il est intéressant de se livrer à une analyse critique, aussi bien théorique que pratique, d'ailleurs, d'un arsenal cryptographique dont les missions sont aussi diverses (et parfois contradictoires !) que déjouer la fraude, assurer la confidentialité des communications, faciliter la surveillance des mobiles, ou permettre l'utilisation de réseaux partenaires à l'étranger.
La première observation qui s'impose est que l'algorithme A3/A8 calcule un résultat dont le nombre de bits est inférieur à celui des deux opérandes qui lui sont soumis. Cela n'a rien d'exceptionnel (l'algorithme « Secure Hash » SHA-1 repose sur ce même principe de génération d'un « condensé »), mais il en résulte nécessairement qu'un même résultat peut être obtenu à partir de plusieurs couples d'opérandes distincts. Bien entendu, la probabilité est infime d'obtenir les bonnes valeurs de SRES et de Kc à partir d'une clef Ki incorrecte, et quand bien même cela arriverait, cela ne donnerait accès au réseau que pour un temps très court. Avec seulement quatre octets (soit à peine plus de quatre milliards de possibilités !), le risque n'est pas totalement négligeable de tomber « par hasard » sur une signature SRES correcte, mais rien d'intéressant ne pourra être fait sans la bonne clef Kc. Tout irait pour le mieux dans le meilleur des mondes si tous les opérateurs avaient pris la peine de se doter d'un algorithme cryptographique à toute épreuve.
En effet, la spécification GSM est ainsi faite que chaque opérateur a toute latitude pour utiliser un algorithme A3/A8 «propriétaire » (ou à l'extrême limite plusieurs algorithmes distincts). L'algorithme « COMP128 », dont le détail figure dans la partie réputée confidentielle des spécifications, n'est fourni qu'à titre d'exemple. La loi du moindre effort aidant, la plupart des opérateurs ont sauté à pieds joints sur cet algorithme « par défaut », à l'exception remarquable des Pays-Bas (encore eux !) et? de l'Allemagne, qui est curieusement le pays d'origine du COMP128 ! En France, il semblerait qu'un seul des trois opérateurs GSM se soit donné le mal de chercher un algorithme plus robuste.

Une faille
Il faut, en effet, appeler un chat un chat : dès 1998, des universitaires américains mettaient en évidence de sérieuses failles dans la méthode mathématique utilisée, prouvant ainsi la faisabilité du « clonage » de cartes SIM. Il est édifiant, suggèrent-ils, de solliciter l'algorithme de façon à provoquer des « collisions », c'est-à-dire l'occurrence de couples d'opérandes distincts menant à un résultat identique. Il a été démontré que des calculs relativement simples permettent de découvrir deux octets de la clef Ki (normalement inaccessible en lecture) lors de chaque collision. Cela étant, il semblerait que la totalité de la clef puisse être ainsi reconstituée en moins de 200 000 sollicitations d'une carte SIM basée sur l'algorithme COMP128. On peut trouver, sur l'internet, un logiciel du domaine public baptisé SIMscan, capable de faire le travail en moins de vingt heures à l'aide d'un lecteur de cartes à puce compatible avec celui décrit dans ce même numéro. Bien entendu, les opérateurs ne pouvaient pas manquer de réagir !
Faute de pouvoir changer radicalement d'algorithme en « rappelant » toutes les cartes SIM déjà émises, rien ne leur interdisait de modifier leurs nouvelles cartes de façon à ce qu'elles se bloquent au bout d'un nombre d'exécutions de l'algorithme insuffisant pour leur faire « avouer » Ki en totalité. Bien entendu, cela suppose qu'eux-mêmes n'abusent pas de la procédure d'authentification, sous peine d'avoir à remplacer (gratuitement ?) les cartes un peu trop fréquemment. On retiendra en tout cas qu'il serait prudent de se borner à expérimenter SIMscan avec des cartes émises avant 1998, et autant que possible périmées. Reste tout de même à vérifier que la clef ainsi déterminée est bien la bonne.

Le programme
Il circule également sur l'internet un code source en langage C, écrit par les universitaires américains qui ont découvert « le pot aux roses ». Compilé en un fichier Comp128.EXE, il permet de simuler l'algorithme sur un simple PC, à partir de deux opérandes de 16 octets librement choisis. L'un d'eux (Ki) sera naturellement la clef découverte avec SIMscan, tandis que l'autre pourra être l'équivalent hexadécimal de la chaîne ASCII « ABCDEFGHIJKLMNOP » (soit 0x414243444546 4748494A4B4C4D4E4F50). On notera soigneusement le résultat obtenu (12 octets), avant de soumettre la carte elle-même au petit programme que voici :


#Include CARDUTIL.DEF
#Include COMMERR.DEF
Declare Command &HA0 &HA4 SL(S$,Disable Le)
Declare Command &HA0 &H88 GSM(S$,Disable Le)
Declare Command &HA0 &HC0 GETR(P$)
CLS:Call WaitForCard
ResetCard:Call CheckSW1SW2:PRINT
CALL SL(CHR$(&H7F)+CHR$(&H20))
IF SW1=&H6E THEN EXIT
CALL GSM("ABCDEFGHIJKLMNOP")
IF SW1SW2<>&H9F0C THEN EXIT
CALL GETR(P$,Le=&H0C)
IF SW1SW2<>&H9000 THEN EXIT
FOR F=1 TO LEN(P$)
M=ASC(MID$(P$,F,1))
M$=HEX$(M):IF Len(M$)=1 Then M$="0"+M$
PRINT M$;"";
NEXT F:PRINT
PRINT:Call WaitForNoCard

Écrit en ZCBasic (le langage de programmation de la BasicCard - lire Virus 18), il peut être exécuté après compilation en un exécutable A3A8.EXE. Pour l'expérimenter (en mode console de Windows 32 bits) avec le lecteur de cartes « CyberMouse » du kit BasicCard, on pensera à taper d'abord SET ZCPORT=1 si celui-ci est branché sur COM1:, SET ZCPORT=2 s'il est connecté à COM2:, ou SET ZCPORT=101 si l'on préfère se servir d'un quelconque lecteur compatible PC/SC.
Une autre approche consisterait à utiliser notre programme ISO.EXE, et le lecteur pour cartes asynchrones décrit dans ce même numéro. Voici un exemple de ce que cela pourrait donner :


Presser ESCape pour quitter
 <
 < 3B 82 00 55 19
 > A0 A4 00 00 02
 < A4
 > 7F 20
 < 9F 17
 > A0 88 00 00 10
 < 88
 > 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50
 < 9F 0C
 > A0 C0 00 00 0C
 < C0 7D 7E EE 28 B0 3D 6A 5E FE CB 0C 00 90 00
 >

Sur la dernière ligne devraient s'afficher, entre C0 et 90 00, les douze (mêmes ?) octets que ceux obtenus avec COMP128.EXE, C.Q.F.D.
Rien n'interdit bien évidemment de se livrer à cette même expérience sans faire avouer auparavant Ki à la carte (car c'est tout de même très vilain, et, nous l'avons vu, un tant soit peu périlleux !). Il n'échappera alors certainement pas à un œil averti que le résultat obtenu se termine par dix bits à 0 (un octet 00h précédé d'un octet dont les deux derniers bits sont eux-mêmes à 0).
Si c'est systématique (et tel est apparemment le cas...), cela trahit indiscutablement le fait que la force de cryptage de l'algorithme A5 n'est plus que de 54 bits au lieu des 64 prévus par la spécification d'origine, autrement dit 1024 fois moindre ! Or, les cryptages à 56 bits (quatre fois plus solides) sont unanimement considérés comme « faibles »...
Ce délabrement volontaire de la sécurité des communications ne présentant guère d'intérêt pratique pour les opérateurs, il est bien tentant d'y voir la subtile influence de certaines agences friandes d'écoutes en tous genres... « Echelon », cela ne vous dit rien ? C'est tellement plausible qu'un fabricant aussi sérieux que Rohde & Schwartz fabrique un portable anti-écoutes baptisé « TopSecGSM », à l'intention des utilisateurs gouvernementaux, qui bénéficient alors d'un cryptage à 128 bits !

De quoi tourner en bourrique !
Afin d'éviter de transmettre par trop souvent l'IMSI en clair, les réseaux affectent une identité temporaire (TMSI) à chaque utilisateur qu'ils ont identifié avec certitude. Tant que cela ne fera naître aucun doute, TMSI sera ainsi utilisé en lieu et place d'IMSI. Aussi curieux (et imprudent !) que cela puisse paraître, TMSI réside dans un fichier (LOCI) où il est possible de lire et écrire librement pour peu que l'on désactive au préalable le code PIN de la carte (et cela se fait très facilement à partir du menu du téléphone).
Une « bonne blague » consiste ainsi à lire LOCI dans une carte qui vient de servir, et à recopier cette valeur dans une carte (de préférence périmée) du même opérateur, d'un de ses concurrents, voire d'un réseau étranger. Si un mobile (non verrouillé) équipé de la carte ainsi « clonée » est mis en route dans la foulée, il cherchera presque toujours à s'inscrire sur le réseau ayant attribué TMSI. En cas de succès de l'opération, le nom de cet opérateur apparaîtra sur l'écran, et y restera peut-être même jusqu'à ce que le réseau initie une procédure d'authentification qui, bien entendu, échouera. Tout l'intérêt de l'expérience consiste à observer au bout de combien de temps la carte se trouvera ainsi rejetée par le réseau. Selon les opérateurs, cela peut aller d'à peine quelques secondes jusqu'à 23 heures. À moins, bien sûr, que l'on ne cherche à téléphoner ou à recevoir un appel entre-temps.

Programme de clonage
Le petit programme que voici, lui aussi développé en ZCBasic (et compilé en un fichier
CLONE.EXE) simplifie au maximum l'opération de « clonage » : il suffit d'introduire tour à tour la carte « modèle », puis le « cobaye », dans le lecteur CyberMouse ou PC/SC.


#include CARDUTIL.DEF
#include COMMERR.DEF
Declare Command &HA0 &HA4 SL(S$,Disable Le)
Declare Command &HA0 &HB0 RD(S$)
Declare Command &HA0 &HD6 WR(S$,Disable Le)
Public LOCI$ As String
Public FPLMN$ As String
CLS:Print:Print"LECTURE DE LA CARTE SIM"
Call WaitForCard
ResetCard:Call CheckSW1SW2:Print
Call SL(CHR$(&H3F)+CHR$(&H00))
IF SW1<>&H9F Then Print"PAS UNE SIM !":EXIT
Print"Lecture de LOCI";
Call SL(CHR$(&H3F)+CHR$(&H00))
Call SL(CHR$(&H7F)+CHR$(&H20))
Call SL(CHR$(&H6F)+CHR$(&H7E))
S$="":S=RD(S$,Le=11):Call CheckSW1SW2
LOCI$=S$:Print
Print"Lecture de FPLMN";
Call SL(CHR$(&H3F)+CHR$(&H00))
Call SL(CHR$(&H7F)+CHR$(&H20))
Call SL(CHR$(&H6F)+CHR$(&H7B))
S$="":S=RD(S$,Le=12):Call CheckSW1SW2
FPLMN$=S$:Print
Print:Call WaitForNoCard
Print:Print"RECOPIE"
Call WaitForCard
ResetCard:Call CheckSW1SW2:Print
Print»Ecriture de LOCI";
S$=LOCI$
Call SL(CHR$(&H3F)+CHR$(&H00))
Call SL(CHR$(&H7F)+CHR$(&H20))
Call SL(CHR$(&H6F)+CHR$(&H7E))
Call WR(S$):Call CheckSW1SW2:Print
Print"Ecriture de FPLMN";
S$=FPLMN$
Call SL(CHR$(&H3F)+CHR$(&H00))
Call SL(CHR$(&H7F)+CHR$(&H20))
Call SL(CHR$(&H6F)+CHR$(&H7B))
Call WR(S$):Call CheckSW1SW2:Print
Print

En plus de LOCI, il « écrase » également FPLMN, la liste des réseaux interdits, qui risquerait autrement de se remplir très vite de codes destinés à faire cesser au plus tôt cette aimable plaisanterie.
Patrick Gueulle

Tous les ouvrages de l'auteur

Vous voulez soutenir une information indépendante ? Rejoignez notre Club privé !

[homepage] [RSS] [archives]
[contact & legal & cookies] [since 1997]