VAI AL CAPITOLO 5 :JAVA CARD (CARTE MULTI APPLICAZIONE)
CAPITOLO 4 Sistemi Operativi per Smart Card
4.1 Descrizione dei componenti (SmarTEC OS)
Aggiornamento di Servizi
READ, WRITE, UPDATE, ERASE BINARY
READ, WRITE, APPEND, UPDATE RECORD.
GET DATA, PUT DATA
SELECT FILE
VERIFY
GET CHALLENGE, INTERNAL AUTHENTICATE, EXTERNAL AUTHENTICATE
MANAGE CHANNEL
GET RESPONSE, ENVELOPE
Crittografia simmetrica
Crittografia Asimmetrica
Codice di autenticazione dei messaggi (MAC)
Digital Signature (firma digitale)
CardOS/M3
CardOS/M4
CAPITOLO 4 Sistemi Operativi per Smart Card
4.1 Descrizione dei
componenti
I Sistemi Operativi per Smart Card sono stati sviluppati dai fornitori della carta stessa fin dalle prime versioni risalenti ad una ventina di anni orsono. Dal 1997 sono disponibili soluzioni con Sistemi Operativi sviluppati da terze parti quali MULTOS e Windows per Smart Card. Inizialmente erano scritti in linguaggio assembler e presentavano una API (Application Programming Interface) o un set di comandi predefiniti dallo sviluppatore, codificati nella ROM e non modificabili. In seguito si utilizzarono soluzioni che permettevano l’aggiornamento di procedure del Sistema Operativo attraverso il caricamento nella EEPROM di codici sostitutivi (subroutine). In realtà solo pochi sviluppatori avevano il permesso di modificare le funzionalità della carta; le modifiche restavano vincolate alla particolare ROM-Mask (versione di Sistema Operativo) presente sulla carta. Nel 1995 si tento un approccio differente che si basava sulla creazione di un processore astratto con particolari requisiti di sicurezza (implementato sul processore reale a 8-bit) e che funzionasse nel poco spazio di memoria concesso dalla carta. Lo scopo era quello di creare applet, sviluppate in codice orientato ad oggetti, caricabili sulla carta e interpretate in run time dal processore virtuale. Questo permetteva di aggiungere flessibilità ed alto grado di programmabilità senza compromettere la sicurezza del Sistema Operativo. Una soluzione simile porto alla implementazione di una Java Virtual Machine sulla memoria di una Smart Card (12 Kbyte), ed alla definizione della specificazione JavaCard 1.0 API (marzo 1997).
Come esempio di Sistema Operativo Per Smart Card introdurrò SmarTEC OS, che presenta caratteristiche comuni a molti altri Sistemi attualmente in uso. SmarTEC OS, definito come Sistema Operativo sicuro per Multi Applicazioni, risiede sulla ROM della carta. Sono permesse modifiche al codice presente sulla memoria EEPROM da parte dello sviluppatore, ma solo con forti controlli all’atto del caricamento delle applicazioni. La verifica di sicurezza avviene per mezzo di una firma crittografica che garantisce la buona fede dello sviluppatore (non sono permesse modifiche a livello utente). In figura 14 sono mostrati tutti i componenti del Sistema che saranno descritti di seguito.
Memory Manager
Il gestore della memoria fornisce un servizio per applicazioni e per il Sistema Operativo che consente l’accesso controllato alla memoria. Le applicazioni sono in grado di allocare e liberare celle dinamicamente senza necessità di pre-allocare spazio di memoria durante l’installazione.
I/O Manager
Il gestore di Input/Output contiene le primitive di comunicazione della carta (tutti i dati trasferiti passano attraverso questo servizio). Nel caso si debbano inserire nuovi protocolli di trasporto il codice relativo all’I/O manager viene sostituito lasciando inalterate le altre componenti.
File Manager
Questo servizio si occupa dell’immagazzinamento dei dati, contiene le strutture dei file di sistema e quelle definite dallo sviluppatore (private). Fornisce spazio di memoria alle applicazioni per l’estensione di file esistenti e la cancellazione di file non utilizzati.
Security Manager
Fornisce le primitive per implementare modelli di sicurezza definiti dallo sviluppatore. Supporta metodi di identificazione basati su DES, Triple DES, DSA ed RSA (512,1024 bit). Sono disponibili anche metodi RSA per scambio di chiavi crittografiche e generazione di numeri casuali.
Transaction Manager
Fornisce meccanismi per transazioni quali Commit e Rollback necessari ad operare scambi finanziari. In caso di errori o cadute di alimentazione la transazione viene invalidata (rollback) e lo stato della carta è riportato alle condizioni iniziali.
Message Manager
Fornisce un meccanismo per il passaggio dei messaggi tra Sistema Operativo ed applicazioni. Questo permette il corretto instradamento dei messaggi dal I/O Manager alla corretta applicazione.
Application Manager
Permette la corretta installazione delle applicazioni e la loro registrazione per ricevere messaggi. Una volta registrata, l’applicazione riceve e reagisce ai messaggi ad essa indirizzati.
Patch Manager
Permette l’aggiornamento delle applicazioni presenti sulla
carta e la modificati servizi del Sistema Operativo. Questo può
essere fatto attraverso un terminale sicuro o su una rete (utilizzando
codice crittografato e correttamente decodificato dalla carta).
Aggiornamento di Servizi
Le modifiche sono fatte scaricando sulla memoria EEPROM
un Patch e cambiando il vettore della tavola di puntatori che indirizzano
i servizi sulla carta. In figura 15 è mostrata la tabella dei puntatori
contenuta nella EEPROM (per permetterne la modifica dei vettori). Il servizio
I/O Manager #1 (presente sulla ROM-Mask) è sostituito dall’aggiornamento
I/O Manager #2 (salvato sulla EEPROM). Il puntatore I/O è modificato
con il nuovo valore indicante l’indirizzo di memoria del servizio sostitutivo.
In questo modo le chiamate di sistema vengono riferite al nuovo codice,
mentre il vecchio codice resta inerte sulla ROM. Sempre in figura 15 si
vede una tipica suddivisione della EEPROM per contenere i file (dati) di
applicazioni comuni. Nell’esempio si hanno:
Questo modello è largamente seguito per garantire
flessibilità e robustezza nella personalizzazione di una Smart Card.
Diverse soluzioni prevedono funzionalità minime codificate in ROM
(Sistema Operativo) e maggiore dimensione della EEPROM per fornire servizi
altamente personalizzabili. SmarTEC OS contiene in ROM servizi (proprietari)
aggiuntivi denominati Smart Token SW e CKM Functions che possono essere
pensati come librerie di supporto al Sistema Operativo. Nel paragrafo successivo
sono trattati comandi che definiscono un substrato su cui costruire soluzioni
più o meno articolate.
TORNA ALL'INDICE DEL
CAPITOLO ATTUALE (CAP 4 : SISTEMI OPERATIVI PER SMART CARD)
Lo standard ISO 7816-4 indica un insieme di 18 comandi
che il Sistema Operativo di una Smart Card deve supportare. Una sottoparte,
spesso tutti, di questi comandi è presente su ogni tipo di carta
e l’introduzione di macchine virtuali (JavaCard, BasicCard) prevede un
ampliamento delle funzionalità offerte dal Sistema Operativo. I
comandi vengono inviati alla carta per mezzo di APDU di comando ed il Sistema
Operativo crea, e restituisce, un APDU di risposta. La normativa fornisce
solo indicazioni generali sui codici a Byte utilizzati e sui meccanismi
base supportati, ma non specifica come implementare tali soluzioni. Si
possono trovare molti Sistemi Operativi che non supportano tutte le funzioni,
ma solo un insieme ristretto. Solitamente un fornitore di Smart Card possiede
un Set di Carte, con Hardware (ROM, EEPROM) e Software (ROM-Mask) differenziato,
adatto a diverse soluzioni finali. Di seguito descrivo un insieme di comandi
che in forma simile o equivalente sono la base delle funzioni offerte da
un Sistema Operativo per Smart Card.
READ, WRITE, UPDATE, ERASE BINARY
Questi quattro comandi hanno sintassi simile e sono utilizzati
solo per file di tipo transparent. Permettono di modificare o leggere il
contenuto di una file (EF transparent) presente sulla carta.
READ BINARY
Questo comando richiede la lettura del contenuto (o parte
di esso) di un Elementary File di tipo transparent. Quando il comando contiene
un identificatore di EF valido e lo stato di sicurezza è soddisfatto
(attributi e condizioni) il Sistema Operativo risponde con un APDU di risposta
contenente il file selezionato. La sintassi dell’APDU di comando, per la
READ BINARY, prevede il valore B0 per il Byte INS; i parametri P1 e P2
individuano il tipo di accesso (Identificatore, Path Name, ecc); Lc (che
rappresenta la lunghezza dei dati del comando) e Data (dati di comando)
sono posti a 0; infine Le (che rappresenta la lunghezza dei dati di risposta)
contiene il numero di Byte che si vogliono leggere. L’APDU di risposta
contiene i Byte richiesti (in numero pari a Le) nel campo dati e i due
Byte di stato SW1 e SW2 (che specificano la correttezza, o eventuali errori,
in lettura).
| CLA | Tipo di classe |
| INS | 'B0' |
| P1-P2 | Tipo di accesso |
| Lc | Vuoto |
| Data | Vuoto |
| Le | Numero di Byte |
WRITE BINARY
Questo comando permette di scrivere un valore binario in un EF (di tipo transparent), con la possibilità di effettuare operazioni logiche (OR e AND) tra i bit presenti sulla carta e nel file da scrivere. La sintassi per APDU di comando e risposta è simile alla precedente. Se il file è correttamente indirizzato e le condizioni di sicurezza sono rispettate, tale file viene selezionato come file corrente ed il comando viene eseguito.
APDU di comando
| CLA | Tipo di classe |
| INS | 'D0' |
| P1-P2 | Identificatore ed offset |
| Lc | Dimensione del campo dati |
| Data | Stringa di dati da scrivere |
| Le | Vuoto |
UPDATE BINARY
Questo comando sostituisce i bit presenti nel file (solo se di tipo transparent) con quelli contenuti nell’APDU di comando. La sintassi è equivalente a quella della Write Binary con eccezione per il Byte INS (posto a D6).
ERASE BINARY
Questo comando pone il file (o parte di esso) in stato logico cancellato, il byte INS contiene 0E.
L’APDU di risposta è identico per questi comandi con l’eccezione della READ BINARY che possiede un campo dati non vuoto
APDU di Risposta
| Data | Vuoto o dati letti |
| SW1-SW2 | Byte di stato |
READ, WRITE, APPEND, UPDATE RECORD.
Questi quattro comandi permettono di modificare, e leggere, i dati contenuti in file di tipo non transparent (con record a dimensione fissa o variabile). Presentano sintassi simile per indirizzare il file ed il record su cui operare. Il comando chiede alla carta di verificare attributi condizioni di accesso al file, quali correttezza di indirizzamento e possibilità di lettura/scrittura. Dopo tale controllo il file è selezionato come file corrente; se invece il comando è lanciato mentre esiste un file corrente viene eseguito senza necessità di indirizzamento. Le modalità di utilizzo permettono la gestione dei record come indicato nel capitolo precedente.
Il comando READ RECORD permette la lettura di uno o più record, che sono inviati dalla carta per mezzo di un APDU di risposta. La sintassi di questi APDU è mostrata di seguito per chiarire l’indirizzamento ed i messaggi di risposta. Per la lettura il campo dati è lasciato vuoto, le indica il Numero di Byte da leggere e P2 consente una selezione di particolari modalità operative.
Il comando WRITE RECORD permette la scrittura di un record con modalità uguale a quella vista per la WRITE BINARY (su Byte) e sintassi di selezione uguale alla READ RECORD. Tale similitudine può essere utilizzata per comprendere anche i comandi di UPDATE RECORD e APPEND RECORD. In particolare l’ultimo comando (APPEND) permette l’inserimento di un nuovo record come successivo ad uno specificato.
APDU di Comando READ RECORD
| CLA | Tipo di classe |
| INS | 'B2' |
| P1 | Numero di record o identificatore del primo record da leggere ('00' indica il record corrente) |
| P2 | Controllo (vedi seguito) |
| Lc | Vuoto |
| Data | Vuoto |
| Le | Numero di Byte da leggere |
Funzione del Parametro P2
| b8 b7 b6 b5 b4 b3 b2 b1 | Significato |
| 0 0 0 0 0 -- -- -- | EF correntemente selezionato |
| x x x x x -- -- -- | EF con identificatore corto |
| 1 1 1 1 1 -- -- -- | Riservato per Uso Futuro (RFU) |
| -- -- -- -- -- 1 x x | Uso del Numero di record contenuto in P1 |
| -- -- -- -- -- 1 0 0 | Leggi record P1 |
| -- -- -- -- -- 1 0 1 | Leggi tutti i record da P1 fino all’ultimo |
| -- -- -- -- -- 1 1 0 | Leggi tutti i record dal’ultimo a P1 |
| -- -- -- -- -- 1 1 1 | RFU |
| -- -- -- -- -- 0 x x | Uso dell’indentificatore di record P1 |
| -- -- -- -- -- 0 0 0 | Leggi il primo record indicato |
| -- -- -- -- -- 0 0 1 | Leggi l’ultimo record indicato |
| -- -- -- -- -- 0 1 0 | Leggi il prossimo record indicato |
| -- -- -- -- -- 0 1 1 | Leggi il precedente record indicato |
GET DATA, PUT DATA
Il comando GET DATA è usato per ottenere un oggetto dati di un determinato contesto, ad esempio dati relativi ad una specifica applicazione (identificata da un Dedicated File). I dati possono essere contenuti in un singolo TLV o catene di TLV come descritto precedentemente. La sintassi è indicata di seguito.
APDU di Comando
| CLA | Tipo di classe |
| INS | 'CA' |
| P1-P2 | Vedi sotto |
| Lc | Vuoto |
| Data | Vuoto |
| Le | Numero di Byte in risposta |
P1 e P2 permettono di selezionare il tipo di TLV utilizzato attraverso la suddivisione in intervalli di valori (mostrati di seguito).
Utilizzo di P1 e P2
| Range di P1-P2 | Significato |
| '0000'-'003F' | RFU |
| '0040'-'00FF' | BER-TLV (1 byte) in P2 |
| '0100'-'01FF' | Dati della applicazione (codice proprietario) |
| '0200'-'02FF' | TLV semplice in P2 |
| '0300'-'3FFF' | RFU |
| '4000'-'FFFF' | BER-TLV (2 bytes) in P1-P2 |
I valori di P1 e P2 compresi tra "0100" e "01FF" sono riservati per identificatori di dati relativi ad applicazioni proprietarie (servizi) o test interni alla carta. Quelli indicati con TLV e BER-TLV sono solitamente valori di puntatori ad oggetti dati e sono utilizzati per selezionare dati in contesti strutturati ad oggetti (Javacard).
Il comando PUT DATA permette di immagazzinare dati
oggetto in un contesto specifico. La suddivisione dei valori di P1 e P2
è la stessa di quella vista per GET DATA, mentre la modalità
di immissione dei dati (Update, Append, Write, OR, AND) è indicata
dal metodo contenuto nell’oggetto indirizzato.
SELECT FILE
Questo comando permette di connettere un file corrente
con un canale logico, selezioni successive di tale file possono essere
fatte attraverso tale canale. Selezionando un DF (Dedicated File) con questo
comando lo si pone in stato di DF corrente e selezioni di un EF appartenente
a tale DF possono utilizzare il canale logico costituito. Se la selezione
avviene direttamente su un EF si crea una coppia di file correnti costituita
dall’ EF e dal DF a cui è collegato. Normalmente, dopo un Reset
della carta, il file selezionato come corrente è il Master File
(eccezioni possono essere definite nell’ ATR, risposta al reset). Durante
la selezione di un file possono essere modificate le condizioni di accesso
ai dati. Per esempio entrando in un nuovo dominio di sicurezza può
essere richiesta la chiave di accesso a tali dati (come indicato nel capitolo
precedente).
APDU di Comando
| CLA | Tipo di classe |
| INS | 'A4' |
| P1 | Controllo di selezione |
| P2 | Controllo di selezione |
| Lc | Vuoto o dimensione dei dati seguenti |
| Data | Dati di indirizzamento in accordo con P1-P2
File identifier Path dal MF Path dal corrente DF DF name |
| Le | Vuoto o massima dimensione dei dati attesi in risposta |
I parametri P1 e P2 consentono di scegliere la modalità
di indirizzamento del file da selezionare ed influenzano il contenuto del
campo dati. In particolare P1 permette di scegliere l’indirizzamento e
P2 indica il record da selezionare. Di seguito sono mostrate le possibili
alternative.
Utilizzo dei parametri P1
| b8 b7 b6 b5 b4 b3 b2 b1 | Significato |
| 0 0 0 0 0 0 x x | Selezione con Identificatore |
| 0 0 0 0 0 0 0 0 | Selezione di MF, DF o EF (data = identificatore o vuoto) |
| 0 0 0 0 0 0 0 1 | Selezione di un figlio di DF (data = identificatore DF) |
| 0 0 0 0 0 0 1 0 | Selezione di EF sotto il corrente DF (data = identificatore EF) |
| 0 0 0 0 0 0 1 1 | Selezione del DF padre del corrente DF (data) |
| 0 0 0 0 0 1 x x | Selezione con DF name |
| 0 0 0 0 0 1 0 0 | Selezione diretta conDF name (data = DF name) |
| 0 0 0 0 1 x x x | Selezione con path |
| 0 0 0 0 1 0 0 0 | Selezione da MF (data = path senza identificatore del MF) |
| 0 0 0 0 1 0 0 1 | Selezione dal corrente DF (data = path senza identificatore del corrente DF) |
| Altri valori | RFU |
VERIFY
Questo comando permette di confrontare dati forniti dall’esterno (dispositivo lettore) con quelli presenti sulla carta (per esempio un controllo sulla password). La verifica deve avvenire all’interno della carta per non trasferire all’esterno informazioni riservate. Lo stato di sicurezza associato ad alcune informazioni può essere modificato se la verifica è confermata. Ulteriori accessi ai dati possono essere fatti senza ripetere il comando. Solitamente una comparazione non corretta viene registrata sulla carta e un contatore permette un limitato numero di tentativi. Di seguito sono indicate la sintassi e le funzioni di questo comando.
APDU di Comando VERIFY
| CLA | Tipo di classe |
| INS | '20' |
| P1 | Solo P1='00' è valido (altri valori sono RFU) |
| P2 | Vedi sotto |
| Lc | Vuoto o lunghezza del campo data |
| Data | Vuoto o dati di verifica |
| Le | Vuoto |
Valori associati a P2
| b8 b7 b6 b5 b4 b3 b2 b1 | Significato |
| 0 0 0 0 0 0 0 0 | Nessuna informazione data |
| 0 -- -- -- -- -- -- -- | Dati di carattere globale (esempio: password della carta) |
| 1 -- -- -- -- -- -- -- | Dati di tipo specifico (esempio : password dello specifico DF) |
| -- -- -- x x x x x | Numero di riferimento dei dati |
| Altri valori | RFU |
Il parametro P1 assume valore 00, mentre P2 permette di
specificare il contenuto del campo dati come indicato sopra. Se non è
data nessuna informazione P2=00 significa che esiste un solo tipo di verifica
possibile (valida per tutti gli accessi). Il numero di riferimento dati
si riferisce ad un numero di Password (nel caso di Password multiple) o
ad un Identificatore corto di File.
GET CHALLENGE, INTERNAL AUTHENTICATE, EXTERNAL AUTHENTICATE.
Il comando GET CHALLENGE permette di stabilire una connessione sicura tra un dispositivo lettore e la carta. La carta utilizza un numero casuale combinato ad algoritmi crittografici (di tipo esponenziale) per garantire la sicurezza sulla provenienza dei messaggi tra carta e lettore. Tale comando è utilizzato, in combinazione agli altri due, per effettuare una mutua autenticazione (carta/lettore) e permettere il passaggio di dati riservati. Solitamente questo comando ha effetto solo sul comando successivo e deve essere ripetuto più volte in caso si debbano inviare serie di comandi di autentificazione.
L’APDU di comando contiene valore "B4" nel Byte INS e
"00 00" per P1 e P2
Il comando INTERNAL AUTHENTICATE inizia la computazione dei dati di autenticazione utilizzando i dati ricevuti dal lettore (esempio il numero casuale dato dal lettore), una chiave crittografica interna e uno specifico algoritmo crittografico. Una chiave collegata al Master File può autenticare l’intera carta, mentre chiavi collegate a DF possono autenticare una specifica applicazione. L’esito di questo comando è di tipo booleano (si o no) e serve a definire condizioni di accesso successive sui dati presenti nella carta. Questo meccanismo permette di verificare la provenienza (lo sviluppatore) di una specifica applicazione e ad instaurare una connessione sicura tra applicazioni sulla carta e sul lettore (spesso collegato ad Host remoti).
APDU di Comando
| CLA | Tipo di Classe |
| INS | '88' |
| P1 | Indica l’algoritmo sulla carta |
| P2 | Indica la chiave |
| Lc | Lunghezza del campo dati |
| Data | dati relativi alla autenticazione (dalla GET CHALLENGE) |
| Le | Massimo numero di Byte in risposta |
I parametri P1 e P2 sono utilizzati in modo analogo al
comando VERIFY.
Il comando EXTERNAL AUTHENTICATE aggiorna lo stato
di sicurezza della carta dopo avere ottenuto un esito positivo. Similmente
al comando precedente utilizza i dati della GET CHALLENGE, la chiave e
l’algoritmo specificati; anche in questo caso i tentativi falliti vengono
registrati sulla carta. La sintassi è simile alla INTERNAL AUTHENTICATE.
La differenza tra i due comandi è che una istruzione autentica le
informazioni interne, l’altra il lettore.
MANAGE CHANNEL
Questo comando apre e chiude canali logici sulla carta.
Ossia, percorsi che identificano uno specifico file senza ricorrere all’indirizzamento
effettivo ad ogni lettura/scrittura, ma attraverso la definizione dei parametri
all’atto della creazione del canale. Il comando ha due funzioni: open e
close. La prima apre un nuovo canale logico (ne esiste uno base sempre
aperto) con possibilità di definizione del numero da parte della
carta o del lettore; la seconda chiude un canale logico precedentemente
aperto. Diversi canali logici possono presentare stato di sicurezza differente.
Un esempio è rappresentato da diverse applicazioni su terminale
che accedono a dati sulla carta ma possiedono livelli di accesso diversi
(dottore e paziente del caso sanitario); sono aperti due canali logici
in modo che non possano avvenire errori nella gestione dei dati presenti
sulla carta.
APDU di Comando
| CLA | Tipo di Classe |
| INS | '70' |
| P1 | P1='00' per aprire un canale logico
P1='80' per chiudere un canale logico (altri valori sono RFU) |
| P2 | '00'-'03' (altri valori sono RFU) |
| Lc | Vuoto |
| Data | Vuoto |
| Le | '01' se P1-P2= "0000"
Vuoto se P1-P2!='0000' |
GET RESPONSE, ENVELOPE
Questi due comandi sono orientati alla trasmissione e servono a definire protocolli per APDU non supportati dallo standard ISO 7816.
GET RESPONSE è usato per trasmettere APDU
dalla carta al dispositivo lettore che altrimenti non potrebbero essere
trasmessi. Di seguito è mostrata la sintassi.
APDU di comando
| CLA | Tipo di classe |
| INS | 'C0' |
| P1-P2 | '0000' (altri valori sono RFU) |
| Lc | Vuoto |
| Data | Vuoto |
| Le | Massimo numero di Byte attesi |
APDU di risposta al GET RESPONSE
| Data | APDU (o parte di esso) in accordo a Le |
| SW1-SW2 | Byte di stato |
Il comando ENVELOPE svolge una funzione simile
al precedente e permette di inviare APDU (o parti di esso) o stringhe di
dati che altrimenti non sarebbero trasmissibili con i protocolli forniti.
In questo caso è la carta che invia parti di APDU all’interno del
comando stesso. La risposta è uguale a quella precedente.
APDU di Comando
| CLA | Tipo di classe |
| INS | 'C2' |
| P1-P2 | '0000' (altri valori sono RFU) |
| Lc | Dimensione del campo dati |
| Data | APDU (o parte di esso) |
| Le | Vuoto o massimo numero di Byte attesi |
TORNA ALL'INDICE DEL
CAPITOLO ATTUALE (CAP 4 : SISTEMI OPERATIVI PER SMART CARD)
I Sistemi operativi per Smart Card devono spesso offrire
funzioni crittografiche per garantire la riservatezza dei dati in esse
contenuti. Sono utilizzati diversi tipi di algoritmi che si basano principalmente
su due tecniche crittografiche (simmetrica ed asimmetrica).
Crittografia simmetrica
Questa tecnica utilizza una singola chiave per codificare
e decodificare i dati contenuti nella carta. Il più diffuso algoritmo
simmetrico è il DES (Data Encryption Standard) che presenta vantaggi
in termini di tempo computazionale, sicurezza e facilita di implementazione
in Hardware (e Software). Tale algoritmo opera su un di 8 Byte ed opera
una codifica utilizzando una chiave di dimensioni variabili. In figura
16 è mostrata la codifica di 8 Byte dati con chiave della stessa
dimensione. Il testo codificato ha le stesse dimensioni del testo in chiaro
(dati iniziali). Conoscendo algoritmo e testo codificato è possibile
decodificare il messaggio anche senza il possesso della chiave, ma il tempo
necessario alla decifrazione è fortemente influenzato dalla lunghezza
della chiave.
Dimensioni di 56 bit sono generalmente utilizzate per
immagazzinare dati riservati sulla carta; Anche riuscendo ad ottenere i
dati contenuti sulla carta occorrerebbe conoscere la chiave e l’algoritmo
utilizzato. Questo tipo di algoritmo può essere utilizzato nella
variante Triple DES (3DES), con più livelli di codifica dei dati
e chiavi di dimensione doppia, garantendo ancora maggiore sicurezza. Il
problema principale di questo tipo di algoritmi è rappresentato
dal fatto che la chiave deve essere posseduta sia dal mandante che dal
ricevente del messaggio. In tal modo si deve garantire la riservatezza
sulla stessa chiave da parte di due entità distinte.
Crittografia Asimmetrica
Con questa tecnica sono utilizzate due chiavi crittografiche,
una per codificare i dati ed una per decodificarli. Le due chiavi sono
matematicamente correlate in modo che solo i messaggi codificati con una
chiave possono essere decodificati con l’altra. L’algoritmo più
diffuso è Il RSA (Rivest, Shamir, Adleman). In figura 18 è
mostrato uno schema di codifica e decodifica in cui clear text rappresenta
il messaggio originale (messaggio in chiaro), mentre il messaggio codificato
è indicato come ciphered text.
Il messaggio è codificato usando una chiave pubblica
distribuita a tutti i mandanti dal ricevente. Tale messaggio è poi
decodificato con la chiave privata che resta unica e permette di ottenere
un messaggio in chiaro. In questo modo solo il possessore della chiave
privata può decodificare i messaggi. La chiave pubblica viene distribuita
a tutte le entità che desiderano inviare un messaggio che solo il
destinatario può leggere; se una chiave pubblica viene distribuita
a terze parti, si possono solo inviare messaggi e non decodificarli come
avveniva nel caso precedente. Le Smart Card utilizzano questo tipo di algoritmo
in funzioni d’autenticazione di quali digital Signature o in combinazione
con la tecnica precedente. La chiave pubblica è contenuta sulla
carta in modo che risulti poco accessibile all’esterno. L’algoritmo RSA
risulta computazionalmente più complesso del DES e la trasmissione
di dati in tale codifica richiederebbe alla carta lunghi tempi di elaborazione.
Solitamente si usano algoritmi asimmetrici per trasmettere chiavi per algoritmi
simmetrici; una volta che entrambe le parti possiedono una chiave uguale
(DES), generata anche come numero casuale, si può stabilire una
connessione sicura e trasmettere messaggi codificati simmetricamente.
Codice di autenticazione dei messaggi (MAC)
Un MAC è il valore di un blocco di 8 Byte generato
per un singolo messaggio da un algoritmo di tipo simmetrico. Tale valore
è ottenuto per mezzo della chiave condivisa, dell’algoritmo specifico
e del messaggio da inviare (in chiaro). Il messaggio è trasmesso
accodando il MAC in modo che il ricevente possa confrontarlo con quello
calcolato all’atto del ricevimento (utilizzando la propria chiave). Ottenendo
due MAC identici si può essere certi che chi ha inviato il messaggio
sia in possesso della chiave condivisa ed il messaggio è autenticato.
Digital Signature (firma digitale)
Gli algoritmi simmetrici visti prima permettono di autenticare
messaggi e costituiscono la base per effettuare una certificazione sulla
provenienza del messaggio (come nel caso di una firma tradizionale). Se
un MAC (codice unico associato al messaggio) viene codificato con un RSA
utilizzando la chiave privata del mandatario si ottiene una firma digitale.
La firma generata è unica per ogni entità e può essere
verificata da tutti gli altri soggetti. L’algoritmo solitamente utilizzato
è denominato SHA-1 (Secure Hashing Algorithm) e permette di codificare
un testo in chiaro e di segnarlo utilizzando la chiave privata di un RSA.
La verifica di autenticità viene poi eseguita conoscendo la chiave
pubblica del mandatario. In figura 19 è mostrato un esempio.
Una parte del documento è trattata con un algoritmo
SHA-1 e il risultato viene trattato con un algoritmo RSA (utilizzando la
chiave privata). Il messaggio è poi trasmesso al destinatario, che
effettua una verifica della firma utilizzando una chiave pubblica contenuta
in una memoria di massa o detenuta da un’autorità competente (che
rilascia le chiavi e certifica il processo di autenticazione).
Tutte queste soluzioni sono adottate, in varia forma,
per garantire la sicurezza sulle applicazioni e sui dati presenti sulla
carta. Il Sistema Operativo presente sulla ROM-mask deve garantire che
le operazioni (scelta degli algoritmi e delle chiavi appropriate) siano
portate a termine con sicurezza. Soluzioni più o meno complesse
possono richiedere un elevato carico elaborativo al processore della carta,
e spesso necessitano di coprocessori o microcontrollori a 16 o 32 bit.
TORNA ALL'INDICE DEL
CAPITOLO ATTUALE (CAP 4 : SISTEMI OPERATIVI PER SMART CARD)
Questo Sistema Operativo definito come OSSCA (Operating
System for SmartCard Applications) è distribuito dalla Keycorp con
carta e software per sviluppare le soluzioni. Come per SmarTEC OS è
data la possibilità di inserire applicazioni personalizzate all’interno
della EEPROM. Le funzionalità offerte sono comuni a quelle viste
in precedenza e comprendono:
La sicurezza dei dati è garantita attraverso i
seguenti meccanismi.
I dati sono contenuti in file che possono essere condivisi
o riservati a particolari applicazioni. Firewall tra le applicazioni e
possibilità di definire dati pubblici (nome del possessore, data
di scadenza della carta). Disabilitazione del caricamento dinamico delle
applicazioni e uso di codici crittografati per validazione di applicazioni.
Disabilitazione della carta in caso di manomissioni o errori sistematici.
Possibilità di impedire l’uso di alcuni comandi ad applicazioni
specifiche.
TORNA ALL'INDICE DEL
CAPITOLO ATTUALE (CAP 4 : SISTEMI OPERATIVI PER SMART CARD)
Questo Sistema Operativo è sviluppato dalla Siemens
in diverse versioni (ROM-Mask) per ottimizzare la dimensione della memoria
in funzione di particolari tipologie applicative. CardOS prevede la versione
CardOS/M3 e CardOS/M4 con funzionalità quasi identiche per la gestione
delle applicazioni e dei loro dati. In particolare CardOS/M4 supporta un
microprocessore SLE66CX con istruzioni crittografiche dedicate per la codifica
e decodifica di dati ad alto livello di sicurezza.
CardOS/M3
Questo Sistema Operativo è definito come multi
funzionale poiché permette la personalizzazione delle applicazioni
presenti sulla carta e delle funzioni supportate. I comandi compatibili
con lo standard ISO 7816 parte 3, 4, 5, 8 e 9 e con PC/SC. Diverse fasi
nello sviluppo della carta permettono di differenziare i comandi ed i servizi
offerti a differenti livelli. Il file System permette di creare un numero
arbitrario di file DF ed EF (compatibilmente con le dimensioni della memoria);
sono permessi fino ad otto livelli di annidamento dei direttori. Un gestore
della memoria si occupa di allocare e disallocare spazio sulla EEPROM e
sulla RAM in funzione delle richieste provenienti dalle applicazioni. L’accesso
ai dati è definibile a 32 livelli di diritto e combinato con funzioni
booleane. Si possono definire accessi condizionati su singoli oggetti e
cambiare i meccanismi di accesso senza perdere i dati contenuti. I servizi
crittografici supportano i principali algoritmi come per SmarTEC OS (RSA,
DES, SHA-1, MAC) e particolari protezioni contro le metodologie di attacco
più comuni. Lo schema di strutturazione della carta (file iniziali
e dati statici) può essere fissato a priori (dal fornitore della
carta) per produzioni su alti volumi o caricato singolarmente dal Master
File (dal fornitore delle applicazioni). Il protocollo di comunicazione
supportato è T=1 mentre T=0 può essere caricato opzionalmente.
I comandi sono quelli visti sopra nel paragrafo 4.2 ed alcuni presenti
nella parte 8 e 9 del ISO 7816. In particolare sono supportati CREATE,
DEACTIVATE, REACTIVATE FILE e GIVE RANDOM. Alcuni comandi per la gestione
della sicurezza riguardano: Signature Generation, Signature Verification,
Hashing, crittografia e generazione di chiavi asimmetriche.
CardOS/M4
Questo Sistema Operativo è uguale al precedente ma offre alcuni servizi crittografici aggiuntivi quali:
TORNA ALL'INDICE DEL CAPITOLO ATTUALE (CAP 4 : SISTEMI OPERATIVI PER SMART CARD)