Casi d’uso della PKI: HTTPS, S/MIME e firma del codice

La Public Key Infrastructure (PKI) è la struttura portante invisibile delle comunicazioni digitali sicure. I certificati e le CA che ha studiato vengono applicati ogni giorno in decine di scenari reali. L’esame Security+ verifica la Sua capacità di riconoscere i casi d’uso della PKI, comprendere quale tipo di certificato sia appropriato per ciascuno di essi e identificare quale protezione fornisca la PKI in ogni contesto. I tre casi d’uso più importanti per l’esame sono HTTPS/TLS (sicurezza del Web), S/MIME (sicurezza della posta elettronica) e la firma del codice (integrità del software).

HTTPS (HTTP su TLS) è il caso d’uso più visibile della PKI. Quando si connette a https://bank.com, il browser: (1) riceve il certificato TLS del server, (2) verifica che la catena di certificati conduca a una CA radice attendibile, (3) confronta il nome host con i campi SAN, (4) verifica che il certificato non sia stato revocato e (5) utilizza la chiave pubblica per uno scambio di chiavi Diffie-Hellman, così da stabilire una sessione cifrata. L’icona del lucchetto nel browser indica che tutti questi controlli sono stati superati. Un certificato mancante o non valido genera un avviso del browser che impedisce alla maggior parte degli utenti di procedere.

S/MIME (Secure/Multipurpose Internet Mail Extensions) utilizza i certificati PKI per fornire due servizi di sicurezza per la posta elettronica. Cifratura: il mittente cifra il corpo dell’email con la chiave pubblica del destinatario, così solo il destinatario può decifrarlo, proteggendo la riservatezza anche se l’email viene intercettata durante il transito o memorizzata su un server compromesso. Firme digitali: il mittente firma con la propria chiave privata, dimostrando al destinatario che l’email proviene realmente dal mittente e non è stata modificata, proteggendo l’integrità e fornendo il non ripudio. S/MIME richiede che ogni utente disponga di un proprio certificato emesso da una CA.

La firma del codice utilizza la PKI per firmare digitalmente il software — eseguibili, script, driver e programmi di installazione — affinché gli utenti possano verificare che provenga da un editore attendibile e non sia stato manomesso. Il fornitore del software firma il codice con una chiave privata associata a un certificato di firma del codice emesso da una CA attendibile. Quando un utente esegue il software, il sistema operativo verifica la firma utilizzando la chiave pubblica del fornitore presente nella catena di certificati. Windows SmartScreen, macOS Gatekeeper e gli app store iOS/Android si affidano tutti alla firma del codice per stabilire la provenienza del software. Il software non firmato può essere bloccato o generare avvisi di sicurezza.

L’autenticazione tramite certificato client (chiamata anche TLS reciproco o mTLS) estende il modello TLS standard richiedendo anche al client di presentare un certificato. Nel TLS standard, solo il server viene autenticato tramite certificato; in mTLS, entrambe le parti vengono autenticate reciprocamente. Questo meccanismo viene utilizzato per: autenticazione VPN (smart card o certificati client al posto delle password), autenticazione API (autenticazione tra macchine, in cui il client è un servizio e non una persona) e accesso amministrativo privilegiato (con l’obbligo per gli amministratori di usare token hardware con certificati integrati).

SSH utilizza la crittografia a chiave pubblica per due scopi: autenticazione del server e autenticazione del client. Autenticazione del server: quando si connette per la prima volta a un server SSH, questo presenta la propria chiave host (chiave pubblica). Il client SSH la memorizza in ~/.ssh/known_hosts. Nelle connessioni successive, se la chiave host cambia (circostanza che potrebbe indicare un attacco MITM o la ricostruzione del server), SSH mostra un avviso. Autenticazione del client: invece delle password, gli amministratori utilizzano coppie di chiavi; la chiave pubblica viene aggiunta a authorized_keys del server e la chiave privata (mai trasmessa) dimostra l’identità. Le chiavi host SSH sono separate dai certificati PKI, ma svolgono la stessa funzione di instaurazione della fiducia.

La PKI consente la firma digitale legalmente vincolante dei documenti in molte giurisdizioni. Le firme Adobe PDF, DocuSign e i sistemi governativi di firma elettronica utilizzano tutti certificati PKI per firmare i documenti. Un complemento fondamentale alla firma dei documenti è la marcatura temporale: una Trusted Timestamp Authority (TSA) controfirma l’hash del documento con un orario attendibile, dimostrando che il documento esisteva in un determinato momento. La marcatura temporale è essenziale anche per la firma del codice: senza una marca temporale, le firme del codice diventano non valide quando scade il certificato di firma, anche per il software distribuito prima della scadenza.

Con la proliferazione dei dispositivi IoT, la PKI fornisce un meccanismo per autenticare i dispositivi su larga scala. Ogni dispositivo viene dotato di un certificato univoco durante la produzione (un processo chiamato provisioning dell’identità del dispositivo), consentendo ai server di autenticare i singoli dispositivi tramite i relativi certificati. Ciò abilita scenari come: un contatore intelligente che dimostra la propria identità al server dell’azienda elettrica, un dispositivo medico che si autentica alla rete di un ospedale o una flotta di veicoli che si autentica al backend del produttore. La PKI per l’IoT deve gestire milioni di dispositivi con risorse limitate, favorendo l’adozione di certificati ECC per le loro dimensioni ridotte e la verifica rapida.

L’autenticazione VPN basata su certificati è significativamente più sicura dell’autenticazione VPN basata su password. A ogni utente o dispositivo VPN viene emesso un certificato client dalla CA interna dell’organizzazione. Durante la connessione, il gateway VPN verifica il certificato client, assicurandosi che sia stato emesso dalla CA interna attendibile, che rientri nel periodo di validità e che non sia stato revocato tramite CRL/OCSP. Quando un dipendente lascia l’organizzazione, la revoca del suo certificato impedisce immediatamente l’accesso alla VPN, offrendo una garanzia più affidabile rispetto alla semplice speranza che non abbia condiviso la propria password con altri.

I professionisti della sicurezza devono essere in grado di diagnosticare gli errori comuni relativi ai certificati. Certificato scaduto: la data notAfter è trascorsa; rinnovare il certificato. Nome host non corrispondente: il SAN del certificato non corrisponde al nome host richiesto; verificare CN e SAN; potrebbe essere necessario un certificato wildcard o multi-SAN. Certificato autofirmato: nessuna CA ha attestato l’affidabilità del certificato; aggiungerlo all’archivio di certificati attendibili locale o sostituirlo con un certificato firmato da una CA. Catena incompleta: il certificato della CA intermedia non è stato fornito dal server; configurare il server affinché invii la catena completa. Certificato revocato: la CRL o OCSP indica la revoca; è necessaria una risposta immediata alla compromissione della chiave.

Due tipi di certificato gestiscono più nomi host. Un certificato wildcard copre tutti i sottodomini di primo livello di un dominio: *.example.com copre www.example.com, mail.example.com e api.example.com, ma NON sub.api.example.com (due livelli). Un solo certificato e una sola chiave privata per tutti i servizi: è pratico, ma rischioso se la chiave viene compromessa, perché tutti i servizi ne subiscono le conseguenze. Un certificato multi-SAN elenca esplicitamente più domini specifici nell’estensione SAN (ad esempio example.com, www.example.com, api.example.com). È più granulare, ma richiede l’aggiornamento del certificato quando vengono aggiunti nuovi domini.

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

In questa lezione ha imparato che HTTPS/TLS utilizza i certificati del server per cifrare il traffico Web e autenticare i server; i certificati S/MIME consentono di firmare e cifrare le email; i certificati di firma del codice dimostrano l’integrità del software e l’identità dell’editore; e i certificati client consentono l’autenticazione reciproca per VPN e API. Ora esamineremo le politiche delle password e l’autenticazione a più fattori.