IKEv1 mot IKEv2 med fördelad nyckel: vad som skiljer autentiseringen

Två gateways med samma fördelade nyckel genomför en handskakning, och en paketinsamling visar ingen hemlighet som passerar tråden. Det är den del folk minns. Den intressanta delen är vad varje version faktiskt räknar fram för att bevisa att hemligheten är känd, eftersom IKEv1 och IKEv2 bygger beviset på olika indata och avslöjar olika information medan de gör det. Läs de två spåren sida vid sida och skillnaden slutar vara kosmetisk.

Vad beviset måste åstadkomma

Diffie-Hellman ger båda parterna ett gemensamt värde vars publika halvor vem som helst som tittar på också kan räkna ut. I sig bevisar det ingenting om identitet: en angripare som slutför ett nyckelutbyte har samma gemensamma värde som din gateway. Autentiseringssteget finns för att binda utbytet till en hemlighet som bara de avsedda parterna har, och till de identiteter och parametrar de enades om.

Den bindningen är skälet till att hashen täcker mer än nyckeln. Om den bara täckte hemligheten kunde en angripare spela upp den i ett annat utbyte med andra identiteter eller förslag.

IKEv1 Main Mode: härled SKEYID och bevisa den sedan

Main Mode kör sex meddelanden. Det första paret förhandlar säkerhetsassociationen, det andra utbyter publika Diffie-Hellman-värden och nonce-värden, och det tredje bär identiteter plus autentiseringshashar under den kryptering som just upprättats. RFC 2409 definierar konstruktionen: med fördelad nyckel härleds SKEYID ur hemligheten och båda nonce-värdena, och det senare nyckelmaterialet ur SKEYID, Diffie-Hellman-värdet, cookies och konstanter.

Hashen i meddelande fem och sex beräknas över Diffie-Hellman-värdet, de två cookies, förslaget och avsändarens identitet, med SKEYID som nyckel. Mottagaren räknar om den med sin egen konfigurerade hemlighet. En avvikelse avslutar utbytet, och hemligheten är aldrig en nyttolast.

Aggressive Mode pressar samma arbete till tre meddelanden, vilket betyder att identiteter och autentiseringshash färdas innan det finns en krypterad kanal. Det är en verklig exponering för en gissbar hemlighet, och det är skilt från frågan om hemligheten skickades. IKEv1 är utfasad av RFC 9395, så ett äldre spår är en diagnostisk övning och inte ett driftsättningsmål.

IKEv2: en annan härledning och en annan AUTH-nyttolast

IKEv2 återanvänder inte IKEv1:s nyckelschema. De första IKE-nycklarna kommer från ett seed byggt av nonce-värdena och Diffie-Hellman-värdet, och barnsäkerhetsassociationerna härleds därifrån. Den fördelade nyckeln matar inte seedet alls.

Autentiseringen dyker då upp som en AUTH-nyttolast. För nyckelautentisering anger RFC 7296 en paddad form av hemligheten, framtagen genom att hasha hemligheten med den fasta strängen Key Pad for IKEv2, och sedan hasha de signerade utbytesdata och identiteten med den paddade nyckeln. Verifieraren kan bygga samma värde igen; en observatör kan inte, utan hemligheten.

Lägg märke till vad som ändrats. I IKEv1 bakas hemligheten in i nyckelschemat innan autentiseringshashen finns; i IKEv2 är nyckelschemat oberoende av hemligheten och beviset en separat nyttolast knuten till de signerade oktettena. Samma begreppsliga garanti, annan maskin, och därför mappar parameternamn och insamlingar inte ett till ett.

Vad en observatör faktiskt får veta

Publika Diffie-Hellman-värden, förslag, nonce-värden och cookies syns i båda versionerna. Identiteter syns i IKEv1 Aggressive Mode och skyddas i de andra fallen. Hemligheten syns aldrig.

Den sista meningen har en gräns värd att nämna. En svag, mänskligt vald hemlighet kan angripas genom gissning: angriparen räknar ut vad autentiseringsvärdet skulle bli för en kandidathemlighet och jämför. IKEv1 Aggressive Mode gör det billigast eftersom beviset ligger i klartext, och standarderna varnar allmänt för hemligheter med låg entropi. Att aldrig skicka hemligheten är inte samma sak som att göra en dålig hemlighet säker.

Vad du gör med jämförelsen

Använd en unik hemlighet per partspar, generera den från en slumpkälla och rotera den genom samma provisioneringsväg som distribuerade den. Om hemligheten ligger i en konfigurationsmall som skickas till varje filial är en kompromiss på en plats en kompromiss överallt.

Föredra certifikatbaserad autentisering där driftkostnaden är acceptabel, eftersom den tar bort gissningsproblemet med den delade hemligheten och ger varje part en egen identitet. Där en fördelad nyckel blir kvar: håll den lång, begränsa dess räckvidd och se IKE-versionen som ett säkerhetsbeslut, inte som en interoperabilitetsdetalj.