Applicazione per la generazione il rilascio e la verifica di certificati

Transcript

1 UNIVERSITÀ DEGLI STUDI DI MILANO DIPARTIMENTO DI TECNOLOGIE DELL INFORMAZIONE Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di LABORATORIO DI CRITTOGRAFIA APPLICATA Applicazione per la generazione il rilascio e la verifica di certificati Studenti: Massimo Manara Docente del corso: Stelvio Cimato Anno Accademico 2006/2007

2 .

3 Indice Introduzione 5 1 L applicazione Architettura Bouncy Castle Il server Generazione rilascio Verifica Il client Generazione rilascio Verifica Bibliografia 19

4 .

5 Introduzione Il lavoro svolto si propone di implementare attraverso il linguaggio java, un applicazione in grado di generare, rilasciare e verificare certificati digitali. L applicazione implementata prende il nome di GE.RI.VE. (Generazione, Rilascio e Verifica). Nella fase di progetto si è scelto di utilizzare le librerie per la gestione dei certificati rilasciate da Bouncy Castle. Il lavoro è stato così organizzato: nel primo capitolo, la descrizione dell architettura del progetto e delle librerie utilizzate, nel secondo la descrizione dal punto di vista del server, sulla generazione, rilascio e verifica dei certificati, nell ultimo capitolo, la parte client, la richiesta di rilascio di un certificato, e la seguente verifica di validità e veridicità.

6 .

7 Capitolo 1 L applicazione In questo capitolo viene presentata l architettura dell applicazione, formata dai componenti client e server, legati da una comunicazione crittografata. Viene inoltre descritto quali librerie sono state utilizzate per realizzare parte del progetto e sulla loro modalità di installazione e uso all interno del proprio Java development Kit (JDK). 1.1 Architettura L architettura dell applicazione, è formata da una parte server e un altra client. Queste due parti comunicano su un canale cifrato TSL (Transport Layer Security, noto anche come SSL 3.1) [DA07]. Nella parte server, come Figura 1.1: Architettura. mostrato in Pseudocodice 1.1, viene creato e caricato il keystore_creato, tramite la funzione key_store_load nella libreria keystore; successivamente viene definito il tipo di connessione cifrata: SSL o TLS, nel nostro

8 8 Capitolo 1. L applicazione caso l ultima delle due, infine il ServerSocket viene messo in ascolto sulla porta prescelta. Pseudocodice 1.1: Instaurazione TLS server 1 KeyStore keystore_creato = keystore. key_store_load ( passphrase ); 3 SSLContext context = SSLContext. getinstance (" TLS "); 5 ServerSocket ss = ssf. createserversocket ( PORT ); 7 Socket s = ss. accept () ; In modo analogo nella parte client Pseudocodice 1.2, viene cariato il keystore_ca di tipo JKS, il formato originale dei keystore SUN, contiene soltanto chiavi private e certificati [HFPS07], gli alias sono case sensitive [Hoo05]. Viene successivamente creata la connessione TLS e messo in ascolto il Socket su HOST e PORT predefiniti. Pseudocodice 1.2: Instaurazione TLS client 1 KeyStore keystore = KeyStore. getinstance (" JKS "); keystore. load ( new FileInputStream (" keystore_ca "), passphrase ); 3 SSLContext context = SSLContext. getinstance (" TLS "); 5 TrustManager [] trustmanagers = tmf. gettrustmanagers () ; 7 SSLSocketFactory sf = context. getsocketfactory () ; 9 Socket s = sf. createsocket ( HOST, PORT ); 1.2 Bouncy Castle Bouncy Castle [Cas07] è una collezione di API (Application Programming Interface) per uso crittografico in linguaggio Java e C#. Dal sito Bouncy Castle nella parte per il linguaggio java, nella sezione latest releases è possibile scaricare il pacchetto il provider bcprov-jdk jar. L installazione di questo provider - nei sistemi Microsoft Windows - avviene seguendo alcuni passi: Copiare il file.jar nella cartella del proprio JRE (Java(TM) Platform, Standard Edition Runtime Environment). Es.: C:\Programmi\Java\jre1.6.0\lib\ext; Copiare il file.jar nella cartella del proprio JDK. Es.: C:\Programmi\Java\jdk1.6.0\jre\lib\ext; Modificare il file java.security andando ad aggiungere il provider appena installato nella lista delle preferenze:

9 Capitolo 1. L applicazione 9 Sia in C:\Programmi\Java\jre1.6.0\lib\security aggiungendo security.provider.xy=org.bouncycastle.jce.provider.bouncycastleprovider dove XY rappresenta il numero di preferenza; Sia in C:\Programmi\Java\jdk1.6.0\jre\lib\security. Utili informazioni sull utilizzo delle API fornite, è possibile trovarne ovviamente sul sito di Bouncy Castle, sul libro [Hoo05] e sul Java Technology Forums:

10 .

11 Capitolo 2 Il server In questo capitolo viene presentato il ruolo e la funzione della parte server. La parte server funge da autorità di certificazione (CA). Ha quindi la possibilità di rilasciare una lista di CA valide per dare modo a una client di scegliere su quale certificarsi. Fornendo poi il certificato al client richiedente. Infine è possibile verificare il proprio certificato creato. 2.1 Generazione rilascio La funzione del server è quella di rilasciare una lista delle CA disponibili e rilasciare quindi certificati infine di poterli verificare. Lo scenario è mostrato in Figura 2.1, il primo passo è il rilascio delle CA disponibili, a seguito della scelta del client e dell invio della propria chiave pubblica, viene rilasciato il certificato firmato, con una validità di una settimana. I passi per il rilascio e la generazione lato server sono l esecuzione del software in modalità generazione: java GERIVE_server -d. A seguito di un errore viene mostrata la sinossi corretta: Sinossi: GERIVE_server [-g genera] [-v verifica] poi, come mostrato in Figura 2.1: 1. Viene mostrato il nome dell applicazione e il suo scopo, e la lista delle CA disponibili inviate al client: ******************************************************************** * Università di Milano * * Laboratorio di crittografia applicata Prof. Stelvio Cimato * * Studente: Massimo Manara mat.: GERIVE - Server * * a.a. 2006/2007 * ********************************************************************

12 12 Capitolo 2. Il server Figura 2.1: Funzione server. <- 1) Invio lista CA al client CA: ca2 CA: ca1 2 A seguito della ricezione della chiave pubblica viene spedito il certificato firmato: -->2) Ricezione chiave pubblica: OK! <--3) Invio del certificato firmato al client: OK! La direzione delle frecce rappresenta l invio o la ricezione di un messaggio. 3 Il client termina la comunicazione inviando il carattere.

13 Capitolo 2. Il server Verifica È possibile inoltre verificare se un dato certificato sia valido o meno come mostrato in Figura 2.2. Questa funzione viene decisa all inizio del lancio dell applicazione sia server che client. I passi per la verifica sono Figura 2.2: Verifica. l esecuzione del software in modalità di verifica: java GERIVE_server -v. 1. Viene mostrato il nome dell applicazione e il suo scopo: ************************************************************************ * Università di Milano * * Laboratorio di crittografia applicata Prof. Stelvio Cimato * * Studente: Massimo Manara mat.: GERIVE - Server Verifica * * a.a. 2006/2007 * ************************************************************************ 2 A seguito l esito della ricezione, il controlla della validità e la verifica: -->1) Ricezione del certificato: OK! ---3) Conrolla data: OK! ---4) Controlla firma: OK!

14 .

15 Capitolo 3 Il client In questo capitolo viene presentato il ruolo e la funzione della parte client. La parte client funge da utente richiedente un certificato o una verifica di un certificato rilasciato a priori rispetto alla CA. 3.1 Generazione rilascio La funzione del client è quella di richiedere al server la lista della CA disponibili, una volta ricevuta tale lista, è possibile decidere su quale certificarsi. Lo scenario è mostrato in Figura 3.1, il primo passo è la richiesta della lista delle CA disponibili al server, a seguito della risposta della CA, il client invia la sua chiave pubblica (nel caso di certificati self-signed, coincide con la chiave pubblica della CA), infine il client riceve il certificato rilasciato dalla CA scelta nel primo passo. I passi per la richiesta e la ricezione sono l esecuzione del software in modalità generazione: java GERIVE_client -d. Poi, come mostrato in Figura 3.1: 1. Viene mostrato il nome dell applicazione e il suo scopo, e la lista delle ricevute con la richiesta da parte dell utente di selezionare la CA desiderata: ******************************************************************** * Università di Milano * * Laboratorio di crittografia applicata Prof. Stelvio Cimato * * Studente: Massimo Manara mat.: GERIVE - Client * * a.a. 2006/2007 * ******************************************************************** -->2) Ricezione CA disponibili

16 16 Capitolo 3. Il client Figura 3.1: Funzione client. ca2 ca1 Con quale vuoi certificarti?(1/2) 2 A seguito della scelta, viene inviata la chiave pubblica alla CA che rilascia il certificato, il client stampa su console il contenuto e chiede all utente se vuole salvarlo su file, per verificarlo in un secondo momento: Con quale vuoi certificarti?(1/2) 2 -->3) Invio chiave pubblica: OK! -->4) Ricezione certificato: OK! Certificato: [ [ Version: V3 Subject: CN=Client, OU=Client, O=Client, L=Client, ST=Client, C=Client Signature Algorithm: SHA256withRSA, OID = Key: Sun RSA public key, 1024 bits modulus:

17 Capitolo 3. Il client public exponent: Validity: [From: Tue Jul 03 23:17:33 CEST 2007, To: Tue Jul 10 23:17:33 CEST 2007] Issuer: CN=GERIVE - CA 1, OU=Ca1, O=ca1, L=ca1, ST=ca1, C=ca1 SerialNumber: [ 01138df1 ff6d] ] Algorithm: [SHA256withRSA] Signature: 0000: A9 29 8C 93 F0 F5 68 4D 03 E1 0B 5E 7A F5 F8.)...hM...^z. 0010: E D C B8 0D CA 03 CF Xq.h&...RS 0020: 1F F D4 4A CC A9 BF 45 6F A $)/.J...Eo.e.h. 0030: 91 AF 7C 8C 5A 8D C6 E0 97 1F E Z...XT...I 0040: 0C D A6 DC BD D7 A7 B c3.$...E2...x) 0050: 45 7D 7C C0 28 8D 42 F8 FB A5 D7 5E 0E AA CD 85 E...(.B...^ : E5 24 B6 27 1C 27 6D E7 71 E0 AF 1B A 44.$.'.'m.q...i..D 0070: DD AA EA D0 85 4A C C2 EE C4...DB..J7%,..$.. ] Vuoi salvare su file il certificato per verificarlo in futuro? (si/no) La direzione delle frecce rappresenta l invio o la ricezione di un messaggio. 3 A seguito della risposta affermativa si, viene chiesto il nome del file che dovrà avere - ad esempio prova.der - il certificato: Vuoi salvare su file il certificato per verificarlo in futuro? (si/no) si Nome del certificato?: prova.der ---6) Salvataggio certificato: OK! 4 Dopo la conferma di salvataggio avvenuto con successo, il client termina la comunicazione inviando il carattere.

18 18 Capitolo 3. Il client 3.2 Verifica È possibile inoltre verificare se un dato certificato sia valido o meno come mostrato in Figura 2.2 a Pagina 13. Questa funzione viene decisa all inizio del lancio dell applicazione sia server che client. I passi per la verifica sono l esecuzione del software in modalità di verifica: java GERIVE_server -v. 1. Viene mostrato il nome dell applicazione e il suo scopo, inoltre viene richiesto il nome del certificato da verificare ad esempio prova.der: ************************************************************************ * Università di Milano * * Laboratorio di crittografia applicata Prof. Stelvio Cimato * * Studente: Massimo Manara mat.: GERIVE - Client Verifica * * a.a. 2006/2007 * ************************************************************************ Nome del certificato?: prova.der 2 A seguito dell invio del certificato al server, si ottiene l esito della verifica sulla validità della data e sulla verifica della firma: -->1) Invio al server il certificato: OK! Certificato valido! Certificato verificato!

19 Bibliografia [Cas07] Bouncy Castle. Data accesso 30 giugno [DA07] T. Dierks and C. Allen. The tls protocol version Data accesso 30 giugno [HFPS07] R. Housley, W. Ford, W. Polk, and D. Solo. Internet x.509 public key infrastructure certificate and crl profile Data accesso 30 giugno [Hoo05] David Hook. Beginning Cryptography with Java. Wiley Publishing, Inc, 2005.