Internettsikkerhet (IPsec)

Dagens tekst er hentet fra kapittel 20 i Cryptography and Network Security, og handler om sikkerhet på IP-laget.

IPsec så dagens lys i 1994, da RFC 1636 “Security in the Internet Architecture” ble publisert. Her ble fundamentale sikkerhetsmekanismer for internett-protokollen skissert: Beskyttelse av nettverksinfrastrukturen fra uautorisert monitorering og kontroll av nettverkstrafikk, og beskyttelse sluttbruker-til-sluttbruker-trafikk vha. autentiserings- og krypteringsmekanismer. Internet Activities Board (IAB) sørget for at disse mekanismene ble inkludert som standard i neste generasjon av IP, IPv6. IPsec er nådefinert som en hel serie av internettstandarder.

IPsec  gjør det mulig å kommunisere sikkert over et lokalnett, private og offentlige WAN, og over det store, stygge Internettet. Eksempler kan omfatte sammenkobling av et distriktskontor med hovedkontoret over internett, sikker fjernaksess fra en bærbar datamaskin til hovedkontoret via internett, opprettelse av ekstranett- og intranett-forbindelse med samarbeidspartnere, og forbedring av sikkerheten til e-handel.

Hovedegenskapen til IPsec er at den kan kryptere og/eller autentisere all trafikk på IP-laget, dette innebærer at alle distribuerte applikasjoner (fjerninnlogging, klient/tjener, epost, filoverføring, vev-aksess) kan sikres. IPsec har flere fordeler. Når IPsec er implementert i en brannmur eller ruter, tilbyr den sterk sikkerhet som kan anvendes på all trafikk som krysser perimeteret. Trafikk innen en virksomhet vil følgelig ikke pådra seg ekstra belastning som følge av sikkerhetsrelatert prosessering. IPsec i en brannmur er resistent mot omgåelse hvis all trafikk fra utsiden må bruke IP og brannmuren er den eneste måte å komme seg fra internett og inn i virksomheten. IPsec ligger under transport-laget (TCP, UDP) og er følgelig transparent for applikasjoner – det er ikke nødvendig å endre programvare på et bruker- eller tjener-system når IPsec implementeres i brannmuren eller ruteren. IPsec kan også være transparent for sluttbrukere, og det er da ikke nødvendig å lære brukere opp i sikkerhetsmekanismer, utstede nøkler per bruker, eller trekke nøkkelmateriale tilbake når brukere skifter beite. IPsec kan også tilby sikkerhet for individuelle brukere ved behov, noe som er nyttig for utegående medarbeidere.

IPsec kan spille en avgjørende rolle i ruting-arkitekturen som kreves for kommuniklasjon på kryss av nettverk. IPsec kan verifisere at en ruter-annonsering kommer fra en autorisert ruter, at en ruter som prøver å opprette eller vedlikeholde et naboforhold men en ruter i et annet ruting-domene er en autorisert ruter, an en omdirigeringsmelding kommer fra ruteren som den opprinnelige IP-pakken var sendt, og at en ruting-oppdatering ikke er forfalsket.

IPsec dokumenter

Detaljene i IPsec er (som vanlig) definert i en rekke RFCer:

  • Arkitektur: RFC4301, Security Architecture for the Internet Protocol
    Dekker de generelle konseptene, sikkerhetskrav, definisjoner og mekanismer som definerer IPsec-teknologien.
  • Authentication Header (AH): RFC 4302, IP Authentication Header
    En utvidelse av IP-hodet for å tilby meldingsautentisering.
  • Encapsulating Security Payload (ESP): RFC 4303, IP Encapsulating Security Payload
    Består av en innkapslende header og trailer som brukes for å tilby kryptering eller kombinert kryptering/autentisering.
  • Internet Key Exchange (IKE): RFC 7296, Internet Key Exchange (IKEv2) Protocol
    En samling med dokumenter som beskriver nøkkelhåndteringsløsninger for bruk med Det finnes også flere andre relaterte RFCer.

Det finnes også en stor samling dokumenter som definerer og beskriver kryptografiske Talgoritmer for kryptering, meldingsautentisering, pseudorandom funksjoner (PRFs), og nøkkelutveksling. Dessuten finnes det flere andre RFCer som omhandler sikkerhetspolicy og Management Information Base (MIB).

IPsec tjenester

IPsec tilbyr sikkerhetstjenester på IP-laget ved gjøre et system i stand til å velge de nødvendige sikkerhetsprotokollene, å bestemme hvilke(n) algoritme som skal brukes for tjenesten(e), og å få på plass eventuelle kryptonøkler som trengs for å tilby den ønskede tjenesten. RFC 4301 lister opp følgende tjenester: Aksesskontroll, forbindelsesløs integritet, autentisering av opphav, forkasting av avspilte pakker (en form for delvis sekvens-integritet), konfidensialitet (kryptering) og en viss trafikkflyt-konfidensialitet.

Transport- og tunell-modi

IPsec kan operer i enten transportmodus eller tunellmodus.

Transportmodus

IPsec i transportmodus tilbyr beskyttelse primært for høyerelags protokoller, f.eks. et TCP- eller UDP-segment eller en ICMP pakke, og brukes typisk for ende-to-ende-kommunikasjon mellom to verter. ESP i transportmodus krypterer og eventuelt autentiserer IP nyttelasten, men ikke IP-hodet. AH i transportmodus autentiserer IP nyttelasten og utvalgte deler av IP-hodet.

Tunellmodus

IPsec i tunellmodus gir beskyttelse for hele IP-pakken, og brukes når en eller begge endene av en sikkerhetsassosiasjon (SA) er en sikkerhetsportner. Et antall verter på nettverk bak brannmurer kan delta i sikker kommunikasjon uten å i det hele tatt implementere IPsec. ESP i tunellmodus krypterer og eventuelt autentiserer hele den indre IP-pakken, inkludert det indre IP-hodet. AH i tunellmodus autentiserer hele den indre IP-pakken og utvalgte deler av det ytre IP-hodet.

Sikkerhetsassosiasjon (SA)

En SA er en enveis logisk forbindelse mellom en avsender og en mottaker so legger til rette for sikkerhetstjenester for trafikken som går over den. I enhver IP-pakke er SAen unikt identifisert av mottakeradressen i IPv4- eller IPv6-hodet, sikkerhetsparameterindeksen (SPI) (et 32-bit heltall med kun lokal signifikans), og sikkerhetsprotokollen i bruk (AH eller ESP).

Sikkerhetsassosiasjonsdatabase (SAD)

SAD definerer parameterne assosiert med hver SA:

  • Sikkerhetsparameterindeks (SPI)
  • Sekvensnummerteller
  • Sekvensnummer oversvømmelse
  • Anti-avspillingsvindu
  • AH informasjon
  • ESP informasjon
  • Levetiden til denne sikkerhetsassosiasjonen
  • IPsec protokollmodus
  • Kommunikasjonsveiens maksimale overføringsenhet (MTU)

Sikkerhetspolicydatabase (SPD)

SPD er måten man finner ut hvordan man kobler IP trafikk til spesifikke SAer. Innslagene definerer et subsett av mulig IP-trafikk, og peker på en SA for denne trafikken. I mer komplekse miljøer kan det være flere innslag som som potensielt forholder seg til en enkelt SA, eller flere SAer assosiert med et enkelt SPD-innslag. Hvert SPD-innslag er definert ved et sett av IP og høyerelags protokollverdier kalt velgere (selectors). Disse brukes til å filtrere utgående trafikk for å avbilde den på en spesifikk SA.

SPD-innslag

De følgende velgerne bestemmer et SPD innslag:

  • Destinasjon IP-adresse: Dette kan være en enkelt IP-adresse, en nummerert liste eller spenn av adresser, eller en “joker-adresse” (wildcard). De to siste er nødvendige for å gjøre det mulig for mer enn ett destinasjonssystem å dele samme SA.
  • Lokal IP-adresse: Dette kan være en enkelt IP-adresse, en nummerert liste eller spenn av adresser, eller en “joker-adresse” (wildcard). De to siste er nødvendige for å gjøre det mulig for mer enn ett avsendersystem å dele samme SA.
  • Neste lag protokoll: Hodet i IP-protokollen har et felt som indikerer hvilken protokoll som opererer på laget over IP (f.eks. UDP eller TCP).
  • Navn: En brukeridentifikator fra operativsystemet. Dette er ikke et felt i IP-hodet eller i de høyere lagene, men kan være tilgjengelig dersom IPsec kjører på samme operativsystem som brukeren.
  • Lokale og fjerne porter: Dette kan være individuelle TCP- eller UDP-porter, en nummerert liste av porter, eller en joker-port (wildcard).

Encapsulating Security Payload (ESP)

ESP brukes til å kryptere nyttelasten, polstringen (padding), polstringslengden og “neste hode” (Next Header) feltene. Hvis algoritmen krever kryptografisk synkronisering, så kan disse dataene transporteres eksplisitt på begynnelsen av nyttelastfeltet. Et valgfritt integritetssjekkfelt (ICV) er til stede kun hvis integritetstjenesten er valgt, og tilbys av enten en separat integritetsalgoritme eller en kombinert-modus-algoritme som bruker en ICV. ICV beregnes etter at krypteringen er utført; denne rekkefølgen av prosessering kan bidra til å redusere konsekvensene av et tjenestenektangrep (DoS). Ettersom ICV ikke er beskyttet med kryptering, må man bruke en integritetsalgoritme med nøkkel (dvs. en MAC) for å beregne den.

Polstringsfeltet tjener flere formål: Hvis den valgte krypteringalgoritmen krever at klarteksten må være et multiplum av et bestemt antall byte, så brukes polstringsfeltet til å utvide klartekst tilsvarende, samtidig som man sørger for at feltene “polstringslengde” og “neste hode” plasseres der de skal. Ytterliger polstring kan legges til for å tilby delvis trafikkflyt-konfidensialitet ved å skjule den faktiske lengden på nyttelasten; dette er altså et motmiddel mot trafikkanalyse.

Kombinasjon av sikkerhetsassosiasjoner

En individuell SA kan enten implementere AH- eller ESP-protokollen, men ikke begge. Det går an å lage en sikkerhetsassosiasjonsbunt (SA bundle) som angir en sekvens av SAer som trafikk må prosesseres gjennom for å tilby et ønsket sett av IPsec-tjenester. SAene i en bunt kan enten terminere i samme endepunkt eller i forskjellige endepunkter.

SAer kan kombineres i bunter på to måter; enten ved nærliggende transport (transport adjacency), som består i å anvende mer enn en sikkerhetsprotokoll til samme IP-pakke uten å bruke tunellering (dette tillater bare ett nivå av kombinasjon); eller ved iterert tunellering, dvs. flere lag av tuneller utenpå hverandre – dette tillater flere lag av nøsting.

ESP med autentiseringsopsjon

I denne tilnærmingen vil brukeren først anvende ESP på dataene som skal beskyttes, og deretter hekte på autentiseringsdatafeltet. I transportmodus vil autentisering og kryptering gjelde IP nyttelasten som leveres til verten, men hodet er ikke beskyttet. I tunellmodus ESP vil autentisering gjelde hele IP-pakken som leveres til den ytre IP destinasjonsadressen, og autentisering foretas på den destinasjonen. Hele den indre IP-pakken beskyttes av konfidensialitetsmekanismen for leveranse til den indre IP-destinasjonen. I begge tilfeller er autentiseringen anvendt på chifferteksten snarere enn klarteksten.

Nærliggende transport (Transport Adjacency)

En annen måte å anvende autentisering etter kryptering er å bruke to buntede transport SAer, hvor den indre er en ESP SA, og den ytre er en AH SA. I dette tilfellet er ESP brukt uten sin autentiseringsopsjon; kryptering anvendes på IP nyttelasten, og AH anvendes så i transportmodus. Fordelen med denne tilnærmingen er at autentiseringen dekker flere felter. En ulempe er overheaden av to SAer kontra en enkelt SA.

Transport-tunnel-bunt

Bruk av autentisering før kryptering kan være å foretrekke av flere grunner; det vil ikke være mulig for noen å snappe opp meldingen og endre autentiseringsdataene uten deteksjon, og det kan være ønskelig å lagre autentiseringsinformasjonen sammen med meldingen for senere referanse. En tilnærming vil være å bruke en bunt som består av en indre AH transport-SA og en ytre ESP tunell-SA. Autentisering vil anvendes på IP nyttelasten pluss IP-hodet, og den resulterende IP-pakken prosesseres så i tunellmodus ESP. Ergo vil hele den indre autentiserte IP-pakken krypteres, og et nytt ytre IP-hode legges til.

Kombinasjon av sikkerhetsassosiasjoner

Når vi kombinerer sikkerhetsassosiasjoner har vi flere valgmuligheter når det gjelder rekkefølgen vi anvender autentisering og kryptering hvis vi ønsker begge deler. Vi kan bruke ESP med autentiseringsopsjonen, vi kan bruke nærliggende transport (transport adjacency):  AHtransport(ESPtransport), og vi kan bruke transport-tunell-bunt:   ESPtunnel(AHtransport).

Boken beskriver 4 eksempler på slike kombinasjoner.

Internet Key Exchange (IKE)

For en gitt kommunikasjonsløsning mellom to parter trenger vi typisk fire symmetriske krypteringsnøkler, 1 nøkkel for sending og en for å motta, både integritet og konfidensialitet. Disse nøklene oppstår ikke av intet, så IPsec har mekanismer for nøkkeletablering og distribusjon.

IPsec-spesifikasjonen angir at man kan enten ha manuell eller automatisert nøkkelhåndtering. Førstnevnte medfører at en systemadministrator manuelt konfigurerer hvert system med sine nøkler og nøklene til systemene man skal kommunisere med; dette er kun praktisk for små, relativt statiske miljøer. Automatisert nøkkeladministrasjon gjør det mulig å opprette nøkler for SAer ved behov, og legger til rette for bruk av nøkler i et stort distribuert system med stadige endringer i konfigurasjonen.

ISAKMP/Oakley

ISAKMP/Oakley er standard automatisert nøkkeladministrasjonsprotokoll i IPsec. Den består av Oakley nøkkeletableringsprotokollen som er basert på Diffie-Hellman algoritmen, men med forbedret sikkerhet.  Den er generisk på den måten at den ikke dikterer spesifikke formater. Videre har vi Internet Security Association and Key Management Protocol (ISAKMP), som tilbyr et rammeverk for internett nøkkeladministrasjon, med spesifikk protokollstøtte og formater for fremforhandling av sikkerhetattributter. ISAKMP består av et sett av meldingstyper som muliggjør bruk av et utvalg nøkkelutvekslingsalgoritmer.

Egenskaper ved IKE nøkkeletablering

IKE karakteriseres ved fem viktige egenskaper:

  1. Den bruker en mekanisme kjent som småkaker (cookies) for å forhindre forstoppelse-angrep (clogging attacks).
  2. Den gjør de to partene i stand til å forhandle fram en gruppe, dvs. de globale parameterne i Diffie-Hellman nøkkeletableringsprotokollen.
  3. Den bruker noncer til å beskytte mot avspillingsangrep
  4. Den legger til rette for utveksling av de offentlige Diffie-Hellman nøkkelverdiene.
  5. Den autentiserer Diffie-Hellman-utvekslingen for å forhindre menneske-i-midten-angrep.