Dalle Smart Card alle Java Card

Il principale limite delle Smart Card era essenzialmente rappresentato dai lunghi tempi di produzione delle carte, limite che spesso finiva col rele-gare le Smart Card sempre un passo indietro rispetto alle richieste del mercato.

I programmi per le Smart Card venivano scritti direttamente in linguaggio assembler e venivano salvati nella ROM; ciò imponeva che il codice di tali applicazioni non potesse subire alcuna evoluzione nè aggiornamento e di fatto rappresentava una forte limitazione all'evoluzione dell'uso di tali carte.

Per poter emettere una carta con una applicazione era infatti richiesta una scrittura precisa e dettagliata delle specifiche, la scrittura e riscrittura del software di base (una sorta di sistema operativo) per le diverse piat-taforme, lo sviluppo di specifiche funzionalità per l'applicazione ed infine la verifica del software prima del suo caricamento su un numero assai ele-vato di carte. É facile comprendere come questo processo fosse pesante in termini di tempo e soprattutto di costi.

Per avvicinarsi sempre di più alle esigenze dei consumatori ed al tempo stesso per ridurre il time-to-market e rendere sempre più flessibili le applicazioni per le carte, negli ultimi anni si è fatta strada una nuova generazione di Smart Card chiamata Java Card.

A differenza delle Smart Card, che una volta prodotte e distribuite all'u-tente risultano immodificabili, le Java Card consentono all'utente di scari-care piccole applicazioni sulla propria carta in modo da poter modificare i servizi offerti dalla carta stessa.

Le Java Card vengono costruite basandosi sugli stessi standard delle Smart Card rappresentando dunque una loro evoluzione. Questo aspetto rende possibile inserire le Java Card all'interno di ambienti che utilizzano Smart Card senza dover modificare il software.

Caratteristiche di una Java Card

Il principale obiettivo della tecnologia Java Card è stato quello di inserire nella carta un sistema Java tale da lasciare ampio spazio di memoria per le applicazioni. Questa soluzione ha fatto sì che le Java Card siano in grado di supportare solo un sottoinsieme di istruzioni del linguaggio Java [7] ed ha portato ad un nuovo modello "splittato" della Java Virtual Machine (JVM).

La Java Card Virtual Machine (JCVM) [1], la versione della JVM per Java Card, risulta infatti divisa, "splittata" in due parti: una parte che lavora off-card e l'altra che lavora invece on-card. La parte di JCVM che lavora on-card si preoccupa di eseguire il bytecode delle applicazioni, di verificare l'allocazione della memoria, di gestire gli oggetti creati dall'applicazione, e di garantire la sicurezza dinamica, come sarà ampiamente illustrato nel prossimo capitolo.

Il linguaggio supportato dalla Java Card

Data la scarsa disponibilità di memoria, le Java Card supportano solo un sottoinsieme di istruzioni del linguaggio Java. Nelle Tabelle 2.3 e 2.4 vengono illustrate rispettivamente le limitazioni imposte al linguaggio Java ed alla struttura dei programmi per Java Card.

Tabella 2.3 : Principali limitazioni al linguaggio Java per Java Card

Tabella 2.4 : Principali limitazioni alla struttura di applet Java per Java Card

Java Card Runtime Environment

Il  Java Card Runtime Environment (JCRE) riunisce tutti i componenti del Java Card system che lavorano sulla Java Card.

Il JCRE è responsabile delle politiche di gestione delle risorse, dell'esecu-zione delle applet e del sistema di sicurezza on-card.

L'architettura del JCRE è illustrata in Figura 2.7.

Le framework classes definiscono le interfacce disponibili per le applica-zioni e sono costruite ed adattate specificamente per le applet delle Java Card così da rendere davvero semplice costruire un'applet per una Java Card.

Le industry-specific extensions definiscono servizi aggiuntivi di sicurezza per le applet.

L'installer si preoccupa invece di garantire la possibilità di scaricare sulla carta, dopo che questa è stata prodotta e distribuita all'utente, nuove ap-plicazioni in sicurezza. L'installer collabora con il programma di instal-lazione off-card .

Le system classes costituiscono il nucleo del sistema operativo delle Java Card.

Infine i native methods mettono a disposizione dei supporti per la JCVM e per le system classes.

Figura 2.7 : Struttura del JCRE

Il JCRE viene inizializzato una sola volta durante il tempo di vita della Java Card al tempo di inizializzazione globale della carta.

Quando l'alimentazione della carta viene meno il JCRE è solamente sospeso e lo stato del JCRE e degli oggetti creati sulla carta viene preser-vato.

Quando la carta viene nuovamente alimentata, il JCRE riattiva l'ese-cuzione della JCVM prelevando i dati necessari dalla memoria non volatile (EEPROM).

Il periodo che va dal momento che la Java Card viene inserita in un CAD al momento in cui la carta viene rimossa dal CAD e chiamato CAD ses-sion.

Durante una CAD session il JCRE opera come una normale Smart Card ovvero supporta la comunicazione con l'host mediante APDU.

Subito dopo che la carta viene inserita in un CAD per iniziare una CAD session, il JCRE, dopo aver inviato una ATR APDU all'host, entra in un loop in attesa di una select APDU ovvero di una APDU di selezione di un applet della carta.

Quando questa select APDU arriva, il JCRE seleziona l'applet richiesta e instrada verso di lei tutte le successive APDU lasciando quindi all'applet il compito di analizzare il contenuto delle APDU e di selezionare gli oppor-tuni metodi dell'applet.

Terminate le operazioni, l'applet restituisce il controllo al JCRE che si mette in attesa di una nuova select APDU, ed il loop riparte.

Creazione di una Java Card Applet

Analizziamo adesso come si realizza una Java Card Applet [8,15].

In Figura 2.8 è illustrato il processo di realizzazione di una Java Applet.

Figura 2.8 : Processo di creazione di una applet

Questo processo inizia con la scrittura dell'applicazione attraverso la sua scomposizione in classi Java che verranno salvate in altrettanti file Java.

Questi file verranno dapprima compilati per produrre class file e suc-cessivamente inviati al simulatore che esegue e testa l'applet simulando su PC il JCRE della carta.

Durante la simulazione l'applet viene eseguita mediante JVM e dunque alcuni aspetti tipici delle Java Card quali ad esempio il meccanismo del Firewall o la definizione di oggetti transienti o persistenti, che vedremo meglio più avanti, non vengono  presi in considerazione in questa fase.

Successivamente i class file che costituiscono un package vengono inviati al converter, il quale riceve in ingresso anche eventuali export file relativi a package esterni cui l'applicazione fa eventualmente riferimento e produce un CAP (Converted APplet) file ed un export file per il package.

Infine il CAP file prodotto dal converter viene eseguito e testato da un emulatore che simula su PC la JCVM della Java Card e dunque l'ambien-te di esecuzione del package risulta essere esattamente lo stesso che si trova su una Java Card.

Se l'emulazione ha successo e l'applet risulta funzionare correttamente può adesso essere caricata ed installata su una Java Card.

Denominazione di applet e package

Concludiamo questa introduzione parlando della denominazione che as-sumono nella piattaforma Java Card le applet oppure i package che rappresentano un insieme di applet associate ad una singola applicazione.

Nella piattaforma Java Card ciascuna istanza di applet o ciascun package è univocamente identificato da un Application IDentifier (o AID). Quando un package viene dunque caricato sulla carta, questo può comunicare con altri package presenti sulla carta mediante i relativi AID.

L'AID è un array di byte che è costituito da due parti: la prima parte ha una lunghezza fissa di 5 byte e prende il nome di Resource IDentifier (o RID), la seconda parte ha invece una lunghezza variabile da 0 a 11 byte e prende il nome di Proprietary Identifier eXtension (o PIX).

Lo standard ISO gestisce l'assegnamento dei RID alle compagnie produt-trici di applet in modo che ciascuna compagnia si veda assegnato un uni-co RID. Ciascuna compagnia gestisce in autonomia l'assegnazione dei PIX ai package prodotti. La concatenazione tra il RID (che identifica la compagnia produttrice) ed il PIX (che identifica i package e le applet prodotti dalla compagnia) costituisce l'AID. L'AID dei package e l'AID di default per ciascuna applet definita in un package viene specificato al converter per generare correttamente il CAP file.