Mifare Ultralight C gebruiken met RC522 op Arduino - Ajarnpa

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:14

Het gebruik van RFID-technologie om kaarthouders te identificeren of om iets te autoriseren (een deur openen etc.) is een vrij gebruikelijke aanpak. In het geval van doe-het-zelf-toepassingen wordt de RC522-module veel gebruikt, omdat deze vrij goedkoop is en er veel code voor deze module bestaat.

In de meeste gevallen wordt de UID van de kaart gebruikt om de kaarthouder te "identificeren", en Mifare Classic-kaarten worden gebruikt omdat ze goedkoop zijn en vaak worden meegeleverd bij het kopen van een RC522-module.

Maar zoals u wellicht weet, is het Mifare Classic-systeem al enkele jaren gehackt en wordt het niet meer als veilig beschouwd. Het coderingssysteem Crypto1 dat door Classic-kaarten wordt gebruikt, kan worden overwonnen en het zijn herschrijfbare kaarten waar gegevens en een UID opnieuw kunnen worden geprogrammeerd (magische kaarten).

Dus voor elke veiligheidsrelevante toepassing wordt het gebruik van Mifare Classic-kaarten niet aanbevolen! Hetzelfde geldt voor (de meeste) NTAG en Mifare Ultralight systemen

De keuze is dus ofwel om een professioneel systeem te gebruiken of om een veiliger RFID-systeem te gebruiken. Beschikbare systemen zijn Mifare Ultralight C, Mifare DESFire en Mifare Plus. Aangezien er veel professionele systemen zijn die deze veiligere systemen gebruiken, zijn er voor de doe-het-zelfgemeenschap vrijwel geen oplossingen (er is één op Teensy gebaseerde DESFire-oplossing, die is gebaseerd op het duurdere PN523-breakoutboard). Bovendien zijn de DESFire-kaarten behoorlijk duur. De uitdaging was dus om een betere en goedkopere oplossing te vinden.

De gepresenteerde oplossing biedt volledige toegang tot de goedkope Mifare Ultralight "C" -kaarten met behulp van de goedkope Chinese RC522 DIY-module. Op basis van deze code kan de veilige Mifare Ultralight C worden gebruikt in doe-het-zelf toepassingen.

Stap 1: Randvoorwaarden

Hoewel de RC522 goed is ontworpen, is hij in de meeste gevallen slecht gebouwd omdat sommige componenten slecht gedimensioneerd zijn. Dit leidt tot de slechte reputatie van de module dat deze een lage gevoeligheid heeft en dat niet alle soorten kaarten worden geïdentificeerd. Vooral de Mifare Ultralight C zal niet worden geïdentificeerd en het zal ook niet mogelijk zijn om de kaarten te lezen.

Het grootste probleem is de specificatie van de inductoren L1 en L2. Zoals beschreven op https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Gewoon door deze smoorspoelen te vervangen door geschikte, b.v. FERROCORE CW1008-2200 plotseling laat de RC522 zien wat zijn echte potentieel is.

Dus voordat u de gegeven code probeert, MOET u de inductoren VERVANGEN. Het werkt gewoon niet met de vooraf geïnstalleerde inductoren!

De achtergrond van dit alles is dat de Ultralight C-kaarten behoorlijk energieverslindend zijn. Deze energie wordt geleverd door het RC522 RF-veld. Door de lage stroomsterkte van de inductoren is het energieveld net niet krachtig genoeg om de Ultralight C van stroom te voorzien. Andere kaarten zoals de Mifare Classic hebben gewoon minder stroom nodig en werken daardoor redelijk stabiel.

Stap 2: Hoe werkt het?

Dus hoe kunt u de Mifare Ulralight C voor uw toepassing gebruiken na het aanpassen van de RC522-module?

De truc is dat Mifare Ultralight C een wachtwoordverificatie ondersteunt op basis van het 3DES-cijfer. Door dit wachtwoord te gebruiken, kan de inhoud van de kaart "alleen-lezen" of volledig onzichtbaar worden gemaakt voor een onbevoegde gebruiker.

Om deze wachtwoordbeveiliging te gebruiken, moet het wachtwoord op de kaart worden geschreven en moeten de pagina's worden beveiligd. Als u klaar bent, kunt u de kaart in uw toepassing verifiëren door gewoon om een op een wachtwoord gebaseerde authenticatie te vragen of door aanvullende gegevens uit een beveiligd gebied. Pas als dit gelukt is, weet je dat je de verstrekte UID op de kaart kunt vertrouwen.

Pas op: zonder de op wachtwoord gebaseerde authenticatie kun je een Mifare Ultralight C-kaart nog steeds niet vertrouwen, omdat er ook "magische kaarten" zijn die de Ultralight C simuleren.

Elke kaart, onafhankelijk van de technologie (indien in de juiste frequentie) zal reageren met hun UID wanneer gevoed door het RF-veld en vragen om zichzelf te identificeren. Bovendien bieden ze een SAK-waarde die minimale informatie geeft over het type kaart dat aanwezig is. Helaas identificeren alle Mifare Ultralight en NTAG zich als het syme-type (SAK=0x00), inclusief de Mifare Ultralight C. Dus bij het peilen naar kaarten, zal ten minste de SAK-waarde van 0x00 een hint geven dat er mogelijk een Ultralight C op de lezer staat.

Om er zeker van te zijn dat het een Ultralight C is, kan een verzoek voor versleutelde authenticatie naar de kaart worden gestuurd. Als dit GEEN Ultralight C-kaart is, wordt dit verzoek niet begrepen en is het antwoord een NAK (not-acnolege).

Als dit een Ulralight C-kaart is, krijgt u een antwoord van 8 bytes. Deze 8 bytes zijn een willekeurig getal "B" (RndB) gecodeerd door de opgeslagen sleutel op de kaart met behulp van de 3DES-codering.

Deze versleutelde RndB moet worden ontsleuteld met dezelfde sleutel in het programma. Dit willekeurige getal wordt dan enigszins gewijzigd (één byte gedraaid → byte 1 wordt verplaatst naar byte 8 en alle andere bytes worden één byte lager geduwd en worden dan RndB' genoemd). Het programma genereert dan zelf een 8 Byte willekeurig getal "A" (RndA) en koppelt deze RndA aan de gewijzigde RndB'. Deze wordt opnieuw versleuteld met de sleutel en naar de kaart gestuurd.

De kaart decodeert het bericht en controleert of RndB' past bij de eerder gegenereerde RndB op de kaart. Als ze overeenkomen, weet de kaart nu dat het programma de sleutel kent.

Op dit moment weet het programma nog steeds niet of de kaart de sleutel kent en dus te vertrouwen is of niet. Om dit te bereiken, roteert de kaart nu de gedecodeerde RndA met één byte, versleutelt deze bytes vervolgens met de sleutel en stuurt ze terug.

Het programma zal dan het antwoord van de kaart decoderen en controleren of de oorspronkelijke RndA en de beantwoorde RndA overeenkomen. ALLEEN DAN weten beide entiteiten (programma en kaart) dat ze de kennis van dezelfde sleutel delen.

Dit proces wordt alleen gebruikt om te verifiëren. Alle verdere communicatie is altijd in “clear text”.

Hoewel er "magic Ultralight C"-kaarten zijn waarbij de UID kan worden gewijzigd, kan de sleutel zelf niet van de kaart worden verkregen en is de 3DES-codering redelijk veilig. De sleutel is een sleutel van 16 bytes, dus een brute force-aanpak om de sleutel te verkrijgen, zal enige tijd duren.

Zoals vermeld, is de communicatie voorafgaand aan authenticatie en na authenticatie altijd in duidelijke tekst (ook bekend als niet-versleuteld). Bij het schrijven van een nieuwe sleutel op de kaart kan met behulp van de juiste apparatuur de inhoud van de sleutel worden opgespoord. Schrijf de sleutel dus alleen in een beveiligde omgeving en houd de sleutel geheim.

Bij gebruik van de Ultralight C-kaart

De Ultralight C-kaart heeft meerdere ingebouwde beveiligingsfuncties:

1. Eenmalig programmeren (OTP) geheugen. In dit gebied kunnen bits worden geschreven, bus niet verwijderd.
2. Een 16-bits eenrichtingsteller. Deze teller kan alleen worden verhoogd als deze is geactiveerd.
3. Een “schrijf” of “lees/schrijf” beveiliging van pagina's in het geheugen. Alleen indien geauthenticeerd met de sleutel, kunnen deze pagina's worden gelezen of gewijzigd.
4. Een bevriezing / blokkering van afzonderlijke pagina's om te beschermen tegen elke wijziging.

Noch het gebruik van OTP, de 16-bits teller, noch het gebruik van de blokkeerbit is geïmplementeerd in de gegeven code, maar kan eenvoudig worden geïmplementeerd op basis van de informatie op https://www.nxp.com/docs/en/data- blad/MF0ICU2.pd…

Omdat de beveiliging per sleutel essentieel is voor het gebruik van de Mifare Ultralight C, zijn alle relevante functies aanwezig.

Alle commando's worden gebruikt in de seriële monitor met "alleen nieuwe regel" en met 115200 Baud

• “auth 49454D4B41455242214E4143554F5946” zal een authenticatie vragen met de gegeven sleutel (in dit geval de standaard Mifare Ultralight C-sleutel)
• "dump" dumpt de inhoud van de kaart voor zover ze zichtbaar zijn. Als pagina's worden beschermd door de sleutel, zijn deze pagina's mogelijk pas zichtbaar na een eerdere authenticatie met sleutel. In de eerste twee kolommen wordt aangegeven of pagina's zijn vergrendeld of de toegang is beperkt.
• “newKey 49454D4B41455242214E4143554F5946” zal een nieuwe sleutel naar de kaart schrijven. De sleutel wordt naar de pagina's 44 t/m 47 geschreven. Dit werkt alleen als deze pagina's niet zijn vergrendeld of beveiligd zonder voorafgaande authenticatie.
• "wchar 10 hello world" zal "hello world" schrijven vanaf pagina 10. Nogmaals, dit alleen werken van de pagina's is niet vergrendeld of beschermd zonder een eerdere authenticatie. Wanneer u probeert om boven pagina 39 of onder pagina 4 te schrijven, zal dit een fout of gegevens worden genegeerd omdat deze pagina's geen gebruikersgeheugen zijn.
• "whex 045ACBF44688" zal Hex-waarden rechtstreeks naar het geheugen schrijven, eerdere voorwaarden zijn van toepassing.
• "protect 30" beschermt alle pagina's vanaf pagina 30. Afhankelijk van de toestemming kunnen deze pagina's dan pas na een voorafgaande authenticatie met sleutel worden gewijzigd of uitgelezen. Als u "protect" gebruikt met waarden hoger dan 47, worden alle pagina's op "unprotected" ingesteld, INCLUSIEF DE SLEUTEL op pagina's 44-47 (die dan alleen kan worden gewijzigd maar niet kan worden gelezen). Om het wijzigen van de sleutel te voorkomen, moet de beveiliging in ieder geval beginnen bij pagina 44.
• "setpbit 0" stelt de beschermingsbit in en beslist of de beveiligde pagina's alleen-lezen ("setpbit 1") of niet kunnen worden gelezen en niet geschreven ("setpbit 0") zonder voorafgaande authenticatie met sleutel.

Niet alle opdrachten kunnen direct worden gebruikt nadat de kaart is gedetecteerd. Een "dump" eerder naar een ander commando helpt altijd.

Stap 3: Belangrijk

1. Het programma maakt onderscheid tussen de Ultralight-types door pagina 43 en 44 te lezen. Als pagina 43 wel leesbaar is en pagina 44 niet, is het hoogstwaarschijnlijk een Ultralight C. MAAR, als u de pagina 43 tegen lezen/schrijven beveiligt, wordt de kaart niet meer herkend als Ultralight C (heeft nergens invloed op) De juiste identificatie van de Ultralight moet gebeuren via de authenticatie met sleutel (ik heb dat niet geïmplementeerd vanwege stabiliteitsredenen).
2. Voorafgaand aan het gebruik van de commando's "setpbit" en "protect" moet het commando "dump" worden gebruikt, anders is de beveiligingsstatus van de pagina's niet bekend.
3. Als je de eerste pagina's van je kaart "lees/schrijf" beveiligt, zal het niet meer werken met dit programma omdat de eerste pagina constant wordt gelezen om te zien of er nog een kaart aanwezig is. Aangezien de eerste twee pagina's sowieso alleen worden gelezen (de UID wordt daar opgeslagen), heeft het geen zin om ze te beschermen.

Stabiliteitsproblemen

Deze code gebruikt de "standaard" RC522-bibliotheek voor Arduino en een 3DES-bibliotheek van https://github.com/Octoate/ArduinoDES. Terwijl de RC522-bibliotheek vrij algemeen wordt gebruikt, lijkt de 3DES-bibliotheek niet zo wijdverbreid en moet deze handmatig worden geïnstalleerd.

De code is getest op een Arduino Uno. Maar tijdens het schrijven kwam ik veel rare problemen tegen met betrekking tot stabiliteit. Op de een of andere manier zijn mijn programmeervaardigheden niet zo goed, is een van de gebruikte bibliotheken onstabiel of is het mixen van bibliotheken geen goed idee.

Houd hier rekening mee bij het gebruik van de code!!!

Het wijzigen of alleen delen ervan gebruiken kan leiden tot vreemd gedrag, zoals crashen, rare dingen afdrukken of time-outs of NAK krijgen bij het lezen van de kaart. Dit kan op elke plaats in de code gebeuren (het kostte me vele uren debuggen). Als je de reden(en) hiervoor vindt, geef me dan een hint.