Immagina un avversario paziente. Non riesce a decifrare le tue comunicazioni oggi, ma le registra tutte e le conserva. Poi, un giorno, riesce a sottrarre la chiave privata del server con cui comunicavi, magari da un backup dimenticato o grazie a una vulnerabilità. Può ora leggere anni di traffico archiviato? La risposta dipende da una proprietà precisa: la forward secrecy, detta anche perfect forward secrecy.
La definizione
Un protocollo offre forward secrecy quando la compromissione delle chiavi a lungo termine non permette di decifrare le sessioni passate. Le chiavi a lungo termine sono quelle che identificano un soggetto per mesi o anni: la chiave privata del certificato di un sito, la chiave d'identità di un'app di messaggistica, la chiave PGP di una persona.
In un sistema con forward secrecy, quelle chiavi servono solo a dimostrare l'identità, non a proteggere direttamente i dati. I dati sono protetti da chiavi temporanee che vengono distrutte dopo l'uso.
Senza forward secrecy: il trasporto della chiave
Per capire il valore di questa proprietà conviene guardare come funzionavano molte connessioni HTTPS fino a qualche anno fa. Nelle versioni di TLS precedenti alla 1.3 era ancora possibile, e per lungo tempo comune, lo scambio di chiavi RSA:
- il browser generava un segreto casuale;
- lo cifrava con la chiave pubblica RSA del certificato del server;
- il server lo decifrava con la propria chiave privata;
- da quel segreto si ricavavano le chiavi di sessione.
Il problema è evidente: chiunque avesse registrato il traffico e ottenuto in seguito la chiave privata del server poteva decifrare il segreto di ogni sessione e, con esso, l'intero contenuto. Una sola chiave rubata apriva tutto l'archivio.
Con forward secrecy: le chiavi effimere
La soluzione è separare autenticazione e cifratura usando uno scambio di chiavi effimero, tipicamente Diffie-Hellman su curve ellittiche (ECDHE):
- per ogni sessione, client e server generano una coppia di chiavi temporanea, usata una sola volta;
- con queste chiavi calcolano un segreto condiviso, che non viaggia mai sulla rete;
- il server firma la propria chiave temporanea con la chiave privata del certificato, per dimostrare chi è;
- a fine sessione le chiavi temporanee vengono cancellate.
Ora, se in futuro la chiave del certificato venisse rubata, l'attaccante potrebbe al massimo impersonare il server da quel momento in poi, finché il certificato non viene revocato. Non potrebbe però decifrare le sessioni registrate in passato, perché le chiavi temporanee che le proteggevano non esistono più da nessuna parte.
TLS 1.3 ha eliminato lo scambio di chiavi RSA: ogni connessione TLS 1.3 offre forward secrecy per progetto.
Forward secrecy nelle chat
Le app di messaggistica che usano il protocollo Signal portano il concetto ancora più avanti. Le chiavi non cambiano solo a ogni sessione, ma a ogni messaggio, grazie al meccanismo detto double ratchet. Se un attaccante riuscisse a estrarre le chiavi correnti da un telefono, non potrebbe comunque decifrare i messaggi precedenti.
A questo si aggiunge una proprietà complementare, la sicurezza dopo la compromissione: dopo qualche scambio di messaggi, l'introduzione di nuovo materiale casuale esclude di nuovo l'attaccante anche dalle comunicazioni future.
Dove la forward secrecy manca
Non tutti i sistemi la offrono.
| Sistema | Forward secrecy |
|---|---|
| TLS 1.3 | Sempre |
| TLS 1.2 con ECDHE o DHE | Sì |
| TLS 1.2 con scambio di chiavi RSA | No |
| App con protocollo Signal | Sì, a ogni messaggio |
| Email cifrate con PGP | No |
| File o dischi cifrati con una chiave fissa | Non applicabile: la chiave protegge i dati nel tempo |
Il caso di PGP è istruttivo: un messaggio cifrato per la tua chiave pubblica resta decifrabile con la tua chiave privata finché questa esiste. Chi ha conservato le tue email cifrate e un giorno ottiene la tua chiave e la passphrase può leggerle tutte.
Un dettaglio tecnico che può vanificarla
Anche con scambi di chiavi effimeri, alcune ottimizzazioni possono indebolire la forward secrecy. Per velocizzare le riconnessioni, i server TLS possono emettere ticket di sessione cifrati con una chiave del server. Se quella chiave resta invariata per mesi e viene rubata, le sessioni riprese con quei ticket possono essere esposte. Chi gestisce server dovrebbe assicurarsi che le chiavi dei ticket vengano ruotate frequentemente.
Cosa la forward secrecy non fa
La forward secrecy protegge il traffico in transito registrato da un avversario. Non protegge:
- i dati conservati in chiaro sul server o sul dispositivo;
- le sessioni in corso nel momento in cui un dispositivo è compromesso;
- le comunicazioni future se l'attaccante usa la chiave rubata per impersonare il server prima della revoca.
In sintesi
- La forward secrecy impedisce che il furto di una chiave a lungo termine esponga le sessioni passate.
- Si ottiene con scambi di chiavi effimeri, firmati dalla chiave a lungo termine solo per l'autenticazione.
- TLS 1.3 la garantisce sempre; il vecchio scambio di chiavi RSA non la offriva.
- Il protocollo Signal la applica a ogni singolo messaggio; PGP non la offre.
- Ticket di sessione con chiavi mai ruotate possono indebolirla.
