Interfacciare una smartcard con micro PIC

Sempre più applicazioni adottano smart card per l’identificazione utente e la memorizzazione di dati sensibili. Le applicazioni principali vanno dalla sicurezza personale alle operazioni di banking, dall’healtcare ai trasporti, fino alle comunicazioni.L'articolo esamina l'architettura di riferimento e API software per la gestione di smart card con micro PIC.

I vantaggi principali rispetto alle tradizionali carte magnetiche sono: maggiore sicurezza, più ampia capacità di memorizzazione dati, vita utile più lunga, supporto per multi-funzioni. Le smart-card, infatti, integrano al loro interno un microcontrollore che gestisce la comunicazione con l’host e la memorizzazione delle informazioni sul supporto non volatile (tipicamente EPROM). Le specifiche per la smart-card a contatto sono standardizzate dalla normativa ISO 7816, che definisce le caratteristiche fisiche della carta (ISO 7816-1), dimensioni e locazione dei contatti sul chip (ISO 78162), i livelli di segnale ed il protocollo di comunicazione (ISO 7816-3), l’organizzazione, la  gestione della sicurezza e l’insieme di comandi (ISO 7816-4).

Per quanto riguarda il protocollo di comunicazione, in particolare, a dispetto dei notevoli vantaggi che la tecnologia assicura, esso è piuttosto semplice, tanto da permettere di gestire le carte anche con economici microcontrollori a 8 bit. Di seguito, ad esempio, è descritto come interfacciare una smart-card (figura 1) mediante un PIC. Prima di questo, però, è opportuno vedere brevemente le caratteristiche principali di questo tipo di carte ‘intelligenti’. Discussioni più approfondite si possono facilmente trovare in rete, come ad esempio al link indicato nei riferimenti [1].

Figura 1: sempre più applicazioni usano smart card.

Figura 1: sempre più applicazioni usano smart card.

CARATTERISTICHE GENERALI DELLE SMART CARD

Come noto più o meno a tutti, una smart card consiste di una scheda di formato tascabile dotata di chip di memorizzazione e comunicazione integrato. Le carte per l’identificazione personale adottano, ad esempio, il formato ID-1 definito dalla specifica ISO-7810, che prevede dimensioni di 85,60 × 53,98 mm2 ed uno spessore di 0,76 mm. Il chip elettronico integrato occupa, invece, un’area di 19,23 x 10,22 mm2. Presenta 8 contatti elettrici sagomanti come mostrato in figura 2 e corrispondenti alle seguenti linee :

  • Vcc : tensione di alimentazione;
  • Vpp : tensione di programmazione;
  • Gnd : massa;
  • Rst : segnale di reset;
  • Clk : clock di ingresso;
  • SIO : linea dati bi-direzionale half-duplex;
  • RFU : riserve for future use;

In funzione della tensione di alimentazione richiesta e della massima potenza dissipata, le smart card si dividono quindi in dispositivi di Classe A, B e C. I dispositivi di classe A sono alimentati con tensione d’ingresso compresa tra 4,5V e 5,5V e richiedono corrente inferiore a 60 mA; i dispositivi di classe B sono invece specificati per Vcc compresa tra 2,7V e 3,3V e corrente inferiore a 50 mA. Le carte di classe C, infine, assorbono meno di 30 mA con tensione di alimentazione compresa tra 1,62V e 1,98V.

Figura 2: layout dei contatti elettrici di una smart card.

Figura 2: layout dei contatti elettrici di una smart card.

IL LIVELLO DI CARATTERE DEL PROTOCOLLO DI COMUNICAZIONE

Il protocollo di comunicazione (figura 3) si basa sullo scambio di caratteri su linea asincrona half-duplex. Non è previsto arbitraggio di accesso alla linea; piuttosto il protocollo stesso definisce quale dei nodi connessi sia correntemente abilitato a trasferire. È però previsto un controllo di errore. Come mostrato in figura 3, ogni carattere consiste di un byte inviato serialmente sulla linea dati, preceduto da un bit di start per la sincronizzazione e seguito da un bit di parità per la verifica della corretta trasmissione. La durata di un bit, cioè il tempo per il quale il livello corrispondente viene pilotato sulla linea dati, è indicata come ETU (Elementary Time Unit). Al bit di parità segue infine il bit di stop. Nel corrispondente periodo di bit, il trasmettitore (sia esso l’host o la smart card) rilascia la linea mentre il ricevitore forza questo a zero (per 1 o 2 ETU) qualora abbia riscontrato errori nella comunicazione. In questo caso, il trasmettitore, informato del problema, a distanza di almeno 2 ETU, può inviare nuovamente il carattere.

Figura 3: il livello di carattere del protocollo di comunicazione delle smart card.

Figura 3: il livello di carattere del protocollo di comunicazione delle smart card.

LA PROCEDURA OPERATIVA PER LA GESTIONE DELLE SMART CARD

La figura 4 mostra il diagramma di flusso della sequenza operativa per la corretta gestione di una smart card. Dopo aver riconosciuto l’inserzione della carta, l’host (o card reader) deve iniziare la procedura di Cold Reset a cui seguono le sequenze ATR (Answer To Reset) e, per le card che la supportino, PPS (Protocol and Parameter Selection).

Figura 4: Smart Card Management Flowchart. Diagramma di flusso per la gestione di una smart card.

Figura 4: Smart Card Management Flowchart. Diagramma di flusso per la gestione di una smart card.

Dopo di queste, l’host può correttamente accedere alla carta inviando comandi. La procedura di Cold Reset, in particolare, prevede che la linea di reset sia asserita, mentre è applicata alla carta la tensione di alimentazione; la linea deve restare quindi asserita per almeno 400 cicli di clock dopo che la tensione si è stabilizzata. La procedura di Answer To Reset (ATR), invece, consiste nell’invio dalla carta all’host di fino a 33 caratteri che ne consentono la corretta identificazione. Tra questi sono inclusi i caratteri:

  • Initial Character (TS), necessario per la sincronizzazione e la selezione delle modalità della comunicazione seriale (MSB first o LSB first e logica attiva o negata);
  • Format Character (T0), che definisce quali Interface Character e quanti Historical Character seguono;
  • Interface Character, per la definizione di tutta una serie di parametri tra i quali, in particolare, la durata dell’ETU durante la normale comunicazione, il tempo di guardia tra due caratteri consecutivi, la selezione della modalità di comunicazione a blocchi o a caratteri singoli;
  • Historical Character, per la definizione delle caratteristiche operative della smart card (produttore, tipo di chip presente a bordo, stato );
  • Check Character, per scopi di con-

Per i dettagli relativi al formato dei diversi caratteri si rimanda all’Application Note di Microchip indicata nei riferimenti al punto [2] ed, ovviamente, alla specifica ISO.

COMUNICAZIONE A BYTE ED A BLOCCHI

Durante il normale funzionamento le smart card prevedono due diverse modalità di comunicazione, di tipo byteoriented o block-oriented. In modalità byte-oriented, ad esempio, carta e host comunicano mediante APDU (Application Protocol Data Unit) che consistono di comando (C-APDU) e relativa risposta (R-APDU). La figura 5 mostra schematicamente la comunicazione che ha inizio con l’invio da parte dell’host di un comando. Questo consiste di un header che comprende i seguenti byte:

  • CLA : Instruction Class;
  • INS : Instruction Code;
  • P1 : Instruction Code Qualifier;
  • P2 : INS Code Qualifier addizionale;
  • P3 : numero di byte del campo data.

Al comando la smart card risponde mediante invio di un byte di procedura. Segue quindi la fase dati, dall’host alla carta o viceversa, a seconda del tipo di accesso; il numero di byte spediti dipende dal comando ed è specificato, come visto in precedenza, nel campo P3 dell’header di questo. Infine, la smart card invia due byte di stato (SW1 ed SW2) per indicare la corretta esecuzione del comando o l’eventuale riconoscimento di errori nel protocollo (INS in valido, riferimento incorretto, lunghezza errata). Per i dettagli del protocollo block-oriented si rimanda all’Application Note di Microchip indicata nei riferimenti al punto [2] ed, ovviamente, alla specifica ISO.

Figura 5: comunicazione tra smart card e host in modalità byte-oriented (T=0).

Figura 5: comunicazione tra smart card e host in modalità byte-oriented (T=0).

IMPLEMENTAZIONE SU PIC

La semplicità del protocollo per smart card, da un lato, e la flessibilità dell’architettura dei micro PIC (figura 6) dall’altro, consentono di interfacciare piuttosto facilmente questi due tipi di dispositivi.

Figura 6: l’architettura dei micro PIC.

Figura 6: l’architettura dei micro PIC.

Dal punto di vista hardware, le relative connessioni sono mostrate in figura 7.

Figura 7: come connettere un micro PIC ad una smart card.

Figura 7: come connettere un micro PIC ad una smart card.

L’alimentazione, ad esempio, è derivata direttamente da uno dei pin di I/O; un condensatore di bypass riduce il rumore su di essa. La tensione sulla porta di uscita è tipicamente Vdd – 0,7V, dove Vdd è la tensione di alimentazione del micro. Prima di connettere la smart card, assicurarsi quindi che sia compatibile con queste specifiche. Per quanto concerne la corrente assorbita dalla carta, invece, si consideri che le porte dei micro PIC hanno una capacità di pilotaggio in corrente massima di 25 mA. Qualora questa non sia sufficiente, è comunque sempre possibile adottare un amplificatore esterno. I segnali di reset e di card detect possono essere ugualmente gestiti mediante porte di I/O. Il segnale di clock, qualora non si disponga di un oscillatore esterno, può invece essere generato mediante controller PWM del micro. La comunicazione dati, infine, può facilmente essere emulata a livello carattere mediante porta seriale. È importante notare che l’unica differenza tra il protocollo di comunicazione con smart card ed il protocollo UART risiede nella gestione del bit di stop e quindi degli errori, come descritto in precedenza. Fortunatamente, nel caso dei micro PIC, le flag di Receiver Ready e Transmitter Empty che segnalano, rispettivamente, l’avvenuta ricezione di un carattere o l’invio di uno di questi sulla porta seriale, sono asserite a metà dell’intervallo del bit di stop. Questo consente al microcontrollore di gestire, entro l’intervallo specificato dalla normativa (0,5 ± 0,2 ETU), il controllo di errore previsto. In trasmissione, ad esempio, deve rilasciare la linea (per consentire al ricevitore di segnalare eventuali errori di parità) e monitorarla (per riconoscere tale eventuale segnalazione). In ricezione, invece, deve forzare la linea bassa qualora abbia riconosciuto un errore di parità. Fortunatamente, dal punto di vista software, tutte queste funzioni, ed anche quelle per la gestione del protocollo byte-oriented o block-oriented a più livelli, sono già rese disponibili da Microchip in una specifica libreria all’interno della distribuzione Microchip Application Libraries scaricabile gratuitamente dal sito web dell’azienda (si veda il link al punto [3] dei riferimenti). Il listato 1 riporta a titolo di esempio un estratto del codice per la ricezione dei dati, mentre il listato 2 mostra la gestione della porta UART per la trasmissione dei caratteri. La tabella 1 elenca, invece, la lista di API incluse nella libreria unitamente ad una loro breve descrizione.

Tabella 1: le API per la gestione di smart card.

Tabella 1: le API per la gestione di smart card.

Lo scheletro di una tipica applicazione di controllo e gestione di smart card mediante microcontrollore PIC ed utilizzando tali API è mostrata infine nel listato 3.

BOOL SCdrv_GetRxData( BYTE* pDat, unsigned long nTrys )
{
//wait for data byte
while( !U1STAbits.URXDA && nTrys— );
if( !U1STAbits.URXDA )
return FALSE;
if( U1STAbits.PERR ) //Parity Error detected
{
SCdrv_TxPin_Direction(0); //pull it low to tell the card that there was error receiving data
U1MODEbits.URXINV = 1; //do not recognize this low state as a valid start bit
//Read the data from UART to clear the error flag
*pDat = U1RXREG;
WaitMicroSec((U1BRG * 116)/371); //for 9600 baud, 116 us. for 250kbps, 5us
SCdrv_TxPin_Direction(1); //release RD10. Card should retransmit now.
U1MODEbits.URXINV = 0;
return SCdrv_GetRxData(pDat, 10000); //Read the data from retransmission
} else
{
//Read the data from UART
*pDat = U1RXREG;
}
return TRUE;
}
Listato 1
void SCdrv_SendTxData( BYTE data )
{
BYTE txRetryCounter = 0;
BOOL noError = TRUE;
U1STAbits.UTXEN = 1;
U1TXREG = data;
while( !U1STAbits.TRMT )
{
Nop();
Nop();
}
U1STAbits.UTXEN = 0;
U1MODEbits.UARTEN = 0; // Disable UART Module
WaitMicroSec( 1 );
if( !SCdrv_GetRxPinData() ) // The Receiver did not like our data.
it is pulling line low
{ // to indicate PE or FR errors
noError = FALSE;
// WaitMicroSec((U1BRG * 170)/371); //wait two etu before repeating
U1MODEbits.UARTEN = 1;
//now retransmit the data
if( txRetryCounter < 5 )
{
txRetryCounter++;
SCdrv_SendTxData(data);
}
}
else
{
//WaitMicroSec((U1BRG * 140)/371); //wait 1.5 etu
}
if( noError ) //no error detected
txRetryCounter = 0;
U1MODEbits.UARTEN = 1; // Enable UART Module
U1STAbits.OERR = 0; //clear any overflow error that we caused
while(1) // remove rx data recvd from our Tx line
{
WORD temp;
if( U1STAbits.URXDA )
temp = U1RXREG;
else
break;
}
}
Listato 2
//Start smart card stack
SC_Initialize();
// Proceed further only after detecting the card
while( !SC_CardPresent() );
//Turn on power to Card and recieve and process Answer-to-Reset
if( !SC_PowerOnATR() )
while(1)
{
breakPoint++;
}
//configure protocol type selection and select configured baud rate
if( !SC_DoPPS() )
while(1)
{
breakPoint++;
}
WaitMilliSec(20);
// application specific instrunction
// …
// end
// Shut Down the Card when dont need anything to do with it
SC_Shutdown();
while(1)
{
breakPoint++;
}
Listato 3
Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend