Java Cards 2

(1)

C A P I T O L O

2 Java Cards

Le Java Cards hanno l’aspetto di piccole tessere magnetiche e sono in grado di memorizzare dati e di offrire capacità computazionali: posseggono infatti un microprocessore (su cui gira la Java Virtual Machine) e della memoria integrati nel substrato di plastica del loro corpo.

Fanno parte della famiglia delle Smart Cards e sono in un certo senso una loro evoluzione. Sono molto versatili: installare nuove funzionalità è infatti sempre possibile grazie al modulo installer che è in grado di caricare Java applets (le Smart Cards tradizionali invece non hanno questa caratteristica: tutte le loro funzionalità sono quelle stabilite durante il processo di produzione).

Smart Cards

Magnetic Stripe Cards

SIM Cards Java Cards Memory Cards

Prepaid Cards Smart Media Cards Cards

(2)

CAPITOLO 2:JAVA CARDS

2.1 I vantaggi della tecnologia Java Card

I benefici introdotti dalle Java Cards sono:

• Facilità nello sviluppo delle applicazioni: il linguaggio Java rende più agevole la creazione di software perché non è più necessario programmare nel linguaggio assembler caratteristico del microcontrollore della carta. Grazie alla tecnologia Java viene infatti offerta una piattaforma standard che definisce le APIs ed il runtime environment del sistema, nascondendo a tutti gli effetti i dettagli hardware della Java Card.

• Sicurezza: la sicurezza è da sempre un requisito fondamentale delle Smart Cards e le caratteristiche di sicurezza incorporate nel linguaggio Java si integrano bene con l’environment delle carte. Ad esempio il livello di accesso a metodi e variabili è strettamente controllato nel linguaggio Java: non c’è modo di utilizzare un puntatore per fare snooping nella memoria. Inoltre il runtime environment delle Java Cards separa i metodi attraverso un firewall che si occupa di controllare l’accesso ai dati effettuato dalle varie applets [Chen, 9]. • Indipendenza dall’hardware: la tecnologia Java conserva anche nei sistemi

embedded l’indipendenza dall’hardware utilizzato. Le applets possono girare su qualsiasi processore (8, 16 o 32 bit) integrato nelle carte senza bisogno di alcuna specifica compilazione.

• Capacità di memorizzare e utilizzare più applicativi: una Java Card può ospitare più applets, ad esempio borsellino elettronico (electronic purse) e programmi per l’autenticazione per differenti service providers; grazie al firewall è possibile controllare gli accessi alle risorse ed una volta acquistata una Java Card è possibile scaricare ed eseguire nuove applets.

• Compatibilità con gli attuali standard delle Smart Cards: le Java Cards rispettano lo standard ISO 7816 della Smart Cards, quindi tutti i sistemi e le applicazioni delle Smart Cards sono in genere compatibili anche con le Java Cards.

(3)

2.2 Java Card APIs

Le Java Cards sono state introdotte sul mercato alla fine del 1996 dalla Schlumberger [Axalto], produttore di Smart Cards. La Schlumberger riconobbe subito in Java il linguaggio di programmazione ideale per le carte, perché era in grado di preservare i requisiti di sicurezza necessari, ed annunciò l’implementazione di una Virtual Machine su un microcontrollore standard delle Smart Cards per un sottoinsieme delle istruzioni Java; contemporaneamente propose anche una bozza (draft) dell’insieme di APIs (framework classes) per le applets, cioè un’idea iniziale sull’insieme di funzionalità da offrire ai programmi (scritti in Java) che potevano girare sulle Smart (Java) Cards. Pochi mesi dopo la pubblicazione del draft altre due industrie, Bull [Bull] e Gemplus [Gemplus], fondarono, insieme alla Schlumberger, il Java Card Forum [JavaCardForum], cioè crearono un gruppo di lavoro comune che aveva come obiettivo lo studio e la promozione delle specifiche delle Java Card APIs.

Nel 1997 la Sun Microsystems, in collaborazione con il gruppo del Java Card Forum, annunciò il rilascio delle specifiche Java Card 2.0: questo insieme di APIs è attualmente lo standard per le Java Card. L’ultima versione è la 2.2.1 (ottobre 2003) ed è composta da 3 sezioni che descrivono le specifiche di APIs, Runtime environment e Virtual Machine [JCspec2.2.1]. Le principali caratteristiche introdotte con la versione 2.2 delle specifiche sono:

• il supporto per i Logical Channels (i Logical Channels permettono alla Java Card di eseguire più applicativi simultaneamente)

• meccanismi per la cancellazione degli oggetti • nuovi algoritmi di crittografia (AES e Elliptic curve)

2.3 Architettura delle Java Cards

Le Java Cards rappresentano una delle più piccole piattaforme con capacità computazionali attualmente in commercio.

(4)

Il chip tipicamente utilizzato è un microcontrollore a 8 bit con una frequenza di clock di 5MHz che supporta il set di istruzioni del Motorola 6805 o dell’Intel 8051. Le Java Cards di ultima generazione hanno microcontrollori a 16 e 32 bit, hanno un moltiplicatore per il clock e cominciano ad essere sviluppate anche su chip con architettura RISC.

contacts chip

card body

fig. 2.2: Struttura di una Contact Card

Le tipologie di memoria utilizzate nelle Java Cards sono tipicamente 3:

• ROM (read-only memory): viene utilizzata per salvare determinati programmi e dati stabiliti in fase di produzione, ad esempio le routines di sistema ed il numero di serie della carta. Il suo contenuto non può essere modificato e non viene perso in assenza di alimentazione. E’ il tipo di memoria meno costoso delle tre e le carte dispongono tipicamente almeno di 16KB di ROM.

• EEPROM (electrical erasable programmable read-only memory): come la ROM, anche questa memoria non perde i dati in assenza di alimentazione elettrica. Viene utilizzata per memorizzare dati ed applicazioni dell’utente (può essere paragonata all’hard disk di un desktop computer): è infatti una memoria che può essere riscritta (tipicamente si possono effettuare fino a 100,000 cicli di scrittura); la velocità di lettura è la stessa delle RAM, la scrittura è invece 3 ordini di grandezza (1000 volte) più lenta della scrittura in RAM. Attualmente le EEPROM sono state affiancate, ed in parte sostituite, dalle memorie Flash, che garantiscono una maggiore efficienza in spazio e velocità. Una carta dispone in genere di almeno 8KB di EEPROM.

(5)

• RAM (random access memory): è memoria non perstistente (cioè in assenza di alimentazione elettrica perde i dati contenuti) e viene utilizzata per memorizzare e modificare dati temporanei. Non ha limiti sui cicli di scrittura possibili e le carte dispongono in genere di almeno 256B di RAM. La quantità di RAM è così inferiore rispetto a ROM ed EEPROM perché una cella occupa molto spazio (4 volte più grande di una cella di EEPROM, 16 volte più di una della ROM) e questo implica difficoltà tecnologiche nella realizzazione di carte secondo le norme ISO 7816.

Le Java Cards vengono alimentate quando sono inserite1_{in una periferica in}

grado di accettare carte, chiamata CAD (card acceptance device). Esistono due tipi di CAD: lettori (readers) e terminali (terminals). I lettori vengono connessi alla porta seriale, parallela o USB di un pc (host) e non hanno capacità di elaborazione, mentre i terminali sono dei veri e propri computer. I programmi che comunicano con una Java Card vengono detti host applications, perché sono sempre installati sulla macchina host (o sul terminale). Il protocollo di comunicazione tra CAD e host è half-duplex ed è basato sullo scambio di pacchetti chiamati APDUs (application protocol data units): le APDUs permettono lo scambio di comandi e dati e la loro struttura è specificata nel documento ISO 7416-4.

command APDUs

response APDUs

Host

CAD

Java Card

fig. 2.3: Comunicazione tra host e Java (Smart) Cards

1 _{Esistono anche contactless cards: queste carte comunicano con i CADs attraverso una antenna}

integrata nella carta e prendono energia da una batteria integrata o attraverso l’antenna stessa sfruttando variazioni del campo magnetico.

(6)

Come accennato in precedenza, a causa della poca quantità di memoria disponibile, la piattaforma Java Card supporta solo un sottoinsieme delle caratteristiche del linguaggio di programmazione Java; nella seguente tabella vengono proposte le principali caratteristiche di Java supportate/non supportate nelle Java Cards:

Caratteristiche supportate Caratteristiche non supportate

• tipi primitivi “piccoli”: boolean, byte, short

• array uni-dimensionali

• packages, classi e interfacce Java • caratteristiche object-oriented di Java:

eredità, metodi virtuali, overloading, creazione dinamica degli oggetti, ... • il supporto per il tipo int e per gli interi

a 32 bit è opzionale

• i tipi primitivi long, double e float • caratteri e stringhe

• array multi-dimensionali • caricamento dinamico delle classi • clonazione degli oggetti

• threads

2.4 Java Card Virtual Machine

Una caratteristica molto particolare della Virtual Machine implementata sulle Java Cards è quella di essere divisa in due parti: esiste una parte off-card ed una parte on-card. La prima si occupa di pre-processare i file class, mentre la seconda è l’interprete Java2_{. La parte off-card è il convertitore (converter) e si occupa di}

trasformare il bytecode dei file class in un nuovo formato, chiamato CAP (converted applet): il CAP file verrà poi caricato sulla Java Card ed eseguito dall’interprete. La conversione è necessaria per ottimizzare il codice del file class (nei sistemi embedded la memoria è preziosa perché poca) e per compiere le verifiche statiche e strutturali sul codice (verifica off-card).

2_{Spesso in letteratura si parla di Java Card Virtual Machine (JCVM) riferendosi solo all’interprete, quindi} alla parte on-card della Virtual Machine.

(7)

convertitore class files

programma di installazione off-card CAD PC o Workstation CAP file runtime environment on-card installer interprete Java Card

fig. 2.4: Conversione dei file class e Java Card installer

La parte on-card della Virtual Machine fornisce il supporto al run-time caratteristico del modello Java, offrendo quindi una macchina virtuale che consente l’indipendenza tra il codice delle applets e l’hardware utilizzato.

2.5 JCRE (Java Card Runtime Environment)

Il run-time environment delle Java Cards (JCRE, Java Card runtime environment) è costituito da tutte le componenti del sistema che sono sulla carta:

• le APIs (framework classes): sono le funzionalità standard definite nelle specifiche Java Card [JCspec2.2.1]; tutte le applets accedono alle funzionalità della carta attraverso queste APIs.

• l’installer: serve ad installare il software sulle Java Cards; senza l’installer tutto il software delle carte, incluse le applets, dovrebbe venire scritto nella memoria della Java Card durante il processo di produzione.

• le estensioni specifiche delle industrie (industry-specific extensions): sono delle librerie che possono offrire servizi aggiuntivi per completare ed estendere il sistema ed il modello di sicurezza della Java Card.

(8)

• le classi di sistema (system classes): costituiscono il core del JCRE; offrono tutti gli strumenti necessari per gestire la comunicazione, la creazione ed il controllo delle applets.

• i metodi nativi (native methods): sono l’insieme di metodi responsabili dei protocolli di comunicazione a basso livello, della gestione della memoria e della crittografia, offrono cioè alla JCVM tutti i metodi necessari per pilotare correttamente l’hardware.

• la JCVM, Java Card Virtual Machine (bytecode interpreter). I compiti principali della parte on-card della Virtual Machine sono:

o esecuzione delle istruzioni del bytecode;

o creazione e allocazione degli oggetti in memoria; o verifica della sicurezza al run-time.

authentication applet

JCRE

Applets framework classes (APIs) industry-specific extensions installer applet

management managementtransaction communicationI/O network servicesother system classes

Java Card Virtual Machine

(bytecode interpreter) native methods

loyalty applet

wallet applet

(9)

Oltre a supportare le caratteristiche del linguaggio di programmazione Java, il JCRE supporta anche 3 nuove caratteristiche:

• oggetti persistenti (persistent) e transienti (transient). Gli oggetti Java Card sono persistenti se vengono creati nella memoria persistente (EEPROM o Flash); gli oggetti persistenti hanno un tempo di vita che va dalla loro creazione alla loro cancellazione, e possono durare quindi per più sessioni CAD3_{. Per motivi di}

sicurezza o di velocità gli oggetti possono essere creati anche in RAM: questi sono gli oggetti transienti. Gli oggetti transienti contengono in genere dati temporanei ed il loro tempo di vita è nell’arco di una sessione CAD.

• operazioni atomiche e transazioni. Tutte le operazioni di scrittura di un singolo campo di un oggetto o di una classe è atomica, cioè viene garantito che il contenuto del campo sia sempre coerente, e le transazioni, che in generale possono generare operazioni di scrittura in più campi, sono gestite attraverso commits e rollbacks, cioè una transazione ha successo (ed i campi da modificare vengono effettivamente modificati) solo se tutta la sequenza di operazioni della transazione è stata effettuata con successo.

• firewall e meccanismi di condivisione delle risorse tra le applets. Il firewall isola ogni applet, imponendole di girare in un determinato spazio di memoria; ogni operazione di un’applet non ha quindi effetto sulle altre applets. In caso di necessità di scambio di dati è necessario invocare sempre funzionalità del JCRE, questo infatti fornisce meccanismi adatti per una condivisione sicura.

2.6 Approcci in letteratura per un verificatore on-card

La verifica del bytecode avviene nella parte off-card della Java Card Virtual Machine: questa soluzione non è la migliore perché, come per le JVM installate sui pc, non possiamo esser sicuri della provenienza e della correttezza del codice dell’applet scaricata, un file CAP in questo caso. Una verifica on-card è bene che venga effettuata perché le Java Cards, come le attuali Smart Cards, conterranno

3_{Una sessione CAD è l’arco di tempo in cui la Java Card è inserita in una periferica CAD: solo durante le} sessioni CAD la Java Card è alimentata e quindi è in grado di funzionare.

(10)

informazioni riservate e dovranno essere affidabili e sicure. Il punto di forza delle Java Cards è la facilità con cui è possibile effettuarne un upgrade delle funzionalità. Ma questo punto di forza è anche il possibile anello debole della catena di sicurezza: applets errate o maliziose devono essere individuate ed il loro codice non deve essere eseguito.

I principali approcci proposti in letteratura per l’implementazione di un verificatore on-card tentano di ridurre i requisiti di memoria attraverso trasformazioni del bytecode o con l’aiuto di sistemi di certificazione:

• E.Rose and K.H.Rose [Rose&Rose] propongono una certificazione “leggera” (LBC, lightweight bytecode certification) off-card ed una verifica “leggera” del bytecode (LBV, lightweight bytecode verification) on-card: la LBC produce un certificato che deve essere distribuito insieme al bytecode e la LBV in questo modo dovrebbe solo verificare che il bytecode corrisponda a quanto specificato nel certificato. Questo metodo è stato ispirato da un lavoro di Necula [Necula] riguardante il PCC (proof carring code) ed è stata dimostrata l’equivalenza tra la verifica standard e la LBV. Attualmente la LBV è utilizzata nella KVM (K Virtual Machine), una JVM compatta che gira su periferiche con risorse limitate, come ad esempio cellulari e palmari, implementata dalla Sun nella Java 2 Micro Edition. I principali limiti di questa tecnica sono:

o la LBV attualmente non supporta le subroutines: in particolare il verificatore implementato nella KVM risolve il problema “espandendo” il codice delle subroutines in tutti i punti di chiamata, durante la certificazione off-card. Ricordiamo che l’utilizzo delle subroutines è legato alla volontà di rendere compatto il codice delle applets, quindi espandere il loro codice non è una cosa ottimale.

o il certificato che viene trasmesso insieme al bytecode richiede in genere oltre il 20% di spazio in più per la memorizzazione delle applets.

• X.Leroy [Leroy] propone invece una trasformazione del bytecode in modo da ridurre la dimensione dei frames4_{da memorizzare: la tecnica prevede una}

(11)

normalizzazione dello stack (stack normalization), cioè ad ogni istruzione di salto e ad ogni target lo stack deve essere vuoto, ed inoltre viene imposto che i registri contengano lo stesso tipo di dati per tutta la durata del metodo. Entrambi i vincoli vengono imposti attraverso una trasformazione del bytecode che avviene off-card. La trasformazione in genere porta ad un aumento poco significativo (2%) della dimensione del codice delle applets. I punti di debolezza di questa tecnica sono:

o aumento del numero di registri richiesti per la verifica di un metodo o la verifica on-card rifiuta codice valido che non è stato pre-processato

con la tecnica esposta.

• D.Deville e G.Grimaud [Deville-Grimaud] propongono un verificatore che memorizzi il dizionario in EEPROM oltre che in RAM: utilizzando un particolare tipo di codifica per i tipi di dati contenuti nelle variabili locali e nello stack dei frames e sfruttando la RAM come una sorta di cache del dizionario, è possibile diminuire il numero di scritture in EEPROM, riducendone quindi il “consumo” (ricordiamo che le scritture, oltre ad essere 3 ordini di grandezza più lente rispetto alle scritture in RAM, possono essere effettuate un numero limitato, anche se alto, di volte). Nel loro articolo inoltre viene accennato che esistono alcuni rami del control-flow graph che non è necessario memorizzare per tutta la verifica del metodo, perché le istruzioni contenute in quei rami non sono più raggiungibili dal flusso di controllo. I limiti della tecnica esposta restano quindi gli stessi della verifica standard:

o utilizzando l’EEPROM per la memorizzazione del dizionario viene aumentata la dimensione massima possibile del dizionario, ma non è comunque detto che la memoria sia sufficiente per la verifica dei metodi “più complessi” [cap 3.6].