Utilizzo di Mifare Ultralight C con RC522 su Arduino: 3 passaggi

2024 Autore: John Day | [email protected]. Ultima modifica: 2024-01-30 09:59

L'utilizzo della tecnologia RFID per identificare i titolari di carta o per autorizzare a fare qualcosa (aprire una porta, ecc.) è un approccio abbastanza comune. In caso di applicazioni fai-da-te, il modulo RC522 è ampiamente utilizzato in quanto è abbastanza economico ed esiste molto codice per questo modulo.

Nella maggior parte dei casi, l'UID della carta viene utilizzato per "identificare" il titolare della carta e vengono utilizzate le carte Mifare Classic in quanto economiche e spesso incluse nell'acquisto di un modulo RC522.

Ma come forse saprai, il sistema Mifare Classic è stato violato per alcuni anni e non è più considerato sicuro. Il sistema di crittografia Crypto1 utilizzato dalle carte Classic può essere superato e le carte sono riscrivibili in cui è possibile riprogrammare i dati e l'UID (carte magiche).

Quindi per qualsiasi applicazione rilevante per la sicurezza l'uso delle carte Mifare Classic non è raccomandato! Lo stesso vale per (la maggior parte) dei sistemi NTAG e Mifare Ultralight

Quindi la scelta è o utilizzare un sistema professionale o provare a utilizzare un sistema RFID più sicuro. I sistemi disponibili sono Mifare Ultralight C, Mifare DESFire e Mifare Plus. Poiché ci sono molti sistemi professionali che utilizzano questi sistemi più sicuri, per la comunità fai-da-te non ci sono praticamente soluzioni (c'è una soluzione DESFire basata su Teensy, che si basa sulla più costosa scheda breakout PN523). Inoltre le carte DESFire sono piuttosto costose. Quindi la sfida era trovare una soluzione migliore e più economica.

La soluzione presentata fornisce pieno accesso alle schede economiche Mifare Ultralight "C" utilizzando il modulo fai-da-te RC522 cinese economico. Sulla base di questo codice, il Mifare Ultralight C sicuro può essere utilizzato in applicazioni fai-da-te.

Fase 1: Precondizioni

Sebbene l'RC522 sia ben progettato, nella maggior parte dei casi è costruito male in quanto alcuni componenti sono mal dimensionati. Ciò porta alla cattiva reputazione del modulo che ha una bassa sensibilità e non tutti i tipi di schede verranno identificati. In particolare il Mifare Ultralight C non sarà identificato né sarà possibile leggere le carte.

Il problema principale è la specifica degli induttori L1 e L2. Come descritto su https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Semplicemente sostituendo questi induttori con quelli appropriati, ad es. FERROCORE CW1008-2200 improvvisamente l'RC522 mostra qual è il suo vero potenziale.

Quindi, prima di provare il codice indicato, DEVI SOSTITUIRE gli induttori. Semplicemente non funzionerà con gli induttori preinstallati!

Lo sfondo di tutto questo è che le carte Ultralight C sono piuttosto affamate di energia. Questa energia è fornita dal campo RF RC522. A causa del basso amperaggio degli induttori, il campo energetico non è abbastanza potente per alimentare l'Ultralight C. Altre schede come la Mifare Classic richiedono solo meno energia e quindi funzionano in modo abbastanza stabile.

Passaggio 2: come funziona?

Quindi, dopo aver modificato il modulo RC522, come puoi utilizzare Mifare Ulralight C per la tua applicazione?

Il trucco è che Mifare Ultralight C supporta un'autenticazione della password basata sul cifrario 3DES. Utilizzando questa password, il contenuto della carta può essere reso “di sola lettura” o completamente invisibile ad un utente non autorizzato.

Per utilizzare questa protezione con password, è necessario scrivere la password sulla scheda e proteggere le pagine. Una volta fatto, puoi verificare la carta nella tua applicazione semplicemente chiedendo un'autenticazione basata su password o anche dati pronti da un'area protetta. Solo in caso di successo, sai che puoi fidarti dell'UID fornito sulla carta.

Attenzione: senza l'autenticazione basata su password non puoi ancora fidarti di una carta Mifare Ultralight C, poiché ci sono anche "carte magiche" che simulano l'Ultralight C.

Ogni scheda indipendente dalla tecnologia (se nella frequenza corretta) risponderà con il proprio UID quando alimentata dal campo RF e richiederà di identificarsi. Inoltre forniscono un valore SAK che fornisce informazioni minime sul tipo di carta presente. Sfortunatamente tutti i Mifare Ultralight e gli NTAG si identificano come il tipo syme (SAK=0x00), incluso il Mifare Ultralight C. Quindi, durante il polling per le carte, almeno il valore SAK di 0x00 indicherà che potrebbe esserci un Ultralight C sul lettore.

Per assicurarsi che si tratti di un Ultralight C è possibile inviare alla scheda una richiesta di autenticazione crittografata. Se NON si tratta di una carta Ultralight C, questa richiesta non verrà compresa e la risposta sarà un NAK (not-acnolege).

Se questa è una carta Ulralight C, otterrai una risposta di 8 byte. Questi 8 byte sono un numero casuale "B" (RndB) crittografato dalla chiave memorizzata sulla scheda utilizzando la cifratura 3DES.

Questo RndB crittografato deve essere decifrato utilizzando la stessa chiave nel programma. Questo numero casuale viene quindi leggermente modificato (ruotato di un byte → il byte 1 verrà spostato al byte 8 e tutti gli altri byte verranno spostati di un byte più in basso, quindi chiamato RndB'). Il programma quindi genera un numero casuale di 8 byte "A" stesso (RndA) e collega questo RndA al RndB' modificato. Questo viene nuovamente crittografato utilizzando la chiave e inviato alla carta.

La carta decifra il messaggio e verifica se RndB' si adatta al RndB precedentemente generato sulla carta. Se corrispondono, la carta ora sa che il programma conosce la chiave.

A questo punto il programma non sa ancora se la carta conosce la chiave e quindi può essere attendibile o meno. Per ottenere ciò, la carta ora ruota l'RndA decifrato di un byte, quindi crittografa questi byte utilizzando la chiave e li restituisce.

Il programma decrittograferà quindi la risposta della carta e verificherà se l'RndA originale e l'RndA replicato corrispondono. SOLO ALLORA entrambe le entità (programma e scheda) sanno di condividere la conoscenza della stessa chiave.

Questo processo viene utilizzato solo per l'autenticazione. Tutte le ulteriori comunicazioni sono sempre in "testo in chiaro".

Sebbene ci siano carte "magic Ultralight C" in cui l'UID può essere modificato, la chiave stessa non può essere ottenuta dalla carta e il codice 3DES è abbastanza sicuro. La chiave è una chiave da 16 byte, quindi un approccio di forza bruta per ottenere la chiave richiederà del tempo.

Come affermato, la comunicazione prima dell'autenticazione e dopo l'autenticazione è sempre in chiaro (ovvero non crittografata). Quando si scrive una nuova chiave sulla carta, il contenuto della chiave può essere annusato utilizzando l'attrezzatura giusta. Quindi, per favore, scrivi la chiave solo in un ambiente sicuro e mantieni la chiave segreta.

Quando si utilizza la scheda Ultralight C

La scheda Ultralight C ha più funzioni di sicurezza integrate:

1. Memoria di programmazione una tantum (OTP). In quest'area si possono scrivere bit, bus non cancellato.
2. Un contatore unidirezionale a 16 bit. Questo contatore può essere incrementato solo se utilizzato.
3. Una protezione “write” o “read/write” delle pagine in memoria. Solo se autenticati con la chiave queste pagine possono essere lette o modificate.
4. Un congelamento/blocco delle singole pagine per proteggerle da qualsiasi modifica.

Né l'uso di OTP, il contatore a 16 bit né l'uso del bit di blocco sono implementati nel codice dato, ma possono essere facilmente implementati in base alle informazioni fornite in https://www.nxp.com/docs/en/data- foglio/MF0ICU2.pd…

Poiché la protezione tramite chiave è essenziale per l'utilizzo di Mifare Ultralight C, tutte le relative funzioni sono presenti.

Tutti i comandi sono utilizzati nel monitor seriale con "solo nuova riga" e con 115200 Baud

• “auth 49454D4B41455242214E4143554F5946” richiederà un'autenticazione con la chiave fornita (in questo caso la chiave Mifare Ultralight C standard)
• "dump" scaricherà il contenuto della carta per quanto è visibile. Nel caso in cui le pagine siano protette dalla chiave, queste pagine potrebbero non essere visibili fino ad una precedente autenticazione con chiave. Nelle prime due colonne viene indicato se le pagine sono bloccate o l'accesso è limitato.
• "newKey 49454D4B41455242214E4143554F5946" scriverà una nuova chiave sulla carta. La chiave viene scritta alle pagine da 44 a 47. Questo funzionerà solo se queste pagine non sono né bloccate né protette senza una precedente autenticazione.
• "wchar 10 hello world" scriverà "hello world" a partire da pagina 10. Anche in questo caso, solo le pagine non sono né bloccate né protette senza una precedente autenticazione. Quando si tenta di scrivere sopra la pagina 39 o sotto la pagina 4 questo richiederà un errore o dati vengono ignorati poiché queste pagine non sono la memoria dell'utente.
• "whex 045ACBF44688" scriverà i valori esadecimali direttamente nella memoria, si applicano le condizioni precedenti.
• “protect 30” protegge tutte le pagine da pagina 30 in su. A seconda dell'autorizzazione, queste pagine possono essere modificate o lette solo previa autenticazione con chiave. Usando “proteggi” con valori maggiori di 47 verranno impostate tutte le pagine come “non protette” COMPRESA LA CHIAVE alle pagine 44-47 (che poi può essere solo modificata ma non letta). Per evitare di alterare la chiave, la protezione dovrebbe iniziare almeno a pagina 44.
• “setpbit 0” imposta il bit di protezione e decide se le pagine protette sono di sola lettura (“setpbit 1”) oppure non possono essere né lette né scritte (“setpbit 0”) senza previa autenticazione con chiave.

Non tutti i comandi possono essere utilizzati immediatamente dopo il rilevamento della scheda. Un "dump" precedentemente ad un altro comando aiuta sempre.

Passaggio 3: importante

1. Il programma distingue tra i tipi Ultralight leggendo pagina 43 e 44. Se la pagina 43 è leggibile e la pagina 44 no, molto probabilmente è un Ultralight C. MA, se leggi/scrivi proteggi la pagina 43 la scheda non viene più riconosciuta come Ultralight C (non ha alcun effetto su nulla) La corretta identificazione dell'Ultralight dovrebbe essere effettuata tramite l'autenticazione con chiave (non l'ho implementata per motivi di stabilità).
2. Prima di utilizzare i comandi “setpbit” e “protect” è necessario utilizzare il comando “dump”, altrimenti non si conoscerà lo stato di protezione delle pagine.
3. Se "leggi/scrivi" proteggi le prime pagine della tua carta, non funzionerà più con questo programma poiché la prima pagina viene letta costantemente per vedere se è ancora presente una carta. Poiché le prime due pagine vengono comunque lette solo (l'UID è memorizzato lì), non ha senso proteggerle.

Problemi di stabilità

Questo codice utilizza la libreria RC522 "standard" per Arduino e una libreria 3DES da https://github.com/Octoate/ArduinoDES. Mentre la libreria RC522 è abbastanza comunemente usata, la libreria 3DES non sembra molto diffusa e deve essere installata manualmente.

Il codice è stato testato su un Arduino Uno. Ma mentre lo scrivevo, ho riscontrato molti problemi strani riguardo alla stabilità. In qualche modo o le mie capacità di programmazione non sono così buone, una delle librerie utilizzate è instabile o mischiare le librerie non è una buona idea.

Si prega di tenerlo a mente quando si utilizza il codice!!!

Modificarlo o utilizzarne solo parti può portare a comportamenti strani come arresti anomali, stampa di cose strane o timeout o NAK durante la lettura dalla carta. Questo può accadere in qualsiasi punto del codice (mi è costato molte ore di debug). Se trovi i motivi per questo, per favore dammi un suggerimento.