La politica di sicurezza dinamica mediante Firewall

La politica di sicurezza dinamica mediante Firewall

La politica di sicurezza dinamica mediante Firewall è essenzialmente ba-

sata sul concetto di contesto.

In sostanza il Firewall rappresenta una linea di confine tra un contesto e tutti gli altri.

Il JCRE assegna e gestisce un diverso contesto per ciascun package Java che contiene applet. Tutte le istanze di applet appartenenti allo stesso package condividono lo stesso contesto, dunque non è previsto alcun Firewall, alcun confine tra applet appartenenti allo stesso package; così una istanza di applet può liberamente accedere ad oggetti di un'altra istanza di applet appartenente allo stesso contesto.

Oltre ai contesti relativi ai package istallati sulla carta vi è un ulteriore contesto, il JCRE-context, proprio del JCRE; tale JCRE-context  possiede un sistema speciale di privilegi che gli consente di eseguire operazioni che sono invece negate ai contesti di applet.

Figura 3.2 : Contesti e Firewall

Ad ogni istante nella JCVM vi è un solo contesto attivo detto Currently Active Context (CAC). Il CAC può essere indifferentemente il JCRE-context oppure un contesto di applet.

Ogni istruzione del bytecode che produce un accesso ad un oggetto di una istanza di applet viene sottoposta ad una serie di controlli (access control), che analizzeremo in dettaglio più avanti. Tali controlli utilizzano il CAC per determinare se tale accesso è consentito oppure no.

I priviliegi del JCRE-context

Poichè il JCRE-context rappresenta il contesto di sistema, esso possiede alcuni privilegi speciali non concessi a tutti gli altri contesti.

Tra questi privilegi vi è quello che consente al JCRE-context di invocare uno qualsiasi dei metodi appartenenti ad un qualunque altro livello di con-testo, effettuando eventualmente una commutazione di contesto se il contesto cui appartiene il metodo invocato non coincide col JCRE-context.

L'altro importante privilegio è quello che il JCRE-context può accedere, non solo ai metodi di altri contesti, ma anche ai campi-dati di altri contesti e dunque può entrare a tutti gli effetti nel contesto di una applet.

Nonostante queste libertà, in realtà dal JCRE-context si accede solamente ai metodi install, select, process, deselect e getShereableInterfaceObject definiti in una applet.

Generalmente il JCRE-context è il CAC quando la JCVM inizia a lavorare dopo un reset della carta. In sostanza possiamo affermare che il JCRE-context è il "root" dei contesti di una carta e solitamente si trova ad essere o il CAC oppure la testa dello stack nel quale si salvano i contesti prece-denti a seguito di una commutazione di contesto.

Figura 3.3 : Accesso del JCRE ad altri contesti

Commutazioni di contesto

A seguito di un tentativo di accesso ad un oggetto di un applet vengono effettuati alcuni controlli per verificare se l'accesso a tale oggetto può es-sere consentito oppure no.

Se l'accesso non è consentito viene sollevata una eccezione.

Se invece l'accesso è consentito, la JCVM determina se è prevista oppure no una commutazione di contesto.

Durante una commutazione di contesto, il precedente contesto viene salvato in uno stack interno alla JCVM ed il nuovo contesto in cui il siste-ma è commutato diviene il CAC.

Subito dopo la terminazione del metodo che ha provocato la commu-tazione di contesto, la JCVM provvederà a ripristinare il contesto giusto, prelevandolo dallo stack in cui precedentemente era stato salvato; il con-testo originale, quello cioè del chiamante del metodo, viene prelevato dalla cima dello stack e ripristinato come CAC.

Il fenomeno della commutazione dei contesti può avvenire in forma innestata anche se esiste un numero massimo di commutazioni innestate consentite che coincide con la dimensione massima dello spazio di memo-ria previsto per lo stack che deve provvedere a memorizzare, per ciascuna commutazione, il precedente valore del CAC.

La maggior parte dei metodi invocati nelle applet non prevedono una com-mutazione di contesto; soltanto alcuni particolari metodi, che vedremo più avanti, prevedono la commutazione di contesto.

Gli oggetti condivisi e l'iterazione tra applet

Per quanto abbiamo detto sino ad ora sembrerebbe che il Firewall si preoccupi solo di evitare che un oggetto possa essere acceduto da una applet appartenente ad un contesto diverso da quello cui appartiene l'oggetto stesso.

In definitiva il Firewall sembrerebbe solo confinare tutte le azioni di una applet all'interno del suo contesto. Se il Firewall fosse semplicemente questo, non sarebbero consentite interazioni tra applet che invece sono necessarie. Ecco dunque che per consentire ad una applet di interagire con applet di altri contesti oppure col JCRE-context sono previsti dei ben definiti e sicuri meccanismi, previsti nella Java Card Application Program-ming Interface (Java Card API) [4], e che sono:

- JCRE Entry Point Object;

- Global Array;

- Shareable Interface.

JCRE Entry Point Object

Un sistema sicuro ha necessità che un livello di contesto di applet possa richiedere dei servizi al livello privilegiato del JCRE-context invocando dei

metodi che appartengono proprio a quest'ultimo contesto.

I JCRE Entry Point Object, oggetti che appartengono al JCRE-context, mettono a disposizione delle applet dei metodi che, se invocati, produ-cono una commutazione di contesto che permette al Firewall di garantire la sicurezza della carta.

Il metodo detto di entry point viene eseguito solo dopo che il Firewall ha verificato che tutti i parametri passati nella chiamata del metodo sono ac-cessibili nel JCRE-context, ovvero nel contesto in cui si porterà il sistema dopo l'invocazione del metodo di entry point.

Figura 3.4 : Accesso al JCRE-context mediante JCRE Entry Point Object (JCRE EPO)

Esistono due diversi tipi di JCRE Entry Point Object: i Temporary Entry Point Object che possono essere invocati da ogni contesto ma che il Firewall controlla che non vengano istanziati in variabili di classe o in componenti di array (esempi di Temporary JCRE Entry Point Object sono l'APDU Object e tutti i metodi JCRE Entry Point Object utilizzati per le eccezioni) ed i Permanent JCRE Entry Point Object i cui riferimenti possono essere salvati in qualsiasi campo e liberamente riutilizzati (esempi di Permanent JCRE Entry Point Object sono le istanze di AID).

Ecco quindi come si concretizza la possibilità concessa dal Firewall alle applet di poter invocare metodi del JCRE-context. Da sottolineare che solo i metodi dei JCRE Entry Point Object possono essere invocati attra-versando il Firewall che separa il JCRE-context (cui i JCRE EPO appar-tengono) dai contesti di applet in cui sono invocati. I campi-dati di questi oggetti sono protetti dal Firewall e possono essere acceduti solo dal JCRE-context.

Chi designa un oggetto come JCRE Entry Point Object? Spetta ovvia-mente a coloro che implementano il JCRE produrre dei meccanismi attraverso i quali vengono designati oggetti come JCRE Entry Point Object e vengono definiti come temporary o permanent.

Global Array

I Global Array sono temporary global array object ed appartengono al JCRE-context ma possono essere acceduti da tutti i contesti.

Figura 3.5 : Accesso al JCRE-context mediante JCRE Entry Point Object (JCRE EPO) e Global Array Object (GAO)

Come per i Temporary JCRE Entry Point Object anche i riferimenti a Global Array non possono essere salvati in variabili di classe o componenti di array e questo per garantire che non si verifichi un loro ri-uso non autorizzato.

Come per gli Entry Point Object, spetta ovviamente a coloro che imple-mentano il JCRE produrre dei meccanismi attraverso i quali vengono designati oggetti come global array .

Gli unici esempi di global array attualmente utilizzati nella Java Card API sono l'APDU Buffer e il bArray, l'array utilizzato nel metodo install per passare i parametri necessari all'istallazione di una applet.

Shareable Interface

Le Shareable interface sono gli strumenti che consentono una sicura interazione tra applet.

Una shareable interface definisce un insieme di metodi shareable che possono essere invocati da un contesto anche se lo shareable interface object (SIO) che implementa tale metodo appartiene ad una applet di un altro contesto.

Figura 3.6 : Accesso ad applet di altri contesti mediante Shareable Interface Object (SIO)

Per il contesto dell'applet cui appartiene, un SIO rappresenta un comu-nissimo oggetto i cui metodi e campi-dati possono essere acceduti; per tutti gli altri contesti invece il SIO è una istanza di una Shareable Interface e solo i metodi definiti nella Shareable Interface possono essere acceduti; i campi-dati e gli altri metodi del SIO sono invece protetti dal Firewall e dunque possono essere acceduti solo da applet che appartengono al me-desimo contesto.

Meccanismo di interazione tra applet

Di seguito ilustriamo nel dettaglio il meccanismo mediante il quale una applet mette a disposizione ad altre applet una shareable interface:

Supponiamo che l'applet Alice intenda mettere a disposizione di altre applet una serie di servizi (attraverso dei metodi che le altre applet possono invocare). Vediamo il meccanismo previsto per poter mettere effettivamente a disposizione di altre applet i servizi.

Alice per prima cosa definisce una Shareable Interface (SI) che estende la javacard.framework.Shareable. I servizi che Alice vuole rendere accessibili ad altre applet debbono essere definiti come metodi della SI appena creata;

Alice adesso definisce una classe C che implementa la Shareable Interface SI, ovvero C implementa i metodi definiti in SI. Eventualmente in C possono essere definiti anche altri metodi o campi-dati, ma solo i metodi definiti nella SI saranno accessibili attraverso il Firewall, tutti gli altri metodi e tutti i campi-dati definiti nella classe sono invece protetti dal Firewall e dunque sono accessibili solo dal medesimo contesto a cui appartengono;

Alice crea una istanza O della classe C. O appartiene al contesto di Alice e dunque il Firewall assicura ad Alice che solo un applet appartenente al suo contesto può accedere a tutti i campi e metodi di O.

Supponiamo adesso che l'applet Bob voglia accedere ad un servizio offerto da Alice, vediamo le azioni che deve eseguire (Figura 3.7):

Bob per prima cosa invoca il metodo del JCRE-context getAppletShareableInterfaceObject per richiedere ad Alice un riferimento al SIO (effettuando dunque una commutazione di contesto dal contesto di Bob al JCRE-context);

il JCRE invoca, sfruttando i suoi privilegi, il metodo getShareableInterfaceObject di Alice (effettuando dunque una commutazione di contesto dal JCRE-context al contesto di Alice) passandole come parametri l'AID di Bob e l'identificativo del servizio richiesto da Bob;

se Alice accetta di condividere con Bob il servizio, fornisce un riferimento di O a Bob, altrimenti ritorna Null;

Bob verifica il valore che è ritornato il metodo getApplet-ShareableInterfaceObject. Se è il SIO da Alice, lo salva per riutiliz-zarlo; se invece la getAppletShareableInterfaceObject è ritornata Null, allora Bob non ha possibilità di accedere al servizio di Alice;

se il metodo getAppletShareableInterfaceObject è ritornato un SIO, da questo momento Bob può invocare, attraverso il SIO, solo i metodi shareable del SIO; i campi-dati ed i metodi non shareable di O sono protetti dal Firewall che impedisce a Bob di accedervi.

Figura 3.7 : Meccanismo di interazione tra applet

Ogni qualvolta Bob decide di invocare un servizio (metodo condiviso) di Alice avviene una commutazione di contesto tra il contesto di Bob e quello di Alice. Dopo tale commutazione di contesto il Firewall consente al me-todo della SI di accedere a tutti i campi-dati ed i metodi di O e di tutti gli oggetti che appartengono al contesto di Alice, in quanto, a seguito della commutazione di contesto, ci troviamo ad operare nel contesto di Alice. Allo stesso tempo però il Firewall ci garantisce che campi-dati e metodi non condivisi del contesto di Bob non possano essere acceduti.

Analogamente, quando viene ripristinato il CAC precedente (ovvero quando Bob ha terminato di utilizzare il servizio di Alice) il Firewall ci garantisce che Bob non possa invocare niente del contesto di Alice se non i suoi metodi condivisi.

Concludendo possiamo affermare che la Shareable Interface possiede una speciale proprietà: i suoi metodi possono essere invocati "filtrando" attraverso il Firewall mediante una commutazione di contesto.

Figura 3.8 : Commutazioni di contesto

Il metodo Applet.getShareableInterfaceObject

Abbiamo visto che il metodo getShareableInterfaceObject viene invocato dal JCRE-context. Questo metodo è implementato da tutte le applet che vogliono rendere condivisibili dei servizi con altre applet (nel nostro esempio da Alice) e può prevedere dei controlli per verificare se colui che ha fatto richiesta del servizio è autorizzato a riceverlo oppure se il servizio richiesto è effettivamente disponibile. Nel caso in cui la richesta di servizio non possa essere autorizzata, il metodo ritorna Null. Altrimenti il metodo ritorna un SIO della Shareable Interface richiesta.

Il metodo JCSystem.getAppletShareableInterfaceObject

Abbiamo visto che il metodo getAppletShareableinterfaceObject viene invocato dall'applet che intende richiedere un servizio ad un'altra applet (nel nostro esempio da Bob).

L'implementazione di tale metodo è demandata al JCRE che provvede affinché, ad ogni invocazione del metodo, siano garantiti i seguenti con-trolli:

l'AID dell'applet a cui viene richiesto il servizio (nell'esempio l'AID di Alice) sia effettivamente registrato in una apposita tabella interna. Verifica in sostanza che l'applet della quale si richiede il servizio sia già registrata ed attiva sulla carta. Se l'applet richiesta non viene trovata il metodo ritorna Null;

se l'AID dell'applet a cui viene richiesto il servizio è registrata nella tabella interna, allora viene invocato il metodo getShareable-InterfaceObject di quell'applet passandogli come parametri l'AID dell'applet che ha richiesto il servizio (nell'esempio l'AID di Bob) e gli eventuali parametri utili a determinare il tipo di servizio richiesto dall'applet cliente. A seguito dell'invocazione del metodo si ha una commutazione di contesto dal JCRE-context al contesto dell'applet server (nell'esempio al contesto di Alice);

l'applet server restituisce un SIO oppure Null che il metodo getAppletShareableInterfaceObject provvede a ritornare all'applet client.

Regole di accesso a classi ed oggetti

Concludiamo questa nostra analisi del meccanismo di sicurezza dinamica implementato sulle Java Card elencando tutti i controlli che vengono effettuati dalla JCVM per garantire la sicurezza di tale meccanismo.

Un oggetto o una classe vengono acceduti ogni qualvolta viene eseguito un particolare bytecode; a seconda del bytecode eseguito la Java Card VM effettua i controlli di seguito riportati:

Accesso a campi statici di una classe 

Bytecodes interessati: getstatic, putstatic

Se il CAC è il JCRE-context allora l'accesso è consentito.

r    Se il bytecode è putstatic  ed il campo dati interessato dall'operazione è di tipo reference ed il valore da inserire nel campo dati della classe è un riferimento ad un JCRE Temporary Entry Point Object o ad un global Array, allora l'accesso è negato.

r    In tutti gli altri casi l'accesso è negato.

Accesso ad un oggetto di tipo array

Bytecodes interessati: <T>aload, <T>astore, arralength, checkcast, instanceof

Se il CAC è il JCRE-context allora l'accesso è consentito.

Se l'array appartiene ad una applet del CAC l'accesso è consentito.

Se l'array è designato global l'accesso è consentito.

r    Se il bytecode è aastore  ed il campo dati interessato dall'operazione è di tipo reference ed il valore da inserire nel campo dati della classe è un riferimento ad un JCRE Temporary Entry Point Object o ad un global Array, allora l'accesso è negato.

r    In tutti gli altri casi l'accesso è negato.

Accesso a campi di una istanza di una classe

Bytecodes interessati: getfield, putfield

Se il CAC è il JCRE-context allora l'accesso è consentito.

Se il campo appartiene ad una applet del CAC l'accesso è consentito.

r    Se il bytecode è putfield  ed il campo dati interessato dall'operazione è di tipo reference ed il valore da inserire nel campo dati della classe è un riferimento ad un JCRE Temporary Entry Point Object o ad un global Array, allora l'accesso è negato.

r    In tutti gli altri casi l'accesso è negato.

Accesso ai metodi di una istanza di una classe

Bytecodes interessati: invokevirtual

Se il metodo appartiene ad una applet del CAC l'accesso è consentito.

Se il metodo è designato come un JCRE Entry Point Object l'accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.

Se il CAC è il JCRE-context l'accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.

r    In tutti gli altri casi l'accesso è negato.

Accesso ai metodi di una interfaccia standard

Bytecodes interessati: invokeinterface

Se il metodo appartiene ad una applet del CAC l'accesso è consentito.

Se il metodo è designato come un JCRE Entry Point Object l'accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.

Se il CAC è il JCRE-context l'accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.

r    In tutti gli altri casi l'accesso è negato.

Accesso ai metodi di una interfaccia condivisa

Bytecodes interessati: invokeinterface

Se il metodo appartiene ad una applet del CAC l'accesso è consentito.

Se la classe cui appartiene l'oggetto implementa una shareable interface e se l'interfaccia invocata estende una shareable interface allora l'accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.

Se il CAC è il JCRE-context l'accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.

r    In tutti gli altri casi l'accesso è negato.

Accesso ad un oggetto di tipo "eccezione"

Bytecodes interessati: athrow

Se il metodo appartiene ad una applet del CAC l'accesso è consentito.

Se il metodo è designato come un JCRE Entry Point Object l'accesso è consentito.

Se il CAC è il JCRE-context l'accesso è consentito.

r    In tutti gli altri casi l'accesso è negato.

Accesso ad una classe

Bytecodes interessati: checkcast, instanceof

Se l'oggetto appartiene ad una applet del CAC l'accesso è consentito.

Se il metodo è designato come un JCRE Entry Point Object l'accesso è consentito.

Se il CAC è il JCRE-context l'accesso è consentito.

r    In tutti gli altri casi l'accesso è negato.

Accesso ad una interfaccia standard

Bytecodes interessati: checkcast, instanceof

Se l'oggetto appartiene ad una applet del CAC l'accesso è consentito.

Se il metodo è designato come un JCRE Entry Point Object l'accesso è consentito.

Se il CAC è il JCRE-context l'accesso è consentito.

r    In tutti gli altri casi l'accesso è negato.

Accesso ad una interfaccia shareable

Bytecodes interessati: checkcast, instanceof

Se l'oggetto appartiene ad una applet del CAC l'accesso è consentito.

Se la classe cui appartiene l'oggetto implementa una shareable interface e se l'interfaccia invocata estende una shareable interface allora l'accesso è consentito. 

Se il CAC è il JCRE-context l'accesso è consentito.

r    In tutti gli altri casi l'accesso è negato.

Accesso ad un metodo di un oggetto array

Bytecodes interessati: invokevirtual

Se l'array appartiene ad una applet del CAC l'accesso è consentito.

Se l'array è designato global l'accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.

Se il CAC è il JCRE-context l'accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.

r    In tutti gli altri casi l'accesso è negato.