Problemi di sicurezza: il flusso illegale di informazioni

I meccanismi di sicurezza dinamica, di cui abbiamo parlato nel capitolo precedente, non sono tuttavia sufficienti a prevenire alcuni tipi particolari di attacco alla sicurezza dell'intero sistema.

In questo capitolo ci preoccuperemo di analizzare due diverse tipologie di attacco alla sicurezza proponendo metodologie e supporti utili per la pro-grammazione sicura di applet per Java Card multi-applicative.

Una applicazione del meccanismo del Firewall

Per comprendere a fondo le due diverse tipologie di attacco alla sicurezza occorre partire da un esempio di applicazione che sfrutta appieno tutte le potenzialità offerte dal meccanismo del Firewall.

Nell'esempio che andiamo ad analizzare consideriamo tre applet: Alice, Bob e Charlie. Per una trattazione completa dell'esempio si veda A Formal Specification of  the Java Card Firewall [5].

Alice implementa una Shareable Interface caratterizzata da un metodo condiviso chiamato foo.

Alice è pronta a condividere tale Shareable Interface con Bob ma non con Charlie che dunque non risulta autorizzato ad accedere al servizio.

Quando Alice riceve una richiesta di servizio attraverso la chiamata, da parte del JCRE, del metodo getShareableInterfaceObject, per prima cosa verifica che l'applet che ha richiesto il servizio sia Bob, confrontando l'AID ricevuto come parametro dalla getShareableInterfaceObject con l'AID di Bob. Se il richiedente il servizio è proprio Bob allora la getShareable-InterfaceObject ritorna un riferimento al SIO richiesto, altrimenti ritorna Null.

Come abbiamo visto nel capitolo precedente, Bob chiederà il servizio foo ad Alice invocando il metodo del JCRE-context getAppletShareable-InterfaceObject.

Supponiamo adesso che la terza applet Charlie provi a richiedere lo stes-so servizio (foo) ad Alice senza però averne l'autorizzazione.

Per richiedere il servizio ad Alice, Charlie invoca il metodo del JCRE-context getAppletShareableInterfaceObject il quale a sua volta invocherà il metodo getShareableInterfaceObject di Alice passandogli, come parame-tro, l'AID del richiedente del servizio (ovvero l'AID di Charlie).

Poichè l'applet Charlie non è autorizzata ad accedere al servizio foo, quando Alice analizzerà l'AID passotogli dalla getShareableInterface-Object, confrontandolo con l'AID dell'applet autorizzata ad utilizzare il servizio (ovvero l'AID di Bob), verificherà che Charlie non ha l'autorizza-zione ed il metodo ritornerà Null, impedendo di fatto a Charlie di utilizzare il servizio richiesto.

Un primo esempio di flusso illegale di informazioni

Supponiamo adesso che, inavvertitamente oppure volontariamente, Bob faccia trapelare il riferimento al SIO di Alice all'applet Charlie.

Adesso Charlie, possedendo direttamente il riferimento al SIO, non ha bisogno di invocare il metodo del JCRE-context getAppletShareable-InterfaceObject per richiedere il servizio foo di Alice, basterà che sempli-cemente invochi il servizio di Alice utilizzando il riferimento al SIO ricevuto inavvertitamente da Bob.

Per come abbiamo visto lo sviluppo dell'applicazione sino a questo mo-mento, Alice effettua l'unico controllo sull'identità del richiedente il servzio foo all'interno del metodo getShareableInterfaceObject  facendo due sup-posizioni più che legittime:

Quando una applet client intende richiederle per la prima volta un servizio ne richiede il SIO attraverso il metodo del JCRE-context getAppletShareableInterfaceObject;

Quando una applet che ne ha fatto richiesta riceve un riferimento al SIO, quest'ultima lo salva per effettuare ulteriori accessi al servizio senza dover richiedere ogni volta il SIO, nella certezza di non far trapelare il riferimento al SIO ad altre applet non autorizzate.

É proprio quest'ultima supposizione che viene, inavvertitamente o volonta-riamente, disattesa da Bob.

Quando Charlie effettua una chiamata al metodo foo attraverso il SIO rice-vuto da Bob, Alice, forte delle supposizioni viste sopra, concede il servizio a Charlie che dunque ottiene delle informazioni non autorizzate. Abbiamo così realizzato un flusso illegale di informazioni.

Figura 1 : Sistema Alice - Bob - Charlie con presenza di flusso illegale di informazioni

Difesa da applet non corrette

Prima di illustrare la soluzione al problema esposto di flusso illegale di in-formazioni occorre effettuare una precisazione importante.

L'esempio di flusso illegale di informazioni potrebbe farci pensare che il sistema di sicurezza dinamica realizzato dal JCRE non sia sufficiente. In realtà il meccanismo di sicurezza dinamica previsto dalle Java Card è sufficiente a garantire una efficace politica di sicurezza. Se tutte le applet di una applicazione sono scritte correttamente, secondo quanto previsto da Java Card Runtime Environment Specification [2], abbiamo la garanzia che tutti i dati ed i metodi non condivisi potranno essere acceduti solo da applet appartenenti allo stesso contesto e che i servizi condivisi saranno accessibili solo alle applet autorizzate (secondo le modalità imposte dal-l'applicazione).

L'aspetto che stiamo analizzando prende invece in considerazione l'ipotesi che, in tempi anche successivi, possano essere installate sulla carta delle applet implementate non correttamente (con o senza dolo) che potrebbero danneggiare il sistema agente sulla carta e, nei nostri casi di studio, generare un flusso illegale di informazioni, precedentemente non presen-te.

Nell'esempio illustrato nel paragrafo precedente abbiamo potuto evincere che una scrittura erronea (volontaria o involontaria) dell'applet Bob (che ad esempio passa a Charlie il riferimento al SIO del metodo foo di Alice) può provocare un flusso illegale di informazioni.

La soluzione: uso del metodo JCSystem.getPreviousContextAID()

Quello che vogliamo adesso verificare è se esistono degli accorgimenti che il programmatore di applet può adottare affinché, nel momento in cui decide di mettere a disposizione di applet client dei servizi (metodi condivisi), sia possibile effettuare controlli sulle applet che accedono a questi servizi condivisi, evitando così che informazioni confidenziali dell'applet server possano essere trasmesse ad applet non autorizzate a riceverle.

Ragionando sull'esempio in esame, noi vogliamo verificare se esistono degli strumenti che consentano ad Alice di evitare di offrire il proprio servizio foo a Charlie anche a seguito di una non corretta implementazio-ne dell'applet Bob.

Quello che in sostanza vogliamo verificare è se è possibile rafforzare l'implementazione dell'applet server Alice in modo da garantirne la sicurezza e la confidenzialità anche a seguito dell'installazione sulla carta di applet client non corrette che con essa verranno ad interagire.

Per realizzare questo dobbiamo far cadere una parte di una delle due sup-posizioni su cui si era fondata l'implementazione dell'applet server Alice ovvero:  "Quando una applet che ne ha fatto richiesta riceve un riferimento al SIO, quest'ultima lo salva per effettuare ulteriori accessi al servizio senza dover richiedere ogni volta il SIO, nella certezza di non far trapelare il riferimento al SIO ad altre applet non autorizzate".

Supponendo adesso che una applet (nell'esempio Charlie) possa ottenere il riferimento al SIO del servizio condiviso del server (nell'esempio di Alice) non direttamente dall'applet server col procedimento noto, bensì da un altra applet client, dobbiamo introdurre nel metodo condiviso (servizio) dell'applet server un ulteriore controllo tale da verificare se l'applet che sta effettuando l'accesso al servizio abbia effettivamente l'autorizzazione ad accedervi oppure no. In questo modo anche una applet client che avesse ottenuto in modo irregolare il SIO verrebbe comunque bloccata dal server proprio all'interno del servizio stesso.

In letteratura questo tipo di flusso illegale di informazioni è stato risolto mediante l'uso di un metodo del JCRE-context, il getPreviousContextAID [5,8], in grado di ritornare l'AID dell'applet attiva immediatamente prima dell'ultima commutazione di contesto.

Se dunque immaginiamo di invocare la getPreviousContextAID come prima istruzione all'interno del metodo condiviso, tale metodo ritornerà l'AID dell'applet client che ha invocato il servizio (dato che l'invocazione di un servizio condiviso mediante il SIO comporta una commutazione di contesto dal contesto dell'applet client chiamante al contesto dell'applet server cui il servizio appartiene).

Adesso l'applet server può confrontare l'AID ottenuto dal metodo get-PreviousContextAID con la lista delle applet client autorizzate ad acce-dere al servizio e, se non appartiene alla lista, può negare il servizio all'ap-plet richiedente.

In Figura 2 viene mostrato il codice modificato delle tre applet del nostro esempio di studio.

E' importante che il controllo dell'AID avvenga necessariamente come prima istruzione del metodo, per evitare che eventuali ulteriori commu-tazioni di contesto (relative ad esempio a chiamate innestate di metodi) provochino un errato recupero dell'AID.

In conclusione possiamo stilare una regola che consente di garantire la sicurezza di accesso ad un metodo condiviso:

In ciascun metodo condiviso occorre invocare, necessariamente come prima istruzione del metodo, il metodo getPreviousContext-AID per ricavare l'AID dell'applet richiedente il metodo condiviso stesso e confrontare tale AID ottenuto con la lista degli AID delle applet autorizzate ad utilizzare il metodo condiviso. Se l'AID in questione non appartiene alla lista, allora l'esecuzione del metodo condiviso deve essere conclusa.

Figura 2 : Sistema Alice - Bob - Charlie modificato senza flusso illegale di informazioni

Un secondo esempio di flusso illegale di informazioni

Quello che andremo adesso ad analizzare rappresenta un altro esempio di flusso illegale di informazioni che non è risolvibile semplicemente rispettando la regola formulata al termine del precedente paragrafo.

Per rendere ancora più chiaro il significato dell'esempio utilizzeremo, anzichè tre generiche applet, un tipico esempio di Java Card multi-applicativa rappresentato dal borsellino elettronico (electronic purse o più semplicemente Purse) che interagisce con due applet che gestiscono due diverse loyalty (raccolte punti): una applicazione per coloro che viaggiano spesso in aereo (che chiameremo AirFrance) ed una invece che gestisce i punti accumulati presso un noleggio di auto (che chiameremo RentaCar).

Quando il proprietario della carta vuole sottoscrivere una raccolta punti (loyalty) con una determinata attività (nel nostro esempio con Air France per i voli aerei e con RentaCar per il noleggio delle auto) basterà che scarichi la corrispondente loyalty applet sulla propria carta. Questa applet scaricata dovrà interagire con Purse, in particolare per conoscere le tran-sazioni effettuate sul borsellino al fine di aggiornare la raccolta dei punti in accordo con le transazioni stesse.

Nel nostro esempio AirFrance dovrà aggiungere chilometri di volo gratuiti al proprietario della carta ogni volta che questo acquisti con Purse un biglietto aereo su voli Air France (il proprietario della carta utilizzerà i chi-lometri accumulati per acquistare biglietti di volo Air France gratuiti per tratte di chilometraggio equivalente), mentre RentaCar dovrà aggiungere ore di noleggio auto gratuite al proprietario della carta ogni volta che questo effettui noleggi di auto attraverso le catene di noleggio  accreditate.

Può inoltre esistere la possibilità di scambiare o sommare i punti raccolti attraverso diverse loyalty partner: per esempio i punti raccolti con Rent-aCar possono essere sommati con quelli raccolti da AirFrance per acqui-stare un biglietto di volo gratuito per una tratta più lunga (ovviamente sacrificando i punti raccolti per il noleggio gratuito di una auto) .

Il caso di studio che abbiamo sin qui descritto in versione semplificata  è stato implementato da Gemplus - Pacap. Per una trattazione completa dell'esempio si veda Electronic Purse Applet Certification: extended ab-stract [6].

Nel caso di studio che analizziamo, il purse ha una Shareable Interface (getTransaction) utilizzata dalle loyalty per consentire a ciascuna di queste di prelevare le proprie transazioni e calcolare i relativi punti, mentre ciascuna loyalty ha una Shareable Interface (getBalance) messa a disposizione delle altre loyalty partner per prelevare i punti accumulati ed eventualmente sommarli ai propri.

Nel caso di studio si suppone che tutte le principali funzioni offerte da Java (verificatore del bytecode) e dalle Java Card (il Firewall) per garantire la sicurezza siano rispettate da Purse.

Dopo aver descritto il caso di studio passiamo ad analizzare come si genera il flusso illegale di informazioni.

La struttura dati transactionLog di Purse, che contiene l'elenco delle ultime transazioni effettuate attraverso Purse, è un campo che può contenere un numero di transazioni limitato. Dopo un certo numero di transazioni dunque, tale campo si riempirà e le successive transazioni effettuate verranno registrate nel campo transactionLog semplicemente sopra-scrivendo le transazioni presenti. Così facendo, se una loyalty non è informata di quando il transactionLog è pieno, può succedere che veda soprascritta una sua transazione che così andrà perduta e con essa andranno persi anche i relativi punti raccolti da quella operazione.

Per evitare che si possano soprascrivere transazioni non ancora utilizzate da una loyalty per il calcolo dei punti, un servizio di logfull è proposto da Purse alle loyalty. Quando il transactionLog è pieno (e dunque una nuova transazione andrà a soprascrivere una vecchia transazione presente nel campo) Purse chiamerà il metodo logfull delle loyalty applet che hanno sottoscritto con Purse il servizio per informarle che il campo transaction-Log è pieno e per consentire loro di scaricare le transazioni di interesse del transactionLog prima che vengano distrutte e soprascritte da nuove transazioni in arrivo.

Abbiamo detto che il purse chiamerà il metodo logfull solo per le loyalty applet che hanno sottoscritto il servizio e dunque che hanno pagato una certa cifra per averlo.

Adesso noi supporremo che AirFrance abbia sottoscritto il servizio di logfull mentre RentaCar abbia scelto di non sottoscriverlo e dunque di non usufruire di tale possibilità, rischiando così di perdere qualche transazione utile per incrementare il proprio paniere di punti.

Dimostreremo con un semplice esempio come RentaCar possa riuscire ugualmente ad ottenere lo stesso servizio di logfull senza però averlo sottoscritto.

Quando il transactionLog è pieno, Purse lancia il metodo logfull di AirFrance, l'unica loyalty che ha sottoscritto questo servizio.

Nella Figura 3 sono rappresentate, mediante frecce, tutte le chiamate a metodi condivisi invocate dal momento in cui viene lanciato il metodo logFull (freccia n. 1) e fino al suo ritorno (freccia n.6).

All'interno di questo metodo, AirFrance esegue nell'ordine le seguenti operazioni:

preleva dalla struttura dati transactionLog di Purse le transazioni relative ad AirFrance per il calcolo dei propri punti (mediante la chiamata a metodo condiviso getTransaction rappresentata in Figura 3 dalle frecce n. 2 e 3);

aggiorna il campo-dati balance relativo ai punti totalizzati con Air- France;

aggiorna il campo extended_balance che contiene i propri punti raccolti sommati a tutti i punti finora raccolti dalle loyalty partner (mediante la chiamata a metodo condiviso getBalance rappresen-tata in Figura 3 dalle frecce n. 4 e 5).

È proprio quest'ultima operazione che rappresenta un problema: per aggiornare il campo extended_balance infatti, AirFrance lancia il metodo getbalance delle loyalty partner (in questo esempio solo di RentaCar).

In questo caso, quando RentaCar si vede leggere il proprio campo balance da AirFrance, può capire che il campo transactionLog di Purse è

Figura 3 : Sistema Purse - AirFrance - RentaCar

pieno e può così chiamare anch'egli il metodo getTransaction di Purse (frecce n. 5 e 6 di Figura 4) per ricevere le proprie transazioni, ottenendo così lo stesso servizio per il quale AirFrance ha pagato ed invece Rent-aCar no.

Questo esempio rappresenta una fuga di informazioni da AirFrance verso RentaCar che costituisce un vero e proprio flusso illecito di informazioni che vogliamo poter rilevare ed eventualmente evitare.

Figura 4 : Sistema Purse - AirFrance- RentaCar con flusso illegale

Possibile soluzione al problema di flusso illegale

Purtroppo, abbiamo detto, questo flusso illecito di informazioni non può essere rilevato dal meccanismo del Firewall che consente la chiamata di metodo provvedendo a verificare semplicemente se il metodo invocato è una Shareable Interface oppure no.

Neppure l'uso del metodo getPreviousContextAID all'interno del metodo getTransaction di Purse evita questo flusso non autorizzato di informazioni in quanto sia AirFrance che RentaCar utilizzano lo stesso metodo condiviso, in condizioni normali, per accedere, periodicamente, ciascuno alle proprie transazioni presenti nel transactionLog di Purse; dunque entrambe le applet avranno il proprio AID contenuto nella lista delle applet autorizzate ad accedere al servizio offerto dal metodo getTransaction.

Per individuare lo strumento più adatto ad evitare il flusso illegale di informazioni occorre per prima cosa individuare la ragione per la quale questo flusso illecito si verifica.

Nel nostro primo esempio il flusso illecito era dovuto al fatto che una applet, volutamente o no, aveva passato un riferimento al SIO ad una applet non autorizzata ad utilizzarlo.

In questo caso di studio invece il flusso illecito si realizza nel momento in cui, all'interno del metodo condiviso getBalance si invoca il metodo shareable getTransaction.

Il flusso illecito di informazioni si ottiene quindi a seguito del formarsi di una catena circolare di chiamate innestate a metodi condivisi, così come è illustrato nella Figura 5.

Nelle Figure 6 e 7 che seguono vengono rispettivamente illustrati gli accessi consentiti al metodo getTransaction e l'accesso che produce un flusso illecito di informazioni.

Figura 5 : Catena circolare di chiamate innestate a metodi condivisi

Compito quindi del programmatore dell'applet server sarà quello di garan-tire che, all'interno di un servizio da lui offerto ad alcune applet client, sia possibile accedere a metodi condivisi del server solo ad applet che abbia-no sottoscritto quel servizio.

Nel nostro esempio, il programmatore dovrà poter garantire che, a seguito dell'utilizzo del servizio di logFull da parte di Purse, all'interno di questo servizio, metodi condivisi di Purse a rischio di flusso illegale siano acces-sibili solo da loyalty che abbiano sottoscritto il servizio di logFull.

Per garantire questa possibilità è necessario introdurre qualche struttura dati aggiuntiva al Purse.

Figura 6 : Accessi consentiti al metodo getTransaction di Purse

Figura 7 : Accesso a getTransaction di Purse attraverso getbalance (flusso illegale)

Abbiamo preso in considerazione due possibili strategie delle quali passeremo ad analizzare gli aspetti, i pregi ed i difetti scegliendo poi la soluzione più conveniente e più generale possibile. Tale soluzione sarà utilizzata per verificare l'efficacia del metodo proposto da un punto di vista implementativo.

La prima soluzione prospettata è quella di aggiungere alla struttura dati di Purse solo un campo booleano, definito notNested, che possa indicare quando non sia opportuno effettuare una catena circolare di chiamate innestate a metodi condivisi.

Questa soluzione sfrutta una struttura dati che è sicuramente presente all'interno dell'applet che gestisce un servizio a pagamento, ovvero una lista degli AID delle applet che hanno sottoscritto quel servizio.

La soluzione impone di:

settare la variabile notNested a true subito prima di lanciare il servizio di logFull;

aggiungere un ulteriore controllo in testa al metodo condiviso che non vogliamo generi flusso illegale (nell'esempio getTransaction). Dopo aver ricavato l'AID dell'applet che ha richiesto il servizio (attraverso la getPreviousContextAID), occorre non soltanto con-frontare tale AID con la lista delle applet autorizzate ad utilizzare il metodo con-diviso (garantisce dal primo tipo di flusso illegale di informazioni) ma dobbiamo anche garantire, se notNested è settato a true, che l'AID ottenuto appartenga alla lista delle applet che hanno sotto-scritto il servizio (nell'esempio il servizio di logFull);

resettare la variabile notNested a false subito dopo aver concluso il servizio di logFull.

Il pregio di questa soluzione è quella di aver aggiunto un numero minimo di strutture dati a Purse per implementare questa ulteriore garanzia.

Il difetto però è rappresentato dalla scalabilità della soluzione proposta all'aumentare dei servizi a pagamento offerti da Purse.

Supponiamo infatti che Purse, oltre al servizio di logFull, offra un ulteriore servizio a pagamento.

Purse avrà bisogno di due liste, una per ciascun servizio offerto, in cui inserire gli AID delle applet che hanno sottoscritto il servizio relativo.

Utilizzando solo il boolean notNested, all'interno dei metodi condivisi che non vogliamo che producano flusso illegale, dovremmo essere in grado di stabilire quale servizio è attualmente in corso. L'individuazione del servizio è infatti necessaria per discriminare quale lista di AID utilizzare per determinare l'accesso oppure no al metodo condiviso.

Dovremmo quindi preoccuparci di aggiungere una ulteriore variabile denominata ad esempio service che registri il servizio attualmente in ese-cuzione.

Inoltre dovremmo preoccuparci di effettuare nella maniera giusta i controlli in ciascun metodo condiviso che non vogliamo che produca flusso illegale preoccupandoci di selezionare ogni volta la o le liste di applet dei servizi che effettivamente possono utilizzare quel metodo al fine di evitare che:

applet autorizzate si vedano negate l'accesso;

applet non autorizzate ottengano l'accesso al metodo generando così quel flusso illegale di informazioni che volevamo eliminare.

Una soluzione meno flessibile ma sicuramente più semplice e scalabile è quella di prevedere l'utilizzo di una diversa struttura dati che al posto del boolean notNested preveda, tra le altre variabili, anche una variabile di tipo AID denominata notNestedActiveContext.

Tale variabile, inizializzata a Null, manterrà il valore Null fintanto che le catene di chiamate innestate a metodi condivisi saranno consentite.

Nel momento in cui verrà lanciato un servizio (ad esempio di logFull) a partire dal quale, e fino alla cui terminazione, non vogliamo consentire catene di chiamate innestate, basterà settare notNestedActiveContext con l'AID dell'applet della quale viene invocato il servizio.

Adesso effettuare il controllo di flusso illegale di informazioni è molto più semplice; all'interno dei metodi dell'applet Purse che non vogliamo siano acceduti in modo innestato (nel nostro esempio di getTransaction) impo-niamo i seguenti controlli:

viene chiamato il metodo JCSystem.getPreviousContextAID che  ritorna l'AID dell'applet chiamante;

si effettua il classico controllo che confronta l'AID ottenuto al punto 1) con la lista degli AID delle applet autorizzate ad accedere al servizio (previene il primo esempio di flusso illegale di informazio-ni); se l'AID appartiene alla lista si prosegue, altrimenti l'accesso viene negato;

se notNestedActiveContext == Null (è consentito effettuare catene di chiamate innestate) l'accesso al metodo viene concesso;

se notNestedActiveContext != Null (non è consentito effettuare catene di chiamate innestate) allora il suo valore rappresenta l'AID dell'applet verso cui è stato lanciato il servizio; il controllo da effettuare è dunque quello di verificare se notNestedActiveContext coincide con l'AID ottenuto dal punto 1). Questo significa che il metodo è stato chiamato proprio dall'applet che ha ricevuto il servizio dunque non siamo nel caso di una catena di chiamate innestate che genera flusso illegale di informazioni. Di conseguen-za l'accesso è consentito. Altrimenti l'accesso viene negato in quanto il metodo è stato acceduto da un applet diversa da quella verso cui è stato lanciato il servizio e dunque siamo in presenza di una catena di chiamate innestate che può generare un flusso illegale di informazioni.

facile verificare che la soluzione proposta è scalabile sia rispetto al numero di possibili applet che interagiscono con l'applet server, sia rispet-to al numero di servizi a pagamento messi a disposizione dal server.

Nel prossimo capitolo ci preoccuperemo di produrre una possibile imple-mentazione del sistema costituito da Purse, AirFrance e RentaCar, pro-durremo una modifica di RentaCar tale da generare un flusso illegale di informazioni ed infine passeremo a dare una implementazione completa  della soluzione al problema di flusso illegale proposta in questo capitolo.