Utilizarea Mifare Ultralight C Cu RC522 pe Arduino: 3 pași

2024 Autor: John Day | [email protected]. Modificat ultima dată: 2024-01-30 11:41

Folosirea tehnologiei RFID pentru a identifica deținătorii de carduri sau pentru a autoriza să facă ceva (deschide o ușă etc.) este o abordare destul de comună. În cazul aplicației DIY, modulul RC522 este utilizat pe scară largă, deoarece este destul de ieftin și există o mulțime de cod pentru acest modul.

În majoritatea cazurilor, UID-ul cardului este utilizat pentru a „identifica” titularul cardului, iar cardurile Mifare Classic sunt utilizate deoarece sunt ieftine și sunt adesea incluse la cumpărarea unui modul RC522.

Dar, după cum știți, sistemul Mifare Classic a fost piratat de câțiva ani și nu mai este considerat sigur. Sistemul de criptare Crypto1 utilizat de cardurile Classic poate fi depășit și sunt carduri rescriptibile în care datele pot fi reprogramate cu un UID (cărți magice).

Deci, pentru orice aplicație relevantă pentru securitate, utilizarea cardurilor Mifare Classic nu este recomandată! Același lucru este valabil pentru (majoritatea) sistemelor NTAG și Mifare Ultralight

Deci, alegerea este fie utilizarea unui sistem profesional, fie încercarea de a utiliza un sistem RFID mai sigur. Sistemele disponibile sunt Mifare Ultralight C, Mifare DESFire și Mifare Plus. Deoarece există multe sisteme profesionale care utilizează aceste sisteme mai sigure, pentru comunitatea DIY nu există practic soluții (există o soluție DESFire bazată pe Teensy, care se bazează pe placa mai scumpă PN523). În plus, cardurile DESFire sunt destul de scumpe. Deci provocarea a fost să găsim o soluție mai bună și mai ieftină.

Soluția prezentată oferă acces complet la cardurile ieftine Mifare Ultralight „C” folosind modulul DIY ieftin din China RC522. Pe baza acestui cod, Mifare Ultralight C sigur poate fi utilizat în aplicații DIY.

Pasul 1: Condiții prealabile

Deși RC522 este bine proiectat, în cele mai multe cazuri este slab construit, deoarece unele componente sunt slab dimensionate. Acest lucru duce la proasta reputație a modulului că are o sensibilitate scăzută și nu toate tipurile de cărți vor fi identificate. În special Mifare Ultralight C nu va fi nici identificat și nici nu va fi posibil să citiți cărțile.

Principala problemă este specificarea inductoarelor L1 și L2. Așa cum este descris pe https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Doar prin înlocuirea acestor inductoare cu altele adecvate, de ex. FERROCORE CW1008-2200 brusc RC522 arată care este potențialul său real.

Deci, înainte de a încerca codul dat, TREBUIE SĂ ÎNLOCUIȚI inductoarele. Pur și simplu nu va funcționa cu inductoarele preinstalate!

Fundalul tuturor acestor lucruri este că cărțile Ultralight C sunt destul de înfometate de energie. Această energie este furnizată de câmpul RF RC522. Datorită amperajului scăzut al inductoarelor, câmpul energetic nu este suficient de puternic pentru a alimenta Ultralight C. Alte cărți precum Mifare Classic necesită doar mai puțină putere și, prin urmare, funcționează destul de stabil.

Pasul 2: Cum funcționează?

Deci, după modificarea modulului RC522, cum puteți utiliza Mifare Ulralight C pentru aplicația dvs.?

Trucul este că Mifare Ultralight C acceptă o autentificare prin parolă bazată pe cifrul 3DES. Prin utilizarea acestei parole, conținutul cardului poate fi făcut „numai în citire” sau complet invizibil pentru un utilizator neautorizat.

Pentru a utiliza această protecție prin parolă, parola trebuie scrisă pe card și paginile trebuie protejate. După ce ați terminat, puteți verifica cardul în aplicația dvs., fie prin simpla solicitare a unei autentificări bazate pe parolă, fie date pregătite suplimentar dintr-o zonă protejată. Doar dacă acest lucru are succes, știți că puteți avea încredere în UID-ul furnizat pe card.

Atenție: fără autentificarea bazată pe parolă, încă nu vă puteți încrede într-o carte Mifare Ultralight C, deoarece există și „cărți magice” care simulează Ultralight C.

Fiecare card independent de tehnologie (dacă are frecvența corectă) va răspunde cu UID-ul lor atunci când este alimentat de câmpul RF și va solicita să se identifice. În plus, acestea oferă o valoare SAK, oferind informații minime despre tipul de card prezent. Din păcate, toate Mifare Ultralight și NTAG se identifică ca tip syme (SAK = 0x00), inclusiv Mifare Ultralight C. Așadar, atunci când sunați cărți, cel puțin valoarea SAK 0x00 va da un indiciu că ar putea exista un ultralight C pe cititor..

Pentru a vă asigura că este un Ultralight C, o cerere de autentificare criptată poate fi trimisă pe card. Dacă acesta NU este un card Ultralight C, această cerere nu va fi înțeleasă, iar răspunsul va fi un NAK (not-acknolege).

Dacă acesta este un card Ulralight C, veți primi un răspuns de 8 octeți. Acești 8 octeți sunt un număr aleatoriu „B” (RndB) criptat de cheia stocată pe card folosind cifrul 3DES.

Acest RndB criptat trebuie decriptat folosind aceeași cheie din program. Acest număr aleatoriu este apoi ușor modificat (rotit cu un octet → octetul 1 va fi mutat în octetul 8 și toți ceilalți octeți sunt împinși cu un octet mai jos, numit apoi RndB’). Programul generează apoi un număr aleatoriu de 8 octeți "A" în sine (RndA) și atașează acest RndA la RndB’modificat. Aceasta este din nou criptată folosind cheia și se trimite pe card.

Cardul decriptează mesajul și verifică dacă RndB’se potrivește cu RndB generat anterior pe card. Dacă se potrivesc, cartela știe acum că programul știe cheia.

În acest moment, programul încă nu știe dacă cardul cunoaște cheia și, prin urmare, poate fi de încredere sau nu. Pentru a realiza acest lucru, cardul roteste acum RndA decriptat cu un octet, apoi criptează acești octeți folosind cheia și le trimite înapoi.

Programul va decripta apoi răspunsul cardului și va verifica dacă RndA original și RndA răspuns se potrivesc. DOAR DUPĂ ambele entități (program și card) știu că împărtășesc cunoștințele aceleiași chei.

Acest proces este utilizat numai pentru autentificare. Toate comunicările ulterioare sunt întotdeauna în „text clar”.

Deși există carduri „magice Ultralight C” în care UID-ul poate fi modificat, cheia în sine nu poate fi obținută de pe card, iar cifrul 3DES este destul de sigur. Cheia este o cheie de 16 octeți, astfel încât o abordare cu forță brută pentru a obține cheia va dura ceva timp.

După cum sa menționat, comunicarea înainte de autentificare și după autentificare este întotdeauna în text clar (alias necriptat). Când scrieți o nouă cheie pe card, conținutul cheii poate fi adulmecat folosind echipamentul potrivit. Așadar, vă rugăm să scrieți cheia numai într-un mediu sigur și să păstrați cheia secretă.

Când utilizați cardul Ultralight C.

Cardul Ultralight C are mai multe funcții de securitate încorporate:

1. Memorie OTP (One Time Programming). În această zonă se pot scrie biți, autobuzul nu șters.
2. Un contor de 16 biți într-un singur sens. Acest contor poate crește numai atunci când este accesat.
3. O protecție „scriere” sau „citire / scriere” a paginilor din memorie. Numai dacă sunt autentificate cu cheia, aceste pagini pot fi citite sau modificate.
4. O înghețare / blocare a paginilor individuale pentru a proteja împotriva oricărei modificări.

Nici utilizarea OTP, contorul de 16 biți și nici utilizarea bitului de blocare nu sunt implementate în codul dat, dar pot fi ușor implementate pe baza informațiilor date în https://www.nxp.com/docs/en/data- foaie / MF0ICU2.pd …

Deoarece protecția prin cheie este esențială pentru utilizarea Mifare Ultralight C, sunt prezente toate funcțiile relevante.

Toate comenzile sunt utilizate în monitorul serial cu „numai linie nouă” și cu 115200 Baud

• „Auth 49454D4B41455242214E4143554F5946” va solicita o autentificare cu cheia dată (în acest caz cheia standard Mifare Ultralight C)
• „Dump” va arunca conținutul cardului atât cât sunt vizibile. În cazul în care paginile sunt protejate de cheie, este posibil ca aceste pagini să nu fie vizibile până la o autentificare anterioară cu cheie. În primele două coloane este indicat dacă paginile sunt blocate sau accesul este restricționat.
• „NewKey 49454D4B41455242214E4143554F5946” va scrie o nouă cheie pe card. Cheia este scrisă în paginile 44-47. Acest lucru va funcționa numai dacă aceste pagini nu sunt nici blocate, nici protejate fără o autentificare anterioară.
• „wchar 10 hello world” va scrie „hello world” începând de la pagina 10. Din nou, acest lucru numai al paginilor nu este nici blocat și nici protejat fără o autentificare anterioară. Când încercați să scrieți mai sus pagina 39 sau mai jos pagina 4 aceasta va solicita o eroarea sau datele sunt ignorate deoarece aceste pagini nu reprezintă memoria utilizatorului.
• „Whex 045ACBF44688” va scrie valori Hex direct în memorie, se aplică condițiile anterioare.
• „Protect 30” protejează toate paginile de la pagina 30 în sus. În funcție de permisiune, aceste pagini pot fi modificate sau citite numai după o autentificare prealabilă cu cheie. Folosind „protejare” cu valori mai mari de 47, toate paginile vor fi „neprotejate” INCLUSIV CHEIA la paginile 44-47 (care poate fi modificată doar dar nu citită). Pentru a preveni modificarea cheii, protecția ar trebui să înceapă cel puțin de la pagina 44.
• „Setpbit 0” setează bitul de protecție și decide dacă paginile protejate sunt doar citite („setpbit 1”) sau nu pot fi citite și nu scrise („setpbit 0”) fără o autentificare anterioară cu cheie.

Nu toate comenzile pot fi utilizate imediat după detectarea cardului. O „descărcare” anterioară către o altă comandă ajută întotdeauna.

Pasul 3: Important

1. Programul diferențiază tipurile Ultralight citind pagina 43 și 44. Dacă pagina 43 este lizibilă și pagina 44 nu, cel mai probabil este un Ultralight C. DAR, dacă citiți / scrieți protejați pagina 43 cardul nu mai este recunoscut ca Ultralight C (nu are niciun efect asupra nimic) Identificarea corectă a ultralightului trebuie făcută prin autentificarea cu cheia (nu am implementat asta din motive de stabilitate).
2. Înainte de a utiliza comenzile „setpbit” și „protect” trebuie folosită comanda „dump”, altfel starea de protecție a paginilor nu va fi cunoscută.
3. Dacă „citiți / scrieți” protejați primele pagini ale cardului dvs., acesta nu va mai funcționa cu acest program, deoarece prima pagină este citită constant pentru a vedea dacă există încă un card prezent. Deoarece primele două pagini sunt citite doar oricum (UID-ul este stocat acolo), nu are sens să le protejăm.

Probleme de stabilitate

Acest cod folosește biblioteca „standard” RC522 pentru Arduino și o bibliotecă 3DES de la https://github.com/Octoate/ArduinoDES. În timp ce biblioteca RC522 este destul de frecvent utilizată, biblioteca 3DES nu pare atât de răspândită și trebuie instalată manual.

Codul a fost testat pe un Arduino Uno. Dar, în timp ce o scrieam, am întâmpinat multe probleme ciudate în ceea ce privește stabilitatea. Cumva, abilitățile mele de programare nu sunt atât de bune, una dintre bibliotecile utilizate este instabilă sau amestecarea bibliotecilor nu este o idee bună.

Vă rugăm să aveți în vedere acest lucru atunci când utilizați codul !!!

Schimbarea sau utilizarea doar a unor părți ale acestuia poate duce la un comportament ciudat, cum ar fi blocarea, imprimarea unor lucruri ciudate sau obținerea unor time-out sau NAK atunci când citiți de pe card. Acest lucru se poate întâmpla în orice loc al codului (m-a costat multe ore de depanare). Dacă găsiți motivul (motivele) pentru acest lucru, vă rog să-mi dați un indiciu.