Sicurezza su Reti II Prof. Alfredo De Santis

Transcript

1 UNIVERSITA DEGLI STUDI DI SALERNO FACOLTA DI SCIENZE MATEMATICHE FISICHE E NATURALI LAUREA SPECIALISTICA IN INFORMATICA ANNO ACCADEMICO Sicurezza su Reti II Prof. Alfredo De Santis SIMULAZIONE DI UNA CERTIFICATION AUTORITY GRUPPO CA: Cerqua Rosaria D Arienzo Loredana Di Giampaolo Barbara Di Matteo Antonio Emilio

2 INDICE 1. INTRODUZIONE 2. CA: CERTIFICATION AUTHORITY 2.1 PUBLIC KEY INFRASTRUCTURE 2.2 CERTIFICATION AUTHORITY E REGISTRATION AUTHORITY 2.3 DOVERI DELLA CA SCHEDA TECNICA DEI SERVIZI OFFERTI DALLA CA 2.4 DOVERI DEL SOTTOSCRITTORE 2.5 DOVERI DI TERZE PARTI COINVOLTE 2.6 OBBLIGHI PER L AUTENTICAZIONE 3 ORGANIZZAZIONE DEL PROGETTO 3.1 DECISIONI DEL GRUPPO 3.2 SERVIZI FORNITI 3.3 STRUMENTI SOFTWARE 3.4 INSTALLAZIONE SOFTWARE 3.5 MANUALE UTENTE 3.6 MANUALE AMMINISTRATORE 4. FASE DI TUNING 4.1 SERVIZI RICHIESTI 4.2 RICHIESTE EFFETTUATE 4.3 RICHIESTE RICEVUTE 5. COMMESSE 5.1 PRIMA COMMESSA GENERALITA SULLA FIRMA DIGITALE LEGISLAZIONE VIGENTE ADEMPIMENTI LEGISLATIVI PER LA CREAZIONE DELLA FIRMA DIGITALE STRUMENTI SOFTWARE E PROCEDURE DI SETUP PROCEDURE PER L UTENTE 5.2 SECONDA COMMESSA GENERATORI DI CHIAVI

3 5.2.2 GENERATORI DI PASSWORD 6 APPLICAZIONE PRODOTTA 6.1 DESCRIZIONE 6.2 MANUALE D USO 7 BIBLIOGRAFIA

4 1. INTRODUZIONE Nel corso di Sicurezza II, tenutosi nell anno accademico 2004/05 è stata realizzata un Internet locale attraverso i gruppi CA, ISP1, ISP2, CERT. Cerqua Rosaria,D Arienzo Loredana,Di Giampaolo Barbara,Di Matteo Antonio Emilio sono stati i componenti del gruppo CA( Certification Authority ), ed hanno simulato, in tutti i doveri, un autorità di certificazione. La seguente, è una rapida panoramica del contenuto del presente documento: Capitolo 2: è descritto tutto ciò che concerne un autorità di certificazione e il contesto in cui essa è presente. Capitolo 3: è descritta l organizzazione generale del gruppo CA, specificando risorse hardware, strumenti software e l installazione del software utilizzato, riportando alla fine del capitolo il manuale utente e amministratore della CA prodotta. Capitolo 4: è descritta la fase di tuning tenutasi con gli altri gruppi, specificando i servizi richiesti dal gruppo CA, oltre alle richieste ricevute ed effettuate. Capitolo 5: sono descritte le commesse assegnate al gruppo, con le soluzioni proposte e i gruppi coinvolti. Capitolo 6: è descritta una libreria prodotta che consente la generazione di una chiave di sessione per la cifratura simmetrica, la cifratura di un file con TripleDES-EDE in modalità CBC, la generazione di una coppia di chiavi privata e pubblica per RSA, la cifratura di un file con RSA, e la firma di un file attraverso la combinazione di SHA-1 ed RSA.

5 2. CA: CERTIFICATION AUTHORITY All interno del capitolo è descritto il contesto di un Autorità di Certificazione con i dettagli relativi ad essa. 2.1 PUBLIC KEY INFRASTRUCTURE Una Certification Authority è una delle componenti più importanti della Public Key Infrastructure(PKI). La PKI rappresenta una soluzione per la sicurezza in rete. Con questo acronimo si definisce il complesso insieme di procedure, tecniche, elaborazioni teoriche e pratiche che permettono di implementare un sistema di crittografia a chiave pubblica basato sui certificati digitali (Cryptography and Network Security: Principles and Practice (3rd Edition) by William Stallings, 2003 ). L obiettivo è quello di definire un metodo veramente sicuro per scambiare informazioni e per accedere alle risorse disponibili nell ambito di un organizzazione, una comunità, un azienda, o nel mondo intero. Tra le componenti di una PKI vi sono: Certification Authority (CA): ha il compito di emettere, consegnare e revocare i certificati; Registration Authority (RA): ha il compito di verificare il legame tra le chiavi pubbliche e le identità dei possessori; Soggetti o possessori dei certificati: persone, organizzazioni, macchine o software per i quali è stato emesso un certificato e che possono usarlo per firmare i propri documenti; Clienti: questi validano le firme digitali e la propria catena di certificati attraverso la chiave pubblica di una CA fidata; Repository: contenitore per le chiavi publiche, i certificati e la lista dei certificati revocati o Certificate Revocation List (CRL); Politica di sicurezza: stabilisce e definisce la direzione che viene scelta, ad alto livello, per l organizzazione della sicurezza, così come tutti i processi ed i principi per l uso della crittografia.

6 2.2 CERTIFICATION AUTHORITY E REGISTRATION AUTHORITY Un Autorità di Certificazione è un autorità accreditata, responsabile dell emissione dei certificati, utilizzati per l identificazione di una comunità di individui o di sistemi o di altre identità che utilizzano una rete informatica, e della revoca di un certificato precedentemente emesso (vedi Figura 1 e Figura 2). Firmando in modo digitale i certificati emessi, l Autorità di Certificazione unisce l identità del possessore del certificato ad una chiave d accesso all interno del certificato stesso, facendosi così garante della validità di quest ultimo. Essa può usare un numero indefinito di RA e svolgere il ruolo di RA se l autenticazione dell entità viene svolta dalla stessa CA. Le Autorità di Registrazione (RA) sono necessarie per ottenere l identificazione e l autenticazione fisica delle entità (vedi Figura 1 e Figura 2). Le RA non devono essere autorizzate ad emettere certificati. Una Registration Authority (RA) è un individuo, oppure un gruppo di persone facenti parte di un organizzazione o di un unità organizzativa, accreditati da una CA in qualità di referente per la registrazione di nuove entità finali che chiedono il rilascio di un certificato. Le RA hanno il compito di controllare in modo appropriato l identità dei richiedenti e devono firmare un accordo con la CA che rilascia i certificati, in cui é previsto l obbligo di aderire alle sue procedure. Figura 1 Interazione tra CA, RA ed entità finali per l emissione di un certficato.

7 Figura 2 Interazione tra CA, RA ed entità finali per la revoca di un certificato. 2.3 DOVERI DELLA CA Considerando che la RA ha il compito di fornire, in quanto Autorità di Registrazione, l autenticazione dell identità del soggetto, la convalida della corrispondenza tra una chiave pubblica e l identità del richiedente, la conferma di tale convalida nei confronti della CA, si è deciso, in seguito alla visione dei dovuti documenti, di far rivestire tali compiti alla CA stessa; per cui i principali doveri di una CA sono: autenticare l identità del soggetto; convalidare la corrispondenza tra una chiave pubblica e l identità del richiedente, attraverso un metodo di verifica opportuno; gestire le richieste di certificazione e l emissione di nuovi certificati; accettare e confermare le richieste di certificazione da parte di entità richiedenti un certificato; rilasciare certificati sulla base delle richieste autenticate; rendere pubblicamente disponibili i certificati emessi; occuparsi delle richieste di revoca dei certificati e della revoca degli stessi; accettare e confermare le richieste di revoca da parte di entità richiedenti; rendere le CRL pubblicamente disponibili.

8 2.3.1 SCHEDA TECNICA DEI SERVIZI OFFERTI DALLA CA Registrazione: questo è il processo attraverso il quale il richiedente si presenta alla CA, per cercare di ottenere un certificato; durante la procedura viene richiesto al soggetto di fornire i propri attributi, come il nome, l indirizzo , il numero di telefono ed altre informazioni, seguendo le specifiche CPS (Certification Practices Statement) della CA; quindi la CA segue le linee guida specificate nel CPS, per verificare che i dettagli forniti dal soggetto siano corretti, prima di emettere il certificato; Certificazione: è il processo attraverso il quale la CA emette un certificato che contiene la chiave pubblica del soggetto, lo pubblica in un repository pubblico ed accessibile a tutti permettendo di scaricarlo; Revoca o annullamento: nella maggior parte dei casi, un certificato rimane valido fino a quando non viene raggiunta la data di scadenza. Ci sono, comunque, un certo numero di situazioni in cui è necessaria una revoca prematura del certificato, ad esempio: il soggetto ha cambiato nome; un impiegato lascia la compagnia che ha emesso il certificato; si è verificata una compromissione (o una sospetta compromissione) della chiave privata. Il metodo stabilito per la revoca dei certificati include l uso di una Certificate Revocation List (CRL), che raccoglie i certificati revocati (normalmente ogni certificato è identificato da un numero seriale unico, assegnato nel momento dell emissione) ed è firmata, con tanto di data, dalla CA; la CA pubblica la CRL ad intervalli regolari, nello stesso repository pubblico. Un certificato la cui corrispondente chiave privata sia stata compromessa deve essere revocato il più presto possibile, subito dopo che la compromissione è stata scoperta; altrimenti, se la CRL non venisse pubblicata per molti giorni, dopo la revoca del certificato, gli utenti non sarebbero a conoscenza del problema e potrebbero accettare messaggi firmati da un intruso con la chiave privata rubata; comunque, anche se la CRL fosse pubblicata immediatamente dopo la revoca, non ci sarebbe garanzia che gli utenti ne vengano a conoscenza in tempo. Una CRL permette ai clienti ed ai server di controllare se l entità con cui stanno dialogando possiede un certificato valido. Il CRL è un file binario che contiene le seguenti informazioni:

9 lista di certificati revocati e ragione della revoca; emissario della CRL; data di emissione della CRL; data di pubblicazione della prossima versione della CRL. È importante specificare che quando la CA, che aveva originariamente emesso il certificato, lo revoca, firma digitalmente la CRL: in questo modo, l utente finale che controlla la CRL può essere sicuro dell attendibilità delle informazioni che la CRL contiene. Si accede ad una CRL quando si ha bisogno di usare un certificato contenente una chiave pubblica per crittografare dati da inviare ad un particolare destinatario, o per verificare la firma digitale presente in un messaggio ricevuto. Quando si ha una qualsiasi di queste due necessità, si eseguono le seguenti operazioni: si ottiene il certificato digitale richiesto; si ottiene il numero seriale del certificato; si ottiene la CRL (si accede al proprio repository locale di CRL); si controlla la firma digitale della CRL, la data di pubblicazione e la data di prossima pubblicazione; si controlla la CRL per determinare se il certificato che si intende usare è stato revocato o sospeso (basandosi sul numero seriale del certificato). 2.4 DOVERI DEL SOTTOSCRITTORE Un utente deve comportarsi nel rispetto della Certification Practice Statements (CPS) della CA addetta al rilascio di certificati. Tale accordo prevede: lettura e rispetto delle procedure concordate; opportuna custodia della propria chiave privata, in quanto unico possessore, nel caso in cui la sottoscrizione si riferisca a un singolo utente. Nel caso, invece, di una chiave privata rilasciata per un componente hardware o software, la custodia ed il controllo della chiave possono essere affidati alla responsabilità di più di una persona autorizzata; autorizzazione al trattamento ed alla conservazione dei dati personali; immediata notifica alla CA in caso di compromissione della chiave privata.

10 2.5 DOVERI DI TERZE PARTI COINVOLTE Una parte coinvolta deve venire a conoscenza della CPS e della policy utilizzata, prima di trarre alcuna conclusione sulla fiducia da riporre nell utilizzo di un certificato emesso da una CA conforme. Essa, inoltre, deve controllare le CRL, al momento di convalidare l utilizzo dello stesso certificato. 2.6 OBBLIGHI PER L AUTENTICAZIONE Ciascuna CA deve utilizzare un archivio pubblicamente accessibile dove conservare i certificati e le liste di revoca (CRL). L archivio dovrà essere disponibile al pubblico quanto più possibile, compatibilmente con le caratteristiche dell ente che gestisce tecnicamente la CA.

11 3 ORGANIZZAZIONE DEL PROGETTO Nel capitolo è descritta l organizzazione generale del gruppo CA, specificando risorse hardware, strumenti software e l installazione del software utilizzato, riportando alla fine del capitolo il manuale utente e amministratore della CA prodotta. 3.1 DECISIONI DEL GRUPPO Fin dall inizio si è deciso di incontrarsi tutti ad ogni incontro. Tutti abbiamo cercato di fare le stesse cose. Di conseguenza ci siamo ritrovati a risolvere insieme i notevoli problemi avuti soprattutto nella fase di installazione e configurazione dell infrastruttura. Bisogna però riconoscere che Antonio Emilio Di Matteo si è rilevato indispensabile per la terminazione di questa fase. Si è deciso di procedere utilizzando, come supporto, documenti scaricati dalle rete (ad esempio la guida OpenCA Guides for di Chris Covell, Michael Bell) e di installare tutti software open source. Si è dovuto lavorare con un PC avente come processore un Intel 200 MHz MMX, 128 MB di RAM, un HD di 8 GB (QUANTUM FIREBALL). A causa dell hardware a disposizione del gruppo si è verificato un notevole dispendio di tempo, considerando che il tempo per eseguire il più breve make è stato di 30 minuti. 3.2 SERVIZI FORNITI Data l assenza della RA, le attività che la nostra CA svolge sono: Autenticazione dell identità dei richiedenti: identifica con certezza la persona che fa richiesta della certificazione della chiave pubblica; Validazione delle richieste di certificati; Registrazione della chiave: emissione di un certificato per una chiave pubblica; Revoca di un certificato: cancellazione di un certificato precedentemente emesso per motivi come la richiesta di revoca dell interessato stesso, scadenza del periodo di validità del certificato, abusi o falsificazioni del certificato o avanzamento tecnologico;

12 Manutenzione di un archivio dei certificati e delle chiavi pubbliche relative ai possessori; Pubblicazione dei certificati emessi: rilascio e pubblicazioni dei certificati (firmati con la propria chiave privata); Pubblicazione dell elenco dei certificati revocati o sospesi; Remissione dei certificati alla scadenza. Per quanto riguarda le modalità di fornitura dei servizi, esse sono riportate nel paragrafo 3.5. Relativamente ai tempi, ogni operazione richiesta dagli utenti è stata registrata e valutata dalla CA (ricordiamo che la CA è off-line)ed è stata eseguita dalla stessa quando possibile. I costi affrontati dagli utenti sono stati unicamente il tempo di attesa per l esecuzione della richiesta inoltrata alla CA. 3.3 STRUMENTI SOFTWARE I software installati sono: SUSE 9.2: sistema operativo; OpenCA: software principale per la realizzazione della CA; Firestarter: firewall usato per impedire accessi indesiderati; Apache : nel toolkit OpenCA, Apache agisce da interfaccia, in locale, ai programmi di supporto sull host CA. Tale versione è stata scelta per motivi legati alla sicurezza. mod_ssl: fornisce un eccellente crittografia per il web server Apache tramite SSL e TLS, servendosi del toolkit OpenSSL; OpenSLL: toolkit crittografico che implementa SSL (acronimo di Secure Socket Layer) e TLS (acronimo di Transport Layer Security) ed i relativi standard crittografici da essi richiesti. OpenSSL consente l autenticazione alle applicazioni client-server (tramite crittografia a chiave pubblica); garantisce la riservatezza della comunicazione; cifra i dati prima di inviarli su canale pubblico (tramite crittografia a chiave simmetrica), fornisce l integrità dell informazione e la possibilità di negoziazione della cipher_suite fra client e server, oltre alla gestione dei certificati digitali x509; OpenLDAP: server utilizzato per la pubblicazione dei certificati;

13 Perl: fornisce un interfaccia al database MYSQL, si presta bene a sviluppare applicazioni web perché può gestire dati cifrati, incluse le transazioni di commercio elettronico sicuro; MySQL: usato come Data Base Management System. Sendmail : usato per inviare mediante , all atto della generazione del certificato, il CRIN (codice per la revoca del certificato) al richiedente del certificato. 3.4 INSTALLAZIONE SOFTWARE Per motivi di licenze sono stati utilizzati esclusivamente prodotti software freeware; ciò ha facilitato non solo il reperimento del software ma anche l utilizzo, essendo tali prodotti utilizzati da gran parte della comunità telematica, che dissemina attraverso forum e siti web notevoli informazioni sulle installazioni, sui conflitti, sulla risoluzione di problemi di qualsiasi tipo. Sulla macchina assegnata al gruppo CA è stato installato il sistema operativo SuSE Linux 9.2 perché abbastanza affidabile, testato e non eccessivamente complesso da configurare. Tale installazione ha richiesto un notevole dispendio di tempo per le prestazioni della macchina e la scelta minuziosa dei pacchetti indispensabili da installare. Al seguito della installazione, la prima operazione è stata aggiornare il sistema operativo attraverso la rete per reperire dal sito ufficiale della SuSE path, updates e bugfixes. Successivamente si è configurato il sistema, controllando i servizi attivi predefiniti e la sicurezza dell utenza. E stato, poi, creato un solo utente ca al di fuori del superuser root. Il secondo prodotto software installato è stato un firewall, Firestarter 1.0.3, selezionato fra i vari prodotti del settore per la sua fama nei forum degli addetti ai lavori come ottimo firewall per Linux. Firestarter, infatti, si è dimostrato subito all altezza del suo nome bloccando tutte le connessioni non sicure, traffico in entrata ed effettuando il log di qualsiasi evento, come di seguito: Time:May 24 15:05:55 Direction: Inbound In:eth0 Out: Port:445 Source: Destination: Length:48 TOS:0x00 Protocol:TCP Service:Microsoft-ds Time:May 24 15:08:26 Direction: Inbound In:eth0 Out: Port:1026 Source: Destination: Length:908 TOS:0x00 Protocol:UDP Service:Cap

14 Time:May 24 15:12:10 Direction: Inbound In:eth0 Out: Port:445 Source: Destination: Length:48 TOS:0x00 Protocol:TCP Service:Microsoft-ds Si è anche bloccato il tentativo di attacco effettuato dal gruppo CERT, il cui scopo era di rilevare eventuali problemi di sicurezza sulla macchina del gruppo. Nella configurazione di Firestarter sono stati abilitati i servizi web per l interfacciamento del server Apache nelle due tipologie di connessioni offerte (http, porta 80; https, porta 443). Firestarter è stato installato attraverso procedura guidata rpm. La base per ogni altro tipo di software installato successivamente è stato OpenSSL 0.9.7g. Tale software ha richiesto un riguardo scrupoloso agli updates poiché soggetto ad aggiornamenti continui per quanto concerne la sicurezza. OpenSSL è stato installato nella sua locazione storica, /usr/local/ssl, ed utilizzato per la creazione di chiavi e certificati per Apache, successivamente autofirmati dalla CA installata. OpenSSL è, inoltre, fondamentale al fine di fornire al server web Apache la possibilità di effettuare connessioni sicure attraverso il protocollo https; per fare ciò è stato, però, indispensabile installare insieme ad Apache il modulo per la comunicazione fra server web ed OpenSSL, mod_ssl. OpenSSL è stato installato attraverso la classica procedura per sistemi Unix like: configure, make, make test, make install. Il DBMS installato è stato MySQL , attraverso procedura guidata rpm, nella directory /usr/local/mysql_ E stato creato un link simbolico mysql che puntasse alla directory effettiva al fine di non riscontrare problemi di path noti con altri software che ne utilizzassero le funzionalità. La versione di Apache installata, la , è stata obbligata dalla versione relativa al modulo per la sicurezza mod_ssl, non esistente per versioni successive del server web. È da sottolineare che, in seguito alla visione dei dovuti documenti presenti in Internet, tale versione di Apache è anche la più sicura. Insieme ad Apache sono stati installati anche i seguenti moduli: Modulo per OpenSSL Modulo per Perl Modulo per Php L installazione ha previsto la configurazione dei singoli moduli nei sorgenti di Apache e la successiva compilazione ed installazione del server. Come già accennato, mod_ssl è indispensabile al fine di fornire connessioni sicure https; il modulo per il Perl è stato installato per fornire alla CA un ambiente Perl dinamico richiesto dal software OpenCA; il modulo Php è stato installato

15 prevedendo la creazione di pagine web dinamiche, ma non è stato necessario utilizzarlo. Ad ogni modo, tutti i moduli sono stati testati dopo l installazione del server web al fine di assicurarsi della effettiva configurazione andata a buon fine: php e perl sono stati testati con semplici hello world reperiti sulla rete; mod_ssl è stato testato utilizzando in loopback il server web con connessione https. Apache è stato installato in /usr/local/apache. Il server web è stato configurato attraverso il suo file principale di configurazione, httpd.conf. Sono stati creati degli alias per il superuser root per l avvio e la terminazione del server web: apache_start: richiama /usr/local/apache/bin/apachectl start apache_startssl: richiama /usr/local/apache/bin/apachectl startssl apache_stop: richiama /usr/local/apache/bin/apachectl stop Infine è stato installato il software principale ai fini del gruppo per la creazione e la gestione di una autorità di certificazione: OpenCA Tale software ha richiesto la precedente installazione di un ulteriore prodotto software: OpenLDAP, per la gestione del Lightweight Directory Access Protocol, nella versione OpenLDAP è stato installato secondo la procedura standard: configure, make, make install. Nella installazione di OpenCA è stato necessario configurare numerosi parametri per ottenere un corretto utilizzo finale del software: ciò ha richiesto numerose installazioni ripetute prima di giungere alle conoscenze necessarie richieste. La configurazione di OpenCA è stata la fase che ha richiesto il maggior numero di ore lavorative: tale configurazione è stata effettuata modificando parametri in diversi file in formato XML e in file di testo contenenti script PERL. E stato necessario utilizzare il tool openca-digest fornito per effettuare l oscuramento della password nel file di configurazione di accesso all interfaccia web privata per la gestione della CA. Tale interfaccia web è stata configurata come virtual host nel server web Apache, all indirizzo L interfaccia pubblica, che fornisce i servizi di certificazione all utenza, è stata configurata nel server web Apache, ri-direzionando i path per l accesso agli script perl. E stata realizzata una semplice interfaccia web per la home dell autorità di certificazione, come presentazione del gruppo e come collegamento alla interfaccia pubblica CA.

16 Infine sono stati creati due ulteriori alias per il superuser root per l avvio e la terminazione del server ca: openca_start: richiama /usr/local/openca/openca/bin/openca-start openca_stop: richiama /usr/local/openca/openca/bin/openca-stop E stata generata una chiave privata server.key ed un certificato server.csr attraverso le funzionalità di openssl. Tale certificato è stato firmato dalla CA, generando un ulteriore certificato, server.ctr. I tre file così generati sono stati installati nel server web Apache, nelle directory: /usr/local/apache/conf/ssl.key /usr/local/apache/conf/ssl.csr /usr/local/apache/conf/ssl.ctr In questo modo le connessioni https con il server web Apache installato sulla macchina del gruppo possono essere riconosciute come sicure attraverso tale certificato, a patto che si riconosca la fiducia all autorità di certificazione SR2CA. In ultimo è stato installato Sendmail per inviare mediante , all atto della generazione del certificato, il CRIN al richiedente del certificato. 3.5 MANUALE UTENTE L utente si deve collegare al sito il browser visualizza la pagina mostrata in Figura 3, contenente il link Interfaccia Pubblica CA. Figura 3 Pagina principale di accesso ai servizi offerti dalla CA.

17 Cliccando sul link menzionato, viene visualizzata la pagina in Figura 4, contenente i seguenti link: GENERAL, CA Infos, User, Certificates, Requests, Language. Figura 4 Pagina contenente tutti i link utilizzabili dall utente. GENERAL: cliccando su di esso, di default, vengono visualizzati i diversi moduli installati con le rispettive versioni (vedi Figura 4). Cliccando su CA Infos compaiono i seguenti link: Policy; Get CA Certificate: se cliccato, vengono visualizzati i link per scaricare il certificato della CA nei formati desiderati (CRT, PEM, DER, CER, TXT); Certificate Revocation Lists: se cliccato, compaiono i link per visualizzare la lista dei certificati revocati nei diversi formati. Cliccando su User compaiono i seguenti link: Request a Certificate: cliccando su di esso, compaiono i link che consentono di richiedere un certificato. Viene chiesto all utente di compilare un form inserendo i propri dati e di confermare la sottomissione. Dopo aver completato la richiesta, l utente deve recarsi dalla RA scelta (nel nostro caso dalla CA) per l approvazione della richiesta; Get Requested Certificate (scarica il certificato richiesto): cliccando su di esso, viene chiesto all utente di inserire il numero

18 seriale del certificato per poterlo scaricare. Se il certificato è stato generato dalla CA, l utente può scaricarlo, altrimenti viene visualizzato un messaggio di errore; Test Certificate: cliccando su di esso, vengono riportati i dati principali del certificato presentato dal browser; Revoke Certificate: cliccando su di esso, viene visualizzato all utente un form richiedente il numero seriale del certificato da revocare con il CRIN precedentemente ricevuto tramite . Cliccando su Certificates compaiono i link: Valid: cliccando su di esso, viene visualizzata la lista dei certificati validi; Expired: cliccando su di esso, vengono visualizzati i certificati scaduti; Suspended: cliccando su di esso, viene visualizzata la lista dei certificati sospesi; Revoked: cliccando su di esso, viene visualizzata la lista dei certificati revocati; Search: cliccando su di esso, viene visualizzato un form richiedente i dati necessari alla ricerca. Cliccando su Requests compaiono i link: Certificate Requests: cliccando su di esso, viene visualizzata la lista delle richieste di certificato; Certificate Revocation Requests: cliccando su di esso, viene, invece, visualizzata la lista delle richieste di revoca. Cliccando su Language viene fornita all utente la possibilità di scegliere la lingua desiderata. 3.6 MANUALE AMMINISTRATORE Per accedere alla sezione amministrativa di OpenCA l amministratore si deve collegare al sito ; appare una schermata in cui viene richiesto l inserimento di login e password, come è possibile vedere in Figura 5.

19 Figura 5 Pagina di login per l amministratore. Dopo la procedura di autenticazione appare la schermata generale dell interfaccia CA (come vediamo in Figura 6) in cui vengono visualizzati i seguenti link: General, Usual Operations, Active CSRs, Active CRRs, Information, Language, Initialization, Configuration, Node Mangement, Logout. Figura 6 Schermata generale dell interfaccia CA. Cliccando su General vengono visualizzati modulo e versione dei software utilizzati e richiesti da OpenCA (vedi Figura 6). Cliccando su Usual Operation appaiono i seguenti link: Approved Certificate Requests: cliccando su di esso, è possibile visualizzare la lista delle richieste di certificazione approvate dalla CA; per ogni richiesta sono riportati diversi dati, come il nome del richiedente ed il numero seriale della richiesta; Approved Revocation Requests: cliccando su di esso, è possibile visualizzare la lista delle richieste di revoca approvate dalla CA; per ogni

20 richiesta sono riportati diversi dati, come il nome del richiedente ed il numero seriale della richiesta; Issue New CRL: cliccando su di esso, appare una schermata in cui viene richiesto di inserire dei parametri addizionali per la funzionalità richiesta, cioè viene settato il periodo di validità (in giorni) della CRL (Control Revocation List) e le eventuali estensioni (vedi Figura 7); Figura 7 Pagina relativa al link Issue New CRL. Issue Certificates (Automaticly): attraverso questo link viene consentito di selezionare il tipo di ruolo dell operatore ed il ruolo richiesto per l emissione del certificato e viene data la possibilità di confermare i dati, inserendo la password, o di effettuarne il reset(vedi Figura 8); Figura 8 Pagina relativa al link Issue Certificates (Automaticly). Revoke Certificates (Automaticly): attraverso questo link viene consentito di selezionare il tipo di ruolo dell operatore ed il ruolo richiesto

21 per la revoca del certificato e viene data la possibilità di confermare i dati, inserendo la password, o di effettuarne il reset (vedi Figura 8). Cliccando su Active CSRs appaiono, invece, i seguenti link: New: cliccando su di esso, appare la lista delle nuove richieste di certificazione. Per ogni richiesta vengono visualizzati il numero seriale della richiesta, i dati del richiedente, la data della richiesta, il ruolo richiesto ed il livello di affidabilità richiesto (vedi Figura 9); Figura 9 Pagina relativa al link New di Active CSRs. Cliccando sul seriale della richiesta è possibile visualizzare tutte le informazioni relative alla richiesta e l amministratore può decidere di modificare la richiesta (Edit Request), cancellare la richiesta (Delete Request), rilasciare il certificato (Issue Certificate), come si può vedere in Figura 10. Figura 10 Pagina relativa al link Serial mostrato in Figura 9.

22 Se l amministratore clicca su Edit Request è possibile modificare la richiesta nei suoi singoli campi (vedi Figura 11). Figura 11 Pagina relativa al link Edit Request mostrato in figura 10. Se l amministratore clicca su Issue Certificate viene richiesto di immettere la password della CA e, dopo la sottomissione, viene rilasciato il certificato (vedi Figura 12); Figura 12 Pagina relativa al link Issue Certificate mostrato in Figura 10. Renewed: cliccando su di esso, appare la lista delle richieste rinnovate di cui vengono specificati alcuni dati come l operatore, il numero seriale, ecc ; Pending: cliccando su di esso, appare la lista delle richieste pendenti, cioè quelle in attesa di approvazione, delle quali viene specificato il numero

23 seriale, il richiedente, la data, il ruolo richiesto ed il livello di affidabilità richiesto (vedi Figura 13); Figura 13 Pagina relativa al link Pending. Cliccando sul seriale della richiesta è possibile modificare la richiesta (cliccando su Edit Request), rilasciare il certificato (cliccando su Issue Certificate), oppure cancellare la richiesta (cliccando su Delete Request), come è mostrato in Figura 14. Figura 14 Pagina relativa al link Numero seriale mostrato in Figura 13. Waiting for additional assignature: cliccando su di esso, viene mostrata la lista dei certificati già firmati che hanno bisogno di un ulteriore firma; Approved: cliccando su di esso, appare le lista delle richieste di certificazione approvate di cui vengono visualizzate varie informazioni come l operatore, il numero seriale, ecc ; Cliccando su Active CRRs appaiono i seguenti link:

24 New: cliccando su di esso, appare la lista delle nuove richieste di revoca dei certificati. Per ogni richiesta vengono visualizzati il numero seriale della richiesta, i dati del richiedente, la data della richiesta, il ruolo richiesto ed il livello di affidabilità richiesto; Pending: cliccando su di esso, appare la lista delle richieste di revoca pendenti, cioè quelle in attesa di approvazione, delle quali viene specificato il numero seriale del certificato, il richiedente e la data di richiesta; Waiting for additional assignature: cliccando su di esso, viene mostrata la lista delle richieste di revoca che hanno bisogno di un ulteriore firma; per ogni richiesta vengono visualizzati campi come l operatore, il seriale del certificato, il nome del richiedente, la data della firma, il ruolo richiesto; Approved: cliccando su di esso, appare la lista delle richieste di revoca approvate di cui vengono visualizzati i seguenti campi: operatore, seriale del certificato, nome del richiedente, data di approvazione. Cliccando sul seriale del certificato viene visualizzata una pagina nella quale si ha la possibilità di revocare il certificato cliccando sul bottone Revoke Certificate ed inserendo la password della CA. Nel momento in cui la richiesta di revoca viene approvata, il certificato passa dallo stato di validità a quello di sospensione; Cliccando su Information appaiono i seguenti link: Certificate Requests: cliccando sul link Archived viene visualizzata la lista delle richieste di certificazione archiviate (vedi Figura 15), mentre cliccando su Deleted viene visualizzata la lista delle richieste di certificazione cancellate (vedi Figura 16);

25 Figura 15 Pagina relativa al link Archived. Figura 16 Pagina relativa al link Deleted. Revocation Requests: permette di visualizzare le richieste di revoca; Certificates: cliccando su di esso, è possibile visualizzare: i certificati validi (tramite il link Valid) di cui vengono specificati il seriale, il nome, l ed il ruolo; i certificati scaduti (tramite il link Expired) di cui sono specificati il seriale, il nome, l ed il ruolo; la lista dei certificati sospesi (tramite il link Suspended) dei quali sono specificati il seriale, il nome, l ed il ruolo; la lista dei certificati revocati (tramite il link Revoked). Ca Certificates: tramite questo link è possibile visualizzare i certificati validi e quelli scaduti della CA; inoltre, cliccando sul seriale del certificato è possibile scaricarlo scegliendo il formato desiderato;

26 CRLs: permette di visualizzare la lista di tutti i certificati revocati. Cliccando su Language è possibile scegliere la lingua desiderata. Cliccando su Initialization appare una schermata che permette di inizializzare l infrastruttura a chiave pubblica attraverso tre fasi (vedi Figura 17). Figura 17 Pagina relativa al link Initialization. Prima fase: Initialize the Certification Authority. Questo link viene usato quando si esegue OpenCA per la prima volta (quindi si deve inizializzare la stessa CA) o quando si deve importare il certificato approvato dalla root CA. Ci sono diversi link (vedi Figura 18) che permettono di effettuare: inizializzazione del database (vengono mostrate le istruzioni sql); inizializzazione delle chiavi (permette di generare una nuova chiave segreta della CA. Si deve specificare l algoritmo per la generazione delle chiavi, l algoritmo per la cifratura della chiave e la lunghezza della chiave); inizializzazione della richiesta (permette di stabilire i campi necessari per una richiesta di certificazione alla CA); setup del certificato; ultimi passi.

27 Figura 18 Pagina relativa al link Initialize the Certification Authority. Seconda Fase: Create the initial administrator. Questo link serve ad inizializzare il primo utente dell infrastruttura a chiave pubblica che è l amministratore. A tal fine vengono visualizzati i passi da seguire (vedi Figura 19): generare una nuova richiesta; modificare la richiesta; rilasciare il certificato; scaricare il certificato. Figura 19 Pagina relativa al link Create the initial administrator. Terza Fase: Create the initial RA Certificate. Questo link viene utilizzato per creare il primo certificato server dell infrastruttura a chiave pubblica e l utente dovrebbe essere un web server. A tal fine vengono visualizzati i passi da seguire (vedi Figura 20):

28 generare una nuova richiesta; modificare la richiesta; rilasciare il certificato; scaricare il certificato. Figura 20 Pagina relativa al link Create the initial RA Certificate. Cliccando su Configuration compaiono i seguenti link: Roles: cliccando su di esso, appare la lista dei ruoli disponibili nell infrastruttura a chiave pubblica, in cui si può anche aggiungere un ruolo (vedi Figura 21); Figura 21 Pagina relativa al link Roles. Rights: cliccando su di esso, vengono mostrati i diritti, identificati dal modulo, operatore, operazione, proprietario. E permesso cancellare un singolo diritto o aggiungere nuovi diritti (vedi Figura 22);

29 Figura 22 Pagina relativa al link Rights. Modules: cliccando su di esso, vengono mostrati i moduli disponibili nell infrastruttura a chiave pubblica, identificati dal numero, descrizione ed è possibile anche cancellarli (vedi Figura 23); Figura 83 Pagina relativa al link Modules. Sign the configuration: cliccando su di esso, viene permesso di approvare la configurazione inserendo la password; Cliccando su Logout viene permesso di uscire dalla sessione.

30 4. FASE DI TUNING Nel capitolo sono descritti i servizi richiesti dal gruppo CA, oltre alle richieste ricevute ed effettuate. 4.1 SERVIZI RICHIESTI La CA necessitava della registrazione del dominio effettuata dal gruppo ISP1. Collegandosi a tale dominio un qualsiasi utente può effettuare diverse richieste (la richiesta di un certificato o della sua revoca). Il gruppo ISP1, oltre a fornire la registrazione del dominio, fornisce anche il servizio di whois, cioè tramite software, l ISP1, permette di riconoscere l identità dell intestatario del dominio. 4.2 RICHIESTE EFFETTUATE La CA ha richiesto all ISP1 la registrazione del dominio RICHIESTE RICEVUTE La CA ha rilasciato, in seguito all apposita richiesta di certificazione, due certificati al gruppo ISP1 con numero seriale 28 in qualità di USER e 31 in qualità di WEB SERVER; tre certificati al gruppo ISP2 con numeri seriali 20, 22, 24, rispettivamente, in qualità di OPERATOR, WEB SERVER, WEB SERVER; infine, un certificato al gruppo CERT con numero seriale 12 in qualità di USER. Tali certificati sono tutti ancora validi, sia perchè il loro periodo di validità non è ancora terminato, sia perché nessun gruppo ne ha richiesto la revoca.

31 5. COMMESSE Nel capitolo sono descritte le commesse assegnate al gruppo, con le soluzioni proposte e i gruppi coinvolti. 5.1 PRIMA COMMESSA Si procede prima ad una breve descrizione della commessa che è stata assegnata al gruppo, poi vengono indicate le soluzioni proposte dal gruppo per finire con il menzionare gli altri gruppi che hanno preso parte alla relativa commessa. DESCRIZIONE Lo studio notarile De Notaris & Figli di Torre del Greco intende documentarsi sulla legislazione vigente sulla firma elettronica, sulle infrastrutture di cui dotarsi per la produzione e l invio di documenti legalmente riconosciuti. Il gruppo CA deve occuparsi di: individuare gli strumenti software necessari; descrivere le procedure per il setup dei software prescelti; descrivere gli adempimenti formali/organizzativi necessari al cliente per dotarsi di tale servizio. SOLUZIONE PROPOSTA GENERALITA SULLA FIRMA DIGITALE Le firme digitali possono: autenticare l identità di chi ha firmato i dati; proteggere e garantire l integrità dei dati contro manomissioni accidentali o dolose; consentire di dimostrare successivamente l identità dell autore di una transazione. Il commercio elettronico richiede che molte transazioni siano riservate. La stessa tecnologia usata per le firme digitali può essere adottata per cifrare i dati e

32 renderli illeggibili a chiunque non sia il destinatario. Affinché un informazione possa essere cifrata in modo da essere leggibile solo da un particolare utente, questi deve essere titolare di un proprio Certificato Digitale. La crittografia a chiave pubblica è usata per assicurare la riservatezza dell informazione, ma fornisce anche un altra funzione vitale per un sicuro scambio d informazioni elettroniche: l autenticazione. L autenticazione, in questo contesto, indica il processo che il destinatario di un messaggio elettronico deve seguire per verificare sia l integrità del messaggio che l identità del mittente. Come la crittografia è usata per garantire la riservatezza, la firma digitale è usata per garantire l autenticità. Per creare una firma digitale, il mittente crea un hash, una versione condensata del messaggio, ed utilizza la sua chiave privata per cifrarlo; il risultato di questa operazione è la firma digitale. Se il messaggio viene modificato in qualsiasi modo, l hash risultante dal messaggio modificato sarà diverso. La firma digitale, in questo modo, garantisce sia il contenuto del messaggio che l identità del mittente; essa viene spedita come allegato del messaggio; il destinatario ricrea l hash del messaggio ricevuto, quindi decifra la firma digitale utilizzando la chiave pubblica del mittente: se i due hash sono identici risultano verificate sia l identità del mittente che l integrità del messaggio. L esattezza della trasmissione dei documenti sarà garantita dal metodo della firma digitale, strumento mediante il quale, facendo ricorso alla procedura della crittografia, si attesta con certezza la paternità, la validità e l integrità di un documento elettronico. La Firma Digitale è l equivalente informatico della tradizionale firma su carta; non sarà pertanto più necessaria la firma autografa per garantire la validità di un documento. Per consentire il massimo della sicurezza, la firma digitale è ospitata su un supporto o smart card, una carta a microprocessore immodificabile, personalizzata e protetta da un codice segreto LEGISLAZIONE VIGENTE Il Decreto del Presidente della Repubblica 10 novembre 1997, n.513 definisce il documento informatico come la rappresentazione informatica di atti, fatti o dati giuridicamente rilevanti e la firma digitale quale risultato della procedura informatica (validazione) basata su un sistema di chiavi asimmetriche a coppia, una pubblica e una privata, che consente al sottoscrittore tramite la chiave privata e al destinatario tramite la chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l integrità di un documento informatico o di un insieme di documenti informatici. Il Decreto del Presidente della Repubblica del 7 aprile 2003, n.137 definisce il regolamento recante disposizioni di coordinamento in materia di firme

33 elettroniche a norma dell articolo 13 del decreto legislativo 23 gennaio 2002, numero 10. L articolo 1 di tale decreto presenta le seguenti definizioni di firme: Firma elettronica(non qualificata); Firma elettronica avanzata; Firma elettronica qualificata; Firma digitale. La Firma Elettronica (non qualificata, lett. cc) è definita come: l insieme dei dati in forma elettronica, allegati oppure connessi tramite associazione logica ad altri dati elettronici, utilizzati come metodo di autenticazione informatica. La Firma Elettronica Avanzata è definita come: la firma elettronica ottenuta attraverso una procedura informatica che garantisce la connessione univoca al firmatario e la sua univoca identificazione, creata con mezzi sui quali il firmatario può conservare un controllo esclusivo e collegata ai dati ai quali si riferisce in modo da consentire di rilevare se i dati stessi siano stati successivamente modificati. La Firma Elettronica Qualificata è definita come: la firma elettronica basata su un certificato qualificato e creata mediante un dispositivo sicuro per la creazione della firma. La Firma Digitale è definita come: un particolare tipo di firma elettronica qualificata basata su un sistema di chiavi asimmetriche a coppia, una pubblica e una privata che consente al titolare tramite la chiave privata ed al destinatario tramite la chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l integrità di un documento informatico o di un insieme di documenti informatici. L articolo 4 sancisce che I contratti stipulati con strumenti informatici o per via telematica mediante l uso della firma elettronica qualificata sono validi e rilevanti a tutti gli effetti di legge. L Articolo 5 sancisce che Il documento informatico, sottoscritto con firma digitale ai sensi dell articolo 10, ha efficacia di scrittura privata ai sensi dell articolo 2702 del codice civile.

34 5.1.3 ADEMPIMENTI LEGISLATIVI PER LA CREAZIONE DELLA FIRMA DIGITALE In termini legislativi, per creare la firma digitale è necessario un software adeguatamente configurato o un hardware, definiti come dispositivo per la creazione della firma (art. 1, lett. hh); inoltre, il titolare, cioè la persona fisica cui è attribuita la firma digitale e che ha accesso al suddetto dispositivo (non sicuro) di firma (art. 1, lett. ff), per poterla creare, deve utilizzare dati peculiari come codici o chiavi crittografiche private (art. 1, lett. gg) STRUMENTI SOFTWARE E PROCEDURE DI SETUP Tra i vari software, per la firma legale di un documento, il gruppo ha scelto di descrivere Signo (strumento software, costo 6 iva esclusa) e Sysgillo (strumento software, costo 32,89 iva esclusa) per la loro facilità di installazione, le caratteristiche tecniche supportate e i costi contenuti. Per la produzione e l invio di documenti legalmente riconosciuti viene utilizzata OpenCA (infrastruttura per la gestione di certificati firmati digitalmente). Con Signo e Sysgillo è possibile firmare e cifrare qualsiasi tipo di documento o file elettronico, verificare firme digitali, essere certo dell identità dei propri corrispondenti, ottenere piena interazione con il dispositivo di firma (Smart Card), apporre firme multiple sul medesimo documento. Le caratteristiche tecniche di Signo e Sysgillo sono le seguenti: algoritmi supportati: RSA, DES, MD5, SHA-1, RIPEMD-160; conformità agli standard: sono conformi agli standard internazionali X.509v3, X.509v4; conformità alle normative: sono conformi ai requisiti di legge italiana sulla firma digitale (DPR 445/00, DPCM 8 febbraio 99) ed alla direttiva europea 1999/93/CE. PROCEDURA DI INSTALLAZIONE DI SIGNO Per installare Signo si devono compiere i seguenti passi: Fare doppio click sull eseguibile di installazione (Signo2.3.0.exe);

35 Seguire le informazioni riportate a video; Terminata l installazione, riavviare il PC. PROCEDURA DI INSTALLAZIONE DI SYSGILLO Per installare Sysgillo si devono compiere i seguenti passi: Chiudere eventuali applicazioni attive; Eseguire il programma SysGilloDeskTOP.exe; Seguire le informazioni riportate a video; Terminata l'installazione, riavviare il PC. PROCEDURA DI INSTALLAZIONE DI OPENCA Vedi sezione 3.4 INSTALLAZIONE SOFTWARE PROCEDURE PER L UTENTE In questa sezione viene spiegato come poter realizzare la firma legale di un documento attraverso i due software che abbiamo analizzato, Signo e Sysgillo, e come poter eseguire la procedura di certificazione mediante OpenCA. FIRMA LEGALE DI UN DOCUMENTO CON SIGNO Per realizzare la firma legale di un documento con Signo i passi da seguire sono i seguenti: Inserire il supporto contenente il certificato nell apposito lettore (lettore IPM per la smart card); Aprire Signo; Selezionare il menu Strumenti => Opzioni ; Si aprirà il Pannello di Configurazione (vedi Figura 24);

36 Figura 24 Pannello di configurazione. Selezionare Smart Card come dispositivo contenente il certificato e chiave personale; Fare click sul pulsante Ricerca SmartCard ; Se il supporto utilizzato (smart card) contiene più di un certificato, occorre assicurarsi di selezionare quello di Firma Elettronica Qualificata; Fare click sul pulsante Applica e poi Chiudi (vedi Figura 25); Selezionare Imbusta Documento Informatico ; Figura 25 Pannello di selezione del certificato. Selezionare il documento da firmare; L applicazione aprirà il documento selezionato affinché se ne possa verificare il contenuto (vedi Figura 26); Fare click sul pulsante Chiudi ;

37 Figura 26 Pannello che mostra il documento da firmare. Selezionare Firma ( vedi Figura 27); Figura 27 Pannello utilizzato per la firma del documento. Inserire il PIN della smart card(vedi Figura 28); Figura 28 Pannello per l inserimento del PIN della smart card.

38 L applicazione completa la procedura di firma e ne fornisce l esito. Verificare che tutti gli step siano stati correttamente eseguiti e selezionare Chiudi (vedi Figura 29); Figura 29 Pannello che fornisce l esito dell operazione di firma. Chiudere Signo e selezionare l opzione Salva e chiudi come mostrato in Figura 30 (al passo successivo, salvare le modifiche al Database; se richiesto, inserire nuovamente il PIN); Figura 30 Pannello di chiusura di Signo. L applicazione genera un file con estensione.p7m che include il documento firmato e la chiave pubblica del firmatario.

39 FIRMA LEGALE DI UN DOCUMENTO CON SYSGILLO Per realizzare la firma legale di un documento con Sysgillo i passi da seguire sono i seguenti: Inserire la smart card nel lettore; Fare doppio click su SysGilloDeskTop; L applicazione aprirà un prompt per la selezione del certificato di firma (vedi Figura 31). Se la smart card utilizzata contiene più di un certificato, occorre assicurarsi di selezionare quello di Firma Elettronica Qualificata; Figura 31 Prompt per la selezione del certificato di firma. Fare click su Nuovo profilo e inserire il PIN (quello di default è ). Fare click su OK e attendere il termine del processo di importazione (vedi Figura 32); Figura 32 Pannello di inserimento del PIN. Fare click con il tasto destro del mouse sul file da firmare; Scegliere SysGilloDeskTop e poi Firma Legale ; L applicazione proporrà il seguente prompt:

40 Figura 33 Pannello che consente di verificare il contenuto del documento. Fare click su Esamina (vedi figura 33): l applicazione aprirà il file per consentire di verificarne il contenuto; Dopo averlo esaminato, chiudere il documento e selezionare Firma (vedi Figura 34); Figura 34 Pannello che consente di firmare il documento. Inserire il PIN della smart card come mostrato in Figura 35 (quello di default è ); Figura 35 Pannello che consente di inserire il PIN della smart card. Attendere il termine della procedura di firma (vedi Figura 36);