Back to Main Page This information is provided by Johnson Consulting

IPSec ger säkra VPN-förbindelser
Det behövs kanaler för säker trafik över Internet. Den vanligaste varianten av dessa är VPN, som står för (Virtual Private Network). VPN-kanalen fungerar alltså som en förlängning av det lokala nätverket, till en annan geografisk ort. Eller, som i figuren till höger, att man kopplar ihop två (eller fler) lokala nätverk, och behandlar dem som om de vore ett enda.

För att denna kanal ska bli "säker", i betydelsen att informationen på kanalen:

  1. Kommer fram, och i oförvanskat skick
  2. Är oläslig för utomstående
så krävs speciella åtgärder. Att den kommer fram oförvanskad borgar TCP/IP-protokollet för. Men för att göra informationen otillgänglig för utomstående krävs det att den krypteras.		 En VPN-kanal genom Internet som knyter ihop två LANs.

Den standard som blivit dominerande för detta ändamål heter "IPSec" - för "IP Security". IP är som bekant (?) det nätverksprotokoll som används på Internet.

Som framgår nedan finns det olika IPSec-protokoll. De kan alla användas i 2 lägen:

  1. Tunnel-läget (A i illustrationen till höger) är avsett för att koppla ihop lokala nät över Internet. Det används därför mest av routrar.

  2. Transport-läget (B i illustrationen till höger) används för direkt kommunikation mellan två IP-adresserbara enheter, t.ex. mellan client och server-datorer.
Skillnaden mellan dessa lägen är att transport-paket bara innehåller sin egen IP-adress och, förstås, datapaketet. Då ESP användes skyddas bara datapaketet med kryptering. Tunnelläget tar hela original-paketet, inkl. avsändar- och mottagaradress, och kapslar in i ett nytt IP-paket som har en egen adressering. Om ESP används i tunnel-läge så skyddas alltså även adresserna.		 Skillnad på krypteringens omfattning i Tunnel-läget resp. Transport-läget.

Internets decentraliserade öppenhet är både nyckeln till dess framgång och dess Akilles-häl. Användarna vill utnyttja nättjänster som kräver garanterade tjänster och förbindelser som ingen kan avlyssna. För detta finns alltså IPSec, en standard som föregriper säkerhetsfunktionen i den nya IP version 6. IPSec förknippas främst med så kallade virtuella privata nät (VPN), det vill säga med logiska utökningar av företagets nät på Internet som skapar en skyddad kanal, eller tunnel, genom det öppna Internet. Genom den kanalen kan en användare med full säkerhet kommunicera mellan lokala LAN-nät som kanske finns på olika geografiska platser, med samma säkerhet som om dessa vore ett enda fysiskt LAN, så när som på eventuellt försämrad prestanda. Eftersom IPSec krypterar och autenticerar trafiken kommer protokollet till användning även för intranät/extranät-tillämpningar. Med IPSec är det lätt att bestämma vem som ska kunna läsa vad. Ett tredje tillämpningsområde är att också kunna använda IPSec-protokollet för elektronisk handel, vilket ställer höga krav på säkerhet.

Protokollet IPSec täcker följande huvudområden:

  • autenticering av avsändaren så att varje paket kan garanteras komma från den avsändare som uppges
  • autenticering av data (data integrity) så att varje paket kan garanteras vara i oförändrat skick när det kommer fram; detta skyddar både mot tekniska fel och uppsåtligt sabotage
  • kryptering som döljer innehållet i paketen
  • skydd mot "återuppspelning" av data, så att det inte går att lagra en avlyssnad sekvens för senare undersökning
  • automatiserad hantering av kryptonycklar och säkerhetsassociationer för att möjliggöra en flexibel implementering av VPN.

Detta har resulterat i en mängd del-protokoll. De viktigaste protokollen är:

  1. Authentication Header (AH), som autenticerar pakethuvudet, avsändaren och innehållet samt ger skydd för återuppspelning,
  2. Encapsulating Security Payload (ESP), som skyddar från insyn, autenticerar avsändaren och innehållet, samt skyddar mot återuppspelning, samt
  3. Internet Key Exchange (IKE), eller ISAKMP/Oakley (Internet Security Association and Key Management Protocol, som sköter automatiserad associering av säkerhetsparametrar samt hanterar kryptonycklar.

Ett viktigt begrepp i detta sammanhang är "Security Association" (SA). En SA är en riktad, logisk förbindelse mellan två IPSec-noder, som unikt identifieras av:

  1. Värdet SPI (security parameter index), ett 32-bitars värde som används för att identifera SA-er med samma destination och protokoll, värdet 0 får bara användas lokalt och värdena mellan 1 och 255 är reserverade av IANA
  2. Destinationsadressen (IP)
  3. Vilket säkerhetsprotokoll som används, alltså AH eller ESP.
SA är alltså enkelriktat, och det krävs då två stycken SA för att kommunicera åt båda hållen mellan två IPSec-noder. Likaså hanterar varje SA bara ett protokoll, så för att använda både AH och ESP samtidigt (se längre fram) måste två SA användas. 		Varje IPSec-implementering använder två databaser för att sköta SA-hanteringen:
  1. Security Policy Database (SPD), specificerar vilka säkerhetstjänster som finns tillgängliga för olika typer av IP-trafik, beroende på avsändare, destination, om det är inkommande, utgående, och så vidare. Dessutom ger SPD en lista över policyregler, uppdelade efter inkommande och utgående trafik. Reglerna säger exempelvis att viss trafik inte ska hanteras med IPSec, att viss ska slängas bort och att resten ska passera genom IPSec-modulen.
  2. Security Association Database (SAD), innehåller information om varje SA, exempelvis om de använder AH eller ESP, samt om nycklar, sekvensnummer eller protokolllägen.
För utgående trafik pekar en SPD-post på en SAD-post, det vill säga SPD-databasen bestämmer vilken SA som ska användas för ett visst paket. För inkommande trafik tillfrågas SAD-databasen om hur paketet ska hanteras.

Låt oss så titta på protokollen. Authentication Header (AH) autenticerar hela IP-paketet förutom vissa fält i huvudet som ändras under transporten. Sådana fält kallas i IPSec-sammanhang för "mutable" (föränderliga) och kan inte skyddas av AH. Fälten är type of service (TOS), flags, fragment offset, time to live (TTL) och header checksum. AH, som av IANA identifieras som protokoll 51, lägger sina fält mellan det vanliga IP-huvudet (vars Protocol- eller Next Header-fält således har värdet 51) och IP-paketets innehåll.

Värt att notera är att AH inte hanterar fragmenterade IP-paket. Däremot kan ett AH-utökat IP-paket fragmenteras av någon router under transporten. I det fallet sätts paketen ihop innan de undersöks på AH-nivå. Om AH-hanteringen får vad som verkar vara ett fragment i sina händer (det vill säga om offset field är något annat än noll eller om biten More Fragment är ett) så slängs det helt sonika bort.

Detta undanröjer risken för så kallad "overlapping fragment attack", som försöker utnyttja ihopsättningsmekanismerna för att tillverka falska IP-paket som ska ta sig igenom brandväggen, alltså i syfte att sabotera åtkomligheten hos en viss tjänst eller server – så kallad "denial of service".

Med AH autenticeras innehållet via en checksumma, som i sin tur beräknas med hjälp av en så kallad message authentication code – eller hashfunktion. Md5 och sha1 är exempel på standardiserade hashing-funktioner. Vanligen klarar en IPSec-implementation flera hashfunktioner. Avsändaren autenticeras genom att de data som ska skyddas kompletteras med en hemlig och delad nyckel. Skydd mot uppspelning av trafik fås via en enkel räknare i AH-huvudet. Genom att räknaren ökas för varje sändning och paketet är autenticerat kan inte någon illasinnad avlyssnare spela upp gamla paket, eftersom de skulle upptäckas direkt. Det går heller inte att ändra sekvensnumret eftersom paketet också är autenticerat. Räknaren är 32 bitar lång och klarar således över fyra miljarder sändningar innan den måste nollställas. Normalt kallas innehålls- och avsändarautenticering, samt skydd mot uppspelning, tillsammans för "autenticering", rätt och slätt.

Det andra viktiga protokollet kallas som nämnts ovan är Encapsulating Security Payload (ESP). Det skiljer sig från AH i två huvudsakliga funktioner:

  1. ESP krypterar, det gör inte AH.
  2. AH autenticerar även IP-huvudet, det gör inte ESP.
I utförandet skiljer de sig framför allt i så motto att ESP omgärdar eller inkapslar ("encapsulating") IP-paketet helt och hållet, med ett huvud och en svansdel. Se figur här intill.

Behövs kryptering?

Krypteringen är valbar oberoende av övriga tjänster i ESP. Det är dock högeligen rekommenderbart att även autenticera innehåll och avsändare. Annars öppnas ett onödigt hål för eventuella inkräktare att låta skumma paket få känna på dekrypteringsmekanismerna. ESP identifieras med protokollnummer 50 av IANA. Liksom AH arbetar det på IP-paketnivå och det är således inte förbindelseorienterat. Liksom AH slänger också ESP bort fragmenterade paket. För att ytterligare spara resurser – och skydda sig från "denial of service"-attacker – sker först autenticering och först därefter, och om datapaketet var intakt, den mer resurskrävande dekrypteringen.

AH och ESP gör alltså samma sak, så när som på krypteringen och autenticeringen av pakethuvudet. Till varför det behövs två protokoll finns det ingen officiell förklaring, men däremot vissa inofficiella. Exempelvis kräver ESP stark kryptering implementerad – även om inte kryptering används – då det i vissa fall är känsligt, inte minst ur exportsynpunkt. Vidare räcker det ofta med autenticering och där är AH ett betydligt mer effektivt alternativ. Och de två protokollen gör faktiskt IPSec-miljön mer flexibel. Såväl ESP som AH kan användas var för sig, eller i kombination med varandra. Exempelvis skulle ESP kunna skydda och kryptera trafiken mellan två brandväggar över ett publikt nät, medan en inre AH-applicering skyddar och autenticerar paketet när det färdas över det inre nätet. Eller omvänt.

Att hantera nyckelknippan

Utöver skillnaderna mellan AH och ESP kan IPSec fungera på två olika vis, i två olika lägen kallade "transport" och "tunnling". Transport är det enklare och det skyddar i princip bara paketens innehåll. Tunnling skyddar hela paketet, såväl huvud som data. Både AH och ESP kan användas i båda lägena. Vi har gått igenom SA och ESP. Återstår IKE (Internet Key Exchange), även kallat ISAKMP/Oakley. IKE sköter hela hanteringen kring krypteringen – det vill säga generering, distribution och uppdatering av nycklar. IKE kräver också att all trafik både krypteras och autenticeras. Eftersom IKE används för att sätta igång krypteringsmekanismerna måste tekniken fungera säkert även över mycket osäkra förbindelser.

Hur bra ett visst krypteringssystem är beror ofta mer på hur bra nycklarna döljs än på hur stark krypteringen är. Med IKE (ISAKMP) sker därför utbytet av nycklar enligt en mycket robust, tudelad metod. Den första fasen etablerar en gemensam "grundhemlighet" som i sin tur används för att framställa alla nycklar. I allmänhet används publik nyckel-kryptering för att etablera IKE-relationer mellan olika system och för att etablera de nycklar som ska skydda trafiken under den andra fasen. Fas ett ägnas alltså uteslutande åt att skapa en säker förbindelse för fas två. Under fas ett är den kryptografiska bearbetningen förhållandevis beräkningstung. Den behöver dock inte utföras så ofta. En enda första fas kan användas för ett flertal andra faser. I regel utförs fas ett en gång om dagen eller till och med en gång i veckan, medan fas två sker med några minuters mellanrum. Fas två är enklare än fas ett och syftar huvudsakligen till att uppdatera krypteringsnycklarna.

IPSec specificerar inte vilken algoritm som ska användas, men i praktiken är det DES (data encryption standard) som används. DES använder 56 bitars nyckel, vilket inte kan anses vara toppsäkert då 56 bitars-krypton av idag kan lösas på några timmar. För den som vill vara bättre skyddad finns därför 3DES eller triple-DES, som kombinerar tre 56-bitars nycklar så att det resulterar i motsvarande 112 bitar.

Last Updated: 2007-01-02
Författare: Ove Johnsson