Hack NFC - Proxmark3

De Wiki de Projets IMA
Révision datée du 7 février 2014 à 10:42 par Fromerow (discussion | contributions) (16/12/2013 : Bilan de liaison et définition des expériences à réaliser pour la caractérisation du système)

Présentation

Contexte:

La technologie RFID est de plus en plus utilisées, notamment pour les cartes bancaires ou les cartes Monéo.

Plus directement, les cartes RFID sont présentes sur le campus de Lille 1, pour le paiement des repas au Restaurant Universitaire, ou pour l'ouverture de portes sécurisées.

Leurs fiabilité est donc un enjeu crucial. Il existe cependant des techniques de hackage de ces cartes : http://www.youtube.com/watch?v=7BQDgPMF_fo


Objectif :

L'objectif de ce PFE est d'étudier la vulnérabilité de ces cartes sans contacts, et de trouver un moyen de renforcer leur sécurité.


Ennoncé :

En utilisant des systèmes Proxmark 3 (http://proxmark3.com/index.html) vous commencerez par une simple copie de carte MiFare. Cela vous permettra de prendre en main l'environnement. Vous travaillerez ensuite sur les différents aspects suivants : - Amélioration des antennes pour permettre la capture de cartes à "longues distance" (entre 2 et 10 m) - Packaging de l'appareil et des nouvelles antennes dans un sac à dos - Description de procédures de mise en oeuvre automatique - Mise en place de contre-mesure Quelques liens : http://bigbrotherawards.eu.org/Le-GIE-cartes-bancaires https://code.google.com/p/readnfccc/source/browse/#svn%2Ftrunk%2FNFCCreditCardTool

Avancement du projet

17/09/2013 : Compréhension et recherches sur le sujet

Discussions avec nos encadrants pour comprendre les enjeux du projet. Prise en main du système Proxmark3, et essais de différents logiciels. L'utilitaire proxmark3 (Client Software) peut être téléchargé à cette addresse: "proxmark3.com/downloads.html". Il contient les pilotes pour permettre à un système Windows de reconaitre le matériel, ainsi que le logiciel client Proxmark3 qui permet de communiquer avec le périphérique grâce à une invite de commandes. LF = Low Frequency (125 kHz, 132.5 kHz) HF = High Frequency (13.56 MHz) UHF = Ultra High Frequency (860 MHZ, 960 MHz) Essais de lecture d'une carte RFID.


Figure 1 : Relevé d'une carte Monéo

04/10/2013 : Lecture d'une carte NFC

Première lecture d'une carte monéo, grâce à l'antenne HF.

Commande "hf mf chk *1 ? t" pour tenter l'acces aux blocs de la carte en utilisant des clefs de base. Si le secteur X utilise la clef Y, la commande : "hf mf nested X 1 A Y d" permet de cracker l'ensemble des clés de la carte, et de les enregistrer dans un fichier "dumpkeys.bin". La commande "hf mf dump" permet ensuite de lire l'ensemble des blocs de la carte, et les enregistre dans le fichier "dumpdata.bin".

Les données lues peuvent être observées facilement avec le logiciel HxD. Si on veut comparer deux relevés, le logiciel HexCmp sera plus pratique.

Vous pouvez voir sur la Figure 1 les données présentes sur la carte Monéo utilisée :


Les données sont écrites sous forme hexadécimale sur la carte, et sont traduites par le logiciel. Certaines données sont compréhensible, comme le nom ou le numéro d'étudiant, mais la plupart des données sont cryptées.


17/10/2013 : Avancée des recherches et relevés de données d'une carte

Découverte de la commande "hf mf wrbl" permettant d'écrire un bloc de données sur une carte, et de la commande "hf mf restore" permettant de restaurer les données sur une carte à l'aide d'un ancien relevé.


Figure 2 : Comparaison (30,17€ à gauche, 33,32€ à droite)


Pendant le mois d'octobre, nous avons effectué de nombreux relevés d'une carte Monéo étant utilisée régulièrement pour le paiement de repas. Nous avons pu effectuer de nombreuses comparaisons comme la suivante, en effectuant un relevé avant et un relevé après le paiement d'un repas de 3.15€.

Figure 3 : Relevé de la carte Monéo, en rouge les octets qui changent systématiquement et en vert ceux susceptibles de changer


Les symboles surlignés sont ceux qui sont modifiés, on remarque que peu de symboles sont modifiés lors de ce prélèvement.

Comme représenté sur la Figure 3, une dizaine de relevés différents nous a permis de repérer les symboles qui ne sont jamais modifiés, ceux qui le sont parfois (encadrés en vert) et ceux qui le sont toujours (encadrés en rouge).



6/11/2013  : Réécriture d'une carte NFC

Recherches sur l'organisation des données sur une carte. Le fichier Fichier:MF1ICS50FunctSpec.pdf nous a aidé dans cette recherche. Nous avons compris que chacune de nos cartes est constituée de 16 secteurs de données. Chaque secteur est constitué de 4 blocs, chaque bloc étant lui constitué de 16 paires d'octets. Sur nos relevés, chaque ligne constitue un bloc. Le dernier bloc de chaque secteur gère les autorisations d'accès à ce secteur. Il peut être représenté sous la forme suivante: AA AA AA AA AA AA KK KK KK XX BB BB BB BB BB BB ou les 12 premiers octets constituent la clé A, les 6 suivants les conditions d'accès et les 12 derniers la clé B. L'accès à chaque secteur est donc contrôlé par deux clefs, et les conditions d'accès qui définissent si un bloc peut être lu, s'il peut être écrit, et avec quelle clé. L'interprétation des 6 octets de conditions d'accès peut être faite grâce au logiciel MiFaRe Acces Conditions téléchargeable ici: http://www.sendspace.com/file/o3frc9 Sur une carte, tous les blocs dont l'adresse se termine par 3,7,B ou F sont donc réservés aux droits d'accès. Il est donc nécessaire de porter une attention particulière à la modification de ces blocs, car en fonction des autorisations attribuées un secteur peut être interdit en lecture, et dans ce cas il ne sera plus du tout utilisable, et ni modifiable.

D'autre part il est important de noter que les 12 premiers octets de chaque carte représentent l'identifiant de la carte, (4E 46 7E 16 60 88 sur la carte utilisée ici) et qu'ils ne sont pas modifiables (mis à part pour certaines cartes NFC chinoise destinées à ce genre d'opération).

Après avoir compris tout cela nous avons pu copier les données de la carte Monéo sur une autre carte NFC, exactement à l'identique, mis à part pour l'identifiant de la carte. Cependant, lors d'un essai de paiement avec cette autre carte, il y a eu une erreur, la carte n'étant pas reconnue du fait de son identifiant.

26/11/2013 : Espionnage d'échanges RFID

Après avoir chercher pendant plusieurs heures à utiliser la commande "hf mf sniff", qui ne s'est pas révélée utile finalement, nous avons trouvé comment "écouter" les données échangées entre une carte et un lecteur, à l'aide de la commande "hf 14a snoop".

Pour ce faire on a utilisé les commandes :

-"hf 14a snoop" pour sniffer et enregistrer l'échange'

-"hf 14a list" pour avoir accès à l'enregistrement

proxmark3> hf 14a snoop

  1. db# cancelled by button
  2. db# maxDataLen=3, Uart.state=0, Uart.byteCnt=1
  3. db# Uart.byteCntMax=20, traceLen=12d, Uart.output[0]

proxmark3> hf 14a list recorded activity:

ETU     :rssi: who bytes
+      0:   0: TAG 02
+ 152797:   0: TAG 00!
+ 289126:   0: TAG 02
+ 147123:   0: TAG 01
+ 147462:   0: TAG 05!
+ 147290:   0: TAG 02
+ 441954:   0: TAG 02
+ 441954:   0: TAG 02
+ 531882:   0: TAG 04  00
+    746:   0: TAG 4e  46  7e  16  60
+   2048:   0: TAG 08  b6  dd
+ 120402:   0: TAG 02
+  21846:   0: TAG 04  00
+    744:   0: TAG 4e  46  7e  16  60
+   2052:   0: TAG 08  b6  dd
+ 142234:   0: TAG 04  00
+    746:   0: TAG 4e  46  7e  16  60
+   2048:   0: TAG 08  b6  dd
+ 142220:    :     26
+   4752:    :     26
+ 142579:    :     26
+   4751:    :     26
+ 142578:    :     26
+   4750:    :     26
+ 142576:    :     26
+   4752:    :     26
+ 142579:    :     26
+   4751:    :     26

ATQA+UID+SAK = 0004 4e467e16 08 : Nous retrouvons donc l'UID de la carte NFC qui vaut 4e467e16.

L'elementary time unit (ETU) est la durée nominale des bits utilisés dans la trame.

Le "rssi" est l'intensité du signal. Il reste ici à 0. Nous avons contacté des développeurs de Proxmark qui nous ont confirmé que c'était le cas pour eux aussi, et qu'il ne fallait pas en tenir compte.

Les échanges au début de l'enregistrement ne signifient rien de particulier, ils ne sont pas à prendre en compte.

Dans ce cas, l'antenne de la Proxmark était placée à moins de 5 cm de l'échange. Notre but est de pouvoir faire ce genre de relevés à au moins 1 m.

6/12/2013 : Etude du circuit de la Proxmark

Dans le but d'augmenter la portée du lecteur de cartes, nous nous sommes intéressés à son fonctionnement.

Nous avons pu en déduire le schéma suivant :

Figure 4 : Représentation simplifiée du fonctionnement de la Proxmark

Le FPGA de la Proxmark exécute entre autres tous les algorithmes de crack.

Le FPGA transmet le signal à émettre, aux circuits amplificateurs d'émission, par les PIN PWR_OE1, PWR_OE2, PWR_OE3 et PWR_OE4. La carte comporte deux circuits amplificateurs, notés HF et BF, suivant le type de fréquence pour lequel chacun est utilisé


Vous pourrez voir ci-contre le schéma des circuits amplificateurs :

Figure 5 : Circuits amplificateurs internes à la Proxmark


Le circuit amplificateur BF se trouve dans la partie haute du schéma, encadré en rouge, tandis que le circuit amplificateur HF est encadré en bleu.

Les 8 tampons d'émission présents sur le schéma sont chacun assimilables à une capacité C0. Des recherches dans la datasheet du composant nous ont permis de connaître la valeur de cette capacité, qui est de 8pF.


L'impédance de sortie de la Proxmark peut donc être simplifie de la façon suivante :

Cadre rouge : on a 4 capacités induites par les tampons d'émission, donc 4 * C0 = 4*8 pF = 32 pF et une résistance de 33 Ohms

Cadre bleu : on a 4 capacités induites par les tampons d'émission, donc 3 * C0 = 3*8 pF = 24 pF et une résistance de 33 Ohms

Cadre vert : on a 4 capacités induites par les tampons d'émission, donc 1 * C0 = 1*8 pF = 8 pF et une résistance de 10 KOhms

En mettant en parallèle les impédances de ces trois parties du circuit, on peut déduire la valeur de l'impédance totale de sortie de la Proxmark, qui est de 21–208j.


16/12/2013 : Bilan de liaison et définition des expériences à réaliser pour la caractérisation du système

Nous avons réalisé un premier bilan de liaison du système, peu précis, en attente des expériences à venir.

Figure 6 : Premier bilan de liaison

Sur ce bilan, on retrouve en rouge le chemin d'émission et en vert le chemin de réception.

Nous avons pris contact avec M. Royes, représentant de la société Rysc Corp créatrice de notre antenne HF. D'après lui la société a conçu une antenne compatible avec la Proxmark3, mais sans en effectuer de relevés de caractéristiques.

Nous avons aussi pris rendez-vous avec M. Ducourneau, Responsable de la Plate-Forme Electronique, Electrotechnique, Instrumentation (EEI) de Polytech, afin de définir les expériences à effectuer pour la caractérisation de l'antenne fournie et le dimensionnement de l'amplificateur.

Nous avons alors défini les expériences à réaliser :

Expérience prévue avec une antenne :

=> Mesure de l'intensité traversant l'antenne.

=> Mesure du coefficient de réflexion S(1,1), à l'analyseur de réseau vectoriel avant amplification puis après amplification. Cette étape est nécessaire car à 13,56 Mhz aucune antenne de petite taille n'est vraiment adaptée. Le but du projetétant de dissimuler le système, l'antenne ne devra pas dépasser 50 cm. Il faut donc partir du principe que quelque soit l'antenne, elle ne pourra pas être adaptée. L'idée est de mesurer son coefficient de réflexion à 13,56 Mhz, pour s'assurer que l'antenne conçue ne rejette pas la plus grande partie du signal. Si ce n'est pas le cas, il faudra s'intéresser à une antenne patch, plus directive et de plus grande portée.

Expérience prévue avec deux antennes (identiques) :

=> Mesure du gain : elle nous permettra de calculer la puissance P1 à la sortie de l'antenne afin de compléter notre bilan de liaison.

=> Mesure des pertes de 0 à 1,5 m, avec un pas de 0,10 m. Cela nous permettra de quantifier les pertes dans l'air.

Nous avons à partir de là pu définir le matériel à commander pour réaliser ces expériences.


6/01/2014 : Modélisation du circuit d'amplification à réaliser

Le signal de sortie de la Proxmark étant d'environ 0,2 W, nous aimerions l'amplifier de façon à obtenir un signal plus proche de 7,5 W. Pour cela, nous avons pensé à modifier si possible la valeur d'un registre du FPGA qui permettrait de gérer la puissance du signal de sortie. Cependant, en parcourant les différents fichiers du programme FPGA, nous n'avons pas trouvé de tel registre.

Documentation

Analyse des données :

[CEPS Technical Specification]

Circuit Proxmark3

[1]

/!\ TWIKI EN COURS DE MISE A JOUR /!\