Teoria e pratica delle SMART CCARD -...

on questo articolo iniziamo un interessanteviaggio nel variegato mondo delle smart-card. Il nostro obiettivo è quello di presen-

tare nella maniera più esauriente possibile tutte leinformazioni necessarie a comprendere le tecnicheche stanno dietro l'utilizzo sempre più diffuso diquesti dispositivi. Naturalmente, il nostro non saràun discorso generale e prettamente teorico, macome sempre, manterrà un occhio di riguardo versoquegli aspetti pratici che permettono la progettazio-ne e la realizzazione di circuiti digitali in grado diinterfacciarsi con le smart card. Conoscere le tecno-logie significa, per noi, essere in grado di farle fun-zionare magari introducendo qualche aspetto inno-vativo rimasto inesplorato, almeno per la maggiorparte degli appassionati di elettronica. Molti circuitisi prestano ad essere integrati con questi oggettiprincipalmente per sviluppare due funzioni fonda-mentali: un accesso sicuro e la ridefinizione dinami-

ca dei parametri di funzionamento. Questi dueaspetti possono dare un valore aggiunto notevole adun progetto amatoriale introducendo delle caratteri-stiche che lo avvicinano ad un prodotto professiona-le. Si pensi ad esempio al nostro FTP-Client.Nell'ultima release tutti i parametri relativi alla con-nessione vengono registrati su una memoriaEEPROM che viene opportunamente modificataattraverso un apposito programma. Sarebbe senz'al-tro più interessante avere la possibilità di riconfigu-rare l'accesso al server FTP inserendo una smartcard anziché dover scollegare la EEPROM.Analogamente sarebbe senz'altro più professionaleaggiungere il concetto di crittografia in tutti queisistemi che hanno a che fare con la sicurezza delleinformazioni. Attualmente esiste, ad esempio, unInternet-Draft (http://www.ietf.org/ietf/1id-abstracts.txt) che descrive il protocollo sftp (SSHFile Transfer Protocol) in grado di sfruttare lo scam-

Elettronica In - maggio 2006 51

>

Teoria e pratica delle

SMART CCARDa cura di Carlo Tauraso

Iniziamo questo mese un viaggio nel mondodelle Smart Card che ci consentirà di acquisirele conoscenze necessarie per poter svilupparedispositivi e sistemi in grado di interfacciarsicon questi particolari componenti, sempre piùpresenti nella nostra vita quotidiana.

Cor

so S

MA

RT

CAR

D

C

Corso

SMAR

TCAR

D 1111

bio di chiavi a 128 bit per rendere più sicuro il tra-sferimento di file con il server e più in generale conun qualsiasi File System. Che dire, poi, di tutti queiprogettini per il controllo degli accessi, per la gestio-ne di crediti (gettoniere e simili) che possono essereridisegnati integrando smart card di nuova genera-zione. Se agli inizi si utilizzavano soltanto delle cardche funzionavano come delle piccole memorie acontatore ora è possibile inserire delle card che con-tengono al loro interno un vero e proprio sistemaoperativo con tanto di motore crittografico dedicato.La seconda strada, ma non per questo meno impor-tante, che intendiamo percorrere è quella della spe-rimentazione. Possiamo, infatti, tranquillamenteaffermare che questo è forse uno dei campi di utiliz-zo dell'elettronica che sta registrando la nascita dellepiù importanti alleanze tra le grandi aziende produt-trici di chip. Il premio in palio è il controllo e lacommercializzazione dei supporti e dei dispositiviche verranno introdotti nel settore economico-finan-ziario (il Bancomat e le carte di credito a bandamagnetica hanno i giorni contati) oltre a tutti queisistemi che controlleranno l'accesso a servizi privati(pay-TV, video-noleggi, parcheggi ecc.) e di pubbli-co dominio (carta d'identità elettronica). Per avereun’idea di cosa ciò significhi, si consideriche soltanto nel mercato mondiale delGSM nel 2003 esistevano circa 300 milio-ni di SIM. Il vero anello mancante a cui unpo’ tutti stanno lavorando è la card intelli-gente multi-funzione e multi-settore ingrado di rivoluzionare effettivamente ilmondo dei servizi ai cittadini ed in lineagenerale dei consumatori. Nel nostro pic-colo vogliamo affacciarci su questo mondoosservando con cognizione di causa i variaspetti che lo compongono. Per sperimen-tare e quindi tradurre in pratica quanto teo-ricamente descriveremo, abbiamo preso ariferimento un interessante SDK commer-cializzato da un'azienda asiatica: la

Advanced Card Systems Ltd. di HongKong (www.acs.com.hk). Si tratta delquarto produttore mondiale di card rea-der per PC ma il primo ad introdurre unlettore con interfaccia USB compatibilePC/SC. Vedremo che quest'ultimacaratteristica è fondamentale perchérappresenta una piattaforma comunecondivisa dalla Microsoft e quindi dalmaggior produttore mondiale di sistemioperativi per PC. Il card reader ACR38incluso nella confezione è decisamente

interessante perché oltre a permettere l'utilizzo didiverse tipologie di card è certificato PC/SC e pre-senta anche un ASIC in grado di interfacciarsi condei driver proprietari sviluppati da ACS. In questomodo sarà possibile apprezzare sia la facilità diimplementazione di un ambiente aperto e standar-dizzato che la più marcata possibilità di personaliz-zazione ed efficienza di un ambiente chiuso e spe-cializzato. La versatilità del sistema permette quindiun'indagine a tutto campo con un investimento mini-mo (si tratta dell’SDK più economico attualmentesul mercato). Premettiamo che nei nostri sviluppi eprogetti futuri adotteremo, tranne in casi ecceziona-li puramente sperimentali, sistemi di interfaccia-mento standard compatibili PC/SC. In questo modotutti avranno la possibilità di utilizzarli senza dotar-si di lettori particolari ma semplicemente attraversoquelli sempre più integrati direttamente nell'hardwa-re dei nuovi PC (tipicamente all'interno della tastie-ra). Non ci resta che iniziare tentando di chiarirealcuni concetti di base e tentando di identificaredelle classi di dispositivi.

Smart Card: contatti e definizioniQuando parliamo di smart card ci riferiamo ad un

52 maggio 2006 - Elettronica In

Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

Fig. 1

Nel CorsoNel Corsovengonovengonoutilizzati iutilizzati icomponenticomponentihardware ehardware esoftwaresoftwarepresenti nelpresenti nelkit dikit disvilupposviluppoSDK-ACR38SDK-ACR38della ACS.della ACS.

>


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

supporto plastico (ABS, PVC opolicarbonato) dotato di unchip integrato conforme alme-no alle caratteristiche dimen-sionali descritte negli standardISO7810 e ISO7816-1. Si tengapresente che nel corso dell'ap-profondimento per semplicitàparleremo di smart card riferen-doci anche a dispositivi che nonsono compatibili con l'ISO7816soprattutto riguardo all'imple-mentazione dei protocolli di comunicazione. Ingenerale, all'interno di un contesto di comunica-zione tra due dispositivi indicheremo la card con iltermine ICC (Integrated Chip Card) e l'host con iltermine IFD (Interface Device). Il documento chedescrive l'ISO7816, nato nel 1997, è stato via viaintegrato nel corso degli anni tant'è che attualmen-te conta una quindicina di parti. Quelle che con-tengono le informazioni di base necessarie e suffi-cienti per iniziare sono raccolte nelle parti 3 e 4 cheraggruppano le caratteristiche fisiche/elettriche deldispositivo, nonché i protocolli di comunicazione ele modalità di funzionamento (www.iso.org). Ilsupporto plastico di cui è composta la card (Fig.1)ha una piccola cavità nella quale deve essere posi-zionato il chip (chiamato anche “Die”). Le linee dicomunicazione sono riportate sullo strato sopra-stante contenente i contatti metallici. Tipicamentesi utilizza una tecnica chiamata “Wire Bonding”.Ogni pad del chip viene cioè collegata al contattosuperiore attraverso un sottilissimo filo di allumi-nio o di oro. Il chip e relativi fili vengono ricopertiper protezione con una resina fatta polimerizzareattraverso il calore o l'esposizione a raggi UV. Iltutto viene assicurato alle pareti della cavità attra-

verso un collante specifico come illustrato in Fig.2. Nonostante molti siano stati abituati a vederecommercializzati chip con 6 contatti, lo standardne prevede 8 anche se i due che si trovano in bassovengono riservati per utilizzi futuri. Riassumiamole funzioni di ciascuno di essi in Tabella 1. Èimportante considerare che esistono diverse tipolo-gie di card. La caratterizzazione delle stesse puòessere fatta prendendo a riferimento vari parametriquali le tecnologie di interfaccia utilizzate, il livel-lo di sicurezza, le modalità di funzionamento. Nonsolo, all'interno di ciascuna categoria nel corsodegli anni si è assistito ad una progressiva diffe-renziazione delle tecniche utilizzate tant'è che sononate ulteriori sotto-categorie. Per non perdere divista il nostro obiettivo primario che è quello diindagare sul funzionamento dei dispositivi sempli-fichiamo il concetto ed indichiamo due macro-classi: le memory-based card e le MCU-basedcard. Le prime possono essere viste come dellememorie “stupide” che possono avere o meno unaccesso controllato e niente di più. Le secondeinvece hanno una logica interna ed un sistema ope-rativo che la gestisce, pertanto sono in grado diinteragire con il resto del sistema come un'entità

Fig. 2

ID ISO Denominazione Descrizione

C1 VCCTensione positiva di alimentazione. Per la Classe A è pari a 5v anche se nel corso deglianni sono state introdotte anche le Classi B e C rispettivamente a 3v e 1,8v.

C2 RST Linea di reset, permette di forzare il riavvio del ICC.

C3 CLKLinea di clock che permette di sincronizzare la comunicazione seriale con il chip.La sua frequenza stabilisce chiaramente la velocità di comunicazione massima rag-giungibile tra l'ICC e l'IFD.

C4 RFU Riservato per utilizzi futuri.C5 GND Ground

C6 VPPTensione di programmazione, tipicamente utilizzata per la programmazione delleEEPROM contenute nelle card di prima generazione.

C7 I/O

Linea seriale di input e output. Tutti i dati vengono veicolati su questo pin attraverso unsistema di comunicazione seriale half-duplex. Esistono secondo standard due protocolliseriali principali: il T=0 asincrono character oriented e il T=1 asincrono block orientedche analizzeremo nel dettaglio.

C8 RFU Riservato per utilizzi futuri

Tabella 1

differenti. In pratica la tecnica utilizzata specializ-za il dispositivo ma il principio di funzionamentodi base è sempre lo stesso quindi le manteniamonel medesimo gruppo.

Segnali e interfaccePrima di addentrarci nella descrizione dei proto-colli di comunicazione che ci permetterà di inizia-re a capire come integrare queste card nei nostriprogetti facciamo una breve premessa relativa ailivelli elettrici utilizzati. Essi vengono ben descrit-ti nella sezione iniziale dell' ISO7816-3 in manierada permettere il corretto dimensionamento delleinterfacce. Dobbiamo comunque sottolineare che,dal punto di vista della progettazione, al giornod'oggi si utilizzano degli integrati come l'LTC4556che fungono da intermediario tra la logica delmicrocontrollore e la smart-card. L'inserimento diquesti chip permette di introdurre un ulteriorelivello di astrazione al firmware visto che ci si puòconcentrare sullo sviluppo della comunicazionesenza preoccuparsi dei livelli elettrici utilizzati. Ècome se si affidasse il livello fisico ad un chipesterno riservando il livello d'applicazione al PIC.Esistono, infatti, diverse classi di smart card carat-terizzate ciascuna da una diversa tensione di ali-mentazione: Classe A =5V, Classe B =3V, Classe


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

autonoma. A queste due grandi classi affianchiamoquelle che sono le tre possibili tecniche di interfac-ciamento:

1) Contact: Si tratta dell'interfaccia più cono-sciuta ed è basata sul collegamento diretto trami-te contatto fisico tra l'ICC e l'IFD. 2) Contactless: Si basa sullo scambio di infor-mazioni tra ICC e IFD senza contatto diretto matramite onde radio (RFID). In pratica nel corpodella card oltre al chip viene integrata ancheun'antenna che permette di interagire con unapposito ricevitore come descritto in Fig. 3. (Rif.ISO/IEC 14443)

Fig. 3

3) Dual Interface: Lacard in questo caso per-mette l'utilizzo dientrambi i sistemi dicomunicazione (general-mente si basano sullapresenza di un doppiochip).

Abbiamo in questo modoidentificato le smart cardattualmente esistenti.Evitando le sotto-catego-rie andremo caso per casoad evidenziare le tecnichedi specializzazione svilup-pate per ciascun dispositi-vo. In questo modo pos-siamo tranquillamenteparlare di due memory-based card una di tipocount-down ed una conaccesso sicuro senzadoverle necessariamenteidentificare in due classi

Fig. 4


>Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

C =1,8V. La realizzazione di un'integrazione diret-ta con il microcontrollore può comportare dei costie delle limitazioni spesso non accettabili. Si pensiad esempio all'introduzione di una nuova tipologiadi card compatibile a livello di protocolli ma diffe-rente per caratteristiche fisiche: sarà necessariosostituire soltanto lo strato fisico anziché ridise-gnare completamente l'applicazione. Una configu-razione d'interfaccia molto diffusa con il chip pro-dotto dalla Linear Technology è visibile in Fig. 4.All'interno delle nostre descrizioni ci riferiremo allaversione descritta nel documento ISO che formal-mente caratterizza la Classe A. Chiaramente sarànecessario tradurre i livelli nel caso si utilizzino clas-si differenti. Per quanto riguarda, invece, i protocol-li, manterremo la definizione universale di livellologico alto o basso. Analizziamo le caratteristichestabilite dallo standard per i diversi segnali usati:

VCC: L'alimentazione della card deve esseremantenuta nel range stabilito pena la distruzionedella stessa. In particolare nello standard si stabi-lisce come assorbimento massimo i 200mAanche se i prodotti attuali nella maggior parte deicasi non superano i 20mA (l'ACR38 prevede unassorbimento max di 50mA). La tensione secon-do specifiche deve rimanere tra i 4,75V e i 5,25V.VPP: La tensione di programmazione nei dispo-sitivi attuali ha perso la sua funzione iniziale tan-t'è che il pin è utilizzato come una linea digitaleordinaria. Nella prima generazione di card eraessenziale per effettuare la scrittura dati all'inter-no della EEPROM. Ci sono state implementazio-ni che prevedevano addirittura una tensione di21V (carte telefoniche). Nei chip attuali nonrisulta necessario applicare una tensione di pro-grammazione esterna ma essa viene regolatadirettamente dall'interno. Le specifiche ISOfanno riferimento alla seguente tabella, in cui ivalori P e I vengono trasferiti all'IFD durante lafase di inizializzazione (Tabella 2).

Reset). Si tratta di una sorta di handshakingattraverso il quale IFD e ICC si mettono d'ac-cordo sulla modalità di comunicazione da uti-lizzare. Il reset è il primo segnale da gestire alivello firmware. In pratica dopo aver applicatola tensione di alimentazione e il segnale diclock alla card si invia un impulso e si attendela risposta dal ICC. La tabella standard di riferimento è la seguente:

Tabella 2

Tabella 3

Stato Min Max Unità

ProgrammazioneON

0,95 x VCC1,05 x VCC V

20 mA

ProgrammazioneOFF

0,975 x P1,025 x P V

I mA

StatoCorrente

maxin Ingresso

Min Max Unità

Livello LogicoAlto

200µA 4 VCC+0,3 V

10µAV C C -0,7

VCC+0,3 V

Livello LogicoBasso

200µA 0,3 0,6 V

CLK: Questo segnale permette la sincronizza-zione della comunicazione tra IFD e ICC.Consideriamo una card con clock esterno. Sidebbono considerare due valori denominati fi efs. Il reset viene forzato inizialmente dal IFD edurante tale fase esso utilizza un valore di fre-quenza iniziale (fi) che, secondo standard, deveessere compreso tra 1 e 5MHz. La velocità dicomunicazione in questo caso è uguale a talefrequenza divisa per un fattore pari a 372, quin-di con 3,58MHz si raggiungono i 9600bps. Poi,attraverso i dati ricevuti durante l'ATR, l'IFDpuò effettuare un cambiamento di frequenza(per ottimizzare la velocità di comunicazione)da fi a fs che è il valore utilizzato durante tuttele transazioni successive. Tale transizione deveavvenire in maniera precisa per il proseguimen-to della comunicazione. Nel caso in cui l'am-piezza del segnale di clock scenda sotto il 45%dell'ampiezza stabilita, la transazione si inter-rompe. Ci sono due parametri chiave trasferitidalla card durante l'ATR e si chiamano rispetti-vamente F (Clock Conversion Factor) e D (BitRate Adjustment Factor). Essi sono codificatisecondo una tabella specifica e permettono distabilire la frequenza massima di lavoro. Seprendiamo, ad esempio F=1100b e D=1, trovia-mo che la card usa un divisore sulla frequenzadi ingresso pari a 1.536. Quindi il bit rate mas-simo con una frequenza di 5MHz sarà pari adappena 3.300bps circa. Vogliamo con questaprima precisazione farvi notare che un approc-cio nel disegno dell'interfaccia basato su un cri-

RST: Il segnale di reset può essere inviato siadal IFD che dalla card stessa. Ha un importan-za fondamentale durante la fase di inizializza-zione della card chiamata ATR (Answer To

stallo a frequenza fissa non è molto efficientevisto che non permette di far crescere la fre-quenza di clock aumentando la velocità dicomunicazione nelle transazioni successiveall'ATR. Secondo lo standard, infine, il massi-mo tempo di salita e discesa del segnale diclock è pari a 0,5µs considerando una capacitàin ingresso di 30pF. La tabella di riferimento è:

tino in trasmissione. Secondo lo standard il tempodi salita e discesa non può essere inferiore almicrosecondo. Fate riferimento alla Tabella 5considerando come input l'ingresso nella card.

La comunicazioneOra che abbiamo descritto almeno a grandi linee lafisica delle smart card, iniziamo ad affrontare laparte più importante cioè i protocolli di comunica-zione. Il firmware che andremo a sviluppare neinostri progetti deve essere in grado di gestire tuttala parte di trasferimento e ricezione delle informa-zioni. La comunicazione con una smart card avvie-ne attraverso la seguente sequenza di operazioni:1) Connessione ed attivazione dei contatti da

parte del IFD;2) Reset del ICC;3) Ricezione dell'ATR dalla card;4) Scambio di transazioni tra IFD e ICC;5) Disattivazione dei contatti da parte del IFD.

Vediamo di analizzarle separatamente.

FFase1:ase1: AttiAttivvazione dei contaazione dei contatti tti La tensione di alimentazione e i vari segnali devo-no essere applicati al supporto soltanto nelmomento in cui la card è stata inserita nell'apposi-to connettore ISO7816 per evitare possibili dan-neggiamenti. Per fare ciò si sfrutta uno switch inse-rito nel connettore in maniera che il microcontrol-lore d'interfaccia possa rilevare l'inserimento dellacard come se fosse un segnale di interrupt. A questo punto sono necessarie le seguenti opera-zioni:

a) Mantenere a livello logico basso il segnaleRST;

b) Applicare la tensione di alimentazione aVCC;

c) Il pin di I/O deve essere messo a livello logico basso in ricezione;

d) VPP deve essere messo a livello logico alto;e) Al pin CLK deve essere applicato un

segnale di clock stabile.

FFase2:ase2: Reset del ICCReset del ICCQuesta è la fase più cruciale perché permette distabilire se la comunicazione può essere portataavanti o meno con la card che è stata inserita. Il reset viene iniziato dal IFD e termina con laricezione da parte di quest'ultimo della sequenzadi ATR (Answer To Reset) trasmessa dalla card.In pratica, dopo l'attivazione dei contatti, l'IFD


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

Tabella 4

StatoCorrente

maxin Ingresso

Min Max Unità

L i v e l l oLogico Alto

200µA 2,4 VCC+0,3 V

20µA 0,7 x VCC VCC+0,3 V

10µA VCC - 0,7 VCC+0,3 V

L i v e l l oL o g i c oBasso

200µA 0,3 0,5 V

Si noti che il segnale di clock viene utilizzato comeriferimento sia nel caso la card risponda al reset inmaniera sincrona che asincrona.

I/O: Questa è la linea dati che permette lo scam-bio di informazioni tra l'ICC e l'IFD. La comuni-cazione avviene in Half-Duplex e può utilizzaredue protocolli seriali asincroni T=0 e T=1. Nelprimo caso la trasmissione è orientata al singolocarattere. Per ogni byte trasmesso deve esserci unapposito segnale di ACK. Nel secondo caso, inve-ce, il trasferimento avviene per blocchi di byte el'ACK segue ogni singolo blocco. In entrambe icasi si prende comunque a riferimento un deter-minato bit-rate che rimane legato alla frequenzadi clock. Secondo lo standard questa linea puòassumere due stati: uno alto, denominato Z(Mark) ed uno basso, denominato A (Space). Lostato Z è presente quando ICC e IFD sonoentrambe in ricezione. Chiaramente gli stati A e Zpossono essere imposti solo dalla parte trasmit-tente e non è possibile che sia ICC che IFD risul-

Tabella 5

StatoCorrente

maxMin Max Unità

Livello LogicoAlto Input

500µA 2 VCC V

50µA 0,7 x VCC VCC+0,3 V

Livello LogicoBasso Input

1mA 0 0,8 V

Livello LogicoAltoOutput

100µA 2,4 VCCV

20µA 3,8 VCC

Livello LogicoBassoOutput

1mA 0 0,4 V

mette a livello alto il segnale di reset e si pone inricezione sul pin I/O. Entro 40.000 cicli di clockla card deve rispondere con la sequenza di ATRaltrimenti il segnale di reset viene riportato alivello logico basso e si salta alla fase 5 ovveroalla disattivazione dei contatti.Il diagramma di Fig. 5 riassume chiaramente lasituazione.

La parità è corretta quando il numero di 1 all'inter-no della sequenza ba..bi è pari. La sequenza ATR èlunga al massimo 33 caratteri (il carattere TDi fina-le precedente alla sezione Historical non viene tra-smesso) ed è composta da 5 sezioni fondamentalicostituite ciascuna da 1 o più caratteri che codifi-cano al loro interno un parametro da 8 bit o dueparametri da 4bit. Osserviamo la Tabella 6. Gli unici due caratteri obbligatori nella ATR sonoil TS e il T0.

CarCaraatterttere e TSTSIl carattere TS fornisce una sequenza di sincro-nizzazione e stabilisce la convenzione di codificautilizzata nella trasmissione dei caratteri succes-sivi. Esistono soltanto due possibili convenzioni:una Diretta ed una Inversa. Vediamo i due TSrisultanti:

1) Codifica DIRETTA: In questo caso il livellologico uno è lo stato Z, ba è il bit meno significa-


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

>

Initial Character SectionTS Carattere iniziale obbligatorio

Format Character Section

T0Carattere di formato obbligatorio che indica lapresenza della sezione Interface e Historical.Parametri Y1 e K

Interface Character SectionTA1 Parametri F1 e D1

TB1 Parametri I1 e PI1

TC1 Parametro N

TD1 Parametri Y2 e T

TA2 Valore specifico

TB2 Parametro PI2

TC2 Valore specifico

TD2 Parametro Y3 e T

TA3,TB3,TC3 Valori specifici


TA4,TB4,TC4 Valori specifici


Historical Character SectionT1..TK Informazioni specifiche sulla card max 15 caratteri

Check Character SectionTCK Carattere di check opzionale

Tabella 6

Fig. 5

FFase3:ase3: Ricezione dell'ARicezione dell'ATRTRSi faccia attenzione che la card può trasmetterel'ATR sia in maniera sincrona che asincrona.Analizziamo quest'ultimo caso che viene preferitonelle MCU-based card di ultima generazione. Iltempo di durata di ciascun bit trasmesso sulla lineadi I/O viene detto “etu” (Elementary Time Unit) enel corso della sequenza di ATR esso è pari a 372/fi(secondi) con fi che rappresenta la frequenza diclock in Hertz. Ogni carattere trasmesso è compo-sto da 10 bit ed è seguito da una breve pausa chia-mata “Guard Time” che divide un frame da quellosuccessivo. Il bit di start è sempre di livello A. Ilframe è così formato:

1 Bit di Start + 8 Bit di Dati + 1 Bit di ParitàbS + ba bb bc bd be bf bg bh + bi

come si vede nel diagramma di Fig. 6(Z=Alto=Mark, A=Basso=Space):

Fig. 6 Fig. 7

usato e la presenza o meno dei caratteri successivi.Quindi, il valore Y1 stabilisce la presenza di TA1,TB1, TC1, TD1 mentre più in generale Y(i+1)(codificato in TDi) definisce la presenza di TAi+1,TBi+1, TCi+1, TDi+1. Quindi se prendiamo Y2=1100b (che è il nibblepiù significativo di TD1) nella sequenza successi-va dovremo aspettarci la presenza di TA2, TB2 manon di TC2 e TD2. Chiaramente se TDi non viene trasmesso il valore


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

tivo e la TS è rappresentata dalla sequenza[Z]A[ZZAZZZAA]Z come si vede nel diagram-ma di Fig. 7. Il valore di TS è pari a 3Bh.2) Codifica INVERSA: In questo caso il livellologico uno è lo stato A, ba è il bit più significati-vo e la TS è rappresentata dalla sequenza

[Z]A[ZZAAAAAA]Z come si vede nel diagram-ma di Fig. 8. Il valore di TS è pari a 3Fh.

Nelle sequenze descritte la fase di sincronizzazio-ne prevede 4 bit che sono rappresentati in entram-be i casi da [Z]AZZA, facendo chiaramente atten-zione alla diversa definizione di stato A e Z.

CarCaraatterttere e T0T0Il carattere T0 è utilizzato per precisare la presen-za o meno della sezione Interface e Historical.

Fig. 8

Esso è costituito da due parametri a 4bit denomi-nati Y1 e K.Y1 è il nibble maggiormente significativo e defini-sce la presenza dei caratteri TA1, TB1, TC1, TD1.Ad esempio se Y1=1100b significa che nellasequenza successiva dovremo aspettarci la presen-za di TA1 e TB1 ma non di TC1 e TD1. Quindi si ha:

TA1 viene trasmesso se b5 = 1TB1 viene trasmesso se b6 = 1TC1 viene trasmesso se b7 = 1TD1 viene trasmesso se b8 = 1

K invece stabilisce il numero di caratteri dellasezione Historical. Ad esempio con K=0111b avre-mo 7 caratteri T1..T7.

CarCaraattertteri i TTAi,Ai, TBi,TBi, TCi,TCi, TDi (i=1,2,3,4)TDi (i=1,2,3,4)TAi, TBi, TCi contengono i parametri del proto-collo mentre TDi definisce il tipo di protocollo

Tabella 7b8 b7 b6 b5 b4 b3 b2 b1

Y1 K

T0


F1 D1

TA1

predefinito di Y(i+1) è null quindi non verrannotrasmessi ulteriori caratteri d'interfaccia.Riferiamoci ai primi quattro caratteri TA1, TB1,TC1, TD1 e osserviamo la Tabella 8 e seguenti perchiarirci le idee. F1 e D1 rappresentano la codificadei parametri F e D che sono rispettivamente il“Clock Conversion Factor” e il “Bit RateAdjustment Factor”. Entrambe risultano fonda-mentali per stabilire la velocità di comunicazionecon la card e la massima frequenza di clock. I valo-ri predefiniti sono F=372 e D=1, visibili nelleTabelle di codifica 9a e 9b (se F1=0 viene preso ariferimento il clock interno alla card). Abbiamo giàaccennato che nella comunicazione con la card siparla di un “etu iniziale” (tempo di durata di cia-scun bit sulla linea di I/O) usato nel corso del ATRe di un etu di lavoro utilizzato nelle transazionisuccessive. Vediamo un paio di semplici calcoli:Clock internoEtu iniziale=1/9600 secEtu di lavoro= (1/D) * (1/9600) secClock esterno (fi=freq clock iniziale fs=freq clocklavoro)Etu iniziale=372/fi secEtu di lavoro= (1/D) * (F/fs) secIl valore minimo di fs è pari a 1MHz mentre il suovalore massimo dipende da F ed è ricavabile dallaTabella 1. A questo punto possiamo capire perchéattraverso una gestione opportuna del segnale CLKsi possa ottimizzare la velocità con le smart card.Se ricordate il nostro esempio precedente utilizza-vamo un cristallo da 5MHz. Con F=1100b e D=1mantenendo la frequenza costante riuscivamo araggiungere un bit rate di lavoro massimo di circa3.300 bps. Se diamo un'occhiata alla Tabella 10 ciaccorgiamo che in realtà potremmo utilizzare dopo

cessive transazioni. Ci sono 16 possibili valori manella realtà vengono utilizzati soltanto i primi due.

l'ATR una fs massima di 15MHz triplicando lavelocità di comunicazione.


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

Tabella 11

b8 b7 b6 b5 b4 b3 b2 b1

N

TC1


Y2 T

TD1

I1 00 01 10 11

I 25 50 100 RFU

F1 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111

F Int 372 558 744 1116 1480 1860 RFU RFU 512 768 1024 1536 2048 RFU RFU

MHz - 5 6 8 12 16 20 - - 5 7,5 10 15 20 - -

D1 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111

D RFU 1 2 4 8 16 32 RFU 12 20 1/2 1/4 1/8 1/16 1/32 1/64

Tabella 9a

Tabella 9b


I1 PI1

TB1

I1 e PI1 codificano il valore della corrente e dellatensione di programmazione. PI1 compreso tra 5 e 25 definisce il valore dellatensione in volt. PI1=0 indica che la Vpp vienegenerata direttamente all'interno della card a par-tire dalla Vcc. Valori differenti da questi vengono riservati perutilizzi futuri. Il valore predefinito è P=5. Nel caso sia presente il parametro PI2, PI1 vieneignorato. P compreso tra 50 e 250 (tali valoririsultano codificati sui 4bit di PI1) definisceinvece la tensione in termini di decimi di volt.La corrente di programmazione viene definita inmA attraverso la Tabella 11 (il valore predefinitoè I=50):

Con T=0 verrà usato il protocollo seriale asincronocharacter oriented, mentre con T=1 si utilizzerà ilprotocollo seriale asincrono block oriented. Nelcaso TD1 non venga trasmesso si utilizza comevalore predefinito T=0. Per completezza vediamola Tabella 13 dei protocolli previsti secondo stan-dard. Naturalmente, nel caso in cui vengano sup-portati diversi tipi di protocolli, l'IFD avrà la facol-tà di scegliere quello che verrà utilizzato nella

N definisce un valore di ritardo suppletivo (in etu)da aggiungere al “Guardtime”. Il valore normal-mente va da 0 a 254 etu. Nel caso venga trasmessoun N=255 il “Guardtime” viene invece ridotto da12 a 11 etu. Il valore predefinito è N=0 (vediTabella 12).Y2 stabilisce come abbiamo già detto la presenzarispettivamente di TA2, TB2, TC2, TD2. Il para-metro T è, invece, piuttosto importante perché sta-bilisce il protocollo che la card utilizzerà nelle suc-

Protocollo Descrizione

T=0Half-Duplex Seriale asincrono characteroriented

T=1Half-Duplex Seriale asincrono blockoriented

T=2 e T=3 Riservato per trasmissioni Full-Duplex

T=4Riservato per un�evoluzione del Serialeasincrono character oriented

da T=5 a T=13 Riservati per usi futuri

T=14 Riservato per protocolli standard ISO

T=15 Riservato per estensioni future

Tabella 13

comunicazione assieme ai relativi parametri di tra-smissione in una fase successiva alla ricezione delATR chiamata PTS (Protocol Type Selection).

CarCaraattertteri i T1…TKT1…TKQuesti caratteri codificano una serie di informazio-ni relative al tipo, il modello e l'uso della smart-card. In realtà non esiste una definizione specificadelle stesse, si tratta di dati che vengono stabilitidal produttore o dal venditore della smart-card. >


CarCaraatterttere e TCKTCKQuesto carattere serve per stabilire se si è verifi-cato un errore nella trasmissione del ATR. Nelcaso il protocollo compatibile con la card sia sol-tanto il T=0 (con F=372 D=1 N<255) il TCK nonviene neanche trasmesso.

Un caso concretoDopo questa analisi abbastanza dettagliata diquella che è la ricezione di un ATR (risposta asin-crona) vediamo un caso reale. Nel SDK fornitocon l'ACR38 ci sono differenti tool che permetto-no di analizzare le diverse fasi di comunicazionecon una smart card. Il primo programma che uti-lizziamo è il “Quick View”. Esso permette di veri-

TS = 3Bh

Il valore stabilisce che viene utilizzata una codi-fica diretta (Z=1 A=0) e che il bit meno signifi-cativo segue il bit di start.

T0 = BEh quindi Y1=1011b K=14

Y1 ci dice che TA1, TC1, TD1 saranno presentinella sezione di interfaccia mentre mancheràTB1. K invece stabilisce che la sezioneHistorical conterrà 14 caratteri

TA1 = 11h quindi F1=0001b e D1=1

Se leggiamo la tabella relativa a F1 tro-viamo che F=372 e D=1. Si tratta deivalori predefiniti. Il massimo valore difrequenza applicabile è pari a 5MHzpertanto si possono raggiungere i13.400bps.TB1 non viene trasmesso quindi nonsarà necessario applicare tensioni di pro-grammazione particolari dall'esterno.

TC1 = 00h quindi non è necessarioaggiungere alcun ritardo al guardtime

previsto (12etu).

TD1 = 00h pertanto Y2=0 e T=0

Y2 ci dice che nella sequenza non seguiranno icaratteri TA2, TB2, TC2, TD2. Per quantoriguarda il protocollo, invece, verrà utilizzato unHalf-Duplex seriale asincrono character-oriented(T=0).Si entra così nella sezione Historical visto chesecondo Y2 non ci saranno ulteriori caratteridella sezione Interface. Ricordiamo che per ilvalore di K seguono i 14 caratteri: 41 01 38 00 0000 00 00 00 00 00 02 90 00. È una sequenza pre-definita caricata alla produzione, però vedremoche nelle ACOS2 può essere personalizzata.

TCK non viene trasmesso visto che T=0.

Abbiamo visto come l'ATR possa fornire tutte leinformazioni necessarie e sufficienti all'avvio dellacomunicazione tra IFD e ICC. La prossima voltadescriveremo per completezza anche l'ATR sincro-no utilizzato in alcune tipologie di memory basedcard e svilupperemo in dettaglio i protocolli dicomunicazione. Non perdetevela!

Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

Fig. 9

ficare la corretta installazione e configurazione delcard reader. Premettiamo che quest'ultimo puòessere installato sia utilizzando un driver proprie-tario che più semplicemente come dispositivoPC/SC. I due driver sono direttamente scaricabilida: http://www.acs.com.hk/Download.asp. Dopoaver installato il card reader, inseriamo unaACOS2. Si tratta di una MCU-based card da 8Kpiuttosto interessante che utilizzeremo anche neiprogetti futuri. Una volta avviato il programmafacciamo clic sul pulsante “Initialize”. Nel box di sinistra viene generato un elenco deireader installati sul PC. In generale si creano duenodi: uno relativo a quelli compatibili PC/SC eduno relativo ai card reader che sfruttano driverACS proprietari. Considerando le due diversepossibilità di installazione, l'ACR38 può esserevisto in entrambe i modi. Noi, per iniziare, abbia-mo utilizzato la versione proprietaria dell'ACS.Mettiamo il check sull'opzione Advanced e sele-zioniamo il reader installato. La form si presente-rà come in Fig. 9. Il software dopo aver rilevato la presenza di unacard effettua l'inizializzazione registrando lastringa ATR ottenuta in risposta. Vediamo diinterpretarla sulla base di quanto detto finora:

uesto mese ci occupiamo del ATR sincro-no utilizzato in alcune tipologie di

memory based card e dei relativi protocolli dicomunicazione.

ATR sincronoLa trasmissione sincrona non viene utilizzatanelle MCU-based card ma è dominio quasiesclusivo delle cosiddette memory-based card.Esse vengono ancora utilizzate in alcune sempli-ci applicazioni come ad esempio nelle carte tele-foniche prepagate (non quelle italiane che usanoancora la striscia magnetica). La comunicazionesincrona è, in generale, molto legata alla tipolo-gia di chip presente nella card. Quindi, i proto-colli utilizzati non sono uniformi, soltanto l'ATRrisulta standardizzato ed uguale per tutti. È chia-ro che ogni costruttore ha voluto imporre il pro-prio sistema facendo sorgere non pochi grattaca-

pi a chi doveva progettare un reader in grado disupportare diverse tipologie di card visto che alivello firmware è necessario sviluppare diverseregole di comunicazione. Nei protocolli di que-sto tipo non si parla di modelli a più livelli comefaremo nel caso di quelli asincroni. Non c'è sepa-razione tra un livello transport ed uno applicationin quanto il lettore accede direttamente alle loca-zioni di memoria della card. Il termine precisoutilizzato per identificare protocolli di questotipo è: clock synchronous serial data transmis-sion. In pratica le informazioni vengono trasferi-te sempre serialmente bit a bit ma ciò avviene inmaniera sincronizzata rispetto ad una linea diclock esterna. Si rendono, in questo modo, inuti-li gli estremi che identificano l'inizio e la fine diciascun pacchetto (bit di start e stop). Per rende-re le cose semplici, non vengono neanche imple-mentati meccanismi di rilevazione degli errori di

Elettronica In - giugno 2006 59

>

Corso diprogrammazione:

SMART CCARD

a cura di Carlo Tauraso

Proseguiamo questo mese il nostro viaggio nelmondo delle Smart Card che ci consentirà diacquisire le conoscenze necessarie per potersviluppare dispositivi e sistemi in grado diinterfacciarsi con questi particolari componenti.Seconda puntata.

Cor

so S

MA

RT

CAR

D

Q

Corso

SMAR

TCAR

D 2222

trasmissione. Naturalmente la frequenza di clocke quindi il bit rate di queste card sono limitati,rendendo la probabilità di errore molto bassa. Siconsideri che normalmente si parla di frequenzedi clock che vanno dai 7kHz ad un massimo di100kHz. Siccome si trasferisce un bit per ogniciclo di clock, a 10 kHz si ha un bit rate di 10.000bps. Si faccia attenzione che il data rate è sicura-mente inferiore visto che per ogni pacchetto ènecessario inviare anche il relativo indirizzo, per-tanto la quantità di dati trasferita è una frazionedi quelli inviati. Se, ad esempio, inviamo uncomando di scrittura di un byte con un indirizzoa 16 bit ed un byte di controllo, stiamo inviandosolo 8 bit di dati rispetto ad un pacchetto di ben32 bit. In questo caso, con un clock a 10.000 bps,in un secondo trasferiamo 312 pacchetti da 32bit, cioè 1248 byte di cui però soltanto 1/4 ècostituito da dati. Pertanto, il data-rate reale èpari soltanto a 2.500 bps. Anche nel caso dellecard sincrone come è logico supporre, il rappor-

to tra terminale di lettura e card è sempre di tipomaster-slave. Il card reader è il “master” ed ha ilcompleto controllo della comunicazione. Per nonperdere di vista il lato pratico, prendiamo a rife-rimento due interessanti tipologie di memory-card based incluse nel kit di sviluppo della ACSltd: SLE4442 e SLE4428. Si tratta di card pro-dotte da Siemens (chip Infineon) aventi rispetti-vamente uno spazio di memorizzazione di256byte e di 1Kbyte. Entrambe hanno la possibi-lità di proteggere dalla scrittura una certa area dimemoria che diventa quindi permanente(Protectable Data-Memory). In secondo luogoimplementano ambedue un sistema di sicurezzaper l'accesso alla memoria chiamato PSC(Programmable Security Code). Osserviamo, atale proposito, la Figura 1.In pratica non è possibile effettuare alcuna ope-razione di scrittura/cancellazione senza avercomunicato correttamente alla card una sequenzadi 3 byte. Molti di voi avranno sicuramente già

60 giugno 2006 - Elettronica In

Corso SM

ARTCA

RD

Corso SM

ARTCA

RD

Fig. 1

Fig. 2

>


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

pensato che 3 byte rappresentano una sicurezzadecisamente debole. Ma rifletteteci un attimo. Ipossibili valori su 3 byte sono 16.777.215. UnaSLE4442 ha una frequenza di clock massima di50kHz. Per ogni verifica del PSC si inviano 21byte, pertanto si riescono a verificare 297 codicial secondo. Nella peggiore delle ipotesi, quindi,dovremo pazientare quasi 16 ore. Mettetevi ilcuore in pace, anche se riuscireste ad avere a dis-posizione la card per un tempo così lungo senzache il possessore se ne accorga, non riuscireste acombinare niente (a meno di non essere partico-larmente fortunati) perché il PSC è associato adun Error Counter (assieme formano la SecurityMemory): dopo tre tentativi errati la logica inter-na blocca definitivamente l'accesso alla memo-ria. Questo non significa che si tratti di prodottisicuri (la fantasia aguzza l'ingegno) però in molteapplicazioni di basso profilo queste card possonoancora essere prese in considerazione. In secon-do luogo la Protectable Data-Memory si può ren-dere non modificabile attraverso una struttura a32 bit chiamata PROM. Essa contiene 32 flagche corrispondono ciascuno ai 32 byte dell'areadi memoria da proteggere. Nel momento in cuiun flag viene messo a 0 il corrispondente bytediventa di sola lettura. Ma torniamo al nostroATR. Come abbiamo anticipato la risposta datadopo un reset è l'unica struttura dati standard cheaccomuna tutte le card sincrone. Vediamola in dettaglio prendendo come riferi-mento pratico una SLE4442. L'ATR sincrono ècostituito da un header composto da 4 byte comestabilito nelle ISO7816-3/4 e da una serie di altricampi definiti nella ISO7816-10. Questo headerè piuttosto importante perché stabilisce il tipo dicard e le caratteristiche del protocollo utilizzate.Esso è suddiviso in due gruppi da 16 bit: proto-col byte (H1, H2) e historical byte (H3, H4).Osservate, a tale proposito, la Figura 2.

Il byte H1 è costituito da 2 campi:Protocol Type S: In questi 4 bit viene codifica-to il tipo di protocollo sincrono secondo laseguente tabella:

In generale i valori da 0 a 7 vengono riservati perprotocolli standard definiti da ISO.

Structure Identifier: Questi 3 bit vanno adidentificare la struttura dati associata al ATR.Essa chiaramente è legata al tipo di utilizzo.Fondamentalmente si identificano 4 tipologie distruttura:

Valore (HEX) Descrizione

8 Serial data access protocol

9 3 wire bus protocol

A 2 wire bus protocol

F Riservato

Tabella 1

Valore (BIN) Descrizione

X100 Riservato

010 General Purpose

110 Struttura di tipo proprietario

X01, X11 Applicazioni Speciali

Tabella 2

Vedremo come esempio la struttura di tipoGeneral Purpose che è quella normalmente uti-lizzata.Il bit 4 è riservato per utilizzi futuri.Il byte H2 definisce alcuni parametri caratteristi-ci del protocollo utilizzato ed è costituito da 2campi:

Number of Data Units: Questo campo stabili-sce il numero di Data Unit presenti nella memo-ria della card. Si consideri che la Data Unitviene definita come la più piccola unità dimemorizzazione direttamente referenziabile.Pertanto questo valore stabilisce la reale capaci-tà di memorizzazione della card. Normalmenteuna Data Unit è costituita da 1 byte.

Tabella 3Valore (BIN) Descrizione

0000 Non definito

0001 128

0010 256

0011 512

0100 1024

0101 2048

0110 4096

0111 8192

1000 16384

1001 32768

�.. ��.

1111 Riservato

coppia di historical byte. Li accantoniamo per-ché non verranno utilizzati nelle nostre applica-zioni.

Il byte H4 ha un contenuto riservato se il bit8 è a0 mentre se il bit8 è a 1 contiene dei riferimentialla struttura dati che segue in sequenza l'headerATR, in particolare alla sezione chiamataDirectory (DIR).

Reference of DIR Data: Come abbiamo giàvisto per quanto riguarda questi riferimenti nonsi ha una definizione formale nella ISO7816-4.

Nel diagramma di Figura 3 potete vedere come sipresenta la struttura informativa associataall'ATR in una SLE4442.La struttura che segue l'intestazione è compostada due gruppi di byte: ATR Data e DIR Data. Idue gruppi sono a loro volta suddivisi in piùsezioni ciascuna delle quali identificata dalla pre-senza di appositi TAG. Ad esempio, il TM stabi-lisce l'inizio della sezione relativa al produttoredella card, il TT stabilisce l'inizio della sezionerelativa ai dati relativi all'applicazione. Come sivede ad ogni TAG segue un campo contenente lalunghezza della sezione. Accanto al TM c'è LMaccanto al TT c'è LT e così via. La sequenzadenominata ATR Data contiene informazionispecifiche per l'identificazione della tipologia dichip mentre la DIR a cui punta l'H4 è legata altipo di dati utilizzati nell'applicazione. Si facciaattenzione che normalmente quando si acquistauna nuova card alcuni di questi campi vengonopredefiniti dal costruttore (per le SLE4442 nel


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

Length of Data Units in Bits: Stabilisce la lun-ghezza in bit di ciascuna Data Unit espressacome potenza di 2. Normalmente ciascuna DataUnit è costituita da 8 bit.

Tabella 4Valore (BIN) Descrizione

000 Non definito

001 2

010 4

011 8

100 16

101 32

110 64

111 128

Il bit 8 è un flag che stabilisce se la lettura dellasequenza di parametri passata deve avvenire finoalla fine della struttura o per un numero di bytepredefinito.Il byte H3 determina meglio la struttura datiassociata al ATR anche se nelle card di utilizzogenerico non trova una definizione particolare alivello di standard. Esso è costituito da un unicocampo:

Category Indicator: Se il valore di questo byteè pari a 10h nel byte H4 si trova un campo diriferimento alla struttura dati successiva il cuisignificato però viene lasciato libero e nonrisulta precisato nella ISO7816-4. Sono stabili-ti altri due valori possibili che precisiamo soloper completezza: 00h e 80h entrambe fannoriferimento ad un campo di status che segue la

Fig. 3


>Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

disegno sono evidenziati con bordo in neretto).Vediamo ora un esempio pratico. Questa voltautilizzeremo un altro programma presente nelkit, un po’ più potente del precedente: ilCardTool (ver1.2.87). Facciamo doppio clic sul-l'icona relativa ed apriamo una nuova sessioneselezionando i driver proprietari del readerACR38 e come tipologia di card la SLE4442. Seinviamo un comando di Reset attraverso il pan-nello laterale vedremo comparire nella finestra dilog i 4 byte del header ATR. Prima di capirne ilsignificato facciamo ancora un piccolo passoavanti e consideriamo che l'intera struttura infor-mativa che abbiamo analizzato si trova proprionei primi 32 byte della memoria della card. Sitrova, cioè, nell'area di memoria che può essereprotetta da scrittura (Protectable Data-Memory)attraverso la PROM (Protection ROM) cheabbiamo visto nel diagramma iniziale.

Quindi si ha:Protocol Type S =1010b = AhSi utilizza un protocollo di tipo 2 wire bus cioèbasato su due linee di comunicazione una per idati ed una per il clock.

Structure Identifier: 010b

La struttura dati associata al ATR è di tipoGeneral Purpose.

H2 = 13h = 00010011b

Quindi si ha:

Number of Data Units: 0010b

Il numero di data units è di 256 corrispondentealla grandezza della memoria disponibile sullacard.

Length of Data Units in Bits: 011b

Ciascuna data unit è costituita da 8 bit. Pertantodall'insieme dei due campi il card reader è ingrado di capire che si trova di fronte una card conuna memoria di 256 byte.

H3 = 10h

Category Indicator: 10h

Qui troviamo il valore di default che indica lapresenza di un riferimento alla DIR successiva.

H4 = 91h = 10010001b

Fig. 4

Fig. 5

Effettuiamo quindi una Read di 32 byte partendodall'indirizzo 00h sempre attraverso il pannellolaterale. Si faccia attenzione che tutti i campidevono essere inseriti in esadecimale (vediFigura 4).

Il log risultante sarà come quello visibile inFigura 5.Si vede chiaramente che i 4 byte del header ATRcorrispondono proprio ai primi 4 byte dellaProtectable Data-Memory. Vediamo, inoltre, chenella struttura ci sono diversi byte già pre-memo-rizzati. Normalmente le SLE4442 vengono ven-dute al pubblico con ATR header, ICM, ICT, AIDgià definiti. Interpretiamo l'ATR come abbiamofatto l'altra volta.

H1 = A2h = 10100010b

Se continuiamo nella sequenza troviamo:

ICM = 81h

Identifica il produttore della card.

ICT = 15h

Identifica il tipo di card.

AID = D2 76 00 00 04 00

Questo codice viene assegnato da un'autorità diregistrazione Internazionale come l'ANSI(www.ansi.org Modulo di registrazione suhttp://www.ansi.org/other_services/registration_programs/rid.aspx?menuid=10) e serve a far inmodo di identificare il tipo di servizi erogabili dal-l'applicazione per cui la card viene rilasciata. Sitratta, in pratica, di un sistema che permette al ter-minale di sapere che tipo di card si trova davanti equali servizi dovrebbe essere in grado di erogare.Esso si compone di due parti principali:

RID (Registered Application Provider Identifier):Identifica l'ente che eroga il servizio (in questocaso è lungo 5 byte). Si consideri ad esempio cheesiste il RID per il PC/SC Workgroup (A0 00 0003 06) che identifica l'associazione di aziende chesta diffondendo lo standard PC/SC di cui parlere-mo prossimamente.PIX (Proprietary Application IdentifierExtension): permette di differenziare il proprioservizio applicativo dagli altri già definiti.

Quello che è importante tenere presente è chequesti 32 byte possono venir protetti da successi-ve modifiche settando il cosiddetto ProtectionBit che si trova nella PROM.

Compatibilità ISO7816L'invio di comandi di lettura/scrittura ad unaSLE4442/28 segue un protocollo che come pertutte le card sincrone è di tipo proprietario.Questo significa che ciascun costruttore ha imple-mentato le proprie strutture di comunicazione. Inquesto caso, ad esempio, si utilizzano comandi a3 byte, la Siemens ha previsto due tabelle per uninsieme complessivo di 7 istruzioni. Per chiarez-za le abbiamo riassunte in Figura 5.Il protocollo prevede chiaramente che alcuneistruzioni come la READ SECURITYMEMORY avvengano esclusivamente dopo unaverifica positiva del pin altrimenti l'accesso aidati viene bloccato. Ora, osservate il log del CardTool. Quando abbiamo letto i primi 32 byte dellamemoria abbiamo inviato una sequenza di bytecorrispondente a quella evidenziata dal simbolo“<”. Certamente la cosa appare un po’ stranavisto che l'istruzione che ci aspettavamo secondole specifiche Siemens era:

30h 00h 00h

Ebbene qui entra in gioco uno strato d'interpreta-zione che in questo caso è rappresentato dal firm-ware contenuto nel card reader. Siccome leSLE4442/28 utilizzano un protocollo di comuni-cazione che esce dallo standard 7816/3 allora èstato realizzato uno strato che emula una MCUcard standard. Tutto ciò facilita lo sviluppo latosoftware perché non è necessario implementareparticolari funzioni che cambiano a seconda dellacard utilizzata. Il programma, quindi, inviacomandi standard. Sarà il card reader ad interpre-tarli e a tradurli nella richiesta prevista dal proto-collo proprietario della card con la quale si stacomunicando. Nel nostro caso all'inizio abbiamo


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

BYTE 1 BYTE2 BYTE3 Descrizione

00110000 Indirizzo NDREAD MAIN MEMORY Permette di leggere i byte contenuti in tutti i256 byte di memoria.

00111000 Indirizzo DatoUPDATE MAIN MEMORY Permette di modificare il contenuto dellamemoria.

00110100 ND NDREAD PROTECTION MEMORY Permette di leggere i 32 bit contenutinella PROM che rendono immodificabili i primi 32 byte della memo-ria (Protectable Data-Memory).

00111100 Indirizzo Dato WRITE PROTECTION MEMORY Permette di scrivere nella PROM.

00110001 ND NDREAD SECURITY MEMORY Permette di leggere i 3 byte del pin ed ilcontatore degli accessi errati (Error Counter).

00111001 Indirizzo Dato UPDATE SECURITY MEMORY Permette di effettuare la modifica del pin

00110011 Indirizzo DatoCOMPARE VERIFICATION DATA Permette di verificare il contenuto diuna cella di memoria.

Tabella 5

Successivamente quando arriva nel ApplicationLayer e quindi alla nostra applicazione utentediventa un APDU (Application Protocol DataUnit). È importante comprendere che mentre leTPDU dipendono dal tipo di protocollo utilizzatole APDU non cambiano. In pratica è possibile stu-diare il contenuto ed il formato di una APDUavendo la sicurezza che essa potrà essere trasferi-ta alla card utilizzando ad esempio sia un proto-collo byte-oriented come il T=0 sia un protocolloblock-oriented come il T=1. Per quanto riguardagli strati OSI, nel mondo delle smart card, ci siriferisce al Link Layer anche come Transport

selezionato un driver proprietario ACS pertantoabbiamo introdotto un’ulteriore complicazione. Ilprogramma, infatti, invia un comando (ACI read)il cui formato è definito dalla ACS. Pertanto ilsoftware invia un “ACI read” e il card reader lointerpreta e lo traduce in un “READ MAINMEMORY” una volta letti i dati li rinvia al PC. La“ACI read” fa parte di una libreria API(Application Program Interface) complessiva con-tenente tutte le funzioni eseguibili dal ACR38 cheviene fornita col lettore per facilitare lo sviluppodi software compatibile con esso. Vediamo neldettaglio il formato (ACI read) previsto dall'ACSper capire che cosa avvie-ne realmente e per intro-durre il concetto di APDU(vedi Tabella 6).I vari campi compongononel loro insieme unaAPDU che sta perApplication Protocol DataUnit. Distinguiamo fin daora il concetto di APDUda quello di TPDU. Percomprendere bene comefunziona il sistema dobbiamo riferirci al modelloISO/OSI che abbiamo già incontrato quando par-lavamo di protocolli Ethernet. In generale, tutta lacomunicazione tra card e terminale può essererappresentata considerando tre strati fondamenta-li: Physical Layer, Link Layer, Application Layer.Ciascuno di questi strati viene descritto in diversistandard. Citiamo ad esempio il GSM 11.11 perl'Application Layer relativo alle SIM dei cellularioppure l'ISO 10536 per quanto riguarda ilPhysical Layer delle contactless card. È importan-te comprendere che quando parliamo di protocol-li gli oggetti che vengono trasferiti tra card e ter-minale sono detti PDU cioè Protocol Data Unit.Quando un PDU arriva al Link Layer (che per noiè lo strato di trasporto) diventa un TPDU(Transmission Protocol Data Unit).


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

>

Campo Valore Descrizione

CLA 00 Definisce la classe dell'istruzione.

INS 01 Identifica la singola istruzione all'interno della classe, in questo caso è una ACI read.

P1 00 MSB dell'indirizzo di lettura.

P2 00 LSB dell'indirizzo di lettura.

P3 00Qui secondo standard va il numero di byte da inviare alla card, il valore è 0 essendo un'istru-zione di lettura.

Le 20Questo campo (Le=Length expected) definisce il numero di byte da leggere, in questo caso sitratta dei 32 byte della Protectable Data-Memory.

Tabella 6

Fig. 6

Layer. Questa può sembrare un'ambiguità in real-tà si tratta di una visione complessiva che associail servizio di trasporto tipico del Transport Layer aquello di gestione degli errori di trasmissione tipi-co del Link Layer. Si faccia attenzione che in alcu-ni protocolli come il T=0 non c'è una separazionetra lo strato di trasporto e quello dell'applicazione.Inoltre tutta la gestione degli errori di trasmissio-ne è affidata soltanto al bit di parità. Pertanto inmolta letteratura che fa riferimento solo a questoprotocollo vi capiterà di non trovare distinzione traTPDU e APDU. Noi abbiamo voluto farne men-zione per completare il discorso chiarendo il fun-zionamento anche di altre tipologie di protocollo(vedi Figura 6). L'APDU rappresenta l'elementofondamentale di comunicazione tra lettore e smartcard e trova la sua naturale definizione nello stan-

zare i driver standard PC/SC e vedere come cam-biano le cose. Avviamo Card Tool e questa voltaapriamo una nuova sessione selezionando i driverPC/SC mantenendo sempre come card laSLE4442. Il form di selezione apparirà come inFigura 7. Se ora effettuiamo un reset della card eproviamo a leggere i primi 32 byte della memoriaci troveremo di fronte il log riportato in Figura 8.Il comando inviato è differente dal precedente perquanto riguarda la classe ed il codice identificati-vo ma il risultato è esattamente lo stesso. L'APDUrelativa ha una struttura che combacia fondamen-talmente con la precedente tranne che per gli iden-tificativi CLA e INS. Facendo riferimento al docu-mento “ACR38 PCSC Memory Card Access” dis-ponibile sul sito della ACS (area download), ci siaccorge che a fronte di questo comando la rispostadella card è più completa rispetto a quanto ripor-

tato nel log del Card Tool. Accanto aibyte letti dalla memoria, infatti, lacard risponde anche con i 4 byte rela-tivi alla Protection Memory che cipermette di sapere quali byte dellamemoria risultano protetti da even-tuali modifiche. Siccome vogliamodarvi una visione quanto più comple-ta del sistema abbiamo provveduto asviluppare un piccolo programminoche permette di inviare l'APDU dilettura visualizzando tutti i byte dirisposta. L'eseguibile funziona utiliz-

capire bene come la distribuzione del nostro pro-dotto divenga decisamente più semplice. Nei pro-getti che andremo a sviluppare manterremo a rife-rimento questo standard per il lato software men-tre per quanto riguarda il lato firmware ci diverti-remo a implementare diverse tipologie di proto-collo per sperimentarne le caratteristiche e funzio-nalità. Questa scelta chiaramente è dettata dallapossibilità di far funzionare i software distribuiti acorredo dei nostri progetti sulla stragrande mag-gioranza di card reader attualmente in commercio.Bene, a questo punto possiamo provare ad utiliz-


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

dard ISO7816/3-4. Naturalmente è prevista la pos-sibilità di creare delle APDU proprietarie anche seciò può comportare una certa difficoltà nella dis-tribuzione del proprio prodotto. Qualcuno, infatti,potrebbe obiettare che un software che implemen-ta la ACI read è in grado di colloquiare solo conl'ACR38 e questo fa sorgere un problema a menoche tutti i propri clienti arrivino a dotarsi delmedesimo lettore. È proprio per ovviare a questiproblemi che nel corso degli anni è stato fatto ungrosso lavoro di standardizzazione che ha portatoalla nascita di uno standard riconosciuto chiamatoPC/SC divenuto poi un punto di riferimento fon-damentale per il mondo Windows. Realizzare unsoftware compatibile PC/SC significa creare unprodotto in grado di colloquiare con qualsiasi let-tore PC/SC. Considerando che tra gli ideatori diquesto sistema ci sono HP e Microsoft, potete

Fig. 7

Fig. 8

Fig. 9

ni di implementazione e compatibilità. Dal nostropunto di vista ora accantoniamo le card sincrone(funzionalità limitate) per occuparci delle MCUbased card che rappresentano il futuro del merca-

to. Sulla base di quantoabbiamo detto fino ad orapartiamo descrivendo lastruttura di un APDU. Poivedremo quali sono le TPDUcaratteristiche dei protocollipiù diffusi. Infine descrivere-mo i comandi veri e propri.L'approccio permette diavere una visione complessi-

va del funzionamento dando la possibilità di com-prendere facilmente tutte le evoluzioni introdotteda diversi standard. Se facessimo un discorso spe-cialistico finiremmo per focalizzare la nostraattenzione su una nicchia specifica limitata ad untipo di applicazione. Attualmente esistono ad esempio standard specifi-ci per le SIM GSM (GSM 11.14) o per le carte dicredito (EMV2000). Anziché descrivere un utiliz-zo particolare (sono molto di moda gli articolisulle SIM GSM) vogliamo descrivere i concettifondamentali che stanno alla base di tutti questisistemi in maniera da avere gli strumenti peraffrontare diversi tipi di sviluppo. Quando presen-teremo i nostri progetti andremo poi a descrivere idettagli relativi. Anche per questo mese il nostro spazio è esaurito,vi diamo appuntamento alla prossima puntatanella quale analizzeremo in dettaglio la strutturadelle APDU vedendo come esse vengano poiincapsulate nelle TPDU dei vari protocolli.Arriveremo quindi ai comandi veri e propri.

zando i driver PC/SC, si chiama Leggi4442.exe edè scaricabile dal sito della rivista. Una volta avvia-to si deve selezionare il lettore dalla lista e fare clicsul pulsante “Avvia Connessione”. Nel log appari-rà una stringa che ci avviserà dell'avvenuta con-nessione con il dispositivo e di seguito l'ATR rice-vuto dalla card. A questo punto è possibile inseri-re i due campi liberi dell'APDU: P2 corrisponden-te all'indirizzo iniziale di memoria dal quale sivuole effettuare la lettura, P3 corrispondente alnumero di byte che si vuole leggere. Abbiamoprovato ad inviare la medesima APDU utilizzata


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

Il sistema di sviluppo cui si fa riferimento in questo corso(cod. SDK-ACR38) è disponibile al prezzo di Euro 119,00presso la ditta Futura Elettronica (www.futurashop.it). Laconfezione comprende il lettore ACR38, 20 smart card,un ACR38T SIM smart card reader, un ABR08LS balancereader e un CD-ROM con software e driver di supporto.

HEX 7 6 5 4 3 2 1 030 0 0 1 1 0 0 0 0

HEX 15 14 13 12 11 10 9 8FF 1 1 1 1 1 1 1 1

HEX 23 22 21 20 19 18 17 161F 0 0 0 1 1 1 1 1

HEX 31 30 29 28 27 26 25 24F8 1 1 1 1 1 0 0 0

Tabella 7

nel Card Tool (Figura 9). Come si vede chiara-mente la risposta ottenuta dalla card è un po’ piùlunga. Nella parte evidenziata si notano i 4 byterelativi alla protection memory e di seguito i duebyte relativi allo status dell'operazione. Vediamodi analizzare la sequenza binaria relativa. InTabella 7 abbiamo evidenziato il valore di ciascunbit in corrispondenza dell'indirizzo di ciascunacella di memoria a cui si riferisce. In pratica ognibit a 0 determina un byte di sola lettura. Se osser-vate bene risultano non modificabili i byte dellelocazioni 0,1,2,3,6,7,21,22,23,24,25,26. Si trattaproprio dei 12 byte contenuti nell'ATR che risulta-no pre-memorizzati dal produttore della card.L'APDU complessiva è riassunta in Tabella 8.Questa digressione ci ha permesso di descriverel'ATR delle card sincrone anticipando le linee fon-damentali del sistema di comunicazione tra letto-re e smart card. La prima cosa che salta all'occhioè che ci possono essere diversi modi per raggiun-gere il medesimo risultato, resta da scegliere quel-lo che risulta maggiormente conveniente in termi-

Tabella 8Campo Valore Descrizione

CLA FF Definisce la classe dell'istruzione

INS B0Identifica la singola istruzione all'interno della classe, inquesto caso è una READ_MEMORY_CARD

P1 00 MSB dell'indirizzo di lettura, per le SLE4442 è sempre a 0

P2 00 LSB dell'indirizzo di lettura

P3 20 Numero di byte da leggere

Telecontrollo GSMcon antenna integrata

IVA inclusa.

Sistema di controllo remoto bidirezionale che sfrutta la reteGSM per le attivazioni ed i controlli. Configurabile con una semplice telefonata, dispone di due uscite a relè (230Vac/10A) con funzionamento monostabile o bistabile e di due ingressi di allarme optoisolati. Possibilità di memorizzare 8 numeri per l'invio degli allarmi e200 numeri per la funzionalità apricancello. Tutte le impostazioni avvengonotramite SMS. Alimentazione compresa tra 5 e 32 Vdc, assorbimento massimo500mA. Antenna GSM bibanda integrata. Il prodotto viene fornito già montato e collaudato.

Caratteristiche tecniche:

! GSM: Dual Band EGSM 900/1800 MHz (compatibile con ETSI GSM Phase 2+ Standard);! Potenza di uscita:

Class 4 (2W @ 900 MHz);Class 1 (1W @ 1800 MHz).

! Temperatura di funzionamento: -10°C ÷ +55°C;! Peso: 100 grammi circa;! Dimensioni: 98 x 60 x 24 (L x W x H) mm;! Alimentazione: 5 ÷ 32 Vdc;! Corrente assorbita: 20 mA a riposo, 500 mA nei picchi;! Corrente massima contatti relè: 10 A;! Tensione massima contatti relè: 250 Vac;! Caratteristiche ingressi digitali:

livello 1 = 5-32 Vdc;livello 0 = 0 Vdc.

[TDG33 ! Euro 198,00]

Applicazioni tipiche:

In modalità SMS! Impianti antifurto per immobili civili ed industriali! Impianti antifurto per automezzi! Controllo impianti di condizionamento/riscaldamento! Controllo pompe ed impianti di irrigazione! Controllo impianti industriali

In modalità chiamata voce / apricancello! Apertura cancelli! Controllo varchi! Circuiti di reset

Via Adige, 11 -21013 Gallarate (VA) Tel. 0331/799775 - Fax. 0331/778112

www.futuranet.it

Maggiori informazioni su questi prodotti e su tutte le altre apparecchiaturedistribuite sono disponibili sul sito

www.futuranet.it tramite il quale è anche possibileeffettuare acquisti on-line.

ontinuiamo il nostro percorso nel mondodelle smart card. Ci eravamo lasciati conl'intenzione di analizzare la strutture

delle APDU (Application Protocol Data Unit)che sono la base della comunicazione tra termi-nale di lettura e smart-card. Successivamente vedremo come tali strutture sidifferenziano a livello transport nei diversi protocolli.

C-APDU: la strutturaTutti i dati che vengono scambiati tra la smartcard ed il terminale di lettura sono inseriti in unastruttura standard associata allo stratoApplication del modello ISO/OSI. Ciascuna APDU viene poi incapsulata all'internodi una TPDU dipendente dal protocollo di tra-smissione usato per passare attraverso lo strato ditrasporto sottostante. Si faccia attenzione che

parliamo di incapsulamento e non di interpreta-zione o conversione, pertanto l'APDU viene tra-sferita in maniera completamente trasparente. Lo standard ISO 7816-4 fa una distinzione traCommand APDU (C-APDU) e Reply APDU (R-APDU). Come abbiamo già detto la comunicazione traterminale e card è di tipo master-slave. Quindi, il terminale invia un comando e la carddopo averlo eseguito ritorna una risposta. L'APDU è una sorta di scatola che può contene-re o un comando per la card o una risposta dallacard. La struttura dell'APDU si compone di un'intesta-zione a lunghezza fissa (header) e di un corpovariabile (body). Se osservate la Figura 1 riconoscerete sicura-mente dei campi che abbiamo incontrato nelladescrizione dei comandi inviati alla SLE4442.

Elettronica In - luglio / agosto 2006 67

>


SMART CCARD


Proseguiamo questo mese il nostro viaggio nelmondo delle Smart Card analizzando lastruttura delle APDU che sono alla base dellacomunicazione tra questi dispositivi eterminale di lettura. Terza puntata.

Cor

so S

MA

RT

CAR

D

C

Corso

SMAR

TCAR

D 3333

L'intestazione è costituita da 4 campi, lunghi cia-scuno 1 byte: CLA, INS, P1, P2. Vediamoli neldettaglio:

CLA: Identifica la classe che raggruppa uninsieme di istruzioni. Generalmente gli insiemisono caratterizzati dal tipo di applicazione percui le istruzioni vengono utilizzate. Ad esempioil codice 'A0' viene usato nei sistemiGSM11.11, il codice '80' per sistemi di tran-sazioni commerciali elettroniche compatibilicon lo standard EN1546-3 ecc. I due bit menosignificativi di questo codice possono essereutilizzati per identificare un canale logico dicomunicazione. Questa funzionalità permette disfruttare le card che contengono più applicazio-ni indipendenti. In pratica un terminale può dia-logare con più applicazioni residenti sulla cardche vengono eseguite in parallelo. I due bit per-mettono di specificare a quale applicazioneviene inviato il comando. Un esempio concretodi applicazione lo si trova facilmente nella SIMdel nostro cellulare quando, durante una con-versazione, sfogliamo la rubrica o inseriamo untesto nel blocco note. I bit 3 e 4 della classe per-mettono, invece, di stabilire se viene utilizzatoun sistema di messaggistica sicura oppure no.Tutti i dati scambiati tra terminale e smart cardviaggiano normalmente in chiaro e pertantorisulta abbastanza semplice modificare un letto-re collegando una linea al contatto di I/O, regi-strare i pacchetti che transitano ed analizzarlisuccessivamente. Sono stati ideati diversi siste-mi per aumentare la sicurezza nel transito diinformazioni critiche uno fra tutti è l'utilizzo deicosiddetti BER-TLV-coded data objects(BER=Basic encoding rules of ASN.1TLV=Tag Length Value). Per il momento tene-

te per buona questa definizione,avremo spazio per parlarne nelmomento in cui affronteremo lefunzioni crittografiche utilizza-te in alcune card come leACOS2. In Tabella 1 abbiamoinserito alcune classi di esem-

pio riportate nella ISO7816-4.

Se prendiamo la classe “0X”, il nibble menosignificativo viene codificato per stabilire i cana-li logici e l'utilizzo di un sistema di messaggisti-ca sicura (SM) come abbiamo sintetizzato inTabella 2. Analogamente il nibble più significati-

68 luglio / agosto 2006 - Elettronica In

Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

Fig. 1

CLA Descrizione

0XComandi standard compatibili ISO 7816-4-7-8

10..7F Riservati per evoluzioni future

D0..FEComandi proprietari o specifici per unaparticolare applicazione

A0 Comandi compatibili GSM 11.11

Tabella 1

Tabella 2b4 b3 b2 b1 Descrizione

x x Numero Canale Logico

0 0 SM non utilizzato

0 1SM utilizzato non

standard ISO

1 0SM utilizzato standard

ISO, Header nonautenticato

1 1SM utilizzato standard

ISO, Header autenticato

vo pari ad “A” identifica una classe di istruzionistrutturalmente compatibile con ISO7816-4 maspecificata in documenti supplettivi come adesempio il GSM 11.11 per la classe “A0”.

INS: Identifica l'istruzione all'interno dellaclasse. Nel caso del protocollo T=0 è prevista lapossibilità di effettuare l'attivazione di una ten-sione di programmazione esterna ritornando alterminale il codice INS incrementato di 1. Percompatibilità con questo protocollo all'iniziosono stati previsti solo codici pari. A causa del-l'obsolescenza di tale pratica (nelle card attualila tensione di programmazione viene generataall'interno del medesimo chip) è stata proposta

INS Descrizione

0E Erase Binary

20 Verify

70 Manage Channel

82 External Authenticate

84 Get Challenge

88 Internal Authenticate

A4 Select File

B0 Read Binary

B2 Read record

Tabella 3

>


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

una revisionedell'ISO7816-3. In Tabella3 abbiamo inserito alcunicodici d'istruzione d'esem-pio riportati nellaISO7816-4.P1, P2: Questi due campiservono principalmente peril passaggio di parametri.Ad esempio, in una Readrecord, P1 viene utilizzatoper passare alla card ilnumero del record sequen-ziale da leggere.Naturalmente, nel caso ilparametro non sia necessario, basta trasmetter-lo con valore zero.

Il corpo dell'istruzione (body) può avere una lun-ghezza variabile e può anche essere omesso.Esso contiene un campo che definisce la lun-ghezza della sezione dati in ingresso o uscita. Inpratica bisogna trasmettere il campo Lc (lengthcommand) che definisce il numero di byte datiinviati alla card oppure il campo Le (lengthexpected) che definisce il numero di byte che cisi aspetta in risposta dalla card. Chiaramentequando si specifica il campo Lc si deve ancheprecisare di seguito la sequenza dati che si vuoleinviare. Ponendo Le=0 si stabilisce che il termi-nale di lettura si aspetta dalla card il massimonumero di byte dati previsti per il comando invia-to. In generale Le e Lc sono lunghi 1 byte, quin-di permettono di stabilire unalunghezza massima della sequen-za dati pari a 255. Per ovviare aquesta limitazione è stata previstala possibilità di utilizzare unasequenza di escape (00) allungan-do il campo relativo di un byte ed

memorizzazione delle schede più diffuse.Vediamo in Tabella 4 come si presenta un campoLe in un comando che si aspetta 300 byte inrisposta dalla card.Se ora consideriamo l'header come obbligatorioe le diverse combinazioni con cui si possono pre-sentare Le e Lc, determiniamo 4 tipi di APDU(Figura 2).

R-APDU: la strutturaAd ogni comando inviato, la card invia una rispo-sta pertanto ad ogni C-APDU corrisponde una R-APDU. Formalmente essa è costituita da unacoppia di codici di risposta (trailer) obbligatoriae da un corpo opzionale. Il corpo contiene i datirichiesti dal terminale di lettura pertanto ha unalunghezza in byte pari al parametro Le inviatoall'interno della C-APDU. Chiaramente il body

Tabella 4Sequenza di escape

Le [MSB] Le [LSB]

00 01 2C

arrivando quindi a precisare una lunghezza dellasequenza dati pari a 65.535. Le e Lc possono,quindi, arrivare ad una lunghezza di 3 byte com-prendendo la sequenza di escape. Si tratta,comunque, di casi piuttosto infrequenti sia per ilfatto che si preferisce effettuare più sessioni ditrasmissioni brevi, sia per le limitate capacità di

Fig. 2

Fig. 3

viene omesso nei casi 1 e 3 quando cioè il termi-nale non richiede dati alla card. Nei casi 2 e 4 ilcorpo nella risposta può non essere inserito sol-tanto se si verifica un errore o i parametri tra-smessi non sono accettabili (Figura 3).La coppia di byte SW1 e SW2 è, invece, obbliga-toria e rappresenta il codice di ritorno dell'opera-zione richiesta. Indica fondamentalmente se l'o-perazione si è conclusa correttamente oppure no.Ad esempio, nella precedente puntata, in rispostaalle richieste fatte alla SLE4442 ricevevamo uncodice “9000” che indica una conclusione corret-

ferenza del suo fratello minore T=0, è l'unicostandard riconosciuto a livello internazionale chepermette uno sviluppo in termini di sicurezzalineare senza dover realizzare procedure partico-lari. La comunicazione tra smart card e terminalesi avvia dopo la trasmissione iniziale dell'ATR: ilterminale invia il primo blocco e la card risponde.In generale i blocchi hanno due compiti fonda-

mentali: trasferire dati applicati-vi, trasferire dati di controllo egestione degli errori. Ogni bloccoha una struttura costituita da treparti: Prologo, Informazione,Epilogo. Il Prologo e l'Epilogosono obbligatori mentre il campoInformazione è opzionale.Quest'ultimo è composto da unaC-APDU o una R-APDU aseconda che il blocco trasporti uncomando da terminale a card ouna risposta da card a terminale.Osservate che il blocco rappre-senta la struttura di trasporto edessa incapsula le informazioni

necessarie allo strato “Application”. Nel passaggio da un livello a quello superiore ilblocco viene spogliato dei campi di contorno efornisce le informazioni necessarie allo stratoapplicativo. Analogamente nella direzione inversale informazioni originali vengono incapsulate dainformazioni di contorno per accedere ai livelliinferiori ed essere trasferite al destinatario. Lastruttura si vede chiaramente in Tabella 6. A livello di protocollo esistono tre blocchi diffe-renti:1.INFORMATION BLOCK (I-BLOCK): per-

mettono lo scambio di dati applicativi.2.RECEIPT ACKNOWLEDGEMENT

BLOCK (R-BLOCK): non trasferiscono infor-mazioni ma servono unicamente per informareil terminale o la card della corretta o errata rice-zione di una sequenza dati.

3.SYSTEM BLOCK (S-BLOCK): veicolanoinformazioni di controllo relative al protocollodi comunicazione in uso.


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

ta dell'elaborazione. Sono stati definiti diversicodici di ritorno per precisare le varie situazionidi errore. Si faccia attenzione che soltanto il codi-ce “9000” ha un significato universale in quanto,spesso, i costruttori hanno implementato dei codi-ci specifici relativi alla particolare applicazionesviluppata. Riassumiamo in Tabella 5 alcuni codi-ci di errore specificati nella ISO 7816-4.

Tabella 5

Il protocollo T=1Dopo aver visto quali sono le strutture fondamen-tali di comunicazione vediamo come questeentrano a far parte dei protocolli più diffusi nelmondo delle smart card. Il T=1 è un protocollohalf-duplex asincrono di tipo block-oriented per-tanto la più piccola unità di informazione scam-biata tra terminale e smart card è costituita da unblocco di byte. Questa è la caratteristica che lodifferenzia principalmente dal suo concorrenteT=0. Un'altro fatto molto importante è che questoprotocollo effettua una separazione precisa tra lostrato transport e quello application. I dati neces-sari all'applicazione specifica possono essere tra-smessi in maniera completamente trasparentedagli strati sottostanti senza che questo comportiparticolari conversioni o interpretazioni.L'utilizzo di un sistema di messaggistica sicurobasato sulla cifratura necessita di una precisaseparazione tra i diversi livelli, pena la necessitàdi compromessi piuttosto scomodi. Il T=1, a dif-

SW1 SW2 Descrizione

65 XX

Errore di esecuzione: Stato della memoria non modificato.Nel caso di un'operazione di scrittura questo codice ci avver-te che l'operazione è stata interrotta prima che le modifichesiano state effettuate.

69 XX Istruzione non permessa.

6C XXLa lunghezza trasmessa in Le è errata, in SW2 viene passa-to il valore corretto.

6D 00 Codice di istruzione non supportato.

6E 00 Classe non supportata.

62 82Raggiunta fine file prima di aver letto un numero di bytepari a Le.

68 81 Identificativo canale non corretto.

Denominazione PROLOGO INFORMAZIONE EPILOGO

CampoNADNode

Address

PCBProtocolControl

Byte

LENLength

APDUApplication

Protocol Data Unit

EDCError Detection

Code

Lunghezza 1 1 1 0...254 1...2

Tabella 6


>

Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

Vediamo di analizzare i vari campi che compon-gono ciascuna sequenza trasferita tra terminale ecard.

PROLOGONode Address (NAD): Contiene l'indirizzo sor-gente e destinazione per il blocco che viene tra-smesso. Ogni indirizzo è codificato con 3 bit.Gli ultimi due bit rimanenti vengono riservatiper la gestione della tensione di programmazio-ne. Essi vengono inclusi solo per mantenere lacompatibilità con le vecchie card visto cheattualmente la tensione di programmazioneviene gestita direttamente all'interno della card.Nel caso un indirizzo non sia utilizzato vienemesso a 0. Nella Tabella 7 si vede la struttura del

ca sia il tipo di errore che il “Receive sequencenumber” N[R]. Si faccia attenzione che termi-nale e smart-card gestiscono al loro interno duecontatori autonomi che identificano le variesequenze trasmesse e ricevute. La Tabella 9 pre-senta un R-BLOCK nelle tre possibili situazio-ni: ricezione corretta, errore di checksum/pari-tà, errore generico. Il secondo bit è relativo aduna feature che contraddistingue il protocolloT=1: il “Block chaining”. Si tratta di una fun-zionalità che permette di concatenare più I-BLOCK superando la lunghezza fisica del buf-fer di trasmissione o ricezione. La cosa diventautile quando è necessario trasmettere unasequenza dati piuttosto lunga. La funzione è uti-lizzabile sia dal terminale che dalla card. Lasessione viene avviata attraverso la trasmissio-

ne di un primo I-BLOCK con il bit M(More Data Bit) a 1.Quest'ultimo permet-te di segnalare aldestinatario che nellatrasmissione si uti-

lizzerà la funzione di concatenamento e che iprossimi blocchi conterranno i dati in sequenza.Nel momento in cui l'altra parte riceve questo

Tabella 7bit8 bit7 bit6 bit5 bit4 bit3 bit2 bit1 Descrizione

X X VPP

X X X DAD (Destination Address)

X X X SAD (Source Address)

NAD. I bit utilizzati per ciascun campo sonoevidenziati dalle X.Protocol Control Byte (PCB): Contiene infor-mazioni di controlloche permettono dimonitorare il funzio-namento del proto-collo di comunicazio-ne. Ad esempio, codi-ficano la tipologia diblocco, la presenza dierrori, il numero disequenza ecc. In Tabella 8 vediamo il PCB nelcaso di un I-BLOCK. Interessanti sono i due bit:“Send Sequence Number” e “Sequence data bitM”. Il primo N[S] parte da 0 e viene incremen-tato ad ogni trasmissione pertanto durante unasessione di comunicazione esso assume alterna-tivamente i valori 0 e 1. In questo modo unnodo può richiedere la ritrasmissione di unblocco errato inviando un R-BLOCK che indi-

bit8 bit7 bit6 bit5 bit4 bit3 bit2 bit1 Descrizione

0 Tipo blocco (I-BLOCK)

N[S] Send sequence number

M Sequence data bit M

X X X X X Riservati

Tabella 8

primo I-BLOCK contenente la prima sezionedati col bit M=1, essa invia un R-BLOCK conun N[R] (Receive Sequence Number) equiva-lente al N[S] (Send Sequence Number) delprossimo blocco. A questo punto il mittenteinvia un nuovo I-BLOCK con la successivasezione dati e così via. Lo scambio reciproco diI-BLOCK e R-BLOCK avviene finché il desti-natario riceve un I-BLOCK con il bit M=0.


1 0 Tipo blocco (R-BLOCK)

0 N[R] 0 0 0 0 Corretto

0 N[R] 0 0 0 1 Errore EDC/Parità

0 N[R] 0 0 1 0 Errore generico

Tabella 9

Questo fatto segnala che l'I-BLOCK ricevuto èl'ultimo della sequenza. Ci sono due limiti fon-damentali in questo processo: la sequenza èunidirezionale quindi se il terminale invia unacatena la card non può rispondere con un'altracatena, in secondo luogo se la RAM della cardnon è sufficientemente grande per conteneretutta la sequenza dati essa deve essere trasferitain EEPROM con una diminuzione della veloci-tà di comunicazione. In alcuni casi questa funzionalità non vieneimplementata pertanto durante lo sviluppo diun'applicazione particolare è bene verificare lecaratteristiche della card che si sta utilizzandotenendo presente che il proprio firmwarepotrebbe in certi casi avere dei problemi dicompatibilità. Nel diagramma di Figura 4 sivede la trasmissione concatenata di due I-Block

da parte del terminale con risposta conclusivada parte della card.

Esiste ancora un tipo di blocco chiamato S-BLOCK che permette di trasferire delle infor-mazioni di controllo per il protocollo utilizzato.Vedremo nel prossimo paragrafo che si tratta diun caso particolare in cui la separazione tra glistrati Application e Transport diventa meno pre-cisa. In Tabella 10 vediamo il PCB con l'eviden-za delle codifiche utilizzate nei vari casi.Come avrete notato, vengono gestite diverseimportanti situazioni relative al protocollo. Nedescriviamo due che forse appaiono un po’ piùcomplesse a chi si avvicina per la prima volta almondo delle smart-card: la resincronizzazione ela gestione del cosiddetto WTE (Waiting TimeExtension). In generale il primo caso si verifica


Corso SM

ARTCA

RD

Corso SM

ARTCA

RD

Fig. 4


1 1 Tipo blocco (S-BLOCK)

0 0 0 0 0 0 Richiesta di resincronizzazione dal terminale

1 0 0 0 0 0Risposta alla richiesta di resincronizzazionedalla smart-card

0 0 0 0 0 1Richiesta di modifica della lunghezza delcampo Informazione

1 0 0 0 0 1Risposta alla richiesta di modifica del campoInformazione

0 0 0 0 1 0 Richiesta cancellata

1 0 0 0 1 0 Risposta alla cancellazione della richiesta

0 0 0 0 1 1Richiesta di un WTE (Waiting Time Extension)dalla smart-card

1 0 0 0 1 1 Risposta alla richiesta di un WTE dal terminale

1 0 0 1 0 0Errore gestione della tensione di programma-zione Vpp dalla smart-card

Tabella 10

quando a seguito della ricezione di un bloccoerrato non è possibile effettuare la ritrasmissionecorretta dello stesso. Il terminale, quindi, inviaun S-BLOCK con una richiesta di resincronizza-zione ed attende la risposta dalla smart-card.Quest'ultima invia a sua volta un S-Block conte-nente la risposta alla richiesta di resincronizza-zione. Se tutto funziona correttamente terminalee smart-card azzerano i propri contatori di tra-smissione e ricezione ed il terminale tenta diriprendere la comunicazione. Si consideri che ècome se ci si riportasse alla situazione esatta-mente successiva all'ATR. Si tratta di una speciedi warm-boot che riguarda solo il motore dicomunicazione e non il resto della logica presen-te nei due dispositivi. La seconda situazione siverifica quando la smart-card necessita di unmaggior intervallo di tempo rispetto a quello pre-visto per generare una risposta ad una richiestadel terminale. Nel primo capitolo avevamo vistocome, durante l'ATR, la smart-card informa ilterminale delle temporizzazioni utilizzate nellacomunicazione. Se vi ricordate, nell'interfacecharacter si definisce ad esempio il BWT (BlockWaiting Time) cioè il massimo intervallo ditempo intercorrente tra la fine di un blocco invia-to e l'inizio di un blocco da ricevere. Nel caso unterminale invii una richiesta e non riceva rispostaper un tempo superiore al BWT, la comunicazio-ne viene terminata. Ebbene, ci possono esseredei casi in cui questo timeout risulta essere trop-po corto pertanto la smart-card invia un S-BLOCK richiedendo un'estensione dell'interval-lo di tempo. Il terminale, a sua volta, deve invia-

re un altro S-BLOCK in accettazione. Il termina-le non può rifiutare una richiesta di WTE. L' S-BLOCK iniziale contiene nel campoInformazione un byte che precisa la lunghezzadell'estensione. In particolare questo valore sta-bilisce di quante volte deve essere moltiplicato ilBWT trasmesso durante l'ATR.

Length (LEN): Indica la lunghezza in byte delcampo Informazioni. Va da un minimo di 0 adun massimo di 254. L'estremo superiore (255)viene riservato per utilizzi futuri.

INFORMAZIONEQuesto campo rappresenta la vera unità dati neces-saria al livello Application. Come abbiamo vistoessa si trova incapsulata tra due sezioni denomina-te Prologo ed Epilogo che invece servono per il tra-sporto. L'informazione contenuta in questo campoviene trasmessa in maniera totalmente trasparentedagli strati sottostanti senza alcun tipo di valuta-zione o interpretazione formale. Si realizza cioèuna precisa separazione tra il livello di trasporto equello di applicazione. Soltanto in un caso partico-lare - quello degli S-BLOCK - questo campo con-tiene delle informazioni utilizzate dallo strato ditrasporto. Ad esempio la richiesta di un WTE daparte della smart-card rappresenta un caso tipico.All'interno del campo Informazione viene trasferi-to il moltiplicatore del BWT quindi un dato adesclusivo uso e consumo dello strato di trasporto.C'è da dire che questa situazione influenza margi-nalmente anche lo strato superiore visto che essoviene messo in attesa. Tuttavia esso non ricevealcun tipo di informazione applicativa visto che


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

>

Tabella 11Hex bit8 bit7 bit6 bit5 bit4 bit3 bit2 bit1

NAD 00 0 0 0 0 0 0 0 0

PCB 00 0 0 0 0 0 0 0 0

LEN 07 0 0 0 0 0 1 1 1

CLA A0 1 0 1 0 0 0 0 0

INS A4 1 0 1 0 0 1 0 0

P1 00 0 0 0 0 0 0 0 0

P2 00 0 0 0 0 0 0 0 0

LEN 02 0 0 0 0 0 0 1 0

D1 2F 0 0 1 0 1 1 1 1

D2 00 0 0 0 0 0 0 0 0

EDC 2E 0 0 1 0 1 1 1 0

Leggete la matrice colonna per colonna dall'alto inbasso. Vi accorgerete che il codice calcolato ha un1 in corrispondenza della colonna con un numerodispari di 1 ed uno 0 in corrispondenza dellacolonna con un numero pari di 1. È chiaro che nel caso di bit errato, il ricevente sene accorge facilmente ma non è in grado di cor-reggerlo perché sa soltanto che l'errore si trova inuna ben determinata posizione ma non sa su qualebyte del blocco. In secondo luogo osservate cheun errore di classe 2 che coinvolge cioè due bitnella stessa posizione in due byte differenti nonpuò essere rilevato perché questo riporta comples-sivamente il numero di 1 al valore corretto.Supponiamo che al terminale venga trasmesso lostesso blocco ma con D1=27h. Nell'EDC in colon-na 4 c'è un 1 quindi ci si aspetta un numero di 1dispari. Se D1=27h, la colonna 4 viene azzerataquindi gli 1 diventano pari. Il nodo ricevente siaccorge che c'è qualcosa che non va. Se, invece,D1=27h e D2=8h, in colonna 4 torna un 1 in cor-rispondenza di D2, pertanto il totale complessivoè dispari, compatibile con il bit dell'EDC. Il nodoricevente non si accorge dell'errore. Osservate ledue tabelle in cui sono stati evidenziati in rosso ibit errati.ERRORE 1 BIT: L'EDC a 2Eh è incompatibile


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

l'S-BLOCK in sostanza trasferisce solo valori dicontrollo. Secondo lo standard, la lunghezza diquesto campo sia per il terminale che per la card èpari a 32 byte anche se nelle attuali implementa-zioni non è raro trovare lunghezze che superano i60-70 byte. La lunghezza del campo Informazioneper il terminale viene detta IFSD (InformationField Size for the interface Device) e può esseremodificata come si vede dalla tabella precedenteattraverso un particolare S-BLOCK. Quella per lasmart-card viene detta IFSC (Information FieldSize for the Card) e si può modificare attraverso l'Interface Character visto nell'ATR.

EPILOGOError Detection Code: Quest'ultima sezionechiude il blocco ed è formata da due byte il cuivalore deriva dall'elaborazione di tutti gli altri.Essi costituiscono un codice in grado di rilevaregli errori di trasmissione ma non permettono lacorrezione dello stesso. L'algoritmo utilizzato peril calcolo viene specificato attraverso un parame-tro contenuto nell'ATR. Normalmente si usanodue algoritmi: LRC (Longitudinal RedundancyCheck) e CRC16 (Cyclic Redundancy Check a16bit). In generale lo standard prevede che ilprimo sia quello predefinito, nel caso l'ATR nonlo specifichi. IlLRC effettua unXOR concatenatosu tutti i byte cheprecedono e quindirisulta esseremolto semplice daimplementare tan-t'è che nei chipattuali il calcoloviene fatto al volodurante una tra-smissione o unaricezione. Si trattadel sistema mag-giormente utilizzato nella pratica e coinvolge ununico byte. Grazie a questo algoritmo è possibilerilevare gli errori relativi ad un singolo bit. In pra-tica il bit n di questo byte stabilisce se c'è unnumero pari o dispari di “uno” nella posizione ndei vari byte che compongono il blocco. Adesempio supponete di dover calcolare l'LRC sulseguente blocco: 00-00-07-A0-A4-00-00-02-2F-00. Se disponete i valori in una matrice e riporta-te in basso l'LRC, si comprende facilmente ilsignificato del codice risultante (vedi Tabella 11).

Tabella 12H b8 b7 b6 b5 b4 b3 b2 b1

NAD 00 0 0 0 0 0 0 0 0

PCB 00 0 0 0 0 0 0 0 0

LEN 07 0 0 0 0 0 1 1 1

CLA A0 1 0 1 0 0 0 0 0

INS A4 1 0 1 0 0 1 0 0

P1 00 0 0 0 0 0 0 0 0

P2 00 0 0 0 0 0 0 0 0

LEN 02 0 0 0 0 0 0 1 0

D1 27 0 0 1 0 0 1 1 1

D2 00 0 0 0 0 0 0 0 0

EDC 2E 0 0 1 0 1 1 1 0

con la sequenza quindi il dispositivo ricevente siaccorge dell'errore (vedi Tabella 12).ERRORE 2 BIT: L'EDC a 2Eh è compatibile conla sequenza quindi il dispositivo ricevente non siaccorge dell'errore (vedi Tabella 13).

La gestione dell'errore di trasmissioneConsideriamo il punto di vista del terminale.Attraverso l'EDC esso è in grado di rilevare lapresenza di un errore di trasmissione. Ma checosa succede dopo? Il terminale tenta di ripren-

mentando dei sistemi molto più semplici e menoonerosi per le risorse dei microcontrollori integra-ti nelle card. Un esempio particolarmente calzan-te è quello relativo alle specifiche EMV. La siglaEMV sta per Europay Mastercard Visa IntegratedChip Card Standard. Si tratta di specifiche nate inseno alle maggiori aziende che operano nel campodei sistemi di pagamento elettronici(www.emvco.com). Attualmente la Europay è stataacquisita da Mastercard e nel gruppo è venuta afar parte la JCB International, leader nel mercatoorientale che da sola nel 2003 movimentava qual-cosa come 52 miliardi di dollari. Considerando leproblematiche di sicurezza e le semplificazioniimplementative necessarie, all'interno di questespecifiche si ritrova un'interpretazione piuttostolimitante che taglia fondamentalmente buonaparte dei meccanismi adottati per il ripristino dellacomunicazione nel protocollo T=1 secondol'ISO7816-3. In pratica vige la regola secondo cui“se qualcosa va storto è meglio disattivare tutto eripartire”. Ad esempio se la risposta da parte dellacard si fa attendere superando il BWT, se la cardinvia un S-BLOCK di cancellazione dell'operazio-ne, se il terminale invia tre blocchi successivisenza ricevere una risposta corretta non c'è sincro-nizzazione che tenga e la card viene disattivata

costringendo l'ope-ratore ad estrarla ericominciare l'ope-razione da capo.Anche per questonumero siamogiunti al terminedel nostro spazio.Tenete bene amente quanto dettoper il protocolloT=1 perché nellaprossima puntatatermineremo il dis-corso sui protocolli

più diffusi nel mondo delle smart card descriven-do il T=0 e completando la panoramica con unpaio di sistemi particolari di sicuro interesse(smartcard USB). Apprezzeremo le differenze conquanto visto in questo articolo, soprattutto in ter-mini di facilità di implementazione, ma porremoanche l'attenzione su alcune limitazioni che talisemplificazioni implicano. Inizieremo, quindi aparlare di comandi veri e propri sperimentandoneil funzionamento sulle ACOS2. Non perdetevi ilprossimo numero.

dere una comunicazione corretta attraverso unaprocedura suddivisa in tre livelli.

1. RICHIESTA DI RIPETIZIONENon appena si accorge dell'errore il terminaleinvia alla smart-card un R-BLOCK con l'indi-cazione dell'errore rilevato. La smart-card,una volta ricevuto l'R-BLOCK, ripete la tra-smissione del blocco errato.

2. RICHIESTA DI RESINCRONIZZAZIONENel caso il primo livello fallisca, il terminaleinvia un S-BLOCK con la richiesta di resin-cronizzazione e la smart-card risponde con unaltro S-BLOCK di accettazione. I contatori diricezione e trasmissione interni vengono azze-rati su entrambe i dispositivi ritornando allasituazione immediatamente successivaall'ATR. Viene tentata nuovamente la trasmis-sione del blocco errato.

3. RESETNel caso anche il secondo livello fallisca, ilterminale effettua un reset della smart-cardtentando una nuova sessione di comunicazio-ne dall'inizio. Se anche in questo caso lasmart-card non risponde correttamente dopo3 tentativi, essa viene disattivata ed il termi-nale segnala all'utente che la card probabil-mente è guasta.


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

Tabella 13

H b8 b7 b6 b5 b4 b3 b2 b1NAD 00 0 0 0 0 0 0 0 0

PCB 00 0 0 0 0 0 0 0 0

LEN 07 0 0 0 0 0 1 1 1

CLA A0 1 0 1 0 0 0 0 0

INS A4 1 0 1 0 0 1 0 0

P1 00 0 0 0 0 0 0 0 0

P2 00 0 0 0 0 0 0 0 0

LEN 02 0 0 0 0 0 0 1 0

D1 27 0 0 1 0 0 1 1 1

D2 08 0 0 0 0 1 0 0 0

EDC 2E 0 0 1 0 1 1 1 0

Se facciamo riferimento al modello ISO/OSI ciaccorgiamo che le prime due fasi di gestione del-l'errore gravano esclusivamente sul livello di tra-sporto senza influenzare quello applicativo. Laterza fase, invece, finisce per influenzare anchequesta parte visto che con il reset si riparte da zeroe tutti i dati della sessione attuale vanno perduti. Sitenga presente che il meccanismo di gestione deglierrori rilevati descritto in questo paragrafo è quel-lo previsto nello standard. In certi casi i costrutto-ri l'hanno interpretato in maniera restrittiva imple-

Completa gamma di sistemi di sviluppo eprogrammazioneoriginali Microchip evasta scelta di microcontrollori disponibili a stock.

Compra originale... compra Microchip!

PICDEM2PLUS DEMOBOARD PER MICRO PIC16XX e 18XX

PICDEMFS USB

La scheda PICDEMF-SUSB è una demo board che consente di valutare i microcontrollori della Microchip dotati di porta USB (PIC18F2455/2550/4455/4550). La confezione comprende:• Demo Board dotata di microcontrollore PIC18F4550 (TQFP a 44 pin);• Cavo USB;• Software e documentazione completa su CD-ROM. PICDEMFSUSB € 93,00

PICDEMFS USB

valutare i microcontrollori della Microchip dotati di porta USB (PIC18F2455/255

La confezione comprende:• Demo Board dotata di microcontrollore PIC18F4550 (TQFP a 44 pin);

new

PICTAIL SDMMC

Starter Kit PICSTART PLUS Sistema di sviluppo originale Microchip a basso costo per i microcontrollori PIC 12C5XX, PIC14000, PIC16C5X, PIC16CXX e PIC17CXX. L’am-biente di sviluppo software (MPLAB, Integra-ted Development Environment) consente di editare e di assemblare il programma sorgente. L’MPLAB-SIM permette di simulare il funziona-mento del programma in modo estremamente semplice. Al termine della fase di debug è possibile procedere ad una rapida programmazione del dispo-sitivo. Il PICSTART Plus, grazie agli aggiornamenti di-sponibili sul sito internet della Microchip (www.microchip.com), è sempre in grado di programmare qualsiasi tipo di microcontrollore PIC. PICPLUS € 274,00

Sistema di sviluppo originale Microchip a basso costo per i microcontrollori PIC 12C5XX, PIC14000, PIC16C5X, PIC16CXX e PIC17CXX. L’am-biente di sviluppo software (MPLAB, Integra-ted Development Environment) consente di editare e di assemblare il programma sorgente. L’MPLAB-SIM permette di simulare il funziona-mento del programma in modo estremamente semplice. Al termine della fase di debug è possibile procedere ad una rapida programmazione del dispo-sitivo. Il PICSTART Plus, grazie agli aggiornamenti di-sponibili sul sito internet della Microchip (www.microchip.com), è sempre in grado di programmare qualsiasi tipo di

€ 274,00274,00

FLASH UPGRADE per PICSTART PLUSModulo di tipo fl ash da installare sulle vecchie versioni dei programmatori PICSTART che montano un PIC non riprogrammabile. Va sostituito al micro esistente e consente l’aggiornamento del fi rmware tramite porta seriale. Il kit comprende il CD con l’ultima versione del software MPLAB® IDE. PICFLASH-UPG € 56,00

II PICDEM 2 Plus è una demo board per mi-crocontrollori della serie PIC16XXXX e PIC18XXXX da 18, 28 e 40 pin. La demo board può essere utilizzata stand-alone, programmando a parte il microcontrol-lore, oppure collegando un emulatore in-circuit (MPLAB ICE) o un debbuger in-circuit (MPLAB ICD 2). PICDEM2PLUS € 164,00

II PICDEM 2 Plus è una demo board per mi-crocontrollori della serie PIC16XXXX e

Kit di sviluppo composto da un pro-grammatore USB in-circuit originale Microchip e da una demo-board dotata di micro vergine (PIC16F917). Il sistema consente di programmare la maggior parte dei microcon-trollori Flash delle famiglie 10, 12, 16, 18 e 24 nonchè di eseguirne - sui micro che supportano tale funzione - il debug in tempo reale. Il PICKit2DE consente a chiunque di avvicinarsi al mondo della programmazione dei microcontrollori, offren-do il vantaggio di poter compiere il debug in fase di progettazione. Il programma in esecuzione nel micro può essere lanciato, bloccato e eseguito passo-passo. Può essere impostato un breakpoint sul programma in esecuzione con la possibilità di resettare il micro. I contenuti dei registri possono essere verifi cati e modifi cati quan-do il programma sul micro non è in esecuzione. Il set comprende anche due CD (MPLAB e PICkit 2 Starter Kit) con tutto il software necessario. Il secondo CD con-tiene un corso in dodici lezioni che copre gli argomenti relativi a I/O, Interrupt, ADC, Tabelle Dati & Timer. Vengono forniti anche i fi le di tutti i codici sorgente. Il fi rmware del dispositivo può essere facilmente aggiornato dal sito Microchip.PICKIT2DE € 81,00

Kit di sviluppo composto da un pro-grammatore USB in-circuit originale Microchip e da una demo-board dotata di micro vergine (PIC16F917). Il sistema consente di programmare la maggior parte dei microcon-trollori Flash delle famiglie 10, 12, 16, 18 e 24 nonchè di eseguirne - sui micro che supportano tale funzione - il debug in tempo reale. Il PICKit2DE consente a chiunque di avvicinarsi al mondo della programmazione dei microcontrollori, offren-do il vantaggio di poter compiere il debug in fase di progettazione. Il programma in

56,0056,0056,00

newSISTEMA DI SVILUPPO USB IN-CIRCUIT DEBUG EXPRESS

Tutti i prezzi si intendono IVA inclusa.

Starter Kit PICSTART PLUS

2PLUS € 164,00,00

new

Programmatore USB in-circuit originale Microchip adatto a tutti i microcontrollori Flash delle famiglie 10, 12, 16 e 18. Il set comprende due CD (MPLAB e PICkit 2 Starter Kit) con tutto il software neces-sario. Il secondo CD comprende anche un corso in dodici lezioni che copre gli argomenti relativi a I/O, Interrupt, ADC, Tabelle Dati & Timer. Vengono forniti anche i fi le di tutti i codici sorgente. Il fi rmware del dispositivo può essere facilmente aggiornato dal sito Microchip. Il programmatore PICkit 2 si collega ad un personal computer via USB 2.0 a piena velocità, permettendo di velocizzare la programmazione e l’aggiornamento del fi r-mware. Il supporto di nuovi dispositivi può essere eseguito aggiornando il fi rmware sul sito web di Microchip; non è necessario un alimentatore aggiuntivo, né per il programmatore né per la scheda dell’applicazione. Il kit si inserisce dentro le schede di sviluppo tramite la tecnologia ICSP™ (In-Circuit Serial Programming™) ed è di dimensioni particolarmente ridotte.PICKIT2 € 56,00

Programmatore USB in-circuit originale Microchip adatto a tutti i microcontrollori Flash delle famiglie 10, 12, 16 e 18. Il set comprende due CD (MPLAB

SISTEMA di SVILUPPO USB IN-CIRCUIT

Sistema di sviluppo composto da un programmatore USB in-cir-cuit originale Microchip adatto a tutti i microcontrollori Flash delle famiglie 10, 12, 16 e 18 e da una demo-board completa di micro vergine. Il set comprende anche due CD (MPLAB e PICkit 2 Starter Kit) con tutto il software necessario. Il secondo CD contiene un corso in dodici lezioni che copre gli argomenti relativi a I/O, Interrupt, ADC, Tabelle Dati & Timer. Vengono forniti anche i fi le di tutti i codici sorgente. Il fi rmware del dispositivo può essere facilmente aggiornato dal sito Micro-chip. Il sistema di sviluppo PICkit 2 DP si collega ad un personal computer via USB 2.0 a piena velocità, permettendo di velocizzare la programmazione e l’aggiorna-mento del fi rmware. Il supporto di nuovi dispositivi può essere eseguito aggiornando il fi rmware sul sito web di Microchip; non è necessario un alimentatore aggiuntivo, né per il programmatore né per la scheda dell’applicazione. Il kit si inserisce dentro le schede di sviluppo tramite la tecnologia ICSP™ (In-Circuit Serial Programming™) ed è di dimensioni particolarmente ridotte. PICKIT2DP € 79,00

SISTEMA di SVILUPPO USB IN-CIRCUIT

Sistema di sviluppo composto da

cuit originale Microchip adatto a tutti i microcontrollori Flash delle famiglie 10, 12, 16 e 18 e da una demo-board completa di micro vergine. Il set comprende

2 Starter Kit) con tutto il software necessario. Il secondo CD contiene un corso in dodici lezioni che copre gli argomenti relativi a

Via Adige, 11 ~ 21013 Gallarate (VA) Tel. 0331/799775 ~ Fax. 0331/778112

Espansione per interfacciare memorie SD e MMC a sistemi di sviluppo dotati di connettore PICtail (es.PICDEMFSUSB). PICTAILSDMMC€ 62,00

PICDEM.NET2 SISTEMA SVILUPPO ETHERNET Il prodotto PICDEM.net 2 è una scheda di sviluppo Internet/Ether-net, supporta sia il controller Ether-net ENC28J60 sia il microcontrollore Ethernet PIC18F97J60. Con questa scheda, scaricando gratuitamente dal sito Microchip lo stack TCP/IP, è possibile sviluppare un web server attraverso il quale è possibile monito-rare e controllare applicazioni stand-alone attraverso internet. PICDEM.NET2 € 240,00

MPLAB ICD 2 è un pro-grammatore in-circuit Microchip per disposi-tivi fl ash che consen-te anche il debugging del programma. Grazie al software fornito a corredo, il programma realizzato può essere eseguito in tempo reale, esaminato in dettaglio e debuggato. Il fi rmware interno può essere facilmente ag-giornato dal sito Microchip. Consente di selezionare le variabili da monitorare e di impostare i breakpoint direttamente dal codice sorgente C o assembly ed eseguire passo passo le istruzioni.ICD2 € 204,00 L’MPLAB-SIM permette di simulare il funziona-

mento del programma in modo estremamente semplice. Al termine della fase di debug è possibile procedere ad una rapida programmazione del dispo-sitivo. Il PICSTART Plus, grazie agli aggiornamenti di-sponibili sul sito internet della Microchip (www.microchip.com), è sempre in grado di programmare qualsiasi tipo di microcontrollore PIC. PICPLUS

FLASH UPGRADE per PICSTART PLUS

€ 204,00204,00

impostare i breakpoint direttamente dal codice sorgente C o assembly ed eseguire

newÈ disponibile un kit comprendente sia il pro-grammatore/debugger ICD2 che la demoboard PICDEM2PLUS.MPLABICD2EVKIT € 315,00

MPLAB ICD 2 è un pro-grammatore in-circuit Microchip per disposi-tivi fl ash che consen-te anche il debugging del programma. Grazie al software fornito a corredo, il programma realizzato può essere eseguito in tempo reale,

PICDEM.NET2 SISTEMA SVILUPPO

Il prodotto PICDEM.net 2 è una scheda di sviluppo Internet/Ether-net, supporta sia il controller Ether-net, supporta sia il controller Ether-net ENC28J60 sia il microcontrollore Ethernet PIC18F97J60. Con questa scheda, scaricando gratuitamente dal sito Microchip lo stack TCP/IP, è possibile sviluppare un web server attraverso il quale è possibile monito-rare e controllare applicazioni stand-

Codice Descrizione PrezzoPIC12C508-04/P 8-Pin, 8-Bit CMOS Microcontroller 2.90PIC12C508A-04/P 2.00PIC12C672-04/P 8-Pin, 8-Bit CMOS Microcontroller with A/D

Converter and EEPROM Data Memory3.80

PIC12CE674 5.10PIC12F675-I/P 8-Pin FLASH-Based 8-Bit CMOS Micro 2.50PIC16C54-RC/P

EPROM/ROM-Based 8-bit CMOSMicrocontroller

5.00PIC16C54-XT/P 5.00PIC16C558-04/P 6.20PIC16C56A-20/P 5.60PIC16F628-20/P FLASH-Based 8-Bit CMOS

Microcontroller

5.10PIC16F628A-I/P 3.50PIC16F648A-I/P 8.00PIC16F84A-20/P 18-pin Enhanced FLASH/EEPROM 8-bit Micro 7.50PIC16F876A-I/SP 28/40/44-Pin Enhanced Flash Micro 8.00PIC16F877-20/P 28/40-Pin 8-Bit CMOS FLASH Micro 10.00PIC16F877A-I/SP 9.00

PIC18F2550-I/SP28/40/44-Pin High-Performance, Enhanced

Flash USB Microcontroller11.00

PIC18F2620-E/SO28/40/44-Pin Enhanced Flash

Microcontroller with 10-Bit A/D12.50

PIC18F458-I/P28/40-Pin High-Performance, Enhanced Flash Microcontrollers with CAN Module

12.50

PIC18F97J60-I/PF64/80/100-Pin, High-Performance, 1 Mbit

Flash Microcontroller with Ethernet 14.00

RFPIC12F67520-Pin FLASH-Based 8-Bit CMOS

Micro with UHF ASK/FSK Transmitter 6.60

ENC28J60/SPStand-Alone Ethernet Controller with SPI™

Interface9.80

PIC18F97J60-I/PFnew

PIC18F97J60-I/PFNuovissimo microcontrollore della serie 18F con interfaccia Ethernet integrata e memoria FLASH 1Mbit.

PROGRAMMATORE DEBUGGERIN CIRCUIT

PIC18F97J60-I/PFPIC18F97J60-I/PFNuovissimo microcontrollore della serie Nuovissimo microcontrollore della serie

new

Disponibile a stock una vasta gamma di microntrollorie integrati Microchip, compresi i dispositivi più recenti.

ENC28J60/SPnew

€ 93,00,00

PICTAIL SDMMC

Espansione per interfacciare memorie SD e MMC a sistemi di sviluppo dotati di connettore PICtail (es.PICDEMFSUSB).

TAILSDMMC

di sviluppo dotati di connettore PICtail (es.PICDEMFSUSB).

newPROGRAMMATORE USB IN-CIRCUITper dispositivi FLASH MICROCHIP

Maggiori informazioni e schede tecniche dettagliate di tutti i prodotti sono disponibili sul sito www.futurashop.it

dove è possibile effettuare acquisti on-line.

ndiamo a concludere il discorso sui pro-tocolli più diffusi nel mondo delle smart-

card descrivendo sinteticamente il T=0. Si trattadi un protocollo ormai storico visto che risulta ilprimo ad essere stato sottoposto ad uno standardinternazionale (ISO/IEC 7816-3). È stato utiliz-zato per la prima volta in Francia ed ha avuto unenorme diffusione successivamente alla introdu-zione delle SIM-card per cellulari GSM.Vediamo le sue caratteristiche in dettaglio.

Protocollo T=0Questo protocollo nasce per essere il più sempli-ce possibile. È byte-orientedpertanto un byte è la più pic-cola unità informativa scam-biata tra terminale e card.Questo fatto è importanteper capire le differenze nella

modalità di gestione degli errori. In secondoluogo in questo protocollo non esiste una vera epropria differenza tra lo strato application e quel-lo di trasporto, tant'è che le APDU e le TPDUperdono di significato. In letteratura si usa rife-rirsi alle sequenze scambiate con il termineAPDU o direttamente con sequenza di comandoe risposta. Nel prosieguo adotteremo quest'ulti-ma definizione che sembra più consona, ancheconsiderando l'ambiente di sviluppo in cui è natoquesto tipo di protocollo. La struttura di uncomando è costituita da un header e da una partedati, osserviamo il diagramma di Figura 1. Il

Elettronica In - settembre 2006 61

>


SMART CCARD


Proseguiamo il nostro viaggio nel mondo delleSmart Card concludendo l�analisi dei protocollipiù diffusi con la descrizione del T0, uno deipiù conosciuti e diffusi. Quarta puntata.

Cor

so S

MA

RT

CAR

D

A

Corso

SMAR

TCAR

D 4444

Fig. 1

significato di ciascun elemento dovrebbe esservigià familiare con l'unica differenza che in questocaso la lunghezza della parte dati è specificataesclusivamente dal campo P3. CLA è il byte chedefinisce la classe a cui appartiene il comando,INS è l'identificativo specifico del comando, P1e P2 sono due parametri del comando il cui signi-ficato varia, P3 è la lunghezza della parte dati cheseguirà il comando. Il campo dati è la sequenzadati che la card dovrà elaborare ed è lunga esat-tamente un numero di byte pari a P3. In questoprotocollo gli errori vengono rilevati esclusiva-mente in base ad un bit di parità che vieneaggiunto a ciascun byte trasmesso. A differenzadi quanto avviene nel T=1, in questo caso nelmomento in cui si rileva un errore si ha la ritra-smissione immediata dell'ultimo byte anziché diun intero blocco. Il chip della card nel momentoin cui rileva un errore mantiene a livello logicobasso il pin di I/O durante il cosiddetto “guard-time” (come abbiamo già visto è l'intervallo ditempo intercorrente tra una trasmissione e l'al-tra). Questo sistema permette di selezionare esat-tamente quale byte deve essere ritrasmesso.Vediamo in Figura 2 come si presenta una tra-smissione corretta e inseguito cosa accade nelmomento in cui vienerilevato un errore(Figura 3). Il pin di I/Oviene messo a livellologico basso per un inte-ra Etu in maniera daidentificare esattamenteil byte errato. Il termina-le a quel punto non faaltro che ripetere l'ulti-mo byte. Si consideriche questo metodo per-

mette di rilevare esclusiva-mente errori derivanti da unsingolo bit mentre nel casomalaugurato che si verifichi-no errori su due bit chiara-mente la parità non è suffi-ciente. Un altro fattore daconsiderare è che la perditaanche di un solo byte puòcomportare un loop infinitoda parte della card. Essa,infatti, nel momento in cuiriceve il P3, si aspetterà esat-tamente il numero di byte

corrispondente (né uno di più né uno di meno).Se un byte viene perso essa continuerà ad atten-dere. Per evitare tali problematiche sono statiinseriti degli appositi meccanismi di time-out(non previsti dallo standard) che forzano un resetdella card e quindi il riavvio della sessione dicomunicazione. Vediamo di analizzare le diversefasi che caratterizzano il processo di comunica-zione tra terminale e card. In primo luogo la cardriceve una sequenza di intestazione del tipoCLA, INS, P1, P2, P3. Nel caso in cui P3 siadiverso da 0 la card risponde con un ACK corri-spondente al cosiddetto “Procedure Byte” (PBequivalente al byte che identifica il comandoricevuto) ed attende il numero di byte dati preci-sato nel parametro P3. Dopo aver ricevuto l'ulti-mo byte, essa inizia l'elaborazione richiesta. Altermine la card invia una coppia di byte (SW1,SW2) corrispondenti alla risposta e all'eventualeindicazione della presenza di una sequenza datida inviare. Ad esempio, nel caso il terminaleabbia richiesto la lettura del contenuto di unacerta sezione di memoria (READ BINARY), lacard risponderà con un SW2 equivalente alnumero di byte letti e da re-inviare al terminale.

62 settembre 2006 - Elettronica In

Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

Fig. 2

Fig. 3

>


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

Quest'ultimo può richiedere i datiattraverso una nuova sequenzaCLA, INS, P1, P2, P3 corrispon-dente al comando GET RESPON-SE (CLA=61 per lo standardISO/IEC 7861) specificando in P3il numero di byte che vuole riceve-re. La card a quel punto invia lasequenza dati seguita dalla coppiaSW1, SW2. L'intero processo èvisibile nel diagramma a blocchi diFigura 4. Come si vede la sequenzacomando-risposta è piuttosto sem-plice e segue un percorso logicolineare. Se consideriamo che l'erro-re di trasmissione non avvienequasi mai, questo protocollo puòessere visto come il migliore sia alivello di overhead introdotto, siaper il buon transfer-rate in grado diraggiungere. D'altro canto la man-cata differenziazione tra il livello ditrasporto e quello dell'applicazionepossono comportare dei problemisia nel caso di un canale di comuni-cazione non ottimale sia nel caso incui sia necessario implementare deilivelli di sicurezza che coinvolgonola cifratura delle sequenze dati.

Protocolli: passato e futuroLa stragrande maggioranza dellesmart-card attualmente in circola-zione utilizzano il T=0 o il T=1 coneventuali varianti specifiche del-l'applicazione implementata.Tuttavia non sono i soli. Esistonoprotocolli sperimentali che attual-mente hanno una diffusione moltolimitata ma che fanno ben sperareper la sempre maggiore integrazio-ne tra molti sistemi e le smart-carddi ultima generazione. Uno di que-sti è il protocollo USB. Si, avete capito bene, sitratta proprio di quello standard di comunicazio-ne che sta facendo scomparire le porte seriali eparallele dai nostri PC. Esiste un'implementazio-ne che utilizza i due contatti C4 e C8 (non con-nessi nello standard ISO) per le linee D- e D+della porta USB. La card viene riconosciuta dalPC come un dispositivo esterno (HID HumanInterface Device) e permette di sfruttare il trans-

Fig. 4

fer rate tipico sia della modalità low-speed (1,5Mbps) che di quella full-speed (12 Mbps).Esistono già dei prodotti del genere che stannodimostrando la loro potenzialità soprattutto nelcampo della sicurezza delle informazioni.Interessante è ad esempio la Axalto e-gate(http://www.xelios.com/axalto-e-gate.html) unasmart card universale che incorpora sia l'interfac-cia ISO che quella USB. Naturalmente soltanto

fatto un breve cenno su quelle che potranno esse-re le evoluzioni future, entriamo nella parte ope-rativa di questo corso descrivendo l'implementa-zione dei comandi veri e propri. Manterremocome riferimento le ACOS2 distribuite assiemeal kit di sviluppo della ACS Ltd. che tra l'altroutilizzeremo in alcuni nostri nuovi progetti.Innanzitutto bisogna considerare che la comuni-cazione tra terminale e smart-card è sempre ditipo master-slave: il terminale invia i comandi, lacard esegue e risponde. Questi due ruoli riman-gono fissi per tutta la sessione: la card non invie-rà mai dei dati al terminale se non sollecitatadallo stesso. Anche l'ATR rientra in questa logi-


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

uno standard interna-zionalmente ricono-sciuto potrà far decol-lare questo tipo dicard che tra l'altro nonavrebbero bisogno diparticolari lettori vistoche riescono ad inter-facciarsi direttamentecon il PC. L'aziendache produce la e-gatedistribuisce anche deisemplici connettoripassivi che permetto-no di trasformare lacard in una chiave USB da inserire sulla porta delproprio computer (vedi Figura 5). Se da una parteesiste un certo fermento nello sviluppo di nuoviprotocolli ed interfacce, non bisogna dimenticareche altrettanti sistemi sperimentali dopo unaprima diffusione hanno subito una battuta di arre-sto pur avendo gettato le basi per protocolli dive-nuti poi uno standard. Un caso tipico è quello delT=14 sviluppato in Germania alla fine degli anni80 e ritirato nel 2000 dopo la chiusura della reteC-Netz (Funktelefonnetz-C). È stato utilizzato sianel campo della telefonia cellulare che di quellapubblica (vedi in Fig. 6 l’evoluzione cronologicadella rete cellulare in Germania) ma è rimastosempre confinato all'interno di quel paese. Si trat-tava di un protocollo asincrono, block-orientedcon un transfer rate di 9.600bps. La sua defini-zione ha contribuito notevolmente allo sviluppo ealla standardizzazione del T=1 di cui costituiscela base.

SmartCard: i comandiDopo aver analizzato i due protocolli principali e

Fig. 5

Fig. 6

ca visto che si tratta di una risposta al reset.Esistono diverse tipologie di comandi, in partepreviste dallo standard ISO7816, in parte previ-ste da standard specifici nati per regolare lo svi-luppo in particolari campi (EMV2000 carte dicredito, GSM11.11 per le carte dei telefonini), inparte implementate dagli stessi produttori di cardper far fronte a delle applicazioni specifiche.Chiaramente non esiste una smart-card in gradodi eseguire tutti i comandi definiti. Nel momentoin cui si sviluppa un nuovo progetto è necessarioscegliere la tipologia di card sulla base delle fun-zionalità che si intendono implementare. Adesempio, esistono card più indicate per l'utilizzonell'ambito della sicurezza, altre per la registra-zione di informazioni. Abbiamo scelto le ACOS2perché rappresentano un buon compromesso,inglobando funzioni crittografiche che permetto-no un’autenticazione con un buon livello di sicu-rezza e nello stesso tempo contengono una strut-tura informativa sufficientemente ampia adegua-ta a differenti applicazioni. In particolare integra-no un sistema interessante per la gestione dei cre-


>Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

diti permettendo di sviluppare tutti quei sistemi“ricaricabili” ormai entrati a far parte del nostrodominio quotidiano: noleggi DVD, consumazio-ni per bar e discoteche, accessi a stabilimenti bal-neari ecc. Per affrontare l'argomento con chiarez-za dividiamo i comandi della ACOS2 in tre clas-si fondamentali: File Management, Security,Account Management.

File Management e strutturedi memorizzazioneQualsiasi smart-card ha al suo interno uno spaziodi memorizzazione che viene visto dal terminalecome un file-system. Proprio come in un hard-disk esistono file e directory ed è possibile mani-polare tali archivi scrivendo e leggendo deirecord. La ACOS2, in particolare, ha uno spaziodi 8 Kbyte suddiviso in due aree: Internal DataMemory e User Data Memory. La prima contie-ne una serie di campi di configurazione ed è uti-lizzata principalmente dal sistema operativodella card mentre la seconda è a disposizione perla gestione dei dati specifici dell'applicazione.Fate attenzione, l'accesso alle aree di memoria è

(File Identifier) che viene precisato al momentodella sua creazione. Il sistema operativo noneffettua alcun controllo sulla denominazione deifile pertanto è possibile creare due file con lostesso ID ma ciò comporterà sicuramente unmalfunzionamento nell'accesso alle informazio-ni. Anche per le smart-card come nei file systempiù diffusi esiste un meccanismo di controllo diaccesso costituito da due attributi: Read SecurityAttribute, Write Security Attribute. Il primoriguarda l'operazione di lettura e stabilisce se unfile può essere letto liberamente oppure no, men-tre l'altro riguarda l'operazione di scrittura.Ciascun attributo è lungo un byte nel quale ognibit ha una funzione ben precisa. In particolare èanche possibile permettere la lettura/scrittura afronte di determinate condizioni come la trasmis-sione di un pin, un Application Code (AC), unIssuer Code. Vediamo la struttura di ciascun attri-buto in Figura 7. Se il bit corrispondente è valo-rizzato a 1 è necessario durante l'accesso al filefornire alla card il campo relativo espresso inTabella 1. Chiaramente è possibile attivare anchepiù bit contemporaneamente richiedendo quindipiù livelli di controllo. Il sistema operativo dellacard però interpreta le richieste in maniera diffe-rente a seconda della combinazione definita.Nella versione 2 (quella caricata sulle ACOS2)quando si attivano più AC viene fatta un'opera-

piuttosto differente rispettoalle memory-based cardcome le SLE4442. In questeultime si accedeva fisicamen-te alle singole locazioni pre-cisando l'indirizzo nelcomando di lettura. NelleACOS2 come in tutte leMCU-based card l'accesso èdi tipo logico ed avviene leg-gendo i singoli record di cia-scun file. Nelle due aree cipossono essere diversi tipi difile i cui record possono avere lunghezza diffe-rente. C'è un'unica limitazione sulla lunghezzadel file che non può contenere più di 255 recorde, ovviamente, non può superare lo spazio dimemorizzazione. Ciascun record ha un indicenumerico sequenziale (1 byte) che deve essereprecisato durante il comando di lettura/scrittura.Analogamente i record devono avere la medesi-ma lunghezza all'interno dello stesso file.Ciascun file è identificato da un codice di 2 byte

Fig. 7

Tabella 1Nome Bit Descrizione

IC 7per accedere al file il terminale deve fornire il codiceidentificativo del distributore IC (Issuer Code).

PIN 6 per accedere al file il terminale deve fornire il PIN.

ACx 5...1per accedere al file il terminale deve fornire il codice x dell'applicazione (x compreso tra 5 e 1).

AC0 0

questo application code non può essere trasferito pertantofornisce essenzialmente un buon sistema per bloccare l'accesso ad un file (tipicamente in sola lettura). Scrivendol'ultimo record si valorizza a 1 l'AC0 proteggendo il file daulteriori modifiche.

zione di OR logico mentre quando i bit sono rela-tivi al IC e PIN si realizza un'operazione di ANDlogico. Per chiarirvi le idee date un'occhiata allaTabella 2 che presenta alcune possibili configu-razioni. La struttura della “Internal Data Area” èpredefinita e tutti gli attributi assegnati ai vari fileche la compongono è decisa dal sistema operati-vo e non può essere variata. La possibilità dimodificare o meno i record di un file in quest'a-rea dipende principalmente dalla fase di vita

della card. Tutte le MCU-card hanno infatti unciclo di vita suddiviso in 3 fasi fondamentali:Manufacturing Stage, Personalization Stage,User Stage che analizzeremo nel prossimo para-grafo. La struttura dell'area di memorizzazioneinterna di una ACOS2 con i relativi file e attribu-ti è visibile in Tabella 3.

Distributore, Utente) aggiunge delle informazio-ni sulle quali ha delle autorizzazioni esclusive.Via via che ci si avvicina al soggetto più debole(Utente) è necessario fornire più credenziali peraccedere a determinate informazioni, precluden-do in certi casi l'accesso. Nella fase di consegnaall'utente esiste solo un unico livello di sicurezza


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

Tabella 2

IC PIN AC5 AC4 AC3 AC2 AC1 AC0 Descrizione0 0 0 0 0 0 0 0 Accesso al file senza nessuna restrizione

0 0 0 1 0 0 0 0 Accesso condizionato alla trasmissione del AC4

0 0 1 1 1 0 0 0Accesso condizionato alla trasmissione di AC5 OR AC4OR AC3

1 0 0 0 0 0 0 0 Accesso condizionato alla trasmissione del IC

1 1 0 0 0 0 0 0 Accesso condizionato alla trasmissione di IC AND PIN

1 0 0 1 0 0 0 0 Accesso condizionato alla trasmissione di IC AND AC4

0 1 1 1 0 0 0 0Accesso condizionato alla trasmissione di AC5 OR AC4AND PIN

Tabella 3

File IDManufacturing

StagePersonalization

StageUser Stage Num.rec

Lung.rec(byte)

MCU-ID File FF 00 Sola Lettura Sola Lettura Sola Lettura 2 8

ManufacturerFile

FF 01Scrittura condizionatada IC.Lettura senza limiti.

Sola Lettura Sola Lettura 2 8

PersonalizationFile


Scrittura condizionatada IC.Lettura senza limiti.

Sola Lettura 3 4

Security File FF 03Scrittura/Lettura condizionate da IC

Scrittura/Lettura condizionate da IC

Scrittura condi-zionata da IC.Lettura non permessa.

12 8

User FileManagementFile

FF 04 Scrittura condizionatada IC.Lettura senza limiti.


Scrittura condi-zionata da IC.Lettura senzalimiti.

N_OF_FILE 6

Account File FF 05Scrittura condizionatada IC.Lettura senza limiti.


Scrittura/Lettura condizionate daIC.

8 4

Account Security File



Scrittura condi-zionata da IC.Lettura non permessa.

4 8

Come si vede l'ID dei file utilizzati formalmentedal sistema operativo ha sempre il primo byte aFFh valore non permesso per i file utente. Insecondo luogo gli attributi di accesso sono pre-definiti e sotto il completo controllo del sistemaoperativo che in alcuni casi non permette la let-tura dei dati ma soltanto la loro modifica. Comesi vede chiaramente le restrizioni di accessoaumentano via via che ci avviciniamo alla conse-gna all'utente. Si faccia attenzione che le tran-sizioni nelle diverse fasi del ciclo di vita di unaMCU-based card sono irreversibili. In pratica adogni passaggio un soggetto (Produttore,

per alcuni file necessari all'utilizzo che è la cono-scenza del IC (Issuer Code). Ad ogni transizioneviene settato un bit ben preciso che rende irre-versibile il passaggio e l'applicazione dei diversiattributi di accesso. Vediamo nel concreto comequesto avviene.

Ciclo di vita ACOS2La prima fase da considerare è immediatamentesuccessiva alla fabbricazione del chip inclusonella card. Durante il “Manufacturing Stage”vengono modificate una serie di informazioniall'interno del Manufacturer File (FF 01) e viene

precisato il codice IC che sarà necessario per leoperazioni di lettura/scrittura nella prossimafase. Per le ACOS2 tale fase viene completamen-te gestita dalla ACS Ltd. prima della distribuzio-ne delle card. Pertanto, noi possiamo interveniresolo successivamente nel cosiddettoPersonalization Stage. Se guardate bene la tabel-la precedente vi accorgerete che le informazioniinserite nel Manufacturer File sono di esclusivodominio della ACS visto che nelle fasi successi-ve il file diventa di sola lettura. Esse riguardanofondamentalmente dati identificativi della cardcome il “Card Manufacturer ID” o il numeroseriale. Dopo la scrittura di tali informazioniviene messo a 1 il bit più significativo del primorecord del Manufacturer File. Questa scritturaporta la card irreversibilmente alla fase successi-va. Le informazioni scritte possono essere lettema non modificate. Nella seconda fase detta“Personalization Stage” vengono modificati tuttiquei campi necessari a predisporre la card all'uti-lizzo che ne farà l'utente. Nei nostri progettidovremo considerare questa fase come quellasuccessiva all'analisi del problema che intendia-mo risolvere. In questa fase si decidono partiquali le chiavi di cifratura, la struttura dei file checonterranno i dati, i codici d'accesso dell'applica-zione (AC), gli Historical Byte trasferiti durantel'ATR, ecc. In pratica si fa in modo di prepararela base informativa e funzionale che dovrà servi-


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

>

re a far “girare” la nostra applicazione. Al termi-ne viene settato un bit denominato“Personalization Bit” che rende alcune di questeinformazioni di sola lettura condizionando l'ac-cesso ad altri campi alla trasmissione dell'IC pre-cisato nel “Manufacturing Stage”. Entriamo cosìnell'ultima fase denominata “User Stage”. Essacorrisponde all'utilizzo “normale” della card daparte dell'utente. Chiaramente le operazioni chevengono fatte dipendono dal tipo di applicazioneche viene eseguita. In questa fase si distingue unsotto livello denominato “Issuer Mode”. La cardentra in questa modalità quando il terminale tra-smette l'IC corretto alla card durante un'opera-zione di lettura/scrittura. In questo caso il siste-ma operativo riconosce il terminale come unasorta di super-user che ha quindi un accesso piùvasto alla memoria della card. Ad esempio sedurante l'utilizzo normale non è possibile scrive-re nel Security File che contiene il PIN e la cop-pia di chiavi di cifratura. Tale operazione vienepermessa se il terminale presenta alla card l'ICcorretto. In quel caso essa entra in questo sotto-livello dove alcune operazioni normalmente vie-tate risultano permesse. È chiaro che sarà l'appli-cazione lato terminale a dover gestire la sicurez-za con cui viene dato all'utente l'accesso a questafase. Normalmente si dà all'utente la possibilitàdi effettuare una serie di operazioni cosiddettestandard relegando a casi eccezionali quelle che

Fig. 8

card. Risultano essere in sola lettura sia durante lafase di personalizzazione che durante quella diconsegna all'utente. Normalmente, quindi noi nonabbiamo alcun controllo su tali informazioni senon la possibilità di leggerle liberamente. Quelloche è interessante considerare è il primo record diquesto file. Ecco come si presenta la sua struttura(vedi Figura 9). I tre bit più significativi sonopiuttosto importanti. Il primo è il bit che stabili-sce il passaggio dal “Manufacturing Stage” al“Personalization Stage”. Nel momento in cuiviene posto ad 1 e il sistema operativo viene riav-viato (Reset) non è più possibile tornare indietro.Il secondo bit stabilisce un aspetto di sicurezza diun comando che vedremo più avanti (ComandiClasse Security) e denominato “INQUIRYACCOUNT” (serve a stabilire il credito rimanen-te sulla card). Questo flag comanda il numero dibyte sui quali si calcolerà il “MAC crypthogra-phic checksum”. Per il momento prendete perbuona questa definizione. Ne parleremo quandoaffronteremo le funzioni crittografiche di questotipo di card. L'ultimo bit stabilisce la modalità dinumerazione dell'indice sequenziale che identifi-ca i record di ciascun file. Se questo flag è ad 1 irecord vengono numerati da 1 a N (con N ilnumero di record del file) mentre se è pari a 0 lasequenza parte da 0 e termina a N-1. Questi flagvengono valorizzati dalla ACS prima di distribui-re le card pertanto non possono essere variati.

smart-card necessaria per comprendere benecome viene regolato l'accesso ai file inseriti nellacard, torniamo alla struttura dell'area di memoriainterna riservata al sistema operativo. Vediamo ilsignificato dei file contenuti nella “Internal DataArea”.MCU ID File: Contiene informazioni inseritedurante il processo di fabbricazione del chip. Irecord sono di sola lettura in tutte le fasi di vitadella card.Manufacturer File: contiene informazioni inse-rite dalla ACS prima della distribuzione della


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

coinvolgono più livelli di sicurezza. Si pensi adesempio alla modifica del pin su una SIM GSM.Si tratta di un'operazione standard a cui risultanoautorizzati tutti gliutenti che conosco-no il vecchio pin.Nel momento in cuila card si blocca acausa dell'inseri-mento errato del pinper tre volte conse-cutive si entra in unafase non standardche prevede un ulte-riore livello di sicurezza cioè la conoscenza delPUK. Analogamente nelle nostre applicazionil'operazione di gestione del credito registrato inuna card a scalare deve essere considerato unevento a più alto livello di sicurezza rispetto aquello della gestione dei dati identificativi dell'u-tente. Le varie transizioni possono essere rias-sunte nel diagramma di Figura 8. Si faccia attenzione che soltanto all'interno del“User Stage” sono possibili dei cambiamentireversibili condizionati dalla conoscenza del “ICCode”. Le altre due transizioni vanno in un'unicadirezione. Su questo fatto c'è da registrare una piccola evo-luzione tra la prima release del sistema operativoACS e quella attualmente inserita sulle ACOS2(mentre scriviamo l'azienda ha rilasciato laACOS5). Agli inizi, infatti, era possibile passare dal “UserStage” al “Personalization Stage” cancellandotutte le modifiche effettuate prima della conse-gna della card all'utente. L'operazione in questio-ne veniva detta “CLEAR CARD” e permettevadi cancellare la EEPROM conservando esclusi-vamente i dati relativi al “Manufacturing Stage”. È chiaro che per ragioni sperimentali la cosapoteva essere apprezzata, ma in un ambiente diproduzione questo diventava inaccettabilesoprattutto nell'ambito della sicurezza. Dopoquesta breve digressione sulle fasi di vita della

Fig. 10

Fig. 9

una transazione di addebito riportando il creditoal valore precedente. Se è pari a 0 la card nonpermetterà tale operazione rifiutando il comandodel terminale come operazione non ammessa.DEB_PIN: determina se è necessaria o meno latrasmissione corretta del pin in una transazionedi addebito. Se è pari a 1 soltanto dopo aver digi-tato correttamente il pin sarà possibile addebita-re la somma corrispondente.DEB_MAC: stabilisce se una transazione diaddebito deve essere validata attraverso il calco-lo del MAC. Vedremo che quest'ultimo può esse-re considerato come una specie di certificato peri dati che vengono trasmessi. Se è pari a 1 la cardeffettua un controllo sui dati che vengono trasfe-riti durante la transazione sulla base del check-sum crittografico allegato.PIN_ALT: se è pari a 1 il PIN può essere modi-ficato attraverso un'operazione CHANGE PINpertanto il livello di sicurezza richiesto è soltan-to relativo alla conoscenza del vecchio PIN.3-DES: se è pari a 1 l'algoritmo crittografico uti-lizzato è il 3-DES mentre se è 0 si utilizza il piùsemplice DES.ACCOUNT: stabilisce se la memoria della carddeve contenere le strutture necessarie a gestire leoperazioni di accredito e di addebito. In pratica sidefinisce se la card verrà utilizzata come un dis-positivo ricaricabile oppure no. Se è pari a 0 larelativa area di memoria che normalmente risul-ta preposta a questo utilizzo viene aggiunta aquella a disposizione dei file utente. Questo flagrisulta decisivo nella scelta del tipo di applica-zione che si vuole realizzare. Nel caso in cuirisulti più importante gestire delle informazionirelative all'utente si farà in modo di sacrificare learee di memoria per l'accounting. D'altro cantoladdove si realizzano applicazioni in cui l'accre-dito e l'addebito sono operazioni preponderanti èchiaro che tale flag verrà messo ad 1 lasciando


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

Personalization File: questo file, costituito da 3record lunghi 4 byte, permette una serie di modi-fiche fondamentali per dimensionare la cardrispetto all'applicazione che si vuole realizzare.Tali modifiche vengono effettuate durante il“Personalization Stage”. Dopo aver settato il“Personalization bit” (bit più significativo delquarto byte del primo record) ed aver riavviato ilsistema operativo (reset) esse divengono definiti-ve tant'è che il file per l'utente è di sola lettura. LaFigura 10 rappresenta la struttura complessiva diquesto file.Il primo record riveste una grande importanzaper la quantità di possibili configurazioni effet-tuabili. Analizziamo nel dettaglio ciascun byte.

OPTION REGISTEREsso contiene una serie di bit (vedi Fig. 11) chepossono influire in maniera significativa sul fun-zionamento della card soprattutto per quantoriguarda il livello di sicurezza utilizzato nellagestione dell'account.INQ_AUT: riguarda sempre l'operazioneINQUIRY ACCOUNT. Se è pari ad 1 tale opera-zione può avvenire soltanto dopo un'autenticazio-ne reciproca di terminale e card. Il MAC in risposta a questa operazione viene cal-colato e cifrato in DES utilizzando l'attuale chia-ve di sessione.TRNS_AUT: questo bit è simile al precedentema non riguarda l'operazione di INQUIRY bensìle transazioni di accredito e addebito. Anche inquesto caso se è pari ad 1 tali transazioni avven-gono soltanto dopo un'autenticazione reciprocadi terminale e card. Il MAC in risposta viene calcolato e cifrato inDES utilizzando l'attuale chiave di sessione.REV_DEB: stabilisce se la card eseguirà o scar-terà l'operazione di REVOKE DEBIT. Talecomando permette ad un terminale di annullare

Fig. 11

Fig. 12

>


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

magari la gestione delle informazioni associateall'utente al software.

SECURITY OPTION REGISTERÈ costituito da 7 bit (vedi Fig. 12) ognuno deiquali stabilisce se un determinato campo essen-ziale per la sicurezza delle transazioni (APPLI-CATION CODE, PIN, IC) deve essere trasmessoin chiaro oppure deve essere cifrato utilizzandol'attuale chiave di sessione durante l'operazionedi SUBMIT CODE. Il bit a 0 forza la trasmissio-ne del relativo campo in chiaro. Per ovvi motividi sicurezza è bene che nel rilascio all'utente ilcodice IC sia sempre trasmesso in maniera cifra-ta. Esso, infatti, rappresenta il livello base disicurezza per le operazioni che abbiamo definitocome non-standard. Nel caso in cui si metta a 1il PIN_DES si forza la trasmissione cifrata delPIN anche durante l'operazione CHANGE PINche ricordiamo deve essere abilitata attraverso ilbit relativo dell' OPTION REGISTER.

N_OF_FILE

Questo byte stabilisce il numero di file utente allo-cati nella “User Data Memory”: il sistema opera-tivo delle ACOS2 considera soltanto i 5 bit menosignificativi pertanto il massimo numero di filepossibile è pari a 31. Per terminare, il bit più signi-ficativo del quarto byte costituisce il“Personalization bit”. Dopo averlo messo a 1 edaver riavviato il tutto la fase di personalizzazionetermina e si entra in quella di consegna all'utente“User Stage”. I primi 8 byte del PersonalizationFile vengono trasferiti all'interno degli HistoricalCharacter durante l'ATR. Analizzeremo nel pro-sieguo il dettaglio di tutti gli elementi che com-pongono la prima fase di avvio di una ACOS2. Peril momento il nostro spazio termina qui. Stiamoentrando in profondità nelle varie strutture checompongono lo spazio di memorizzazione delleACOS2. Tali informazioni risultano essere essen-ziali per il dimensionamento del progetto da rea-lizzare. Un errore nella fase di personalizzazionepuò essere un grave handicap per il sistema com-plessivo soprattutto quando lo si deve inserire inun ambito dove il livello di sicurezza seppur noneccezionale può essere un parametro critico. Nonperdetevi quindi la prossima puntata nella qualetermineremo di analizzare la struttura dei file pre-senti nell'area di memorizzazione interna, passere-mo a quella a disposizione dell'utente e quindi allereali sequenze necessarie a manipolare i dati.

Elettronica In - ottobre 2006 57

>


SMART CCARD

a cura di Fabio Riscica

Proseguiamo il nostro viaggio nel mondo delleSmart Card concludendo la descrizione dellastruttura della smartcard ACOS2 con particolareriferimento alla gestione dell�account ed airelativi meccanismi di sicurezza. Quinta puntata.

Cor

so S

MA

RT

CAR

D

5555n questa puntata concludiamo la descrizio-ne della struttura della smartcard ACOS2,

facendo riferimento in particolare alla gestionedell'account ed ai relativi meccanismi di sicurezza.Continuando il discorso del numero scorso, com-pletiamo l'esame in dettaglio dell'area di memoriz-zazione interna.

SecurSecurity Fity FileileIl Security File (ID FF03H) memorizza le seguen-ti informazioni:

• la coppia di chiavi utilizzata per la mutuaautentificazione fra carta e terminale;

• i cinque Application Codes (AC1 .. AC5) uti-lizzati per il controllo dell'accesso ai files;

• l'Issuer Code (IC);• il PIN;• i contatori di errore che hanno la funzione di

limitare il numero di verifiche errate delle pre-

cedenti chiavi (se uno di questi contatori rag-giunge il valore 8, la corrispondente chiave èbloccata in modo irreversibile);

• il seme utilizzato per la generazione dei nume-ri random durante il processo di mutua autenti-ficazione.

Ricordiamo che il Security File può essere lettosoltanto durante la fase di Manufacturing ePersonalization dietro presentazione dell'IssuerCode; la lettura di tale file non è più possibile nelloUser Stage. La scrittura è invece sempre possibile dietro pre-sentazione dell'IC (cioè nell'Issuer Mode).Il Security File comprende 14 records di 8 bytesciascuno ed è organizzato come mostrato inFigura 1.I record 11 e 12 memorizzano i contatori di erroredelle chiavi e la relativa copia di backup, mantenu-

I

Corso

SMAR

TCAR

D

ta per sicurezza nel caso in cuisi verificasse una perdita di ali-mentazione o un reset durantel'aggiornamento di questi valo-ri. Si faccia attenzione al fattoche la scrittura di un valoreerrato in questi record può bloccare in modo irre-versibile la carta e renderla inutilizzabile; i conta-tori di errore vengono infatti gestiti dal sistemaoperativo della ACOS2 e non risulta necessarioforzarne manualmente il valore (ogni contatore siazzera automaticamente nel momento in cui vienepresentato il relativo codice corretto). I record 13 e14, presenti soltanto nella versione 3.0 della carta,memorizzano i bytes meno significativi delle chia-vi di autentificazione 3-DES (se è selezionata l'op-zione di DES semplice, questi record non sono uti-lizzati).

User FUser File Manaile Managgement Fement FileileLo User File Management File (ID FF04H) ha lafunzione di specificare la struttura e la modalità diaccesso degli User Data Files. Quest'ultimo è costi-tuito da N_OF_FILE record di 6 bytes ciascuno ememorizza in ciascuno di questi il File DefinitionBlock per ogni User Data File allocato (abbiamogià descritto nello scorso numero il meccanismo diaccesso ai file utente ed il parametro N_OF_FILE,

definito nel PersonalizationFile, che specifica il numero difile di dati utente allocati nellasmartcard).Come già accennato nel nume-ro scorso, i record dello UserFile Management File possonoessere liberamente letti e scritti(quest' ultima operazione deveessere preceduta dalla presenta-zione dell'IC) in ogni fase delciclo di vita della carta, inclusolo User Stage. Ovviamente ilnumero di record è fissato dalparametro N_OF_FILE defini-to in fase di personalizzazione.La sequenza in cui i FileDefinition Blocks sono allocatinello User File ManagementFile è irrilevante; nel momentoin cui un file viene selezionato,il sistema operativo della cartascandisce i record alla ricercadell'identificativo del file a cui

58 ottobre 2006 - Elettronica In

Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

Fig. 1

Fig. 2

si fa riferimento. Per questo motivo il sistema ope-rativo non è in grado di verificare la consistenza deiFile Definition Blocks ed errori in questa strutturapossono causare il malfunzionamento della carta.In Figura 2 vediamo il File Definition Block, costi-tuito da 6 bytes, che comprendono, per ciascunfile, l'identificatore, il numero di record, la lun-ghezza di ogni record e gli attribuiti di lettura escrittura (il cui utilizzo è stato descritto nel prece-dente numero). La procedura da seguire per l'allo-cazione degli User Data Files consiste quindi neldefinire il parametro N_OF_FILE nelPersonalization File e quindi i File DefinitionBlocks nello User File Management File. Dopoqueste operazioni gli User Data Files possonoessere letti e scritti, con le condizioni di accessodefinite.

Account FAccount FileileL'Account File (ID FF05H) contiene l'AccountData Structure, che consente di utilizzare la smart-card come un borsellino elettronico. Bisogna

>


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

innanzitutto osservare che, nello User Stage, i datiall'interno dell'Account File non possono esseremanipolati con le istruzioni di gestione dei files,ma sono disponibili soltanto alcuni particolaricomandi che consentono di incrementare o decre-mentare il credito in modoestremamente sicuro,come vedremo più avanti.L'Account Data Structurenell'Account File è costi-tuita da 8 record di 4 bytesciascuno e presenta lastruttura descritta in Figura3. Il primo byte del primorecord prende il nome diTRANSTYPE e memoriz-za il tipo di transazioneassociata al bilancio cor-rente della carta. I tipi ditransazione possibili sullacarta sono tre: CREDIT(incremento del bilanciosecondo un valore fissato)è specificato dal valore03H, DEBIT (decrementodel bilancio secondo un valore fissato) è specifica-to dal valore 01H, REVOKE DEBIT (annullamen-to dell'ultima operazione DEBIT) è specificato dalvalore 02H. Il secondo, terzo e quarto byte delprimo record costituiscono il bilancio correntedella carta (BALANCE). Si tratta di un numerointero positivo di 24 bit; il massimo valore che puòessere rappresentato è quindi 224-1=16777215.Il primo e secondo byte del secondo record forni-scono l'Account Transaction Counter (ATC). Sitratta di un contatore che viene incrementato dopoogni transazione, in modo che possa essere gene-rata una firma univoca per ogni transazione. L'ATCè utilizzato insieme all'Account Identification(AID) per generare l'Account Transaction referen-ce (ATREF) che permette di calcolare il DEScipher-block chained checksum (MAC).Quest'ultimo permette di certificare i comandi rela-tivi all'Account. Quando l'ATC raggiunge il suovalore massimo (FFFFH), il sistema operativodella carta non permette più l'esecuzione di alcuna

carta ed ha la funzione di verificare la consistenzadei dati presenti sulla carta. Se il checksum è erra-to, la carta permette l'esecuzione delle transazionisoltanto nell'Issuer Mode, cioè dopo l'inserimentodell'IC. Il terzo e quarto record rappresentano unbackup dei primi due record, anche qui mantenutiper sicurezza nel caso avvenga una mancanza dialimentazione o un reset durante la transazione. Ilvalore maggiore fra i due ATC permette di ricono-scere la transazione più recente. I primi tre bytesdel quinto record (MAXBAL) hanno la funzionedi limitare l'importo contenuto nella carta. Questovalore viene verificato dal sistema operativo primadi ogni comando CREDIT; se la somma del bilan-cio corrente e del credito eccede MAXBAL, lacarta rifiuta il comando CREDIT. I quattro bytesdel sesto record prendono il nome di AccountIdentification (AID) e sono combinati con l'ATCper ottenere i sei bytes ATREF, il cui utilizzo è giàstato accennato in precedenza. L'AID è scrittodurante la fase di personalizzazione e non è modi-

ficabile (vedi Figura4).I quattro bytes del set-timo record costitui-scono il TerminalTransaction CreditReference (TTREF-

transazione. Il terzo byte del secondo record(CHKSUM) fornisce il byte meno significativo delchecksum ottenuto sommando i bytesTRANSTYP, BALANCE ed ATC, più uno.Questo dato è gestito dal sistema operativo della

Fig. 3

Fig. 4

da inviare alla carta; la CER-TIFY KEY, utilizzata dallacarta per generare il MAC con-tenuto nella risposta delcomando INQUIREACCOUNT da inviare al ter-minale (interrogazione dellostato dell'account), la REVO-KE DEBIT KEY, utilizzata dalterminale nel calcolo del MACper costruire il comandoREVOKE DEBIT da inviare

alla carta (Figura 5). Nel caso in cui invece sia stataabilitata la crittografia 3-DES, l'Account SecurityFile è costituito da 8 record di 8 bytes ciascuno, inquanto in questo caso le chiavi sono ciascuna di 16bytes di lunghezza.

USER DATA FILES E MODALITA' DIACCESSO AI DATIIniziamo adesso ad esaminare più attentamente lastruttura dell'area dei files dati utente, la User DataFiles. Quest'area viene allocata nella fase di perso-nalizzazione della carta; i dati memorizzati posso-no essere letti e scritti con i comandi READRECORD e WRITE RECORD, a patto che le con-dizione d'accesso specificate nei bytes 3 e 4 delloUser File Definition Block siano soddisfatte. Dopola fase di personalizzazione, in cui vengono scrittii records dello User File Managements File, non èpiù possibile modificare il numero di record di unData File se questo è stato utilizzato almeno unavolta. Infatti, una volta allocato lo spazio di memo-ria, lo stesso non può essere più liberato anche se ifiles di dati non sono più utilizzati.Ogni User Data File può contenere al più 255record con un massimo di 32 bytes ciascuno. Lospazio di memoria complessivamente disponibileper l'area utente è teoricamente di 8 KBytes, mabisogna considerare che una parte di questa vieneutilizzata dal sistema operativo. Ad esempio, senella carta è implementata l'Account DataStructure, bisogna tener conto del fatto che sono


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

C), dato fornito dal Card Accepting Device, cioèdal terminale esterno, quando è eseguita una trans-azione di tipo CREDIT. Questo dato non vieneinterpretato dal sistema operativo dalla carta mapuò essere letto ed utilizzato dal terminale, adesempio, per rifiutare una carta che è stata accredi-tata da un terminale non autorizzato.Infine, i quattro bytes dell'ottavo record costitui-scono il Terminal Transaction Debit Reference(TTREF-D), dato anch'esso fornito dal CardAccepting Device quando è eseguita una trans-azione DEBIT od una REVOKE DEBIT. Si osser-vi che il comando REVOKE DEBIT può essereeseguito soltanto se il TTREF-D fornito con ilcomando è identico a quello memorizzato. Ciògarantisce che il terminale che richiede il REVO-KE DEBIT è lo stesso che ha eseguito il preceden-te DEBIT.

Account SecurAccount Security Fity FileileL'Account Security File (ID FF06H) contiene lechiavi di codifica usate nel calcolo del MACdurante le operazioni relative alla gestionedell'Account. Nel caso in cui sia stata abilitata lacrittografia 1-DES, l'Account Security File è costi-tuito da 4 record di 8 bytes ciascuno e contiene lequattro chiavi di 8 bytes utilizzate: la DEBIT KEY,utilizzata dal terminale nel calcolo del MAC percostruire il comando DEBIT da inviare alla carta;la CREDIT KEY, utilizzata dal terminale nel cal-colo del MAC per costruire il comando CREDIT

Fig. 5

Size

Account DataStructure

not available(ACCOUNT = 0)

Account Data Structureavailable with 1-DES (3-

DES=0 and ACCOUNT = 1)

Account Data Structureavailable with 3-DES

(3DES=1 andACCOUNT=1)

No of Files even 7964 - N*6 7900 - N*6 7868 - N*6

No of Files odd 7962 - N*6 7898 - N*6 7866 - N*6

Tabella 1


>Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

riservati a questa 64 bytes (nel casoin cui l'Account Data Structure uti-lizzi il DES semplice) o 96 bytes(nel caso di 3-DES). Bisogna pre-stare attenzione a non allocarememoria per i files utente oltre laquantità disponibile: il sistemaoperativo non effettua alcun con-trollo sul superamento di tale limi-te e quindi, in tal caso, potrebberoverificarsi inaspettati malfunziona-

menti della carta. La Tabella 1 permette di calcola-re in modo preciso la quantità di memoria disponi-bile per gli User Data Files. Si osservi che permotivi legati all'architettura della carta ACOS2, ifiles dati utente occupano uno spazio di memoriasempre multiplo di 4 bytes. Passiamo adesso adescrivere il meccanismo diaccesso ai files dati, che èperaltro identico sia per gliUser Data Files che per gliInternal Data Files (ad ecce-zione, in modalità User,dell'Account File).La prima azione che deveessere necessariamente ese-guita per l'accesso ad un gene-rico file dati è la selezionemediante il comando SELECTFILE. Dopo l'esecuzione diquesto comando, il file specificato (se esistente)sarà selezionato e l'eventuale file correntementeselezionato sarà chiuso. Se l'identificativo del filespecificato dal comando è inesistente, la carta resti-tuisce un codice di errore ed il file correntementeselezionato non cambia. Si osservi che non ènecessario specificare le condizioni di accesso alfile durante l'esecuzione di questo comando.Inoltre, dopo un reset della carta, non risulta sele-

zionato alcun file. LaFigura 6 riassume l'esecuzione del comandoSELECT FILE. Il termina-le deve specificare l'identi-ficativo del file da selezio-nare; la carta restituisce lostatus code che segnala seil comando è andato a buonfine. Dopo aver selezionatoil file è possibile eseguire leoperazioni di lettura e scrit-tura dei record dello stesso.

Il comando di lettura è READ RECORD e, se lecondizioni di accesso relative al file non sono statesoddisfatte prima dell'esecuzione del comando,quest'ultimo viene rifiutato dalla carta. Ognicomando permette di leggere soltanto un recorddel file selezionato; il numero di bytes da leggere è

Fig. 6

Fig. 7

Fig. 8

specificato nel comando stesso (ovviamente ilmassimo numero di bytes che può essere letto èpari alla lunghezza del record).La Figura 7 riassume l'esecuzione del comandoREAD RECORD. Il terminale deve specificarel'indice del record (l'indice del primo record è spe-cificato dal bit RECORD_NUMBERING delManufacturer File ed è generalmente pari a 0) ed ilnumero di bytes da leggere (al più 32); la carta

Quando la mutua autentificazione è abilitatamediante il bit TRNS_AUT, ogni transazione sul-l'account, affinché vada a buon fine, deve esserepreceduta da questa operazione; analogamente, seè abilitata mediante il bit INQ_AUT, lo stato del-l'account può essere interrogato soltanto dopo chela mutua autentificazione è stata effettuata.Vediamo di riassumere nella figura sottostante ilmeccanismo della mutua autentificazione. Il termi-nale inizia inviando alla carta il comando STARTSESSION, che comunica alla stessa di voler ini-ziare il processo di mutua autentificazione. Lacarta risponde generando ed inviando un numerorandom di 8 bytes necessario per continuare l'ope-

razione, seguito dallostatus code. A questopunto il terminalecrittografa il numerorandom ricevuto dallacarta utilizzando laTerminal Key, generaanch'esso un secondonumero random edinvia questi due datialla carta nel corpodel comandoAUTHENTICATE.La carta verificainnanzitutto se il datoinviato dal terminaleè corretto, quindigenera una nuovachiave, la SessionKey (calcolata in base

restituisce i bytes richiestiseguiti dallo status code.Analogamente a quantovisto per la lettura è possibi-le scrivere i bytes di unrecord tramite il comandoWRITE RECORD. Dopoaver selezionato il file everificato le condizioni diaccesso, è possibile scrivereun record come mostrato infigura. Il terminale devespecificare l'indice delrecord ed i bytes da scrive-re; la carta restituisce lo sta-tus code (Figura 8).

SICUREZZA E TRANSAZIONI SULL'ACCOUNTPassiamo adesso ad esaminare tutti i meccanismidi sicurezza messi a disposizione dal sistema ope-rativo della carta ACOS2.

Mutua autentifMutua autentificazioneicazioneIl primo meccanismo che può essere abilitato(mediante i bit TRNS_AUT e INQ_AUTdell'Option Register) è quello della mutua autenti-ficazione fra Card Accepting Device (terminale) ecarta e si basa sullo scambio e verifica delle chiaviin modo sicuro (cioè non in chiaro ma crittografa-te secondo l'algoritmo DES o 3-DES, secondol'opzione selezionata nell'Option Register).


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

Fig. 9

Fig. 10

azzerato (se non bloccato) non appena il comandodi AUTHENTICATE va a buon fine.

VVererififica e modifica e modifica delle cica delle chiahiaviviAbbiamo già parlato delle chiavi della carta, chehanno la funzione di limitare l'accesso ai dati edalle operazioni che possono essere eseguite. Nellacarta ACOS2 possono essere memorizzati cinqueApplication Codes (AC1, AC2, AC3, AC4, AC5),un Issuer Code (IC) ed un PIN Code (PIN).L'Issuer Code è la chiave di amministrazione dellacarta e consente di eseguire delle operazioni privi-legiate; le altre chiavi vengono generalmente uti-lizzate per limitare l'accesso ai files dati (inoltre sul

PIN può essere eseguito un particola-re comando di modifica di cui parle-remo fra poco). La verifica delle chiavi può essereeseguita in chiaro od in modalità crit-tografata, in base al valore dei bit delSecurity Option Register. Il coman-do che permette di verificare le chia-vi è SUBMIT CODE e viene sche-matizzato nelle immagini di Figura10. Il terminale deve specificare l'in-dice della chiave da verificare ed il

valore di 8 bytes,eventualmentecrittografato conla Session Key;la carta dopoaver effettuato laverifica rispondecon lo status

al valore dei duenumeri random,della Terminal Key edella Card Key), concui crittografa ilnumero randominviatogli dal termi-nale. Questo datoviene inviato inrisposta al comandoAUTHENTICATE,seguito al solitodallo status code.Infine il terminale,che ha calcolatoanch'esso la Session Key, verifica larisposta inviatagli dalla carta conclu-dendo la mutua autentificazione(vedi Figura 9). Il risultato finaledella mutua autentificazione è la generazione dellaSession Key, che verrà utilizzata dalla carta percrittografare e decrittografare i dati nel corso dellastessa sessione. La mutua autentificazione fra cartae terminale deve essere completata nell'ordine spe-cificato; se nel corso della mutua autentificazioneviene inviato alla carta un comando differente daquello aspettato, questa viene interrotta e deveessere nuovamente eseguita dall'inizio con ilcomando START SESSION. Se il comando diAUTHENTICATE non invia alla carta il dato cor-rettamente crittografato, il contatore della TerminalKey viene incrementato (se viene raggiunto il valo-re 8 il comando AUTHENTICATE non potrà esse-


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

>

Fig. 11

Fig. 12

re più eseguito dalla carta, cherisulterà inutilizzabile). Il conta-tore della Terminal Key viene

cesso di mutua autentificazione.Anche in questo caso il dato puòessere inviato in chiaro o critto-grafato, in base al valore del bitPIN_DES del Security OptionRegister. Le immagini di Figura11 schematizzano l'esecuzionedel comando CHANGE PIN. Ilterminale deve specificare ilvalore del nuovo PIN, eventual-mente crittografato con laSession Key; la carta memoriz-za questo valore e risponde conlo status code.

TTrransizioni sull’accountansizioni sull’accountQuattro chiavi, memorizzatenell'Account Security File,sono associate alla gestionedell'Account: la Credit Key, laDebit Key, la Certify Key, laRevoke Debit Key. Questechiavi sono utilizzate nel cal-colo e nella verifica del MAC(checksum crittografico), neicomandi relativi alla gestionedell'Account. Ad eccezionedella Certify Key, ad ogni chia-ve è associato un contatore dierrore che limita il numero di

esecuzioni senza successo dei comandi relativialle transazioni. Sull'Account Data Structure


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

code. Gli indici da 1 a 5 identificano i rispettiviApplication Codes, il 6 è relativo al PIN ed il 7identifica l'Issuer Code.Ricordiamo che la carta memo-rizza un contatore per ogni chiavee limita ad otto il numero di ese-cuzioni senza successo delcomando SUBMIT CODE.Anche per questi contatori valgo-no le stesse regole viste in prece-denza per quello della TerminalKey. Le chiavi possono esseremodificate dopo la presentazionedell'Issuer Code con il comandoWRITE RECORD. Se il bitPIN_ALT nell'Option Register èsettato, il PIN può invece esseremodificato con il comandoCHANGE PIN. Per motivi disicurezza questo comando puòessere eseguito soltanto dopo cheil vecchio PIN è stato verificatoed immediatamente dopo il pro-

Fig. 14

Fig. 13

Tabella 2DEB_MAC DEB_PIN Livello di Sicurezza

0 0Nessuno; il comando DEBIT può esseresempre eseguito.

0 1Il comando deve essere preceduto dallaverifica del PIN.

1 0Il calcolo del MAC è richiesto e verrà verificato dalla carta.

1 1Il comando deve essere preceduto dal PINed il calcolo del MAC è richiesto.

possono essere eseguite quattro differenti tipi ditransazione:

• INQUIRE ACCOUNT;• DEBIT;• REVOKE DEBIT;• CREDIT.

Nella transazione di tipo INQUIRE ACCOUNT lacarta restituisce il valore del bilancio correnteseguito da altre informazioni sull'account e dalMAC calcolato sui dati precedenti, che può essereconsiderato dal terminale come un certificato diautenticità fornito dalla carta. Si ricordi che, se il bitINQ_AUT è settato, il comando INQUIREACCOUNT deve essere preceduto dal processo dimutua autentificazione. I disegni di Figura 12 sche-matizzano l'esecuzione del comando INQUIREACCOUNT. Il terminale deve specificare la chiaveche la carta utilizzerà per il calcolo del MAC ed unvalore di quattro bytes chia-mato Reference, che condi-ziona il valore del datorestituito; la carta restituiscele informazioni sull'accounted il MAC (eventualmentecrittografato con la SessionKey se INQ_AUT=1)seguito dallo status code.Nella transazione di tipoDEBIT, il bilanciodell'Account è decrementa-to dell'importo specificato.Il massimo importo che può

essere addebitato è ovviamente parial valore del bilancio corrente (nonsono ammessi valori negativi). Aseconda del valore assunto dai bitDEB_MAC e DEB_PIN dell'OptionRegister, possono essere specificatidiversi livelli di sicurezza (vediTabella 2). Anche in questo caso, seil bit INQ_AUT è settato, il coman-do DEBIT deve essere preceduto dalprocesso di mutua autentificazione(vedi immagini della Figura 13). Latransazione di tipo REVOKEDEBIT è possibile soltanto imme-diatamente dopo una transazioneDEBIT per annullare un erratoaddebito sulla carta; è possibile abi-litare e disabilitare tale opzionemediante il bit REV_DEBdell'Option Register. Come al solito,se il bit INQ_AUT è settato, il

comando REVOKE DEBIT deve essere precedutodal processo di mutua autentificazione (Figura 14).Nella transazione di tipo CREDIT, il bilanciodell'Account è incrementato dell'importo specifica-to. Il massimo importo che può essere accreditato èlimitato dal valore MAXBAL, memorizzatonell'Account Data Structure. La transazione CRE-DIT può essere eseguita soltanto ad un elevatolivello di sicurezza perciò se il bit INQ_AUT è set-tato, il comando CREDIT deve essere precedutodal processo di mutua autentificazione (Figura 15).

Struttura dell�ATRDopo un reset hardware, la carta trasmette l'ATRsecondo lo standard ISO 7816-3. La carta ACOS2supporta il protocollo T=0 con la convenzionediretta della codifica dei bit. Le immagini riportatein Figura 16 illustrano i dati trasmessi dalla carta.


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

Fig. 16

Fig. 15

DVR, la tecnologia digitale per la tua sicurezza

Disponibili presso i nostri Rivenditori o nel nostro punto vendita di Gallarate (VA). Caratteristiche tecniche e vendita on-line direttamente sul sito www.futuranet.it

Via Adige, 11 - 21013 Gallarate (VA)Tel. 0331/799775 ~ Fax. 0331/778112

Disponibili presso i nostri Rivenditori o nel nostro punto vendita di Gallarate (VA).

Tut

ti i p

rezz

i son

o da

inte

nder

si I

VA

incl

usa.

I DVR vengono forniti senza Hard Disk.

Videoregistratore/multiplexer digitale a 4 canali con cassetto per Hard Disk estraibile e in-terfaccia Ethernet. Funziona senza l’ausilio di un PC. Le immagini riprese dalle quattro tele-camere possono essere memorizzate su chiavetta USB e possono essere visualizzate sul browser di qualsiasi PC che dispone di una connessione internet. Dispone di funzionalità duplex: registrazione e live multischermo contemporanei, di Motion Detector, di ricerca rapi-da delle registrazioni su Data/Ora e su evento d’allarme.

Versione a 9 canali con cas-setto Hard Disk estraibile. Integra in

un unico apparecchio un DVR e un multiplexer full-duplex a 9 canali. Quattro differenti modalità di visua-

lizzazione: 1 canale (a pieno schermo), 4 canali (modalità quad), 7 e 9 canali. Funzionalità duplex: registrazione e live multischermo contemporanei, di ricerca rapida delle registrazioni su Data/Ora e su evento d’allarme.

Stesse caratteristiche del modello FR319 ma con l’aggiunta di una in-terfaccia Ethernet che rende possibile la visualizzazione delle immagini da re-moto tramite una connessione Internet.

DVR a 4 canali con Hard Disk estraibile e formato di compressio-ne MPEG4. Web server per visualizzazione remota delle imma-gini tramite Internet. Interfaccia USB 2.0 per lo scarico dei fi lmati su PC. Dispone di funzionalità duplex: registrazione e live multi-schermo contemporanei, di funzione Motion Detection, di ricerca rapida delle registrazioni su Data/Ora e su evento d’allarme.

Stesse caratteristiche del modello FR322D ma con 4 canali anzichè 16.

Stesse caratteristiche del modello FR322 ma con l’aggiunta di un masterizzatoreDVD-RW che permette di effettuare il backup delle registrazioni su DVD.

FR319W - DVR/MULTIPLEXER 9 INGRESSIcon WEB SERVER

€ 570,00 FR319 - DVR/MULTIPLEXER 9 INGRESSI

COMPRESSIONE

MPEG-4 € 1.550,00FR322 DVR/MULTIPLEXER 16 CH PORTA USB, WEB SERVER e GPRS

COMPRESSIONE

MPEG-2

FR322D - DVR/MULTIPLEXER 16 INGRESSI con PORTA USB, WEB SERVER, GPRS e DVD

€ 1.750,00

FR323D - DVR/MULTIPLEXER 4 INGRESSI con PORTA USB, WEB SERVER, GPRS e DVD

FR321 - DVR/MULTIPLEXER 4 INGRESSI con PORTA USB e WEB SERVER

DVR a 4 canali con alloggiamento interno per Hard Disk. Funziona autonomamente senza l’ausilio di un PC. Garantisce registrazioni con una qualità dell’immagine elevata - paragonabile a quella di un DVD - grazie al formato di compressione MPEG2. L’apparecchio converte il segnale video pro-veniente dalle telecamere d’ingresso in immagini digitali che possono essere salvate su chiavetta USB e visualizzate mediante browser -in qualsiasi parte del mondo- con un PC che dispone di una connessione Internet. Possibilità di eseguire il backup delle registrazioni su PC mediante porta USB. Dispone di funzionalità duplex: registrazione e live multischermo contemporanei, di funzione Motion Detection, di ricerca rapida delle registrazioni su Data/Ora e su evento d’allarme.

FR320 - DVR/MULTIPLEXER 4 INGRESSI con PORTA USB

€ 550,00

Questo dispositivo integra in un unico apparecchio un registratore digitale video ed un multiplexer full duplex a 16 canali. Al ter-mine del periodo di registrazione l’Hard Disk può essere sostituito, cancellato oppure riscritto. Funziona in maniera autonoma senza l’ausilio di un PC. Il DMR (Digital Multiplexer Recorder) converte il segnale video proveniente dalle telecamere d’ingresso in immagini digitali che vengono salvate su hard disk removibili. Dispone di due alloggiamenti per HDD.

€ 690,00

FR318W - DVR/MULTIPLEXER 4 INGRESSI con WEB SERVER € 505,00

FR233 - DVR/MULTIPLEXER 16 INGRESSI

DVRDVR, la tecnologia digitale per la tua sicurezzaDVR, la tecnologia digitale per la tua sicurezza, la tecnologia digitale per la tua sicurezzaDVR, la tecnologia digitale per la tua sicurezza

DVR a 16 canali dotato di 2 cassetti estraibili nei quali è possibile installare altrettanti HHD con capacità di oltre 400 GB ciascuno. Garantisce moltissime ore di registrazione con una buona qualità dell’immagine grazie alla compressione MPEG4. Integra in un unico apparecchio un DVR e un multiplexer full-duplex a 16 canali. Dispone di Video Web Server con possibilità di visualizzare le immagini da remoto anche mediante telefono cellulare dotato di connessione GPRS. È dotato di una comoda interfaccia USB per lo scarico dei fi lmati su PC. Completo di adat-tatore di rete e di telecomando IR per gestione DVR e controllo telecamera con funzione PTZ.

FR320W DVR/MULTIPLEXER 4 CHcon PORTA USB e WEB SERVER

Stesse caratteristiche del modello FR320W ma senza connessione di rete.

Vasta gamma di videoregistratori digitali per qualsiasi esigenza, dalla casa, al punto vendita, alla piccola o grande azienda. Da 4 a 16 canali, diff erenti sistemi di compressione, con interfaccia LAN e video web server, con trasferimento dati USB o back-up su DVD:scegli il modello che meglio si adatta alle tue esigenze.

€ 690,00

FR327 - DVR/MULTIPLEXER 4 INGRESSI

Videoregistratore digitale 4 canali con funzione motion detector. Funziona senza l’ausilio del PC e consente di memorizzare sull’Hard Disk interno le immagini ricevute dalle sorgenti video (telecamere, videocamere, ecc.) ad esso collegate. Dispone di due uscite di tipo videocomposi-to (Main e Call) per collegamento a monitor o TV. Visualizzazione delleimmagini su singolo canale a pieno schermo, funzione PIP (Picture In Picture) e POP (Picture On Picture). È dotato di un’uscita a relè (NC/NO). 4 modalità di registrazione: manuale, timer, su allarme, motion.

€ 362,00

COMPRESSIONE

WAVELET

Entry-level

€ 730,00

€ 610,00

€ 890,00

Elettronica In - novembre / dicembre 2006 25

>


SMART CCARD


Impartiamo comandi alla smart card inserita nel mini lettore utilizzando delle applicazioni software scritte appositamente. Un�occasione per fissare i concetti fondamentalidi gestione delle card. Sesta puntata.

Cor

so S

MA

RT

CAR

D

6666n questa puntata approfondiremo la sin-tassi dei comandi che la smartcard

ACOS2 mette a disposizione ed effettueremodelle prove pratiche utilizzando un lettore com-merciale PC/SC, mediante alcuni software appo-sitamente realizzati per i lettori della nostra rivi-sta. Infatti, come sarà più chiaro in seguito, attra-verso questi programmi sarà possibile operare inmodo interattivo con la smartcard attraverso unafinestra di testo in cui potremo digitare i coman-di da inviare alla carta e visualizzare la relativarisposta. Il pacchetto di installazione dei tre soft-ware realizzati come strumenti di lavoro è dispo-nibile all’indirizzo www.elettronicain.it, le appli-cazioni che verranno installate sono: acos2-test.exe; acos2-mac.exe e acos2-des.exe

Accesso ai files datiAbbiamo già accennato il meccanismo di acces-

so ai files dati, che funziona mediante i comandiSELECT FILE e READ RECORD, WRITERECORD. Il comando SELECT FILE ha laseguente sintassi (la descrizione del comandoutilizza la rappresentazione TPDU con i numeriespressi in esadecimale):

dove <FILE ID> rappresenta l’identificativo delfile che si vuole selezionare ed è costituito dadue bytes. La carta risponde a questo comandocon lo status code, cioè con altri due bytes chesegnalano al terminale se il comando è andato abuon fine.Nella tabella riportata nella pagina seguente, acui faremo riferimento anche nei successivicomandi, sono illustrati tutti i possibili statuscode che la carta ACOS2 può restituire.

I

Corso

SMAR

TCAR

D

SELECT FILE:80 A4 00 00 02 <FILE ID>

Una volta installato nel PC un lettore di smart-card PC/SC (noi abbiamo utilizzato il MINI-LECTOR distribuito da Futura Elettronica), tuttele prove descritte da qui in avanti possono essereeseguite mediante l’applicazione ACOS2-TEST. Proviamo a verificare il comando descritto sele-zionando, ad esempio, il Manufacturer File (ID:FF01H).

-> 80 A4 00 00 02 FF 01 <- 90 00

Dallo status code restituito è possibile affermare,in base alla tabella, che il file avente ID FF01 èstato selezionato correttamente.

Passiamo adesso a descrivere i comandi di mani-polazione dei records. Il primo, READRECORD, ha la seguente sintassi:

Proviamo a leggere il primo byte del primorecord del file precedentemente selezionato, cioèil Manufacturer File.

-> 80 B2 00 00 01<- 80 90 00

Dalla risposta della carta (80H=100000002) pos-siamo trarre delle importanti considerazioni.Innanzitutto, come ci aspettavamo, la carta non èpiù in Manufacturer Mode: infatti, il bit 7 delbyte restituito (Manufacturer Fuse) è settato.Inoltre, sia il bit 6 (INQ_ACC_MAC Flag) che ilbit 5 (RECORD_NUMBERING Flag) sonoresettati, quindi si deduce che in questo lotto dicarte il comando INQUIRE ACCOUNT non uti-lizzerà TTREF-C e TTREF-D per il calcolo delMAC; inoltre la numerazione dei records deifiles parte da indice zero.

Come esercizio è possibile selezionare e leggereil contenuto di tutti gli altri files dati presentisulla carta (ad eccezione del Security File che sipuò leggere nel corrente stadio di vita della carta,a patto che sia stato preventivamente verificatol’Issuer Code con il comando SUBMIT CODE)e dedurre altre interessanti informazioni. Peresempio, si può verificare se la carta è inPersonalization Stage e se sono presenti tre files

26 novembre / dicembre 2006 - Elettronica In

Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

STATUS CODE Significato90 00 Comando eseguito correttamente

91 nnIl file dati utente è stato selezionato. Il File Definition Block corrispondente è memorizzato nel recordnn del File Management File.

61 nn Comando eseguito correttamente. Inviare il comando GET RESPONSE con P3=nn per ottenere i dati.

62 81I dati restituiti dal comando INQUIRE ACCOUNT potrebbero non essere corretti a causa di errorinell�Account Data Structure.

63 CnIl comando relativo alla sicurezza non ha avuto successo. Il numero di tentativi ancora possibili èpari ad n.

67 00 Parametro P3 errato.69 66 Comando non disponibile.69 82 Condizione di sicurezza non soddisfatta (chiave, IC o PIN non verificato).69 83 Chiave bloccata. Non sono più possibili ulteriori verifiche.69 85 Non è soddisfatta la condizione per l�uso del comando.

69 F0Account Data Structure errata. Transazione interrotta. L�accesso all�account è permesso soltanto inmodo privilegiato.

6A 82 Il file non esiste; l�account non è disponibile.6A 83 Il record non esiste; il file è troppo corto.6A 86 P1 - P2 errato.6B 20 Importo del comando CREDIT/DEBIT non valido.6C nn Inviare il comando GET RESPONSE con P3=nn per ottenere i dati.6D 00 INS sconosciuta.6E 00 CLA non valida.

6F 10L�Account Transaction Counter ha raggiunto il suo valore massimo. Non sono più possibili transazioni DEBIT o CREDIT.

Tabella 1

READ RECORD:80 B2 <REC> 00 <LEN>

dove <REC> è un byte che specifica il numerodel record e <LEN> un byte che indica il nume-ro di bytes che si vogliono leggere.Se le condizioni di accesso sono verificate, lacarta risponde inviando i bytes richiesti termina-ti dallo status code.

>


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

di dati utente di test, dal contenuto assai vario(chi è Danny Wong?). Si faccia attenzione alfatto che per leggere il file utente con ID FF02 ènecessario verificare il PIN.

L’ultimo comando di manipolazione dei files èWRITE RECORD ed ha la sintassi:

contenuti nel Security Option Register) che sivuole verificare. Anche in questo caso la cartarisponde con lo status code.

Per testare il funzionamento di questo comandoproviamo innanzitutto a leggere il contenuto delsecondo record del Security File (ID: FF03H),che costituisce il PIN della carta.

-> 80 A4 00 00 02 FF 03Selezione del data file FF03 <- 90 00-> 80 B2 01 00 08Lettura degli otto bytes del secondo record<- 69 82Condizione di sicurezza non soddisfatta!

Come già accennato, infatti, in questo stadio divita della carta per poter leggere il contenuto delSecurity File è necessario verificare l’IssuerCode (impostato in fabbrica al valore 41 43 4F53 54 45 53 54, riportato sulle carte).

-> 80 20 07 00 08 41 43 4F 53 54 45 53 54Verifica dell’IC<- 90 00OK-> 80 B2 01 00 08Riproviamo a leggere il record<- 31 32 33 34 35 36 37 38 90 00Ecco il PIN della carta!

È possibile, a questo punto, effettuare tutte leoperazioni di manipolazione dei files soggettealla verifica dell’IC. Possiamo, ad esempio, scri-vere nei records dei files di sistema, modificandole chiavi di accesso fra cui lo stesso IC, oppureforzare il passaggio della carta in User Stage set-tando il Personalization Bit (si ricordi però chequesta operazione non è annullabile).

Mutua autentificazioneEsaminiamo adesso i comandi utilizzati nel pro-cesso di mutua autentificazione fra terminale ecarta, START SESSION, AUTHENTICATE eGET RESPONSE. Si tenga presente che l’esecu-zione dei due comandi è strettamente correlata epermette il calcolo della Session Key, che verràutilizzata anche nei comandi relativi alle trans-azioni (nella stessa sessione di lavoro) se le rela-tive opzioni sono abilitate.La sintassi del comando START SESSION èriportata di seguito:

WRITE RECORD:80 D2 <REC> 00 <LEN> <BYTE 1> .. <BYTE N>

SUBMIT CODE:80 20 <NUM CODE> 00 08 <CODE>

dove <REC> è un byte che specifica il numerodel record, <LEN> un byte che indica il numerodi bytes che si vogliono scrivere, cioè <BYTE 1>.. <BYTE N>. La carta risponde a questo coman-do con lo status code.Proviamo, ad esempio, ad eseguire questocomando scrivendo nel primo record del file datiavente ID F001, costituito come è possibile veri-ficare da 1 record di 3 bytes uguali, impostatidalla fabbrica a 01 01 12, la sequenza di bytes FFFF FF.

-> 80 A4 00 00 02 F0 01Selezione del data file F001 <- 91 01-> 80 B2 00 00 03Lettura dei tre bytes del primo record<- 01 01 12 90 0001 01 12-> 80 D2 00 00 03 FF FF FFScrittura di FF FF FF<- 90 00-> 80 B2 00 00 03Lettura dei tre bytes del primo record<- FF FF FF 90 00FF FF FF

Verifica delle chiaviPassiamo adesso ad esaminare il comando chepermette di verificare le chiavi di accesso allacarta, SUBMIT CODE. La sintassi di questocomando è la seguente:

dove <NUM CODE> specifica la chiave da veri-ficare (un valore compreso tra 01 e 05 è relativoagli Application Codes, 06 al PIN e 07 all’IssuerCode) ed in <CODE> sono contenuti i valoridegli otto bytes della chiave (in chiaro o critto-grafati con la Session Key a seconda dei valori

È importante inoltre notare che il numero ran-dom generato dalla carta e riportato in questoesempio sarà diverso in ogni successiva esecu-zione del comando AUTHENTICATE. Di conse-guenza, i valori calcolati non saranno uguali aquelli riportati, anche se i risultati dei comandi diautentificazione devono essere gli stessi. I dativariabili verranno indicati, per maggiore chiarez-za, con un colore diverso (azzurro).

Iniziamo con START SESSION la mutua auten-tificazione nella finestra di ACOS2-TEST:

-> 80 84 00 00 08START SESSION<- 91 E2 87 BA F2 70 E3 90 90 00RNDC + 90 00

Calcoliamo ora DES(RNDC,#KT) con l’applica-zione ACOS2-DES:

Digitare chiave:41 55 54 48 54 45 52 4DDigitare dato da criptare:91 E2 87 BA F2 70 E3 90[C]riptare o [D]ecriptare ? CDato generato :CD 06 BA A3 AD C1 35 09

Possiamo ora inviare con ACOS2-TEST ilcomando AUTHENTICATE (RNDT = 01 02 0304 05 06 07 08) e chiedere il dato generato dallacarta con GET RESPONSE:

-> 80 82 00 00 10 CD 06 BA A3 AD C1 35 0901 02 03 04 05 06 07 08 <- 61 08OK-> 80 C0 00 00 08GET RESPONSE<- 9E 09 EF F3 EC 93 4E 49 90 00DES(RNDT,#Ks) + 90 00

Per verificare se la carta dispone delle chiavi cor-rette, bisogna adesso calcolare la Session Key eper questo eseguiamo con ACOS2-DES il calco-lo di DES(RNDC,#KC):

Digitare chiave:41 55 54 48 43 41 52 44Digitare dato da criptare:91 E2 87 BA F2 70 E3 90[C]riptare o [D]ecriptare ? C


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

La carta genera un numero random di otto bytes(RNDC) e lo invia in risposta concludendo la tra-smissione con lo status code.A questo punto il terminale deve crittografare ilnumero random ricevuto con la sua chiave, gene-rare un altro numero random di otto bytes (RNDT)ed inviare il comando AUTHENTICATE:

AUTHENTICATE:80 82 00 00 10 <DES(RNDC,#KT)> <RNDT>

GET RESPONSE:80 C0 00 00 <LEN>

START SESSION:80 84 00 00 08

dove <DES(RNDC,#KT)> sono gli otto bytes chederivano dall’operazione di crittografia DES e<RNDT> è il numero random di otto bytes gene-rato dal terminale. La carta verifica se il datoricevuto è corretto, ripetendo l’operazione dicrittografia effettuata dal terminale, quindi calco-la la Session Key mediante la quale crittografa ilnumero random ricevuto dal terminale. LaSession Key viene calcolata, nel caso di DESsemplice, con la formula:

Ks=DES(DES(RNDC,#KC) XOR RNDT,#KT)

Il processo si conclude con l’invio, da parte delterminale, del comando GET RESPONSE:

con <LEN> necessariamente uguale in questocaso a 08. La carta risponde inviando il dato diotto bytes calcolato, DES(RNDT,#KS), seguitodallo status code. Il terminale può, a questopunto, concludere il processo di mutua autentifi-cazione calcolando la Session Key e verificandoche il dato ricevuto sia corretto.

Per verificare praticamente quanto detto dobbia-mo utilizzare, oltre all’applicazione ACOS2-TEST, l’applicazione ACOS2-DES che consentedi crittografare i dati come richiesto dai comandidi mutua autentificazione. Eseguiamo questaapplicazione in una seconda finestra e premettia-mo che il terminale, per poter generare la SessionKey, deve essere a conoscenza sia della TerminalKey che della Card Key. Utilizzeremo in questoe nei prossimi esempi i valori imposti in fabbricaper la ACOS2 (Terminal Key: 41 55 54 48 54 4552 4D; Card Key : 41 55 54 48 43 41 52 44).


>

Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

Dato generato :25 98 B3 B1 A2 7F 7A 3D

Effettuando l’operazione logica di XOR tra que-sto dato e RNDT (si può usare a tale scopo anchela calcolatrice di Windows in modalità scientifi-ca) si ottiene il dato 24 9A B0 B5 A7 79 7D 35,con cui possiamo completare il calcolo dellaSession Key:

Digitare chiave:41 55 54 48 54 45 52 4DDigitare dato da criptare:24 9A B0 B5 A7 79 7D 35[C]riptare o [D]ecriptare ? CDato generato:52 C7 4C CA 82 D1 75 E4

Verifichiamo infine che il valore ricevuto è pro-prio DES(RNDT,#KS):

Digitare chiave:52 C7 4C CA 82 D1 75 E4Digitare dato da criptare:01 02 03 04 05 06 07 08[C]riptare o [D]ecriptare ? CDato generato :9E 09 EF F3 EC 93 4E 49

Come è evidente, si tratta proprio del dato resti-tuito dalla carta in seguito al comando GETRESPONSE. Abbiamo quindi verificato che ilprocesso di mutua autentificazione è stato ese-guito correttamente, secondo le modalità descrit-te nella puntata precedente.

Un ulteriore comando che può essere configura-to per utilizzare la crittografia DES è CHANGEPIN che, se abilitato, consente di modificare ilPIN della carta. La sintassi del comando è laseguente:

Utilizziamo ancora una volta l’applicazioneACOS2-DES:

-> 80 20 07 00 08 41 43 4F 53 54 45 53 54Verifica dell’IC<- 90 00OK-> 80 A4 00 00 02 FF 02Seleziona il file FF02<- 90 00OK-> 80 D2 00 00 01 05Setta PIN_ALT<- 90 00OK

Affinché la modifica del bit sia effettiva bisognaresettare la carta, operazione che può essereeffettuata chiudendo l’applicazione ACOS2-TEST ed eseguendola nuovamente.

Procediamo adesso con la verifica del PIN (chenella ACOS2 è di default pari a 31 32 33 34 3536 37 38) e con la successiva modifica per mezzodel comando CHANGE PIN:

-> 80 20 06 00 08 31 32 33 34 35 36 37 38Verifica del PIN<- 90 00OK-> 80 24 00 00 08 01 01 01 01 01 01 01 01CHANGE PIN<- 90 00OK

Il motivo per cui per la modifica del PIN è preferi-bile utilizzare questo comando risiede nella sicurez-za dovuta al fatto che non è necessario verificarel’Issue Code da terminale (la stessa operazione sipotrebbe infatti eseguire dietro presentazionedell’IC, sovrascrivendo il PIN nel secondo recorddel Security File). Inoltre, prima di procedere con lamodifica del PIN, questo comando impone necessa-riamente la verifica del valore corrente.

Transazioni sull�accountRimangono da esaminare nel dettaglio i coman-di che consentono di operare sull’Account. Ilprimo che prendiamo in considerazione èINQUIRE ACCOUNT:

CHANGE PIN:80 24 00 00 08 <PIN>

dove <PIN> è il nuovo PIN di otto bytes, even-tualmente crittografato (con DES inverso) con laSession Key generata durante la sessione corren-te se il bit PIN_DES del Security Option Registerè pari ad uno. Il comando viene abilitato settan-do il bit PIN_ALT dell’Option Register (didefault pari a zero) e deve essere preceduto dallaverifica del PIN corrente.

INQUIRE ACCOUNT:80 E4 <NUM CODE> 00 04 <REF

dove il <MAC> di quattro bytes viene verificatodalla carta basandosi sulla seguente sequenza di16 bytes:

E6 <BAL> <TTREF-D> <ATREF> 00 00

e viene preso in con-siderazione dallacarta soltanto se il bitDEB_MAC è settato.I tre bytes<AMOUNT> specifi-

cano l’importo da addebitare ed i quattro bytes<TTREF-D> (Terminal Transaction Reference -Debit) sono generati arbitrariamente dal termina-le. Ricordando che i livelli di sicurezza richiestiper l’esecuzione del comando devono essere sod-disfatti (di default il comando DEBIT può sem-pre essere eseguito ed il MAC non viene verifi-cato dalla carta), proviamo ora, come ulteriore

usato dalla carta per il calcolo del MAC utilizzain questo caso la Credit Key (pari di default a 4352 44 49 54 4B 45 59) e, siccome il bitINQ_AUT è pari a zero, il MAC non è ulterior-mente crittografato con la Session Key. Nelcomando INQUIRE ACCOUNT il MAC vienecalcolato basandosi sulla seguente sequenza di16 bytes:

<REF> <TT> <BAL> <ATREF> 00 00

Eseguiamo l’applicazione ACOS2-MAC e pro-viamo a verificare il MAC contenuto nella prece-dente risposta:

Digitare chiave:43 52 44 49 54 4B 45 59Digitare dato di 16 bytes:00 00 00 00 03 00 27 10 42 41 4E 4B 00 01 00 00

MAC generato :FA 0B F5 D1

Si conclude che il MAC è stato generato dallacarta in modo corretto.

Esaminiamo adesso il comando DEBIT, che ciconsente di effettuare addebiti sull’Account.La sintassi del comando è la seguente:

dove <NUM CODE> specifica la chiave chedeve essere utilizzata dalla carta per il calcolo delMAC (00 : Debit Key; 01 : Credit Key; 02 :Certify Key; 03 : Revoke Debit Key) ed in<REF> vengono inviati quattro bytes arbitrariche saranno utilizzati per il calcolo del MAC. Lacarta risponde con lo status code specificandoche, per ottenere i dati relativi, bisogna procede-re con il comando GET RESPONSE con P3=19.La struttura dell’Account è la seguente:


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

Bytes 0-3 : MAC

Byte 4 : Tipo di transazione (01 : DEBIT,02: REVOKE DEBIT, 03 : CREDIT)

Bytes 5-7 : Bilancio corrente

Bytes 8-13 : ATREF (Account Transaction Reference)

Bytes 14-16 : Massimo bilancio ammesso

Bytes 17-20 : TTREF-C (Terminal TransactionReference � Credit)

Bytes 21-24 : TTREF-D (Terminal TransactionReference � Debit)

DEBIT:80 E6 00 00 0B <MAC> <AMOUNT> TTREF-D >

Se il bit INQ_AUT è settato, il comando INQUI-RE ACCOUNT deve essere preceduto dallamutua autentificazione ed il MAC risulterà crit-tografato con la Session Key.

Effettuiamo adesso qualche prova pratica conACOS2-TEST e proviamo ad interrogare lo statodell’Account della nostra carta:

-> 80 E4 01 00 04 00 00 00 00INQUIRE ACCOUNT (REF = 00 00 00 00)<- 61 19OK-> 80 C0 00 00 19GET RESPONSE

Fig. 1

Dalla risposta ricevuta possiamo dedurre chel’ultima transazione (eseguita in fabbricadall’ACS) è stata di CREDIT; inoltre il bilanciocorrente è 2710H=10000 ed è pari al bilanciomassimo ammissibile. A questo punto sarebbeopportuno verificare il MAC e, a tale scopo, èpossibile adoperare una terza applicazione appo-sitamente realizzata: ACOS2-MAC. L’algoritmo

Risultato dell�interrogazione

REV_DEB dell’Option Register (REVOKEDEBIT è disattivato di default):

-> 80 20 07 00 08 41 43 4F 53 54 45 53 54Verifica dell’IC<- 90 00OK-> 80 A4 00 00 02 FF 02Seleziona il file FF02<- 90 00OK-> 80 D2 00 00 01 25Setta PIN_ALT<- 90 00OK

Affinché la modifica del bit sia effettiva bisognaresettare la carta, operazione che può essereeffettuata chiudendo l’applicazione ACOS2-TEST ed eseguendola nuovamente.

Dobbiamo ora calcolare il MAC da inserire nelcorpo di REVOKE DEBIT con ACOS2-MAC (didefault la Revoke Debit Key è pari a 52 45 56 4F4B 4B 45 59):

Digitare chiave:52 45 56 4F 4B 4B 45 59Digitare dato di 16 bytes:E8 00 27 10 00 00 00 00 42 41 4E 4B 00 03 00 00

MAC generato :28 8F 71 5E

Procediamo adesso con lo storno dell’addebitoper mezzo del comando REVOKE DEBIT:

-> 80 E8 00 00 04 28 8F 71 5EREVOKE DEBIT<- 90 00OK-> 80 E4 01 00 04 00 00 00 00INQUIRE ACCOUNT (REF = 00 00 00 00)<- 61 19OK-> 80 C0 00 00 19GET RESPONSE

<- 7E 20 8A E1 02 00 27 10 42 41 4E 4B 00 0300 27 10 42 41 4E 4B 00 00 00 00 90 00

Come si può verificare, l’ultima transazioneeffettuata è stata di tipo REVOKE DEBIT ed ora

passaggio, ad effettuare l’addebito alla carta diun’unità di credito:

-> 80 E6 00 00 0B 00 00 00 00 00 00 01 00 0000 00DEBIT<- 90 00OK-> 80 E4 01 00 04 00 00 00 00INQ. ACCOUNT<- 61 19OK-> 80 C0 00 00 19GET RESPONSE

<- D9 5E F9 02 01 00 27 0F 42 41 4E 4B 00 0200 27 10 42 41 4E 4B 00 00 00 00 90 00

Come si può verificare, l’ultima transazioneeffettuata è stata di tipo DEBIT ed ora il bilanciocorrente della carta è pari a 270FH=9999. Siosservi, inoltre, che l’ATREF è stato automatica-mente incrementato.

Se il bit REV_DEB è settato, l’ultimo comandoDEBIT effettuato sulla carta può essere annulla-to dallo stesso terminale che ha effettuato l’adde-bito (identificato dal TTREF-D) con il comandoREVOKE DEBIT, che ha la seguente sintassi:


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

>

REVOKE DEBIT:80 E8 00 00 04 <MAC>

dove il <MAC> di quattro bytes viene verificatodalla carta basandosi sulla seguente sequenza di16 bytes ed utilizzando la Revoke Debit Key:

E8 <BAL> <TTREF-D> <ATREF> 00 00

Si osservi che stavolta, per motivi di sicurezza, ilMAC deve essere necessariamente verificatodalla carta prima di effettuare lo storno dell’ad-debito. Inoltre <BAL> è il valore del bilancioprecedente all’operazione DEBIT, mentre<ATREF> è l’Account Transaction Referenceper la transazione corrente (bisogna incrementa-re il valore della precedente transazione restitui-to dal comando INQUIRE ACCOUNT).

Proviamo adesso, come esempio pratico, a stor-nare l’operazione di addebito eseguita in prece-denza sulla carta con ACOS2-TEST. Iniziamocon l’attivare il comando settando il bit

Verifica dell’IC<- 90 00OK-> 80 A4 00 00 02 FF 05Seleziona il file FF05<- 90 00OK-> 80 D2 04 00 03 00 27 11MAXBAL=2711H=10001<- 90 00OK

Dobbiamo ora calcolare il MAC da inserire nelcorpo di CREDIT con ACOS2-MAC (di defaultla Credit Key è pari a 43 52 44 49 54 4B 45 59):

Digitare chiave:43 52 44 49 54 4B 45 59Digitare dato di 16 bytes:E2 00 00 01 00 00 00 00 42 41 4E 4B 00 04 00 00

MAC generato :CC C3 AD 72

Procediamo adesso ad accreditare una unità dicredito con il comando CREDIT:

-> 80 E2 00 00 0B CC C3 AD 72 00 00 01 00 00 00 00

CREDIT<- 90 00OK-> 80 E4 01 00 04 00 00 00 00INQ. ACCOUNT<- 61 19OK-> 80 C0 00 00 19GET RESPONSE

<- 50 6A 38 BB 03 00 27 11 42 41 4E 4B 00 0400 27 11 00 00 00 00 00 00 00 00 90 00

Come si può verificare, l’ultima transazioneeffettuata è stata di tipo CREDIT ed ora il bilan-cio corrente della carta è pari a 2711H=10001.

Con questo ultimo esempio abbiamo quindicompletato la descrizione dei comandi dellacarta ACOS2. Nella prossima puntata del corsopresenteremo il progetto di un lettore di smart-card di tipo PIN-PAD, che potrà essere utilizzatocome terminale offline per implementare unsistema di pagamento a smartcard.


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

CREDIT:80 E2 00 00 0B <MAC> <AMOUNT> TTREF-C >

il bilancio corrente della carta è nuovamente paria 2710H=10000.

L’ultimo comando relativo alla gestionedell’Account è CREDIT, che ha la sintassi:

dove il <MAC> di quattro bytes è obbligatorio eviene verificato dalla carta basandosi sullaseguente sequenza di 16 bytes ed utilizzando laCredit Key:

E2 <AMOUNT> <TTREF-C> <ATREF> 00 00

I tre bytes <AMOUNT> specificano l’importo chedeve essere accreditato ed i quattro bytes <TTREF-C> (Terminal Transaction Reference - Credit) sonogenerati arbitrariamente dal terminale.Se il bit TRNS_AUT è settato, il comando CRE-DIT deve essere preceduto dalla mutua autentifi-cazione ed il MAC risulterà ulteriormente critto-grafato con la Session Key.

Proviamo adesso, come esempio pratico, adaccreditare una unità di credito sulla carta conACOS2-TEST. Iniziamo con l’osservare che lacarta ha già raggiunto il massimo valore di bilan-cio e, quindi, dobbiamo incrementare questovalore affinché la transazione possa essere eseguita.

-> 80 20 07 00 08 41 43 4F 53 54 45 53 54

Elettronica In - gennaio 2007 89

>


SMART CCARD


In questa puntata ci occupiamo della personalizzazione e della inizializzazione della Cardproponendo due software da noi messi a punto checi consentiranno di inizializzare e gestire le ACOS2nell�ambito di un circuito di pagamento sicuro.Settima puntata.

Cor

so S

MA

RT

CAR

D

7777opo aver approfondito nella puntatadello scorso numero i comandi della

smart card ACOS2, passiamo ora ad esaminarela procedura generale di personalizzazione dellacarta proposta dal produttore. Dal punto di vistaoperativo illustreremo due software, realizzatiappositamente per i nostri lettori, che ci consen-tiranno di inizializzare e gestire le ACOS2 nel-l’ambito di un circuito sicuro di pagamento. Nonmancherà infine un cenno alla smart card ACOS-SAM, che sarà utilizzata come modulo crittogra-fico in alcuni progetti pratici di prossima pubbli-cazione.

Personalizzazione della card ACOS2La sequenza di operazioni suggerita dal produt-tore per l’inizializzazione della smart card, che sitrova nel Personalization Stage, è la seguente:1. Alimentare e resettare la card.

2. Verificare l’Issuer Code di default (fornito daldistributore con la card).

3. Selezionare il Personalization File (ID =FF02H) e scrivere gli opportuni settagginell’Option Register ed il parametroN_OF_FILE, prestando attenzione a nonimpostare accidentalmente il PersonalizationBit ed a non modificare il Security OptionRegister in questa fase.

4. Resettare nuovamente la card. Dopo il reset,l’ACOS2 legge il Personalization File edaccetta il nuovo valore di N_OF_FILE e glioption bits memorizzati nell’OptionRegister.

5. Verificare ancora l’Issuer Code di default.6. Selezionare lo User File Management File

(ID = FF04H) e scrivere i File DefinitionBlocks per gli User Files richiesti, utilizzan-do il comando WRITE RECORD, con gli

D

Corso

SMAR

TCAR

D

attributi di sicurezza impostati a “FreeAccess”.

7. Selezionare individualmente gli User Files edinizializzare i dati come richiesto utilizzandoil comando WRITE RECORD.

8. Selezionare lo User File Management File(ID = FF04H) ed impostare gli attributi disicurezza richiesti per tutti gli User Files uti-lizzando il comando WRITE RECORD.Verificare il contenuto dello User FileManagement File con il comando READRECORD. Si presti attenzione a non modifi-care accidentalmente gli altri parametri nelFile Definition Block.

9. Se presente, selezionare l’Account File (ID =FF05H) ed inizializzarne i dati con il coman-do WRITE RECORD. Verificare il contenutodell’Account File con il comando READRECORD.

10.Se l’Account File è presente, selezionarel’Account Security File (ID = FF06H) ed ini-zializzarne le chiavi con il comando WRITERECORD. Verificare il contenutodell’Account Security File con il comandoREAD RECORD.

11.Selezionare il Security File (ID = FF03H) edinizializzare tutte le chiavi con il comandoWRITE RECORD. Verificare il contenutodel Security File con il comando READRECORD.

12.Selezionare il Personalization File (ID =FF02H) ed inizializzare il Security OptionRegister ed i bytes restanti. Impostare ilPersonalization Bit con il comando WRITERECORD. Verificare il contenuto delPersonalization File con il comando READRECORD. Prestare attenzione a non modifi-care accidentalmente il contenutodell’Option Register ed il valoreN_OF_FILE.

13.Resettare la card. Lo stadio di vita della cardriportato nell’ATR dovrebbe a questo puntoessere “User Stage”.

14.La corretta personalizzazione può essereverificata con i comandi AUTHENTICATE eSUBMIT CODE, facendo riferimento allechiavi impostate, leggendo e scrivendo i datafiles allocati ed eseguendo i comandi relativiall’account.

Per illustrare l’architettura che abbiamo pensatodi implementare nella smart card utente, utiliz-ziamo ora il software ACOS2-TEST presentato

nello scorso numero e procediamo manualmentealla personalizzazione, facendo riferimento allaprocedura proposta dal produttore. Ovviamentequesta procedura viene eseguita a scopi didattici;infatti, in seguito, per l’inizializzazione dellecarte utente verrà impiegato un apposito softwa-re. Si tenga inoltre presente che i valori dellechiavi inserite sono stati scelti a titolo di esempioe devono essere personalizzati in ogni distintaapplicazione per motivi di sicurezza.

Iniziamo con l’inserire la carta ACOS2 nelMINILECTOR e verificandone l’Issue Code didefault (41 43 4F 53 54 45 53 54) nella finestradi ACOS2-TEST:

-> 80 20 07 00 08 41 43 4F 53 54 45 53 54SUBMIT CODE (IC)<- 90 00OK

selezioniamo adesso il Personalization File (ID:FF02H):

-> 80 A4 00 00 02 FF 02SELECT FILE FF02 <- 90 00OK

Dobbiamo adesso scrivere i nostri settaggi neirelativi bit dell’Option Register. Vogliamo preve-dere ovviamente l’utilizzo dell’account(ACCOUNT=1); utilizzare per il calcolo delMAC la crittografia DES semplice (3-DES=0)riservarci la possibilità di cambiare il PIN con ilcomando CHANGE_PIN (PIN_ALT=1); nonutilizzare il checksum MAC per l’operazioneDEBIT (DEB_MAC=0); non richiedere l’inseri-mento del PIN per l’operazione DEBIT(DEB_PIN=0) riservarci la possibilità di esegui-re il comando REVOKE DEBIT (REV_DEB=1);non utilizzare la mutua autentificazione per latransazione sull’account e per il comandoINQUIRE_ACCOUNT (TRNS_AUT=0,INQ_AUT=0). Il contenuto dell’Option Registerdeve essere quindi pari a 001001012, cioè 25 H.Per quanto riguarda il numero di files utente,imposteremo N_OF_FILE=02 H (il primo fileverrà utilizzato per memorizzare il numero seria-le della carta, il secondo, per uso futuro, potràmemorizzare il log delle transazioni). Prestiamo attenzione a non sovrascrivere in que-sta fase il Personalization Bit ed il Security

90 gennaio 2007 - Elettronica In

Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

>


Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

Option Register (il secondo e quarto bytes delrecord devono essere lasciati a zero):

-> 80 D2 00 00 04 25 00 02 00WRITE RECORD<- 90 00OK

Resettiamo la carta chiudendo l’applicazioneACOS2-TEST ed eseguendola nuovamente.

Verifichiamo quindi nuovamente l’IC di default.

-> 80 20 07 00 08 41 43 4F 53 54 45 53 54SUBMIT CODE (IC)<- 90 00OK

selezioniamo adesso lo User File ManagementFile (ID: FF04H):


Nostra intenzione è scrivere, a questo punto, iFile Definition Blocks per i due files utente.Riserviamo per il serial number (ID = F000H) unsolo record di lunghezza pari a 32 bytes e per illog (ID = F001H) 255 records di lunghezza paria 32 bytes. Prestiamo attenzione a non impostare gli attribu-ti di sicurezza.

-> 80 D2 00 00 06 20 01 00 00 F0 00WRITE RECORD 00<- 90 00OK-> 80 D2 01 00 06 20 FF 00 00 F0 01WRITE RECORD 01<- 90 00OK

Selezioniamo quindi il serial number ed inizia-lizziamo i suoi 32 bytes, ad esempio al valore 0000 00 00 .. 00 01:

-> 80 A4 00 00 02 F0 00SELECT FILE F000 <- 91 00OK-> 80 D2 00 00 20 00 00 00 00 00 .. 00 01

WRITE RECORD<- 90 00OK

Selezioniamo ora nuovamente lo User FileManagement File (ID: FF04H) ed impostiamol’attributo di sicurezza per il serial number(vogliamo che ne sia possibile la lettura ma nonla scrittura):

-> 80 A4 00 00 02 FF 04SELECT FILE FF04 <- 90 00OK-> 80 D2 00 00 06 20 01 00 01 F0 00WRITE RECORD<- 90 00OK

Selezioniamo l’Account File (ID: FF05H) esovrascriviamo i bytes relativi a MAXBALAN-CE, ad esempio al valore 50000 (00C350H):

-> 80 A4 00 00 02 FF 05SELECT FILE FF05<- 90 00OK-> 80 D2 04 00 04 00 C3 50 00WRITE RECORD MAXBALANCE<- 90 00OK

Procediamo adesso inizializzando le chiavi rela-tive alla gestione dell’account, selezionandol’Account Security File (ID: FF06H)


e sovrascrivendo le chiavi che saranno utilizzate,cioè in questo caso la CREDIT KEY e la REVO-KE DEBIT KEY:

-> 80 D2 01 00 08 01 02 03 04 05 06 07 08WRITE CREDIT KEY<- 90 00OK-> 80 D2 03 00 08 01 02 03 04 05 06 07 08WRITE REV.DEBIT KEY<- 90 00OK

cartella di lavoro del software e descritto qui diseguito, il cui contenuto deve essere modificatocon un generico editor di testo, come ad esempioil Notepad (Blocco Note) di Windows.Il file acos2.txt è costituito rispettivamente daquattro righe di sedici caratteri, con la codificaASCII delle chiavi utilizzate e da una riga di seicaratteri pari al massimo bilancio, secondo laseguente struttura:


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

41434F5354455354 ISSUER CODE DI DEFAULT0102030405060708 NUOVO ISSUER CODE0102030405060708 CREDIT KEY0102030405060708 REVOKE DEBIT KEY005350 MAX BALANCE

Analoga operazione deve essere effettuata inizia-lizzando le chiavi relative alla sicurezza, selezio-nando il Security File (ID: FF03H)


e sovrascrivendo le chiavi che saranno utilizzate(almeno l’IC):

-> 80 D2 00 00 08 01 02 03 04 05 06 07 08WRITE IC<- 90 00OK

Concludiamo la personalizzazione della cartaselezionando il Personalization File (ID:FF02H), sovrascrivendo il Security OptionRegister con 00H, specificando cioè che la veri-fica di tutte le chiavi deve avvenire in chiaro, edimpostando il Personalization Bit per effettuarela transizione in User Stage:

-> 80 A4 00 00 02 FF 02SELECT FILE FF02 <- 90 00OK-> 80 D2 00 00 04 25 00 02 80WRITE RECORD<- 90 00OK

Resettiamo la carta chiudendo l’applicazioneACOS2-TEST ed eseguendola nuovamente: daquesto momento in poi la carta si trova in UserStage. Non sarà quindi più possibile la modificadel Personalization File, la lettura del SecurityFile e dell’Account Security File.

Procedura automatica di personalizzazione delle carteAbbiamo dunque esaminato in dettaglio i pas-saggi necessari per una personalizzazione di basedella smart card ACOS2. Come accennato in pre-cedenza, non sarà necessario eseguire questasequenza di operazioni per l’inizializzazione diogni carta, ma a tale scopo verrà utilizzato il soft-ware ACOS2-INIT.Per agevolare l’operazione di personalizzazioneabbiamo pensato di memorizzare tutti i dati diinteresse nel file di testo acos2.txt, presente nella

L’operazione preliminare, obbligatoria per ovvimotivi di sicurezza, consiste nella modifica dellechiavi contenute in questo file (bisogna inoltreverificare che l’Issuer Code di default sia quellostandard fornito con le carte, altrimenti occorremodificare anch’esso in accordo con quellocomunicato dal fornitore). Il funzionamento del software ACOS2-INIT ècome al solito abbastanza intuitivo: dopo avercollegato il MINILECTOR ad una porta USBdisponibile sul nostro PC, possiamo eseguirel’applicazione. L’utente deve iniziare la procedu-ra digitando il numero di carte da inizializzare eil seriale della prima carta del lotto; i dati lettiche verranno impostati sulla carta vengono ripro-posti a video ed è richiesta conferma prima dieffettuare il passaggio in user stage. E’ possibilequindi procedere con una nuova carta (il numeroseriale viene automaticamente incrementato) oterminare la procedura.

Implementiamo un circuitodi pagamentoPassiamo adesso ad esaminare il softwareACOS2-PURSE, che è possibile utilizzare pergestire le carte ACOS2 in un circuito di paga-mento, come ad esempio quello di un’attivitàcommerciale. L’interfaccia grafica del software èvisibile in Figura 1.Anche in questo caso è presente un file di testoche contiene la sola chiave utilizzata, cioè cre-dit.txt relativo alla Credit Key, che deve esserepreventivamente modificato dall’utente in accor-do con il valore impostato nella personalizzazio-ne delle carte.Dopo aver inserito la carta nel lettore bisognaprocedere agendo sul pulsante di attivazione


>Cor

so S

MA

RT

CAR

DC

orso

SM

AR

TCA

RD

“Power ON”: il led lampeggiante del lettoreaumenterà la sua frequenza fino a diventare fisso,segnalando la corretta alimentazione della smartcard; nella casella “Bilancio” verrà quindi visua-lizzato il bilancio corrente. Per eseguire un’ope-razione di addebito è necessario digitare nellacasella “Importo” il relativo valore ed agire sulpulsante “Debit”: se il bilancio della carta è suf-ficiente da consentire tale operazione, risulteràche lo stesso sarà aggiornato come richiesto. Pereseguire invece un’operazione di accredito, dopoaver digitato nella casella “Importo” il valoredesiderato, bisogna agire sul pulsante “Credit”:se la Credit Key memorizzata nel file credit.txt ècorretta ed il valore dell’importo massimoammissibile sulla carta è tale da non essereeccessivo in relazione al MAXBALANCE,anche in questo caso verrà visualizzato l’aggior-namento del valore.Prima di estrarre la carta è necessario disattivar-la uscendo dal programma mediante il pulsante“Uscita” o, alternativamente, cliccando sul pul-sante di chiusura delle finestre di Windows.

Nel software è stata inserita una diagnostica ele-mentare sotto forma di finestre di popup, chesegnalano il verificarsi di condizioni anomale.Commentiamo brevemente i vari messaggi dia-gnostici che si possono presentare.

La prima categoria di messaggi si riferisce aglierrori delle funzioni di libreria PC/SC WIN-SCARD.LIB, i cui più probabili sono i seguenti:

• Failed SCardListReaders: è fallita l’enumera-zione dei lettori, probabilmente non è statocollegato il lettore di smart card al PC.

• Failed SCardConnect: è fallita la connessione

alla card, probabilmente non è stata inserita lacard nel lettore.

• Failed SCardTransmit: il lettore non riesce ascambiare i dati con la card, probabilmente lacard o il lettore hanno qualche problema.

• Failed SCardDisconnect: è fallita la discon-nessione alla card, probabilmente non è statainserita la card nel lettore e si è richiesto diuscire dal programma e quindi di disconnet-tersi.

La seconda categoria di messaggi si riferisce allerisposte anomale della carta e sono i seguenti:• Account does not exist: l’account non è pre-

sente sulla carta, probabilmente la carta non èstata inizializzata.

• ATC at maximum: il contatore di transazionipresente sulla carta ha raggiunto il valore mas-simo. È un caso abbastanza improbabile, per-ché tale contatore è implementato con un con-tatore di sei bytes ma, se così fosse avvenuto,la carta risulterebbe inutilizzabile.

• Amount too large: si è tentata un’operazionedi DEBIT superiore all’account della carta oun’operazione di CREDIT eccessiva rispettoal MAXBALANCE.

• MAC is wrong: il certificato MAC relativoall’operazione di CREDIT richiesta è errato,quindi è probabile che la Credit Key non siacorretta. Prestare particolare attenzione a que-sto caso, perché se si continua ad insistere conl’operazione di CREDIT, la Credit Key sibloccherà e la carta risulterà inutilizzabile.

• Credit Key locked: la carta è stata bloccata edè quindi inutilizzabile a causa della richiesta diun numero eccessivo di operazioni di CRE-DIT con il MAC errato.

Infine, nel caso in cui il file credit.txt non fossepresente nella cartella dell’applicazione, verràvisualizzato il messaggio Missing credit.txt e nonsarà possibile eseguire l’applicazione ACOS2-PURSE.

Concludiamo ricordando che, nella struttura pro-posta, per l’operazione di CREDIT è necessarioil calcolo del MAC, basato sull’applicazione del-l’algoritmo DES ed implementato nel softwareACOS2-PURSE. L’operazione di DEBIT invecenon è vincolata ad alcun meccanismo di autenti-ficazione e quindi può essere sempre eseguita,anche se non si è in possesso della Credit Key.Ne consegue che il software ACOS2-PURSE

Fig. 1

MAC. Si tratta della ACOS-SAM, che ha un’ar-chitettura basata sulla sua sorella minoreACOS2, che permette di implementare un moto-re crittografico così da alleggerire la CPU dellarelativa mole di lavoro e dalla conoscenza dellechiavi che vengono memorizzate nella ACOS-SAM stessa.In particolare, la carta dispone del comando“PREPARE ACOS ACCOUNT TRANSAC-TION” che, ricevuto in input l’importo da accre-ditare, calcola in base alla Credit Key in suo pos-sesso il MAC di cui la carta ACOS2 necessita pereseguire l’operazione di CREDIT, come ampia-mente descritto nelle scorse puntate. Il MAC può essere poi letto mediante il coman-do “GET RESPONSE SAM” e passato allaACOS2 per l’operazione di CREDIT. Successivamente presenteremo il progetto di unlettore portatile di smartcard che utilizzal’ACOS-SAM per le finalità descritte; in talesede provvederemo ad approfondire le caratteri-stiche accennate del modulo.

può essere utilizzato in due diver-se modalità: ad esempio potrem-mo fornire in comodato d’uso adun bar o ad una tavola calda talesistema per la gestione delle con-sumazioni senza comunicare laCredit Key, consentendo quindi ilsolo addebito degli importi. La ricarica delle carte esauriteverrebbe invece eseguita diretta-mente da noi, in possesso dellachiave corretta.

La Smart CardACOS-SAMIl meccanismo di accredito degliimporti sulla smart card ACOS2 èstato agevolato dall’implementazionenel software dell’algoritmo DES.Se per la gestione degli importi sulle carte voles-simo invece utilizzare un dispositivo custom,come ad esempio una scheda a micro controllo-re, ci troveremmo di fronte a due problemi.Innanzitutto sarebbe necessario implementarenel firmware i meccanismi di autentificazione equindi almeno l’algoritmo DES, con tutte lecomplicazioni del caso. Ma, anche se la programmazione assemblerfosse il nostro pane quotidiano, un secondo pro-blema da non sottovalutare è che la Credit Keydovrebbe essere memorizzata nel firmware a dis-capito della sicurezza; inoltre la modifica di que-st’ultima renderebbe necessario l’aggiornamentodel firmware di ogni dispositivo distribuito.Il produttore delle carte, così come fatto da altregrandi aziende, ha ideato una particolare smartcard in formato “SIM” che può essere utilizzatacome supporto, in grado di eseguire le operazio-ni di calcolo richieste, come l’elaborazione del


Corso SM

AR

TCA

RD

Corso SM

AR

TCA

RD

CCCCaaaarrrraaaatttttttteeeerrrriiiisssstttt iiiicccchhhheeee tttteeeeccccnnnniiiicccchhhheeee ddddeeeellll llll ��AAAACCCCOOOOSSSS3333--SSSSAAAAMMMM

� Conforme allo standard ISO 7816 Parti 1, 2, 3 e 4;� Baud rate selezionabile tra 9.600, 14.400, 28.800,

57.699 e 115.200 bps;� 8 K di memoria EEPROM per dati;� Supporta le strutture definite da ISO 7816 Parte 4:

Trasparente, Lineare fisso, Lineare variabile, Ciclico;� Supporta DES e Triple DES;� Mutua autenticazione con generazione di chiavi di

sessione;� Accesso sicuro tramite gerarchia multilivello;� Struttura di dati dedicata opzionale per applicazioni di

pagamento ad alta sicurezza;� Anti-tearing fatto su Header file e comandi PIN.

Teoria e pratica delle SMART CCARD -...

Documents

Transcript of Teoria e pratica delle SMART CCARD -...