close

IPsec

Hoppa till navigering Hoppa till sökning

Inom telekommunikation och informationsteknik är IPsec , kort för IP Security , en standard för paketnätverk som syftar till att uppnå säkra anslutningar över IP -nätverk . Denna säkerhet uppnås genom att lägga till autentisering , kryptering och integritetskontroll av IP- paket ( datagram ) . Möjligheten att tillhandahålla skydd eller säkerhet tillhandahålls därför på nätverksnivå (i motsats tillHTTPS , SSL / TLS ), vilket gör detta protokoll transparent på applikationsnivå som därför inte får modifieras.

Standardöversikt

Syftet med projektet

IPsec utformades för att säkra både portal-till-portal och end-to-end- kommunikation . I den första konfigurationen görs trafiken " säker " till olika datorer (i vissa fall till ett helt LAN ); i det andra är det bara de peers som upprättar anslutningen som utbyter säkra paket. Den dominerande användningen av IPsec är dock skapandet av virtuella privata nätverk ; båda ovanstående metoder kan användas för att uppnå detta syfte.

Introduktion

IPsec är en samling protokoll som består av:

  • Protokoll som implementerar utbyte av nycklar för att realisera det krypterade flödet.
  • Protokoll som ger dataströmskryptering.

Det finns bara ett protokoll för nyckelutbyte, IKE- protokollet . IPsec är en integrerad del av IPv6 , medan det är valfritt i IPv4 . Följaktligen förväntas det att det kommer att användas mer när IPv6 vinner popularitet. Protokollet definieras i RFCs 2401-2412. Studier har pågått sedan 2004 för att uppdatera protokollen.

När det gäller den andra aspekten finns det två protokoll: Authentication Header (AH) och Encapsulating Security Payload (ESP).

AH tillhandahåller autentisering och meddelandeintegritet , men erbjuder inte konfidentialitet och är IP 51-protokollet.
ESP tillhandahåller istället autentisering, konfidentialitet och meddelandeintegritetskontroll och är IP 50-protokollet. Av dessa skäl används ESP mycket mer än AH.

Tekniska detaljer

IPsec stöder två driftlägen:

  • Transportläge
    1. värd -till-värd- anslutning ;
    2. används av slutpunkter, inte gateways ;
    3. vid kryptering är endast nyttolasten för IP-datagrammen krypterad, inte rubriken ;
    4. beräkningsmässigt lätt;
    5. varje värd som vill kommunicera måste ha all programvara som behövs för att implementera IPsec;
    6. endast IPsec-huvudet läggs till; slutpunkternas avsändar- och mottagaradresser är detekterbara.
  • Tunnelläge
    1. gateway-till-gateway-anslutning;
    2. vid kryptering är hela det ursprungliga IP-paketet krypterat;
    3. används för att bygga VPN;
    4. beräkningsmässigt betungande;
    5. endast gateways måste ha IPsec-programvara;
    6. det finns centraliseringspunkter, därför enskilda punkter av misslyckande;
    7. använder en dubbel inkapsling och placerar som nyttolast för kommunikationen mellan gatewayadresser vad som erhålls genom att kryptera föreningen av avsändar- och mottagaradresser för slutpunkterna med den faktiska nyttolasten; Genom att anta protokollet Encapsulating Security Payload är avsändar- och mottagaradresserna för slutpunkterna därför inte längre detekterbara (de förblir detekterbara genom att anta AH).

De två lägena stöds av både AH och ESP.

IPsec kan också användas för anslutningar mellan gateways och värdar.

Säkerhetsförening och säkerhetspolicy

Konceptet med Security Association ( SA för kort ) är grunden för hur IPsec fungerar. En SA är ett "kontrakt" mellan de två enheterna som är involverade i kommunikationen; den fastställer skyddsmekanismerna och nycklarna som ska användas under den efterföljande dataöverföringen. I samband med IPsec är det IKE- protokollets ansvar att upprätta säkerhetsassociationer , även om det också är möjligt att ställa in dem manuellt; den manuella proceduren rekommenderas inte eftersom den kan införa fel som försvagar tunneln.

En egenhet med SA är att de identifierar en enkelriktad kommunikation; under skapandet av anslutningen skapar och hanterar de inblandade enheterna därför en SA för var och en av kommunikationsriktningarna, sedan identifierar två SA:er en full-duplex- kanal . För att förenkla hanteringen av SA:erna används en speciell databas kallad SAD ( S ecurity A ssociation D atabase), där de aktiva SA:erna hålls koll. I synnerhet består en SA av följande parametrar:

  • IP-adresserna för de kamrater som är involverade i kommunikationen;
  • Protokollet som kommer att användas för tunneln (AH eller ESP);
  • de krypteringstekniker som används och de relaterade nycklarna;
  • Ett 32-bitars heltal som kallas SPI , som står för S ecurity P arameter I ndex.

Från granskningen av parametrarna för en SA härleds därför all information som är nödvändig för att fastställa de metoder som trafiken måste skyddas; nästa steg är att definiera vilken trafik som ska skyddas: detta är vad Säkerhetspolicyn (kort sagt SP ) tar hand om. En SP är en regel som bestämmer vilken typ av trafik som ska dirigeras i tunneln och därför omfattas av IPsec; på samma sätt som SA:er finns SP:erna i en SPD ( S ecurity P olicy D atabase). Säkerhetspolicyn innehåller:

  • Källadress och destinationsadress för paketet. Denna information finns redan i SA och kan därför verka överflödig. Egentligen är denna information vettig när tunnelläget används.
  • Protokollet och dess hamn att dirigera i tunneln. Detta alternativ beror på protokollimplementeringen och övervägs inte alltid; om den inte är tillgänglig transporteras all trafik som produceras i tunneln.
  • En SA-identifierare som ska användas för att behandla data.

När säkerhetsföreningen och säkerhetspolicyn har upprättats kan kommunikationen börja som kommer att använda AH-protokollet eller ESP-protokollet som SPI-parametern kommer att skickas till, vilket gör det möjligt att spåra de kryptografiska tekniker som ska användas för överföring.

IPsec-protokoll

IKE

Beskrivning

IKE är en akronym för Internetnyckel och xchange och är det protokoll som används för att upprätta en säkerhetsassociation i IPsec- protokollsviten . Detta protokoll är definierat i RFC 4306 . Det är ett applikationslagerprotokoll och använder UDP som sitt transportprotokoll ; porten som anslutningen upprättas på är 500.

IKE:s mål är att etablera en delad sessionshemlighet , det vill säga en delad nyckel som motsvarar den session som ska upprättas och för detta ändamål använder den Diffie-Hellman-algoritmen ; de kryptografiska nycklarna som kommer att användas för efterföljande kommunikation härleds därefter från den delade hemligheten . För att autentisera de enheter som är involverade i kommunikationen kan symmetriska nyckeltekniker eller, alternativt, asymmetriska nyckeltekniker användas; i det senare fallet används publika nyckelinfrastrukturer (PKI) och användningen av digitala certifikat .

Autentiseringshuvud (AH)

Beskrivning

Authentication Header (förkortat AH ), är ett protokoll som ingår i IPsec-sviten. Dess uppgift är att tillhandahålla paket-för-paket-integritetskontroll, verifiering av avsändarens äkthet och replay -skydd . AH garanterar inte på något sätt meddelandets konfidentialitet.

Autenticitet garanteras genom symmetriska nyckelhash-funktioner, det vill säga genom mekanismen för fördelade nycklar. För att kunna kommunicera måste två enheter dela samma nyckel; denna nyckel kombineras med det ursprungliga meddelandet och sedan beräknas kontrollsumman med hjälp av en kryptografisk hashfunktion (MD5 eller SHA). Slutligen skickas meddelandet och kontrollsumman till den externa peer . Den fjärranslutna kamraten tar emot meddelandet; eftersom detta är klart kan det läsa det, kombinera det med nyckeln det känner till och beräkna kontrollsumman. Om kontrollsumman stämmer överens med den som skickades är meddelandet autentiskt och accepteras annars kasseras det eftersom det har modifierats på ett sätt som inte tillåts av standarden.

AH-protokollet är utformat för att skydda hela IP-paketet som skickas; det måste emellertid beaktas att vissa fält i IP-huvudet, såsom TTL , varierar under överföringen; dessa ändringar måste nödvändigtvis tillåtas, så innan kontrollsumman beräknas, sätts fälten som tillåts variera till 0 .

Paketformat

Strukturen för AH-paketet visas nedan (varje ruta representerar 1 byte ).

0 1 2 3
Nästa rubrik Nyttolaststorlek RESERVERAD
Säkerhetsparameterindex (SPI)
Successionsnummer

Autentiseringsdata (variabel längd)

Nästa rubrik
Indikerar vilken typ av protokoll som kommer härnäst.
Nyttolaststorlek (8 bitar)
Längden på AH i ord (1 ord = 32 bitar) minus 2. Till exempel är 96 standardbitar i fältet Autentiseringsdata, plus ytterligare 96 bitar för fälten med fast längd för AH gör 6 ord (96 + 96 = 192 bitar, dividerat med 32 = 6). Att subtrahera 2 resulterar därför i 4 det inneslutna värdet av standardnyttolastens storlek.
RESERVERAD
Utrymme kvar för framtida utveckling. Alla bitar i detta fält är inställda på 0.
Säkerhetsparameterindex
Detta fält identifierar säkerhetsparametrarna i kombination med IP-adressen. Det är i allmänhet ett pseudoslumptal som identifierar säkerhetsföreningen som detta paket är en del av.
Sekvensnummer
En rad monotont ökande siffror. För att förhindra omspelsattacker får sekvensnumret när det når maxvärdet (2 ^ {32} -1) inte återgå till 0, utan en ny SA måste skapas.
Data för autentisering
Den innehåller integritetskontrollvärdet (ICV) och representerar HMAC som beräknats av avsändaren av meddelandet. HMAC beräknas med hjälp av fälten i IP-huvudet (med den ursprungliga TTL ), fälten i AH-huvudet förutom autentiseringsdata (det anses vara 0) och slutligen all data från de högre nivåerna, inklusive dessa applikationer , som inte ändras under transport.

Transportläge och tunnelläge

AH stöder inbyggt både transport- och tunnellägen . I transportläge är endast protokoll på en högre nivå än nätverket ( TCP , UDP , etc) skyddade; i tunnelläge är det ursprungliga IP-paketet inkapslat i ett nytt IP-paket, efter att ha bearbetats av AH. Vi förklarar hur det fungerar med hjälp av några ritningar. Måtten är utan tvekan det ursprungliga IP-paketet; i närvaro av en IPsec-baserad anslutning ändras paketet uppenbarligen.

IP-huvud TCP-huvud Data

Original IP-paket

Beroende på driftläget för IPsec (tunnelläge eller transportläge), ändras originalpaketet på olika sätt.

IP-huvud Rubrik AH TCP-huvud Data
autentiserade data

AH i transportläge

Extern IP-header Rubrik AH IP-huvud TCP-huvud Data
autentiserade data

AH i tunnelläge

Den blå linjen indikerar de områden i paketet som är autentiserade. Ur säkerhetssynpunkt är paketen i båda fallen helt skyddade. Vi noterar att i IP-huvudet varierar vissa fält under överföring i nätverket, till exempel TTL . Dessa fält sätts till 0 innan hashfunktionen beräknas , vilket är nödvändigt för att skydda paketet. Av det som just har sagts är det omedelbart klart att AH-protokollet är oförenligt med de olika NAT- teknikerna ; i själva verket, om adressfälten i IP-huvudet ändras (i båda lägena), misslyckas kontrollsumman omedelbart vid mottagning.

Encapsulating Security Payload (ESP)

Beskrivning

Encapsulating Security Payload , betecknat med akronymen ESP , är ett protokoll som ingår i IPsec-sviten. Dess mål är att tillhandahålla autenticitet, konfidentialitet och integritetskontroll till kommunikation. I motsats till vad AH gör , omfattas inte IP-huvudet av kontrollerna. Liksom AH stöder den dock både tunnel- och transportsätt.

Paketformat

Formatet för ESP -paketet visas nedan (varje ruta representerar 1 byte ).

0 1 2 3
Säkerhetsparameterindex (SPI)
Sekvensnummer

Nyttolast * (variabel)

  Utfyllnad (0-255 byte)
    Pads längd Nästa rubrik

Autentiseringsdata (variabel)

Säkerhetsparameterindex (SPI)
Precis som vad som händer i AH, identifierar detta fält, i kombination med IP-adressen, den säkerhetsförening som paketet tillhör.
Sekvensnummer
En monotont ökande rad av nummer, som identifierar paketet inom Security Association och förhindrar reprisattacker .
Nyttolast
Uppgifterna som ska överföras
Stoppning
Det är ett utfyllnadsfält. Det är nödvändigt eftersom vissa chifferkoder fungerar på block med fast längd. Den används för att öka storleken på data tills den blir en multipel av blocket som den använda algoritmen kan hantera.
Pads längd
Representerar, i oktetter, storleken på tillagda utfyllnadsdata.
Nästa rubrik
Identifierar protokollet för de data som överförs
Autentiseringsdata
Innehåller data som används för att autentisera paketet.

Som kan ses från paketstrukturen (men kommer att illustreras bättre senare), " lindar " ESP data från protokoll på högre nivå, i motsats till AH som lägger till en header.

Tunnelläge och transportläge

Eftersom det är ett dataöverföringsprotokoll för IPsec-sviten, stöder ESP både tunnelläge och transportläge. Beroende på läget behandlar den data på olika sätt. Innan vi beskriver datainkapslingen visar vi det ursprungliga IP-paketet, som skulle passera över nätverket i frånvaro av IPsec

IP-huvud TCP-huvud Data

Original IP-paket

IP-huvud ESP-huvud TCP-huvud Data ESP Trailer ESP auth
  Krypterad data  
  Autentiserade data  

ESP i transportläge

Ny IP Header ESP-huvud IP-huvud TCP-huvud Data ESP Trailer ESP auth
  Krypterad data  
  Autentiserade data  

ESP i tunnelläge

De gröna linjerna utgör den del av paketet som utsätts för kryptering, medan de blå linjerna utgör den del av paketet som utsätts för en äkthets- och integritetskontroll. I transportläge förblir den ursprungliga IP-headern fri (därför oskyddad) för routing av paketet till mottagarändpunkten som också kommer att ansvara för att bearbeta autentiseringen och dekrypteringen av ESP-nyttolasten. Annars, i tunnelläge är den ursprungliga IP-headern krypterad (därför skyddad) tillsammans med TCP-headern och data, och det är därför nödvändigt att införa en ny IP-header (i gult) med den information som behövs för routing till den delegerade enheten ( gateway / brandvägg ) vid stängning av IPsec-tunneln med dekryptering av ESP-nyttolasten, en enhet som i sin tur vidarebefordrar det autentiserade och dekrypterade paketet till den slutpunkt som deklareras i den ursprungliga IP-huvudet (i grått). När det gäller krypteringsalgoritmerna kan Data Encryption Standard (DES), 3DES , AES och Blowfish användas . Integritets- och autenticitetskontrollen utförs genom HMAC (hash-funktioner); hashen beräknas genom en hashfunktion ( MD5 eller SHA1 ), med hjälp av en delad nyckel; den erhållna hashen bifogas meddelandet och skickas. I receptionen kontrolleras meddelandets integritet. Som visas i diagrammen täcks inte den yttersta IP-adressen av integritetskontrollen. Detta alternativ gör ESP-protokollet lämpligt för användning i vissa typer av NAT , särskilt i statiska. Det finns dock ad-hoc- lösningar för gemensam drift av IPsec och NAT, såsom NAT-traversal.

NAT-traversal

Beskrivning

NAT-traversal (eller NAT-T för kort) är namnet på ett protokoll som är en del av IPsec-sviten och standardiserat i olika RFC :er , varav den officiella är RFC 3947 . Syftet med detta protokoll är att ge möjligheten att etablera en IPsec-tunnel även när en av de två inblandade peers genomgår en NAT-operation för att nå den andra enheten som är involverad i kommunikationen.

Scenario

NAT är en mycket använd teknik för återanvändning av IP- adresser . Däremot har värdar bakom en router (eller brandvägg ) som utför NAT-operationer inte ände-till-ände-anslutning . Även om det finns flera typer av NAT, är det övergripande målet att ändra pakethuvuden. Detta beteende står i skarp kontrast till IPsec som har paketintegritetskontroll bland sina mål . I synnerhet är NAT inkompatibel med AH både i tunnelläge och i transportläge, eftersom AH verifierar integriteten för hela IP-paketet. ESP, å andra sidan, täcker inte IP-huvudet med kontroller av något slag varken i tunnelläge eller i transportläge, så det är lämpligt om den utförda NAT är av SNAT -typ ; med andra ord, ändringen som görs av routern får bara involvera IP-huvudet och inte porten på den högre nivån.

NAT skapar även problem med IKE och speciellt med IKE i huvudläge . Huvudläget som används tillsammans med metoden med fördelade nycklar kräver autentisering av de värdar som är involverade i kommunikationen och denna autentisering tillhandahåller en kontroll av IP-adresserna; därför orsakar ändringen av adressen av en NAT-enhet autentiseringsfelet.

I allmänhet, i enheter som ansvarar för att hantera IPsec-tunnlar och i VPN-klienter, är NAT-T inte aktiverat som standard utan måste ställas in för hand; dess användning förblir dock valfri: i själva verket, under skapandet av säkerhetsföreningen , bestämmer kamraterna om en av de två genomgår NAT-operationer och endast i detta fall används NAT-T; detta görs under den första fasen av IKE- förhandlingen . Först verifierar kamraterna att båda har NAT-T-stöd; denna verifiering utförs i den allra första fasen av IKE-protokollet, med hjälp av ett paket med ett leverantör-ID- fält , som innehåller ett känt hashvärde.
När det väl har fastställts att båda stöder NAT-T, skickas "NAT-Discovery" (NAT-D) ramar, för att verifiera vilken av de två som genomgår NAT, eller åtminstone om båda genomgår det.
När väl fastställts vem som utsätts för NAT, flyttas kommunikationen till ett nytt par UDP-portar och " nat-tata "-entiteten börjar skicka keepalive -ramar ; dessa ramar används för att hålla kommunikationsportarna på routern fasta och för att förhindra att den omtilldelar dem till en ny kommunikation.

Vi beskriver hur det ursprungliga ESP-paketet är inkapslat.

IP-huvud ESP-huvud Intern IP-header TCP-huvud Data ESP Trailer ESP auth

ESP i tunnelläge

IP-huvud UDP-huvud NAT-T-huvud ESP-huvud Intern IP-header TCP-huvud Data ESP Trailer ESP auth

ESP i tunnelläge med UDP-inkapsling för NAT-T

Fälten markerade med mörkgrönt är de som hänför sig till NAT-T; dessa fält infogas omedelbart efter den externa IP-huvudet, som inte ändras, precis som följande fält inte ändras. Vid mottagning utförs den omvända operationen.

Lista över IPsec-relaterade RFC:er

  • RFC 4301 : Säkerhetsarkitektur för Internetprotokollet
  • RFC 2402 : Autentiseringshuvud
  • RFC 2406 : Encapsulating Security Payload
  • RFC 2407 : IPsec Tolkningsdomän för ISAKMP (IPsec DoI)
  • RFC 2408 : Internet Security Association and Key Management Protocol (ISAKMP)
  • RFC 2409 : Internet Key Exchange (IKE)
  • RFC 2410 : NULL-krypteringsalgoritmen och dess användning med IPsec
  • RFC 2411 : Färdkarta för IP-säkerhetsdokument
  • RFC 2412 : OAKLEY Key Deermination Protocol
  • RFC 3947 : Förhandling av NAT-traversal i IKE

Relaterade artiklar

Externa länkar

Hämtad från " https://it.wikipedia.org/w/index.php?title=IPsec&oldid=129215258 "