MokaByte Numero  44  - Settembre 2000
 
Dallas Semiconduttor
 Java iButton
Seconda parte
di 
Roberto Fabbrica
Ambiente Java Card su supporto indossabile, 
ovvero la JavaCard dell'ormai famoso anello Java

I Dallas Semiconductor Java iButton sono dispositivi miniaturizzati molto resistenti che integrano al loro interno l’ambiente JavaCard. L’involucro del dispositivo, come si può immaginare dal nome, ha il formato di un bottone ed è realizzato in acciaio: questo permette una resistenza agli urti, alle flessioni, alla polvere e all’acqua indubbiamente superiori alle normali JavaCard. Se a questo si aggiunge il basso costo, non solo dei dispositivi ma anche dei lettori che ne permettono l’interfacciamento con i dispositivi di controllo, ne risulta che questi dispositivi possono essere utilizzati con profitto per la realizzazione di una moltitudine d’applicazioni..

Introduzione
Nella prima parte di questo articolo si sono prese in considerazione le caratteristiche tecniche del dispositivo, sia dal punto di vista del hardware che del software, e le caratteristiche dell’interfaccia con i dispositivi di controllo, in particolare la MicroLAN, cioè il mezzo che permette di interfacciare più dispositivi utilizzando un unico bus collegato ad un’unica porta. Chi non abbia letto questo articolo può trovarlo pubblicato sul numero di Luglio 2000 di MokaByte.

 In questa seconda parte dell’articolo verrà invece analizzato l’ambiente di sviluppo utilizzabile per la creazione di applicazioni Java basate su iButton. Questo è in realtà un vero e proprio IDE, cioè un ambiente integrato di sviluppo, che contiene al suo interno un editore di testo per la scrittura del codice sorgente, un’interfaccia di compilazione per il codice delle applicazioni e applet Java, un’interfaccia di compilazione per le applet JavaCard e un sistema di debugging, nonché altri tool di supporto al test delle applicazioni sviluppate.

 Nel proseguo dell’articolo verrà descritto, fra le altre cose, il wizard di creazione di un nuovo progetto, molto utile per creare velocemente la struttura sia dell’applicazione Java che dell’applet JavaCard, il debugger integrato, utilizzabile per l’esecuzione passo-passo del codice prodotto, l’APDU sender, strumento indispensabile per il test delle applet JavaCard prodotte, e verranno discussi i principali parametri di configurazione degli iButton disponibili.
 
 

Dallas  iB-IDE 1.0
 La versione di iB-IDE analizzata in questa sede è la 1.0, prima versione stabile dopo la presentazione, per un periodo relativamente lungo, di versioni beta da parte di Dallas Semiconductor. Attualmente è disponibile una versione più recente di questo ambiente integrato di sviluppo, la 1.01, che corregge diversi problemi della versione precedente. La nuova versione utilizza, inoltre, la versione 1.1 del Framework OCF, mentre la versione 1.0 utilizza il Framework OCF 1.0.

 Questo ambiente integrato di sviluppo, fornito gratuitamente, è scritto interamente in Java. Questo permette di eseguire l’ambiente su una moltitudine di piattaforme diverse: attualmente però sono distribuite, per via dei driver di connessione ai lettori tramite porta parallela, solo due versioni, una per piattaforme Windows (95/98/NT) e una per piattaforme Solaris. Purtroppo la scelta di sviluppare l’intero ambiente in Java porta a richieste di sistema piuttosto impegnative, almeno per la piattaforma Windows. Per un utilizzo minimo dell’ambiente in questione è, in pratica, necessario disporre di almeno un processore a 300 MHz ed almeno 64 MByte di RAM. Questo ambiente integrato di sviluppo è comunque dotato di tutte le funzionalità necessarie allo sviluppo di applicazioni, sia sul lato PC o workstation sia sul lato Java iButton, ed è realizzato con estrema perizia. E’, infatti, presente un ottimo editore di testo a cui si affianca la gestione dei progetti con una finestra per l’organizzazione del codice delle JavaCard Applet e del codice da eseguire su PC o workstation a cui è collegato il lettore (che d’ora in poi chiameremo Host, come consigliato da Dallas Semiconductor). La figura 1 mostra iB-IDE in modalità di gestione di un progetto.
 
 

Figura 1– L’ambiente iB-IDE.

 

Notare che il compilatore utilizzato è quello del JDK 1.2, che deve essere presente sulla macchina prima di eseguire l’installazione di iB-IDE. Questo ha come evidente vantaggio l’utilizzo di un compilatore Java altamente standardizzato e rispondente alle specifiche.

Questo ambiente contiene anche un debugger, corredato da un utilissimo simulatore di iButton che permette l’esecuzione passo passo del codice delle JavaCard Applet. A questo si affianca anche uno strumento molto utile per la verifica delle JavaCard Applet: un APDU Sender, in pratica uno strumento che permette di inviare, tramite un’apposita interfaccia grafica, comandi APDU all’iButton simulato o all’iButton reale. Questi due strumenti saranno analizzati più in dettaglio nel proseguo dell’articolo.

 Notare infine la presenza di un comodo help in linea integrato con l’ambiente di sviluppo. Da questo help in linea è possibile avere informazioni relativamente a iB-IDE ed al suo utilizzo, oltre che informazioni relative alle classi che integrano il framework OpenCard e alle classi d’accesso alle funzionalità aggiuntive messe a disposizione dall’hardware dell’iButton. La figura 2 mostra l’help in linea relativo all’ambiente integrato di sviluppo ed alle sue funzionalità.
 
 

Figura 2– Help in linea di iB-IDE.

 La prima funzionalità, estremamente comoda, messa a disposizione del programmatore dall’ambiente integrato di sviluppo è la possibilità di generare una parte consistente del codice della JavaCard Applet e dell’applicazione Host in fase di creazione di un nuovo progetto. Durante questa fase è, infatti, possibile utilizzare un wizard che genera tutto il codice relativo allo scheletro della JavaCard Applet e dell’applicazione Host. La figura 3 mostra un passo del wizard, più precisamente quello che richiede al programmatore quali istruzioni intende utilizzare per l’interfaccia con la JavaCard.
 
 
 

Figura 3 – Wizard di creazione di un nuovo progetto

La figura 4 mostra invece un altro passo dello stesso wizard che richiede al programmatore quali operazioni di conversione intende utilizzare sull’Host e sulla JavaCard Applet.
 

Figura 4– Wizard di creazione di un nuovo progetto

In altre parole, è quindi richiesto di specificare i byte CLA, il nome logico dell’istruzione (da cui verrà ricavato il byte INS) e i byte P1 e P2 di ogni istruzione APDU, nonché le funzioni di conversione da e verso byte array dei tipi predefiniti Java più importanti. Questo permette al wizard di creazione di un nuovo progetto di generare automaticamente le seguenti parti della JavaCard Applet e dell’applicazione Host:

  • JavaCard Applet: i metodi install( ) e process( ) completi della quasi totalità del codice necessario,  i metodi appositi che semplificano l’invio della risposta all’applicazione Host, i metodi che permettono una facile conversione dei byte array reperiti dai comandi APDU o da restituire tramite le risposte APDU;
  • Applicazione Host: l’implementazione della procedura automatica di caricamento della JavaCard Applet sull’iButton se questo non la contiene, l’implementazione dei meccanismi ad eventi in grado di gestire l’inserimento e l’estrazione di iButton dai lettori, i metodi per la conversione dei byte array da inserire nei comandi APDU e da reperire dalle risposte APDU.


Grazie a questi supporti lo sviluppo delle applicazioni risulta piuttosto veloce, una volta che le strutture generate automaticamente sono state ben comprese e verificate dallo sviluppatore.

L’editor di testo è purtroppo afflitto, nella versione 1.0, da alcuni antipatici problemi di funzionamento che si presentano alla ripresa del fuoco da parte di una qualsiasi delle finestre. In questa occasione il cursore ritorna nell’ultima posizione assunta prima che la finestra perdesse il fuoco. Questo è particolarmente scomodo nelle finestre che visualizzano il codice sorgente quando si tenta di risalire dalla finestra dei messaggi ad una riga contenente un errore: puntualmente la finestra contenente il codice visualizza la riga che si deve modificare, ma appena si tenta di accedere alla finestra questa sposta la visualizzazione al punto in cui era precedentemente, vanificando, di fatto, il posizionamento precedente. Questo problema risulta corretto nella nuova versione di iB-IDE, la 1.01.

Il debugger integrato in iB-IDE fornisce due strumenti appositi per il debug dei sorgenti JavaCard: uno permette l’inserimento di breakpoint all’interno del codice sorgente, mentre l’altro permette di visualizzare le variabili e lo stato dell’iButton simulato su cui viene eseguito il codice. In questo modo è possibile eseguire parti del codice tramite step-into o step-over (ovvero eseguendo passo passo il codice delle funzioni chiamate o meno), visualizzando contemporaneamente il contenuto delle variabili disponibili ad ogni istante.

Purtroppo anche questi strumenti hanno dimostrato diversi problemi nella versione 1.0 dell’iB-IDE. Il debugger, in particolare, ha dimostrato una certa propensione al blocco, cosa che ne ha reso problematico l’utilizzo in diverse occasioni.

E’ importante notare che il debugger si basa completamente sul simulatore di iButton fornito con l’ambiente IDE. Questo simulatore non permette di rilevare possibili errori dipendenti dall’esaurimento delle risorse di memorizzazione, in quanto il simulatore di iButton non prevede limiti alla memoria utilizzabile, come invece accade inesorabilmente per gli iButton reali. Se a questo si aggiunge che la finestra di visualizzazione dello stato dell’iButton simulato riporta una quantità di memoria utilizzata molto approssimativa e non tiene conto del funzionamento dei garbage collector, è facile immaginare che il debug di applicazioni che presentano problemi di occupazione di memoria è piuttosto problematico, anzi, per certe applicazioni non banali, questi tempi di debug possono rappresentate una percentuale significativa dei tempi complessivi di sviluppo.

 L’ADPU Sender è uno strumento che permette di inviare comandi sia all’iButton simulato sia agli iButton reali. I comandi inviabili possono essere sia comandi indirizzati alle applet installate sull’iButton, sia comandi di configurazione per la gestione dell’iButton. La figura 5 mostra l’interfaccia grafica dell’APDU Sender.
 
 

Figura 5  - L’APDU sender di iB-IDE.

Questo strumento permette di selezionare l’iButton a cui inviare il comando da una lista a discesa, contenente tutti gli ID degli iButton correntemente collegati al sistema. E’ inoltre previsto un campo di testo per l’immissione dell’eventuale Master PIN per permettere l’accesso all’iButton (nel caso in cui questo sia protetto da un PIN di protezione). I comandi inviabili all’iButton sono raccolti in un’ulteriore lista a discesa e, una volta selezionato uno di essi, è possibile inserire gli eventuali parametri dalla finestra apposita, modificata dinamicamente in funzione del comando correntemente selezionato. L’interfaccia grafica dell’APDU Sender è infine completata da un’area di testo per la visualizzazione delle JavaCard Applet correntemente caricate sull’iButton selezionato e da un’area di testo per la visualizzazione dei dati e della status word ottenute come risposta all’ultimo comando inviato.

 Di seguito sono riportati alcuni dei comandi più importanti messi a disposizione dall’APDU Sender (si tratta dei comandi più frequentemente utilizzati in sede di debug):

  • Master Erase: questo comando permette di cancellare tutte le JavaCard Applet caricate sull’iButton;
  • Load Applet: questo comando permette di caricare una nuova JavaCard Applet sull’iButton;
  • Select Applet: questo comando permette di selezionare la JavaCard Applet indicata;
  • Process: questo comando permette di inviare un comando alla JavaCard Applet correntemente selezionata;


Altri comandi disponibili sono i seguenti. Questi sono meno utilizzati in fase di debug, ma il loro utilizzo è inevitabile nello sviluppo di applicazioni non banali:

  • Set Master PIN: questo comando permette di impostare il Master PIN per il controllo degli accessi all’iButton (il Master PIN è una stringa di byte di lunghezza massima pari ad otto). Naturalmente per eseguire questo comando è necessario specificare il Master PIN correntemente attivo;
  • Set Command PIN Mode: questo comando permette di abilitare e disabilitare la verifica del Master PIN per l’esecuzione dei comandi per cui è necessario specificare il Master PIN. Per eseguire questo comando è necessario specificare il Master PIN;
  • Get Command PIN Mode: questo comando permette di verificare se la verifica del Master PIN è attiva per l’esecuzione dei comandi. Per eseguire questo comando non è necessario specificare il Master PIN;
  • Set Load PIN Mode: questo comando permette di abilitare e disabilitare la verifica del Master PIN per l’esecuzione dell’installazione di JavaCard Applet sull’iButton. Per eseguire questo comando è necessario specificare il Master PIN correntemente attivo;
  • Get Load PIN Mode: questo comando permette di verificare se la verifica del Master PIN è attiva per l’installazione delle JavaCard Applet. Per eseguire questo comando non è necessario specificare il Master PIN;
  • Delete Currently Selected Applet: questo comando permette di cancellare la JavaCard Applet correntemente selezionata. Per eseguire questo comando è necessario specificare il Master PIN;
  • Delete Applet Using Number: questo comando permette di cancellare la JavaCard Applet specificata per numero. Per eseguire questo comando è necessario specificare il Master PIN;
  • Delete Applet Using AID: questo comando permette di cancellare la JavaCard Applet specificata per AID. Per eseguire questo comando è necessario specificare il Master PIN;
  • Set Applet GC Mode: questo comando permette di attivare o disattivare l’Applet Garbage Collector, cioè il garbage collector addetto al recupero dello spazio occupato dagli oggetti i cui riferimenti sono stati tutti spostati ad altri oggetti o all’oggetto null. Per eseguire questo comando è necessario specificare il Master PIN;
  • Get Applet GC Mode: questo comando permette di verificare se l’Applet GC è correntemente attivo. Per eseguire questo comando non è necessario specificare il Master PIN;
  • Set Ephemeral GC Mode: questo comando permette di attivare o disattivare l’Ephemeral Garbage Collector, cioè il garbage collector addetto al recupero dello spazio occupato da oggetti i cui riferimenti sono andati fuori scope. Per eseguire questo comando è necessario specificare il Master PIN;
  • Get Ephemeral GC Mode: questo comando permette di verificare se l’Ephemeral GC è correntemente attivo. Per eseguire questo comando non è necessario specificare il Master PIN;
  • Set Restore Mode: questo comando permette di attivare o disattivare l’esecuzione atomica di tutte le operazioni sull’iButton. Per eseguire questo comando è necessario specificare il Master PIN;
  • Get Firmware Version String: questo comando permette di leggere le informazioni relative al firmware dell’iButton. Per eseguire questo comando non è necessario specificare il Master PIN;
  • Get Free RAM: questo comando permette di leggere il quantitativo di memoria RAM attualmente libero sull’iButton. Per eseguire questo comando non è necessario specificare il Master PIN;
  • List Applet by Number: questo comando permette di ricavare l’AID di una JavaCard Applet referenziata per numero.


Per ulteriori informazioni e per gli altri comandi non riportati in questa sede, si veda l’help in linea di iB-IDE versione 1.0 o 1.01.
 
 
 

Conclusioni
Gli strumenti di sviluppo messi a disposizione da Dallas Semiconductor per i propri iButton sono di potenza e facilità d’uso ampiamente superiori alla media dei tool forniti da altri produttori di JavaCard. Questo permetterebbe, se il funzionamento fosse impeccabile, di sviluppare con una velocità ed una precisione notevoli. Purtroppo l’ambiente iB-IDE, almeno nella versione 1.0, non si è dimostrato sufficientemente stabile per raggiungere questi obiettivi.

Un altro problema è dato dalla forte integrazione del software sviluppato con i framework messi a disposizione dall’ambiente di sviluppo. Questo rende non immediata la distribuzione delle applicazioni sviluppate, richiedendo uno sforzo non banale da parte dello sviluppatore.

Lodevole è la possibilità di sviluppare e testare applicazioni basate su iButton senza avere a disposizione i dispositivi veri e propri, utilizzando cioè il simulatore di iButton integrato nell’ambiente di sviluppo. Questo permette a chiunque di prendere confidenza con l’ambiente JavaCard e con il framework OCF senza investire nulla, visto che l’intero ambiente di sviluppo è distribuito gratuitamente e non è necessario acquistare iButton per eseguire i test del codice prodotto.

Positiva è stata anche la scelta di Dallas Semiconductor di sviluppare l’intero ambiente integrato utilizzando Java. Questo permette, teoricamente, di utilizzaree l’IDE su una moltitudine di piattaforme, tenendo anche conto che l’accesso tramite porta seriale agli iButton è gestito a livello di Factory del framework OCF, e quindi in maniera completamente indipendente dalla piattaforma.
 
 
 

Bibliografia
Chi intendesse approfondire i temi trattati in questo articolo, può trovare documenti ai seguenti indirizzi:

- www.ibutton.com: il sito web di Dallas Semiconductor dedicato ai Java iButton e agli altri dispositivi della stessa azienda, denominati genericamente iButton;

- www.opencard.org: il sito web della Fondazione OpenCard, da cui è possibili reperire tutte le informazioni sul framework OpenCard utilizzato dai Java iButton per l’interfacciamento con l’entità esterna di controllo;

- www.javasoft.com: il sito web di SUN dedicato alla tecnologia Java, dove è possibile reperire informazioni sulle estensioni relative ad OpenCard e per le specifiche relative alla tecnologia JavaCard.
 
 

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.

Chi volesse mettersi in contatto con la redazione può farlo scrivendo a mokainfo@mokabyte.it