Korzystanie z Mifare Ultralight C z RC522 na Arduino: 3 kroki

2025 Autor: John Day | [email protected]. Ostatnio zmodyfikowany: 2025-01-13 06:58

Stosowanie technologii RFID do identyfikacji posiadaczy kart lub upoważnienia do zrobienia czegoś (otwarcia drzwi itp.) jest dość powszechnym podejściem. W przypadku aplikacji DIY moduł RC522 jest szeroko stosowany, ponieważ jest dość tani i istnieje wiele kodu dla tego modułu.

W większości przypadków UID karty służy do „identyfikacji” posiadacza karty, a karty Mifare Classic są używane, ponieważ są tanie i często dołączane do zakupu modułu RC522.

Ale jak być może wiesz, system Mifare Classic był hackowany od kilku lat i nie jest już uważany za bezpieczny. System szyfrowania Crypto1 używany przez karty Classic można pokonać i są to karty wielokrotnego zapisu, w których dane UID można przeprogramować (karty magiczne).

Dlatego w przypadku aplikacji związanych z bezpieczeństwem nie zaleca się używania kart Mifare Classic! To samo dotyczy (większości) systemów NTAG i Mifare Ultralight

Wybór polega więc na skorzystaniu z profesjonalnego systemu lub próbie użycia bezpieczniejszego systemu RFID. Dostępne systemy to Mifare Ultralight C, Mifare DESFire i Mifare Plus. Ponieważ istnieje wiele profesjonalnych systemów korzystających z tych bezpieczniejszych systemów, dla społeczności DIY praktycznie nie ma rozwiązań (istnieje jedno rozwiązanie DESFire oparte na Teensy, które opiera się na droższej tabliczce zaciskowej PN523). Dodatkowo karty DESFire są dość drogie. Wyzwaniem było więc znalezienie lepszego i tańszego rozwiązania.

Prezentowane rozwiązanie zapewnia pełny dostęp do tanich kart Mifare Ultralight „C” z wykorzystaniem taniego chińskiego modułu DIY RC522. W oparciu o ten kod bezpieczny Mifare Ultralight C może być używany w aplikacjach DIY.

Krok 1: Warunki wstępne

Chociaż RC522 jest dobrze zaprojektowany, w większości przypadków jest źle zbudowany, ponieważ niektóre komponenty są słabo zwymiarowane. Prowadzi to do złej reputacji modułu, który ma niską czułość i nie wszystkie typy kart zostaną zidentyfikowane. Zwłaszcza Mifare Ultralight C nie zostanie zidentyfikowany ani nie będzie można odczytać kart.

Głównym problemem jest specyfikacja cewek L1 i L2. Jak opisano na https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Wystarczy wymienić te induktorki na odpowiednie np. FERROCORE CW1008-2200 nagle RC522 pokazuje, jaki jest jego prawdziwy potencjał.

Więc przed wypróbowaniem danego kodu MUSISZ WYMIENIĆ cewki indukcyjne. Po prostu nie będzie działać z preinstalowanymi cewkami!

Powodem tego wszystkiego jest to, że karty Ultralight C są dość energochłonne. Ta energia jest dostarczana przez pole RF RC522. Ze względu na niskie natężenie cewek, pole energetyczne nie jest wystarczająco silne, aby zasilić Ultralight C. Inne karty, takie jak Mifare Classic, wymagają po prostu mniejszej mocy i dlatego działają dość stabilnie.

Krok 2: Jak to działa?

Jak więc po zmodyfikowaniu modułu RC522 wykorzystać Mifare Ulralight C do swojej aplikacji?

Sztuczka polega na tym, że Mifare Ultralight C obsługuje uwierzytelnianie hasłem w oparciu o szyfr 3DES. Używając tego hasła, zawartość karty może być „tylko do odczytu” lub całkowicie niewidoczna dla nieuprawnionego użytkownika.

Aby skorzystać z tej ochrony hasłem, hasło musi być zapisane na karcie, a strony muszą być chronione. Po zakończeniu możesz zweryfikować kartę w swojej aplikacji, prosząc o uwierzytelnienie na podstawie hasła lub dodatkowo o gotowe dane z chronionego obszaru. Tylko jeśli to się powiedzie, wiesz, że możesz zaufać podanemu UID na karcie.

Uwaga: bez uwierzytelniania opartego na haśle nadal nie można ufać karcie Mifare Ultralight C, ponieważ istnieją również „magiczne karty”, które symulują Ultralight C.

Każda karta niezależna od technologii (jeśli ma odpowiednią częstotliwość) odpowie swoim UID, gdy zostanie zasilona przez pole RF i poprosi o identyfikację. Dodatkowo podają wartość SAK, zapewniając minimalną informację o rodzaju obecnej karty. Niestety wszystkie Mifare Ultralight i NTAG identyfikują się jako typ syme (SAK=0x00), w tym Mifare Ultralight C. Tak więc podczas odpytywania kart przynajmniej wartość SAK 0x00 da wskazówkę, że na czytniku może znajdować się Ultralight C.

Aby upewnić się, że jest to Ultralight C, na kartę można wysłać żądanie zaszyfrowanego uwierzytelnienia. Jeśli NIE jest to karta Ultralight C, to żądanie nie zostanie zrozumiane, a odpowiedzią będzie NAK (not-acknolege).

Jeśli jest to karta Ulralight C, otrzymasz 8 bajtową odpowiedź. Te 8 bajtów to losowa liczba „B” (RndB) zaszyfrowana kluczem zapisanym na karcie za pomocą szyfru 3DES.

Ten zaszyfrowany RndB musi zostać odszyfrowany przy użyciu tego samego klucza w programie. Ta liczba losowa jest następnie nieznacznie modyfikowana (obrócona o jeden bajt → bajt 1 zostanie przesunięty do bajtu 8, a wszystkie inne bajty zostaną przesunięte o jeden bajt niżej, a następnie nazywane RndB'). Następnie program sam generuje 8-bajtową liczbę losową „A” (RndA) i dołącza ten RndA do zmodyfikowanego RndB’. Jest to ponownie szyfrowane za pomocą klucza i wysyłane na kartę.

Karta odszyfrowuje wiadomość i sprawdza, czy RndB’ pasuje do wcześniej wygenerowanego RndB na karcie. Jeśli pasują, karta wie, że program zna klucz.

W tym momencie program nadal nie wie, czy karta zna klucz i dlatego można mu ufać, czy nie. Aby to osiągnąć, karta obraca teraz odszyfrowane RndA o jeden bajt, a następnie szyfruje te bajty za pomocą klucza i odsyła je z powrotem.

Program następnie odszyfruje odpowiedź karty i sprawdzi, czy oryginalne RndA i odpowiedzi RndA pasują do siebie. TYLKO WTEDY oba podmioty (program i karta) wiedzą, że dzielą wiedzę o tym samym kluczu.

Ten proces służy wyłącznie do uwierzytelniania. Cała dalsza komunikacja odbywa się zawsze w „czystym tekście”.

Chociaż istnieją karty „magiczne Ultralight C”, w których można zmodyfikować UID, sam klucz nie może zostać uzyskany z karty, a szyfr 3DES jest dość bezpieczny. Klucz jest kluczem 16-bajtowym, więc brutalne podejście do uzyskania klucza zajmie trochę czasu.

Jak wspomniano, komunikacja przed uwierzytelnieniem i po uwierzytelnieniu jest zawsze w postaci zwykłego tekstu (inaczej nie zaszyfrowanej). Wpisując nowy klucz na kartę, zawartość klucza można wywęszyć przy użyciu odpowiedniego sprzętu. Dlatego proszę pisać klucz tylko w bezpiecznym środowisku i zachować klucz w tajemnicy.

Podczas korzystania z karty Ultralight C

Karta Ultralight C ma wiele wbudowanych funkcji bezpieczeństwa:

1. Pamięć jednorazowego programowania (OTP). W tym obszarze można zapisywać bity, magistrala nie jest kasowana.
2. 16-bitowy licznik jednokierunkowy. Ten licznik może się zwiększać tylko po uzyskaniu dostępu.
3. Ochrona „zapisu” lub „odczyt/zapis” stron w pamięci. Tylko po uwierzytelnieniu za pomocą klucza strony te mogą być odczytywane lub modyfikowane.
4. Zamrożenie/zablokowanie poszczególnych stron w celu zabezpieczenia przed jakąkolwiek modyfikacją.

Ani użycie OTP, 16-bitowego licznika, ani użycie bitu blokującego nie jest zaimplementowane w danym kodzie, ale można je łatwo zaimplementować na podstawie informacji podanych w https://www.nxp.com/docs/en/data- arkusz/MF0ICU2.pd…

Ponieważ ochrona kluczem jest niezbędna do korzystania z Mifare Ultralight C, wszystkie istotne funkcje są obecne.

Wszystkie polecenia są używane w monitorze szeregowym z „tylko nową linią” i 115200 bodów

• „auth 49454D4B41455242214E4143554F5946” zażąda uwierzytelnienia podanym kluczem (w tym przypadku standardowym kluczem Mifare Ultralight C)
• „dump” zrzuci zawartość karty, o ile są one widoczne. W przypadku, gdy strony są chronione kluczem, strony te mogą nie być widoczne do czasu poprzedniego uwierzytelnienia za pomocą klucza. W pierwszych dwóch kolumnach jest wskazane, czy strony są zablokowane lub dostęp jest ograniczony.
• „newKey 49454D4B41455242214E4143554F5946” zapisze nowy klucz na karcie. Klucz jest zapisany na stronach od 44 do 47. To zadziała tylko wtedy, gdy strony te nie są ani zablokowane ani chronione bez wcześniejszego uwierzytelnienia.
• „wchar 10 hello world” napisze „hello world” zaczynając od strony 10. Ponownie, to tylko prace stron nie są ani zablokowane ani chronione bez uprzedniego uwierzytelnienia. Podczas próby pisania powyżej strony 39 lub poniżej strony 4 zostanie wyświetlony monit błąd lub dane są ignorowane, ponieważ te strony nie są pamięcią użytkownika.
• „whex 045ACBF44688” zapisze wartości szesnastkowe bezpośrednio do pamięci, obowiązują poprzednie warunki.
• „protect 30” chroni wszystkie strony od strony 30 w górę. W zależności od uprawnień strony te mogą być modyfikowane lub odczytywane tylko po uprzednim uwierzytelnieniu za pomocą klucza. Użycie „zabezpiecz” z wartościami wyższymi niż 47 ustawi wszystkie strony na „niezabezpieczone” WŁĄCZNIE Z KLUCZEM na stronach 44-47 (który może być tylko modyfikowany, ale nie może być odczytywany). Aby zapobiec zmianie klucza, ochrona powinna zaczynać się przynajmniej na stronie 44.
• „setpbit 0” ustawia bit ochrony i decyduje, czy chronione strony są tylko do odczytu („setpbit 1”), czy też nie mogą być odczytywane ani zapisywane („setpbit 0”) bez uprzedniego uwierzytelnienia za pomocą klucza.

Nie wszystkie polecenia mogą być użyte natychmiast po wykryciu karty. Zawsze pomaga "zrzut" wcześniej do innego polecenia.

Krok 3: Ważne

1. Program rozróżnia typy Ultralight czytając strony 43 i 44. Jeśli strona 43 jest czytelna, a strona 44 nie, najprawdopodobniej jest to Ultralight C. ALE, jeśli czytasz/zapisujesz chroń stronę 43, karta nie jest już rozpoznawana jako Ultralight C (nie ma na nic wpływu) Prawidłowa identyfikacja Ultralighta powinna odbywać się poprzez uwierzytelnienie kluczem (nie zaimplementowałem tego ze względu na stabilność).
2. Przed użyciem poleceń „setpbit” i „protect” należy użyć polecenia „dump”, w przeciwnym razie stan ochrony stron nie będzie znany.
3. Jeśli „odczyt/zapis” chronisz pierwsze strony swojej karty, nie będzie on już działał z tym programem, ponieważ pierwsza strona jest stale czytana, aby sprawdzić, czy nadal jest obecna karta. Ponieważ pierwsze dwie strony i tak są tylko do odczytu (uID jest tam przechowywany), nie ma sensu ich chronić.

Problemy ze stabilnością

Ten kod wykorzystuje „standardową” bibliotekę RC522 dla Arduino i bibliotekę 3DES z https://github.com/Octoate/ArduinoDES. Podczas gdy biblioteka RC522 jest dość powszechnie używana, biblioteka 3DES nie wydaje się tak rozpowszechniona i musi być instalowana ręcznie.

Kod został przetestowany na Arduino Uno. Ale pisząc to, napotkałem wiele dziwnych problemów związanych ze stabilnością. Jakoś albo moje umiejętności programistyczne nie są tak dobre, jedna z używanych bibliotek jest niestabilna, albo mieszanie bibliotek nie jest dobrym pomysłem.

Proszę mieć to na uwadze używając kodu!!!

Zmiana go lub używanie tylko jego części może prowadzić do dziwnych zachowań, takich jak awarie, drukowanie dziwnych rzeczy, przekroczenie limitu czasu lub NAK podczas czytania z karty. Może się to zdarzyć w dowolnym miejscu w kodzie (kosztowało mnie to wiele godzin debugowania). Jeśli znajdziesz powód(y) tego, proszę o podpowiedź.