IKEv2 En halvformell analys

1. IKEv2En halvformell analys

2. Agenda • IKEv2 – protokollet i huvuddrag • Proverif – bakgrund, funktion • Analys – fokus • Modell – abstraktioner, förenklingar • Resultat

3. 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

4. IKEv2 - faser • Etablering av en SA för IKE konversationen. • Ömsesidig autenticering och etablering av första SA för användande i exempelvis IPsec. • Etablering av ytterligare SAs, utbyte av kontrollinformation…

5. IKEv2 – fas I • Etablering av en SA för IKE konversationen. • Ömsesidig autenticering och etablering av första SA för användande i exempelvis IPsec. • Etablering av ytterligare SAs, utbyte av kontrollinformation…

6. IKEv2 – fas I • Alice sänder: • Fix IKEv2 header • KEa = publikt Diffie-Hellman värde • SAa = erbjudna kryptografiska algoritmer • Ni = nonsens (nonce) Header, SAa, KEa, Ni Alice Bob

7. 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. Header, SAa, KEa, Ni Alice Bob

8. 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) Header, SAb, KEb, Nb Alice Bob

9. 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.

10. IKEv2 – fas II • Etablering av en SA för IKE konversationen. • Ömsesidig autenticering och etablering av första SA för användande i exempelvis IPsec. • Etablering av ytterligare SAs, utbyte av kontrollinformation…

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

12. 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 Header, SK{IDa, AUTHa, SAa, TSIa} Alice Bob

13. IKEv2 – fas II Bob tar emot Alices meddelande, utvärderar erbjudanden vad gäller kryptografiska algoritmer, verifierar identiteten, samt skapar ett svarsmeddelande. Header, SK{IDa, AUTHa, SAa, TSIa} Alice Bob

14. 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} Alice Bob

15. 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.

16. IKEv2 – fas III • Etablering av en SA för IKE konversationen. • Ömsesidig autenticering och etablering av första SA för användande i exempelvis IPsec. • Etablering av ytterligare SAs, utbyte av kontrollinformation…

17. IKEv2 – fas III 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.

18. 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

19. 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”

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

21. 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.

22. 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.

23. 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).

24. 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.

25. 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.

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

27. 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.

28. Analysförbiseende … samt utelämnat: • Faktiska algoritmer för kryptering/integritetskontroll • DOS skydd (cookies) • Med mera med mera…

29. 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.

30. 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.

31. 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, …

32. 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.

33. 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)

34. 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).

35. Resultat 4 • Föregående, fast vice versa för Alice Ja (aber annan modell).

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