Certificati e certificatori Infrastruttura a chiave pubblica · chiave pubblica di Alberto e gli scrive un messaggio riser-vato cifrandolo con quella chiave, solo Alberto sarà in

PC Open www.pcopen.it98

ITAdministrator - Sicurezza informatica Lezione 6

Come è stato descritto nella sezione 5.2 (Crittografia),la crittografia asimmetrica si è affiancata alla critto-grafia simmetrica, che da sola presentava notevoli

problemi di trasmissione e gestione delle chiavi. La critto-grafia asimmetrica, nata negli ambienti militari negli anni’60 del secolo scorso e separatamente inventata nel mon-do civile durante il decennio successivo, è basata sull’uti-lizzo di una chiave pubblica e di una chiave privata. Le duechiavi sono legate da una relazione matematica che per-mette di decifrare con una chiave ciò che è stato cifrato conl’altra. Tuttavia, la lunghezza delle chiavi e la complessitàdel problema matematico da risolvere impediscono, con imezzi correnti, di ricostruire una chiave partendo dall’altrachiave della coppia. Pertanto una delle due chiavi può es-sere resa disponibile pubblicamente, per esempio memo-rizzata in un database, pubblicata in un elenco o stampatasu un biglietto da visita. Finché la chiave privata rimane se-greta, la conoscenza della chiave pubblica non pone alcunproblema di sicurezza (se si è certi che la chiave pubblicasia autentica).

L’idea che una chiave crittografica potesse essere rive-lata pubblicamente era così radicale e suggestiva che il me-todo di protezione delle informazioni con crittografia asim-metrica divenne noto con il nome di crittografia a chiavepubblica.

L’introduzione della crittografia a chiave pubblica ha re-so disponibile una serie di servizi, parte dei quali eranosconosciuti o irrealizzabili con la cifratura simmetrica. Diquesti, i principali sono:- la comunicazione sicura tra estranei- la cifratura (di dati di breve lunghezza, come chiavi sim-metriche)

- la firma digitale (che garantisce l’autenticità e l’integritàdei dati)

- lo scambio di chiavi (spesso simmetriche).Quando si utilizza una chiave pubblica per verificare una

firma digitale o per cifrare un messaggio, è d’importanzafondamentale conoscere con certezza chi è l’effettivo pro-prietario della chiave. Per esempio, se Anna ha ricevuto lachiave pubblica di Alberto e gli scrive un messaggio riser-vato cifrandolo con quella chiave, solo Alberto sarà in gra-do di decifrarlo con la propria chiave privata. Ma qualcuno,impersonando Alberto o in altri modi, può fare avere ad An-na una falsa chiave pubblica, così da decifrare i messaggiche Anna cifra con tale chiave. Come fa Anna a sapere chela chiave pubblica ricevuta sia autentica?

Un’infrastruttura è un substrato che pervade un vastoambiente (una grande azienda, una rete, una collettività, ec-cetera) e che fornisce servizi ogniqualvolta le entità uten-ti abbiano bisogno di attingervi. Due esempi sono la retedell’energia elettrica e Internet. Analogamente, un’infra-

In questa nuova lezione di Eucip IT Administrator SicurezzaInformatica scoprirete come si crea un certificato, come lo sivalida e come si viene riconosciuti per suo tramite.I contenuti sono composti da tre elementi: un articolo sulla rivista, un articolo, moltopiù esteso in formato PDF e un corso multimedialecompleto su CD e DVD di Giorgio Gobbi

Materiale didatticovalidato da AICACertificazione EUCIPIT AdministratorModulo 5 - IT SecuritySicurezza informatica

"AICA Licenziatariaesclusiva in Italia delprogramma EUCIP(European Certificationof InformaticProfessionals), attestache il materiale didatticovalidato coprepuntualmente eintegralmente gliargomenti previsti nelSyllabus IT Administratore necessari per ilconseguimento dellacertificazione ITAdministrator ITSecurity. Diconseguenza AICAautorizza sul presentemateriale didattico l'usodel marchio EUCIP,registrato da EUCIP Ltde protetto dalle leggivigenti"

Obiettivo del corso IT AdministratorSicurezza InformaticaFornire al lettore familiarità con i vari modi diproteggere i dati sia su un singolo PC sia in una LANconnessa a Internet. In particolare, metterlo nellecondizioni di proteggere i dati aziendali controperdite, attacchi virali e intrusioni. Inoltre, metterlonelle condizioni di conoscere e utilizzare le utility e iprogrammi più comuni destinati a tali scopi.

Riferimento Syllabus2.0 (curriculumufficiale AICA)

5.6.1 PKI

5.6.1.1 Essere alcorrente delleproblematiche didistribuzione dellachiave pubblica,anche riguardol'identificazione delpossessore

I contenuti delle 8 lezioni Lezione 1: Informazioni generaliLezione 2: parte 1 Crittografia -

fondamenti e algoritmiLezione 2: parte 2 Crittografia -

applicazioniLezione 3: Autenticazione

e controllo degli accessiLezione 4: Disponibilità dei datiLezione 5: Codice malignoLezione 6: Infrastruttura a chiave pubblicaLezione 7: Sicurezza della reteLezione 8: Aspetti sociali, etici e legali della

sicurezza informatica

In collaborazionecon:

� Certificati e certificatori

Infrastrutturaa chiave pubblica

Lezione 6 IT Administrator - Sicurezza informatica

struttura di sicurezza dovrebbe essere a disposizione degliutenti (individui, applicazioni, eccetera) che hanno neces-sità di sicurezza e dovrebbe essere facilmente accessibilenell’ambito di un’architettura caratterizzata da interope-rabilità, coerenza e gestibilità attraverso piattaforme ete-rogenee. L’infrastruttura a chiave pubblica può formare labase su cui costruire e gestire un’infrastruttura di sicurez-za e ha come obiettivi fondamentali l’autenticazione, l’in-tegrità e la riservatezza delle informazioni.

L’infrastruttura a chiave pubblica nasce con lo scopo didistribuire e gestire in modo sicuro le chiavi pubbliche pertutto il periodo della loro validità, garantendo la corri-spondenza tra ogni chiave pubblica e il proprietario dellacoppia di chiavi. La garanzia di autenticità delle chiavi pub-bliche (e quindi delle corrispondenti chiavi private) è for-nita dalle Autorità di Certificazione (Certification Authorityo CA) tramite l’emissione di certificati digitali. Un certifi-cato è una struttura di dati che associa l’identità del titola-re alla coppia di chiavi (la chiave pubblica è inclusa nel cer-tificato), certificata tramite una firma digitale prodotta permezzo della chiave privata della CA. In questo modo,chiunque, tramite la chiave pubblica della CA, può verifi-care la validità del certificato e quindi l’autenticità dellachiave pubblica che vi è contenuta. Questi certificati sonodetti certificati digitali o certificati di chiave pubblica (pu-blic key certificate).

Una coppia di chiavi asimmetriche ha tipicamente que-sto ciclo di vita:- l’entità da certificare viene identificata con certezza e re-gistrata presso una CA o presso una RA (RegistrationAuthority), un componente dell’infrastruttura che vienetalvolta utilizzato per sollevare la CA da certe funzioni, au-mentando la scalabilità e riducendo i costi. Se la genera-zione delle chiavi non è contestuale alla registrazione, laRA deve fornire all’entità richiedente un codice di acces-so che consenta di autenticare la connessione all’inviodella richiesta.

- Vengono generate le chiavi. Ciò avviene normalmentepresso l’entità utente, per esempio attraverso le funzionicrittografiche del sistema operativo, invocate da un webbrowser. Tale approccio offre la migliore protezione dellachiave privata. Se le chiavi vengono generate all’internodella PKI (una procedura che si raccomanda di evitare), sidovrebbe ricorrere a procedure di sicurezza particolar-mente rigorose per garantire il non ripudio.

- Viene generata una richiesta di certificato conforme a unodei protocolli di sicurezza che sono stati definiti. Peresempio, il gruppo di lavoro IETF PKIX ha pubblicato lespecifiche Internet X.509 Public Key Infrastructure Certi-ficate Management Protocol (CMP) - RFC 2510, InternetX.509 Certificate Request Message Format (CRMF) - RFC2511 e il successivo CMP2. Alcuni ambienti utilizzano, inalternativa, i Public Key Cryptography Standards (PKCS)7 - RFC 2315 e PKCS 10 - RFC2986. Altri protocolli sono ba-sati sulle strutture PKCS 7/10, come il Certificate Manage-ment Messages over CMS (Cryptographic Message Syn-tax) - RFC 2797 e il Simple Certificate Enrollment Protocoldi Cisco. CMP e CRMF costituiscono il protocollo più com-pleto per la gestione del ciclo di vita dei certificati. SiaCRMF sia PKCS 10 prevedono l’invio di un messaggio fir-mato, in modo che la CA abbia la prova che il mittente del-la richiesta di certificato sia in possesso anche della chia-ve privata.

- La richiesta di certificato è inviata alla CA. E’ una fase de-licata, perciò si deve garantire che avvenga su un canalesicuro, possibilmente autenticato.

- Il certificato viene generato. In questa fase la CA crea lastruttura di dati contenente la chiave pubblica, i dati iden-tificativi del possessore delle chiavi (il richiedente), il pe-riodo di validità e varie altre informazioni, alcune riguar-danti la CA stessa.

- Il certificato è inviato al richiedente ed è pubblicato nella

directory della CA. Ci sono vari modi di disseminare uncertificato, come la distribuzione out-of-band (invio conmezzi non elettronici, inclusa la consegna fisica) e la di-stribuzione con protocolli in-band, per esempio all’inter-no di un messaggio di posta elettronica sicuro (S/MIME).

- Se è necessario porre termine al periodo di validità delcertificato prima della sua data di scadenza, la CA può re-vocare il certificato inserendo un riferimento ad esso nel-la Certificate Revocation List (CRL). La richiesta di revo-ca può provenire dal possessore del certificato, per esem-pio perché è stata compromessa la sicurezza della chiaveprivata o per cambio di mansioni o dimissioni di un di-pendente. L’utente può comunicare la richiesta di revocaalla CA o alla RA online o, in alternativa (per esempio in ca-so di furto di una smart card o di un computer), via te-lefono.

- Prima della scadenza del certificato, di solito è prevista lapossibilità di generare una nuova coppia di chiavi e di ri-chiedere il rinnovo del certificato. (Sebbene si parli co-munemente di rinnovo nei termini citati, in letteratura sidistingue tra rinnovo e aggiornamento: il rinnovo conser-va la coppia di chiavi e l’aggiornamento prevede la gene-razione di nuove chiavi. Anche ammesso che le circo-stanze e la sicurezza delle chiavi giustifichino questo tipodi rinnovo, è una procedura pericolosa se non si prende laprecauzione di assicurare che le firme digitali siano di-stinguibili in corrispondenza di ogni variazione dei datidel certificato).

Ciclo di vita delle chiavi asimmetriche (Fig A-B)


A

B



Certificati digitali e liste dei certificati revocati(CRL)

Il concetto di certificato digitale, ovvero di una struttu-ra di dati firmata contenente una chiave pubblica, fu intro-dotto nel 1978 da uno studente del MIT (Massachusetts In-stitute of Technology). Sono quindi trascorsi quasi tre de-cenni dalla concezione di un metodo sicuro e scalabile pertrasportare le chiavi pubbliche a tutte le parti interessate.Il certificato era lo strumento che permetteva di legare ilnome di un’entità (più altre informazioni) alla corrispon-dente chiave pubblica.

Oggi esistono vari tipi di certificati, tra cui i seguenti:- certificati di chiave pubblica X.509- certificati SPKI (Simple Public Key Certificate)- certificati PGP (Pretty Good Privacy)- certificati SET (Secure Electronic Transaction)- certificati di attributi (attribute certificate).

Ogni tipo di certificato ha un formato diverso, inoltreper alcuni tipi esistono diverse versioni. Per esempio, delformato più diffuso, l’X.509, esistono tre versioni di certifi-cato. La versione 1 è un sottoinsieme della versione 2, chea sua volta è un subset della versione 3. Un certificato X.509versione 3 include numerose estensioni opzionali e puòquindi essere utilizzato in diversi modi secondo le specifi-che applicazioni. Ad esempio, i certificati SET sono certifi-cati X.509 V 3 con estensioni specifiche definite solo per letransazioni SET (pagamenti tramite carta di credito) e in-comprensibili alle applicazioni non SET.

Per i nostri scopi, intendiamo come certificato (sinomi-no di certificato digitale e di certificato di chiave pubblica),un certificato X.509 versione 3, come definito dalla racco-mandazione ITU-T X.509 “Information Technology - OpenSystems Interconnection - The Directory: Public Key andAttribute Certificate Frameworks”, marzo 2000, equivalen-te all’ISO/IEC 9594-8:2001. La versione 3 del 2000 correggee completa la versione 3 del 1997, che a sua volta rimedia-va alle carenze delle versioni 1 e 2.

Sebbene la norma X.509 definisca certi requisiti associa-ti ai campi standard e alle estensioni di un certificato, le esi-genze d’interoperabilità richiedono un ulteriore raffinamen-to delle specifiche in corrispondenza di certi profili d’uso. Atale scopo, il gruppo di lavoro PKIX (Public Key Infrastruc-ture X.509) dell’IETF ha pubblicato la RFC 2559 nel 1999, rim-piazzata dalla RFC 3280 nel 2002. Sebbene la RFC3280 si ri-volga alla comunità Internet, contiene molte raccomanda-zioni valide anche per le applicazioni aziendali.

Il contenuto di un certificato digitale è accessibile in va-ri modi. Per esempio, si può utilizzare un web browser perinterrogare il server LDAP (Lightweight Directory AccessProtocol) della CA e avere accesso ai contenuti dei certifi-cati archiviati nella directory (vedi la sezione Servizi di Di-

rectory, più avanti). Con unbrowser si possono ancheeseguire operazioni sui cer-tificati locali, come visualiz-zare gli attributi di un certi-ficato installato e importareo esportare certificati. Per esempio, attraversouna CA, possiamo usare In-ternet Explorer in Windowsper creare una coppia dichiavi asimmetriche e pro-curarci il relativo certificatodigitale, un servizio che peruso personale associato al-la posta elettronica è dispo-nibile gratuitamente pressowww.thawte.com. Dopoaver installato il certificatoseguendo le istruzioni diThawte, ne possiamo vede-

re gli attributi aprendo, in IE, Strumenti > Opzioni Internet >Contenuto > Certificati (fig.1).

Dopo aver selezionato il certificato da visualizzare, unclic su Visualizza porta alla sezione generale della finestraCertificato (fig.2).

La sezione dettagli mostra gli attributi del certificato(fig.3).

La sezione Percorso di certificazione mostra la gerarchiadelle CA che certificano la validità del certificato.

Le informazioni di base contenute in un certificatoX.509 sono le seguenti.- Version (Numero di versione del certificato): 1 o 3, vistoche la versione 2 non ha avuto applicazione pratica. Laversione 3 è la più diffusa ed è caratterizzata dalla pre-senza di estensioni, che vedremo nella prossima sezione.

- Serial Number (Numero di serie): un numero che identifi-ca il certificato in modo univoco all’interno della CA. OgniCA deve garantire che ogni certificato emesso abbia un

5.6.1.2 Conoscere ilsignificato di:certificato, liste deicertificati revocati(CRL)

1

2

3


numero di serie unico.- Signature (Algoritmo della firma elettronica): indica l’al-goritmo utilizzato per firmare il certificato. Si tratta di unOID (Object Identifier) che identifica l’algoritmo in modounivoco, a cui è associata una sigla mnemonica che indi-ca gli algoritmi di hash e di cifratura utilizzati, per esem-pio md5RSA (come nell’esempio) o sha1RSA.

- Issuer (Rilasciato da): il nome dell’entità che ha rilasciatoil certificato, per esempio una CA. Questo attributo è nelformato Distinguished Name (DN), che indica univoca-mente un oggetto nella struttura della directory. Il DN è ot-tenuto concatenando tutti gli oggetti che lo compongono,che nell’esempio di cui sopra sono C (nazione), O (orga-nizzazione) e CN (common name, il nome della persona).Tale DN rappresenta anche l’entry della directory relativaalla CA dove normalmente si trova il certificato auto-fir-mato della CA e le CRL (un certificato è auto-firmato se èfirmato con la chiave privata corrispondente alla chiavepubblica contenuta nel certificato, come solitamente ac-cade per i certificati di CA).

- Valid from, Valid to (Valido dal e Valido fino al): le date el’ora di inizio e fine della validità del certificato.

- Subject (Soggetto): il nome del soggetto certificato sottoforma di DN; per esempio, in un certificato personale diThawte, è composto da CN = Thawte Freemail Member eda E = <email del soggetto>.

- Public key (Chiave pubblica): nell’esempio una chiaveRSA di 1024 bit.

La chiave pubblica.Come si è accennato, può esser necessario interrompe-

re la validità di un certificato prima della sua scadenza. L’in-terruzione può essere definitiva (revoca del certificato) op-pure temporanea (sospensione del certificato). La revocao la sospensione si attuano inserendo un riferimento al cer-tificato all’interno di una lista di revoca (CRL) fig.4.

Si revoca un certificato quando, a partire da un certomomento, non devono più essere considerate valide le fir-me generate con la chiave privata abbinata alla chiave pub-blica contenuta nel certificato. Ciò può essere determinatoda motivi organizzativi (come il trasferimento del dipen-dente a cui è assegnato il certificato) o di sicurezza (chia-ve privata compromessa, smart card smarrita o rubata, ec-cetera).

Si sospende un certificato quando sono necessarie ul-teriori indagini per decidere se revocarlo o riattivarlo. Du-rante il periodo di sospensione, il certificato è come revo-cato. Se il certificato viene riattivato, il suo riferimento vie-ne tolto dalla CRL, come se non fosse stato mai sospeso. Seviene revocato, la data di revoca coincide con quella di so-spensione.

Per determinare se un messaggio firmato è da conside-rare valido, occorre accertare se, al momento della firma,il certificato risultava revocato o sospeso (cioè incluso nel-la CRL). Perciò è necessario conoscere con certezza il mo-mento della firma, oltre a quello di revoca o sospensioneeventualmente contenuto nella CRL.

Un modo standard per associare a un dato una coordi-nata temporale, dimostrando la sua esistenza a una certadata e ora, è l’uso di un servizio di marcatura temporale for-nito da una Time Stamping Authority (TSA), come descrit-to nella RFC 3161. Una marca temporale (timestamp) è undato strutturato, firmato dalla TSA, che contiene l’hash deldocumento associato, un numero seriale di identificazionee data e ora.

La TSA ha una propria coppia di chiavi per la firma dellemarche temporali. Il certificato TSA contiene la chiave pub-blica e viene emesso, nel caso di firma qualificata secondola normativa italiana, da una CA diversa da quella dei tito-lari. In tal modo, in caso di compromissione della chiave diCA, è possibile verificare correttamente la validità delle fir-me apposte dagli utenti prima della compromissione.

Anche la lista di revoca dei certificati (CRL, CertificateRevocation List) è una struttura firmata (poiché occorre ga-rantire l’attendibilità delle informazioni che vi sono conte-nute) ed è composta di due parti: una generale con infor-mazioni sulla CRL stessa e la lista dei certificati revocatidall’ente emettitore. Per ogni certificato revocato, viene in-dicato come minimo il suo numero di serie e la data e oradi revoca.

La parte generale ha il seguente formato.- Version (Numero di versione): 1 o 2. La versione 2 è la piùdiffusa ed è caratterizzata dalla presenza di estensioni op-zionali.

- Issuer (Rilasciato da): il nome della CA che ha emesso laCRL.

- Effective Date (Data di validità): la data e ora di emissionedella CRL.

- Next Update (Aggiornamento successivo): la data e ora in


4

5

6

Un esempio di partegenerale di una CRL inversione 1

Un esempio di elenco deicertificati revocati


cui è prevista una nuova emissione della CRL.- Signature (Algoritmo della firma elettronica): come nelcorrispondente campo del certificato

5.6.1.3 Certificati X.509 v3La versione 3 della norma X.509 ha introdotto un campo

di estensioni opzionali sia nel certificato sia nelle CRL. Ogniestensione è costituita da un identificatore unico (OID) cheidentifica l’estensione, da un flag di criticità (vero se l’e-stensione è critica, oppure falso) e dal valore dell’esten-sione. In tal modo si possono aggiungere nuove informa-zioni al certificato senza doverne ridefinire la sintassi di ba-se. La norma X.509 prevede un certo numero di estensionistandard, ma è possibile (sebbene sconsigliato) aggiunge-re estensioni proprietarie a un certificato o a una CRL. Lacriticità di un’estensione è un’informazione utilizzata dal-l’applicazione che analizza il certificato o la CRL. Se l’ap-plicazione non riconosce un’estensione marcata come cri-tica, dovrà scartare il certificato (o la CRL) considerando-lo non valido.

Le estensioni più importanti per i certificati sono le se-guenti.- Authority Key Identifier e Subject Key Identifier: identifi-catori della chiave della CA che ha emesso il certificato edella chiave certificata; normalmente si calcolano comehash (impronta) SHA-1 della corrispondente chiave. Que-sta estensione è usata per verificare la firma digitale cal-colata sul certificato (e quindi la validità del certificato)quando la CA utilizza più chiavi di firma; in tal casol’Authority Key Identifier del certificato dell’entità e ilSubject Key Identifier del certificato di CA devono corri-spondere. La RFC3280 prescrive l’uso dell’Authority KeyIdentifier per tutti i certificati tranne quelli auto-firmati eprescrive l’uso del Subject Key Identifier per i certificatidelle CA, raccomandandolo anche per i certificati delleentità (utenti) finali.

- Basic Constraints: indica se si tratta di un certificato di CAo di entità finale. Tipicamente, è assente nei certificati dientità finale; se presente, deve valere falso.

- Key Usage: indica quali sono gli usi permessi per la chia-ve pubblica del certificato. Può essere usato per indicareil supporto per firme digitali, non ripudio, cifratura dellechiavi, accordo su chiavi, firma di certificati, firma di CRL,solo cifratura, solo decifratura.

- Subject Alternative Name e Issuer Alternative Name: sononomi aggiuntivi che caratterizzano l’entità certificata e laCA; ad esempio, nei certificati personali di Thawte, Nomealternativo oggetto contiene l’email del titolare.

- CRL Distribution Point: è un puntatore alla CRL relativa aquel particolare certificato.

- Certificate Policies: è una sequenza di uno o più OID(Object Identifier che identifica un attributo) che identifi-cano i documenti di policy della CA, ovvero gli impegniche la CA assume nei riguardi dei propri clienti in relazio-ne al tipo di servizio offerto. Se l’estensione è marcata co-me critica, l’applicazione deve aderire ad almeno una del-le policy indicate, altrimenti il certificato non deve essereutilizzato. Oltre agli OID, sono previsti dei qualificatori op-zionali. Sebbene la RFC3280 sconsigli i qualificatori dellepolicy ai fini dell’interoperabilità, ne definisce due in par-ticolare: il Certificate Practice Statement (CPS) e lo UserNotice. Il qualificatore CPS è un indirizzo URI (Uniform Re-source Identifier) dell’ubicazione dove si può trovare il do-cumento CPS applicabile al certificato in questione. Il qua-lifier User Notice può comprendere un riferimento a infor-mazioni reperibili altrove, una nota esplicta (max 200 ca-ratteri) o entrambi.

- Extended Key Usage: indica degli utilizzi particolari dellachiave non elencati nell’estensione Key Usage di cui so-pra. Ad esempio, può indicare la firma di marche tempo-rali o l’autenticazione TSL (Transport Layer Security). LaRFC3280 identifica diversi OID associati con questa esten-

sione, ma probabilmente la lista verrà estesa nel tempo.Questa estensione è usata tipicamente nei certificati del-le entità finali.

La versione del 2000 della norma X.509 ha introdotto nu-merose estensioni opzionali, che possono essere relative atutta la CRL o a singoli certificati revocati. Le estensioni piùutilizzate sono le seguenti.- CRL Number: il numero progressivo di CRL emesse.- Authority Key Identifier, come per i certificati.

A livello di singolo certificato, è importante l’estensioneCRL Reason Code, che fornisce il motivo per cui il certifi-cato è stato revocato. Tra i valori, ci sono Key Compromi-se (è stata violata l’integrità della chiave privata corri-spondente a quel certificato), cambio di affiliazione, rim-piazzato, cessata operatività, sospensione, privilegi ritira-ti e altri.

La PKI e i suoi componenti principali:Certification Authority e Registration Authority

La Certification Authority è l’unica entità essenziale inuna PKI X.509, del cui funzionamento assume totale re-sponsabilità. La CA ha la responsabilità di emettere, gesti-re e revocare i certificati e garantisce quindi, nei confrontidei terzi, il legame tra una chiave pubblica e i dati identifi-cativi dell’entità che possiede quella chiave pubblica e lacorrispondente chiave segreta.

Per realizzare il suo compito di emettere certificati, la CAriceve una richiesta di certificato dall’entità finale (l’uten-te), autentica la sua identità e convalida il contenuto dellarichiesta di certificazione. Quindi la CA genera il contenu-to del nuovo certificato e lo firma digitalmente. Se la CA èconfigurata in modo da usare un certificate repository (undatabase che contiene tutti i certificati emessi), vi archiviail nuovo certificato. Quindi la CA consegna il certificato al-l’entità richiedente: per esempio, può inviarlo via email ocomunicare l’URL dell’ubicazione dove il richiedente potràprelevarlo. Quando un certificato deve essere revocato, laCA crea e gestisce le informazioni di revoca per il certifi-cato. La richiesta può essere originata dall’entità utente odalla CA. La CA è responsabile di autenticare la richiesta direvoca. All’atto della revoca, la CA può rimuovere il certifi-cato dal repository o può limitarsi a marcare il certificatocome revocato. La CA include il numero di serie del certi-ficato nella CRL e, solitamente, informa l’utente dell’avve-nuta revoca.

Chi utilizza un certificato, tipicamente per verificare unafirma digitale, deve sapere quale grado di fiducia può ave-re nell’affidabilità del certificato. Questo dipende da varifattori, come le regole e le procedure seguite dalla CA peraccertare l’identità del soggetto, le politiche e le procedu-re operative, gli obblighi dei soggetti per proteggere le pro-prie chiavi segrete (per esempio potrebbero essere tenutia utilizzare dispositivi di firma sicuri e certificati), l’effica-cia con cui la CA protegge la sua chiave privata e via di-cendo.

Un elemento di particolare importanza è il metodo usa-to dalla CA per distribuire la propria chiave pubblica, nor-malmente inserita in un certificato auto-firmato. Da tale cer-tificato dipende la possibilità di verificare la validità di tut-ti i certificati e delle CRL. Occorre quindi che venga utiliz-zato un metodo di distribuzione sicuro e che consenta al-l’utente di verificare se sta utilizzando il certificato di CAcorretto. Per esempio, si può generare un hash del certifi-cato e metterlo a disposizione degli utenti con modalità ta-li da rendere difficili le contraffazioni (a mezzo stampa, susiti web ecc.). La pratica oggi diffusa è quella di includerei certificati delle CA direttamente all’interno dei browser,delegando ai distributori del software l’onere della verificae della distribuzione sicura. Gli utenti restano così all’o-scuro dell’importanza di queste verifiche.

In Italia, per la firma qualificata, a garanzia dell’autenti-cità dei certificati di CA, è previsto che venga tenuto dal


5.6.1.3 Conoscere icertificati X.509.V3

5.6.1.4 Conoscere ilsignificatodell'acronimo PKI e lerelative componentifondamentali:CertificationAuthority, RegistrationAuthority, etc.


CNIPA (Centro Nazionale per l’Informatica nella PubblicaAmministrazione) un elenco dei certificati e che questo siafirmato con una particolare chiave, il cui hash è stato pub-blicato nella Gazzetta Ufficiale.

Le informazioni necessarie per garantire il grado di fi-ducia richiesto vengono normalmente raccolte in due do-cumenti: Certificate Policy (CP), che raccoglie l’insieme diregole seguite dalla CA per garantire la sicurezza e Certifi-cate Policy Statement (CPS), che documenta le procedureoperative che implementano la CP. Questi due documentisono scritti in conformità alle indicazioni fornite dallaRFC2527 (Internet X.509 Public Key Infrastructure: Certifi-cate Policy and Certification Practices Framework, marzo1999).

L’estensione Certificate Policies, che può essere inseri-ta nei certificati, deve contenere uno o più OID che identi-fichino i documenti di policy della CA e possono contene-re l’URL della loro ubicazione.

Una CA potrebbe non essere in grado di identificare cor-rettamente tutti i soggetti che deve certificare, per esempionel caso in cui la procedura di registrazione richieda un ri-conoscimento de visu dei soggetti e che questi siano di-stribuiti su una vasta area geografica. In questi casi si puòdelegare a una Registration Authority (RA) il compito diidentificare i soggetti. Con la crescita dell’infrastruttura, sipuò avere una struttura a più livelli, in cui un numero limi-tato di RA coordina il lavoro delle RA locali (LRA). I docu-menti di policy dovranno includere le procedure di regi-strazione adottate.

Una RA è un’entità opzionale concepita per distribuire inmodo efficiente il carico di lavoro di una CA, ma non eseguenessun servizio che non possa essere fornito dalla sua CA.I servizi della RA sono di autenticazione e validazione del-le richieste provenienti dalle entità utenti. La RA, in qualitàdi front-end per conto della CA, è tenuta a mettere in attole policy della CA, quindi una RA dovrebbe essere dedica-ta a una sola CA, mentre una CA può essere assistita da piùRA. Dato che la generazione delle firme digitali è un’attivitàcomputazionalmente intensa, la presenza delle RA per-mette alla CA di occuparsi prevalentemente delle attivitàcrittografiche, oltre a interagire con il repository dei certi-ficati e a firmare i certificati e le CRL.

Il repository è il database dove la CA pubblica i certifi-cati che genera, che può essere utilizzato come fonte cen-trale dei certificati e delle chiavi pubbliche dagli utenti del-la PKI. Esso può inoltre essere usato come ubicazione cen-trale delle CRL.

I repository possono essere implementati attraversotecnologie software, ma le directory X.500 raccolgono am-pia accettazione. Una directory X.500 è la scelta naturaleper conservare i certificati, perché i titolari dei certificatisono spesso identificati dai distinguished names (DN) del-l’X.500. La modalità standard per accedere ai certificati e al-le CRL archiviate in una directory X.500 è attraverso il pro-

tocollo LDAP (Lightweight Directory Access Protocol).Un’applicazione che offre un’interfaccia LDAP è detta ser-ver LDAP; un utente può inviare una richiesta LDAP a unserver LDAP e leggere i dati di un certificato o di una CRL.Per la ricerca di un certificato, la query deve specificare ilDN parziale o completo dell’entità finale che possiede ilcertificato; per la ricerca del certificato di una CA o di unaCRL, la query deve specificare il DN della CA.

Utilizzo di un browser per generare chiavi e inviare una richiesta di certificato alla CA

Utilizzando un web browser, è possibile generare unacoppia di chiavi asimmetriche (RSA), inviare una richiestadi certificato a una CA, installare il certificato ed esportar-lo ad altre applicazioni (come un programma di posta elet-tronica). Un certificato può servire ad attivare una con-nessione mutuamente autenticata con un server protettoda SSL/TSL che supporti tale servizio.

I certificati personali per email, come quelli che Thawterilascia gratuitamente, ci forniscono un esempio della pro-cedura con cui Internet Explorer, in Windows, crea le chia-vi attraverso la CryptoAPI, l’interfaccia con le funzioni crit-tografiche di Windows.

Nel sito di Thawte.com, alla pagina Personal E-Mail Cer-tificates, si avvia la procedura di registrazione cliccando suJoin. L’utente fornisce una serie di informazioni personalie attende un messaggio email con le istruzioni successive.Queste richiedono di aprire una certa pagina web e di in-serire due dati (probe e ping) che servono a Thawte per ve-rificare che il richiedente sia in effetti il titolare dell’accountdi email (che sarà l’elemento identificativo del certificato).Segue la richiesta del certificato X.509 con la scelta delsoftware che lo utilizzerà, tra cui Netscape Communicator,Internet Explorer (con Outlook o Outlook Express) e Ope-ra. Al momento della generazione delle chiavi e della ri-chiesta del certificato, un messaggio di Windows mette inguardia sull’operazione in corso e richiede conferma perproseguire.

Viene creata la coppia di chiavi.


Schema generale di unaPKI con le sue entitàprincipali

7

5.6.1.5 Essere ingrado d'utilizzare unbrowser per generarele chiavi e larichiesta dicertificazione a una CA

8

9

10


Il dialogo col sito di Thawte continua fino alla confermadella richiesta di certificato e all’accesso alla pagina di ge-stione dei certificati (Certificate Manager Page). Qui sonoelencati il o i certificati rilasciati all’utente (per ogni indi-rizzo email utilizzato, occorre un distinto certificato) e il lo-ro stato. Un messaggio di posta avvisa che il certificato èstato rilasciato e fornisce un link per scaricarlo; aprendo lapagina web, un ulteriore clic permette di installare il certi-ficato in Internet Explorer (nel caso di Netscape, l’installa-zione è automatica). Un messaggio del sistema operativoavvisa che si sta aggiungendo un certificato e attende con-ferma per proseguire.

Il certificato viene installato.

Lo si trova elen-cato aprendo,in IE, Strumenti> Opzioni Inter-net > Contenu-to > Certificati.

Da qui, il certificato può essere esportato con o senzachiave privata, secondo l’utilizzo, ed essere importato nelprogramma di email, per esempio per firmare i messaggiinviati. L’esportazione e importazione della chiave privatavengono protette da una password scelta dall’utente.

Importare ed esportare certificati in un browserUn browser può importare certificati in diversi formati,

come X.509 (.cer o .crt), PKCS #7 (.spc o .p7b), PKCS #12(.pfx o .p12) e vari altri. I formati PKCS (Public Key Cryp-tography Standards) sono stati introdotti da RSA nel 1991per supportare l’implementazione e l’interoperabilità del-le tecnologie della PKI. Il PKCS #7 (CMS, CryptographicMessage Syntax Standard) specifica i formati per codifica-re messaggi creati con metodi di crittografia asimmetricaed è stato creato per compatibilità con gli standard PEM(Privacy Enhancement for Internet Electronic Mail) del-l’IETF. PKCS #7 è stato adottato dall’IETF nella RFC 2315 eaggiornato con la RFC 2630.

Il PKCS #12 (Personal Information Exchange Syntax, oPFX) è stato introdotto per consentire alle applicazioni dicondividere credenziali crittografiche personali, visto chemolte applicazioni hanno adottato formati proprietari per

archiviare localmente le chiavi private e i certificati X.509.Il formato PFX permette l’esportazione di un certificato daun’applicazione (come browser e programmi di email) a unfile binario (o a una smart card). Questo file può essere im-portato in un’altra applicazione sullo stesso o su un altrocomputer.

Un esempio in Internet ExplorerConsideriamo un esempio di export in Windows, trami-

te IE, di un certificato installato da una CA, come nel casovisto in precedenza. Nella sezione Certificati di IE, si sele-ziona il certificato da esportare (fig. 14).

Cliccando su Esporta inizia la procedura guidata diesportazione. Viene richiesto se il file esportato deve con-tenere anche la chiave privata (per esempio per spostarlaoff-line o su un altro computer) (fig. 15).

Ora si decide il formato di esportazione, che per defaultè PKCS #12 (fig. 16).

Per proteggere la sicurezza del file, si definisce una pas-sword, che verrà richiesta all’atto dell’importazione. Comeal solito, la password dovrebbe essere abbastanza lunga eusare lettere e cifre (fig. 17).

Si stabilisce la directory e il nome del file da esportare(fig. 18).

Il sistema operativo chiede conferma dell’esportazionedella chiave privata e genera il file di export (fig. 19).

L’importazione di un certificato in IE inizia anch’essadalla sezione Certificati. Cliccando su Importa, si selezionail certificato in uno dei formati ammessi (fig. 20).

Si specifica la password che protegge la chiave privata,che in questo caso era stata inclusa nel file esportato (fig.21).

Il file di export può essere salvato nell’archivio di defaulto in un altro archivio (fig. 22).

Il certificato è stato importato e aggiunto all’archiviopersonale dei certificati (fig. 23).


5.6.1.6 Essere ingradod'importare/esportare un certificato in unbrowser

11

12

13

14

15

16


Un esempio di importazione in Konqueror (SuSELinux)

Si inizia dalla sezione Crittografia del configuratore diKonqueror (fig. 24).

Si clicca su Importa e si seleziona un file di export loca-le (se il file è in rete, va copiato o spostato localmente) (fig.25).

Si introduce la password che protegge la chiave privata(se esportata) (fig. 26).

Il certificato risulta ora importato (fig. 27).


17

18

19

20

21

22

23

24

25

26


Un esempio di importazione in Mozilla FirefoxDalle opzioni avanzate di Firefox si entra nella Gestione

Certificati (fig. 28).Si clicca su Importa (fig. 29).Si seleziona il file da importare (fig. 30).

Si introduce lapassword (se il fi-le include la chia-ve privata) (fig.31).Un messaggioconferma il buonesito dell’impor-tazione (fig. 32)..Il certificato èstato inserito nel-l’archivio dei cer-tificati personali(fig. 33). Se ne possono visualizzare le informazioni gene-rali e i dettagli (fig. 34).

Un esempio d’importazione in OutlookNelle opzioni di sicurezza di Outlook si clicca su Im-

port/Export (fig. 35).


27

28

29

30

31

32

33

34

35


Si seleziona il certificato esportato in precedenza da In-ternet Explorer, specificando la password di export e l’i-dentificatore del certificato, che per il certificato persona-le di Thawte è l’indirizzo email associato al certificato (fig.36).

Ora si può chiedere ad Outlook di aggiungere una firmadigitale a tutti i messaggi in uscita (in alternativa, si può se-lezionare di volta in volta quali messaggi firmare) (fig. 37).

Accesso alla CRL dal browser e utilizzo di OCSP (Online Certificate Status Protocol)

Un certificato include al suo interno il periodo di validità(data e ora d’inizio e di scadenza). Se si deve porre termi-ne anticipatamente alla validità di un certificato, questo de-ve essere revocato e il suo numero di serie deve essere in-cluso nella CRL della CA che ha emesso il certificato. I mo-tivi che determinano la revoca di un certificato sono di va-ria natura, per esempio il trasferimento del titolare ad altramansione o altra azienda o il venir meno della sicurezzadella chiave privata.

Le CRL sono normalmente emesse ogni 12/24 ore, perciòla revoca diventa effettiva entro un giorno. Mentre questaperiodicità può essere adeguata di routine, ci sono situa-zioni che richiedono maggiore tempestività nel bloccare un

certificato, come la sottrazione della chiave privata al pro-prietario o l’uso fraudolento del certificato.

L’emissione immediata della CRL dopo una revoca nonrisolverebbe il problema perché, per ragioni di efficienza, isoftware di verifica mantengono una cache delle CRL e nonscaricano le nuove CRL finché quelle correnti non sianoscadute. D’altra parte, le PKI con un numero elevato diutenti tendono ad avere CRL voluminose, il cui scarica-mento genera un ingente volume di traffico in rete, spe-cialmente intorno ai tempi di scadenza. In definitiva, le CRLcostituiscono una lacuna nella sicurezza delle PKI.

OCSP (Online Certificate Status Protocol) è un proto-collo che cerca di risolvere questi problemi attraverso unsistema aggiuntivo (responder) che mantiene al proprio in-terno lo stato di tutti gli utenti e che viene interrogato dal-le applicazioni che devono verificare la validità di un certi-ficato. La versione 1 di OCSP, documentata nella RFC 2560(X.509 Internet Public Key Infrastructure Online CertificateStatus Protocol-OCSP) è un protocollo relativamente sem-plice di domanda-risposta, che offre uno strumento per ot-tenere online informazioni aggiornate sulla revoca dei cer-tificati, fornite da un’entità fidata (il responder OCSP). Unarichiesta OCSP include il numero di versione del protocol-lo, il tipo di richiesta di servizio e uno o più identificatori dicertificati. Questi ultimi consistono dell’hash del DN (di-stinguished name, nella terminologia LDAP) dell’emittente,dell’hash della chiave pubblica dell’emittente e del nume-ro di serie del certificato. Possono essere presenti esten-sioni opzionali. Le risposte contengono l’identificatore delcertificato, lo stato del certificato (valido, revocato o sco-nosciuto) e l’intervallo di validità della risposta associataa ogni certificato specificato nella richiesta. Se un certifi-cato è revocato, viene indicato il momento della revoca; op-zionalmente, può essere incluso il motivo della revoca. Lerisposte del responder OCSP devono essere firmate per as-sicurare l’autenticità della loro origine. Come nel caso del-le CRL, anche OCSP utilizza l’estensione Authority Infor-mation Access dei certificati (come da RFC 3280) per aiu-tare le parti interessate a trovare il responder appropriato.

OCSP si limita a fornire lo stato di revoca di un certifi-cato, senza alcuna presunzione sulla sua validità. OCSP nonverifica il periodo di validità e non esegue controlli sui da-ti del certificato (come Key Usage, Extended Key Usage oPolicy Qualifier) che potrebbero indicare un uso scorrettodel certificato. Tutte le verifiche di validità restano a cari-co dell’applicazione. Inoltre, il tempo di latenza tra la ri-chiesta e la risposta (da mantenere al minimo) non è ga-rantito. OCSP è solo un protocollo; sebbene possa essereimplementato con risposte in tempo reale, non specifica lastruttura di back-end da cui il responder attinge le infor-mazioni, che comprende le CRL e altri database da cui pre-levare le informazioni. OCSP non elimina la necessità delleCRL e fornisce risposte aggiornate compatibilmente con lalatenza dei meccanismi di accesso alle sue fonti di infor-mazioni. Sebbene il responder possa essere strettamenteaccoppiato alla CA per offrire una latenza pressoché nulla,questo non può essere assunto implicitamente, tanto piùche la firma digitale delle risposte può determinare un im-patto significativo sulle prestazioni.

Tra le possibili evoluzioni di OCSP V.1 ci sono SVP (Sim-ple Validation Protocol), sviluppato dal gruppo di lavoroPKIX dell’IETF con l’intento di scaricare su una terza partefidata il processo di verifica della validità dei certificati, e laversione 2 di OCSP, in fase di sviluppo.

Un esempio del funzionamento di OCSPIn questo esempio (fig. 37), l’applicazione desktop (per

es. un browser) si connette a un server web via SSL, utiliz-zando l’autenticazione tramite certificato sia del client siadel server. Il browser chiede al server una connessione SSL.Il server risponde inviando il proprio certificato. Il browsercompie una verifica di validità del certificato ed esegue una


36

36

5.6.1.7 Essere ingrado d'accederealle liste CRL dalbrowser, e sapereeffettuare controllisulla validità deicertificati tramiteOCSP (OnlineCertificate StatusProtocol).)


chiamata di sistema per verificare lo stato di revoca del cer-tificato. Il plugin OCSP client installato nel desktop inter-cetta la chiamata e invia una richiesta al responder OCSP.Il responder verifica lo stato del certificato del server (pres-so la CA emettitrice) e risponde con un messaggio firmatoal client, che in base alla risposta (buono, revocato o sco-nosciuto) decide se fidarsi del server web. Se si fida, pro-cede con la connessione SSL. Il server chiede al client il suocertificato e, dopo averlo ricevuto, esegue la sua valida-zione tramite l’opportuno responder OCSP. Il responder in-terroga la CA che ha emesso il certificato del client e inviaal server lo stato del certificato, mettendo in grado il serverdi decidere se fidarsi del certificato del client.

Per accedere alle CRL, si possono usare i browser di ul-tima generazione (come Mozilla Firefox), che utilizzano leindicazioni contenute nell’estensione CRL DistributionPoint del certificato. Se sono specificati più valori, il softwa-re tenta di accedere alla prima CRL, passando se necessa-rio a quelle successive finché non trova un formato e unaCRL utilizabili.

Per configurare Mozilla Firefox per l’utilizzo di OCSP, ba-sta aprire Strumenti > Opzioni > Avanzate e, nella sezioneVerifica, attivare una delle opzioni per l’uso di OCSP (fig.38).

Importare la CRL nel browser Nel caso in cui la CRL non fosse accessibile automatica-

mente dal browser o i certificati non contenessero un’e-stensione CRL Distribution Point, si può utilizzare il browserper scaricare la CRL manualmente sulla base del suo URL.

Per esempio, aprendo in Internet Explorer l’URL delleCRL di Thawte (http://crl.thawte.com), vengono elencate leCRL disponibili (fig. 39).

Selezionandone una, IE risponde offrendo di aprire o sal-

vare in un file la CRL. Scegliendo Apri, compare la finestraElenco certificati revocati, sezione generale.

Selezionando la sezione Elenco revoche, vengono elen-cati i numeri di serie e le date di revoca (fig. 41).


38

5.6.1.8 Essere ingrado d'importare unalista CRL nel browser,e sapere effettuarecontrolli sulla validitàdei certificati tramiteOCSP (OnlineCertificate StatusProtocol)

37 38

40

41


Mozilla Firefox permette di importare le CRL e di ag-giornare automaticamente le CRL relative ai certificati in-stallati. Se da Firefox si apre crl.thawte.com e si selezionauna delle CRL elencate, appare il messaggio di confermadell’importazione della CRL e accesso alle opzioni di ag-giornamento (fig. 42).

Rispondendo Sì, si apre la seguente finestra (fig. 43).Nelle preferenze di aggiornamento della CRL si può im-

postare l’aggiornamento automatico e altre personalizza-zioni.

BIBLIOGRAFIAPer l’argomento PKI e firme digitali segnaliamo l’eccellen-

te “Understanding PKI”, Second Edition, di C. Adams e S.Lloyd, Addison Wesley, 2003, e “Digital Signatures” di Atreya,Hammond, Paine, Starret e Wu, RSA Press - McGraw-Hill, 2002.

Servizi di directoryNegli ambienti connessi in rete, è fondamentale che le

informazioni importanti (come quelle legate alla sicurezza)siano archiviate in modo strutturato e siano reperibili ra-pidamente. Questa esigenza ha trovato una risposta neiservizi di directory. che, a somiglianza di un elenco telefo-nico, contengono le informazioni in forma strutturata e so-no di facile consultazione. In questo contesto, directory in-dica un elenco di dati strutturati secondo uno schema ge-rarchico, senza nessuna relazione con le cartelle di un filesystem, anch’esse chiamate directory.

Idealmente, possiamo immaginare che un servizio di di-rectory consista di un server centrale che contiene i dati inuna determinata directory e li distribuisce ai client attra-verso opportuni protocolli. I dati dovrebbero essere strut-turati in modo che siano facilmente accessibili da una va-sta gamma di applicazioni. In questo modo le applicazioninon hanno bisogno di conservare una propria banca datima possono accedere a un database centrale sicuro e ag-giornato, con notevole riduzione del carico amministrativo.

Un directory service organizza i contenuti e viene ese-guito su un server; la directory è invece il database conte-nente le informazioni che sono gestite dal servizio di di-rectory. Il servizio di directory è l’interfaccia con la direc-tory e fornisce accesso ai dati della directory.

Una directory è un tipo particolare di database, diversodai tradizionali database (per esempio relazionali, ma nonsolo) utilizzati dalle applicazioni gestionali. Una directoryè oggetto di un gran numero di accessi in lettura contem-poranei, mentre l’accesso in scrittura è limitato ai pochi ag-giornamenti amministrativi. Vista la scarsità di accessi inscrittura, i dati di una directory sono essenzialmente stati-ci, come i numeri di telefono dei dipendenti di un’aziendao gli attributi dei certificati di chiave pubblica emessi dauna CA (o da un’azienda). Perciò, la coerenza degli aggior-namenti di una directory non pone problemi di criticità,mentre al contrario un sistema di gestione di database perapplicazioni gestionali, che opera su dati dinamici, deve im-plementare il concetto di transazione, per cui i dati si uncerto insieme devono essere aggiornati “contemporanea-mente” o la transazione deve essere annullata.

Un servizio di directory è quindi ottimizzato per le ope-razioni di lettura. I dati sono memorizzati nella directory se-condo una struttura definita da uno schema estendibile emodificabile. I servizi di directory usano un modello di-stribuito di archiviazione delle informazioni, che solita-mente prevede delle repliche sincronizzate tra i server didirectory.

Esempi di servizi di directory sono i DNS (Domain NameSystem) che associano i nomi di host o i nomi di domini airispettivi indirizzi IP e ad altre informazioni.

X.500I servizi di directory erano parte dell’iniziativa Open Sy-

stems Interconnect (OSI) volta a introdurre standard dinetworking comuni e a garantire l’interoperabilità tra di-versi produttori. Negli anni ’80 del secolo scorso, ITU e ISOintrodussero un insieme di standard - la famiglia ITU X.500- per i servizi di directory, inizialmente per supportare loscambio di messaggi elettronici tra diversi gestori e la ri-cerca dei nomi dei componenti di rete.

Le norme X.500 hanno definito un modello per la me-morizzazione delle informazioni chiamato DIT (DirectoryInformation Tree), che consente di organizzare e raggrup-pare gli oggetti (persone e risorse) secondo una strutturagerarchica.

L’esempio di DIT mostra graficamente la struttura ge-rarchica dei dati. Dalla radice (root), in cima, si diramanotutti gli altri oggetti.

Il primo livello sotto la radice può individuare una na-zione e nella figura vengono mostrati due oggetti di tipocountry (abbreviati con c) e valorizzati con IT, sigla dell’I-talia, e UK per United Kingdom.

All’interno delle nazioni sono presenti delle organizza-


5.6.2 Servizi didirectory

5.6.2.1 Conoscere iserver LDAP

Esempio di DirectoryInformation Tree X.500

42

43

44


zioni (oggetto organization, abbreviato con o), indicate conil loro nome (o=società X e o=società Y).

Sotto un’organizzazione si può avere un’unità organiz-zativa (oggetto organizationalUnit, abbreviato con ou) op-pure una persona (oggetto commonName, abbreviato concn).

Ogni oggetto ha una sua indicazione univoca all’internodella directory, che viene detta Distinguished Name (ab-breviata con DN), ottenuta concatenando l’identificativo diogni oggetto, che viene chiamato Relative DistinguishedName. Nella figura, cn=Mario Rosi è un RDN, mentre il suoDN completo è cn=Mario Rosi, ou=Acquisti, o=società X,c=IT.

Il DIT è svincolato dall’ubicazione effettiva delle infor-mazioni, infatti è possibile collegare tra loro più server didirectory, ognuno responsabile del contenuto di un sot-toalbero, che forniscono un servizio di directory che è lasomma dei servizi forniti dai singoli server.

Le norme X.500 si basano sui protocolli OSI, ma rimase-ro largamente inutilizzate perché la famiglia di protocolliTCP/IP rimase lo standard di fatto per i protocolli di rete.

LDAPLo standard X.500 si è dimostrato molto più complesso

di quanto sia realmente necessario alle organizzazioni. Èstato quindi introdotto un protocollo “leggero” chiamatoLDAP (Lightweight Directory Access Protocol, protocolloleggero d’accesso alle directory), basato su TCP/IP, persemplificare l’accesso ai servizi di directory pur mante-nendolo stesso modello gerarchico introdotto da X.500.LDAP oggi è ampiamente accettato nella comunità Internete consente di interrogare, inserire, rimuovere e modificaregli oggetti contenuti in una directory secondo una modalitàstandard. Esistono due versioni di LDAP in uso: LDAP v2(descritta dalla RFC 1777, X.500 Lightweight Directory Ac-cess Protocol) e LDAP v3, descritta dalla RFC 2251, Li-ghtweight Directory Access Protocol (v3).

LDAP è una versione ridotta di DAP (Directory AccessProtocol), un protocollo che fornisce accesso ai servizi didirectory X.500 e che richiede l’intero stack dei protocolliOSI unitamente a una quantità di risorse di calcolo pococompatibili con i desktop computer. LDAP è una versionedi DAP ampiamente snellita e adattata all’esecuzione su re-ti TCP/IP.

Un tipico esempio di utilizzo di LDAP è attraverso i pro-grammi di posta elettronica; anziché costruire o distribui-re una rubrica di contatti su ogni computer, il programmasi collega al server LDAP che ospita la directory contenen-te gli indirizzi email di tutti gli utenti dell’organizzazione(azienda, università, ente pubblico ecc.). L’accesso è mol-to rapido e l’amministrazione delle informazioni ha un co-sto minimo.

L’uso di LDAP non si limita alle informazioni relative apersone o contatti. LDAP è utilizzato per cercare i certificatidi chiave pubblica, stampanti e componenti di una rete eper fornire il single-signon, dove un’unica autenticazione dàaccesso a un insieme di risorse di rete. LDAP è adatto peraccedere a qualunque informazione di tipo elenco (direc-tory), dove frequenti ricerche veloci (accesso in lettura) esporadici aggiornamenti sono la norma.

LDAP non definisce come funzionano i programmi sul la-to server e sul lato client. Definisce il linguaggio usato daiclient per dialogare con i server (il dialogo può avvenire an-che tra server e server). Il client può essere un browser, unprogramma di email o un’altra applicazione. Il server puòparlare solo LDAP o anche altre lingue (protocolli).

LDAP definisce uno schema, cioè il formato e gli attributidei dati conservati nel server, e dei permessi, stabiliti da unamministratore per limitare l’accesso al database a chi neha titolo. I server LDAP possono essere classificati a tre li-velli: i grandi server pubblici, i grandi server di universitàe imprese e server più piccoli a livello di gruppo di lavoro.

La maggior parte dei server pubblici è sparita introno al-l’anno 2000 a causa degli abusi nell’utilizzo degli indirizziemail, mentre restano accessibili i server LDAP delle CAcon le informazioni relative ai certificati X.509.

Esistono numerose implementazioni di server LDAP, tracui le seguenti.• Slapd

• University of Michigan • Openldap

• Netscape Directory Server • Microsoft Active Directory (AD) • Novell Directory Services (NDS) • Sun Directory Services (SDS) • Lucent Internet Directory Server (IDS)

Utilizzo di un browser per interrogare un server LDAP

I browser moderni sono in grado di collegarsi a un ser-ver LDAP secondo un metodo definito nella RFC 2255 (TheLDAP URL Format). Si utilizza un particolare formato diURL e il browser (se supporta l’accesso LDAP) esegueun’interrogazione in lettura sull’host specificato, usando iparametri definiti e permettendo di aggiungere le voci tro-vate alla rubrica locale. La notazione dell’URL in realtà èuna comoda interfaccia con il browser, che viene tradottain una chiamata standard per interrogare il server LDAPspecificato.

Gli URL di tipo LDAP possono diventare complessi se siusano i numerosi parametri previsti dalla sintassi. Nel ca-so più semplice, gli URL presentano la struttura ldap://ho-stname[:port]/distinguishedName. Se non si specifica unaporta TCP, viene utilizzata quella di default (la 389). Il di-stinguished name è nella forma vista nella sezione prece-dente.

Per esempio, il seguente ipotetico URLldap://ldap.infocamere.it/cn=CACCIA%2FANDREA%2F2003111435A3009,ou=Ente%20Certificatore%20del%20Sistema%20Camerale,o=InfoCamere%20SCpa,c=IT permetterebbe al browser di accedere al server LDAP diInfoCamere (che dà accesso tra l’altro ai dati dei certifica-ti emessi da questa CA) e di aggiungere l’utente AndreaCaccia alla rubrica locale dell’utente.

Le informazioni del server di InfoCamere sono suddivi-se in diverse ou (unità organizzative). La ou Certificati diFirma elenca i cn (nomi comuni) dei titolari dei certificatie le relative informazioni. Se si vuole accedere alle infor-mazioni di una voce di un server LDAP e non si conosce ilDN corrispondente, si può utilizzare un’applicazione spe-cifica fornita dalla CA o uno dei browser LDAP (ne esisto-no sia gratuiti sia a pagamento) per esplorare i contenuti diun server LDAP e procurarsi il DN dei titolari di certificato.Con il DN inserito nell’URL LDAP vista sopra, si può usareun web browser per visualizzare i dati del certificato.

Vediamo un esempio. Supponiamo di voler verificare ilcertificato di XY, rilasciato da InfoCamere. Usiamo il brow-


5.6.2.2 Utilizzo di unbrowser perinterrogare un serverLDAP

45


ser LDAP Administrator (www.ldapadministrator.com) peraccedere in lettura, in modo anonimo (senza credenziali),al server di Infocamere (fig 45).

Aprendo la ou Certificati Di Firma e ordinando i cn in sen-so crescente è facile trovare il nominativo che ci interessa(qui il nome del titolare è oscurato per privacy) (fig 46).

In uno dei modi consentiti da LDAP Administrator (co-me visualizzazione ed esportazione), si copia il DN del ti-tolare del certificato e lo si incolla nel browser (in coda aldap://ldap.infocamere.it). Sia in IE sia in Firefox, si apre laseguente finestra, che permette di aggiungere il nominati-vo alla rubrica (fig 47).

Aprendo la sezione ID digitali, si seleziona il certificato(fig 48).

Cliccando su Proprietà, viene visualizzato il contenutodel certificato (fig 49).

Conoscere il significato di Common Name,Distinguished Name e Attributo

Riprendiamo ed estendiamo alcuni concetti introdottinella sezione 5.6.2.1. Il protocollo LDAP presuppone cheuno o più server forniscano l’accesso a un Directory Infor-mation Tree. Il DIT non è necessariamente memorizzato inunico server, ma ogni server è proprietario delle informa-zioni contenute in uno o più rami del DIT complessivo (ser-ver master). Ogni server può anche fornire servizi di repli-ca rispetto a rami del DIT di cui non è proprietario (serverslave); in questo caso i server possono essere configuratiin modo che le informazioni in essi contenute siano sin-cronizzate a intervalli determinati o in tempo reale a se-guito di una modifica dei dati.

Il DIT è composto da oggetti che vengono chiamati en-try. Ogni entry è composto da un insieme di attributi, chesono costituiti da un nome e da uno o più valori. Uno o piùattributi, detti naming attributes, costituiscono il nome del-l’entry, detto Relative Distinguished Name (RDN). Tutti glientry che condividono lo stesso padre devono avere RDNdistinti.

La concatenazione di tutti gli RDN, partendo da un de-terminato entry fino alla root (esclusa), forma il Distingui-shed Name (DN) di quell’entry. Ogni entry ha quindi un pro-prio DN distinto e unico.

Ogni attributo è un tipo di dato che ha associati uno opiù valori. Il tipo di dato è identificato da un nome descrit-tivo e da un Object Identifier (OID) che è un identificatoreunivoco assegnato da un ente di standardizzazione. Il tipodi dato dell’attributo ha associata una serie di proprietàche definiscono se il valore associato è unico o può esseremultiplo, la sintassi a cui il valore si deve conformare e leregole con cui effettuare le ricerche (per esempio nel casodi un nome di persona non si fa distinzione tra caratterimaiuscoli e minuscoli). L’attributo mail, per esempio, puòavere uno o più valori di tipo IA5 String (ASCII) e non fa dif-ferenza tra caratteri minuscoli e maiuscoli.

Lo schema è la collezione delle definizioni dei tipi di at-tributo, delle definizioni delle classi di oggetti e delle altreinformazioni utilizzate dal server nelle operazioni di ricer-ca, aggiunta e modifica di entry.

Ogni entry deve avere un attributo objectClass. Questoattributo indica quali sono le classi di oggetti associate aglientry che determinano, insieme allo schema, quali attri-buti sono consentiti e quali sono obbligatori all’interno


5.6.2.3 Conoscere ilsignificato diCommon Name,Distinguished Name eAttributo

46

47

48

49


dell’entry. Le objectClass costituiscono una gerarchia e ognuna di

esse ha sempre una superclasse, da cui eredita tutti gli at-tributi, ad eccezione della superclasse “top” che è la radi-ce di tutte le definizioni di objectClass.

Quando viene aggiunta una classe di oggetti, anche tut-te le relative superclassi vengono aggiunte (la superclasseè la classe da cui una classe di oggetti eredita tutti gli attri-buti obbligatori e opzionali). Vi sono tre tipi di objectClass:- Astratte (abstract), definite solo a scopo logico. Non po-sono essere usate direttamente per definire un entry mapossono essere superclassi di altre objectClass (ad esem-pio la superclasse top).- Strutturali (structural), possono essere usate per definireun entry e ne definiscono gli attributi base. Ad esempio, laclasse di tipo “Organization” prevede degli attributi tipi-camente associati a un’organizzazione, come il nome(“organizationName”).

- Ausiliarie (auxiliary), possono essere usate per estendereil numero di attributi associabili a un entry. Ad esempio,la classe di tipo “certificationAuthority” prevede gli attri-buti “caCertificate” dove viene memorizzato il certificatodi CA e “certificateRevocationList” dove viene memoriz-zata la CRL. Questa objectClass può essere per esempioassociata a entry di tipo “Organization”.

Esempi di classi di oggetti sono country (c), locality (l),organization (o), ornanizationalUnit (ou) e person (cn). Adesempio, un entry cn contiene l’identificatore della perso-na e può includere attributi come indirizzo, telefono, privi-legi e così via.

La RFC 2256 (A Summary of the X.500(96) User Schemafor use with LDAPv3) fornisce una panoramica dei tipi di at-tributo e delle classi di oggetti definiti dai comitati ISO eITU-T nei documenti X.500.

DN e RDNLa cima dell’albero di una directory LDAP è la base, chia-

mata in inglese “Base DN” (paragonabile alla root di un filesystem Unix). Il base DN può essere espresso con varie no-tazioni:

- o=”FooBar, Inc.”, c=US- o=foobar.com- dc=foobar, dc=com.Il DN è composto di due parti: il base DN (l’ubicazione al-

l’interno della directory LDAP dove si trova l’entry) e l’RDN(Relative Distinguished Name).

Considerando l’albero di directory seguente (i singolientry sono omessi):

dc=foobar, dc=com ou=customers

ou=asia ou=europe ou=usa

ou=employees ou=rooms ou=groups ou=assets-mgmt ou=nisgroups ou=recipes

il base DN è dc=foobar, dc=com e l’RDN di un entry memo-rizzato in ou=recipes è cn=Oatmeal Deluxe. Il DN completodi questo entry (costruito partendo dalla fine) è quindi:cn=Oatmeal Deluxe,ou=recipes,dc=foobar,dc=com.

Un esempio di entry LDAP Quello che segue è il record di Fran Smith, impiegato del-

la società Foobar, Inc. Il formato di questo entry è LDIF(LDAP Data Interchange Format), usato per esportare e im-portare gli entry dalle e nelle directory LDAP.

dn: uid=fsmith, ou=employees, dc=foobar, dc=comobjectclass: personobjectclass: organizationalPersonobjectclass: inetOrgPersonobjectclass: foobarPersonuid: fsmithgivenname: Fransn: Smithcn: Fran Smithcn: Frances Smithtelephonenumber: 510-555-1234roomnumber: 122Go: Foobar, Inc.mailRoutingAddress: [email protected]: mail.foobar.comuserpassword: {crypt}3x1231v76T89Nuidnumber: 1234gidnumber: 1200homedirectory: /home/fsmithloginshell: /usr/local/bin/bash

Il DN di questo entry è uid=fsmith, ou=employees,dc=foobar, dc=comIn sintesi:- Un entry è composto di attributi- Gli attributi consistonodi tipi di dati a uno o piùvalori e sono definiti se-condo una specifica sin-tassi

- Il tipo descrive qual èl’informazione

- Il valore è l’effettiva infor-mazione

Esempi di nomi di attri-buti e abbreviazioni (ve-di RFC 2256) (fig. 50):

Un esempio di definizione di attributo in uno schema LDAP:attributetype ( 1.3.6.1.4.1.15490.1.11 NAME'studentName'

DESC 'description'EQUALITY caseIgnoreMatchSUBSTR caseIgnoreSubstringsMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.15SINGLE-VALUE )

Un esempio di definizione di objectclass in uno schemaLDAP:objectclass ( 1.3.6.1.4.1.15490.2.4 NAME 'objStudent'

DESC 'object class'SUP top STRUCTURALMUST ( studentName $ studentNumber $

studentAddress $ studentAcademicYear $ studentCourse $studentStatus $ studentYear ) )

Conoscere il significato di X.509Tra le norme X.500, ha particolare rilevanza, ai fini della

sicurezza, la norma X.509, Directory: Authentication Fra-mework. Si tratta di una norma fondamentale, dato che af-fronta le problematiche più sostanziali relative all’imple-mentazione di infrastrutture a chiave pubblica. Quello chesegue è un breve sommario dei contenuti.- Definizione del concetto di CA (Certification Authority)come Terza Parte Fidata che si occupa della gestione del-le chiavi pubbliche di tutte le entità che fanno parte di unaPKI.

- Definizione del formato dei certificati digitali, che asso-ciano le entità con le loro chiavi pubbliche e che vengonoemessi dalla CA.

- Definizione delle liste di revoca dei certificati (CRL),


5.6.2.4 Conoscere ilsignificato di X.509

50


che elencano i certificati che sono stati revocati (resi nonvalidi) prima della data di scadenza. Le CRL sono firmate epubblicate dalla CA.

- Definizione del concetto di mutua certificazione tra CAdiverse. Si tratta di un accordo che consente a due CA diunire i propri domini: gli utenti di una CA sono in grado diaccettare e validare i certificati emessi dall’altra CA e vice-versa. Perché ciò accada, ogni CA emette un certificato perla chiave pubblica dell’altra CA e questi certificati vengonouniti in un unico oggetto detto crossCertificatePair.

- Utilizzo della directory quale deposito di tutte le infor-mazioni di sicurezza necessarie alla PKI per il suo funzio-namento. A questo scopo vengono descritte apposite clas-si di oggetti che possono contenere certificati e CRL.

Le classi di oggetti che vengono definite sono le se-guenti.- certificationAuthority: un entry con questa objectClasspuò contenere gli attributi CACertificate, dove vengonomemorizzati i certificati della CA; certificateRevocation-List e authorityRevocationList, dove vengono memoriz-zate le liste di revoca per i certificati degli utenti e per icertificati di CA; crossReferencePair, dove vengono me-morizzati eventuali certificati di mutua autenticazione.

- strongAuthenticationUser, che consente la memorizza-zione dei certificati utente nell’attributo userCertificate.

Il formato dei certificati e delle liste di revoca è stato de-scritto nella sezione PKI.

La norma X.509, pur definendo il formato standard dicertificati e CRL, non dà garanzia che due implementazio-ni conformi allo standard possano interoperare. La già ci-tata RFC 3280, Internet Public Key Infrastructure Certifica-te and Revocation List (CRL) Profile, definisce un profilo,ovvero una serie di limitazioni ai gradi di libertà concessidallo standard, che consente di avere applicazioni intero-perabili.

Utilizzo dei server LDAP per la gestione dei profiliutente e l’autenticazione

Come si è visto, un server LDAP fornisce un servizio didirectory basato su un database con struttura gerarchica,interrogabile da client disponibili sui vari sistemi operati-vi, sia come software libero sia come software proprietario,con interoperabilità assicurata dagli standard che defini-scono il protocollo LDAP.

Esempi di server LDAP sono Active Directory, introdot-to da Microsoft a partire da Windows 2000 server, e OpenL-DAP, una versione Open Source ampiamente diffusa nelmondo Linux.

Un servizio di directory fornisce un deposito centraliz-zato e facilmente accessibile di informazioni relative a or-ganizzazioni, unità organizzative, persone e altri elementiappartenenti a un certo dominio, contenendo informazio-ni come nomi, numeri di telefono e indirizzi di posta elet-tronica. Un servizio di directory si presta altrettanto benea memorizzare tutte le risorse logiche e fisiche, tutti i di-spositivi e gli elaboratori appartenenti a una rete di com-puter appartenente a un dominio (un gruppo di computergestiti in modo centralizzato e caratterizzato da un peri-metro di sicurezza). La directory può contenere informa-zioni dettagliate su file system (file e cartelle), stampanti,indirizzi, credenziali di accesso, utenti e gruppi di utenti.

Per esempio, l’Active Directory di Windows Server 2003server gestisce informazioni sui computer, i domain con-troller, la configurazione del sistema, utenti e gruppi d’u-tenti e altro ancora (fig. 51).

Un profilo utente è costituito da tutte le informazioni as-sociate all’utente, incluse le informazioni di autenticazionee le autorizzazioni di accesso alle risorse di rete. Per esem-pio, in Windows Server 2003, le proprietà di un utente pos-sono includer numerose categorie di informazioni, come sivede nella figura. (fig. 52).

Per descrivere ogni utente e gruppo di utenti si deve po-

ter specificare quali sono le risorse a cui hanno diritto diaccedere e per quali tipi di operazioni. Ad esempio, unutente potrebbe avere il diritto di usare una determinatastampante, l’accesso in lettura a certi archivi e l’accesso inscrittura ad altri. Questa associazione viene normalmenteespressa mediante delle Access Control List (ACL); ogniACL rappresenta l’elenco delle regole di accesso a una ri-sorsa ed è memorizzata nella directory in una Access Con-trol Entry (ACE).

Un altro concetto fondamentale è quello di gruppo diutenti e di gruppo di risorse. Anche i gruppi sono descrittiin entry di directory, che contengono l’elenco dei membridel gruppo e i privilegi del gruppo. All’interno dell’entry diogni utente o risorsa ci può essere l’elenco dei gruppi di ap-partenenza, dato che utenti e risorse possono appartene-re a più gruppi. I gruppi permettono di semplificare note-volmente l’amministrazione di una rete.

Ad esempio, in una grossa organizzazione, si possonodefinire dei gruppi in base alle divisioni dell’organigramma,per esempio “Promo-Marketing”, “Vendite”, “Amministra-zione” e “Qualità”. Considerando che esista una cartellaMarketing del file system, si può supporre che gli utenti delgruppo Marketing vi abbiano accesso in lettura e scritturae che gli utenti del gruppo Vendite vi abbiano accesso in so-la lettura. Oltre che in base alla funzione, i gruppi possonoessere definiti anche secondo l’ubicazione fisica degli uten-ti e delle risorse; possono esserci ad esempio gruppi diutenti e risorse suddivisi per edifici e sedi distaccate e


5.6.2.5 Utilizzo deiserver LDAP per lagestione dei profiliutente el’autenticazione

51

52


gruppi di telelavoratori.Il profilo utente memorizzato nella directory può essere

utilizzato per memorizzare informazioni legate all’autenti-cazione dell’utente, come hash di password, token o certi-ficati. In questo modo, con un singolo sign-on, la directorypermette di autenticare l’utente nell’accesso ai vari sistemie risorse che compongono la rete.

Una rete paritetica, in cui ogni computer gestisce leinformazioni relative ai propri utenti e risorse, richiede lamoltiplicazione delle attività di gestione e una complessaamministrazione per definire gli utenti e i privilegi per gliaccessi tra i computer della rete. Al contrario, un serviziodi directory permette di unificare il controllo e la gestionedelle informazioni, che sono mantenute coerenti e aggior-nate; se basato su standard aperti, il servizio di directoryassicura anche la riutilizzabilità futura. Inoltre, l’utilizzo diprotocolli standard permette di attuare meccanismi di pro-

visioning (approvvigionamento d’informazioni) automati-co, popolando la directory con informazioni provenienti dadatabase aziendali di tipo diverso.

I meccanismi di gestione e di replica delle directory pre-sentano vantaggi anche in termini di affidabilità, visto cheforniscono una visione logicamente coerente delle infor-mazioni, anche se queste possono essere fisicamente di-stribuite su più sistemi aziendali e in diverse aree geogra-fiche.

I server LDAP forniscono alle applicazioni un’infrastrut-tura di supporto per l’autenticazione e le autorizzazioni,consentendo la gestione centralizzata dei profili utente, lascelta del livello e della modalità d’interazione con i diver-si repository dei dati (le directory) e l’automatizzazione deiprocessi di creazione e rimozione degli account sui sistemifinali. La facilità e il controllo della gestione centralizzata sitraduce quindi in una maggiore sicurezza complessiva. �


Documents

Certificati e certificatori Infrastruttura a chiave pubblica · chiave pubblica di Alberto e gli scrive un messaggio riser-vato cifrandolo con quella chiave, solo Alberto sarà in