Le PKI (Public Key Infrastructure) sono, come il nome stesso lascia intuire, delle infrastrutture tecnologiche che consentono di portare a termine la maggior parte delle operazioni che compiamo ogni giorno, soprattutto in Rete, legate all’applicazione di meccanismi di cifratura dei dati.
Per questioni pratiche, la crittografia in uso nella maggior parte dei casi è detta “in chiave pubblica”: questo tipo di cifratura consente a due entità che non si conoscono, come ad esempio il mio computer e un sito web dall’altra parte del mondo, di stabilire una connessione cifrata senza che ci si debba scambiare anticipatamente una chiave di cifratura per proteggere i dati.
Questo è ciò che accade ogni volta che visitiamo un sito protetto da SSL/TLS/HTTPS (secondo l’aspetto che stiamo esaminando), ma come vedremo molte altre attività si basano sul medesimo meccanismo.
In particolare, è utile analizzare il processo di richiesta, creazione e gestione dei certificati digitali che ricoprono un ruolo sostanziale nei processi di crittografia in chiave pubblica che, oltre ai già citati siti web protetti, ci consente molte altre applicazioni.
Indice degli argomenti
PKI e cifratura dei dati: a cosa servono i certificati digitali
Cominciamo quindi con lo specificare che cosa sia un certificato digitale; si tratta semplicemente di un file da pochi kilobytes che contiene un insieme di informazioni codificate secondo uno standard (solitamente X.509). Le similitudini con un certificato cartaceo o tradizionale sono molte, quindi procederemo nella spiegazione evidenziando analogie e differenze tra i due tipi.
Un certificato che tutti conosciamo è la carta d’identità (CI di seguito): ha uno scopo preciso (attestare l’identità di una persona), viene emessa dal Comune di residenza e contiene una serie di informazioni obbligatorie: il suo numero, la data di emissione e quella di scadenza, il nome, la fotografia, l’indirizzo e via dicendo.
Ci sono anche altre informazioni facoltative, come la professione o lo stato coniugale. In questo il certificato digitale è simile, ma la lista delle informazioni che possono comparire è molto più lunga rispetto alla carta d’identità (CI). Soffermiamoci ora su un aspetto fondamentale della CI: perché quando qualcuno ce la presenta noi crediamo a quanto in essa contenuto? Perché ci fidiamo dell’ente che l’ha emessa, nello specifico il Comune, e ci fidiamo del Comune perché a sua volta è emanazione dello Stato. Non conosciamo singolarmente quella specifica CI numero 123456 che abbiamo davanti, ma assumiamo che sia stata rilasciata seguendo le appropriate procedure di identificazione.
Se per certificare l’identità di una persona ci venisse mostrato il tesserino del laghetto di pesca sportiva, ci fideremmo di quello? Dipende dal contesto, magari al laghetto al sabato si, ma in generale la risposta è no. Perché? Semplice, non sappiamo quali procedure segua il laghetto per rilasciare il documento, quindi non ci fidiamo. Il termine fidarsi (to trust) è un cardine essenziale nella gestione dei certificati digitali.
Come accennavamo all’inizio, un certificato digitale nasce all’interno di quella che si chiama PKI (Public Key Infrastructure), un complesso tecnico e amministrativo che svolge essenzialmente due compiti: identificazione dei soggetti, mediante la RA (Registration Authority), e l’emissione dei certificati mediante le CA (Certification Authority).
Così come andiamo in Comune che ci identifica e ci rilascia una CI, allo stesso modo per avere un certificato digitale dobbiamo presentarci alla RA e convincerla che siamo chi diciamo di essere, così che essa possa concedere alla CA il benestare all’emissione del certificato digitale. A questo punto avremo un documento digitale da mostrare a chiunque ce lo chiedesse ad uno scopo preciso: certificare la nostra identità.
Ritorna tuttavia il problema del laghetto di pesca, bisogna che io mi fidi dell’emittente per fidarmi del certificato. Lo stesso avviene per quelli digitali: io mi fido del certificato digitale specifico che mi viene mostrato dal sito (ad esempio) per il fatto che l’emittente è qualcuno di cui mi fido: tecnicamente in questo caso si tratta della CA emittente. Dal punto di vista pratico questa a sua volta è identificata da un certificato emesso da qualcun altro e così a risalire indietro lungo quella che si chiama chain of trust fino al primo livello, detto root of trust. Analogamente alla CI di cui mi fido perché emessa dal Comune e quindi dallo Stato.
Come “leggere” i certificati digitali
Analizziamo l’uso dei certificati digitali nell’accezione più comune oggi, quella in cui sono utilizzati per le comunicazioni sui siti web.
Vediamo un certificato reale, quello del sito Cybersecurity360, ed esaminiamo la sua catena di trust:
Siccome mi fido (meglio, il mio PC si fida) di tutti gli attori della catena, allora riterrò valido almeno il nome presente nel certificato. Qui cominciano le cose da guardare con attenzione, sempre su quel certificato.
- qual è lo scopo di questo certificato, cioè identificare un computer remoto. Vedremo che questo è uno delle decine di scopi possibili. In questo caso ci va bene, visto che l’operazione che sto compiendo è quella di navigare su un sito del quale voglio certificare l’identità;
- il nome a cui è stato rilasciato il certificato, che deve essere lo stesso che ho inserito nel browser;
- la CA emittente, di cui mi devo fidare;
- l’intervallo di validità.
Se tutte queste informazioni sono coerenti con quello che mi aspetto, allora per me (per il mio browser) quel certificato è valido e il sito si guadagna il lucchetto di fianco all’URL nella barra degli indirizzi. In alternativa, comparirà la pagina di errore che conosciamo e che varia per ogni browser.
Attenzione però, c’è qualcosa che non torna in quanto visto sopra: ho chiesto di collegarmi a www.cybersecurity360.it, ma il certificato è rilasciato a www.agendadigitale.eu; è come se dicessi di chiamarmi Mario Rossi ed esibissi una CI con scritto Ajeje Brazorf. Questo accade perché, a differenza di una CI che contiene il nome di una singola persona, è assolutamente normale per un certificato digitale contenere diversi subject, ovvero entità per cui il certificato è valido. Nello specifico osserviamo i campi di dettaglio del certificato e dentro troviamo un campo specifico, detto SAN (Subject Alternative Name):
A volte è possibile trovare dei soggetti definiti come:
Resta da capire una cosa importante: va bene la catena di fiducia dei certificati, ma chi ha stabilito il punto di inizio della catena? Nello specifico, chi ha deciso che io debba fidarmi di Amazon Root CA 1 e di conseguenza di tutti i certificati da essa emessi? Nel mio caso, usando un PC Windows, l’ha deciso Microsoft in base ad un accordo commerciale con quella PKI che ha fatto sì che ogni computer Windows si fidi di quella e di molte altre entità, notate la barra di scorrimento:
Come si ottiene un certificato digitale
Andiamo quindi all’indietro e proviamo a capire come abbia fatto quel particolare sito ad ottenere il certificato.
Innanzitutto, i gestori si saranno posti come obbiettivo quello di scegliere un certificato emesso da una PKI (tecnicamente da una CA, parte di una PKI) che sia trusted sulla maggior parte dei dispositivi. Questo perché altrimenti visitando il sito si otterrebbe un messaggio di errore.
Quindi ci si rivolge ad una struttura che verosimilmente abbia accordi con tutti i produttori per essere inserita di default nei suoi dispositivi: in questo caso Amazon.
Poi è stata avviata la procedura amministrativa (pagato il dovuto) ed in seguito quella tecnica che richiede di presentare alla PKI la richiesta di certificato. Questa ha la forma di un file CSR (Certificate Signing Request) che comprende una serie di informazioni che vogliamo essere scritte nel certificato, tra cui almeno il nome del sito da certificare.
A questo punto la RA verificherà che le informazioni che ci sono nella richiesta di certificato siano adeguate. La procedura di validazione può seguire diverse strade: tanto più complessa e pedante è la procedura di validazione, tanto più credibile sarà il certificato.
Nei termini corretti la validation può essere semplice oppure extended: il tipo di validazione eseguita è poi scritto nel certificato così che chi lo riceve possa ragionare opportunamente. Ad esempio, se la CI fosse emessa per conoscenza personale dall’impiegato dell’anagrafe potremmo chiamarla con validazione semplice.
Se invece fosse richiesto l’esame del DNA allora parleremmo di una validazione estesa. Per me che voglio capire chi ho davanti le due carte di identità emesse in questi modi differenti avranno un “peso” differente, pur essendo entrambe formalmente valide.
Tornando al sito web, la nostra CSR richiede di scrivere nel certificato che è per il sito www.cybersecurity360.it: la RA in questo caso dovrà assicurarsi che il dominio in oggetto sia in nostra gestione e ad esempio opererà chiedendo una validazione in uno tra questi modi:
- richiesta di caricare un file di prova sul sito con quel nome;
- e-mail inviata ad un account amministrativo che finisca con @cybersecurity360.it;
- modifica al DNS della zona cybersecurity360.it (aggiunta di record CNAME o TXT).
Ognuna di queste richiede che in qualche modo possiamo gestire un qualche aspetto del dominio, quindi che sia “nostro”.
Se la validazione, piuttosto semplice, viene completata (per ognuno dei diversi nomi presenti tra i SAN) allora la RA concederà alla CA di creare e firmare un certificato digitale con i dati che abbiamo chiesto nella CSR. Il dettaglio della creazione di una CSR e della successiva firma della stessa richiedono di avere delle basi di crittografia che non è possibile inserire qui come inciso e richiedono una trattazione apposita.
Il certificato firmato verrà quindi dato indietro al richiedente che, assieme alla chiave privata (che non ha spedito alla PKI!) con cui aveva formato la CSR, verrà messo sul server web che mantiene il sito che potrà quindi operare.
Avete presente quel 2.23.140.1.2.1 che si legge nel certificato analizzato più sopra? Indica proprio come è stata validata la richiesta di certificato:
domain-validated(1) => (2.23.140.1.2.1) (Compliant with Baseline Requirements – No entity identity asserted)
Altri tipi di validazione possono richiedere di validare l’azienda o il singolo individuo in vari modi, più o meno credibili e invasivi: sta a chi visualizza il certificato (che ripeto, tecnicamente è valido) decidere se quel tipo di validazione è sufficiente per lo scopo per cui viene mostrato. In questo caso si tratta di vedere un sito web su cui non transitano dati sensibili, quindi io in questo caso decido che va bene.
PKI e cifratura dei dati: l’emissione dei certificati digitali
Torno su un aspetto sfiorato poco sopra: il certificato emesso dalla CA è, tecnicamente, firmato dalla CA. Senza addentrarci negli aspetti magici della crittografia, questo mi permette di stabilire matematicamente che il certificato che mi viene esposto è esattamente come quando è stato emesso e contiene le stesse informazioni, senza alterazioni.
Questo non è fattibile, almeno in prima battuta con una CI: dopo l’emissione potrei ad esempio aver sostituito il mio indirizzo sopra al precedente facendo molta attenzione a che non si veda, oppure potrei aver creato ex novo un documento come quelli originali, quindi un falso. La validazione crittografica previene ogni tipo di manomissione di un certificato.
Inoltre tra i vari dettagli di un certificato ce n’è uno interessante che si chiama CDP (CRL Distribution Point): questo è il “luogo” dove andare a prendere la CRL, ossia la Certificate Revocation List. Si tratta di una lista dei certificati emessi dalla PKI che l’emittente ha deciso di invalidare per i motivi più vari (compromissioni varie, perdita ecc.).
In questo modo io che ricevo da verificare il certificato numero 342522 emesso da Amazon posso verificare, attingendo a questa lista, se il certificato numero 342522 non si stato invalidato successivamente all’emissione.
Attenzione, un certificato finisce in CRL solo per ragioni anomale, non quando scade: la data va sempre controllata comunque. Ad esempio, se il nostro server venisse compromesso da un hacker questo potrebbe rubare il certificato e chiave privata relativa, consentendogli di impersonare il sito web (pensate ad esempio a quello di una banca su cui viene fatto un attacco di phishing).
In un caso di evento dannoso come questo caso avvertiremmo la PKI emittente la quale, verificata nuovamente la nostra identità, metterà il vecchio certificato compromesso nella CRL e magari ce ne darà uno nuovo con un nuovo numero di serie.
Un visitatore del sito di phishing messo in piedi dall’hacker otterrebbe quindi un messaggio del browser che indica un sito non sicuro, essendo il vecchio certificato numero 342522 nella CRL.
In questo caso abbiamo un vantaggio rispetto alla CI tradizionale in quanto se qualcuno ce ne presentasse una rubata, noi non potremmo distinguerla a differenza delle FF.OO. che invece hanno accesso alla “CRL” dei documenti rubati.
Riassumendo quindi, chiedendo al nostro browser di andare su www.cybersecurity360.it facciamo sì che questo si colleghi al server e chieda come prima cosa il certificato, ne validi emittente, data di scadenza e corrispondenza tra il nome presente in esso e il sito richiesto ed infine la non presenza del numero di serie nella CRL: se tutto quadra allora abbiamo stabilito l’identità del server e che il certificato non è revocato per ragioni anomale. Questo non significa che abbiamo in qualche modo cifrato la connessione! Perché questo avvenga abbiamo sempre bisogno del certificato, ma di una sua sezione specifica di cui parlerò in futuro e che contiene la chiave pubblica ed altre indicazioni su come operare la cifratura che avviene solo successivamente all’identificazione del server. Esistono molti altri campi in un certificato che non trattiamo in questo articolo e che rivelano gli altri usi che si possono fare di questi alleati digitali.
Per quanto riguarda la gestione, un certificato se non viene annullato per qualche motivo deve solamente essere rinnovato entro la scadenza. La procedura dipende dalla PKI a cui ci siamo rivolti ed in genere è più o meno quella della prima emissione, a volte semplificata avendo già validato l’utente in precedenza. Molti dei servizi cloud su cui si appoggiano i server oggi, gestiscono in completa autonomia il rinnovo dei certificati per nostro conto.
PKI e cifratura dei dati in ambito aziendale
Concludo con due argomenti che completano quanto visto: il primo riguarda le PKI aziendali. Dal punto di vista tecnico niente vieta che, ad esempio nella nostra azienda, venga creata una PKI interna.
Tecnicamente funziona esattamente come quelle commerciali, l’emissione dei certificati avviene secondo regole interne e tutto funziona come descritto in precedenza.
La differenza sta nel fatto che un qualsiasi computer non accetterà come buoni i certificati emessi fino a che non metteremo la CA principale (root) della nostra azienda tra quelle fidate dei nostri dispositivi, aggiungendola a quelle che vedete nella lunga lista sopra.
A quel punto non ci sarà differenza nell’uso di certificati acquistati o interni e si potranno emettere certificati senza pagare un’entità terza oppure che contengano informazioni particolari che la CA commerciale non accetterebbe oppure informazioni confidenziali.
Molte aziende oggi hanno in casa una PKI, gestita più o meno male: gli usi spaziano dai certificati web di prova all’autenticazione dei computer per le VPN o per il WiFi o applicazioni custom.
L’ultimo argomento sono i certificati self signed. Quando li osservate di solito si presentano così:
Questo genere di certificati si usa spesso durante le fasi di sviluppo di programmi/prodotti e, di norma, non deve essere presentato al pubblico: è come se chiedessi ad una persona di identificarsi, questa prendesse un tovagliolo usato e ci scrivesse sopra davanti a me “Mario Rossi” prima di pormelo. Tecnicamente è un documento, sul fatto che io in quel contesto lo ritenga valido, possiamo parlarne.
Dobbiamo sempre prestare attenzione quando il browser presenta un messaggio relativo al certificato del sito che vogliamo visitare e certamente, benché sia spesso (non sempre) possibile, non dobbiamo continuare se il messaggio arriva inaspettato o se sul sito dobbiamo inserire delle informazioni, come ad esempio le password.
Il browser ci sta dicendo “guarda che il sito che hai di fronte potrebbe non essere quello che intendevi raggiungere”: potrebbe trattarsi di trascuratezza di chi gestisce il sito, che ad esempio non ha rinnovato il certificato per tempo, ma anche di un attacco di tipo man in the middle, in cui una terza parte si interpone tra noi ed il sito per intercettare delle informazioni.
Curiosamente ma non troppo, questo tipo di attacco è alla base di una delle tecniche di protezione comunemente utilizzate in azienda: ne parleremo in un articolo dedicato.
Conclusioni
Questo è un viaggio ad alto livello sul mondo dei certificati che in questo caso è stato limitato a quelli usati per identificare i siti web.
Tuttavia, esistono molti altri utilizzi: possiamo usare un certificato per identificare noi su un sito, una VPN o sul WiFi invece che (o assieme a) user e password, possiamo usarli per firmare digitalmente documenti, possiamo cifrare e firmare le e-mail, cifrare i file sul disco o verificare l’autenticità di un programma prima di eseguirlo e molto altro.
I certificati possono essere registrati sul computer, su una smart card o chiavetta USB, ed ognuno di questi media ha utilizzi e logiche differenti.
Ciò che non cambia è la struttura che porta all’emissione e gestione dei certificati, descritta brevemente in questo articolo.
