Använda Mifare Ultralight C med RC522 på Arduino: 3 steg

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:37

Att använda RFID -teknik för att identifiera kortinnehavare eller för att ge tillstånd att göra något (öppna en dörr etc.) är ett ganska vanligt tillvägagångssätt. Vid DIY -applikation används RC522 -modulen i stor utsträckning eftersom den är ganska billig och det finns mycket kod för den här modulen.

I de flesta fall används kortets UID för att”identifiera” korthållaren, och Mifare Classic -kort används eftersom de är billiga och ingår ofta när man köper en RC522 -modul.

Men som du kanske vet har Mifare Classic -systemet hackats i några år och det anses inte längre vara säkert. Krypteringssystemet Crypto1 som används av Classic-kort kan övervinnas och det är omskrivbara kort där data och UID kan omprogrammeras (magiska kort).

Så för alla säkerhetsrelevanta applikationer rekommenderas inte användning av Mifare Classic -kort! Detsamma gäller för (de flesta) NTAG- och Mifare Ultralight -system

Så valet är antingen att använda ett professionellt system eller att försöka använda ett säkrare RFID -system. Tillgängliga system är Mifare Ultralight C, Mifare DESFire och Mifare Plus. Eftersom det finns många professionella system som använder dessa säkrare system, finns det för DIY -samhället praktiskt taget inga lösningar (det finns en Teensy -baserad DESFire -lösning, som är baserad på det dyrare PN523 -utbrottskortet). Dessutom är DESFire -korten ganska dyra. Så utmaningen var att hitta en bättre och billigare lösning.

Den presenterade lösningen ger full tillgång till de billiga Mifare Ultralight “C” -korten med den billiga kinesiska RC522 DIY -modulen. Baserat på denna kod kan den säkra Mifare Ultralight C användas i DIY -applikationer.

Steg 1: Förutsättningar

Även om RC522 är väl utformad, är den i de flesta fall dåligt byggd eftersom vissa komponenter är dåligt dimensionerade. Detta leder till modulens dåliga rykte att den har låg känslighet och inte alla typer av kort kommer att identifieras. Speciellt Mifare Ultralight C kommer varken att identifieras eller att det är möjligt att läsa korten.

Huvudproblemet är specifikationen för induktorerna L1 och L2. Som beskrivs på https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Bara genom att ersätta dessa induktorer till lämpliga sådana t.ex. FERROCORE CW1008-2200 visar plötsligt RC522 vad dess verkliga potential är.

Så innan du provar den angivna koden måste du byta induktorerna. Det kommer bara inte att fungera med de förinstallerade induktorerna!

Bakgrunden till allt detta är att Ultralight C -korten är ganska energisugna. Denna energi tillhandahålls av RC522 RF-fältet. På grund av låg strömstyrka hos induktorerna är energifältet bara inte tillräckligt kraftfullt för att driva Ultralight C. Andra kort som Mifare Classic behöver bara mindre ström och fungerar därför ganska stabilt.

Steg 2: Hur fungerar det?

Så efter att ha ändrat RC522 -modulen, hur kan du använda Mifare Ulralight C för din applikation?

Tricket är att Mifare Ultralight C stöder en lösenordsautentisering baserad på 3DES -krypteringen. Genom att använda det här lösenordet kan innehållet på kortet göras”skrivskyddat” eller helt osynligt för en obehörig användare.

För att kunna använda detta lösenordsskydd måste lösenordet skrivas till kortet och sidorna måste skyddas. När du är klar kan du verifiera kortet i din applikation antingen genom att bara be om ett lösenordsbaserat verifieringssystem eller ytterligare färdiga data från ett skyddat område. Endast om detta lyckas vet du att du kan lita på det tillhandahållna UID -kortet.

Akta dig: utan lösenordsbaserad autentisering kan du fortfarande inte lita på ett Mifare Ultralight C -kort, eftersom det också finns "magiska kort" som simulerar Ultralight C.

Varje kort som är oberoende av tekniken (om det är i rätt frekvens) svarar med sitt UID när det drivs av RF-fältet och begär att de ska identifiera sig. Dessutom ger de ett SAK -värde som ger minimal information om vilken typ av kort som finns. Tyvärr identifierar alla Mifare Ultralight och NTAG som symetypen (SAK = 0x00), inklusive Mifare Ultralight C. Så vid polling efter kort ger åtminstone SAK -värdet 0x00 en antydan om att det kan finnas ett Ultralight C på läsaren.

För att vara säker på att det är en Ultralight C kan en begäran om krypterad autentisering skickas till kortet. Om detta INTE är ett Ultralight C-kort kommer denna begäran inte att förstås och svaret kommer att vara ett NAK (not-acknolege).

Om detta är ett Ulralight C -kort får du ett 8 bytes svar. Dessa 8 bytes är ett slumpmässigt nummer “B” (RndB) krypterat av den lagrade nyckeln på kortet med hjälp av 3DES -krypteringen.

Denna krypterade RndB måste dekrypteras med samma nyckel i programmet. Detta slumpmässiga tal ändras sedan något (roteras med en byte → byte 1 flyttas till byte 8 och alla andra byte trycks en byte lägre, kallas sedan RndB’). Programmet genererar sedan ett 8 Byte slumpmässigt nummer "A" själv (RndA) och fäster denna RndA till den modifierade RndB’. Detta krypteras igen med nyckeln och skickas till kortet.

Kortet dekrypterar meddelandet och kontrollerar om RndB’passar till den tidigare genererade RndB på kortet. Om de matchar vet kortet nu att programmet känner till nyckeln.

Vid denna tidpunkt vet programmet fortfarande inte om kortet känner till nyckeln och därför kan lita på eller inte. För att uppnå detta roterar kortet nu den dekrypterade RndA med en byte och krypterar sedan dessa byte med nyckeln och skickar tillbaka dem.

Programmet kommer att dekryptera svaret på kortet och kontrollera om det ursprungliga RndA och det svarade RndA matchar. ENDAST då vet båda enheterna (program och kort) att de delar kunskapen om samma nyckel.

Denna process används endast för autentisering. All vidare kommunikation sker alltid i”klartext”.

Även om det finns "magiska Ultralight C" -kort där UID kan modifieras, kan själva nyckeln inte hämtas från kortet och 3DES -krypteringen är ganska säker. Nyckeln är en 16 Byte -nyckel, så en brute force -strategi för att få nyckeln tar lite tid.

Som sagt är kommunikationen före autentisering och efter autentisering alltid i klartext (aka inte krypterad). När du skriver en ny nyckel till kortet kan innehållet i nyckeln nosas ut med hjälp av rätt utrustning. Så skriv bara nyckeln i en säker miljö och håll nyckeln hemlig.

När du använder Ultralight C -kortet

Ultralight C -kortet har flera inbyggda säkerhetsfunktioner:

1. One Time Programming (OTP) minne. I detta område kan bitar skrivas, buss inte raderas.
2. En 16 -bitars enkelriktad räknare. Denna räknare kan bara öka när den är ansluten.
3. Ett”skriv” eller”läs/skriv” skydd av sidor i minnet. Endast om de är autentiserade med nyckeln kan dessa sidor läsas eller ändras.
4. En frysning / blockering av enskilda sidor för att skydda mot eventuella ändringar.

Varken användningen av OTP, 16-bitarsräknaren eller användningen av blockeringsbiten är implementerad i den angivna koden, men kan enkelt implementeras baserat på informationen i https://www.nxp.com/docs/en/data- blad/MF0ICU2.pd …

Eftersom nyckelskyddet är viktigt för att använda Mifare Ultralight C finns alla relevanta funktioner.

Alla kommandon används i seriemonitorn med "endast ny linje" och med 115200 Baud

• “Auth 49454D4B41455242214E4143554F5946” kommer att begära en autentisering med den angivna nyckeln (i detta fall standard Mifare Ultralight C -nyckel)
• "Dump" kommer att dumpa innehållet på kortet så långt det är synligt. Om sidor skyddas av nyckeln kanske dessa sidor inte är synliga förrän en tidigare autentisering med nyckel. I de två första kolumnerna anges om sidorna är låsta eller om tillgången är begränsad.
• “NewKey 49454D4B41455242214E4143554F5946” skriver en ny nyckel till kortet. Nyckeln skrivs till sidorna 44 till 47. Detta fungerar bara om dessa sidor varken är låsta eller skyddade utan en tidigare autentisering.
• "wchar 10 hello world" kommer att skriva "hej värld" från och med sidan 10. Återigen är detta bara sidorna varken låsta eller skyddade utan en tidigare autentisering. När du försöker skriva ovan sidan 39 eller under sidan 4 kommer detta att uppmana en fel eller data ignoreras eftersom dessa sidor inte är användarminne.
• “Whex 045ACBF44688” kommer att skriva Hex -värden direkt till minnet, tidigare villkor gäller.
• ”Skydda 30” skyddar alla sidor från sida 30 och uppåt. Beroende på tillståndet kan dessa sidor sedan endast ändras eller läsas efter en tidigare autentisering med nyckel. Om du använder "skydda" med värden högre än 47 ställs alla sidor till "oskyddade" INKLUSIVE NYCKELN på sidorna 44-47 (som bara kan ändras men inte läsas). För att förhindra att nyckeln ändras bör skyddet åtminstone börja på sidan 44.
• "Setpbit 0" ställer in skyddsbiten och avgör om de skyddade sidorna är skrivskyddade ("setpbit 1") eller inte kan läsas som inte skrivs ("setpbit 0") utan en tidigare autentisering med nyckel.

Alla kommandon kan inte användas direkt efter att kortet upptäcktes. En "dumpning" tidigare till ett annat kommando hjälper alltid.

Steg 3: Viktigt

1. Programmet skiljer mellan Ultralight -typerna genom att läsa sidan 43 och 44. Om sidan 43 är läsbar och sidan 44 inte är det troligtvis en Ultralight C. MEN, om du läser/skriver skyddar sidan 43 igenkänns kortet inte längre som Ultralight C (har ingen effekt på någonting) Korrekt identifiering av Ultralight bör göras via autentisering med nyckel (jag implementerade det inte på grund av stabilitetsskäl).
2. Innan du använder kommandona "setpbit" och "skydda" måste kommandot "dumpa" användas, annars är inte sidornas skyddsstatus känd.
3. Om du "läser/skriver" skyddar de första sidorna på ditt kort fungerar det inte längre med det här programmet eftersom den första sidan läses hela tiden för att se om det fortfarande finns ett kort. Eftersom de två första sidorna är skrivskyddade i alla fall (UID lagras där) har det ingen mening att skydda dem.

Stabilitetsproblem

Denna kod använder "standard" RC522 -biblioteket för Arduino och ett 3DES -bibliotek från https://github.com/Octoate/ArduinoDES. Medan RC522 -biblioteket är ganska vanligt, verkar 3DES -biblioteket inte så utbrett och måste installeras manuellt.

Koden har testats på en Arduino Uno. Men när jag skrev det stötte jag på många konstiga problem när det gäller stabilitet. På något sätt är mina programmeringskunskaper inte så bra, ett av de använda biblioteken är instabilt eller att blanda biblioteken är ingen bra idé.

Tänk på detta när du använder koden !!!

Att byta eller bara använda delar av det kan leda till konstigt beteende som att krascha, skriva ut konstiga saker eller få timeout eller NAK när man läser från kortet. Detta kan hända var som helst i koden (det kostade mig många timmars felsökning). Om du hittar orsaken till detta, ge mig en ledtråd.