La sicurezza delle Java card

La sicurezza delle Java card

Le procedure di sicurezza delle Java Card sono una combinazione tra le procedure di sicurezza previste dal linguaggio Java e le protezioni aggiun-tive definite attraverso la piattiaforma Java Card.

Analizziamo adesso queste due procedure di sicurezza.

Procedure di sicurezza del linguaggio Java

Le Java Card supportano un sottoinsieme di istruzioni del linguaggio Java ed una versione adattata alle Java Card delle specifiche della Virtual Ma-chine (VM). Per questo i meccanismi di sicurezza previsti dal linguaggio Java, sulle Java Card, sono rimodellati attorno al sottoinsieme di istruzioni che opera sulle carte stesse.

Le procedure di sicurezza del linguaggio Java (adattate alle specifiche delle Java Card) rappresentano la base delle procedure complessive di sicurezza previste dalla piattaforma Java Card.

Di seguito sono riportate le principali procedure di sicurezza previste dal linguaggio Java che ritroviamo sulle Java Card [8]:

il linguaggio Java è fortemente tipato. Non sono dunque consentite conversioni illegali di dati (ad esempio non è consentito convertire un integer a puntatore);

il linguaggio Java prevede controlli sugli accessi ad array per prevenire accessi oltre la sua lunghezza;

il linguaggio Java non prevede puntatori aritmetici. Questo ci garan-tisce che non vi è possibilità per un programma di "curiosare" attra-verso la memoria;

le variabili, nel linguaggio Java, debbono necessariamente essere ini-zializzate prima di essere utilizzate;

il livello di accesso a tutte le classi, a tutti i metodi ed a tutti i campi-dati è fortemente controllato. Questo non consente ad esempio che un metodo privato possa essere invocato esternamente dalla classe di definizione e appartenenza.

Procedure di sicurezza aggiuntive della piattaforma Java Card

Sono riportate di seguito le procedure di sicurezza aggiuntive previste dalle Java Card per garantire livelli di sicurezza adatti agli innumerevoli usi che di una Java Card possono essere fatti [8]:

Definizione di oggetti persistenti e transienti

Nella piattaforma delle Java Card gli oggetti sono memorizzati, per default in memoria persistente (EEPROM). Per ragioni essenzialmente di sicurez-za e di miglioramento delle prestazioni delle carte, le Java Card memoriz-zano i dati temporanei - come ad esempio le chiavi di sessione per la crit-tografia - come oggetti transienti nella RAM. Il tempo di vita di questi og-getti può inoltre essere dichiarato come clear_on_deselect (il contenuto dell'oggetto transiente viene azzerato quando l'applet correntemente in esecuzione viene deselezionata oppure quando la carta subisce il reset) oppure come clear_on_reset (il contenuto dell'oggetto transiente viene az-zerato solo quando la carta subisce il reset).

Concetto di Atomicità e transazioni per i dati

Durante le operazioni di scrittura su oggetti persistenti possono avvenire situazioni di reset (ad esempio nel caso in cui si abbia un calo di alimen-tazione) che potrebbero rendere inconsistenti gli aggiornamenti (scritture) in corso.

Per garantire quindi l'integrità dei dati sono definite tre specifiche :

1. la tecnologia Java Card assicura che un aggiornamento di un campo-dati di un oggetto persistente avvenga in maniera atomica; ovvero se durante l'aggiornamento dell'oggetto persistente si verifica un errore o un reset, la piattaforma si preoccupa di ripri-stinare il valore che il campo-dati possedeva prima che l'operazione di aggiornamento avesse inizio;
2. la tecnologia Java Card assicura l'atomicità sull'intero blocco di dati contenuto in una struttura ad array; ovvero se durante la copia o l'aggiornamento dei dati contenuti in un array si verifica un errore o un reset, l'intero contenuto dell'array viene ripristinato ai valori che possedeva prima che l'operazione di copia o aggiornamento aves-se inizio;
3. la tecnologia Java Card infine supporta la modalita a transazioni; ovvero è possibile garantire l'atomicità non solo per l'aggiorna-mento di un solo campo-dati ma anche per un insieme di campi-dati di tipo persistente; con questa modalità o tutti i campi-dati della transazione sono stati correttamente aggiornati oppure vengono ripristinati tutti i precedenti valori.

Sicurezza dinamica mediante il Firewall

Concludiamo con l'aspetto della sicurezza delle carte che andremo ad approfondire meglio nei prossimi paragrafi ovvero il meccanismo del Firewall per garantire un livello di sicurezza dinamico.

Questo meccanismo è incaricato di imporre l'isolamento ed il controllo degli accessi agli oggetti di ogni applet. Visto che in alcune situazioni le applet possono condividere campi-dati e metodi di istanze di una classe, il Firewall deve concedere alle applet autorizzate la possibilità di accedere a tali campi-dati e metodi ed al tempo stesso deve impedire a qualsiasi applet non autorizzata di eseguire accessi non dovuti a campi-dati e a metodi di istanze di classe. Il Firewall è dunque responsabile dell'impo-sizione di politiche di accesso.

Il Firewall è l'ultima difesa della JCVM contro codice non "fidato": deve garantire che l'esecuzione di bytecode non pregiudicherà l'integrità della memoria e la riservatezza dei dati della carta.

I Controlli di sicurezza effettuati su un applet

Prima che una applet possa essere installata ed eseguita su una Java Card deve superare un certo numero di controlli di sicurezza sia off-card (fuori dalla carta) sia on-card (sulla carta).

I controlli off-card sono principalmente quelli effettuati:

1. dal Compiler che analizza i file java che costituiscono l'applet e verifica se rispettano i vincoli imposti dal linguaggio Java (che abbiamo detto è fortemente tipato) producendo un file binario detto class file (file .class).
2. dal Verifier, un componente della Java Card Virtual Machine, che si preoccupa di verificare che i file .class abbiano un formato corretto e rispettino una serie di vincoli strutturali quali ad esempio:
1. non gestiscano in modo errato lo spazio di memoria e non si verifichino fenomeni di stack overflow o di stack underflow;
2. non siano violate le restrizioni di accesso imposte ad esem-pio ai metodi ed ai campi-dati privati;
3. i metodi siano chiamati con il numero e la tipologia appro-priata di argomenti;
4. ect, ect.
3. dal Converter che si preoccupa di verificare che i file .class utiliz-zino esclusivamente il sottoinsieme di istruzioni Java supportato dalle Java Card, convertendo poi i file class in CAP (Converted APplet) file (file .cap).

Figura 3.1 : Livelli di sicurezza sulle Java Card

Mentre i controlli on-card sono effettuati:

1. dal Loader  che ha il principale compito di caricare il CAP file sulla carta verificando preliminarmente se la carta può supportare quel CAP file (ad esempio se vi è sufficiente spazio di memoria per installare l'applicazione);
2. dal linker con il compito di verificare che i riferimenti interni previsti dal CAP file siano locali allo spazio di memoria del package e che invece i riferimenti esterni siano collegati a locazioni accessibili dei package riferiti oppure siano collegati al JCRE.

Questi due ultimi controlli on-card possono però solo garantire politiche di sicurezza statica, dato che non eseguono previsioni circa il comporta-mento delle applet a runtime. In conseguenza di ciò, il JCRE impone vincoli di sicurezza aggiuntivi in fase di esecuzione, presenti nelle specifi-che del JCRE [2].

Controlli aggiuntivi in fase di esecuzione sono realizzati mediante l'utilizzo del Firewall che andremo ad analizzare nel dettaglio dal prossimo para-grafo.