I Certificati digitali

I Certificati digitali

Nella trattazione della firma digitale abbiamo messo in evidenza l'importanza della chiave e della sua protezione. Un altro aspetto fondamentale è che la chiave pubblica, necessaria alla verifica, sia autentica. Una soluzione a questo problema è rappresentato dai certificati digitali.

I certificati digitali legano tra loro una chiave pubblica ad un particolare identificatore di persona o ente, e rappresentano la garanzia, fornita da terze parti, che questo legame è autentico. Le terze parti a cui si fa riferimento sono particolari autorità dette Certification Authority, il cui scopo è quello di garantire l'affidabilità di una chiave di un certo ente o persona. L'affidabilità della chiave per essere garantita deve sottostare a rigidissime regole di scurezza e integrità. In Figura 2‑ riportiamo lo schema di principio per la costruzione di un certificato firmato con la chiave privata corrispondente alla chiave pubblica certificata:

Figura : Modello di creazione di un certificato - tratto da [11]

Le due autorità di certificazione più note sono Verisign e Thawte. Queste sono le autorità di certificazione che maggiormente sono presenti sul mercato delle certificazioni. Le autorità di certificazioni sono enti di rilascio di certificati riconosciute da tutti i maggiori sistemi operativi e enti per la sicurezza. La loro notorietà e affidabilità fa in modo che una firma con la loro chiave privata, posta su un certificato di una persona o di un ente sia sufficiente per garantire l'affidabilità su quanto dichiarato dal certificato stesso.

Per quanto riguarda il contenuto dei certificati, oltre alla chiave pubblica, sono presenti informazioni sulla persona o ente possessore dello stesso e sull'ente che lo ha rilasciato. Le principali caratteristiche di un certificato sono appunto le identità del possessore e di chi lo ha rilasciato e firmato ma anche la data di rilascio e di validità. Infatti un certificato ha una validità di durata limitata, oltre la quale non è più considerato valido.

I certificati in genere sono di vario tipo a seconda dell'utilizzo a cui sono destinati; i certificati di tipo X.509 sono i più diffusi. Lo standard X.509 definisce un'architettura di riferimento per l'erogazione di servizi di autenticazione da parte della directory X.500 ai suoi utenti [18].

La directory, in linea di principio, è un server o un insieme distribuito di server, che mantengono una base di dati contente informazioni sugli utenti, tra cui quelle relative alla corrispondenza tra nomi utente e indirizzi di rete. La directory può essere utilizzata come deposito di certificati a chiave pubblica. Ciascun certificato contiene la chiave pubblica di un utente ed è firmato con la chiave privata di un'autorità di certificazione fidata[1], oppure con la chiave privata dell'utente stesso .

L'importanza di questo standard è dovuta al fatto che la struttura dei certificati e dei protocolli definiti in X.509 sono utilizzati in tantissimi contesti.

Lo standard X.509 si basa sull'utilizzo della crittografia a chiave pubblica e delle firme digitali. Lo standard non impone l'utilizzo di un algoritmo di cifratura particolare anche se viene raccomandato l'RSA[3]. Per quanto riguarda la firma digitale si ipotizza l'utilizzo di una funzione di hash, anche se lo standard non ne consiglia una specifica.

In questi certificati sono contenute informazioni personali del possessore, tra cui il nome, cognome, ente di cui fa parte il possessore, la sua chiave pubblica e la data di emissione e relativa durata di validità del certificato stesso, oltre ai parametri relativi alla Certification Authority, che lo ha autenticato con la propria firma digitale. La validità di un certificato può dipendere da molti fattori, tra cui la lunghezza della chiave utilizzata per firmare il documento e soprattutto quanto il possessore lo intende pagare.

Siccome ottenere un certificato da parte di queste Certification Authority è molto costoso, spesso si ricorre a delle tecniche limitative ma più veloci e meno costose: l'autocertificazione. Questa soluzione risulta parecchio limitativa, infatti un certificato autofirmato non è riconosciuto come fidato, in quanto manca la firma della Certification Authority; infatti nel processo di verifica di una catena di certificati è importante che a monte della stessa ci sia un certificato definito root, considerato trusted, che abbia firmato il proprio certificato e quello di livello più alto all'interno della catena.

Di seguito viene riportato uno schema che specifica i campi contenuti in un certificato X.509 con le rispettive versioni:

Figura : Contenuto di un certificato X509 - tratta da [18]

Le catene di certificazioni

Come si è potuto capire da quanto scritto finora, un certificato sostanzialmente convalida una chiave pubblica mezzo di una firma di un'autorità riconosciuta attendibile e fidata. Questo procedimento è facilmente estendibile a più certificati creando una catena di certificati[4].

Ogni autorità di certificazione presenta un proprio certificato, il root, con il quale certifica gli altri certificati. Quindi un'autorità nota, come ad esempio Verisign, può utilizzare il certificato root per convalidare il certificato di un altro ente che fornisce alcuni servizi tra cui la convalida di certificati privati dei singoli utenti. È importante tener presente che nel processo di verifica, ogni certificato della catena, ad eccezione del certificato dell'utente, è stato utilizzato come autorità di certificazione.

Figura : Catena di certificati dal root all'utente finale

Tra le caratteristiche di un certificato, oltre a quelle specificate in precedenza, c'è la tipologia del certificato, ossia se il certificato può essere utilizzato per l'e-mail, per certificare nuovi certificati, ed altri, oppure se può convalidare una chiave pubblica. In un certificato X.509, a partire dalla seconda versione, sono state inserite delle estensioni che specificano ciò per cui un certificato può essere utilizzato e per cosa non può essere usato.

La concatenazione dei certificati è molto utile per la gestione degli stessi, in quanto è possibile specializzare le funzioni di ogni certificato.

Lista di revoca dei certificati

La scadenza del termine di validità non è l'unica causa per cui un certificato non è più considerato valido. Le cause della perdita dell'affidabilità di un certificato possono essere molteplici; alcune di queste possono riguardare la chiave privata associata alla chiave pubblica certificata, oppure a scelte della autorità di certificazione, oppure alla terminazione di rapporto di collaborazione tra enti, e tante altre ancora.

Al di là di quale sia la motivazione, una certification authority può avere la necessità di revocare la validità ad un certificato. Questo compito viene svolto dai Certificate Revocation List, CRL, che non sono altro che un elenco di numeri di serie di certificati revocati dall'autorità di certificazione. I CRL sono propri di ogni autorità di certificazione, e sono scaricabili dai siti delle rispettive autorità, quindi un certificato rilasciato da una certa autorità X, non sarà mai presente all'interno di una CRL di un'altra autorità di rilascio Y. Se un certificato non è presente all'interno di queste liste e non è ancora scaduto, è da considerare valido. Un certificato presente nella CRL ci rimarrà fino alla scadenza dello stesso. Sfortunatamente, il controllo di queste liste non è una prassi comune per le applicazioni che gestiscono i certificati.

Il contenuto di una CRL è riportata in Figura 2‑ :

Figura : contenuto dei CRL - tratta da [18]

I certificati in Java

Nel JDK sono presenti tre classi molto importanti per la gestione dei certificati, tutte poste nel package java.security.cert. Queste tre classi sono le seguenti:

java.security.cert.Certificate: è una classe astratta per la gestione di una varietà di certificati. Questa classe è un'astrazione per i certificati che hanno formati differenti ma ugualmente di uso comune. Per esempio i certificati in formato X.509 e PGP sono differenti, ma possono contenere alcuni tipi di informazioni comuni come le chiave pubbliche. I metodi con i quali si ha più spesso a che fare sono getPublicKey() getEncoded() e verify(). Il primo dei tre metodi serve per recuperare una chiave pubblica dal certificato, ritornando proprio un oggetto PublicKey. Il secondo metodo permette di ottenere una forma codificata di questo certificato. Questo metodo assume che ogni tipo di certificato abbia una sola forma di codifica. Ad esempio i certificati X.509 potrebbero essere codificati come ASN.1 DER. L'oggetto codificato che ritorna da questo metodo è sotto forma di array di byte. L'ultimo metodo serve invece per effettuare la verifica del certificato ed è necessario che sia passata la chiave pubblica dell'autorità di certificazione che lo ha firmato:

java.security.cert.X509Certificate: è una classe astratta per i certificati X.509. Questa classe rappresenta un modo standard per accedere a tutti gli attributi del certificato. Questi certificati sono istanziati usando un oggetto CertificateFactory. Sono presenti numerosi metodi get che permettono il trattamento di tutte le informazioni contenute nel certificato, come il periodo di validità, il numero di serie e le informazioni del proprietario e di chi lo ha rilasciato.

java.security.certCertificateFactory: questa classe definisce le funzionalità di un costruttore di certificati, necessario per la generazione di un certificato, di una catena di certificazione e di una lista di certificati revocati. Per la conversione, da un file o da un qualunque supporto, in un formato adatto, è necessario utilizzare metodi diversi a seconda che si tratti di un certificato singolo o di una catena di certificati. Per certificati singoli occorre utilizzare il metodo generateCertificate(), mentre per catene di certificati occorre utilizzare generateCertificates(). Quest'ultimo metodo permette di trattare quella che era una catena di certificazione come una collezione di certificati non più strettamente legati. Nel caso in cui si volesse generare una catena di certificazione il metodo da invocare sarà generateCertPath(), mentre nel caso in cui si voglia verificare la validità di una catena di certificati, si dovrà fare affidamento sul metodo CertPathValidator(). Quando si utilizza un oggetto CertificateFactory questo deve ritornare certificati che sono istanze di oggetti X509Certificate oppure deve ritornare CRL che sono istanze di oggetti X509CRL. Se ad esempio volessimo leggere i certificati contenuti in un file, aventi codifica in Base64, in cui ogni certificato deve essere limitato, in testa dalla stringa "----BEGIN CERTIFICATE----" mentre in coda dalla stringa "----END CERTIFICATE----", dovremmo leggere il file come nel seguente esempio:

Per quanto riguarda le catene di certificazione abbiamo detto che vengono gestite in maniera particolare rispetto ad un semplice certificato. Dalla terminologia con cui si identificano in Java, certification path, la classe che le gestisce è presente nel package java.security.cert, con il nome di CertPath

java.security.cert.CertPath: rappresenta una sequenza immutabile di certificati. Questa, come altre classi di questo package, è una classe astratta, e definisce tutti i metodi comuni a tutte le catene di certificazione. Le sue dirette sottoclassi sono classi che specificano particolari tipi di certificati come X509 o PGP. Tutti gli oggetti CertPath sono formati da un tipo, che è una lista di oggetti Certificate ed uno o più codifiche di supporto. Il tipo è un oggetto String, il cui valore identifica il tipo del certificato all'interno della catena. La lista di certificati è una lista ordina di zero o più oggetti Certificate. Le codifiche supportate servono alla traslazione degli oggetti in array di byte necessari per la trasmissione e la memorizzazione degli stessi. Sarebbe opportuno che lo standard di codifica fosse uno di largo consumo e ben noto come potrebbe essere il PKCS#7. Per convenzione, i certification path in formato X.509, che in Java sono rappresentati dagli oggetti della classe X509Certificate, sono ordinati in modo che il primo certificato sia quello dell'utente, mentre l'ultimo deve essere quello rilasciato da un'autorità certificazione, definita in Java, TrustAnchor. Infatti, in una catena, colui che emette un certificato è il proprietario di quello successivo e così via fino al TrustAnchor. Il certificato della TrustAnchor non dovrebbe essere incluso nella catena. Queste, naturalmente, rimangono caratteristiche tipiche di una catena di certificazione considerata valida, perchè per quelle non valide non è detto che siano rispettate. I metodi di questa classe che maggiormente vengono utilizzati sono quelli relativi al recupero di informazioni dei certificati e per il recupero dei certificati da un certo supporto. Quasi tutti questi metodi iniziano con la parola get seguita dall'attributo ritornato, come ad esempio i metodi getEncoding() che restituisce la forma codificata della catena, tramite la codifica di default, oppure getCertificates(), che restituisce la lista di certificati presenti nella catena.

java.security.cert.CertPathValidator: rappresenta il supporto necessario per effettuare il processo di verifica della validità di una catena di certificazione. La struttura di questa classe come quella di moltissime altre è costruita su un'architettura basata su provider, come è la JCA. Per creare un oggetto CertPathValidator, utilizziamo uno dei metodi statici getInstance(), dove a ciascuno di questi passiamo una stringa indicante il nome dell'algoritmo per la validazione che si vuole usare più, eventualmente, il nome del provider. Una volta che è stato creato un oggetto è possibile andare ad effettuare il controllo della validità di una catena invocando il metodo validate(), al quale va passato come input la catena da verificare sotto forma di oggetto CertPath, più un set di parametri di uno specifico algoritmo di validazione. Se il processo di validazione dà buon esito questo metodo ritornerà un oggetto che implementa l'interfaccia CertPathValidatorResult

java.security.cert.CertPathValidatorResult: rappresenta una descrizione dettagliata del processo di validazione di una catena di certificazione. Il suo scopo è quello di raggruppare in un'interfaccia comune tutti i possibili valori di ritorno di un controllo su una catena di certificazione. Questa classe non contiene metodi, serve solo per rappresentare la buona riuscita del controllo della catena.

java.security.cert.PKIXParameters: rappresenta un insieme di parametri, relativi all'algoritmo PKIX, da passare come input al metodo CertPathValidator.validate(). Per creare un oggetto di questo tipo occorre specificare uno o più "most-Trusted CAs", definiti secondo i criteri di validazione dell'algoritmo PKIX. Sono disponibili due tipi di costruttori, a seconda del tipo di parametro passato; è possibile passare come input al costruttore un oggetto Set, inizializzato con oggetti TrustAnchor, ognuno dei quali identifica una delle CA trusted. Un altro modo per costruire un oggetto PKIXParameters è invece quello di passare al costruttore un oggetto Keystore, il quale al suo interno contenga delle entry relativi a certificati trusted, ognuna delle quali rappresenta una CA trusted. Una volta creato un oggetto di questo tipo è possibile settare ulteriori parametri, che altrimenti assumerebbero  valori di default, quindi renderlo parametro di ingresso al metodo validate(), già esaminato.

java.security.cert.TrustAnchor: rappresenta un oggetto che identifica una delle CA considerate trusted. Questo oggetto è utilizzato per validare una catena di certificati X.509. in questo oggetto sono inclusi sia la chiave pubblica che il nome della CA, oltre ad altri parametri.

È nostra intenzione adesso fornire un semplice esempio di utilizzo di queste ultime classi appena descritte :