Autorità di certificazione e catene di fiducia

La crittografia asimmetrica è utile solo se si può avere la certezza che una chiave pubblica appartenga effettivamente alla persona o all'organizzazione che si pensa. Senza un meccanismo di fiducia, un attaccante può intercettare la richiesta della chiave pubblica di qualcuno e sostituirla con la propria: si tratta del classico attacco man-in-the-middle. La Public Key Infrastructure (PKI) risolve questo problema di fiducia introducendo una Certificate Authority (CA), una terza parte attendibile che firma digitalmente i certificati associando le chiavi pubbliche a identità verificate. Se ci si fida della CA, ci si può fidare di chiunque sia stato certificato dalla CA.

Una Certificate Authority (CA) è un'organizzazione che emette certificati digitali dopo aver verificato l'identità del richiedente. La CA firma ogni certificato con la propria chiave privata, consentendo a chiunque si fidi della CA di verificarne l'autenticità usando la chiave pubblica della CA. Esistono due tipi: le CA pubbliche (come DigiCert, GlobalSign e Let's Encrypt), i cui certificati radice sono preinstallati nei sistemi operativi e nei browser, e le CA private (interne), gestite direttamente dalle organizzazioni per emettere certificati interni (VPN, servizi interni e certificati dei dispositivi).

Una Root CA è l'autorità al vertice della gerarchia PKI. I certificati delle CA radice sono autofirmati: non esiste un'autorità superiore che li convalidi. I certificati radice sono invece considerati attendibili perché i produttori dei sistemi operativi (Microsoft, Apple e Mozilla sottopongono le CA radice a rigorosi processi di verifica e ne preinstallano i certificati negli archivi dei certificati attendibili. In un tipico archivio di attendibilità di un browser sono presenti circa 130-150 CA radice attendibili. Se una CA radice viene compromessa, ogni certificato emesso da essa diventa sospetto; per questo le chiavi private delle CA radice vengono conservate in moduli hardware di sicurezza (HSM) offline e isolati fisicamente dalla rete.

Le CA radice emettono raramente certificati direttamente alle entità finali. Creano invece CA intermedie (chiamate anche CA subordinate), emettendo certificati agli operatori delle CA intermedie. Le CA intermedie emettono poi certificati per le entità finali (come i certificati dei server HTTPS). Questa gerarchia di delega ha diversi scopi: protegge le chiavi private delle CA radice mantenendole offline (se una CA intermedia viene compromessa, viene revocata solo la sua catena di certificati, non l'intera radice); consente di creare CA specializzate per diversi casi d'uso (firma del codice anziché TLS); e permette di realizzare una gerarchia organizzativa all'interno di una PKI privata.

Una catena di certificati (o catena di fiducia) è la sequenza di certificati che parte dal certificato dell'entità finale e risale fino alla CA radice attendibile. Per un tipico sito HTTPS, la catena è: Certificato dell'entità finale (ad es., *.google.com) → Certificato della CA intermedia (ad es., Google Trust Services WR2) → Certificato della CA radice (ad es., Google Trust Services LLC). Quando il browser visita un sito, convalida l'intera catena, verificando che la firma di ogni certificato sia stata apposta dal livello immediatamente superiore e che la radice sia presente nell'archivio attendibile. Qualsiasi interruzione di questa catena causa un errore del certificato.

Quando due gerarchie PKI separate devono stabilire una fiducia reciproca, usano la cross-certification. Ogni CA emette un certificato per la radice dell'altra, stabilendo la fiducia in entrambe le direzioni. Una Bridge CA è una CA centrale che esegue la cross-certification con più CA di dominio, creando una rete di fiducia tra organizzazioni o agenzie governative diverse. La US Federal Bridge CA collega più sistemi PKI del governo federale. La cross-certification è complessa da gestire, ma necessaria quando si uniscono organizzazioni o si stabilisce la fiducia tra agenzie senza fondere tutto in un'unica gerarchia.

Una Registration Authority (RA) è un'entità che verifica l'identità per conto di una CA, ma non emette direttamente i certificati. La RA riceve le richieste di certificato, verifica l'identità del richiedente (tramite controllo dei documenti, convalida del dominio o verifica di persona, a seconda del tipo di certificato) e inoltra le richieste approvate alla CA per la firma. Questa delega consente alle CA di aumentare il volume delle emissioni senza eseguire direttamente tutte le verifiche. In una PKI aziendale, la RA potrebbe essere il reparto Risorse umane o l'help desk IT che convalida le richieste di certificato dei dipendenti.

Le CA offrono certificati con diversi livelli di convalida, che riflettono il grado di accuratezza con cui è stata verificata l'identità del richiedente. Domain Validation (DV): la CA verifica solo che il richiedente controlli il dominio (procedura automatizzata, richiede pochi minuti, usata da Let's Encrypt). Organization Validation (OV): la CA verifica l'esistenza legale dell'organizzazione (da 1 a 3 giorni lavorativi). Extended Validation (EV): verifica più approfondita, che comprende identità legale, indirizzo fisico ed esistenza operativa (da 1 a 2 settimane, in passato usata per mostrare il nome dell'azienda in verde nella barra degli indirizzi del browser). La DV è sufficiente per la cifratura di base; la EV è appropriata per obiettivi di alto valore, come i siti bancari.

Il certificate pinning è una tecnica che configura un'applicazione per considerare attendibile solo uno specifico certificato o una specifica CA, anziché qualsiasi certificato emesso da una CA radice attendibile. In questo modo si prevengono gli attacchi MITM anche se un attaccante riesce a ottenere un certificato fraudolento da una CA attendibile. Le app mobili e le applicazioni che gestiscono dati sensibili usano il pinning per assicurarsi di accettare solo i certificati dei propri server. Lo svantaggio è che, se il certificato sottoposto a pinning scade o viene sostituito, l'applicazione smette di funzionare finché non viene aggiornata. HPKP (HTTP Public Key Pinning) era un meccanismo di pinning basato sul browser, deprecato a causa dei rischi di configurazione errata.

Le organizzazioni gestiscono una propria CA privata per le esigenze interne relative ai certificati: autenticare i client VPN, emettere certificati per i servizi HTTPS interni, firmare il codice e autenticare i dispositivi. Active Directory Certificate Services (AD CS) di Microsoft è la CA privata aziendale più comune. I certificati della CA interna devono essere distribuiti a tutti i dispositivi e browser che devono considerare attendibili i certificati emessi internamente, in genere tramite Criteri di gruppo. Le CA private non possono emettere certificati considerati attendibili su Internet pubblica: il loro uso è limitato ai dispositivi dell'organizzazione che hanno installato la radice della CA privata.

La compromissione di DigiNotar (2011) è l'incidente relativo a una CA più importante che i candidati a Security+ devono conoscere. La CA olandese DigiNotar fu violata da attaccanti che emisero certificati fraudolenti per Google, Mozilla e domini governativi. Questi certificati furono usati in Iran per eseguire attacchi man-in-the-middle contro i cittadini. Di conseguenza, tutti i principali produttori di browser e sistemi operativi rimossero immediatamente DigiNotar dai propri archivi delle radici attendibili, invalidando tutti i certificati che DigiNotar aveva mai emesso. DigiNotar dichiarò bancarotta nel giro di poche settimane. Questo incidente ha dimostrato che la compromissione di una CA è catastrofica e spiega perché oggi siano richiesti i record DNS CAA, la Certificate Transparency e l'autenticazione a più fattori per i sistemi delle CA.

Verifichi la Sua comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione ha appreso che le Autorità di certificazione associano le chiavi pubbliche a identità verificate; la catena di attendibilità parte dall'entità finale, passa per le CA intermedie e arriva a una radice autofirmata; le CA radice vengono mantenute offline negli HSM e sono considerate attendibili in anticipo dai sistemi operativi; inoltre, la compromissione di una CA (DigiNotar) può invalidare milioni di certificati. Nella prossima sezione esamineremo la struttura dei certificati X.509.