Bibliografia:
Computer Networking. Autori: James F. Kurose (University of Massachusetts, Amherst) Keith W. Ross (Polytechnic Institute of NYU).
Sicurezza al livello Rete: IPsec e Virtual Private network
Il protocollo IP security, anche noto come IPsec, fornisce i servizi di sicurezza al livello Rete. IPsec rende sicuri i datagrammi IP tra qualsiasi coppia di entità di livello Rete, quali host e router. IPsec serve principalmente per creare una Virtual Private Network (VPN) sulla rete pubblica Internet.
La riservatezza al livello Rete, tra due host, tra due router o tra un host ed un router, richiede che l'entità mittente cripti i dati contenuti nei datagrammi e li trasmetta al destinatario. I dati criptati nel datagramma potrebbero essere un segmento TCP, un segmento UDP, un messaggio ICMP ecc. La realizzazione di un servizio di sicurezza per il livello Rete, garantirebbe che tutti i dati inviati da una entità all'altra, quali le e-mail, le pagine Web, i messaggi di handshake del TCP e i messaggi di diagnostica della rete (quelli del protocollo ICMP) dovrebbero essere incomprensibili a chiunque li intercetti. Per questa ragione, si dice anche che un livello di Rete sicuro rappresenta un Tunnel.
Accanto alla riservatezza, il livello Rete potrebbe fornire anche altri servizi di sicurezza. Ad esempio, potrebbe fornire l'autenticazione della sorgente, in modo che l'entità ricevente possa accertare l'identità sorgente del datagramma sicuro. Il protocollo di Rete sicuro potrebbe anche fornire l'integrità dei dati, in modo che il destinatario di un datagramma possa verificare che, lungo il percorso, il datagramma non ha subito manomissioni. Il protocollo sicuro del livello Rete potrebbe anche prevenire l'attacco di ripetizione, cioè il ricevitore dovrebbe avere la possibilità di riconoscere i datagrammi duplicati inviati da un attaccante. Il protocollo IPsec possiede meccanismi che consentono di applicare tutti questi servizi di sicurezza, cioè: riservatezza, autenticazione del mittente, integrità dei dati e prevenzione dell'attacco di ripetizione.
IPsec e Virtual Private Networks (VPN)
Un'organizzazione che, con le sue sedi periferiche, copre un'area geografica molto vasta, avrebbe convenienza a possedere una propria rete di comunicazione, in modo che solo i suoi host e i suoi server possano utilizzare quei canali di comunicazione e quindi nessuno sarebbe in grado di intercettare i pacchetti. Ma una tale rete sarebbe estremamente costosa: l'azienda dovrebbe installare le apparecchiature di rete, acquistare i canali, realizzare le infrastrutture che offrono i servizi di rete, quali il DNS, in modo da essere completamente separata dalla rete pubblica Internet. Inoltre anche i costi di manutenzione sarebbero a carico dell'organizzazione.
Invece di installare e manutenzionare una rete privata, le organizzazioni preferiscono creare VPN sulla rete pubblica Internet. Con una VPN, il traffico tra le sedi dell'organizzazione viaggia sulla rete pubblica Internet piuttosto che su una rete fisicamente indipendente. Ma per offire il servizio di riservatezza dei dati, il traffico tra le sedi periferiche deve essere criptato prima di essere immesso nella rete pubblica. Si pensi ad una azienda che ha una sede centrale in una città, molte sedi periferiche in altre città ed inoltre ha agenti di vendita che possono viaggiare per recarsi presso i clienti. Gli host che comunicano attraverso la rete locale della sede centrale o delle sedi perifieriche usano il tradizionale protocollo IP, non avendo necessità di criptare i pacchetti. La criptografia è richiesta quando i pacchetti devono viaggiare sulla rete pubblica.
Il seguente esempio vuole fornire un'idea sommaria del principio di funzionamento di una VPN. Quando un host della sede pricipale invia un pacchetto ad un agente di vendita che si trova in un albergo con il suo computer portatile, Il router di default della rete della sede centrale converte il datagramma IP in un datagramma IPsec e trasmette questo datagramma IPsec su Internet. Questo datagramma IPsec ha l'intestazione nel formato IPv4, in modo che i router della rete pubblica Internet possano elaborare normalmente il datagramma. Ai router, il datagramma ricevuto appare come un ordinario datagramma nel formato IPv4. Il datagramma originario completo convertito nel formato IPsec, contenente l'header e il payload, è contenuto nel payload del datagramma IPv4. Quando il datagramma IPsec giunge al computer dell'agente di vendita, il sistema operativo del computer decripta il payload (verifica anche l'integrità dei dati) e consegna il pacchetto decriptato al livello superiore (TCP o UDP).
| Header IP | Header IPsec | Payload IPsec |
| ← Payload IP → | ||
Questa era solo una descrizione sommaria, utile per comprendere meglio i dettagli di IPsec per la creazione di una VPN.
I protocolli AH ed ESP
Il protocollo IPsec può indicare nell'header uno tra due protocolli: il protocollo Authentication Header (AH) e il protocollo Encapsulation Security Payload (ESP) protocol. L'entità sorgente di IPsec (un host o un router) invia un datagramma protetto ad un'entità destinazione (un altro host o un router) usa uno dei due protocolli: AH o ESP. Il protocollo AH fornisce i servizi di autenticazione della sorgente e il controllo di integrità dei dati, ma non fornisce la riservatezza dei dati. Il protocollo ESP fornisce i servizi di autenticazione, integrità e risevatezza. Poichè la riservatezza è un requisito che deve possedere una VPN, e altre applicazioni di IPsec, il protocollo ESP è molto più usato del protocollo AH. Per questa ragione, in questa sezione si approfondisce esclusivamente il protocollo ESP.
Security Association
I pacchetti IPsec vengono scambiati tra due entità di rete, ad esempio due host, due router, o un host e un router. Prima di trasmettere i datagrammi IPsec dall'entità sorgente all'entità destinazione, le due entità sorgente e destinazione creano una connessione logica a livello Rete. Questa connessione logica è chiamata una security association (SA). Una SA è una connessione simplex, cioè è una connessione unidirezionale da sorgente a destinazione. Se entrambe le entità devono scambiarsi datagrammi sicuri, allora devono essere stabilite due SA, cioè due connessioni logiche, una in ogni direzione.
Ad esempio, in una VPN di una organizzazione aziendale, dove ci potrebbe essere un traffico IPsec bidirezionale tra la sede centrale e una sede periferica e un altro traffico IPsce bidirezionale tra la sede centrale e N agenti di vendita esterni, sarebbero necessarie due SA tra il router di default della rete locale della sede principale e il router della rete locale della sede periferica, e 2·N SA tra il router di default della rete della sede centrale e ciascun computer degli agenti di vendita. In totale ci sono (2 + 2·N) SA. Tenere presente, comunque, che non tutto il traffico uscente dal router di default della rete della sede principale o dai computer degli agenti di vendita è protetto con IPsec. Ad esempio, un host della sede centrale che si collega ad un server Web su Internet non richiede servizi di sicurezza. Quindi dal router della sede principale escono sia pacchetti IP sia pacchetti IPsec.
Per comprendere la struttura di una SA, si osservi la figura seguente:
Una SA è stata stabilita tra il router R1 e il router R2. Il router R1 potrebbe essere il router di default dell'organizzazione, e il router R2 potrebbe essere il router di default della sede periferica. Il router R1 memorizza le seguenti informazioni di stato di questa SA:
un identificatore a 32 bit della SA, chiamato il Security Parameter Index (SPI)
l'interfaccia di origine della SA (in questo caso 200.168.1.100) e l'interfaccia di destinazione della SA (in questo caso 193.68.2.23)
il tipo di criptografia da usare (ad esempio, 3DES con CBC)
la chiave di criptografia
il tipo di controllo dell'integrità (ad esempio, HMAC con MD5)
la chiave di autenticazione
Ogni volta che il router R1 deve costruire un datagramma IPsec per inviarlo su questa SA, accede alle informazioni di stato per determinare come dovrebbe autenticare e criptare il datagramma. Analogamente, il router R2 memorizza le stesse informazioni di stato di questa SA ed le userà per autenticare e decriptare i datagrammi IPsec che vengono ricevuti su questa SA.
Un'entità IPsec (router o host) deve memorizzare informazioni di stato per molte SA. Ad esempio, nella VPN con N agenti commerciali e una sede periferica, il router di default della sede centrale memorizza informazioni di stato per (2 + 2·N) SA. Un'entità IPsec memorizza le informazioni di stato di tutte le sue SA nel suo Security Association Database (SAD), che è una struttura dati memorizzata nel kernel del sistema operativo dell'entità.
Formato del datagramma IPsec
IPsec ha due diversi formati di pacchetti, uno per il modo tunnel e l'altro per il modo trasporto. Il modo tunnel, essendo più appropriato per le VPN, è preferito rispetto al modo trasporto. In questa sezione si descriverà il modo tunnel.
| ← | Enchilada autenticato | → | ||||||
| ← | criptato | → | ||||||
| Nuovo header IP |
header ESP |
header IP originale |
Payload originale del datagramma IP |
trailer ESP |
MAC ESP | |||
| SPI | Nr SEQ | riempimento | Lunghezza del riempimento |
Next Header |
||||
La figura precedente mostra il formato del pacchetto IPsec. Si supponga che il router R1 riceva un datagramma IPv4 dall'host 172.16.1.17 (nella rete della sede centrale) destinato all'host 172.16.2.48 (nella rete di una sede periferica). Il router R1 segue il seguente procedimento per convertire il datagramma originale IPv4 in un datagramma IPsec:
aggiunge alla fine del datagramma originale IPv4 (che contiene anche i campi dell'header originale) un campo ESP trailer,
cripta il risultato usando l'algoritmo e la chiave specificati nella SA,
prima di questo campo criptato, inserisce un campo chiamato ESP header; il pacchetto risultante viene chiamato l'enchilada (dal nome di un panino farcito messicano),
crea un MAC di autenticazione dell'intero enchilada usando l'algoritmo e la chiave specificati nella SA,
Aggiunge il MAC in fondo all'enchilada formando il payload,
Infine, crea un nuovo header IP nel tradizionale formato IPv4 e lo inserisce priam del payload.
Al termine di queste operazioni, il datagramma IPsec ottenuto è simile ad un normale datagramma IPv4. Ma in questo caso il payload contiene un'intestazione ESP, il datagramma IP originale, un ESP trailer, e un campo per l'autenticazione ESP (con il datagramma originale e l'ESP trailer criptati). Il datagramma IP originale ha l'indirizzo IP sorgente = 172.16.1.17 e l'indirizzo IP destinazione = 172.16.2.48. Poichè il datagramma IPsec include il datagramma IP originale, questi indirizzi sono inclusi (e criptati) come parte del payload del pacchetto IPsec. Nei campi indirizzo sorgente e indirizzo destinazione della nuova intestazione del pacchetto sono stati scritti gli indirizzi delle interfacce dei router sorgente e destinazione, che si trovano agli estremi del tunnel, cioè 200.168.1.100 e 193.68.2.23. Inoltre il codice del protocollo in questa nuova intestazione del pacchetto IPv4 non viene codificato con nessuno dei protocolli TCP, UDP, o SMTP, ma viene fissato al valore 50, per indicare che questo è un datagramma IPsec che usa il protocollo ESP.
Il datagramma IPsec che R1 invia nella rete pubblica Internet, attraverserà molti router prima di raggiungere R2. Ognuno di questi router elaborerà il datagramma come se fosse un ordinario datagramma IPv4. Questi sono completamente ignari del fatto che il datagramma sta trasportando dati IPsec criptati. Per i router della rete pubblica Internet, il datagramma deve essere consegnato al router R2. Ai router intermedi non interessa sapere altro.
Dalla figura si vede che il campo ESP trailer consiste di tre campi: riempimento, lunghezza del riempimento e next header. Si ricordi che i cifrari a blocchi richiedono che il messaggio che deve essere criptato abbia una lunghezza multipla della lunghezza di un blocco. Il riempimento (costituito da byte privi di significato) è usato allo scopo di aggiungerlo al datagramma originale (insieme ai campi lunghezza riempimento e next header), e ottenere un messaggio che abbia una lunghezza tale da essere costituito da un numero intero di blocchi. Il campo lunghezza del riempimento indica all'entità destinataria, quanto riempimento è stato inserito. (e quindi deve essere rimosso). Il campo next header identifica il tipo (es. UDP) di dati contenuti nel campo payload. I dati edl payload (il datagramma originale IP) e il campo ESP trailer sono concatenati e criptati.
In testa a questa parte criptata, viene aggiunta l'ESP header, che viene trasmesso in chiaro e consiste di due campi: il campo SPI ed il campo numero di sequenza. Il campo SPI indica all'entità ricevente la SA a cui appartiene il datagramma; l'entità ricevente può usare questo valore SPI come indice di accesso al suo SAD per determinare gli appropriati algoritmi di autenticazione/decriptografia e le chiavi. il campo numero di sequenza serve per difendersi dagli attacchi di ripetizione.
L'entità mittente aggiunge anche un MAC di autenticazione. L'entità mittente calcola un MAC sull'intero enchilada (consistente dell'ESP header, del datagramma IP originale, e dell'ESP trailer (in cui il datagramma e il trailer sono criptati). Si ricordi che per calcolare un MAC, il mittente concatena una chiave segreta all'enchilada e calcula un hash di lunghezza fissa del risultato.
Quando R2 riceve il datagramma IPsec, R2 osserva che l'indirizzo IP di destinazione del datagramma è R2 stesso. R2 quindi elabora il datagramma. Poichè il campo protocollo (nell'intestazione più a sinistra del pacchetto) è 50, R2 sa che deve applicare l'elaborazione IPsec ESP al datagramma. Primo, R2 usa il campo SPI per determinare a quale SA appartiene il datagramma. Secondo, calcola il MAC dell'enchilada e verifica che il MAC corrisponde al valore contenuto nel campo ESP MAC. Se i due valori sono uguali, R2 sa che l'enchilada proviene da R1 e non è stato falsificato lungo il percorso. Terzo, controlla il campo numero di sequenza per verificare che il datagramma è quello atteso (e non una copia registrata e ripetuta). Quarto, decripta i dati usando l'algoritmo e la chiave specificati nella SA. Quinto, rimuove il riempimento ed estrae il datagramma originale. Ed infine, sesto, consegna il datagramma originale alla rete periferica, dove raggiungerà la destinazione finale.
Resta ancora un importante problema da risolvere. Quando R1 riceve un datagramma (in chiaro, non riservato) da un host nella rete della sede principale, e quel datagramma è destinato ad un host esterno, come fa R1 a sapere se lo deve convertire in un datagramma IPsec e, in tal caso, come fa R1 a sapere qual è la SA che deve usare per costruire il datagramma IPsec? La soluzione è la seguente: insieme al SAD, l'entità IPsec gestisce anche una struttura dati chiamata Security Policy Database (SPD). Il SPD indica quali tipi di datagrammi (a seconda dell'indirizzo IP sorgente, dell'indirizzo IP destinazione e del protocollo) devono essere elaborati in IPsec, e per quelli che devono essere elaborati in IPsec, quale SA deve essere usata. In altri termini, si uò dire che le informazioni nel SPD indicano cosa fare con un datagramma entrante, le informazioni nel SAD indicano come farlo.
IKE: Key Management in IPsec
Quando una VPN ha un piccolo numero di sistemi terminali (ad esempio, solo due router), l'amministratore di rete può inserire manualmente le informazioni della SA (algoritmi di criptografia e di autenticazione e chiavi, e gli SPI) nei SAD dei sistemi terminali. Queste operazioni manuali, sono improponibili. quando la VPN è grande, composta da centinaia di router e hosts IPsec. In una rete molto grande e dispersa geograficamente si richiede un meccanismo automatico per creare le SA. IPsec usa, per questo scopo, il protocollo Internet Key Exchange (IKE).
IKE ha alcune analogie con l'handshake in SSL. Ogni entità IPsec ha un certificato, che include la chiave pubblica dell'entità. Come in SSL, il protocollo IKE prevede che le due entità si scambino i certificati, negozino gli algoritmi di criptografia e di autenticazione, e si scambino con sicurezza la chiave per creare le chiavi di sessione nella SA. A differenza di SSL, IKE impiega due passi per compiere queste operazioni.
Sempre con riferimento alla figura precedente, la prima fase consiste nello scambio di due messaggi tra R1 e R2:
Durante il primo scambio di messaggi, i due lati usano l'algoritmo di Diffie-Hellman per creare una IKE-SA bidirezionale tra i router. Questa IKE-SA bidirezionale è completamente differente dall'IPsec SA descritta prima. L'IKE SA fornisce un canale autenticato e criptato tra i due router. Durante questo primo scambio di messaggi, vengono decise le chiavi per criptare e autenticare l'IKE SA. Viene anche decisa una master secret che servirà per calcolare le chiavi IPSec SA nela secoda fase. Durante questo primo passo, le chiavi RSA pubblica e privata non sono usate. In particolare, né R1 né R2 rivela la sua identità firmando un messaggio con la sua chiave privata.
Durante il secondo scambio di messaggi, entrambi i lati rivelano la propria identità l'uno all'altro, firmando i messaggi. Comunque le identità non sono rivelate ad uno sniffer passio, perchè i messaggi sono trasmessi sul canale sicuro IKE SA. Inoltre, durante questa fase, i due lati negoziano gli algoritmi di criptografia e autenticazione IPsec che saranno impiegati dalle IPsec SA.
Nella fase 2 di IKE, i due lati creano una SA in ciascuna direzione. al termine della fase 2, vengono decise le chiavi di sessione per criptare e autenticare su entrambi i lati della SA. I due estremi possono inviare datagrammi sicuri usando le SA. Lo scopo di avere due fasi in IKE è il costo del calcolo, poichè la seconda fase non coinvolge la criptografia a chiave pubblica, IKE può generare moltissime SA tra due entità IPsec con costi molto bassi.