|
Appunti informatica |
|
Visite: 1720 | Gradito: | [ Medio appunti ] |
Leggi anche appunti:Il provider Bouncy CastleIl provider Bouncy Castle Per quanto riguarda i provider, oltre a quello della Dalle Smart Card alle Java CardDalle Smart Card alle Java Card Il principale limite delle Smart Card era Applicazioni tipiche delle Smart CardApplicazioni tipiche delle Smart Card Inizialmente introdotte in Europa |
Le prime Smart Card prodotte in grande quantità erano per lo più semplici memory card, non realmente "smart" in quanto non contenevano un microprocessore; erano "embedded" con un chip di memoria accompa-gnato o meno da una logica non programmabile. Queste carte, ancora og-gi in commercio, possono contenere fino a 4Kb di dati e sono principal-mente utilizzate come carte prepagate per servizi di telefonia pubblici.
Dalle memory card si è poi passati alle microprocessor card che invece contengono, oltre ad una memoria, anche un processore contenuti su un unico microchip. La Smart Card diviene dunque un dispositivo in grado sia di memorizzare dati che di eseguire semplici applicazioni.
Poichè non contiene una sorgente di alimentazione, affinchè la carta divenga attiva è necessario connetterla con un card reader; una volta connessa, dopo le necessarie procedure di reset, la carta resta passiva, in attesa di ricevere comandi da una client application (o host application) attraverso il card reader.
La Smart Card può essere contact o contactless a seconda se comunica
Figura 2.1 : Modello di Smart Card contact
col card reader rispettivamente mediante una serie di contatti elettrici op-pure mediante un segnale in radio frequenza.
Figura 2.2 : Modello di Smart Card contactless
Dato che la Smart Card contact deve essere inserita in un dispositivo di accettazione (Card Acceptance Device o CAD) in modo corretto secondo un verso prestabilito, solitamente vengono utilizzate in situazioni che non richiedono una particolare velocità di operazione. Nel seguito ci dedicheremo ad analizzare il modello delle Smart Card contact in quanto risultano quelle più comunemente utilizzate.
All'interno del microchip della Smart Card possiamo individuare i seguenti componenti:
r Un microprocessore, in genere con architettura a 8 bit anche se sul mercato sono presenti carte con processore a 32 bit;
r Diverse tipologie di memoria:
ROM (Read Only Memory) il cui contenuto è deciso in fase di produzione della carta ed in genere contiene il sistema operativo e qualche applicazione specifica di quest'ultimo;
EEPROM (Electrical Erasable Programmable Read Only Me-mory) usata come memoria non volatile in quanto il suo conte-nuto resta valido anche quando l'alimentazione della carta viene interrotta. È utilizzata dalle carte multi-applicative per memoriz-zare il codice delle applicazioni che vengono aggiunte alla carta in tempi successivi alla sua produzione.
RAM (Random Acces Memory) usata come memoria volatile adatta a contenere lo heap e lo stack ed in generale come spa-zio di lavoro temporaneo; il suo contenuto non si preserva quan-do l'alimentazione viene meno e dunque le informazioni memo-rizzate temporaneamente in essa, al calo dell'alimentazione vanno perdute.
(opzionale) Un coprocessore dedicato alle operazioni di critto-grafia per rendere tali operazioni più veloci.
Figura 2.3 : Struttura del microcomputer di una Smart Card
Abbiamo detto che per poter interagire con una Smart Card occorrono dei
dispositivi che consentono di instaurare una comunicazione con la carta.
Questi dispositivi presentano delle fessure (slot) in cui viene inserita la Smart Card creando una connessione con i contatti della carta che per-mette di comunicare con essa.
Si distinguono due categorie di dispositivi per le Smart Card: lettori di Smart Card (card readers) e terminali per Smart Card (card terminals).
I lettori di Smart Card sono impiegati come mezzo di comunicazione tra la Smart Card e un dispositivo, in genere rappresentato da un computer.
Essi possono sia scrivere che leggere dati dalla carta.
I card readers presentano da un lato l'interfaccia per comunicare con la
Smart Card e dall'altro l'interfaccia per comunicare con il computer a cui sono connessi. Esistono lettori con interfaccia USB, seriale o parallela, ed
alcuni possono avere anche una tastiera (PIN-pad) per inserire il PIN[1] della carta. Di solito è presente un solo slot ma esistono lettori con due slot usati, per esempio, in applicazioni in cui è necessario inserire una car-ta master per poter lavorare con l'altra carta.
Figura 2.4 : Lettore di Smart Card
I terminali risultano in genere molto più complessi dei lettori e rendono possibile un controllo più stretto degli accessi alle Smart Card. Sono perciò spesso impiegati per i sistemi di pagamento elettronico in cui è richiesto un certo livello di sicurezza. Essi possono lavorare anche senza essere connessi ad altri dispositivi.
Le applicazioni che fanno uso di Smart Card possono essere suddivise in due parti: una parte on-card (su carta) ed una parte off-card (fuori carta).
La prima, localizzata all'interno della carta, può consistere in dati o codice eseguibile, memorizzati durante la fase di inizializzazione della carta (rela-tivamente a carte chiamate a singola applicazione) o in altri momenti (car-te dette a multipla applicazione). Nel caso la parte su carta sia un codice eseguibile, viene eseguito dalla Smart Card e può utilizzare tutti i servizi messi a disposizione dal sistema operativo della carta stessa.
La parte off-card risiede sull 'host dove è connesso il lettore e dialoga con
l'utente e con la parte on-card.
La comunicazione tra carta ed host è half-duplex ovvero i dati possono essere inviati dall'host alla carta oppure dalla carta all'host ma non con-temporaneamente.
Quando un computer comunica con altri computer, questo scambia dei pacchetti di dati (data packets) costruiti seguendo un particolare protocollo di comunicazione, come ad esempio TCP/IP. Allo stesso modo le Smart Card comunicano con l'host utilizzando un particolare protocollo chiamato APDU (Application Protocol Data Unit).
Le Smart Card, una volta inserite in un CAD, non iniziano autonomamente una comunicazione con l'host ma attendono da questo specifiche istru-zioni, mediante command APDU, e rispondono alle istruzioni ricevute mediante response APDU.
Command e response APDU vengono scambiati alternativamente tra host e carta come mostrato nella seguente figura.
Figura 2.5 : Modello di comunicazione con Smart Card
Lo standard ISO 7816-4 [9] definisce i formati degli unici due tipi di APDU previsti: i command APDU ed i response APDU.
Nelle Tabelle 2.1 e 2.2 sono illustrate rispettivamente le strutture dei due tipi di APDU.
Command APDU |
||||||
Header (obbligatorio) |
Body (opzionale) |
|||||
CLA |
INS |
P1 |
P2 |
Lc |
Campo Dati |
Le |
Tabella 2.1 : Struttura del command APDU
La struttura del command APDU possiede un header obbligatorio e un body che può essere presente o meno (opzionale). L'header ed il body contengono i seguenti campi:
INS
(1 byte): specifica un
particolare comando all'interno della clas-se di comandi specificata nel
campo CLA. Come per il campo CLA valori validi per il campo INS sono
definiti nello standard ISO
7816-4 [9]; P1
(1 byte): specifica l'eventuale
primo parametro dell'istruzione definita nei precedenti campi. Può essere
utilizzato anche come campo di input per i dati;P2
(1 byte): specifica l'eventuale
secondo parametro dell'istruzione definita nei precedenti campi. Può
essere utilizzato anche come campo di input per i dati;Lc
(1 byte): questo campo
opzionale indica la lunghezza in byte del campo dati che segue nel command
APDU;Campo Dati
(variabile, pari a Lc
bytes): contiene i dati
(opzionali) da inviare alla carta;Le
(1 byte): questo campo
opzionale contiene la lunghezza in byte dei dati che saranno eventualmente
inviati in risposta.
Tabella 2.2 : Struttura del response APDU |
Come per il command APDU anche il response APDU possiede un body opzionale ed un trailer che invece è obbligatorio. Il body ed il trailer contengono i seguenti campi:
Campo Dati
(lunghezza variabile,
determinata in byte dal campo Le
del command APDU): questo campo
opzionale contiene i dati di ri-torno;SW1
(1 byte): questo campo
obbligatorio specifica lo status word 1;
SW2
(1 byte): questo
campo obbligatorio specifica lo status word 2.I valori dei campi di status word (SW1 e SW2) contengono due byte che rappresentano univocamente un tipo di errore, mentre in caso di successo contengono 0x9000[2].
I valori dei campi di status word (SW1 e SW2) sono definiti nello standard ISO 7816-4 [9].
A livello di applicazione ogni comando viene tradotto in una serie di com-mand APDU, a ciascuno dei quali fa seguito la ricezione delle relative ris-poste della carta sotto forma di response APDU. Ci sono molte APDU, standardizzate in base allo standard ISO, che permettono di dialogare con il sistema operativo della carta, consentono di creare e cancellare file della carta, verificare il PIN, scrivere in file ecc. Ogni programmatore di applica-zioni che fa uso di Smart Card e che usa parti software che risiedono nella carta (diverse dal sistema operativo), ha la necessità di definire le proprie APDU. Ovviamente per ogni APDU definita, il byte CLA deve essere diver-so da tutti quelli delle APDU standardizzate.
Le APDU vengono trasmesse mediante un ulteriore livello di protocollo, il protocollo di livello trasporto (transport protocol) definito nello standard ISO 7816-3 [9]. La struttura dati scambiata tra host e carta mediante il protocollo di trasporto è chiamata transmission protocol data units (TPDU).
I due principali protocolli di trasporto utilizzati comunemente sono il protocollo T=0 e il protocollo T=1.
Il protocollo T=0 fa parte della classe dei protocolli half-duplex asincroni orientati al carattere ed è il più utilizzato dalle carte GSM. Risulta molto semplice e di facile implementazione, caratteristiche rilevanti viste le limi-tate risorse delle carte.
Lo svantaggio tuttavia è di non separare completamente, nella serie dei protocolli usati, il livello soprastante dal livello a cui appartiene. Infatti, do-po aver spedito l'APDU per il comando, è necessaria una ulteriore APDU per ricevere i dati in risposta (la GET RESPONSE). Il fatto che nel livello "application" si è obbligati a generare e spedire una APDU, che ha signi-ficato solo nel livello soprastante "transport", porta alla non completa divi-sione tra i due livelli.
Il protocollo T=1 è piu evoluto del precedente e permette una divisione perfetta dai protocolli di livello superiore. Infatti fa parte della classe di pro-tocolli half-duplex asincroni orientati ai blocchi e quindi rende possibile l'in-capsulamento di ogni APDU e di ogni risposta in un pacchetto dati.
Immediatamente dopo aver ricevuto l'alimentazione, la Smart Card invia all'host un messaggio chiamato Answer to reset (ATR). Questo messaggio invia all'host i parametri necessari per stabilire una corretta comunicazione con la carta.
L'ATR è costituito da almeno 33 byte e contiene informazioni quali il pro-tocollo di trasmissione supportato dalla carta (usualmente T=0 o T=1), la velocità di trasmissione dei dati (data trasmission rate), le caratteristiche hardware della carta come il serial number del chip e tante altre informa-zioni necessarie all'host per instaurare un corretto rapporto con la carta.
Il sistema operativo della Smart Card riceve le APDU che provengono dall'esterno, elabora, genera e invia le risposte. Esso presenta inoltre un File System molto semplice in cui è possibile creare vari tipi di file, cancel-larli, leggere e scrivere in essi. Il formato dello Smart Card File System è definito nello standard ISO 7816-4 [9] ed è composto dai seguenti tre tipi di componenti:
Con questi componenti è possibile creare una struttura gerarchica di file
e directory (vedi Figura 2.6) in cui alla radice è presente sempre un file tipo MF. Ogni file è specificato da un identificatore composto da due byte. E' importante dire che l'intero file system è persistente: rimane cioè valido anche quando la carta non è più alimentata.
Alcune delle operazioni che agiscono sui file sono: SELECT, READ BINARY, WRITE BINARY, UPDATE BINARY, APPEND RECORD etc.
Prima di eseguire qualsiasi operazione su di un file quest'ultimo deve essere selezionato tramite il suo identificatore di due byte.
Ad ogni file sono associate delle condizioni di accesso che specificano le
operazioni fattibili su quel file. Il formato di queste condizioni (access conditions) non sono specificate nello standard ISO e quindi possono variare anche di molto da un costruttore ad un altro.
Figura 2.6 : Struttura del File System secondo ISO 7816-4
Standard come quelli ISO e quelli generati da iniziative industriali sono ne-
cessari per assicurare che le applicazioni per Smart Card, le Smart Card stesse e i lettori di carte siano costruiti secondo un'unica specifica. Senza alcun standard l'interoperabilità tra diversi modelli di carte o di applicazioni o di lettori non sarebbe possibile.
Ecco di seguito riportati i principali standard definiti per le Smart Card.
L'International organization for Standardization (ISO) mantiene anche uno
standard dedicato alle Smart Card. L'ISO 7816 è il più importante e si intitola 'Identification cards - Integrated circuit cards with contacts' [9]. Questo standard si occupa di definire le caratteristiche di una Smart Card, come ad esempio la dimensione e la locazione dei contatti elettrici, i protocolli T=0 e T=1, i comandi che consentono l'accesso alla carta, la sicurezza e la trasmissione dei dati sulla carta, etc.
Lo standard PC/SC (Interoperability Specification for ICCs and Personal
Computer System) [10] ha lo scopo di fornire delle specifiche per l'uso delle Smart Card mediante personal computer.
L'obiettivo principale è quello della interoperabilità delle Smart Card (ICC) con i lettori di Smart Card (IFD, Interface Device) e la cooperazione tra il lettore di carte ed il sistema operativo del Personal Computer. Nelle ver-sioni Windows 98 e Windows 2000 questo standard è parte integrante del sistema operativo stesso.
Appunti su: |
|
Appunti c | |
Tesine internet | |
Lezioni database | |