La scelta di realizzare l’intero framework utilizzando Java permette poi di utilizzare questo framework virtualmente su ogni piattaforma hardware e software, in modo conforme alla filosofia che anima il framework OpenCard stesso e l’ambiente JavaCard. Unico neo di questa scelta è, in realtà, una certa pesantezza del framework stesso, soprattutto rispetto ai semplici driver di accesso al CAD e alla SmartCard, che comunque devono continuare ad esistere per permettere il corretto funzionamento del framework OpenCard.

In quest’articolo sarà introdotto il framework OpenCard, concentrando l’attenzione sulle funzionalità offerte e sui vantaggi che ne derivano per l’utilizzo delle JavaCard. Nelle conclusioni saranno inoltre riportati pregi e difetti di questo strumento.
 

OCF OpenCard
OpenCard Foundation, il consorzio che ha creato e che mantiene lo standard OpenCard, è un’importante organizzazione che raggruppa i principali produttori di JavaCard e SmartCard, tra questi troviamo: 3-G International, Bull, Dallas Semiconductor, First Access, Gemplus, IBM Corp., Intellect, Network Computer Inc., Newcom Technologies Pty. Ltd., Schlumberger, SCM Microsystems, Siemens, Sun Microsystem, UbiQ e Visa International. Tale varietà di aziende interessate a questo standard indica, piuttosto chiaramente, quale sia l’attuale peso di questo standard nell’ambito JavaCard e SmartCard.

E’ importante sottolineare in primo luogo che quello che viene fornito da OCF con lo standard OpenCard non è propriamente un’implementazione completa di funzionalità per l’accesso alle SmartCard tramite lettori e ai servizi installati sulle SmartCard, ma piuttosto un framework, cioè un modello, costituito in buona parte da classi astratte e interfacce in grado di orientare i fornitori di CAD e di SmartCard ad un utilizzo standardizzato delle risorse. Questo permette agli sviluppatori che utilizzano le SmartCard di lavorare in maniera indipendente dal tipo di SmartCard e CAD utilizzati e dai dettagli organizzativi dei servizi installati.

Il framework OpenCard è stato progettato avendo come obiettivo generale la sua applicabilità ad ambienti estremamente diversi fra loro. Per questo motivo il framework è scritto completamente in Java e tutte le informazioni di configurazione necessarie sono reperite inizialmente da parametri di sistema. Questo permette al framework di funzionare correttamente non solo su PC e workstation, ma anche su macchine dotate di hardware minimali, come macchine automatiche per l’accettazione di SmartCard o telefoni cellulari.

Gli obiettivi tecnici dichiarati dello standard OpenCard sono l’indipendenza dal tipo di CAD (detto anche IFD, cioè InterFace Device) e l’indipendenza dal tipo di sistema operativo installato sulla SmartCard (fonte dei servizi resi disponibili dalla SmartCard). Questo viene ottenuto tramite l’implementazione di due livelli denominati CardTerminal Layer e CardService Layer, come riportato nella figura 1, che insieme compongono la struttura dello standard OpenCard:
 
 

Figura 1 – CardService Layer e CardTerminal Layer
 

Nel proseguo dell’articolo verranno trattati questi due livelli, analizzandoli dal punto di vista dei loro ulteriori componenti e delle loro funzionalità. Per ulteriori informazioni di carattere generale si consulti [Ibm98a].

 Di seguito viene descritto il CardTerminal Layer, cioè la parte dello standard OpenCard dedicata alla standardizzazione dell’accesso alle SmartCard tramite il lettore. I compiti di questo livello sono di astrarre dall’implementazione della connessione al lettore e di uniformare i metodi di accesso alla SmartCard.

 Il CardTerminal Layer, basato sulla classe CardTerminal, è realizzato tramite l’implementazione di API Java addette all’accesso alle SmartCard tramite i lettori da parte dell’entità esterna. I servizi forniti da questo livello sono principalmente la notifica tramite eventi dell’inserimento di SmartCard all’interno dei lettori, la standardizzazione della procedura di verifica del PIN della carta, la standardizzazione dei metodi di invio di APDU di comando e di ricezione di APDU di risposta.

Questo livello fornisce anche il supporto per la gestione degli slot, cioè delle postazione multiple messe a disposizione da certi lettori. Questo tipo di lettori fornisce la possibilità di connettere diverse SmartCard ad una stessa interfaccia, pur mantenendoli distinguibili dal punto di vista del software che le accede.

Naturalmente, un livello di questo tipo deve comunque basarsi su un ulteriore livello che astrae dall’hardware sottostante. Questo viene realizzato applicando le regole definite dall’abstract factory pattern e dal singleton pattern. Queste regole prevedono la fornitura, da parte dei produttori dei lettori, di una classe CardTerminalFactory per ogni tipo di lettore, che permette la creazione di oggetti specifici in grado di fornire le funzionalità di basso livello richieste alla classe CardTerminal.

Le informazioni relative a tutte le coppie di oggetti delle classi CardTerminal e CardTerminalFactory installati nell’entità esterna sono mantenute da un oggetto della classe CardTerminalRegistry, che mantiene inoltre tutte le informazioni di configurazione necessarie per un corretto funzionamento. Quest’oggetto permette due tipi di configurazione, in funzione del tipo di collegamento utilizzato fra entità esterna e lettore: una di tipo statico, basata sulla conoscenza a priori della configurazione dei lettori collegati all’entità esterna, e una di tipo dinamico, che permette il collegamento a runtime di ulteriori lettori all’entità esterna tramite metodi di registrazione e di deregistrazione. Quest’ultimo caso è tipico del collegamento di lettori a porte fisiche che permettono il collegamento dinamico di periferiche (per esempio USB e PCMCIA).

Scendendo ancor più in dettaglio, è necessario precisare che la classe CardTerminal è in realtà una classe astratta da cui derivano le classi effettivamente istanziabili, funzione del tipo di lettore ad alto livello, per la creazione di oggetti di controllo. Questi oggetti contengono in generale diversi oggetti della classe Slot, che rappresentano una connessione virtuale verso una delle SmartCard attualmente inserite nel lettore.
La figura 2 riporta un esempio di organizzazione degli oggetti relativi alla connessione di due lettori all’entità esterna (uno tramite collegamento statico, quale una connessione seriale, e uno tramite collegamento dinamico, quale una connessione PC Card), a cui sono collegate due SmartCard, una per lettore.
 
 

Figura 2 – Funzionamento del framework OpenCard

 L’inserimento o l’estrazione di una SmartCard da un lettore provoca, secondo lo standard OpenCard, l’invio di un’eccezione specifica dall’oggetto CardTerminal all’oggetto CardTerminalRegistry. Quest’ultimo provvede successivamente a notificare l’accaduto, sempre tramite un’eccezione specifica, a tutti gli altri oggetti CardTerminal e ai rispettivi oggetti CardTerminalFactory registrati. La figura 3 mostra questo comportamento.
 
 

Figura 3 – Notifica dell’inserimento di una carta

Notare che un comportamento del genere non è invece previsto per la registrazione o la deregistrazione di un oggetto CardTerminal, in quest’ultimo caso il comportamento di default è di non generare eccezioni. Per ulteriori informazioni si consulti [Ibm98b].

Passiamo ora alla descrizione del CardService Layer, cioè della parte dello standard OpenCard dedicata alla standardizzazione dell’accesso ai servizi messi a disposizione dalla SmartCard. In questo caso, l’obiettivo è la realizzazione dell’indipendenza dal produttore del sistema operativo della SmartCard. Questo viene ottenuto standardizzando, sia come denominazione sia come interfaccia verso l’entità esterna, tutti i servizi virtualmente presenti su una SmartCard. Attualmente è stato individuato e standardizzato un numero ridotto di servizi, ma OCF sta incrementando continuamente il numero di questi servizi, con l’obiettivo di standardizzare ogni possibile servizio utilizzabile su una SmartCard.

 Il CardService Layer, come il CardTerminal Layer, è realizzato tramite API Java. I servizi attualmente forniti da questo livello sono, fra gli altri, l’accesso standardizzato ai file system contenuti sulla SmartCard, l’accesso standardizzato alle funzionalità di firma offerte dalla SmartCard e la standardizzazione delle funzionalità di identificazione, selezione e controllo dei servizi correntemente caricati sulla SmartCard. Quest’ultimo punto è molto importante dal punto di vista dell’astrazione e della fruibilità dei servizi e si basa sulla realizzazione di interfacce standard per:
 

• Elencazione dei servizi installati sulla SmartCard: questo permette di ottenere la lista dei servizi installati sulla carta, in modo che l’entità esterna possa scegliere quale utilizzare oppure verificare se la SmartCard correntemente inserita nel lettore supporta un certo servizio;
• Locazione e selezione di servizi installati sulla carta: questo permette l’utilizzo di servizi presenti sulla carta senza conoscere a priori le scelte fatte in termini di indirizzo, di codifica delle istruzioni, ecc.;
• Installazione e cancellazione di servizi installati sulla carta: questo permette di svolgere con facilità le procedure di caricamento e cancellazione di servizi installati, anche direttamente dal codice in esecuzione sull’applicazione. Tutto ciò permette di realizzare applicazioni o Applet Java in grado di caricare su una SmartCard un nuovo servizio quando necessario o di cancellarne uno quando questo diventa obsoleto;
• Bloccaggio e sbloccaggio dei servizi installati sulla carta: Questo permette all’entità esterna di rendere non utilizzabili o rendere di nuovo utilizzabili servizi correntemente caricati sulla carta.

L’accesso ai servizi messi a disposizione da una SmartCard avviene tramite l’utilizzo di oggetti appartenenti a classi che estendono la classe astratta CardService, fulcro del CardService Layer. Di seguito viene riportata una breve descrizione delle interfacce che permettono, insieme alla classe CardService, di implementare i principali servizi standardizzati secondo lo standard OpenCard:
 

• FileAccessCardService: si tratta di un’interfaccia che permette l’astrazione dell’accesso ai file custoditi sui file system della SmartCard. Quest’interfaccia fornisce i metodi che permettono di accedere a file lineari o strutturati senza la necessità di scendere a livello dello standard ISO 7816-4 per i file system;
• SignatureCardService: si tratta di un’interfaccia che fornisce i metodi standard per la firma, la verifica e la conservazione di chiavi. Questi metodi permettono di accedere alle funzionalità di firma e verifica in maniera del tutto indipendente dai dettagli dell’implementazione sottostante, quali la presenza o meno di funzionalità di accelerazione per operazioni di crittografia o scelte di implementazione alternative;
• ApplicationManagementCardService: si tratta di un’interfaccia che fornisce i metodi per l’elencazione e il reperimento dell’interfaccia delle applicazioni presenti sulla carta. Tramite questi metodi l’entità esterna può recuperare le informazioni relative al nome e ai parametri dei servizi installati sulla carta;
• CardManagementCardService: si tratta di un’interfaccia che fornisce i metodi per l’installazione, la rimozione, il bloccaggio e lo sbloccaggio di servizi installati sulla carta. Questi metodi permettono di svolgere le operazioni appena descritte in maniera completamente indipendente dal tipo di SmartCard utilizzata e dal tipo di sistema operativo su essa installato.

Naturalmente, il CardService Layer deve comunque basarsi su un ulteriore livello che astrae dai dettagli di implementazione propri del sistema operativo della SmartCard o dei servizi installati. Questo viene realizzato applicando, come per il CardTerminal Layer, le regole definite dall’abstract factory pattern e dal singleton pattern. Queste regole prevedono il rilascio da parte dei fornitori delle SmartCard di una classe CardServiceFactory, che permette la creazione di oggetti specifici, funzione del tipo di SmartCard cui sono associati, in grado di fornire le funzionalità di basso livello richieste alla classe CardService.
Anche in questo contesto, tutte le informazioni di configurazione relative agli oggetti di classe CardService e agli oggetti di classe CardServiceFactory sono mantenute da un oggetto di classe CardServiceRegistry, in maniera del tutto simile al CardTerminal Layer. Per ulteriori informazioni si consulti [Ibm98b].
 
 
 

Conclusioni
L’adozione dello standard OpenCard è particolarmente vantaggioso quando i gruppi di lavoro che si occupano dello sviluppo delle applicazioni o delle applet Java e dello sviluppo dei servizi installati sulla JavaCard sono distinti, o quando i servizi installati sulla JavaCard sono addirittura forniti da terze parti. In questi casi la non adozione dello standard richiederebbe la produzione e la consultazione di una quantità elevata di documentazione, necessaria per rendere note le scelte fatte in termini di nomi, di parametri e di altri dettagli, con alta possibilità di introdurre errori nell’utilizzo o nella creazione dei servizi. Naturalmente questo implicherebbe anche la dipendenza delle applicazioni e delle Applet dal tipo di SmartCard utilizzate. Alla luce di tutto ciò, sono evidenti i vantaggi nell’utilizzo di questo standard:

- indipendenza delle applicazioni o delle Applet dal tipo delle JavaCard utilizzate;

- possibilità di utilizzare un unico sistema di accesso per tutte le JavaCard;

- possibilità di rendere effettivamente portabili fra diverse piattaforme le applicazioni e le Applet sviluppate.

Il rovescio della medaglia è dato principalmente dalla presenza di un framework riconfigurabile che funziona da interfaccia fra l’applicazione ed il lettore di SmartCard, e quindi la SmartCard stessa. Questo significa:

- aumento del consumo di risorse per l’accesso alla JavaCard;

- necessità di formazione per l’utilizzo del framework (strumento molto generico e quindi piuttosto ostico);

- dipendenza dell’affidabilità complessiva dalle classi di interfaccia sviluppate dal produttore del lettore.

In realtà, nella maggior parte dei casi i vantaggi sono decisamente prevalenti sugli svantaggi. I soli casi in cui può non essere conveniente l’utilizzo del framework OpenCard sono alcune applicazioni che necessitano di prestazioni elevate.
 

Bibliografia
Per approfondire i concetti trattati in quest’articolo si consiglia la lettura dei seguenti documenti, tutti disponibili nel sito web di OCF dedicato allo standard OpenCard (www.opencard.org):

[Ibm98a]: IBM, “OpenCard Framework General Information Web Document – Second Edition”, 1998

[Ibm98b]: IBM, “OpenCard Framework 1.1 Programmer's Guide – Second Edition”, 1998
 
 
 
 

Conclusioni
xxxxx

Bibliografia
[]
[]
[]

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 ad una software house bolognese e collaborando al progetto e all’implementazione di applicazioni Java presso il DEIS (Dipartimento di Elettronica, Informatica e Sistemistica) della Facoltà di Ingegneria dell’Università di Bologna, sede di Cesena.