Come lavora IPsec
IPsec lavora applicando al pacchetto IP originale dei protocolli di sicurezza che come dice il nome hanno la funzione di proteggerlo. La protezione viene fatta incapsulando il pacchetto IP in base alle modalità di funzionamento dei protocolli di sicurezza e del tipo di servizio di sicurezza che si vuole ottenere sul traffico. IPsec usa due protocolli di sicurezza per fornire sicurezza al traffico dei dati AH (Autentication Header) ed ESP (Encapsulating Security Payload). Le implementazioni di IPsec devono supportare ESP e possono supportare AH.
I protocolli di sicurezza AH ed ESP
Questi protocolli di sicurezza vanno scelti in base alle necessità in cui si deve trovare il traffico dei dati:
- Se il traffico necessita di autenticazione e di integrità con il protocollo AH, e opzionalmente (cioè a discrezione del ricevente) la protezione contro gli attacchi da ripetizione di pacchetto.
- Se necessita anche di protezione crittografica oltre che di integrità e autenticazione con il protocollo ESP.
- Se necessita di protezione crittografica + autenticazione e integrità con ESP + AH.
Questi due protocolli (AH e ESP) si applicano al protocollo IP modificando in maniera sostanziale il pacchetto IP e sono indipendenti dagli algoritmi di cifratura.
Numeri di protocollo del campo “Protocol”/“Next Header” di AH ed ESP (Assigned Numbers RFC 1700)
Per poter usare in maniera uniforme e standardizzata i protocolli di internet come l’IP (Internet Protocol) è richiesto che, i valori di particolari campi siano assegnati in modo univoco come il campo “Protocol” in IPv4 (RFC 791). In IPv6 (RFC 2460) questo campo è chiamato “Next Header”. Questo è un campo che nelle due versioni di IP è lungo 8 bit (256 valori differenti) ed anche se nelle due versioni hanno nomi differenti (Protocol e Next Header) hanno la stessa funzione, indicare al processore di destinazione il prossimo header da processare. Il processore deve elaborare sempre gli header che arrivano secondo l’ordine in cui appaiono nel datagramma. Il datagramma IP v4 o v6 incapsula sempre al suo interno uno o più header/protocolli che trasportano informazioni. Se questi header trasportano informazioni di livello Internet vengono chiamati extension header e si trovano tra l’header IP e l’header di livello superiore; se sono di livello Transport sono i normali header di livello superiore (TCP, UDP ecc.). Quindi, il campo, questo campo, indica nel valore rappresentato un distinto tipo di header/ protocol che seguirà (Next Header).
Ne sono previsti vari tipi e gli stessi valori del campo “protocol” di IPv4 sono usati dal campo ”Next Header” di IPv6 . I valori di questo campo sono stabiliti univocamente dallo IANA (Internet Assigned Numbers Autority).
La logica di questa assegnazione da parte di una autorità di internet, lo IANA (Internet Assigned Numbers Autority) è dovuta alla necessità di coordinare ed assegnare in modo univoco i valori di questo campo e di altri parametri dei protocolli usati in Internet. Lo IANA ha pubblicato questi valori in una tabella detta degli “Assigned Internet Protocol Numbers” RFC 1700.
Per quello che riguarda i due protocolli di sicurezza usati da IPsec i valori sono rispettivamente per ESP di 50 e per AH di 51.
Decimal Keyword Protocol References ------- ------- -------- --------- 50 ESP Encapsulation Security Payload [RFC4303]
Authentication Header (AH) RFC 4302
Il protocollo di sicurezza Authentication Header (AH) fornisce i seguenti servizi di sicurezza:
- L’autenticazione dell’origine dei dati.
- L’integrità per pacchetti IP connectionless spediti tra due sistemi.
- Un servizio di protezione anti-replay (facoltativo a discrezione del ricevente) attraverso l’uso di un numero di sequenza.
Il protocollo AH fornisce i servizi di autenticazione ed integrità al datagramma IP ad entrambe le interfacce finali del tunnel.
Il servizio opzionale anti-replay verifica che ogni pacchetto sia unico, non duplicato.
IMPORTANTE: il protocollo Authentication Header NON fornisce riservatezza ai dati trasportati (nessuna Cifratura) che di conseguenza vengono trasmessi in chiaro.
Come lavora il protocollo AH
Per cominciare una disamina di come il protocollo AH lavora è necessario stabilire a priori la modalità di funzionamento. Il protocollo AH può essere impiegato in due modi: tunnel mode o transport mode. La prima maniera (transport mode) che ora andremo ad esaminare è applicabile solamente alle implementazioni su host e offre i suoi servizi di protezione per i protocolli di livello superiori, ma non all’header di IP cosa che invece fa la seconda maniera (tunnel mode).
Step 1 – L’apparecchiatura sorgente di IPsec riceve un pacchetto IP. Su questo pacchetto compie una funzione hash calcolandoci un HMAC. Questo algoritmo (HMAC) compie un calcolo di hash One-Way sul pacchetto. Concatenando al pacchetto una chiave segreta condivisa fra i pari partecipanti. Il Pacchetto su cui compiere questo calcolo va dal payload fino a comprendere i campi dell’header IP che non possono cambiare durante il transito sulla rete. AH supporta gli algoritmi di hash HMAC-MD5, HMAC-SHA-1 e AES-XCBC-MAC-96.
La gestione dei campi Immutabili/Mutabili dell’header IP
I campi immutabili dell’header IPv4 sono:
- Version
- Internet Header Length
- Total Length
- Identification
- Protocol
- Source IP Address
- Destination IP Address
Questi campi vengono tutti inclusi nel calcolo di un HMAC.
Campi mutabili dell’header IPv4:
- Type of Service (TOS)
- Flags
- Fragment Offset
- Time to Live (TTL)
- Header Checksum
TOS – Questo campo viene escluso dal calcolo dell’HMAC perché alcuni router cambiano il valore di questo campo durante il percorso.
Flags – Questo campo viene escluso dal calcolo dell’HMAC settando i bit di DF, anche se la sorgente non lo setta.
Fragment Offset – Questo campo viene escluso dal calcolo dell’HMAC perché AH viene applicato solamente ai pacchetti IP non-frammentati, il campo Fragment Offset deve essere sempre settato a zero (anche se è prevedibile).
TTL – Questo campo viene escluso dal calcolo dell’HMAC perché viene modificato dai router durante il normale percorso di instradamento, e così il suo valore non è prevedibile dal mittente.
Header Checksum – Questo campo viene escluso dal calcolo dell’HMAC perché è destinato a cambiare se i campi mutabili cambiano, viene ricalcolato da ogni nodo che attraversa e così il suo valore non può essere predetto dal mittente.
Campi mutabili dell’header IPv6:
Hop Limit – Questo campo viene escluso dal calcolo dell’HMAC perché viene modificato dai router durante il normale percorso di instradamento, e così il suo valore non è prevedibile dal mittente.
I campi mutabili precedentemente descritti hanno tutti i valori settati a zero (0) per poter realizzare su tutto il pacchetto un calcolo di HMAC. L’approccio di riempire con dei zero i campi mutabili prima del calcolo dell’HMAC assicura che la lunghezza dei campi e quindi la struttura generale dell’header IP non possa essere modificata.
Step 2 – L’HMAC del messaggio risultante troncato ai primi 96 bit (valore authenticator) viene usato in parte per costruire un header AH. Questo header AH viene inserito nel pacchetto originale IP tra l’header IP e l’header del livello trasporto. Modificando in maniera sostanziale l’originale datagramma IP viene creato un nuovo pacchetto per il transito. Questo nuovo datagramma avrà però un header IP modificato rispetto all’originale. E sarà modificato il valore del campo protocol in IPv4 o next header in IPv6. A seguire un pacchetto IP nuovo, reso sicuro (con i servizi di integrità ed autenticazione) dal protocollo AH, viene inviato al destinatario. L’HMAC che si trova all’interno del header AH offrirà un valore di controllo (campo authenticator) al ricevente che consente di verificare se i dati sono stati modificati durante il transito.
AH fornisce l’autenticazione per gran parte dell’header IP, così come per i dati di protocollo dei livelli superiori. Ad eccezione dei campi mutabili dell’IP header che così non sono protetti da AH. Questo significa che AH non offre una protezione completa all’IP header. Inoltre AH non offre servizi di cifratura per la riservatezza dei dati (payload). Ovvero il protocollo AH offre una sicurezza limitata perchè i dati sono trasmessi in chiaro.
Il formato dell’header AH
Il formato dell’header AH è lungo almeno 24 byte. Ed è formato da 6 campi. Tutti i campi che descriveremo sono sempre presenti nella configurazione di AH e sono sempre inclusi nel calcolo di controllo dell’integrità ICV (Integrity Check Value) che è il campo autenticatore.
Next Header
Il primo campo è detto Next Header, è un campo di 8 bit che identifica il tipo di protocollo che verrà dopo l’header di AH. Ovvero indicano al processore di destinazione il prossimo header da trattare o processare. Il valore di questo campo viene scelto da un set di numeri di protocolli IP definiti dallo IANA (Internet Assigned Numbers Authority) e pubblicati in una tabella RFC 1700. Ad esempio in tunnel mode viene incapsulato un intero datagramma IPv4, il valore di questo campo è 4. Quando invece in transport mode viene incapsulato un pacchetto TCP, il valore è 6. Il valore di 41 indica un datagramma IPv6.
Payload Length
Il campo seguente è detto Payload Length ed è di 8 bit che indica la lunghezza del payload in parole di 32-bit (unità da 4 byte) meno 2.
Reserved
Il campo successivo è detto Reserved, è un campo di 2 byte riservati per usi futuri. Deve essere settato a zero dal mittente e deve essere ignorato dal ricevente. Il valore di questo campo è incluso nel calcolo ICV.
Security Parameters Index (SPI)
Segue un campo detto SPI (Security Parameter Index), è un campo di 4 byte contenenti un valore arbitrario di 32 bit, che in combinazione con l’indirizzo IP di destinazione e il protocollo di sicurezza (AH) serve al ricevente ad identificare univocamente la Security Association per questo datagramma.
Il set dei valori di SPI nel range che va da 1 a 255 è riservato dallo IANA (Internet Assigned Numbers Authority) per usi futuri. Normalmente questi valori sono selezionati dal sistema di destinazione durante lo stabilimento di una SA (Security Association). Il valore SPI di zero (0) è riservato per uso locale e quindi non viene mai utilizzato nelle trasmissioni.
Sequence Number
Il campo Sequence Number, è un campo di 32 bit necessario per proteggersi da attacchi di tipo replay. Questo campo di 32-bit contiene un contatore che incrementa di valore (numero di sequenza) per ogni pacchetto inviato. La trasmissione di questo campo è obbligatoria per il mittente, anche se il ricevente non abilita il meccanismo di protezione anti-ripetizione per una specifica SA. Infatti, la protezione anti-ripetizione è un servizio opzionale e l’utilizzo del campo Sequence Number ai fini della sicurezza è a discrezione del ricevente. Il mittente deve sempre trasmettere questo campo, ma il ricevente può anche non abilitare questo servizio. Questo servizio viene concretamente utilizzato solamente se il ricevente controlla il numero di sequenza del pacchetto. Questo avviene verificando che ogni pacchetto sia unico, non duplicato e si ottiene settando il replay bit ad 1 nell’header per indicare che il pacchetto è stato ricevuto.
Il contatore del mittente e il contatore del ricevente vengono inizializzati a 0 quando viene stabilita una SA. Il primo pacchetto spedito usando una determinata SA avrà un Sequence Number di uno (1); Se un meccanismo anti-ripetizione viene abilitato(di default), il Numero di Sequenza trasmesso non può essere casuale ma deve sincronizzarsi ogni volta con il ricevente. Così, il contatore del mittente e il contatore del ricevente devono essere azzerati ogni volta che viene stabilita una nuova Associazione di Sicurezza (SA) ed una nuova chiave su una SA. Naturalmente dato che il campo Sequence Number è lungo 32 bit il numero massimo che il contatore può raggiungere è di 2^32-1 ovvero numero 4.294.967.295 quattro miliardi 294 milioni 967 mila 295 pacchetti.
Integrity Check Value (ICV): Authentication Data
Infine il campo Integrity Check Value (ICV), è un campo di lunghezza variabile e serve per autenticare i dati trasportati. Il campo deve essere un multiplo integrale di 32 bit (per IPv4) o di 64 bit per (IPv6) di lunghezza. Questo campo può includere esplicitamente un padding. Questo padding viene incluso nel campo per assicurare che la lunghezza dell’header di AH sia un multiplo integrale di 32 bit (IPv4) o di 64 bit (IPv6). Tutte le implementazioni devono supportare il padding in questo campo per soddisfare i requisiti di allineamento. Questo campo contiene l’HMAC troncato ai primi 96 bit (Hash Message Authentication Code) che è il valore di controllo dell’integrità del pacchetto Integrity Check Value (ICV). Quest’ultimo protegge l’integrità del pacchetto poiché solo chi conosce la chiave segreta può ri-creare l’hash completo, troncarlo a 96 bit e compararlo con quello ricevuto per verificarne l’esattezza.
Step 3 – Il nuovo pacchetto viene trasmesso dal pari IPsec sorgente verso il destinatario IPsec.
Step 4 – Il destinatario IPsec ricevuto il pacchetto estrae l’header di AH dal pacchetto e sul rimanente ricalcola l’HMAC usando il valore di chiave condiviso con la sorgente. Questo HMAC viene troncato ai primi 96 bit. Questi formano il valore authenticator (ICV).
Step 5 – Il destinatario IPsec estrae il valore authenticator di 96 bit (l’HMAC) ricevuto dall’header di AH.
Step 6 – Il destinarlo IPsec a questo punto compara i due valori di hash (ricevuto e ricalcolato). Se i due hash combaciano precisamente (in gergo tecnico si dice che devono matchare) vuole dire che l’autenticità è garantita. Anche se solo uno dei bit dei pacchetti è stato modificato durante la trasmissione, l’output dell’hash sul pacchetto ricevuto cambia, e il pacchetto viene scartato. Il fatto che l’hash One-Way (HMAC) comporta anche l’uso di una chiave segreta simmetrica tra i due sistemi vuole dire che viene garantita l’autenticità.
AH è qui stato implementato nella modalità Transport Mode
AH può essere usato da solo, o in combinazione con il protocollo ESP (Encryption Service Payload), o attraverso l’uso di tunnel mode in cui l’intero pacchetto IP originario viene incapsulato in un nuovo pacchetto. AH da solo non fornisce riservatezza ovvero, NON fornisce nessuna protezione crittografica ai dati. Ogni testo è trasportato in chiaro.
Continua a leggere VPN ovvero Reti Private Virtuali: Tecnologia IPsec v3 – 6a parte
