Mosto Alessio a.mosto@libero.it IPsec Mosto Alessio a.mosto@libero.it 07/01/2003 IPsec.

Presentazione sul tema: "Mosto Alessio a.mosto@libero.it IPsec Mosto Alessio a.mosto@libero.it 07/01/2003 IPsec."— Transcript della presentazione:

1 Mosto Alessio a.mosto@libero.it
IPsec Mosto Alessio 07/01/2003 IPsec

2 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 07/01/2003 IPsec

3 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 07/01/2003 IPsec

4 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. 07/01/2003 IPsec

5 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. 07/01/2003 IPsec

6 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. 07/01/2003 IPsec

7 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) 07/01/2003 IPsec

8 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) 07/01/2003 IPsec

9 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. 07/01/2003 IPsec

10 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. 07/01/2003 IPsec

11 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]. 07/01/2003 IPsec

12 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. 07/01/2003 IPsec

13 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 07/01/2003 IPsec

14 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. 07/01/2003 IPsec

15 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 07/01/2003 IPsec

16 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. 07/01/2003 IPsec

17 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. 07/01/2003 IPsec

18 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 07/01/2003 IPsec

19 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. 07/01/2003 IPsec

20 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à. 07/01/2003 IPsec

21 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] 07/01/2003 IPsec

22 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. 07/01/2003 IPsec

23 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 07/01/2003 IPsec

24 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) 07/01/2003 IPsec

25 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) 07/01/2003 IPsec

26 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) 07/01/2003 IPsec

27 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. 07/01/2003 IPsec

28 Transport e Tunnel Modes
Transport Mode SA Original Packet IP header Payload Protected Packet IP header IPsec header Payload Il payload potrebbe essere criptato 07/01/2003 IPsec

29 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. 07/01/2003 IPsec

30 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. 07/01/2003 IPsec

31 Transport e Tunnel Modes
Tunnel Mode SA Original Packet IP header Payload Protected Packet New IP header IPsec header IP header Payload Potrebbero essere criptati 07/01/2003 IPsec

32 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). 07/01/2003 IPsec

33 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). 07/01/2003 IPsec

34 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. 07/01/2003 IPsec

35 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. 07/01/2003 IPsec

36 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. 07/01/2003 IPsec

37 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). 07/01/2003 IPsec

38 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! 07/01/2003 IPsec

39 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. 07/01/2003 IPsec

40 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. 07/01/2003 IPsec

41 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. 07/01/2003 IPsec

42 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. 07/01/2003 IPsec

43 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). 07/01/2003 IPsec

44 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. 07/01/2003 IPsec

45 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. 07/01/2003 IPsec

46 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. 07/01/2003 IPsec

47 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). 07/01/2003 IPsec

48 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. 07/01/2003 IPsec

49 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) 07/01/2003 IPsec

50 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) 07/01/2003 IPsec

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

52 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. 07/01/2003 IPsec

53 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. 07/01/2003 IPsec

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

55 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. 07/01/2003 IPsec

56 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). 07/01/2003 IPsec

57 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. 07/01/2003 IPsec

58 Note bibliografiche “Enhanced IP service for Cisco networks”, Cisco Press RFC 2401, 2402, 2406, 2409 ( 07/01/2003 IPsec