IPsec HOWTO
PrevNext

2. Teoria

2.1. Cosa è IPsec?

IPsec è un estensione del protocollo IP che fornisce sicurezza a livello IP ed ai livelli superiori. È stato sviluppato prima all'interno dello standar IPv6 ed in seguito inserito in Ipv4. L'architettura di IPsec viene descritta nell'RFC2401. I seguenti paragrafi rappresentano una breve introduzione al protocollo.

IPsec usa due differenti protocolli - AH ed ESP - per fornire l'autenticazione, l'integrità e la confidenzialità della comunicazione. Può proteggere l'intero datagramma IP o solamente i protocolli di alto livello. I diversi modelli di funzionamento sono detti tunnel mode e transport mode. Nel tunnel mode il datagramma IP viene completamente incapsulato in un nuovo datagramma IP utilizzando IPsec. In transport mode solo il payload del datagramma IP viene trattato da IPsec che inserisce il proprio header tra l'header IP ed i livelli superiori (si veda Figure 1).

Figure 1. IPsec tunnel e transport mode

Per proteggere l'integrità di un datagramma IP il protocollo IPsec utilizza meccanismi di autenticazione basati su codici hash (HMAC).Per ottenere questo HMAC vengono usati algoritmi come MD5 o SHA per calcolare un hash basato su una chiave segreta e sul contenuto di un datagramma IP. L'HMAC viene quindi inserito nell'header IPsec ed il destinatario del pacchetto ne può verificare l'esattezza soltanto avendo accesso alla chiave segreta.

Per proteggere la confidenzialità di un datagramma IP il protocollo IPsec utilizza degli algoritmi di cifratura simmetrici. L'IPsec richiede l'implementazione di NULL (nessuna cifratura) e del DES. Attualmente vengono utilizzati algoritmi più robusti come 3DES, AES ed il Blowfish.

Per proteggersi contro un attacco di tipo denial of service, il protocollo IPsec utilizza un meccanismo di sliding window. Ciascun pacchetto possiede un numero di sequenza e viene accettato solo se tale numero rientra nella finestra o è più recente. I pacchetti più vecchi vengono immediatamente scartati. Questo protegge da attacchi di tipo replay, nei quali pacchetti originali vengono conservati e rispediti in seguito.

Perchè le due parti siano in grado di effettuare l'incapsulamento ed il recupero dei pacchetti IPsec è necessario che vi sia un luogo nel quale conservare le chiavi, gli algoritmi e gli indirizzi IP coinvolti nella comunicazione. Tutti questi parametri necessari per la protezione del datagramma IP, sono inseriti in una security association (SA). Le security association vengono conservate a turno in un database detto SAD (security association database).

Ciascuna security association definisce i seguenti parametri:

Alcune implementazioni di security association database permettono inoltre di immagazzinare:

Poichè la security association contiene l'IP sorgente e destinazione, può proteggere una sola direzione in una connessione full duplex. Per proteggere entrambe le direzioni sono necessarie due security association.

Una security association specifica solo come proteggere il traffico. Sono necessarie ulteriori informazioni per definire quale tipo di traffico proteggere. Queste informazioni sono contenute in una security policy (SP) e immagazzinate a turno in un security policy database (SPD).

Una security policy specifica normalmente i seguenti parametri:

Il setup manuale di una security association è passibile di errore e non molto sicuro. La chiave segreta e gli algoritmi di crittografia devono essere condivisi dalle due parti di una virtual private network. È soprattutto lo scambio di chiavi a mettere in crisi gli amministratori di sistema: come scambiarsi una chiave simmetrica senza un canale cifrato già attivo?

Per risolvere questo problema è stato sviluppato l'internet key exchange protocol (IKE). Nella prima fase quest'ultimo autentica le due parti. Nella seconda la security association viene negoziata e le chiavi simmetriche vengono scambiate attraverso il metodo Diffie Hellmann. Il protocollo IKE rinegozia periodicamente le chiavi per garantire la confidenzialità.

2.2. Il protocollo IPsec

La famiglia di protocolli IPsec è composta da: Authentication Header (AH) e Encapsulated Security Payload (ESP). Entrambi sono indipendenti dai protocolli IP. AH è il protocollo IP 51 ed ESP è il 50 (si veda /etc/protocols). Le due sezioni seguenti presentano brevemente le loro caratteristiche.

2.2.1. AH - Authentication Header

Il protocollo AH protegge l'integrità del datagramma IP, calcola un HMAC del pacchetto in base ad una chiave segreta, al payload e le parti del header IP che non possono cambiare, ad esempio i campi con gli indirizzi IP. Quindi aggiunge l'header AH all'header del pacchetto.

Figure 2. L'Header AH protegge l'integrità del pacchetto

L'header AH è lungo 24 bytes. Il primo byte è detto Next Header, contiene il protocollo dell'header seguente. In tunnel mode viene incapsulato un intero datagramma IP: il valore di questo campo è dunque 4. Quando invece in transport mode viene incapsulato un pacchetto TCP, il valore è 6. Il byte seguente indica la lunghezza del payload. Quindi vi sono 2 byte riservati. Seguono 32 bit contenenti il Security Parameter Index (SPI), che indicano quale SPI utilizzare per interpretare correttamente il pacchetto al momento della ricezione. I successivi 32 bit sono per il Sequence Number, per proteggersi da attacchi di tipo replay. Infine gli ultimi 96 bit contengono l'hash message authentication code (HMAC). Quest'ultimo protegge l'integrità del pacchetto poichè solo chi conosce la chiave segreta può crearlo e verificarne l'esattezza.

Poichè il protocollo AH calcola l'HMAC in base ad alcune parti non mutabili del datagramma IP, tra le quali gli indirizzi, il NAT non si sposa bene con IPsec. Il Network address translation (NAT) sostituisce infatti un IP (di solito il sorgente) con uno differente. Quindi l'HMAC viene invalidato subito. Un'estensione al protocollo detta NAT-Traversal extension riesce però a superare questa limitazione.

2.2.2. ESP - Encapsulated Security Payload

Il protocollo ESP può garantire sia l'integrita di un pacchetto utilizzando HMAC sia la confidenzialità della trasmissione utilizzando la cifratura. Dopo aver cifrato il pacchetto e calcolato l'HMAC viene generato ed aggiunto l'header ESP. L'header ESP si compone di due parti, mostrate in Figure 3.

Figure 3. Header ESP

I primi 32 bit sono il Security Parameter Index (SPI), indicano quale SA utilizzare per interpretare correttamente il pacchetto ESP al momento della ricezione. I successivi 32 bit contengono il Sequence Number, per proteggersi da attacchi di tipo replay. Seguono 32 bit per l'Initialization Vector (IV), utilizzato durante le operazioni di cifratura. Gli algoritmi di crittografia simmmetrica sono vulnerabili ad attacchi statistici se non viene utilizzato un IV. Quest'ultimo infatti assicura che due payload in chiaro identici producano due versioni cifrate differenti.

IPsec utilizza cifrari a blocchi per il processo di cifratura. Dunque il payload deve essere completato (padding) nel caso in cui non risulti un multiplo della dimensione del blocco. Quindi la lunghezza dell'eventuale pad viene inserita nell'header. Subito dopo 2 byte indicano quale sia l'header del protocollo sottostante, Next Header. Infine vengono aggiunti 96 bit con l'HMAC per garantire l'integrità del pacchetto. L'HMAC è calcolato sul payload, l'header IP non viene considerato.

L'utilizzo del NAT non rende inutilizzabile il protocollo ESP. Ma nonostante questo il NAT nella maggior parte dei casi non può essere utilizzato in combinazione con IPsec. Il NAT-Traversal è una possibile soluzione al problema incapsulando i pacchetti all'interno di pacchetti UDP.

2.3. Protocollo IKE

Il protocollo IKE risolve la maggior parte dei problemi a cui abbiamo accennato nell'instaurazione di una connessione sicura: l'autenticazione delle parti e lo scambio di chiavi simmetriche. Crea inoltre le security association e popola il SAD. IKE utilizza di solito un demone in user space e non viene inclusa nel sistema operativo. IKE utilizza la porta 500/udp per la comunicazione tra le parti.

Il protocollo IKE consta di due fasi: la prima realizza una Internet Security Association Key Management Security Association (ISAKMP SA). Nella seconda l'ISAKMP SA viene utilizzata per la negoziazione e l'instaurazione delle IPsec SA.

L'autenticazione delle parti nella prima fase può di solito essere basata su pre-shared keys (PSK), RSA keys e certificati X.509 (racoon supporta anche Kerberos).

La prima fase può utilizzare di solito due differenti modalità: main mode ed aggressive mode. Entrambe autenticano le parti e stabiliscono una ISAKMP SA, ma l'aggressive mode è in grado di farlo utilizzando la metà dei messaggi. Il prezzo da pagare per la maggior velocità è l'assenza del supporto per l'identificazione dei partecipanti e quindi la possibilità di attacchi di tipo man-in-the-middle nel caso di utilizzo di pre-shared keys. Questo però è anche il solo scopo dell'aggressive mode. Il main mode infatti è strutturato per non accettare preshared keys differenti da macchine sconosciute. L'aggressive mode non supporta alcuna forma di identificazione delle due parti e trasferisce l'identità del client in chiaro. Le due parti si devono conoscere prima che l'autenticazione avvenga e chiavi differenti possono venire utilizzate per partecipanti differenti.

Nella seconda fase vengono negoziate le security association utilizzando l'ISAKMP SA appena instaurata. Quest'ultima fornisce i meccanismi di autenticazione necessari a proteggersi contro attacchi man-in-the-middle. Questa seconda fase utilizza il quick mode.

Di norma le due parti negoziano una sola ISAKMP SA, che utilizzano per creare diverse (almeno due) IPsec SA unidirezionali.

PrevHomeNext
Introduzione Linux Kernel 2.2 and 2.4 -- FreeS/WAN