Verwenden von Mifare Ultralight C mit RC522 auf Arduino - Gunook

2024 Autor: John Day | [email protected]. Zuletzt bearbeitet: 2024-01-30 07:15

Der Einsatz der RFID-Technologie zur Identifizierung von Karteninhabern oder zur Autorisierung einer Handlung (Tür öffnen etc.) ist ein recht verbreiteter Ansatz. Bei Heimwerkeranwendungen ist das RC522-Modul weit verbreitet, da es recht billig ist und für dieses Modul viel Code existiert.

In den meisten Fällen wird die UID der Karte verwendet, um den Karteninhaber zu „identifizieren“, und Mifare Classic-Karten werden verwendet, da sie billig sind und oft beim Kauf eines RC522-Moduls enthalten sind.

Aber wie Sie vielleicht wissen, wird das Mifare Classic-System seit einigen Jahren gehackt und gilt nicht mehr als sicher. Das von Classic-Karten verwendete Verschlüsselungssystem Crypto1 kann überwunden werden und es sind wiederbeschreibbare Karten, bei denen Daten und UID umprogrammiert werden können (Magic Cards).

Für alle sicherheitsrelevanten Anwendungen wird daher der Einsatz von Mifare Classic Karten nicht empfohlen! Gleiches gilt für (die meisten) NTAG- und Mifare-Ultralight-Systeme

Sie haben also die Wahl, entweder ein professionelles System zu verwenden oder ein sichereres RFID-System zu verwenden. Verfügbare Systeme sind Mifare Ultralight C, Mifare DESFire und Mifare Plus. Da es viele professionelle Systeme gibt, die diese sichereren Systeme verwenden, gibt es für die DIY-Community praktisch keine Lösungen (es gibt eine Teensy-basierte DESFire-Lösung, die auf dem teureren Breakout-Board PN523 basiert). Außerdem sind die DESFire-Karten ziemlich teuer. Die Herausforderung bestand also darin, eine bessere und kostengünstigere Lösung zu finden.

Die vorgestellte Lösung bietet vollen Zugriff auf die günstigen Mifare Ultralight „C“-Karten mit dem billigen chinesischen RC522 DIY-Modul. Basierend auf diesem Code kann das sichere Mifare Ultralight C in Heimwerkeranwendungen eingesetzt werden.

Schritt 1: Voraussetzungen

Obwohl der RC522 gut konstruiert ist, ist er in den meisten Fällen schlecht verarbeitet, da einige Komponenten schlecht dimensioniert sind. Dies führt zu dem schlechten Ruf des Moduls, dass es eine geringe Empfindlichkeit hat und nicht alle Kartentypen erkannt werden. Vor allem die Mifare Ultralight C wird weder erkannt, noch können die Karten gelesen werden.

Das Hauptproblem ist die Spezifikation der Induktivitäten L1 und L2. Wie auf https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html beschrieben. Allein durch den Austausch dieser Induktivitäten gegen geeignete, z. B. FERROCORE CW1008-2200 plötzlich zeigt der RC522 sein wahres Potenzial.

Bevor Sie also den angegebenen Code ausprobieren, MÜSSEN Sie die Induktivitäten ERSETZEN. Es funktioniert einfach nicht mit den vorinstallierten Induktoren!

Der Hintergrund von all dem ist, dass die Ultralight C-Karten ziemlich energiehungrig sind. Diese Energie wird vom RC522 HF-Feld bereitgestellt. Aufgrund der geringen Stromstärke der Induktivitäten reicht das Energiefeld für die Ultralight C einfach nicht aus. Andere Karten wie die Mifare Classic brauchen einfach weniger Strom und arbeiten daher recht stabil.

Schritt 2: Wie funktioniert es?

Wie können Sie das Mifare Ulralight C nach der Modifikation des RC522-Moduls für Ihre Anwendung verwenden?

Der Clou ist, dass Mifare Ultralight C eine Passwort-Authentifizierung basierend auf der 3DES-Chiffre unterstützt. Durch die Verwendung dieses Passworts kann der Inhalt der Karte für einen nicht autorisierten Benutzer „nur lesbar“oder vollständig unsichtbar gemacht werden.

Um diesen Passwortschutz nutzen zu können, muss das Passwort auf die Karte geschrieben und die Seiten geschützt werden. Sobald Sie fertig sind, können Sie die Karte in Ihrer Anwendung verifizieren, indem Sie entweder nur eine passwortbasierte Authentifizierung anfordern oder zusätzlich Daten aus einem geschützten Bereich bereitstellen. Nur wenn dies erfolgreich ist, wissen Sie, dass Sie der bereitgestellten UID auf der Karte vertrauen können.

Achtung: Ohne die passwortbasierte Authentifizierung kann man einer Mifare Ultralight C Karte immer noch nicht vertrauen, da es auch „Magic Cards“gibt, die die Ultralight C simulieren.

Jede Karte unabhängig von der Technologie (bei korrekter Frequenz) antwortet mit ihrer UID, wenn sie durch das RF-Feld gespeist wird und fordert, sich zu identifizieren. Darüber hinaus liefern sie einen SAK-Wert, der nur minimale Informationen über den vorhandenen Kartentyp liefert. Leider identifizieren sich alle Mifare Ultralight und NTAG als Syme Type (SAK=0x00), einschließlich Mifare Ultralight C. Wenn also nach Karten abgefragt wird, gibt zumindest der SAK-Wert von 0x00 einen Hinweis darauf, dass sich auf dem Leser ein Ultralight C befinden könnte.

Um sicherzustellen, dass es sich um eine Ultralight C handelt, kann eine Anfrage zur verschlüsselten Authentifizierung an die Karte gesendet werden. Wenn dies KEINE Ultralight-C-Karte ist, wird diese Anfrage nicht verstanden und die Antwort ist ein NAK (not-acknolege).

Wenn es sich um eine Ulralight C-Karte handelt, erhalten Sie eine 8-Byte-Antwort. Diese 8 Bytes sind eine Zufallszahl „B“(RndB), die durch den auf der Karte gespeicherten Schlüssel mit der 3DES-Chiffre verschlüsselt wird.

Diese verschlüsselte RndB muss mit dem gleichen Schlüssel im Programm entschlüsselt werden. Diese Zufallszahl wird dann leicht modifiziert (um ein Byte gedreht → Byte 1 wird auf Byte 8 verschoben und alle anderen Bytes werden um ein Byte tiefer geschoben, dann RndB genannt). Das Programm generiert dann selbst eine 8 Byte große Zufallszahl „A“(RndA) und hängt diese RndA an die geänderte RndB’ an. Dieser wird wiederum mit dem Schlüssel verschlüsselt und an die Karte gesendet.

Die Karte entschlüsselt die Nachricht und prüft, ob RndB’ zu dem zuvor generierten RndB auf der Karte passt. Stimmen sie überein, weiß die Karte nun, dass das Programm den Schlüssel kennt.

Zu diesem Zeitpunkt weiß das Programm noch nicht, ob die Karte den Schlüssel kennt und daher vertrauenswürdig ist oder nicht. Dazu rotiert die Karte nun das entschlüsselte RndA um ein Byte, verschlüsselt diese Bytes dann mit dem Schlüssel und sendet sie zurück.

Das Programm entschlüsselt dann die Antwort der Karte und prüft, ob die ursprüngliche RndA und die geantwortete RndA übereinstimmen. NUR DANN wissen beide Entitäten (Programm und Karte), dass sie das Wissen über denselben Schlüssel teilen.

Dieser Vorgang dient nur zur Authentifizierung. Die weitere Kommunikation erfolgt immer im „Klartext“.

Obwohl es „magische Ultralight C“-Karten gibt, bei denen die UID geändert werden kann, kann der Schlüssel selbst nicht von der Karte abgerufen werden und die 3DES-Chiffre ist ziemlich sicher. Der Schlüssel ist ein 16-Byte-Schlüssel, so dass ein Brute-Force-Ansatz einige Zeit in Anspruch nehmen wird, um den Schlüssel zu erhalten.

Wie bereits erwähnt, erfolgt die Kommunikation vor der Authentifizierung und nach der Authentifizierung immer im Klartext (auch nicht verschlüsselt). Beim Schreiben eines neuen Schlüssels auf die Karte kann der Inhalt des Schlüssels mit der richtigen Ausrüstung erschnüffelt werden. Schreiben Sie den Schlüssel daher bitte nur in einer sicheren Umgebung und halten Sie den Schlüssel geheim.

Bei Verwendung der Ultralight C-Karte

Die Ultralight C-Karte verfügt über mehrere integrierte Sicherheitsfunktionen:

1. One Time Programming (OTP)-Speicher. In diesem Bereich können Bits geschrieben werden, Bus nicht gelöscht.
2. Ein 16-Bit-Einwegzähler. Dieser Zähler kann nur inkrementiert werden, wenn darauf zugegriffen wird.
3. Ein „Schreib“- oder „Lese-/Schreib“-Schutz von Seiten im Speicher. Nur wenn mit dem Schlüssel authentifiziert, können diese Seiten gelesen oder geändert werden.
4. Ein Einfrieren/Sperren einzelner Seiten zum Schutz vor jeglicher Veränderung.

Weder die Verwendung von OTP, des 16-Bit-Zählers noch die Verwendung des Sperrbits ist im angegebenen Code implementiert, kann jedoch anhand der Informationen in https://www.nxp.com/docs/en/data- leicht implementiert werden. Blatt/MF0ICU2.pd…

Da der Schlüsselschutz für die Nutzung des Mifare Ultralight C unerlässlich ist, sind alle relevanten Funktionen vorhanden.

Alle Befehle werden im Serial Monitor mit "new line only" und mit 115200 Baud verwendet

• „auth 49454D4B41455242214E4143554F5946“fordert eine Authentifizierung mit dem angegebenen Schlüssel an (in diesem Fall der Standard-Mifare Ultralight C-Schlüssel)
• „dump“gibt den Inhalt der Karte aus, soweit er sichtbar ist. Falls Seiten durch den Schlüssel geschützt sind, sind diese Seiten möglicherweise erst nach einer vorherigen Authentifizierung mit dem Schlüssel sichtbar. In den ersten beiden Spalten wird angezeigt, ob Seiten gesperrt oder der Zugriff eingeschränkt ist.
• „newKey 49454D4B41455242214E4143554F5946“schreibt einen neuen Schlüssel auf die Karte. Der Schlüssel wird auf die Seiten 44 bis 47 geschrieben. Dies funktioniert nur, wenn diese Seiten ohne vorherige Authentifizierung weder gesperrt noch geschützt sind.
• "wchar 10 hello world" schreibt ab Seite 10 "hello world". Auch hier werden nur Werke der Seiten ohne vorherige Authentifizierung weder gesperrt noch geschützt. Beim Versuch, oberhalb von Seite 39 oder unterhalb von Seite 4 zu schreiben, wird eine Fehler oder Daten werden ignoriert, da diese Seiten kein Benutzerspeicher sind.
• „whex 045ACBF44688“schreibt Hex-Werte direkt in den Speicher, vorherige Bedingungen gelten.
• „protect 30“schützt alle Seiten ab Seite 30. Je nach Berechtigung können diese Seiten dann nur nach vorheriger Authentifizierung mit Schlüssel geändert oder gelesen werden. Wenn Sie „protect“mit Werten über 47 verwenden, werden alle Seiten auf „ungeschützt“gesetzt, EINSCHLIESSLICH DER SCHLÜSSEL auf den Seiten 44-47 (die dann nur geändert, aber nicht gelesen werden können). Um eine Veränderung des Schlüssels zu verhindern, sollte der Schutz mindestens ab Seite 44 beginnen.
• „setpbit 0“setzt das Schutzbit und entscheidet, ob die geschützten Seiten nur gelesen werden („setpbit 1“) oder ohne vorherige Authentifizierung mit Schlüssel weder gelesen noch geschrieben werden können („setpbit 0“).

Nicht alle Befehle können sofort verwendet werden, nachdem die Karte erkannt wurde. Ein "Dump" vorher auf einen anderen Befehl hilft immer.

Schritt 3: Wichtig

1. Das Programm unterscheidet zwischen den Ultralight-Typen, indem es Seite 43 und 44 liest. Wenn Seite 43 lesbar ist und Seite 44 nicht, handelt es sich höchstwahrscheinlich um eine Ultralight C. ABER wenn Sie die Seite 43 mit Lese-/Schreibschutz versehen, wird die Karte nicht mehr erkannt als Ultralight C (hat keine Auswirkung auf nichts) Die korrekte Identifizierung des Ultralight sollte über die Authentifizierung mit Schlüssel erfolgen (das habe ich aus Stabilitätsgründen nicht implementiert).
2. Vor der Verwendung der Befehle „setpbit“und „protect“muss der Befehl „dump“verwendet werden, da sonst der Schutzstatus der Seiten nicht bekannt ist.
3. Wenn Sie die ersten Seiten Ihrer Karte mit „Lesen/Schreiben“schützen, funktioniert dies mit diesem Programm nicht mehr, da ständig die erste Seite gelesen wird, um zu sehen, ob noch eine Karte vorhanden ist. Da die ersten beiden Seiten ohnehin nur gelesen werden (die UID wird dort gespeichert), macht es keinen Sinn, sie zu schützen.

Stabilitätsprobleme

Dieser Code verwendet die „Standard“-Bibliothek RC522 für Arduino und eine 3DES-Bibliothek von https://github.com/Octoate/ArduinoDES. Während die RC522-Bibliothek recht häufig verwendet wird, scheint die 3DES-Bibliothek nicht so weit verbreitet zu sein und muss manuell installiert werden.

Der Code wurde auf einem Arduino Uno getestet. Aber während ich es schrieb, stieß ich auf viele seltsame Probleme in Bezug auf die Stabilität. Irgendwie sind meine Programmierkenntnisse nicht so gut, eine der verwendeten Bibliotheken ist instabil oder das Mischen der Bibliotheken ist keine gute Idee.

Bitte bedenken Sie dies bei der Verwendung des Codes!!!

Wenn Sie es ändern oder nur Teile davon verwenden, kann es zu seltsamem Verhalten wie Abstürzen, seltsamen Drucken oder Timeouts oder NAK beim Lesen von der Karte kommen. Dies kann an jeder Stelle im Code passieren (es hat mich viele Stunden Debugging gekostet). Wenn Sie die Gründe dafür finden, geben Sie mir bitte einen Hinweis.