Bruke Mifare Ultralight C med RC522 på Arduino: 3 trinn

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:21

Å bruke RFID -teknologi for å identifisere kortholdere eller for å autorisere å gjøre noe (åpne en dør osv.) Er en ganske vanlig tilnærming. Ved DIY -bruk er RC522 -modulen mye brukt, da den er ganske billig og det finnes mye kode for denne modulen.

I de fleste tilfeller brukes UID for kortet for å "identifisere" kortholderen, og Mifare Classic -kort brukes da de er billige og ofte inkludert når du kjøper en RC522 -modul.

Men som du kanskje vet, har Mifare Classic -systemet blitt hacket i noen år, og det regnes ikke som trygt lenger. Krypteringssystemet Crypto1 som brukes av Classic-kort kan overvinnes, og det er omskrivbare kort der data og UID kan omprogrammeres (magiske kort).

Så for alle sikkerhetsrelevante applikasjoner anbefales ikke bruk av Mifare Classic -kort! Det samme gjelder for (de fleste) NTAG- og Mifare Ultralight -systemer

Så valget er enten å bruke et profesjonelt system eller prøve å bruke et sikrere RFID -system. Tilgjengelige systemer er Mifare Ultralight C, Mifare DESFire og Mifare Plus. Siden det er mange profesjonelle systemer som bruker disse sikrere systemene, er det for DIY -fellesskapet praktisk talt ingen løsninger (det er en Teensy -basert DESFire -løsning, som er basert på det dyrere PN523 breakout -kortet). Dessuten er DESFire -kortene ganske dyre. Så utfordringen var å finne en bedre og billigere løsning.

Den presenterte løsningen gir full tilgang til de billige Mifare Ultralight “C” -kortene ved hjelp av den billige kinesiske RC522 DIY -modulen. Basert på denne koden kan den sikre Mifare Ultralight C brukes i DIY -applikasjoner.

Trinn 1: Forutsetninger

Selv om RC522 er godt designet, er den i de fleste tilfeller dårlig bygget siden noen komponenter er dårlig dimensjonert. Dette fører til modulens dårlige rykte at den har lav følsomhet, og ikke alle typer kort vil bli identifisert. Spesielt Mifare Ultralight C vil verken bli identifisert eller det vil være mulig å lese kortene.

Hovedproblemet er spesifikasjonen til induktorene L1 og L2. Som beskrevet på https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Bare ved å bytte disse induktorene til passende, f.eks. FERROCORE CW1008-2200 plutselig viser RC522 hva det virkelige potensialet er.

Så før du prøver den gitte koden, MÅ du bytte induktorene. Det vil bare ikke fungere med de forhåndsinstallerte induktorene!

Bakgrunnen for alt dette er at Ultralight C -kortene er ganske energisultne. Denne energien leveres av RC522 RF-feltet. På grunn av lav strømstyrke av induktorene, er energifeltet bare ikke kraftig nok til å drive Ultralight C. Andre kort som Mifare Classic trenger bare mindre strøm og fungerer derfor ganske stabilt.

Trinn 2: Hvordan fungerer det?

Så etter å ha endret RC522 -modulen, hvordan kan du bruke Mifare Ulralight C for søknaden din?

Trikset er at Mifare Ultralight C støtter passordgodkjenning basert på 3DES -krypteringen. Ved å bruke dette passordet kan innholdet på kortet gjøres "skrivebeskyttet" eller helt usynlig for en uautorisert bruker.

For å bruke denne passordbeskyttelsen må passordet skrives til kortet og sidene må beskyttes. Når du er ferdig, kan du bekrefte kortet i søknaden din enten ved å be om et passordbasert godkjenning eller i tillegg klare data fra et beskyttet område. Bare hvis dette lykkes, vet du at du kan stole på den medfølgende UID -en på kortet.

Vær forsiktig: uten den passordbaserte autentiseringen kan du fremdeles ikke stole på et Mifare Ultralight C -kort, siden det også er "magiske kort" som simulerer Ultralight C.

Hvert kort som er uavhengig av teknologien (hvis det er i riktig frekvens) vil svare med sitt UID når det drives av RF-feltet og be om å identifisere seg selv. I tillegg gir de en SAK -verdi som gir minimal informasjon om hvilken type kort som er tilstede. Dessverre identifiserer alle Mifare Ultralight og NTAG seg som symetypen (SAK = 0x00), inkludert Mifare Ultralight C. Så ved polling for kort vil minst SAK -verdien på 0x00 gi et hint om at det kan være en Ultralight C på leseren.

For å sikre at det er en Ultralight C, kan en forespørsel om kryptert autentisering sendes til kortet. Hvis dette IKKE er et Ultralight C-kort, vil denne forespørselen ikke bli forstått, og svaret vil være et NAK (not-acknolege).

Hvis dette er et Ulralight C -kort, får du et 8 bytes svar. Disse 8 Bytes er et tilfeldig tall “B” (RndB) kryptert av den lagrede nøkkelen på kortet ved hjelp av 3DES -krypteringen.

Denne krypterte RndB må dekrypteres med den samme nøkkelen i programmet. Dette tilfeldige tallet blir deretter litt modifisert (rotert med en byte → byte 1 flyttes til byte 8 og alle andre byte skyves en byte lavere, deretter kalt RndB’). Programmet genererer deretter et 8 Byte tilfeldig tall "A" selv (RndA) og knytter denne RndA til den modifiserte RndB’. Dette krypteres igjen med nøkkelen og sendes til kortet.

Kortet dekrypterer meldingen og sjekker om RndB’passer til den tidligere genererte RndB på kortet. Hvis de stemmer overens, vet kortet nå at programmet kjenner nøkkelen.

På dette tidspunktet vet programmet fremdeles ikke om kortet kjenner nøkkelen og derfor kan stole på eller ikke. For å oppnå dette, roterer kortet nå den dekrypterte RndA med en byte, deretter krypterer disse byte ved hjelp av nøkkelen og sender dem tilbake.

Programmet vil deretter dekryptere svaret på kortet og sjekke om den opprinnelige RndA og den svarte RndA stemmer overens. KUN DA vet begge enhetene (program og kort) at de deler kunnskapen om den samme nøkkelen.

Denne prosessen skal bare brukes til å autentisere. All videre kommunikasjon er alltid i "klar tekst".

Selv om det er "magiske Ultralight C" -kort der UID kan endres, kan selve nøkkelen ikke hentes fra kortet, og 3DES -krypteringen er ganske sikker. Nøkkelen er en 16 Byte -nøkkel, så en brute force -tilnærming for å få nøkkelen vil ta litt tid.

Som nevnt er kommunikasjonen før autentisering og etter autentisering alltid i klartekst (aka ikke kryptert). Når du skriver en ny nøkkel til kortet, kan nøkkelen bli sniffet ut ved hjelp av riktig utstyr. Så vær så snill å skrive nøkkelen bare i et sikkert miljø og hold nøkkelen hemmelig.

Når du bruker Ultralight C -kortet

Ultralight C -kortet har flere innebygde sikkerhetsfunksjoner:

1. One Time Programming (OTP) minne. I dette området kan biter skrives, buss ikke slettet.
2. En 16 bit enveis teller. Denne telleren kan bare økes når den er tilgjengelig.
3. En "skrive" eller "lese/skrive" beskyttelse av sider i minnet. Bare hvis de er godkjent med nøkkelen, kan disse sidene leses eller endres.
4. En frysing / blokkering av individuelle sider for å beskytte mot endringer.

Verken bruk av OTP, 16-bitstelleren eller bruken av blokkeringsbiten er implementert i den gitte koden, men kan enkelt implementeres basert på informasjonen gitt i https://www.nxp.com/docs/en/data- ark/MF0ICU2.pd …

Siden nøkkelbeskyttelsen er avgjørende for bruk av Mifare Ultralight C, er alle relevante funksjoner tilstede.

Alle kommandoer brukes i seriell monitor med "bare ny linje" og med 115200 Baud

• “Auth 49454D4B41455242214E4143554F5946” vil be om autentisering med den angitte nøkkelen (i dette tilfellet standard Mifare Ultralight C -nøkkel)
• "Dump" vil dumpe innholdet på kortet så langt det er synlig. Hvis sider er beskyttet av nøkkelen, er det ikke sikkert at disse sidene er synlige før en tidligere godkjenning med nøkkel. I de to første kolonnene indikeres det om sider er låst eller tilgangen er begrenset.
• “NewKey 49454D4B41455242214E4143554F5946” vil skrive en ny nøkkel til kortet. Nøkkelen skrives til sidene 44 til 47. Dette fungerer bare hvis disse sidene verken er låst eller beskyttet uten en tidligere godkjenning.
• "wchar 10 hello world" vil skrive "hei verden" fra side 10. Igjen er dette bare sidene verken låst eller beskyttet uten en tidligere autentisering. Når du prøver å skrive over side 39 eller under side 4, vil dette be om en feil eller data ignoreres da disse sidene ikke er brukerminne.
• “Whex 045ACBF44688” vil skrive Hex -verdier direkte til minnet, tidligere betingelser gjelder.
• “Beskytte 30” beskytter alle sidene fra side 30 og oppover. Avhengig av tillatelse kan disse sidene deretter bare endres eller leses etter en tidligere godkjenning med nøkkel. Hvis du bruker "beskytt" med verdier høyere enn 47, vil alle sider settes til "ubeskyttet" INKLUDERT NØKKELEN på side 44-47 (som bare kan endres, men ikke leses). For å forhindre at nøkkelen endres, bør beskyttelsen minst starte på side 44.
• “Setpbit 0” angir beskyttelsesbiten og avgjør om de beskyttede sidene er skrivebeskyttet (“setpbit 1”) eller ikke kan leses ikke skrives (“setpbit 0”) uten en tidligere godkjenning med nøkkel.

Ikke alle kommandoer kan brukes umiddelbart etter at kortet ble oppdaget. En "dump" tidligere til en annen kommando hjelper alltid.

Trinn 3: Viktig

1. Programmet skiller mellom Ultralight -typene ved å lese side 43 og 44. Hvis side 43 er lesbar og side 44 ikke, er det mest sannsynlig en Ultralight C. MEN, hvis du leser/skriver beskytter side 43, blir kortet ikke lenger gjenkjent som Ultralight C (har ingen effekt på noe) Riktig identifisering av Ultralight bør gjøres via autentisering med nøkkel (jeg implementerte det ikke på grunn av stabilitetshensyn).
2. Før du bruker kommandoene "setpbit" og "beskytte" må kommandoen "dump" brukes, ellers vil ikke beskyttelsesstatusen til sidene være kjent.
3. Hvis du "leser/skriver" beskytter de første sidene på kortet ditt, vil det ikke fungere lenger med dette programmet ettersom den første siden leses konstant for å se om det fortsatt er et kort tilstede. Ettersom de to første sidene er skrivebeskyttet uansett (UID er lagret der), er det ingen mening å beskytte dem.

Spørsmål om stabilitet

Denne koden bruker det "vanlige" RC522 -biblioteket for Arduino og et 3DES -bibliotek fra https://github.com/Octoate/ArduinoDES. Mens RC522 -biblioteket er ganske vanlig, virker 3DES -biblioteket ikke så utbredt og må installeres manuelt.

Koden er testet på en Arduino Uno. Men mens jeg skrev den, møtte jeg mange rare problemer med hensyn til stabilitet. På en eller annen måte er programmeringskunnskapene mine ikke så gode, et av de brukte bibliotekene er ustabilt, eller blanding av bibliotekene er ikke en god idé.

Vær oppmerksom på dette når du bruker koden !!!

Hvis du endrer det eller bruker bare deler av det, kan det føre til merkelig oppførsel som å krasje, skrive ut rare ting eller få timeout eller NAK når du leser fra kortet. Dette kan skje hvor som helst i koden (det kostet meg mange timer med feilsøking). Hvis du finner årsaken (e) til dette, vennligst gi meg et hint.