Sebbene la crittografia a chiave pubblica risolva molti dei problemi legati all’utilizzo della crittografia e dell’autenticazione in ambienti aperti, rimangono ancora molte questioni da definire.

La questione più delicata riguarda la gestione e la diffusione delle chiavi pubbliche.

Per evitare il rischio che un impostore spacci la propria chiave pubblica per quella di una persona con cui si è interessati ad interagire, è necessario disporre di un meccanismo che consenta il reperimento delle chiavi pubbliche in modo sicuro, e consenta di sapere a chi è associata una determinata chiave pubblica in modo inequivocabile.

Questo compito è svolto da opportuni enti certificatori che vanno sotto il nome di Certification Authority (CA), i quali si occupano di verificare la validità delle chiavi pubbliche e la loro effettiva appartenenza a persone o entità riconosciute.

Il risultato di queste verifiche è il certificato di chiave pubblica, un documento digitale che lega una chiave pubblica ad una persona o entità, e ne testimonia la validità sotto la responsabilità della Certification Authority (CA), che firma elettronicamente il certificato in questione per garantirlo.

Altra questione non secondaria è quella della definizione di un insieme di standard di base che consenta l’interoperabilità delle diverse implementazioni delle tecniche di crittografia a chiave pubblica.

Senza tali standard i vantaggi della crittografia a chiave pubblica sarebbero vanificati da strutture proprietarie e intrinsecamente chiuse.

Si rende dunque necessaria la definizione Public Key Infrastructure (PKI), ossia di un’infrastruttura che consiste di protocolli, servizi e standard che supportano applicazioni di crittografia a chiave pubblica.

Le PKI definiscono, ad esempio, gli standard per la struttura dei certificati di chiave pubblica, le procedure di sicurezza per il trattamento delle chiavi private, la struttura delle richieste per l’emissione di certificati di chiave pubblica da parte della CA, e molti altri aspetti per l’implementazione di sistemi di sicurezza.

L’obbiettivo è la creazione di un contesto che garantisca la massima interoperabilità delle diverse soluzioni che è possibile adottare.

E’ noto che una chiave pubblica è intimamente legata alla sua corrispondente chiave privata; ma la sola conoscenza della chiave pubblica non fornisce nessuna informazione su chi sia il detentore della chiave privata corrispondente. E’ necessario dunque un meccanismo che leghi univocamente una chiave pubblica all’identità dell’individuo o dell’entità in possesso della corrispondente chiave privata.

La soluzione utilizzata nell’ambito delle PKI è l’uso dei certificati digitali di chiave pubblica.

Un certificato è un documento elettronico, rilasciato ad una persona o ad un ente, che contiene:

Il documento nel suo complesso verrà firmato digitalmente con la chiave privata dell’ente certificatore (CA); la firma digitale ne garantirà l’autenticità e l’integrità, ossia ne impedirà l’alterazione o la manomissione.

L’utilizzo dei certificati di chiave pubblica anziché di chiavi pubbliche pure e semplici presenta diversi vantaggi:

Il formato del certificato con cui si lavora è l’X.509, che è lo standard alla base dell’intera struttura delle PKI, ed è dettagliatamente codificato e formalizzato.

I certificati digitali associano una chiave pubblica ad una identità e ad una serie di informazioni sul detentore delle chiave pubblica. A volte però alcune informazioni espressamente indicate nel certificato non devono essere usate al di fuori del contesto opportuno.

Si preferisce allora utilizzare, quando necessario, diversi certificati, associati alla stessa chiave pubblica, ma contenenti di volta in volta informazioni specifiche ad un preciso contesto.

Questo meccanismo consente di utilizzare sempre la stessa coppia di chiavi, ed allo stesso tempo certifica solo le informazioni rilevanti all’uso specifico che di quel certificato si deve fare, e questo fornisce una forma di protezione della privacy personale.

Le Certification Authorities (CA) sono gli enti che verificano e garantiscono l’associazione tra la chiave pubblica di una persona o di un ente e la sua identità, e provvedono ad emettere un opportuno certificato digitale.

Il loro ruolo è centrale nello sviluppo delle PKI, dunque si è posta molta attenzione nella definizione dei compiti e dei requisiti di sicurezza che una CA deve rispettare. Il mancato rispetto di questi requisiti creerebbe dei gravi problemi per l’intera struttura.

I compiti che una CA è tenuta a svolgere sono:

Il procedimento che porta alla emissione di un certificato prevede che l’utente interessato all’ottenimento del certificato generi autonomamente la propria coppia di chiavi, e sottoponga poi la sua chiave pubblica alla valutazione della CA.

La scelta di rendere la generazione delle chiavi dell’utente autonoma garantisce una minore esposizione della chiave privata, che non è costretta ad essere trasmessa in nessun modo, ma anzi viene generata localmente, e riduce dunque il rischio di intercettazioni.

La richiesta di certificazione (Certification Request) viene generata dall’utente secondo degli opportuni standard (PKCS #10) e presentata alla CA.

Il compito di una CA è quello di accertarsi che:

La CA può verificare che il soggetto in questione possieda la chiave privata associata alla chiave pubblica da certificare verificando la firma elettronica apposta dal soggetto alla richiesta di certificazione stessa: se il certificato, firmato con la chiave privata del soggetto, è verificato dalla chiave pubblica sottoposta alla CA non c’è possibilità di errore.

La valutazione dei dati di identificazione è invece un processo più complesso, che può articolarsi in molte procedure e può richiedere a volte che il soggetto richiedente si presenti di persona per le verifiche opportune. Il grado di impegno richiesto varia a seconda dei casi e può a volte essere svolto automaticamente attraverso una serie di controlli incrociati da parte della CA sui dati forniti.

I certificati di chiave pubblica emessi portano con sé la firma della CA, quindi qualunque sia il mezzo, anche insicuro, attraverso cui essi pervengono ad un potenziale utilizzatore, la loro validità può essere sempre verificata con certezza, a patto che l’utilizzatore disponga del certificato della CA.

E’ tuttavia opportuno che la CA renda disponibile pubblicamente un database contenente tutti i certificati emessi nel corso della sua attività, per facilitarne il reperimento.

L’implementazione di questo servizio avviene tramite l’uso di database relazionali consultabili tramite il protocollo LDAP (Lightweight Directory Access Protocol). Questo protocollo di interrogazione dei servizi di directory consente una facile consultazione del database e snellisce le procedure di cifratura e verifica della firma per i client di crittografia.

Ciascun certificato pubblico ha un suo periodo di validità, specificato in opportuno attributo del certificato stesso. Al momento della verifica del certificato può dunque essere facilmente controllato, oltre alla firma della CA, se il certificato sia scaduto o meno.

A volte tuttavia è necessario revocare il certificato prima della sua data di scadenza naturale. Questo può rendersi necessario quando venga persa o compromessa la chiave privata corrispondente, quando vengano meno le condizioni che sono specificate nel certificato, o per diversi altri motivi.

C’è bisogno dunque di un meccanismo che impedisca al certificato stesso, che risulterebbe ancora correttamente firmato e non scaduto, di essere utilizzato da allora in avanti.

Per risolvere questo problema la CA crea periodicamente delle liste contenenti tutti i certificati che sono stati revocati tra quelli da lei emessi.

Le liste di revoca dei certificati (Certificate Revocation List - CRL) non sono altro che delle liste di serial-number, ciascuno corrispondente ad un certificato emesso precedentemente ed ora revocato; la lista è poi firmata dalla CA stessa per garantirne l’autenticità e l’integrità.

Il compito di verificare che un certificato non sia stato revocato ricade dunque interamente su chi si appresta a farne uso: egli deve dunque verificare la firma apposta al certificato, che il certificato non sia scaduto e che il certificato non sia stato revocato.

Le CRL vengono generate, gestite e pubblicate periodicamente dalla CA. Poiché sono formattate nello stesso formato dei certificati di chiave pubblica (Standard X.509) la loro diffusione e le modalità di utilizzo possono essere condivise, e questa rappresenta una grande semplificazione nella loro gestione.

La pubblicazione periodica delle CRL pone dei problemi di non secondaria importanza:

La soluzione che si va delineando è nella validazione on-line dei certificati, per quanto possibile. Questa scelta consente un maggior livello di sicurezza circa la validità dei certificati.

Per migliorare la gestione dei certificati è previsto che venga creata una rete di CA organizzata gerarchicamente; ciò consente una maggiore flessibilità e rapidità nella emissione dei certificati.

Una CA può decidere di demandare parte dei suoi compiti ad una o più CA da lei autorizzate, e lasciare che queste ultime si occupino della raccolta delle richieste di certificazione, della validazione dei dati di identità forniti e della emissione stessa del certificato.

Per implementare questo processo di delega è sufficiente che la CA principale (root CA) emetta un certificato di chiave pubblica per la CA sussidiaria (sub-CA) che la autorizza a firmare a sua volta altri certificati. I dettagli di questa implementazione vanno ricercati nello standard X.509, standard utilizzato per tutti i certificati di chiave pubblica, che prevede un attributo apposito per autorizzare l’emissione di certificati, e consente alla Root CA di aggiungere specifiche condizioni (constraints) sul tipo di certificati che la sub-CA è autorizzata ad emettere.

La delega di alcuni processi di certificazione ad una sub-CA consente un controllo più semplice sui dati da verificare, e dunque una maggiore rapidità nella verifica e nella emissione dei certificati.

Nella definizione di una rete di CA vanno prese in considerazione due esigenze contrastanti:

La definizione della topologia della PKI è dunque estremamente delicata, e va studiata caso per caso, senza sottovalutare l’impegno che la gestione di una CA comporta.

I suoi aspetti principali sono:

La Certification Practice Statement (CPS) è, di fatto, il documento che specifica le modalità secondo cui vengono raccolte le richieste di certificazione a seconda del tipo di certificato rilasciato e del livello di affidabilità che si vuole garantire nell’identificazione.

Dall’accuratezza delle verifiche e dalla affidabilità dei documenti forniti è possibile valutare la bontà del processo di certificazione.

La compromissione delle chiavi della CA è estremamente dannosa, in quanto dal momento della revoca della chiave pubblica della CA

Operazioni, queste, molto costose e rischiose.

La CA, come tutti gli utenti di un sistema di crittografia, è soggetta a due tipi di attacchi alla sua sicurezza: un attacco di tipo critto-analitico, ed un attacco mirato al recupero diretto della chiave privata se non opportunamente custodita.

In alcuni casi si preferisce addirittura isolare fisicamente il server dalla rete, e farlo lavorare solo off-line, per prevenire rischi di intrusione.

In questo contesto vengono introdotte le cosiddette Registration Authorities (RA), ossia delle entità che si occupano di raccogliere le richieste di certificato, di verificare la validità dei dati forniti e passano poi i documente al server CA off-line per la sola firma dei certificati. Questo garantisce un maggior livello di sicurezza al prezzo di tempi più lunghi e procedure non del tutto automatiche

Non da ultimo va considerata la protezione del sistema da possibili danneggiamenti all’hardware, o da improvvisi black-out di corrente che potrebbero compromettere i dati memorizzati. Vista l’estrema importanza dei dati trattati tutte le precauzioni vanno considerate.

Lo standard X.509 è lo standard che governa nel dettaglio la struttura di un certificato digitale.

Esso consente di associare un nome identificativo di una persona o di una identità alla sua chiave pubblica. Il nome identificativo è detto Distinguished Name (DN), ed è una raccolta di informazioni molto articolata che serve ad identificare la persona o l’ente in modo univoco.

Alcuni tra i parametri più importanti per identificare la persona o l’ente a cui assegnare il certificato sono:

Le regole per stabilire esattamente quali campi devono essere usati, e cosa devono contenere, dipendono dalla politica dell'autorità che deve firmare il certificato.

Un certificato X.509 contiene inoltre delle informazioni sulle proprietà del certificato stesso:

X.509 fu proposto nel 1988 come strumento di supporto per l’autenticazione dei servizi di directory X.500; sia X.509 che X.500 fanno parte di una serie di standard sostenuti dall’ISO e dall’ITU per la diffusione di servizi di directory su reti di computer.

Il protocollo ha conosciuto diverse versioni, e oggi è universalmente accettato l’uso della versione 3 (X.509v3); rispetto alla versione 2 sono stati fatti molti passi in avanti soprattutto per quanto riguarda la flessibilità e l’estensibilità di questo standard.

Pkcs è l’acronimo di Public Key Cryptography Standards, ed è un insieme di proposte il cui scopo è quello di garantire l’interoperabilità tra diverse implementazioni degli algoritmi di crittografia.

Questi standard sono stati proposti inizialmente da RSA Security Inc.,società leader nel settore della crittografia a chiave pubblica e punto di riferimento del mercato, e da un consorzio costituito originariamente da Apple, Digital, Lotus, Sun e Novell.

Gli standard Pkcs risalgono al giugno 1991, e sono ormai il punto di riferimento nello sviluppo di applicazioni di crittografia.

Il loro utilizzo è stato incorporato in molti standard di mercato come ad esempio nell’X.509, e in S/MIME, il protocollo per lo scambio di posta elettronica sicura, e governano la codifica di molti aspetti chiave delle PKI.

Gli standard PKCS vengono indicati con un numero progressivo: Pkcs#1, #2, #3, etc.; si occupano della metodologia di cifratura RSA, della sintassi dei certificati estesi e della chiave privata, di alcune API per smart card, e di una sintassi di trasferimento di informazioni private (chiavi private, certificati e certificati estesi).

Vediamo alcuni dei Pkcs che più utilizzeremo:

Lo standard Pkcs#1 descrive nei dettagli come generare la coppia di chiavi pubbliche/private, definisce la sintassi per le chiavi pubbliche e private, introduce tre algoritmi di firma digitale impiegabili nei certificati X.509, e descrive dettagliatamente il processo di cifratura RSA.

Lo standard Pkcs#7 specifica la sintassi da applicare ad “oggetti” risultato di operazioni di firma o crittografia. Il suo utilizzo è alla base della struttura dei certificati X.509, e questo ne fa un punto di riferimento fondamentale.

La sua struttura è ricorsiva, ciò significa che un oggetto in formato Pkcs #7 può essere contenuto in un altro oggetto nello stesso formato.

La codifica binaria è di tipo BER, cioè i valori sono rappresentati come “octet strings”, questo rende Pkcs#7 vulnerabile a problemi di codifica su sistemi che non supportano i caratteri estesi; si preferisce dunque usarlo in combinazione con strutture MIME che prevengono questi problemi.

Lo standard Pkcs#8 definisce i criteri per il salvataggio della chiave privata. Per non mettere a repentaglio la sicurezza della chiave privata non basta conservarla in un posto sicuro, è necessario prendere ulteriori precauzioni. Il PKCS #8 prescrive l’utilizzo di un algoritmo di crittografia simmetrico per salvare la chiave privata in forma cifrata e protetta da una Password (o PIN). Solo introducendo il PIN corretto la chiave sarà decodificata e sarà utilizzabile.

Lo standard Pkcs#10 tratta della sintassi per la richiesta di un certificato(Certificate Request). Tale richiesta consiste di un identificatore, una chiave pubblica e, volendo, di un insieme di attributi. La richiesta viene trasmessa ad una autorità di certificazione che la trasforma in un certificato X.509.

Lo standard Pkcs#11 che descrive delle Api, chiamate Cryptoki, per accedere alle smart-card e sfruttarne le funzionalità. Tali Api permettono di ottenere l'indipendenza dai dettagli tecnologici del dispositivo crittografico, presentando alle applicazioni un'unica entità, corrispondente al dispositivo (cryptographic token).

E’ opportuno sottolineare che gli standard Pkcs lasciano la più completa libertà nella implementazione proprietaria degli algoritmi di crittografia; vengono in questo contesto definite solo le regole sintattiche e di formattazione degli oggetti risultanti da operazioni di crittografia, ma non le modalità con cui tali oggetti sono generati (purchè in accordo con gli algoritmi in questione).