Autenticazione delle chiavi pubbliche

Abbiamo già incontrato il problema fondamentale della crittografia asimmetrica, che è l'autenticazione delle chiavi pubbliche. Infatti, per poter comunicare con Bob, Alice deve conoscere la chiave pubblica di Bob, $K_{pub,B}$ e, spesso, anche Bob deve conoscere la chiave pubblica di Alice, $K_{pub,A}$. Scambiarsi queste chiavi è un problema, perché dovrebbero essere scambiate su un canale ritenuto sicuro, al fine di garantire l'autenticità della sorgente del certificato e l'integrità del certificato stesso. Vi sono poi altri problemi, legati alla crittografia asimmetrica, come la scalabilità: in una rete di $n$ nodi, come abbiamo visto, occorrerebbe tenere aggiornati $(n-1)$ certificati pubblici per macchina. Esiste poi un altro punto fondamentale, che è la revoca delle chiavi pubbliche: se Alice si accorge che Trudy ha rubato la sua chiave privata, allora deve avere un metodo semplice ed efficace per informare tutti del fatto che la sua chiave pubblica non deve più essere usata né si deve ritenere vera una firma creata dopo la data del furto.

Certificati digitali

Un certificato digitale è un oggetto $CERT_{ID}$ che garantisce un collegamento esistente tra una chiave pubblica ed un nome, che può essere il nome di una persona, di un'azienda, di un particolare ufficio di un'azienda, di un server, ecc...

$CERT_{ID}=\{ID,K_{pub,ID}\}$

Chi garantisce che il certificato è vero, e che quindi esiste un legame tra la chiave pubblica e l'identità dichiarata, è una certification authority CA: la CA appone la sua firma sul certificato digitale, in modo tale da garantire che

• Il certificato non è stato manomesso;
• Lei ha verificato l'identità del possessore della chiave privata omologa di quella pubblica nel certificato.

L'identità può essere verificata in diversi modi, a seconda delle politiche adottate dalla CA. Sta all'utente finale del computer decidere di quali CA fidarsi, scegliendole in base alla serietà con cui operano, alle loro politiche di verifica delle identità, ....

Per poter verificare l'identità delle CA fidate, bisogna avere una copia autentica della chiave pubblica della CA. Questo è un problema, dal momento che non si ha modo di verificare se una chiave pubblica di CA sia vera. A questo punto, entra in gioco il "canale sicuro": quando si acquista un calcolatore, tipicamente lo si acquista con un sistema operativo preinstallato. Questo sistema operativo possiede già, al suo interno, delle chiavi pubbliche di CA che il produttore del software ha deciso essere fidate: quando si acquista un computer, si acquista anche l'elenco delle CA preferite dal produttore del computer e, implicitamente, si accetta di fidarsi di quelle CA; di norma, nessun utente sa nemmeno dell'esistenza di queste chiavi, quindi men che meno va a controllare l'elenco delle sue chiavi pubbliche.

Manuale: Controllare l'elenco delle CA fidate dal vostro browser

Il vostro browser contiene delle chiavi fidate. Se avete Mozilla Firefox, per vedere l'elenco delle CA di cui vi fidate, cercate:

Strumenti -> Opzioni -> Avanzate

Da qui, accedete alla scheda Cifratura e cliccate sul pulsante Mostra certificati. Dalla finestra che si apre, potete accedere all'elenco di tutte le CA che Mozilla ha deciso di inserire tra le vostre fidate.

File:Sicurezza finestra certificati root CA firefox.png

Public Key Infrastructure

Una PKI, infrastruttura a chiave pubblica, è un'architettura che definisce i meccanismi e le politiche che sono necessarie, al fine di garantire l'autenticazione delle chiavi pubbliche. Un'architettura PKI definisce:

• Come devono essere formattati i certificati;
• Come vengono gestite le relazioni che esistono tra le CA e gli utenti, oppure tra diverse CA;
• Le politiche che permettono la revoca dei certificati;
• I servizi che possono essere offerti da un certificato.

Certificati X.509

I certificati X.509 sono dei certificati digitali, formattati secondo lo standard ITU-T X.500. Il formato con cui vengono salvati i parametri è del tipo

$<{\text{object}}={\text{property}}>$

E la codifica usata è l'ASN.1. D'ora in avanti useremo una suddivisione logica dei campi dei certificati, che può essere diversa nella realtà.

File:Sicurezza formato certificato x 509.png

Versione ed altri dati

Lo standard X.509 è stato pubblicato in tre versioni, quindi in questo campo ci deve essere il numero di versione, $1$, $2$ o $3$. Oltre alla versione, sono contenuti:

• Periodo di validità del certificato, che non deve essere ritenuto valido prima e dopo le date indicate. Questo campo, poi, può essere integrato con un successivo certificato di revoca, da usare se la chiave viene persa o rubata.
• Numero di serie del certificato, perché ogni CA deve tener tracciato il numero di certificati che vengono firmati. Questo numero non può essere replicato per più certificati firmati con la stessa chiave privata della CA; la coppia

$<{\text{CA}},{\text{numero di serie}}>$

Deve essere univoca.

• Estensioni varie, come per esempio il tipo di utilizzo che è permesso fare del certificato:

• Posso firmare documenti;
• Posso creare a mia volta una CA, di cui la CA originale si fida e si fa garante.

Identità della CA e dell'intestatario

Le identità devono essere specificate secondo lo standard X.500. Un paio di righe di esempio:

Issuer: C=IT, ST=RM, L=Roma, O=Wikimedia, OU=Wikiversity, CN=Ca di Wikiversity

Subject: C=IT, ST=RM, L=Roma, O=Wikimedia, OU=Wikiversity, CN=it.wikiversity.org

Vediamo i vari campi:

• $C$ sta per country, la nazione in cui si trova la CA o l'intestatario;
• $ST$ indica lo state, la nazione in cui si trova la CA o l'intestatario: se siamo in USA, useremo il nome della nazione (Alabama, Ohio, ...), mentre in Italia useremo la provincia di appartenenza;
• $L$ è la città in cui si trova la CA o l'intestatario;
• $O$ è l'organization, il nome dell'azienda CA o dell'intestatario.
• $OU$ è l'organization unit, diremmo il dipartimento o l'ufficio particolare dell'azienda;
• $CN$ è il common name, il nome: può essere il nome dell'azienda in maniera intellegibile dall'uomo, oppure l'indirizzo del server che userà questo certificato:

• Nel caso in cui si stia specificando l'issuer, allora definisce la CA che ha rilasciato il certificato;
• Nel caso in cui si stia specificando il subject, allora si definisce l'utente, cioè la persona o l'azienda a cui quel certificato è associato.

Chiave pubblica dell'intestatario

In questo campo troviamo la chiave pubblica che viene certificata, cioè che la CA dichiara essere associata al soggetto indicato nel campo subject del certificato. All'interno di questo campo, oltre alla chiave stessa, devono esserci anche tutte quelle informazioni che sono necessarie per interpretare la chiave, come

• Il sistema di cifratura, che può essere RSA, DSS, ...
• Parametri del sistema di cifratura, come il numero $n$ usato come modulo oppure l'esponente pubblico $e$.

Firma su tutto ciò che precede

La firma apposta in coda al certificato è la garanzia che tutto quello che è stato scritto prima è effettivamente valido. La firma contiene, tra le altre cose, i parametri che sono stati usati per generarla, come l'algoritmo MDC usato o il tipo di chiave usata per firmare tutto.

La firma autentica tutto il certificato dal numero di versione fino alla chiave autenticata. Si tratta della versione cifrata, con la chiave privata della CA, del digest MDC del certificato. A questo punto, chiunque voglia verificare l'autenticità del messaggio dovrà

• Calcolare l'MDC del corpo del certificato;
• Cifrare il digest con la chiave pubblica dell'ente certificatore;
• Verificare se la firma del certificato ed il risultato della cifratura corrispondono.

Certificati di revoca

Qualsiasi sistema di certificazione deve prevedere anche un meccanismo di revoca dei certificati; questo è necessario per tutti quei casi in cui la chiave risulta compromessa, si ha il dubbio che possa essere stata compromessa oppure si sa che non sarà più usata per nessun motivo (per esempio, il titolare cambia lavoro o mansione).

La revoca del certificato deve essere fatta in maniera esplicita, attraverso una lista di certificati revocati.

Certificate Revocation Lists

Le CRL sono degli elenchi di certificati da considerare non più validi, per qualsiasi motivo. Ogni CA pubblica o aggiorna periodicamente questo elenco di certificati, che sarebbero ancora validi secondo il parametro expiration date del certificato, ma che si richiede non lo siano più.

La lista di revoca contiene:

• Il nome della CA che revoca;
• Le date che indicano quando la lista è stata scritta l'ultima volta e quando sarà aggiornata;
• L'elenco di tutti i numeri seriali di tutti i certificati che non devono più essere considerati validi;
• La firma di autenticità della CA su tutto il certificato di revoca.

A questo punto, la CA non può fare più nulla per proteggere gli utenti, ed i suoi clienti, da un certificato rubato o perso: devono essere i singoli, in maniera automatizzata o meno, a contattare la CA e farsi dare la lista dei certificati revocati. È importante notare che i certificati che sono stati revocati non possono più essere considerati nuovamente validi: la revoca non è revocabile. Di conseguenza, anche se si ha una CRL scaduta, questa resta comunque valida in tutto e per tutto.

Ad oggi, esiste un solo protocollo pensato per aggiornare la lista dei certificati revocati, il Online Certificate Status Protocol, OCSP; purtroppo, ad oggi, quasi nessun software implementa ed usa questo protocollo, di conseguenza, c'è sempre il rischio di considerare valido un certificato anche già revocato da anni.

Distribuzione delle chiavi pubbliche dei CA

Per poter verificare l'autenticità di una firma digitale, dobbiamo avere la versione pubblica della coppia di chiavi in possesso da chi ha firmato; il problema, ancora una volta, è che le chiavi dei CA non sono autenticate, ma sono autofirmate (self-signed), dal momento che non c'è un ente superiore che possa certificare la validità delle loro chiavi. Questo è lo stesso problema che ci siamo posti inizialmente, quando abbiamo cominciato a studiare il problema dell'autenticazione di qualsiasi chiave pubblica.

Esistono, anzitutto, due tipi di CA:

• La root CA, la CA radice;
• La CA figlia.

Nel caso di CA figlia, la chiave pubblica è garantita da una root CA, cioè una CA radice di tutto il cosiddetto albero delle certificazioni. Una root CA, a sua volta, avrà una chiave pubblica autofirmata. Per garantire l'autenticità delle chiavi pubbliche delle root CA, ad oggi, l'unico metodo trovato è stato quello di inserire le chiavi all'interno dei browser e dei programmi che le usano, direttamente al momento dell'installazione del sistema operativo su computer e cellulari, ancora in fabbrica.

Come conseguenza di questo fatto, quando si scarica un software da internet che contiene certificati, non si può avere la garanzia assoluta che questi certificati siano corretti. Quello che si può fare è procurarsi la firma del produttore del software, apposta su un digest MDC del programma di installazione. In questa maniera, partendo da un software con dei certificati installati all'origine, si può avere qualche garanzia, se l'MDC non è stato violato, che i certificati (così come tutto il software) che stiamo scaricando non siano stati modificati. È importante che il digest sia firmato, perché deve provenire da una fonte sicura: se per esempio si scarica un browser come Mozilla Firefox da un sito-truffa, questo probabilmente avrà pubblicato un digest MDC non firmato dalla Mozilla foundation, cosa che può portare ad una sensazione di falsa sicurezza dell'utente finale.

Distribuzione dei certificati

Il sistema ideale per la distribuzione dei certificati sarebbe un directory service, cioè un'infrastruttura simile al DNS che permetta a chiunque di procurarsi i certificati cercati, permettendo di verificare la firma in maniera sicura: in questo caso, Alice potrebbe parlare con Bob senza dovergli chiedere il suo certificato, gli basterebbe cercarlo su internet.

Ad oggi, un'infrastruttura del genere esiste, ma non in larga scala: all'interno di reti che usano LDAP è possibile trovare un'infrastruttura a directory service per i certificati digitali.

È importante notare che la stragrande maggioranza dei programmi che necessitano una qualche forma di autenticazione, ad oggi, utilizzano e scambiano certificati prima di fare autenticazione: quasi tutti i browser moderni utilizzano i certificati per permettere all'utente una navigazione sicura.

File:Sicurezza firefox certificato valido.png

File:Sicurezza firefox problemi di certificato.png

Quante e quali CA

Per l'infrastruttura delle CA ci sono diversi possibili approcci:

• Monopolio;
• Oligopolio;
• Anarchia.

Monopolio significa avere una sola, grande root CA, dalla quale le CA figlie dipendono. Avere un sistema anarchico, al contrario, significa che chiunque può fare da root CA, autofirmando il proprio certificato digitale. Infine, un sistema ad oligopolio prevede un numero ridotto di root CA, tutte allo stesso livello e con il loro certificato autofirmato, da cui poi dipendono altre CA figlie.

Ad oggi, nel mondo, il sistema usato principalmente è quello oligarchico, dove si hanno centinaia di root CA usate per lo scambio di dati tra sconosciuti (firme digitali, server di siti web); nonostante questo, anche il modello anarchico è molto vivo: molte aziende hanno al proprio interno delle root CA, usate per creare altri certificati per gli usi interni.

La ricerca moderna si sta concentrando sull'implementazione di catene di CA, cioè un'infrastruttura di oligopolio in cui i certificati delle root CA sono garantiti, a loro volta, da altre root CA e viceversa. In questa maniera, si vuole dare una risposta al problema dei certificati autofirmati.

Costruire la propria root CA

La sicurezza di tutto l'albero di certificati che ha le proprie fondamenta in una root CA risiede sulla chiave privata della root CA stessa. Devono essere prese delle misure efficaci per garantire che non possano essere installati certificati autofirmati fasulli delle root CA, e ci deve essere un grande sforzo per proteggere la chiave privata della root CA. Nel caso di grandi aziende di certificazione, la protezione della chiave privata giustifica investimenti enormi per la sicurezza fisica dei supporti dove questa è memorizzata: non di rado, esistono guardie armate agli ingressi dei caveau in cui queste chiavi sono custodite, si tratta del valore principale di un'azienda che può arrivare a valere anche parecchi miliardi di dollari.

Esempio: Caso di certification authority'

Mark Shuttleworth è un imprenditore sudafricano. Nel 1999, Shuttleworth ha venduto la sua azienda di certificazione Thawte a VeriSign per la somma di 575 milioni di dollari americani. Con questi soldi, ha potuto diventare un turista spaziale e fondare la Canonical, un'azienda che, tra le altre cose, è la principale finanziatrice del sistema operativo Ubuntu GNU/Linux.

La chiave privata di una root CA dovrebbe essere mantenuta scollegata da qualsiasi rete, su memorie cifrate ed, a sua volta, in forma cifrata.

Per poter firmare una chiave pubblica, un'autorità di certificazione può adottare diverse politiche. Una CA seria dovrebbe accertarsi dell'identità delle persone che posseggono le chiavi che si devono autenticare, cioè verificare che la chiave pubblica di Alice sia veramente di Alice e non di Trudy. Molte CA, al contrario, si accontentano di autocertificazioni on-line e di una verifica di possesso di un indirizzo e-mail valido: si tratta di una mancanza, nella legislazione, di procedure standard di verifica dei dati, fatto che rende tutto il sistema dei certificati digitali meno affidabile.

Utenti dei certificati

Chi usa certificati X.509 di solito sono server che implementano protocolli come:

• SSL/TLS;
• IPSec;
• EAP in varie forme;
• S/MIME;
• ...

Altri utenti possono essere dei calcolatori che vogliono usare crittografia asimmetrica per le proprie comunicazioni, come i collegamenti STS.

La sicurezza dei certificati digitali non deve essere migliorata con crittografia aggiuntiva, perché devono essere fruibili da tutti in chiaro: tutta la loro sicurezza risiede nella firma della CA e nell'algoritmo MDC usato per calcolare il digest firmato dalla CA.

Tutti i certificati creati da una CA restano validi anche se la chiave privata del CA viene perduta: il problema principale, in quel caso, sarà che non potranno più essere generate le liste di revoca e non potranno essere emessi nuovi certificati, almeno non con il certificato installato nei calcolatori degli utenti di tutto il mondo. Inoltre, anche se la chiave privata di una CA viene rubata, tutte le comunicazioni protette con i certificati firmati dalla CA resteranno comunque protette, indipendentemente. Infatti, la protezione della privacy non viene influenzata dai certificati, che hanno l'unico scopo di autenticare le chiavi che, di norma, vengono scaricate e scambiate attraverso internet, un canale ritenuto insicuro per definizione.

Collegamenti esterni

• Pagina di download di Mozilla Firefox (8/12/2008 verificato funzionante)
• Standard ITU-T X.509 (in inglese) (8/12/200 verificato funzionante)
• Sito della root CA anarchica dell'Università degli studi di Brescia, con istruzioni per l'installazione dei certificato autofirmato (8/12/2008 verificato funzionante)
• Esempio di certificato di root CA da installare (8/12/2008 verificato funzionante)