UNIVERSITÀ DEGLI STUDI DI PADOVA

FACOLTÀ DI INGEGNERIA

Corso di Laurea in Ingegneria Informatica

TESI DI LAUREA

Titolo

ANALISI E SPERIMENTAZIONE DI UNA CERTIFICATION AUTHORITY IN UN SISTEMA

DI AUTENTICAZIONE BIOMETRICO Relatore: prof. Michele Moro Candidato: Costa Alberto

ANNO ACCADEMICO 2006-2007

Sommario Scopo di questa tesi di laurea è la realizzazione di una Certification Authority per la gestione dei certificati a chiave pubblica, nell’ambito di un sistema di autenticazione biometrico. Tale sistema, il cui scopo è quello di garantire l’identificazione sicura di un utente grazie ad un parametro biometrico come l’impronta digitale, è costituito non solo da una Certification Authority, ma anche da una Attribute Authority. Quest’ultima si preoccupa proprio della gestione dei certificati di attributo, che contengono l’informazione sull’impronta digitale. Un tale progetto era già stato realizzato precedentemente; il lavoro effettuato in questa tesi pone però l’attenzione solo sulla Certification Authority, con il duplice scopo di aggiornare il software presente con le nuove versioni disponibili e di realizzare una guida passo passo che accompagni l’utente durante l’installazione e la configurazione di tale software. Tutto questo naturalmente senza trascurare gli aspetti teorici che permettono di capire il perché di alcune scelte effettuate in fase realizzativa. Per le funzioni di Certification Authority la scelta è ricaduta sul software open-source Ejbca, che si appoggia all’application server JBoss per funzionare. Inoltre per la gestione e memorizzazione dei certificati è stato utilizzato OpenLDAP. Particolare attenzione è stata inoltre riservata per garantire la sicurezza durante le comunicazioni tra i vari programmi utilizzati, grazie a software come OpenSSL e Cyrus SASL. I campi dove è possibile utilizzare una Certification Authority sono innumerevoli, e non per forza legati a sistemi di autenticazione tramite parametri biometrici; un esempio attuale è rappresentato dal commercio elettronico, dove alla necessità di sicurezza nelle comunicazioni si aggiunge il bisogno di una identificazione sicura delle parti coinvolte, per evitare fenomeni come il phishing.

1

Indice

1 Introduzione ....................................................................................................... 4 2 Crittografia ......................................................................................................... 6 2.1 Informazioni generali................................................................................... 6 2.2 Crittografia e Steganografia nel passato ...................................................... 6 2.2.1 Il cifrario di Cesare ........................................................................... 7 2.3 La crittografia fino al XVIII secolo ............................................................. 9 2.4 La crittografia moderna.............................................................................. 11 2.4.1 Enigma ............................................................................................ 12 2.5 Cifrario di Vernam e sicurezza perfetta ..................................................... 15 2.6 Crittografia simmetrica e asimmetrica....................................................... 16 2.6.1 Crittografia simmetrica ................................................................... 16 2.6.1.1 Des .................................................................................... 17 2.6.1.2 Triple-Des ......................................................................... 19 2.6.1.3 AES ................................................................................... 20 2.6.1.4 IDEA ................................................................................. 21 2.6.1.5 Lo scambio di chiavi di Diffie-Hellman ............................ 22 2.6.2 Crittografia asimmetrica ................................................................. 23 2.6.2.1 RSA................................................................................... 24 2.7 Funzioni di Hash ........................................................................................ 25 2.8 Firma Digitale ............................................................................................ 26 3 Certification Authority e PKI ......................................................................... 28 3.1 Certificato digitale...................................................................................... 28 3.1.1 Il formato X.509.............................................................................. 29 3.2 Public Key Infrastructure ........................................................................... 30 3.2.1 Certificazione .................................................................................. 31 3.2.1.1 Certification Authority...................................................... 31 3.2.1.2 Procedura di certificazione................................................ 33 3.2.2 Validazione ..................................................................................... 35 3.3 X.500 e LDAP............................................................................................ 36 4 Realizzazione .................................................................................................... 38 4.1 Hardware.................................................................................................... 38 4.2 Il software utilizzato................................................................................... 38 4.2.1 Java.................................................................................................. 38 4.2.2 Ant................................................................................................... 40 4.2.3 JBoss ............................................................................................... 41 4.2.4 Ejbca................................................................................................ 41 4.2.5 OpenSSL ......................................................................................... 43 4.2.6 Berkeley DB.................................................................................... 45 4.2.7 Cyrus SASL .................................................................................... 46 4.2.8 OpenLDAP ..................................................................................... 47 4.2.8.1 I file di OpenLDAP........................................................... 47 4.2.8.2 Slapd e Slurpd ................................................................... 47 4.2.8.3 Strumenti e librerie di OpenLDAP ................................... 48

2

4.2.9 Ldap Browser/Editor....................................................................... 49 4.3 Guida all’installazione ............................................................................... 50 4.3.1 Login ............................................................................................... 50 4.3.2 Installazione di Java ........................................................................ 52 4.3.3 Installazione di Ant ......................................................................... 58 4.3.4 Installazione di JBoss...................................................................... 61 4.3.5 Installazione di Ejbca ...................................................................... 73 4.3.6 Installazione di OpenSSL ............................................................... 82 4.3.6.1 Creazione di una CA con OpenSSL.................................. 84 4.3.7 Installazione di BerkeleyDB ........................................................... 91 4.3.8 Installazione di Cyrus SASL........................................................... 94 4.3.9 Installazione di OpenLDAP............................................................ 96 4.3.9.1 Configurazione di OpenLDAP.......................................... 99 4.3.10 Installazione di Ldap Browser/Editor ......................................... 106 4.3.11 Errore di accesso alla sezione Administration di Ejbca.............. 108 4.4 Conclusioni .............................................................................................. 111 Bibliografia .......................................................................................................... 112

3

Capitolo 1 Introduzione Il grande sviluppo di Internet negli ultimi anni è stato molto rapido, e oramai molte delle attività che implicavano una interazione fisica tra le persone, come il commercio, la vendita e l’acquisto di beni, vengono effettuate anche in rete. È quindi indispensabile garantire una certa sicurezza sull’identità dei soggetti che nella rete Internet forniscono servizi, soprattutto se a pagamento. Se non fosse presente nessun metodo di controllo, non ci sarebbe per esempio la garanzia che il bene che stiamo acquistando, e che pagheremo magari con una carta di credito, non sia in realtà una truffa, messa in piedi da qualche soggetto non meglio identificato che una volta ricevuti i nostri soldi non si farà più sentire. Gli strumenti introdotti in questo lavoro possono evitare il verificarsi di situazioni spiacevoli come quella descritta ora. La parola chiave che ricorrerà molto spesso nelle pagine di questa tesi è autenticazione, cioè il fatto di essere davvero sicuri che un soggetto sia davvero chi dice di essere. La scoperta che segna la svolta, e che apre la strada a meccanismi di autenticazione efficienti, è la crittografia asimmetrica, il cui aspetto fondamentale è la presenza di una coppia di chiavi, una privata da custodire e una pubblica da rendere disponibile. Così si usa la chiave pubblica di un soggetto per cifrare un messaggio diretto al soggetto stesso, e solo lui potrà decifrarlo essendo l’unico possessore della chiave privata. Tutto questo ha rappresentato una rivoluzione rispetto ai metodi di crittografia precedenti, dove era presente una sola chiave segreta. Con la crittografia asimmetrica si riescono infatti a fornire strumenti come la firma digitale, che rendono l’identificazione di un soggetto nella rete molto più semplice, anche se non assolutamente certa. Il vero strumento che porterà a garantire la certezza assoluta nell’identificazione di un soggetto è il certificato digitale, emesso dalla Certification Authority, che permette di associare una certa chiave pubblica a un soggetto, e riesce quindi a fornire alla firma digitale quello che mancava per avere la certezza del riconoscimento: si riesce a garantire il cosiddetto “non ripudio”. Questo significa ad esempio che se un soggetto A manda un messaggio a un soggetto B e lo firma digitalmente, e B verifica attraverso il certificato digitale che è stato proprio A a mandare il messaggio, A non può negare di averlo mandato. Tale fatto è così importante che alla firma digitale e ai certificati digitali è stato dato valore legale; l’elenco pubblico delle Certification Authority, così come il formato dei certificati, è regolato infatti in Italia dall’articolo 29 comma 1 del decreto legislativo 7 marzo 2005 nn 82 e specificato nel DPCM 13 gennaio 2004. Per informazioni e materiale vedere il sito del CNIPA (Centro Nazionale per l’Informatica nella Pubblica Amministrazione) http://www.cnipa.gov.it/site/it-IT/Attivit%c3%a0/Certificatori_accreditati/Elenco_certificatori_di_firma_digitale/. Una Certification Authority non deve però solo emettere certificati, ma anche emettere delle liste dove sono contenuti i certificati non più validi, oltre a prendersi carico di verificare l’identità di un soggetto che richieda un certificato.

4

La scelta effettuata per la Certification Authority è stata EJBCA, un software open source scritto in Java che fornisce tutte le funzioni di cui abbiamo parlato, e che supporta moltissimi algoritmi crittografici e protocolli per la gestione dei certificati, come X.509. Tutta questa struttura messa in atto per rendere disponibili le chiavi pubbliche e garantire la loro autenticità con i certificati prende il nome di Public Key Infrastructure. Infatti chiavi e certificati digitali devono essere diffusi e resi disponibili, altrimenti non avrebbero molta utilità. Ad aggiungere maggior sicurezza, sono stati usati software come OpenSSL e Cyrus SASL, che garantiscono la sicurezza nelle comunicazioni client – server (come potrebbe essere nel caso di un utente che da casa richiede un certificato collegandosi alla pagina web di EJBCA) e che forniscono metodi di autenticazione avanzati. Per quanto riguarda la struttura della tesi, nel capitolo 2 verrà fatta una panoramica sulla crittografia, partendo dalle tecniche utilizzate in passato fino a quelle più attuali, e introducendo tra le altre cose i concetti già accennati di firma digitale e crittografia asimmetrica. Nel capitolo 3 si analizzeranno invece gli scopi e il funzionamento di Certification Authority e PKI (Public Key Infrastructure), descrivendo inoltre la struttura dei certificati digitali secondo lo standard X.509 v3 e presentando anche il protocollo LDAP per la gestione di directory contenenti informazioni, nel nostro caso relative ai certificati. Infine nel capitolo 4 si descriveranno i software utilizzati in questa tesi, terminando con la guida all’installazione, in modo che se in futuro dovesse rendersi necessario il ripristino del sistema utilizzato, questo sia semplice e intuitivo anche per chi non ha molta familiarità con l’ambiente Linux. Tale guida, oltre a riportare i comandi da utilizzare, è ricca di immagini che riprendono le varie fasi di installazione dei programmi, in modo che ci si renda conto subito se tutto sta procedendo per il verso giusto o se sono presenti errori. Si ricorda che nel dvd allegato alla tesi sono presenti, oltre a questo file, tutti i programmi utilizzati nella guida con relativi file di istruzioni, comprese le immagini in formato ISO del sistema operativo Linux utilizzato, in modo da evitare a chi dovrà eventualmente ripristinare il tutto di dover cercare in Internet il materiale necessario, cosa sicuramente abbastanza onerosa in termini di tempo.

5

Capitolo 2 Crittografia Data la grande importanza della crittografia nell’ambito di questo lavoro, in questo capitolo verrà trattato l’argomento, descrivendo i vari tipi di tecniche crittografiche, evidenziandone i pregi e i difetti, in modo da rendere comprensibili alcune delle scelte effettuate nella realizzazione del progetto. Non verrà comunque fatta una trattazione esaustiva su tutti gli aspetti della crittografia, ma solo su quelli ritenuti più importanti per la comprensione del lavoro svolto, oltre ad una parte di introduzione storica. 2.1 Informazioni generali La parola crittografia deriva dalla parola greca kryptós che significa nascosto e dalla parola greca gráphein che significa scrivere. La crittografia è la controparte della crittanalisi ed assieme formano la crittologia. Volendo definire semplicemente questi termini, possiamo dire che la crittografia è la parte della crittologia che si occupa di trasformare un messaggio in qualcosa di diverso, utilizzando adeguate tecniche, così da renderne impossibile, o quantomeno difficile, la decifrazione. Di questa ultima si occupa invece la crittanalisi, cioè del risalire al messaggio originale conoscendo quello cifrato ma senza sapere la tecnica usata per cifrarlo. 2.2 Crittografia e Steganografia nel passato Sembra che il primo esempio scritto di messaggio cifrato risalga a circa 6000 anni fa; si tratta di una iscrizione egizia, dove vennero usati geroglifici non standard per celare il significato di un messaggio. Per migliaia di anni re, regine e generali hanno avuto il bisogno di comunicazioni efficienti per governare i loro paesi e comandare i loro eserciti. Inoltre, essi compresero le conseguenze dell’eventuale caduta dei loro messaggi in mano ostili: informazioni preziose sarebbero state a disposizione di nazioni rivali e nemici. Fu il pericolo dell'intercettazione da parte degli avversari a promuovere lo sviluppo di codici, tecniche di alterazione del messaggio destinate a renderlo comprensibile solo alle persone autorizzate. Una delle prime tecniche di comunicazione segrete, basata sull'occultamento del messaggio, si chiama steganografia, dalle parole greche steganós, che significa coperto, e gráphein, che significa scrivere. Negli anni sono state impiegate in tutto il mondo innumerevoli forme di steganografia. La longevità della steganografia dimostra che essa garantisce una certa sicurezza, ma il suo punto debole è evidente: se il portatore del messaggio è attentamente perquisito, è probabile che il messaggio sia scoperto. In altre parole, la segretezza è perduta nel momento stesso dell'intercettazione.

6

Perciò in parallelo con lo sviluppo della steganografia si assisté all'evoluzione della crittografia. Essa non mira a nascondere il messaggio in sé, ma il suo significato. Per rendere incomprensibile un testo, lo si altera per mezzo di un procedimento concordato dal mittente e dal destinatario. Questi può quindi invertire il procedimento, e ricavare il messaggio originale. Il vantaggio della crittografia è che anche se il nemico intercetta il messaggio, esso risulta incomprensibile e quindi inutilizzabile. Infatti il nemico, non conoscendo il procedimento di alterazione, dovrebbe trovare difficile, se non impossibile, ricostruire il significato. Non tutte le società antiche svilupparono forme di crittografia. La Cina, per esempio, l'unica civiltà antica ad usare una scrittura ideografica, non ne ha mai viste. Le ragioni, secondo gli storici, sono legate alla natura prevalentemente orale delle comunicazioni. Anche se la steganografia e la crittografia sono discipline indipendenti, possono essere impiegate per alterare e occultare il medesimo testo, garantendo un livello di sicurezza molto più elevato. Per esempio, il « microdot », cioè la riduzione di uno scritto alle dimensioni di un punto, è una forma di steganografia che ebbe largo impiego durante la seconda guerra mondiale. Tramite un procedimento fotografico, gli agenti tedeschi in America latina trasformavano una pagina scritta, precedentemente crittografata, in una macchia con un diametro inferiore al millimetro, che poteva essere nascosta nel puntino di una « i » in una comunicazione banale. Il primo microdot fu scoperto dall' FBI nel 1941 grazie a una soffiata. Come esempio di tecniche crittografiche usate in passato, esaminiamo il Cifrario di Cesare, forse il più famoso. 2.2.1 Il cifrario di Cesare Svetonio nella Vita dei dodici Cesari, un'opera del II secolo d.C., racconta che Giulio Cesare usava per le sue corrispondenze riservate un codice di sostituzione molto semplice, nel quale ogni lettera del testo veniva sostituita dalla lettera che la segue di tre posti nell'alfabeto (usiamo in questo esempio l’alfabeto inglese) a b c d e f g h i j k l m n o p q r s t u v w x y z

d e f g h i j k l m n o p q r s t u v w x y z a b c Figura 2.1: Cifrario di Cesare Supponiamo per esempio di voler trasformare la parola “informatica” usando questo metodo, e facendo in modo che ogni lettera del messaggio cifrato sia spostata di 3 posizioni rispetto a quella del messaggio originale. Il risultato sarebbe “lqirupdwlfd”. Certo, oggi può sembrare banale una tecnica del genere, ma al tempo di Cesare, quando erano poche le persone che sapevano leggere, poteva bastare. Metodi come questo si chiamano “cifrari a scorrimento”, ed un esempio è il ROT-13, dove l’offset tra i caratteri del messaggio cifrato e quello originale è 13.

7

Figura 2.2: ROT 13

Il cifrario di Cesare ci permette comunque di definire gli elementi principali della crittografia.

1. Un testo in chiaro (plain-text) da proteggere (nell’esempio del cifrario di Cesare, “informatica”)

2. Un algoritmo di cifratura, cioè il metodo usato per elaborare il testo in chiaro; nel nostro caso la sostituzione di ogni carattere con una lettera più avanti nell’alfabeto.

3. Una chiave, che serve all’algoritmo crittografico per produrre il testo cifrato; nell’esempio analizzato è il numero 3, cioè il numero di posizioni di cui far avanzare ogni lettera del testo in chiaro.

4. Il testo cifrato (cipher-text), l’output dell’algoritmo; nel nostro esempio la parola “lqirupdwlfd”. Un algoritmo come quello di Cesare, dove la stessa chiave viene usata per cifrare e decifrare, è detto simmetrico o a chiave privata, per differenziarlo dagli algoritmi asimmetrici o a chiave pubblica; torneremo su questi argomenti più avanti. Il difetto principale del metodo di Cesare è però che usando una tecnica “brute force” (cioè provando tutte le chiavi possibili) si riesce facilmente ad arrivare alla decifrazione del messaggio; infatti supponendo di usare l’alfabeto italiano, le possibili chiavi sono 20. Questo perché l’alfabeto italiano ha 21 caratteri, e usando la chiave 21 si avrebbe il cipher-text uguale al plain-text, mentre con la chiave 22 si otterrebbe lo stesso risultato fornito dalla chiave 1 e così via (in sostanza si avrebbe la chiave modulo 21). Si potrebbe a questo punto pensare che per ovviare al problema basti tenere segreto il metodo di cifratura (l’algoritmo) usato. Questo approccio però è sbagliato, perché se un eventuale nemico si impadronisse dell’algoritmo, sarebbe in grado di decifrare tutti i messaggi, anche quelli futuri. Nel 1883 lo studioso di crittologia Auguste Kerckhoffs, scrisse infatti: "La sicurezza di un crittosistema non deve dipendere dal tener celato il crittoalgoritmo. La sicurezza dipenderà solo dal tener celata la chiave." Un buon algoritmo non dovrà quindi basarsi sulla sua segretezza, ma sull’impossibilità di provare tutte le chiavi in tempo ragionevole, evitando l’attacco “brute force”, e sulla difficoltà di risalire alla chiave usata conoscendo solo l’algoritmo.

8

2.3 La crittografia fino al XVIII secolo

Nel 1446 il grande architetto e letterato Leon Battista Alberti pubblicò il trattato De Cifris, dove oltre a parlare dei vari metodi di cifratura conosciuti, introdusse un nuovo algoritmo, la cui particolarità era quella di modificare periodicamente la chiave. Alberti ha proposto un disco composto di due cerchi concentrici di rame. Uno esterno fisso di diametro maggiore sul quale sono riportate le lettere dell'alfabeto in chiaro e uno interno mobile per le lettere dell'alfabeto cifrante. Il disco esterno è composto di 24 caselle contenenti 20 lettere maiuscole in ordine lessicografico, escluse H, J, K, W, Y, al posto delle quali ci sono i numeri 1, 2, 3, 4. Il disco interno riporta le 24 lettere minuscole in maniera disordinata (la u e la v sono collassate) ed un simbolo speciale &. Fissata una lettera maiuscola come chiave, ad esempio B, si deve spostare il disco mobile interno in modo da far corrispondere la B con un simbolo particolare del disco interno(&). Si stabilisce in tal modo un'associazione tra le lettere dell'alfabeto in chiaro e quello dell'alfabeto cifrante.

Blaise de Vigenère pubblicò nel 1586 un trattato di cifrari nel quale proponeva tra gli altri un codice che ebbe grande fortuna e che è ricordato con il suo nome. Si tratta del più semplice codice di sostituzione polialfabetica, e proprio per la sua semplicità ha goduto per secoli di una grossa fama. La forza del cifrario di Vigenère sta nell'utilizzare non uno ma 26 alfabeti cifranti per cifrare un solo messaggio. Il metodo si può considerare una generalizzazione del codice di Cesare; invece di spostare sempre dello stesso numero di posti la lettera da cifrare, questa viene spostata di un numero di posti variabile, determinato dalle lettere della parola chiave, da concordarsi tra mittente e destinatario. La parola è detta chiave o verme, per il motivo che, essendo in genere molto più corta del messaggio, deve essere ripetuta molte volte. Di seguito viene riportata il cifrario utilizzato nei codici di Vigenère.

Figura 2.3: Disco di Leon Battista Alberti

9

Forniamo ora un esempio pratico dell’utilizzo del cifrario di Vigenère. Scegliamo innanzitutto una parola chiave, per es. “mito”, e scriviamo di seguito le righe della tabella precedente (alfabeti) con le iniziali corrispondenti alle lettere della parola chiave.

Figura 2.4: Cifrario di Vigenère

M N O P Q R S T U V W X Y Z A B C D E F G H I J K L

I J K L M N O P Q R S T U V W X Y Z A B C D E F G H

T U V W X Y Z A B C D E F G H I J K L M N O P Q R S

O P Q R S T U V W X Y Z A B C D E F G H I J K L M N

A questo punto supponiamo di voler codificare la parola “mondo”. Dobbiamo usare i 4 alfabeti ottenuti in ciclo continuo; ora, la “m” di mondo corrisponde nel primo alfabeto a “y”, infatti “m” è la 13 esima lettera dell’alfabeto, e “y” è la 13 esime lettera del primo alfabeto. Di conseguenza, la “o” viene codificata, usando il secondo alfabeto, in “w”, la “n” usando il terzo in “g”, la “d” usando il quarto in “r”, e per la “o” finale dobbiamo riusare il primo alfabeto ottenendo “a”. Quindi la parola che otteniamo è “ywgra”. La cosa importante da notare è che alla stessa lettera del testo in chiaro, possono corrispondere lettere diverse del testo cifrato. E, viceversa, a lettere diverse del testo in chiaro può corrispondere la stessa lettera nel testo cifrato. Questa caratteristica rende il cifrario di Vigenerè inattaccabile con le tecniche di analisi statistica, basate sul fatto che in tutte le lingue alcune lettere sono molto più frequenti di altre (per es. in italiano la “e” ricorre molo più spesso della “q”). La forza di questo cifrario risiede anche nel fatto che il numero di chiavi è enorme, quindi un tentativo di decifratura basato sulla forza bruta (cioè sulla prova in sequenza di tutte le chiavi possibili) risulta computazionalmente troppo oneroso. Questo metodo, che rimase per circa 300 anni inviolato, venne però sconfitto da Friederich Kasiski, che in un suo trattato del 1861 descrisse un modo per attaccare con successo un cifrario polialfabetico con chiave ripetuta come quello di Vigenère.

10

2.4 La crittografia moderna

Il cifrario di Jefferson prende il nome dal suo inventore Thomas Jefferson (1743-1826), uno degli autori della Dichiarazione d'Indipendenza e Presidente degli USA nel 1801-1804. Jefferson non lo mise mai in uso e il suo cifrario fu dimenticato fino al 1922, quando fu riscoperto e utilizzato, fino agli anni '50, dall'esercito statunitense. Nel 1890 Etienne Bazeries un crittologo francese propose "La chiffre endecifrable", un cifrario del tutto equivalente a quello di Jefferson. Il codice di Jefferson è un metodo di cifratura meccanico basato su un cilindro costituito da 36 dischi, imperniati su di un asse, in grado di ruotare liberamente. Ogni disco riporta le 26 lettere dell'alfabeto sul bordo esterno, in ordine differente l'uno rispetto all' altro. Inoltre i dischi possono volta per volta essere inseriti sull'asse in un ordine differente per ogni cifratura. La cifratura di un messaggio avviene nel seguente modo: il messaggio viene innanzitutto diviso in blocchi di 36 caratteri. Per ogni blocco, i dischi della macchina vengono ruotati in modo tale da far comparire allineati su una riga i caratteri del blocco. Una volta effettuata tale operazione, si sceglie a caso un'altra riga, e si considera la corrispondente sequenza di 36 lettere come il messaggio cifrato. Il ricevente, che possiede un cilindro identico a quello del trasmittente, non deve far altro che ruotare i dischi in modo tale da far comparire il cifrato allineato su una riga. Compiuta questa operazione, deve analizzare le restanti righe. Una sola di queste è una frase di senso compiuto rappresentante il messaggio in chiaro. Una variante è quella di fissare a priori la riga su cui sarà possibile trovare il messaggio in chiaro. Il cilindro di Jefferson è il primo esempio di una serie di macchine cifranti basate su cilindri e dischi ruotanti intorno ad un asse, e la più celebre di tutte è la cosiddetta Macchina Enigma usata dai Tedeschi nella Seconda Guerra Mondiale. Figura 2.5: Cifrario di Jefferson Il Playfair cipher fu inventato dal noto fisico Sir Charles Wheatstone (1802-1875), ma il nome di Playfair deriva da colui che ha divulgato nelle alte sfere governative questo metodo di cifratura. Lyon Playfair, barone di St.Andrews, mostrò per la prima volta questo sistema nel 1854 durante una cena organizzata da Lord Granville alla presenza di Lord Palmerton (1784-1865) allora ministro degli Esteri.

11

Il Cipher è ritenuto essere il primo metodo di cifratura a bigrammi (coppie di caratteri). Si usa una matrice di 25 lettere che viene riempita nelle prime caselle con la parola chiave, eliminando le eventuali lettere ripetute, ed è completata con le rimanenti lettere in ordine alfabetico. Si tralascia la W che, se necessario, potrà essere cifrata come una doppia V. Il testo in chiaro deve essere diviso in bigrammi di due lettere consecutive. Le due lettere si cercano sul quadrato e si sostituiscono con altre secondo alcune regole prestabilite. Durante la seconda guerra mondiale, le operazioni di decifrazione Britanniche furono spostate da Londra a Bletchley Park. Anche Alan Turing (1912-1954) (uno dei più famosi matematici di questo secolo, fra i fondatori dell'informatica teorica) era nel team di Bletchley Park e il lavoro suo e dei suoi colleghi poté essere completamente apprezzato solo molti anni dopo, quando cadde il segreto militare sulle tecniche di crittoanalisi durante la guerra. Quasi tutte le comunicazioni tedesche venivano cifrate con una macchina chiamata Enigma. Questa macchina è una nobile rappresentante dei cifrari a rotore, utilizzati fino all'introduzione di cifrari elettronici e microelettronici che hanno sconvolto e trasformato il mondo della crittografia. Per sconfiggere Enigma (alcuni dettagli della soluzione sono tenuti segreti fino ad oggi) Turing, per conto del governo inglese, si servì di gigantesche macchine chiamate appunto Colossi, che possono considerarsi i precursori dei moderni calcolatori elettronici. Turing è inoltre autore di ricerche estremamente importanti sul concetto logico-matematico di calcolabilità: lo strumento che egli ha proposto per affrontare il problema è noto oggi col nome di macchina di Turing. 2.4.1 Enigma

Nel 1918 l'inventore tedesco Arthur Scherbius mise a punto un dispositivo crittografico che in sostanza era una versione elettromeccanica del disco cifrante di Leon Battista Alberti: la macchina Enigma. La versione semplificata di questo dispositivo consiste in 3 componenti collegati da fili elettrici: una tastiera per immettere le lettere del testo in chiaro; un'unità scambiatrice che cifra la lettera e un visore con varie lampadine, che accendendosi indicano la lettera da inserire nel testo cifrato; una stampante elettro-meccanica avrebbe appesantito troppo il congegno e lo avrebbe reso poco maneggevole. Per generare il crittogramma, l'operatore preme il tasto corrispondente alla lettera da cifrare; l'impulso elettrico raggiunge l'unità scambiatrice, e dopo essere stato elaborato va ad illuminare il visore in modo da evidenziare la lettera cifrata corrispondente Figura 2.6: Versione semplificata della macchina

Enigma con un alfabeto di sei lettere.

12

Con questo schema lo scambiatore in sostanza definisce una corrispondenza tra le lettere del testo in chiaro e quelle cifrate, e la macchina può essere usata per realizzare una semplice cifratura per sostituzione monoalfabetica. Il passo successivo consiste nel far ruotare automaticamente il disco scambiatore di un 1/26 di giro dopo la cifratura di ogni lettera. Con questa disposizione rotante, lo scambiatore in sostanza definisce 26 diverse corrispondenze tra lettere in chiaro e cifrate, ed Enigma può essere usata per effettuare una cifratura polialfabetica. Tuttavia il congegno ha un punto debole evidente: dopo 26 pressioni continue dello stesso tasto, il disco torna alla posizione iniziale, e se si continuasse a premere lo stesso tasto, lo schema di cifratura si ripeterebbe tale e quale. Per ridurre il numero di ripetizioni può essere aggiunto un altro scambiatore. In questo modo, ogni volta che una lettera è cifrata, il primo disco ruota di un carattere, mentre il secondo disco invece resta immobile fin quando il primo scambiatore ha completato un giro; solo a questo punto il secondo scambiatore avanza di una posizione. L'aggiunta del secondo scambiatore comporta il vantaggio che lo schema della cifratura non si ripete finché il secondo scambiatore non è tornato al punto di partenza, il che richiede 26 giri completi del primo scambiatore, ovvero la cifratura di 26x26=676 lettere. Per una sicurezza maggiore viene aggiunto un terzo rotore, per cui il numero di sostituzioni diverse è 26x25x26=16.900 (il secondo rotore effettua una rotazione in meno rispetto agli altri due, poiché dopo aver effettuato un giro completo rimane fermo una volta per far ruotare il terzo rotore). Inoltre viene aggiunto un riflessore molto simile allo scambiatore che consiste in un disco di gomma con circuiti interni che non ruotano e i fili entrano ed escono dallo stesso lato. Col riflessore installato quando si digita una lettera il segnale elettrico attraversa i 3 rotori, raggiunge il riflessore ed è mandato indietro. Quindi il segnale elettrico passa di nuovo nei rotori ma lungo un percorso diverso.

Figura 2.7: Il progetto di Scherbius del modello base di Enigma includeva un terzo scambiatore e un riflessore, che costringe l'impulso elettrico ad attraversare di nuovo gli scambiatori.

Dato che il numero di chiavi è alto ma non abbastanza per scoraggiare un crittoanalista che può disporre di più macchine, per accrescere l'affidabilità si dovrebbe aumentare il numero di chiavi. Invece di aggiungere un altro rotore e aumentare di 26 volte le chiavi sono state introdotte due nuove caratteristiche. Innanzitutto si possono utilizzare rotori removibili e sostituibili, ad esempio il primo e il terzo rotore si possono scambiare di posto. Quindi dati tre elementi intercambiabili essi possono essere permutati in sei modi differenti; con questo accorgimento il numero di chiavi aumenta di un fattore sei. La seconda

13

caratteristica è l'inserimento di un pannello a prese multiple tra la tastiera e il primo rotore. Il pannello permette al mittente di inserire alcuni cavi muniti di spinotti, che aveva l'effetto di scambiare due lettere prima della loro immissione nel rotore. L'operatore di Enigma dispone di sei cavi che gli danno la possibilità di scambiare sei coppie di lettere contemporaneamente. Figura 2.8: Il pannello a prese multiple è interposto tra la

tastiera e gli scambiatori. Inserendo gli appositi cavetti è possibile scambiare due lettere.

Eseguiamo ora un rapido calcolo per trovare il numero di chiavi possibili

• Rotori I due dischi rotanti più esterni effettuano 26 rotazioni ognuno, mentre quello centrale ne effettua 25, quindi sono ammesse 26x25x26=16.900 combinazioni

• Unità cifratrice I tre rotori (1, 2 e 3) possono essere inseriti nell'unità centrale in diverse posizioni reciproche, così riassumibili: 123, 132, 213, 231, 312, 321. Sono quindi ammesse 6 diverse posizioni reciproche dei rotori.

• Pannello a prese multiple I possibili abbinamenti di 2 x 6 = 12 lettere su 26 sono moltissime, per l'esattezza 100.391.791.500, che si ottiene dalla formula seguente dove p, il numero di cavi, è uguale a 6.

Il numero totale di chiavi si ottiene moltiplicando queste possibilità: 16.900 x 6 x 100.391.791.500

14

Figura 2.9: Macchina Enigma 2.5 Cifrario di Vernam e sicurezza perfetta Nel 1917 Gilbert Vernam, impiegato della compagnia AT&T, inventò un ingegnosissimo sistema di protezione crittografica, per comunicazioni su telegrafo, dei testi codificati in binario. Egli costruì per prima cosa un dispositivo in grado di leggere contemporaneamente due nastri in input e generare a partire da essi un nastro di output in modo che ciascun foro fosse generato mediante uno XOR dei due corrispondenti fori sui nastri input. Dopodiché prese un nastro su cui era perforata una sequenza di caratteri casuale ed un nastro su cui era perforato un testo reale e li passò nella sua macchina. Lo schema di crittografia di Vernam è uno schema one-time pad; un tale schema richiede che:

• la chiave sia utilizzata una sola volta; • la chiave deve essere lunga almeno quanto il testo in chiaro; • fra i bit che compongono la chiave non deve esserci alcuna relazione; • la chiave deve essere generata casualmente.

In pratica se il testo in chiaro è X = 0110 e la chiave è K = 1100, applicando il metodo di Vernam si ottiene il seguente testo cifrato : Y= X ⊕ K = 1010 la decifratura si ottiene nel seguente modo: X= Y ⊕ K = 0110

15

Notiamo che è stata applicata la stessa chiave ed è stata effettuata la stessa operazione sia per la cifratura che per la decifratura; ciò caratterizza un sistema crittografico reversibile, e questo è uno dei molti aspetti notevoli del cifrario di Vernam. Per quanto riguarda la sicurezza, a tutt'oggi questo è l'unico metodo ad essere perfetto, ossia costituisce un cifrario assolutamente indecifrabile in senso stretto. Un cifrario si dice perfetto se, dati X il testo in chiaro e Y il cifrato corrispondente, gode della seguente proprietà: per ogni X’e Y’ risulta: Pr (X = X’) = Pr (X = X’ | Y = Y’) La proprietà di cui sopra si chiama sicurezza perfetta. Per un cifrario che gode della sicurezza perfetta, l'indecisione nello stabilire qual è il testo in chiaro X senza conoscere il testo cifrato Y è la stessa che si ha su X conoscendo il testo cifrato Y. Le proprietà che caratterizzano l’one-time pad sono estremamente restrittive, e volendole rispettare si ottiene un sistema scomodo da usare in pratica, considerando che le ingombranti chiavi andrebbero generate in anticipo rispetto al loro uso, e conservate in luogo sicuro. Sono questi i motivi per cui questo sistema non viene usato che per casi eccezionali, come la famosa hot-line tra Washington e Mosca. Un'altro problema è che l’one-time pad è modificabile; un intruso può cambiare Y così che il messaggio M decifrato sia differente dal messaggio spedito. Non ci sono modi per il destinatario di controllare che il mittente abbia spedito proprio il messaggio ricevuto. Ci sono delle varianti che possono evitare di utilizzare delle chiavi così grandi, ma che fanno perdere la perfezione al sistema perché introducono delle dipendenze statistiche. Un esempio è quello di prendere una chiave in un grosso testo, come la Divina Commedia, specificando un punto di inizio qualunque, e tutti i caratteri da quel punto in poi formeranno la chiave. La dipendenza statistica dipende proprio dal fatto che le parole devono avere senso compiuto. La difficoltà per i crittoanalisti, oltre alla conoscenza della chiave (punto di inizio nel testo), sta anche nel capire qual è il testo utilizzato. Il problema con le chiavi corte, che dunque devono essere riutilizzate ciclicamente nel corso del messaggio, è che producono, in uscita, delle regolarità statistiche che possono essere usate dai crittoanalisti per forzare il cifrario. 2.6 Crittografia simmetrica e asimmetrica Si può effettuare una distinzione in 2 grandi categorie per quanto riguarda i metodi di cifratura: quelli a chiave privata (o simmetrici, o a chiave segreta) e quelli a chiave pubblica (o asimmetrici). Analizziamo ora le caratteristiche principali di questi tipi di algoritmi fornendo anche qualche esempio. 2.6.1 Crittografia simmetrica La crittografia simmetrica si basa sul fatto che la stessa chiave che viene usata per cifrare il messaggio viene utilizzata anche per decifrarlo.

16

Figura 2.10: Funzionamento riassuntivo della crittografia a chiave privata

Ad esempio il cifrario di Cesare visto in precedenza è un classico esempio di sistema simmetrico. La chiave in questo caso è rappresentata dal numero 3 corrispondente al numero di traslazioni, verso sinistra, delle lettere dell'alfabeto della lingua italiana a partire dalla lettera a. I cifrari simmetrici sono stati tra i primi cifrari della storia e vengono tuttora utilizzati nei moderni sistemi crittografici per la loro velocità di elaborazione. Vediamone alcuni esempi.

2.6.1.1 Des

Il DES (Data Encryption Standard) venne adottato dal governo degli Stati Uniti nel 1977 come standard federale. Esso deriva dall'algoritmo Lucifer inventato dall' IBM nei primi anni '70. Mentre Lucifer era ancora in via di sviluppo il NBS (National Bureau of Standard), diventato poi NIST (National Institute of Standards and Technology), sollecitò l'industria americana alla creazione di un nuovo standard crittografico per la protezione di dati riservati ma non classificati come "segreti militari" o di "stato". L'NBS non fu accontentato molto presto forse perché il governo degli Stati Uniti non ha mai incoraggiato ricerche in questo campo, e nel 1974 l'IBM propose un Lucifer modificato a cui fu dato il nome di DEA (Data Encryption Algorithm). L’NBS sceglie il DEA come standard ed è annunciato sul documento N.46 di Federal Information, col nuovo e definitivo nome di DES. La chiave di crittografazione è lunga 64 bit, ma 8 bit sono di controllo, quindi la chiave effettiva è di 56 bit. Questo porta ad avere 256 (circa 72 milioni di miliardi) possibili chiavi in un tentativo di attacco brute - force. In effetti un supercomputer potrebbe scoprire la password in un tempo che va dalle 3 alle 10 ore (per quello che è noto a livello non militare). Tuttavia, anche senza basarsi sull'attacco di forza bruta, gli studiosi Biham e Shamir hanno ideato una nuova tecnica di forzatura detta crittoanalisi differenziale. Questa tecnica consiste nell'utilizzo dell'algoritmo per la cifratura di 247 testi particolari ed il confronto dei risultati. Ancora in tempi più recenti, Matsui ha ideato un altro tipo di forzatura, la crittoanalisi lineare. Anche in questo caso vengono cifrati dei testi noti, per la precisione 243, ed analizzati i risultati con il testo da decifrare. I tempi di decrittazione sono comunque lunghi: il primo esperimento di Matsui richiese 9735 postazioni di lavoro e 50 giorni e 12 ore di tempo.

17

Il DES non viene più certificato dal NIST. Ha tuttavia ancora larghissimo impiego nelle trasmissione audiovisive (è incluso nello standard IRDETO, usato nelle trasmissioni svizzere) e nei sistemi di protezione di Bancomat e carte di credito, data anche l'elevata velocità di crittografazione rispetto al suo rivale RSA a chiave pubblica. Non può essere tuttavia utilizzato in quei casi dove il valore dell'informazione da proteggere sia tropo elevato, dato che già da tempo è stato dimostrato che in circa 3 ore qualsiasi testo cifrato con DES può essere riportato in chiaro tramite un computer dal costo di 1 milione di dollari. É comunque stata costruita una versione del DES, chiamata Triplo DES, che utilizza 3 chiavi diverse ad ogni passaggio di sovracifratura. Nonostante i risultati siano inferiori alle aspettative, è stato innalzato moltissimo il tempo necessario per un attacco di brute-force. Figura 2.11: Riassunto del funzionamento del Des

18

2.6.1.2 Triple-Des Il Triple-Des, o TDES, è l’evoluzione del Des; venne realizzato quando i 56 bit del Des oramai erano insufficienti a garantire un alto livello di sicurezza dei messaggi crittografati. Il Triple Des funziona in sostanza applicando 3 volte il Des a un messaggio da cifrare usando 3 chiavi; questa si chiama configurazione “EEE”, e per decifrare il messaggio si faranno 3 passaggi di decifrazione come si farebbe per il Des normale usando le 3 chiavi. Un altro metodo di funzionamento è il cosiddetto “EDE”, dove il secondo passaggio, nella generazione del messaggio cifrato, è in realtà di decifrazione; così per decifrare il messaggio, il secondo passo dovrà essere di cifrazione.

Figura 2.12: Triple-Des in modalità “EDE”

Quando le 3 chiavi sono diverse si parla di 3TDES, e in questo caso la chiave è lunga 168 bit, infatti ogni chiave del Des è lunga 56 bit; con i bit di parità si arriverebbe ad una lunghezza effettiva di 192 bit. C’è un altro approccio, chiamato 2TDES, dove la prima e la terza chiave sono uguali; questo fa scendere la lunghezza della chiave a 112 bit (128 con i bit di parità). Il Triple Des è sicuramente molto più difficile da sconfiggere del Des, e in effetti anche usando tecniche di calcolo parallelo sarebbe molto oneroso in termini di tempo e denaro riuscire a decifrare un messaggio cifrato con TDES, ma questo algoritmo è stato superato da AES, molto più veloce ed efficiente.

19

2.6.1.3 AES Aes (Advanced Encryption Standard) è una implementazione dell’algoritmo Rijndael (dai cognomi dei suoi inventori, Joan Daemen e Vincent Rijmen). Questo è un algoritmo molto veloce, sia se sviluppato in hardware, sia in software, (fino a 6 volte più di Des), ed è usato come standard dal governo degli Stati Uniti d’America. Aes è un algoritmo di cifratura a blocchi, e questi ultimi hanno dimensione di 128 bit, mentre la chiave può essere di 128, 192 o 256 bit. Per funzionare l’algoritmo usa matrici di 4x4 byte chiamate “Stati”. La cifratura avviene seguendo questi 4 passaggi ad ogni passo, tranne l’ultimo dove il terzo passaggio viene saltato.

• Passo 1 SubBytes: in questa fase tutti i byte della matrice vengono rimpiazzati seguendo una specifica tabella in maniera non lineare

• Passo 2 ShiftRows: a seconda della riga di appartenenza viene effettuato uno spostamento dei byte di un certo numero di posti

• Passo 3 MixColumns: i byte, una colonna per volta, vengono trattati con una operazione lineare

• Passo 4 AddRoundKey: Ogni byte della tabella viene combinato con una certa chiave.

Figura 2.13: I vari passi di AES

Finora tutti gli attacchi ad AES si sono rivelati inefficaci, nel senso che seppur corretti formalmente richiedono un tempo di calcolo troppo elevato per poter essere presi in considerazione.

20

2.6.1.4 IDEA Questo algoritmo è stato sviluppato da Xuejia Lay e James Massey. La prima versione dell’algoritmo sviluppato, chiamata PES, era però facilmente attaccabile da crittoanalisi differenziale, quindi venne sviluppata una seconda versione, IPES, che è in pratica il vero e proprio IDEA. Come RSA, che vedremo più avanti, IDEA è usato nel famoso programma PGP (Pretty Good Privacy), ed è quindi un algoritmo efficiente. Come DES, è un sistema di cifratura a blocchi, ma usa chiavi da 128 bit (e non 56, o 64 se contiamo i bit di parità, come DES). Un attacco “brute force” è quindi impraticabile, dato che dovrebbero essere analizzate chiavi. 1282IDEA si basa su un procedimento in 9 passi: ad ogni passo vengono utilizzate 6 sottochiavi, mentre nell’ultimo 4. Il testo in input viene suddiviso in blocchi da 64 bit, e vengono utilizzante come operazioni lo XOR, la somma modulo e la moltiplicazione modulo +1.

162162

Per la decifrazione sono usate sottochiavi diverse, ma il procedimento è lo stesso. Non vogliamo qui analizzare a fondo il funzionamento di IDEA, ma ricordiamo che è uno degli algoritmi più sicuri in circolazione al momento.

Figura 2.14: Funzionamento di IDEA

Ci sarebbero ancora moltissimi algoritmi a chiave segreta, come RC5, RC6, Blowfish, Serpent e Mars solo per fare alcuni nomi, ma non vogliamo analizzarli

21

tutti. Per gli scopi di questa tesi gli esempi presentati sono sufficienti; in rete è comunque possibile trovare facilmente molto materiale per chi fosse interessato ad approfondire l’argomento. 2.6.1.5 Lo scambio di chiavi di Diffie-Hellman Lo svantaggio principale della crittografia simmetrica è che se Alice e Bob vogliono comunicare devono scambiarsi le chiavi. Usando il metodo di Diffie ed Hellman si riesce a risolvere questo problema. Questa tecnica si basa innanzitutto sulla presenza di 2 parametri, p e g: il primo è un numero primo e il secondo è un intero minore di p, e si chiama generatore. Il generatore deve avere la proprietà che ][ 1,1 −∈∀ pn esiste una potenza k di g tale che . Ora, per scambiarsi una chiave segreta Alice sceglie un valore a e Bob sceglie un valore b in modo casuale rispettando però la condizione che a,b

pgn k mod=

][ 2,1 −∈ p . A questo punto Alice calcola il valore e lo invia a Bob, mentre Bob calcola il valore e lo invia ad Alice. Ora Alice calcola il valore , e Bob calcola

. Così ora Alice e Bob hanno la possibilità di avere una chiave in comune, K, per poter comunicare usando la crittografia segreta.

pgA a mod=pgB b mod=

pgpBK aba modmod ==pgpAK abb modmod ==

Figura 2.15: Scambio delle chiavi di Diffie-Hellman

Questo metodo presenta però uno svantaggio: se un intruso T volesse, potrebbe intercettare i messaggi di Alice e Bob, e farsi spacciare per Bob nei confronti di Alice, e per Alice nei confronti di Bob: questo è il cosiddetto attacco “man in the middle”, e si può presentare anche con i metodi di crittografia simmetrica come RSA. La soluzione a questo problema verrà analizzata nel capitolo 3 quando si parlerà di certificati digitali e Certification Authority.

22

2.6.2 Crittografia asimmetrica Uno dei problemi maggiori dell’utilizzo di tecniche di crittografia simmetrica è che, come abbiamo detto, se A e B vogliono comunicare, devono in qualche modo scambiarsi la chiave segreta. Questo sarebbe possibile in modo sicuro per esempio se A e B si incontrassero di persona e si scambiassero tale informazione, ma per ovvi motivi non è sempre attuabile. Whitfield Diffie e Martin Hellman introdussero nel 1976 un sistema nuovo, dove erano presenti 2 chiavi: la chiave pubblica e quella privata. Ogni persona possiede una coppia di chiavi, pubblica e privata, ma quest’ultima va tenuta segreta, mentre la prima deve essere resa disponibile. Se A vuole mandare un messaggio a B, non deve fare altro che cifrarlo usando la chiave pubblica di B, che è disponibile. Solo B, con la sua chiave privata, potrà decifrare tale messaggio. Se infatti un intruso T riuscisse ad intercettare il messaggio che A ha inviato a B, non riuscirebbe a fare nulla, dato che non possiede la chiave privata di B. Il metodo si basa sul fatto che è computazionalmente molto difficile risalire alla chiave privata di una persona anche sapendo la sua chiave pubblica; queste proprietà derivano di solito da importanti teoremi dell’algebra.

Figura 2.16: Crittografia asimmetrica (a chiave pubblica)

23

2.6.2.1 RSA L’esempio forse più famoso per quanto riguarda la crittografia a chiave pubblica è RSA. Esso è un algoritmo ideato da Rivest, Shamir e Adleman nel 1978 (RSA deriva dalle iniziali dei loro cognomi). Supponiamo che A e B vogliano scambiarsi messaggi usando RSA; vediamo i vari passaggi necessari. Per prima cosa A e B devono generare ognuno una coppia <chiave pubblica, chiave privata>. Analizziamo questo processo di generazione per A, ma lo stesso deve fare B. 1. A sceglie due numeri primi grandi, p e q. 2. A calcola n=p x q e calcola anche il prodotto (p-1) x (q-1). 3. A deve scegliere un numero e in modo che e e (p-1) x (q-1) siano primi tra

loro (cioè non abbiano fattori in comune a parte 1); e non deve essere banale, cioè non deve essere ne 1 ne (p-1) x (q-1).

4. A calcola d in modo che d x e mod (p-1) x (q-1) sia uguale a 1. 5. La chiave pubblica di A è la coppia <n,e> e viene pubblicata; quella privata

<n,d> deve essere mantenuta segreta. Ricordiamo che la funzione mod è il modulo, cioè a mod b è il resto della divisione tra a e b. Supponiamo che anche B abbia fatto lo stesso, e che la sua chiave pubblica sia <n’,e’> mentre quella privata sia <n’,d’>. Se ora B volesse spedire ad A un messaggio M, per prima cosa, usando la chiave pubblica di B (che ricordiamo è disponibile), dovrebbe calcolare la quantità

; questo sarebbe il messaggio da spedire ad A. Una volta ricevuto il messaggio, A utilizzando la sua chiave privata dovrebbe calcolare la quantità

, che equivale a M, il messaggio che B voleva mandare.

nMc e mod=

nc d modSe a volesse mandare un messaggio a B dovrebbe fare lo stesso, ma usando la chiave pubblica di B <n’,e’>, e B dovrebbe usare la sua chiave privata <n’,d’> per la decifrazione. Facciamo ora un esempio per far capire meglio come funziona l’algoritmo. Supponiamo che B, come nel caso precedente, voglia spedire un messaggio ad A. In questo caso A deve calcolare le sue chiavi pubbliche e private; anche se abbiamo detto che dobbiamo usare numeri grandi, come esempio scegliamo p e q abbastanza piccoli:

• p=7 , q=11 ; ora calcoliamo i valori n e (p-1) x (q-1) • n=7 x 11=77, (p-1) x (q-1)=6 x 10=60; ora troviamo e • e deve essere primo con 60; scegliamo ad esempio 7, infatti mdc(7,60)=1.

Adesso calcoliamo d | e x d mod (p-1) x (q-1)=1 • Abbiamo che 7 x d mod 60 = 1; in questo caso prendiamo d=43, infatti 7 x

43 mod 60 = 301 mod 60 =1 • Ora la chiave pubblica è <7,77> mentre la privata è <43,77>

Supponiamo ora che il messaggio che B vuole spedire sia M=9 (usiamo un esempio in decimale per semplicità). Allora innanzitutto B calcola, usando la chiave pubblica di A, il valore ; sarà quindi 37 il messaggio 3777mod97 ==c

24

che B invierà ad A. Una volta ricevuto 37, A dovrà decifrarlo usando la sua chiave privata, ottenendo , cioè il messaggio originale mandato da B. 977mod37 43 ==mTutto questo funziona grazie a dei teoremi molto importanti dell’algebra, come il piccolo teorema di Fermat, il teorema cinese del resto e l’algoritmo di Euclide, che però non andremo ad approfondire. La potenza dell’algoritmo non è legata all’impossibilità di sconfiggerlo, ma si basa sul fatto che è molto oneroso in termini di tempo riuscire a fattorizzare un numero, soprattutto se elevato. Lo svantaggio è che RSA è molto più lento di algoritmi simmetrici come DES, anche di 3-4 ordini di grandezza. Anche in questo caso, come già anticipato, l’attacco “man in the middle” non è eliminabile, in quanto un intruso Trudy potrebbe spacciarsi per Bob e far credere agli altri che la sua chiave pubblica sia quella di Bob; così se Alice vuole spedire un messaggio a Bob, lo cifra con la chiave pubblica di Bob, ma in realtà è quella di Trudy, che avendo la corrispondente chiave privata può leggere il messaggio. Il problema verrà risolto, come già anticipato, nel capitolo 3. 2.7 Funzioni di Hash Prima di proseguire con la trattazione, ed analizzare argomenti come la firma digitale, dobbiamo introdurre un terzo tipo di algoritmi crittografici; le cosiddette funzioni di hash o di message digest (riassunto). Lo scopo di questi algoritmi è quello di creare un “riassunto” a partire da un messaggio; per fare questo i vari algoritmi di message digest di solito operano delle trasformazioni su messaggi da 512 bit alla volta, in un modo che ricorda un po’ il Des. Non vogliamo scendere nel dettaglio di come funzionano questi algoritmi; per chi fosse interessato, un esempio del funzionamento dei più famosi, MD5 e SHA, si trova al sito http://nsfsecurity.pr.erau.edu/crypto/md5.html per l’algoritmo MD5 e su http://nsfsecurity.pr.erau.edu/crypto/sha1.html per SHA, mentre un generico algoritmo di hash su http://nsfsecurity.pr.erau.edu/crypto/generichash.html.

Figura 2.17: Esempio di funzione di hash 1/2

25

Figura 2.18: Esempio di funzione di hash 2/2

Ricordiamo brevemente le 3 proprietà che una funzione hash MD (P) deve possedere (supponiamo P un messaggio del quale si vuole calcolare il digest):

• È facile calcolare MD(P). • Sapendo MD(P) è computazionalmente difficile trovare P. • La probabilità di avere due documenti P1 e P2 tali che MD(P1)=MD(P2) è

molto bassa. Per questo terzo requisito di solito MD(P) deve essere lungo almeno 128 bit. Uno degli utilizzi di questi algoritmi è quello di garantire che un messaggio non sia stato alterato: A invia a B un messaggio e il suo hash, e quando B riceve il messaggio ne ricalcola l’hash e lo confronta con quello ricevuto da A per vedere se ci sono state alterazioni. Ovviamente anche qui potrebbe esserci un attacco di tipo “man in the middle”, infatti T potrebbe intercettare il messaggio che A ha inviato a B, e sostituirlo con un proprio messaggio contenente un hash valido.

2.8 Firma Digitale La firma digitale è una sequenza di bit di lunghezza fissa detta impronta che permette di individuare univocamente un documento, codificata con la chiave privata del firmatario. Essa varia a seconda del documento. Lo scopo di questa tecnica non è proteggere i dati ma dare una qualche garanzia sull’autenticità del mittente del messaggio (autenticazione). Un primo metodo consiste nel cifrare un messaggio utilizzando la propria chiave privata; in questo modo, dato che sicuramente solo io conosco la mia chiave privata, il destinatario del messaggio può sapere con certezza che sono io ad averlo

26

mandato. Di solito si usa in combinazione con RSA, ma si può usare un qualsiasi altro algoritmo asimmetrico. Ad esempio, se A vuole mandare un messaggio a B, lo firma con la chiave privata di A e con la pubblica di B (in questo caso l’impronta è il messaggio stesso e la firma il risultato della prima cifratura) . Una volta ricevuto il messaggio, B prima lo decifrerà usando la sua chiave privata , e poi con la chiave pubblica di A per sapere se è davvero A che lo manda. Il problema è che cifrare con RSA è oneroso, e fare 2 cifrature lo è ancora di più; per questo si è pensato di usare RSA in combinazione con tecniche di hash. Infatti se A vuole mandare un messaggio a B, prima ne calcola l’hash, usando per esempio MD5 (impronta), e poi cifra con la sua chiave privata solo l’hash e non tutto il messaggio, ottenendo la firma. Infine cifra il tutto con la chiave pubblica di B. La firma digitale riguarda quindi solo l’hash del messaggio. Quando B riceve il messaggio, lo decifra con la sua chiave privata, e poi decifra l’hash spedito da A con la chiave pubblica di A, calcola l’hash sul messaggio che A gli ha inviato e confronta questi 2 hash: se il risultato è positivo non solo B saprà che è stato A a mandargli quel messaggio, ma saprà anche che non è stato modificato il messaggio stesso, dato che il confronto degli hash ha dato esito positivo: è stata assicurata anche l‘integrità del messaggio, un'altra caratteristica molto importante nelle comunicazione su rete, assieme alla privacy e alla autenticazione. Inoltre questo metodo è più veloce del precedente, dato che una delle 2 operazioni di cifratura/decifratura con RSA è stata eseguita su un hash e non sull’intero testo, che potrebbe essere anche lungo. Rimane però un problema: una firma digitale attesta che i dati sono stati generati dal proprietario di una certa chiave privata, ma nessuno assicura che quella persona sia chi dice di essere; in altre parole è ancora il problema “man in the middle”. Se per esempio ricevo un messaggio con firma digitale di Alice, presumo che sia proprio di Alice perché decifrandolo con la sua chiave pubblica, che è disponibile, vedo che il processo va a buon fine. Ma chi mi assicura che la chiave pubblica che ho trovato appartenga davvero ad Alice? Questo sarà il problema affrontato nel capitolo successivo.

Figura 2.19: Firma Digitale

27

Capitolo 3 Certification Authority e PKI In questo capitolo verranno analizzati i concetti di Certification Authority e Public Key Infrastructure (PKI), come possibile soluzione per il problema lasciato in sospeso nel capitolo precedente, cioè la garanzia che una particolare chiave pubblica appartenga effettivamente a un certo utente. Verranno inoltre introdotti i certificati digitali, come strumento per garantire questa corrispondenza “chiave pubblica - utente”. Infine si parlerà di LDAP come protocollo per la gestione e memorizzazione di dati, nel nostro caso le informazioni relative ai certificati e alle chiavi pubbliche degli utenti. 3.1 Certificato digitale Abbiamo detto alla fine del capitolo precedente che il problema principale rimasto irrisolto è la prevenzione dell’attacco “man in the middle”. In sostanza bisogna garantire che il proprietario di una certa chiave pubblica sia veramente chi dice di essere, altrimenti tutta la teoria sulla crittografia asimmetrica e sulla firma digitale non servirebbe a nulla. Il certificato digitale serve proprio a risolvere questo problema; esso infatti permette di associare un utente a una determinata chiave pubblica, in modo da avere la certezza che tale chiave appartenga effettivamente a quell’utente. Dal punto di vista fisico il certificato è una sequenza di "caratteri" codificati in maniera opportuna che forniscono le informazioni relative all’ente emittente, al soggetto del certificato ed una serie di informazioni aggiuntive che indicano l’uso per il quale il certificato è stato rilasciato. In particolare un certificato contiene (anche se non sono le uniche informazioni contenute):

• La chiave pubblica del possessore • Il nome del possessore; se il possessore è una persona fisica si tratterà di

nome e cognome, data di nascita ecc... se invece è un server web sarà presente l'indirizzo web e il nome della compagnia titolare del dominio

• La data di scadenza della chiave pubblica • Il nome della Certification Authority (CA) che ha emesso il certificato • La firma digitale della CA che ha emesso il certificato

Il problema dell’autenticazione sembra non essere però stato risolto, ma solo spostato: infatti se è vero che un certificato attesta che una determinata coppia utente – chiave pubblica è valida, è altresì vero che dobbiamo avere una qualche garanzia che il certificato sia valido. In altre parole se l’attacco man in the middle si spostasse dal farsi passare per un altro utente all’emettere certificati falsi, saremmo al punto di partenza.

28

Introducendo però la Certification Authority come terza parte fidata che garantisce la validità del certificato, si riesce a superare il problema e a garantire finalmente l’autenticazione. Prima di descrivere il funzionamento di una Certification Authority, analizziamo però la struttura di un certificato e il formato che definisce lo standard per questi importantissimi file. 3.1.1 Il formato X.509 Per garantire una reale possibilità di utilizzo dei certificati su vasta scala serve uno standard, riconosciuto a livello mondiale, che detti le regole fondamentali e le specifiche relative ai certificati stessi. Lo standard di riferimento per i certificati digitali è il cosiddetto X.509 di ITU-T (International Telecommunication Union – Telecommunication Standardization Bureau, ovvero è il settore della Unione Internazionale delle Telecomunicazioni che si occupa di regolare le telecomunicazioni telefoniche e telegrafiche), che garantisce anche valore legale alle firme digitali. Esso venne presentato nel 1988 assieme allo standard X.500, di cui accenneremo dopo. Attualmente la versione dello standard è la X.509 v3. La struttura di un certificato digitale per chiave pubblica X.509 v3 è mostrata sotto ed è formata da attributi ed estensioni: 1. Attributi del certificato digitale

• Versione: numero di versione del certificato che attualmente è la 3. • Serial Number: numero seriale del certificato che identifica il certificato

in modo univoco all’interno della CA. • Firma: Identificativo dell'algoritmo usato dalla CA per firmare il

certificato. • Issuer: questo campo identifica le entità che hanno firmato ed emesso il

certificato. Questo campo contiene un distiguished name DN e Issuer Distinguished Name.

i. Distinguished Name: identificativo dell’utente suddiviso nelle

voci: CN ed E che stanno per nome della Certificate Autority ed Email dell’utente certificato.

ii. Issuer Distinguished Name: nello stesso formato del DN, identifica la CA che ha emesso il certificato.

• Validità (not after, not before): l’ora e le date di inizio del periodo di

validità del certificato. • Soggetto: nome. • Informazioni sulla chiave pubblica del soggetto.

i. Algoritmo per l'utilizzo della chiave pubblica. ii. Chiave pubblica.

29

2. Estensioni del certificato digitale (facoltative)

• CRLDistributionPoint: è un puntatore, un URL del server da dove scaricare la CRL (Certificate Revocation List) relativa ad un particolare certificato.

• KeyUsage: questo campo dichiara gli scopi per i quali è possibile utilizzare la chiave pubblica (uno o più tra i seguenti):

o Digital Signature: firma digitale. o Key Encipherment: “canale sicuro” per chiavi simmetriche. o Non Repudiation: assieme a “Digital Signature” per la firma

e per il non ripudio dei documenti. o Data Encipherment: cifratura dei dati. o CRL e KeyCert Signature: firma di CRL (Certificate

Revocation List) e la firma del Certificato della chiave (usato dalla CA).

• Algoritmo di firma del certificato. • Firma del certificato.

Le estensioni più comuni con le quali possiamo trovare un file in formato X.509 sono :

• .CER: certificato codificato con DER, a volte sequenze di certificati • .DER: certificato codificato con DER • .PEM: certificato codificato con Base64 (è un sistema di conversione da

formato ASCII a binario che usa 64 simboli), racchiuso tra “BEGIN CERTIFICATE” e “END CERTIFICATE”

• .P7B: vedi .P7C • .P7C: PKCS #7 (uno standard che descrive il formato dei certificati tramite

la definizione della sintassi generale da applicare ai dati che devono essere criptati).

• .PFX: Personal inFormation eXchange, ora superato da PKCS #12 • .P12: PKCS #12 (può contenere certificati e chiavi pubbliche e private, ed

è infatti usato per scambiarsi oggetti pubblici e privati, come le chiavi) I PKCS (Public Key Cryptography Standard) sono in realtà un insieme di standard sviluppati dai laboratori RSA per velocizzare la diffusione della crittografia a chiave pubblica. Abbiamo appena accennato a due di questi standard, PKCS #7 e PKCS #12, ma in realtà ne esistono molti altri, da PKCS #1 a PKCS #15, anche se in futuro potrebbero esserne creati degli altri. 3.2 Public Key Infrastructure Ora che abbiamo definito cosa è e come è composto un certificato digitale, possiamo parlare di PKI. Una Public Key Infrastructure è, se vogliamo darne una definizione semplice, la struttura composta da hardware, software, persone e procedure che serve per la

30

diffusione delle chiavi pubbliche in un contesto di crittografia a chiave asimmetrica. Ovviamente questa è solo una definizione generale, ma ogni tipo di PKI deve garantire 2 cose fondamentali:

• Certificazione • Validazione

Analizzeremo ora questi aspetti, discutendo sulle modalità con cui una PKI riesce a fornire tali servizi. 3.2.1 Certificazione Il problema della certificazione è essenzialmente quello presentato all’inizio del capitolo 3, e riguarda cioè la corrispondenza tra una chiave pubblica e un utente. Come già anticipato il modo di garantire tale corrispondenza è rappresentato dal certificato digitale, ma dovevamo ancora risolvere il problema della validità del certificato stesso. Introduciamo allora il concetto di Certification Authority come ente garante della validità di un certificato digitale. 3.2.1.1 Certification Authority Il compito di una CA è essenzialmente quello di emettere un certificato digitale, che certifichi il legame tra una persona fisica e una chiave pubblica. Naturalmente la CA deve essere sicura che la persona che richiede il certificato sia davvero chi dice di essere, ma analizzeremo il processo di emissione di un certificato in seguito. Prima di farlo dobbiamo infatti fare alcune precisazioni. Ogni volta che un certificato viene emesso, la CA lo firma digitalmente con la sua chiave privata, in modo che un utente sappia chi ha emesso tale certificato. É evidente allora che la Certification Authority deve essere una struttura di cui gli utenti hanno fiducia (da qui il termine terza parte fidata). Se infatti chiunque potesse svolgere la funzione di CA, e potesse dunque emettere certificati, il problema dell’autenticazione non sarebbe risolto. Per risolvere tale problema, si è introdotta una struttura gerarchica di CA. Questo significa che una CA (chiamiamola A) emette dei certificati firmandoli con la propria chiave privata, e per garantire che tale CA sia “fidata”, un’altra Certfification Authority (B), situata ad un “livello superiore” in una ipotetica struttura ad albero, ha emesso un certificato per A. Questo processo continua via via ricorsivamente fino ad arrivare a una Certification Authority universalmente riconosciuta detta IPRA (Internet Policy Certification Root), che è la radice di questa struttura ad albero, e che possiede un certificato firmato da essa stessa.

31

Figura 3.1: Gerarchia di CA

In figura, al livello sottostante l’IPRA, ci sono le PCA (Policy Certification Authority), che stabiliscono le proprie politiche di registrazione degli utenti e delle organizzazioni. Un arco indica che un nodo padre ha emesso un certificato per un nodo figlio. L’IPRA emette certificati solo per le PCA, mentre queste ultime emettono certificati per le varie Certification Authority, le quali a loro volta emettono certificati o per altre CA o per gli utenti finali. Un ulteriore elemento di tale struttura, è la “Root CA”; questa è la CA di cui un utente si fida direttamente, e non corrisponde per forza alla CA che gli ha emesso il certificato, potrebbe essere anche una CA a un livello superiore. Ipotizziamo ora di trovarci nella situazione rappresentata nella figura seguente.

Figura 3.2: Esempio di gerarchia di CA

32

In questa figura le foglie sono utenti mentre i nodi interni sono CA. Supponiamo ora che a riceva un messaggio firmato da n. Come può a essere sicuro dell’identità di n ? Innanzitutto a deve verificare, usando la chiave pubblica di n, che la firma del messaggio sia autentica, nel modo illustrato in figura 2.19. Fatto questo, a vede che la chiave pubblica di n è stata certificata come appartenente a n dalla CA L. Allora a verifica la firma di tale certificato (ricordiamo che ogni certificato è firmato con la chiave privata della CA che lo ha emesso) con la chiave pubblica di L. Se questo è andato a buon fine, siccome la chiave pubblica di L è in un certificato emesso da D, a deve verificare la firma di questo certificato con la chiave pubblica di D. In modo simile viene verificata l’autenticità dei certificati di D e di A. Ora, dato che il certificato di A è la radice dell’albero, a si fida del certificato di A, quindi di quello di D, quindi di quello di L e quindi di quello di n. Questo processo di verifica si chiama Certification Path Validation (verifica del percorso di certificazione), ed è il metodo con cui è finalmente possibile garantire l’autenticazione. Ci sono però ancora dei problemi da risolvere, ad esempio la gestione dei certificati non più validi, ma di questo parleremo poi. 3.2.1.2 Procedura di certificazione Analizziamo ora il metodo con cui un utente richiede ed ottiene un certificato da una Certification Authority. Supponiamo che Alice voglia ottenere un certificato digitale. Per prima cosa Alice genera una coppia di chiavi pubblica/privata, chiede alla Registration Authority (RA), che è una emanazione amministrativa della CA realizzata per alleggerirne il lavoro, di certificare la sua chiave pubblica.

Figura 3.3: Richiesta di certificato alla RA

33

Dopo aver identificato Alice in modo sicuro, per esempio richiedendo la carta di identità, ed aver verificato la corrispondenza delle coppia di chiavi asimmetriche, la RA chiede alla CA di generare un certificato per Alice e la sua chiave pubblica. Il certificato di Alice viene a questo punto firmato dalla CA con la sua chiave privata, o con il suo certificato digitale di Root CA, dato che Alice si dovrebbe fidare di tale CA (in quanto è stata scelta da Alice per la creazione del suo certificato).

Figura 3.4: Creazione del certificato da parte della CA

A questo punto la CA pubblicherà su un particolare server pubblico (Certificate Server) una lista dei certificati validi associati alla chiave pubblica corrispondente, così chiunque potrà verificare tramite il metodo del Certificate Validation Path descritto in precedenza se la chiave pubblica è davvero di Alice. Alice riceve infine dalla CA il proprio Certificato Digitale firmato e il Certificato della CA stessa.

Figura 3.5: Rilascio del certificato da parte della CA

34

3.2.2 Validazione I certificati, una volta emessi, sono validi, ma tale condizione può cambiare. Per esempio se il possessore del certificato perdesse la propria chiave privata, o peggio gli fosse sottratta, il certificato dovrebbe essere reso inattivo per ovvi motivi. Gli stati in cui si può trovare una certificato sono in generale:

• Valido • Revocato • Scaduto • Sospeso

In effetti solo i primi 2 stati sono previsti da ogni PKI. Un certificato potrebbe non essere più valido se le informazioni che contiene non sono più vere, o se come detto precedentemente è compromessa la segretezza della chiave privata associata alla chiave pubblica contenuta nel certificato stesso. Inoltre, nel caso esista un intervallo di validità per il certificato, se non è rispettato il certificato non è più valido ed è definito scaduto. Nel caso che sia verificata una delle prime 2 condizioni il certificato viene invece revocato. Infine si parla di certificato sospeso quando ci si trova ad esempio nella condizione di non essere sicuri se la sicurezza della chiave privata è stata compromessa; il certificato viene allora sospeso, e se alla fine la chiave privata era stata effettivamente acquisita da persone non autorizzate, il certificato diventa revocato. In caso contrario il certificato torna allo stato valido. Di tutto questo deve preoccuparsi la CA, pubblicando e aggiornando periodicamente nel Certificate Server, oltre alla lista dei certificati validi, altre 2 liste dette CRL (Certificate Revocation List) e CSL (Certificate Suspension List), firmate anche queste dalla CA, e liberamente consultabili. La prima contiene la lista dei certificati revocati, mentre la seconda quella dei certificati sospesi. Invece un certificato scaduto viene rimosso dalla lista dei certificati validi. Ora se un utente vuole verificare l’autenticità di una chiave pubblica, deve seguire il metodo descritto precedentemente con l’aggiunta però di verificare, ogni volta che esamina un certificato, che tale certificato non si trovi nella CRL o nella CSL del Certificate Server. Tutto questo presenta però 2 problemi: il primo è che le dimensioni delle CRL possono diventare eccessive (e di difficile consultazione per chi non dispone di un accesso veloce alla rete), il secondo è che se un certificato diventa non più valido al tempo t, ma l’aggiornamento della CRL avviene al tempo v, con v > t, il certificato stesso nell’intervallo v-t risulta essere valido anche se di fatto non è così. Per risolvere il primo problema di solito si suddivide la CRL secondo il motivo che ha portato alla revoca del certificato, così se ad esempio un utente vuole solo verificare che un certificato sia stato revocato perchè la chiave privata è compromessa, può limitarsi ad analizzare solo una parte della CRL. Un possibile rimedio per il secondo problema sta nell’utilizzare le cosiddette delta-CRL. Così, invece di pubblicare le CRL con una frequenza non molto alta, viene pubblicata prima una CRL e poi con frequenza abbastanza alta le delta-CRL, che sono di fatto degli aggiornamenti alla CRL contenenti i nuovi certificati revocati. Ovviamente verranno pubblicate ancora CRL, ma con meno frequenza.

35

Lo standard X.509 presenta un’alternativa all’uso delle CRL, chiamata OCSP (Online Certificate Status Protocol), che permette di verificare la validità in tempo reale di un certificato, evitando di scaricare l’intera CRL. Questo avviene in pratica sfruttando messaggi di tipo “request/response”, con cui i server OCSP informano il client sulla validità o meno del certificato. 3.3 X.500 e LDAP Abbiamo parlato finora della creazione e della distribuzione dei certificati. Per salvare le intestazioni dei certificati e le CRL si sono usati directory LDAP. LDAP, come X.500, è un protocollo per l’interrogazione e la modifica di servizi di directory, dove con “servizi di directory” si intende l’insieme dei programmi che servono a memorizzare informazioni su reti di computer e su risorse condivise disponibili tramite la rete. X.500 è uno standard ISO e si basa su DAP (Directory Access Protocol). Prevede la presenza dell’intero stack OSI, perché è un protocollo che lavora al livello delle applicazioni. Per questo motivo è stato introdotto LDAP (Lightweight Directory Access Protocol), che richiede il protocollo TCP/IP e non l’intero stack OSI, e risulta essere molto meno pesante e più semplice di X.500. Un entry, in un directory LDAP, è un insieme di attributi, e può essere individuato con il suo Distinguished Name (DN), per esempio “cn=Mario Bianchi, ou=people, dc=unipd, dc=it” Per ogni attributo di un entry possiamo avere più valori, e ognuno di questi attributi appartiene a una classe di oggetti, raggruppati in uno schema. Ogni elemento nel directory è associato a una o più classi di oggetti, che definiscono se un attributo sia opzionale o meno, e che tipo di informazioni questo contenga. I nomi degli attributi solitamente sono scelti per essere facilmente memorizzabili, per esempio "cn" per common name, o "mail" per un indirizzo e-mail. I valori degli attributi dipendono dal tipo, e la maggioranza dei valori non binari sono memorizzati in LDAP v3 (LDAP versione 3) come stringhe UTF-8. Per esempio, un attributo di tipo mail potrebbe contenere il valore "user@example.com", mentre un attributo "jpegPhoto" potrebbe contenere una fotografia nel formato (binario) JPEG. In un directory LDAP gli entry presentano una struttura gerarchica ad albero. L’entry che rappresenta il paese si trova alla radice dell’albero. Al di sotto di esso ci sono quelle che rappresentano stati e organizzazioni nazionali. Seguono poi altri tipi di entry che possono rappresentare organizzazioni, persone, documenti, o altro.

36

Figura 3.6: Struttura di un directory LDAP Per rappresentare l’albero può anche essere utilizzato lo schema del DNS. In questo caso avremo Figura 3.7: Struttura di un directory LDAP modello internet Per importare o esportare dati da server LDAP si usano i cosiddetti file in formato LDIF (LDAP Data Interchange Format): essi sono dei file ASCII con una forma simile alla seguente: [<id>] dn: <distinguished name> <tipoattr>: <valoreattr> <tipoattr>: <valoreattr> Un entry può contenere più coppie di tipo <tipoattr>: <valoreattr>; una riga bianca separa invece un entry dalla successiva.

37

Capitolo 4 Realizzazione In questo capitolo si parlerà dell’hardware e del software utilizzati per questa tesi, descrivendo caratteristiche e scopi di questi ultimi. Infine verrà realizzata una semplice guida all’installazione passo passo dei vari software, in modo che in un futuro, se si dovesse reinstallare il tutto, questo risulti essere semplice e immediato anche per chi non ha familiarità con l’ambiente Linux. 4.1 Hardware L’hardware utilizzato è un pc con le seguente caratteristiche:

• SISTEMA OPERATIVO: Linux Mandriva 2007 • PROCESSORE: Intel Pentium 4 1700 Mhz • RAM: 512 MB

Per quanto riguarda la configurazione di rete, il pc è connesso ad Internet tramite interfaccia ethernet e router. Seguiranno ora le impostazioni di rete usate.

• IP 147.162.96.24 • GATEWAY 147.162.96.254 • DNS 147.162.2.100 • SUBNET MASK 255.255.255.0 • NOME CORRISPONDENTE ALL’ IP pcsitr2.dei.unipd.it

4.2 Il software utilizzato Ora verrà fatta una panoramica sui vari software utilizzati; si ricorda che questi sono presenti nel dvd allegato alla tesi; per maggiori informazioni leggere il file readme.txt presente all’interno del dvd. 4.2.1 Java Il primo software che analizziamo è Java; i programmi principali utilizzati, come Ejbca, JBoss, Ant e Ldap Browser/Editor, sono infatti basati su questo potente linguaggio di programmazione, ed è quindi un componente indispensabile per questo lavoro. Non ci sarebbe neppure bisogno di parlare di Java, dato il grande successo e la grande diffusione che ha avuto, ma diamo comunque qualche informazione generale.

38

Java è un linguaggio di programmazione orientato agli oggetti, come C++, è stato creato dalla Sun Microsystem ed è stato annunciato ufficialmente il 23 maggio 1985; dal 13 novembre 2006 è disponibile sotto licenza GPL. Ci sono però molte differenze tra Java e il C/C++ (il linguaggio con cui viene più spesso fatto un paragone). Innanzitutto Java non è un linguaggio compilato in codice macchina, come C/C++, ma è un linguaggio interpretato. Questo significa in poche parole che mentre il file sorgente C/C++, una volta compilato, produce un eseguibile per uno specifico processore, in Java ogni volta che si vuole eseguire il programma, esso viene compilato producendo il cosiddetto “bytecode” (istruzioni per la macchina virtuale) ed eseguito dalla JVM (Java Virtual Machine), dopo aver caricato anche i file di bytecode dalla libreria, quando necessari. Questo ha un notevole vantaggio rispetto a C/C++: infatti il programmatore può scrivere codice indipendentemente dal sistema operativo in cui il programma dovrà funzionare, perché la JVM (disponibile per i diversi sistemi operativi) crea un ambiente omogeneo che nasconde le specifiche del sistema operativo al programma stesso. Questo fatto è stato pubblicizzato dalla Sun con il noto slogan write once, run everywhere

cioè "scrivi una volta, esegui dappertutto". In effetti leggendo questa frase sembrerebbe che la portabilità dei programmi Java sia assoluta, anche se in pratica le diverse JVM non sono tutte compatibili perfettamente tra di loro, soprattutto le ultime versioni. Un altro aspetto molto importante di Java sono le API (Application Programming Interface), cioè un insieme di procedure che permettono al programmatore di realizzare un’astrazione dall’hardware e dal software di basso livello, in modo che non debba scrivere ogni funzione da zero: se per esempio in un programma servisse la funzione “radice quadrata”, non dovrà essere il programmatore a scriverla, ma qualcuno lo ha già fatto, preoccupandosi dell’implementazione a basso livello. Il linguaggio Java e le API costituiscono la cosiddetta “piattaforma Java”. Sono al momento disponibili molte JVM, sia per i vari sistemi operativi sia anche per i cellulari e PDA. Di solito Java viene distribuito in 2 versioni. La prima si chiama JRE (Java Runtime Environment) e comprende la virtual machine e le librerie di classi, cioè il necessario per eseguire programmi Java. La seconda è la JDK (Java Development Kit), che oltre agli strumenti della JRE mette a disposizione anche il compilatore, ed è quindi rivolta ai programmatori. L’ultima versione di JDK è la 1.6 update 2, ma noi abbiamo usato la 1.5 update 12, dato che non era garantita la compatibilità dei programmi usati con la versione 1.6.

Figura 4.1: Varie versioni del famoso logo di Java

39

4.2.2 Ant Ant è un progetto Apache, open source, rilasciato sotto licenza Apache e scritto in Java. Il suo utilizzo è simile a quello del comando “make” dei sistemi Unix, ma molto più semplice da usare, ed esegue tutti gli step che servono per ottenere il prodotto finale di un progetto, anche di grandi dimensioni, a partire dal codice sorgente. Con Ant si può compilare, generare documentazione in formato javadoc, realizzare file .jar, e altre funzioni, tutto in modo automatico e semplice. Questo programma si usa da linea di comando e richiede la presenza nel progetto del file build.xml, all’interno del quale Ant legge i comandi che deve eseguire. Ad esempio Ejbca, programma di cui parleremo dopo, contiene proprio tale file nella sua cartella, infatti lo abbiamo installato con Ant. All’interno del file build.xml sono contenuti i vari task, cioè i vari compiti che Ant deve svolgere, che possono essere svariati, dalla semplice creazione e rimozione di directory alla copia di file tramite FTP. L’ultima versione presente, quella da noi usata, è la 1.7.0.

Figura 4.2: pagina principale del sito di Ant

40

4.2.3 JBoss JBoss è un Application Server multipiattaforma, open source e basato su tecnologia Java. Da aprile 2006 JBoss è entrato a far parte di Red Hat. Ma che cosa significa “Application Server” ? Un Application Server, se vogliamo darne una definizione semplice, è un software utilizzato per l’esecuzione, la gestione e lo sviluppo di applicazioni server (come Ejbca) in contesto distribuito. Elenchiamo di seguito alcune delle caratteristiche principali di un Application Server:

• Supporto a vari linguaggi di programmazione per la scrittura delle applicazioni.

• Sistema affidabile per il controllo delle transazioni. • Scalabilità, ovvero possibilità di gestire anche un numero elevato di utenti

che accedono in modo concorrente, suddividendo le applicazioni su più di un sistema, utilizzando sistemi multiprocessore.

• Prestazioni elevate, grazie al supporto al multithreading e al bilanciamento dinamico dei carichi di lavoro (load balancing).

• Estensibilità, in quanto sull’Application Server possono essere caricate dinamicamente molte applicazioni e possono essere estese le loro funzionalità.

• Robustezza, sia perché il bilanciamento dinamico dei carichi di lavoro garantisce un alta disponibilità del sistema, sia perché i vari componenti del server possono essere riconfigurati, aggiunti o rimossi senza dover sospendere i servizi che in quel momento sono attivi.

• Sicurezza, perché vengono implementati algoritmi molto potenti, come quelli definiti dal protocollo SSL, per la comunicazione tra client e server.

La versione da noi utlizzata è la 4.0.5. 4.2.4 Ejbca Ejbca è una potente Certification Authority basata su tecnologia Java, che sfrutta le funzionalità dell’Application Server JBoss per poter funzionare al meglio. Ejbca può realizzare una PKI completa, con funzioni di emissione e revoca dei certificati. Elenchiamo di seguito alcune delle caratteristiche principali di questo software

• Architettura flessibile. • Possibilità di avere più CA all’interno di una singola istanza di Ejbca. • Supporto per RSA fino a 4096 bit. • Supporto per algoritmi hash come SHA-1, SHA-256 e MD5. • I certificati Server e Client possono essere esportati in vari formati tra i

quali PKCS12, JKS o PEM. • Browser enrollment (registrazione) con Netscape, Mozilla, IE. • Supporto a token e smart card.

41

• Possibilità di gestire livelli diversi di amministrazione corrispondenti a privilegi differenti.

• Supporto allo standard X.509. • Supporto alla tecnologia OCSP (Online Certificate Status Protocol). • Gestione e creazione di CRL (Certificate Revocation List). • Integrazione con LDAP per salvataggio dei certificati. • Supporto a vari tipi di database come MySQL, PostgreSQL, Oracle,

Microsoft SQL-2000.

Figura 4.3: Architettura di Ejbca

Analizziamo ora brevemente il funzionamento di Ejbca. Per emettere un certificato sono necessarie 3 fasi:

• Creazione della Certificate Signing Request (CSR) • Identificazione dell’utente • Emissione del certificato

Figura 4.4: Riassunto del funzionamento di Ejbca

42

Una volta aperta l’interfaccia Web (come verrà spiegato nella guida al capitolo 4.3.5), l’utente crea la CSR e una coppia di chiavi (operazione possibile anche con OpenSSL, come spiegato nel capitolo 4.3.6.1); si reca poi dalla CA per l’identificazione e, una volta fatto questo, viene emesso il certificato vero e proprio. Ovviamente il certificato viene emesso usando una connessione sicura, sfruttando SSL per esempio; la stessa cosa avviene per un eventuale aggiornamento del certificato. Infine i certificati emessi e revocati sono memorizzati in un albero LDAP. La versione usata da noi di Ejbca è la 3.4.3, anche se al momento è disponibile la 3.5.1.

Figura 4.5: Evoluzione di Ejbca

4.2.5 OpenSSL OpenSSL è un progetto open source dei protocolli SSL e TSL, basato sulle librerie SSLeay di Eric Young e Tim Hudson. Le librerie di OpenSSL, scritte in C, forniscono molte funzioni crittografiche, ed è inoltre possibile accedere a queste funzioni da vari linguaggi di programmazione. OpenSSL è disponibile per la maggior parte dei sistemi operativi, come Unix, Linux e Windows, tanto per citarne alcuni. Negli Stati Uniti l’Open Source Software Institute, una organizzazione senza fini di lucro composta da rappresentanti del governo, del mondo accademico e dell’industria, sta tentando di far ottenere a OpenSSL la conformità FIPS 140-2 (Federal Information Processing Standard), uno standard per la sicurezza informatica. Spieghiamo ora brevemente cosa sono i protocolli SSL/TSL.

43

Il protocollo SSL (Secure Socket Layer) è stato sviluppato da Nestscape Communications Corporations, e la versione 3.0 è la base del protocollo TSL (Transport Layer Security), definito nella RFC 2246. Lo scopo di questi protocolli è di impedire, utilizzando funzioni crittografiche, la manomissione e la falsificazione dei dati che viaggiano lungo la rete Internet durante comunicazioni client/server, come per esempio durante l’invio di un messaggio di posta elettronica. In questo modo sono garantiti i 3 servizi fondamentali per la comunicazione sicura in rete:

• Autenticazione, ovvero la verifica delle identità delle entità coinvolte nella comunicazione.

• Privacy, ovvero la prevenzione della diffusione non autorizzata di informazioni.

• Affidabilità, cioè la garanzia che il messaggio non venga alterato durante la comunicazione.

Tutto questo è possibile grazie ad algoritmi di crittografia a chiave pubblica (come RSA), privata (come DES, 3-DES, AES), e di Message Digest (come MD5). Infatti le fasi iniziali richieste dai protocolli SSL/TSL sono:

• Le due parti coinvolte nella comunicazione devono concordare l’algoritmo crittografico da utilizzare.

• Scambio delle chiavi segrete tramite cifratura a chiave pubblica e identificazione degli utenti usando i certificati.

• Cifratura del traffico con crittografia a chiave privata (la chiave usata è quella concordata e scambiata precedentemente).

Figura 4.6: Protocollo SSL nello stack di protocolli OSI e Internet

44

Il protocollo SSL è stato pensato per lavorare sotto i protocolli applicativi come HTTP ma sopra il protocollo TCP, così da rendere sicure le applicazioni che si basano su TCP. In riferimento ad HTTP, se questo protocollo si appoggia su SSL/TSL diventa HTTPS, e questa è garanzia di comunicazioni sicure e crittografate. 4.2.6 Berkeley DB Berkeley DB è un database open source della Sleepycat Software molto famoso, disponibile per vari sistemi operativi, come Windows, Linux e MacOs X. Questo Database è un prerequisito per l’installazione di OpenLDAP, e la versione da noi utilizzata è la 4.6.18. La qualità del software è dimostrata dal fatto che nel febbraio del 2007 Sleepycat è stata acquisita da Oracle, che è quindi diventata proprietaria di Berkeley DB. Le caratteristiche principali di Berkeley DB sono le seguenti:

• Non serve la figura del DBA (Data Base Administrator). • Basso consumo di memoria. • Compatibilità con applicazioni sviluppate con i più diffusi linguaggi di

programmazione, come C/C++, Java, PHP, Perl ed altri. • Alta affidabilità. • Supporto alle transazioni ACID (garantisce quindi le funzioni di Atomicità,

Isolamento, Persistenza e Consistenza). • Supporto ad accesso concorrente di molti utenti al database. • Configurabile e poco complesso. • Funzioni di backup a “freddo” e a “caldo” (cioè con sistema non

funzionante ma anche mentre è in funzione). • Supporto di indicizzazione a più livelli con strutture dati avanzate come i

BTree (Alberi B) per garantire prestazioni migliori. • Supporto a funzioni di crittografia come AES.

Figura 4.7: Schema che riassume la struttura di Berkeley DB

45

4.2.7 Cyrus SASL Cyrus SASL è un software che implementa SASL (Simple Authentication and Security Layer), un metodo per aggiungere il supporto per l’autenticazione ai protocolli internet. Esso specifica un protocollo di domanda-risposta in cui i dati sono scambiati fra il client e il server per gli scopi dell'autenticazione e di instaurazione di uno strato di sicurezza su cui effettuare una comunicazione successiva. La prima versione di SASL è collegata al RFC 2222, anche se è stata superata da RFC 4422. Nel nostro caso abbiamo usato SASL in combinazione con OpenLDAP. In questo modo LDAP può supportare qualunque tipo di autenticazione tra client e server LDAP. Questo aggiunge un ulteriore livello di sicurezza al nostro sistema. I componenti installati con SASL sono:

• saslauthd: è il server di autenticazione SASL. • sasldblistusers2: è utilizzato per fare un elenco degli utenti nel database

delle password SASL. • saslpasswd2: serve per impostare e cancellare una password utente SASL. • libsasl2.so: è una libreria di autenticazione di uso generale per applicazioni

client e server. Nella guida verrà spiegato meglio come utilizzare i servizi offerti da SASL, anche in relazione all’utilizzo del software con OpenLDAP.

Figura 4.8: Il funzionamento di SASL con OpenLDAP

46

4.2.8 OpenLDAP OpenLDAP è un prodotto open source che implementa le specifiche dettate dal protocollo LDAP presentato nel capitolo 3. Tra le caratteristiche più importanti ricordiamo

• Supporto alla distribuzione dei carichi di lavoro. • Tempi di risposta brevi. • Supporto alla replica delle informazioni. • Supporto a LDAP v.3. • Supporto a IP v.6. • Supporto a LDIF v.1 (LDAP Data Interchange Format).

Analizziamo di seguito la struttura dei file di configurazione e dei componenti di OpenLDAP; nella guida verrà discusso più in dettaglio questo argomento. 4.2.8.1 I file di OpenLDAP Nel directory /usr/local/etc/openldap, una volta installato il software, dovrebbero trovarsi i seguenti file:

• ldap.conf • ldap.conf.default • slapd.conf • slapd.conf.conf • DB_CONFIG.example

e la cartella “schema”. Il file slapd.conf è quello che contiene le informazioni sulla configurazione del server LDAP chiamato “slapd”, di cui parleremo a breve. Nella guida verrà spiegato come adattarlo per il nostro sistema. Nel directory “schema” ci sono dei file con estensione .schema, che contengono le definizioni di objectclass; queste, oltre a descrivere il tipo di attributi di una entry, determinano anche se essi sono obbligatori o meno. È qui che metteremo il file di configurazione certificate.schema che contiene la definizione della struttura dei certificati della nostra CA. 4.2.8.2 Slapd e Slurpd OpenLDAP si basa sul funzionamento di 2 demoni: slapd e slurpd, collocati di solito nella cartella /usr/local/libexec. Il demone slapd è il demone Stand-Alone di LDAP e serve per eseguire OpenLDAP; in pratica esso è il server che gestisce le richieste dei client del servizio. Slurpd invece serve per garantire la consistenza delle informazioni tra le istanze di slapd che partecipano al servizio (la consistenza è garantita mediante replica e scambio di messaggi); questo è indispensabile solo se si hanno più server LDAP nella rete, nel qual caso è slurp a tenere sincronizzati i directory LDAP.

47

Figura 4.9: Interazione tra slapd e slurpd

4.2.8.3 Strumenti e librerie di OpenLDAP Nelle cartelle /usr/local/bin e /usr/local/sbin sono presenti alcune utility che permettono di modificare aggiungere e cancellare entry LDAP da riga di comando. Vediamo quali sono: File contenuti in /usr/local/bin

• ldapadd: apre una connessione con un server LDAP, collega e aggiunge voci

• ldapcompare: apre una connessione con un server LDAP, collega e compara voci

• ldapdelete: apre una connessione con un server LDAP, collega e cancella una o più voci

• ldapmodify: apre una connessione con un server LDAP, collega e modifica una o più voci

• ldapmodrdn: apre una connessione con un server LDAP, collega e modifica l’RDN delle entrate

• ldappasswd: apre una connessione con un server LDAP, collega ed esegue ricerche utilizzando parametri specifici

• ldapwhoami: apre una connessione con un server LDAP, collega e visualizza informazioni whoami

48

File contenuti in /usr/local/sbin

• slapadd: serve per aggiungere campi specifici in formato LDIF in un database LDAP

• slapcat: genera output in formato LDIF partendo dal contenuto di un database LDAP

• slapdn: verifica una lista di stringhe DN basate su schema syntax • slapindex: genera indici slapd basandosi sul contenuto corrente del

database • slappasswd: utilità di password di OpenLDAP • slaptest: verifica lo stato di slapd.conf

Inoltre nella cartella /usr/local/lib sono presenti le librerie liblber e libldap, che supportano i programmi LDAP e forniscono funzionalità ad altri programmi che interagiscono con OpenLDAP.

4.2.9 Ldap Browser/Editor Questo programma scritto in java permette di avere una visione gerarchica degli oggetti memorizzati in un directory LDAP, e consente inoltre se si effettua l’accesso come “Directory Manager”, di modificare il contenuto del directory LDAP. In questo programma gli oggetti LDAP sono visualizzati come alberi mentre gli attributi come tabelle. Per una guida completa vedere il dvd allegato alla tesi o il sito Internet http://www-unix.mcs.anl.gov/~gawor/ldap/usage.html. Le principali caratteristiche di Ldap Browser/Editor sono:

• Integrazione con SSL. • Supporto all’importazione/esportazione di file in formato LDIF. • Supporto al “drag and drop”. • Possibilità di usare programmi esterni per vedere immagini, certificati,

password. • Supporto alle applet. • Possibilità di modifica degli attributi. • Facilità di utilizzo.

Ecco perché si è scelto di usare questo software, che rende molto più comprensibile la struttura dei directory LDAP di quanto si possa ottenere dalla semplice shell.

49

Figura 4.10: Esempio di schermata di Ldap Browser / Editor

4.3 Guida all’installazione Questo capitolo è molto importante soprattutto per chi dovesse riprendere in mano questo lavoro, perché permette di riuscire in poco tempo a installare e configurare il software utilizzato per realizzare la Certification Authority, di cui si è parlato nel capitolo precedente. Si suppone che sul pc sia installato Linux Mandriva 2007, anche se un'altra distribuzione di Linux andrebbe bene lo stesso; di seguito verrà spiegato come installare i vari programmi utilizzati. Si suppone inoltre che la password di root sia impostata a “biometria”; questa sarà la password usata anche per tutti gli altri programmi che richiedono di definire una password, ma ovviamente nulla vieta di utilizzarne altre. Come utente “normale” è invece stato scelto il nome di certification_authority in fase di installazione di Linux, senza definire alcuna password. Si ricorda inoltre che tutti i programmi utilizzati e le relative guide sono presenti nel dvd allegato alla tesi. 4.3.1 Login Abbiamo detto prima di aver creato in fase di installazione l’utente “root” con password “biometria” e l’utente “certification_authority” senza password. All’avvio del pc apparirà una schermata come questa

50

Figura 4.11: Login

Si inserisca su nome utente “certification_authority” e si prema invio. Sebbene molte operazioni di installazione vengano fatte come utente “root”, non è possibile effettuare il login come “root”; ecco perché dobbiamo entrare come utente “certification_authority”. Si dovrebbe ottenere alla fine qualcosa di simile a questo:

Figura 4.12: Schermata iniziale di avvio

51

4.3.2 Installazione di Java Dal momento che i vari programmi come JBoss ed Ejbca necessitano dell’ambiente Java per funzionare, la prima cosa da installare è il java development kit (jdk) che si può trovare su http://java.sun.com/javase/downloads/index_jdk5.jsp. La versione utilizzata è la 1.5.0 update 12, in quanto per la versione 1.6 non era garantita la compatibilità con i programmi usati. Una volta scaricato il file per Linux, che dovrebbe chiamarsi jdk-1_5_0_12-linux-i586.bin, copiamolo nella cartella /home/certification_authority (accessibile dal desktop con doppio clic sull’icona Home)

Figura 4.13: Cartella Home

A questo punto siamo pronti per installare il programma. Si potrebbe fare doppio clic sopra l’icona del file come in Windows ma utilizziamo la shell per installarlo. Clicchiamo sulla stellina gialla in basso a sinistra, andiamo su Sistema, Terminali, e clicchiamo su Konsole; si aprirà una finestra stile dos come questa:

52

Figura 4.14: Shell Bash

Ora siamo nella cartella home/certification_authority, dove c’è il file jdk-1_5_0_12-linux-i586.bin che dobbiamo installare. Scriviamo allora il comando ./jdk-1_5_0_12-linux-i586.bin come in figura. (Per non scrivere tutto il nome del file basta scrivere la prima parte del nome, fino a che tale parte non basti a identificare in modo univoco il file, e poi premere tab, e il nome verrà completato automaticamente)

Figura 4.15: Comando di installazione di Linux

53

Dopo aver premuto invio apparirà del testo che faremo scorrere con invio e una volta terminato alla domanda che apparirà rispondiamo yes e clicchiamo invio. Inizierà allora la decompressione dei file e si dovrebbe arrivare a breve a una schermata come questa

Figura 4.16: Esecuzione terminata del comando di fig. 4.13

A questo punto possiamo andare sulla cartella home/certification_authority ed eliminare il file jdk-1_5_0_12-linux-i586.bin. Vedremo inoltre che è apparsa la cartella jdk1.5.0_12 nella cartella home/certification_authority. Qui è dove è installato Java. Arrivati a questo punto l’installazione di Java non è però completa: infatti per il corretto funzionamento di Ejbca, che utilizza password più lunghe di 7 caratteri e potenti funzioni crittografiche, serve il componente “Unlimited Strenght Jurisdiction Policy Files”, scaricabile anche questo dal sito http://java.sun.com/javase/downloads/index_jdk5.jsp. Il file, dal nome jce_policy-1_5_0.zip, copiamolo nella solita cartella home/certification_authority. Fatto ciò apriamo una shell come fatto in precedenza, (si apre già in automatico nella cartella home/certification_authority), e da qui diamo il comando unzip jce_policy-1.5.0.zip

54

Figura 4.17: Comando di decompressione del file zip Alla pressione di invio, dopo alcuni istanti la decompressione dovrebbe essere avvenuta. Chiudiamo la shell e nella cartella home/certification_authority dovremmo avere qualcosa di simile a questo

Figura 4.18: Risultato della decompressione del file

La cartella jce contiene i file decompressi. A questo punto entriamo nella cartella jce, copiamo i 2 file local_policy.jar e US_export_policy.jar. Ora entriamo nella cartella jdk1.5.0_12 situata in home/certification_authority, andiamo in jre, poi in lib e infine nella cartella security. Qui troveremo 2 file con lo stesso nome di quelli che abbiamo copiato.

55

Come suggerisce il file readme della guida della “Unlimited Strenght Jurisdiction Policy Files”, non sovrascriviamo i file presenti con quelli nuovi, perché in futuro potrebbe essere necessario riusarli. Allora rinominiamo i 2 file presenti aggiungendo l’estensione.old, e poi copiamo i file precedentemente selezionati dalla cartella jce. Dovremmo ottenere qualcosa di simile a questo

Figura 4.19: Applicazione della patch per supporto a funzioni

crittografiche in Java

A questo punto possiamo tornare nella cartella home/certification_authority ed eliminare il file jce_policy-1_5_0.zip e la cartella jce. Ora dobbiamo far sapere al sistema dove abbiamo installato Java. Per farlo dobbiamo aggiungere alcune righe di testo ad un file di configurazione della shell. Apriamo una shell e scriviamo su. Ci verrà richiesta la password; scriviamo biometria e dopo aver premuto invio saremo diventati il superutente “root”. Questo è indispensabile per avere i privilegi occorrenti a modificare il file di configurazione della shell. Diamo il comando cd /etc per entrare nella cartella contenente il file di configurazione. Ora scriviamo kwrite bashrc e dopo alcuni messaggi dovrebbe aprirsi il file bashrc come in figura.

56

Figura 4.20: contenuto del file bashrc Portiamoci alla fine del file ed aggiungiamo le seguenti righe di codice export JAVA_HOME=/home/certification_authority/jdk1.5.0_12 export PATH=$PATH:$JAVA_HOME/bin

Figura 4.21: Il file bashrc modificato con il Path di Java

57

A questo punto chiudiamo il file e alla richiesta clicchiamo su salva. Chiudiamo la shell per permettere che i cambiamenti vengano attivati e poi apriamo una nuova shell. Scriviamo java e alla pressione di invio dovrebbe apparire una schermata simile a questa

Figura 4.22: Esecuzione del comando java

Prima di modificare il file avremmo ottenuto invece l’errore command not found. Per vedere se tutto è ok diventiamo utente root come fatto in precedenza (scrivendo su e la password) e poi diamo il comando java; se otteniamo una schermata simile a quella ottenuta poc’anzi, allora tutto è configurato esattamente. 4.3.3 Installazione di Ant Arrivati a questo punto Java è installato, ma prima di procedere all’installazione dei programmi veri e proprio è necessario installare Ant. Questo è un programma gratuito scaricabile da http://ant.apache.org e servirà per installare Ejbca successivamente. Il file di installazione si chiama apache-ant-1.7.0-bin.zip. Copiamo questo file nella cartella home/certification_authority, apriamo la shell e digitiamo il comando unzip apache-ant-1.7.0-bin.zip Dopo alcuni istanti la decompressione dovrebbe essere terminata e dovrebbe essere presente nella cartella home/certification_authority la cartella apache-ant-1.7.0

58

Figura 4.23: Decompressione di Ant A questo punto possiamo eliminare il file apache-ant-1.7.0-bin.zip dalla cartella home/certification_authority. Ora, come fatto per Java, dobbiamo dire al sistema dove è installato Ant. Come fatto precedentemente, avviamo una shell, diventiamo utente “root”, e scriviamo cd /etc e dopo aver premuto invio scriviamo kwrite bashrc e aggiungiamo alla fine del file le seguenti righe di codice export ANT_HOME=/home/certification_authority/apache-ant-1.7.0 export PATH=$PATH:$ANT_HOME/bin

59

Figura 4.24: Il file bashrc modificato con il Path di Ant A questo punto chiudiamo e salviamo il file. Chiudiamo anche la shell e apriamone un'altra; scrivendo ant, sia come utente root sia come utente certification_authority, dovrebbe comparire una schermata simile a questa

Figura 4.25: Esecuzione del comando ant

Questo vuol dire che Ant è stato installato correttamente.

60

4.3.4 Installazione di JBoss Siamo arrivati a questo punto all’installazione di JBoss, l’application server su cui si appoggia Ejbca per funzionare. Prima di tutto scarichiamo dal sito http://labs.jboss.com/jemsinstaller/downloads il file jems-installer-1.2.0.GA.jar, che contiene JBoss versione 4.0.5. Copiamo il file nella cartella home/certification_authority, poi apriamo una shell, e dopo essere diventati l’utente “root” scriviamo java –jar jems-installer-1.2.0.GA.jar alla pressione di Invio dovrebbe apparire qualcosa simile a questo

Figura 4.26: Installazione di JBoss 1/16 Clicchiamo su ok e apparirà la schermata seguente

61

Figura 4.27: Installazione di JBoss 2/16 Clicchiamo ora su Next per ottenere

Figura 4.28: Installazione di JBoss 3/16

Ancora su Next e dovremmo vedere qualcosa di simile a

62

Figura 4.29: Installazione di JBoss 4/16

A questo punto selezioniamo “I accept the terms of this license agreement.”, e poi clicchiamo ancora su Next

Figura 4.30: Installazione di JBoss 5/16 Ora ci verrà chiesto dove installare JBoss. Scriviamo /home/certification_authority/jboss-4.0.5.GA

63

Fatto questo clicchiamo su Next Alla domanda che appare, che ci informa che il directory non esiste, clicchiamo su ok, e così la cartella verrà creata.

Figura 4.31: Installazione di JBoss 6/16

Ora lasciamo pure la selezione su “default” e clicchiamo Next

Figura 4.32: Installazione di JBoss 7/16

64

Clicchiamo ancora Next senza modificare nulla per ottenere la seguente schermata

Figura 4.33: Installazione di JBoss 8/16

Qui selezioniamo Advanced e proseguiamo con Next Figura 4.34: Installazione di JBoss 9/16

65

Ora lasciamo il nome “default” e proseguiamo con Next

Figura 4.35: Installazione di JBoss 10/16 Lasciamo “default” e clicchiamo su Next Figura 4.36: Installazione di JBoss 11/16

66

Ora lasciamo deselezionata la casella e premiamo Next per arrivare a

Figura 4.37: Installazione di JBoss 12/16

Qui impostiamo nome utente e password a “biometria” e poi clicchiamo Next Figura 4.38: Installazione di JBoss 13/16

67

Ora ancora Next e aspettiamo che l’installazione termini Figura 4.39: Installazione di JBoss 14/16

Ora che l’installazione è terminata clicchiamo su Next ancora per ottenere Figura 4.40: Installazione di JBoss 15/16

Clicchiamo su Done e dovremmo tornare alla shell

68

Figura 4.41: Installazione di JBoss 16/16

Possiamo adesso eliminare il file jems-installer-1.2.0.GA.jar contenuto nella cartella home/certification_authority. Vedremo inoltre che in questa cartella è comparsa la nuova cartella jboss-4.0.5.GA. Ora, come per Java e Ant, dobbiamo dire al sistema dove è installato JBoss. Apriamo come fatto precedentemente il file /etc/bashrc con i privilegi di utente “root” usando kwrite ed aggiungiamo alla fine del file le righe export JBOSS_HOME=/home/certification_authority/jboss-4.0.5.GA export PATH=$PATH:$JBOSS_HOME/bin

Figura 4.42: Il file bashrc modificato con il Path di JBoss

69

Salviamo il file e chiudiamo la shell per rendere effettivi i cambiamenti. Per testare se la nostra installazione di JBoss è andata a buon fine, apriamo la shell, diventiamo utente “root” e poi scriviamo cd jboss-4.0.5.GA/bin dopo aver premuto invio scriviamo ./run.sh

Figura 4.43: Comando di avvio di JBoss

A questo punto appariranno alcuni messaggi e dopo un po’ dovremmo arrivare a una schermata simile alla seguente, dove si dice come ultima cosa “Started in” seguito dal tempo impiegato all’application server per partire.

70

Figura 4.44: Avvio di JBoss effettuato

Ora non chiudiamo la shell, e apriamo un web browser, come Mozilla Firefox, oppure Konqueror. Nella barra degli indirizzi scriviamo http://localhost:8080 e dovrebbe apparire una schermata di questo tipo

Figura 4.45: Schermata principale di JBoss

71

Cliccando per esempio su JBoss Web Console ed inserendo come nome utente e password “biometria” dovrebbe aprirsi una schermata di questo tipo

Figura 4.46: Web Console di JBoss

Che conferma l’installazione corretta di JBoss. Se il pc in questione è connesso alla rete, e da un altro pc su un browser digitiamo il suo indirizzo IP seguito da :8080, accediamo alla stessa pagina. Un esempio è il seguente; si nota infatti che abbiamo avuto accesso alla stessa schermata di prima da un altro pc specificando l’indirizzo IP del pc dove è installato JBoss, nel nostro caso 147.162.96.24

Figura 4.47: Accesso a JBoss da un pc remoto

A questo punto torniamo alla shell che avevamo lasciato aperta e premendo Control+C terminiamo JBoss.

72

4.3.5 Installazione di Ejbca A questo punto siamo pronti per l’installazione della Certification Authority Ejbca. Scarichiamo dal sito http://ejbca.sourceforge.net Ejbca (il link esatto è http://sourceforge.net/project/showfiles.php?group_id=39716&package_id=108797 ). La versione utilizzata è la 3.4.3, corrispondente al file ejbca3_4_3.zip. Ora apriamo una shell, e dal momento che siamo in automatico nella cartella /home/certification_authority, possiamo dare il comando unzip ejbca.3_4_3.zip fatto questo verrà creata nella cartella /home/certification_authority la cartella ejbca_3_4_3. A questo punto possiamo anche eliminare il file ejbca_3_4_3.zip Ora andiamo nella cartella /home/certification_authority/ejbca_3_4_3/conf, ed apriamo il file ejbca.properties.sample e modifichiamolo come segue (di seguito verrà riportato il file con in grassetto le modifiche apportate; il file è presente nel dvd allegato alla tesi comunque) # # $Id: ejbca.properties.sample,v 1.17.2.2 2007/03/28 10:32:35 jbagnert Exp $ # # This is a sample file to override properties used # during development (or deployment) of EJBCA # # You should copy and rename this file to ejbca.properties # and customize at will. # # Which application server is used? # Possible values: jboss, glassfish, weblogic # Default jboss #appserver.type=jboss # Application server home directory used during development # Default: $APPSRV_HOME or $JBOSS_HOME #appserver.home=/home/jboss/jboss-4.0.5.GA #appserver.home=${env.APPSRV_HOME} # which compiler to use # default: javac #build.compiler=jikes # which java version to use 14 for jdk 1.4, 15 for jdk 1.5 and jdk 6 (note use 15 for jdk6 as well) # default: 15 #java.ver=15 # ------------ Basic CA configuration --------------------- # When upgrading, the important options are: # - ca.keystorepass # - ca.ocspkeystorepass # This installation will create a first administrative CA. This CA will be used to create the first

73

# superadministrator and for the SSL server certificate of administrative web server. # When the administrative web server have been setup you can create other CA:s and administrators. # This is only used for administrative purposes, # Enter a short name for the CA. ca.name=AdminCA1 # The Distinguished Name of the CA. # This is used in the CA certificate to distinguish the CA. ca.dn=CN=AdminCA1,O=EJBCA Sample,C=SE # The keysize in bits of the CA, only digits. ca.keysize=1024 # The keytype, can be RSA or ECDSA ca.keytype=RSA # The validity in days for the CA, only digits. ca.validity=3650 # The policy id of the CA. Policy id determines which PKI policy the CA uses. # Type your policy id or use '2.5.29.32.0' for 'any policy' (rfc3280) or 'null' for no policy at all. ca.policy=null # This password is used internally to protect CA keystores in database (i.e. the CAs private key). # foo123 is to keep compatibility with default installations of EJBCA 3.0, please change this if possible # If upgrading from EJBCA 3.0.x, you should take this value from src/ca/ca/META-INF/ejb-jar.xml -> keyStorePass. # The default value is the same for convenience. ca.keystorepass=biometria #ca.keystorepass=!secret! # Password user to protect OCSP keystores in the database (CAs OCSP signer certificate). # If upgrading from EJBCA 3.0.x, you should take this value from src/ca/ca/META-INF/ejb-jar.xml -> OCSPKeyStorePass. # The default value is the same for convenience. ca.ocspkeystorepass=biometria #ca.ocspkeystorepass=ocsp!secret! # Password user to protect XKMS keystores in the database (CAs XKMS signer/enc certificate). # The default value is the same for convenience. ca.xkmskeystorepass=biometria # Password user to protect CMS keystores in the database (CAs CMS signer/enc certificate). # The default value is the same for convenience. ca.cmskeystorepass=biometria # ------------- Approval configuration ------------------------ # Settings working as default values in the approval functionality # # Default request validity in seconds # Default : 28800 (8 Hours) #approval.defaultrequestvalidity=28800 # Default approval validity (how long an approved request should stay valid) # Default : 28800 (8 Hours) #approval.defaultapprovalvalidity=28800 # Setting excluding som classes from approval. When one of the classes in this list calls a method that normally

74

# required approval, the call is immediately allowed, bypassing the approval mechanism. The list is comma separated. # Example: org.ejbca.extra.caservice.ExtRACAProcess # Default : empty #approval.excludedClasses= # ------------ CRL Creation service configuration --------------------- # # Enable this (set to true) if you want to deploy the create CRL service MBean for JBoss. # There are several ways to automatically create CRLs, see the section "CRL generation" in the User's Guide. # Default: false #createcrl.service.enabled=false # ------------ Log4j logging configuration --------------------- # # Enable this by setting it to a log4j.xml configuration file configuring the logging for EJBCA. # Not needed for JBoss, that configures log4j itself. Glassfish and Weblogic does not use log4j, so here we need to configure this. # Possible values: false (don't explicitly configure log4j), basic (use basic configurator putting everything on the console) # or a path to a log4j.xml configuration file. # Default: false #logging.log4j.config=basic #logging.log4j.config=/home/glassfish/glassfish/domains/domain1/config/log4j.xml # ----------------- cluster configuration ---------------- # The configuration. Use "all" when clustering. # Default: default #jboss.config=all # Name of the farm directory. Use "farm" when clustering. # Default: deploy #jboss.farm.name=farm #------------------- HW token ------------------------------ # The directory of the HW token classes. If this is an emty directory no HW token will be used. # If the directory is not existing an empty directory will be created. # Default: ./hwtoken #hwtoken_classes=../primeCard/caTokenClasses-1.5 # Define this property when Luna HW token should be used. # You must have the Luna jars available in the build classpath (lib) when enabling this option. # Any value of the property will compile with Luna support. No Luna if undefined. #hsm.luna=X #------------------- EJBCA Healthcheck settings ------------- # Specifies the basic settings of the EJBCA Healtcheck servlet # for more detailed configuration edit the file src/publicweb/healthcheck/WEB-INF/web.xml # # Parameter specifying amount of free memory (Mb) before alarming # Default: 1 #healthcheck.amountfreemem=1 # Parameter specifying database test query string. Used to check that # the database is operational. # Default : Select 1 From CertificateData #healthcheck.dbquery=Select 1 From CertificateData # Parameter specifying IP addresses authorized to access the healthcheck # servlet. Use ';' for between multiple IPs. #healthcheck.authorizedips=127.0.0.1

75

#------------------- ECDSA implicitlyCA settings ------------- # Sets pre-defined EC curve parameters for the implicitlyCA facility. # See the User's Guide for more information about the implicitlyCA facility. # Setting these parameters are not neccesary when using regular named curves. # if you don't know what this means, you can safely ignore these settings. # # Default values that you can experiment with: # ecdsa.implicitlyca.q=883423532389192164791648750360308885314476597252960362792450860609699839 # ecdsa.implicitlyca.a=7fffffffffffffffffffffff7fffffffffff8000000000007ffffffffffc # ecdsa.implicitlyca.b=6b016c3bdcf18941d0d654921475ca71a9db2fb27d1d37796185c2942c0a # ecdsa.implicitlyca.g=020ffa963cdca8816ccc33b8642bedf905c3d358573d3f27fbbd3b3cb9aaaf # ecdsa.implicitlyca.n=883423532389192164791648750360308884807550341691627752275345424702807307 #------------------- Debug and special settings ------------- # # Specifies if the DN order should be constructed in forward (standard and default) # or reverse order. # Forward is: CN=Tomas Gustavsson, O=PrimeKey, C=SE # Reverse is: C=SE, O=PrimeKey, CN=Tomas Gustavsson # # Do not change this unless you really know what you are doing. # You can NOT install a CA in one order and then change the order, you have to re-install completely, # otherwise strange phenomenon will happen. # # Default: false #certtools.dnorderreverse=false # Flag indicating if the BC security provider should be removed before installing it again. When developing and re-deploying alot # this is needed so you don't have to restart JBoss all the time. # In production it may cause failures because the BC provider may get removed just when another thread wants to use it. # Therefore the default value is false. Do not change this unless you are an EJBCA developer. # # Default: false #development.provider.installation=false

A questo punto salviamo il file come ejbca.properties. Ora apriamo la shell, diventiamo superutente “root”, entriamo nella cartella /home/certification_authority/ejbca_3_4_3 e diamo il comando ant bootstrap Stiamo usando il programma Ant installato prima, per poter installare Ejbca. Dopo qualche istante il processo dovrebbe finire e dovremmo arrivare a una schermata di questo tipo.

76

Figura 4.48: Termine del comando ant deploy

Ora dobbiamo far partire JBoss. Per farlo possiamo fare come in precedenza, con il file run.sh contenuto nel directory /home/certification_authority/jboss-4.0.5.GA/bin oppure, e noi questa volta faremo così, scrivendo il comando che segue dalla cartella ejbca_3_4_3 dove siamo già ant j2ee:run Dopo un po’ dovremmo vedere una schermata come questa

Figura 4.49: Avvio di JBoss effettuato

77

Apriamo una nuova shell, entriamo nella cartella di ejbca_3_4_3, e scriviamo ant install Alla prima domanda lasciamo l’impostazione di default premendo invio. Poi per superadmin password e per Ca certificate password scriviamo “biometria”

Figura 4.50: Impostazione password per Ejbca

Torniamo alla shell di JBoss e con Control+C lo terminiamo. Diamo il comando sempre come root, e sempre dalla cartella di Ejbca ant deploy e dovremmo dopo un po’ arrivare a una schermata simile a questa

78

Figura 4.51: Termine del comando ant deploy

Ora dobbiamo importare il certificato dell’ amministratore, che è stato appena creato, nel nostro web browser, per accedere all’interfaccia grafica di amministrazione di Ejbca successivamente. Il certificato è in /home/certification_authority/ejbca_3_4_3/p12 e si chiama superadmin.p12. Per importarlo in Firefox dobbiamo andare su Modifica, Preferenze poi da qui sulla scheda avanzate, poi la scheda sicurezza, e clicchiamo su mostra certificati. Poi andiamo alla scheda certificati personali e clicchiamo su importa. A questo punto scegliamo il file superadmin.p12 di cui abbiamo parlato.

Figura 4.52: Importazione del certificato in Mozilla Firefox

79

Alle richieste di password inseriamo sempre “biometria”, dato che era questa la password impostata in precedenza. Ora rifacciamo partire JBoss, sempre come utente “root”, con i comandi cd /home/certification_authority/jboss-4.0.5.GA/bin ./run.sh

Dopo l’avvio di JBoss apriamo Firefox all’indirizzo http://localhost:8443/ejbca, e dovremmo ottenere una pagina come questa.

Figura 4.53: Accesso a Ejbca Questa è la pagina principale di Ejbca, da dove si può accedere a tutte le funzioni. Se entriamo in Administration ci verrà chiesto di accettare il certificato; clicchiamo su accetta in modo permanente, poi inseriamo la password “biometria” e si aprirà una schermata di questo tipo

80

Figura 4.54: Strumenti di amministrazione di Ejbca

Da cui si può accedere alle varie funzioni di CA e RA, come per esempio creare una CRL oppure visualizzare i dati dei certificati. (NB. Alla fine della guida è presente la sezione 4.3.11 che spiega cosa fare in caso di errore nell’accesso alla sezione Administration perché il certificato non è riconosciuto). Come per JBoss, si riesce ad accedere a Ejbca anche da un altro pc connesso alla rete, sostituendo localhost con l’indirizzo IP del pc dove sta funzionando Ejbca, come mostra la figura

Figura 4.55: Accesso a Ejbca tramite pc remoto

81

A questo punto possiamo chiudere il browser, e anche JBoss con la solita combinazione Control + C. Ora dobbiamo installare OpenLDAP, che serve per memorizzare informazioni sui certificati emessi dalla Certification Authority. Non possiamo installarlo subito però; prima dobbiamo installare 3 componenti: BerkeleyDB per farlo funzionare e OpenSSL e Cyrus SASL per il supporto alle funzioni di crittografia e autenticazione. 4.3.6 Installazione di OpenSSL La versione da noi utilizzata di OpenSSL è la 0.9.8e; scarichiamola dal sito http://www.openssl.org/source/ per ottenere il file openssl-0.9.8e.tar.gz. Copiamolo nella solita cartella /home/certification_authority. A questo punto apriamo una shell e diamo il comando tar xzvf openssl-0.9.8e.tar.gz ora dovremmo avere la cartella openssl-0.9.8e in /home/certification_authority; eliminiamo pure il file openssl-0.9.8e.tar.gz e apriamo una shell per scrivere i seguenti comandi cd openssl-0.9.8e e poi ./config shared --openssldir=/usr/local Dovremmo ottenere alla fine una schermata come questa

Figura 4.56: Termine del passaggio di configurazione di OpenSSL

82

A questo punto diamo il comando make e dopo alcuni minuti la shell dovrebbe apparire come nella figura seguente

Figura 4.57: Termine delle operazioni effettuate da make Ora per installare il programma acquisiamo i privilegi di utente “root” e usiamo il comando make install

Alla fine dovremmo ottenere una schermata simile alla seguente

83

Figura 4.58: Installazione di OpenSSL conclusa

Chiudiamo la shell. Il programma dovrebbe essere installato in /usr/local. Ora, a scopo di esempio, vediamo come sia possibile creare una Certification Authority (CA) con OpenSSL, comprendente una chiave e un certificato associato, che si possono usare per firmare altri certificati. 4.3.6.1 Creazione di una CA con OpenSSL Apriamo la shell e creiamo la cartella “test” con il comando md test Dovremmo ora avere la cartella /home/certification_authority/test. Entriamo nella cartella appena creata con il comando cd test Sarebbe meglio mettere i nostri certificati per la CA in una cartella meno accessibile e magari protetta, ma questo è solo un test per far vedere come usare OpenSSL. Creiamo a questo punto la chiave CA con il comando openssl genrsa -des3 -out test-ca.key 1024 1024 indica che la chiave rsa generata è a 1024 bit, il massimo gestibile dal token presente in laboratorio.

84

Dopo aver dato il comando verrà chiesto di inserire la password, e noi inseriamo sempre “biometria”. Ci verrà chiesto di confermarla, e alla fine dovremmo ottenere qualcosa di simile a

Figura 4.59: Creazione di una CA 1/6

e dovrebbe essere presente il file test-ca.key nella cartella /home/certification_authority/test. Produciamo ora un certificato nel formato X.509 valido per un anno per la nostra Certification Authority, con il comando (sempre dato dalla cartella test dove è presente il file con la chiave) openssl req -new -x509 -days 365 -key test-ca.key -out test-ca.crt ci verrà chiesta la password usata prima per creare la chiave (“biometria”), inseriamola e ci verranno poi chiesti dei dati che inseriremo come in figura

85

Figura 4.60: Creazione di una CA 2/6

E’ ora doveroso fare 2 precisazioni; la prima riguarda il fatto che l’indirizzo email nell’esempio è stato inventato; nella realtà meglio metterne uno esistente. La seconda riguarda il common name; questo deve essere un nome valido. Nel nostro caso abbiamo messo ca.example.com, solo a titolo di esempio, nella realtà avremmo potuto mettere pcsitr2.dei.unipd. In pratica sarebbe il nome che un server DNS trasforma nell’indirizzo IP corrispondente. Torniamo ai certificati; a questo punto nella cartella test dovrebbe esserci anche il file test-ca.crt, cioè il certificato della Certification Authority. Creiamo ora il certificato e la chiave per il nostro server. Diamo il comando

openssl genrsa -des3 -out test-server.key 1024 per ottenere la chiave per il server; usiamo come password “server”. Ora creiamo la richiesta di certificato per il server openssl req -new -key test-server.key -out test-server.csr Riempiamo i campi come segue

86

Figura 4.61: Creazione di una CA 3/6

Questa volta ci vengono chieste altre informazioni: alla prima inseriamo password, l’altra diamo semplicemente invio. NB: il nome assegnato all’indirizzo IP da usare come common name lo si potrebbe anche ottenere con il comando host mioIP dove al posto di mioIP va l’indirizzo IP del calcolatore. Ad esempio eseguendo il comando sul nostro pc otteniamo la schermata seguente

Figura 4.62: Nome del pc corrispondente al suo indirizzo IP

87

Creiamo ora il certificato per un utente che lo abbia richiesto. Innanzitutto creiamo la chiave usando il comando openssl genrsa -des3 -out test-utente.key 1024 Facciamo tutto sempre nella cartella test; come prima ci verrà chiesta la password e ci verrà chiesta la conferma; usiamo questa volta “utente”. Ora creiamo una richiesta per il certificato utente (associato alla chiave appena creata) con il comando openssl req -new -key test-utente.key -out test-utente.csr Come per il server ci verrà chiesta la password usata per la chiave e poi una serie di informazioni; completiamo il tutto come in figura, e alla penultima e ultima domanda rispondiamo come per il server, cioè con “password” e poi non scriviamo nulla e premiamo solo invio.

Figura 4.63: Creazione di una CA 4/6 Ora abbiamo le richieste di certificato per il server e per l’utente; creiamo questi certificati usando il certificato della CA. Creiamo il certificato server con il comando openssl x509 -req -in test-server.csr -out test-server.crt -sha1 -CA test-ca.crt -CAkey test-ca.key -CAcreateserial -days 365

88

ci verrà chiesta la password della chiave della CA (“biometria”); a questo punto il certificate viene creato, ed è firmato dalla nostra CA per attribuirgli validità.

Figura 4.64: Creazione di una CA 5/6

Facciamo una cosa simile anche per l’utente con il comando openssl x509 -req -in test-utente.csr -out test-utente.crt -sha1 -CA test-ca.crt -CAkey test-ca.key -CAcreateserial -days 365 Ora dovremmo avere nella cartella test anche i file test-server.crt e test-utente.crt. Trasformiamo ora il certificato utente appena creati per poterlo usare con i web browser più comuni che richiedono il certificato nel formato PKCS#12. Diamo il comando openssl pkcs12 -export -in test-utente.crt -inkey test-utente.key -name “utente.example.com” -out test-utente.p12 viene richiesta la password della chiave test-utente.key (“utente”) e una export password (che bisogna anche confermare un altra volta); scegliamo ancora “utente” ma potremmo sceglierne un altra. La schermata che otteniamo dovrebbe essere

89

Figura 4.65: Creazione di una CA 6/6

Il token presente in laboratorio, il rainbow iKey 3000, accetta i certificati in formato DER. Dobbiamo allora effettuare una conversione con i comandi openssl x509 -in test-utente.crt -outform PEM -out test-user.pem e infine openssl x509 -in test-utente.pem -out test-utente.cer -outform DER Alla fine dovremmo avere nella cartella test anche il file test-utente.cer, che è il file da importate nel token.

Figura 4.66: Cartella test contenente i file creati nell’esempio

90

4.3.7 Installazione di BerkeleyDB BerkeleyDB è un pacchetto che contiene molti programmi e utility che forniscono funzioni di database. E’ un componente indispensabile per molte applicazioni, come OpenLDAP. Prima di tutto scarichiamo da http://www.oracle.com/technology/software/products/berkeley-db/index.html il file db-4.6.18.tar.gz contenente la versione 4.6 di BerkeleyDB. Mettiamo il file nella solita cartella /home/certification_authority; fatto questo apriamo una shell e diamo il comando tar xzf db-4.6.18.tar.gz Dopo alcuni istanti dovremmo la decompressione dovrebbe essere terminata e dovremmo vedere una schermata simile a questa

Figura 4.67: Decompressione di Berkeley DB

Dovrebbe esserci ora la cartella db-4.6.18 in /home/certification_authority. Eliminiamo il file db-4.6.18.tar.gz che non serve più; entriamo ancora nella shell e dovremmo essere sempre nella solita cartella /home/certification_authority. Diamo il comando cd db-4.6.18 Ora diamo il comando cd build_unix

91

e poi ../dist/configure --prefix=/usr/local Dopo un po’ dovremmo ottenere una schermata simile a questa

Figura 4.68: Esecuzione del comando configure A questo punto scriviamo il comando make e dopo un po’ la shell dovrebbe apparire così

92

Figura 4.69: Esecuzione di make

A questo punto acquisiamo i privilegi di utente “root” e diamo il comando make install per ottenere

Figura 4.70: Installazione di Berkeley DB completata

Possiamo ora eliminare la cartella /home/certification_authority/db-4.6.18.

93

4.3.8 Installazione di Cyrus SASL Innanzitutto scarichiamo dal sito ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/ il file cyrus-sasl-2.1.22.tar.gz, per poi metterlo nella solita cartella /home/certification_authority. Apriamo ora una shell e diamo il comando tar xzvf cyrus-sasl-2.1.22.tar.gz Alla fine della decompressione digitiamo cd cyrus-sasl-2.1.22 e ora, dopo aver premuto invio, diamo il seguente comando env CPPFLAGS=”-I/usr/local/include” LDFLAGS=”-L/usr/local/lib” ./configure Alla fine dovremmo ottenere qualcosa di simile a

Figura 4.71: Esecuzione di configure Ora diamo il comando make e alla fine arriveremo alla schermata

94

Figura 4.72: Esecuzione di make A questo punto diventiamo superutente “root” e lanciamo il comando make install per ottenere Figura 4.73: Installazione completata di Cyrus SASL

Infine sempre come utente “root” diamo l’ultimo comando ln -s /usr/local/lib/sasl2 /usr/local/sasl2

95

Possiamo adesso eliminare il file cyrus-sasl-2.1.22.tar.gz dalla cartella /home/certification_authority. 4.3.9 Installazione di OpenLDAP

Siamo pronti ora per l’installazione vera e propria di OpenLDAP. Assicuriamoci che BerkeleyDB, OpenSSl e CyrusSASL siano installati nella cartella /usr/local. Se abbiamo seguito la guida fino ad ora i programmi dovrebbero essere installati in queste cartelle, altrimenti nel comando ./configure che useremo tra poco ricordiamoci di sostituire le cartelle di installazione passate come parametro con quelle esatte per il nostro sistema. Procuriamoci OpenLDAP dal sito http://www.openldap.org/software/download/. La versione da noi usata è la versione 2.3.38, corrispondente al file openldap-stable-20070831.tg. Copiamo il file in /home/certification_authority, apriamo una shell e scriviamo tar xzvf openldap-stable-20070831.tgz alla fine del processo, dopo aver eliminato il file openldap-stable-20070831.tgz, entriamo nella cartella appena creata con il comando cd openldap-2.3.38 e diamo il comando seguente

env LD_LIBRARY_PATH=”/usr/local/lib” CC=gcc CPPFLAGS=”-I/usr/local/include” LDFLAGS=”-L/usr/local/lib” ./configure --with-ssl --with-tsl --enable-ldbm --enable-hdb --enable-bdb Figura 4.74: Comando configure con i parametri

96

Dopo qualche minuto se tutto è andato bene dovremmo ottenere una schermata come questa, senza aver ottenuto errori

Figura 4.75: Esecuzione di configure A questo punto diamo il comando make depend e arriviamo a

Figura 4.76: Esecuzione di make depend

97

Ora il comando make per arrivare a

Figura 4.77: Esecuzione di make

Infine passiamo all’installazione con il comando make install Dovremmo alla fine ottenre qualcosa di simile a

98

Figura 4.78: Installazione completata di OpenLDAP A questo punto l’installazione è completata. Iniziamo ora la configurazione di OpenLDAP.

4.3.9.1 Configurazione di OpenLDAP Come spiegato nella guida di Ejbca, per permettere ai certificati della nostra CA di essere gestiti da OpenLDAP dobbiamo entrare nell’interfaccia grafica di amministrazione di Ejbca (quella di figura 4.51) e ciccare su “Edit Publisher”. Figura 4.79: Accesso alla funzione “Edit Publishers” nella sezione

Administration di Ejbca

99

A questo punto configuriamo il tutto secondo le nostre esigenze come spiegato in modo esauriente nel file di configurazione di Ejbca presente nel dvd. Figura 4.80: Configurazione di Ejbca per OpenLDAP 1/2

Figura 4.81: Configurazione di Ejbca per OpenLDAP 2/2

Ora una volta impostato tutto clicchiamo su save ed usciamo poi dalla schermata di amministrazione d Ejbca.

100

Copiamo il file ejbca.schema contenuto in /home/certification_authority/ejbca_3_4_3/doc/ldapschema all’interno della cartella /usr/local/etc/openldap/schema con il comando (dobbiamo essere “root”) cp /home/certification_authority/ejbca_3_4_3/doc/ldapschema/ejbca.schema /usr/local/etc/openldap/schema Nella stessa cartella inseriamo anche il file certificate.schema, creato da Zampieri Daniele, che contiene la definizione per le entry riferite ai certificati della CA (i file .schema usati trovano nel dvd nella cartella di OpenLDAP, vedere il file readme per maggiori informazioni). Il file certificate.schema contiene il seguente testo ## ## Zampieri Daniele ## Estensione schema ldap per Certification Authority ## ho usato l'oid 99999 fittizzio in attesa di registrazione ## attributeType ( 1.3.6.1.4.1.99999.1.1.2.20 NAME 'Serial' DESC 'Certificate Serial Number' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.21 NAME 'Common' DESC 'Common Name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.22 NAME 'Organization' DESC 'Organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.23 NAME 'OrganizationUnit' DESC 'Organization Unit' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.24 NAME 'E-mail' DESC 'E-mail' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.25 NAME 'Locality' DESC 'Locality' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.26 NAME 'State' DESC 'State' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch

101

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.27 NAME 'Country' DESC 'Country' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.28 NAME 'CERT' DESC 'Certificate' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.29 NAME 'userPwd' DESC 'User Password' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.30 NAME 'edate' DESC 'Emission Date' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.31 NAME 'expdate' DESC 'Expiration Date' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.32 NAME 'revdate' DESC 'Revocation Date' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) attributeType ( 1.3.6.1.4.1.99999.1.1.2.33 NAME 'CAname' DESC 'CA Name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) objectclass ( 1.3.6.1.4.1.99999.1.1.1.4 NAME 'CAcert' SUP top STRUCTURAL MUST (Serial) MAY (Common $ Organization $ OrganizationUnit $ E-mail $ Locality $ State $ Country $ CERT $ userPwd $ edate $ expdate $ revdate) ) objectclass ( 1.3.6.1.4.1.99999.1.1.1.5 NAME 'CA' SUP top STRUCTURAL MUST (CAname))

Apriamo ora il file slapd.conf contenuto in /usr/local/etc/openldap/ nello stesso modo in cui abbiamo aperto con kwrite il file bashrc precedentemente (dobbiamo avere i privilegi di “root”). Il file dovrebbe essere simile a

102

# # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND

103

# should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data # Indices to maintain index objectClass eq Modifichiamolo nel modo seguente (in grassetto le modifiche) # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema ##################################################################################### # campi aggiunti per pc certification authority include /usr/local/etc/openldap/schema/corba.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/java.schema include /usr/local/etc/openldap/schema/certificate.schema # CAMPI EJBCA # #include /usr/local/etc/openldap/schema/ejbca.schema ##################################################################################### # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: # modulepath /usr/local/libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access

104

# Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb

suffix "dc=conmo,dc=com" rootdn "cn=root,dc=conmo,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw biometria # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data # Indices to maintain index objectClass eq A questo punto siamo pronti ad usare OpenLDAP. Per poter utilizzare i metodi di autenticazione forniti da Cyrus SASL, dobbiamo innanzitutto aprire una shell, diventare utente “root”, e dare il comando saslpasswd2 –c nomeutente al posto di nomeutente mettiamo ad esempio root (è il nome dell’utente a cui verrà poi permesso di accedere a OpenLDAP ad esempio per aggiungere entry); alle richieste successive di password mettiamo ad esempio “biometria”. Fatto ciò aggiungiamo al file slapd.conf la riga (varia a seconda delle nostre esigenze) sasl-regexp uid=(.*),cn=root,cn=DIGEST-MD5,cn=auth uid=$1,dc=conmo,dc=com Chiudiamo e salviamo. Ora possiamo far partire il server slapd con i comandi (sempre come “root”) cd /usr/local/libexec ./slapd start

105

4.3.10 Installazione di Ldap Browser/Editor Come ultima cosa installiamo un programma per poter vedere graficamente la struttura dei nostri directory LDAP. Scarichiamo dal sito http://www-unix.mcs.anl.gov/~gawor/ldap/download.html il file Browser282b2.tar.gz. Dopo averlo copiato nella solita cartella /home/certification_authority, apriamo una shell e diamo il comando tar xzvf Browser282b2.tar.gz a decompressione avvenuta entriamo nella cartella appena create con il comando cd ldapbrowser ora diamo il comando ./lbe.sh Dovrebbe aprirsi una schermata simile a questa Figura 4.82: Ldap Browser/Editor Con questo programma è possibile sia una visione piu chiara dei directory ed entry LDAP, sia l’esecuzione di comandi che sarebbero stati precedentemente possibili sono tramite riga di comando.

106

Clicchiamo su “new” e dovrebbe aprirsi una schermata come questa Figura 4.83: Configurazione di Ldap Browser/Editor 1/2

Diamo come nome “certification_authority” e poi passiamo alla scheda “Connection”; a questo punto inseriamo le informazioni come in figura. (NB. Possiamo mettere, invece dell’indirizzo IP, anche il nome corrispondente, come pcsitr2.dei.unipd.it)

Figura 4.84: Configurazione di Ldap Browser/Editor 2/2

107

Figura 4.85: Avvio di Ldap Browser/Editor Ovviamente non abbiamo ancora inserito alcun dato; per farlo basta usare il comado ldapadd come utente “root”, o importare entry in formato LDIF. Se si una ldapadd verrà richiesto nome utente e password per l’autenticazione con SASL; sono quelli inseriti precedentemente con il comando saslpasswd2. 4.3.11 Errore di accesso alla sezione Administration di Ejbca Può capitare che per qualche motivo l’accesso alla sezione Administration di Ejbca non sia possibile in quanto Mozilla Firefox visualizza un errore di “Certificato Rifiutato”. Nelle prove effettuate questo si è verificato in qualche circostanza; vediamo allora come risolvere il problema. Per prima cosa si deve avviare Mozilla Firefox, poi andiamo su modifica, preferenze, avanzate, e passiamo alla scheda sicurezza. Fatto questo clicchiamo su “mostra certificati” ed eliminiamo dalla scheda “Certificati personali” il certificato “SuperAdmin”, mentre dalla scheda “Autorità” eliminiamo il certificato “AdminCA1” se presente, come mostrato in figura.

108

Figura 4.86: Eliminazione del certificato personale

Figura 4.87: Eliminazione del certificato di autorità

Ora apriamo una shell, diventiamo utente “root”, ed entriamo nella cartella di installazione di ejbca, e poi nella cartella bin, nel nostro caso con il comando cd /home/certification_authority/ejbca_3_4_3/bin

109

A questo punto diamo il comando ./ejbca.sh ca getrootcert AdminCA1 ca.crt -der Dove AdminCA1 è il nome che abbiamo deciso nel file ejbca.properties per ca.name (se abbiamo lasciato il nome di default, come nel nostro caso, dovrebbe essere AdminCA1). Verrà creato il certificato ca.crt nella cartella bin di Ejbca. Ora diamo il comando rm /home/certification_authority/jdk1.5.0_12/jre/lib/security/cacerts Rispondiamo “yes” alla domanda e premiamo invio. A questo punto scriviamo keytool –import –trustcacerts –alias AdminCA1 –keystore /home/certification_authority/jre/lib/security/cacerts –storepass changeit –file /home/certification_authority/ejbca_3_4_3/bin/ca.crt Fatto ciò, sempre dalla schermata dei certificate di Firefox, andiamo nella scheda “Autorità”, clicchiamo su Importa, e scegliamo come certificato il file ca.crt presente nella cartella /home/certification_authority/ejbca_3_4_3/bin, cliccando poi su Apri una volta selezionato tale file. Una volta fatta questa operazione, comparirà una figura come quella sottostante; selezioniamo le opzioni ritenute opportune, e clicchiamo su OK.

Figura 4.88: Importazione del nuovo certificato di autorità

Ora passiamo a “Certificati personali”, e importiamo il file superadmin.p12, contenuto nella cartella /home/certification_authority/ejbca_3_4_3/p12; alla richiesta di password inseriamo quella decisa in fase di installazione di Ejbca, nel nostro caso“biometria”.

110

Figura 4.89: Importazione del certificato personale

A questo punto il ripristino è terminato, e riavviando JBoss ed Ejbca, non si dovrebbe più presentare l’errore di “Certificato Rifiutato”, quando da Firefox si cerca di accedere alla sezione Administration di Ejbca. 4.4 Conclusioni Il lavoro di questa tesi ha analizzato a fondo i motivi principali per i quali è indispensabile la figura della Certification Authority come entità che garantisce l’autenticazione di un utente. I vari software utilizzati riescono a fornire tutte le funzioni necessarie ai nostri scopi, con il notevole vantaggio di essere open-source e completamente gratuiti. Come già detto però la Certification Authority realizzata era parte di un sistema di autenticazione a parametri biometrici molto più complesso. Per aumentare la sicurezza e l’efficienza, nelle varie comunicazioni tra la Certification Authority e gli altri elementi del sistema stesso, si potrebbero utilizzare altri 2 software. Il primo è OpenVPN, che appoggiandosi ad OpenSSL riesce a creare dei tunnel crittografati punto-punto tra i vari pc del sistema, ad esempio tra il pc contenente la CA e il pc con l’Attribute Authority. Il secondo programma è il Mit Kerberos, che aggiunge ulteriore sicurezza alle comunicazioni tra i vari host, tramite cifratura dei dati e un meccanismo di autenticazione che prevede la presenza di una terza parte fidata (Authentication Server) che mantiene un database di chiavi segrete. Ogni host condivide la sua chiave segreta solo con AS, che la usa per provare l’identità dei soggetti che vogliono comunicare, e una volta fatto ciò genera una chiave segreta di sessione per la comunicazione di questi host mediante crittografia simmetrica.

111

Bibliografia

• T.H Cormen, C.E. Leiserson, R.L. Rivest, C.Stein: Introduction to Algorithms – Second Edition. McGraw Hill/MIT Press, Cambridge Mass. USA, 2001

• Maurizio Bergami: Proteggi il tuo PC. Mondatori Informatica, 2002

• Larry L. Peterson, Bruce S. Davie: Reti di calcolatori. Apogeo, 2004

• Maurizio Cuna: Progetto di una infrastruttura sicura e flessibile per

l’autenticazione tramite parametri biometrici. Università degli studi di Padova, 2006

• Alessio Mozzi: Messa a punto di una piattaforma distribuita per

autenticazione biometria. Università degli studi di Padova, 2006

• Wikipedia http://it.wikipedia.org

• The Java Tutorials: PATH AND CLASSPATH http://java.sun.com/docs/books/tutorial/essential/environment/paths.html

• JavaStaff – Apache Ant: come semplificare la vita di un

programmatore Java http://www.javastaff.com/article.php?story=20041228143333139

• Installare e utilizzare Ant http://openskills.info/topic.php?ID=176

• JBoss Installation Guide https://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/Installation_Guide.pdf

• The JBoss 4 Installation Guide http://docs.jboss.com/jbossas/guides/installguide/r1/en/pdf/jboss4-install.pdf

• EJBCA – The J2EE Certificate Authority – User Guide http://ejbca.sourceforge.net/manual.html

• PrimeKey Solutions | EJBCA http://www.primekey.se/primekey/en/Products/EJBCA.html

• EJBCA advanced features http://www.linagora.com/IMG/pdf/advanced-features-paris-

20070131_Tomas.pdf

112

• RFC 2246: The TSL Protocol version 1.0 http://tools.ietf.org/html/rfc2246

• OpenSSL: Support, Frequently Asked Question http://www.openssl.org/support/faq.html

• Oracle Berkeley DB http://www.oracle.com/technology/products/berkeley-db/db/index.html

• RFC 2222: Simple Authentication and Security Layer (SASL) http://www.ietf.org/rfc/rfc2222.txt

• RFC 4422: Simple Authentication and Security Layer (SASL) http://tools.ietf.org/html/rfc4422

• Dott. Gianna Bellè: Appunti del corso di reti di calcolatori, Università di Genova

http://www.disi.unige.it/person/BelleG/Reti99/Appunti/Appunti2/Cap2b/ Cap2b.html

• PKI e firma digitale

http://www.comune.modena.it/firma/

• Simone Galdino: Algoritmo IDEA http://www.dia.uniroma3.it/~dispense/rota/Algoritmo_IDEA.pdf

• OpenLDAP Installation on GNU/Linux

http://www.proscrutiny.com/howtos/OpenLDAP.html

• OpenLDAP Software 2.3 Administrator’s Guide http://www.openldap.org/doc/admin23/

• OpenLDAP FAQ-O-Matic http://www.openldap.org/faq/data/cache/1.html

• Antonio Radesca: OpenLDAP: installazione, configurazione, setup http://www.dia.unisa.it/%7Eads/corso-security/www/CORSO-0203/openLDAP/

• Forum con discussione sul problema di accesso alla sezione Administration di Ejbca

http://www.nabble.com/cannot-access-adminweb-t4006583.html#a11378494

113