Le Applet Java

Le Applet Java

Le Applet sono piccoli programmi scritti in linguaggio Java per essere scaricati dalla rete ed essere eseguiti all'interno di un'altra applicazione, tipicamente un browser. Il browser di per sé non è in grado di eseguire un'Applet ma necessita di essere integrato con una Java Virtual Machine. Per quelle che sono le caratteristiche di un browser, questo interpreta il contenuto di particolari tag. Quindi anche le Applet per essere riconosciute, ed interpretate dal browser devono essere inserite all'interno di appositi tag. Dunque l'Applet è stata pensata per essere leggera in quanto parte integrante di una pagina html o di un qualcosa che deve essere eseguita in rete.

Evoluzione delle Applet

Come è già stato detto in precedenza per impostazione predefinita le Applet sono eseguite in una Sandbox, la quale offre accesso limitato alle risorse presenti sulla macchina su cui è eseguita. Nel primo paragrafo di questo capitolo è stato fatto presente come nelle primissime versioni del linguaggio Java, per un'Applet era impossibile uscire fuori dalla Sandbox. Ben presto, però, fu capito che questa non poteva essere altro che una limitazione per lo sviluppo delle Applet, in quanto potevano esserci delle situazioni in cui un codice sicuro avesse bisogno di eseguire operazioni considerate pericolose come leggere un file oppure scrivere sul file system. Si passò, dunque, con Java 1.1, alle Applet firmate. Infatti una firma conferiva all'Applet dei permessi per accedere alle risorse che prima invece non aveva, diventando come una semplice applicazione eseguita sulla macchina. Anche questa non era una soluzione definitiva in termini di sicurezza perchè tramite la firma, un'Applet, acquisiva ogni tipo di permesso; in teoria, quindi, era possibile anche che accedesse alla posta elettronica o ad informazioni sensibili e private come i file di password. Per apportare una soluzione a questo problema i costruttori dei principali browser del momento, quali Microsoft per Internet Explorer e Netscape per l'omonimo browser, personalizzarono ulteriormente i loro prodotti dotandoli di policy di sicurezza aggiuntive atte proprio a vincolare questo problema. L'unico inconveniente è rappresentato dal fatto che gli ideatori di queste policy, lavorando ciascuno per il proprio prodotto hanno perso di vista il punto di vista dell'utente, producendo prodotti che sono incompatibili tra loro e con le precedenti versioni di sicurezza in Java. Per ovviare parzialmente a questo inconveniente in Java 2 si è cercato di fornire un modello di sicurezza che fosse completo e raffinato, riferito sia alle applicazioni che alle Applet. Con l'introduzione di una particolare voce all'interno del file java.policy è possibile assegnare alle Applet permessi ben definiti su una particolare risorsa mentre, allo stesso tempo, è possibile mantenere le restrizioni di default sulle altre risorse. Tutto sommato non si era ancora raggiunto una soluzione soddisfacente valida per l'utente, infatti in questo modo si doveva costringerlo a mettere mano al file di policy, dato che l'ambiente Java non fornisce un metodo automatico per modificare questo file. Una soluzione definitiva è stata trovata facendo un piccolo passo indietro e introducendo le Applet firmate RSA[11].

Funzionamento delle Applet

Abbiamo detto che le Applet sono piccoli programmi in linguaggio Java che risiedono su una macchina server e tramite connessione web possono essere scaricate ed eseguite sulla macchina locale.

Il loro funzionamento è abbastanza semplice, anche se alcuni punti meritano una spiegazione dettagliata.

Al momento in cui un browser carica una pagina HTML in cui sia presente un tag relativo ad un'Applet, avvia il plug-in Java che si occuperà di caricare e gestire l'esecuzione dell'Applet. Il compito del plug-in appena caricato è quello di cercare nell'Applet la firma digitale, e nel caso in cui trovi una firma RSA dovrà controllare il file java.policy e il file della policy di sicurezza $USER_HOME/java.policy, alla ricerca di una voce corrispondente al codesource dell'Applet, rappresentato dalla firma e dal codebase, e controllare se il permesso java.lang.Permission usePolicy è stato abilitato.

Nel caso in cui sia stato abilitato il permesso, il plug-in, usa questo per portare avanti nell'esecuzione l'Applet, altrimenti controlla il certificato del firmatario dell'Applet e controlla se è possibile risalire con successo alla Certification Authority. In caso di successo chiede all'utente se intende accettare l'esecuzione di quella particolare Applet estendendo i suoi permessi concedendo AllPermissions

Il  plug-in di Java

I plug-in, in generale, sono programmi atti ad implementare servizi e utilità che altrimenti un ambiente non avrebbe.

I plug-in sono programmi che vengono scaricati dalla rete o installati tramite qualche altro dispositivo, e vengono incorporati con l'ambiente di qualche applicazione, in modo da offrire quei servizi che altrimenti non sarebbe possibile fornire 

Il plug-in di Java è un programma che può assumere dimensioni di qualche MegaByte, quindi non deve essere usato sempre e per tutte le applicazioni, ma solo laddove se ne richieda effettivamente l'utilizzo. Una di queste è, per esempio, l'Applet.

In ogni caso il plug-in non deve essere scaricato ogni volta, ma basta che lo sia la prima volta che lo si vuole utilizzare. Una volta che è stato caricato il plug-in, occorre modificare le pagine HTML in modo da renderle compatibili. 

A partire da Java 2, se si vuole che la nostra Applet utilizzi una delle funzioni di questa versione di Java occorre utilizzare il plug-in, in quanto né Netscape né I.E. supportano Java 2. i vantaggi del plug-in sono che non è più compito  dello sviluppatore preoccuparsi del diverso funzionamento dell'Applet nei diversi browser, oltre al fatto che il plug-in eredita il modello di sicurezza di Java 2 quindi c'è un forte controllo sulle azioni delle Applet. 

Nel paragrafo 1.4.1 abbiamo accennato alla incompatibilità dei browser nell'interpretare le Applet fino alla versione di Java 2. Infatti a partire da questa versione di Java, la JavaSoft introdusse il plug-in Java, il cui scopo era quello di cercare di fornire un ambiente runtime Java universale per tutti i browser. Il plug-in viene fornito di default dalla JavaSoft ed eseguito tramite un JRE, Java Runtime Environment. Il plug-in dovrebbe essere scritto in modo da supportare tutto ciò che potrebbe essere fatto con un ambiente Java e da essere compatibile con tutti i browser e soprattutto con tutte le piattaforme. Sia il JDK che il JRE integrano il plug-in Java.

Le Applet firmate RSA

Affinché un'Applet possa essere definita con l'appellativo di Applet firmata RSA occorre che venga accompagnata da un certificato di sviluppatore da parte di Verisign[9] o Thawte . Un'Applet per essere firmata deve subire il processo di firma di tutti le sue classi, e questo può essere fatto con il tool della JavaSoft, jarsigner, il quale è stato adottato nel nostro processo, oppure nell'omonimo prodotto della Netscape, signtool. Naturalmente l'utilizzo di uno strumento o dell'altro, al fine del prodotto finale non ha alcuna rilevanza significativa. Una soluzione alternativa, e molto più vantaggiosa, rispetto alla firma di ogni singola classe, è rappresentata dalla firma di un file JAR, nel quale erano state, precedentemente, inserite tutte le classi costituenti l'Applet.

Tool di sviluppo per le Applet firmate

La Sun Microsystem fornisce dei tool che permettono la firma e la creazione di un file JAR. Questi tool sono rispettivamente jarsigner e jar.

I               JAR

Il tool jar [14] è un'applicazione Java che combina più file in un singolo file di archivio .jar, è un tool di archiviazione e compressione basato sul formato di compressione ZIP e ZLIB. Lo scopo della sua creazione, fu quello di facilitare il packaging di Applet o di applicazioni Java in un unico file. Questo, infatti, permette il caricamento, da parte di un utente, di tutto il necessario per l'esecuzione dell'Applet o dell'applicazione in un'unica transazione HTTP, oltre a consentire una connessione con durata minore, per via della compressione dei file. Inoltre un altro beneficio nel compattare un'Applet in un file JAR è che in questo modo è possibile firmare un solo file e inserire un'unica entry nella pagina HTML che la deve caricare. Il tool può prendere in ingresso tre tipi di file: il file manifest (disponibile sotto forma di opzione), il file Jar di destinazione e i file da comprimere.

Un file manifest è generato in automatico dal tool ed è sempre corrispondente alla prima entry nel file .jar. Di default, il suo nome è META-INF/MANIFEST.MF, e corrisponde al posto in cui vengono memorizzati tutte le meta-informazioni relative all'archivio.

Nel caso in cui il file JAR non sia firmato, il contenuto del file manifesto si riferisce esclusivamente alla versione del prodotto e ai dati del creatore. Se, invece, il file JAR è firmato, nel manifesto sono memorizzate anche tutte le informazioni relative alla firma ovvero i nome e gli hash dei file.

II            Jarsigner

Il tool Jarsigner [12], presente in JDK, permette di apportare e verificare la firma di un file .jar. Il jarsigner, per generare la firma di un file JAR, usa chiavi e certificati provenienti da un keystore. Il certificato potrebbe essere anche autoprodotto, ma generalmente si predilige un certificato firmato da una Certification Authority, per maggiori garanzie.

Per generare la firma si utilizza una chiave privata. Il file JAR firmato contiene, tra le altre cose, una copia del certificato della chiave pubblica, corrispondente alla chiave privata, utilizzata per la firma. Questo tool può anche servire per verificare la firma posta su un file .jar, utilizzando il certificato posto al suo interno. Per specificare che si intende verificare una firma si utilizza l'opzione -verify. Il tool può firmare solo file JAR creati con il tool JAR del JDK o file zip, infatti un JAR è un archivio di file compressi in un formato analogo e compatibile con quello .zip. Gli algoritmi per la firma utilizzati dal tool sono: DSA[1] (Digital Signature Algorithm) con l'algoritmo di digest SHA-1, oppure RSA, con l'algoritmo di digest MD5. Questo significa che se le chiavi pubbliche e private sono state create con DSA, jarsigner utilizzerà l'algoritmo "SHA1withDSA", altrimenti utilizzerà l'algoritmo "MD5withRSA" se le chiavi erano state create con RSA.

L'utilizzo tipico di un  JAR firmato recapitare codice che vogliamo sia riconosciuto come "trusted". La distribuzione di un codice firmato permetta a tutti coloro che lo utilizzano di sapere con certezza che quel codice proviene da chi lo ha firmato e non è stato modificato dopo la firma, da terze parti. Quella della firma del software è una buona norma adottata anche dalla SUN per il rilascio degli aggiornamenti dei propri IDE.

Nelle versioni precedenti a quella 1.2.1 del JDK, se una firma veniva forzata,  cioè veniva tentato di falsificare, in fase di esecuzione l'Applet veniva comunque eseguita ma non riceveva dei permessi extra. Questo comportava un problema notevole in quanto era possibile modificare quelle classi, presenti in JAR, e che non tentavano di uscire dalla Sandbox. Questo bug è stato risolto a partire dalla versione 1.2.1 di Java richiedendo che ciascuna classe all'interno dello stesso package, presenti in un JAR firmato fosse firmato dallo stesso certificato.

III          Keytool

Il keytool[13] è un'utility per la gestione delle chiavi e dei certificati, il quale permette ad un utente di amministrare le proprie chiavi e di associarle a dei certificati per processi di autenticazione o di firma digitale.

Questo tool memorizza le chiavi e i certificati all'interno di un archivio chiamato keystore

Il keystore è un contenitore particolare, il cui accesso tramite password lo rende sicuro e protetto, che contiene le informazioni dell'utente necessarie all'implementazione del processo di firma di file; vale a dire la chiave privata e il certificato, contenente la rispettiva chiave pubblica. Un keystore può essere memorizzato in un file oppure all'interno di un database o altre tipologie di supporto.

Il keystore può contenere una o più entry identificate da un alias. Sono disponibili due possibili tipi di entry, una per i certificati affidabili, definita come trustedCertEntry, e una per contenere le chiavi private definita come KeyEntry.

Il tool Keytool permette la creazione di coppie di chiavi pubbliche e private tramite la specifica dell'opzione -genkey. È possibile anche specificare ulteriori opzioni per le chiavi come l'algoritmo da usare, la lunghezza delle chiavi ed altre.

Un'altra opzione di questo tool è -selfcert, la quale permette la creazione di un certificato autofirmato di tipo X.509, tramite tutte le informazioni contenute nel keystore. Infine sono presenti anche altre opzioni relative alla gestione diretta del keystore e delle chiavi. Per qualsiasi altra informazione si lascia al lettore la consultazione del manuale come indicato nella bibliografia.