Biztonságos kulcscsere-protokollok Összefoglalás (Victor Shoup: On Formal Methods for Secure Key Exchange alapján) II. rész Tóth Gergely 1 Bevezetés A következőkben a Shoup által publikált cikk fő vonulatának (statikus és adaptív feltörés esetére vonatkozó kulcscsere-protokollok) összefoglalása olvasható. A cikkben a következő feltörési módok definíciója található: statikus feltörés: a támadó különböző álnevekkel is megjelenhet a rendszerben, de becsületes felhasználókat nem tud feltörni (korrumpálni); adaptív feltörés: a támadó feltörhet (korrumpálhat) becsületes felhasználókat, és így hozzájuthat ezen felhasználók hosszú távú titkaihoz (long-term secret, LTS); erősen adaptív feltörés: a támadó feltörhet (korrumpálhat) becsületes felhasználókat, és így azok minden belső információjához (amit azok előzőleg kifejezetten nem töröltek) hozzájuthat. Az összefoglalóban csak a protokollok rövid ismertetése és az üzenetek specifikációja kerül bemutatásra. Az egyes protokollok biztonságának formális bizonyítása a teljes cikkben olvasható. Az specifikált protokollok csoportosítása az alábbi táblázatban látható: Fajta Statikus feltörés esetére Statikus feltörés esetére (anonim) Adaptív feltörés esetére Diffie-Hellman alapú DHKE A-DHKE DHKE-1 DHKE-2 DHKE-3 Titkosítás alapú EKE A-EKE-1 EKE-1 A-EKE-2 Adaptív feltörés esetére (anonim) A-DHKE-1 A-DHKE-3 2 Statikus feltörés Először a statikus feltörés esetére vizsgálunk meg protokollokat. Ebben az esetben a támadó a hálózati forgalomtól függetlenül tör fel (korrumpál) felhasználókat. Mivel a támadóról feltesszük, hogy tetszőlegesen befolyásolhatja a hálózatot, a továbbiakban magát a hálózatot beleolvasztjuk a támadóba, így maga a támadó kézbesíti az üzeneteket. Létezik a valós világ a korábban ismertetett módon. Ennek modellezésére definiáltuk az ideális világot. A két világ eseményeinek leírására mindkét esetben készül egy napló Tóth Gergely, 2004. május 5. 1
(transcript). A két naplónak megkülönböztethetetlennek kell lennie. Amennyiben ez teljesül, úgy egy az ideális világban modellezhető protokoll a valós világban biztonságos. Példa: tegyük fel, létezik egy A valós világbeli támadó, aki az egyeztetett viszonykulcsot az egyeztetés után, de még a használat előtt kideríti és beleírja a naplóba. A valós világban tehát a kulcs kitalált és a tényleges értéke tehát megegyezne, amennyiben A meg tudja törni a protokollt. Az ideális világban ez a két érték azonban csak nagyon kis valószínűséggel lenne ugyanaz. Ez azonban statisztikai tesztelésre adna lehetőséget, amivel a valós és az ideális világ naplóját meg lehetne különböztetni. Tehát vagy nincs ilyen A, vagy a kulcscsere protokoll nem biztonságos. Ismétlés: Ideális világ start session operátora: create: start session i, j, create: a porondmester K ij kulcsot véletlen kulcsra állítja connect: start session i, j, connect i, j : a porondmester K ij és K i j kulcsot egyenlővé teszi compromize: start session i, j, compromize, W: a porondmester K ij kulcsot a támadó által adott W kulcsra állítja. Feltételek: C1: create mindig lehetséges: utána I ij izolált. C2: connect akkor lehetséges, ha I i j izolált és kompatibilis I ij -vel. Ezek után I i j már nem izolált. C3: compromize akkor lehetséges, ha PID ij nem. 3 Diffie-Hellman alapú protokoll (DHKE) Minden felhasználó kiválaszt magának egy q-ad rendű G csoportot és ennek egy g generátorát. Ezek után minden felhasználó generál magának egy nyilvános/titkos aláíró kulcspárt. A felhasználó teljes nyilvános kulcsa ezek után G, g és az aláíró nyilvános kulcs, míg a teljes titkos kulcs az aláíró titkos kulcs. sig i (msg) jelenti msg digitális aláírását, melyet az U i felhasználó készített, míg cert i az a tanúsítvány, mely U i felhasználó nyilvános kulcsát és személyazonosságát összekapcsolja. A protokoll szerint U i és U i cserél kulcsot. G, g, q az U i felhasználó tanúsítványában leírt csoportra vonatkozik. A protokollt U i indítja. H k páronként független hash-függvények családja, ahol k egy előre meghatározott hosszúságú véletlenül választott bitsorozat. U i U i : g x, sig i (g x, ID i ), cert i U i U i : g y, k, sig i (g x, g y, k, ID i ), cert i A viszonykulcs ezek után H k (g xy ). Ezen felül minkét fél ellenőrzi a tanúsítványokat és digitális aláírásokat. Amennyiben ezek hibát eredményeznek, úgy nem számolják ki viszonykulcsot és visszautasítják a kapcsolatot. DDH feltételezés: nincs hatékony algoritmus DHP kiszámítására. g 1, g 2, u 1, u 2 G, DHP(g 1, g 2, u 1, u 2 ) 1 ha létezik x Z q, hogy u 1 =g 1 x és u 2 =g 2 x, máskülönben 0. Tóth Gergely, 2004. május 5. 2
F1 feltételezés: A (g, g x, g y, k, H k (g xy )) és a (g, g x, g y, k, K) eloszlás megkülönböztethetetlen (K H k (g xy ) hosszú véletlen szám). T1 tétel: DHKE biztonságos kulcscsere protokoll a DDH feltételezés (F1 feltételezés) mellet, feltéve hogy az alkalmazott aláírási rendszer biztonságos. első üzenet megérkezett I i j -höz PID i j nem PID i j U i második PID ij nem üzenet megérkezett I ij -hez PID ij U i 1. Az ideális világban compromize I i j, a valós világból nyerjük a kulcsot. 1. Azt állítjuk, hogy egy egyértelmű I ij van, úgy hogy PID ij = ID i és I ij küldte g x -et. Ez a protokoll lefolyásából és az aláírások biztonságosságából következik. 2. Emiatt create I i j lehetséges csak és a porondmester kicseréli az aktuális viszonykulcsot egy véletlen viszonykulcsra. Bizonyítandó, hogy ez megkülönböztethetetlen. Ez következik a F1 feltételezésből, feltéve ha I ij nem volt és soha nem is kompromittálódik. Ez azonban fenn áll, hiszen PID ij = ID i és ilyen I ij -re nem megengedett a compromize operátor: I ij vagy soha nem jut elfogadó állapotba vagy I i j -vel connect kapcsolatba lép vagy U i másik példányával kerül kapcsolatba. 1. Az ideális világban compromize I ij, a kulcsot magából I ij -ből nyerjük. 1. Azt állítjuk, hogy egy egyértelmű I i j van úgy, hogy PID i j = ID i és g x, g y, k megegyeznek. Ez a protokoll lefolyásából és az aláírások biztonságosságából következik. Ebben az esetben connect I ij és I i j következik, és a porondmester I ij kulcsát I i j kulcsára állítja be (amit előzőleg szintén a porondmester generált). Ez a csere megkülönböztethetetlen. Ezzel a szimulálhatóság bizonyított. Az életképesség és a befejeződés triviális. 4 Titkosítás alapú protokoll (EKE) Minden felhasználó generál magának egy aláíró és egy titkosító nyilvános/titkos kulcspárt. Hasonlóan az előzőekhez sig i (msg) U i felhasználó msg digitális aláírása, míg E i (msg) U i felhasználó titkosító nyilvános kulcsával való kódolása. U i U i : r, cert i // r egy megfelelően hosszú véletlen bitsorozat U i U i : α = E i (K, ID i ), sig i (α, r, ID i ), cert i // K egy véletlen bitsorozat Ezek után a viszonykulcs K. Ezen felül minkét fél ellenőrzi a tanúsítványokat és digitális aláírásokat. Továbbá U i ellenőrzi, hogy α visszakódolása helyes formájú eredményt ad és a megfelelő személyazonosságot tartalmazza. T2 tétel: EKE biztonságos kulcscsere protokoll, feltéve hogy az alkalmazott aláírási rendszer biztonságos és a titkosítási rendszer rejtjeles szöveg módosíthatatlan biztonságos (nonmalleable). Tóth Gergely, 2004. május 5. 3
első üzenet PID i j nem megérkezett I i j -höz második üzenet megérkezett I ij -hez PID i j U i PID ij nem PID ij U i 1. Az ideális világban compromize I i j, a valós világból nyerjük a kulcsot. 1. create I i j és a porondmester kicseréli az aktuális viszonykulcsot egy véletlen viszonykulcsra. Mivel a titkosítás módosíthatatlan ez a csere megkülönböztethetetlen, feltéve (T2a), hogy a titkosított α-t soha nem kódolják vissza. Ezt a későbbiekben bizonyítjuk. 1. Amennyiben α-t egy olyan I i j generálta, ahol PID i j = ID i, akkor I ij elutasít, mivel az α-ban levő ID i identitás nem az, amit I ij vár (PID ij ). Ezt α dekódolása nélkül megtehető. 2. Amennyiben nem az előbbi eset áll fenn, akkor I ij befejezi a protokollt. Ha elfogadó állapotba kerül, akkor compromize I ij, a kulcsot magából I ij -ből nyerjük. Ez persze implicit módon használja U i dekódoló függvényét, de az előbbiekben biztosítottuk, hogy nem dekódolunk semmit, amit olyan I i j titkosított, ahol PID i j = ID i. Mivel csak itt dekódolunk bármit is ebben a játékban, a fenti kitételt (T2a) miszerint nem dekódolunk olyan titkosított szöveget, amit create operátoros felhasználó generált bizonyítottuk. 1. Amennyiben az aláírás ellenőrzése sikerült, úgy α-t olyan I i j készítette, ahol PID i j = ID i és az α-ban levő identitás ID i. Továbbá connect I ij és I i j érvényes, mivel az r érték egyértelmű (legalábbis óriási valószínűséggel). Tehát connect I ij és I i j, és a porondmester I ij kulcsát I i j kulcsára állítja be (amit előzőleg szintén a porondmester generált). Ez a csere megkülönböztethetetlen. Ezzel a szimulálhatóság bizonyított. Az életképesség és a befejeződés triviális. 5 Anonim alanyok Anonim alany (U 0 ) alatt olyan felhasználót értünk, akinek nincs tanúsítványa. Ennek megfelelően szinonimaként talán a nem hitelesített felhasználót is használhatnánk. Mivel az anonim felhasználó a támadó is lehet, a nem anonim felhasználó számára ezek a protokollok nem tudnak sokat garantálni. Azonban amennyiben felsőbb protokollban (pl. az egyeztetett kulccsal titkosított csatornán keresztül) az anonim alany azonosítja magát (pl. jelszó segítségével), úgy a kommunikáció során mindkét fél személyazonosságának hitelessége garantálható. Ebben az esetben az ideális világ szabályrendszerét módosítani kell: C3*: compromize akkor lehetséges, ha PID ij nem vagy PID ij =anonymous. Tóth Gergely, 2004. május 5. 4
5.1 Anonim Diffie-Hellman alapú protokoll (A-DHKE) A-DHKE a DHKE protokoll módosítása anonim alanyok kezelése érdekében. U 0 U i : g x U i U 0 : g y, k, sig i (g x, g y, k, anonymous), cert i A kulcs ezek után H k (g xy ). Természetesen az anonim alany ellenőrzi a digitális aláírásokat. 5.2 Anonim titkosítás alapú protokollok (A-EKE-1 és A-EKE-2) EKE módosítása A-EKE-1 anonim alanyok kezelése érdekében. U i U 0 : r, cert i // r egy megfelelően hosszú véletlen bitsorozat U 0 U i : α = E i (K, anonymous, r) // K egy véletlen bitsorozat Mint általában, a viszonykulcs K és U i ellenőrzi, hogy a titkosított üzenetben levő értékek megfelelőek-e. Alternatívaként A-EKE-2 protokoll is használható. Legyen f egy K kulccsal indexelt véletlenfüggvény család. U i U 0 : cert i U 0 U i : E i (K, anonymous) // K egy véletlen bitsorozat U i U 0 : r // r egy véletlen bitsorozat Az egyeztetett viszonykulcs f K (r) Mivel általában a gyakorlatban az anonim alany kezdi a kommunikációt, A-EKE-1 és A-EKE-2 implementációja esetén az anonim alany pl. egy üres üzenettel jelezheti kommunikációs szándékát. 6 Adaptív feltörés Adaptív feltörés esetén a támadó hozzájut a felhasználó hosszú távú titkaihoz (LTS), de máshoz nem (így ideiglenes adatokhoz csak a későbbiekben ismertetett erősen adaptív feltörés esetén jut). Ezen kívül megengedjük, hogy a megbízható harmadik félnél is történjen hiba (pl. a támadó beszerezhet olyan tanúsítványt, mely őt mint egy felhasználót jelöli meg). Az elemzéseink során egy feltört felhasználó normálisan vesz továbbra is részt a protokollok lefolyásában, azaz minden üzenetet megfelelően generál és küld. Természetesen mivel a támadó megszerezte a feltört felhasználó hosszú távú titkait, az ő nevében tud más felhasználókkal kapcsolatba lépni. Tóth Gergely, 2004. május 5. 5
Az ideális világ szabályrendszerét módosítani kell: C3*: compromize akkor lehetséges, ha o PID ij nem vagy o PID ij korrumpált vagy o U i korrumpált. A következőkben az adaptív feltörésnek két alfaját különböztetjük meg: általános adaptív kompromittálás: ha U i feltört (korrumpált), akkor minden I ij példánya kompromittálható (compromize érvényes). szigorú adaptív kompromittálás: csak akkor kompromittálható I ij, ha PID ij nincs hozzárendelve semelyik még nem korrumpált. Különbség: Alice a következőképpen gondolkodhat: egy biztonságosan egyeztetett viszonykulccsal titkosított csatornán érkezett üzenet vagy Bob-tól érkezett, vagy Bob korrumpált. Alice ebben biztos lehet, függetlenül attól, hogy az ő kulcsa kiderült-e, azaz függetlenül attól, hogy ő korrumpált-e. 7 Adaptív feltörésnek ellenálló Diffie-Hellman alapú protokollok (DHKE-1, DHKE-2 és DHKE-3) 7.1 DHKE-1 DKHE-1 a DHKE protokoll módosításával kapható és ellenáll adaptív feltörések ellen is. Alapvetően a DHKE protokoll kiegészítése egy kulcs-visszaigazolás üzenettel. U i U i : g x, sig i (g x, ID i ), cert i U i U i : g y, k, sig i (g x, g y, k, ID i ), cert i U i U i : k 1 // ahol (k 1, k 2 ) = BitGen(H k (g xy )) Az egyeztetett viszonykulcs k 2. Az általános aláírás ellenőrzéseken kívül U i ellenőrzi, hogy a megkapott k 1 üzenet megegyezik a várt értékkel. Feltételezzük, hogy k 1 egy elegendően hosszú bitsorozat. A következőkben jelölje G i a cert i -ben leírt csoportot. Hasonlóan az előzőekben ismertetett módszerhez, DHKE-1-et is lehet úgy módosítani, hogy támogasson anonim felhasználókat. Az így kapott protokoll A-DHKE-1. U 0 U i : g x U i U 0 : g y, k, sig i (g x, g y, k, anonymous), cert i U 0 U i : k 1 // ahol (k 1, k 2 ) = BitGen(H k (g xy )) Tóth Gergely, 2004. május 5. 6
7.2 DHKE-2 DHKE-1 DHKE minimális módosítása volt. Most ismertetjük DHKE-2-t, ami egy másik megközelítés. U i U i : g x, cert i U i U i : g y, k, sig i (g x, g y, k, ID i ), cert i U i U i : sig i (g x, g y, k, ID i ) A feltételek azonosak DHKE-vel, azaz a viszonykulcs H k (g xy ). 7.3 DHKE-3 Bár DHKE-1 és DHKE-2 biztonságos általános adaptív kompromittálás esetén, érdemes megjegyezni, hogy a szigorú adaptív kompromittálás esetén nem biztonságosak. DHKE-1 esetén nincs egyszerű mód eme hiányosság kijavítására, azonban DHKE-2 könnyen módosítható úgy, hogy a szigorú szabálynak is megfeleljen. Az így létrejött protokoll DHKE-3. U i U i : G i, g x, cert i U i U i : g y, k, sig i (G i, g x, g y, k, ID i ), cert i U i U i : sig i (G i, g x, g y, k, ID i ) Természetesen DHKE-3 is módosítható úgy, hogy támogassa az anonim felhasználókat. Az így kapott protokoll A-DHKE-3. U i U 0 : G i, g x, cert i U 0 U i : g y, k U i U 0 : sig i (G i, g x, g y, k, anonymous) 8 Adaptív feltörésnek ellenálló titkosítás alapú protokoll (EKE-1) Legvégül ismertetésre kerül az EKE-1 protokoll, ami az EKE protokoll kicsit módosított változata. A módosítás lényege, hogy nem csak hosszú-távú aszimmetrikus kulcsokat használ, hanem ideiglenes (csak egy viszony alatt élő) kulcsokat is. Minden felhasználó egyrészt generál magának egy aláíró kulcspárt, melynek nyilvános része kerül a felhasználó tanúsítványába. Ezen felül minden felhasználó rendelkezik egy kulcsgeneráló algoritmussal KeyGen(), ami egy nyilvános/titkos kulcspárt (E, D) generál. U i U i : E, sig i (E, ID i ), cert i // ahol (E, D) = KeyGen() U i U i : α = E(K), sig i (α, E, ID i ), cert i // K egy véletlen bitsorozat Tóth Gergely, 2004. május 5. 7
Az egyeztetett viszonykulcs K, amit U i D(α) kiszámolásával kap meg. Mint mindig, mindkét fél ellenőrzi a digitális aláírásokat. Megjegyzés: EKE-vel ellentétben U i nem rakja bele személyazonosságát (ID i ) a titkosított üzenetbe. 9 Összefoglaló A biztonságos kulcscsere protokollok legelterjedtebb alkalmazási területe az ún. rejtjel protokollok (pl. SSL, TLS, SSH, WTLS) első lépése, melynek során a két kommunikáló fél megegyezik a közös titokban (master secret), amelyből aztán mindketten legenerálják a titkosítási és üzenet-hitelesítési kulcsokat. Az összefoglaló ismertetett Diffie-Hellman és titkosítás alapú protokollokat, melyek különböző feltételek (pl. statikus feltörés, anonim alanyok, adaptív feltörés) mellett biztosítják a kulcsok biztonságos (titkos és hiteles) egyeztetését. Tóth Gergely, 2004. május 5. 8