IKE

IKE (Internet Key Exchange) er en standardprotokol i IPsec -protokolpakken , der bruges til at levere sikker kommunikation i virtuelle private netværk . Formålet med IKE er sikker forhandling og levering af identitetsoplysninger for en "sikkerhedsforening" (SA). Baseret på Oakley -protokollen .

Historie

IKE blev oprindeligt defineret i november 1998 i en række anbefalinger RFC 2407 , RFC 2408 , RFC 2409 .

I december 2005 blev den anden version af IKEv2 udgivet, som blev beskrevet i RFC 4306 .

I oktober 2014 blev en ændret version af standarden, der beskriver IKEv2, frigivet i revisionen af ​​RFC 7296 .

Arkitektur

Protokollen transmitterer meddelelser på UDP - porte 500 og/eller 4500. Den etablerede SA inkluderer en delt hemmelig nøgle og et sæt kryptografiske algoritmer. IKE kan også bruge IP-komprimering.

Udvekslingen af ​​information udføres af parrede beskeder "anmodning-svar". Sådanne par kaldes "udveksling".

Dataudveksling i IKE foregår i 2 faser. I første fase etableres SA IKE. I den anden bruges SA IKE til protokolforhandling (normalt IPSec).

Definitioner

SKEYID - en streng hentet fra en hemmelig nøgle kun kendt af deltagerne i udvekslingen.

SKEYID_e er nøglematerialet, som SA ISAKMP bruger til at beskytte fortroligheden af ​​sine meddelelser.

SKEYID_a er nøglematerialet, som SA ISAKMP bruger til at identificere dets meddelelser.

SKEYID_d - Nøglemateriale brugt ved udledning af nøgler til ikke-ISAKMP SA'er

Nx - aktuelle tidsdata (x kan være i eller r i tilfælde af henholdsvis initiativtageren eller modtageren)

prf(key, msg) er en pseudo-tilfældig funktion med en tast (pseudo-tilfældig funktion). En hash-funktion bruges ofte .

g^xy er en delt hemmelig Diffie-Hellman- kode .

CKY_x - initiator (hvis x == I) eller modtager (hvis x == R) cookies fra ISAKMP header

HDR - ISAKMP header. Dens udvekslingstypefelt angiver tilstanden. Hvis HDR* er skrevet, er dataene krypteret.

SA - Forhandlingsdata indeholdende en eller flere sætninger. Initiativtageren kan indsende flere forslag, men respondenten skal kun svare med ét forslag.

IDx - identifikationsdata for x. Hvis x == ii, så er dette initiatorens data i den første fase, hvis x == ir, så er dette responderens data i første fase, hvis x == ui, så er dette dataene for initiativtageren i anden fase, hvis x == ur , så er dette data fra responderen i anden fase.

CERT - certificeringsdata.

SIG_X er signaturdata for initiatoren eller responderen i tilfælde af henholdsvis X == I eller X == R.

KE er nøgleudvekslingsdataene, der indeholder de offentlige oplysninger, der overføres under Diffie-Hellman-udvekslingen.

HASH(X) - hashkodedata.

<X>_b er datalegemet for X.

<x>y - x er krypteret med nøglen y.

x | Y er sammenkædningen af ​​X og Y.

Fase 1

For den første fase er 2 tilstande mulige: grundlæggende og aggressiv.

I hovedtilstanden finder 3 udvekslinger sted: i den første er noderne enige om reglerne, i den anden udveksler de åbne Diffie-Hellman-værdier og hjælpedata, i den tredje anerkendes Diffie-Hellman-udvekslingen.

I aggressiv tilstand etableres reglerne i den første udveksling, de offentlige Diffie-Hellman-værdier og tilhørende information transmitteres. Ydermere, i den anden besked i den første udveksling, identificeres responderen. Den tredje besked identificerer initiativtageren og bekræfter deltagelse i udvekslingen. Den sidste (fjerde) besked sendes muligvis ikke.

For begge disse metoder er fire typer af forskellige identifikationsmetoder mulige: digital signatur , to typer offentlig nøglekryptering og en delt nøgle (foruddelt nøgle).

Afhængigt af typen af ​​identifikation genereres et SKEYID i begyndelsen.

SKEYID = prf(Ni_b | Nr_b, g^xy) i tilfælde af identifikation med en digital signatur.

SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | CKY-R) i tilfælde af offentlig nøglekryptering.

SKEYID = prf(pre-shared-key, Ni_b | Nr_b) i tilfælde af en delt nøgle.

Derefter beregner parterne materialerne for nøglerne SKEYID_d, SKEYID_a, SKEYID_e.

SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)

SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)

SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

Identifikation med en digital signatur

I hovedtilstanden, i trin 1 og 2, er parterne enige om SA IKE og enige om udvekslingsindstillinger. Begge parter skal dele deres cookies. På trin 3 og 4 udveksler parterne Diffie-Hellman-nøgler og pseudo-tilfældige værdier. Parterne kan så beskytte beskederne. I trin 5 og 6 udveksles krypteret identifikationsinformation.

I aggressiv tilstand er forhandling begrænset, fordi initiativtageren skal sende Diffie-Hellman-værdier og aktuelle tidsdata i samme besked. Det betyder, at initiativtageren ikke kan foreslå forskellige Diffie-Hellman-grupper. Men nogle gange kan aggressiv tilstand være den eneste måde at etablere en IKE SA på, for eksempel hvis modtageren ikke kender adressen på initiativtageren. Hvis initiativtageren allerede har oplysninger om modtageren, vil aggressiv tilstand være mere effektiv.

I både grundlæggende og aggressive tilstande er resultatet signerede data (SIG_I og SIG_R).

Identifikation med offentlig nøglekryptering

Hvis svaret har flere offentlige nøgler i indbygget tilstand, sender den 3. besked hashen af ​​certifikatet (HASH(1)), der bruges af initiatoren til kryptering. På denne måde vil modtageren være i stand til at bestemme, hvilken nøgle beskederne er krypteret med ved blot at kompilere hashes af deres certifikater og sammenligne dem med det modtagne. Det er værd at bemærke, at identifikationsdata og det aktuelle tidspunkt er krypteret ved hjælp af den anden parts nøgle.

Godkendelse med den ændrede offentlige nøglekrypteringstilstand

Autentificering med offentlig nøglekryptering kræver en omkostning ved nøgleoperationer: 2 operationer til kryptering med den offentlige nøgle og 2 operationer til dekryptering med den private nøgle. Den korrigerede tilstand giver dig mulighed for at halvere antallet af operationer. I denne tilstand krypteres de aktuelle tidsdata også ved hjælp af den anden parts offentlige nøgle, og identifikatorerne (og, hvis de sendes, certifikater) krypteres ved hjælp af en forhandlet symmetrisk krypteringsalgoritme (baseret på SA-dataene). Nøglen til denne kryptering er afledt af de aktuelle tidsdata.

Årsagen til eventuelt at sende HASH(1) er den samme som for simpel autentificering med offentlig nøglekryptering. Nøglerne Ke_i og Ke_r forhandles under SA-dataudveksling. Dataene er krypteret, og dataheaderne sendes i klartekst.

Delt nøgleidentifikation

Hovedtilstandsnøglen kan bestemmes ud fra parternes IP-adresse, da initiatorens HASH_I-hash skal beregnes, før initiatoren kan behandle IDir. Aggressiv tilstand giver parterne mulighed for at have flere delte nøgler og kommunikere, hvilken der bruges, når de forhandler en udveksling.

Fase 2

Hurtig tilstand

Fast mode er ikke en komplet udveksling (fordi den er uløseligt forbundet med fase 1-udvekslinger), selvom den bruges som en del af SA-forhandlingsprocessen, der leverer nøglematerialer og forhandlingsregler for ikke-ISAKMP-SA'er. Alle meddelelser skal beskyttes af ISAKMP SA. Det betyder, at alle dele af meddelelserne undtagen ISAKMP-headeren er krypteret.

HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr)

HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr)

HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

Det nye nøglemateriale er defineret som:

KEYMAT = prf(SKEYID_d, protokol | SPI | Ni_b | Nr_b) - perfekt fremadrettet hemmeligholdelse er ikke påkrævet

KEYMAT = prf(SKEYID_d, g(qm)^xy | protokol | SPI | Ni_b | Nr_b) - perfekt fremadrettet hemmeligholdelse er påkrævet. Her er g(qm)^xy den delte nøgle, der blev opnået under Diffie-Hellman-udvekslingen.

Ny gruppetilstand

Den nye gruppetilstand må ikke bruges, før ISAKMP SA er etableret. Beskrivelsen af ​​den nye gruppe bør først følge efter fase 1-forhandlingen (selvom selve den nye gruppetilstand ikke gælder for fase 2).

HASH(1) = prf(SKEYID_a, M-ID | SA)

HASH(2) = prf(SKEYID_a, M-ID | SA)

OAKLEY bands

I OAKLEY-grupper forekommer Diffie-Hellman-matching. RFC 2409 definerer 4 grupper. For første gang blev disse grupper beskrevet i OAKLEY-protokollen, hvorfor de fik dette navn.

Kilder