IKEv2 En halvformell analys

IKEv2En halvformell analys

Agenda

• IKEv2 – protokollet i huvuddrag

• Proverif – bakgrund, funktion

• Analys – fokus

• Modell – abstraktioner, förenklingar

• Resultat

IKEv2

• Protokoll att använda i anslutning till IPsec för etablering av ”security association” (SA) mellan två deltagare, Alice och Bob, när dessa vill konversera.

• Förenkling och förtydligande av IKEv1• Ramverksprotokoll – kryptografiska

algoritmer är utbytbara och vilka som används diskuteras under session

IKEv2 - faser

I. Etablering av en SA för IKE konversationen.

II. Ömsesidig autenticering och etablering av första SA för användande i exempelvis IPsec.

III. Etablering av ytterligare SAs, utbyte av kontrollinformation…

IKEv2 – fas I

I. Etablering av en SA för IKE konversationen.

II. Ömsesidig autenticering och etablering av första SA för användande i exempelvis IPsec.

III. Etablering av ytterligare SAs, utbyte av kontrollinformation…

IKEv2 – fas I

Alice sänder:

• Fix IKEv2 header

• KEa = publikt Diffie-Hellman värde

• SAa = erbjudna kryptografiska algoritmer

• Ni = nonsens (nonce)

Alice BobHeader, SAa, KEa, Ni

IKEv2 – fas I

Bob tar emot Alices meddelande, utvärderar erbjudanden vad gäller kryptografiska algoritmer, kontrollerar att KEa är av rätt typ för sitt tänka val samt skapar ett svarsmeddelande.

Alice BobHeader, SAa, KEa, Ni

IKEv2 – fas I

Bob sänder:

• Fix IKEv2 header

• KEb = publikt Diffie-Hellman värde

• SAb = valt erbjudande gällande kryptografiska algoritmer

• Nb = nonsens (nonce)

Alice BobHeader, SAb, KEb, Nb

IKEv2 – slut på fas I

Efter fas I kan Alice och Bob (som ännu inte är säkra på varandras identiteter) kryptera och integritetsskydda efterföljande faser med hjälp av förhandlade algoritmer och delade nycklar härledda ur Diffie-Hellman hemligheten och utbytt nonsens.

IKEv2 – fas II

I. Etablering av en SA för IKE konversationen.

II. Ömsesidig autenticering och etablering av första SA för användande i exempelvis IPsec.

III. Etablering av ytterligare SAs, utbyte av kontrollinformation…

I beskrivningen betyder SK {abc} att abc är krypterat och integritetsskyddat med förhandlade algoritmer och gemensamma nycklar. Dessutom är resten av meddelandet integritetsskyddat.

IKEv2 – fas II

Alice sänder:

• IDa = sin identitet i lämpligt format

• AUTHa = ett värde som styrker identiteten och bevisar att Alice var avsändaren i fas I.

• SAa = som förut, men för ny SA

• TSIa = trafikspecifikation

Alice BobHeader, SK{IDa, AUTHa, SAa, TSIa}

IKEv2 – fas II

IKEv2 – fas II

Bob tar emot Alices meddelande, utvärderar erbjudanden vad gäller kryptografiska algoritmer, verifierar identiteten, samt skapar ett svarsmeddelande.

Alice BobHeader, SK{IDa, AUTHa, SAa, TSIa}

Alice Bob

IKEv2 – fas II

Bob sänder:

• IDb = sin identitet i lämpligt format

• AUTHb = ett värde som styrker identiteten och bevisar att Bob var avsändaren i fas I.

• SAb = som förut, men för ny SA

• TSIb = trafikspecifikation Header, SK{IDb, AUTHb, SAb, TSIb}

IKEv2 – slut på fas II

Efter fas II vet båda parter vem de konverserar med och kan vid framtida meddelandeutbyten vara säkra på att tala ostört, privat och med rätt person.

IKEv2 – fas III

I. Etablering av en SA för IKE konversationen.

II. Ömsesidig autenticering och etablering av första SA för användande i exempelvis IPsec.

III. Etablering av ytterligare SAs, utbyte av kontrollinformation…

Till största delen utlämnat då inte särskilt intressant att studera. Innefattar (krypterade och integritetsskyddade) meddelanden för borttagande och nyskapande av SAs, informationsmeddelanden med mera.

IKEv2 – fas III

Proverif

• Verktyg för automatisk protokollverifiering

• Uppbackat av ett antal papper

• Bruno Blanchet huvudperson

• Verifiering i form av prologliknande härledning utifrån protokollrepresentation

• Undviker typisk tillståndsrymdsexplosion

(à la SPIN) genom ”säkra” antaganden

Proverif – protokollrepresentation

Protokollet och attackeraren beskrivs med prologliknande regler:attacker:secret & attacker:ch -> mess:ch, secret

”Om attackeraren känner till secret och ch kan meddelandet secret sändas över kanalen ch”attacker:enc(secret, key) & attacker:key -> attacker(secret)

”Om attackeraren känner till (secret krypterat med key) och key så känner attackeraren också till secret”

Proverif – applied-pi

Lyckligtvis kan protokollspecifikationer även ges i en begränsad form av applied-pi, som automatiskt översätts till Proverifs klausulformat.

Proverif - termer

Meddelanden och kanaler representeras av termer som är namn, variabler eller funktionsappliceringar av andra termer.

Variabler kan representera andra termer.

Termer används också för att representera saker som hashning, kryptering och konstanter. I det sista exemplet var ”enc” en funktion/2.

Proverif - reduktioner

Termer kan brytas ner enligt givna reduktionsrelationer. Hela sista exemplet är egentligen en Proverif-översättning av relationen:dec(enc(secret, key), key) = secret

Typexempel för användandet av reduktionsrelationer är just dekryptering och verifiering av signaturer.

Proverif - termekvivalens

Stödet för att uttrycka ekvivalens mellan termer är enligt utsago ”experimentellt”, men tillräckligt funktionellt för att uttrycka exempelvis Diffie-Hellman.

(g^i mod p)^r mod p = (g^r modp)^i mod p

skulle kunna uttryckas som:xPowYModP(gPowXModP(x), y) = xPowYModP(gPowXModP(y), x).

Proverif – verifiering av protokollegenskaper

För att verifiera protokollegenskaper ställer man Proverif en fråga uttryckt som ett faktum, exempelvis:query: attacker(sharedDH).

Inte helt olikt förfarandet i Prolog. Vad Proverif sedan gör är att utifrån (översatt) protokollspecifikation försöka härleda faktumet.

Proverif – verifiering av protokollegenskaper 2

För att undvika oändlig sökning, används en annan sökningsmetod än Prologs. Ett par ”säkra antaganden” gör att om en eventuell attack mot protokollet finns, så kommer den att hittas. Men tyvärr ges även vissa falska alarm.

Algoritmen för detta har bevisats vara korrekt. Däremot verkar applied-pi översättningen inte vara bevisad korrekt än.

Proverif – övrigt

Utöver protokollspecifikation etc. kan parametrar ges för attackerarens beteende (passiv/aktiv), flaggor för att guida Proverifs sökning etc.

Analysfokus

I min analys av IKEv2 har jag fokuserat på:

• Vad en attackerare kan få reda på ur Alice och Bobs konversation

• Vad (och om) en attackerare kan tänkas påverka utvecklingen annat än genom typisk DOS.

Analysförbiseende

… samt utelämnat:

• Faktiska algoritmer för kryptering/integritetskontroll

• DOS skydd (cookies)

• Med mera med mera…

Analys - specifika frågor

• Kan en attackerare ändra något innehåll i de första meddelandena (fas I och II) utan att det märks och på så sätt förändra exempelvis förhandlingarna (till det sämre)

• Kan en attackerare avläsa Alices och/eller Bobs identitet?

• Kan vi bevisa att om Bob efter fas I och II tar emot ett krypterat meddelande som verifierar ok, så är det Alice som har skickat det, och i det skick det skickades.

• Ovan, fast vice versa för Alice.

Analys - specifika frågor 2

Om en attackerare inte omärkt kan påverka den inledande förhandlingen om IKE SA (fas I och II) och inte heller omärkt kan påverka den efterföljande konversationen, tycker jag det är befogat att säga att IKEv2 är någorlunda säkert mot attackerare. Det är motivationen bakom analysen och modellen.

Modell

Modellen motsvarar en ytterst stympad version av IKEv2.

Bland saker som utlämnats kan nämnas:

• Versionsnummer

• Certifikat och alternativa autenticeringsmetoder

• Felmeddelanden

• CREATE_CHILD_SA och INFORMATIONAL meddelanden (efter fas II)

• ”Faktisk” betydelse av algoritmer, trafikspecifikationer, …

Resultat

• Kan en attackerare ändra något innehåll i de första meddelandena (fas I och II) utan att det märks och på så sätt förändra förhandlingarna (till det sämre)?

Nej. Om den första SAn etableras är det med de ”bästa” ursprungliga parametrarna.

Resultat 2

• Kan en attackerare avläsa Alices och/eller Bobs identitet? (egentligen: kan en attackerare läsa meddelandena i fas II)

Attackeraren kan låtsas vara Bob i den första fasen och därmed läsa hela Alices meddelande (inkl. identitet)

Resultat 3

• Kan vi bevisa att om Bob efter fas I och II tar emot ett krypterat meddelande som verifierar ok, så är det Alice som har skickat det, och i det skick det skickades.

Ja (aber annan modell).

Resultat 4

• Föregående, fast vice versa för Alice

Ja (aber annan modell).

Relevans

Stämmer egenskaperna bestämda ovan även för en riktig minimal implementation av IKEv2?