La Sicurezza in quattro Applet

Fino ad ora sono stati affrontati quelli che sono i problemi di carattere generale della tesi, cioè come è stata affrontata la sicurezza in Java nelle varie versioni e quella che è l'architettura della sicurezza in Java con la JCA e la JCE.

In questo capitolo è nostra intenzione dare una descrizione del progetto da noi implementato. Saranno descritti tutti gli aspetti progettuali e implementativi che sono stati affrontati.

Partiremo con una descrizione di quella che è la causa che ci ha spinto all'implementazione di questa tesi, quindi passeremo a  quelle che sono state le scelte progettuali, soffermandosi sulle scelte che hanno caratterizzato maggiormente tutto il lavoro.

Infine affronteremo quella che è la struttura di tutto il progetto, spiegando come è stato organizzato lo sviluppo del progetto e quale sono state le scelte di maggiore interesse.

Descrizione del progetto

Fino ad ora abbiamo descritto quelli che sono gli strumenti a disposizione per gestire la sicurezza nel linguaggio Java, senza però soffermarsi su quelle che sono le soluzioni presenti al momento. Abbiamo dato spiegazioni, in qualche caso, molto dettagliate, di alcuni dei package che permettono l'implementazione di alcune delle funzionalità di crittografia e sicurezza, senza però dire se sono presenti soluzioni software che le implementano.

Sul mercato attuale le problematiche della sicurezza stanno sempre più prendendo spazio e importanza. Questo ha portato ad un enorme sviluppo di soluzioni hardware e software.

Le soluzioni software presenti sono per lo più applicazioni del tipo standalone, in cui cioè il software è gia presente sulla macchina locale e la sua esecuzione avviene esclusivamente offline.

Il nostro progetto si pone come obiettivo quello di fornire agli utenti di Internet, un servizio di firma digitale che permetta loro di firmare un file di qualsiasi tipo. Affinché la firma sia considerata attendibile da un altro utente o ente, è necessario che questa sia accompagnata da un certificato digitale, a sua volta firmato da una autorità di certificazione considerata fidata. Affinché l'operazione di firma sia considerata attendibile occorre che sia verificabile in qualche modo.

Infine affinché sia possibile firmare e verificare un documento è necessaria una coppia di chiavi asimmetriche.

Il progetto si pone come obiettivo quello fornire ad un utente gli strumenti necessari a compiere le principali funzioni crittografiche e per la generazione di firme digitali. Gli strumenti forniti sono appunto:

Perchè le Applet

Una volta definito il progetto, il primo problema da risolvere consiste nello scegliere quali strumenti adoperare per implementarlo, vale a dire il linguaggio da usare e se sono disponibili alcuni strumenti da utilizzare come supporto per quel particolare linguaggio di programmazione. Naturalmente per questo tipo di progetto la scelta era veramente ampia, in quanto sono presenti numerosi linguaggi e strumenti software che permettono di trattare la sicurezza nella comunicazione e la crittografia.

La nostra scelta poteva vertere su numerosi strumenti software; infatti potevamo orientarci sugli ActiveX control, i quali a differenza di altri strumenti molto utilizzati, come il JavaScript, o il MacroMedia Flash, i quali ne sono sprovvisti, possiede anche il supporto per le firme digitali. L'unico inconveniente che ci ha spinto a rivolgerci altrove è stato il fatto che questo strumento lavora solo sul browser Internet Explorer, e pochi altri browser ad esso compatibili; ma quello ancor più riduttivo è che funziona solo su sistemi operativi Microsoft. Quindi questa scelta poteva limitare enormemente l'utilizzo del pacchetto da noi implementato. Quindi la nostra scelta è ricaduta, sulle Applet di Java, le quali sfruttano l'indipendenza dalla macchina, tipica del linguaggio Java, ed in più sono compatibili con tutti i maggiori browser presenti attualmente sul mercato. Uno dei grossi vantaggi rappresentati dall'utilizzo delle Applet di Java, oltre al fatto che generalmente sono di piccole dimensioni, è che viene  lasciata completamente all'utente la scelta se eseguire o meno il software scaricato. Infatti è compito dell'utente a collegarsi alla pagina web dove risiede il software e fidarsi della correttezza e affidabilità dello stesso.

Inoltre la presenza della possibilità di firmare le Applet e di accompagnarle con un certificato che ne garantisca l'affidabilità, dà maggiori garanzie del suo utilizzo sicuro. In questo modo, se l'utente decide di eseguire un codice, per l'esattezza un'Applet, la cui origine è dubbia, ed il cui certificato non è affidabile, la responsabilità ricadrà totalmente sull'utente stesso.

Per tutto il resto, ci pensa l'architettura della piattaforma Java a garantire la sicurezza della macchina locale, tramite il meccanismo della Java Virtual Machine.

Le Applet hanno la caratteristica di essere chiamate direttamente dal browser e la loro esecuzione può avvenire solo all'interno di questo ultimo, il quale capisce che deve essere lanciata un'Applet tramite l'interpretazione di specifici tag. 

Per far in modo che venga eseguita un'Applet come Applet firmata è necessario che sia inclusa in un file .jar e che questa venga firmata. Infatti se l'Applet non fosse confezionata in un archivio con estensione .jar e non fosse firmata non potrebbe assumere dei permessi speciali che le permettono di eseguire operazioni che altrimenti non potrebbe eseguire.

Possibili utenti

Prima di soffermarci nella descrizione dettagliata delle specifiche di progetto, può essere interessante vedere quali possono essere i vari utenti, cioè a chi possono interessare i servizi offerti.

L'utenza più ovvia è tutta quella di Internet; infatti essendo un progetto implementato tramite Applet, e quindi caricate tramite pagine HTML, tutti i "navigatori della rete" sono possibili utenti. In ogni caso l'utenza più significativa e realistica, e soprattutto quella a cui è rivolto questo progetto è rappresentata da tutti coloro che sono interessati ad avere dei servizi di crittografia in maniera mobile, cioè a tutti coloro che hanno il bisogno di firmare un certo documento.  

Struttura del progetto

Come abbiamo già accennato in precedenza questo progetto è strutturato in maniera tale da fornire diversi servizi, i quali sono:

Come è facilmente intuibile, i servizi cardine di tutto il progetto sono gli ultimi due, ovvero i servizi di firma e verifica della stessa, in quanto gli altri due servizi possono essere visti come servizi di supporto, anche se possono, presi singolarmente, ricoprire ugualmente un ruolo importante.

La firma digitale ricopre un ruolo importante all'interno del progetto perché, oltre al fatto che è il servizio per cui è stata pensata tutta la tesi, riveste un ruolo molto significativo all'interno della crittografia, mettendo due utenti nelle condizioni giuste per comunicare, sicuri del fatto che nessuno possa alterare i propri messaggi. Analogamente anche la verifica ricopre un ruolo importante perché permette all'utente che riceve il messaggio firmato di avere la garanzia che questo ultimo non sia stato modificato da nessuno.

Per quanto riguarda la struttura interna del progetto, si è pensato di dividere tutti i servizi in quattro Applet distinte. La scelta di dividere il progetto in quattro Applet è basata sul fatto che, in questo modo ogni Applet risulta più "leggera" dal punto di vista delle prestazioni durante il caricamento da web. Quindi il progetto è stato scomposto in quattro package Java, i cui sono rispettivamente:

Sarà adesso nostra intenzione fornire una spiegazione dettagliata di ciascun package, partendo però con il fornire alcune informazioni comuni ad ogni package e che sono state indispensabili ai fini del corretto funzionamento del progetto.

Applet e HTML

Per quanto riguarda le Applet, abbiamo detto essere dei programmi in linguaggio Java, generalmente di piccole dimensioni che vengono scaricate, per essere eseguite, da pagine web scritte in HTML. Proprio il fatto che vengono scaricate dal web merita una breve spiegazione. Quando una pagina, ad esempio HTML,  viene caricata, il browser della macchina locale, legge, o meglio interpreta, quelli che sono i comandi presenti su tale pagina. Ad ogni comando, detto tag, corrisponde un'azione da parte del browser che ricostruisce la pagina HTML sulla macchina locale, con tutte le funzionalità in essa contenute. Un tag molto importante è il tag <applet> insieme al tag </applet>, che delimitano il campo di azione di un'Applet presente sulla pagina web. Nel primo di questi due tag si inseriscono le indicazioni necessarie per comunicare alla macchina client dove reperire, sul server, il codice compilato dell'Applet e alcune opzioni come possono essere le dimensioni della finestra in cui visualizzarlo. Tra i due tag, invece, è possibile specificare, tramite altri tag, alcuni parametri che verranno utilizzati nell'Applet. Questi ultimi tag non sono necessari e la loro presenza è legata alla particolare Applet; quindi teoricamente il tag di chiusura dello spazio dell'Applet, </applet>, può trovarsi immediatamente dopo quello di apertura. Il nome dell'Applet da eseguire deve essere posto all'interno del tag <applet> preceduto dall'attributo code ed è rappresentato dal nome dell'elemento contenente il metodo init(), con estensione .class. Per quanto riguarda le Applet firmate queste sono rappresentate da un file .jar che deve essere specificato nell'attributo archive, sempre all'interno del tag <applet>. Per il passaggio dei parametri all'Applet, il discorso è analogo; adoperando il tag <param> è possibile specificare un elemento HTML di nome param e attributi name e value

Su ogni pagina web possono essere presenti più Applet ciascuna limitata dai propri tag. Un esempio che renda più semplice la comprensione di quanto detto fino ad ora è riportato di seguito:

Per quanto riguarda il primo parametro,

serve per indicare il plug-in nel caso in cui questo non fosse presente sulla macchina locale.

Firmare  i file JAR delle Applet

Come abbiamo già detto, un'Applet, affinché acquisisca dei privilegi non posseduti in partenza, deve essere firmata. L'operazione di firma di tutte le classi di un'Applet può risultare un'operazione lunga e noiosa. Per evitare questi problemi, ci si affida ad una tecnica ormai collaudata e affidabile; si raggruppano tutte le classi presenti nell'Applet in un file .jar, di cui abbiamo già discusso nel primo capitolo, e si firma una sola volta questo file mediante un tool chiamato jarsigner. Sia il tool che il file .jar sono già stati introdotti nei precedenti capitoli, quindi non sarà nostra intenzione approfondire ulteriormente questi argomenti ma semplicemente mostrare, tramite un esempio come si può creare un file .jar, contenente le classi dell'Applet e firmare il tutto. Per poter firmare un file .jar occorre disporre  di una coppia di chiavi pubblica e private. Generalmente queste coppie di chiavi sono mantenute in un file particolare, il keystore, di cui abbiamo già parlato nel primo capitolo.

Di seguito riportiamo il comando necessario alla creazione di un file .jar avente al suo interno il package dell'Applet.

Per comodità di rappresentazione riportiamo il comando che abbiamo adoperato per creare il file .jar relativo all'Applet di creazione dei certificati, il file Certificato.jar

In questo comando è da mettere in evidenza la creazione del file manifest, il quale conterrà tutte le firme delle varie classi, che vengono create in automatico dal comando jar. Un esempio di contenuto del file manifest, anche questa volta preso da un caso reale, sempre relativo alla stessa Applet, è riportato di seguito:

Figura : Estratto di un file manifest

All'inizio del file manifest, inoltre viene aggiunta un'indicazione su quella che è la classe principale, specificata dall'attributo Main-Class: . Nel nostro caso la classe principale è stata specificata tramite l'ausilio di un file di testo: mainClassCertif.txt, come è specificato nel comando. La presenza di questo file viene specificata a riga di comando dall'opzione m, che nel nostro comando è insieme ad altre opzioni. Per tutte le spiegazioni sull'utilizzo del comando jar, si rimanda il lettore alla consultazione dell'help disponibile con il tool, digitando semplicemente jar seguito da invio. Inoltre è possibile e necessario, per il loro corretto funzionamento, specificare la presenza di package aggiuntivi inseriti. Questo viene fatto inserendo la dichiarazione dei package aggiuntivi all'interno del file mainClassCertif.txt Per completezza di descrizione riportiamo anche quello che è il contenuto del file sopra citato:

Per quanto riguarda, infine, la firma del file .jar questa viene eseguita tramite un comando del tool jarsigner, come riportato di seguito:

Anche questa volta abbiamo riportato un esempio vero, utilizzato per firmare l'Applet per la creazione del certificato, dove, però, sono stati, ovviamente, omesse le password per l'accesso al keystore, da noi generato, e per l'accesso alla chiave privata in esso contenuta.

A questo punto, non ci resta che passare alla descrizione di ciascuna delle quattro Applet, partendo dalla creazione delle chiavi asimmetriche, passando poi alla creazione dei certificati e alla firma di un documento, per concludere poi con l'Applet per la verifica della firma.

Applet  "CreaCoppiaChiavi"

Questa Applet fornisce le funzionalità per creare una coppia di chiavi asimmetriche. Lo scopo di questa Applet dunque è quello di creare delle chiavi pubbliche e private, e per far ciò si avvale dell'utilizzo di due algoritmi molto noti ed utilizzati, RSA e DSA. Per l'utente è anche possibile scegliere la dimensione delle chiavi, tra tre possibili varianti, per quanto riguarda le chiavi di tipo RSA, mentre tra solo due possibilità, e per le chiavi di tipo DSA. Questa limitazioni per le chiavi di tipo DSA sono dovute ad un fatto di implementazione a basso livello dei package utilizzati per la creazione delle chiavi, infatti non è possibile creare chiavi di questo tipo e di tale lunghezza. Generalmente le chiavi possono essere create di qualsiasi lunghezza purché multiplo di 8, ma nel nostro caso abbiamo scelto di ridurre a poche e prefissate dimensioni per una questione di praticità, infatti una lunga lista di dimensioni disponibili avrebbe soltanto confuso un utente poco esperto e per di più sarebbe stato poco utile dato che la lunghezza della chiave incide enormemente sulla sua sicurezza; inoltre quelle messe come possibili scelte sono quelle più utilizzate. Dunque l'utente potrà scegliere sia il tipo che la dimensione della chiave tramite una finestra di dialogo come questa in Figura 3‑ :

Figura : Selezione parametri delle chiavi asimmetriche

Naturalmente all'utente non è preclusa a priori la possibilità di scegliere una chiave di tipo DSA di lunghezza 2048 bit, ma qualora un utente selezionasse questa combinazione verrebbe generata un'eccezione, il cui unico compito è quello di informare l'utente della non corretta selezione dei parametri, tramite una finestra di dialogo, che per la precisione è creata con un oggetto di tipo JOptionPane. Un oggetto di questo tipo ha come scopo proprio quello di creare finestre di dialogo per la comunicazione di particolari eventi all'utente, fornendo anche la possibilità di inserire delle icone nel messaggio per una spiegazione anche visiva di quello che è il tipo del messaggio. Un oggetto JOptionPane fa parte del package javax.swing, e presenta alcune costanti che ne permettono la personalizzazione a seconda del tipo di messaggio e dell'azione che consegue alla notifica del messaggio. Infatti tramite un oggetto di questo tipo è anche possibile porre all'utente una domanda con delle opzioni di scelta.

Ritornando alla spiegazione del funzionamento dell'Applet, una volta che l'utente avrà selezionato i parametri tecnici della coppia di chiavi, le chiavi vengono create e sono pronte per essere salvate in due file. In questo caso all'utente viene lasciata la scelta di dove salvare il file con il nome e l'estensione che vuole, come mostrato in Figura ‑ :

Figura : Salvataggio chiavi pubbliche

Sulla scelta dell'estensione vengono fatte delle restrizione a seconda del tipo di chiave, pubblica e privata. Per quanto riguarda le chiavi pubbliche, le estensioni che si possono scegliere sono mostrate in Figura 3‑ , mentre per le chiavi private le estensioni si limitano a: .pem .p12 e .pfx, che sono anche gli standard più utilizzati. Di default viene assegnato un nome standard sia alla chiave privata sia alla chiave pubblica. Questo nome viene creato in parte con una stringa costante e in parte con una stringa che dipende dal tipo di chiave, cioè se pubblica o privata e dall'algoritmo usato per la creazione delle coppie di chiavi. Quindi il nome di default assegnato alle chiavi avrà la seguente forma:

CTipoAlgoritmo

Per il salvataggio della chiave privata, come abbiamo già detto, è necessario proteggerne l'accesso con una password, la quale sarà chiesta all'utente con una finestra di dialogo come quella riportata in Figura 3‑ :

Figura : Immissione della password per il salvataggio della chiave privata

Come è possibile notare dalla figura la scrittura della password a video viene protetta con degli asterischi per conservarne la riservatezza.

Una volta completata tutta la procedura di acquisizione delle informazioni dall'utente si passerà alla procedura di salvataggio vera e propria, che consisterà nella codifica in Base64 di entrambe le chiave. Per la chiave privata invece viene eseguita anche una cifratura con password proprio come descritto nel Capitolo 2 , nel paragrafo relativo. Alla fine della procedura di creazione della coppia di chiavi, verrà visualizzata una finestra di dialogo che notificherà l'avvenuta creazione delle chiavi, come mostrato in Figura 3‑ :

Figura : Conferma della creazione delle chiavi

In ogni caso, sia in caso di creazione avvenuta con successo, sia in caso di fallimento, la procedura ripartirà dall'inizio, pronta per la creazione di una nuova coppia di chiavi.

Applet "CreaCertificato"

Questa Applet fornisce le funzionalità per creare un certificato dalle informazioni dell'utente e da una coppia di chiavi generata ad hoc. Questa Applet permette due scelte per l'utente, che riguardano il tipo di algoritmo da utilizzare per la creazione e la firma del certificato una sulla durata della validità del certificato. Essendo un certificato autofirmato, le caratteristiche tecniche del certificato vengono fatte scegliere all'utente stesso, come la durata, il tipo di firma da apportare al certificato, e l'estensione del certificato.

Siccome abbiamo pensato di suddividere il progetto in quattro Applet per mantenere ogni servizio indipendente degli altri il più possibile, ci è sembrato logico far creare autonomamente,a questa Applet, le chiavi pubbliche e private necessarie per la creazione e la firma del certificato.  Infatti una volta che l'utente ha acconsentito a far eseguire l'Applet per la creazione di un certificato autofirmato, la prima cosa che viene chiesta all'utente è la selezione della durata della validità dello stesso e l'algoritmo da utilizzare per la creazione delle chiavi e la firma del certificato, tramite una finestra come quella mostrata in Figura 3‑ :

Figura : Selezione dei parametri del certificato

Sono possibili solo due scelte tra tutte le combinazioni di algoritmi di creazione delle chiavi e di firma; questo sempre per cercare di rendere meno difficile la scelta ad un utente poco esperto e poi perchè sono anche le combinazioni maggiormente utilizzate in crittografia. Per quanto riguarda la durata della validità del certificato, questa deve essere  un numero positivo e non può prevedere nessun tipo di altro carattere. Infatti viene eseguito un controllo sulla consistenza del dato inserito e in caso di errata immissione viene lanciata un'eccezione il cui scopo è quello di avvisare dell'errore e consentire all'utente di ripartire, come mostrato in Figura 3‑ :

Figura :Controllo immissione parametri validità certificato

Una volta che il controllo sulla coerenza del dato immesso è andato a buon fine, si passa alla creazione di due chiavi asimmetriche, proprio come fatto nell'Applet precedente. Anche qua le informazioni sull'algoritmo della chiave vengono recuperate dalla finestra di dialogo mostrata adesso; l'unica cosa che cambia dall'Applet precedente è per la lunghezza della chiave che, in questo caso, per togliere ogni possibile problema di incompatibilità tra algoritmo e lunghezza si è imposto, per default e senza possibilità di modifica, la lunghezza pari a 1024 bit. Anche in questa Applet è presente la limitazione sul numero di caratteri che possono comporre la password di memorizzazione della chiave privata.

Quindi a questo punto sono disponibili le chiavi asimmetriche ma mancano le informazioni relative all'utente. Siccome il certificato è autofirmato, il proprietario è anche colui che lo rilascia, quindi i campi Subject e Issuer presenti nel certificato in formato X.509 sono identici. Questo campo viene costruito tramite le informazioni prelevate dalla seconda finestra di dialogo mostrata all'utente in cui si chiede di inserire i propri dati personali, che faranno parte delle informazioni contenute nel certificato. Queste informazioni sono quelle mostrate in Figura ‑ :

Figura : Inserimento di parametri personali nel certificato

In Figura 3‑ si è riportato, per esempio, la schermata utilizzata per creare il certificato utilizzato per le prove di funzionamento dell'Applet. Non viene fatto nessun controllo sull'immissione dei dati, ad eccezione del fatto che i campi non possono essere vuoti. Per attenersi allo standard di definizione dei certificati, le stringhe che vengono inserite non possono superare la lunghezza massima di 64 caratteri, ad eccezione della stringa dello stato che non può superare i 2 caratteri. Nel caso in cui questi vincoli non fossero rispettati l'Applet non genererà alcun errore, ma sarà generata un'eccezione da una classe esterna, adoperata per la creazione di una struttura di supporto del certificato. Questa è la classe X509Name, la quale viene adoperata su un oggetto della classe X509V3CertificateGenerator. Queste classi non fanno parte della JCA, ma bensì appartengono ad un provider esterno importato per l'occasione, org.bouncycastle. Quindi la classe X509Name, solleverà un eccezione qualora la lunghezza delle varie stringhe non fosse consona ai parametri esposti in precedenza. Per quanto riguarda invece la creazione della data di inizio validità del certificato, viene presa la data e l'ora del momento in cui viene eseguita l'Applet, mentre per il calcolo della data di fine validità, si somma la quantità inserita dall'utente durante la prima finestra di dialogo. Quindi la durata della validità del certificato creato scadrà alla stessa ora di quella di creazione di un numero di giorni, pari a qualli specificati dall'utente, successivi alla stessa.

A questo punto tutto è pronto per poter creare il certificato, che quindi verrà generato tramite la classe X509V3CertificateGenerator del provider org.bouncycastle. Il certificato verrà firmato con la chiave privata corrispondente alla chiave pubblica presente all'interno dello stesso.

Il certificato deve, adesso, essere memorizzato all'interno di un file. Per quanto riguarda il certificato, a seconda dell'estensione scelta dall'utente cambia il modo in cui viene salvato. Se viene scelta come estensione .p7b, allora il file viene salvato in formato binario, altrimenti viene salvato in formato di codifica Base64, limitato anche dalle seguenti due stringhe:

Il salvataggio avviene in maniera analoga a quanto avveniva per le coppie di chiavi, come si può vedere in Figure ‑ :

Figure : Salvataggio certificato

Per l'operazione di salvataggio del certificato, a differenza di quanto avveniva per la coppia di chiavi non è previsto alcun nome di default da assegnare al file. Le estensioni associabili al file contenente il certificato sono le stesse delle chiavi pubbliche, viste in precedenza.

La chiave privata invece viene salvata di default con un nome costruito della base dei parametri scelti dall'utente, ovvero:

Anche l'estensione, come è possibile intuire è prefissata in .pfx. Il salvataggio della chiave privata avviene nella stessa directory in cui l'utente ha deciso di salvare il file del certificato.

Applet "FirmaApplet"

Questa Applet fornisce le funzionalità per firmare un documento con l'utilizzo di una chiave privata. È importante specificare che, per il corretto funzionamento dell'Applet, l'utente deve essere già in possesso di una coppia di chiavi pubblica e privata preventivamente salvate in due file, e la chiave privata deve essere anche protetta con una password. Questa Applet non implementa alcuna comunicazione con il server da cui è stata scaricata, ma una volta acquisiti i permessi, semplicemente lavora sulla macchina locale, salvando anche tutto il necessario su questa. Quindi se un utente volesse recapitare il file con la firma ad un altro utente, sarà compito suo fare in modo che possa riceverli.

Lo scopo di questa Applet dunque è quello di prendere un file, o un documento in genere, di firmarlo con la chiave privata dell'utente quindi rendere disponibile la firma per l'invio eventuale ad un alto utente, oppure per il salvataggio in un file.

Quando l'utente che decide di permettere l'esecuzione di questa Applet sulla propria macchina si troverà davanti una pagina come quella mostrata in Figura ‑ :

Figura : Form iniziale per la firma

A questo punto devono essere inseriti i valori all'interno dei campi. L'Applet effettua un controllo sul corretto inserimento dei valori all'interno dei campi. Nel caso in cui alcuni campi rimanessero vuoti al momento della pressione del pulsante di firma, verrebbe generata un'eccezione per la notifica dell'assenza di dati nei campi, come riportato in Figura ‑ :

Figura : controllo immissione nel form di firma

Per poter immettere un path di un file all'interno dei campi è stata prevista la presenza di pulsanti per l'apertura di finestre di dialogo che permettono la navigazione all'interno del file system della macchina locale. Per quanto riguarda la selezione della chiave privata, la navigazione nel file system è stata filtrata ai soli file che hanno estensione .pem, .pfx o .p12, come mostrato in Figura ‑ :

Figura : Selezione della chiave privata per la firma

Anche in questa Applet la password è gestita in modo tale da garantirne la protezione durante la digitazione, infatti ogni carattere inserito sarà sostituto,a video, da un asterisco.

Una volta inseriti i valori all'interno dei campi e una volta che il controllo sull'immissione è andato a buon fine si passerà all'operazione di firma vera e propria, processata allo stesso modo di come descritta sommariamente nel Capitolo 2 . Per quanto riguarda la determinazione dell'algoritmo di firma da utilizzare abbiamo deciso di utilizzare soltanto l'algoritmo di digest SHA-1, insieme all'algoritmo di creazione della chiave; quindi gli algoritmi di firma utilizzati nel nostro progetto saranno:

SHA1withRSA

e

SHA1withDSA    

Quindi, effettuata la firma, se tutto è andato a buon fine, viene visualizzata un finestra di dialogo per informare l'utente di quanto accaduto e per chiedere se intende avere un resoconto del processo di firma. Per far fare all'utente questa scelta è stato utilizzato un oggetto JOptionPane, proprio come si era fatto per l'Applet di creazione delle chiavi. La finestra di dialogo si presenterà all'utente come mostrato in Figura ‑ :

Figura : Conferma avvenuta firma

Nel caso in cui l'utente decida di avere un resoconto del processo di firma appena terminato si troverà davanti una schermata in cui sono riassunti tutti i dati più importanti quali l'algoritmo di firma utilizzato, la posizione, sulla macchina locale, in cui è posto il file con la chiave privata e una casella di testo in cui è posta la firma del file in formato codificato Base64, proprio come è mostrato in Figura ‑ :

Figura : Resoconto del processo di firma

Come si può notare, è possibile anche salvare la firma in un file tramite la pressione del pulsante "Salva". A questo pulsante corrisponde l'apertura di una finestra di dialogo simile a quella vista nel caso del salvataggio delle coppie di chiavi. Di default è previsto un nome da assegnare a questo file; tale nome è recuperato dal nome del file che abbiamo appena firmato con l'aggiunta dell'estensione .sig, come mostrato in Figura ‑ :

Figura : Salvataggio file di firma

Ad operazione terminata sarà possibile rincominciare con la firma di un nuovo documento.

Applet "VerificaFirma"

Questa Applet fornisce le funzionalità per verificare la firmare di un documento con l'utilizzo della chiave pubblica, presente nel certificato, associata alla chiave privata utilizzata per la firma. Questa Applet, per funzionare correttamente ha bisogno di tre dati di ingresso, che sono proprio quelli prodotti dall'operazione di firma, più un certificato che garantisca l'affidabilità della chiave pubblica associata. Quindi per funzionare avrà bisogno del file di cui abbiamo calcolato la firma, il file con la firma, e il file con il certificato o la catena di certificazione.

Un utente che avrà permesso ad un'Applet di essere eseguita sulla propria macchina con tutti i permessi di cui ha bisogno, si troverà davanti una schermata come quella mostrata in Figura ‑ :

Figura : Form iniziale di verifica della firma

In questa Applet, come possiamo notare da quanto mostrato in figura, è possibile inserire ogni campo tramite il pulsante "Sfoglia" che permete l'ispezione del file system della macchina locale; questo implica che in qualche modo l'utente deve aver ricevuto i dati ed esserseli salvati sulla propria macchina.

Per quanto riguarda il campo relativo alla firma, può essere riempito manualmente, facendo ad esempio un "taglia e incolla" dal file oppure selezionando il file stesso; in ogni caso nel campo, il file apparirà sempre in codifica Base64, mentre negli altri campi compariranno i path completi dei file. Per quanto riguarda la selezione dei file da file system, sono previsti dei filtraggi di accesso  a seconda del tipo di file che si deve selezionare. Per il file di firma è previsto un filtro di accesso ai soli file che terminano con un'estensione .sig, mentre per il file del certificato è previsto un filtro ai soli file che hanno estensione di un certificato, come visto nel paragrafo 3.4.4. Per l'accesso al file, invece, non sono previste alcune operazioni di filtraggio.

Anche questa volta l'Applet compie un'operazione di controllo sull'immissione dei dati, generando un'eccezione qualora uno o più campi rimanessero vuoti. Il risultato dell'eccezione generata, può essere visto in Figura ‑ :

Figura : Controllo immissionedati per la verifica

Una volta che tutti i campi sono stati riempiti correttamente la pressione del pulsante "Verifica" fa partire l'operazione di verifica vero e proprio.

Dato che il certificato può essere singolo oppure una catena di certificazione, questa differenziazione va trattata adeguatamente. Se abbiamo una catena di certificazione dobbiamo verificare che il certificato root sia un certificato Trusted e quindi controllare che la firma su ogni certificato sia stata effettuata con la chiave privata di colui che ha lo rilasciato. Ammettendo come ipotesi di base che un certificato di root trusted, sia firmato con la chiave privata del possessore e di chi lo ha rilasciato, in quanto coincidenti, dobbiamo prendere la chiave pubblica presente in un certificato e andare a verificare l'affidabilità del certificato sottostante, fino ad arrivare al certificato dell'utente. Per verificare se un certificato root di una catena è considerato trusted o meno abbiamo controllato se il suo numero di serie compariva all'interno di un file, chiamato cacerts. Questo file è installato insieme allo SDK di Java e la sua locazione sul file system è nella directory java_homejrelibsecurity. Questo file contiene, di partenza, 25 entry, ciascuna indicante un certificato di root trusted. In ogni caso è possibile aggiungere in ogni momento un certificato; per compiere questa operazione possiamo adoperare il tool keytool

Nell'eventualità in cui il certificato non fosse presente all'interno del file cacerts, verrà visualizzato un messaggio di errore con la stessa tecnica vista nelle Applet precedenti, altrimenti si parte con il controllo di affidabilità della catena, e infine, a controllo avvenuto, si passa alla verifica della firma con la chiave pubblica recuperata dal certificato utente. È da far presente che per recuperare la catena di certificazione, in Java, dobbiamo affidarci alle classi viste nel Capitolo 2 , e per la creazione dell'oggetto CertPath, il certificato dell'utente dovrebbe essere memorizzato al primo posto della catena, mentre il certificato di root all'ultimo.

Quindi per quanto riguarda l'operazione di verifica della firma, se questa conclude con esito positivo, allora verrà visualizzata una finestra di dialogo simile a quella mostrata in Figura ‑ , la quale notificherà l'avvenuta verifica con successo e chiederà all'utente se vuole una schermata con il resoconto dell'operazione oppure no. In tal caso verrà visualizzata una schermata simile a quella mostrata in Figura ‑ .

Capitolo 2 Conclusioni

Lo scopo di questa tesi è quello di fornire dei servizi che permettano ad un utente di effettuare operazioni di firma di un certo documento e permettere ad un altro utente di effettuare la corrispondente operazione di verifica. Tutto questo viene contornato dalla possibilità, per l'utente, di crearsi autonomamente delle coppie di chiavi asimmetriche, sia di tipo RSA che di tipo DSA, e la possibilità di creare un certificato autofirmato, per la certificazione di una chiave pubblica, e la creazione della rispettiva chiave privata.

La validità del certificato è limitata, in quanto non firmato da un'autorità di certificazione riconosciuta. Non avendo la possibiltà di ottenere un certificato firmato da un'autorità di certificazione riconosciuta, abbiamo dovuto inserire il certificato da noi creato e firmato tra i certificati trusted, per poter effettuare le prove di funzionamento delle varie applicazioni. Per semplificare il problema, e per non inserire certificati non fidati tra quelli trusted, abbiamo inserito il nostro certificato all'interno del file keystore cacerts di Java, il cui unico problema è quello di contenere una versione ridotta dei certificati trusted, per l'esattezza solo 25 certificati.

Inoltre non avendo un certificato firmato da un'autorità di certificazione, non è stato implementato il controllo delle liste di revoca dei certificati, le CRL, in quanto non sarebbe stato possibile effettuare test di verifica del corretto funzionamento del software.

Per quanto riguarda gli sviluppi futuri di queste Applet, potrebbe essere interessante implementare il servizio di ottenimento della firma di un'aurotità di certificazione sui certificati creati tramite i meccanismi di richiesta alle autorità, e l'implementazione del controllo della presenza del certificato all'interno delle liste di revoca dei certificati di ciascuna autorità di certificazione.

Bibliografia

Sun Microsystem, Security in Java 2 SDK 1.2, da Java Tutorial, https://java.sun.com/docs/books/tutorial/security1.2/index.html

Mauro Molino, Manuale pratico di Java, A.A.V.V, Ed. Hops 2001- https://www.mokabyte.com/mokabook/

Sun Microsystem, Default Policy Implementation and Policy File Sintax,  https://java.sun.com/j2se/1.4.2/docs/guide/security/PolicyFiles.html - last modified 20.04.2002

Sun Microsystem, Java Cryptography Architecture API Specification & Reference, last Modified 04.08.2002 - https://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html

FIPS Home Page, https://www.itl.nist.gov/fipspubs/index.htm

Sun Microsystem, JavaCryptography Extension (JCE)  - Reference Guide https://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.html

MD5, The MD5 Message - Digest Algorithm, https://www.ietf.org/rfc/rfc1321.txt

Legion of the Bouncy Castle https://www.bouncycastle.org

Verisign, https://www.verisign.com

Thawte, https://thawte.com

Garms & Somerfield, Sicurezza in Java - Ed. Mc Graw Hill 2002

Jarsigner, https://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/jarsigner.html

Keytool, https://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html

JAR, https://java.sun.com/docs/books/tutorial/jar/

Implemere un CSP

https://java.sun.com/j2se/1.4.2/docs/guide/security/HowToImplAProvider.html

RSA Laboratories, https://www.rsasecurity.com/rsalabs

RFC 2459, https://www.ietf.org/rfc/rfc2459.txt

William Stallings, Sicurezza delle reti - Applicazioni e Standard, di William Stallings Ed. Addison-Wesley 2001

Maurizio Colleluori, Java Security Extensions - Università degli studi di Bologna a.a. 2003-04

ASN.1, Abstract Syntax Notation number One (ASN.1) - https://asn1.elibel.tm.fr/en/