Използване на Mifare Ultralight C с RC522 на Arduino: 3 стъпки

2024 Автор: John Day | [email protected]. Последно модифициран: 2024-01-30 07:50

Използването на RFID технология за идентифициране на притежателите на карти или за упълномощаване да се направи нещо (отваряне на врата и т.н.) е доста често срещан подход. В случай на приложение „направи си сам“модулът RC522 се използва широко, тъй като е доста евтин и има много код за този модул.

В повечето случаи UID на картата се използва за „идентифициране“на притежателя на картата, а картите Mifare Classic се използват, тъй като са евтини и често се включват при закупуване на модул RC522.

Но както може би знаете, системата Mifare Classic е хакната от няколко години и вече не се счита за безопасна. Системата за криптиране Crypto1, използвана от класическите карти, може да бъде преодоляна и картите за презаписване, където данни и UID могат да бъдат препрограмирани (магически карти).

Така че за всяко приложение, свързано със сигурността, използването на карти Mifare Classic не се препоръчва! Същото важи и за (повечето) системи NTAG и Mifare Ultralight

Така че изборът е или да използвате професионална система, или да се опитате да използвате по -сигурна RFID система. Наличните системи са Mifare Ultralight C, Mifare DESFire и Mifare Plus. Тъй като има много професионални системи, използващи тези по -сигурни системи, за общността „направи си сам“практически няма решения (има едно решение, базирано на Teensy DESFire, което е базирано в по -скъпата платка за пробив PN523). Освен това картите DESFire са доста скъпи. Така че предизвикателството беше да се намери по -добро и по -евтино решение.

Представеното решение осигурява пълен достъп до евтините Mifare Ultralight “C” карти, използващи евтиния китайски RC522 DIY модул. Въз основа на този код защитеният Mifare Ultralight C може да се използва в приложения „направи си сам“.

Стъпка 1: Предпоставки

Въпреки че RC522 е добре проектиран, в повечето случаи той е лошо изграден, тъй като някои компоненти са лошо оразмерени. Това води до лошата репутация на модула, че има ниска чувствителност и не всички видове карти ще бъдат идентифицирани. Особено Mifare Ultralight C нито ще бъде идентифициран, нито ще бъде възможно да се четат картите.

Основният проблем е спецификацията на индукторите L1 и L2. Както е описано на https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Само чрез подмяна на тези индуктори с подходящи напр. FERROCORE CW1008-2200 изведнъж RC522 показва какъв е реалният му потенциал.

Така че преди да опитате дадения код, ТРЯБВА ДА ЗАМЕНЕТЕ индукторите. Просто няма да работи с предварително инсталираните индуктори!

Фонът на всичко това е, че картите Ultralight C са доста гладни за енергия. Тази енергия се осигурява от радиочестотното поле RC522. Поради ниската ампераж на индукторите, енергийното поле просто не е достатъчно мощно за захранване на Ultralight C. Други карти като Mifare Classic просто се нуждаят от по -малко енергия и следователно работят доста стабилно.

Стъпка 2: Как работи?

И така, след като промените модула RC522, как можете да използвате Mifare Ulralight C за вашето приложение?

Номерът е, че Mifare Ultralight C поддържа удостоверяване на парола въз основа на 3DES шифъра. Използвайки тази парола, съдържанието на картата може да стане „само за четене“или напълно невидимо за неоторизиран потребител.

За да използвате тази защита с парола, паролата трябва да бъде записана на картата и страниците трябва да бъдат защитени. След като приключите, можете да проверите картата в приложението си, като просто поискате удостоверяване на базата на парола или допълнително готови данни от защитена зона. Само ако това е успешно, вие знаете, че можете да се доверите на предоставения UID на картата.

Внимавайте: без удостоверяване, основано на парола, все още не можете да се доверите на карта Mifare Ultralight C, тъй като има и „вълшебни карти“, които симулират Ultralight C.

Всяка карта, независима от технологията (ако е на правилната честота), ще реагира с UID, когато се захранва от радиочестотното поле и ще поиска да се идентифицира. Освен това те предоставят стойност на SAK, предоставяща минимална информация за вида на наличната карта. За съжаление всички Mifare Ultralight и NTAG се идентифицират като тип syme (SAK = 0x00), включително Mifare Ultralight C. Така че при анкетиране за карти поне стойността на SAK от 0x00 ще подскаже, че може да има Ultralight C на четеца.

За да се уверите, че е Ultralight C, може да се изпрати заявка за криптирана автентификация към картата. Ако това НЕ е Ultralight C карта, тази заявка няма да бъде разбрана и отговорът ще бъде NAK (not-acknolege).

Ако това е карта Ulralight C, ще получите отговор от 8 байта. Тези 8 байта са произволно число „B“(RndB), криптирано от записания ключ на картата с помощта на 3DES шифъра.

Този шифрован RndB трябва да бъде декриптиран с помощта на същия ключ в програмата. След това това произволно число е леко променено (завъртено с един байт → байт 1 ще бъде преместен в байт 8 и всички останали байтове се избутат с един байт по -ниско, след което се наричат RndB’). След това програмата генерира 8 -байтово произволно число "A" (RndA) и прикрепя това RndA към модифицирания RndB '. Това отново се криптира с помощта на ключа и се изпраща на картата.

Картата декриптира съобщението и проверява дали RndB 'се вписва в генерирания преди това RndB на картата. Ако те съвпадат, картата вече знае, че програмата знае ключа.

В този момент програмата все още не знае дали картата знае ключа и следователно може да се вярва или не. За да се постигне това, картата сега завърта декриптираната RndA с един байт, след което шифрова тези байтове с помощта на ключа и ги изпраща обратно.

След това програмата ще декриптира отговора на картата и ще провери дали оригиналната RndA и отговорената RndA съвпадат. Едва след това и двата обекта (програма и карта) знаят, че споделят знанията за един и същ ключ.

Този процес се използва само за удостоверяване. Цялата по -нататъшна комуникация винаги е в „ясен текст“.

Въпреки че има карти „magic Ultralight C“, където UID може да бъде променен, самият ключ не може да бъде получен от картата и 3DES шифърът е доста защитен. Ключът е 16 -байтов ключ, така че подходът с груба сила за получаване на ключа ще отнеме известно време.

Както бе посочено, комуникацията преди удостоверяване и след удостоверяване винаги е в ясен текст (известен още като не шифрован). Когато пишете нов ключ към картата, съдържанието на ключа може да бъде издухано с помощта на подходящото оборудване. Затова, моля, напишете ключа само в защитена среда и пазете ключа в тайна.

Когато използвате Ultralight C карта

Картата Ultralight C има вградени множество функции за сигурност:

1. Памет за еднократно програмиране (OTP). В тази област битовете могат да бъдат записани, шината да не бъде изтрита.
2. 16 -битов еднопосочен брояч. Този брояч може да се увеличава само при достъп.
3. Защита „запис“или „четене/запис“на страници в паметта. Само ако са удостоверени с ключа, тези страници могат да се четат или променят.
4. Замразяване / блокиране на отделни страници за защита срещу всякакви промени.

Нито използването на OTP, 16-битовия брояч, нито използването на блокиращия бит е реализирано в дадения код, но може лесно да се реализира въз основа на информацията, дадена в https://www.nxp.com/docs/en/data- лист/MF0ICU2.pd…

Тъй като защитата с ключ е от съществено значение за използването на Mifare Ultralight C, всички съответни функции са налични.

Всички команди се използват в серийния монитор с "само нов ред" и със 115200 бода

• „Auth 49454D4B41455242214E4143554F5946“ще поиска удостоверяване с дадения ключ (в този случай стандартният ключ Mifare Ultralight C)
• „Dump“ще изхвърли съдържанието на картата, доколкото е видимо. В случай, че страниците са защитени с ключа, тези страници може да не се виждат до предишно удостоверяване с ключ. В първите две колони е посочено дали страниците са заключени или достъпът е ограничен.
• “NewKey 49454D4B41455242214E4143554F5946” ще запише нов ключ към картата. Ключът е записан на страниците 44 до 47. Това ще работи само ако тези страници не са нито заключени, нито защитени без предварително удостоверяване.
• "wchar 10 hello world" ще напише "hello world", започвайки от страница 10. Отново, само тези работи на страниците не са нито заключени, нито защитени без предишно удостоверяване. Когато се опитвате да напишете над страница 39 или под страница 4, това ще подкани грешка или данни се игнорират, тъй като тези страници не са потребителска памет.
• “Whex 045ACBF44688” ще запише шестнадесетични стойности директно в паметта, важат предишни условия.
• „Защита 30“защитава всички страници от страница 30 нагоре. В зависимост от разрешението, тези страници могат да бъдат модифицирани или прочетени само след предварително удостоверяване с ключ. Използването на „защита“със стойности, по-високи от 47, ще настрои всички страници на „незащитени“, ВКЛЮЧВАЩИ КЛЮЧЪТ на страници 44-47 (който може да бъде променен, но не и прочетен). За да се предотврати промяната на ключа, защитата трябва да започне поне на страница 44.
• „Setpbit 0“задава защитния бит и решава дали защитените страници са само за четене („setpbit 1“) или нито могат да бъдат прочетени без запис („setpbit 0“) без предварително удостоверяване с ключ.

Не всички команди могат да се използват веднага след откриването на картата. "Дъмп" преди това към друга команда винаги помага.

Стъпка 3: Важно

1. Програмата прави разлика между ултралеките типове, като прочете страници 43 и 44. Ако страница 43 е четима, а страница 44 не, най -вероятно е ултра лека C. НО, ако четете/пишете, защитете страница 43, картата вече не се разпознава като Ultralight C (няма никакъв ефект върху нищо) Правилната идентификация на Ultralight трябва да се извърши чрез удостоверяване с ключ (не го приложих поради причини за стабилност).
2. Преди да използвате командите „setpbit“и „protect“трябва да се използва командата „dump“, в противен случай състоянието на защита на страниците няма да бъде известно.
3. Ако „четете/пишете“, защитавате първите страници на картата си, тя вече няма да работи с тази програма, тъй като първата страница се чете постоянно, за да се види дали все още има карта. Тъй като първите две страници така или иначе се четат само (UID се съхранява там), няма смисъл да ги защитавате.

Проблеми със стабилността

Този код използва „стандартната“библиотека RC522 за Arduino и библиотека 3DES от https://github.com/Octoate/ArduinoDES. Докато библиотеката RC522 се използва доста често, библиотеката 3DES изглежда не толкова широко разпространена и трябва да бъде инсталирана ръчно.

Кодът е тестван на Arduino Uno. Но докато го писах, срещнах много странни проблеми по отношение на стабилността. По някакъв начин или уменията ми за програмиране не са толкова добри, една от използваните библиотеки е нестабилна или смесването на библиотеките не е добра идея.

Моля, имайте това предвид, когато използвате кода !!!

Промяната му или използването само на части от него може да доведе до странно поведение като срив, отпечатване на странни неща или получаване на таймаути или NAK при четене от картата. Това може да се случи на всяко място в кода (струваше ми много часове за отстраняване на грешки). Ако откриете причината (ите) за това, моля, подскажете ми.