La Public Key Infrastructure

(scritto da Alessandro Tani e Iarno Pagliani )

Col termine Public Key Infrastructure, o più brevemente PKI, s'intende un sistema composto logicamente dai seguenti componeneti:

Digital Certificates (ovvero chiavi pubbliche firmate digitalmente);
Certification Authorities (o più brevemente CA);
Certificate Revocation Lists (o più brevemente CRL);

Un'infrastruttura di PKI permette di rendere sicure le seguenti operazioni:

L'invio e la ricezione di e-mail.
Secure Web Comunication. I server che offrono servizi Internet, come ad esempio i server di posta elettronica, possono autenticare i client (usando i certificati digitali dei client) e fornire comunicazioni confidenziali e criptate (utilizzando i certificati digitali del server).
Secure Web Site. I siti Web possono utilizzare i certificati dei client per autenticare gli utenti e per controllare i loro diritti e permessi per accedere alle risorse dei siti Web.
Digital Signing of Software Files.
Local Network Smart Card Authentication. Il processo di logon via Kerberos può far uso dei certificati digitali e delle chiavi private imagazzinate in una Smart Card per autenticare un utente di rete quando questi tenta di fare logon.
Remote Access Smart Card Authentication. I server che eseguono il Routing and Remote Access Services possono utilizzare i certificati e le chiavi private imagazzinate nelle Smart Card per autenticare gli utenti di rete quando questi eseguono il logon.
IPSec Authentication.
Encrypting File System Recovery Agent.
EAP-TLS Computer Authentication. Attraverso il protocollo EAP-TLS risulta possibile stabilire quali postazioni di lavoro possono accedere o meno ad una rete.

Alla base del concetto di PKI, c'è il processo di criptazione denominato Crittografia a Chiave Pubblica. Questo processo di criptazione verte sull'idea di creare una coppia univoca di chiavi pubbliche e private. La chiave pubblica va resa nota al maggior numero possibile di persone (o sistemi), mentre la chiave privata, deve essere assolutamente confidenziale, nota solamente al proprietario della chiave privata. Affinchè però il sistema funzioni, si deve avere la ragionevole certezza che la chiave pubblica che si sta tentando di utilizzare sia effettivamente la chiave pubblica della persona o dell'applicazione con cui si desidera comunicare in modo sicuro. Per garantire questa ragionevole certezza, entrambe le parti, sia chi fornisce la chiave pubblica sia chi la utilizza, convengono di affidarsi ad una terza parte, la Certification Authority (o più brevemente CA), la quale ha il compito di garantire che la chiave pubblica affidata alla tale persona o alla tale applicazione sia effettivamente la chiave pubblica di quella persona o di quell'applicazione. Per stabilire questa garanzia, la CA provvede ad apporre, sulla chiave pubblica, un suo sigillo, od in altri termini, a firmare digitalmente la chiave pubblica. In questo modo, le parti coinvolte nel processo di comunicazione sicura, saranno in grado di individuare il sigillo della CA e quindi di avere una ragionevole fiducia che la chiave pubblica sia effettivamente autentica. Una chiave pubblica che è stata firmata digitalmente, prende il nome di certificato digitale. Ad ogni CA corrisponde uno ed uno solo sigillo e per ogni CA non ci possono essere due sigilli identici. Il sigillo, altri non è che la chiave privata della CA stessa.

Gli algoritmi con cui possono venire generate le coppie di chiavi pubblico/private, devono garantire la fondatezza delle seguenti due affermazioni:

nota la chiave pubblica, non si può risalire da questa alla chiave privata e viceversa;
cifrando un messaggio (o flusso di dati) con una soltando delle due chiavi, solamente l'altra chiave è in grado di decifrarlo.

Quando almeno una delle due affermazioni di sopra non è più vera, si dice che l'algoritmo di criptazione è stato violato e pertanto i certificati digitali basati su tale algoritmo non sono più validi. I certificati digitali che non sono più validi devono venire inseriti in una apposita lista chiamata Certificate Revocation Lists (o più brevemente CRL). Le CRL, affinchè siano utili, devono essere rese pubbliche, ovvero consultabili facilmente da coloro che voglio assicurarsi che un dato certificato digitale sia ancora valido. Da qualche anno, è stato reso disponibile un apposito protocollo, lo Online Certificate Status Protocol (o più brevemente OCSP), per facilitare la consultazione delle CRL (l'implementazione del protocollo OCSP non sarà oggetto di questo articolo). Uno degli algoritmi più utilizzati per generare le coppie di chivi pubbliche/private è l'algoritmo di Ron Rivest, Adi Shamir, e Leonard Adleman (RSA), pubblicato nel 1977 al MIT.

Ad ogni CA resta associata una coppia univoca di chiavi pubbliche/private. Questa coppia di chiavi pubblico/private, viene utilizzata per firmare digitalmente i certificati garantiti dalla Certification Authority (si osservi che il compito principale ci una CA, non è fornire le coppie di chiavi pubblico/private, ma di garantire l'autenticità delle chiavi pubbliche, fermo restando che una CA, è anche in grado di realizzare le coppie di chiavi pubblico/private). Col termine firmare digitalmente s'intende una procedura matematica di criptazione con la quale le chiavi pubbliche vengono criptate con la chiave privata di una data CA. Sfruttando la chiave pubblica della CA risulta possibile decriptare il certificato digitale, in questo modo si ha la certezza che la chiave pubblica è stata criptata e quindi garantita da quella CA.

Per Digital Certificates (Certificato Digitale) intenderemo tutte quelle chiavi pubbliche che sono state firmate digitalmente da una Certification Authority. All'interno di un certificato digitale vengono poi inserite una serie di informazioni cha hanno il compito di chiarire i seguenti aspetti:

qual'è stata la CA che ha generato il certificato digitale;
come è fatta la chiave pubblica da cui il certificato digitale ha avuto origine;
qual'è l'utilizzo che se ne deve fare del certificato digitale;
dove reperire la CRL che corrisponde alla CA che ha rilasciato il certificato digitale.

Per stabilire come le informazioni di sopra debbano venire inserite all'interno di un certificato digitale, sono state create delle opportune regole internazionali, queste regole vanno sotto il nome di ITU-T Recommendation X.509. Al momento in cui questo articolo viene scritto, esistono tre versioni di possibili certificati digitali, a seconda del tipo di informazioni che ciascun certificato contiene. Per scelta degli autori, in questo articolo verranno esposti solamente certificati conformi alla terza versione.

Grazie all'utilizzo delle chiavi pubblico/private e di opportuni algoritmi di criptazione a chiave simmetrica, denominati Hash Funtions, risulta possibile criptare in modo sicuro o un flusso di dati (streaming) o un file. Gli Hash Funtions sono particolari procedure matematiche che consentono di rendere inalterabile un flusso di dati o il contenuto di un file. Per raggiungere questo livello di affidabilità, il flusso di dati o il contenuto del file vengono opportunamente criptati secondo delle opportune procedure matematiche, il risultato di questa procedura di criptazione prendere il nome di Message Digest. Ad ogni flusso di dati o ad ogni file criptato corrisponde uno e uno solo Message Digest, pertanto i Message Digest sono in corrispondenza biunivoca con i documenti originali da cui il Message Digest ha avuto origine. Questo fa in modo che se qualcuno o qualcosa tenta di alterare il documento originale (sia esso un file od un flusso di dati), il Message Digest risultante è completamente diverso da quello che si è ottenuto in precedenza dal documento originale stesso! In questo modo si può comprendere se un documento originale è stato manipolato o meno. Due fra i più usati Hash Funtions sono: Message Digest 5 (MD5) e Secure Hash Algorithm-1 (SHA-1).

Viene chiamato Cryptographic Service Provider (o più brevemente CSP) quel software che si preoccupa di generare la coppia chiave pubblica e chiave privata che vengono utilizzate dalle varie Certification Authorities. Nel nostro caso, il CSP sarà il programma OpenSSL che si trova all'interno di una distribuzione Debian (Etch).

Le CA hanno il compito di garantire che le coppie chiavi pubbliche e chiavi private affidate alle persone, o ai computer o a delle applicazioni siano affidabili ed autentiche. Le chiavi pubbliche vengono rilasciate sotto forma di certificato digitale e rese disponibili a tutti. Per assolvere questo compito, le CA vengono inseriti all'interno di un'apposita struttura gerarchica. Il legame che lega, ciascuna CA di una medesima struttura gerarchica, è la fiducia, ovvero le CA che si trovano nella parte più bassa della gerachia credono alle CA che si trovano nella parte più alta della gerarchia. La struttura di fiducia a cui le CA danno luogo è di tipo piramidale, ed in cima a questa piramide c'è la Root Certification Authority (o più brevemente Root CA). La Root CA è una CA che crede a se stessa, ovvero la coppia di chiavi pubbliche/private, che corrisponde alla Root CA, viene utilizzata per firmare digitalmente la chiave pubblica della CA stessa (self-signed certificate). Il legame di fiducia si manifesta nel fatto che le CA che si trovano nei livelli più bassi della scala gerarchica utilizzano coppie di chiavi pubbliche/private generate dalle CA che si trovano nel livello gerarchico immediatamente superiore al proprio. Per semplicità, comunque, non vengono generate strutture gerarchiche con più di tre livelli: al primo livello si trova la sola Root CA, nel secondo livello si trovano le Certification Policy Certification Authority (o più brevemente Policy CA), nel terza livello invece si trovano le Issuing Certification Authority (o più brevemente Issuing CA). Lo scopo della Root CA è quello di firmare (ed eventualmente fornire) le chiavi pubbliche a tutte le CA che compongono il secondo livello, ovvero le Policy CA. Compito delle Policy CA è quello di firmare (ed eventualmente fornire) le chiavi pubbliche a tutte le CA che compongono il terzo livello, ovvero le Issuing CA. Compito delle Issuing CA è quello di firmare (ed eventualmente fornire) le chiavi pubbliche degli utenti, dei computer o delle applicazioni.

Ma perchè realizzare una simile struttura di CA? Lo scopo ultimo di una simile infrastruttura è la sicurezza e l'affidabilità dei certificati digitali delle Issuing CA, tenendo presente che quest'ultime possono venire compromesse! Infatti, in una simile struttura gerarchica, la Root CA e le Policy CA non vengono minimamente coinvolte nel processo di rilascio dei certificati digitali da parte delle Issuing CA, per cui possono venire tranquillamente spente! Come si sà, una macchina spenta e scollegata dalla rete, gode del maggiore livello di sicurezza possibile contro le manomissioni da parte delle persone maleintenzionate. Inoltre, qualora una delle Issuing CA venisse compromessa, solamente i certificati digitali rilasciati da questa CA sarebbero da revocare, mentre l'intera archiettura sarebbe ancora valida, cioè le Root CA e le Policy CA non risulterebbero in alcun modo compromesse (erano spente!).

A livello pratico, si creano di solito strutture di CA a due livelli (composti solamente dalla Root CA e dalle Issuing CA), il terzo livello viene creato solamente se l'infrastruttura PKI di cui si ha bisogno è molto estesa a livello geografico. Si pensi ad esempio ad una multi-nazionale che ha sedi in diverse nazioni e che per ciascuna nazione esistono diverse sedi assai affollate di personale. Se questa azienda dovesse dotarsi di una infrastruttura PKI, potrebbe scegliere di procedere come segue:

La Root CA viene creata all'interno della rete della sede principale dell'azienda.
Per ciascuna nazione, viene creata una Policy CA.
Per ciascuna sede all'interno della stessa nazione, viene creata una Issuing CA.

Prende il nome di Certificate Signing Request la procedura con cui una CA genera la chiave pubblica che poi dovrà venire firmata digitalmente (ovviamente a questa chiave pubblica resterà associata, in modo univoco, una chiave privata).

Esistono infine, due formati con cui vengono creati i file che contengono le chiavi pubbliche e private. Il formato PEM ed il formato DER. Questi due formati sono molto simili, l'unica differenza è che nel formato PEM esiste una stringa di caratteri (tipicamente del tipo "-----BEGIN CERTIFICATE REQUEST-----" e "-----END CERTIFICATE REQUEST-----" o simili), denominata intestazione, con la quale viene identificata la parte del file che contiene o la chiave pubblica o la chiave privata. Nel formato DER queste stringhe di testo non esistono. Il formato PEM è il formato di default utilizzato dal programma OpenSSL.

Per maggiori informazioni sui certificati digitali e sulle infrastrutture PKI, si possono consultare i seguenti siti o documenti:

mentel

La Public Key Infrastructure