Studio e implementazione di una architettura PKI in ambito...

UNIVERSITÀ DEGLI STUDI DI MILANO Facoltà di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea in Informatica

“Studio e implementazione di una architettura PKI in ambito industriale: definizione dei requisiti, caratteristiche comparative ed

implementazione di una soluzione” Relatore: Prof. Roberto Bisiani Correlatori: Stefano Pisati Prof.ssa Emilia Rosti Tesi di Laurea di: Alessandro Magnolo Matricola: 521753

Anno Accademico 1998 - 1999

Saluto

Auguro a tutti i lettori di poter trovare in questo documento informazioni utili ed interessanti. Eventuali aggiornamenti, revisioni ed altro materiale collegato saranno pubblicati nel sito http://i.am/amagnolo. Sono a disposizione per discutere di critiche, suggerimenti e richieste di chiarimenti: il mio indirizzo e-mail è [email protected]. L'Autore

Avvertenza

Questo documento è a distribuzione gratuita; il materiale contenuto è copyright © 2000 Alessandro Magnolo. Questa versione del documento non consente la stampa, la copia e la modifica del testo. In caso di esigenze particolari, si può richiedere una versione dotata di queste funzionalità scrivendo all'indirizzo [email protected].

Introduzione

- I -

Introduzione

“L’infrastruttura di crittografia a chiave pubblica è una tecnologia fondamentale che è scalabile per realizzare la sicurezza

all’interno di un’impresa, in Internet, ed infine per l’intera società” Eric C. Limits

La crittografia a chiave pubblica consente di realizzare una serie di servizi per la protezione dei dati, lo scambio sicuro di informazioni ed il commercio elettronico. Fino a poco tempo fa, la mancanza di uno standard riconosciuto ha impedito la crescita del mercato e l’implementazione diffusa di infrastrutture interoperabili. In seguito alla definizione, da parte dell’IETF, di uno standard (PKIX) adottato da tutti i maggiori produttori di soluzioni PKI, si aprono delle prospettive interessanti per la realizzazione dei benefici derivanti dall’impiego diffuso di questa tecnologia. Una infrastruttura PKI consiste in un sistema di certificati digitali, rilasciati da autorità di certificazione riconosciute, che verificano ed autenticano l’identità di ogni partecipante ad una transazione elettronica attraverso l’impiego della crittografia a chiave pubblica. Scopo di questa tesi è lo studio delle funzionalità richieste ad una PKI in ambito industriale, attraverso la modellazione di una soluzione ideale, e la successiva ricerca e prova di una soluzione commerciale in grado di rispondere ai requisiti individuati. Il lavoro è articolato in tre fasi distinte. La prima fase (capitolo 1) consiste nell’analisi dei requisiti per l’impiego di una PKI a livello industriale, corredata dello studio degli standard attuali e dalla modellazione di una soluzione ideale. I requisiti individuati richiedono una serie di servizi forniti agli utenti, che sono firma elettronica, cifratura di dati, autenticazione forte, non ripudio, e marcatura temporale. Le applicazioni che sfruttano tali servizi sono quelle relative al controllo dell’accesso, posta elettronica, pubblicazione di documenti ed applicazioni su web, cifratura di reti private virtuali su reti pubbliche, commercio elettronico. Dal punto di vista gestionale, si considerano le problematiche relative a scalabilità, interoperabilità con altre infrastrutture, interazione con le applicazioni, gestione dei certificati, gestione delle chiavi, sicurezza. La sezione relativa agli standard (paragrafo 1.2) propone una panoramica dei protocolli e degli algoritmi di uso corrente nell’ambito PKI, in particolare riguardo agli standard emergenti come dominatori del mercato quali LDAP per il servizio di directory, X.509 come formato per i certificati, e PKIX quale standard per l’interoperabilità delle diverse infrastrutture. Conclude la prima fase l’elaborazione di un modello teorico di una soluzione PKI ideale, chiamata iPKI. Queste sono le sue caratteristiche salienti:

• organizzazione gerarchica, basata su PKIX; • utilizzo di dispositivi di autenticazione forte (smart card); • distinzione delle chiavi di cifratura e di firma/autenticazione;

Introduzione

- II -

• meccanismo di key recovery; • una interfaccia che richiede poche e semplici scelte da parte degli utenti finali,

svolgendo in automatico le operazioni amministrative, quali ad esempio il rinnovo delle chiavi.

La seconda fase (capitolo 2) ha lo scopo di ricercare e comparare le soluzioni PKI commerciali esistenti, al fine di individuare quella che più si avvicina al modello delineato nella fase 1. Dalla ricerca sono emersi una serie di aspetti comuni, tra cui in particolare l’adozione quasi unanime di PKIX (con la sola eccezione di PGP), l’assenza di meccanismi di sospensione dei certificati, l’utilizzo di chiavi con usi distinti, e la mancanza di funzioni di marcatura temporale (fa eccezione Entrust). Le maggiori differenziazioni si sono avute riguardo ai servizi forniti sul lato client, che in molti casi si limitano alla possibilità di richiedere certificati tramite pagine web. Diversamente rispetto al modello implementativo di iPKI, alcune soluzioni prevedono la gestione della CA in outsourcing, ripartendo le responsabilità di gestione tra il cliente, che si occupa della registrazione, revoca, e key recovery, ed il fornitore, che garantisce l’emissione dei certificati e la sicurezza della CA. Altre soluzioni infine forniscono una serie di API per lo sviluppo di applicazioni ad hoc (Xeti JKIX), o sistemi per la protezione di ambienti di esecuzione all’interno di risorse di calcolo condivise (IBM Vault Registry). In base alla ricerca effettuata, la soluzione che più si avvicina al modello di iPKI è Entrust/PKI 5.0, in quanto si tratta di una soluzione completa che fornisce il più largo numero di funzionalità richieste da iPKI, ed è l’unica tra tutte quelle esaminate dotata di autorità di marcatura temporale (TSA) e verifica in tempo reale dello stato di validità di un certificato (OCSP). Ha però il grosso limite di essere una soluzione chiusa, basata su formati proprietari che impediscono l’utilizzo di applicazioni per le quali non dispone di plug-in dedicati. Data la necessità, in questa fase di evoluzione degli standard, di non legarsi ad un determinato produttore, si è ritenuto opportuno optare per l’infrastruttura fornita da Windows 2000: si tratta di una soluzione aperta, aderente agli standard e pienamente compatibile con le applicazioni predisposte all’uso di PKI. Questa apertura consente l’utilizzo di prodotti di terze parti o lo sviluppo di applicazioni ad hoc per integrare le carenze evidenziate dal lato client. Una caratteristica peculiare è la stretta integrazione con il sistema operativo, che consente una serie di semplificazioni a livello gestionale e fruitivo. La terza fase (capitolo 3) consiste nella implementazione di un case study, nella quale si sono verificate le effettive capacità del software, l’interoperabilità di questa soluzione con altre infrastrutture, e l’adeguatezza dei meccanismi di gestione ed utilizzo dell’infrastruttura. Per queste prove si sono simulate le condizioni tipiche di un contesto aziendale.

Sommario

- III -

Sommario

INTRODUZIONE................................................................................................. I

SOMMARIO ...................................................................................................... III

GLOSSARIO........................................................................................................V

1 DEFINIZIONE DEI REQUISITI E DEI CRITERI DI VALUTAZIONE PER LA SCELTA DI UNA SOLUZIONE PKI.................................................1

1.1 CARATTERISTICHE E FUNZIONALITÀ ........................................................2 1.1.1 Servizi per gli utenti .................................................................................. 2 1.1.2 Applicazioni .............................................................................................. 3 1.1.3 Scalabilità ................................................................................................. 4 1.1.4 Interoperabilità......................................................................................... 5 1.1.5 Interazione con le applicazioni................................................................. 5 1.1.6 Gestione dei certificati.............................................................................. 6 1.1.7 Gestione delle chiavi................................................................................. 8 1.1.8 Sicurezza ................................................................................................. 10 1.1.9 Altri fattori che vanno considerati.......................................................... 12

1.2 DISCUSSIONE DEGLI STANDARD .............................................................14 1.2.1 Infrastrutture a chiave pubblica ............................................................. 14 1.2.2 Gestione delle chiavi............................................................................... 15 1.2.3 Posta elettronica ..................................................................................... 15 1.2.4 Certificati ................................................................................................ 16 1.2.5 Algoritmi e protocolli di cifratura, firma e funzioni di hash .................. 19

1.3 MODELLO TEORICO DI UNA SOLUZIONE PKI IDEALE .............................23 1.3.1 Caratteristiche di iPKI............................................................................ 23 1.3.2 iPKI per l’utente ..................................................................................... 27 1.3.3 Amministrazione di iPKI......................................................................... 29

2 STUDIO DELLE SOLUZIONI PKI ESISTENTI ...................................33

2.1 RICERCA ED ANALISI DELLE SOLUZIONI .................................................34 2.1.1 Entegrity Solutions Notary...................................................................... 34 2.1.2 Entrust/PKI 5.0 ....................................................................................... 34 2.1.3 GTE CyberTrust Enterprise CA.............................................................. 35 2.1.4 IBM Vault Registry 2.2.2 ........................................................................ 35 2.1.5 Lotus Domino.......................................................................................... 35 2.1.6 Microsoft Windows 2000 PKI................................................................. 35 2.1.7 Netscape Certificate Management System 4.1........................................ 35 2.1.8 Network Associates NetTools PKI Server e PGP VPN Client................ 36 2.1.9 Network Associates PGP Certificate Server e PGP ............................... 36 2.1.10 RSA Keon 5.0 .......................................................................................... 36 2.1.11 Thawte Enterprise PKI ........................................................................... 36 2.1.12 Verisign OnSite 4.0 ................................................................................. 36

Sommario

- IV -

2.1.13 Xcert Sentry 3.7....................................................................................... 36 2.1.14 Xeti JKIX 2.0........................................................................................... 37

2.2 ASPETTI GENERALI .................................................................................38 2.2.1 Documentazione...................................................................................... 38 2.2.2 Adesione agli standard ........................................................................... 38 2.2.3 Sospensione dei certificati ...................................................................... 38 2.2.4 Marcatura temporale.............................................................................. 38 2.2.5 Modalità di lavoro non in linea .............................................................. 38 2.2.6 Utilizzo di chiavi con usi distinti............................................................. 38 2.2.7 Verifica della validità dei certificati ....................................................... 39 2.2.8 Paradigmi di implementazione di PKI alternativi a quello di iPKI ....... 40 2.2.9 Soluzioni parziali .................................................................................... 40 2.2.10 Implementazioni di riferimento............................................................... 40

2.3 SCELTA DI UNA SOLUZIONE ....................................................................42

3 IMPLEMENTAZIONE DI UN CASE STUDY .......................................44

3.1 INSTALLAZIONE E GESTIONE ..................................................................45 3.1.1 CA principale.......................................................................................... 45 3.1.2 CA subordinata ....................................................................................... 50 3.1.3 Impostazione dei parametri di emissione ............................................... 55 3.1.4 Gestione dei certificati............................................................................ 61

3.2 APPLICAZIONI.........................................................................................75 3.2.1 Cifratura e firma di e-mail con S/MIME ................................................ 75 3.2.2 Comunicazione web sicura con HTTPS.................................................. 95 3.2.3 Cifratura di file con EFS ...................................................................... 112 3.2.4 Autenticazione tramite smart card........................................................ 117

3.3 CONSIDERAZIONI..................................................................................119 3.3.1 Carenze ................................................................................................. 119 3.3.2 Problemi................................................................................................ 119 3.3.3 Soluzioni................................................................................................ 121

BIBLIOGRAFIA ..............................................................................................122

SOMMARIO APPROFONDITO ...................................................................124

INDICE DELLE FIGURE...............................................................................128

INDICE ANALITICO......................................................................................131

Glossario

- V -

Glossario Nel documento si utilizzeranno i seguenti termini nelle accezioni qui descritte. Public Key Infrastructure (PKI): per PKI si intende l’insieme delle politiche e delle risorse umane, hardware e software che consentono l’associazione dell’identità di un attore a coppie di chiavi crittografiche tramite l’emissione e la gestione (creazione, mantenimento, revoca, archiviazione) di certificati. Attore1: utente o fornitore, umano o macchina, dei servizi della PKI. Certification Authority (CA): rilascia certificati che attestano l’appartenenza di una determinata coppia di chiavi ad un attore. I certificati sono firmati dalla CA, ed includono informazioni sul periodo di validità del certificato e sui possibili usi delle chiavi. La CA è responsabile non solo dell’emissione dei certificati, ma anche della loro gestione (distribuzione, rinnovo e revoca) durante tutto il loro ciclo di vita. Certificato: documento elettronico firmato in cui l’emittente dichiara l’associazione di una chiave pubblica ad un determinato attore. Titolare di un certificato: il possessore della chiave privata relativa alla chiave pubblica contenuta nel certificato. Registration Authority (RA): effettua l’identificazione degli attori che richiedono il rilascio di un certificato e fornisce gli strumenti necessari per la creazione delle chiavi. Può essere integrata nella CA. Riconoscimento (trust): relazione fiduciaria di un attore verso una CA. Un attore ritiene autentici i certificati firmati da una CA riconosciuta. Riconoscimento esplicito: un attore riconosce esplicitamente le CA di cui conserva i certificati in una particolare locazione. Riconoscimento implicito: un attore riconosce implicitamente una CA quando questa è dotata di una catena di certificati riconducibile ad una CA esplicitamente riconosciuta dall’attore. Convalida di un certificato: consiste nella verifica che la firma apposta ad un certificato per attestarne l’autenticità appartenga ad una CA riconosciuta, oppure sia accompagnata da un certificato a sua volta convalidato; viene verificato inoltre che il certificato non sia scaduto, sospeso o revocato. 1 Da non confondere col concetto di entità finale (end entity) come definito nei documenti RFC, che rappresenta invece solo gli utenti o i soggetti di un certificato. Rif. [16].

Glossario

- VI -

Time Stamping Authority (TSA): si occupa della generazione e memorizzazione di marche temporali da apporre ai documenti per attestarne l’esistenza al momento della marcatura. Chiavi di firma: coppia di chiavi destinate alla generazione e verifica di firme digitali apposte o associate a documenti. Chiavi di autenticazione: coppia di chiavi per l’accesso ad un sistema informativo protetto attraverso l’autenticazione dell’identità dell’utente. Chiavi di cifratura: coppia di chiavi utilizzate nelle operazioni di cifratura e decifratura di documenti e nelle operazioni di autenticazione. Chiavi di certificazione: coppia di chiavi utilizzata per le operazioni di generazione e verifica di firme apposte ai certificati digitali. Chiavi di marcatura temporale: coppia di chiavi utilizzate per la generazione e verifica di firme sulle marche temporali. Impronta di un documento: sequenza binaria di lunghezza predefinita generata da una funzione di hash applicata al documento. Certificate Revocation List (CRL): lista di certificati la cui validità è stata revocata dalla CA che li aveva originariamente emessi. La revoca non può essere annullata. Certificate Suspension List (CSL): lista di certificati la cui validità è stata sospesa dalla CA che li aveva originariamente emessi. La sospensione può essere annullata.

CAPITOLO 1

- 1 -

1 Definizione dei requisiti e dei criteri di valutazione per la scelta di una soluzione PKI

iversi sistemi per garantire la sicurezza su reti telematiche non sicure, come Internet, utilizzano protocolli che si basano su algoritmi crittografici a chiave pubblica.

Utilizzando questi protocolli si possono realizzare servizi di:

• confidenzialità: le informazioni trasmesse sono accessibili solo agli interlocutori espressamente autorizzati;

• integrità: verifica che i dati non abbiano subito modifiche; • autenticazione: accerta l’identità di un utente o un di server; • non ripudio: il firmatario di un documento non può

successivamente disconoscerlo. Il collegamento tra un soggetto e la sua coppia di chiavi (chiave pubblica e chiave privata) viene stabilito attraverso un certificato digitale, emesso da un’autorità fidata e riconosciuta. L’autenticità e la validità temporale di un certificato possono essere verificate da un utente senza l’intervento di un server, quindi la distribuzione dei certificati può avvenire utilizzando vie di comunicazione non sicure e questi dati possono essere conservati in una cache locale non sicura. In questo modo si ottimizzano le prestazioni in termini di tempo e di uso della rete senza dover predisporre difese aggiuntive per i canali di comunicazione esistenti. Lo scopo di una infrastruttura a chiave pubblica (Public Key Infrastructure, PKI) è quello rendere possibile l’uso dei protocolli basati su crittografia a chiave pubblica gestendo in modo efficace e sicuro i certificati e le chiavi ad essi associate.

D

Capitolo 1.1 Caratteristiche e funzionalità

- 2 -

1.1 Caratteristiche e funzionalità In questa sezione vengono esposte le funzionalità di base che un’architettura PKI deve fornire per poter essere impiegata in un contesto aziendale con molti utenti da gestire. Dopo aver esposto un’analisi dei servizi che si richiedono all’infrastruttura, si prendono in considerazione le problematiche di gestione implicate dall’uso di tali funzionalità nel contesto delineato, evidenziando i punti critici e le possibili soluzioni.

1.1.1 Servizi per gli utenti 1.1.1.1 Firma L’operazione di firma consiste nella generazione, tramite un opportuno algoritmo di hash, di un’impronta di un file, e nella successiva cifratura di questa impronta con la chiave privata di firma. L’impronta viene poi allegata al documento insieme al certificato della chiave, in modo che sia possibile per chiunque verificarne l’autenticità. Per la verifica della firma, bisogna effettuare questi controlli: • verifica che l’autore dichiarato nel documento corrisponda a quello presente nel

certificato; • verifica che il certificato sia valido: nessun certificato della catena che riconduce il

certificato ad una CA riconosciuta deve essere stato revocato oppure scaduto al momento in cui il documento è stato firmato;

• verifica che il certificato sia stato utilizzato per uno scopo consentito dalle politiche di rilascio dello stesso;

• verifica che il documento non sia stato alterato dopo la firma, confrontando l’impronta allegata al documento (decifrata con la chiave pubblica contenuta nel certificato) con l’impronta generata applicando lo stesso algoritmo di hash sul documento.

Se tutti questi controlli danno esito positivo, il documento è inconfutabilmente autentico ed integro.

1.1.1.2 Cifratura La cifratura consiste nella codificazione di un documento in modo che sia reso comprensibile solo a chi dispone della chiave opportuna. Per velocizzare l’operazione, si utilizza un algoritmo crittografico simmetrico (quindi più veloce) per la cifratura del documento, la cui chiave viene generata ad hoc. Diverse copie di questa chiave sono poi cifrate con le chiavi pubbliche di cifratura degli attori cui si vuole rendere disponibile il documento, e conservate insieme allo stesso. Questa tecnica, oltre ad essere più veloce rispetto alla cifratura del documento con un algoritmo asimmetrico, consente anche un notevole risparmio di spazio nel caso in cui si voglia rendere accessibile il documento a diversi soggetti. In questo caso, infatti, l’occupazione di spazio per ogni soggetto aggiuntivo è pari alla dimensione della chiave utilizzata nell’algoritmo simmetrico, tipicamente dai 128 ai 256 bit. La cifratura dell’intero documento con la chiave pubblica del soggetto richiederebbe invece uno spazio pari alle dimensioni del documento.


- 3 -

1.1.1.3 Autenticazione L’autenticazione consente di verificare l’identità di un attore attraverso una prova di possesso della chiave privata di cifratura. Questo tipo di autenticazione prende il nome di “autenticazione forte” per distinguerla dalla autenticazione basata su una password ricordata a memoria, che è passibile di attacchi a forza bruta, dictionary attack e password guessing.

1.1.1.4 Non ripudio Il possesso di un documento firmato e di un certificato valido relativo alla firma garantisce al possessore che il firmatario non può negare di aver originato il documento.

1.1.1.5 Marcatura temporale L’apposizione di una marcatura temporale ad un documento da parte della TSA ne attesta l’esistenza al momento della marcatura. La marcatura temporale consiste in una firma con data e ora dell’impronta del documento (non è quindi necessario rivelare alla TSA il contenuto del documento).

1.1.2 Applicazioni 1.1.2.1 Controllo dell’accesso La PKI consente un controllo dell’accesso più versatile rispetto a quella basata su algoritmi a chiave segreta, in quanto per l’autenticazione il gestore non necessita della chiave privata dell’utente, ma solo di un certificato pubblico. Questo consente all’utente di utilizzare un unico meccanismo di autenticazione (single sign on).

1.1.2.2 Posta elettronica Utilizzando gli strumenti della PKI gli attori possono scambiarsi messaggi di posta elettronica in modo confidenziale e sicuro, senza doversi conoscere o concordare un codice segreto in precedenza.

1.1.2.3 Web Gli utenti possono verificare l’autenticità del server a cui sono collegati; l’autenticazione dell’utente consente l’accesso alle pagine riservate o a pagamento. I pacchetti software possono essere firmati per consentirne l’autenticazione prima dell’esecuzione (ad esempio applet Java e controlli ActiveX).

1.1.2.4 Rete privata virtuale su rete pubblica Cifrando il canale di comunicazione su una rete pubblica, quale Internet, si può realizzare un rete privata virtuale (Virtual Private Network, VPN). Esempi di utilizzo sono la connessione di due LAN aziendali remote oppure consentire ai clienti di accedere a determinate risorse aziendali.

1.1.2.5 Commercio elettronico L’adozione di una PKI apre le porte al commercio elettronico, consentendo transazioni sicure (Zimits e Montaño [6]) e la stipula di contratti per via telematica. L’articolo 10, comma 2, del DPR 513 [5], recita: “L’apposizione o l’associazione della firma digitale al documento informatico equivale alla sottoscrizione prevista per gli atti e documenti in forma scritta su supporto cartaceo”.


- 4 -

L’attribuzione di valore legale alla firma elettronica consente la stipula di contratti senza che siano stati presi accordi in precedenza. Le regole tecniche per la validità delle firme e dei certificati sono illustrate nel DPCM [4].

1.1.2.6 Assimilazione nella società Dopo la sua diffusione nei settori del commercio elettronico e delle reti telematiche, la tecnologia basata su PKI diventerà di uso comune nella società, rimpiazzando i tradizionali metodi di autenticazione quali la firma ad inchiostro (Zimits e Montaño [6]), e progressivamente sostituendo il denaro fisico con il “portafoglio elettronico” [1]. Gli utenti potranno auspicabilmente usufruire di un accesso unificato a tutti i servizi offerti da diverse PKI, sia governative che commerciali.

1.1.3 Scalabilità L’automazione di alcuni processi di routine gioca un ruolo importante nella determinazione del grado di scalabilità di una implementazione di PKI. Alcuni accorgimenti implementativi sono inoltre fondamentali: replica delle informazioni nei vari segmenti di rete interessanti, caching di certificati e CRL/CSL, utilizzo di diversi punti di distribuzione di CRL/CSL partizionate, controllo che le date di scadenza di chiavi e certificati non siano concentrate in periodi critici ma piuttosto ben distribuite. Sempre per questioni di scalabilità e di gestione, le CA sono organizzate gerarchicamente, permettendo una gestione decentralizzata dei certificati. Una CA può avere una CA padre ed un numero variabile di CA figli. Una CA rilascia ai figli un certificato che ne attesta l’identità ed il rapporto di relazione col padre, creando così una catena di riconoscimento (chain of trust). Gli attori riconoscono implicitamente tutte le CA appartenenti ad una catena di riconoscimento di una CA riconosciuta esplicitamente. L’organizzazione gerarchica consente ad esempio ad una sede staccata di gestire localmente i certificati dei propri utenti; inoltre si può disabilitare in modo selettivo un ramo della gerarchia in caso di compromissione. La CA deve appoggiarsi ad un meccanismo di directory per la distribuzione e la memorizzazione dei certificati e delle chiavi. E’ importante strutturare la gerarchia delle directory ed il relativo schema in modo che vengano garantite le caratteristiche di scalabilità e sicurezza. Oltre alla gerarchia di certificazione, esiste la funzionalità di mutuo riconoscimento, consistente nel riconoscimento reciproco di due CA, così che gli attori che riconoscono una delle due CA possano convalidare automaticamente tutti i certificati rilasciati dall’altra. Per realizzarla, entrambe le CA coinvolte rilasciano un certificato di mutuo riconoscimento (cross certificate). Il mutuo riconoscimento elimina la complessità di una gerarchia, rendendo immediata e semplice la comunicazione ad esempio con un partner commerciale. La praticabilità di questa soluzione è però limitata a piccoli numeri, in quanto per gestire una gran numero di utenti si rende necessaria un’organizzazione gerarchica delle CA. Infine, per raggiungere una diffusione globale, l’infrastruttura deve aprirsi a gerarchie pubbliche e commerciali. In una tipica implementazione, le CA apparterranno ad una o più gerarchie, ed utilizzeranno il mutuo riconoscimento per situazioni particolari o come “scorciatoia” verso i domini più utilizzati.


- 5 -

1.1.4 Interoperabilità Affinché una PKI esprima tutte le sue potenzialità è necessario raggiungere un adeguato livello di interoperabilità che consenta lo scambio di messaggi sicuri e la verifica dell’autenticità delle informazioni anche con attori afferenti ad un’altra PKI. Questo può essere il caso ad esempio di una necessità di comunicazione fra due società che utilizzano differenti implementazioni di PKI. Anche all’interno di una stessa organizzazione ci potrebbero essere differenti PKI, in base alle diverse esigenze dei vari dipartimenti o gruppi di lavoro. L’interoperabilità implica non soltanto l’utilizzo di standard comuni (per la cifratura, la firma, la richiesta di certificati, ecc.) ma anche la condivisione di politiche di emissione e di sicurezza compatibili. Si presenta la necessità di mappare le relazioni fiduciarie tra attori di diverse PKI compatibilmente con le specifiche politiche di emissione e di mantenere traccia di queste mappatura per gestirne l’evoluzione. In mancanza di uno standard ufficiale, la capacità di una infrastruttura di utilizzare diversi protocolli pubblici e di non dipendere da soluzioni o estensioni proprietarie, è un fattore determinante per consentire l’effettivo impiego dell’infrastruttura in un contesto eterogeneo ed in continua evoluzione. Si richiede quindi alla PKI di essere in grado di operare in conformità agli standard attualmente in uso ed in fase di definizione trattati nella sezione 0, dedicata all’illustrazione degli standard.

1.1.5 Interazione con le applicazioni Affinché l’infrastruttura messa a disposizione dalla PKI sia sfruttata, è necessario che le applicazioni ed i sistemi operativi dispongano di un’interfaccia verso tali servizi, altrimenti lo sforzo per istituire l’infrastruttura è vanificato. Per la scelta di una soluzione PKI occorre esaminare il tipo di supporto che essa fornisce alle applicazioni che si intendono utilizzare. Il supporto può essere fornito in questi modi: • integrazione con l’applicazione interessata, sotto forma di estensione, macro o plug-

in dedicato; • supporto degli standard utilizzati dall’applicazione, nel caso in cui questa sia già

abilitata alle funzionalità PKI; • fornitura di interfacce di programmazione (API) ad alto livello che consentano di

sviluppare delle soluzioni ad hoc per l’interazione applicazione - PKI. Il sistema di certificazione deve essere consistente per le diverse applicazioni e le diverse piattaforme supportate. Deve funzionare come un singolo login (single sign on), che consenta al sistema di autenticare automaticamente l’utente presso i diversi servizi, seguendo le procedure appropriate. Per esempio durante una sessione l’utente potrebbe voler utilizzare la posta elettronica, collegarsi ad un server web per effettuare una transazione sicura, e lavorare su dei file cifrati. Per farlo, l’utente avvia il software client della PKI, e si autentica digitando la password o utilizzando un’apposita smart card. Fatto questo, l’integrazione dei servizi di PKI nell’ambiente operativo gli consente di effettuare le operazioni prima citate senza curarsi di periodi di validità delle chiavi, scelta della chiave da utilizzare tra quelle disponibili, tipo di algoritmi di cifratura impiegati, ecc.


- 6 -

Questa flessibilità deve essere messa a disposizione anche dei programmatori che vogliano sviluppare delle applicazioni sicure utilizzando delle librerie che si interfaccino al client PKI e ne sfruttino i servizi senza richiedere allo sviluppatore di intervenire a livello di implementazione di algoritmi di cifratura o protocolli di certificazione. L’utilizzo di interfacce di programmazione ad alto livello fornite a corredo della PKI semplifica il processo di sviluppo mettendo a disposizione una serie di procedure la cui correttezza è stata verificata e testata scrupolosamente. Per lo sviluppo di applicazioni sicure è però sempre necessaria una approfondita conoscenza delle problematiche di sicurezza e dei principi di funzionamento di algoritmi e protocolli forniti dalle librerie. Un utilizzo improprio di tali servizi può compromettere l’intera architettura di sicurezza. La PKI inoltre si integra con i servizi di directory aziendali, attraverso il supporto di LDAP. La directory viene utilizzata per contenere non solo i certificati e le CRL/CSL, ma anche informazioni relative alle CA, come ad esempio quali domini gestiscono, i certificati di mutuo riconoscimento, la periodicità di pubblicazione delle CRL e CSL, ecc. Agli oggetti contenuti nella directory che identificano un attore viene associato il certificato emesso dalla CA. Il servizio di directory può essere implementato ad hoc per la PKI, oppure la PKI può fare uso di un servizio già esistente. In questo caso il servizio deve essere in grado di gestire gli oggetti della PKI (certificati, CRL, CSL) e garantire la distribuzione degli aggiornamenti in tutte le repliche del database. Gli attori utilizzano le directory per acquisire le chiavi pubbliche di altri attori con cui vogliono comunicare, e per verificare la validità dei certificati di cui fanno uso.

1.1.6 Gestione dei certificati Un certificato di per sé non fornisce autenticazione: perché il certificato venga convalidato, infatti, è necessario che la firma apposta allo stesso sia stata fatta da una CA di cui si riconosce la validità. E’ necessario quindi che per ogni attore venga mantenuto un archivio delle CA da esso riconosciute. Ad esempio, i browser abilitati alle tecnologie PKI vengono forniti con una serie di certificati di CA sia commerciali che governative già installati, e danno la possibilità all’utente di installarne di nuovi in modo che i certificati emessi da queste CA vengano riconosciuti automaticamente dal programma. Se invece il browser incontra un certificato firmato da una CA non riconosciuta, l’evento viene segnalato all’utente così che egli possa prendere una decisione: potrebbe rigettare il certificato (ed i dati che erano da questo certificati) oppure accettarlo ed inserire la nuova CA tra quelle riconosciute (nel caso in cui il certificato fosse stato acquisito in maniera sicura). Nel caso di una PKI aziendale, affinché la CA principale (root CA) venga riconosciuta dalle applicazioni si può procedere in uno di questi modi: • la chiave pubblica della CA principale viene certificata da una CA che è già

riconosciuta dalle applicazioni che ne devono fare uso; • la CA principale viene inserita tra le CA riconosciute dalle applicazioni già in fase

di installazione;


- 7 -

• la CA principale emette un certificato sottoscritto relativo alla sua chiave pubblica, poi questo certificato viene distribuito in modo sicuro agli utenti così che possano inserirlo nel proprio archivio di certificati di CA riconosciute.

Una volta che la CA principale viene riconosciuta, la creazione e certificazione di una CA subordinata, che ad esempio può servire un particolare dominio o un dipartimento, è semplice: la CA principale emette un certificato relativo alla chiave pubblica della CA subordinata attestandone così l’autenticità. In questo modo, attraverso il meccanismo della catena di riconoscimento, la nuova CA è riconosciuta automaticamente da tutti gli attori che riconoscono la CA principale. Come vengono gestiti i certificati? Per la prima emissione di un certificato, è necessario verificare “di persona” la legittimità della richiesta, utilizzando mezzi tradizionali: questo è compito della RA. Ad esempio la RA potrebbe essere rappresentata da un addetto alla sicurezza che verifica l’autenticità della richiesta tramite la presentazione da parte del richiedente di un documento d’identità, assiste l’utente nella creazione di una coppia di chiavi fornendogli un dispositivo di firma (smart card), ed infine fornisce i dati alla CA che emette il certificato. Un documento (Certification Practice Statement, CPS) espone in modo completo ed inequivocabile le procedure relative alla creazione, revoca, sospensione e rinnovo di chiavi e certificati. Questo documento contiene inoltre la definizione delle politiche che stabiliscono la durata di chiavi e certificati in base all’uso, la scelta degli algoritmi utilizzati (tipo di algoritmo e lunghezza delle chiavi) per ogni tipo di attività, e la definizione dei ruoli di tutti i componenti dell’infrastruttura. Rif. [21]. Ogni certificato ha una durata prestabilita, pertanto si deve procedere regolarmente al rinnovo utilizzando un protocollo di richiesta di un nuovo certificato. Per fare questo l’attore deve inoltrare la richiesta di rinnovo utilizzando gli strumenti messi a disposizione dalla PKI, firmando elettronicamente la richiesta prima che il certificato di cui è in possesso sia scaduto. L’intera procedura può essere gestita automaticamente dall’infrastruttura senza richiedere l’intervento dell’utente, che così non deve preoccuparsi di controllare lo stato di validità dei propri certificati. Contestualmente al rinnovo di un certificato si possono rinnovare le chiavi ad esso associate (vedi 1.1.7); i certificati scaduti vengono conservati per la convalida dei documenti che erano stati emessi durante il periodo in cui il certificato era valido. Prima della sua naturale scadenza, un certificato può essere revocato per uno dei seguenti motivi: • compromissione della chiave privata; • errore o frode nell’emissione del certificato; • cambio delle condizioni per le quali il certificato era stato emesso. In caso di sospetta compromissione un certificato può essere sospeso. Differentemente rispetto alla revoca, la sospensione può essere annullata così che il certificato torni valido. La revoca avviene attraverso la pubblicazione del certificato nella CRL, che è firmata dalla CA. La CRL ha una marcatura temporale di emissione e l’indicazione del momento in cui verrà pubblicato un aggiornamento. Per facilitarne la gestione e la scalabilità, la CRL può essere separata in diverse liste, suddivise ad esempio per tipo di


- 8 -

certificato, con diverse frequenze di emissione in base alla rilevanza delle chiavi certificate. Per esempio, una CA potrebbe mettere le revoche di routine (come nel caso di un cambiamento nel nome di una persona) in una CRL e le revoche derivanti da compromissione delle chiavi in un’altra CRL, aggiornata più frequentemente. Le CRL potrebbero poi essere suddivise in base al dipartimento cui gli attori appartengono, così da ridurne le dimensioni e velocizzarne l’accesso (ogni dipartimento può tenere una copia della propria CRL in un server locale). Un meccanismo analogo gestisce le sospensioni, tramite l’uso di CSL. La sospensione o la revoca non hanno valore retroattivo; sono pertanto ritenuti validi tutti i documenti firmati prima del provvedimento. Le CRL e CSL sono pubblicate periodicamente nella directory e sono accessibili tramite LDAP, e-mail o HTTP; particolari applicazioni possono richiedere la verifica in tempo reale della validità di un certificato direttamente alla CA. I certificati e le liste possono essere replicati e memorizzati anche in modo non sicuro, in quanto l’integrità è garantita dalla firma della CA. Essendo la pubblicazione delle CRL/CSL a carattere periodico, c’è un problema di latenza durante il quale un certificato da revocare risulta valido perché non è stato ancora emesso un aggiornamento della lista. Questo periodo di latenza può essere ridotto aumentando la frequenza di emissione, ma per applicazioni particolarmente critiche potrebbe essere necessario ricorrere ad un meccanismo di verifica in tempo reale. Per fare questo, l’attore comunica direttamente con la CA, a cui richiede lo stato di validità di un certificato in quel momento. Questo tipo di verifica on-line richiede un maggiore impiego di risorse ed inoltre necessita di una connessione sicura con la CA. Per converso, la verifica off-line tramite CRL/CSL può fare uso di tecniche di caching delle liste e non richiede un canale di comunicazione sicuro.

1.1.7 Gestione delle chiavi Le coppie di chiavi vengono generate dagli attori o dalla RA per conto degli attori, poi sono certificate dalla CA. Nel certificato viene stabilita l’appartenenza ad un determinato attore ed i possibili usi delle chiavi; le chiavi non possono essere usate per scopi non definiti esplicitamente nel certificato. Le chiavi hanno una durata di validità e vengono rinnovate in accordo alle politiche stabilite, nel modo più trasparente possibile per l’utente. Mentre per la chiave privata di firma è opportuno che esista una sola copia (custodita esclusivamente dal titolare), della chiave privata di cifratura possono esistere altre copie conservate in luogo sicuro. Attraverso l’utilizzo di un meccanismo di memorizzazione e recupero delle chiavi (key escrow), si consente al personale autorizzato di avere accesso ai dati cifrati ed alle chiavi private. Questa funzionalità serve in caso di smarrimento della chiave da parte dell’utente oppure se l’azienda ha necessità di accedere a certi file anche se il dipendente che li ha cifrati non vuole o non può collaborare, ad esempio in caso di licenziamento o morte. L’opportunità dell’impiego di questo meccanismo deve essere vagliata attentamente in quanto la sicurezza del deposito delle chiavi private sarebbe ad alto rischio di attacco, ed inoltre c’è il rischio di un abuso del sistema da parte di chi è autorizzato ad accedervi. Un’accorta definizione delle politiche di autorizzazione deve regolamentare


- 9 -

questa delicata funzionalità. A seconda della tipologia di utente, il meccanismo di recovery potrebbe essere abilitato solo su richiesta dell’utente, oppure non implementato affatto. In questo caso sarebbe responsabilità dell’utente mantenere una copia della chiave privata in quanto nessun altro potrebbe assisterlo nel recupero di informazioni cifrate con una chiave smarrita o rubata. Vi è infine la possibilità di utilizzare due chiavi private diverse, una con la comodità del recovery, l’altra con la sicurezza dell’unicità, e scegliere volta per volta quale utilizzare. Gli svantaggi di questa soluzione consistono nel dover gestire più chiavi e nell’affidarsi all’utente finale per la scelta della chiave, cosa che richiede una comprensione non superficiale delle relative problematiche. Diversamente, si potrebbe presentare questa situazione: l’azienda non autorizza un utente a salvare file privati cui egli avrebbe accesso esclusivo, quindi implementa un key recovery per il file system. La legge ed il buon senso impongono però che la posta rimanga privata, e quindi le applicazioni di e-mail utilizzano un’altra chiave apposita di cui non esiste recovery. La scelta di quale chiave utilizzare non è a carico dell’utente, ma viene fatta automaticamente dalle applicazioni utilizzando le estensioni del certificato, dove si potrebbe indicare chiaramente se la chiave serve per cifrare file o e-mail. Un altro approccio ai problemi affrontati dal key recovery consiste nell’utilizzare un meccanismo di data recovery, che permette il recupero dei dati cifrati senza risalire alla chiave privata. Secondo questo paradigma, i dati vengono sempre salvati in due copie2, una cifrata con la chiave pubblica di cifratura dell’utente ed un’altra cifrata con un’apposita chiave di recovery (detta chiave del security agent). Sarebbe così possibile decifrare i dati senza la chiave privata dell’utente. Il data recovery, rispetto al key recovery, evita che terze parti vengano in possesso della chiave dell’utente, con lo svantaggio però di una minore flessibilità. Facciamo un esempio: un utente dimentica la password per l’uso della sua smart card dove conserva la chiave privata di cifratura. Con un meccanismo di key recovery, l’amministratore recupera la chiave dell’utente, la memorizza in un’altra smart card e la consegna all’utente che ha così riguadagnato l’accesso ai suoi dati. Se invece il meccanismo di recovery del sistema fosse quello del data recovery, l’amministratore sarebbe costretto ad individuare tutti i documenti dell’utente, decifrarli con la chiave di recovery, cifrarli con una nuova chiave ed infine consegnare questa nuova chiave all’utente. Un altro problema del data recovery deriva dal fatto che la chiave di recovery è unica per tutti gli utenti, così che un amministratore in possesso della chiave di recovery ha accesso ai dati cifrati di tutti gli utenti. Il key recovery consente un controllo più granulare del recovery, in quanto è possibile consegnare ad un amministratore autorizzato la chiave del solo utente di cui si vogliono decifrare i documenti.

2 Tecnicamente questa operazione non richiede un sostanziale aumento dello spazio occupato su disco, in quanto per la cifratura dei dati si utilizza un algoritmo simmetrico con una chiave generata ad hoc: è solo questa chiave che viene successivamente cifrata con la chiave dell’utente ed eventualmente con la chiave di recovery, e poi memorizzata insieme al documento (vedi 1.1.1.2).


- 10 -

Il numero di chiavi gestite da una CA aziendale è molto grande, quindi va posta una particolare attenzione ai meccanismi che ne regolano l’emissione, l’uso e l’aggiornamento. I possibili problemi che si possono presentare sono rappresentanti da utenti che dimenticano la password, impiegati che cambiano il proprio ruolo all’interno dell’azienda (o che la lasciano), scadenza del periodo di validità di chiavi e certificati. Oltre a queste problematiche di gestione, l’azienda ha necessità di poter accedere a documenti cifrati anche senza la chiave di chi li aveva inizialmente cifrate, e di verificare firme anche per lunghi periodi di tempo dopo che la chiave di firma è scaduta. Tutto questo implica la necessità di mantenere delle copie delle chiavi, sia mentre queste sono in uso, sia dopo la loro naturale scadenza. Si richiede alla PKI di supportare funzionalità di memorizzazione, backup e recupero delle chiavi di cifratura per consentire agli utenti di riguadagnare l’accesso alle proprie chiavi (e quindi ai propri dati) nel caso in cui dimentichino la password di accesso. Un’altra importante problematica è quella dell’aggiornamento delle chiavi. Ad intervalli regolari, le chiavi scadono e devono essere rinnovate. La frequenza può essere diversa in base ai vari utilizzi delle chiavi, ma comunque nessuna chiave ha una validità indefinita. La durata del periodo di validità di una chiave viene stabilita in base agli usi per i quali la chiave è stata creata ed alla importanza dei dati cifrati, raggiungendo un compromesso tra la sicurezza di una durata breve e l’impiego di risorse per un rinnovo frequente. Alcuni accorgimenti vanno presi per garantire la gestibilità dell’aggiornamento delle chiavi, ad esempio la procedura va iniziata prima della scadenza delle chiavi (l’utente deve sempre avere almeno una chiave valida), ed il processo deve essere scaglionato a livello aziendale, distribuendo i periodi di validità delle chiavi su date diverse. E’ auspicabile che l’aggiornamento avvenga in modo trasparente per l’utente e senza l’intervento dell’amministratore. Il sistema controlla se la scadenza della chiave è prossima, ed in tal caso provvede ad inoltrare alla CA la richiesta di una nuova chiave. Una volta ottenuta la nuova chiave (con relativo certificato), quella vecchia non viene cancellata, ma conservata con tutte le altre chiavi scadute nella “key history”. La key history è necessaria per accedere a tutti quei dati cifrati con chiavi ormai scadute ma che erano valide al momento della cifratura. La scelta della chiave opportuna per la decifratura di un determinato documento deve avvenire automaticamente e senza l’intervento da parte dell’utente. Diversamente, per quanto riguarda le chiavi di firma non vengono mantenute copie della chiave privata in quanto non è necessaria per la verifica di una firma. Inoltre, in caso di smarrimento essa può essere revocata e si può procedere alla creazione di una nuova chiave senza perdite di dati. La chiave pubblica, con relativo certificato, deve invece essere sempre disponibile per consentire l’autenticazione ed il non ripudio, anche dopo che la chiave privata è stata revocata o è scaduta.

1.1.8 Sicurezza La sicurezza delle CA è di estrema importanza, pertanto si deve porre particolare cura nella protezione fisica dei server, memorizzazione sicura delle chiavi ed implementazione di funzionalità di auditing. Le chiavi delle CA sono conservate su smart card oppure in altri dispositivi crittografici dedicati a prova di manomissione; in


- 11 -

questo modo, esse non vengono mai viste direttamente dal sistema operativo del server ospitante, ma possono essere accedute solo tramite le funzioni messe a disposizione dall’hardware. Di queste chiavi esistono delle copie, conservate in altro luogo seguendo le stesse procedure adottate per custodire i più importanti documenti e chiavi fisiche aziendali. Le chiavi possono anche essere separate in modo che sia necessario avere almeno un certo numero di parti per ricostruire l’intera chiave; i diversi pezzi vengono custoditi separatamente. Le chiavi private rappresentano l’unico segreto da custodire per una CA. L’archivio delle chiavi destinate al key recovery è infatti custodito separatamente, e cifrato con una chiave pubblica apposita. La gestione della corrispettiva chiave privata è meno problematica che per la chiave della CA; infatti una copia è contenuta in un dispositivo hardware che ne consenta l’utilizzo nel server contenente l’archivio, mentre le copie di sicurezza sono cifrate con la chiave della CA e quindi possono essere tenute anche in luoghi non sicuri. In definitiva, le diverse chiavi private della CA principale (differenziate in base all’uso) sono l’unico segreto da custodire per l’intera infrastruttura PKI. Tutto il resto è protetto da queste chiavi utilizzando gli stessi servizi forniti dall’infrastruttura. Gli utenti possono utilizzare dei dispositivi di firma (smart card) a prova di manomissione (tamper proof) che hanno la possibilità di generare e memorizzare al proprio interno coppie di chiavi ed effettuare internamente le operazioni di firma digitale. Per l’autenticazione, gli utenti utilizzano smart card oppure token card, che sono protette da un codice di utilizzo per impedirne l’utilizzo da parte di impostori in caso di smarrimento. Gli algoritmi di cifratura devono essere di provata affidabilità, e le chiavi di lunghezza sufficiente per escludere la fattibilità di un attacco a forza bruta su tutte le possibili chiavi. Le scelte implementative degli algoritmi non devono comprometterne la sicurezza. Per una discussione degli algoritmi di cifratura vedi 1.2.5. E’ importante qui sottolineare che l’utilizzo di una PKI non esaurisce in sé la totalità delle misure necessarie per raggiungere un adeguato livello di sicurezza. Possibili minacce e vulnerabilità vanno individuate attraverso una ricerca ad ampio raggio su tutti gli aspetti delle modalità di interazione col sistema informativo aziendale. Di seguito si elenca brevemente una serie di potenziali fonti di pericolo; una completa disamina delle problematiche di sicurezza informatica ed aziendale esula dagli obiettivi di questo documento, pertanto si rimanda per un approfondimento a testi dedicati: si veda ad esempio [7].

1.1.8.1 Virus e cavalli di troia La diffusione di virus, che infettano il sistema operativo o una particolare applicazione, può causare la negazione del servizio (denial of service, DoS) oltre alla perdita di dati. I cavalli di troia sono applicazioni che eseguono, oltre alle funzioni dichiarate, anche delle operazioni ostili, a insaputa dell’utente. Particolarmente insidiosi sono i cavalli di troia che sostituiscono i normali programmi utilizzati per l’accesso ai servizi della PKI al fine di intercettare informazioni riservate.


- 12 -

1.1.8.2 Informazioni conservate nei dispositivi di memorizzazione Deve essere analizzata la modalità di cancellazione dei file all’interno di un file system: tipicamente i settori dei dischi occupati da un file vengono semplicemente marcati come disponibili, e quindi l’informazione è ancora memorizzata nel disco rigido. Per ovviare a questo è necessaria una soprascrittura (anche multipla) di tutti i settori utilizzati dal file prima della sua cancellazione dal file system. Il file di swap della memoria virtuale, sulla quale la PKI non ha controllo, può contenere dati sensibili, pertanto deve essere possibile effettuarne una soprascrittura o anche, nei casi più critici, impedirne l’uso. La applicazioni possono far uso di file temporanei, che creati in base alle necessità e cancellati in modo insicuro. Per eliminare le informazioni che vi sono conservate è necessaria una soprascrittura di tutti i settori inutilizzati del dispositivo di memorizzazione.

1.1.8.3 Intercettazione ambientale ed elettromagnetica I dispositivi di spionaggio consentono di intercettare suoni, voci, conversazioni telefoniche, osservare la tastiera di un utente mentre digita la password, vedere schermate di informazioni confidenziali. Anche escludendo la visione all’esterno con tende alle finestre, si è esposti alla intercettazione elettromagnetica, che consente di ricostruire le immagini visualizzate sui monitor. Qualora si rendesse necessario, per la protezione da questo tipo di attacco si deve provvedere alla schermatura dei dispositivi critici ed alla insonorizzazione dell’ambiente.

1.1.8.4 Analisi del traffico di rete Anche se i dati sono cifrati, per viaggiare su una rete pubblica devono indicare l’origine e la destinazione del messaggio, oltre a contenere altre informazioni come ad esempio la lunghezza del messaggio. Se si desidera che queste informazioni non vengano rivelate, si deve ricorrere all’uso di una rete privata, in cui i dati sono trasmessi a flusso continuo e cifrati anche a livello di pacchetti di rete, oppure inserire del “rumore”, ovvero scambi di dati il cui solo scopo è quello di falsare le informazioni ricavate da un’analisi del traffico.

1.1.8.5 Social engineering, minacce e corruzione Col termine social engineering si indica una modalità di attacco che si basa sull’attacco dei difetti del personale umano piuttosto che quelli del software. In pratica si tratta di un raggiro al fine di ottenere password o documenti riservati, per proteggersi dal quale si deve educare il personale ed attenersi a precise procedure di notifica e gestione dei problemi. Il personale può essere minacciato o corrotto, e in questo caso le contromisure consistono nel cercare di attestare l’affidabilità e l’integrità morale dei dipendenti.

1.1.9 Altri fattori che vanno considerati 1.1.9.1 Facilità di implementazione In fase di implementazione, va considerata l’integrazione con i servizi di directory eventualmente presenti nella rete aziendale, e la disponibilità di API per lo sviluppo di applicazioni che sfruttino i servizi della PKI.


- 13 -

1.1.9.2 Facilità d’uso Gli utenti devono essere messi in condizione di poter comprendere ed utilizzare i servizi della PKI senza che questo comporti un cambiamento radicale per il loro modo di lavorare, onde evitare il ricorso a pratiche non sicure e programmi non compatibili con la PKI.

1.1.9.3 Problematiche di amministrazione Una cura particolare va messa nella pianificazione e definizione dello schema da applicare alla directory di appoggio alla PKI, in quanto una successiva riorganizzazione potrebbe avere risvolti gestionalmente molto pesanti. Ad esempio una variazione della posizione di un oggetto nella directory comporta la necessità di rinnovare il certificato associato in quanto il campo relativo al nome dell’oggetto risulterebbe invalidato. Se viene modificato il nome di un nodo nell’albero della directory, tutti i certificati relativi agli oggetti presenti nella gerarchia sottostante andrebbero rinnovati. Bisogna quindi prevedere le specifiche esigenze della PKI nell’uso della directory, ed impostare lo schema in modo che le possibilità di successive modifiche vengano ridotte al minimo. Un’altra problematica riguarda la gestione delle repliche dei dati e dei server, che devono essere sincronizzate in modo da consentire l’utilizzo di risorse locali e garantire il funzionamento anche in caso di guasti.

1.1.9.4 Flessibilità delle politiche d’uso (policies) La gestione delle politiche di accesso ed uso deve consentire di creare dei profili adeguati alle diverse tipologie di utenti e di esigenze.

1.1.9.5 Robustezza Il sistema deve garantire adeguati livelli di fault tolerance.

1.1.9.6 Costi Nel calcolo del costo del dispiegamento dell’infrastruttura vanno conteggiati l’acquisto dell’hardware e del software dedicato, lo sviluppo o modifica delle applicazioni per abilitarle all’utilizzo dei servizi PKI, e la formazione degli utenti.

1.1.9.7 Prestazioni Valutazione delle prestazioni in termini di utilizzo delle risorse di calcolo, di rete, e di memorizzazione.

Capitolo 1.2 Discussione degli standard

- 14 -

1.2 Discussione degli standard

1.2.1 Infrastrutture a chiave pubblica 1.2.1.1 Public Key Infrastructure X.509 (PKIX) PKIX è il gruppo di lavoro dell’Internet Engineering Task Force (IETF) che si propone di sviluppare degli standard per Internet che consentano di utilizzare una PKI basata su X.509. Si pone l’obbiettivo di promuovere l’interoperabilità di differenti implementazioni, basata su un sistema di certificazione gerarchico. Gode di un vasto supporto da parte dell’industria, ed è il candidato principale ad essere ratificato come Internet Standard. Rif. [9].

1.2.1.2 Simple Public Key Infrastructure (SPKI) Si tratta di un gruppo di lavoro dell’IETF che propone uno standard alternativo al PKIX. Ha elaborato dei protocolli e dei formati con lo scopo di renderne la comprensione, l’implementazione e l’uso il più semplice possibile. Invece di collegare un coppia di chiavi ad una entità, collega le chiavi a dei diritti o autorizzazioni (capabilities). Non contempla l’uso di una gerarchia, proponendo in alternativa un modello piatto. E’ improbabile che guadagni un vasto supporto, in quanto i certificati X.509 sono di fatto considerati la soluzione più opportuna per le applicazioni PKI. Rif. [10].

1.2.1.3 Public Key Cryptography System (PKCS) PKCS è l’insieme di standard per la crittografia a chiave pubblica sviluppato da RSA Laboratories, compatibile con lo standard X.509. Definisce sintassi indipendenti dall’algoritmo utilizzato per la cifratura. I seguenti sono gli standard definiti: • PKCS #1 meccanismi per crittografia e firma utilizzando algoritmi RSA. • PKCS #3 protocollo per l’accordo (agreement) di una chiave di cifratura utilizzando

l’algoritmo Diffie-Hellman. • PKCS #5 metodo per cifrare una stringa con una chiave segreta derivata da una

password. • PKCS #6 formato per i certificati; è stato sostituito dal formato X.509. • PKCS #7 sintassi per messaggi cifrati e firmati. • PKCS #8 formato per il mantenimento di informazioni riguardanti una chiave

privata. • PKCS #9 definizioni di tipi di attributi per l’uso con gli altri standard PKCS. • PKCS #10 sintassi per i messaggi di richiesta di certificazione ad una CA. • PKCS #11 interfaccia di programmazione per dispositivi crittografici quali smart

card o schede PCMCIA. • PKCS #12 formato per la memorizzazione di chiavi private, certificati ed altre

informazioni dell’utente. • PKCS #13 meccanismi per la cifratura e firma utilizzando crittografia a curva

ellittica (Elliptic Curve Cryptography). • PKCS #14 standard per la generazione di numeri pseudo-casuali. Gli standard PKCS sono brevettati da RSA Laboratories, che ne mantiene il controllo. Rif. [18].


- 15 -

1.2.1.4 Secure European System for Applications in a distributed Multi-vendor Environment (SESAME)

Sistema che comprende PKI e Kerberos, sviluppato da aziende europee (RACE, Bull SA, ICL, Siemens-Nixdorf) con fondi della Commissione Europea. Non è supportato da importanti produttori americani quali Microsoft e Netscape.

1.2.1.5 Pretty Good Privacy (PGP) PGP è un programma che utilizza crittografia a chiave pubblica per lo scambio di posta elettronica sicura via Internet. Sviluppato da Zimmermann nel ‘91, è diventato molto famoso grazie al modello di relazione fiduciaria utilizzato (il web of trust, vedi 1.3.1.1) che ben si adatta ad Internet, dove non c’è un’autorità riconosciuta da tutti. Il protocollo utilizzato da PGP è stato riconosciuto e standardizzato dall’IETF [3], ed il codice sorgente è pubblico per consentirne l’esame. PGP è ora disponibile sia in versione gratuita che commerciale; quest’ultima include capacità di cifratura di file, autorità di certificazione e compatibilità con X.509.

1.2.2 Gestione delle chiavi 1.2.2.1 Simple Key-management for Internet Protocols (SKIP) Basato sulla tecnologia Diffie-Hellman, è stato sviluppato da Sun Microsystems allo scopo di fornire funzioni di crittografia a chiave pubblica a livello IP. E’ conforme allo standard IPSec.

1.2.2.2 Internet Security Association Key Management Protocol and Oakley Key Determination Protocol (ISAKMP/Oakley)

Anch’esso basato su tecnologia Diffie-Hellman, definisce autenticazione e scambio automatico di chiavi. Sviluppato dell’IETF IPSec Working Group.

1.2.3 Posta elettronica 1.2.3.1 Open PGP Standard di pubblico dominio basato su Diffie-Hellman e DSA. Non utilizza certificati X.509.

1.2.3.2 Privacy Enhanced Mail (PEM) Questo protocollo, ormai obsoleto (viene descritto nella RFC 1422 pubblicata nel ‘93), consente lo scambio sicuro di posta elettronica con una PKI basata su certificati X.509. Utilizza una struttura gerarchica molto rigida che richiede un’autorità centrale riconosciuta da tutti. Utilizza come funzioni di hash MD2 o MD5, di cui è stata messa in dubbio la sicurezza (vedi 1.2.5.1).

1.2.3.3 Secure Multi-purpose Internet Mail Extensions (S/MIME) S/MIME è un protocollo sviluppato da RSA Data Security che descrive come includere informazioni cifrate e certificati in un messaggio di posta elettronica codificato secondo lo standard ufficiale per la posta elettronica estesa in Internet, MIME (RFC 1521). Segue la sintassi del PKCS #7, utilizzando X.509 per i certificati, RSA per lo scambio di chiavi, e MD5 o SHA-1 per la firma. E’ utilizzato da Netscape e Microsoft nei rispettivi browser.


- 16 -

1.2.4 Certificati 1.2.4.1 X.509 Un certificato X.509 è costituito da una struttura dati che collega una chiave pubblica ad un attore. I campi del certificato includono quindi il nome del proprietario della chiave, la chiave pubblica, nome e firma della CA che emette il certificato, il periodo di validità del certificato, gli usi per i quali la chiave è autorizzata, ecc. Esistono tre versioni del formato, che definiscono delle estensioni incrementali al formato base (versione 1). La versione 2 aggiunge due campi per il controllo di accesso alla directory. La versione 3 (X.509v3) aggiunge la possibilità di includere delle estensioni ai campi del certificato per supportare una vasta gamma di applicazioni, rendendo il formato versatile ed aperto ad innovazioni. Questo è in dettaglio il contenuto di un certificato X.509:

Versione Numero seriale

Identificativo dell’algoritmo di firma Nome della CA

Validità Nome del soggetto

Informazioni sulla chiave pubblica Identificatore dell’emittente (vers. 2 o 3) Identificatore del soggetto (vers. 2 o 3)

Estensioni (vers. 3) Firma

certificato X.509 Versione: la versione del certificato può essere 1, 2, o 3. Numero seriale: identifica univocamente il certificato tra quelli emessi dalla CA. Identificativo dell’algoritmo di firma: indica il tipo di algoritmo utilizzato dalla CA per firmare il certificato. Nome della CA: nome X.500 della CA. Se il certificato è versione 3 questo campo può essere lasciato vuoto, indicando il nome nell’estensione “Nome alternativo dell’emittente” che può essere in formato URL. Validità: inizio e fine del periodo di validità del certificato. Nome del soggetto: nome X.500 del soggetto titolare del certificato. Come per il nome della CA, questo campo può essere lasciato vuoto nella versione 3. Informazioni sulla chiave pubblica: contiene la chiave pubblica del soggetto e l’identificativo dell’algoritmo per il quale la chiave è stata creata. Identificatore dell’emittente: identificativo unico della CA, per consentire la distinzione in caso di riutilizzo dei nomi. Se presente, la versione del certificato dev’essere 2 o 3. Identificatore del soggetto: identificativo unico del soggetto; valgono le stesse osservazioni dell’identificatore dell’emittente.


- 17 -

Estensioni: questo campo consente l’aggiunta di nuovi campi senza dover modificare la definizione del formato del certificato. Una estensione consiste in un identificatore, un flag che indica se l’estensione è da considerare critica, e dei dati. Se il campo è presente, la versione del certificato dev’essere 3. Firma: la firma della CA emittente. Ogni estensione può essere marcata come critica o non critica. Se un sistema che utilizza il certificato incontra una estensione che non riconosce deve esaminarne la criticità: se si tratta di una estensione critica, il certificato non deve essere convalidato; altrimenti, l’estensione può essere ignorata. La versione 3 definisce delle estensioni standard per il certificato. Altre estensioni, dette estensioni private, possono essere aggiunte dai protocolli per sfruttare funzionalità specifiche. Queste sono le estensioni standard: lo sfondo grigio indica che l’estensione può essere marcata come critica; lo sfondo bianco indica che l’estensione è sempre non-critica.

Identificatore della chiave della CA Identificatore della chiave del soggetto

Usi della chiave Validità della chiave privata

Politiche del certificato Mappatura di politiche

Nome alternativo del soggetto Nome alternativo dell’emittente

Attributi di directory del soggetto Limitazioni di base

Limitazioni sui nomi Limitazioni di politiche

Punti di distribuzione delle CRL estensioni standard

Identificatore della chiave della CA: identifica la particolare chiave della CA utilizzata per firmare il certificato, nel caso in cui una CA disponga contemporaneamente di più chiavi valide (ad esempio durante il rinnovo delle chiavi). Identificatore della chiave del soggetto: come per la chiave della CA, serve per distinguere tra più chiavi appartenenti al soggetto. Usi della chiave: indica per quali scopi l’uso della chiave è autorizzato. Questi possono essere firma, non ripudio, cifratura di chiavi, cifratura di dati, accordo di chiavi, firma di certificati, firma di CRL. Validità della chiave privata: periodo di validità della chiave privata; si usa per ridurre la durata della chiave privata di firma rispetto alla durata della chiave pubblica (utilizzata per verificare la firma). Politiche del certificato: indica le politiche in base alle quali il certificato è stato emesso e per quali scopi il certificato può essere utilizzato.


- 18 -

Mappatura di politiche: stabilisce una mappatura tra le politiche utilizzate dalla CA emittente e le politiche di un’altra CA, in caso di utilizzo di una catena di certificazione. Nome alternativo del soggetto: contiene uno o più nomi alternativi rispetto al nome X.500 indicato nel campo “Nome del soggetto” del certificato base. Questo campo consente di indicare in modo più versatile il nome del soggetto, che può essere per esempio un indirizzo di posta elettronica o un indirizzo di server HTTP. Nome alternativo dell’emittente: come per il soggetto, questo campo contiene dei nomi alternativi per identificare la CA emittente. Attributi di directory del soggetto: in questo campo possono essere indicati attributi di directory aggiuntivi relativi al titolare del certificato. Limitazioni di base: indica se il soggetto può fungere da CA, e che profondità può raggiungere la catena di certificazione. Limitazioni sui nomi: utilizzata per i certificati di CA, limita l’insieme dei possibili nomi dei soggetti che possono essere certificati dalla CA titolare del certificato. Limitazioni di politiche: può specificare la richiesta di identificazione esplicita delle politiche del certificato o inibire la mappatura delle politiche. Punti di distribuzione delle CRL: indica i luoghi in cui si trovano le CRL per il certificato. Per ulteriori informazioni sul formato X.509, vedi [15].

1.2.4.2 Lightweight Directory Access Protocol (LDAP) LDAP è un servizio di directory che consente di creare, gestire e leggere dati relativi ad una PKI, quali certificati e informazioni sulle CA. La replicazione delle directory consente di propagare automaticamente gli aggiornamenti al database dei certificati tra i diversi server. Può essere conveniente, ad esempio, conservare le informazioni relative agli impiegati di un determinato dipartimento in un server dedicato, così che molte richieste possano essere esaudite localmente. Il protocollo definisce le modalità con cui dati possono essere conservati in più di una locazione e come i diversi server interagiscono per recuperare informazioni non disponibili localmente. Dato che la validità dei certificati può essere verificata direttamente dal client, i certificati possono essere distribuiti attraverso server e vie di comunicazione non sicure e possono essere conservati in una cache locale senza rischio di manomissioni. Questo protocollo si interfaccia e segue il modello di directory di X.500, rendendone disponibili alcuni servizi in modo più “leggero”, senza implementare tutte le caratteristiche del fratello maggiore. In un contesto aziendale, un utente ha tipicamente diversi tipi di autorizzazioni e di password associate, per account e-mail, database, file service, ecc. L’utilizzo di LDAP consente di mantenere queste informazioni in modo centralizzato, rendendone più semplice l’aggiornamento ed il controllo; la PKI a sua volta consente di autenticarsi una sola volta per accedere a tutti i servizi (Single Sign On). Lo schema della directory deve rispettare un insieme di requisiti per soddisfare le esigenze della PKI [19], ma una directory ha diverse altre possibilità di impiego all’interno di un’azienda, anche non direttamente correlate con i servizi di PKI. Tali impieghi possono essere ad esempio condivisione di configurazioni tra le applicazioni, servizi di white e yellow pages, ed in generale servizi di database: queste attività


- 19 -

possono convivere con la PKI senza costituire un ostacolo, anzi si integrano con le funzionalità da essa fornite. L’implementazione del protocollo LDAP deve consentire un accesso ai dati protetto da un meccanismo di privilegi, tipo quello di un file system; per esempio, considerando la entry di un impiegato, si potrebbero rendere accessibili a chiunque i certificati relativi alle sue chiavi, rendere accessibile solo all’interno dell’azienda il suo numero di telefono, e consentire solo a lui di accedere alle chiavi private o ai suoi documenti conservati nella directory. In un contesto di questo tipo, la directory si configurerebbe come il luogo principale per la conservazione e la distribuzione dei dati a livello aziendale, e quindi assume un grande rilievo la necessità di un’implementazione robusta che garantisca, oltre alla sicurezza contro attacchi esterni, adeguati livelli di fault tolerance. Si devono prevedere ridondanza dei dati e dei server per ridurre al minimo il tempo di non funzionamento del servizio, e meccanismi di disaster recovery per il recupero dei dati in seguito a guasti o calamità di vario genere. Rif. [20].

1.2.5 Algoritmi e protocolli di cifratura, firma e funzioni di hash Di seguito sono illustrati gli algoritmi ed i protocolli di cifratura, di firma e le funzioni di hash utilizzate per la realizzazione di un’infrastruttura PKI. I testi di riferimento utilizzati per lo studio, e nei quali si può trovare un esame dei principi teorici e matematici della crittografia, sono [1], [7] e [18].

1.2.5.1 Digital Signature Standard (DSS) Lo standard ufficiale per la firma elettronica del governo degli Stati Uniti, definito dal National Institute of Standards and Technology (NIST). Utilizza SHA-1 per creare un’impronta che viene poi cifrata con DSA.

1.2.5.2 SHA-1 Funzione di hash a una via (one-way hash function) che produce un’impronta di 160 bit, usata in Digital Signature Standard (DSS). Secondo la proposta del PKIX working group, questa è la funzione di hash da preferirsi per una PKI in Internet.

1.2.5.3 Digital Signature Algorithm (DSA) Algoritmo di cifratura a chiave pubblica utilizzato da DSS.

1.2.5.4 Diffie-Hellman Protocollo per l’accordo di una chiave (key agreement protocol) sviluppato da Diffie e Hellman. Consente a due utenti di creare una chiave segreta utilizzando un canale di comunicazione non sicuro, senza avere in precedenza segreti condivisi. Si basa sul problema del logaritmo discreto (discrete logarithm problem).

1.2.5.5 Data Encryption Standard (DES) DES è l’algoritmo crittografico simmetrico più usato, essendo standard ufficiale del governo USA per la cifratura di dati non riservati (classified); fu sviluppato inizialmente da IBM, poi modificato dalla National Security Agency (NSA). Progettato per poter essere implementato efficacemente in hardware, opera su blocchi di 64 bit con una chiave di 56 bit. Una variante più sicura verso attacchi a forza bruta è il Triple-DES (3DES) che utilizza una sequenza di 112 bit, suddivisa in due chiavi, A e B. La cifratura dei dati avviene in tre passi successivi: cifratura con la chiave A, cifratura con la chiave


- 20 -

B, cifratura con la chiave A. In questo modo si mantiene la compatibilità con il DES se le chiavi A e B coincidono. In DES e 3DES le operazioni di cifratura e decifratura sono le stesse.

1.2.5.6 International Data Encryption Algorithm (IDEA) Algoritmo di cifratura che lavora su blocchi di 64 bit utilizzando una chiave di 128 bit, sviluppato in Svizzera da Lai e Massey nel 1990. E’ stato disegnato con lo scopo di poter essere implementato facilmente sia in hardware che in software e di poterne valutare la resistenza ad attacchi di crittoanalisi differenziale. Al momento è considerato immune da attacchi di crittoanalisi differenziale.

1.2.5.7 CAST CAST è un algoritmo crittografico simile al DES in quanto si basa su una rete di sostituzione e permutazione; offre una buona resistenza contro la crittoanalisi lineare, differenziale, e a chiavi correlate. Ne esistono varianti con chiavi di diverse dimensioni (CAST-128, CAST-256).

1.2.5.8 RSA Algoritmo crittografico a chiave pubblica basato sulla fattorizzazione di grandi numeri, ed è utilizzato sia per crittografia a chiave pubblica che come algoritmo di firma. Il nome deriva dai suoi sviluppatori: Rivest, Shamir e Adleman.

1.2.5.9 Algoritmi a curva ellittica Gli algoritmi di cifratura a curva ellittica consentono di utilizzare metodi di cifratura a chiave pubblica che richiedono minori risorse in termini di lunghezza delle chiavi e tempo di calcolo rispetto agli algoritmi più tradizionali, mantenendo un livello di sicurezza equivalente.

1.2.5.10 Message Digest (MD2, MD4, MD5) Funzioni di hash a una via che producono un’impronta di 128 bit; ideate da Ron Rivest ed utilizzate in PEM. MD2 è la più lenta, MD4 la più veloce ma meno sicura, mentre MD5 è una variante di MD4 che sacrifica parte della velocità (è di circa il 33% più lenta) in favore di un maggior grado di sicurezza. La sicurezza di queste funzioni è stata in qualche modo messa in dubbio dalla dimostrazione di una linea di attacco [8][14] che arriva vicino a trovare delle collisioni, ovvero individuare due stringhe differenti che danno lo stesso valore. Sebbene non siano state ancora compromesse, RSA Laboratories ne sconsiglia l’uso [17].


- 21 -

1.2.5.11 Considerazioni sulla lunghezza delle chiavi Questa tabella indica una stima della lunghezza delle chiavi (in bit) da usare in base all’algoritmo ed al grado di sicurezza, per mettersi al riparo da attacchi a forza bruta su tutte le possibili chiavi. Il grado export è il limite consentito dalle leggi USA sull’esportazione di software crittografico.

Grado DES e varianti RSA DSA Curva ellittica Export 40 512 512 80

Personale 56/64 768 768 136 Commerciale 128 1024 1024 160

Militare 160 2048 2048 200 rielaborazione su dati RSA Laboratories [18]

Nella scelta della lunghezza delle chiavi bisogna anche considerare per quanto tempo si vogliono mantenere i dati cifrati inaccessibili ed il tipo di attacco contro il quale si vuole che resistano. La seguente tabella indica la lunghezza di chiavi raccomandata per algoritmi a chiave pubblica affinché i dati siano sicuri fino ad un certo anno.

Anno Personale Commerciale Militare 2000 1024 1280 1536 2005 1280 1536 2048 2010 1280 1536 2048 2015 1536 2048 2048

rielaborazione su dati University of West Florida [12] Queste “previsioni” vanno comunque sempre prese con molta cautela ed attenzione, in quanto progressi nel campo della crittoanalisi e della potenza di elaborazione dei calcolatori possono rendere rapidamente inadeguate anche le stime più prudenti.

1.2.5.12 IP Security protocol (IPSec) Insieme di specifiche, sottoinsieme dell’IPv6, per servizi di autenticazione, integrità e confidenzialità a livello IP, in fase di sviluppo da parte di un gruppo di lavoro dell’IETF. Consente di creare, per ogni pacchetto IP, un header separato di autenticazione (AH, Authentication Header) e la possibilità di cifrare il contenuto del payload (ESP, Encapsulating Security Payload). I formati sono indipendenti dallo specifico algoritmo crittografico, sebbene alcuni algoritmi siano indicati come obbligatori per garantire l’interoperabilità.

1.2.5.13 Secure Electronic Transaction (SET) Protocollo standard di Visa e MasterCard per l’utilizzo sicuro di pagamenti con carta di credito tramite internet. Utilizza certificati digitali per realizzare una transazione che coinvolge il venditore, l’acquirente e la banca.

1.2.5.14 Secure Hypertext Transfer Protocol (HTTPS) Protocollo per la cifratura delle pagine web scambiate tra un server ed un browser. Utilizza certificati X.509 per l’autenticazione, SSL per la connessione e diversi algoritmi per la cifratura, in particolare RC4.


- 22 -

1.2.5.15 Secure Sockets Layer (SSL) Protocollo per la creazione di un canale dati (socket) cifrato sul protocollo TCP/IP, utilizzando crittografia a chiave pubblica e certificati per autenticare gli utenti. Transport Layer Security (TLS) é una versione migliorata e standardizzata del protocollo.

1.2.5.16 Online Certificate Status Protocol (OCSP) Protocollo per la verifica in linea dello stato di un certificato (valido, revocato o sospeso). Il client invia una richiesta al server OCSP e sospende la validazione del certificato finché non riceve una risposta; questo metodo consente una verifica in tempo reale, ma richiede maggiori risorse rispetto all’uso di CRL/CSL. Rif. [13].

Capitolo 1.3 Modello teorico di una soluzione PKI ideale

- 23 -

1.3 Modello teorico di una soluzione PKI ideale Nel seguito vengono delineate le caratteristiche progettuali e funzionali di un modello di PKI “ideale” per l’impiego in un contesto aziendale con molti utenti da gestire. Il modello teorico servirà come base per la valutazione di soluzioni PKI esistenti, al fine di scegliere quella che più si avvicina alla soluzione ideale. Nel seguito, la PKI ideale del modello sarà chiamata per comodità iPKI.

1.3.1 Caratteristiche di iPKI La iPKI è costituita dai software di CA, TSA, directory ed un programma client che consente agli utenti finali di usufruire dei servizi e gestire le proprie chiavi e certificati. I servizi sono anche utilizzati dai programmi predisposti (browser, e-mail client, … ) tramite protocolli standard. Le funzionalità di RA sono assolte dagli addetti alla registrazione utilizzando il software di CA. Gli utenti utilizzano una smart card per la conservazione delle chiavi personali e per l’accesso al sistema. Lo standard adottato è il PKIX, per la organizzazione gerarchica e per il vasto supporto di cui dispone da parte di applicazioni di terze parti e di altre implementazioni di PKI; i certificati sono quindi in formato X.509v3 e la directory opera secondo il protocollo LDAP. La directory non è ad uso esclusivo della iPKI, ma è utilizzata anche per scopi non legati alla crittografia, ad esempio per individuare il numero di telefono di un ufficio. L’accesso alle informazioni è regolato dai permessi associati agli oggetti presenti nella directory. Non si specifica l’ambiente operativo (sistema operativo e hardware) su cui funzionano i programmi server, mentre il client di autenticazione è disponibile per i più diffusi sistemi operativi e richiede la presenza di un lettore di smart card. L’autenticazione al sistema tramite password in alternativa alla smart card non è consentito, a causa della vulnerabilità di questo sistema ad attacchi a forza bruta e di social engineering.

1.3.1.1 Organizzazione gerarchica Le CA sono organizzate gerarchicamente, così da consentire una gestione decentralizzata delle certificazioni. Ogni dipartimento o divisione aziendale dispone di una CA locale, figlia della CA radice dell’azienda. Una possibile alternativa alla struttura gerarchica è rappresentata da una struttura di tipo “web of trust”, in cui la relazione fiduciaria è organizzata in modo differente. In questo contesto, ogni utente può certificarne un altro, e ad ogni certificazione è associato un peso. Affinché un certificato venga quindi riconosciuto ed accettato, possono essere necessarie firme da parte di diverse entità. Questo tipo di verifica dell’autenticità è stato ideato per poter funzionare in un contesto in cui non si riconosce una autorità superiore (come è la CA principale nel modello gerarchico), ed in particolare per consentire lo scambio di posta elettronica sicura via internet tra gruppi di persone. Il “web of trust” modella i rapporti interpersonali, in cui una persona fidata può introdurre ed autenticare i propri conoscenti. Nel contesto in cui dovrà operare la iPKI non c’è questo tipo di necessità, anzi si richiede che solo le CA, di cui si possono verificare sicurezza e protezione, godano della fiducia necessaria per autenticare le credenziali. La struttura gerarchica consente comunque la decentralizzazione e la delega del carico di lavoro; nel caso in cui fossero


- 24 -

necessarie più firme o autorizzazioni per una determinata operazione, è compito dell’applicazione finale richiedere il raggiungimento del quorum prefissato. La mutua certificazione, infine, consente di snellire la catena di certificazione senza per questo allargare incontrollatamente l’insieme di attori che grazie a questa funzionalità vengono autenticati, grazie alle estensioni (critiche) relative alle limitazioni, introdotte nella versione 3 del certificato X.509 (vedi 1.2.4.1).

1.3.1.2 Dispositivi di autenticazione forte L’autenticazione tramite password ricordate a memoria è troppo debole per poter essere usata efficacemente nel contesto di iPKI. Si ritiene dunque necessario l’utilizzo di dispositivi di autenticazione forte, i quali consentono l’autenticazione a due fattori: per autenticarsi con successo è necessario sia conoscere un dato segreto (il PIN) che possedere fisicamente un oggetto (il dispositivo). Il solo possesso del dispositivo non consente di autenticarsi, in quanto la realizzazione è prova di manomissione (tamper proof), che impedisce di ricavare i dati segreti dall’esame dell’oggetto. Al momento i due dispositivi che consentono questo tipo di autenticazione sono token card e smart card. La token card consiste in un dispositivo delle dimensioni di una piccola calcolatrice dotato di un display. All’interno un processore conserva un identificatore unico (seme), che viene combinato con il valore fornito da un orologio interno e con il PIN fornito dall’utente utilizzando un apposito algoritmo. Il valore risultante rappresenta il codice di autenticazione da inviare al server, che è sincronizzato con la token card e conosce il valore del seme e del PIN. Data la sua dipendenza dall’ora corrente, questo codice cambia ad intervalli regolari (tipicamente ogni minuto), così che una eventuale intercettazione del codice non risulti nella compromissione di un accesso. La smart card ha le dimensioni di una carta di credito, è dotata di un processore e di una memoria (tipicamente 8-16 KB) nella quale si possono memorizzare certificati e chiavi private. Il processore è capace di eseguire operazioni crittografiche all’interno del dispositivo, quindi le chiavi private contenute non vengono mai esportate. Per utilizzare una smart card è necessario un apposito lettore collegato ad un computer. L’accesso alle funzione ed ai dati della smart card è protetto da un codice conosciuto solo dal titolare. Considerandone l’utilizzo all’interno di iPKI, quindi non solo come meccanismo di autenticazione, queste sono le differenze principali tra i due tipi di dispositivo:

1) La smart card è più sicura, perché le chiavi private sono conservate esclusivamente al suo interno, o al più in un server off-line nel caso di copie per il recovery. L’uso di una token card richiede invece che le chiavi private siano conservate, in forma cifrata, in un posto accessibile al server di autenticazione, che può così inviarle al client dopo averne verificato l’identità. Nel caso specifico della firma elettronica, il titolare dovrebbe essere l’unico detentore della chiave privata per garantire la certezza del non ripudio, e questo può essere ottenuto solo con la smart card.

2) La smart card può essere usata per l’autenticazione anche off-line. Ad esempio, un computer portatile potrebbe contenere i certificati con la chiave pubblica degli utenti autorizzati e verificarne il possesso della corrispettiva chiave privata per autenticare un utente senza accedere ad un server. Sarebbe invece molto


- 25 -

rischioso tenere nel portatile i valori di seme e PIN necessari all’autenticazione tramite token card.

3) La token card si può usare anche nei casi in cui non sia disponibile un lettore di smart card, ed esempio un chiosco Internet in un aeroporto. Questa specifica funzione si potrebbe emulare con una smart card utilizzando un lettore portatile dotato di tasti e display; la smart card diventerebbe così una token card, programmabile ma estremamente costosa.

4) La token card è più economica. Il costo medio di una token card è di 60’000 lire, mentre quello di una smart card si aggira sulle 100’000 lire. Un lettore di smart card costa dalle 150’000 alle 300’000 lire, a seconda del tipo di interfaccia col sistema ospitante.

5) La smart card può essere usata anche come documento di identificazione e come tessera per accedere ad un edificio protetto.

I due tipi di dispositivo presentano quindi delle peculiarità e dei vantaggi unici, e si potrebbe anche ipotizzare l’utilizzo di entrambi i sistemi a seconda delle necessità dei singoli utenti. Questo però aumenterebbe la complessità del sistema, e la complessità è un pericolo che è opportuno evitare. I due ostacoli maggiori all’uso generalizzato di smart card sono il costo e l’utilizzo laddove non sia disponibile un lettore. In prospettiva, con la diffusione delle PKI, questi due aspetti verranno ridimensionati dalla riduzione dei costi determinata dall’allargamento della base d’utenza e dalla diffusione di sistemi dotati di lettori. In conclusione, nell’ottica di una PKI che rispetti in pieno i principi del capitolo 0:

- La soluzione ottimale è completamente basata su smart card; - È da evitarsi un sistema ibrido, a causa della elevata complessità inerente; - Una soluzione basata su token card sarebbe utilizzabile e sufficientemente

sicura, qualora i costi di una sistema con smart card fossero troppo elevati per le risorse destinate alla PKI.

iPKI rappresenta una soluzione ideale ed ottimale, e quindi utilizza un sistema di autenticazione basato su smart card. Le smart card utilizzate da iPKI sono dispositivi intelligenti, delle dimensioni di una carta di credito, in grado di contenere le chiavi private di firma/autenticazione e di cifratura di un utente, ed i relativi certificati rilasciati dalla CA di appartenenza, che contengono le chiavi pubbliche. Le funzioni crittografiche della smart card consistono nella capacità di cifrare/decifrare file di dimensioni ridotte, tipicamente impronte di documenti o chiavi di algoritmi simmetrici. Il dispositivo è a prova di manomissione e tutte le operazioni vengono eseguite internamente, così che le chiavi private non vengano mai esposte. Ogni utente dispone di una smart card personale, sulla quale è riportato il nome e la foto del titolare.

1.3.1.3 Chiavi di cifratura e di firma/autenticazione Gli utenti dispongono di due coppie di chiavi: una per la cifratura ed un’altra per la firma e l’autenticazione. L’unificazione delle chiavi di firma e di autenticazione consente una riduzione della complessità del sistema senza ridurne la sicurezza; la


- 26 -

chiave di cifratura deve essere invece diversa in quanto presenta caratteristiche differenti. Infatti, allo scadere della validità di una chiave privata di cifratura, essa deve essere conservata nella key history per avere accesso ai dati cifrati con tale chiave; quando invece scade la validità di una chiave privata di firma, non serve conservarla, perché la corrispettiva chiave pubblica è memorizzata nel certificato presente nella directory o conservato insieme ai documenti firmati. Un altro esempio è la procedura da seguire in caso di smarrimento di una chiave: nel caso della chiave di firma/autenticazione è sufficiente revocare la chiave smarrita e crearne una nuova; se viene smarrita la chiave di cifratura è invece necessario recuperarla per non perdere tutti i dati cifrati. La gestione della key history è eseguita dal programma client in maniera trasparente per l’utente e per le applicazioni: ogni richiesta di decifratura inviata al sottosistema di sicurezza è accompagnata da un identificativo univoco della chiave utilizzata, che è sempre memorizzato insieme ai dati cifrati. Il programma client interpreta quindi questo dato per effettuare la scelta della chiave appropriata tra quelle presenti nella key history; questo programma si occupa anche della gestione completa della key history. Un certificato contenente un coppia di chiavi occupa circa 3KB; un certificato con la sola chiave pubblica circa 1.5KB. A causa delle limitazioni della capacità di memorizzazione delle smart card attuali (8-16 KB), potrebbe non essere possibile memorizzare l’intera key history nella smart card dell’utente; in questo caso il programma client memorizza le chiavi più recenti nella smart card fino a saturarne la capacità, mentre deposita le chiavi restanti nella directory, dopo averle opportunamente cifrate con la chiave attualmente valida. Essendo queste le chiavi più vecchie, sono anche quelle che hanno una minore frequenza di utilizzo. Un discorso analogo vale per l’insieme dei certificati delle CA riconosciute dall’utente. I certificati che non possono essere conservati su smart card per mancanza di spazio sono tenuti nella directory, in un archivio la cui impronta è firmata dall’utente per garantirne l’integrità. Non è necessario in questo caso cifrare l’archivio. Tutte le operazioni di memorizzazione e recupero di chiavi dalla key history e di certificati delle CA riconosciute sono svolte automaticamente dal programma client; in questo modo l’utente non deve preoccuparsi di dove sono effettivamente tenuti questi dati, ed un eventuale passaggio ad una smart card di capacità superiore comporterebbe lo sfruttamento automatico dello spazio a disposizione. La parte di key history e di archivio di CA riconosciute conservata nella directory può essere copiata localmente per consentirne l’utilizzo in modalità offline o comunque in tutti quei casi in cui non sia possibile accedere direttamente ad iPKI. Un modello alternativo per la gestione delle chiavi scadute consiste nel tenere le chiavi che hanno durata temporale diversa all’interno di un unico certificato. Secondo questo modello, utilizzato da PGP, in fase di creazione di un certificato si creano più chiavi, con periodi di validità differenti, in modo che quando una chiave scade, non bisogna crearne una nuova e richiederne la certificazione alla CA, ma è sufficiente utilizzare la chiave, già contenuta nel certificato corrente, che è attualmente valida. Le chiavi scadute possono essere ancora usate per la decifratura. Non esiste quindi una key history separata, in quanto essa è contenuta all’interno del certificato, che contiene pure le chiavi che saranno valide solo in futuro. Questo modello risulta molto efficace in un contesto nel quale non ci sia una autorità riconosciuta, per cui ottenere un certificato aggiornato di


- 27 -

un utente può essere un’operazione dispendiosa, mentre nel contesto in cui opera iPKI la richiesta di un certificato aggiornato non rappresenta un problema. Inoltre, se ad un certo momento si decide di modificare la procedura di generazione delle chiavi (ad esempio si possono scegliere chiavi più lunghe, o utilizzare un algoritmo migliore), nel modello a chiave multipla sarebbe necessario revocare i certificati esistenti, in quanto possono contenere chiavi valide anche per molti anni in avanti, mentre in iPKI è sufficiente applicare le nuove regole alle nuove chiavi generate dopo la naturale scadenza di quelle esistenti. Per questo motivo i certificati di iPKI contengono solo una chiave, con una precisa indicazione del periodo di validità. Per l’accesso a dati cifrati da altri, dopo che la chiave usata è scaduta e quindi il relativo certificato non è più conservato dal programma client, è necessario che insieme ai dati sia stato memorizzato il certificato contenente la chiave corrispondente a quella che è stata usata per cifrarli. Questo è necessario anche per garantire il non ripudio delle firme dopo che è trascorso il periodo di validità del certificato; infatti, le CA conservano i certificati emessi solo per un determinato periodo di tempo, solitamente intorno ai dieci anni.

1.3.1.4 Key recovery La iPKI fornisce ed utilizza un meccanismo di key recovery che consente al personale autorizzato di recuperare la chiave privata di un utente. Per il recupero delle chiavi è necessario il raggiungimento di un prefissato quorum di amministratori, attraverso la firma di un’autorizzazione a procedere elettronica. La scelta di utilizzare tale meccanismo piuttosto che un meccanismo di data recovery oppure nessun recovery è stata fatta considerando i vantaggi e gli svantaggi delle diverse soluzioni discussi nel paragrafo 1.1.7. Esigenze particolari di maggiore sicurezza o privacy, considerate nel modello poco frequenti, sono gestite da programmi e politiche esterne alla iPKI.

1.3.2 iPKI per l’utente Ad ogni utente viene consegnata dagli addetti alla registrazione una smart card contenente le coppie di chiavi di firma/autenticazione e cifratura ed i relativi certificati. La smart card esegue le operazioni crittografiche al proprio interno, quindi non esporta mai le chiavi private. L’utilizzo della smart card è protetto da una password che il titolare deve ricordare a memoria. Per accedere al sistema informatico controllato da iPKI, l’utente deve inserire la smart card nell’apposito lettore e poi digitarne la password quando il programma client la richiede. Se l’operazione viene eseguita correttamente, il client ha accesso alle funzioni crittografiche della smart card, che utilizza per eseguire il logon tramite proof of possession: il sistema invia una sequenza binaria generata casualmente al client, il quale, utilizzando le funzioni della smart card, la cifra con la chiave privata di autenticazione e la rispedisce al server di autenticazione. Il server decifra a sua volta la sequenza con la chiave pubblica di autenticazione dell’utente, verificando così che quest’ultimo sia effettivamente in possesso della chiave privata e sia quindi chi dichiara di essere. Questo meccanismo consente di autenticare e consentire l’accesso anche ad utenti non locali, la cui identità è certificata da una CA esterna riconosciuta, intervenendo solo sui controlli di accesso e senza dover gestire singolarmente i permessi per ogni utente esterno.


- 28 -

In questa fase il client esegue anche dei controlli sullo stato di validità di chiavi e certificati contenuti nella smart card, provvedendo automaticamente al rinnovo qualora tali oggetti fossero scaduti o prossimi alla scadenza. Queste operazioni non richiedono intervento da parte dell’utente, a meno che non sia scaduta la chiave di autenticazione. Se questo accade, il programma avverte l’utente che è necessario rivolgersi alla RA per riottenere accesso al sistema. Per evitare un elevato numero di interventi da parte della RA, il client esegue in automatico il rinnovo della chiave di autenticazione con un ragionevole margine di anticipo rispetto alla scadenza. Una volta terminata la fase di logon, il client mette a disposizione le funzioni elencate in 1.1.1, nelle modalità di seguito esposte.

1.3.2.1 Firma di un documento Crea una firma per un determinato documento, calcolando l’impronta e poi sottoponendola alla smart card per la cifratura con la chiave privata di firma. Su richiesta può raggruppare documento, firma e certificato in un unico file, che in questo modo contiene tutto il necessario per verificarne l’autenticità e che può essere comodamente inviato o archiviato.

1.3.2.2 Verifica dell’autenticità di un documento Verifica che la firma associata ad un documento sia valida; per farlo, l’utente sottopone al programma il documento e la firma da verificare. Il certificato contenente la chiave pubblica del firmatario può essere fornito dall’utente oppure trovarsi nell’archivio di certificati personale, o ancora può essere ricercato nella directory.

1.3.2.3 Marcatura temporale Gestisce la richiesta ad una TSA di attestare l’esistenza di un documento in quel determinato momento. L’utente fornisce il documento da certificare al client, che ne calcola l’impronta. Questa viene spedita alla TSA che crea, firma e ritorna un file contente l’impronta, la data e l’ora in cui è pervenuta la richiesta. L’attestazione può anche certificare l’appartenenza del file, inviando l’impronta cifrata come descritto nel paragrafo 1.3.3.2.

1.3.2.4 Cifratura e decifratura Cifra o decifra un file utilizzando un algoritmo simmetrico la cui chiave è cifrata con la chiave pubblica di cifratura del destinatario; la chiave cifrata, con un identificatore che specifica quale chiave è stata usata per la cifratura, è allegata al file in questione. La stessa chiave può essere allegata in diverse copie ciascuna cifrata con una chiave pubblica di cifratura diversa, per consentire la decifratura a più di un attore. Il file originale (non cifrato) può essere opzionalmente cancellato in modo sicuro, sovrascrivendo i settori utilizzati dal file in modo da renderne impossibile il recupero.

1.3.2.5 Gestione dei certificati Il client dispone di funzionalità per la gestione dei certificati dei quali l’utente è in possesso; per esempio l’utente può inserire nel proprio archivio un certificato di cui si fida nonostante non sia stato firmato da una CA fidata. L’utente utilizza questa funzione anche per indicare le CA da riconoscere esplicitamente. Il client mantiene una cache dei certificati usati più recentemente, per alleggerire il carico di lavoro della directory ed il traffico generato sulla rete. Questa cache consente inoltre di poter utilizzare le funzioni crittografiche anche qualora i server di iPKI non


- 29 -

fossero raggiungibili, ad esempio nel caso di un utente che utilizza un computer portatile per svolgere del lavoro mentre si trova in viaggio. Per evitare che i certificati contenuti nella cache scadano mentre l’utente è fuori linea, il programma client è dotato di una funzionalità che opzionalmente controlla se ci sono dei certificati che scadono entro un certo termine, e ne ricerca di nuovi nel caso in cui questa ricerca dia esito positivo. L’uso dei servizi di iPKI senza accedere alla directory è però sempre limitato dalla frequenza di emissione di CRL e CSL. Non è possibile verificare la validità di un certificato se non si dispone dell’ultima versione delle liste di revoca e di sospensione, emessa in accordo alle politiche di emissione della CA. L’accesso alla directory da parte di un utente remoto è facilitato dalla modalità di ricerca di un certificato dal lato server (vedi 1.3.3.3), che rende pratico, per esempio, ottenere un determinato certificato tramite una connessione via modem. L’utilizzo delle funzioni è il più possibile semplice ed integrato nel sistema operativo ospitante, per evitare che gli utenti ricorrano a “scorciatoie” non sicure. L’interfaccia consente un’interazione di tipo drag and drop: per esempio, è sufficiente trascinare un file sull’icona rappresentante un lucchetto chiuso perché questo venga cifrato con la chiave pubblica di cifratura dell’utente. Per cifrare il file con la chiave di un altro utente, basta trascinare il file sull’icona relativa al certificato di tale utente. Il programma si integra con il sistema operativo rispettandone le peculiarità; ad esempio, attraverso l’associazione del tipo di file “certificato” al client, quando un utente seleziona un certificato presente nel file system gli viene presentato un riassunto del contenuto del certificato e gli si offre la possibilità di inserirlo nel proprio database. Quando l’utente cerca di accedere ad un file cifrato, l’operazione di decifratura avviene in modo automatico e trasparente; l’operazione inversa avviene quando l’utente salva tale file dopo aver apportato delle modifiche. Intere directory possono essere marcate come “cifrate”; tutti i file che saranno memorizzati all’interno di una di queste directory sarà automaticamente cifrato. L’uso dei servizi di iPKI può prescindere dal programma client; per esempio un browser può accedere autonomamente al database di certificati conservato nella directory e richiedere direttamente alla CA di iPKI la verifica dell’autenticità di un server utilizzando un protocollo standard. Un programma di posta elettronica può cifrare un messaggio ricercando l’indirizzo del destinatario nella directory, dove troverà anche il relativo certificato.

1.3.3 Amministrazione di iPKI 1.3.3.1 CA Al momento della sua installazione, la CA principale (radice) dell’azienda produce un autocertificato, che ogni attore afferente alla iPKI deve inserire tra i certificati riconosciuti esplicitamente. La CA principale serve come punto di raccordo tra le CA amministrate indipendentemente dai diversi dipartimenti aziendali. Ogni CA dipartimentale dispone di almeno una RA per la registrazione degli attori; dispone inoltre di un certificato rilasciato dalla CA principale, così che, tramite il meccanismo della catena di certificazione, tutti gli attori possano interagire indipendentemente dalla particolare CA dipartimentale da cui vengono certificati.


- 30 -

La CA utilizza la directory aziendale, eventualmente preesistente, per depositarvi CRL, CSL, e certificati emessi. Tipicamente i certificati degli utenti sono anche memorizzati nella directory insieme alle altre informazioni relative ad un determinato dipendente, così che sia facile individuare contestualmente indirizzo e-mail e chiave pubblica di cifratura per spedire un messaggio sicuro. Il database delle chiavi di cui viene conservata una copia per il key recovery è memorizzato in una archivio dedicato e cifrato cui hanno accesso solo gli operatori autorizzati; non è conservato nella directory per evitare che l’eventuale individuazione di una falla nell’implementazione della directory o delle procedure di cifratura renda possibile l’accesso a queste delicate informazioni. Per consentire l’interoperabilità verso l’esterno, la CA principale richiede dei certificati di riconoscimento ad una o più CA governative o commerciali; per snellire la catena di riconoscimento le CA dipartimentali stipulano accordi di mutuo riconoscimento con le CA appartenenti ai partner commerciali. Le procedure da seguire per creare un riconoscimento sono esposte nel CPS (vedi 1.1.6), insieme alla descrizione delle politiche che regolano la durata di chiavi e certificati, la scelta degli algoritmi utilizzati e la definizione dei ruoli di tutti i componenti dell’infrastruttura. Le CA sono eseguite su server dedicati e protetti fisicamente; l’accesso è consentito solo ai responsabili. La chiave privata di firma della CA principale è memorizzata in un dispositivo hardware a prova di manomissione che ne consente un uso efficiente ed al tempo stesso ragionevolmente protetto da attacchi di tipo software o fisici. Questo dispositivo:

- esegue tutte le operazioni crittografiche (generazione della chiave, firma, cifratura) internamente;

- garantisce che in nessuna circostanza la chiave possa essere esposta in chiaro al di fuori del dispositivo;

- consente di creare una copia di riserva della chiave, da utilizzare in caso di perdita della copia in uso;

- verifica l’identità ed i permessi degli utilizzatori, utilizzando metodi di autenticazione forti ed eventualmente richiedendo la contemporanea presenza di più soggetti autorizzati;

- individua guasti o malfunzionamenti al proprio interno, evitando di operare in maniera non corretta (fail-safety);

- cancella permanentemente le informazioni contenute in caso di manomissione fisica o ripetuti tentativi falliti di autenticazione.

Una simile protezione può essere applicata anche ad altre chiavi, in particolare le chiavi di firma delle CA subordinate, in base alle specifiche esigenze di sicurezza. L’interfaccia di gestione della CA consente di configurare le modalità di rilascio di CRL e CSL, impostare i parametri relativi alla durata standard di chiavi e certificati, e revocare o sospendere i certificati. I servizi che la CA fornisce a tutti gli utenti sono: • Revoca e sospensione: il titolare di un certificato può richiederne la revoca o la

sospensione; • Rinnovo: effettua il rinnovo di un certificato o la creazione di una nuova chiave;


- 31 -

• Convalida on-line: verifica la validità di un certificato al momento della richiesta; questo servizio si usa qualora la validazione tramite controllo di CRL/CSL non sia possibile o sufficientemente aggiornata;

• Richiesta di un certificato: fornisce al richiedente il certificato relativo ad un determinato attore.

Per gli addetti ai servizi di RA sono disponibili inoltre i servizi di: • Creazione: genera le chiavi ed i certificati per un nuovo attore, inserisce questi dati

negli archivi, prepara una smart card; • Modifica: consente di modificare le informazioni relative ad un attore, rilasciando

un certificato aggiornato; • Revoca e sospensione: la RA può revocare e sospendere anche certificati di cui non

è titolare; • Riattivazione: annulla un precedente provvedimento di sospensione.

1.3.3.2 TSA La TSA offre come unico servizio la marcatura temporale di un’impronta. La marcatura può limitarsi ad attestare l’esistenza oppure anche l’appartenenza di un documento. Per richiedere una attestazione di esistenza è sufficiente inviare alla TSA l’impronta del documento da marcare; la TSA ritorna un file, cifrato con la propria chiave privata, contenente l’impronta, la data e l’ora corrente. Per ottenere un attestato di appartenenza, il proprietario spedisce alla TSA l’impronta cifrata con la propria chiave privata di firma; la TSA ritorna un file, cifrato con la propria chiave privata, contenente l’impronta (decifrata), la data, l’ora, ed il nome del proprietario. Il fatto che alla TSA venga spedita la sola impronta, piuttosto che l’intero documento, consente di non rivelare alla TSA il contenuto del documento, e comporta un notevole risparmio di risorse di rete e di risorse computazionali per il server TSA.

1.3.3.3 Directory La directory fornita con iPKI utilizza il protocollo LDAP e supporta la distribuzione dei dati su diverse repliche che vengono sincronizzate automaticamente ad intervalli di tempo stabiliti. Ogni CA dispone di una replica di riferimento, sulla quale è tenuta ad apportare tutte le modifiche; la successiva distribuzione delle modifiche alle altre repliche è compito della directory. Per ottimizzare le risorse, le repliche si scambiano solo le informazioni relative alle differenze rispetto all’ultima sincronizzazione (sincronizzazione incrementale). La directory è a sua volta organizzata gerarchicamente, in modo che ogni server debba gestire e mantenere solo una parte dei certificati esistenti in iPKI. Per semplicità di gestione è opportuno, anche se non necessario, che questa organizzazione rispecchi la gerarchia esistente tra le CA. Replicazione, organizzazione gerarchica, sincronizzazione incrementale e caching nel client garantiscono un elevato grado di scalabilità e performance. Il programma che gestisce una determinata replica della directory su un server è in grado di rispondere a richieste di certificati basate su diversi parametri, come numero seriale, nome del soggetto o usi della chiave. La ricerca dei certificati dal lato server consente una bassa utilizzazione della rete e la possibilità di fare ricerche anche utilizzando connessioni a ridotta larghezza di banda.


- 32 -

1.3.3.4 Smart card Ad ogni utente di iPKI viene assegnata una smart card. La procedura di rilascio è la seguente: l’addetto di RA, dopo aver verificato l’identità del richiedente e la legittimità della richiesta, inserisce i dati nella directory e crea le coppie di chiavi di cifratura e di firma/autenticazione utilizzando il software di CA. Una copia della chiave privata di cifratura viene memorizzata in forma cifrata nell’archivio di key recovery; per le chiavi pubbliche la CA rilascia un certificato e lo inserisce nella directory. Le chiavi private ed i certificati (contenenti le chiavi pubbliche) vengono memorizzate nella smart card, la quale viene consegnata all’utente. Al primo uso della smart card, l’utente è invitato ad impostarne la password di accesso.

CAPITOLO 2

- 33 -

2 Studio delle soluzioni PKI esistenti

copo di questa fase è l’esame delle soluzioni per implementare una PKI presenti sul mercato, al fine di individuare, tra queste, quella che più si avvicinasse al

modello rappresentato da iPKI. Dalla ricerca sono emerse una serie di tendenze comuni, in particolare sull’adozione degli standard, e di divergenze progettuali che distinguono in maniera anche radicale le diverse soluzioni proposte. Il capitolo si conclude con la scelta ragionata di Windows 2000 come soluzione più adatta ad approssimare il modello delineato da iPKI; questa soluzione verrà poi utilizzata nella fase successiva per l’implementazione di un case study.

S

Capitolo 2.1 Ricerca ed analisi delle soluzioni

- 34 -

2.1 Ricerca ed analisi delle soluzioni Le soluzioni esaminate sono:

1. Entegrity Solutions Notary 2. Entrust/PKI 5.0 3. GTE CyberTrust Enterprise CA 4. IBM Vault Registry 2.2.2 5. Lotus Domino 6. Microsoft Windows 2000 PKI 7. Netscape Certificate Management System 8. Network Associates NetTools PKI Server e PGP VPN Client 9. Network Associates PGP Certificate Server e PGP 10. RSA Keon 5.0 11. Thawte Enterprise PKI 12. Verisign OnSite 4.0 13. Xcert Sentry 3.7 14. Xeti Jkix

Di queste, alcune realizzano solo una parte dei servizi necessari a iPKI, altre adottano un modello diverso, demandando la gestione della CA ad un fornitore esterno all’azienda. Solo le soluzioni 2 e 9, realizzate rispettivamente da Entrust e da Network Associates, si avvicinano sufficientemente ad iPKI. Le maggiori differenziazioni sono state sulla parte dei servizi forniti sul lato client. Si fornisce ora una breve panoramica delle caratteristiche distintive delle soluzioni esaminate, evidenziandone le differenze o mancanze rispetto ad iPKI; si discutono poi una serie di aspetti generali emersi dalla ricerca, ed infine si realizza un confronto approfondito tra le due soluzioni candidate ad essere selezionate per il case study.

2.1.1 Entegrity Solutions Notary http://www.entegrity.com

Il client fornito da questa soluzione consente esclusivamente di gestire la richiesta di certificazione inoltrata alla CA. Entegrity dispone di due programmi separati per la cifratura di file e per la posta elettronica: Secrets for Windows ed AssureMail, entrambi disponibili solo in ambiente Windows. Secrets for Windows non supporta PKIX (usa invece PKCS); è in grado di cifrare file utilizzando algoritmi crittografici a chiave pubblica. AssureMail opera a livello di chiamate MAPI e protocolli SMTP/POP3, intercettando i messaggi in arrivo ed in uscita per applicare la cifratura e la firma; supporta PKIX.

2.1.2 Entrust/PKI 5.0 http://www.entrust.com/entrust

Questa soluzione, rilasciata pochi giorni prima dell’inizio della ricerca, fornisce una vasta serie di funzionalità sia dal lato server che dal lato client. In particolare, consente


- 35 -

la registrazione automatica di nuovi utenti senza l’intervento della RA (AutoRA) ed il rinnovo automatico della chiave della CA (CA key update). Supporta molti sistemi operativi sia come server che come client.

2.1.3 GTE CyberTrust Enterprise CA http://www.cybertrust.com/cybertrust/products_services/ products/enterprise/enterprise.html

Cybertrust dispone di un software di CA o di servizi di CA hosting forniti in outsourcing. Il client, Desktop Accelerator Program, consiste in una serie di servizi di consulenza e prodotti sviluppati da terzi, che sono compatibili con la CA di Cybertrust. I programmi del client consentono di firmare e cifrare la posta elettronica, stabilire connessioni SSL, e cifrare file.

2.1.4 IBM Vault Registry 2.2.2 http://www-4.ibm.com/software/security/registry

Vault Registry fornisce funzionalità di certificazione ed autenticazione, mettendo a disposizione degli utenti dei “vault”, ovvero ambienti di esecuzione sicuri (cifrati) per programmi residenti su server. L’impostazione della PKI di Vault Registry va al di là delle necessità di iPKI, con richieste onerose anche dal punto di vista dell’hardware necessario per l’esecuzione.

2.1.5 Lotus Domino http://www.lotus.com/home.nsf/welcome/domino

Domino è una piattaforma per la gestione di applicazioni e messaggi per gruppi di lavoro (groupware). Non è quindi una soluzione PKI, ma dispone di una directory LDAP e sfrutta la crittografia a chiave pubblica per la comunicazione sicura. Lotus ha siglato un accordo con Entrust per integrare Entrust/PKI all’interno dell’infrastruttura di sicurezza di Domino.

2.1.6 Microsoft Windows 2000 PKI http://www.microsoft.com/windows2000

Windows 2000 integra le funzioni di PKI all’interno del sistema operativo, fornendo una CA (Certificate Services), una directory LDAP (Active Directory) e funzionalità dal lato client di cifratura di file (Encrypted File System), cifratura di comunicazioni (VPN), autenticazione dei componenti (Authenticode) e Single Sign On. Il logon al sistema supporta autenticazione basata su password, certificati e smart card, ed è integrato con Kerberos. Dal lato client non dispone di strumenti per la firma di documenti, la cancellazione sicura di file e la gestione di una key history.

2.1.7 Netscape Certificate Management System 4.1 http://www.iplanet.com/products/infrastructure/ dir_security/cert_sys

Si tratta di un pacchetto che svolge funzioni di CA e comprende una directory, ma non offre funzionalità dal lato client.


- 36 -

2.1.8 Network Associates NetTools PKI Server e PGP VPN Client http://www.pgp.com/asp_set/products/tns/ntpki_intro.asp

Questa seconda soluzione di Network Associates supporta sia PGP che PKIX. E’ l’unica soluzione a fornire il supporto per entrambi i formati, e questo è notevole vista la diffusione di PGP sia come numero di utenti che come piattaforme supportate. Il client è rappresentato dagli stessi componenti di PGP, a cui è stato aggiunto il supporto per certificati X.509, ed è anche compatibile con le CA di Entrust e Verisign. Non ci sono funzionalità di key recovery.

2.1.9 Network Associates PGP Certificate Server e PGP http://www.pgp.com/asp_set/products/tns/pgpcert_intro.asp

Questa soluzione supporta solo certificati PGP. PGP Certificate Server non è una vera e propria CA, in quanto non firma i certificati che gestisce; però ne garantisce la legittimità (se sono nella directory rispettano la policy) e ne conserva le firme fatte da terzi (che rappresentano quindi un’authority). Il paradigma seguito è molto distante da quello delineato da iPKI: se un certificato è presente nella directory, significa che è legittimo in quanto rispetta le politiche stabilite; i firmatari rappresentano l’authority che ne garantisce l’autenticità. Il client (PGP) fornisce notevoli funzionalità, ed è disponibile per molti sistemi operativi, anche in versione freeware. PGP supporta il key splitting, che consiste nel suddividere una chiave in più pezzi in modo tale che possa essere ricostruita solo disponendo di un sufficiente numero di parti. Un’altra funzionalità peculiare di questo prodotto è il Secure Viewer, una soluzione software per visualizzare documenti in un formato immune da intercettazione elettromagnetica (attacchi TEMPEST). Il grosso limite di questa soluzione è l’incompatibilità con PKIX, che impedisce l’interoperabilità di questo prodotto con le PKI più diffuse.

2.1.10 RSA Keon 5.0 http://www.rsasecurity.com/products/keon

La soluzione di RSA fornisce CA, RA, programma client e smart card. Il client è in grado di segue cifratura e SSO in ambiente windows, ma non gestisce firme, key history e cancellazione sicura. La documentazione di RSA è l’unica che cita la chiave di autenticazione, che è unificata con quella di firma come in iPKI.

2.1.11 Thawte Enterprise PKI http://www.thawte.com

Thawte si limita a fornire il servizio di CA in outsourcing.

2.1.12 Verisign OnSite 4.0 http://www.verisign.com/onsite

In questa soluzione i compiti sono suddivisi, infatti la CA è gestita da Verisign, mentre i clienti possono controllare emissione, revoca e key recovery.

2.1.13 Xcert Sentry 3.7 http://www.xcert.com/software/sentryca.html


- 37 -

Sentry non dispone di funzionalità client. Il modulo Websentry è un plug-in che consente di abilitare un server web ai servizi di PKI.

2.1.14 Xeti JKIX 2.0 http://www.xeti.com

Si tratta di una serie di API java per lo sviluppo di applicazioni compatibili con PKIX; forniscono un supporto per protocolli quali LDAP, OCSP, PKCS, X.509. Hanno ricevuto la certificazione 100% Pure Java. Dopo la recensione, Xeti è stata acquisita da Critical Path; JKIX è stato incorporato nei prodotti di quest’ultima e rimosso dal mercato. La seguente matrice consente un confronto diretto tra le soluzioni più interessanti; sono riportati solo quei pacchetti che offrono una serie completa di funzionalità sia dal lato server che da quello client.

Capitolo 2.2 Aspetti generali

- 38 -

2.2 Aspetti generali Queste considerazioni emergono dall’analisi dell’insieme di tutte le soluzioni esaminate, sottolineando tendenze comuni e divergenze progettuali.

2.2.1 Documentazione Le informazioni relative ai pacchetti sono state ricavate in larga parte dai siti web delle case produttrici, esaminando brochure, annunci stampa e white paper. In generale questi siti abbondano di brochure con descrizioni sommarie dei prodotti, mentre il reperimento di documentazione tecnica approfondita è stato difficoltoso. In alcuni casi però è stato possibile consultare i manuali utente dei prodotti, cosa che si è rivelata molto utile per la verifica della presenza di funzionalità specifiche.

2.2.2 Adesione agli standard Con la sola eccezione di PGP, tutti le soluzioni supportano gli standard PKIX, X.509v3 e LDAP. L’effettiva interoperabilità è però da verificare, perché PKIX lascia un ampio margine di manovra per gli implementatori; c’è comunque da segnalare una sensibilità da parte dei produttori verso queste problematiche, infatti diversi pacchetti segnalano la compatibilità con i più diffusi prodotti concorrenti.

2.2.3 Sospensione dei certificati Nessuno dei pacchetti esaminati supporta la sospensione dei certificati tramite pubblicazione di CSL. Sebbene si possano approssimare le funzioni di sospensione tramite una revoca seguita eventualmente dall’emissione di un nuovo certificato per le stesse chiavi, in alcuni casi sarebbe comodo avere la possibilità di sospendere un certificato senza ricorrere alla revoca. Probabilmente si è considerato il mantenimento di una CSL troppo complicato, ed i casi di effettiva necessità infrequenti. L’unificazione di CSL e CRL in un’unica lista (che si potrebbe chiamare CRSL) consentirebbe di eseguire sospensioni senza aumentare il grado di complessità del sistema, a scapito però dell’interoperabilità con altre soluzioni.

2.2.4 Marcatura temporale Solo la soluzione di Entrust dispone di una TSA per l’attestazione di esistenza ed appartenenza dei documenti.

2.2.5 Modalità di lavoro non in linea La possibilità di lavorare fuori linea, per utenti mobili o in caso di temporanea inaccessibilità della rete, non viene contemplata nella documentazione relativa ai prodotti esaminati. L’effettiva capacità dell’infrastruttura di funzionare anche in queste situazioni rappresenta una caratteristica di rilevante importanza.

2.2.6 Utilizzo di chiavi con usi distinti Sebbene le estensioni standard dei certificati X.509 individuino ben sette distinti possibili usi per le chiavi, l’utilizzo di due chiavi distinte per la cifratura e per la firma è presentata come una innovazione. Fa eccezione la CA di Microsoft che permettere di


- 39 -

specificare per ogni chiave quali sono gli usi consentiti tramite le estensioni standard di X.509. L’unica soluzione che cita esplicitamente la chiave di autenticazione è quella di RSA, che unifica le chiavi di autenticazione e di firma come in iPKI.

2.2.7 Verifica della validità dei certificati E’ necessario esaminare il tipo di verifica che un programma predisposto ad utilizzare i servizi di una PKI effettua sui certificati prima di considerarli validi, perché c’è il rischio che questo controllo non rispetti le politiche stabilite. Si prendano ad esempio le ultime versioni dei due browser più diffusi, Netscape Communicator 4.7 e Microsoft Internet Explorer 5.0, che utilizzano i certificati per stabilire comunicazioni sicure via HTTPS, per applicazioni quali il pagamento di un servizio tramite carta di credito. Per stabilire se un certificato è valido, Communicator esegue queste verifiche:

• il certificato presentato dal server dev’essere firmato da un’autorità fidata o disporre di una catena di certificazione che riconduca ad una tale autorità;

• le chiavi utilizzate per stabilire la connessione devono essere autorizzate a questo specifico uso;

• il periodo di validità dei certificati utilizzati deve comprendere la data attuale.

A queste verifiche Explorer aggiunge, opzionalmente, la verifica che nessun certificato compaia nell’ultima versione della CRL pubblicata dalla CA emittente. Questo tipo di verifica consente di impedire l’uso di una chiave trafugata, o anche di rimediare ad eventuali errori commessi durante l’emissione del certificato. In casi come questi, è compito del programma client mettere a disposizione delle funzionalità che consentano di rispettare le politiche di sicurezza stabilite. Nell’esempio citato, il controllo delle CRL potrebbe avvenire tramite l’uso di un plug-in dedicato, oppure il programma client potrebbe tenere sotto controllo l’archivio di certificati utilizzato da Communicator per individuare l’eventuale presenza di certificati revocati. E’ probabile, nonché auspicabile, che la diffusione di sistemi che utilizzano PKI standard porti ad un progressivo adeguamento delle procedure seguite dai programmi che ne fanno uso. La necessità di un programma che gestisca l’archivio dei certificati per conto dell’utente e per conto delle applicazioni resterebbe comunque inalterata, perché questo consente l’uso di un solo archivio comune a tutte le applicazioni ed un accesso semplificato ai servizi di PKI. Ad esempio, uno sviluppatore di un editor di testi potrebbe includere la possibilità di salvare un documento cifrandone il contenuto, utilizzando una chiave contenuta in un certificato X.509;egli potrebbe decidere, per questioni di portabilità, di non utilizzare le API specifiche di una PKI. In questo caso sarebbe semplice estrarre la chiave dal certificato ed applicare l’algoritmo di cifratura, mentre sarebbe dispendioso recuperare tutti i certificati della catena di certificazione e stabilire una connessione LDAP per la verifica delle CRL. Questo è compito del programma client, che esegue la verifica della validità di un certificato contenuto nell’archivio condiviso prima di fornirlo all’applicazione che lo richiede. In questo modo è anche possibile modificare le


- 40 -

politiche di controllo della validità intervenendo su un unico punto critico: per esempio, imponendo al programma client di accertare lo stato di un certificato in tempo reale via OCSP ad ogni uso dello stesso.

2.2.8 Paradigmi di implementazione di PKI alternativi a quello di iPKI

Diverse soluzioni propongono la gestione della CA in outsourcing, in modo che le responsabilità di gestione vengano ripartite tra il cliente, che si occupa della registrazione, revoca, e key recovery, ed il fornitore, che garantisce l’emissione dei certificati e la sicurezza della CA. Questo tipo di implementazione potrebbe risultare ottimale per una PKI di dimensioni medio-piccole o per soluzioni rapide o a breve termine. Le API di Xeti JKIX, al contrario, sono una risorsa per lo sviluppo di soluzioni ad hoc o per integrare le mancanze delle soluzioni esistenti tramite la realizzazione di programmi facilmente portabili. I vault di IBM Vault Registry rispondono ad esigenze particolari, portando l’architettura crittografica all’interno del sistema operativo, per assicurare la protezione degli ambienti di esecuzione degli utenti che utilizzano risorse di calcolo condivise.

2.2.9 Soluzioni parziali La maggior parte dei pacchetti esaminati fornisce solo una parte delle funzionalità richieste da iPKI. Ad esempio alcuni produttori forniscono solo una CA, o solo una directory. Questo è ragionevole, perché contesti diversi da quello esaminato possono richiedere solo determinate caratteristiche. Ad esempio, qualora si utilizzasse la PKI solo per autenticare la posta elettronica, un programma client general purpose è superfluo: in questo caso la PKI potrebbe essere costituita semplicemente da un programma di e-mail compatibile con PKIX, una directory per l’accesso veloce ai certificati degli utenti, ed una CA che fornisce il servizio in outsourcing. Un’altra possibilità è poi quella di assemblare una PKI utilizzando componenti provenienti da svariate soluzioni, al fine di sfruttarne caratteristiche specifiche. Per fare questo è però ancora necessario eseguire una accurata verifica dell’interoperabilità di tutti i componenti.

2.2.10 Implementazioni di riferimento Esistono attualmente due implementazioni di riferimento per PKI basate sullo standard PKIX. Il NIST (National Institute of Standards and Technology), un’organizzazione governativa americana, ha sviluppato un’implementazione di riferimento all’interno del progetto MISPC (Minimum Interoperability Specification for PKI Components). Lo scopo è quello di fornire una piattaforma di riferimento per testare implementazioni commerciali, ponendo l’accento sulla correttezza dell’implementazione piuttosto che sull’efficienza e la robustezza. Il prodotto, che è disponibile gratuitamente su richiesta, comprende gli eseguibili per Windows e parte del codice sorgente in C++.


- 41 -

Un’altra implementazione di riferimento, conosciuta come Jonah, è sviluppata da IBM, Lotus e Iris. Una versione gratuita, distribuita dal MIT, è disponibile negli USA, ma il supporto è stato interrotto per svilupparne una versione commerciale.

Capitolo 2.3 Scelta di una soluzione

- 42 -

2.3 Scelta di una soluzione Come accennato precedentemente, dai dati rilevati emerge chiaramente che le soluzioni che forniscono un programma client capace di svolgere tutte le funzioni del client di iPKI sono Entrust/PKI e Network Associates NetTools PKI Server con PGP VPN Client. Tra le due, la soluzione che è stata inizialmente scelta per il case study è Entrust/PKI, in quanto si tratta di una soluzione completa che fornisce il più largo numero di funzionalità richieste da iPKI, ed è l’unica tra tutte quelle esaminate dotata di TSA e OCSP. La soluzione di Network Associates, seppur dotata di caratteristiche peculiari che la rendono molto interessante, è stata scartata perché si ritiene sia ancora troppo condizionata dall’eredità di PGP, il cui modello non si adatta alle esigenze delineate per il contesto in cui dovrà operare la PKI selezionata. La versione di Entrust/PKI recensita, la 5.0, è stata rilasciata negli stessi giorni in cui si è svolto il confronto tra le diverse proposte di PKI commerciali. Questo ha indubbiamente favorito Entrust, in quanto la rapida evoluzione di tali prodotti, in questa fase di maturazione del mercato, comporta un progressivo adattamento delle diverse versioni del software alle reali esigenze degli utenti ed alle richieste degli standard emergenti. Ad esempio, una caratteristica fondamentale come l’organizzazione gerarchica e la mutua certificazione delle CA (ribattezzata da Entrust “PKI networking”) è presentata come una novità della versione 5.0. Dai primi test effettuati però, si è evidenziato un grosso limite dell’architettura, che non è evidenziato nella documentazione on-line: l’impossibilità di esportare certificati contenenti anche la chiave privata in formati standard. Entrust consente esclusivamente l’esportazione della chiave privata in un formato proprietario, che può essere interpretato solo dalle applicazioni espressamente progettate per essere compatibili con Entrust (Entrust/Ready). Questo pone dei pesanti limiti nella possibilità di scelta dei programmi che possono usufruire dei servizi dell’infrastruttura PKI, impedendo in particolare l’utilizzo di sistemi operativi che non dispongono del client (ad esempio Linux). Anche per le applicazioni supportate, il passaggio ad una versione più aggiornata dipende dalla presenza di un plug-in che supporti la nuova versione. In definitiva, si tratta di una soluzione chiusa, basata su formati proprietari che legano al produttore. Come è stato più volte evidenziato nel capitolo 1, nella fase attuale gli standard sono in evoluzione, e quindi risulta ancora più determinante mantenere la possibilità di adeguare l’infrastruttura ai nuovi protocolli e servizi, anche per consentirne l’interoperabilità con infrastrutture esterne. Come nota positiva, il software di Entrust è risultato molto semplice da utilizzare e da gestire. L’installazione è lineare e veloce, ed molte operazioni amministrative (rilascio, rinnovo e revoca dei certificati) possono essere svolte in maniera automatica. Anche per l’utente l’interfaccia risulta semplice ed intuitiva. La scelta di Entrust di non consentire l’utilizzo di formati standard è chiaramente dettata da scelte di carattere economico, in quanto un filtro di conversione non

Capitolo 2.3 Scelta di una soluzione

- 43 -

rappresenterebbe tecnicamente una grossa difficoltà realizzativa; Entrust dispone di una vasta base d’utenza che difficilmente potrebbe migrare verso altre soluzioni. Si è allora ritenuto opportuno optare per l’infrastruttura fornita da Windows 2000: si tratta di una soluzione aperta, aderente agli standard e pienamente compatibile con le applicazioni predisposte all’uso di PKI. Questa soluzione è fornita di serie con la versione Server di Windows 2000, e presenta la caratteristica peculiare di essere strettamente integrata nel sistema operativo. La PKI diventa così parte integrante del sistema operativo, riproponendo lo schema che Microsoft aveva seguito a suo tempo integrando le funzioni di navigazione su Internet. La directory che utilizza, Active Directory, è il luogo dove sono conservati non solo i certificati, ma anche tutte le informazioni relative agli utenti, i servizi, le policies, e le risorse aziendali; questa integrazione consente una serie di semplificazioni a livello gestionale e fruitivo. L’Active Directory conserva infatti tutte le informazioni riguardo agli account ed alle politiche di sicurezza, ed è organizzata con uno spazio dei nomi gerarchico, consentendo di gestire utenti, gruppi e computer suddivisi per unità organizzative (Organizational Unit, OU). I diritti amministrativi possono essere delegati ad ogni livello della gerarchia, in modo da consentire una gestione indipendente e decentralizzata delle OU. Le caratteristiche dei server includono replicazione, struttura gerarchica e sincronizzazione flessibile dei dati, oltre alla possibilità di integrare moduli con funzionalità specifiche. Dal lato client manca la possibilità di condividere file cifrati tra gruppi di utenti ed un programma di firma digitale; queste carenze possono però essere facilmente colmate dall’impiego di applicazioni di terze parti predisposte ai servizi PKI, che non richiederebbero particolari adattamenti in quanto l’infrastruttura dispone di numerosi filtri di importazione/esportazione e supporta diversi protocolli per l’accesso alle informazioni. Questo implica anche la completa indipendenza dal sistema operativo ospitante: non è necessario disporre di un client Microsoft per ottenere ed utilizzare un certificato dalla CA.

CAPITOLO 3

- 44 -

3 Implementazione di un case study

a struttura che si intende dare all’implementazione consiste in un un dominio principale di cui fanno parte diversi domini figli, che rappresentano dipartimenti dotati di

autonomia amministrativa. Il dominio principale è denominato “bicocca.local”, ed è dotato di una CA principale (root CA). Per le prove, si creerà un unico dominio figlio “informatica.bicocca.local”, dotato della propria CA emittente (issuing CA), subordinata alla CA principale. La CA subordinata verrà poi certificata dalla CA principale, in modo che i certificati da essa emessi siano riconosciuti all’interno del l’intero dominio.

La CA principale si limita ad emettere certificati per le CA subordinate, le quali hanno invece lo scopo di emettere i certificati relativi agli attori (utenti, computer, recovery agent) appartenenti al proprio dominio figlio.

L

Capitolo 3.1 Installazione e gestione

- 45 -

3.1 Installazione e gestione L’installazione dei server consiste nella definizione del ruolo che il server deve avere all’interno dell’albero dei domini, e nella configurazione dei servizi di Active Directory (AD), Domain Name System (DNS) e Certification Authority (CA).

3.1.1 CA principale Per prima cosa si procede all’installazione del sistema operativo Windows 2000 Server sulla macchina “bingo”, che ospiterà il domain controller di “bicocca.local” e la relativa CA principale. Al termine dell’installazione si avvia il programma di configurazione guidata dei servizi che si intendono rendere disponibili.

Figura 1: Windows 2000 Configure Your Server

Essendo questo il primo server dell’albero di domini, il sistema provvederà a configurare automaticamente i servizi di Active Directory, DHCP e DNS, utilizzando impostazioni di default; parte di queste impostazioni andranno poi modificate in un secondo momento per adeguarle all’integrazione con realtà preesistenti.


- 46 -

In particolare, l’installazione del DNS configura il DHCP per l’assegnazione di indirizzi IP appartenenti al network di classe A 10.X.X.X riservato alle reti private; per consentire l’accesso alla rete pubblica, bisogna impostare gli indirizzi IP correttamente registrati per le macchine in uso.

Figura 2: configurazione automatica di un Domain Controller

In accordo alla topologia pianificata per il test, si definisce il dominio “bicocca.local”, che diventa l’identificativo del dominio nel DNS e nell’Active Directory; il nome di dominio retro-compatibile con versioni precedenti di Windows sarà solo “ bicocca”.

Figura 3: definizione del dominio


- 47 -

A questo punto l’installazione dei servizi di base di un Domain Controller di Windows 2000 è terminata. Per attivare l’infrastruttura PKI è necessario installare “Certificate Services”, un componente opzionale. L’attivazione della procedura di installazione avviene sempre dall’interfaccia di configurazione guidata del server, selezionando “Optional Components” nel menu “Advanced”.

Figura 4: scelta dei componenti opzionali

Una nuova procedura guidata (Windows Components Wizard) ci consente di scegliere i servizi da attivare. Scegliamo “Certificate Services” per la configurazione e gestione della Certification Authority.

Figura 5: installazione di Certificate Services


- 48 -

E’ importante sottolineare che l’installazione dei Certificate Services implica l’impossibilità di modificare il nome del computer e la sua posizione all’interno dell’albero di domini. Il sistema operativo avverte di questo, e poi procede alla configurazione della CA. Nella PKI di Windows 2000 esistono due tipi di CA, Enterprise e Stand-alone, che a loro volta possono essere CA principali o subordinate. Le Enterprise CA sono integrate nell’Active Directory e consentono l’automazione delle procedure di registrazione, pubblicazione e rinnovo dei certificati; le CA Stand-alone sono indipendenti e richiedono l’intervento di un amministratore per l’approvazione delle singole richieste di certificazione. Nel nostro scenario siamo interessati alla gestione avanzata di un grande numero di utenti, e quindi procediamo alla definizione di una Enterprise CA principale.

Figura 6: impostazione di una Enterprise CA principale


- 49 -

Si definiscono i dati identificativi della CA, tra cui il nome che è “Bicocca Root CA”. In questa fase si imposta anche la validità dell’autocertificato che la CA rilascia per sé stessa (2 anni).

Figura 7: dati identificativi della CA principale

Dopo aver impostato ulteriori parametri di minor rilievo, si avvia una fase di inizializzazione dei servizi installati. Al termine di questa fase ed in seguito al riavvio del sistema, il computer “bingo” è il Domain Controller del dominio “bicocca.local”, e ne ospita la CA principale “Bicocca Root CA”.


- 50 -

3.1.2 CA subordinata Procediamo ora alla configurazione del computer “subordinate” come Domain Controller (DC) del dominio figlio “informatica.bicocca.local”, che gestisce le risorse e gli utenti del dipartimento di informatica all’interno dell’organizzazione denominata bicocca.local. Doteremo questo DC di una CA subordinata per la delega delle certificazioni. Al termine dell’installazione del sistema operativo si avvia il programma di configurazione guidata dei servizi che si intendono rendere disponibili, e questa volta specifichiamo che esistono già dei server funzionanti all’interno della rete.

Figura 8: Windows 2000 Configure Your Server

Ora inseriamo il computer nel dominio bicocca.local; l’identificativo del computer nella rete diventa così subordinate.bicocca.local.

Figura 9: inserimento di "subordinate" nel dominio "bicocca.local"


- 51 -

A questo punto si prosegue all’installazione dei servizi desiderati. Cominciamo con la creazione di un dominio figlio, attraverso la configurazione dell’Active Directory. Tornando nella procedura guidata Configure Your Server del pannello di controllo, selezioniamo l’opzione Active Directory.

Figura 10: configurazione di Active Directory

L’Active Directory Installation Wizard ci consente di promuovere questo server a Domain Controller di un nuovo dominio.

Figura 11: creazione di un nuovo Domain Controller


- 52 -

Le schermate seguenti consentono la collocazione del DC all’interno dell’albero di domini, e verificano i diritti di affiliazione. Si arriva così all’assegnazione del nome del dominio:

Figura 12: assegnazione del nome al dominio figlio

Dopo un’altra serie di schermate per la definizione di parametri di minor rilievo, la configurazione dell’Active Directory per il Domain Controller del dominio figlio “informatica.bicocca.local” è conclusa.

Figura 13: riepilogo dei parametri impostati


- 53 -

Passiamo all’installazione della CA subordinata, avviando il Windows Components Wizard come precedentemente illustrato in Figura 4 e Figura 5. Il tipo di CA sarà stavolta Enterprise subordinate CA.

Figura 14: creazione di una CA subordinata

Assegniamo alla CA il nome “Informatica Subordinate CA”, nell’organizzazione Bicocca.

Figura 15: dati identificativi della CA


- 54 -

Ora la CA è pronta per generare una richiesta di certificazione alla CA principale, “Bicocca Root CA”, operante sul computer bingo.bicocca.local.

Figura 16: richiesta di certificazione

Ottenuto il certificato, si avvia una fase di inizializzazione dei servizi installati. Al termine di questa fase ed in seguito al riavvio del sistema, il computer “subordinate” è il Domain Controller del dominio figlio “informatica.bicocca.local”, e ne ospita la CA subordinata “Informatica Subordinate CA”. Grazie al certificato rilasciato dalla CA principale, tutti i certificati emessi dalla CA subordinata saranno automaticamente riconosciuti all’interno dell’intero dominio “bicocca.local”.


- 55 -

3.1.3 Impostazione dei parametri di emissione A questo punto abbiamo la CA principale “Bicocca Root CA” e la CA subordinata “Informatica Subordinate CA” operative e funzionanti. Non è però ancora possibile per gli utenti del dominio informatica.bicocca.local ottenere certificati, perché l’installazione guidata non provvede a configurare i permessi di emissione per i domini figli. Vediamo cosa succede. Il modo preferibile per richiedere un certificato in Windows 2000 è quello di utilizzare il Certificate Request Wizard; per attivarlo occorre caricare il Certificates Snap-in nella Microsoft Management Console.

Figura 17: inserimento del Certificates Snap-in nella MMC


- 56 -

Per richiedere un nuovo certificato, si deve selezionare l’opzione “Request New Certificate… ” come illustrato in Figura 18.

Figura 18: attivazione del Certificate Request Wizard

Ora, se questa operazione è eseguita da un utente del dominio informatica.bicocca.local, invece del wizard compare il seguente messaggio di errore:

Figura 19: mancato avvio del Certificate Request Wizard

Il messaggio è fuorviante perché potrebbe far pensare ad un problema di comunicazione del client con la CA di dominio, mentre invece il problema è un altro: Windows ha contattato le CA raggiungibili, ma di queste nessuna ha l’autorizzazione ad emettere un certificato per l’utente. Nelle Enterprise CA di Windows 2000 tutti i certificati sono generati a partire da modelli, detti template, che ne definiscono le caratteristiche. Perché un utente possa ottenere un determinato tipo di certificato devono verificarsi due condizioni:

• l’utente deve avere il permesso “Enroll” nell’Access Control List del template del certificato (paragrafo 3.1.3.1);

• la CA deve avere il template del certificato nei propri Policy Settings (paragrafo 3.1.3.2).


- 57 -

3.1.3.1 Assegnazione dei diritti di Enroll agli utenti di informatica.bicocca.local La modifica dei diritti di accesso ai template dei certificati avviene utilizzando lo “Active Directory Sites and Services” Snap-in. Una volta avviato bisogna attivare la visualizzazione dei dati relativi ai servizi, con l’opzione “Show Services Node”.

Figura 20: visualizzazione dei servizi pubblicati nell’AD

In questo modo si può accedere a tutti i template di certificati presenti nell’Active Directory. Il nostro obbiettivo è quello di emettere certificati utente per la firma e per la cifratura, e per questo abiliteremo gli utenti di informatica.bicocca.local alla richiesta di certificati di tipo UserSignature (per la firma) e User (per la cifratura3).

3 Il template User consente l’utilizzo del certificato sia per la cifratura che per la firma. Sarà poi a discrezione dell’utente utilizzarlo solo per la cifratura, ed usare invece il certificato SignatureOnly per la firma.


- 58 -

Illustriamo ora la procedura di abilitazione per il template UserSignature. Cominciamo con l’esame delle proprietà del template:

Figura 21: modifica delle proprietà del template UserSignature

Dall’esame del pannello “Security” risulta che gli utenti di informatica.bicocca.local non hanno il permesso “Enroll” per questo template.

Figura 22: L’ACL di UserSignature


- 59 -

Si aggiunge quindi il gruppo “Domain Users” di informatica.bicocca.local nella lista, assegnando il diritto “Enroll”.

Figura 23: modifica dell’ACL di UserSignature

La stessa operazione viene ripetuta per il template “User”, che verrà utilizzato per la cifratura.

3.1.3.2 Impostazione dei Policy Settings della CA Il controllo della CA avviene tramite lo Snap-in “Certification Authority”. L’impostazione dei Policy Settings regola i tipi di certificati che la CA può emettere. I certificati di tipo “User” sono presenti tra quelli impostati di default per le Enterprise CA, mentre manca il tipo “UserSignature”. Procediamo all’aggiunta di questo template nei Policy Settings della CA subordinata.

Figura 24: aggiunta di un template ai Policy Settings della CA


- 60 -

Selezioniamo il template “UserSignature” per la firma elettronica.

Figura 25: scelta del template

La CA subordinata è ora abilitata all’emissione di certificati “UserSignature” per la firma e “User” per la cifratura.

Figura 26: i Policy Settings della CA


- 61 -

3.1.4 Gestione dei certificati 3.1.4.1 Creazione di un utente Le Enterpise CA rilasciano certificati per le diverse tipologie di utenti, amministratori, servizi e computer del dominio di appartenenza. Per emettere un certificato utente è quindi necessario per prima cosa inserire l’utente nella lista degli utenti di dominio. Questa procedura è quella standard utilizzata in Windows 2000, indipendentemente dalla presenza di una PKI, e quindi sarà illustrata solo sommariamente. Per prima cosa creiamo una Organizational Unit, “mlab”, all’interno del dominio informatica.bicocca.local. Questa rappresenterà un laboratorio di ricerca la cui gestione è delegata ad un amministratore locale.

Figura 27: creazione di una Organizational Unit


- 62 -

All’interno di mlab creiamo ora un profilo per l’utente Pippo, seguendo la procedura standard di Windows 2000.

Figura 28: creazione di un utente nella OU mlab

Conclusa la creazione dell’utente, è molto importante a questo punto inserire nel suo profilo l’indirizzo e-mail. Se questo non viene fatto, tale indirizzo non risulterà nei certificati dell’utente, ed egli non potrà quindi utilizzarli per firmare messaggi o ricevere documenti cifrati utilizzando la posta elettronica.


- 63 -

L’inserimento dell’indirizzo e-mail avviene modificando l’apposito campo nella finestra delle Properties dell’utente.

Figura 29: inserimento dell’indirizzo e-mail nel profilo utente

Pippo potrà ora richiedere certificati utilizzando il Certificate Request Wizard (paragrafo 3.1.4.2) oppure la procedura di richiesta via pagine web (paragrafo 3.1.4.3). Potrà poi utilizzare l’indirizzo e-mail [email protected] per l’invio e la ricezione di messaggi cifrati.

3.1.4.2 Ottenimento di un certificato tramite Certificate Request Wizard In questa sezione illustreremo l’utilizzo del Certificate Request Wizard da parte dell’utente Pippo per la richiesta, creazione ed installazione di un certificato di tipo UserSignature per la firma elettronica.


- 64 -

L’avvio del wizard avviene come illustrato in Figura 17 e Figura 18; rispetto al paragrafo 3.1.3 (Figura 19), questa volta i permessi sono impostati correttamente, e quindi si presenterà la schermata introduttiva del wizard.

Figura 30: il Certificate Request Wizard

Scegliamo il template UserSignature per la firma elettronica.

Figura 31: scelta del template


- 65 -

Per comodità di gestione, è opportuno attribuire al certificato un nome di riferimento ed una breve descrizione dell’origine. Questo si rivelerà utile quando l’utente disporrà di diversi certificati ottenuti da autorità diverse e con scopi diversi.

Figura 32: assegnazione di un nome al certificato

La coppia di chiavi (privata e pubblica) viene generata dal client. La chiave pubblica è inviata alla CA che provvede ad inserirla in un certificato firmato.

Figura 33: la richiesta ha avuto successo


- 66 -

A questo punto l’utente installa il certificato nel proprio archivio personale (Personal Certificate Store).

Figura 34: il Personal Certificate Store dell’utente Pippo

Esaminando il certificato l’utente ottiene informazioni riguardo agli usi consentiti per la chiave, all’identità dell’autorità emittente ed al periodo di validità del certificato. Si noti che il certificato in possesso dell’utente include anche la chiave privata.

Figura 35: il certificato ottenuto


- 67 -

Con una procedura analoga l’utente Pippo richiede ed ottiene anche un certificato di tipo User, che userà in seguito per abilitare la ricezione di messaggi e-mail cifrati.

3.1.4.3 Ottenimento di un certificato via Web Un modo alternativo di ottenere certificati è quello di utilizzare il Microsoft Certificate Services web site. Questo sito è raggiungibile con qualunque browser predisposto ai servizi PKI, risultando quindi utilizzabile dagli utenti che non dispongono di una versione di Windows 2000. Illustreremo qui l’esempio dell’utente Pluto che richiede un certificato di tipo UserSignature, utilizzando Internet Explorer 5 in ambiente Windows 2000; un esempio di utilizzo del sito con programmi non Microsoft sarà dato nel paragrafo 3.2.1.3. L’URL del sito è della forma http://nome_del_dominio/certsrv, quindi nel caso dell’utente Pluto, appartenente alla OU mlab nel dominio figlio informatica.bicocca.local, l’indirizzo a cui accedere sarà http://informatica.bicocca.local/certsrv. L’accesso a questo sito è riservato agli utenti del dominio, ed è quindi necessario autenticarsi secondo la procedura standard per l’autenticazione a segreto condiviso.

Figura 36: autenticazione utente


- 68 -

Verificata l’identità ed i permessi del client, il server web presenta la pagina dei Certificate Services.

Figura 37: il sito web della CA di informatica.bicocca.local

Per la richiesta di un certificato UserSignature scegliamo di utilizzare la modalità avanzata, tramite la quale si arriva alla scelta della modalità di inoltro delle richiesta alla CA. Scegliamo di utilizzare un modulo on-line.

Figura 38: richiesta avanzata di certificazione


- 69 -

Nel modulo specifichiamo che il certificato richiesto è di tipo UserSignature. Si noti l’opzione per rendere la chiave privata esportabile, che è necessaria qualora si desiderasse trasferire il certificato all’esterno del dominio di Windows 2000.

Figura 39: modulo per la richiesta di un certificato UserSignature


- 70 -

Inoltrando la richiesta, il browser procede a creare la coppia di chiavi ed a spedire la chiave pubblica alla CA per ottenere la certificazione. Il certificato generato e firmato sarà memorizzato nel Personal Certificate Store dell’utente e pubblicato nell’Active Directory.

Figura 40: il certificato è stato emesso

3.1.4.4 Recupero di un certificato utente dall’Active Directory Per recuperare un certificato utente, Windows 2000 mette a disposizione la funzione di ricerca Find People, che si attiva direttamente dal menu Start.

Figura 41: avvio di Find People


- 71 -

Si possono specificare diversi parametri di ricerca, e lo stesso programma può essere utilizzato sia per ricerche all’interno dell’AD di dominio, che per ricerche in directory pubbliche su Internet o nel proprio Address Book.

Figura 42: l’interfaccia di Find People

Una volta individuato un utente le cui caratteristiche corrispondono ai criteri di ricerca, è possibile esaminare ed eventualmente esportare i suoi certificati per utilizzarli nelle applicazioni predisposte alla PKI.

Figura 43: i certificati dell'utente


- 72 -

Il recupero di un certificato utente può anche essere eseguito direttamente dall’applicazione che intende farne uso, come ad esempio illustrato in Figura 53.

3.1.4.5 Revoca di un certificato La revoca di un certificato avviene tramite il Certification Authority Snap-in, già incontrato nel paragrafo 3.1.3.2. La procedura di revoca si attiva selezionando il certificato da revocare e scegliendo l’operazione Revoke Certificate nel menu contestuale.

Figura 44: revoca di un certificato

Si specifica poi il motivo della revoca. Nell’esempio ipotizziamo la compromissione della chiave privata.

Figura 45: motivo della revoca


- 73 -

L’effettiva revoca del certificato avverrà quando sarà pubblicata una Certificate Revocation List (CRL) aggiornata. La frequenza di pubblicazione può essere modificata tramite il pannello delle proprietà dei certificati revocati.

Figura 46: parametri di pubblicazione delle CRL

Si può anche emettere subito una CRL aggiornata, nel caso in cui sia urgente rendere effettiva la revoca del certificato.

Figura 47: pubblicazione immediata di una CRL aggiornata


- 74 -

La CRL contiene i numeri seriali di tutti i certificati revocati fino al momento dell’emissione, insieme alla data di revoca ed alla motivazione del provvedimento.

Figura 48: contenuto della CRL

Le CRL sono pubblicate nell’Active Directory e sul sito web del dominio di appartenenza della CA. Gli indirizzi possono essere ricavati direttamente dai certificati emessi, nell’estensione “CRL Distribution Points”, ed acceduti manualmente od in automatico dai programmi che verificano lo stato di validità del certificato.

Figura 49: indirizzi per il reperimento delle CRL

Vedremo un esempio degli effetti della revoca di un certificato nel paragrafo 3.2.1.4.

Capitolo 3.2 Applicazioni

- 75 -

3.2 Applicazioni

3.2.1 Cifratura e firma di e-mail con S/MIME Per illustrare l’utilizzo della PKI per lo scambio di posta elettronica sicura, individuiamo tre tipologie di utente:

• utenti interni al dominio informatica.bicocca.local, che usano la PKI di Windows 2000 (paragrafo 3.2.1.1);

• utenti esterni, che non appartengono al dominio e non utilizzano la stessa infrastruttura (paragrafo 3.2.1.2);

• utenti interni al dominio che usano sistemi operativi ed applicazioni client diversi da quelli forniti da Windows 2000 (paragrafo 3.2.1.3).

3.2.1.1 Scambio di messaggi tra utenti interni al dominio Il client di posta elettronica fornito da Windows 2000 è Outlook Express 5. Vediamo come l’utente Pippo può utilizzare questo programma per inviare un messaggio e-mail cifrato e firmato all’utente Pluto. Pippo ha già ottenuto i propri certificati di firma e di cifratura come illustrato nel paragrafo 3.1.4.2: deve ora configurare Outlook Express per utilizzare tali certificati. Il programma è in grado di gestire più account di posta contemporaneamente; per associare i certificati digitali ad un determinato account selezioniamo l’opzione “Accounts… ” nel menu “Tools”.

Figura 50: gestione degli account in Outlook Express


- 76 -

Nelle proprietà dell’account [email protected] impostiamo l’utilizzo dei certificati ottenuti in precedenza, per la firma e per la cifratura.

Figura 51: scelta dei certificati

Ora Pippo è in grado di firmare i messaggi che invia. Per poterli cifrare deve entrare in possesso del certificato di cifratura dei destinatari, in modo che dopo aver cifrato il messaggio con la chiave pubblica presente nel certificato, solo il destinatario sarà in grado di interpretarne il contenuto. La rubrica di Outlook Express si interfaccia direttamente con l’Active Directory; possiamo quindi recuperare il certificato dell’utente Pluto selezionando la funzione di ricerca persone all’interno dell’Address Book.

Figura 52: la funzione di ricerca persone della rubrica


- 77 -

Cerchiamo il nome Pluto; il risultato si può aggiungere direttamente nella propria rubrica personale, completo di dati anagrafici, indirizzo e-mail e certificati digitali.

Figura 53: ricerca nell’Active Directory

Figura 54: i certificati associati all’utente trovato


- 78 -

Per spedire un messaggio, selezioniamo Send E-Mail nel menu contestuale relativo alla entry di Pluto nella lista dei contatti.

Figura 55: invio di un messaggio

La composizione del messaggio avviene normalmente. Possiamo però impostare le funzioni di sicurezza:

• “Sign” genera un’impronta del messaggio, la cifra con la chiave privata di firma di Pippo e la allega al messaggio;

• “Encrypt” cifra il messaggio con la chiave pubblica di cifratura di Pluto prima di spedirlo.

Figura 56: firma e cifratura del messaggio


- 79 -

Vediamo cosa succede quando Pluto, che è a sua volta un utente del dominio informatica.bicocca.local, riceve il messaggio. Outlook Express avverte l’utente che il messaggio include delle funzionalità avanzate di sicurezza:

Figura 57: ricezione di un messaggio firmato e cifrato

Dopo aver mostrato il messaggio di avviso, Outlook Express decifra il messaggio usando la chiave privata di cifratura di Pluto, e verifica la firma. Per verificare la firma, decifra l’impronta allegata al messaggio con la chiave pubblica di firma di Pippo, e confronta questa impronta con quella generata applicando lo stesso algoritmo di hash al testo del messaggio. La chiave pubblica di firma di Pippo è contenuta nel certificato allegato al messaggio; la validità di questo messaggio è a sua volta verificata.


- 80 -

Al termine di queste operazioni, Pluto può leggere il messaggio; le icone sulla destra ed il campo “Security” nella finestra di lettura del messaggio indicano che la firma è stata verificata e che il contenuto è cifrato.

Figura 58: lettura del messaggio


- 81 -

Si possono esaminare i dettagli relativi alla sicurezza del messaggio, guardando i certificati, gli algoritmi utilizzati ed il tipo di verifiche eseguite. Si noti che è stato verificato lo stato di revoca del certificato di firma.

Figura 59: informazioni relative alla sicurezza del messaggio

La verifica della revoca è svolta opzionalmente da Outlook Express, e di default è disattivata. L’attivazione, che era stata eseguita prima di leggere il messaggio, si effettua nel pannello “Advanced Security Settings” nelle opzioni del programma.

Figura 60: impostazione del controllo CRL


- 82 -

3.2.1.2 Scambio di messaggi con utenti esterni Cosa succede quando un utente del dominio bicocca.local invia un messaggio firmato ad un utente esterno al dominio? Il ricevente del messaggio non riconosce l’autorità di “Bicocca Root CA”, né quella di “Informatica Subordinate CA”, e quindi la firma apposta al messaggio risulterà non fidata.

Figura 61: ricezione di un messaggio con firma non fidata


- 83 -

Esaminiamo il certificato allegato al documento: non c’è nessuna catena di certificazione che lo riconduce ad una CA fidata.

Figura 62: il certificato non riconosciuto

Per rendere possibile la comunicazione, l’utente deve riconoscere l’autorità della CA che ha emesso il certificato. Vediamo come deve procedere. Per prima cosa l’utente deve entrare in possesso del certificato della CA emittente; l’estensione “Authority Information Access” contiene l’URL dell’indirizzo da cui possiamo scaricare il certificato, usando il protocollo HTTP.

Figura 63: individuazione dell’indirizzo del certificato della CA emittente


- 84 -

E’ sufficiente copiare l’indirizzo in un browser web per scaricare il certificato ed aprirlo.

Figura 64: apertura del certificato della CA

Ora che possediamo il certificato della CA, ne impostiamo i parametri per la fiducia esplicita.

Figura 65: impostazione dei parametri di riconoscimento


- 85 -

Torniamo adesso al certificato allegato al messaggio e-mail. Esso risulta valido, perché è ora riconducibile ad una autorità firmata. Esaminiamo più in dettaglio la catena di certificazione, che consta di cinque anelli. Cominciamo dal fondo della catena, ovvero dal certificato di Pluto: esso è stato emesso da “Informatica Subordinate CA”, che è una CA subordinata di “Bicocca Root CA”. Questa CA è stata inserita (vedi Figura 65) nella Certificate Trust List dell’utente (ale), la cui autorità è implicita. L’utente dispone di certificati validi e verificati per tutti gli anelli della catena, e quindi il certificato di Pluto è valido.

Figura 66: catena di certificazione del certificato di Pluto

L’utente può finalmente verificare la firma apposta al messaggio.

Figura 67: messaggio con firma riconosciuta


- 86 -

3.2.1.3 Utilizzo di altri sistemi operativi La PKI di Windows 2000 si basa su protocolli e formati standard, che ne consentono l’interazione con applicazioni predisposte all’utilizzo di un’infrastruttura a chiave pubblica, senza che queste necessitino di modifiche. Questa caratteristica si rivela utile in molti contesti: prenderemo ad esempio il caso dell’utente Linus, appartenente al dominio informatica.bicocca.local, che ha necessità di utilizzare il sistema operativo Linux. Il client di posta elettronica utilizzato sarà Netscape Communicator 4.61. Per ottenere i certificati, non potendo utilizzare il Certificate Request Wizard di Windows 2000, l’utente Linus ha due possibilità: accedere al sito web di “Informatica Subordinate CA” o importare un certificato precedentemente ottenuto e salvato su file. La procedura di richiesta di un certificato tramite accesso al sito web è simile a quella effettuata tramite Internet Explorer. L’accesso al sito è riservato agli utenti del dominio, quindi Linus provvederà ad autenticarsi utilizzando il proprio account nel dominio informatica.biccca.local.

Figura 68: accesso al sito web della CA

Prima di richiedere un certificato personale, Linus deve installare il certificato della CA (con Windows 2000 questo non è necessario perché i certificati delle CA di dominio vengono inseriti automaticamente in tutti i profili utente).

Figura 69: pagina per l’ottenimento del certificato della CA


- 87 -

Per accertarsi dell’autenticità del certificato, l’utente Linus può confrontare l’impronta (fingerprint) del certificato con l’impronta del certificato della CA, ottenuta con un altro mezzo.

Figura 70: verifica dell’autenticità del certificato

L’installazione consente di specificare il tipo di certificati per i quali si riconosce l’autorità di questa CA.

Figura 71: installazione del certificato


- 88 -

Adesso Linus può procedere alla richiesta di un proprio certificato utente.

Figura 72: richiesta di un certificato utente

Si noti che le chiavi sono generate dal client: sarà quindi Communicator a generarle, per poi richiederne la certificazione alla CA.

Figura 73: generazione della coppia di chiavi


- 89 -

Il certificato è ora pronto per essere installato.


L’altra possibilità per utilizzare un certificato è quello di ottenerlo in Windows 2000 e poi esportarlo. Questa operazione è necessaria qualora si intenda utilizzare lo stesso certificato in diversi sistemi operativi o applicazioni che non si interfacciano direttamente con l’architettura di Windows 2000.


- 90 -

L’esportazione di un certificato si esegue avviando il Certificate Export Wizard dal Certificates Snap-in.

Figura 75: avvio del Certificate Export Wizard

E’ fondamentale specificare l’esportazione della chiave privata, altrimenti il certificato potrà essere utilizzato solo per operazioni di verifica.

Figura 76: esportazione della chiave privata


- 91 -

Una volta che il certificato è stato memorizzato in un file, utilizzando il formato standard Personal Information Exchange (PKCS #12), è possibile importarlo in Netscape Communicator.

Figura 77: l’archivio di certificati di Communicator

Figura 78: importazione di un certificato


- 92 -

Adesso Linus può decifrare i messaggi ricevuti e verificarne la firma.

Figura 79: ricezione di un messaggio firmato e cifrato

Può anche a sua volta cifrare e firmare i messaggi che spedisce.

Figura 80: firma e cifratura di un messaggio


- 93 -

3.2.1.4 Invalidazione di una firma con certificato revocato Vediamo gli effetti della revoca del certificato di firma dell’utente Pippo illustrata nel paragrafo 3.1.4.5. Quando Pluto riceve un messaggio firmato da Pippo, Outlook Express verifica l’ultima CRL emessa dalla CA, e vi trova il certificato utilizzato per firmare il messaggio. Questo viene segnalato all’utente come in Figura 81.

Figura 81: il certificato di firma è stato revocato


- 94 -

Esaminando il certificato allegato si può verificare che il certificato non può essere convalidato a causa di una revoca da parte della “Informatica Subordinate CA” che lo aveva emesso.

Figura 82: il certificato revocato

E’ comunque possibile leggere il contenuto del messaggio.

Figura 83: il messaggio ricevuto


- 95 -

3.2.2 Comunicazione web sicura con HTTPS Metteremo ora alla prova le capacità della PKI di Windows 2000 riguardo alla cifratura ed autenticazione del contenuto di un sito web. Iniziamo impostando l’ACL del template WebServer, per la certificazione di server web, analogamente a quanto fatto in 3.1.3.1; in questo caso il diritto di enroll viene assegnato solo agli amministratori.

Figura 84: proprietà del template WebServer


- 96 -

Per il test realizziamo un sito di prova, utilizzando il Web Site Creation Wizard, ed alcuni documenti HTML ai quali assoceremo diversi gradi di sicurezza. Il sito sarà ospitato dal Domain Controller di informatica.bicocca.local.

Figura 85: creazione di un sito web

Una volta creato il sito “Test HTTPS” e le pagine contenute, possiamo impostarne le proprietà.

Figura 86: impostazione delle proprietà del sito


- 97 -

Nel pannello “Directory Security” si possono impostare le limitazioni di accesso al sito. La nostra intenzione è quella di utilizzare i certificati digitali per l’autenticazione e la confidenzialità, quindi per prima cosa dobbiamo ottenere un certificato per il server.

Figura 87: il pannello Directory Security

Selezionando “Server Certificate… ” si avvia il Web Server Certificate Wizard, che raccoglie le informazioni necessarie ed inoltra la richiesta alla CA prescelta.

Figura 88: richiesta di un Web Server Certificate


- 98 -

Al termine della procedura disponiamo di un certificato per il nostro sito web.


Per abilitare il protocollo SSL è necessario specificare la porta da utilizzare. Impostiamo questo valore a 443, la porta standard di HTTPS.

Figura 90: assegnazione della porta SSL


- 99 -

E’ ora possibile attivare le funzioni di sicurezza e di controllo sulle singole pagine del sito. Esamineremo quattro diversi modelli di sicurezza:

• autenticazione del server e cifratura delle comunicazioni (paragrafo 3.2.2.1); • autenticazione del client tramite presentazione di un certificato digitale

(paragrafo 3.2.2.2); • controllo dell’accesso tramite mappatura molti a uno (paragrafo 3.2.2.3); • controllo dell’accesso tramite mappatura uno a uno (paragrafo 3.2.2.4).

3.2.2.1 Autenticazione server e cifratura In questo paragrafo mostreremo come impostare una pagina web in modo che la comunicazione tra il server ed il client sia cifrata, e l’autenticità del server sia verificata. Dallo “Internet Information Services Snap-in” impostiamo le proprietà del file “cifrato.html”:

Figura 91: impostazione delle proprietà di "cifrato.html"


- 100 -

Dal pannello “file security”, impostiamo i parametri per la comunicazione sicura.

Figura 92: il pannello File Security

Selezioniamo l’opzione “Require secure channel” per imporre la cifratura della comunicazione con SSL.

Figura 93: impostazione di SSL


- 101 -

Esaminiamo l’effetto di questa impostazione su un client che tenta di accedere alla pagina. Digitando l’indirizzo http://informatica.bicocca.local/cifrato.html si ottiene un messaggio d’errore: l’accesso alla pagina è consentito solo tramite SSL.

Figura 94: tentativo di accesso alla pagina tramite HTTP

Per abilitare la comunicazione tramite SSL, bisogna inserire “https” nell’indirizzo. Riprovando quindi con https://informatica.bicocca.local/cifrato.html, il browser avvisa che sta utilizzando una connessione sicura per ottenere le pagine richieste.

Figura 95: avviso di inizio comunicazione cifrata


- 102 -

Possiamo ora visualizzare il contenuto della pagina. Si noti il lucchetto chiuso sulla barra di stato del browser, ad indicare che la comunicazione è cifrata e l’identità del server è stata verificata.

Figura 96: la pagina cifrata

Possiamo visualizzare informazioni più dettagliate sui protocolli utilizzati selezionando “Properties” dal menu “File” del browser.

Figura 97: accesso alle proprietà della pagina


- 103 -

Si possono esaminare i dati relativi al protocollo utilizzato (SSL 3.0) ed alla lunghezza delle chiavi utilizzate (56 bit per la cifratura e 1024 bit per lo scambio di chiavi). Si può anche visualizzare il certificato del server.

Figura 98: proprietà della pagina e della connessione


- 104 -

3.2.2.2 Autenticazione client Impostiamo le proprietà della pagina “riservato.html” in modo che possa essere acceduto solo dai client che si autenticano con un certificato digitale riconosciuto. Rispetto a quanto fatto nel paragrafo 3.2.2.1, oltre alla impostazione di SSL, richiediamo che il client fornisca un certificato.

Figura 99: impostazione dei certificati client

Quando un utente (nell’esempio, Pluto) tenta di accedere alla pagina, il browser gli chiede di scegliere, tra i certificati in suo possesso abilitati all’autenticazione client, quale intende usare per identificarsi.

Figura 100: scelta del certificato da utilizzare per l’autenticazione


- 105 -

Scegliendo un certificato valido che sia riconosciuto dal server, si può visualizzare la pagina.

Figura 101: la pagina riservata

3.2.2.3 Mappatura molti a uno La modalità di autenticazione illustrata in 3.2.2.2 si limita a richiedere la presentazione di un certificato valido, senza discriminare tra i diversi utenti. Per controllare l’accesso alle risorse, limitandone la visione a solo una parte degli utenti, si utilizza la modalità di mappatura dei certificati in account Windows. Vedremo qui la mappatura molti a uno, e nel prossimo paragrafo la mappatura uno a uno. Ricordiamo che l’autenticazione client nei protocolli SSL e TLS avviene attraverso la mappatura delle credenziali (certificati) in account di utenti Windows esistenti. In questo modo l’assegnazione dei diritti per il controllo dell’accesso risulta indipendente dal tipo di autenticazione utilizzato, sia esso a segreto condiviso (login e password) o a chiave pubblica (certificato digitale). La mappatura molti a uno consente di mappare un determinato insieme di certificati su un singolo account di Windows; in pratica, tutti i possessori di un certificato appartenente all’insieme possono accedere alle pagine impersonando l’utente sul cui account sono mappati i certificati.


- 106 -

Impostiamo le proprietà della pagina “mappato.html” in modo che utilizzi SSL, richieda l’autenticazione del client ed esegua la mappatura dei certificati.

Figura 102: abilitazione della mappaura di certificati

Selezionando “Edit… ” possiamo specificare i parametri di mappatura. Dal pannello Many-to-1 scegliamo “Add… ” per aggiungere una mappatura.

Figura 103: il pannello Many-to-1


- 107 -

Le mappature sono realizzate da regole che associano una determinata caratteristica del certificato ad un account Windows esistente. Creiamo una regola che associ i certificati rilasciati da “Informatica Subordinate CA” nell’utente utente_internet del dominio informatica.bicocca.local.

Figura 104: aggiunta di una regola

Figura 105: scelta dell’account su cui verranno mappati i certificati


- 108 -

Un’altra accortezza da avere è quella di correggere le impostazioni del controllo di accesso nelle proprietà della pagina.

Figura 106: impostazione del controllo di accesso alla pagina

Bisogna rimuovere l’accesso anonimo, che è consentito di default.

Figura 107: selezione dei metodi di autenticazione consentiti


- 109 -

Quando un utente tenta di accedere alla pagina gli viene richiesta la presentazione di un certificato; se egli presenta un certificato rilasciato da “Informatica Subordinate CA”, questo verrà mappato sull’account Windows utente_internet. Se l’utente utente_internet gode del diritto di lettura nell’ACL del file “mappato.html”, il browser mostrerà il contenuto della pagina.

Figura 108: accesso alla pagina


- 110 -

3.2.2.4 Mappatura uno a uno La mappatura uno a uno consente di associare un determinato certificato ad un determinato account Windows. Useremo questa modalità per associare il certificato di firma dell’utente Pluto con il suo account nel dominio informatica.bicocca.local, nelle proprietà della pagina “solo_per_pluto.html”.

Figura 109: il pannello di mappatura 1-to-1

Selezioniamo il certificato di Pluto, precedentemente esportato in formato ASCII (con codifica Base-64).

Figura 110: scelta del certificato da mappare


- 111 -

Lo mappiamo sull’account di Pluto nel dominio informatica.bicocca.local.

Figura 111: scelta dell’account su cui mappare il certificato

Quando Pluto tenta di accedere alla pagina il browser gli chiede quale certificato intenda utilizzare. Scegliendo il certificato che è stato mappato, egli potrà visualizzare la pagina. Si noti che l’utente Pluto ha il permesso di lettura nell’ACL del file “solo_per_pluto.html”, e che l’accesso anonimo è stato rimosso come in Figura 107.

Figura 112: accesso alla pagina


- 112 -

3.2.3 Cifratura di file con EFS La cifratura di un file utilizzando EFS è molto semplice: la cifratura è impostata come un attributo del file. Cliccando con il tasto destro del mouse su un file, si apre un menu contestuale dal quale possiamo accedere alle proprietà del file.

Figura 113: accesso alle proprietà del file

Selezionando “Advanced” dal pannello “General” arriviamo alla finestra di impostazione degli attributi avanzati. Da qui selezioniamo di cifrare il file in questione.

Figura 114: impostazione dei parametri di compressione


- 113 -

Osservando il file da Windows Explorer, notiamo che viene evidenziato l’attributo che indica che il file è cifrato. Ora soltanto l’utente Pluto, che ha cifrato il file, ed il recovery agent, che ha diritti di recupero di file cifrati, saranno in grado di leggerne il contenuto.

Figura 115: il file cifrato

Pluto accede al file normalmente: può leggere, modificare e salvare il file senza preoccuparsi di cifrarlo ogni volta, perché questo avviene trasparentemente. Il file non viene mai scritto in chiaro sul disco, perché il sistema provvede a cifrare i dati in memoria prima di scriverli.

Figura 116: modifica del file cifrato


- 114 -

Se un altro utente tenta di leggere il file, si trova l’accesso negato, anche se l’ACL gliene consentirebbe la lettura.

Figura 117: negazione dell’accesso

Eseguendo le operazioni di Figura 113 e Figura 114 su una directory, il sistema offre la possibilità di cifrare tutto il contenuto della directory ricorsivamente.

Figura 118: parametri di cifratura per l’albero delle directory

Quando una directory è cifrata, tutti i nuovi documenti creati all’interno di tale directory verranno automaticamente cifrati. Vediamolo in un esempio: creiamo un nuovo file di testo.

Figura 119: creazione di un nuovo file in una directory cifrata


- 115 -

Da Windows Explorer si può vedere che il file creato è cifrato. In questo modo si evita di avere una copia in chiaro sul disco prima di cifrarla: questo risulta particolarmente utile nel caso si utilizzino programmi che creano copie temporanee dei file in uso, ad esempio Microsoft Word.

Figura 120: il file è automaticamente cifrato

Per avere informazioni su un file cifrato, si può utilizzare il programma “efsinfo” fornito con il Windows 2000 Resource Kit. Questo programma consente di ricavare informazioni sullo stato di cifratura di un file, sull’utente che lo ha cifrato, l’impronta del certificato utilizzato, ed informazioni sul recovery agent. La figura seguente illustra alcuni usi del programma.

Figura 121: il programma efsinfo


- 116 -

Per verificare che l’utente sia in possesso del certificato corretto si può verificare la corrispondenza delle impronte, ricavando questa informazione dai dettagli del certificato.

Figura 122: l’impronta del certificato

Il data recovery in caso di smarrimento della chiave è semplice quanto la cifratura, e consiste nell’operazione inversa. Il recovery agent (in questo caso INFORMATICA\Administrator, come mostrato in Figura 121) rimuove l’impostazione di cifratura dagli attributi avanzati del file. In questo modo il file viene decifrato, e l’utente può cifrarlo nuovamente utilizzando una nuova chiave.

Figura 123: rimozione della cifratura


- 117 -

3.2.4 Autenticazione tramite smart card L’accesso al sistema tramite smart card non è stato provato in quanto non si disponeva dell’hardware necessario (smart card, scrittore e lettore). L’impostazione segue comunque il modello dell’autenticazione client HTTPS (paragrafo 3.2.2), con la mappatura dei certificati in account utente esistenti.

Figura 124: mappatura di certificati su un account utente

Si possono scegliere diversi certificati, per gestire situazioni in cui un utente disponga di certificati rilasciati da diverse autorità.

Figura 125: informazioni sui certificati mappati


- 118 -

In una fase iniziale si può consentire agli utenti di utilizzare sia l’autenticazione forte tramite smart card che l’autenticazione standard di Windows con login e password. Una volta che il funzionamento del meccanismo di autenticazione con smart card è stato acquisito dagli utenti, è opportuno imporne l’uso come unico meccanismo di autenticazione, al fine di sfruttarne tutti i vantaggi dal punto di vista della sicurezza.

Figura 126: impostazione delle modalità di logon

Capitolo 3.3 Considerazioni

- 119 -

3.3 Considerazioni

3.3.1 Carenze Le carenze principali individuate nella PKI di Windows 2000 sono la mancanza di alcune funzioni dal lato client, come già evidenziato nel capitolo 2.3, e la limitazione a 56 bit nella cifratura a chiave simmetrica.

3.3.1.1 Client Le funzioni di cifratura di file si limitano ad EFS, che è un file system disegnato per la memorizzazione sicura dei dati utente nel computer locale. Non è una soluzione per la condivisione di dati riservati, in quanto non consente l’accesso multiutente ad un file cifrato, né un sistema per la verifica di autenticità ed integrità dei dati in quanto non offre funzioni di firma. Si sente inoltre la mancanza di una funzione di cancellazione sicura; questa esigenza è mitigata dal fatto che la manipolazione di un file cifrato non comporta mai la memorizzazione dello stesso in chiaro, ma non risolve il problema della cifratura di un file esistente, nonché della cancellazione del file di swap. Un’altra mancanza è quella di funzioni di rinnovo automatico dei certificati utente: l’utilità di gestione dei certificati, il Certificate Snap-in, si limita ad elencare i certificati ottenuti dall’utente, il quale deve esaminarne manualmente la data di scadenza ed eventualmente chiederne il rinnovo. Infine, il recupero di un certificato utente da parte di un client esterno al dominio o che non utilizza Windows 2000 è problematico in quanto la pubblicazione dei certificati avviene solo su Active Directory; sarebbe invece molto comodo l’accesso ai certificati attraverso un sito web.

3.3.1.2 Crittografia debole Un grave problema evidenziato dalla versione di Windows 2000 Server utilizzata per le prove (build 2195) è dato dal limite di 56 bit nella lunghezza delle chiavi per la cifratura ad algoritmo simmetrico. Questo limite era imposto dalla legislazione statunitense sull’esportazione di software crittografico, ed avrebbe obbligato alla ricerca di un Cryptographic Service Provider (CSP) alternativo. La versione commercializzata internazionalmente di Windows 2000 non avrà però questa limitazione, in seguito alla rimozione di molti dei limiti di esportazione imposti dalle autorità americane. Microsoft ha annunciato che la versione in commercio, non ancora disponibile al momento della stampa di questa tesi, disporrà nativamente di crittografia a 128 bit, le cui dimensioni sono adeguate per un uso commerciale (vedi paragrafo 1.2.5.11).

3.3.2 Problemi Il funzionamento dell’infrastruttura è stato stabile durante tutto il periodo di prova; l’impressione è quella di un’architettura solida, sebbene soffra dei problemi legati al fatto che si tratta di una prima versione. In particolare, l’installazione guidata di una CA subordinata non ne consente l’utilizzo immediato in quanto non provvede ad impostare i diritti di richiesta di certificazione per gli utenti del dominio di appartenenza (si veda il


- 120 -

paragrafo 3.1.3). Un’altra evidenza della giovinezza della PKI è data dai messaggi di errore, a volte fuorvianti (Figura 19). Problemi veri e propri si sono invece riscontrati nella verifica della revoca dei certificati, o meglio nella mancata verifica. Il Certificates Snap-in non esegue nessuna verifica delle CRL, impedendo all’utente di notare la revoca di un proprio certificato, e l’individuazione di quale sia quello revocato nel caso sia a conoscenza di un provvedimento di questo tipo. Ancora più grave è la procedura di verifica dello stato di validità di un certificato in Outlook Express, che indica come valido un certificato revocato quando la CRL non è raggiungibile. La validazione di un certificato in mancanza della CRL può essere una scelta ragionevole nei casi non critici, ma l’utente dovrebbe essere avvertito di questo potenziale pericolo. E’ stata fatta una prova rendendo irraggiungibile la CA che ha emesso e poi revocato il certificato di firma di Pippo, modificando il DNS o scollegandone la connessione di rete. Esaminando le informazioni sulla sicurezza di un messaggio ricevuto, firmato da Pippo con il certificato revocato, questo è quello che Outlook Express mostra:

Figura 127: informazioni sulla sicurezza del messaggio

In Outlook Express è stata impostata la verifica delle CRL, ed il risultato, “The digital ID has not been revoked” è identico a quello che si ha quando la CA è contattata e si verifica l’ultima versione della CRL.


- 121 -

E’ evidente che, anche qualora si intendesse convalidare un certificato in caso di irreperibilità della CRL, la mancata verifica dovrebbe essere segnalata all’utente. Non c’è modo altrimenti di distinguere tra la correttezza della verifica e l’errore nella ricerca della CRL.

3.3.3 Soluzioni L’integrazione delle mancanze del lato client può essere fatta abbastanza semplicemente utilizzando applicazioni di terze parti o sviluppando soluzioni ad hoc. L’architettura crittografica di Windows 2000 consente infatti l’interfacciamento con i CSP ed anche l’utilizzo di CSP alternativi a quelli forniti. Tutta l’architettura è modulare, consentendo personalizzazioni ed adattamenti ad esigenze specifiche. Ad esempio, per pubblicare tutti i certificati emessi su pagine web sarebbe sufficiente disporre di un plug-in che svolga questa funzione, ed aggiungerlo alla lista degli exit module attivi per la CA (dal Certification Authority Snap-in).

Figura 128: aggiunta di un exit module

Le carenze del Certificates Snap-in sono da imputare alla relativa immaturità del programma, e ritengo che saranno man mano colmate nelle successive revisioni del prodotto. Il problema della verifica delle CRL in Outlook Express ha le caratteristiche di un vero e proprio baco, non si tratta di un problema di design.

Bibliografia

- 122 -

Bibliografia [1] Bill Gates, “The Road Ahead”, revised edition; Penguin Books, USA, 1996.

[2] Bruce Schneier, “Applied Cryptography, Protocols, Algorithms, and Source Code in C”, second edition; John Wiley & Sons, New York, USA, 1996.

[3] D. Atkins, W. Stallings, P. Zimmermann, “PGP Message Exchange Formats”; RFC 1991, agosto 1996.

[4] Decreto del Presidente del Consiglio dei Ministri 8 febbraio 1999, “Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche temporale, dei documenti informatici ai sensi dell’articolo 3, comma 1, del Decreto del Presidente della Repubblica, 10 Novembre 1997, n. 513”; Gazzetta Ufficiale, Serie generale, n° 87, 15 aprile 1999.

[5] Decreto del Presidente della Repubblica 10 novembre 1997, n° 513, “Trasmissione di documenti con strumenti informatici e telematici, a norma dell’articolo 15, comma 2, della legge 15 marzo 1997, n. 59”; Gazzetta Ufficiale n° 60, 13 marzo 1998.

[6] Eric C. Zimits, Christopher Montaño, “Public Key Infrastructure: Unlocking the Internet’s Economic Potential”; iWord, Volume 3 Issue 2, 1998.

[7] Gregory B. White, Eric A. Fisch, Udo W. Pooch, “Computer System and Network Security”; CRC Press, Boca Raton, USA, 1996.

[8] Hans Dobbertin, “Cryptanalysis of MD5 Compress”; German Information Security Agency, Maggio 1996.

[9] IETF PKIX working group, http://www.ietf.org/html.charters/pkix-charter.html.

[10] IETF SPKI working group, http://www.ietf.org/html.charters/spki-charter.html.

[11] Jamie Lewis, “Public Key Infrastructure Architecture”; The Burton Group Network Strategy Overview, 1997.

[12] Key Strength And Key Management, http://www.cs.uwf.edu/~wilde/CEN6990/papers/boone/KEYS.htm.

[13] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol”; RFC 2560, giugno 1999.

[14] N. Rogier, P. Chauvaud, “The compression function of MD2 is not collision free”; Presentato al Selected Areas in Cryptography ‘95, Canada.

[15] Petra Glöckner, “X.509v3 Certificate”; GMD-TKT, 1996.

Bibliografia

- 123 -

[16] R. Housley, W. Ford, W. Polk, D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile”; RFC 2459, gennaio 1999.

[17] RSA Laboratories Bulletin number 4, “On Recent Results for MD2, MD4 and MD5”, 1996.

[18] RSA Laboratories’ “Frequently Asked Questions About Today’s Cryptography”, version 4.0, 1998.

[19] S. Boeyen, T. Howes, P. Richard, “Internet X.509 Public Key Infrastructure LDAPv2 Schema”; RFC 2587, giugno 1999.

[20] S. Boeyen, T. Howes, P. Richard, “Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2”; RFC 2559, aprile 1999.

[21] S. Chokhani, W. Ford “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework”; RFC 2527, marzo 1999.

[22] Ueli Maurer, “Modelling a public-key infrastructure”; Institute for Theoretical Computer Science, ETH Zürich, 1996.

Indici Sommario approfondito

- 124 -

Sommario approfondito

INTRODUZIONE................................................................................................. I

SOMMARIO ...................................................................................................... III

GLOSSARIO........................................................................................................V

1 DEFINIZIONE DEI REQUISITI E DEI CRITERI DI VALUTAZIONE PER LA SCELTA DI UNA SOLUZIONE PKI.................................................1

1.1 CARATTERISTICHE E FUNZIONALITÀ ........................................................2 1.1.1 Servizi per gli utenti .................................................................................. 2

1.1.1.1 Firma ...............................................................................................................2 1.1.1.2 Cifratura ..........................................................................................................2 1.1.1.3 Autenticazione.................................................................................................3 1.1.1.4 Non ripudio .....................................................................................................3 1.1.1.5 Marcatura temporale .......................................................................................3

1.1.2 Applicazioni .............................................................................................. 3 1.1.2.1 Controllo dell’accesso.....................................................................................3 1.1.2.2 Posta elettronica ..............................................................................................3 1.1.2.3 Web .................................................................................................................3 1.1.2.4 Rete privata virtuale su rete pubblica..............................................................3 1.1.2.5 Commercio elettronico....................................................................................3 1.1.2.6 Assimilazione nella società .............................................................................4

1.1.3 Scalabilità ................................................................................................. 4 1.1.4 Interoperabilità......................................................................................... 5 1.1.5 Interazione con le applicazioni................................................................. 5 1.1.6 Gestione dei certificati.............................................................................. 6 1.1.7 Gestione delle chiavi................................................................................. 8 1.1.8 Sicurezza ................................................................................................. 10

1.1.8.1 Virus e cavalli di troia ...................................................................................11 1.1.8.2 Informazioni conservate nei dispositivi di memorizzazione.........................12 1.1.8.3 Intercettazione ambientale ed elettromagnetica ............................................12 1.1.8.4 Analisi del traffico di rete .............................................................................12 1.1.8.5 Social engineering, minacce e corruzione.....................................................12

1.1.9 Altri fattori che vanno considerati.......................................................... 12 1.1.9.1 Facilità di implementazione ..........................................................................12 1.1.9.2 Facilità d’uso.................................................................................................13 1.1.9.3 Problematiche di amministrazione ................................................................13 1.1.9.4 Flessibilità delle politiche d’uso (policies)....................................................13 1.1.9.5 Robustezza ....................................................................................................13 1.1.9.6 Costi ..............................................................................................................13 1.1.9.7 Prestazioni .....................................................................................................13

1.2 DISCUSSIONE DEGLI STANDARD .............................................................14 1.2.1 Infrastrutture a chiave pubblica ............................................................. 14

1.2.1.1 Public Key Infrastructure X.509 (PKIX) ......................................................14 1.2.1.2 Simple Public Key Infrastructure (SPKI)......................................................14


- 125 -

1.2.1.3 Public Key Cryptography System (PKCS) ...................................................14 1.2.1.4 Secure European System for Applications in a distributed Multi-vendor Environment (SESAME)................................................................................................15 1.2.1.5 Pretty Good Privacy (PGP) ...........................................................................15

1.2.2 Gestione delle chiavi............................................................................... 15 1.2.2.1 Simple Key-management for Internet Protocols (SKIP)...............................15 1.2.2.2 Internet Security Association Key Management Protocol and Oakley Key Determination Protocol (ISAKMP/Oakley) ...................................................................15

1.2.3 Posta elettronica ..................................................................................... 15 1.2.3.1 Open PGP......................................................................................................15 1.2.3.2 Privacy Enhanced Mail (PEM) .....................................................................15 1.2.3.3 Secure Multi-purpose Internet Mail Extensions (S/MIME)..........................15

1.2.4 Certificati ................................................................................................ 16 1.2.4.1 X.509.............................................................................................................16 1.2.4.2 Lightweight Directory Access Protocol (LDAP) ..........................................18

1.2.5 Algoritmi e protocolli di cifratura, firma e funzioni di hash .................. 19 1.2.5.1 Digital Signature Standard (DSS) .................................................................19 1.2.5.2 SHA-1 ...........................................................................................................19 1.2.5.3 Digital Signature Algorithm (DSA) ..............................................................19 1.2.5.4 Diffie-Hellman ..............................................................................................19 1.2.5.5 Data Encryption Standard (DES) ..................................................................19 1.2.5.6 International Data Encryption Algorithm (IDEA) ........................................20 1.2.5.7 CAST ............................................................................................................20 1.2.5.8 RSA...............................................................................................................20 1.2.5.9 Algoritmi a curva ellittica .............................................................................20 1.2.5.10 Message Digest (MD2, MD4, MD5) ............................................................20 1.2.5.11 Considerazioni sulla lunghezza delle chiavi .................................................21 1.2.5.12 IP Security protocol (IPSec)..........................................................................21 1.2.5.13 Secure Electronic Transaction (SET)............................................................21 1.2.5.14 Secure Hypertext Transfer Protocol (HTTPS) ..............................................21 1.2.5.15 Secure Sockets Layer (SSL)..........................................................................22 1.2.5.16 Online Certificate Status Protocol (OCSP) ...................................................22

1.3 MODELLO TEORICO DI UNA SOLUZIONE PKI IDEALE .............................23 1.3.1 Caratteristiche di iPKI............................................................................ 23

1.3.1.1 Organizzazione gerarchica ............................................................................23 1.3.1.2 Dispositivi di autenticazione forte.................................................................24 1.3.1.3 Chiavi di cifratura e di firma/autenticazione.................................................25 1.3.1.4 Key recovery .................................................................................................27

1.3.2 iPKI per l’utente ..................................................................................... 27 1.3.2.1 Firma di un documento .................................................................................28 1.3.2.2 Verifica dell’autenticità di un documento.....................................................28 1.3.2.3 Marcatura temporale .....................................................................................28 1.3.2.4 Cifratura e decifratura ...................................................................................28 1.3.2.5 Gestione dei certificati ..................................................................................28

1.3.3 Amministrazione di iPKI......................................................................... 29 1.3.3.1 CA .................................................................................................................29 1.3.3.2 TSA ...............................................................................................................31 1.3.3.3 Directory .......................................................................................................31 1.3.3.4 Smart card .....................................................................................................32


- 126 -

2 STUDIO DELLE SOLUZIONI PKI ESISTENTI ...................................33

2.1 RICERCA ED ANALISI DELLE SOLUZIONI .................................................34 2.1.1 Entegrity Solutions Notary...................................................................... 34 2.1.2 Entrust/PKI 5.0 ....................................................................................... 34 2.1.3 GTE CyberTrust Enterprise CA.............................................................. 35 2.1.4 IBM Vault Registry 2.2.2 ........................................................................ 35 2.1.5 Lotus Domino.......................................................................................... 35 2.1.6 Microsoft Windows 2000 PKI................................................................. 35 2.1.7 Netscape Certificate Management System 4.1........................................ 35 2.1.8 Network Associates NetTools PKI Server e PGP VPN Client................ 36 2.1.9 Network Associates PGP Certificate Server e PGP ............................... 36 2.1.10 RSA Keon 5.0 .......................................................................................... 36 2.1.11 Thawte Enterprise PKI ........................................................................... 36 2.1.12 Verisign OnSite 4.0 ................................................................................. 36 2.1.13 Xcert Sentry 3.7....................................................................................... 36 2.1.14 Xeti JKIX 2.0........................................................................................... 37

2.2 ASPETTI GENERALI .................................................................................38 2.2.1 Documentazione...................................................................................... 38 2.2.2 Adesione agli standard ........................................................................... 38 2.2.3 Sospensione dei certificati ...................................................................... 38 2.2.4 Marcatura temporale.............................................................................. 38 2.2.5 Modalità di lavoro non in linea .............................................................. 38 2.2.6 Utilizzo di chiavi con usi distinti............................................................. 38 2.2.7 Verifica della validità dei certificati ....................................................... 39 2.2.8 Paradigmi di implementazione di PKI alternativi a quello di iPKI ....... 40 2.2.9 Soluzioni parziali .................................................................................... 40 2.2.10 Implementazioni di riferimento............................................................... 40

2.3 SCELTA DI UNA SOLUZIONE ....................................................................42

3 IMPLEMENTAZIONE DI UN CASE STUDY .......................................44

3.1 INSTALLAZIONE E GESTIONE ..................................................................45 3.1.1 CA principale.......................................................................................... 45 3.1.2 CA subordinata ....................................................................................... 50 3.1.3 Impostazione dei parametri di emissione ............................................... 55

3.1.3.1 Assegnazione dei diritti di Enroll agli utenti di informatica.bicocca.local ...57 3.1.3.2 Impostazione dei Policy Settings della CA...................................................59

3.1.4 Gestione dei certificati............................................................................ 61 3.1.4.1 Creazione di un utente...................................................................................61 3.1.4.2 Ottenimento di un certificato tramite Certificate Request Wizard................63 3.1.4.3 Ottenimento di un certificato via Web ..........................................................67 3.1.4.4 Recupero di un certificato utente dall’Active Directory ...............................70 3.1.4.5 Revoca di un certificato ................................................................................72

3.2 APPLICAZIONI.........................................................................................75 3.2.1 Cifratura e firma di e-mail con S/MIME ................................................ 75

3.2.1.1 Scambio di messaggi tra utenti interni al dominio........................................75 3.2.1.2 Scambio di messaggi con utenti esterni ........................................................82


- 127 -

3.2.1.3 Utilizzo di altri sistemi operativi...................................................................86 3.2.1.4 Invalidazione di una firma con certificato revocato......................................93

3.2.2 Comunicazione web sicura con HTTPS.................................................. 95 3.2.2.1 Autenticazione server e cifratura...................................................................99 3.2.2.2 Autenticazione client...................................................................................104 3.2.2.3 Mappatura molti a uno ................................................................................105 3.2.2.4 Mappatura uno a uno...................................................................................110

3.2.3 Cifratura di file con EFS ...................................................................... 112 3.2.4 Autenticazione tramite smart card........................................................ 117

3.3 CONSIDERAZIONI..................................................................................119 3.3.1 Carenze ................................................................................................. 119

3.3.1.1 Client...........................................................................................................119 3.3.1.2 Crittografia debole ......................................................................................119

3.3.2 Problemi................................................................................................ 119 3.3.3 Soluzioni................................................................................................ 121

BIBLIOGRAFIA ..............................................................................................122

SOMMARIO APPROFONDITO ...................................................................124

INDICE DELLE FIGURE...............................................................................128

INDICE ANALITICO......................................................................................131

Indici Indice delle figure

- 128 -

Indice delle figure FIGURA 1: WINDOWS 2000 CONFIGURE YOUR SERVER................................................... 45 FIGURA 2: CONFIGURAZIONE AUTOMATICA DI UN DOMAIN CONTROLLER ....................... 46 FIGURA 3: DEFINIZIONE DEL DOMINIO.............................................................................. 46 FIGURA 4: SCELTA DEI COMPONENTI OPZIONALI .............................................................. 47 FIGURA 5: INSTALLAZIONE DI CERTIFICATE SERVICES .................................................... 47 FIGURA 6: IMPOSTAZIONE DI UNA ENTERPRISE CA PRINCIPALE....................................... 48 FIGURA 7: DATI IDENTIFICATIVI DELLA CA PRINCIPALE .................................................. 49 FIGURA 8: WINDOWS 2000 CONFIGURE YOUR SERVER................................................... 50 FIGURA 9: INSERIMENTO DI "SUBORDINATE" NEL DOMINIO "BICOCCA.LOCAL"................ 50 FIGURA 10: CONFIGURAZIONE DI ACTIVE DIRECTORY..................................................... 51 FIGURA 11: CREAZIONE DI UN NUOVO DOMAIN CONTROLLER ......................................... 51 FIGURA 12: ASSEGNAZIONE DEL NOME AL DOMINIO FIGLIO ............................................. 52 FIGURA 13: RIEPILOGO DEI PARAMETRI IMPOSTATI.......................................................... 52 FIGURA 14: CREAZIONE DI UNA CA SUBORDINATA.......................................................... 53 FIGURA 15: DATI IDENTIFICATIVI DELLA CA ................................................................... 53 FIGURA 16: RICHIESTA DI CERTIFICAZIONE ...................................................................... 54 FIGURA 17: INSERIMENTO DEL CERTIFICATES SNAP-IN NELLA MMC.............................. 55 FIGURA 18: ATTIVAZIONE DEL CERTIFICATE REQUEST WIZARD...................................... 56 FIGURA 19: MANCATO AVVIO DEL CERTIFICATE REQUEST WIZARD ................................ 56 FIGURA 20: VISUALIZZAZIONE DEI SERVIZI PUBBLICATI NELL’AD................................... 57 FIGURA 21: MODIFICA DELLE PROPRIETÀ DEL TEMPLATE USERSIGNATURE..................... 58 FIGURA 22: L’ACL DI USERSIGNATURE ......................................................................... 58 FIGURA 23: MODIFICA DELL’ACL DI USERSIGNATURE ................................................... 59 FIGURA 24: AGGIUNTA DI UN TEMPLATE AI POLICY SETTINGS DELLA CA ....................... 59 FIGURA 25: SCELTA DEL TEMPLATE ................................................................................. 60 FIGURA 26: I POLICY SETTINGS DELLA CA...................................................................... 60 FIGURA 27: CREAZIONE DI UNA ORGANIZATIONAL UNIT ................................................. 61 FIGURA 28: CREAZIONE DI UN UTENTE NELLA OU MLAB ................................................. 62 FIGURA 29: INSERIMENTO DELL’INDIRIZZO E-MAIL NEL PROFILO UTENTE ....................... 63 FIGURA 30: IL CERTIFICATE REQUEST WIZARD ............................................................... 64 FIGURA 31: SCELTA DEL TEMPLATE ................................................................................. 64 FIGURA 32: ASSEGNAZIONE DI UN NOME AL CERTIFICATO ............................................... 65 FIGURA 33: LA RICHIESTA HA AVUTO SUCCESSO.............................................................. 65 FIGURA 34: IL PERSONAL CERTIFICATE STORE DELL’UTENTE PIPPO ............................... 66 FIGURA 35: IL CERTIFICATO OTTENUTO ........................................................................... 66 FIGURA 36: AUTENTICAZIONE UTENTE............................................................................. 67 FIGURA 37: IL SITO WEB DELLA CA DI INFORMATICA.BICOCCA.LOCAL ........................... 68 FIGURA 38: RICHIESTA AVANZATA DI CERTIFICAZIONE.................................................... 68 FIGURA 39: MODULO PER LA RICHIESTA DI UN CERTIFICATO USERSIGNATURE................ 69 FIGURA 40: IL CERTIFICATO È STATO EMESSO .................................................................. 70 FIGURA 41: AVVIO DI FIND PEOPLE ................................................................................. 70 FIGURA 42: L’INTERFACCIA DI FIND PEOPLE ................................................................... 71 FIGURA 43: I CERTIFICATI DELL'UTENTE .......................................................................... 71


- 129 -

FIGURA 44: REVOCA DI UN CERTIFICATO ......................................................................... 72 FIGURA 45: MOTIVO DELLA REVOCA................................................................................ 72 FIGURA 46: PARAMETRI DI PUBBLICAZIONE DELLE CRL.................................................. 73 FIGURA 47: PUBBLICAZIONE IMMEDIATA DI UNA CRL AGGIORNATA .............................. 73 FIGURA 48: CONTENUTO DELLA CRL .............................................................................. 74 FIGURA 49: INDIRIZZI PER IL REPERIMENTO DELLE CRL.................................................. 74 FIGURA 50: GESTIONE DEGLI ACCOUNT IN OUTLOOK EXPRESS........................................ 75 FIGURA 51: SCELTA DEI CERTIFICATI ............................................................................... 76 FIGURA 52: LA FUNZIONE DI RICERCA PERSONE DELLA RUBRICA ..................................... 76 FIGURA 53: RICERCA NELL’ACTIVE DIRECTORY.............................................................. 77 FIGURA 54: I CERTIFICATI ASSOCIATI ALL’UTENTE TROVATO .......................................... 77 FIGURA 55: INVIO DI UN MESSAGGIO................................................................................ 78 FIGURA 56: FIRMA E CIFRATURA DEL MESSAGGIO............................................................ 78 FIGURA 57: RICEZIONE DI UN MESSAGGIO FIRMATO E CIFRATO........................................ 79 FIGURA 58: LETTURA DEL MESSAGGIO............................................................................. 80 FIGURA 59: INFORMAZIONI RELATIVE ALLA SICUREZZA DEL MESSAGGIO ........................ 81 FIGURA 60: IMPOSTAZIONE DEL CONTROLLO CRL .......................................................... 81 FIGURA 61: RICEZIONE DI UN MESSAGGIO CON FIRMA NON FIDATA ................................. 82 FIGURA 62: IL CERTIFICATO NON RICONOSCIUTO ............................................................. 83 FIGURA 63: INDIVIDUAZIONE DELL’INDIRIZZO DEL CERTIFICATO DELLA CA EMITTENTE 83 FIGURA 64: APERTURA DEL CERTIFICATO DELLA CA....................................................... 84 FIGURA 65: IMPOSTAZIONE DEI PARAMETRI DI RICONOSCIMENTO ................................... 84 FIGURA 66: CATENA DI CERTIFICAZIONE DEL CERTIFICATO DI PLUTO.............................. 85 FIGURA 67: MESSAGGIO CON FIRMA RICONOSCIUTA ........................................................ 85 FIGURA 68: ACCESSO AL SITO WEB DELLA CA................................................................. 86 FIGURA 69: PAGINA PER L’OTTENIMENTO DEL CERTIFICATO DELLA CA .......................... 86 FIGURA 70: VERIFICA DELL’AUTENTICITÀ DEL CERTIFICATO ........................................... 87 FIGURA 71: INSTALLAZIONE DEL CERTIFICATO ................................................................ 87 FIGURA 72: RICHIESTA DI UN CERTIFICATO UTENTE ......................................................... 88 FIGURA 73: GENERAZIONE DELLA COPPIA DI CHIAVI........................................................ 88 FIGURA 74: IL CERTIFICATO OTTENUTO ........................................................................... 89 FIGURA 75: AVVIO DEL CERTIFICATE EXPORT WIZARD................................................... 90 FIGURA 76: ESPORTAZIONE DELLA CHIAVE PRIVATA ....................................................... 90 FIGURA 77: L’ARCHIVIO DI CERTIFICATI DI COMMUNICATOR .......................................... 91 FIGURA 78: IMPORTAZIONE DI UN CERTIFICATO............................................................... 91 FIGURA 79: RICEZIONE DI UN MESSAGGIO FIRMATO E CIFRATO........................................ 92 FIGURA 80: FIRMA E CIFRATURA DI UN MESSAGGIO ......................................................... 92 FIGURA 81: IL CERTIFICATO DI FIRMA È STATO REVOCATO .............................................. 93 FIGURA 82: IL CERTIFICATO REVOCATO ........................................................................... 94 FIGURA 83: IL MESSAGGIO RICEVUTO .............................................................................. 94 FIGURA 84: PROPRIETÀ DEL TEMPLATE WEBSERVER....................................................... 95 FIGURA 85: CREAZIONE DI UN SITO WEB .......................................................................... 96 FIGURA 86: IMPOSTAZIONE DELLE PROPRIETÀ DEL SITO .................................................. 96 FIGURA 87: IL PANNELLO DIRECTORY SECURITY............................................................. 97 FIGURA 88: RICHIESTA DI UN WEB SERVER CERTIFICATE................................................ 97 FIGURA 89: IL CERTIFICATO OTTENUTO ........................................................................... 98


- 130 -

FIGURA 90: ASSEGNAZIONE DELLA PORTA SSL ............................................................... 98 FIGURA 91: IMPOSTAZIONE DELLE PROPRIETÀ DI "CIFRATO.HTML" ................................. 99 FIGURA 92: IL PANNELLO FILE SECURITY ...................................................................... 100 FIGURA 93: IMPOSTAZIONE DI SSL ................................................................................ 100 FIGURA 94: TENTATIVO DI ACCESSO ALLA PAGINA TRAMITE HTTP............................... 101 FIGURA 95: AVVISO DI INIZIO COMUNICAZIONE CIFRATA ............................................... 101 FIGURA 96: LA PAGINA CIFRATA .................................................................................... 102 FIGURA 97: ACCESSO ALLE PROPRIETÀ DELLA PAGINA .................................................. 102 FIGURA 98: PROPRIETÀ DELLA PAGINA E DELLA CONNESSIONE ..................................... 103 FIGURA 99: IMPOSTAZIONE DEI CERTIFICATI CLIENT...................................................... 104 FIGURA 100: SCELTA DEL CERTIFICATO DA UTILIZZARE PER L’AUTENTICAZIONE .......... 104 FIGURA 101: LA PAGINA RISERVATA.............................................................................. 105 FIGURA 102: ABILITAZIONE DELLA MAPPAURA DI CERTIFICATI ..................................... 106 FIGURA 103: IL PANNELLO MANY-TO-1......................................................................... 106 FIGURA 104: AGGIUNTA DI UNA REGOLA ....................................................................... 107 FIGURA 105: SCELTA DELL’ACCOUNT SU CUI VERRANNO MAPPATI I CERTIFICATI.......... 107 FIGURA 106: IMPOSTAZIONE DEL CONTROLLO DI ACCESSO ALLA PAGINA ...................... 108 FIGURA 107: SELEZIONE DEI METODI DI AUTENTICAZIONE CONSENTITI ......................... 108 FIGURA 108: ACCESSO ALLA PAGINA ............................................................................. 109 FIGURA 109: IL PANNELLO DI MAPPATURA 1-TO-1......................................................... 110 FIGURA 110: SCELTA DEL CERTIFICATO DA MAPPARE .................................................... 110 FIGURA 111: SCELTA DELL’ACCOUNT SU CUI MAPPARE IL CERTIFICATO ........................ 111 FIGURA 112: ACCESSO ALLA PAGINA ............................................................................. 111 FIGURA 113: ACCESSO ALLE PROPRIETÀ DEL FILE.......................................................... 112 FIGURA 114: IMPOSTAZIONE DEI PARAMETRI DI COMPRESSIONE.................................... 112 FIGURA 115: IL FILE CIFRATO ........................................................................................ 113 FIGURA 116: MODIFICA DEL FILE CIFRATO ..................................................................... 113 FIGURA 117: NEGAZIONE DELL’ACCESSO....................................................................... 114 FIGURA 118: PARAMETRI DI CIFRATURA PER L’ALBERO DELLE DIRECTORY ................... 114 FIGURA 119: CREAZIONE DI UN NUOVO FILE IN UNA DIRECTORY CIFRATA ..................... 114 FIGURA 120: IL FILE È AUTOMATICAMENTE CIFRATO..................................................... 115 FIGURA 121: IL PROGRAMMA EFSINFO ........................................................................... 115 FIGURA 122: L’IMPRONTA DEL CERTIFICATO ................................................................. 116 FIGURA 123: RIMOZIONE DELLA CIFRATURA.................................................................. 116 FIGURA 124: MAPPATURA DI CERTIFICATI SU UN ACCOUNT UTENTE .............................. 117 FIGURA 125: INFORMAZIONI SUI CERTIFICATI MAPPATI ................................................. 117 FIGURA 126: IMPOSTAZIONE DELLE MODALITÀ DI LOGON ............................................. 118 FIGURA 127: INFORMAZIONI SULLA SICUREZZA DEL MESSAGGIO................................... 120 FIGURA 128: AGGIUNTA DI UN EXIT MODULE................................................................. 121

Indici Indice analitico

- 131 -

Indice analitico

A

Access Control List (ACL) ...56; 58; 59; 95; 109; 111; 114

Active Directory (AD) ....35; 43; 45; 46; 48; 51; 52; 57; 70; 71; 74; 76; 77; 119

Autenticazione .. I; VI; 1; 3; 4; 6; 10; 11; 15; 21; 23; 24; 25; 27; 28; 30; 32; 35; 39; 67; 95; 97; 99; 104; 105; 106; 108; 117; 118

C

Catena di certificazione ..18; 24; 29; 39; 83; 85

Certificate Revocation List (CRL) VI; 4; 6; 7; 8; 17; 18; 22; 29; 30; 31; 38; 39; 73; 74; 81; 93; 120; 121; 123

Certificate Store ........................... 66; 70 Certificate Suspension List (CSL) VI; 4;

6; 8; 22; 29; 30; 31; 38 Certification Authority (CA) I; II; V; VI;

2; 4; 6; 7; 8; 10; 11; 14; 15; 16; 17; 18; 23; 25; 26; 27; 28; 29; 30; 31; 32; 34; 35; 36; 38; 39; 40; 42; 43; 44; 45; 47; 48; 49; 50; 53; 54; 55; 56; 59; 60; 61; 65; 68; 70; 72; 74; 82; 83; 84; 85; 86; 87; 88; 93; 94; 97; 107; 109; 119; 120; 121 emittente.................17; 18; 39; 44; 83 principale 6; 7; 11; 23; 29; 30; 44; 45;

48; 49; 54; 55 subordinata. 7; 44; 50; 53; 54; 55; 59;

60; 85; 119 Certification Practice Statement (CPS)

................................................... 7; 30 Certificato I; II; V; VI; 1; 2; 3; 4; 5; 6; 7;

8; 9; 10; 13; 14; 15; 16; 17; 18; 19; 21; 22; 23; 24; 25; 26; 27; 28; 29; 30; 31; 32; 35; 36; 38; 39; 40; 42; 43; 44; 48; 54; 55; 56; 57; 59; 60; 61; 62; 63; 65; 66; 67; 68; 69; 70; 71; 72; 73; 74; 75; 76; 77; 79; 81; 83; 84; 85; 86; 87;

88; 89; 90; 91; 93; 94; 97; 98; 99; 103; 104; 105; 106; 107; 109; 110; 111; 115; 116; 117; 119; 120; 121

Chiave di autenticazione ..........VI; 28; 36; 39 di certificazione.............................. VI di cifratura .... I; VI; 10; 14; 25; 26; 32 di firma...................VI; 10; 25; 27; 30 di marcatura temporale .................. VI privata . V; 1; 2; 3; 7; 8; 9; 10; 11; 14;

17; 19; 24; 25; 26; 27; 28; 30; 31; 32; 42; 66; 69; 72; 78; 79; 90

pubblica I; V; 1; 2; 6; 7; 9; 10; 11; 14; 15; 16; 17; 19; 20; 21; 22; 24; 25; 26; 27; 28; 29; 30; 32; 34; 35; 65; 70; 76; 78; 79; 86; 105

Cifratura ....I; VI; 2; 3; 5; 6; 8; 9; 10; 11; 14; 15; 17; 19; 20; 21; 25; 27; 28; 29; 30; 32; 34; 35; 36; 38; 39; 57; 59; 60; 75; 76; 78; 79; 92; 95; 99; 100; 103; 112; 114; 115; 116; 119

Commercio elettronico..................I; 3; 4 Confidenzialità.........................1; 21; 97

D

Domain Controller (DC) .46; 47; 49; 50; 51; 52; 54; 96

Domain Name System (DNS).....45; 46; 120

E

Encrypting File System (EFS) . 112; 119 Entegrity............................................. 34 Entrust ................... II; 34; 35; 36; 38; 42

F

Firma elettronica I; 4; 19; 24; 60; 63; 64

G

GTE.............................................. 34; 35

H

Hash ...................... VI; 2; 15; 19; 20; 79


- 132 -

HTTPS .......21; 39; 95; 96; 98; 101; 117

I

IBM....................... II; 19; 34; 35; 40; 41 Impronta2; 3; 19; 20; 26; 28; 31; 78; 79;

87; 115; 116 Integrità ..................1; 8; 12; 21; 26; 119 Internet Engineering Task Force (IETF)

................................I; 14; 15; 21; 122 iPKI I; II; 23; 24; 25; 26; 27; 28; 29; 31;

32; 33; 34; 35; 36; 39; 40; 42

K

Key history.......................10; 26; 35; 36

L

LDAP I; 6; 8; 18; 19; 23; 31; 35; 37; 38; 39

Linux............................................ 42; 86 Lotus ...................................... 34; 35; 41

M

Mappatura di certificati...5; 18; 99; 105; 106; 110; 117

Marcatura temporale .......... I; II; 3; 7; 31 Microsoft 15; 34; 35; 38; 39; 43; 55; 67;

115; 119

N

Netscape...............15; 34; 35; 39; 86; 91 Network Associates ............... 34; 36; 42 Non ripudio ...................I; 10; 17; 24; 27

O

Online Certificate Status Protocol II; 22; 37; 40; 42

Outlook Express75; 76; 79; 81; 93; 120; 121

P

Personal Identification Number (PIN)................................................. 24; 25

PGP ......... II; 15; 26; 34; 36; 38; 42; 122 PKIX .....I; II; 14; 19; 23; 34; 36; 37; 38;

40; 122 Posta elettronica (e-mail) ....8; 9; 18; 23;

30; 40; 62; 63; 67; 75; 77; 85

Public Key Cryptography System (PKCS)...................14; 15; 34; 37; 91

Public Key Infrastructure (PKI). I; II; V; 1; 2; 3; 4; 5; 6; 7; 10; 11; 12; 13; 14; 15; 18; 19; 23; 25; 33; 34; 35; 36; 37; 39; 40; 42; 43; 47; 48; 61; 67; 71; 75; 86; 95; 119; 120

R

Recovery data .....................................9; 27; 116 key........... II; 9; 11; 27; 30; 32; 36; 40

Registration Authority ...V; 7; 8; 23; 28; 29; 31; 32; 35; 36

Revoca.....II; V; VI; 7; 8; 29; 30; 36; 38; 40; 42; 72; 73; 74; 81; 93; 94; 120

Riconoscimento...........V; 4; 6; 7; 30; 84 esplicito ........................................... V implicito .......................................... V

RSA....... 14; 15; 20; 21; 34; 36; 39; 123

S

S/MIME ....................................... 15; 75 Secure Socket Layer (SSL) ...21; 22; 35;

98; 100; 101; 103; 104; 105; 106 Single Sign On (SSO) ............18; 35; 36 Smart card .I; 5; 7; 9; 10; 11; 14; 23; 24;

25; 26; 27; 28; 31; 32; 35; 36; 117; 118

Snap-in55; 57; 59; 72; 90; 99; 119; 120; 121

T

Template ....... 56; 57; 58; 59; 60; 64; 95 Thawte.......................................... 34; 36 Time Stamping Authority (TSA) . II; VI;

3; 23; 28; 31; 38; 42 Token card .............................11; 24; 25 Transport Layer Security (TLS). 22; 105

U

Uniform Resource Locator (URL).... 16; 67; 83

V

Verisign........................................ 34; 36


- 133 -

Virtual Private Network (VPN) .... 3; 34; 35; 36; 42

Virus................................................... 11

W

Windows 2000II; 33; 34; 35; 43; 45; 47; 48; 50; 55; 56; 61; 62; 67; 69; 70; 75; 86; 89; 95; 115; 119; 121

Wizard.... 47; 51; 53; 55; 56; 63; 64; 86; 90; 96; 97

X

X.509... I; 14; 15; 16; 18; 21; 23; 24; 36; 37; 38; 39; 122; 123

Xcert............................................. 34; 36 Xeti.................................... II; 34; 37; 40

Studio e implementazione di una architettura PKI in ambito...

Documents

Transcript of Studio e implementazione di una architettura PKI in ambito...