Nella scorso puntata abbiamo introdotto due concetti tra loro differenti e, solo in apparenza, sconnessi: cifratura di messaggi usando algoritmi asimmettrici e la firma digitale di un documento (nel caso in esame una mail, ma lo stesso concetto può essere esteso a qualsiasi documento digitale).

In questa puntata metteremo insieme quanto esposto e faremo luce su cosa si intende PKI, che è alla base di Https.

Come fidarsi dell’interlocutore ?

Quando si scambiano messaggi con un interlocutore in forma confidenziale, occorre accertarsi di due aspetti.

1. Che i messaggi sia criptati, in modo tale che un eventuale man-in-the-middle non posso leggere il contenuto di quanto scambiato oppure anche che, se i messaggi vengono scambiati in “chiaro”, questi non vengano modificati senza che il destinatario non ne abbia evidenza.
2. Che l’interlocutore con cui si scambiano i messaggi (in chiaro o criptati) sia proprio quello che ci si aspetta (cioè non sia un fake).

Il primo punto direi che è stato analizzato e risolto nella parte precedente: qui analizzeremo il secondo punto, che in pratica è l’aspetto da cui scatiriscono le PKI e i certificati da questi gestiti.

Per meglio focalizzare la necessità, riesprimiamola in altri termini: come fa Alice a essere sicura che la mail ricevuta da Bob sia realmente stata scritta dal Bob che conosce Lei ? E non da uno che si finge Bob ? O che i messaggi inviti da Bob non vengano modificati nel tragitto da qualche utente malevole ?

O in un’altra declinazione: come facciamo a essere sicuri che quando ci connettiamo al sito della banca bancademiliardari.com i dati che vengono scambiati con il nostro browser vadano veramente al sito della banca e non vengano intercetti da qualcuno ? E viceversa ?

Infatti quanto visto sinora (algoritmi simmetrici o asimmetrici) non risolvono in alcun modo il rischio di un attacco man-in-the-middle.

Occorre sviluppare bene questo concetto per comprendere appieno cosa è un main-in-the-middle, che è l’esigenza base che in pratica risolve la PKI.

Partiamo dalla presenza di un’utente “birichino” che è in grado di intercettare tutte le comunicazioni tra Bob e Alice, che avvengono con l’uso di una sistema di firma dei messaggi come quello visto nella puntata precedente.

Grazie al fatto di poter vedere questo scambio di messaggi questo utente è in grado potezialmente di prendere i messaggi di Bob, modificarli, e inoltrarli ad Alice modificati, e senza che nessuno di questi due attori si possa rendere conto di qualcosa, anche a fronte dell’utilizzo del sistema di firma di cui abbiamo parlato.

Vediamo meglio come l’utente birichino può “gabbare” lo scambio di messaggi tra Alice e Bob.

1. Il birichino, vedendo passare tutti i messaggi scambiati, quando vede passare la chiave pubblica di Bob (cioè che Bob stesso sta inviando ad Alice dietro sua richiesta la sua chiave pubblica) la intercetta, la blocca e se la tiene per sè. Questa, come da definizione, è distribuita pubblicamente senza alcuna limitazione. Una volta intercettata e bloccata genera a sua volta una differente coppia di chiavi pubbliche/private, e inoltra la propria chiave pubblica ad Alice, la quale pensa sia quella di Bob poichè non ha motivo per pensare diversamente.
2. Successivamente Bob scrive la sua mail (firmata) ad Alice, sicuro del fatto che nessuno la potrà modificare perchè Alice ha la sua chiave pubblica (anche se in realtà Alice in realtà NON ha la sua chiave pubblica, bensì quella dell’utente birichino, pensado sia quella di Bob).
3. L’utente intercetta questa mail, bloccandola anch’essa , cambia il testo, e cancella la firma precedemente calcolata ed apposta da Bob. Sempre il birichino, quindi, completa la mail con una nuova firma calcolata con il digest dell’hash del messaggio modificato, e quindi criptato con la propria chiave privata.
4. A questo punto inoltra la mail ad Alice
5. Alice fa i controlli della mail appena ricevuta e la trova corretta.

In modo del tutto analogo lo stesso utente birichino/man-in-the-middle è in grado di intercettare la comunicazione tra il mio browser e il sito della banca.

1. Il browser inizia la connessione, e il sito della banca restituisce la propria chiave pubblica per iniziare la connessione criptata.
2. Il birichino intercetta questa connessione e crea una propria versione di chiave pubblica/privata, e inoltra al browser richiedente la propria chiave pubblica tenendo per sè quella della banca.
3. Il browser riceve la chiave pubblica pensando sia quella della banca invece è quella dell’utente birichino/man-in-the-middle.
4. Il browser invia un messaggio criptandolo con la chiave pubblica ricevuta (che credere essere quella del sito della banca).
5. L’utente birichino intercetta il messaggio, che è in grado agilmente di decriptare perchè possiede la chiave privata che va in coppia con la chiave pubblica fornita: quindi dopo aver letto il messaggio, e magari averlo modificato, lo cripta nuovamente, questa volta usando la chiave pubblica del sito della banca di cui è in possesso, e l’inoltra al sito stesso.

Se ci pensate bene a una situazione di questo genere non cè soluzione: Alice non si accorge di nulla, e tantomento Bob. Idem il sito della banca e il browser che lo sta consultando.

Il problema può essere riassunto con il fatto che non si ha la certezza che la chiave pubblica usata sia quella corretta: per risolvere occorre introdurre qualche meccanismo che ci permetta di validare la chiave pubblica ricevuta, per essere sicuri che appartenga certamente al nostro interlocutore.

Ecco, quindi, che ci viene in aiuto la PKI (=Public Key Infrastucture): in pratica questo strumento ci fornisce la prova provata che la chiave pubblica che si sta usando è proprio quello che ci aspettiamo essere e scongiura la presenza di un utente malevolo in grado di perpeturare il man-in-the-middle.

In altri temini PKI ci permette di essere sicuri che la chiave pubblica di Bob, e che Alice sta usando per verificare la sua firma, sia proprio quella di Bb: similmente che il certificato pubblico che si sta usando per connettersi al sito della banca sia proprio quello del server della banca.

Certification Authority

Per scongiurare quanto sopra si utilizzano le Certification Authority (=nel seguito abbreviata anche semplicemente CA), che sono in grado di emettere certificati.

Diamo un significato a questi termini.

Le CA sono delle entità esterne (cioè esterne a Bob e Alice, o al nostro browser e al sito della banca), in grado di garantire che la chiave pubblica utilizzata sia proprio quella di propretà della controparte che ci si aspetta.

Per confermare questo emettono dei documenti chiamati certificati (di più nel seguito).

Vediamo quale è il ruolo delle CA e come sono in grado di scongiurare l presenza di un utente birichino main-in-the-middle.

Nel seguito ci concentreremo solo sull’esempio della consutazione del sito della banca, che è più rispondente alla realtà e rappresenta un esempio pratico che immagino molti di Voi conosceranno meglio e quindi rappresenta una sponda con una realtà più coosciuta.

1. I gestori del sito bancademiliardari.com prima di pubblicare il sito decidono un algoritmo di cripting asimmetrico e creano una coppia di chiavi pubbliche e private.
2. Contattano una Certification Authorithy e gli sottopongono la chiave pubblica che intendono utilizzare per lo scambio di dati con gli utilizzatori. Normalmente questa richiesta avviene tramite l’utilizzo di un Certificate Signing Request CSR, che altro non è che un documento informatico codificato che al suo interno riporta il nome del sito, i vari dati del gestore e dei proprietari del sito stesso, e a completare il tutto c’è anche la chiave pubblica che gli utilizatori devono usare per connettersi al sito.
3. La CA normalmente verifica che il sito bancademiliardari.com sia esistente, e che chi sta richiedendo il certificato ne abbia le facoltà (cioè sia veramente il gestore del sito e non una persona esterna che non centra nulla).
4. Una volta che la CA verifica la correttezza dei dati rilascia un certificato, che altro non è che documento codificato che contiene al suo interno in sostanza gli stessi dati del CSR, ma questa volta firmati dalla chiave privata della CA stessa.

Oss.: Per meglio chiarire il certificato è un documento codificato che contiene le seguenti informazioni.

• Soggetto, cioè nome del sito
• Dati vari del’azienda richiedente
• Emittente, cioè dati identificativi della Certification Authority
• Data scadenza del certificato
• Chiave Pubblica che deve essere usata per connettersi al sito
• Firma apposta dalla CA (cioè hash di quanto sopra, criptata con la chiave privata utilizzata dalla Certification Authority).

Il protocolo Https, quindi funziona con l’utilizzo dei certificati; quando un browser si connette al sito bancademiliardari.com questo fornirà, nelle fasi iniziali della connessione, il certificato del sito rilasciato da qualche Certification Autorithy: grazie a questo documento il browser è in grado di ottenere la chiave pubblica da utilizzare per scambiare i dati con il sito.

Ma dove stà la sicurezza che la chiave pubblica sia proprio quella corretta e che nel mezzo non ci sia un utente birichino ? Sta nel fatto che le Certification Autorithy sono delle entità conosciute a tal punto che le loro chiavi pubbliche normalmente sono già inserite all’interno del nostro browser.

Pertanto quando il browser riceve il certificato da parte del sito bancademiliardari.com , verifica da quale CA è stata rilasciata, ricava la relativa chiave pubblica (è già all’interno del browser), ed è in grado subito di verificare se la firma apposta è quella corretta.

Se la firma è corretta ha la certezza che la chiave pubblica che equipaggia il certificato ricevuto sia proprio quella del sito bancademiliardari.com.

Quindi tutti il sistema si basa sui seguenti fatti notevoli.

1. La Certification Authority deve verificare, prima di rilasciare il certificato, che la chiave pubblica da inglobare in questo documento sia richiesta proprio dai gestori di questo sito
2. La Certification Authority utilizzata per il certificato deve essere tanto famosa e riconosciuta tanto che la sua chiave pubblica sia inglobata nei browser in uso (quindi i soliti forefox/chrome, etc etc).

Quindi in sostanza per esemplificare possiamo dire che la CA garantisce che la chiave pubblica sia propio quela corretta da usare: si basa tutto sulla serietà e precisione delle CA.

Quindi in definitiva: cosa è PKI ?

Nela nostra analisi ci siamo concentrati solo sulle CA: ma affinchè il meccanismo descritto funzioni occorre molto di più che le sole CA.

Infatti occorre pensare alle CA come a delle entità che interagiscono a loro volta con altre entità.

Infatti quando si richiede un certificato deve esistere un’infrastruttura che si occupa di verificare che il sogggetto del certificato sia realmente esistente, e anche che il richiedente sia realmente il gestore del sito: queste entità prende il nome di Registration Autority.

Altre entità sono quelle che devono che devono controllare i certificati emessi, ed eventualmente ritirare quelli che sono stati utilizzati in modo improvvido (per questo vengono create delle liste di certificati che devono essere rifiutati per un qualche motivo, e che devono essere aggiornate e prontamente disponibili a quant be fanno richiesta).

Insomma la CA è solo l’ultimo anello di una catena di diverse entità che interagiscono tra loro affinchè il sistema descritto in queste pagine sia sicuro ed affidabile.

L’insieme di tutte queste entità prende il nome generico di PKI Public Key Infrastructure.

Noi, come utilizzatori o gestori del sito bancademiliardari.com, abbiamo a che fare solo con la CA, ma in realtà affinchè tutto funzioni in modo corretto esiste tutta un’infrastruttura complessa e articolata.

Gerarchia delle Certification Authority

Quanto esposto sin qui secondo me è assolutamente sufficiente per comprendere il significato dei termini PKI, CA, certificati.

Qui riporto un addenum, per completare il discorso e approfondirlo uteriormente.

Noi abbiamo parlato genericamente di CA, ma in realtà esistono delle gerarchie di CA, e questo per diversi motivi.

Facciamo un esempi pratico di una gerarchia di CA a due livelli (nella pratica in realtà i livelli sono spesso di più).

La CA “padre” prende il nome di rootCA: quella successiva nella gerarchia rende il nome di CA_01.

I certificati per i siti sono rilasciati sempre dalle gerarchie inferiori: per megli dire il certificato per il sito bancademiliardari.com è rilasciato esclusivamente da CA_01.

La rootCA rilascia un solo certificato, chiamato certificato autofirmato, che assume l’aspetto nel seguito.

Soggetto: rootCA
Emittente: rootCA
Scadenza
Chiave pubblica di rootCA
Hash di quanto sopra firmato con la chiave privata di rootCA

Dopo aver creato questo certificato viene creato un nuovo certificato per esprimere che CA_01 è nella gerarchia sotto rootCA (chiamiamolo, per semplicità, certificato di gerarchia).

Soggetto: CA_01
Emittente: rootCA
Scadenza
Chiave pubblica di CA_01
Hash di quanto sopra firmato con la chiave privata di rootCA

Quando CA_01 rilascia un certificato per il sito bancademiliardari.com questo assumerà l’aspetto nel seguito (nulla di nuovo rispetto a quanto visto: Ve lo riporto solo per completezza).

Soggetto: bancademiliardari.com
Emittente: CA_01
Scadenza
Chiave pubblica di bancademiliardari.com
Hash di quanto sopra firmato con la chiave privata di CA_01

A completamento di quanto sopra occorre osservare che in realtà all’interno del browser NON vengono salvate le chiavi pubbliche di tutte le CA, ma in realtà vengono salvati i soli certificati autofirmati di tutte le rootCA: in altri temini troverete all’interno del browser solo il certificato autofirmato di rootCA e mai e poi mai nulla relativo a CA_01.

So di averVi detto poco fa una cosa differente, ma era solo un modello mentale esemplificato funzionante per far comprendere il meccanismo: comunque se leggete i sacri testi si usa la stessa progressione che ho usato io sin qui, pertanto non prendetevela con me.

Comunque la realtà nuda e cruda è che solo i certificati delle rootCA sono salvati all’interno del browser. E quindi siccome i certificati contengono le chiavi pubbliche, possiamo affermare che le sole chiavi pubbliche delle rootCA sono prontamente disponibili all’interno di un browser.

Proseguendo con la nuda e cruda realtà nela realtà quando un browser di un utilizzatore si connette al sito bancademiliardari.com otterrà due certificati.

1. Quello con soggetto CA_01 (certificato di gerarchia)
2. Quello con oggetto bancademiliardari.com (rilasciato da CA_01).

Quindi usando il primo certificato (da cui si ottiene la chiave pubblica di CA_01) è possibile validare il fatto che il secondo certificato (quello che riporta la chiave pubblica del sito) è corretto ed emesso proprio da CA_01.

Ma come facciamo a fidarci di CA_01 ? Potrebbe essere anche esso un fake ?

Semplice: consultando e validando il primo certificato (quello con soggetto CA_01 ed emesso dalla rootCA) poichè abbiamo la disponibilità della chiave pubblica di rootCA, proprio perchè è presente all’interno del browser.

Ora la domanda principe: perchè creare questa gerarchia che complica un pò le cose ?

Le motivazioni sono molteplici, e Ve ne riporto solo le due più evidenti (ma che non sono nemmeno le principali)

1. In questo modo si riduce il numero di certificati da inserire all’interno dei browser. Infatti vengono salvati e gestiti i soli rootCA, e non quelli di tutte le CA discendenti (che sono molte di più perchè a fronte di un’unica rootCA possono esistere un numero arbitrario di CA discendenti).
2. Se per caso ad un’azienda che è proprietaria di una gerachia di CA viene trafugata la chiave privata di qualche CA discendente (diciamo la CA_01) non tutto è perduto: semplicemente si invalidano tutti i certificati emessi dalla CA_01, si crea una nuova CA_02, si rigenerano i certificati, che quindi dovranno essere sostituiti. In questo modo si limitano al massimo i danni. Osservo che il vero problema è se la chiave privata di rootCA viene trafugata: ma per come esposto le rootCA vengono usate raramente, solo all’atto della creazione di CA discendenti, e quindi teoricamente si limita al massimo questo rischio.

Spero di essere stato abbastanza chiaro: so che in questo scritto ci sarà qualche imprecisione, e me ne scuso. Ma posso affermare che globalmente il flusso seguito per la gestione delle PKI è proprio questo.

Vi ringrazio per l’attenzione.