Brug af Mifare Ultralight C Med RC522 på Arduino: 3 trin

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:25

At bruge RFID -teknologi til at identificere kortholdere eller til at give tilladelse til at gøre noget (åbne en dør osv.) Er en ret almindelig tilgang. I tilfælde af DIY -applikation er RC522 -modulet meget udbredt, da det er ret billigt, og der findes en masse kode til dette modul.

I de fleste tilfælde bruges kortets UID til at “identificere” kortholderen, og Mifare Classic -kort bruges, da de er billige og ofte inkluderet, når de køber et RC522 -modul.

Men som du måske ved, er Mifare Classic -systemet blevet hacket i nogle år, og det betragtes ikke længere som sikkert. Krypteringssystemet Crypto1, der bruges af Classic-kort, kan overvindes, og de kan omskrives kort, hvor data og et UID kan omprogrammeres (magiske kort).

Så for enhver sikkerhedsrelevant applikation anbefales brug af Mifare Classic -kort ikke! Det samme gælder for (de fleste) NTAG- og Mifare Ultralight -systemer

Så valget er enten at bruge et professionelt system eller forsøge at bruge et mere sikkert RFID -system. Tilgængelige systemer er Mifare Ultralight C, Mifare DESFire og Mifare Plus. Da der er mange professionelle systemer, der bruger disse mere sikre systemer, er der for DIY -samfundet stort set ingen løsninger (der er en Teensy -baseret DESFire -løsning, som er baseret i det dyrere PN523 -breakout -kort). Desuden er DESFire -kortene temmelig dyre. Så udfordringen var at finde en bedre og billigere løsning.

Den præsenterede løsning giver fuld adgang til de billige Mifare Ultralight “C” -kort ved hjælp af det billige kinesiske RC522 DIY -modul. Baseret på denne kode kan den sikre Mifare Ultralight C bruges i gør -det -selv -applikationer.

Trin 1: Forudsætninger

Selvom RC522 er godt designet, er den i de fleste tilfælde dårligt bygget, da nogle komponenter er dårligt dimensionerede. Dette fører til modulets dårlige ry, at det har lav følsomhed, og ikke alle typer kort vil blive identificeret. Især Mifare Ultralight C vil hverken blive identificeret, eller det vil være muligt at læse kortene.

Hovedproblemet er specifikationen af induktorerne L1 og L2. Som beskrevet på https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Bare ved at udskifte disse induktorer til passende dem f.eks. FERROCORE CW1008-2200 pludselig viser RC522, hvad dens reelle potentiale er.

Så før du prøver den givne kode, SKAL du SKIFTE induktorerne. Det vil bare ikke fungere med de forudinstallerede induktorer!

Baggrunden for alt dette er, at Ultralight C -kortene er ret energisultne. Denne energi leveres af RC522 RF-feltet. På grund af lav strømstyrke af induktorerne er energifeltet bare ikke kraftigt nok til at drive Ultralight C. Andre kort som Mifare Classic har bare brug for mindre strøm og fungerer derfor ret stabilt.

Trin 2: Hvordan fungerer det?

Så hvordan kan du bruge Mifare Ulralight C til din applikation efter at have ændret RC522 -modulet?

Tricket er, at Mifare Ultralight C understøtter en adgangskodeautentificering baseret på 3DES -krypteringen. Ved at bruge denne adgangskode kan indholdet af kortet gøres "skrivebeskyttet" eller helt usynligt for en uautoriseret bruger.

For at bruge denne adgangskodebeskyttelse skal adgangskoden skrives til kortet, og siderne skal beskyttes. Når det er gjort, kan du bekræfte kortet i din applikation enten ved blot at bede om en adgangskodebaseret godkendelse eller yderligere klar data fra et beskyttet område. Kun hvis dette lykkes, ved du, at du kan stole på den medfølgende UID på kortet.

Pas på: uden adgangskodebaseret godkendelse kan du stadig ikke stole på et Mifare Ultralight C -kort, da der også er "magiske kort", der simulerer Ultralight C.

Hvert kort, der er uafhængigt af teknologien (hvis det er i den korrekte frekvens), reagerer med deres UID, når det drives af RF-feltet og anmoder om at identificere sig selv. Derudover giver de en SAK -værdi, der giver minimal information om, hvilken type kort der er til stede. Desværre identificerer alle Mifare Ultralight og NTAG sig som symetypen (SAK = 0x00), inklusive Mifare Ultralight C. Så ved polling efter kort vil i det mindste SAK -værdien på 0x00 give et fingerpeg om, at der kan være en Ultralight C på læseren.

For at sikre, at det er en Ultralight C, kan en anmodning om krypteret godkendelse sendes til kortet. Hvis dette IKKE er et Ultralight C-kort, vil denne anmodning ikke blive forstået, og svaret vil være et NAK (ikke-akknolege).

Hvis dette er et Ulralight C -kort, får du et svar på 8 byte. Disse 8 Bytes er et tilfældigt nummer “B” (RndB) krypteret af den lagrede nøgle på kortet ved hjælp af 3DES -chifferen.

Denne krypterede RndB skal dekrypteres ved hjælp af den samme nøgle i programmet. Dette tilfældige tal ændres derefter lidt (roteret med en byte → byte 1 flyttes til byte 8, og alle andre bytes skubbes en byte lavere, derefter kaldet RndB’). Programmet genererer derefter et 8 Byte tilfældigt tal "A" selv (RndA) og knytter denne RndA til den modificerede RndB’. Dette krypteres igen ved hjælp af nøglen og sendes til kortet.

Kortet dekrypterer meddelelsen og kontrollerer, om RndB’passer til den tidligere genererede RndB på kortet. Hvis de matcher, ved kortet nu, at programmet kender nøglen.

På dette tidspunkt ved programmet stadig ikke, om kortet kender nøglen og derfor kan stole på eller ej. For at opnå dette roterer kortet nu den dekrypterede RndA med en byte og krypterer derefter disse bytes ved hjælp af nøglen og sender dem tilbage.

Programmet vil derefter dekryptere svaret på kortet og kontrollere, om det originale RndA og det svarede RndA stemmer overens. KUN ved begge enheder (program og kort), at de deler viden om den samme nøgle.

Denne proces bruges kun til godkendelse. Al videre kommunikation sker altid i “klar tekst”.

Selvom der er "magiske Ultralight C" -kort, hvor UID'en kan ændres, kan selve nøglen ikke hentes fra kortet, og 3DES -chifferen er rimelig sikker. Nøglen er en 16 Byte nøgle, så en brute force -tilgang for at opnå nøglen vil tage noget tid.

Som nævnt er kommunikationen før godkendelse og efter godkendelse altid i klar tekst (aka ikke krypteret). Når du skriver en ny nøgle til kortet, kan nøglens indhold sniffes ud ved hjælp af det rigtige udstyr. Så skriv venligst nøglen kun i et sikkert miljø og hold nøglen hemmelig.

Ved brug af Ultralight C -kortet

Ultralight C -kortet har flere indbyggede sikkerhedsfunktioner:

1. One Time Programming (OTP) hukommelse. I dette område kan bits skrives, bus ikke slettet.
2. En 16 bit envejstæller. Denne tæller kan kun øges, når den er tilsluttet.
3. En “skrive” eller “læse/skrive” beskyttelse af sider i hukommelsen. Kun hvis disse sider er godkendt med nøglen, kan disse sider læses eller ændres.
4. En indefrysning / blokering af individuelle sider for at beskytte mod enhver ændring.

Hverken brugen af OTP, 16 bit-tælleren eller brugen af den blokerende bit er implementeret i den givne kode, men kan let implementeres baseret på oplysningerne i https://www.nxp.com/docs/da/data- ark/MF0ICU2.pd…

Da beskyttelsen med nøgle er afgørende for brug af Mifare Ultralight C, er alle relevante funktioner til stede.

Alle kommandoer bruges i den serielle skærm med "kun ny linje" og med 115200 Baud

• “Auth 49454D4B41455242214E4143554F5946” vil anmode om en godkendelse med den givne nøgle (i dette tilfælde standard Mifare Ultralight C -nøgle)
• "Dump" vil dumpe indholdet af kortet, så langt det er synligt. Hvis sider er beskyttet af nøglen, er disse sider muligvis ikke synlige før en tidligere godkendelse med nøgle. I de to første kolonner angives det, om siderne er låst, eller adgangen er begrænset.
• “NewKey 49454D4B41455242214E4143554F5946” skriver en ny nøgle til kortet. Nøglen skrives til siderne 44 til 47. Dette fungerer kun, hvis disse sider hverken er låst eller beskyttet uden en tidligere godkendelse.
• "wchar 10 hello world" vil skrive "hej verden" fra side 10. Igen er dette kun værker på siderne hverken låst eller beskyttet uden en tidligere godkendelse. Når du prøver at skrive over side 39 eller under side 4, vil dette bede om en fejl eller data ignoreres, da disse sider ikke er brugerhukommelse.
• “Whex 045ACBF44688” vil skrive hex -værdier direkte til hukommelsen, tidligere betingelser gælder.
• “Beskytte 30” beskytter alle siderne fra side 30 og opefter. Afhængigt af tilladelsen kan disse sider derefter kun ændres eller læses efter en forudgående godkendelse med nøgle. Brug af "beskytt" med værdier højere end 47 vil indstille alle sider til "ubeskyttet" INKLUSIVE NØGLEN på siderne 44-47 (som kun kan ændres, men ikke læses). For at forhindre ændring af nøglen skal beskyttelsen i det mindste starte på side 44.
• “Setpbit 0” indstiller beskyttelsesbitten og afgør, om de beskyttede sider er skrivebeskyttet (“setpbit 1”) eller hverken kan læses, ikke skrevet (“setpbit 0”) uden en tidligere godkendelse med nøgle.

Ikke alle kommandoer kan bruges umiddelbart efter, at kortet blev opdaget. Et "dump" tidligere til en anden kommando hjælper altid.

Trin 3: Vigtigt

1. Programmet skelner mellem Ultralight -typerne ved at læse side 43 og 44. Hvis side 43 er læsbar og side 44 ikke, er det højst sandsynligt en Ultralight C. MEN, hvis du læser/skriver beskytter side 43, genkendes kortet ikke længere som Ultralight C (har ingen effekt på noget) Den korrekte identifikation af Ultralight skal foretages via godkendelse med nøgle (jeg implementerede det ikke på grund af stabilitetsmæssige årsager).
2. Inden kommandoerne "setpbit" og "protect" bruges, skal kommandoen "dump" bruges, ellers kendes sidernes beskyttelsesstatus ikke.
3. Hvis du "læser/skriver" beskytter de første sider på dit kort, fungerer det ikke længere med dette program, da den første side læses konstant for at se, om der stadig er et kort til stede. Da de to første sider alligevel kun er læst (UID er gemt der), er der ingen mening i at beskytte dem.

Stabilitet spørgsmål

Denne kode bruger "standard" RC522 -biblioteket til Arduino og et 3DES -bibliotek fra https://github.com/Octoate/ArduinoDES. Hvorimod RC522 -biblioteket er ret almindeligt brugt, virker 3DES -biblioteket ikke så udbredt og skal installeres manuelt.

Koden er testet på en Arduino Uno. Men mens jeg skrev det, stødte jeg på mange underlige problemer med hensyn til stabilitet. På en eller anden måde er mine programmeringsevner ikke så gode, et af de brugte biblioteker er ustabilt, eller blanding af bibliotekerne er ikke en god idé.

Husk dette, når du bruger koden !!!

Hvis du ændrer det eller kun bruger dele af det, kan det føre til mærkelig opførsel som f.eks. Nedbrud, udskrivning af underlige ting eller få timeouts eller NAK, når du læser fra kortet. Dette kan ske ethvert sted i koden (det kostede mig mange timers fejlfinding). Hvis du finder årsagen til dette, så giv mig et tip.