Utiliser Mifare Ultralight C avec RC522 sur Arduino : 3 étapes

2024 Auteur: John Day | [email protected]. Dernière modifié: 2024-01-30 09:05

L'utilisation de la technologie RFID pour identifier les porteurs de cartes ou pour autoriser une action (ouvrir une porte, etc.) est une approche assez courante. En cas d'application DIY, le module RC522 est largement utilisé car il est assez bon marché et il existe beaucoup de code pour ce module.

Dans la plupart des cas, l'UID de la carte est utilisé pour « identifier » le titulaire de la carte, et les cartes Mifare Classic sont utilisées car elles sont bon marché et souvent incluses lors de l'achat d'un module RC522.

Mais comme vous le savez peut-être, le système Mifare Classic est piraté depuis quelques années et il n'est plus considéré comme sûr. Le système de cryptage Crypto1 utilisé par les cartes Classic peut être surmonté et ce sont des cartes réinscriptibles où les données et un UID peuvent être reprogrammés (cartes magiques).

Ainsi, pour toute application liée à la sécurité, l'utilisation de cartes Mifare Classic n'est pas recommandée ! Il en va de même pour (la plupart) des systèmes NTAG et Mifare Ultralight

Le choix est donc soit d'utiliser un système professionnel, soit d'essayer d'utiliser un système RFID plus sécurisé. Les systèmes disponibles sont Mifare Ultralight C, Mifare DESFire et Mifare Plus. Comme de nombreux systèmes professionnels utilisent ces systèmes plus sécurisés, il n'existe pratiquement aucune solution pour la communauté des bricoleurs (il existe une solution DESFire basée sur Teensy, basée sur la carte de dérivation PN523 plus chère). De plus, les cartes DESFire sont assez chères. Le défi était donc de trouver une solution meilleure et moins chère.

La solution présentée offre un accès complet aux cartes Mifare Ultralight "C" bon marché à l'aide du module DIY chinois bon marché RC522. Sur la base de ce code, le Mifare Ultralight C sécurisé peut être utilisé dans des applications de bricolage.

Étape 1: Conditions préalables

Bien que le RC522 soit bien conçu, il est dans la plupart des cas mal construit car certains composants sont mal dimensionnés. Cela conduit à la mauvaise réputation du module qui a une faible sensibilité et tous les types de cartes ne seront pas identifiés. Surtout le Mifare Ultralight C ne sera ni identifié ni possible de lire les cartes.

Le problème principal est la spécification des inductances L1 et L2. Comme décrit sur https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Juste en remplaçant ces inducteurs par des inducteurs appropriés, par ex. FERROCORE CW1008-2200 soudainement le RC522 montre quel est son vrai potentiel.

Donc, avant d'essayer le code donné, vous DEVEZ REMPLACER les inducteurs. Cela ne fonctionnera tout simplement pas avec les inducteurs pré-installés !

L'arrière-plan de tout cela est que les cartes Ultralight C sont assez gourmandes en énergie. Cette énergie est fournie par le champ RF RC522. En raison du faible ampérage des inducteurs, le champ d'énergie n'est tout simplement pas assez puissant pour alimenter l'Ultralight C. D'autres cartes comme la Mifare Classic ont juste besoin de moins d'énergie et fonctionnent donc de manière assez stable.

Étape 2: Comment ça marche ?

Alors après avoir modifié le module RC522, comment pouvez-vous utiliser le Mifare Ulralight C pour votre application ?

L'astuce est que Mifare Ultralight C prend en charge une authentification par mot de passe basée sur le chiffrement 3DES. En utilisant ce mot de passe, le contenu de la carte peut être rendu « en lecture seule » ou complètement invisible pour un utilisateur non autorisé.

Pour utiliser cette protection par mot de passe, le mot de passe doit être écrit sur la carte et les pages doivent être protégées. Une fois cela fait, vous pouvez vérifier la carte dans votre application en demandant simplement une authentification basée sur un mot de passe ou en plus des données prêtes à partir d'une zone protégée. Ce n'est que si cela réussit que vous savez que vous pouvez faire confiance à l'UID fourni sur la carte.

Attention: sans l'authentification par mot de passe, vous ne pouvez toujours pas faire confiance à une carte Mifare Ultralight C, car il existe également des « cartes magiques » qui simulent l'Ultralight C.

Chaque carte indépendante de la technologie (si dans la fréquence correcte) répondra avec son UID lorsqu'elle est alimentée par le champ RF et demandera de s'identifier. De plus, ils fournissent une valeur SAK fournissant des informations minimales sur le type de carte présent. Malheureusement, tous les Mifare Ultralight et NTAG s'identifient comme le type syme (SAK=0x00), y compris le Mifare Ultralight C. Ainsi, lors de l'interrogation des cartes, au moins la valeur SAK de 0x00 donnera un indice qu'il pourrait y avoir un Ultralight C sur le lecteur.

Pour s'assurer qu'il s'agit d'un Ultralight C, une demande d'authentification cryptée peut être envoyée à la carte. S'il ne s'agit PAS d'une carte Ultralight C, cette demande ne sera pas comprise et la réponse sera un NAK (not-acknolege).

S'il s'agit d'une carte Ulralight C, vous obtiendrez une réponse de 8 octets. Ces 8 octets sont un nombre aléatoire « B » (RndB) crypté par la clé stockée sur la carte à l'aide du chiffrement 3DES.

Ce RndB chiffré doit être déchiffré en utilisant la même clé dans le programme. Ce nombre aléatoire est alors légèrement modifié (rotation d'un octet → l'octet 1 sera déplacé vers l'octet 8 et tous les autres octets sont poussés d'un octet plus bas, puis appelés RndB'). Le programme génère ensuite lui-même un nombre aléatoire "A" de 8 octets (RndA) et attache ce RndA au RndB' modifié. Celui-ci est à nouveau crypté à l'aide de la clé et envoyé à la carte.

La carte décrypte le message et vérifie si RndB' correspond au RndB précédemment généré sur la carte. S'ils correspondent, la carte sait maintenant que le programme connaît la clé.

À ce stade, le programme ne sait toujours pas si la carte connaît la clé et est donc digne de confiance ou non. Pour ce faire, la carte fait maintenant pivoter le RndA déchiffré d'un octet, puis crypte ces octets à l'aide de la clé et les renvoie.

Le programme déchiffrera alors la réponse de la carte et vérifiera si le RndA original et le RndA répondu correspondent. ALORS UNIQUEMENT, les deux entités (programme et carte) savent qu'elles partagent la connaissance de la même clé.

Ce processus ne sert qu'à s'authentifier. Toutes les communications ultérieures se font toujours en « texte clair ».

Bien qu'il existe des cartes "magic Ultralight C" où l'UID peut être modifié, la clé elle-même ne peut pas être obtenue à partir de la carte et le chiffrement 3DES est assez sécurisé. La clé est une clé de 16 octets, donc une approche par force brute pour obtenir la clé prendra un certain temps.

Comme indiqué, la communication avant et après l'authentification est toujours en texte clair (c'est-à-dire non cryptée). Lors de l'écriture d'une nouvelle clé sur la carte, le contenu de la clé peut être détecté en utilisant le bon équipement. Veuillez donc écrire la clé uniquement dans un environnement sécurisé et garder la clé secrète.

Lors de l'utilisation de la carte Ultralight C

La carte Ultralight C intègre plusieurs fonctions de sécurité:

1. Mémoire de programmation unique (OTP). Dans cette zone, des bits peuvent être écrits, le bus n'est pas supprimé.
2. Un compteur unidirectionnel 16 bits. Ce compteur ne peut s'incrémenter qu'une fois accédé.
3. Une protection « en écriture » ou en « lecture/écriture » des pages en mémoire. Seulement si authentifiées avec la clé, ces pages peuvent être lues ou modifiées.
4. Un gel/blocage de pages individuelles pour se protéger contre toute modification.

Ni l'utilisation d'OTP, le compteur 16 bits ni l'utilisation du bit de blocage ne sont implémentés dans le code donné, mais peuvent facilement être implémentés sur la base des informations fournies dans https://www.nxp.com/docs/en/data- feuille/MF0ICU2.pd…

La protection par clé étant indispensable à l'utilisation du Mifare Ultralight C, toutes les fonctions utiles sont présentes.

Toutes les commandes sont utilisées dans le moniteur série avec « nouvelle ligne uniquement » et avec 115 200 bauds

• "auth 49454D4B41455242214E4143554F5946" demandera une authentification avec la clé donnée (dans ce cas la clé Mifare Ultralight C standard)
• "dump" videra le contenu de la carte dans la mesure où ils sont visibles. Dans le cas où les pages sont protégées par la clé, ces pages peuvent ne pas être visibles jusqu'à une authentification précédente avec la clé. Dans les deux premières colonnes, il est indiqué si les pages sont verrouillées ou l'accès est restreint.
• "newKey 49454D4B41455242214E4143554F5946" écrira une nouvelle clé sur la carte. La clé est écrite dans les pages 44 à 47. Cela ne fonctionnera que si ces pages ne sont ni verrouillées ni protégées sans authentification préalable.
• "wchar 10 hello world" écrira "hello world" à partir de la page 10. Encore une fois, seuls les travaux des pages ne sont ni verrouillés ni protégés sans authentification préalable. Lorsque vous essayez d'écrire au-dessus de la page 39 ou en dessous de la page 4, cela demandera un l'erreur ou les données sont ignorées car ces pages ne sont pas de la mémoire utilisateur.
• "Whex 045ACBF44688" écrira les valeurs Hex directement dans la mémoire, les conditions précédentes s'appliquent.
• « protect 30 » protège toutes les pages à partir de la page 30. Selon l'autorisation, ces pages ne peuvent alors être modifiées ou lues qu'après une authentification préalable avec clé. L'utilisation de « protect » avec des valeurs supérieures à 47 définira toutes les pages sur « non protégées » Y COMPRIS LA CLÉ aux pages 44-47 (qui ne peuvent être modifiées mais pas lues). Afin d'éviter d'altérer la clé, la protection doit au moins commencer à la page 44.
• « setpbit 0 » définit le bit de protection et décide si les pages protégées sont en lecture seule (« setpbit 1 ») ou ne peuvent être ni lues ni écrites (« setpbit 0 ») sans une authentification préalable avec clé.

Toutes les commandes ne peuvent pas être utilisées immédiatement après la détection de la carte. Un "vidage" avant une autre commande aide toujours.

Étape 3: Important

1. Le programme fait la différence entre les types Ultralight en lisant les pages 43 et 44. Si la page 43 est lisible et la page 44 non, il s'agit probablement d'un Ultralight C. MAIS, si vous protégez la page 43 en lecture/écriture, la carte n'est plus reconnue comme Ultralight C (n'a aucun effet sur quoi que ce soit) L'identification correcte de l'Ultralight doit se faire via l'authentification avec clé (je n'ai pas implémenté cela pour des raisons de stabilité).
2. Avant d'utiliser les commandes « setpbit » et « protect », la commande « dump » doit être utilisée, sinon l'état de protection des pages ne sera pas connu.
3. Si vous protégez en « lecture/écriture » les premières pages de votre carte, cela ne fonctionnera plus avec ce programme car la première page est lue en permanence pour voir s'il y a encore une carte présente. Comme les deux premières pages sont de toute façon en lecture seule (l'UID y est stocké), il n'y a aucun sens à les protéger.

Problèmes de stabilité

Ce code utilise la bibliothèque "standard" RC522 pour Arduino et une bibliothèque 3DES de https://github.com/Octoate/ArduinoDES. Alors que la bibliothèque RC522 est assez couramment utilisée, la bibliothèque 3DES semble moins répandue et doit être installée manuellement.

Le code a été testé sur un Arduino Uno. Mais en l'écrivant, j'ai rencontré de nombreux problèmes étranges en ce qui concerne la stabilité. D'une manière ou d'une autre, soit mes compétences en programmation ne sont pas très bonnes, l'une des bibliothèques utilisées est instable ou le mélange des bibliothèques n'est pas une bonne idée.

Veuillez garder cela à l'esprit lorsque vous utilisez le code !!!

Le changer ou n'en utiliser que certaines parties peut entraîner un comportement étrange comme un plantage, l'impression de choses étranges ou l'obtention de délais d'attente ou de NAK lors de la lecture à partir de la carte. Cela peut arriver n'importe où dans le code (cela m'a coûté de nombreuses heures de débogage). Si vous en trouvez la ou les raisons, merci de me donner un indice.