A Mifare Ultralight C használata az RC522 -tel Arduino -n: 3 lépés

2024 Szerző: John Day | [email protected]. Utoljára módosítva: 2024-01-30 09:39

Az RFID -technológia használata a kártyatulajdonosok azonosítására vagy az engedélyezésre (ajtónyitás stb.) Meglehetősen gyakori megközelítés. DIY alkalmazás esetén az RC522 modult széles körben használják, mivel meglehetősen olcsó, és sok kód létezik ehhez a modulhoz.

A legtöbb esetben a kártya UID azonosítóját használják a kártya tulajdonosának „azonosítására”, míg a Mifare Classic kártyákat használják, mivel olcsók és gyakran szerepelnek az RC522 modul vásárlásakor.

De amint azt Ön is tudja, a Mifare Classic rendszert néhány éve feltörték, és már nem tekintik biztonságosnak. A Classic kártyák által használt Crypto1 titkosítási rendszer leküzdhető, és az újraírható kártyák, ahol az UID-adatok átprogramozhatók (varázslatos kártyák).

Tehát a biztonság szempontjából fontos alkalmazásokhoz nem ajánlott a Mifare Classic kártyák használata! Ugyanez vonatkozik a (legtöbb) NTAG és Mifare Ultralight rendszerekre is

Tehát a választás vagy professzionális rendszer használata, vagy egy biztonságosabb RFID rendszer használata. Rendelkezésre álló rendszerek: Mifare Ultralight C, Mifare DESFire és Mifare Plus. Mivel sok professzionális rendszer használja ezeket a biztonságosabb rendszereket, a barkácsközösség számára gyakorlatilag nincs megoldás (van egy Teensy -alapú DESFire megoldás, amely a drágább PN523 -as alaplapon található). Ezenkívül a DESFire kártyák nagyon drágák. A kihívás tehát egy jobb és olcsóbb megoldás megtalálása volt.

A bemutatott megoldás teljes hozzáférést biztosít az olcsó Mifare Ultralight „C” kártyákhoz az olcsó kínai RC522 DIY modul használatával. E kód alapján a biztonságos Mifare Ultralight C használható barkács alkalmazásokban.

1. lépés: Előfeltételek

Bár az RC522 jól megtervezett, a legtöbb esetben rosszul épül, mivel egyes alkatrészek rosszul vannak méretezve. Ez a modul rossz hírnevéhez vezet, hogy alacsony érzékenységű, és nem minden típusú kártyát lehet azonosítani. Különösen a Mifare Ultralight C -t nem lehet azonosítani, és nem lehet olvasni a kártyákat.

A fő probléma az L1 és L2 induktorok specifikációja. A https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html oldalon leírtak szerint. Csak úgy, hogy ezeket az induktorokat megfelelőre cserélik pl. A FERROCORE CW1008-2200 hirtelen az RC522 megmutatja, mi a valós potenciálja.

Tehát mielőtt megpróbálná a megadott kódot, KÖTELEZŐ az induktivitás cseréje. Csak nem fog működni az előre telepített induktivitásokkal!

Mindezek hátterében az áll, hogy az Ultralight C kártyák meglehetősen energiaéhesek. Ezt az energiát az RC522 RF-mező biztosítja. Az induktivitások alacsony áramerőssége miatt az energiamező nem elég erős ahhoz, hogy táplálja az Ultralight C -t. Más kártyák, mint például a Mifare Classic, csak kevesebb energiát igényelnek, és ezért elég stabilan működnek.

2. lépés: Hogyan működik?

Tehát az RC522 modul módosítása után hogyan használhatja a Mifare Ulralight C -t az alkalmazásához?

A trükk az, hogy a Mifare Ultralight C támogatja a 3DES titkosításon alapuló jelszó -hitelesítést. Ezzel a jelszóval a kártya tartalma „csak olvashatóvá” tehető, vagy teljesen láthatatlanná válik egy jogosulatlan felhasználó számára.

A jelszóvédelem használatához a jelszót be kell írni a kártyára, és az oldalakat védeni kell. Ha elkészült, ellenőrizheti a kártyát az alkalmazásban, ha csak jelszóalapú hitelesítést kér, vagy további kész adatokat kér egy védett területről. Csak ha ez sikeres, tudja, hogy bízhat a kártyán megadott UID -ban.

Vigyázat: jelszóalapú hitelesítés nélkül továbbra sem bízhat a Mifare Ultralight C kártyában, mivel vannak „varázslatos kártyák” is, amelyek az Ultralight C -t szimulálják.

Minden, a technológiától független kártya (ha a megfelelő frekvencián van) válaszol az UID-jével, ha az RF-mező táplálja, és kéri az azonosítást. Ezenkívül SAK értéket biztosítanak, minimális információt nyújtva a jelen lévő kártya típusáról. Sajnos minden Mifare Ultralight és NTAG azonosítja a syme típust (SAK = 0x00), beleértve a Mifare Ultralight C -t is. Tehát kártyák lekérdezésekor legalább a 0x00 SAK érték utal arra, hogy Ultralight C lehet az olvasón.

Annak érdekében, hogy megbizonyosodjon arról, hogy Ultralight C -ről van szó, titkosított hitelesítési kérelmet küldhet a kártyára. Ha ez nem Ultralight C kártya, akkor ezt a kérést nem fogjuk megérteni, és a válasz NAK (not-acknolege) lesz.

Ha ez egy Ulralight C kártya, akkor 8 bájtos választ kap. Ez a 8 bájt egy véletlenszerű „B” (RndB) szám, amelyet a kártyán tárolt kulcs titkosít a 3DES titkosítással.

Ezt a titkosított RndB -t a programban ugyanazzal a kulccsal kell visszafejteni. Ezt a véletlen számot ezután kissé módosítják (egy bájttal elforgatva → 1 bájt a 8 bájtra kerül, és minden más bájt egy bájttal lejjebb kerül, amelyet RndB’-nek neveznek). A program ezután 8 bájtos "A" véletlen számot generál (RndA), és ezt az RndA -t a módosított RndB -hez csatolja. Ezt ismét titkosítják a kulccsal, és elküldik a kártyára.

A kártya visszafejti az üzenetet, és ellenőrzi, hogy az RndB’illeszkedik -e a kártyán korábban létrehozott RndB -hez. Ha megegyeznek, a kártya most már tudja, hogy a program ismeri a kulcsot.

Ezen a ponton a program még mindig nem tudja, hogy a kártya ismeri -e a kulcsot, és ezért megbízható -e benne. Ennek elérése érdekében a kártya most egy bájttal elforgatja a visszafejtett RndA -t, majd a kulccsal titkosítja ezeket a bájtokat, és visszaküldi őket.

A program ezután visszafejti a kártya válaszát, és ellenőrzi, hogy az eredeti RndA és a válaszolt RndA megegyeznek -e. CSAK Ekkor mindkét entitás (program és kártya) tudja, hogy ugyanazt a kulcsot ismeri.

Ezt a folyamatot csak hitelesítésre lehet használni. Minden további kommunikáció mindig „világos szövegben” történik.

Bár vannak „varázslatos ultrakönnyű C” kártyák, ahol az UID módosítható, maga a kulcs nem szerezhető be a kártyáról, és a 3DES titkosítás meglehetősen biztonságos. A kulcs egy 16 bájtos kulcs, így a nyers erő megközelítése a kulcs megszerzéséhez bizonyos ideig tart.

Mint említettük, a hitelesítés előtti és a hitelesítés utáni kommunikáció mindig világos szövegben történik (más néven nem titkosított). Amikor új kulcsot ír a kártyára, a kulcs tartalmát a megfelelő felszereléssel ki lehet szippantani. Ezért kérjük, hogy csak biztonságos környezetben írja meg a kulcsot, és tartsa titokban.

Az Ultralight C kártya használatakor

Az Ultralight C kártya számos biztonsági funkcióval rendelkezik:

1. Egyszeri programozási (OTP) memória. Ezen a területen bitek írhatók, a busz nem törölhető.
2. 16 bites egyirányú számláló. Ez a számláló csak akkor növelhető, ha elérik.
3. A memória oldalainak „írása” vagy „olvasása/írása” védelme. Ezek az oldalak csak akkor olvashatók vagy módosíthatók, ha a kulccsal hitelesítik.
4. Az egyes oldalak befagyasztása / blokkolása a változtatások ellen.

Sem az OTP, sem a 16 bites számláló, sem a blokkoló bit használata nem valósul meg az adott kódban, de könnyen megvalósítható a https://www.nxp.com/docs/en/data- sheet/MF0ICU2.pd…

Mivel a kulcsos védelem elengedhetetlen a Mifare Ultralight C használatához, minden releváns funkció megtalálható.

A soros monitoron minden parancs "csak új vonal" és 115200 Baud esetén használatos

• Az „auth 49454D4B41455242214E4143554F5946” hitelesítést kér a megadott kulccsal (ebben az esetben a szabványos Mifare Ultralight C kulcs)
• A „dump” a kártya tartalmát, amennyire csak látható, kiüríti. Ha az oldalakat a kulcs védi, akkor előfordulhat, hogy ezek az oldalak nem lesznek láthatók a kulccsal végzett korábbi hitelesítés során. Az első két oszlopban megjelenik, ha az oldalak zárolva vannak, vagy a hozzáférés korlátozott.
• „NewKey 49454D4B41455242214E4143554F5946” új kulcsot ír a kártyára. A kulcs a 44-47. Oldalra van írva. Ez csak akkor működik, ha ezek az oldalak nincsenek zárolva vagy védve korábbi hitelesítés nélkül.
• A "wchar 10 hello world" a "hello world" feliratot fogja írni a 10. oldaltól kezdve. Ismétlem, ez csak az oldalak műveit nem zárolja és nem védi előzetes hitelesítés nélkül. hiba vagy adatok figyelmen kívül hagyása, mivel ezek az oldalak nem felhasználói memória.
• A „whex 045ACBF44688” hexadecimális értékeket ír közvetlenül a memóriába, a korábbi feltételek fennállnak.
• A „védi a 30” védi az összes oldalt a 30. oldaltól felfelé. Az engedélytől függően ezek az oldalak ezután csak módosíthatók vagy olvashatók, előzetes kulccsal történő hitelesítés után. Ha a „protect” értéket 47-nél magasabb értékkel használja, akkor minden oldal „védtelen” -re áll, BELEZETTEN A GOMBOT a 44-47. Oldalon (amely csak módosítható, de nem olvasható). A kulcs megváltoztatásának megakadályozása érdekében a védelemnek legalább a 44. oldalon kell kezdődnie.
• A „setpbit 0” beállítja a védelmi bitet, és eldönti, hogy a védett oldalak csak olvashatók -e („setpbit 1”), vagy egyik sem olvasható -e nem írva („setpbit 0”) a kulccsal való korábbi hitelesítés nélkül.

Nem minden parancs használható közvetlenül a kártya észlelése után. A "dump" korábban egy másik parancshoz mindig segít.

3. lépés: Fontos

1. A program különbséget tesz az ultrakönnyű típusok között a 43. és 44. oldal olvasásával. Ha a 43. oldal olvasható, a 44. oldal pedig nem, akkor valószínűleg ultrakönnyű C. DE, ha olvasás/írás védi a 43. oldalt, a kártya már nem ismerhető fel Ultralight C (nincs hatással semmire) Az Ultralight megfelelő azonosítását a kulccsal történő hitelesítéssel kell elvégezni (ezt stabilitási okok miatt nem valósítottam meg).
2. A „setpbit” és a „protect” parancsok használata előtt a „dump” parancsot kell használni, különben az oldalak védelmi állapota nem lesz ismert.
3. Ha „olvasni/írni” védi a kártya első oldalait, akkor ez a program már nem működik ezzel a programmal, mivel az első oldalt folyamatosan olvassák, hogy lássák, van -e még kártya. Mivel az első két oldal egyébként is csak olvasható (az UID ott van tárolva), nincs értelme megvédeni őket.

Stabilitási kérdések

Ez a kód az Arduino „szabványos” RC522 könyvtárát és a https://github.com/Octoate/ArduinoDES weboldal 3DES könyvtárát használja. Míg az RC522 könyvtárat meglehetősen gyakran használják, a 3DES könyvtár úgy tűnik, nem annyira elterjedt, és manuálisan kell telepíteni.

A kódot egy Arduino Uno -n tesztelték. Írás közben azonban sok furcsa problémával találkoztam a stabilitással kapcsolatban. Valahogy a programozási ismereteim nem olyan jók, az egyik használt könyvtár instabil, vagy a könyvtárak keverése nem jó ötlet.

Kérjük, vegye figyelembe ezt a kód használata során !!!

Ha megváltoztatja vagy csak annak egy részét használja, furcsa viselkedéshez vezethet, például összeomláshoz, furcsa dolgok nyomtatásához, vagy időtúllépésekhez vagy NAK -hoz, amikor a kártyáról olvas. Ez a kód bármely pontján megtörténhet (sok órányi hibakeresésbe került). Ha megtalálja ennek okát, kérjük, adjon tippet.