(Italiano) Raspberry Pi e Smart Card Mifare Classic 1K: Realizzare un sistema di accesso

Sorry, this entry is only available in Italian. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

Le Smart Card fanno parte ormai da tempo del nostro quotidiano: dalla SIM (Subscriber Identity Module) del cellulare, alla carta di credito, come sistema di fidelizzazione, per accedere ai locali e come mezzo per fruire dei servizi della pubblica amministrazione.

Integrare sistemi di autenticazione basati su Smart Card nei propri sistemi e applicazioni, credo che possa essere un’attività molto interessante per chi programma e l’aspetto a mio avviso più coinvolgente è la vicinanza con quelli che amo definire bonariaménte “pezzi di ferro”.

Quasi due anni fa ho scritto l’articolo Raspberry Pi – Un esempio di applicazione della TS-CNS, dove mostravo come poter creare un sistema di accesso utilizzando la propria TS-CNS; in questo articolo vedremo invece come mettere insieme Raspberry Pi, modulo da quattro relè, lettore di Smart Card e MIFARE Classic 1K contactless Smart Card per poi armonizzare il tutto con il software necessario allo scopo di realizzare un sistema di accesso.

Per lo sviluppo del progetto è necessario toccare un numero considerevole di argomenti e cercherò di trattare i principali con il giusto livello di profondità, in caso contrario l’articolo assumerebbe delle dimensioni notevoli. Mi impegnerò a lasciare tutti i riferimenti utili per ogni vostro approfondimento.

A questo punto direi d’iniziare; mettetevi comodi e munitevi della giusta concentrazione perché la lettura di questo articolo sarà abbastanza impegnativa ma spero interessante.

1. Descrizione dello scenario

Credo d’intuire quale potrebbe essere il vostro pensiero in questo momento. Che tipo di Sistema di Accesso andremo a realizzare?

Vorrei implementare qualcosa che tutti almeno una volta abbiamo usato. Un comunissimo scenario di Sistema di Accesso lo abbiamo vissuto tutti accedendo alla nostra camera di albergo grazie alla Smart Card (o chiave elettronica) consegnata al momento dell’accoglienza. La figura a seguire mostra lo schema hardware della soluzione che andremo a realizzare.

La MIFARE Classic® 1K contactless si basa su NXP MF1 IC S50. Questa tipologia di carta è una buona scelta per applicazioni classiche come la biglietteria dei trasporti pubblici, servizi di fidelizzazione e può essere utilizzata anche per molte altre applicazioni come sistemi di apertura porte e simili.

Il lettore di Smart Card deve essere conforme a standard indicati nello schema di figura 1. Nel mio caso ho utilizzato il lettore CIE Bit4id miniLector collegato al Raspberry Pi tramite la porta USB. Il nome tecnico del lettore che ho utilizzato è: BIT4ID miniLector AIR NFC v3.

Al Raspberry Pi è collegato un modulo di quattro relè gestito tramite le porte GPIO. Nel nostro scenario, i relè rappresentano gli attuatori necessari per aprire le porte dell’hotel dove siamo ospiti.

Appurato che il nostro scenario è quello di un sistema di accesso per consentire agli ospiti di un hotel di accedere alle proprie stanze attraverso una Smart Card, vediamo quali sono i due processi che portano al raggiungimento di questo obiettivo.

La figura 2 illustra il processo semplificato (in notazione BPMN) di ciò che accade quando un ospite viene ricevuto dal personale dell’hotel. Dell’intero processo, solo il Service Task (indicato in rosso) sarà l’oggetto dell’implementazione del software.

Il processo di figura 3 mostra invece cosa succede quando l’ospite chiede di entrare nella sua camera tramite l’uso della chiave elettronica appoggiandola sul lettore. Dell’intero processo, solo i Service Task (indicati in rosso) saranno oggetto dell’implementazione del software.

Credo che tutti i processi illustrati (in figura 2 e figura 3) in notazione BPMN siano abbastanza esplicativi da non richiedere ulteriori approfondimenti. I Service Task sono gli elementi che saranno oggetto di nostro interesse per l’implementazione del software che fin da questo momento possiamo dividere in due macro componenti le cui responsabilità devono essere:

1. il setup della Smart Card (o chiave elettronica) in fase di registrazione dell’ospite presso la struttura alberghiera. All’interno della Smart Card sarà memorizzato l’identificativo di un documento di riconoscimento dell’ospite, sul database del sistema di gestione dell’albergo saranno invece memorizzati i dati anagrafici insieme ad altri dati necessari per associare la chiave elettronica all’ospite e alla stanza a lui assegnata;
2. la verifica che la chiave elettronica sia abilitata e associata all’ospite e alla stanza a cui consentire l’accesso.

 

2. Qualche dettaglio sulla MIFARE Classic 1K

MIFARE è un marchio registrato di NXP Semiconductors. I prodotti MIFARE sono circuiti integrati ampiamente utilizzati per l’utilizzo in Smart Card senza contatto e molte altre applicazioni in tutto il mondo. La gamma MIFARE comprende circuiti integrati per la realizzazione di tessere contactless e lettori per la comunicazione con esse.

Il nome MIFARE racchiude diversi tipi di Smart Card senza contatto, quella utilizzata in questo scenario rientra nel tipo Classic. Si tratta di schede di memoria a logica cablata che solo parzialmente sono conformi allo standard ISO/IEC 14443A (caratteristiche fisiche, potenza e interfaccia del segnale radio, inizializzazione e anticollisione), poiché utilizzano un set di comandi proprietari invece del protocollo ISO/IEC 14443-4 di alto livello e non sono conformi al formato frame ISO/IEC 14443-3 e nelle comunicazioni crittografate usano un protocollo di sicurezza proprietario NXP (CRYPTO1) per l’autenticazione e la crittografia che è stato rotto nel 2008.

Dopo l’ultima frase immagino che vi stiate domandando: perché scrivere allora un articolo su questa Smart Card? La risposta è abbastanza semplice. Questa è una delle Smart Card a sola memoria più diffuse e semplici da usare, e per il tipo di scenario qui presentato, la possibilità di scoprire “facilmente” la chiave di autenticazione è secondario, inoltre, questo è articolo prettamente didattico.

La MIFARE Classic 1K dispone di 1024 byte di memoria (EEPROM) suddivisa in 16 segmenti; ogni settore è protetto da due chiavi che vengono chiamate A e B. In tutti i tipi di carta, 16 byte a settore sono riservati alle chiavi e alle condizioni d’accesso e non possono essere utilizzati per i dati dell’utente; inoltre, i primi 16 byte contengono il numero di serie univoco e di sola lettura. In questo modo la memoria disponibile si riduce a 752 byte.

Data l’altissima diffusione di questa tipologia di Smart Card e le versioni “cinesi” esistenti, dubito che non ci siano numeri di serie duplicati, visto anche che i byte dedicati alla memorizzazione del numero di serie sono quattro.

 

Prima di poter compiere operazioni di lettura o scrittura sui blocchi di memoria, è necessario eseguire prima un’autenticazione tramite la chiave del settore del blocco. In genere tutte le chiavi (A e B) sono impostate su valore FFFFFFFFFFFFh in fase di produzione del chip (e in ogni caso la documentazione fornita al momento dell’acquisto fornisce indicazioni sulle chiavi di accesso e su come eseguire la modifica).

La tabella mostrata in figura 5 rappresenta la mappa della memoria con in evidenza il range degli indirizzi per i Data Blocks e i Trailer Block per ogni settore. Questa mappa sarà utile nel momento in cui dovremo leggere e scrivere sui data blocks.

Dopo questa sorvolata sulle caratteristiche principali della MIFARE Classic 1K che sono di nostro interesse per il nostro obiettivo, possiamo andare avanti ed esplorare il modo su come comunicare con la carta per le operazioni di autenticazione, lettura e scrittura.

 

3. I misteriosi pacchetti APDU

La comunicazione delle informazioni tra la carta e il lettore è resa possibile grazie allo scambio di pacchetti detti APDU (Application Protocol Data Unit); essi rappresentano l’unità di comunicazione tra il lettore e la carta e la loro struttura è ben definita da ISO/IEC 7816-4 Organization, security and commands for interchange.

Esistono due tipi di APDU: quelli di comando e quelli di risposta. I primi richiedono un set di attributi attraverso cui il lettore è in grado di sapere quali operazioni compiere e quali dati inviare, i secondi contengono il risultato dell’operazione richiesta con in coda l’esito dell’operazione.

La tabella di figura 6 mostra la struttura dei comandi APDU che attraverso il lettore di Smart Card possiamo inviare alla carta MIFARE.

 

 

La tabella di figura 7 mostra un esempio di comando APDU per ottenere l’UID della MIFARE Classic 1K, la cui lunghezza è pari a 4 byte (vedi attributo Le). A fronte dei comandi inviati, riceviamo sempre una risposta che ha la struttura indicata dalla tabella di figura 8.

 

 

La tabella di figura 9 mostra la risposta ottenuta a fronte del comando APDU per richiedere l’UID (vedi figura 7) la cui lunghezza dell’UID è pari a 4 byte più 2 byte che segnalano l’esito del comando. L’UID è restituito con il byte meno significativo (LSB) a sinistra e quello più significativo (MSB) a destra (quindi usa il sistema little-endian).

 

Confrontando i valori di SW1 e SW2 (Status Word) con quelli riportati dalla tabella mostrata in figura 10 è possibile evincere se l’esecuzione del comando è andato a buon fine.

Attenzione. I valori di SW1 e SW2 fanno riferimento al comando per ottenere l’UID della carta; questi valori potrebbero essere diversi per altre classi di comando, in particolare nei casi di errore.

Per maggiori dettagli sui comandi ed eventuali estensioni, consiglio sempre di consultare il datasheet della MIFARE Classic 1K. I comandi APDU di nostro interesse per implementare lo scenario descritto nella parte introduttiva dell’articolo, sono:

• comando per ottenere l’UID della carta;
• comando per leggere i dati da un determinato settore e blocco;
• comando per scrivere dati su un determinato settore e blocco della carta.

 

4. Cos’è l’Answer to reset o ATR

La prima risposta di una Smart Card inserita in un lettore si chiama ATR (Answer to reset). Lo scopo dell’ATR è descrivere i parametri di comunicazione supportati, la natura e lo stato della carta. L’ottenimento di un ATR viene spesso utilizzato come prima indicazione che questa sia operativa, e il suo contenuto viene esaminato come prima prova che sia del tipo appropriato per un determinato utilizzo. Il lettore di Smart Card, il driver del lettore e il sistema operativo utilizzeranno questi parametri per stabilire una comunicazione con la scheda.

L’ATR è descritto dallo standard ISO/IEC 7816-3. I primi byte dell’ATR descrivono i parametri elettrici, seguiti da byte che descrivono le interfacce di comunicazione disponibili e i rispettivi parametri. Questi byte di interfaccia sono quindi seguiti da byte storici che non sono standardizzati e sono utili per trasmettere informazioni proprietarie come il tipo di scheda, la versione del software integrato o lo stato della scheda. Infine questi byte storici sono eventualmente seguiti da un byte di checksum.

Potremmo riassumere che l’ATR contiene “un sacco di dati” che ci dicono vita morte e miracoli della Smart Card. Per esempio, scopriamo di più sull’ATR 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 01 00 00 00 00 6A  utilizzando il tool Smart card ATR parsing sviluppato da Ludovic Rousseau. La figura a seguire mostra le informazioni estratte alcune delle quali:

• tipo di Smart Card e in questo caso si tratta della MIFARE Classic 1K;
• produttore della Smart Card e in questo caso NXP;
• standard tecnologici;
• protocolli di comunicazione e in questo caso T=0 (orientato al byte, che costituisce l’unità minima di informazione scambiata) e T=1 (orientato al blocco di byte, grazie al quale la velocità di accesso è maggiore), protocollo solitamente utilizzato di default quando disponibile e supportato anche dal lettore.

 

 

Ludovic Rousseau ha fatto un ottimo lavoro tracciando dal 2002 un gran numero di ATR costruendo un vero e proprio database. Così facendo è possibile identificare una Smart Card dato il suo ATR. All’interno della lista sono presenti anche le “nostrane Smart Card” come la TS-CNS (Tessera Sanitaria – Carta Nazionale Servizi) e CIE (Carta d’Identità Elettronica). È possibile utilizzare il comando pcsc_scan per ottenere informazioni di dettaglio sulla Smart Card, le stesse illustrate in figura 11. La figura 12 mostra l’output del comando menzionato da cui è possibile dedurre che la Smart Card analizzata è una CIE.

 

 

5. Requisiti Hardware

Realizzare lo scenario descritto richiede il recupero di una serie di “pezzi di ferro”.

1. Raspberry Pi 4 Model B 8GByte RAM
2. MicroSD Card (min 8GByte)
3. Elegoo 4 Channel DC 5V Modulo Relay
4. Jumper Wire Cable Cavo F2F female to female
5. Bit4id miniLector CIE
6. Mifare Classic 1K
7. Mifare Classic 1K RFID Tag (opzionale)

Per quanto riguarda il Raspberry Pi è possibile optare per la versione con 4GByte di RAM ma è importante installare come sistema operativo l’ultima versione di Raspberry Pi OS affinché sia supportato il lettore di Smart Card Bit4id miniLector CIE e questo grazie alla versione 1.4.34-1 della libreria libccid (check via apt info libccid).

 

Nel caso in cui abbiate già un lettore di Smart Card o vogliate acquistarne un diverso modello, consiglio di consultare la lista dei lettori di Smart Card supportati dal driver libccid.

 

6. Requisiti Software

Così come abbiamo bisogno dell’hardware, è necessario che siano soddisfatti una serie di requisiti software, quali:

1. Raspberry Pi OS (64bit)
2. Python 3.9.x (distribuito e installato di default con Raspberry Pi OS)
3. Docker 20.10.12
4. Development Tools (make, gcc) (install or update via sudo apt install build-essential)

Per questo genere di scenari non è assolutamente necessario provvedere all’installazione del sistema operativo in versione Desktop, consiglio pertanto di preparare e usare l’immagine di Raspberry Pi OS Lite (64bit). Per coloro che avessero bisogno di una guida su come installare questo sistema operativo, consiglio di seguire la guida ufficiale Installing the Operating System.

L’installazione di Docker potrebbe essere anche opzionale; personalmente preferisco installare il database in forma di container. Più in avanti vedremo quale database ho scelto per questa soluzione.

Per approfondimenti sul tema Docker, consiglio la lettura del libro Docker: Sviluppare e rilasciare software tramite container di Serena Sensini e la visione delle Pillole di Docker sul canale YouTube di Mauro Cicolella.

 

7. Schema elettrico della soluzione

Una volta ottenuto l’hardware (indicato in precedenza), possiamo procedere con il collegamento del modulo dei quattro relè all’interfaccia GPIO con l’ausilio dei jumper femmina-femmina.

La figura 14 mostra lo schema elettrico di collegamento tra il modulo a quattro relè e il Raspberry Pi. Ricordo che il lettore di Smart Card è collegato via USB al Raspberry Pi. Utilizzando i jumper e seguendo lo schema, il risultato sarà assicurato. È preferibile eseguire l’operazione di collegamento lasciando il proprio Raspberry Pi spento e scollegato dalla fonte di alimentazione.

 

 

Per ogni dubbio sulla disposizione dei pin del connettore J8 del Raspberry, consultare l’output del comando pinout (vedi figura 15) prima di procedere con l’operazione di collegamento, oppure, puntate il vostro browser su pinout.xyz.

 

8. Progettare il software

È arrivato il momento di saltare dall’hardware al software cercando di delineare ciò che dovremo implementare con l’obiettivo di soddisfare i requisiti espressi in forma di diagrammi BPMN (vedi figura 2 e figura 3). Ricordo che solo quanto espresso dai Service Task deve essere realizzato in forma di software.

Cerchiamo di identificare il cosa dovrà essere soddisfatto dal punto di vista funzionale per poi passare al come gli aspetti funzionali dovranno essere implementati. La tabella mostrata in figura 16 (trasposizione di una classica Mind Map), descrive gli aspetti funzionali che il software che andremo a realizzare deve implementare.

Il software deve prevedere due entry point, ed esattamente quelli indicati all’interno della tabella di figura 16, le cui responsabilità devo essere:

• Setup Smart Card: entry point la cui principale responsabilità è quella di “formattare” la Smart Card (o chiave elettronica) con i dati personali dell’ospite e in questo caso il numero del documento d’identità, inoltre, creare l’associazione tra chiave elettronica, ospite e stanza a lui assegnata. Una volta eseguiti i task di questo entry point (vedi figura 16), la Smart Card potrà essere consegnata all’ospite.
• Gestione Accesso Porte entry point la cui principale responsabilità è quella di garantire l’accesso (apertura della porta della stanza) solo a coloro che hanno in possesso una Smart Card valida, aggiornando i dati di accesso sul database. La Mind Map di figura 16 mostra i singoli task che devono essere eseguiti da questo specifico entry point.

 

Più volte è stato fatto riferimento all’esistenza di un database, bene, adesso cerchiamo di capire quali sono i dati da esso trattati e le responsabilità dei due entry point in merito al trattamento di questi dati. La tabella di figura 17 mostra la struttura dati del documento che descrive l’associazione ospite, Smart Card e stanza assegnata e traccia i dati degli eventi d’inizializzazione e accesso.

La tabella mostra un’informazione importante per ogni attributo del documento, ovvero, lo scope, quindi l’entry point, con evidenza del diritto di accesso: (r -read) lettura o (w – write) scrittura.

9. Implementare il software

Adesso che il cosa è chiaro, vediamo il come, rispondendo alle domande a seguire:

1. Quale linguaggio usare per implementare lo scenario che abbiamo descritto all’inizio dell’articolo? Python
2. Esiste qualche libreria Python per la costruzione di applicazioni basate su Smart Card? Pyscard
3. Quale tipo di database usare per la memorizzazione dei dati? MongoDB (NoSQL database)
4. Esiste qualche libreria Python per operare con MongoDB? PyMongo
5. Esiste qualche libreria Python per interagire con l’interfaccia GPIO del Raspberry Pi? RPi.GPIO

Da questa lista le cose da fare sono parecchie e lo spazio per vederle tutte nel dettaglio in questo articolo non c’è. Direi quindi di focalizzare la nostra attenzione sui componenti da realizzare rimanendo ad alto livello, senza scendere nello specifico del codice.

Non vi allarmate! Il progetto è già stato sviluppato prima di scrivere questo articolo e disponibile sul mio repository GitHub Smart Card Contactless Raspberry Pi.

Nota su MongoDB. È necessario preparare un’instanza di MongoDB sul proprio Raspberry Pi affinche la soluzione funzioni nel modo corretto. Le scelte sono due: container docker o installazione classica direttamente sul sistema operativo. Personalmente ho scelto la strada di Docker (vedi 6. Requisiti Software), per cui, una volta installato Docker sul proprio Raspberry Pi OS, i passi per tirare su un’istanza MongoDB 4.4.12 sono quelli indicati a seguire.

 

# 1. Docker pull e run MongoDB 4.4.12
$ docker pull mongo:4.4.12
$ docker run -d -p 27017-27019:27017-27019 --name mongodb mongo:4.4.12

# 2. Verifica che l'istanza sia su e accesso alla console bash (task opzionale)
$ docker exec -it mongodb bash

# 3. Avvio della console MongoDB (task opzionale)
root@0d21da235b0d:/# mongo

Nel caso in cui preferiate perseguire la seconda strada, il blog di MongoDB riporta la procedura completa sull’articolo Install & Configure MongoDB on the Raspberry Pi.

 

9.1 Cos’è Pyscard

Pyscard, Python Smart Card library, è un modulo Python che aggiunge il supporto per le Smart Card facilitando la costruzione di applicazioni che hanno la necessità di utilizzare la tecnologia delle Smart Card.

Pyscard supporta la piattaforma Microsoft Windows utilizzando i componenti Microsoft Smart Card Base, Linux e macOS utilizzando PCSC-lite. Il diagramma di figura 18 mostra l’architettura Pyscard (box in verde). Il modulo smartcard.scard è il wrapper di WinSCard API (smart card base components). Il modulo smartcard è un vero e proprio framework costruito su PC/SC API.

Pyscard sarà di aiuto per:

1. Eseguire la connessione al lettore di Smart Card e alla MIFARE Classic 1K
2. Filtrare le connessioni alle sole MIFARE Classic 1K tramite l’ATR
3. Inviare i comandi APDU
4. Ricevere le risposte ai comandi APDU
5. Intercettare gli eventi di aggiunta e rimozione Smart Card dal lettore

9.2 Struttura del progetto software

Adesso che abbiamo visto dalla superficie cos’è Pyscard e per cosa sarà utile, cerchiamo di disegnare la struttura del nostro progetto che implementerà lo scenario introdotto a inizio articolo.

Il diagramma (in notazione UML) di figura 19 mostra package, component e classi utilizzati per l’implementazione dello scenario che abbiamo descritto a inizio articolo. Gli elementi del diagramma del nostro progetto sono quelli evidenziati con il colore giallo ocra e in particolare:

• Classi
  • ManageRelay (manage_relay.py). Classe che gestisce attraverso l’interfaccia GPIO l’attivazione e disattivazione dei quattro relè, nonché l’inizializzazione della stessa interfaccia GPIO.
  • SmartCardAccessCrud (smart_card_access_crud.py). Classe che gestisce le operazioni CRUD sul database NoSQL MongoDB.
  • MifareClassicInterface (mifare_interface.py). Classe che gestisce la comunicazione con il lettore di Smart Card e di conseguenza d’interagire con la Smart Card connessa. Le operazioni gestite sono: autenticazione, lettura ATR, lettura UID, lettura dalla memoria della carta e scrittura sulla memoria della carta.
• Component
  • Setup Smart Card (setup_smart_card.py). Script Python che rapprensentata l’entry point responsabile del setup della Smart Card e memorizzazione dei dati anagrafici dell’ospite sul database MongoDB. Questo script deve ricevere in input i parametri necessari per eseguire il setup della Smart Card.
  • Access via Smart Card (access_via_smart_card.py). Script Python che rappresenta l’entry point responsabile di governare l’apertura delle porte (attraverso l’attivazione dei relè) sulla base della validazione dei dati estratti dalla Smart Card. Questo script deve ricevere in input la chiave di autenticazione della Smart Card.

 

 

Il package smartcard (in verde) fa parte di Pyscard, e i componenti all’interno sono utilizzati per sfruttare il monitoraggio delle Smart Card. Utilizzando l’interfaccia CardObserver siamo in grado di poter sapere quando la Smart Card viene aggiunta (appoggiata sul lettore) o rimossa (dal raggio di azione del segnale RF).

Il sequence diagram di figura 20 descrive lo scenario del setup della Smart Card (vedi Figura 2 – Processo semplificato di accoglienza dell’ospite in hotel), mostrando le azioni principali e gli eventuali flussi alternativi. Sempre da questo diagramma possiamo vedere le relazioni che intercorrono, in termini di messaggi, tra i vari attori, quest’ultimi sono stati descritti in precedenza e mostrati nel diagramma di figura 19.

Le azioni decisamente più importanti sono quelle che riguardano l’invio dei comandi APDU, che riassumendo sono:

1. Load Authentication Key sulla memoria volatile
2. Autenticazione per accedere al primo blocco del settore uno della MIFARE Classic 1K
3. Richiesta UID
4. Lettura dell’eventuale precedente documentId (numero identificativo del documento di riconoscimento)
5. Salvataggio del documentId

I link della precedente lista riportano direttamente sul metodo specifico della classe Mifare Classic Interface all’interno del quale è specificato il contenuto dell’APDU inviata.

 

Nella fase di setup della Smart Card, prima di inserire i dati anagrafici dell’ospite sul database, viene eseguita la query utilizzando il filtro {"smartCardId": f"{uid}", "documentId": f"{identification_number}"} , in modo che sia possibile verificare che non esista già un documento con l’associazione smartCardId e documentId (fare riferimento allo step 33 del sequence diagram di figura 20).

Il sequence diagram di figura 21 descrive lo scenario di Accesso alla stanza tramite Smart Card (vedi Figura 3 – Processo di accesso alla stanza), mostrando le azioni principali e gli eventuali flussi alternativi. Sempre da questo diagramma possiamo vedere le relazioni che intercorrono, in termini di messaggi, tra i vari attori, quest’ultimi sono stati descritti in precedenza e mostrati nel diagramma di figura 19.

In questo diagramma, tra gli attori in gioco abbiamo anche il componente Card Monitor di Pyscard, che abbiamo utilizzato per aggiungere la nostra interfaccia Mifare Classic Interface come observable, in questo modo il Card Monitor richiamerà il metodo update(self, observable, actions) nel momento in cui si verificheranno gli eventi di aggiunta o rimozione della Smart Card. Il metodo update implementa quando descritto in Figura 16 – Mind Map sugli aspetti funzionali che il software dovrà implementare, di cui le azioni sono evidenti sul sequence diagram a seguire.

 

I dati sono estratti dal database MongoDB utilizzando il filtro {"smartCardId": f"{uid}", "documentId":f{identification_number}", "smartCardEnabled": "true"}, nel caso non ci siano documenti che rispettino questo filtro, il sistema negerà l’accesso, alternativamente, sarà aggiornato il documento su MongDB e attivato il relè corrispondente al numero della stanza associato all’ospite (fare riferimento allo step 1.7 del sequence diagram di figura 21).

Molto bene! Una volta descritti i sequence diagram dei nostri due scenari, direi che potremmo passare all’azione, ovvero, eseguire il deploy dell’applicazione sul Raspberry Pi 4.

 

10. Deploy e test del software sul Raspberry Pi

Ci siamo! È arrivato il momento d’installare il progetto software sul Raspberry Pi e verificare che tutto funzioni così per com’è stato ideato. Il deployment diagram della figura a seguire mostra tutti i componenti del nostro sistema di accesso.

 

Assumiamo a questo punto che tutti i requisiti software indicati in precedenza siano tutti soddisfatti (fare riferimento a 6. Requisiti Software). Per installare il progetto software sul Raspberry Pi occorre seguire i seguenti passi:

1. accedere in ssh alla Raspberry Pi;
2. decidere una locazione dove installare il progetto software. Non ci sono restrizioni; nel mio caso ho preferito usare la home del mio account;
3. eseguire il clone del repository del progetto;
4. eseguire l’installazione delle dipendenze Python.

Per ambienti di sviluppo o test è possibile pensare di fare ricorso alla creazione di quella che viene definita nel mondo Python, Virtual Environments.

 

# Accesso al Raspberry Pi via SSH
$ ssh amusarra@192.168.238.169

# Clone del repository GitHub del progetto
$ git clone https://github.com/amusarra/smartcard-contactless-raspberry-pi.git

# Installazione delle dipendenze Python
$ cd smartcard-contactless-raspberry-pi
$ make

Il comando make non fa altro che procedere con l’installazione delle dipendenze Python specificate sul file requirements.txt utilizzando pip. La figura 23 mostra il processo d’installazione delle dipendenze Python sul Raspberry Pi. Ultimata l’installazione, è possibile eseguire il test vero e proprio del software. Prima di eseguire il test occorre accertarsi che dal punto di vista hardware sia tutto regolare controllando tutti i collegamenti (vedi schema elettrico), compreso il collegamento del lettore di Smart Card via USB.

Ormai dovremmo sapere quali sono gli entry point da utilizzare, sia quello per il setup della Smart Card, sia quello che avvia il controllo degli accessi. Entrambi gli entry point, quindi gli script Python, devono essere avviati specificando una serie di parametri. Le due tabelle a seguire mostrano i parametri d’input dei due script: setup_smart_card.py e access_via_smart_card.py.

 

La figura 26 mostra un esempio di come si presenta l’help in linea dello script setup_smart_card.py attivato utilizzando l’opzione --help (o -h).

A questo punto siamo davvero pronti. Il primo step è la registrazione della Smart Card per il nuovo ospite Mario Rossi il cui documento d’identità ha il numero MU589876XD e al quale assegnamo la stanza numero due.

Prima di avviare la registrazione, prendiamo la Smart Card poggiandola sul lettore. Il comando da avviare per la registrazione è: ./setup_smart_card.py -a FFFFFFFFFFFF -i MU589876XD -s --firstname Mario --lastname Rossi -r 2

Se tutto va per il verso giusto, l’output ottenuto in console dovrebbe essere quello mostrato dalla figura a seguire.

Dopo la registrazione della Smart Card e la consegna all’ospite, quest’ultimo può usare la Smart Card per accedere alla propria stanza assegnata in fase di registrazione, che ricordo essere la numero due.

 

 

Avviamo adesso il programma del controllo degli accessi utilizzando il comando: ./access_via_smart_card.py -a FFFFFFFFFFFF. Avviato il programma, questo resta in attesa di leggere la Smart Card. Poggiando la Smart Card registrata poc’anzi, l’ospite dovrebbe riuscire ad accedere alla sua stanza, così come mostra la figura a seguire.

L’output mostrato dalla figura 29 evidenzia anche un accesso non riuscito perché in questo caso la Smart Card presentata non è registrata sul sistema. Gli screencast a seguire mostrano i due entry point in azione: setup_smart_card.py e access_via_smart_card.py.

 

Dopo i due screencast che mostrano il sistema di accesso in azione, possiamo affermare che il nostro lavoro di analisi, progettazione e implementazione sia arrivato al termine, raggiungendo anche l’obiettivo prefissato.

11. Conclusioni

Ringrazio tutti voi per essere arrivati “incolumi” alla fine di questo lungo percorso sperando di non essere stato noioso e di essere riuscito nell’intento di rendere interessanti gli argomenti trattati oltre che a spingere la vostra curiosità in avanti.

Potrei lasciarvi un compito per casa: come aprire la porta di casa utilizzando la propria CIE o TS-CNS.

Mi sarebbe piaciuto approfondire maggiormente alcuni degli argomenti trattati, come per esempio il framework Pyscard e alcune sezioni del codice Python sviluppato. Nell’attesa di pubblicare altri articoli di approfondimento, vi chiedo di scrivere le vostre impressioni, esperienze o altro di cui vorreste qualche approfondimento utilizzando i commenti all’articolo oppure condividendo attraverso i classici canali social.

Sempre nell’ottica Open Source, il progetto Smart Card Contactless Raspberry Pi pubblicato sul mio repository GitHub, contiene all’interno della directory docs i seguenti elementi:

• il file diagrams.drawio contenente diagrammi e tabelle. File che potete aprire con Draw.io
• il file SCH_Smart_Card_Contactless_Raspberry_Pi_2022-03-11.json dello schema elettrico che potete aprire con EasyEDA
• i file UML *.puml di PlantUML che contengono i sequence diagram

 

12. Risorse

Come di consueto lascio una serie di risorse che ritengo utili ai fini dell’approfondimento degli argomenti trattati nel corso di questo articolo.

• Attuatori per maker – https://amzn.to/3slHmE9
• Raspberry Pi. La guida completa – https://amzn.to/2RpYZWh
• Docker: Sviluppare e rilasciare software tramite container – https://amzn.to/3tiyO1W  di Serena Sensini
• Valutiamo se continuare a usare Docker o passare a Podman – https://www.theredcode.it/podman/what-is-podman/
• Pillole di Docker – https://www.youtube.com/watch?v=wAyUdtQF05w di Mauro Cicolella
• Raspberry PI GPIO – Tutti i segreti del pinout – https://www.moreware.org/wp/blog/2021/04/09/raspberry-pi-gpio-tutti-i-segreti-del-pinout/
• Smart cards – A short illustrated guide ( Feb. 2022) – https://www.thalesgroup.com/en/markets/digital-identity-and-security/technology/smart-cards-basics
• Hacking Mifare Classic Cards – https://www.blackhat.com/docs/sp-14/materials/arsenal/sp-14-Almeida-Hacking-MIFARE-Classic-Cards-Slides.pdf
• How to Crack Mifare Classic Cards – https://firefart.at/post/how-to-crack-mifare-classic-cards/
• A Practical Attack on the MIFARE Classic – https://arxiv.org/pdf/0803.2285.pdf
•  ACR122U Application Programming Interface – https://www.acs.com.hk/download-manual/419/API-ACR122U-2.04.pdf