Indice. Introduzione. Wrapper OpenSSL. Installazione di EJBCA. Conclusioni. Appendice A Procedure di installazione di EJBCA. Appendice B Codice C/Java

Indice Introduzione Wrapper OpenSSL Installazione di EJBCA Conclusioni Appendice A Procedure di installazione di EJBCA Appendice B Codice C/Java Bibliografia

Introduzione Sistemi complessi richiedono accorgimenti altrettanto complessi; uno di questi è quello della sicurezza del sistema stesso. E' quasi impossibile realizzare un sistema intrinsecamente sicuro nella sua totalità in particolar modo se lo vogliamo anche flessibile e facile da utilizzare, specie se abbiamo a che fare con sistemi informatici. Essi sono quanto di più complesso ha creato l'uomo ed è facile quindi intuire quanto siano delicati. Strutture complesse richiedono soluzioni complesse ed il tema di questa tesi è proprio una di queste soluzioni. Durante il periodo del tirocinio da me frequentato all'asl (Azienda Sanitaria Locale) di Ancona sono stati posti due obiettivi: realizzare un wrapper in Java della libreria OpenSSL (scritta in C) mediante l'uso della JNI (Java Native Interface) ed installare e configurare un software che applica una certification authority (EJBCA Enterprise Java Bean Certification Authority). E' ovvio quindi che abbiamo a che fare con un tipo di sicurezza molto specifico: quello contro attacchi di tipo informatico eseguito mediante la rete Internet e che è stata utilizzata la crittografia come strumento di difesa. Questa tesi può essere quindi divisa in due parti piuttosto indipendenti. Riguardo alle scelte effettuate (riguardo ai software) non posso fare a meno di far notare che le soluzioni scelte sono tutte open source (o perlomeno gratuite) inoltre, per lo sviluppo dei progetti è stato utilizzato un pc con installata una particolare versione di linux (Knoppix). Durante quaste attività ho riscontrato problemi al di là della mia portata che non mi hanno consentito di raggiungere entrambi gli obiettivi prefissati è di questo ne discuterò nel corso di questa tesi. Prima di proseguire vorrei fare alcuni ringraziamenti: primo fra tutti l'ingegniere Giuseppe Giampieri, il mio tutore aziendale, per tutti i preziosi consigli ed aiuti forniti nei momenti di necessità, sono molto grato anche al professore Aldo Dragoni per la continua disponibilità e chiarezza nelle sue utili spiegazioni inoltre non voglio escludere i miei amici e la mia famiglia per il loro appoggio morale senza il quale non sarei mai giunto a questo punto. Vorrei inoltre ringraziare coloro che mi hanno aiutato tramite email in particolar modo Thomas Gustavsson uno degli sviluppatori di EJBCA.

Wrapper OpenSSL Come già accennato in precedenza uno degli obiettivi posti nel tirocinio è stato quello di dover realizzare un wrapper (una libreria che funge da involucro ) utilizzando il linguaggio Java della libreria OpenSSL. Prima di motivare questa scelta e le conclusioni alle quali sono arrivato vorrei accennare alcuni concetti base che potrebbero non essere noti a tutti. Concetti base Cos'è una CA e una PKI Il concetto di PKI (Public Key Infrastructure) e CA (Certification Authority) è pressoche impossibile da descrivere in poche parole, per questo motivo verrà fornito solo un accenno. Una certification authority (autorità di certificazione) è un'entità che permette la realizzazione di infrastrutture a chiave pubblica (PKI Public Key Infrastructure) la quale, mediante l'utilizzo della crittografia simmetrica ed asimmetrica e di opportuni protocolli, consente di far transitare dati in una rete in modo tale da garantire l'identificazione di colui con il quale si scambia dati e garantire l'integrità e la confidenzialità dei dati stessi. Le CA hanno varie funzioni da svolgere come quella di distribuire certificati o di verificarne l'autenticità. Nella PKI ci sono anche altre entità che entrano in gioco; l'illustrazione seguente è stata tratta dal RFC (Request For Comment) 2510 [pagina 6]:

Questo schema riassume in maniera molto chiara la PKI. Una CA in realtà è composta da una certification authority ed una registration authority (RA) ma questa distinzione è andata persa con il tempo e con CA si indica normalmente sia la CA che la RA come fossero un tutt'uno. L'infrastruttura si basa sull'utilizzo dei certificati che possono essere definiti come sequenze di bit che seguono un determinato protocollo (o una determinata struttura se si preferisce). La End Entity rappresenta l'utente che chiede servizi offerto dalla CA (registrazione iniziale, aggiornamento certificati, ecc..). La CA ha la necessità di essere a sua volta certificata da un'altra CA (nel diagramma viene chiamata CA-2). Una trattazione esauriente della PKI e del ruolo delle CA non è tema di questa tesi e questi concetti base verranno dati per acquisiti. Per una trattazione completa consultare l'rfc 2510.

La libreria OpenSSL La OpenSSL (Open Secure Socket Layer) è una libreria scritta in C che svolge molteplici funzioni: la principale è sicuramente quella di applicare il protocollo SSL e le routine di base della crittografia simmetrica e asimmetrica (MD5, RSA, Blowfish, DES, ecc..), inoltre permette di realizzare e manipolare certificati X.509. Il principale aspetto positivo è sicuramente quello di essere considerato lo standard de facto, infatti con questa libreria viene utilizzata come riferimento per molti software che devono svolgere compiti per il quale è nata questa libreria. E' inoltre una libreria molto completa ed il fatto che sia stata scritta in C la rende anche molto efficiente in termini di prestazioni. Tuttavia non è una libreria facile da utilizzare e questa complicazione è amplificata dal fatto che non possiede una buona documentazione (a dire la verità non ha una sua documentazione se escludiamo quella della sua versione precedente chiamata SSLeay). JNI (L'interfaccia nativa di Java) L'interfaccia nativa di Java è una componente del JDK (Java Development Kit) che consente di chiamate funzioni compilate in codice nativo come quello generato da linguaggi come il C/C++ e Pascal. Per realizzare quest'interfaccia è necessario eseguire alcuni procedimenti che verranno illustrati mediante un esempio. Sarà data per scontata una sufficiente conoscenza dalla JNI. Prima di tutto scriviamo la nostra interfaccia Java: testing.java package test; public class testing public testing()

// Dichiara la funzione nativa stampa() private native void stampa(); static // Carica la libreria Runtime.getRuntime().load("/usr/lib/libtesting.so"); public static void main(string[] args) // Utilizza la funzione nativa stampa() new testing().stampa(); Scritto questo codice dobbiamo eseguire da console: javac testing.java javah -jni testing Quest'ultimo passaggio genererà una firma (signature) che consiste in un file con estensione.h che in questo caso si chiamerà testing.h. Ora dobbiamo realizzare la nostra libreria in C (o qualsiasi altro linguaggio compilato): testing.c #include "testing.h" #include <stdio.h> JNIEXPORT void JNICALL Java_testing_stampa (JNIEnv *env, jobject obj) printf("ciao"); dove la firma:

JNIEXPORT void JNICALL Java_testing_stampa (JNIEnv *env, jobject obj) è stata copiata dal file.h. Compiliamo il file testing.c affinche otteniamo una libreria. A questo punto non ci rimane altro da fare che eseguire il programma in Java da console: java testing per veder apparire la scritta ciao. Questo procedimento va bene nel caso in cui non abbiamo ancora scritto la libreria in codice nativo quindi nel nostro caso dobbiamo aggiungere alcuni passaggi dato che dobbiamo scrivere un wrapper di una libreria già esistente e che quindi le funzioni ad essa appartenenti non hanno la signature appropriata. La soluzione a questo problema verrà descritta in seguito [vedi paragrafo Struttura del wrapper]. La JNI è sicuramente un utile strumento ma presenta alcuni aspetti negativi intrinseci e progettuali: i primi sono dati dal fatto che per realizzare un'interfaccia sono necessari molti passaggi, i problemi progettuali sono dati dal fatto che è possibile realizzare interfacce delle sole librerie alle quali è stata eseguita una fase di link statico, non è quindi possibile realizzare interfacce di librerie che utilizzano funzioni di altre librerie a meno che non sia stato utilizzato un link statico. A mio avviso quest'ultimo problema si sarebbe potuto evitare progettando il sistema JNI in maniera diversa. Scelte progettuali e obiettivi Prima di proseguire con la spiegazione è necessario fare qualche passo indietro. All'inizio del tirocinio era stato stabilito un obiettivo che poi a causa delle circostanze verificatesi è mutato. Si era deciso infatti di realizzare una certification authority pertendo da quello che avevano svolto altri studenti tirocinanti in precedenza.

Perchè era stato deciso di realizzare una nuova CA anzichè utilizzarne una già esistente open source? Il motivo è semplice: tra le varie CA non ce n'è nessuna che soddisfi in pieno le necessità dell'asl cioè fornire un'infrastruttura PKI che svolga i servizi necessari all'azienda. Sono stati presi in considerazione diversi software di CA prima di eseguire questa scelta: primo fra tutti l'ejbca ma oltre che ad essere difficile da installare, non utilizza la libreria OpenSSL che come abbiamo detto in precedenza è considerato come uno standard ed è segno di massima affidabilità; il secondo software preso in considerazione è l'openca ma il problema più grave è che il programma è scritto in Perl e quindi particolarmente difficile da modificare secondo le proprie necessità. E' stato quindi necessario partire dalle basi: una libreria multifunzionale come l'openssl. E' stato scelto il linguaggio Java per le sue proprietà intrinseche (prima fra tutti la sicurezza del codice) e per la disponibilità di strumenti specifici come librerie e applicativi Svolgimento Struttura del wrapper Il procedimento descritto in precedenza non è di per se sufficiente a raggiungere l'obiettivo da noi imposto è necessario frapporre un ulteriore strato (interfaccia) tra l'interfaccia in Java e la libreria OpenSSL: creiamo una libreria in C che invoca funzioni della libreria OpenSSL e che a sua volta viene invocata dall'inerfaccia Java. Tra le varie funzioni è stato deciso di iniziare con delle funzioni di generica utilità e di controllo degli errori. Prima di tutto riportiamo il primo file scritto contenete l'interfaccia JNI che permette di richiamare le funzioni di gestione di errore della OpenSSL con opportuni commenti (alcune parti sono state omesse per semplicità): Errors.java package it.asl7.wopenssl;

public class Errors //----- Costruttore public Errors() LoadCryptoStrings(); LoadERRStrings(); //----- Metodi // Cancella tutti gli errori dalla lista statica public void ClearAll() // Chiamata a una funzione della libreria che verrà // frapposta tra questa e la OpenSSL. Questa funzione // cancella tutti gli errori dalla lista statica. ERR_clear_error(); //... public void FreeStrings() // Libera tutte le stringhe d'errore caricate nella // tabella statica degli errori che mappa codici di // librerie e funzioni in stringhe di testo ERR_free_strings(); //... public long GetError() // Ottiene il codice dell'errore e rimuove questa // voce dalla coda degli errori return ERR_get_error(); //...

public String LibErrorString(long e) // Restituisce il nome della libreria corrispondente // al codice di errore numerico return ERR_lib_error_string(e); public void LoadCryptoStrings() // Carica in memoria l'insieme crypto delle stringhe d'errore ERR_load_crypto_strings(); //... // Caricamento stringhe di errore public void LoadStrings(ErrStringData[] str) int[] error = new int[str.length]; String[] message = new String[str.length]; for (int i = 0; i < str.length; i++) error[i] = str[i].geterror(); message[i] = str[i].getstring(); ERR_load_strings(error, message); //... // Dichiarazioni di funzioni native. Come è facile notare è // sufficiente l'utilizzo della parola chiave native oltre // che al prototipo della funzione private native long ERR_get_error(); private native int ERR_get_next_error_library(); private native long ERR_peek_error(); private native String ERR_error_string(long num);

private native void ERR_error_string_n(long num); private native void ERR_clear_error(); private native void ERR_put_error(int lib, int func, int reason, String file, int line); private native void ERR_set_error_data(String data, int flags); private native String ERR_lib_error_string(long e); private native String ERR_func_error_string(long e); private native String ERR_reason_error_string(long e); //... static // Ci sono vari metodi per caricare una libreria. Tra quelli // disponibili, quello utilizzato ci permette di avere più // informazioni in caso di errore. In alternativa è possibile // utilizzare System.loadLibrary("errors"); come mostrato // tra gli esempi presenti nella documentazione. Runtime.getRuntime().load("/usr/lib/liberrors.so"); // Un piccolo test.. public static void main(string []args) Errors err = new Errors(); err.clearall(); for (int i = 0; i < 50; i++) System.out.println(err.ErrorString(i)); Il file completo (come tutti quelli che seguiranno) sono disponibili nell'appendice A e nel CD- ROM allegato. Eseguendo i comandi javac e javah otteniamo il file class e la signature seguente:

Errors.h /* DO NOT EDIT THIS FILE - it is machine generated */ #ifndef it_asl7_wopenssl_errors #define it_asl7_wopenssl_errors #include <jni.h> #ifdef cplusplus extern "C" #endif extern jlong Java_it_asl7_wOpenSSL_Errors_ERR_1get_1error (JNIEnv *env, jobject); extern jlong Java_it_asl7_wOpenSSL_Errors_ERR_1get_1error_1line (JNIEnv *env, jobject); //... #ifdef cplusplus #endif #endif /* it_asl7_wopenssl_errors */ E' facile notare che la signature segue delle regole ben precise infatti il prototipo di ogni funzione ha la seguente struttura: Java_ + percorso della classe + nome funzione. Se nell'interfaccia Java, un nome di funzione contiene un carattere di underscore, nella signature verrà sostituito con _1. Ora dobbiamo dare corpo a queste funzioni scrivendo il file Errors.c : Errors.c // Includiamo la parte della libreria OpenSSL inerente la gestione degli errori #include <openssl/err.h> // Includiamo la signature

#include "Errors.h" // Includiamo funzioni che verranno descritte in seguito #include "Utils.h" char error[256]; JNIEXPORT jlong JNICALL Java_it_asl7_wOpenSSL_Errors_ERR_1get_1error (JNIEnv *env, jobject obj) return ERR_get_error(); //... JNIEXPORT jstring JNICALL Java_it_asl7_wOpenSSL_Errors_ERR_1reason_1error_1string (JNIEnv *env, jobject obj, jlong e) return CharpToJstr( env, ERR_reason_error_string(e) ); //... JNIEXPORT jstring JNICALL Java_it_asl7_wOpenSSL_Errors_val_1error (JNIEnv *env, jobject obj) return CharpToJstr( env, error ); Scrivere questa parte di codice è piuttosto semplice infatti è sufficiente copiare i vari prototipi dalla signature e nella maggior parte dei casi il corpo della funzione è composto dalla sola chiamata alla funzione delle OpenSSL. E' fondamentale ora notare l'utilizzo della funzione CharpToJstr. Il prototipo di questa funzione è presente nel file Utils.h e definita nel file Utils.c. Il file Utils.h dichiara anche altre funzioni: Utils.h

#ifndef Utils #define Utils #include <jni.h> JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *jvm, void *reserved); JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *jvm, void *reserved); void JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg); char * JstrToCharp(JNIEnv *env, jstring str); jstring CharpToJstr(JNIEnv *env, const char *str); #endif Queste funzioni sono di varia utilità: ad esempio JNI_OnLoad è una funzione che viene invocata all'avvio dalla Java Virtual Machine da parte di una funzione JNI. La funzione CharToJstr richiede una particolare spiegazione. Nonostante le similitudini, tra il Java ed il C ci sono delle incompatibilità tra i tipi di dato esistenti, primo fra tutti la rappresentazione delle stringhe infatti nel C abbiamo a disposizione i puntatori a carattere mentre il Java ha un tipo di dato astratto che si occupa di questo. Le funzioni CharToJstr e JstrToCharp si occupano di eseguire questa conversione in entrambe le direzioni. La definizione (il corpo) di queste cinque funzioni sono state tratte da un documento presente nel sito della Sun: The Java Native Interface, il codice è il seguente: Utils.c #include "Utils.h" jclass Class_java_lang_String = NULL; jmethodid MID_String_getBytes = NULL; jmethodid MID_String_init = NULL; JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *jvm, void *reserved) JNIEnv *env; if ((*jvm)->getenv(jvm, (void **)&env, JNI_VERSION_1_4))

return JNI_ERR; // Crea un riferimento globale if (Class_java_lang_String == NULL) jclass localrefcls = (*env)->findclass(env, "java/lang/string"); if (localrefcls == NULL) return JNI_ERR; // Lancio eccezione Class_java_lang_String = (*env)->newglobalref(env, localrefcls); (*env)->deletelocalref(env, localrefcls); if (Class_java_lang_String == NULL) return JNI_ERR; // Lancio eccezione OutOfMemory // Inizializazione Method ID MID_String_getBytes = (*env)->getmethodid(env, Class_java_lang_String, "getbytes", "()[B"); MID_String_init = (*env)->getmethodid(env, Class_java_lang_String, "<init>", "([C)V"); if ( (MID_String_getBytes == NULL) (MID_String_init == NULL) ) return JNI_ERR; return JNI_VERSION_1_4; JNIEXPORT void JNICALL JNI_OnUnload(JavaVM *jvm, void *reserved) JNIEnv *env;

if ((*jvm)->getenv(jvm, (void **)&env, JNI_VERSION_1_4)) return; void JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) jclass cls = (*env)->findclass(env, name); if (cls!= NULL) (*env)->thrownew(env, cls, msg); (*env)->deletelocalref(env, cls); char * JstrToCharp(JNIEnv *env, jstring str) jbytearray bytes = 0; jthrowable exc; char *result = 0; if ( (*env)->ensurelocalcapacity(env, 2) < 0 ) return 0; bytes = (*env)->callobjectmethod(env, str, MID_String_getBytes); return NULL; exc = (*env)->exceptionoccurred(env); if (!exc) jint len = (*env)->getarraylength(env, bytes); result = (char *)malloc(len + 1); if (result == 0) JNU_ThrowByName(env, "java/lang/outofmemoryerror", 0);

(*env)->deletelocalref(env, bytes); return 0; (*env)->getbytearrayregion(env, bytes, 0, len, (jbyte *)result); result[len] = 0; else (*env)->deletelocalref(env, exc); (*env)->deletelocalref(env, bytes); return result; jstring CharpToJstr(JNIEnv *env, const char *str) jstring result; jbytearray bytes = 0; int len; if ( (*env)->ensurelocalcapacity(env, 2) < 0 ) return NULL; len = strlen(str); bytes = (*env)->newbytearray(env, len); if (bytes!= NULL) (*env)->setbytearrayregion(env, bytes, 0, len, (jbyte *)str); result = (*env)->newobject(env, Class_java_lang_String, MID_String_init, bytes); return result; return NULL;

Durante la fase di compilazione non si verifica alcun problema ma eseguendo il comando java Errors otteniamo il seguente messaggio da parte della Java Virtul Machine: Unexpected Signal : 11 occurred at PC=0x401B53A7 Function=(null)+0x401B53A7 Library=/usr/j2sdk1.4.2_04/jre/lib/i386/client/libjvm.so NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: Dynamic libraries: 08048000-08049000 r-xp 00000000 03:01 117962 /usr/source/openssl_c/a.out 08049000-0804a000 rw-p 00000000 03:01 117962 /usr/source/openssl_c/a.out 40000000-40012000 r-xp 00000000 03:01 425365 /lib/ld-2.3.2.so 40012000-40013000 rw-p 00012000 03:01 425365 /lib/ld-2.3.2.so 40014000-40024000 r-xp 00000000 03:01 637723 / usr/j2sdk1.4.2_04/jre/lib/i386/libverify.so 40024000-40026000 rw-p 0000f000 03:01 637723 / usr/j2sdk1.4.2_04/jre/lib/i386/libverify.so 40026000-40422000 r-xp 00000000 03:01 637718 / usr/j2sdk1.4.2_04/jre/lib/i386/client/libjvm.so 40422000-4043d000 rw-p 003fb000 03:01 637718 / usr/j2sdk1.4.2_04/jre/lib/i386/client/libjvm.so 4044f000-4046f000 r-xp 00000000 03:01 637725 / usr/j2sdk1.4.2_04/jre/lib/i386/libjava.so 4046f000-40471000 rw-p 0001f000 03:01 637725 / usr/j2sdk1.4.2_04/jre/lib/i386/libjava.so 40472000-4047a000 r-xp 00000000 03:01 637712 / usr/j2sdk1.4.2_04/jre/lib/i386/native_threads/libhpi.so 4047a000-4047b000 rw-p 00007000 03:01 637712 / usr/j2sdk1.4.2_04/jre/lib/i386/native_threads/libhpi.so 4047b000-4047f000 rw-s 00000000 03:01 69255 /tmp/hsperfdata_root/1007 4047f000-40481000 r-xp 00000000 03:01 179698 /usr/lib/liberrors.so

40481000-40482000 rw-p 00001000 03:01 179698 /usr/lib/liberrors.so 40483000-40595000 r-xp 00000000 03:01 425368 /lib/libc-2.3.2.so 40595000-4059a000 rw-p 00111000 03:01 425368 /lib/libc-2.3.2.so 4059d000-40679000 r-xp 00000000 03:01 554049 / usr/lib/i686/cmov/libcrypto.so.0.9.7 40679000-4068a000 rw-p 000db000 03:01 554049 / usr/lib/i686/cmov/libcrypto.so.0.9.7 4068e000-4069e000 r-xp 00000000 03:01 425372 /lib/libnsl-2.3.2.so 4069e000-4069f000 rw-p 00010000 03:01 425372 /lib/libnsl-2.3.2.so 406a1000-406c2000 r-xp 00000000 03:01 425371 /lib/libm-2.3.2.so 406c2000-406c3000 rw-p 00020000 03:01 425371 /lib/libm-2.3.2.so 406c3000-406c5000 r-xp 00000000 03:01 425370 /lib/libdl-2.3.2.so 406c5000-406c6000 rw-p 00001000 03:01 425370 /lib/libdl-2.3.2.so 406c6000-406d2000 r-xp 00000000 03:01 425383 /lib/libpthread-0.10.so 406d2000-406d3000 rw-p 0000c000 03:01 425383 /lib/libpthread-0.10.so 40716000-40742000 r-xp 00000000 03:01 554050 / usr/lib/i686/cmov/libssl.so.0.9.7 40742000-40745000 rw-p 0002b000 03:01 554050 / usr/lib/i686/cmov/libssl.so.0.9.7 40753000-40759000 r-xp 00000000 03:01 425373 /lib/libnss_compat-2.3.2.so 40759000-4075a000 rw-p 00005000 03:01 425373 /lib/libnss_compat-2.3.2.so 4075a000-40761000 r-xp 00000000 03:01 425377 /lib/libnss_nis-2.3.2.so 40761000-40762000 rw-p 00007000 03:01 425377 /lib/libnss_nis-2.3.2.so 40762000-4076a000 r-xp 00000000 03:01 425375 /lib/libnss_files-2.3.2.so 4076a000-4076b000 rw-p 00007000 03:01 425375 /lib/libnss_files-2.3.2.so 4076b000-4077f000 r-xp 00000000 03:01 637727 / usr/j2sdk1.4.2_04/jre/lib/i386/libzip.so 4077f000-40782000 rw-p 00013000 03:01 637727 / usr/j2sdk1.4.2_04/jre/lib/i386/libzip.so 40782000-42126000 r--s 00000000 03:01 639155 / usr/j2sdk1.4.2_04/jre/lib/rt.jar 42170000-42186000 r--s 00000000 03:01 637759 / usr/j2sdk1.4.2_04/jre/lib/sunrsasign.jar 42186000-42263000 r--s 00000000 03:01 639063 / usr/j2sdk1.4.2_04/jre/lib/jsse.jar 42263000-42274000 r--s 00000000 03:01 637761 / usr/j2sdk1.4.2_04/jre/lib/jce.jar

42274000-427cd000 r--s 00000000 03:01 639101 / usr/j2sdk1.4.2_04/jre/lib/charsets.jar Heap at VM Abort: Heap def new generation total 576K, used 97K [0x44880000, 0x44920000, 0x44d60000) eden space 512K, 19% used [0x44880000, 0x44898758, 0x44900000) from space 64K, 0% used [0x44900000, 0x44900000, 0x44910000) to space 64K, 0% used [0x44910000, 0x44910000, 0x44920000) tenured generation total 1408K, used 0K [0x44d60000, 0x44ec0000, 0x48880000) the space 1408K, 0% used [0x44d60000, 0x44d60000, 0x44d60200, 0x44ec0000) compacting perm gen total 4096K, used 827K [0x48880000, 0x48c80000, 0x4c880000) the space 4096K, 20% used [0x48880000, 0x4894ecd8, 0x4894ee00, 0x48c80000) Local Time = Wed Aug 25 08:58:59 2004 Elapsed Time = 0 # # HotSpot Virtual Machine Error : 11 # Error ID : 4F530E43505002EF # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode) # E' un messaggio che rivela un bug della JVM. Per risolvere questo problema sono state cercate informazioni su questo tipo di problema ed eventuali soluzioni ma non è stato trovato nulla che possa soddisfare le nostre necessità. Vorrei evidenziare il fatto che nel codice di queste funzioni di utilità non ci sono errori di sintassi ne di semantica. Il problema di conversione da char * a jstring (e viceversa) non è raggirabile. Dopo vari tentativi (eseguendo semplici esempi) è stato deciso di abbandonare la realizzazione del wrapper. Avremmo potuto tentare di rieseguire il codice in altri sistemi operativi come ad esempio MS Windows o altre versioni della JVM ma questa scelta sarebbe andata contro uno degli obiettivi preposti: realizzare una CA utilizzabile nella maggior parte dei sistemi. Non a caso è stato scelto il

Java come linguaggio di programmazione.

Installazione di EJBCA Il secondo obiettivo preposto è stato quello di installare il software EJBCA e descrivere in maniera abbastanza dettagliata la procedura di installazione. EJBCA (Enterprise Java Bean Certification Authority) è un software per la certification authority scritto in Java. Per l'esecuzione è necessiario che sia avviato un application server (per ulteriori dettagli sugli application server consultare la documentazione del JDK). La procedura di installazione qui descritta è valida per sistemi operativi linux ma con determinati accorgimenti è facilmente adattabile per altri ambienti. Per una sua versione più schematica consultare l'appendice B. Descrizione dei software da installare JDK Il primo software da installare è il JDK. Si consiglia di installare l'ultima versione stabile disponibile nel sito ufficiale http://java.sun.com. La versione da me utilizzata è la 1.4.2_05. Copiare il contenuto dell'archivio scaricato in una directory a scelta. Per i passaggi successivi (e per convenienza) andiamo a modificare uno dei file di avvio dove possiamo andare a definire variabili di ambiente come il file profile inserendo le variabili JDK_HOME, JAVA_HOME e CLASSPATH a seconda della directory in cui è stato installato il JDK. Ad esempio nel mio caso ho inserito le seguenti righe: export PATH=/usr/lib/java:... export JDK_HOME="/usr/lib/java/bin" export JAVA_HOME=/usr/j2sdk1.4.2_05 export CLASSPATH=/usr/j2sdk1.4.2_05/jre/lib/ext/... :$CLASSPATH

Verificare quindi che sia installato il package JCE (Java Cryptography Extension). Questo package è già presente nella versione 1.4 e probabilmente lo sarà anche nelle successive. E' inoltre necessario installare l'unlimited Strength Java Cryptography Extension per poter utilizzare crittografia forte e illimitata. Il pacchetto è disponibile nel sito della sun nella stessa pagina dove è possibile scaricare il JDK e consiste in due file *.jar (local_policy.jar e US_export_policy.jar) che devono essere copiati nelle directory $JAVA_HOME/jre/lib e $JAVA_HOME/lib/security (questa directory è da creare). Questo pacchetto è necessario fondamentalmente per scopi legali infatti nel file README.txt che si trova insieme ai file jar è possibile leggere: JCE for J2SDK, v 1.4.2 has been through the U.S. export review process. The JCE framework, along with the SunJCE provider that comes standard with it, is exportable. The JCE architecture allows flexible cryptographic strength to be configured via jurisdiction policy files. Due to the import restrictions of some countries, the jurisdiction policy files distributed with the J2SDK, v 1.4.2 software have built-in restrictions on available cryptographic strength. The jurisdiction policy files in this download bundle (the bundle including this README file) contain no restrictions on cryptographic strengths. This is appropriate for most countries. Framework vendors can create download bundles that include jurisdiction policy files that specify cryptographic restrictions appropriate for countries whose governments mandate restrictions. Users in those countries can download an appropriate bundle, and the JCE framework will enforce the specified restrictions. MySQL EJBCA richiede l'utilizzo di un database per immagazzinare ogni tipo di informazione necessaria e ci da la possibilità di scegliere tra varie opzioni e tra le quali abbiamo scelto il MySQL disponibile all'indirizzo www.mysql.com. E' stato scelto questo DBMS perchè possiede molte qualità che vengono incontro alle nostre necessità infatti il MySQL è multipiattaforma, open source, efficiente, dispone di una buona documentazione e in caso di problemi non si hanno grosse difficoltà nel

trovare una soluzione. La versione che è stata installata è la 4.0.21. C'è da fare attenzione con la scelta della versione da scegliere perchè si possono riscontrare anomalie: installando la versione 4.0.14 ci sono stati dei problemi alla tabella UserData del database ejbca, tale tabella veniva danneggiata durante l'installazione di EJBCA. Una volta scaricato il pacchetto dal sito ufficiale, creare il gruppo e l'utente mysql : shell> groupadd mysql shell> useradd -g mysql mysql Possiamo quindi proseguire iniziando l'installazione: shell> cd /usr/local shell> gunzip < /PATH/TO/MYSQL-VERSION-OS.tar.gz tar xvf - shell> ln -s FULL-PATH-TO-MYSQL-VERSION-OS mysql shell> cd mysql Copiamo il file /directory-di-installazione-mysql/support-file/my-medium.cnf nella directory /etc e rinominarlo in my.cnf e verificare che all'interno di tale file la voce skip-networkin sia posta sotto commento (anteponendo il carattere # ) o cancellata; questa operazione è necessaria perchè il linguaggio Java accede al MySQL come se si trovasse in un altro pc utilizzando un indirizzo IP. Dalla directory /usr/local/mysql eseguire: scripts/mysql_install_db --user=mysql Acquisiamo i privilegi necessari: shell> chown -R root. shell> chown -R mysql data

shell> chgrp -R mysql. L'installazione è completata. Per poter utilizzare MySQL è necessario che il demone mysqld sia attivo, quindi sarebbe è necessario avviarlo all'avvio del sistema operativo o perlomeno prima di utilizzare il DBMS: shell> /usr/local/mysql/bin/mysqld_safe --user=mysql & Per terminare il demone in qualsiasi momento: shell> killall mysqld Il MySQL mette a disposizione una particolare console che ci consente di creare e manipolare database digitiamo quindi: shell> /usr/local/mysql/bin/mysql Inviamo i comandi: > use mysql > create database ejbca; > grant all privileges on *.* to 'ejbca'@'%' identified by 'ejbca' with grant option; > grant all privileges on *.* to 'ejbca'@'linux' identified by 'ejbca' with grant option; > quit Il primo comando ci permette di accedere al database mysql, successivamente creiamo il database ejbca, con le due operazioni successive forniamo privilegi illimitati a tutti coloro che accedono dall'esterno ( % ) e dall'interno ( linux alias di 127.0.0.1) per tutte le tabelle di tutti i database. Sarebbe bene modificare le tabelle (e i relativi utenti) alle quali si vogliono fornire i privilegi (per