Encapsulated Security Payload (ESP) RFC 4303
Il protocollo di sicurezza Encapsulated Security Payload (ESP) fornisce i seguenti servizi di sicurezza:
- L’autenticazione dell’origine dei dati
- L’integrità per pacchetti IP connectionless spediti tra due sistemi.
- La riservatezza dei dati con la cifratura
- Un servizio opzionale di protezione contro le ripetizioni (una forma parziale dell’integrità di sequenza).
- Una limitata riservatezza del flusso di traffico (sconfiggendo così l’analisi del flusso di traffico).
L’autenticazione dell’origine dei dati e l’integrità dei dati connectionless sono due servizi strettamente connessi e vengono offerti come una unica opzione effettuata attraverso l’uso di una chiave condivisa, simmetrica da scegliere in congiunzione con il servizio di riservatezza che è opzionale. Questi due servizi congiunti vengono forniti attraverso l’uso degli stessi algoritmi usati da AH e cioè impiegando un algoritmo HMAC, che può essere realizzato con SHA-1/RFC 2404, MD5/RFC 2403 o AES-XCBC-MAC-96/RFC 3566.
La riservatezza è una scelta “opzionale” e può essere selezionata e implementata indipendentemente da tutti gli altri servizi, e viene portata a termine compiendo la cifratura del pacchetto al livello IP. La Cifratura del pacchetto IP nasconde il payload dei dati e l’identità finale della sorgente e della destinazione. ESP supporta gli algoritmi di cifratura simmetrica come il DES, 3DES e AES. Comunque, l’uso della riservatezza senza selezionare l’autenticazione o l’integrità, sia in ESP che separatamente in AH, può sottoporre il traffico a certe forme di attacchi attivi che possono minare il servizio di riservatezza ed è quindi sconsigliato non farne uso. Da notare che anche se, la riservatezza e l’autenticazione sono in ESP dei servizi opzionali, almeno uno di loro deve essere necessariamente selezionato.
La protezione anti-replay verifica che ogni pacchetto sia unico, non duplicato. La scelta di sfruttare il servizio anti-ripetizione si può selezionare solamente se l’autenticazione dell’origine dei dati viene selezionata. Questa scelta non può essere fatta dal mittente infatti, la scelta di questo servizio è a discrezione del ricevente. Anche se di default i pacchetti inviati dal mittente incrementano automaticamente il numero di sequenza usato per il servizio anti-ripetizione, il servizio viene effettivamente usato solo se il ricevente controlla il numero di sequenza settando ad 1 il bit di ripetizione dell’header.
La limitata riservatezza del flusso di traffico richiede di selezionare la modalità di trasmissione denominata “tunnel mode”. La riservatezza del flusso di traffico diventa effettiva se viene implementata su un security gateway dove l’aggregazione del traffico può essere capace di mascherare i veri percorsi di sorgente-destinazione. Un attaccante che monitorizzasse il traffico di rete su un segmento non saprebbe quali pari stanno comunicando. Comunque, la riservatezza del flusso di traffico è limitata dal fatto che possono essere contati il numero di pacchetti che vengono scambiati su un segmento.
ESP incapsula avvolgendo completamente il pacchetto IP. Il protocollo ESP può essere utilizzato da solo o insieme al protocollo AH. ESP usato congiuntamente ad AH sfrutta i suoi servizi di sicurezza (l’integrità e l’autenticazione) per offrire una maggiore protezione al datagramma. Durante l’utilizzo di IPsec, bisogna assicurarsi che ogni routers perimetrale permetta il passaggio del traffico sulle porte TCP 50 e 51 mentre per ISAKMP la porta da tenere aperta è la 500 del protocollo UDP.
Il set di servizi fornito da questo protocollo dipende dalle scelte selezionate durante lo stabilimento delle Associazioni di Sicurezza (SA) e sulla disposizione della implementazione.
Come lavora il protocollo ESP
Per cominciare una disamina di come il protocollo ESP lavora è necessario stabilire a priori la modalità di funzionamento. Come con il protocollo AH, il protocollo ESP può essere impiegato in due modi: transport mode o tunnel mode. La prima maniera (transport mode) è applicabile solamente alle implementazioni su host e offre protezione per i protocolli di livello superiori, ma non all’header di IP cosa che invece fa la seconda maniera (tunnel mode) e che ora andremo ad esaminare.
Step 1L’apparecchiatura sorgente di IPsec riceve un pacchetto IP. Questo pacchetto IP viene interamente cifrato. Utilizzando a questo scopo degli algoritmi di cifratura simmetrica come il DES, 3DES o AES.
Step 2A questo punto viene generato un pacchetto ESP. Questo ESP avvolge completamente il Payload Data (cifrato) con un header e un trailer ESP.
Il formato del protocollo ESP protegge l’integrità del pacchetto
Il formato del pacchetto ESP si compone di due parti, header ESP ed Trailer ESP che avvolgono il Payload Data ed è mostrato nella figura sotto. E’formato da 8 campi.
Le seguenti descrizioni definiscono i campi del formato dell’header ESP.
Security Parameters Index
Il primo campo di 32 bit è il Security Parameter Index (SPI), ed è un valore arbitrario che, in combinazione con l’indirizzo IP di destinazione e il protocollo di sicurezza (ESP), identifica univocamente l’Associazione di Sicurezza (SA) per questo datagramma. Questo consente di tenere traccia della Security Association (SA) corrente tra due apparecchiature IPsec per interpretare correttamente il pacchetto ESP al momento della ricezione.
Il set di valori dello SPI nel range da 1 a 255 è riservato dallo IANA (Internet Assigned Number Autority) per un uso futuro; un valore SPI riservato non sarà assegnato normalmente dallo IANA a meno che l’uso del valore di SPI assegnato non sia specificato in una RFC. Di norma il valore SPI viene selezionato dal sistema di destinazione durante lo stabilimento di una SA. Il valore SPI di zero (0) è riservato per usi locali, e non viene mai trasmesso. L’implementazione del campo SPI in ESP è obbligatorio.
Sequence Number
Il secondo campo è di 32-bit ed è chiamato Sequence Number, contiene un contatore del numero di sequenza necessario per proteggersi da attacchi di tipo replay. La compilazione di questo campo è obbligatorio per il mittente ed è sempre presente anche se il ricevente non abilita il servizio di protezione anti-ripetizione per una specifica SA. Difatti 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 numero di Sequenza di 1. Se un meccanismo anti-ripetizione viene abilitato(di default), il Numero di Sequenza trasmesso non è mai scelto casualmente, ma deve avere un ordine cronologico preciso per sincronizzarsi ogni volta con il ricevente. Così, il contatore del mittente e il contatore del ricevente devono essere azzerati/resettati ogni volta che viene stabilita una nuova Associazione di Sicurezza (SA) e viene stabilita una nuova chiave su una SA prima della trasmissione del pacchetto N° 2^32 su una SA (numero limite massimo di trasmissione di pacchetti su una SA infatti, il campo è lungo 32 bit).
Initialization Vector
Segue il campo di 32 bit Initialization Vector (IV), utilizzato durante le operazioni di cifratura. Gli algoritmi di crittografia simmetrica sono vulnerabili ad attacchi statistici se non viene utilizzato un Vettore di Inizializzazione (IV). Quest’ultimo infatti assicura che due payload in chiaro identici producano due versioni cifrate differenti.
A questo punto viene inserito il pacchetto IP cifrato che compone il campo Payload Data.
Payload Data
Il campo Payload Data è di lunghezza variabile e contiene i dati descritti nel campo Next Header. Il campo Payload Data è obbligatorio e può avere una lunghezza variabile ma, comunque deve essere un numero intero calcolato in byte. Se l’algoritmo usato per cifrare il payload richiede una sincronizzazione dei dati, è necessario utilizzare un Vettore di Inizializzazione (IV). Questo Vettore di Inizializzazione (IV) in base all’algoritmo utilizzato può essere immesso separatamente all’inizio del ciphertext o cifrato all’interno del campo Payload.
Padding
Il campo padding è un campo di lunghezza variabile da (0-255 byte). IPsec utilizza cifrari a blocchi per il processo di cifratura. Dunque il campo Payload Data deve essere completato da un (padding) per permettere un giusto allineamento nel caso in cui il campo non risulti un multiplo della dimensione del blocco. Ogni algoritmo di cifratura che richiede il Padding oltre che per default, deve definire il contenuto del padding (ad esempio se è composto di tutti zero (0) o di dati casuali). Il ricevente deve trattare questi byte di padding secondo le specifiche richieste dall’algoritmo di cifratura usato da ESP. In tali circostanze, il contenuto del campo di Padding sarà determinato dall’algoritmo di cifratura. L’algoritmo relativo può specificare che il ricevente deve ispezionare il campo di padding o che il ricevente deve informare il mittente di come il ricevente gestirà il campo di padding.
Pad Length
Il campo Pad Length indica la lunghezza in byte del campo padding immediatamente precedente. Il range dei valori validi è da 0 a 255, dove il valore di 0 indica che non è presente nessun byte di padding. Il campo di Pad Length è obbligatorio.
Next Header
Il campo Next Header è un campo lungo 8-bit (256 valori) che identifica univocamente il tipo di header che verrà dopo l’header di ESP. Ovvero indicano al processore di destinazione il prossimo header da trattare o processare. Il valore di questo campo viene scelto dal set di numeri di protocolli IP definiti dallo IANA (Internet Assigned Numbers Autority) RFC 1700.
Integrity Check Value (ICV) Authentication Data
Il campo Integrity Check Value è un campo di lunghezza variabile che contiene un Valore del Controllo dell’integrità (ICV) calcolato sull’intero pacchetto ESP (campi: Security Parameters Index, Sequence Number, Initialization Vector, Payload Data (cifrato), Padding, Pad Length, Next Header) meno il campo Integrity Check Value (se stesso). La lunghezza del campo è specificata dalla funzione di autenticazione selezionata (HMAC). Il campo Integrity Check Value è un campo opzionale, quindi viene incluso nel pacchetto ESP alla fine solamente se il servizio di autenticazione è stato selezionato per la SA in questione.
Step 3In seguito se è stata selezionata la funzione di autenticazione su questo nuovo pacchetto formato dal payload cifrato incapsulato da ESP viene compiuta una funzione hash calcolando un HMAC. Questo algoritmo (HMAC) compie un calcolo di hash One-Way su questo nuovo pacchetto. Mediante una chiave segreta condivisa fra i pari partecipanti. ESP supporta gli algoritmi HMAC-MD5, HMAC-SHA-1 e AES-XCBC-MAC-96. Questi HMAC offrono l’autenticazione dell’origine e l’integrità dei dati per il payload dei dati.
Questo HMAC così ottenuto serve per creare un campo ESP Authentication data che viene messo alla fine del pacchetto dopo l’ESP Trailer. La creazione di questo campo (ICV) avviene troncando ai primi 96 bit l’output dell’HMAC ottenuto ed inserendo questo risultato nel campo Integrity Check Value che è il campo autenticatore di ESP.
Step 4A questo punto per poter rendere instradabile questo nuovo pacchetto è necessario creare un nuovo header IP. Questo nuovo header IP viene aggiunto all’inizio del nuovo pacchetto.
Step 5 A questo punto il pacchetto con il nuovo header IP viene inviato al destinatario IPsec.
Step 6Il destinatario IPsec ricevuto il pacchetto protetto da ESP. Toglie il nuovo header IP servito al mittente per l’instradamento. Sul pacchetto rimasto, meno il campo ESP Authenticator (ICV) data viene compiuta una funzione hash calcolando un HMAC. Questo algoritmo (HMAC) compie un calcolo di hash One-Way su questa parte di pacchetto. Utilizzando la stessa chiave segreta condivisa con il mittente.
Step 7Questo HMAC ricalcolato e troncato ai primi 96 bit offre al destinatario l’autenticazione dell’origine e l’integrità dei dati per il payload dei dati, perché il destinatario IPsec compara i due hash (ricevuto (nel campo ESP Authentication data) e ricalcolato). Se i due hash combaciano precisamente 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 sensibilmente, e il pacchetto viene scartato. Il fatto che l’hash One-Way (HMAC) comporta anche l’uso di una chiave segreta simmetrica condivisa tra i due sistemi vuole dire che viene garantita l’autenticità del pacchetto.
La motivazione logica per procedere in questo ordine è che autenticando i pacchetti in entrata prima di qualunque altra operazione viene facilitata la rapida scoperta di pacchetti ripetuti e artefatti da parte del ricevente IPsec. Questo permette di scoprire prima i problemi e potenzialmente può ridurre l’impatto degli attacchi DOS.
Step 8Successivamente viene decifrato il payload data. Utilizzando a questo scopo degli algoritmi di cifratura simmetrica come il DES, 3DES o AES. In base all’algoritmo utilizzato per decifrare il payload può essere necessario: sincronizzare i dati come richiesto da un Vettore di Inizializzazione (Initialization Vector)(IV) che può trovarsi o separatamente all’inizio del ciphertext o cifrato all’interno del campo payload; e trattare i dati di padding secondo le istruzioni dettate dall’algoritmo di cifratura.
Step 9 A questo punto la trasmissione dei dati sicura tra due pari IPsec è compiuta.
Continua a leggere VPN ovvero Reti Private Virtuali: Tecnologia IPsec v3 – 7a parte
