IPsec

IPsec Mosto Alessio [email_address]

Argomenti del seminario IPsec: in risposta a quali esigenze? IPsec: cos’è? IPsec concepts Transform Sets Security Associations Transport e Tunnel Modes Authentication Header ed Encapsulating Security Payload IKE

In risposta a… Esigenze di sicurezza su rete Fondamentale insicurezza dei protocolli di rete Voler utilizzare Internet come “propria infrastruttura” per connettere le proprie reti locali in maniera sicura: VPN

In risposta a… VPN VPN: Virtual Private Network – è un servizio di rete sopra una infrastruttura pubblica con le politiche di sicurezza e privacy di una rete privata. Internet fornisce vari servizi ed è un “luogo” pubblico. I dati scambiati fra reti private e Internet sono solitamente non confidenziali.

In risposta a… VPN I dati riservati sono generalmente confinati nelle reti private visto che spedirli attraverso Internet significherebbe renderli visibili al “pubblico”. Se però si potessero mandare “internal data” attraverso Internet ad un’altra locazione privata (ad esempio un ufficio distaccato)? Ecco che si potrebbe utilizzare Internet come propria infrastruttura per connettere le reti private. Invece che costruire il proprio worldwide network si potrebbe usare il worldwide network di Internet.

In risposta a… VPN Significherebbe dunque utilizzare Internet come una Virtual Private Network (VPN), risparmiando così in termini di costi e risorse da reinvestire. IPsec permette tutto questo: connettere uffici e utenti privati, usando una qualsiasi IP network insicura, per una interconnessione sicura.

Un po’ di date … Agosto 1995: primi RFC avanzati dalla IETF RFC 1825: Security Architecture for the Internet Protocol (R. Atkinson) RFC 1826: IP Authentication Header (R. Atkinson) RFC 1827: IP Encapsulating Security Payload (ESP) (R. Atkinson)

Un po’ di date … Novembre 1998: nuovi RFC sull’argomento aggiornati RFC 2401: Security Architecture for the Internet Protocol (R. Atkinson, S. Kent) RFC 2402: IP Authentication Header (R. Atkinson, S. Kent) RFC 2406: IP Encapsulating Security Payload (R. Atkinson, S. Kent) RFC 2409: The Internet Key Exchange (IKE) ( D. Harkins, D. Carrel)

IPsec: cos’è? Lo standard IPsec è un’architettura per il trasporto sicuro di dati su una rete insicura, usando criptaggio e altri servizi. Può essere impiegato su ogni rete IP anche se è usato principalmente per la costruzione di VPN su Internet.

IPsec: cos’è? Lavora sul IP Layer (Layer 3) e si integra con la rete IP esistente. Questo approccio a livello IP da’ a IPsec vantaggi su molte tradizionali strategie di sicurezza come i link-layer e application-layer encryption.

IPsec: cos’è? Alcuni vantaggi chiave di IPsec: Per trasferire in maniera sicura dati tra due siti, c’è bisogno di IPsec solo agli endpoints: la rete “in mezzo” (Internet ad esempio) non necessita di essere abilitata a IPsec ma basta solo supporti IP (deve solo inoltrare pacchetti IP) [l’approccio link-layer (layer 2) richiede dispositivi di encryption su ogni network link tra i due siti]. Può essere adoperato in maniera trasparente ai client e ai server: non c’è bisogno di riconfigurare le workstation o le applicazioni per lavorare con IPsec [con l’application-layer encryption ogni programma client deve avere la propria implementazione per la sicurezza e poco si può fare per rendere sicuro un programma che non ha già disponibili servizi quali il criptaggio dei dati].

IPsec: cos’è? Caricando IPsec sui router o altri dispositivi di rete si semplifica il deployment: i router si occupano di applicare alcuni servizi come l’encryption e i client e i server rimangono come sono per un più facile mantenimento. Applicare i servizi IPsec in punti chiave della rete permette di forzare e mantenere una politica di sicurezza consistente in tutta l’organizzazione. IPsec è flessibile: si possono proteggere solo alcuni tipi di traffico lasciando al resto del traffico non segreto di circolare in chiaro per salvare risorse di sistema.

IPsec: cos’è? IPsec non è dunque un protocollo di sicurezza, ma una architettura per la costruzione di comunicazioni sicure su una rete untrusted e fornisce diversi servizi di sicurezza: Confidentiality Integrity Origin authentication Anti-replay

Confidentiality Confidentiality garantisce la privacy per i dati che devono essere scambiati (solo il destinatario può facilmente leggere i dati). Questa è ottenuta attraverso algoritmi crittografici.

Integrity Integrity (o data integrity) significa garantire che i dati non siano stati alterati durante il trasporto – due parti che stanno comunicando su una rete untrusted devono essere capaci di verificare che i dati ricevuti siano esattamente quelli spediti E’ ottenuta mediante algoritmi di hash crittografici

Origin Authentication Origin Authentication riguarda l’assicurazione che la persona con cui si sta comunicando sia veramente chi dice di essere. Si ottiene con firme e certificati digitali.

Anti-Replay Anti-Replay assicura che una transazione effettuata non possa essere ripetuta da un attaccante – un attaccante potrebbe semplicemente provare a registrare e ripetere una transazione senza bisogno di dover violare alcuna difesa Per IPsec c’è IKE (Internet Key Exchange) che fornisce l’anti-replay mediante l’uso di sequence numbers combinati con l’autenticazione.

IPsec concepts Voler parlare di IPsec significa dover parlare di: Peers Transform Sets Security Associations Transport e Tunnel Modes Autentication Header e Encapsulating Security Payload

IPsec: Peers Un peer di un device IPsec è un altro device che partecipa ad IPsec. Può essere un router, un firewall, un server o un dispositivo di accesso remoto come un PC con supporto ad IPsec. Se A e B stanno comunicando con IPsec, A è un peer di B e B è un peer di A.

Transform Sets Un Transform Set è una lista di protocolli IPsec e algoritmi crittografici che un peer può accettare. Poiché IPsec permette l’utilizzo di diversi protocolli e algoritmi, un peer deve dichiarare e negoziare con gli altri peer quali può supportare. I peers comunicano i protocolli e algoritmi che supportano scambiando i Transform Sets. Per poter comunicare quindi due peer devono condividere un comune Transform Set, altrimenti il loro tentativo di comunicazione fallirà.

Transform Sets Un transform set generalmente contiene: Un IPsec security protocol (AH o ESP) che è supportato dal peer [nota: è possibile usare AH e ESP insieme] Un integrity/authentication algorithm supportato dal peer (ad esempio MD5 HMAC o SHA-1 HMAC) Un algortimo crittografico supportato dal peer (DES o Triple-DES ad esempio) [nota: è anche supportato un null encryption algorithm - cioè si può anche non criptare i dati]

Transform Sets Un transform set definisce un insieme di protocolli e algoritmi che possono essere usati per il peering con un altro device. Non definisce tutti i protocolli e algoritmi supportati! Il transform set dunque “lists the rules for a session and is session-focused, not device-focused” Un transform set è una proposta per la comunicazione.

Security Associations Una security association (SA) è una connessione logica che protegge il flusso di dati da un peer ad un altro utilizzando un transform set. Le security associations sono come tunnel virtuali tra due peer: il traffico che entra in una SA è protetto e trasportato dall’altra parte (l’altro peer). Le SA sono unidirezionali, quindi per una comunicazione bidirezionale sicura tra due peer c’è bisogno di due Security Associations

Security Associations IPsec mantiene molte parti di dati necessari per supportare una SA tra due peer; questi parametri includono: L’indentità del peer remoto che partecipa alla comunicazione con IPsec (indirizzo IP od hostname) Il security protocol (AH o ESP), algoritmo di hashing (se è usato), e l’algoritmo crittografico (se è usato ESP). Queste informazioni sono negoziate quando i peer si cambiano i transform sets La chiave condivisa usata dagli algoritmi di hash e criptaggio per la durata della SA (chiamata lifetime della SA)

Security Associations Una descrizione del flusso di traffico protetto dalla SA. Solitamente questo specifica l’indirizzo IP e il numero della porta protetta dalla SA. La descrizione può essere più o meno granulare (una singola sessione TCP tra due host o tutto il traffico dalla sottorete X alla sottorete Y, ad esempio) Un numero unico che identifica la SA, chiamato Security Parameter Index (SPI) Timer e contatori che registrano il lifetime di una SA. E’ usato per determinare quando una SA e le sue chiavi associate diventano vecchie e devono essere aggiornate. Le SA e le chiavi possono essere aggiornate solo quando IKE è usato con IPsec I sequence numbers per l’individuazione di attacchi di tipo replay (solo quando IKE viene usato)

Security Associations Coppie di SA multiple sono permesse tra due peer (ad esempio una coppia di SA può proteggere il traffico Telnet con Triple-Des e MD5, e un’altra coppia di SA può proteggere tutto il restante traffico con DES e SHA-1) Le SA sono stabilite manualmente dall’utente o dinamicamente da IKE (IKE è il metodo raccomandato per la maggior parte delle implementazioni per via della sua scalabilità e della sicurezza offerta – autogenerazione dinamica di chiavi e anti-replay)

Transport e Tunnel Modes IPsec definisce due tipi di SA: transport e tunnel mode SA. Una transport mode SA è un’associazione tra due host. Nel transpot mode l’IP payload (carico dei pacchetti IP) è protetto da IPsec e l’IP header originale viene lasciato intatto; un IPsec header viene inserito dopo l’IP header.

Transport e Tunnel Modes Payload IP header Payload IPsec header IP header Transport Mode SA Protected Packet Original Packet Il payload potrebbe essere criptato

Transport e Tunnel Modes Il transport mode protegge il traffico tra due IPsec host e non fornisce confidentiality al flusso di traffico. Il volume di traffico trasmesso da un host ad un altro può quindi facilmente essere osservato, anche se viene usato il criptaggio, poiché gli indirizzi sorgente e destinazione originali rimangono intatti. Un attaccante potrebbe quindi usare questa informazione per determinare la locazione dei server, assumendo che i server trasmettano e ricevano molti più dati dei client.

Transport e Tunnel Modes Una tunnel mode SA è una associazione tra due routers o tra un router e un host. Nel tunnel mode l’intero pacchetto IP è protetto e diventa payload di un nuovo pacchetto. L’IPsec header è inserito dopo l’IP header del nuovo pacchetto.

Transport e Tunnel Modes IP header Payload Payload IP header IPsec header New IP header Tunnel Mode SA Original Packet Protected Packet Potrebbero essere criptati

Transport e Tunnel Modes Il tunnel mode è alla base per abilitare VPN dedicate tra due router. Con il tunnel mode non è necessario equipaggiare ogni PC e server con IPsec; basta attivare IPsec sui routers e usare tali routers per fornire i servizi IPsec per conto dei vari computers (ad esempio si potrebbe instaurare un IPsec peering su Internet tra due router di uffici distaccati e usare la tunnel mode SA tra i due router per proteggere tutto il traffico tra i due uffici).

Transport e Tunnel Modes Gli indirizzi d’origine e destinazione contenuti nel nuovo IP header sono quelli degli endpoints della tunnel mode SA. La tunnel mode SA fornisce la confidentiality del flusso di traffico poiché gli indirizzi IP del pacchetto originale sono trasportati nel payload sicuro di un pacchetto IPsec (supponendo l’encryption sia usata).

Authentication Header e Encapsulating Security Payload IPsec definisce due protocolli di sicurezza chiamati Authentication Header (AH – RFC 2402) e Encapsulating Security Payload (ESP – RFC 2406). Ciascun protocollo definisce il proprio formato per l’IPsec header che segue l’IP header di un pacchetto IPsec. Entrambi usano il concetto di Security Association.

Authentication Header e Encapsulating Security Payload Le SA possono essere o AH SA o ESP SA (una SA non può essere AH e ESP). Sia AH che ESP supportano le modalità trasporto e tunnel.

Authentication Header e Encapsulating Security Payload AH fornisce integrity e authentication, usando algoritmi di hash a chiave condivisa come MD5 HMAC e SHA-1 HMAC. AH non fornisce confidentiality (encryption). ESP fornisce confidentiality e, opzionalmente, integrity e authentication. Per la confidentiality, ESP supporta algoritmi crittografici simmetrici come DES e Triple-DES. Come AH, ESP supporta algoritmi di hashing a chiave condivisa per l’integrity e l’authentication.

Authentication Header e Encapsulating Security Payload Poiché ESP fornisce tutti i servizi di AH (integrity e authentication) si potrebbe pensare che AH non serva dopo tutto. C’è però una piccola differenza tra l’integrity e l’authentication forniti da AH e quelli forniti da ESP. ESP non verifica l’integrità dell’intero pacchetto IP (protegge tutto ma non l’IP header).

Authentication Header e Encapsulating Security Payload AH invece controlla l’integrità dell’intero pacchetto IPsec, incluso l’IP header (tecnicamente, alcuni campi nel IP header sono soggetti a cambiamenti durante il trasporto e AH non può proteggere tali valori). Quindi se la integrity del IP header è importante si può usre AH ed ESP insieme, ovviamente al prezzo di avere un numero doppio di SA rispetto ad usare solo ESP) NOTA: una SA può supportare AH o ESP, non entrambe!

Internet Key Exchange Il protocollo Internet Key Exchange (IKE – RFC 2409) è un management protocol usato insieme ad IPsec e si basa su tre protocolli di gestione chiavi: Internet Security Association e Key Management Protocol (ISAKMP – RFC 2408), Oakley (RFC 2412) e SKEME.

Internet Key Exchange IKE è un importante protocollo che fornisce ad IPsec i seguenti servizi: Stabilisce le IPsec SA dinamicamente quando sono nocessarie. Senza IKE si devono configurare manualmente tutte le SA richieste tra tutti i peer. Abilita il rekeying dinamico. Le chiavi sono sostituite dopo un certo periodo di tempo con nuove chiavi generate dinamicamente. Abilita la protezione anti-replay. Senza IKE IPsec non è in grado di identificare un attacco di tipo replay.

Internet Key Exchange Abilita la origin authentication mediante certificati digitali e CA (Certification Authorities) servers. Senza IKE non vi è supporto per i CA e l’origin authentication deve essere fatto persona a persona (manualmente e out-of-band). Opzionalmente fornisce Perfect Forward Secrecy (PFS). Questa è una caratteristica crittografica delle chiavi condivise e significa che la compromissione di una chiave non aiuta l’attaccante a scoprire le altre chiavi. In altre parole, ogni chiave è sicura “per propri meriti” e non è derivata da altre chiavi.

Internet Key Exchange Per queste ragioni utilizzare IPsec con IKE è altamente raccomandato. IKE aggiunge features di sicurezza, aumenta la scalabilità e semplifica la configurazione. Quando due device IPsec devono comunicare utilizzando IPsec, come prima cosa si autenticano l’un l’altro usando IKE e quindi stabiliscono una IKE SA tra di loro per la gestione.

Internet Key Exchange IKE SA è sicura e si comporta come un canale di controllo per lo scambio delle chiavi e la negoziazione delle IPsec SA (le SA che proteggono il flusso di dati dell’utente tra i peer). Diversamente dalle IPsec SA, che sono unidirezionali, la IKE SA è bidirezionale (solo una IKE SA è necessaria tra due IPsec peer per supportare IPsec SA multiple).

Esempio Come lavorano assieme tutte le varie tecnologie viste fino ad ora? Vediamo un esempio che mostra come le tecniche crittografiche di IPsec possono ottenere una comunicazione sicura su una rete untrusted. I “protagonisti” sono Alice e Bob. Per rendere l’esempio più concreto supponiamo che Alice abbia bisogno di stabilire una sessione FTP sicura con Bob.

Esempio Alice inizia una IKE SA con Bob e propone un transform set che potrebbero utlizzare. Il transform set specifica gli algoritmi di crittografia, hashing e authentication per la IKE SA come altre informazioni quale la SA lifetime (la lifetime setta un tempo di scadenza per la SA). Se Bob può supportare il transform set, la negoziazione continua; altrimenti la IKE SA fallisce e non vi sono altre comunicazioni. Alice spedisce il proprio certificato digitale a Bob. Il certificato contiene la sua chiave pubblica e garantisce l’autenticità della chiave. Bob fa la stessa cosa così che anche Alice abbia la sua chiave pubblica.

Esempio Alice e Bob si scambiano digitalmente i numeri Diffie-Hellman per stabilire una chiave segreta condivisa. I numeri dell’algoritmo di Diffie-Hellman sono segnati così che ciascun peer possa validare l’identità dell’altro peer. [Si ricordi che il Diffie-Hellman è vulnerabile ad attacchi del tipo man-in-the-middle; come contromisure IKE usa firme digitali per autenticare l’origine dello scambio Diffie-Hellman]. Alice verifica la firma sul Diffie-Hellman number di Bob con la chiave pubblica di Bob (questo autentica Bob). Bob fa la stessa cosa e verifica la firma sul numero Diffie-Hellman di Alice usando la chiave pubblica di Alice.

Esempio Alice e Bob calcolano una chiave condivisa che conoscono solo loro usando l’algoritmo di Diffie-Hellman. A questo punto la IKE SA è stabilita tra Alice e Bob: i dati possono essere spediti in maniera sicura tra i due peer, usando la chiave condivisa (punto 5) e gli algoritmi specificati nel IKE transform set. Alice inizia una IPsec SA, che è necessaria per supportare i pacchetti per la sessione FTP (ricordiamo che la IKE SA è usata solo per la gestione, non per gli user data). Usando la IKE SA come un canale sicuro, Alice propone a Bob uno o più transform set per la IPsec SA. Ciascun transform set specifica un protocollo di sicurezza (AH o ESP) e gli algoritmi (di hashing e/o di crittografia) per la SA. Se Bob può supportare un transform set, la negoziazione continua; altrimenti la IPsec SA fallisce e non vi sono altre comunicazioni (pacchetti FTP non possono essere spediti).

Esempio Alice e Bob calcolano una chiave condivisa per la IPsec SA usando l’algoritmo di Diffie-Hellman. Questo fornisce il PFS (Perfect Forward Secrecy): la chiave per l’IPsec SA non deriva dalla chiave della IKE SA [compromettere l’una non aiuta a trovare l’altra]. Alice può ora spedire pacchetti FTP in maniera sicura a Bob sopra la IPsec SA, usando la chiave condivisa (punto 8) e gli algoritmi specificati nel transform set per la IPsec SA (punto 7). La IPsec SA è mantenuta da IKE. Poco prima che la IPsec SA scada, a nuova SA con nuove chiavi è creata e la comunicazione è trasportata sopra la nuova SA in maniera trasparente. Questo è il servizio di rekeying fornito da IKE. Quando Bob ha bisogno di spedire dati, deve iniziare e stabilire una IPsec SA con Alice, visto che le IPsec SA sono unidirezionali.

Qualche piccola informazione e aggiunte tecniche IPsec è obbligatorio per IPv6 e solo opzionale in IPv4. L’implementazione pratica dell’architettura non è uno standard. Vi sono diversi modi nei quali IPsec può essere implementato in un host o in congiunzione con un router o un firewall (per creare un security gateway)

Qualche piccola informazione e aggiunte tecniche Alcuni esempi di implementazione: Integrazione di IPsec nell’implementazione nativa di IP. Questo richiede l’accesso al IP source code ed è applicabile sia agli host che ai security gateway. “ Bump-in-the-stack” (BITS), dove IPsec è implementato al di sotto di una implementazione esistente di un IP protocol stack, tra il native IP e i local network drivers. Solitamente questo approccio è applicato agli host. “ Bump-in-the-wire” (BITW)

Qualche piccola informazione e aggiunte tecniche Authentication Header Format: Payload Len Next Header RESERVED Security Parameters Index (SPI) Sequence Number Field Authentication Data (variable) 0 8 16 31

Qualche piccola informazione e aggiunte tecniche Next Header: un campo di 8 bit che identifica il tipo del successivo payload dopo l’Autentication Header. Payload Length: un campo di 8 bit che specifica la lunghezza di AH in parole di 32 bit, meno 2. Reserved: questi 16 bit sono riservati per un uso futuro.

Qualche piccola informazione e aggiunte tecniche Security Parameters Index (SPI): è un valore di 32 bit arbitrario che, in cominazione con l’indirizzo IP di destinazione e il security protocol (AH), identifica in maniera univoca la Security Association per questo datagram Sequence Number: campo unsigned di 32 bit contenente un numero di sequenza necessario per il rifiuto di pacchetti già trasmessi. Authentication Data: è un campo di lunghezza variabile che contiene il ICV (Integrity Check Value) per questo pacchetto.

Qualche piccola informazione e aggiunte tecniche Encapsulating Security Payload Packet Format: Security Parameters Index (SPI) Sequence Number 0 8 16 31 24 Payload Data (variable) Padding (0-255 bytes) Pad Length Next Header Authentication Data (variable)

Qualche piccola informazione e aggiunte tecniche SPI: è un arbitrario valore a 32 bit che, in combinazione con l’IP address e il security protocol (ESP), identifica univocamente la SA per questo datagram. Sequence Number: numero di sequenza per l’anti-replay Payload Data: un campo a dimensione variabile contenente i data descritti dal campo Next Header.

Qualche piccola informazione e aggiunte tecniche Padding: ha principalmente tre scopi Se un algoritmo di crittografia è impiegato e richiede che il plaintext (testo in chiaro) sia un multiplo di un qualche numero di byte, il campo Padding è usato per “riempire” il plaintext (Payload Data, Pad Length e Next Header oltre al Padding stesso) fino alla dimensione richiesta dall’algoritmo. Può essere adoperato per assicurare che il risultante ciphertext (testo crifrato) termini su un 4 byte boundary (ad esempio ESP richiede che Pad Length e Next Header debbano essere allineati in una parola di 4 byte).

Qualche piccola informazione e aggiunte tecniche Può essere utilizzato per aumentare la confidenzialità dei dati, oscurando la reale lunghezza dei dati una volta che siano stati cifrati. Pad Length: indica il numero di byte precedenti questo stesso campo. Next Header: è un campo di 8 bit che identifica il tipo di dati contenuti nel campo Payload Data. Authentication Data: un campo di lunghezza variabile contenente il ICV (Integrity Check Value) calcolato sul pacchetto ESP meno l’Authentication Data.

Note bibliografiche “ Enhanced IP service for Cisco networks”, Cisco Press RFC 2401, 2402, 2406, 2409 (http://www.rfc-editor.org/)

IPsec

More Related Content

Viewers also liked (19)

Similar to IPsec (20)

IPsec