Gebruik Mifare Ultralight C met RC522 op Arduino: 3 stappe

2024 Outeur: John Day | [email protected]. Laas verander: 2024-01-30 07:23

Die gebruik van RFID -tegnologie om kaarthouers te identifiseer of om toestemming te gee om iets te doen ('n deur oopmaak, ens.) Is 'n redelik algemene benadering. In die geval van 'n self -toepassing, word die RC522 -module wyd gebruik, aangesien dit redelik goedkoop is en daar baie kode vir hierdie module bestaan.

In die meeste gevalle word die UID van die kaart gebruik om die kaarthouer te "identifiseer", en Mifare Classic -kaarte word gebruik, aangesien dit goedkoop is en dikwels ingesluit word by die aankoop van 'n RC522 -module.

Maar soos u dalk weet, is die Mifare Classic -stelsel al 'n paar jaar gehack en word dit nie meer as veilig beskou nie. Die enkripsiestelsel Crypto1 wat deur Classic-kaarte gebruik word, kan oorkom word, en dit kan herskryfbare kaarte word waar data en UID herprogrammeer kan word (towerkaarte).

Die gebruik van Mifare Classic -kaarte word dus nie aanbeveel vir enige veiligheidstoepassing nie! Dieselfde geld vir (die meeste) NTAG- en Mifare Ultralight -stelsels

Die keuse is dus om 'n professionele stelsel te gebruik of om 'n veiliger RFID -stelsel te gebruik. Beskikbare stelsels is Mifare Ultralight C, Mifare DESFire en Mifare Plus. Aangesien daar baie professionele stelsels is wat hierdie veiliger stelsels gebruik, is daar feitlik geen oplossings vir die DIY -gemeenskap nie (daar is een op Teensy gebaseerde DESFire -oplossing, wat gebaseer is op die duurder PN523 -uitbreekbord). Boonop is die DESFire -kaarte redelik duur. Die uitdaging was dus om 'n beter en goedkoper oplossing te vind.

Die oplossing bied volledige toegang tot die goedkoop Mifare Ultralight "C" -kaarte met behulp van die goedkoop Chinese RC522 DIY -module. Op grond van hierdie kode kan die veilige Mifare Ultralight C in DIY -toepassings gebruik word.

Stap 1: Voorwaardes

Alhoewel die RC522 goed ontwerp is, is dit in die meeste gevalle swak gebou, aangesien sommige komponente swak gedimensioneer is. Dit lei tot die slegte reputasie van die module dat dit 'n lae sensitiwiteit het en dat nie alle tipe kaarte geïdentifiseer sal word nie. Veral die Mifare Ultralight C sal nie geïdentifiseer word nie, en dit is ook nie moontlik om die kaarte te lees nie.

Die grootste probleem is die spesifikasie van die induktors L1 en L2. Soos beskryf op https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Net deur hierdie induktors te vervang by toepaslike, bv. FERROCORE CW1008-2200 toon skielik die RC522 wat die werklike potensiaal daarvan is.

Dus, voordat u die gegewe kode probeer, MOET u die induktors vervang. Dit werk net nie met die vooraf geïnstalleerde induktors nie!

Die agtergrond hiervan is dat die Ultralight C -kaarte nogal honger is. Hierdie energie word verskaf deur die RC522 RF-veld. As gevolg van 'n lae stroomsterkte van die induktors, is die energieveld net nie sterk genoeg om die Ultralight C. van krag te maak nie. Ander kaarte soos die Mifare Classic benodig net minder krag en werk dus redelik stabiel.

Stap 2: Hoe werk dit?

Dus, na die wysiging van die RC522 -module, hoe kan u die Mifare Ulralight C vir u toepassing gebruik?

Die truuk is dat Mifare Ultralight C 'n wagwoordverifikasie ondersteun wat gebaseer is op die 3DES -kode. Deur hierdie wagwoord te gebruik, kan die inhoud van die kaart vir 'n ongemagtigde gebruiker "leesalleen" of heeltemal onsigbaar gemaak word.

Om hierdie wagwoordbeskerming te kan gebruik, moet die wagwoord op die kaart geskryf word en die bladsye moet beskerm word. Sodra dit klaar is, kan u die kaart in u aansoek verifieer, óf deur net 'n wagwoordgebaseerde verifikasie te vra, óf ekstra gereed data uit 'n beskermde gebied. Slegs as dit suksesvol is, weet u dat u die verskafde UID op die kaart kan vertrou.

Pasop: sonder die wagwoordgebaseerde verifikasie kan u steeds nie 'n Mifare Ultralight C -kaart vertrou nie, aangesien daar ook 'magiese kaarte' is wat die Ultralight C simuleer.

Elke kaart wat onafhanklik is van die tegnologie (indien in die korrekte frekwensie) reageer met hul UID wanneer dit deur die RF-veld aangedryf word en versoek om hulself te identifiseer. Boonop bied hulle 'n SAK -waarde wat minimale inligting verskaf oor die tipe kaart wat daar is. Ongelukkig word alle Mifare Ultralight en NTAG geïdentifiseer as die tipe tipe (SAK = 0x00), insluitend die Mifare Ultralight C. Dus, as u na kaarte gaan, sal die SAK -waarde van 0x00 ten minste 'n aanduiding gee dat daar 'n Ultralight C op die leser kan wees.

Om seker te maak dat dit 'n Ultralight C is, kan 'n versoek om geënkripteerde verifikasie na die kaart gestuur word. As dit NIE 'n Ultralight C-kaart is nie, word hierdie versoek nie verstaan nie, en die reaksie is 'n NAK (nie-akknolege).

As dit 'n Ulralight C -kaart is, kry u 'n antwoord van 8 byte. Hierdie 8 Bytes is 'n ewekansige getal "B" (RndB) wat deur die gestoorde sleutel op die kaart geïnkripteer word met behulp van die 3DES -kode.

Hierdie geïnkripteer RndB moet met dieselfde sleutel in die program ontsyfer word. Hierdie ewekansige getal word dan effens gewysig (met een greep gedraai → greep 1 sal na greep 8 geskuif word en alle ander grepe word een greep laer gedruk, dan RndB genoem). Die program genereer dan self 'n 8 Byte ewekansige getal "A" (RndA) en heg hierdie RndA aan die gewysigde RndB '. Dit word weer geïnkripteer met die sleutel en na die kaart gestuur.

Die kaart ontsyfer die boodskap en kyk of RndB 'pas by die voorheen gegenereerde RndB op die kaart. As hulle ooreenstem, weet die kaart nou dat die program die sleutel ken.

Op hierdie stadium weet die program steeds nie of die kaart die sleutel ken nie en daarom kan dit vertrou word of nie. Om dit te bereik, draai die kaart die gedecodeerde RndA nou met een greep, en dan versleutelt hierdie grepe met die sleutel en stuur dit terug.

Die program sal dan die antwoord van die kaart ontsyfer en kyk of die oorspronklike RndA en die geantwoord RndA ooreenstem. SLEGS DAN weet beide entiteite (program en kaart) dat hulle die kennis van dieselfde sleutel deel.

Hierdie proses word slegs gebruik om te verifieer. Alle verdere kommunikasie is altyd in 'duidelike teks'.

Alhoewel daar 'magiese Ultralight C' kaarte is waar die UID aangepas kan word, kan die sleutel self nie van die kaart verkry word nie en is die 3DES -kode redelik veilig. Die sleutel is 'n 16 Byte -sleutel, so 'n brute kragbenadering om die sleutel te kry, sal 'n rukkie neem.

Soos gesê, is die kommunikasie voor verifikasie en na verifikasie altyd in duidelike teks (ook nie geïnkripteer nie). As u 'n nuwe sleutel vir die kaart skryf, kan die inhoud van die sleutel uitgesnuffel word deur die regte toerusting te gebruik. Skryf die sleutel dus slegs in 'n veilige omgewing en hou die sleutel geheim.

As u die Ultralight C -kaart gebruik

Die Ultralight C -kaart het verskeie beveiligingsfunksies ingebou:

1. Eenmalige programmeer (OTP) geheue. In hierdie gebied kan stukkies geskryf word, bus nie uitgevee nie.
2. 'N 16 -bits eenrigting -toonbank. Hierdie toonbank kan slegs toeneem as dit toeganklik is.
3. 'N "Skryf" of "lees/skryf" beskerming van bladsye in die geheue. Hierdie bladsye kan slegs gelees of gewysig word as dit met die sleutel geverifieer is.
4. Bevriesing / blokkering van individuele bladsye om te beskerm teen enige verandering.

Nóg die gebruik van OTP, die 16-bits teller of die gebruik van die blokkeerbit is geïmplementeer in die gegewe kode, maar kan maklik geïmplementeer word op grond van die inligting in https://www.nxp.com/docs/en/data- blad/MF0ICU2.pd …

Aangesien die sleutelbeskerming noodsaaklik is vir die gebruik van die Mifare Ultralight C, is alle relevante funksies teenwoordig.

Alle opdragte word gebruik in die seriële monitor met 'slegs' nuwe reël 'en met 115200 Baud

• "Auth 49454D4B41455242214E4143554F5946" sal 'n verifikasie met die gegewe sleutel versoek (in hierdie geval die standaard Mifare Ultralight C -sleutel)
• "Dump" sal die inhoud van die kaart so ver as dit sigbaar is, dump. As bladsye deur die sleutel beskerm word, is hierdie bladsye moontlik nie sigbaar totdat 'n vorige verifikasie met die sleutel nie. In die eerste twee kolomme word aangedui of bladsye gesluit is of toegang beperk is.
• 'NewKey 49454D4B41455242214E4143554F5946' sal 'n nuwe sleutel vir die kaart skryf. Die sleutel word op die bladsye 44 tot 47 geskryf. Dit sal slegs werk as hierdie bladsye nie gesluit of beskerm is sonder 'n vorige verifikasie nie.
• "wchar 10 hallo wêreld" sal "hallo wêreld" skryf vanaf bladsy 10. Weereens word slegs die werke van die bladsye nie gesluit of beskerm sonder 'n vorige verifikasie nie. As u bo bladsy 39 of onder bladsy 4 probeer skryf, sal dit 'n fout of data word geïgnoreer, aangesien hierdie bladsye nie gebruikersgeheue is nie.
• 'Whex 045ACBF44688' sal Hex -waardes direk na die geheue skryf, vorige voorwaardes geld.
• “Beskerm 30” beskerm al die bladsye vanaf bladsy 30 opwaarts. Afhangende van die toestemming, kan hierdie bladsye slegs gewysig of gelees word na 'n voorafgaande verifikasie met 'n sleutel. Deur 'beskerm' met waardes hoër as 47 te gebruik, word alle bladsye op 'onbeskermd' gestel, insluitend die sleutel op bladsye 44-47 (wat slegs verander kan word, maar nie gelees kan word nie). Om te verhoed dat die sleutel verander word, moet die beskerming ten minste vanaf bladsy 44 begin.
• "Setpbit 0" stel die beskermingsbit in en besluit of die beskermde bladsye slegs leesbaar is ("setpbit 1") of nie gelees kan word nie ("setpbit 0") sonder 'n vorige verifikasie met sleutel.

Nie alle opdragte kan onmiddellik gebruik word nadat die kaart opgespoor is nie. 'N' dump 'wat voorheen na 'n ander opdrag was, help altyd.

Stap 3: Belangrik

1. Die program onderskei tussen die Ultralight -tipes deur bladsy 43 en 44 te lees. As bladsy 43 leesbaar is en bladsy 44 nie, is dit waarskynlik 'n Ultralight C. MAAR, as u die bladsy 43 lees/skryf, word die kaart nie meer erken as Ultralight C (het geen uitwerking op enigiets nie) Die korrekte identifisering van die Ultralight moet gedoen word via die verifikasie met die sleutel (ek het dit nie geïmplementeer nie weens stabiliteitsredes).
2. Voordat u die opdragte "setpbit" en "beskerm" gebruik, moet die opdrag "dump" gebruik word, anders is die beskermingsstatus van die bladsye nie bekend nie.
3. As u die eerste bladsye van u kaart "lees/skryf" beskerm, werk dit nie meer met hierdie program nie, aangesien die eerste bladsy voortdurend gelees word om te sien of daar nog 'n kaart is. Aangesien die eerste twee bladsye in elk geval slegs gelees word (die UID word daar gestoor), het dit geen sin om dit te beskerm nie.

Stabiliteitskwessies

Hierdie kode gebruik die 'standaard' RC522 -biblioteek vir Arduino en 'n 3DES -biblioteek van https://github.com/Octoate/ArduinoDES. Terwyl die RC522 -biblioteek baie algemeen gebruik word, lyk die 3DES -biblioteek nie so wydverspreid nie en moet dit met die hand geïnstalleer word.

Die kode is getoets op 'n Arduino Uno. Maar tydens die skryf daarvan het ek baie vreemde probleme met betrekking tot stabiliteit ondervind. Op een of ander manier is my programmeringsvaardighede nie so goed nie; een van die gebruikte biblioteke is onstabiel, of dit is nie 'n goeie idee om die biblioteke te meng nie.

Hou dit in gedagte wanneer u die kode gebruik !!!

As u dit verander of slegs gedeeltes daarvan gebruik, kan dit tot vreemde gedrag lei, soos om neer te val, vreemde dinge te druk of tydsberekeninge of NAK te kry wanneer u van die kaart lees. Dit kan op enige plek in die kode gebeur (dit het my baie ure se ontfouting gekos). Gee my 'n wenk as u die rede (s) hiervoor vind.