La sicurezza delle VPN, sia site-to-site sia remote-access, poggia su tre garanzie crittografiche che devi saper distinguere con precisione: riservatezza, integrità e autenticazione. Ogni garanzia è fornita da una famiglia di algoritmi diversa, e l’errore d’esame più comune è confondere quale componente fa cosa.
Hashing e HMAC: integrità
Una funzione di hash (SHA-256, SHA-384, la deprecata MD5) produce un digest a lunghezza fissa da un input di lunghezza arbitraria. È one-way e priva di chiave: chiunque può ricalcolarla, quindi da sola non garantisce che il messaggio non sia stato alterato da un attaccante che ricalcola anche il digest.
Per l’integrità autenticata si usa HMAC (Hash-based Message Authentication Code), che combina la funzione hash con una chiave segreta condivisa. In IPsec, HMAC-SHA verifica che ogni pacchetto non sia stato modificato in transito e provenga da chi possiede la chiave. Ricorda: l’hash garantisce integrità, non riservatezza — il dato resta in chiaro.
Cifratura simmetrica: riservatezza
La confidenzialità del traffico è affidata a cifrari simmetrici, dove la stessa chiave cifra e decifra. Lo standard è AES (128/192/256 bit), oggi tipicamente in modalità AES-GCM, che unisce cifratura e integrità autenticata (AEAD) in un solo passaggio. I cifrari simmetrici sono veloci e adatti a grandi volumi di dati: per questo cifrano il bulk traffic del tunnel. Il loro limite è la distribuzione della chiave: entrambe le parti devono condividere lo stesso segreto senza trasmetterlo in chiaro.
Cifratura asimmetrica: scambio chiavi e firme
La crittografia asimmetrica usa una coppia chiave pubblica/privata e risolve due problemi:
- Key exchange — Diffie-Hellman (DH) e la variante a curve ellittiche ECDH permettono a due peer di derivare una chiave simmetrica condivisa scambiandosi solo valori pubblici, senza mai trasmettere il segreto. In IKE il gruppo DH (es. group 14, 19, 20) definisce la robustezza di questo scambio.
- Firme digitali e autenticazione — con RSA o ECDSA si firma un digest con la chiave privata; chi possiede la chiave pubblica verifica origine e integrità. È il meccanismo che autentica i peer e i certificati.
Gli algoritmi asimmetrici sono computazionalmente pesanti: non si usano per cifrare il traffico, ma per negoziare in modo sicuro le chiavi simmetriche e per autenticare.
PKI: CA, certificati e catena di fiducia
Le chiavi pubbliche vanno legate a un’identità verificabile, altrimenti un attacker può presentare la propria. La PKI risolve questo con una Certificate Authority (CA) fidata che firma i certificati X.509, associando un’identità alla sua chiave pubblica.
| Componente | Ruolo |
|---|---|
| Root CA | Radice di fiducia, certificato self-signed |
| Subordinate/Intermediate CA | Firma i certificati end-entity per delega |
| Certificato X.509 | Lega identità ↔ chiave pubblica, firmato dalla CA |
| CRL / OCSP | Verifica revoca del certificato |
La catena di fiducia funziona a ritroso: il certificato del peer è firmato da una CA intermedia, a sua volta firmata dalla root. Se il device fida la root CA (presente nel trustpoint), fida l’intera catena. Nelle VPN IKEv2 con autenticazione a certificati, i peer si scambiano i certificati e verificano la firma risalendo fino a una root fidata.
Come si combina nel handshake TLS/SSL
Il TLS handshake orchestra tutti i componenti insieme:
- Il server presenta il certificato X.509; il client verifica la catena di fiducia fino a una root CA.
- Le parti usano (EC)DHE per derivare un segreto condiviso, garantendo Perfect Forward Secrecy.
- Il server firma i parametri con la chiave privata (RSA/ECDSA) → autenticazione.
- Dalla chiave derivata si generano chiavi AES per la riservatezza e HMAC/AEAD per l’integrità del traffico applicativo.
Lo stesso schema — DH per lo scambio, firma per l’autenticazione, AES per il bulk, HMAC per l’integrità — si ritrova identico in IPsec/IKE.
Trappole tipiche d’esame
- Scenario: “quale componente garantisce lo scambio sicuro delle chiavi in IPsec?” → Diffie-Hellman/ECDH, non AES e non RSA. AES cifra i dati, DH negozia la chiave.
- Scenario: “quale fornisce integrità/anti-tampering dei pacchetti?” → HMAC-SHA, non l’hash “nudo” né AES.
- Scenario: “quale assicura la riservatezza del traffico nel tunnel?” → cifrario simmetrico AES, mai RSA (troppo lento, usato solo per firma/scambio).
- Scenario: “il peer autentica l’altro tramite certificati: cosa verifica?” → la firma della CA e la catena di fiducia fino a una root fidata, più stato di revoca (CRL/OCSP).
- Scenario: “serve Perfect Forward Secrecy” → richiede scambio DHE/ECDHE effimero, non chiavi RSA statiche riutilizzate.