VAI AL CAPITOLO 6 : MASSC (Architettura per Smart
Card)
CAPITOLO 5 JavaCard (Carte Multi Applicazione)
Ciclo di vita di una JavaCard
JavaCard 2.1
Esempio di Java Card Applet
CAPITOLO 5 JavaCard (Carte Multi Applicazione)
Le carte Multi Applicazione sono un nuovo sviluppo nel
campo delle Smart Card. L’esempio più significativo è rappresentato
dalle JavaCard, da Multos e da Windows for Smart Card. Il nuovo concetto
si basa sull’introduzione di una macchina virtuale, o di un interprete
di linguaggio, nel software presente sulla carta. Tale strato si occupa
di interpretare le istruzioni delle applicazioni presenti sulla carta (scritte
in linguaggio di alto livello).Questo permette di sviluppare applicativi
senza dipendere dal particolare sotto livello Hardware presente sulla carta.
Di seguito tratterò le JavaCard come esempio di sviluppo. Le carte
Multi applicazione offrono vantaggi sulle tradizionali che sono riassumibili
come segue:
Lo svantaggio principale è rappresentato dal
fatto che il funzionamento di una macchina virtuale rende lenta l’elaborazione
dei comandi richiesti alla carta.
Le JavaCard sono Smart Card che possono caricare ed eseguire
un programma scritto in Java. Le modalità di funzionamento sono
simili a quelle viste in precedenza, in cui la carta svolge un ruolo passivo
nel processo di interazione con il terminale remoto. Essa riceve comandi,
li elabora ed emette i risultati, attendendo poi ulteriori istruzioni
o il reset. Una macchina virtuale definita come JCVM (Java Card Virtual
Machine) è implementata sulla ROM-Mask della carta. Tale JVM si
occupa di gestire tutte le risorse della Smart Card, quali memoria ed I/O
e di effettuare le chiamate al Sistema Operativo sottostante. Il linguaggio
supportato dalla JCVM è un subset, in codice a Byte (Byte Code),
del tradizionale linguaggio Java che fornisce funzionalità tipiche
per Smart Card (quelle viste precedentemente). Il vantaggio principale
di questa metodologia è la possibilità di programmare in
linguaggio conosciuto e non basandosi sullo specifico linguaggio della
carta in uso. Questo rende possibile scaricare applicazioni dopo che la
carta è stata distribuita all’utenza senza ricorrere a codici diversi
per carte sviluppate da fornitori differenti. Un esempio è rappresentato
da carte di credito (fornite da una specifica banca) che possono caricare
applicativi sviluppati da entità diverse senza preoccuparsi dell’effettivo
Hardware e Sistema Operativo montato sulla carta. Le tradizionali carte
multifunzionali (ISO compatibili) permettevano aggiornamenti solo
da parte di sviluppatori che possedevano una forte conoscenza dei meccanismi
di basso livello della carta.
In figura 20 è mostrata la struttura di una Java
Card e si può vedere la suddivisione in livelli logici. La parte
Hardware, le funzioni (comandi), ed il Sistema Operativo supportati dalla
carta sono il livello più basso. Seguono la machina virtuale, il
JavaCard Framework e le classi create privatamente. Il JavaCard Framework
rappresenta una standardizzazione delle classi supportate dalla VM (JavaCard
API 2.1) alle quali è possibile aggiungere le classi sviluppate
dai fornitori delle singole soluzioni. La differenza sostanziale tra questa
struttura e quella vista in precedenza per le carte tradizionali risiede
nel fatto che, le funzioni fornite da queste ultime sono in larga misura
già presenti sulla carta (come particolare ROM-Mask del Sistema
Operativo), mentre quelle presenti nelle classi della JavaCard sono quasi
totalmente aggiunte in seguito. Il JavaCard API 2.1 rappresenta un insieme
di classi, inserite sulla ROM della JavaCard, che consentono l’installazione
e l’inizializzazione delle nuove applicazioni e delle classi aggiuntive
(poste in EEPROM) contenenti le funzioni specifiche richieste. Attualmente
le classi supportate comprendono funzionalità per transazioni finanziarie,
per gestioni inter bancarie, per certificazione di applicazioni, e per
pagamenti sicuri su Internet. La presenza di un linguaggio interpretato
permette un controllo, da parte della carta, sulle operazioni svolte da
applicazioni scaricate anche dopo la distribuzione della carta. Nelle carte
tradizionali è necessario un controllo sulla correttezza di funzionamento
di tutte le applicazioni da inserire sulla carta. Questa fase di test è
svolta prima di distribuire la carta e garantisce, in combinazione con
i meccanismi di sicurezza (fire walling) forniti dal Sistema Operativo,
che non vi siano errori durante il funzionamento. L’introduzione di nuove
applicazioni è permessa ma deve essere posta attenzione a possibili
operazioni illecite attuate dalla nuova applicazione immessa. La macchina
virtuale effettua un controllo aggiuntivo sulla legalità di una
funzione richiesta che favorisce la sicurezza delle altre applicazioni
presenti sulla carta.
Ciclo di vita di una JavaCard
La vita della JavaCard comincia quando il Sistema Operativo,
i metodi nativi, le classi base e le applicazioni residenti sono inserite
nella ROM della carta. Tra le informazioni sono inseriti i dati dello specifico
costruttore e identificativi del tipo di ROM-Mask (restituiti di solito
nell’ATR). Una ulteriore inizializzazione viene operata dal fornitore dei
servizi che installa applicazioni e classi specifiche (o proprietarie).
Si ha poi una fase di personalizzazione dove sono inseriti i dati del possessore
e chiavi numeriche (personalizzabili). L’aggiunta di ulteriori applicazioni
avviene possedendo un software di sviluppo che permette di costruire applet
Java (utilizzando le classi fornite da JavaCard 2.1 o personali). Tale
software permette anche una simulazione sul funzionamento della carta e
la creazione di un file contenente il Byte Code della JavaCard (File di
tipo CAP, Card Application). Dopo l’inserimento del nuovo applet (il file
.CAP), ulteriori test sono permessi per garantire il corretto funzionamento
della carta. Infine la carta può essere utilizzata dall’utente.
TORNA ALL'INDICE DEL CAPITOLO
ATTUALE (CAP 5 :JAVA CARD CARTE MULTI
APPLICAZIONE)
La macchina virtuale implementata sulla carta è diversa da quella realizzata su PC per motivi di limitazioni di memoria e risorse (processori e frequenza di funzionamento). In particolare la JCVM entra in funzione alla prima accensione della carta e lavora perennemente fino alla terminazione. Per ovviare alla carenza di alimentazione in determinati intervalli, sono salvati in EEPROM particolari oggetti contenenti lo stato della carta ad un determinato istante. Durante il normale funzionamento la VM opera sulle istruzioni ricevute creando stati consistenti che sono volta per volta aggiornati. Togliendo alimentazione la VM resta bloccata in un ciclo di clock a tempo infinito fino all’ulteriore riaccensione. Gli applicativi e gli oggetti devono essere inizializzati e registrati prima di essere usati dalla carta. Una volta rimossi, lo spazio occupato (sulla EEPROM) può essere riutilizzato. Le applet creano oggetti che immagazzinano e manipolano i dati; tali oggetti sono associati alla singola applicazione in modo che non si verifichino accessi non sicuri. Sono permesse dichiarazioni sulla condivisione di oggetti con altri applet o con tutti. Le istruzioni ed i tipi di variabili supportati sono una sottoparte di quelli offerti da Java.
In particolare NON sono supportati:
JavaCard 2.1
Le classi base presenti attualmente per le JavaCard sono
contenute nella specifica JavaCard 2.1 che fornisce comandi compatibili
con quelli ISO 7816 (visti in precedenza) ed i principali componenti sono
i seguenti.
JavaCard.framework : è il set montato sulla carta e contiene classi quali Applet e PIN, che sono mattoni fondamentali per costruire i programmi. Le Classi APDU, System e Util forniscono i servizi per la gestione run-time dei comandi e la condivisione degli oggetti.
JavaCardx.framework : contiene le classi per definire un file system orientato ad oggetti compatibile a quello ISO 7816 (MF, DF, EF).
JavaCardx.crypto e JavaCardx.cryptoEnc : contengono
classi che supportano funzioni crittografiche.
TORNA ALL'INDICE DEL CAPITOLO
ATTUALE (CAP 5 :JAVA CARD CARTE MULTI
APPLICAZIONE)
Il JCRE (Java Card Run-time Environment) utilizza la macchina
virtuale e le librerie presenti sulla JavaCard ed associa un identificatore
unico (AID) ad ogni applet. Dopo avere caricato una applet nella EEPROM
ed averla connessa alle librerie del JavaCard Framework il JCRE invoca
un metodo di inizializzazione (install) che registra la applet. In generale,
gli oggetti previsti per una applicazione sono creati ed inizializzati
nello stesso momento; questo impedisce che si creino problemi di carenza
di memoria durante il funzionamento della carta e permette la risoluzione
di eventuali conflitti. Un applet resta inattivo fino al momento in cui
è selezionato. Il terminale invia un ADPU di comando SELECT e al
JCRE. La applet corrente è sospesa e invocando una deselect per
ripristinare un contesto sicuro. Una operazione di select è effettuata
sulla applet identificata dall’AID contenuto nell’APDU di comando. Questo
permette al JCRE di preparare la nuova applet a ricevere gli APDU di comando
provenienti dall’esterno. Tutto resta immutato fino all’arrivo di un nuovo
comando di selezione.
Esempio di Java Card Applet
Di seguito è mostrato il codice di una semplice
applet implementata su JavaCard che salva il nome del possessore sulla
carta.
/* Il javacard.framework definisce
* i blocchi base per programmare le JavaCard.
* Le classi permettono la gestione di
* APDUs, i servizi di sistema e runtime.
*/
import javacard.framework.*;
/* istanza della classe Employee
* che estende
* javacard.framework.Applet.
*/
public class Employee extends javacard.framework.Applet
{
/* Byte dell’APDU header */
public static final byte READ_INS =(byte) 0xBB ;
public static final byte UPDATE_INS =(byte) 0xCC ;
public byte£` apduBuffer ;
private static byte£` name ;
/* Il metodo install() è invocato dal JCRE.
* La applet chiama il metodo register per
* registrarsi presso il JCRE.
* JCRE la rende visibile a all’esterno.
*/
public static void install (APDU apdu ) throws ISOException
{
Employee person=new Employee();
person.register();
}
/* Il metodo select() è invocato dal JCRE
* per notificare che la applet è stata selezionata .
* Gli APDU di comando sono indirizzati qui.
*/
public boolean select() throws ISOException
{
return TRUE;
}
/* Il metodo process() è invocato dal JCRE
* per maneggiare gli APDU in arrivo.
*/
public void process(APDU apdu) throws ISOException
{
apduBuffer = apdu.getBuffer();
switch( (byte) apduBuffer£ISO.OFFSET_INS`)
{
case READ_INS : readName();
case UPDATE_INS: updateName();
default:
ISOException.throwIt(ISO.SW_INS_NOT_SUPPORTED);
}
return;
}
/* Il metodo readName copia il
* nome del possessore nel buffer dell’APDU
* ed invia i dati. JCRE si occupa di creare
* il corretto APDU di risposta.
* In questo caso SW1 e SW2 sono “90 00” poiché
* tutto è andato correttamente.
*/
public void readName()
{
byte£` buffer = apdu.getBuffer;
util.arrayCopy( name, 0, buffer, 0, name.length);
/* invia i dati di lunghezza del nome e offset nullo (0)
*/
apdu.setOutgoingAndSend(short)0, (short) name.length);
return;
}
/* Il metodo updateName aspetta i dati in arrivo
* contenenti il nome del proprietario
* e riceve i dati che iniziano a offset
* ISO.OFFSET_CDATA.
*/
public void updateName()
{
byte£` buffer = apdu.getBuffer;
length = buffer£ISO.OFFSET_LC` ;
util.arrayCopy( buffer, ISO.OFFSET_CDATA , name, 0, length);
return;
}
}
TORNA ALL'INDICE DEL CAPITOLO ATTUALE (CAP 5 :JAVA CARD CARTE MULTI APPLICAZIONE)