Si noti che questa JavaCard implementa la versione 2.0 dell’API JavaCard, cioè la versione precedente a quella attuale (la 2.1). Le differenze fra i due ambienti non sono eccessive, per questo motivo la maggior parte delle informazioni qui riportate può essere proficuamente utilizzata per apprendere le caratteristiche anche delle JavaCard dell’ultima generazione.

 Per la corretta interpretazione di questo articolo si consiglia vivamente la lettura dei precedenti articoli pubblicati dall’autore su MokaByte (numeri di Gennaio 2000, Febbraio 2000, Marzo 2000 e Aprile 2000). Alcuni dei concetti trattati in questa sede necessitano, infatti, di conoscenze sul campo delle JavaCard.
 
 

Javacard Galactic 1.0
Il kit di sviluppo fornito dalla De La Rue comprende un lettore/scrittore di JavaCard Philips modello PE122, tre JavaCard versione 1.0, un’applicazione per la conversione del bytecode per renderlo installabile su JavaCard (Javaconv), un’applicazione per il caricamento delle JavaCard Applet su JavaCard (Javaload) ed un’applicazione per l’esecuzione di test e debug delle JavaCard Applet caricate sulla carta (Pcom32).

Per quanto riguarda le specifiche tecniche, il kit GalactIC versione 1.0 di De La Rue fornisce delle JavaCard con dotazioni medie rispetto all’attuale disponibilità sul mercato. Si tratta, infatti, di carte equipaggiate con un processore a 16 bit in grado di funzionare ad una frequenza massima pari a 8 MHz. La dotazione di memoria è apprezzabile, sono, infatti, disponibili 32 KByte di ROM, 16 KByte di EEPROM e 1 KByte di RAM. La JVM ed il Framework, nonché le estensioni di quest’ultimo, sono compatibili con l’API JavaCard 2.0. Nella media è anche il supporto alla crittografia: non si dispone di alcun acceleratore ma è presente l’implementazione degli algoritmi DES e triple DES (tramite l’estensione javacardx.cryptoEnc, definita come estensione dalla JavaCard API 2.0 ed installata dall’importatore successivamente all’importazione in Italia).

 Per quanto riguarda l’implementazione delle estensioni definite dalla JavaCard API 2.0, oltre alla crittografia è implementato il supporto per l’emulazione dei dati di tipo integer e l’estensione javacardx.framework per la gestione dei file system ISO (non più supportata dall’API JavaCard 2.1). Purtroppo però, come per molti altri dispositivi analoghi, non è implementato alcun meccanismo di garbage collecting.

 Il lettore fornito con il kit utilizza un collegamento seriale per la connessione dati al PC e sfrutta l’alimentazione del mouse o della tastiera grazie ad un cavo passante per porte PS/2.

 Il software ed i driver forniti a corredo si sono dimostrati abbastanza aggiornati e funzionali, ma purtroppo non era presente una classe utilizzabile con il JDK 1.2 per il collegamento con il lettore (disponibile solo a richiesta, e comunque fornita gratuitamente via email) e l’unica piattaforma supportata è quella Windows (95, 98, NT). Inoltre, la documentazione fornita è solo in formato elettronico.

 Passiamo ora alla descrizione dei passi necessari all’installazione di una JavaCard Applet sulla JavaCard GalactIC 1.0. Si noti che queste informazioni, pur facendo riferimento a strumenti propri di questo dispositivo, possono essere generalizzate ad ogni altra JavaCard in commercio.

E’ importante notare che, prima di installare una JavaCard Applet su una JavaCard GalactIC, è necessario compilarne il codice sorgente tramite un compilatore Java per PC o workstation (per esempio, il JDK della SUN). Poiché i sorgenti delle Applet JavaCard fanno generalmente riferimento a classi del Framework dell’API JavaCard 2.0, questo non è possibile utilizzando le sole classi disponibili negli ambienti Java per PC o workstation. Per questo motivo il kit GalactIC fornisce un insieme di riferimenti alle classi del Framework denominato crdclass.jar da utilizzare per eseguire la compilazione. In pratica, se si vuole compilare un file sorgente di una JavaCard Applet con il JDK SUN, è necessario utilizzare una riga di comando quale la seguente:

javac –g –classpath crdclass.jar <nomesorgente>.java

L’opzione –g compila il file sorgente inserendo nel bytecode informazioni per il debug, requisito necessario al corretto funzionamento del tool Javaconv per la conversione del bytecode. Se si utilizza un ambiente visuale, solitamente è sufficiente abilitare la compilazione dei sorgenti con le opzioni necessarie al debug. 

Il tool Javaconv.exe permette la trasformazione del bytecode ottenuto dalla compilazione in un formato che ne permette il caricamento sulla JavaCard. Questa trasformazione provvede ad elaborare il bytecode, in maniera tale da garantirne il funzionamento in ambiente JavaCard, ed esegue una separazione in pacchetti del bytecode risultante, in maniera tale da permetterne l’installazione su JavaCard da parte del tool Javaload. Contemporaneamente alla conversione, questo strumento esegue anche il controllo del bytecode alla ricerca di eventuali istruzioni non ammesse nell’API JavaCard 2.0, quali riferimenti a classi non comprese nel Framework e tipi di dato non ammessi. Viene inoltre anche eseguita un’ottimizzazione del bytecode ed una generica verifica dell’utilizzo della memoria da parte del codice: i bytecode che richiedono una quantità di memoria non disponibile nell’ambiente JavaCard specificato non sono convertiti e provocano la visualizzazione di un errore apposito.

Questo strumento è utilizzabile esclusivamente dalla riga di comando e richiede come input un file di bytecode JavaCard valido compilato con l’opzione di debug attivata. La riga di comando da utilizzare per la conversione delle JavaCard Applet da caricare sulle JavaCard GalactIC versione 1.0 è quella specificata nella seguente riga di comando:

javaconv –tsiemens –a<AID> -v2.0.0 <nomefile>.class

 La figura 1 mostra un’esecuzione del programma su Windows NT Workstation 4.0 dal prompt di DOS.

 Il parametro AID specifica l’Applet IDentifier, cioè un numero espresso in esadecimale di lunghezza compresa fra 2 e 32 cifre esadecimali utilizzato successivamente per identificare la JavaCard Applet sulla carta. De La Rue consiglia di esprimere questo numero come A00000000XXXXX, dove XXXXX deve essere sostituito con cinque cifre esadecimali scelte dal programmatore. Il file restituito dal convertitore, se la conversione avviene con successo, ha come nome l’AID specificato e come estensione .dlrjar. Per ulteriori informazioni su JavaConv si consiglia la consultazione di [Dlr98c].

 Il tool javaload.exe permette di caricare il bytecode, precedentemente convertito tramite il tool Javaconv, sulla JavaCard. Questo programma è dotato di un’interfaccia grafica e permette il caricamento sicuro delle JavaCard Applet tramite cifratura dei pacchetti ed autenticazione. I dati inviati alla carta vengono, infatti, cifrati e firmati dal tool tramite l’algoritmo triple DES e decifrati e verificati dalla JavaCard per verificarne i diritti di installazione. Le chiavi utilizzate sono apposite chiavi decise dalle due entità (la JavaCard ed il tool Javaload) all’inizio della sessione, ed hanno una durata pari alla sessione stessa. In questo modo, la configurazione delle Applet JavaCard caricate può essere modificata solo da colui che è in grado di ottenere le chiavi di sessione. Notare che le JavaCard che compongono il kit GalactIC della De La Rue sono configurate inizialmente con identiche chiavi predefinite. Le chiavi necessarie per installare JavaCard Applet in queste condizioni sono denominate GalactIC demo keys e sono automaticamente inserite nella finestra di selezione apposita, sull’interfaccia grafica del tool Javaload, durante la sua installazione.

 L’installazione di una JavaCard Applet tramite Javaload richiede di specificare, oltre alle chiavi, anche il nome della connessione dell’entità esterna con il CAD da utilizzare (una sigla del tipo XXNN, cioè due lettere seguite da due numeri), definita da un apposito tool di configurazione installato nel pannello di controllo di Windows. Il nome della connessione da utilizzare permette, in pratica, di identificare il lettore da impiegare per caricare le informazioni sulla JavaCard.

 La figura 2 mostra la finestra relativa al tool di configurazione della connessione con visualizzata una connessione virtuale. Questo strumento è accessibile dal pannello di controllo di Windows ed è installato assieme ai driver del lettore/scrittore di SmartCard.

E’ infine necessario specificare anche altri parametri, quali il file .dlrjar ottenuto dal convertitore Javaconv e la stringa di numeri esadecimali che rappresentano l’AID della JavaCard Applet.

Notare inoltre che, viste le caratteristiche relative alla protezione crittografica delle JavaCard fornite con il kit, è obbligatorio utilizzare l’opzione External Authentication presente nella parte destra dell’interfaccia grafica.

 La figura 3 mostra la finestra principale del tool Javaload con i principali campi compilati secondo le indicazioni fornite fino ad ora:

 Per ulteriori informazioni sull’utilizzo dell’applicazione Javaload si rimanda invece a [Dlr98c].

 L’applicazione Pcom32 è un debugger, dotato di interfaccia grafica, in grado di gestire script contenenti comandi APDU e direttive, per il test delle JavaCard Applet caricate sulle JavaCard. E’ possibile eseguire gli script in maniera continuata oppure eseguirli passo per passo. E’ inoltre possibile associare ad ogni comando uno stato atteso ed un dato atteso parametrizzati che permettono la verifica automatica delle risposte fornite dalla JavaCard: questo è quindi uno strumento piuttosto efficace per la ricerca di bachi, soprattutto con l’esecuzione continuata delle istruzioni.

 La figura 4 mostra la finestra principale dell’applicazione, in cui è caricato un file di comando pronto per l’esecuzione:
 
 

 Esiste già, nell’installazione standard del tool, un file contenente comandi e direttive utilizzabile per la cancellazione delle JavaCard consegnate con il kit di sviluppo GalactIC. Tramite questo script e il debugger Pcom32 è possibile cancellare tutte le JavaCard Applet caricate precedentemente e tutta la memoria eventualmente utilizzata da altri oggetti. Tale file è denominato Reuse.cmd ed è fondamentale per l’utilizzo del kit.

 Le principali direttive (ovvero comandi indirizzati al lettore e non alla JavaCard) sono elencate di seguito, corredate da una breve spiegazione dei loro effetti:
 

• INSERT: questa direttiva richiede all’utente di inserire la JavaCard nel lettore e blocca l’esecuzione finché questa non è pronta a ricevere comandi;
• EJECT: questa direttiva richiede all’utente di estrarre la JavaCard dal lettore e blocca l’esecuzione finché questa non è stata rimossa;
• POWER_ON: questa direttiva provvede all’accensione del lettore, in altre parole all’alimentazione della JavaCard in esso inserita. Questa direttiva permette di specificare anche alcuni parametri, fra i quali la frequenza a cui far lavorare la JavaCard (da un minimo di 4 MHz fino ad un massimo di 8 MHz);
• POWER_OFF: questa direttiva provvede allo spegnimento del lettore, in altre parole allo spegnimento della JavaCard in esso inserita;
• LIST_ON: questa direttiva provvede all’attivazione del logging su file, cioè attiva la scrittura dell’output delle operazioni su un file di log;
• LIST_OFF: questa direttiva provvede alla disattivazione del logging su file, cioè disattiva la scrittura dell’output delle operazioni su un file di log;
• STEP_ON: questa direttiva provvede all’attivazione della modalità di esecuzione passo per passo;
• STEP_OFF: questa direttiva provvede alla disattivazione della modalità di esecuzione passo per passo;
• SET_TIMEOUT: questa direttiva permette di modificare il valore del time out dei comandi, cioè del tempo atteso dal lettore dopo l’invio di un comando prima di lanciare un errore di mancata risposta da parte della JavaCard;
• BEGIN_LOOP e LOOP: queste direttive permettono di inserire cicli all’interno del flusso di esecuzione degli script.

Il tool Pcom32 fornisce inoltre al programmatore cinque buffer general purpose per la gestione dei dati all’interno dello script e due buffer dedicati per i dati da inviare e ricevuti dalla JavaCard.

Per quanto riguarda i comandi, questi sono esprimibili nel formato proprio dei comandi APDU, cioè una sequenza di byte espressi in formato esadecimale, eventualmente separati fra loro da uno spazio. Un esempio di comando valido può essere il seguente:

A0 11 01 01 03 04 01 04

 Si riconosce, infatti, il byte di classe (CLA A0), il byte dell’istruzione (INS 11), i due byte che compongono il parametro (P1 01 e P2 01), il byte della lunghezza dei dati del comando (Lc 03) ed i byte contenenti i dati del comando (DATA 04 01 04).

 Come accennato precedentemente, è possibile specificare anche lo stato di ritorno atteso parametrizzato, cioè contenente dei valori definiti dallo sviluppatore e delle wildcard per i posti in cui il valore ritornato può essere qualsiasi. Lo stato di ritorno parametrizzato deve essere posizionato in coda al comando fra parentesi tonde. Un esempio di comando con specificato lo stato di ritorno atteso parametrizzato può essere il seguente:

 A0 11 01 01 03 04 01 04 (XA XX)

 In questo caso qualsiasi stato di ritorno restituito dalla JavaCard che abbia i quattro bit meno significativi del primo byte restituito esprimibili in esadecimale come A non lancia nessun errore. Quindi gli stati di ritorno 0A 00, AA BB, FA 23 permettono un’esecuzione senza errori, mentre gli stati AB 00, A4 45, 90 00 fanno sì che l’applicazione riporti a video (ed eventualmente sul file di log) un errore durante l’esecuzione dello script.

 In maniera analoga, è possibile specificare i dati di risposta attesi parametrizzati, cioè contenenti dei valori definiti e delle wildcard per i posti in cui il valore ritornato può essere qualsiasi. I dati di risposta attesi parametrizzati devono essere posizionati in coda al comando fra parentesi quadre. Un esempio di comando, con specificati i dati di risposta attesi parametrizzati, può essere il seguente:

 A0 11 01 01 03 04 01 04 [XX 00 XX 22 XX 44 XX]

 La semantica delle wildcard è identica al caso precedente, quindi il dato di risposta 00 00 00 22 11 44 11 è accettabile e non lancia errori, mentre il dato di risposta 00 00 00 21 00 44 00 fa sì che l’applicazione riporti un errore durante l’esecuzione dello script. Per ulteriori informazioni si rimanda a [Dlr98c].
 
 

Conclusioni
La JavaCard GalactIC 1.0 è sicuramente un dispositivo che rappresenta piuttosto bene l’insieme della JavaCard disponibili fino alla fine dell’anno scorso, e continua a rappresentare un buon metro di paragone per le JavaCard dell’ultima generazione attualmente disponibili.

In questo articolo, oltre ad un breve cenno sulle caratteristiche tecniche del kit con cui viene distribuita la JavaCard, sono stati analizzati gli strumenti disponibili per l’utilizzo di questo dispositivo. I passi descritti possono essere facilmente generalizzati per ogni altra JavaCard attualmente disponibile. In particolare, il fatto che questi strumenti lavorino piuttosto a basso livello permette di capire quali sono le problematiche legate all’installazione di un servizio sulla JavaCard. 

Nel prossimo articolo, verranno prese in considerazione le informazioni avanzate che riguardano questo dispositivo. Più in particolare, si tratterà il sistema operativo della JavaCard GalactIC, alcune particolarità nella gestione dei comandi APDU di questo dispositivo e altre informazioni avanzate.
 
 
 

Bibliografia 
Le informazioni riportate in questo articolo possono essere approfondite leggendo il documento descritto di seguito. Questo documento non è purtroppo disponibile in linea, poiché distribuito esclusivamente insieme al kit JavaCard GalactIC 1.0. Per ulteriori informazioni è comunque possibile consultare il sito web del produttore all’indirizzo www.delarue.com.

[Dlr98c]: De La Rue Cartes et Systèmes, “GalactIC Version 1 – User Manual”, 1998, Manual references: PE: 993-099 / 12NCT: 4311 240 26362, www.delarue.com

Roberto Fabbrica, nato a Ravenna il 28 dicembre 1972, è laureato in Ingegneria Informatica alla Facoltà di Ingegneria dell’Università di Bologna dal 1999. Attualmente lavora come libero professionista, fornendo consulenze come analista programmatore in Visual Basic ed esperto SQL ad una software house bolognese e collaborando al progetto e all’implementazione di applicazioni Java web oriented presso il DEIS (Dipartimento di Elettronica, Informatica e Sistemistica) della Facoltà di Ingegneria dell’Università di Bologna, sede di Cesena.