(The Internet Key Exchange (IKE)) - Scambio di chiavi.
Architettura IPsec
I protocolli IPsec, a differenza di altri noti protocolli SSL e TLS, operano a livello di rete (Livello 3 del modello OSI). Ciò rende IPsec più flessibile in modo che possa essere utilizzato per proteggere qualsiasi protocollo basato su TCP e UDP. IPsec può essere utilizzato per fornire sicurezza tra due host IP, tra due gateway di sicurezza o tra un host IP e un gateway di sicurezza. Il protocollo è un "add-on" sul protocollo IP ed elabora i pacchetti IP generati nel modo descritto di seguito. IPsec può imporre l'integrità e/o la riservatezza dei dati trasmessi su una rete.
IPsec utilizza i seguenti protocolli per eseguire varie funzioni:
- L'intestazione di autenticazione (AH) fornisce l'integrità della connessione virtuale (dati trasmessi), l'autenticazione della fonte di informazioni e una funzione aggiuntiva per impedire la ritrasmissione dei pacchetti
- Encapsulating Security Payload (ESP) può fornire privacy (crittografia) informazioni trasmesse, limitando il flusso di traffico riservato. Inoltre, può garantire l'integrità della connessione virtuale (dati trasmessi), l'autenticazione della fonte di informazioni e una funzione aggiuntiva per impedire la ritrasmissione dei pacchetti (ogni volta che viene utilizzato l'ESP, l'uno o l'altro set di dati del servizio di sicurezza deve essere utilizzato senza fallire)
- La Security Association (SA) fornisce una serie di algoritmi e dati che forniscono i parametri necessari per il funzionamento di AH e/o ESP. sicurezza in internet L'Association and Key Management Protocol (ISAKMP) fornisce un framework per l'autenticazione e lo scambio di chiavi, l'autenticazione delle chiavi.
Associazione per la sicurezza
Il concetto di "Security Association" (SA) è fondamentale per l'architettura IPsec. SA è una connessione simplex, che è formata per trasportare il traffico corrispondente su di essa. Quando si implementano i servizi di sicurezza, viene formata una SA basata sull'uso dei protocolli AH o ESP (o entrambi contemporaneamente). SA è definito secondo il concetto di connessione point-to-point e può operare in due modalità: Transport Mode (PTP) e Tunneling Mode (RTU). La modalità di trasporto è implementata con una SA tra due nodi IP. In modalità tunnel, la SA forma un tunnel IP.
Tutte le SA sono archiviate nel Security Associations Database (SADB) del modulo IPsec. Ogni SA ha un token unico composto da tre elementi:
- Indice dei parametri di sicurezza (SPI)
- Indirizzi IP di destinazione
- identificatore del protocollo di sicurezza (ESP o AH)
Il modulo IPsec, dati questi tre parametri, può cercare la voce SADB per un particolare SA. L'elenco dei componenti SA include:
Numero di serie Valore a 32 bit utilizzato per formare il campo sequenza di numeri nelle rubriche AH ed ESP. Overflow del contatore di sequenza Un flag che segnala l'overflow del contatore del numero di sequenza. Finestra di soppressione degli attacchi di ripetizione Utilizzato per determinare la ritrasmissione dei pacchetti. Se il valore nel campo sequenza di numeri non rientra nell'intervallo specificato, il pacchetto viene distrutto. AH Informazioni l'algoritmo di autenticazione utilizzato, le chiavi richieste, la durata delle chiavi e altri parametri. Informazioni sull'ESP algoritmi di crittografia e autenticazione, chiavi richieste, parametri di inizializzazione (ad esempio, IV), durata della chiave e altri parametri Modalità di funzionamento IPsec tunnel o trasporto MTU La dimensione massima del pacchetto che può essere inviato su un circuito virtuale senza frammentazione.Poiché le connessioni virtuali sicure (SA) sono simplex, sono necessarie almeno due SA per organizzare un canale duplex. Inoltre, ogni protocollo (ESP/AH) deve avere la propria SA per ciascuna direzione, ovvero AH+ESP richiede quattro SA. Tutti questi dati si trovano in SADB.
- AH: algoritmo di autenticazione.
- AH: chiave segreta per l'autenticazione
- ESP: algoritmo di crittografia.
- ESP: chiave di crittografia segreta.
- ESP: usa l'autenticazione (sì/no).
- Opzioni di scambio chiave
- Restrizioni di percorso
- politica di filtraggio IP
Oltre al database SADB, le implementazioni IPsec supportano l'SPD (Security Policy Banca dati dati sulla politica di sicurezza). Una voce in un SPD è costituita da un insieme di valori di campo di intestazione IP e campi di intestazione del protocollo di livello superiore. Questi campi sono chiamati selettori. I selettori vengono utilizzati per filtrare i pacchetti in uscita in modo da far corrispondere ogni pacchetto con una specifica SA. Quando si forma un pacchetto, i valori dei campi corrispondenti nel pacchetto (campi selettore) vengono confrontati con quelli contenuti nell'SPD. Si trovano le SA corrispondenti. Vengono quindi determinati i SA (se presenti) per il pacchetto e il relativo Security Parameter Index (SPI). Successivamente, vengono eseguite le operazioni IPsec (operazioni del protocollo AH o ESP).
Esempi di selettori contenuti in SPD:
- Indirizzo IP di destinazione
- Indirizzo IP del mittente
- Protocollo IPsec (AH, ESP o AH+ESP)
- Porte di origine e di destinazione
Intestazione di autenticazione
| compensazioni | 16 ottobre | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 16 ottobre | bit 10 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Intestazione successiva | Len | Riservato | |||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | sequenza di numeri | |||||||||||||||||||||||||||||||
| C | 96 | Valore di controllo dell'integrità (ICV) … |
|||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
Il protocollo AH viene utilizzato per l'autenticazione, ovvero per confermare che stiamo comunicando esattamente con chi pensiamo di essere e che i dati che riceviamo non vengono manomessi durante il transito.
Elaborazione di pacchetti IP di output
Se il modulo IPsec trasmittente determina che il pacchetto è associato a un SA che richiede l'elaborazione AH, inizia l'elaborazione. A seconda della modalità (modalità di trasporto o tunnel), inserisce l'intestazione AH in modo diverso nel pacchetto IP. In modalità di trasporto, l'intestazione AH viene visualizzata dopo l'intestazione del protocollo IP e prima delle intestazioni del protocollo di livello superiore (tipicamente TCP o UDP). In modalità tunnel, l'intero pacchetto IP di origine viene prima incorniciato con l'intestazione AH, quindi con l'intestazione del protocollo IP. Tale intestazione è chiamata esterna e l'intestazione del pacchetto IP originale è chiamata interna. Successivamente, il modulo IPsec trasmittente deve generare un numero di serie e scriverlo nel campo sequenza di numeri. Quando viene stabilita una SA, il numero di sequenza viene impostato su 0 e incrementato di uno prima dell'invio di ciascun pacchetto IPsec. Inoltre, c'è un controllo se il contatore è andato in cicli. Se ha raggiunto il valore massimo, viene nuovamente impostato su 0. Se viene utilizzato il servizio di prevenzione della ritrasmissione, quando il contatore raggiunge il valore massimo, il modulo IPsec trasmittente azzera il SA. Ciò fornisce protezione contro il rinvio del pacchetto: il modulo IPsec ricevente controllerà il campo sequenza di numeri e ignora i pacchetti di tentativi. Successivamente, viene calcolato il checksum ICV. Va notato che qui il checksum viene calcolato utilizzando una chiave segreta, senza la quale un utente malintenzionato potrà ricalcolare l'hash, ma senza conoscere la chiave, non sarà in grado di formare il checksum corretto. Gli algoritmi specifici utilizzati per calcolare l'ICV possono essere trovati in RFC 4305. Attualmente, ad esempio, possono essere utilizzati algoritmi HMAC-SHA1-96 o AES-XCBC-MAC-96. Il protocollo AH calcola il checksum (ICV) dai seguenti campi del pacchetto IPsec:
- campi nell'intestazione IP che non sono stati modificati durante il processo di traduzione o sono considerati i più importanti
- Intestazione AH (campi: "Intestazione successiva", "Len carico utile, "Riservato", "SPI", "Numero sequenza", "Valore verifica integrità". Il campo "Valore verifica integrità" è impostato su 0 durante il calcolo dell'ICV
- dati del protocollo di livello superiore
Elaborazione dei pacchetti IP in entrata
Alla ricezione di un pacchetto contenente un messaggio di protocollo AH, il modulo IPsec ricevente cerca la connessione virtuale (SA) SADB (Security Associations Database) corrispondente utilizzando l'indirizzo IP di destinazione, il protocollo di sicurezza (AH) e l'indice SPI. Se non viene trovata alcuna SA corrispondente, il pacchetto viene scartato. La connessione virtuale sicura (SA) trovata indica se viene utilizzato il servizio di prevenzione della ritrasmissione dei pacchetti, ad es. sulla necessità di controllare il campo sequenza di numeri. Se il servizio è in uso, il campo viene selezionato. Per questo, viene utilizzato il metodo della finestra scorrevole. Il modulo IPsec ricevente forma una finestra di larghezza W. Il bordo sinistro della finestra corrisponde al numero di sequenza minimo ( sequenza di numeri) N pacchetto ricevuto correttamente. Confezione con scatola sequenza di numeri, che contiene un valore da N+1 a N+W, viene accettato correttamente. Se il pacchetto ricevuto si trova sul bordo sinistro della finestra, viene distrutto. Il modulo IPsec ricevente calcola quindi l'ICV dai campi appropriati del pacchetto ricevuto utilizzando l'algoritmo di autenticazione che apprende dal record SA e confronta il risultato con il valore ICV situato nel campo "Integrity Check Value". Se il valore ICV calcolato corrisponde a quello ricevuto, il pacchetto in entrata è considerato valido e viene accettato per un'ulteriore elaborazione IP. Se il controllo fallisce, il pacchetto ricevuto viene scartato.
| compensazioni | 16 ottobre | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 16 ottobre | bit 10 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Indice dei parametri di sicurezza (SPI) | |||||||||||||||||||||||||||||||
| 4 | 32 | sequenza di numeri | |||||||||||||||||||||||||||||||
| 8 | 64 | dati del carico utile | |||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
| … | … | Imbottitura (0-255 ottetti) | |||||||||||||||||||||||||||||||
| … | … | Lunghezza pastiglia | Intestazione successiva | ||||||||||||||||||||||||||||||
| … | … | Valore di controllo dell'integrità (ICV) … |
|||||||||||||||||||||||||||||||
| … | … | ||||||||||||||||||||||||||||||||
Elaborazione dei pacchetti IPsec in uscita
Se il modulo IPsec trasmittente determina che il pacchetto è associato a un SA che richiede l'elaborazione ESP, inizia l'elaborazione. A seconda della modalità (modalità di trasporto o tunnel), il pacchetto IP originale viene elaborato in modo diverso. In modalità di trasporto, il modulo IPsec di trasmissione incapsula il protocollo di livello superiore (ad esempio, TCP o UDP) utilizzando l'intestazione ESP e il trailer ESP senza influire sull'intestazione del pacchetto IP originale. In modalità tunnel, il pacchetto IP è incorniciato con un'intestazione ESP e un trailer ESP, dopodiché è incorniciato con un'intestazione IP esterna. Successivamente, viene eseguita la crittografia: in modalità di trasporto, viene crittografato solo il messaggio di protocollo sopra il livello sottostante (ovvero tutto ciò che era dopo l'intestazione IP nel pacchetto di origine), in modalità di tunneling, l'intero pacchetto IP di origine. Il modulo IPsec di trasmissione dalla voce SA determina l'algoritmo di crittografia e la chiave segreta. Gli standard IPsec consentono l'uso di algoritmi di crittografia triple-DES, AES e Blowfish. Poiché la dimensione del testo normale deve essere un multiplo di un certo numero di byte, ad esempio la dimensione del blocco per gli algoritmi di blocco, prima della crittografia viene eseguito anche il riempimento necessario del messaggio crittografato. Il messaggio crittografato viene inserito nel campo dati del carico utile. In campo Lunghezza pastiglia la lunghezza del pad è posizionata. Quindi, come in AH, si calcola sequenza di numeri. Successivamente, viene calcolato il checksum (ICV). Il checksum, contrariamente al protocollo AH, dove nel calcolo vengono presi in considerazione anche alcuni campi dell'intestazione IP, in ESP viene calcolato solo dai campi del pacchetto ESP meno il campo ICV. Prima di calcolare il checksum, viene riempito di zeri. L'algoritmo di calcolo ICV, come nel protocollo AH, il modulo IPsec trasmittente apprende dal record della SA a cui è associato il pacchetto elaborato.
Gestione dei pacchetti IPsec in entrata
Alla ricezione di un pacchetto contenente un messaggio del protocollo ESP, il modulo IPsec ricevente cerca la connessione virtuale sicura (SA) corrispondente in SADB (Security Associations Database) utilizzando l'indirizzo IP di destinazione, il protocollo di sicurezza (ESP) e l'indice SPI. Se non viene trovata alcuna SA corrispondente, il pacchetto viene scartato. La connessione virtuale sicura (SA) trovata indica se viene utilizzato il servizio di prevenzione della ritrasmissione dei pacchetti, ad es. la necessità di controllare il campo Numero di sequenza. Se il servizio è in uso, il campo viene selezionato. Per questo, come in AH, viene utilizzato il metodo della finestra scorrevole. Il modulo IPsec ricevente forma una finestra di larghezza W. Il bordo sinistro della finestra corrisponde al numero di sequenza minimo N di un pacchetto ricevuto correttamente. Un pacchetto con un campo Sequence Number contenente un valore da N+1 a N+W viene ricevuto correttamente. Se il pacchetto ricevuto si trova sul bordo sinistro della finestra, viene distrutto. Quindi, se viene utilizzato il servizio di autenticazione, il modulo IPsec ricevente calcola l'ICV dai campi corrispondenti del pacchetto ricevuto utilizzando l'algoritmo di autenticazione che apprende dalla voce SA e confronta il risultato con il valore ICV situato nel "Valore di verifica dell'integrità" campo. Se il valore ICV calcolato corrisponde a quello ricevuto, il pacchetto in arrivo è considerato valido. Se il controllo fallisce, il pacchetto ricevuto viene scartato. Successivamente, il pacchetto viene decrittografato. Il modulo IPsec ricevente apprende dalla voce SA quale algoritmo di crittografia viene utilizzato e la chiave segreta. Si precisa che il controllo del checksum e la procedura di decrittazione possono essere effettuati non solo in sequenza, ma anche in parallelo. In quest'ultimo caso, la procedura di verifica del checksum deve terminare prima della procedura di decrittazione e, se la verifica ICV ha esito negativo, deve terminare anche la procedura di decrittazione. Ciò consente un rilevamento più rapido dei pacchetti danneggiati, che a sua volta aumenta il livello di protezione contro gli attacchi Denial of Service (attacchi DOS). Successivamente, il messaggio decodificato in base al campo Intestazione successiva inviato per ulteriore elaborazione.
Utilizzo
Il protocollo IPsec viene utilizzato principalmente per organizzare i tunnel VPN. In questo caso, i protocolli ESP e AH funzionano in modalità tunnel. Inoltre, configurando le politiche di sicurezza in un certo modo, il protocollo può essere utilizzato per creare un firewall. Il significato di un firewall è che controlla e filtra i pacchetti che lo attraversano secondo le regole date. Viene impostato un insieme di regole e lo schermo guarda tutti i pacchetti che lo attraversano. Se i pacchetti trasmessi rientrano in queste regole, il firewall li elabora di conseguenza. Ad esempio, può rifiutare determinati pacchetti, interrompendo così le connessioni non sicure. Configurando di conseguenza la politica di sicurezza, è possibile, ad esempio, bloccare il traffico Internet. Per fare ciò è sufficiente vietare l'invio di pacchetti che contengono messaggi di protocollo HTTP e HTTPS. IPsec può essere utilizzato anche per proteggere i server: per questo, tutti i pacchetti vengono scartati, ad eccezione dei pacchetti necessari per il corretto svolgimento delle funzioni del server. Ad esempio, per un server Web, è possibile bloccare tutto il traffico ad eccezione delle connessioni sulla porta TCP 80 o sulla porta TCP 443 nei casi in cui viene utilizzato HTTPS.
Guarda anche
Collegamenti
- Descrizione della configurazione IPSec (cisco.com)
| Reti private virtuali (VPN) | |
|---|---|
| Software |
Chaply Check Point VPN-1 Client VPN Cisco Systems CloudVPN CryptoLink Gbridge Hamachi Jabpunch Gateway di accesso unificato Microsoft Forefront n2n responsabile del network OpenVPN Openswan pLan OpenVPN Edition (client di gioco ZeroGC) rp-pppoe Social VPN strongSwan Tinc tccrypt Vyatta Wippien |
| Meccanismi | |
| Gestito dal fornitore | |
| Meccanismi di sicurezza in |
|---|
IPsec non è un singolo protocollo, ma un sistema di protocolli progettato per proteggere i dati a livello di rete delle reti IP. Questo articolo descriverà la teoria dell'utilizzo di IPsec per creare un tunnel VPN.
introduzione
La VPN basata su tecnologia IPsec può essere suddivisa in due parti:
- Protocollo di scambio di chiavi Internet (IKE)
- Protocolli IPsec (AH/ESP/entrambi)
La prima parte (IKE) è la fase di negoziazione, durante la quale i due punti VPN decidono quali metodi verranno utilizzati per proteggere il traffico IP inviato tra di loro. Inoltre, IKE viene utilizzato anche per gestire le connessioni, per questo viene introdotto il concetto di Security Associations (SA) per ogni connessione. Le SA puntano solo in una direzione, quindi una tipica connessione IPsec utilizza due SA.
La seconda parte sono i dati IP che devono essere crittografati e autenticati prima della trasmissione utilizzando le modalità concordate nella prima parte (IKE). Esistono diversi protocolli IPsec che possono essere utilizzati: AH, ESP o entrambi.
La sequenza per stabilire una VPN su IPsec può essere brevemente descritta come:
- IKE negozia la sicurezza del livello IKE
- IKE negozia la sicurezza del livello IPsec
- i dati protetti vengono trasmessi tramite VPN IPsec
IKE, scambio di chiavi Internet
Per crittografare e autenticare i dati, è necessario selezionare il metodo di crittografia/autenticazione (algoritmo) e le chiavi utilizzate in essi. Il compito del protocollo Internet Key Exchange, IKE, in questo caso è distribuire queste "chiavi di sessione" e concordare algoritmi che proteggeranno i dati tra i punti VPN.
I compiti principali di IKE:
- Autenticare i punti VPN dell'altro
- Organizzazione di nuove connessioni IPsec (attraverso la creazione di coppie SA)
- Gestione delle connessioni correnti
IKE tiene traccia delle connessioni assegnando a ciascuna di esse una determinata Security Association, SA. SA descrive i parametri di una particolare connessione, incluso il protocollo IPsec (AH/ESP o entrambi), le chiavi di sessione utilizzate per crittografare/decodificare e/o autenticare i dati. SA è unidirezionale, quindi ci sono più SA per connessione. Nella maggior parte dei casi in cui viene utilizzato solo ESP o AH, vengono create solo due SA per ogni connessione, una per il traffico in entrata e una per il traffico in uscita. Quando ESP e AH vengono utilizzati insieme, SA ne richiede quattro.
Il processo di negoziazione IKE passa attraverso diverse fasi (fasi). Queste fasi includono:
- IKE prima fase (IKE Fase-1):
- Viene negoziata la protezione dell'IKE stesso (tunnel ISAKMP). - Seconda fase IKE (IKE Fase-2):
- Negoziare la sicurezza IPsec
— Ricezione dei dati dalla prima fase per generare chiavi di sessione
Le connessioni IKE e IPsec sono limitate nella durata (in secondi) e nella quantità di dati trasferiti (in kilobyte). Questo viene fatto per migliorare la sicurezza.
La durata di una connessione IPsec è in genere più breve di IKE. Pertanto, alla scadenza di una connessione IPsec, viene ricreata una nuova connessione IPsec attraverso la seconda fase della negoziazione. La prima fase della negoziazione viene utilizzata solo quando si ricrea la connessione IKE.
Per negoziare IKE, viene introdotto il concetto di proposta IKE (proposta IKE): si tratta di una proposta su come proteggere i dati. Il punto VPN che avvia la connessione IPsec invia un elenco (proposta) che specifica diversi metodi di sicurezza della connessione.
Le negoziazioni possono essere condotte sia per stabilire una nuova connessione IPsec, sia per stabilire una nuova connessione IKE. Nel caso di IPsec, i dati protetti sono i dati inviati attraverso il tunnel VPN, mentre nel caso di IKE i dati protetti sono i dati delle negoziazioni IKE stesse.
Il punto VPN che ha ricevuto la lista (offerta) seleziona da essa quella più adatta e la indica nella risposta. Se nessuna delle offerte può essere selezionata, il gateway VPN rifiuta.
L'offerta contiene tutto informazione necessaria per selezionare un algoritmo di crittografia e autenticazione, ecc.
Fase 1 IKE - Negoziazione sulla sicurezza IKE (tunnel ISAKMP)
Nella prima fase di negoziazione, i punti VPN si autenticano a vicenda sulla base di una chiave comune (Chiave precondivisa). L'algoritmo hash viene utilizzato per l'autenticazione: MD5, SHA-1, SHA-2.
Tuttavia, prima di autenticarsi reciprocamente, in modo da non trasmettere informazioni in chiaro, i punti VPN si scambiano elenchi di proposte (Proposte), descritti in precedenza. Solo dopo aver selezionato l'offerta adatta a entrambi i punti VPN, il punto VPN dell'altro si autentica.
L'autenticazione può essere eseguita diversi modi: tramite chiavi precondivise, certificati o . Le chiavi condivise sono il metodo di autenticazione più comune.
La negoziazione IKE della prima fase può avvenire in una delle due modalità: principale (principale) e aggressiva (aggressiva). La modalità principale è più lunga, ma anche più sicura. Nel suo processo, vengono scambiati sei messaggi. La modalità aggressiva è più veloce, limitata a tre messaggi.
Il lavoro principale della prima fase di IKE risiede nello scambio di chiavi Diffie-Hellman. Si basa sulla crittografia a chiave pubblica, ogni lato crittografa il parametro di autenticazione (Pre-Shared Key) con la chiave pubblica del vicino, che, ricevuto il messaggio, lo decritta con la sua chiave privata. Un altro modo per autenticare le parti l'una con l'altra è utilizzare i certificati.
Fase 2 IKE - Negoziazione sulla sicurezza IPsec
Nella seconda fase viene effettuata la scelta di come proteggere la connessione IPsec.
La seconda fase utilizza il materiale delle chiavi estratto dallo scambio di chiavi Diffie-Hellman avvenuto nella prima fase. Sulla base di questo materiale, vengono create chiavi di sessione, che vengono utilizzate per proteggere i dati nel tunnel VPN.
Se viene utilizzato il meccanismo Segretezza di inoltro perfetta (PFS), quindi per ogni corrispondenza della seconda fase verrà utilizzata nuovo scambio Chiavi Diffie Hellman. Rallentando leggermente la velocità questa procedura assicura che le chiavi di sessione siano indipendenti l'una dall'altra, il che aumenta la protezione, poiché anche se una delle chiavi è compromessa, non può essere utilizzata per selezionare le altre.
C'è solo una modalità di funzionamento della seconda fase della negoziazione IKE, si chiama modalità rapida - modalità veloce. Nel processo di negoziazione della seconda fase, vengono scambiati tre messaggi.
Al termine della seconda fase viene stabilita una connessione VPN.
Impostazioni IKE.
Durante la creazione della connessione vengono utilizzati diversi parametri, senza negoziazione dei quali è impossibile stabilire una connessione VPN.
- Identificazione del nodo finale
Come i nodi si autenticano a vicenda. La più comunemente usata è la chiave condivisa. L'autenticazione a chiave condivisa utilizza l'algoritmo Diffie-Hellman. - Rete/host locale e remoto
Specifica il traffico che sarà consentito attraverso il tunnel VPN. - Tunnel o modalità di trasporto.
IPsec può operare in due modalità: tunnel e trasporto. La scelta della modalità dipende dagli oggetti protetti.
modalità tunnel utilizzato per la protezione tra oggetti remoti, ad es. Il pacchetto IP è completamente incapsulato in uno nuovo e solo la connessione tra due punti VPN sarà visibile a un osservatore dall'esterno. Gli indirizzi IP reali dell'origine e della destinazione saranno visibili solo dopo che il pacchetto è stato decapsulato quando viene ricevuto nel punto di ricezione della VPN. Pertanto, la modalità tunnel è più comunemente utilizzata per le connessioni VPN.
Modalità di trasporto protegge i dati del pacchetto IP (TCP, UDP e protocolli di livello superiore) e l'intestazione del pacchetto IP originale verrà preservata. Pertanto, l'origine e la destinazione originali saranno visibili all'osservatore, ma non i dati trasmessi. Questa modalità è più comunemente utilizzata quando si protegge una connessione LAN tra host. - Gateway remoto
Un punto VPN di destinazione della connessione sicura che decrittograferà/autentica i dati dall'altro lato e li invierà alla destinazione finale. - Modalità operativa IKE
La negoziazione IKE può operare in due modalità: di base e aggressivo.
La differenza tra i due è che la modalità aggressiva utilizza meno pacchetti per ottenere una connessione più rapida. La modalità aggressiva, invece, non supera alcuni parametri di trattativa, come i gruppi Diffie-Hellman e PFS, che richiedono una loro identica configurazione preliminare sui punti di connessione. - Protocolli IPsec
Esistono due protocolli IPsec, Authentication Header (AH) e Encapsulating Security Payload (ESP), che eseguono funzioni di crittografia e autenticazione.
ESP ti consente di crittografare, autenticare individualmente o contemporaneamente.
AH consente solo l'autenticazione. La differenza con l'autenticazione ESP è che AH autentica anche l'intestazione IP esterna, consentendo di verificare che il pacchetto provenga effettivamente dall'origine specificata in esso. - Crittografia IKE
Specifica l'algoritmo di crittografia IKE da utilizzare e le relative chiavi. Sono supportati vari algoritmi di crittografia simmetrica, ad esempio: DES, 3DES, AES. - Autenticazione IKE
L'algoritmo di autenticazione utilizzato nell'handshake IKE. Può essere: SHA, MD5. - Gruppi IKE Diffie-Hellman (DH).
Gruppo utilizzato dal DF per lo scambio di chiavi in IKE. Più ampio è il gruppo di argomenti taglia più grande scambiare le chiavi. - Durata della connessione IKE
È specificato sia dal tempo (secondi) che dalla dimensione dei dati trasferiti (kilobyte). Non appena uno dei contatori raggiunge valore di soglia inizia una nuova prima fase. Se non sono stati trasmessi dati dalla creazione della connessione IKE, non verranno create nuove connessioni fino a quando una delle parti non vorrà creare una connessione VPN. - PFS
Con PFS disabilitato, il materiale per la generazione delle chiavi verrà recuperato nella prima fase della negoziazione IKE al momento dello scambio delle chiavi. Nella seconda fase della negoziazione IKE verranno create chiavi di sessione in base al materiale ricevuto. Con PFS abilitato, quando si creano nuove chiavi di sessione, il materiale per esse verrà utilizzato ogni volta che ne vengono nuove. Pertanto, se la chiave è compromettente, non è possibile creare nuove chiavi basate su di essa.
PFS può essere utilizzato in due modalità: prima PFS sulle chiavi, avvierà un nuovo scambio di chiavi nella prima fase di IKE ogni volta che inizia una negoziazione
seconda fase. La seconda modalità, PFS sulle identità, rimuoverà la SA della prima fase ogni volta dopo aver superato la negoziazione della seconda fase, garantendo così che nessuna negoziazione della seconda fase sia crittografata con la stessa chiave della precedente. - Gruppi IPsec DH
Questi gruppi DF sono simili a quelli utilizzati in IKE, utilizzati solo per PFS. - Crittografia IPsec
Algoritmo utilizzato per crittografare i dati. Utilizzato quando si utilizza ESP in modalità di crittografia. Esempi di algoritmi: DES, 3DES, AES. - Autenticazione IPsec
Algoritmo utilizzato per autenticare i dati trasmessi. Utilizzato in caso di AH o ESP in modalità di autenticazione. Esempi di algoritmi: SHA, MD5. - Durata IPsec
La durata di una connessione VPN è indicata sia dal tempo (secondi) che dalla dimensione dei dati trasferiti (kilobyte). Il primo contatore che raggiunge il limite inizierà a ricreare le chiavi di sessione. Se non sono stati trasmessi dati dalla creazione della connessione IKE, non verranno create nuove connessioni fino a quando una delle parti non vorrà creare una connessione VPN.
Metodi di autenticazione IKE
- Modalità manuale
Il metodo più semplice, in cui non viene utilizzato IKE, e le chiavi di autenticazione e crittografia, nonché alcuni altri parametri, vengono impostati manualmente su entrambi i punti della connessione VPN. - Tramite chiavi precondivise (PSK)
Una chiave precondivisa su entrambi i punti della connessione VPN. La differenza rispetto al metodo precedente è che viene utilizzato IKE, che consente di autenticare gli endpoint e utilizzare chiavi di sessione modificabili, anziché chiavi di crittografia fisse. - Certificati
Ogni punto VPN utilizza: la propria chiave privata, la propria chiave pubblica, il suo certificato inclusa la sua chiave pubblica e firmato da un'autorità di certificazione attendibile. A differenza del metodo precedente, permette di evitare di inserire una chiave comune in tutti i punti di connessione VPN, sostituendola con certificati personali firmati da un'autorità fidata.
Protocolli IPsec
I protocolli IPsec vengono utilizzati per proteggere i dati trasmessi. La scelta del protocollo e delle sue chiavi avviene durante la negoziazione IKE.
AH (intestazione di autenticazione)
AH offre la possibilità di autenticare i dati trasmessi. Per fare ciò, viene utilizzata una funzione crittografica hash rispetto ai dati contenuti nel pacchetto IP. L'output di questa funzione (hash) viene trasmesso insieme al pacchetto e consente al punto VPN remoto di confermare l'integrità del pacchetto IP originale, confermando che non è stato modificato lungo il percorso. Oltre ai dati del pacchetto IP, l'AH autentica anche parte della sua intestazione.
In modalità di trasporto, l'AH incorpora la sua intestazione dopo il pacchetto IP originale.
In modalità tunnel, l'AH incorpora la sua intestazione dopo l'intestazione IP esterna (nuova) e prima dell'intestazione IP interna (originale).
ESP (Encapsulating Security Payload)
Il protocollo ESP viene utilizzato per la crittografia, per l'autenticazione o per entrambe su un pacchetto IP.
In modalità di trasporto, il protocollo ESP inserisce la sua intestazione dopo l'intestazione IP originale.
In modalità tunnel ESP, l'intestazione è dopo l'intestazione IP esterna (nuova) e prima di quella interna (originale).
Due differenze principali tra ESP e AH:
- ESP, oltre all'autenticazione, fornisce anche la possibilità di crittografare (AH non lo fornisce)
- ESP in modalità tunnel autentica solo l'intestazione IP originale (AH autentica anche quella esterna).
Lavora dietro NAT (NAT Traversal)
Una specifica separata è stata implementata per supportare il funzionamento dietro NAT. Se il punto VPN supporta questa specifica, IPsec supporta il funzionamento NAT, ma sono presenti determinati requisiti.
Il supporto NAT è composto da due parti:
- A livello IKE, i dispositivi finali comunicano tra loro in merito al supporto, al NAT Traversal e alla versione della specifica supportata.
- A livello ESP, il pacchetto generato è incapsulato in UDP.
NAT Traversal viene utilizzato solo se entrambi i punti lo supportano.
Definizione di NAT: entrambe le VPN inviano gli hash dei loro indirizzi IP insieme alla porta UDP di origine della negoziazione IKE. Queste informazioni vengono utilizzate dal destinatario per determinare se l'indirizzo IP e/o la porta dell'origine sono cambiati. Se questi parametri non sono stati modificati, il traffico non passa attraverso NAT e il meccanismo NAT Traversal non è necessario. Se l'indirizzo o la porta sono stati modificati, è presente un NAT tra i dispositivi.
Una volta che gli endpoint determinano che NAT Traversal è necessario, la negoziazione IKE viene spostata dalla porta UDP 500 alla porta 4500. Questo perché alcuni dispositivi non gestiscono correttamente una sessione IKE sulla porta 500 quando si utilizza NAT.
Un altro problema deriva dal fatto che il protocollo ESP è un protocollo di livello di trasporto e si trova direttamente sopra l'IP. Per questo motivo, i concetti di porta TCP/UDP non sono applicabili ad esso, il che rende impossibile per più di un client connettersi tramite NAT a un gateway. Per risolvere questo problema, ESP viene impacchettato in un datagramma UDP e inviato alla porta 4500, la stessa utilizzata da IKE quando NAT Traversal è abilitato.
NAT Traversal è integrato nei protocolli che lo supportano e funziona senza una configurazione preliminare.
breve cenni storici sull'aspetto del protocollo
Nel 1994, l'Internet Architecture Board (IAB) ha pubblicato il rapporto "Internet Architectural Security". Questo documento descrive le principali aree di applicazione degli strumenti di sicurezza aggiuntivi su Internet, vale a dire la protezione contro il monitoraggio non autorizzato, lo spoofing dei pacchetti e il controllo del flusso di dati. Tra le misure di tutela prioritarie e più importanti è stata indicata la necessità di sviluppare un concetto e meccanismi di base per garantire l'integrità e la riservatezza dei flussi di dati. Poiché un cambiamento nei protocolli di base della famiglia TCP/IP avrebbe causato una completa ristrutturazione di Internet, il compito era garantire la sicurezza dello scambio di informazioni nelle reti di telecomunicazioni aperte basate sui protocolli esistenti. Così, è iniziata la creazione della specifica Secure IP, aggiuntiva ai protocolli IPv4 e IPv6.
Architettura IPSec
IP Security è una suite di protocolli che si occupano di crittografia, autenticazione e sicurezza nel trasporto di pacchetti IP; ora include quasi 20 proposte di standard e 18 RFC.
La specifica IP Security (conosciuta oggi come IPsec) è stata sviluppata dall'IP Security Protocol Working Group dell'IETF. Inizialmente, IPsec includeva 3 specifiche di base indipendenti dall'algoritmo pubblicate come RFC "IP Security Architecture", "Authentication Header (AH)", "Encrypted Data Encapsulation (ESP)" (RFC1825, 1826 e 1827). Va notato che nel novembre 1998 il gruppo di lavoro IP Security Protocol ha proposto nuove versioni di queste specifiche, che attualmente hanno lo stato di standard preliminari, si tratta di RFC2401 - RFC2412. Si noti che RFC1825-27 è stato considerato obsoleto per diversi anni e non è realmente utilizzato. Inoltre, esistono diverse specifiche dipendenti dall'algoritmo che utilizzano i protocolli MD5, SHA, DES.
Fig. 1. Architettura IPSec
L'IP Security Protocol Working Group sviluppa anche protocolli chiave di gestione delle informazioni. Il compito di questo gruppo è sviluppare l'Internet Key Management Protocol (IKMP), un protocollo di gestione delle chiavi a livello di applicazione indipendente dai protocolli di sicurezza utilizzati. I concetti di gestione delle chiavi sono attualmente allo studio utilizzando la specifica ISAKMP (Internet Security Association e Key Management Protocol) e l'Oakley Key Determination Protocol. La specifica ISAKMP descrive i meccanismi per negoziare gli attributi dei protocolli utilizzati, mentre il protocollo Oakley consente di impostare chiavi di sessione sui computer su Internet. In precedenza, venivano considerate anche le possibilità di utilizzare i meccanismi di gestione delle chiavi SKIP, ma ora tali possibilità non sono praticamente utilizzate da nessuna parte. Gli standard di gestione delle informazioni chiave in fase di creazione supporteranno probabilmente i centri di distribuzione delle chiavi simili a quelli utilizzati nel sistema Kerberos. I protocolli di gestione delle chiavi per IPSec basati su Kerberos sono attualmente gestiti da un sistema relativamente nuovo gruppo di lavoro KINK (negoziazione Internet Kerberizzata delle chiavi).
Le garanzie di integrità e riservatezza dei dati nella specifica IPsec sono fornite rispettivamente attraverso l'uso di meccanismi di autenticazione e crittografia. Questi ultimi, a loro volta, si basano sull'accordo preliminare delle parti sul cosiddetto scambio di informazioni. "contesto di sicurezza" - algoritmi crittografici applicati, algoritmi di gestione delle informazioni chiave e loro parametri. La specifica IPsec prevede la possibilità per le parti di scambiare informazioni per supportare vari protocolli e parametri per l'autenticazione e la crittografia dei pacchetti di dati, nonché vari schemi di distribuzione delle chiavi. Allo stesso tempo, il risultato della negoziazione del contesto di sicurezza è la definizione di un indice dei parametri di sicurezza (SPI), che è un indicatore di un certo elemento della struttura interna del lato scambio di informazioni che descrive possibili insiemi di parametri di sicurezza.
In sostanza, IPSec, che diventerà parte integrale IPv6, funziona al terzo livello, ovvero al livello di rete. Di conseguenza, i pacchetti IP trasmessi saranno protetti in modo trasparente per le applicazioni e l'infrastruttura di rete. A differenza di SSL (Secure Socket Layer), che opera al quarto livello (ovvero di trasporto) ed è più strettamente associato ai livelli più alti del modello OSI, IPSec è progettato per fornire una sicurezza di basso livello.
Fig.2. Modello OSI/ISO
Per IP dati pronti per la trasmissione virtuale rete privata, IPSec aggiunge un'intestazione per identificare i pacchetti protetti. Prima di essere trasmessi su Internet, questi pacchetti vengono incapsulati in altri pacchetti IP. IPSec supporta diversi tipi di crittografia, inclusi Data Encryption Standard (DES) e Message Digest 5 (MD5).
Per stabilire una connessione sicura, entrambi i partecipanti alla sessione devono essere in grado di concordare rapidamente parametri di sicurezza come algoritmi di autenticazione e chiavi. IPSec supporta due tipi di schemi di gestione delle chiavi attraverso i quali i partecipanti possono negoziare i parametri di sessione. Questo doppio supporto ha causato qualche attrito nel gruppo di lavoro IETF in quel momento.
Con l'attuale versione di IP, IPv4, è possibile utilizzare il protocollo ISAKMP (Internet Secure Association Key Management Protocol) o il protocollo Simple Key Management for Internet. DA nuova versione IP, IPv6, dovrà utilizzare ISAKMP, ora noto come IKE, sebbene la possibilità di utilizzare SKIP non sia esclusa. Tuttavia, va tenuto presente che SKIP non è più considerato un candidato chiave per la gestione ed è stato rimosso dall'elenco dei possibili candidati già nel 1997.
Intestazioni AH ed ESP
Intestazione di autenticazione AH
L'intestazione di autenticazione (AH) è una normale intestazione opzionale e di solito si trova tra l'intestazione del pacchetto IP principale e il campo dati. La presenza di AH non pregiudica il processo di trasferimento delle informazioni del trasporto e degli strati superiori. Lo scopo principale e unico di AH è fornire protezione contro gli attacchi associati a modifiche non autorizzate al contenuto del pacchetto, incluso lo spoofing dell'indirizzo originale del livello di rete. I protocolli di livello superiore devono essere modificati al fine di effettuare la verifica dell'autenticità dei dati ricevuti.
Il formato AH è abbastanza semplice e consiste in un'intestazione a 96 bit e dati a lunghezza variabile di parole a 32 bit. I nomi dei campi riflettono il loro contenuto in modo abbastanza chiaro: Next Header indica l'intestazione successiva, Payload Len rappresenta la lunghezza del pacchetto, SPI è un puntatore al contesto di sicurezza e Sequence Number Field contiene il numero di sequenza del pacchetto.
Fig.3. Formato dell'intestazione AH
Il numero di sequenza del pacchetto è stato introdotto nell'AH nel 1997 durante il processo di revisione della specifica IPsec. Il valore di questo campo è generato dal mittente e serve a proteggere dagli attacchi legati al riutilizzo dei dati del processo di autenticazione. Poiché Internet non garantisce l'ordine di consegna dei pacchetti, il destinatario deve conservare le informazioni sul numero di sequenza massimo di un pacchetto che è stato autenticato con successo e sulla ricezione di un certo numero di pacchetti contenenti numeri di sequenza precedenti (di solito questo numero è 64).
Contrariamente agli algoritmi per il calcolo del checksum utilizzati nei protocolli per la trasmissione di informazioni su linee di comunicazione dial-up o su canali LAN e incentrati sulla correzione di errori casuali nel mezzo di trasmissione, i meccanismi di integrità dei dati nelle reti di telecomunicazioni aperte devono disporre di mezzi di protezione contro la creazione di cambiamenti mirati. Uno di questi meccanismi è un'applicazione speciale dell'algoritmo MD5: durante la formazione di AH, una funzione hash viene calcolata in sequenza dalla combinazione del pacchetto stesso e di qualche chiave prestabilita, e quindi dalla combinazione del risultato e della trasformata chiave. Questo meccanismo applicato per impostazione predefinita al fine di fornire a tutte le implementazioni di IPv6 almeno un algoritmo comune non soggetto a restrizioni di esportazione.
incapsulamento di dati ESP crittografati
Nel caso dell'incapsulamento dei dati crittografati, l'intestazione ESP è l'ultima delle intestazioni opzionali "visibili" nel pacchetto. Poiché lo scopo principale di ESP è garantire la riservatezza dei dati, diversi tipi di informazioni possono richiedere l'uso di algoritmi di crittografia significativamente diversi. Pertanto, il formato ESP può subire modifiche significative a seconda degli algoritmi crittografici utilizzati. Tuttavia si possono distinguere i seguenti campi obbligatori: SPI che indica il contesto di sicurezza e Sequence Number Campo contenente il numero di sequenza del pacchetto. Il campo "Dati di autenticazione ESP" (checksum) è facoltativo nell'intestazione ESP. Il destinatario del pacchetto ESP decodifica l'intestazione ESP e utilizza i parametri ei dati dell'algoritmo di crittografia applicato per decodificare le informazioni del livello di trasporto.
Fig.4. Formato dell'intestazione ESP
Esistono due modalità di applicazione di ESP e AH (così come le loro combinazioni) - trasporto e tunnel:
La modalità di trasporto viene utilizzata per crittografare il campo dati di un pacchetto IP contenente protocolli di livello di trasporto (TCP, UDP, ICMP), che a sua volta contiene informazioni sul servizio dell'applicazione. Un esempio di applicazione della modalità di trasporto è la trasmissione E-mail. Tutti i nodi intermedi sul percorso del pacchetto dal mittente al destinatario utilizzano solo informazioni aperte livello di rete e possibilmente alcune intestazioni di pacchetti opzionali (in IPv6). Lo svantaggio della modalità di trasporto è la mancanza di meccanismi per nascondere lo specifico mittente e destinatario del pacchetto, nonché la possibilità di analisi del traffico. Il risultato di tale analisi può essere informazioni sul volume e sulla direzione del trasferimento di informazioni, sulle aree di interesse degli abbonati, sull'ubicazione dei gestori.
La modalità tunnel crittografa l'intero pacchetto, inclusa l'intestazione del livello di rete. La modalità tunnel viene utilizzata quando è necessario nascondere lo scambio di informazioni dell'organizzazione con il mondo esterno. Allo stesso tempo, i campi dell'indirizzo dell'intestazione a livello di rete di un pacchetto che utilizza la modalità tunnel vengono riempiti dal firewall dell'organizzazione e non contengono informazioni sul mittente specifico del pacchetto. Quando si trasmettono informazioni dal mondo esterno a rete locale organizzazione, l'indirizzo di destinazione è l'indirizzo di rete del firewall. Dopo che il firewall ha decrittografato l'intestazione del livello di rete iniziale, il pacchetto viene inviato al destinatario.
Associazioni di sicurezza
Una Security Association (SA) è una connessione che fornisce servizi di sicurezza per il traffico che la attraversa. I due computer su ciascun lato della SA memorizzano la modalità, il protocollo, gli algoritmi e le chiavi utilizzati nella SA. Ciascun SA viene utilizzato in una sola direzione. Per la comunicazione bidirezionale sono necessarie due SA. Ogni SA implementa una modalità e un protocollo; quindi, se è necessario utilizzare due protocolli (come AH ed ESP) per un pacchetto, sono necessarie due SA.
Politica di sicurezza
La politica di sicurezza è archiviata nell'SPD (Security Policy Database). L'SPD può specificare una delle tre azioni per un pacchetto di dati: scartare il pacchetto, non elaborare il pacchetto con IPSec, elaborare il pacchetto con IPSec. In quest'ultimo caso, l'SPD specifica anche quale SA utilizzare (ammesso che sia già stata creata una SA adeguata, ovviamente) o specifica con quali parametri dovrebbe essere creata una nuova SA.
SPD è un meccanismo di controllo molto flessibile che consente molto buona gestione elaborazione di ogni pacchetto. I pacchetti sono classificati in base a un numero elevato di campi e l'SPD può controllare alcuni o tutti i campi per determinare l'azione appropriata. Ciò può comportare l'invio di tutto il traffico tra due macchine utilizzando una singola SA o l'utilizzo di SA separate per ciascuna applicazione o anche per ciascuna connessione TCP.
Protocollo ISAKMP/Oakley
Il protocollo ISAKMP definisce struttura complessiva protocolli utilizzati per stabilire una SA e per eseguire altre funzioni di gestione delle chiavi. ISAKMP supporta diversi Domains of Interpretation (DOI), uno dei quali è IPSec-DOI. ISAKMP non definisce un protocollo completo, ma fornisce "blocchi di costruzione" per vari DOI e protocolli di scambio di chiavi.
Il protocollo Oakley è un protocollo di determinazione della chiave che utilizza l'algoritmo di sostituzione della chiave Diffie-Hellman. Il protocollo Oakley supporta Perfect Forward Secrecy (PFS). La presenza di PFS significa che tutto il traffico non può essere decrittografato se una qualsiasi chiave nel sistema è compromessa.
protocollo IKE ipad = byte 0x36 ripetuto B volte; Per calcolare l'HMAC dai dati "di testo", è necessario eseguire la seguente operazione: H(K XOR opad, H(K XOR ipad, testo)) Dalla descrizione deriva che IKE utilizza i valori HASH per autenticare le parti. Si noti che HASH in questo caso si riferisce esclusivamente al nome Payload in ISAKMP e questo nome non ha nulla a che fare con il suo contenuto. attacchi su AH, ESP e IKE Come sapete, questo è un attacco contro il quale non esiste una protezione completa. Tuttavia, il rapido rifiuto dei pacchetti danneggiati e l'assenza di qualsiasi reazione esterna ad essi (secondo la RFC) consentono di affrontare più o meno bene questo attacco. In linea di principio, la maggior parte (se non tutti) gli attacchi di rete noti (sniffing, spoofing, dirottamento, ecc.) vengono contrastati con successo da AH ed ESP se utilizzati correttamente. Con IKE, è un po' più complicato. Il protocollo è molto complesso, difficile da analizzare. Inoltre, a causa di errori di battitura (nella formula di calcolo HASH_R) in fase di scrittura e soluzioni non del tutto riuscite (gli stessi HASH_R e HASH_I), contiene diversi potenziali "buchi" (in particolare, non tutti i Payload nel messaggio sono autenticati nel prima fase), tuttavia, non sono molto gravi e portano, al massimo, al rifiuto di stabilire una connessione IKE è più o meno protetto con successo da attacchi come replay, spoofing, sniffing, hijacking. Con la crittografia, è un po' più complicato: non viene visualizzato separatamente, come in AH ed ESP, ma viene implementato nel protocollo stesso. Tuttavia, quando si utilizzano algoritmi e primitive persistenti (PRF), non dovrebbero esserci problemi. In una certa misura, può essere considerato un punto debole di IPsec che DES sia indicato come l'unico algoritmo di crittografia obbligatorio per l'implementazione nelle specifiche attuali (questo vale sia per ESP che per IKE), di cui 56 bit della chiave non sono più considerati sufficiente. Tuttavia, questa è una debolezza puramente formale: le specifiche stesse sono indipendenti dall'algoritmo e quasi tutti i noti fornitori hanno implementato da tempo 3DES (e alcuni hanno già implementato AES).Quindi, se implementato correttamente, Denial-Of-Service rimane il attacco più "pericoloso". Valutazione del protocollo IPSec Si consideri l'architettura della famiglia di protocolli IPSec. Lo scopo di questa famiglia di protocolli è fornire diversi servizi di sicurezza a livello IP per IPv4 e IPv6. Considera i servizi di sicurezza forniti dai protocolli IPSec e l'uso di questi protocolli nelle reti TCP/IP. Quando questi servizi sono installati correttamente, non interferiscono con utenti, host e altri componenti di Internet che non utilizzano questi servizi di sicurezza per proteggere il proprio traffico. Questi servizi sono indipendenti dall'algoritmo. Ciò significa che è possibile aggiungere nuovi algoritmi crittografici senza modificare i protocolli stessi. Ad esempio, diversi gruppi di utenti possono utilizzare diversi insiemi di algoritmi. È stato definito un insieme standard di algoritmi predefiniti per garantire l'interoperabilità in Internet. L'utilizzo di questi algoritmi insieme alla protezione del traffico fornita da IPSec e ai protocolli di gestione delle chiavi consentirà al progettista di sistemi e applicazioni di fornire un elevato grado di sicurezza crittografica. IPSec può essere implementato sia nel sistema operativo che nel router o firewall. IPSec fornisce riservatezza, l'integrità dei dati, controllo di accesso e l'autenticazione dell'origine dei dati per i datagrammi IP. Questi servizi sono forniti attraverso la statefulness tra l'origine e la destinazione dei datagrammi IP. Questo stato definisce i servizi di sicurezza specifici a livello di datagramma, gli algoritmi crittografici utilizzati per i servizi forniti e le chiavi per tali algoritmi. Elenchiamo i compiti principali dei protocolli IPSec: IPSec è progettato per comunicazioni sicure utilizzando la crittografia per i protocolli IPv4 e IPv6. I servizi di sicurezza includono controllo di accesso, integrità e riservatezza dati e protezione contro i replay attack, che viene fornita garantendo l'integrità di una determinata sequenza di datagrammi. Questi servizi sono forniti a livello IP, fornendo protezione per il protocollo IP e protocolli di livello superiore. IPSec supporta due forme di integrità: l'integrità dei dati e l'integrità di una particolare sequenza di datagrammi. L'integrità dei dati rileva la modifica di un particolare datagramma IP, indipendentemente dalla sequenza di datagrammi nel flusso di traffico. Datagram Sequence Integrity è un servizio anti-risposta che determina se vengono ricevuti datagrammi IP duplicati. Questo è diverso dall'integrità del collegamento, che ha requisiti di integrità del traffico più severi, ovvero la capacità di rilevare i messaggi persi o riordinati. Considerare l'implementazione dei protocolli IPSec, i componenti principali del sistema e la loro interazione per fornire servizi di sicurezza. IPSec viene eseguito su un host (Host - H) o un gateway di sicurezza (Security Gateway - SG), fornendo protezione per il traffico IP. Il termine Security Gateway viene utilizzato per riferirsi a un router che implementa i protocolli IPsec. La sicurezza si basa sui requisiti definiti nel Security Policy Database (SPD), che viene installato e gestito dall'amministratore. In generale, i pacchetti vengono elaborati in uno dei tre modi, in base all'intestazione IP e alle informazioni sul livello di trasporto, in base alle voci nell'SPD. Ogni pacchetto viene eliminato, passato senza elaborazione o elaborato in base alla voce SPD per quel pacchetto. Esistono diversi modi per implementare IPSec su un host o in combinazione con un router o un firewall (per creare un gateway di sicurezza). I servizi di protezione del traffico forniti da IPSec sono implementati utilizzando due protocolli di traffico sicuro: Authentication Header (AH) e Encapsulating Security Payload (ESP). I seguenti protocolli sono definiti per proteggere il traffico in IPSec: Il traffico protetto da IPSec è associato al concetto di Security Association (SA). SA contiene tutte le informazioni necessarie per eseguire vari servizi di sicurezza della rete. SA è simplex (unidirezionale) connessione logica, creato tra due endpoint che utilizzano uno dei protocolli IPSec per la sicurezza. ESP e AH trasportano il traffico su SA. Tutto il traffico trasmesso su SA viene elaborato in conformità con la politica di sicurezza impostata alle estremità della connessione. Descriviamo vari aspetti della gestione di SA, definiamo possibili modi per gestire la politica di sicurezza, i metodi di elaborazione del traffico e la gestione di SA. La SA definisce i parametri dei servizi di sicurezza che vengono applicati al traffico. Tipicamente, una connessione bidirezionale tra due host o tra due Security Gateway richiede due SA (una per ciascuna direzione). Considereremo SA solo per connessioni unicast. Sono definite due modalità SA: modalità di trasporto e modalità tunnel. Modalità di trasporto utilizzato per creare una VPN tra due host. In IPv4, l'intestazione Transport Mode Security Protocol viene visualizzata immediatamente dopo l'intestazione IP. Nel protocollo ESP, la modalità di trasporto SA fornisce servizi di sicurezza solo per protocolli di livello superiore, non per l'intestazione IP. Nel caso di AH, la protezione si estende anche a parti dell'intestazione IP. Un'altra modalità SA è la modalità tunneling. Se una delle estremità della connessione è un Security Gateway, secondo gli standard IPSec SA, deve essere eseguito in modalità tunnel, ma in questo caso molti produttori consentono sia la modalità tunnel che quella di trasporto. Si noti che quando il traffico è destinato a un gateway di sicurezza, come nel caso dei comandi ping o SNMP, il gateway di sicurezza viene trattato come un host e viene generalmente utilizzato modalità di trasporto. I due host possono opzionalmente impostare modalità tunnel. In modalità tunnel, viene aggiunta un'intestazione IP esterna, in cui gli indirizzi sono gateway di sicurezza. L'intestazione IP interna indica gli host di destinazione. L'intestazione del protocollo di sicurezza si trova dopo l'intestazione IP esterna e prima dell'intestazione IP interna. Se l'AH viene utilizzato in modalità tunnel, parti dell'intestazione IP esterna sono protette, così come l'intero pacchetto IP in tunnel, ad es. tutte le intestazioni interne sono protette, così come tutti i protocolli di livello superiore. Se viene utilizzato ESP, la protezione viene fornita solo per il pacchetto in tunnel, non per l'intestazione esterna. Riassumiamo brevemente: Set di realizzabile
IKE è il protocollo di scambio delle chiavi predefinito per ISAKMP, attivo questo momento essere l'unico. IKE si trova sopra ISAKMP e realizza l'effettiva costituzione sia di ISAKMP SA che di IPSec SA. IKE supporta un insieme di diverse funzioni primitive da utilizzare nei protocolli. Tra questi ci sono la funzione hash e la funzione pseudo-casuale (PRF).
Una funzione hash è una funzione resistente alle collisioni. La resistenza alla collisione è intesa come il fatto che è impossibile trovare due diversi messaggi m1 e m2 tali che H(m1)=H(m2), dove H è una funzione hash.
Per quanto riguarda le funzioni pseudo-casuali, attualmente, invece di PRF speciali, viene utilizzata una funzione hash nella progettazione HMAC (HMAC è un meccanismo di autenticazione dei messaggi che utilizza funzioni hash). Per definire HMAC, abbiamo bisogno di una funzione di hash crittografica (indicata come H) e di una chiave segreta K. Assumiamo che H sia una funzione di hash in cui i dati vengono sottoposti a hash utilizzando una procedura di compressione applicata in sequenza a una sequenza di blocchi di dati. Indicheremo con B la lunghezza di tali blocchi in byte e la lunghezza dei blocchi ottenuti come risultato dell'hashing - come L (L
opad = byte 0x5C ripetuto B volte.
Tutti i tipi di attacchi ai componenti IPSec possono essere suddivisi nei seguenti gruppi: attacchi che sfruttano la finitezza delle risorse di sistema (un tipico esempio è un attacco Denial of Service, Denial of Service o DOS), attacchi che utilizzano le funzionalità e errori di una specifica implementazione IPSec e, infine, attacchi basati sui punti deboli degli stessi protocolli AH ed ESP. Gli attacchi puramente crittografici possono essere ignorati: entrambi i protocolli definiscono il concetto di "trasformazioni", in cui tutta la crittografia è nascosta. Se il criptoalgoritmo utilizzato è resistente e la trasformazione definita con esso non introduce ulteriori punti deboli (non è sempre così, quindi è più corretto considerare la stabilità dell'intero sistema - Protocol-Transform-Algorithm), allora da questo lato va tutto bene. Cosa rimane? Replay Attack - livellato utilizzando il numero di sequenza (in un singolo caso non funziona - quando si utilizza ESP senza autenticazione e senza AH). Inoltre, l'ordine delle azioni (prima crittografia, poi autenticazione) garantisce un rapido rifiuto dei pacchetti "cattivi" (inoltre, secondo le ultime ricerche nel mondo della crittografia, è questo ordine di azioni che è più sicuro, l'ordine inverso in alcuni casi, seppur molto particolari, possono portare a potenziali falle di sicurezza; fortunatamente né SSL, né IKE, né altri protocolli comuni con protocollo "prima autentica, poi crittografa" non appartengono a questi casi speciali, e quindi non hanno questi buchi). Ciò che resta è l'attacco Denial-Of-Service.
Il protocollo IPSec ha ricevuto recensioni contrastanti da parte di esperti. Da un lato, si segnala che il protocollo IPSec è il migliore tra tutti gli altri protocolli per la protezione dei dati trasmessi in rete, sviluppato in precedenza (compreso quello sviluppato da Microsoft PPTP). Secondo l'altro lato, vi è eccessiva complessità e ridondanza del protocollo. Ad esempio, Niels Ferguson e Bruce Schneier nel loro lavoro "A Cryptographic Evaluation of IPsec" notano di aver riscontrato seri problemi di sicurezza in quasi tutti i componenti principali di IPsec. Questi autori sottolineano inoltre che la suite di protocolli richiede molto lavoro per fornire un buon livello di sicurezza.Possibili modi per implementare IPSec
Protocolli di protezione del traffico e concetto di associazione sicura
