A „kryptográfia” szóra egyesek felidézik a WiFi-jelszavukat, a zöld lakatot a kedvenc oldaluk címe mellett és azt, hogy mennyire nehéz belépni mások e-mail fiókjába. Mások az elmúlt évek sorozatos sebezhetőségeire emlékeznek a beszédes mozaikszavakkal (DROWN, FREAK, POODLE…) és a figyelmeztetésekre, hogy sürgősen frissíteni kell a böngészőt.

A kryptográfia mindezt magába foglalja, de a lényeg másban rejlik. A lényeg a könnyű és a nehéz közötti vékony határvonal. Néhány dolgot könnyű megtenni, de nehéz visszafordítani: például tojást törni. Más dolgokat könnyű megtenni, de nehéz visszafordítani, amikor egy kis, fontos, döntő rész hiányzik: például kinyitni egy zárt ajtót, amikor a „döntő rész” a kulcs. A kryptográfia ezeket a helyzeteket és azok gyakorlati alkalmazását vizsgálja.

Az utóbbi években a kryptográfiai támadások gyűjteménye egy üvöltő logókkal teli állatkertté változott, tele tudományos cikkek formuláival, és egy általános zord érzést keltett, hogy minden eltört. De valójában sok támadás néhány közös elven alapul, és a végtelen oldalnyi formula gyakran leegyszerűsödik könnyen érthető ötletekké.

Ebben a cikksorozatban különböző típusú kryptográfiai támadásokat fogunk áttekinteni, a fő elvekre összpontosítva. Nagyjából, ha nem is pontosan ebben a sorrendben, de a következőket beszéljük meg:

Alapvető stratégiák: bruteforce, frekvenciaanalízis, interpoláció, csökkentés és keresztprotokollok.
„Márkás” sebezhetőségek: FREAK, CRIME, POODLE, DROWN, Logjam.
Fejlett stratégiák: oracle támadások (Waters támadása, Kelsey támadása); meet-in-the-middle módszer, születésnapi támadás, statisztikai eltolás (differenciális kryptográfiai analízis, integrális kryptográfiai analízis stb.).
Oldalsó csatornákon történő támadások és azok közeli rokonai, hibaelemzési módszerek.
Nyilvános kulcsú kryptográfiára irányuló támadások: kocka gyökér, broadcast, kapcsolt üzenet, Coppersmith támadása, Pollard-Hellman algoritmus, numerikus szitálás, Wiener támadása, Bluhmenbach támadása.

Ez a konkrét cikk a fent említett anyagot a Kelsey támadásig terjedően fedi le.

Alapvető stratégiák

A következő támadások abban az értelemben egyszerűek, hogy szinte teljesen meg lehet őket magyarázni különösebb technikai részletek nélkül. Minden egyes támadást a legegyszerűbb értelemben fogunk elmagyarázni, anélkül hogy bonyolult példákba vagy kiterjesztett felhasználási módokba mélyednénk.

E támadások közül néhány lényegében elvesztette relevanciáját, és már évek óta nem alkalmazzák őket. Mások viszont igazi veteránok, amelyek továbbra is rendszeresen rá törnek a gyanútlan kriptosystem fejlesztőkre a 21. században. Úgy vélik, hogy a modern kriptográfia kora az IBM DES megjelenésével kezdődött - ez volt az első titkosítás, amely minden, ebben a listában szereplő támadást túlél.

Egyszerű bruttó erő

A titkosítási séma két részből áll: 1) egy titkosító függvény, amely egy üzenetet (nyílt szöveg) fogad el egy kulccsal együtt, és titkos üzenetet - titkosított szöveget - hoz létre; 2) egy visszafejtő függvény, amely titkosított szöveget és kulcsot fogad el és előállít egy nyílt szöveget. A titkosításnak és a visszafejtésnek is könnyen kiszámíthatónak kell lennie a kulccsal — és nehéznek anélkül.

Tegyük fel, hogy látunk egy titkosított szöveget és megpróbáljuk visszafejteni anélkül, hogy bárminemű kiegészítő információt használnánk (ezt hívják "csak titkos szöveges támadásnak"). Ha valamilyen varázslatos módon megtaláljuk a helyes kulcsot, akkor könnyen ellenőrizhetjük, hogy valóban helyes-e, ha az eredmény egy ésszerű üzenet.

Ne feledjük, hogy itt két implicit feltételezés áll fent. Először is, hogy tudjuk, hogyan végezhető el a visszafejtés, azaz hogyan működik a kriptosystem. Ez a kriptográfia vitájában megszokott feltételezés. A titkosító részleteinek elrejtése a támadóktól kiegészítő biztonsági intézkedésnek tűnhet, de amint a támadó felfedezi ezeket a részleteket, ez a kiegészítő biztonság észrevétlenül és visszafordíthatatlanul elveszik. Ilyen az Kerckhoffs-elv: a rendszer ellenség kezére jutása nem okozhat kényelmetlenséget.

Másodszor, azt feltételezzük, hogy a helyes kulcs az egyetlen kulcs, amely ésszerű visszafejtéshez vezet. Ez szintén ésszerű feltételezés; ez teljesül, ha a titkosított szöveg jóval hosszabb, mint a kulcs, és jól olvasható. Általában ez a való világban is így van, kivéve, hogy óriási gyakorlatilag megoldhatatlan kulcsok vagy más manőverek, amelyekről jobb, ha nem beszélünk (ha nem tetszik, hogy elutasítottuk a magyarázatokat, kérem, nézze meg a 3.8-as tételt) itt).

A fentieket figyelembe véve egy stratégia merül fel: ellenőrizni minden lehetséges kulcsot. Ezt hívják bruttóforrásnak, és ilyen támadás garantáltan működik minden gyakorlati titkosítás ellen - végül is. Például a bruttóforrást elegendő ahhoz, hogy feltörje Cézar titkosítását, egy ősi titkosítást, ahol a kulcs egy betű az ábécében, ami valamivel több mint 20 lehetséges kulcsot jelent.

Sajnos a kriptográfiai elemzők szempontjából a kulcs méretének növelése jól véd a bruttóforrástól. Ahogy nő a kulcs mérete, a lehetséges kulcsok száma exponenciálisan nő. A modern kulcsméretek mellett a szimpla bruttóforrás teljesen gyakorlatlan. Ahhoz, hogy megértsük, mire gondolunk, vegyük a 2019 közepén a leggyorsabb ismert szuperszámítógépet: Summit az IBM-től, amelynek csúcs teljesítménye körülbelül 10^17 művelet/másodperc. Ma egy tipikus kulcshossz 128 bit, ami 2^128 lehetséges kombinációt jelent. Mivel az összes kulcs végigpróbálásához a Summit szuperszámítógépnek olyan időre lenne szüksége, amely körülbelül 7800-szorosa a Világegyetem életkorának.

Kell-e a bruttóforrást történelmi kuriózumnak tekinteni? Semmiképpen: ez egy szükséges hozzávaló a kriptográfiai elemzés receptjében. Ritkán találkozhatunk olyan gyenge titkosítással, amelyet csak okos támadással lehet feltörni, a fizikai erő alkalmazása nélkül. Sokan sikeres feltörések kezdetben algoritmikus módszert használnak a célzott titkosítás gyengítésére, majd bruttóforrást indítanak.

Frequencies elemzés

A legtöbb szöveg nem zavaros. Például az angol nyelvű szövegekben sok ‘e’ betű és ‘the’ névelő található; a bináris fájlokban pedig sok nullás bájt van használva az információs fragmentumok közötti kitöltőként. A frekvenciaelemzés - bármilyen támadás, amely ezt a tényt használja.

A klasszikus példa a titkosításhoz, amely érzékeny erre a támadásra, a egyszerű helyettesítő titkosítás. Ebben a titkosításban a kulcs egy táblázat az összes betű helyettesítésére. Például a ‘g’ helyettesítve van ‘h’-ra, az ‘o’ - j-re, ezért a ‘go’ szó ‘hj’-vé alakul. Ez a titkosítás nehezen adható fel bruttóforrással, mivel nagyon sok lehetséges helyettesítő tábla létezik. Ha érdekli a matematika, a hatékony kulcshossz körülbelül 88 bit:
. De a frekvenciaelemzés általában gyorsan megbirkózik a feladattal.

Vizsgáljuk meg a következő titkosított szöveget, amelyet egy egyszerű helyettesítő titkosítás kezel:

XDYLY ALY UGLY XDWNKE WN DYAJYN ANF YALXD DGLAXWG XDAN ALY FLYAUX GR WN OGQL ZDWBGEGZDO

Mivel Y Gyakran előfordul, különösen sok szó végén, előzetesen feltételezhetjük, hogy ez a betű e:

XDeLe ALe UGLe XDWNKE WN DeAJeN ANF eALXD DGLAXWG XDAN ALe FLeAUX GR WN OGQL ZDWBGEGZDO

Pár XD több szó elején is ismétlődik. Különösen a kombináció XDeLe egyértelműen azt sugallja, hogy ez a szó these vagy there, ezért folytatjuk:

theLe ALe UGLe thWNKE WN heAJeN ANF eALth DGLAtWG thAN ALe FLeAUt GR WN OGQL ZDWBGEGZDO

Továbbá feltételezzük, hogy L megfelel r, A — a és így tovább. Valószínűleg többször is próbálkozni kell, de a teljes brütforccal összehasonlítva ez a támadás a lehető legrövidebb időn belül helyreállítja az eredeti szöveget:

there are more things in heaven and earth horatio than are dreamt of in your philosophy

Néhányak számára ezeknek a „kryptogramoknak” a megoldása izgalmas hobbi.

A frekvenciaelemzés ötlete alapvetőbb, mint amilyennek első pillantásra tűnik. És alkalmazható sokkal bonyolultabb titkosításokra. A történelem során különféle titkosító konstrukciók próbáltak ellenállni az ilyen támadásoknak „polialfabetikus helyettesítéssel”. Itt a titkosítás során a betűk helyettesítési táblázata bonyolult, de előre jelezhető módokon változik, amelyek a kulcstól függenek. Mindezeket a titkosításokat valaha nehezen feltörhetőnek tartották; és mégis, a szerény frekvenciaelemzés végül mindegyiket legyőzte.

A történelem legambiciózusabb polialfabetikus titkosítása, és talán a legismertebb a második világháborúban, az „Enigma” titkosítás volt. Összehasonlítva az elődeihez, viszonylag bonyolult volt, de a brit kriptoanalitikusok hosszú és kitartó munkával feltörték, frekvenciaelemzéssel. Természetesen nem tudtak olyan elegáns támadást kifejleszteni, mint amit fentebb mutattunk; ismert nyílt és titkosított szövegpárok összehasonlításával kellett próbálkozniuk (úgynevezett „nyílt szöveg alapú támadás”) és még arra is rávették az „Enigma” használóit, hogy bizonyos üzeneteket titkosítsanak a végeredmény analíziséhez („megbízott nyílt szövegek alapú támadás”). De ez nem könnyítette meg az ellenséges hadseregek és megsemmisített tengeralattjárók sorsát.

Egy ilyen diadal után a frekvenciaelemzés eltűnt a kriptoelemzés történetéből. A modern digitális korszak titkosításai a bitek kezelésére készültek, nem pedig a betűkére. Ami még fontosabb, ezeket a titkosításokat sötét megértéssel tervezték, ami később a következő néven vált ismertté Schneier törvény: bárki létrehozhat olyan titkosítási algoritmust, amelyet maga nem tud feltörni. Nem elegendő, ha a titkosító rendszer bonyolultnak tűnik: ahhoz, hogy bizonyítsa értékét, könyörtelen biztonsági ellenőrzésnek kell alávetni számos kriptoelemző által, akik mindent megtesznek a titkosítás feltörésére. Előzetes számítások

Vegyünk egy hipotetikus Prakom Heights várost, 200 000 lakossal. A város minden házában átlagosan 30 000 dollár értékű értékek találhatók, de legfeljebb 50 000 dollár értékben. A Prakomi biztonsági piacot az ACME Industries monopóliuma tartja kézben, amely a legendás Coyote ™ osztályú zárakat gyártja. Szakértői elemzés szerint a Coyote osztályú zárat csak egy nagyon összetett hipotetikus gép képes feltörni, amelynek létrehozása körülbelül öt évet és 50 000 dollár befektetést igényel. Biztonságban van a város?

Valószínűleg nem. Végül megjelenik egy elég ambiciózus bűnöző. Így érvel: "Igen, nagy előzetes költségeket fogok viselni. Öt év türelmes várakozás és 50 000 dollár. De a munka végén hozzáférésem lesz

a város összes gazdagságához. . Ha jól kijátszom a lapjaimat, ez a befektetés többszörös megtérülést fog hozni."Hasonlóan van ez a kriptográfiában is. A konkrét titkosítással szembeni támadásokat könyörtelen költség-haszon elemzésnek vetik alá. Ha a ráta kedvező, a támadás nem fog megtörténni. De azok a támadások, amelyek egyszerre sok potenciális áldozat ellen irányulnak, szinte mindig megtérülnek, és ebben az esetben a legjobb tervezési gyakorlat az, hogy feltételezzük, hogy ezek a támadások az első naptól kezdve megkezdődtek. Lényegében van egy kriptográfiai Murphy-törvényünk: "Minden, ami valóban képes feltörni a rendszert, feltöri a rendszert."

A legegyszerűbb példája a titkosítási rendszernek, amely érzékeny a előzetes számítások támadására, a kulcs használata nélküli, állandó algoritmussal működő titkosítás. Ilyen volt a

Caesar titkosítás. Caesar-rejtés, ami egyszerűen minden betűt a abc-ban hárommal előrébb tol, a táblázat zárt, így az abc utolsó betűje a harmadik betűvel titkosított. Itt ismét megjelenik a Kerckhoffs-elv: amint a rendszert feltörték, azt örökre feltörték.

A koncepció egyszerű. Még egy kezdő kriptográf valószínűleg tisztában van a fenyegetéssel, és ennek megfelelően felkészül. Ha megnézzük a kriptográfia fejlődését, az ilyen támadások a legtöbb titkosítás számára nem voltak relevánsak, a Julius Caesar titkosításának első fejlettebb változataitól kezdve egészen a poli-alfa titkosítások hanyatlásáig. Ezek a támadások csak a modern kriptográfiai korszak beköszöntével tértek vissza.

Ez a visszatérés két tényezőnek köszönhető. Először is, végre elérkeztek olyan bonyolult kriptográfiai rendszerek, ahol a törés utáni kihasználás lehetősége nem volt nyilvánvaló. Másodszor, a kriptográfia annyira elterjedt, hogy minden nap milliók hoztak döntéseket arról, hol és milyen kriptográfiai elemeket használjanak újra. Amíg a szakértők fel nem ébredtek a felmerülő kockázatokra és meg nem kongatták a vészharangot, telt el egy kis idő.

Emlékezz a pre-kalkulált támadásra: a cikk vége felé két valós példát fogunk megvizsgálni, ahol fontos szerepet játszott.

Interpoláció

Itt van a híres detektív, Sherlock Holmes, aki interpolációs támadást hajt végre a balsorsú doktor Watsonon:

Azonnal rájöttem, hogy Afganisztánból érkezett... A gondolataim így haladtak: „Ez az ember orvos, de katonai tartása van. Tehát katonai orvos. Most jött a trópusokról – az arca sötét, de ez nem a bőrszíne természetes árnyalata, mivel a csuklói sokkal világosabbak. Az arca kimerült – nyilván nem kis szenvedéseken ment keresztül és átvészelt egy betegséget. A bal karján megsebesült – mozdulatlanul tartja, és egy kicsit természetellenes is. Hol szenvedhetett katonai orvosként a trópusokon, és szerzett sebet? Természetesen Afganisztánban.” Az egész gondolatmenet nem tartott tovább egy másodpercnél. És azt mondtam, hogy Afganisztánból érkezett, amire meglepődött.

Minden kaptárból külön-külön Holmes csak nagyon kevés információt tudott kiemelni. Ő csak akkor juthatott el a következtetéséhez, ha mindegyiküket együtt vizsgálta. Hasonlóan működik az interpolálás támadása, amely a nyílt és titkos szövegek ismert párjait kutatja, amelyeket ugyanazzal a kulccsal alkalmaztak. Minden párból külön megfigyelések nyerhetők, amelyek lehetővé teszik, hogy általános következtetést vonjunk le a kulcsról. Mindezek a megfontolások homályosak, és haszontalannak tűnnek, amíg hirtelen el nem érik a kritikus tömeget, és nem vezetnek egyetlen lehetséges következtetéshez: bármennyire hihetetlen is, annak igaznak kell lennie. Ezt követően vagy a kulcs fedeződik fel, vagy a dekódolási folyamat olyan kifinomulttá válik, hogy többször is meg lehet ismételni.

Illusztráljunk egy egyszerű példával, hogyan működik az interpolálás. Tegyük fel, hogy el szeretnénk olvasni ellenségünk, Bob naplóját. Bob minden számot egyszerű kriptográfiai rendszerrel titkosít, amelyről egy hirdetésben hallott a „Közönséges élcelődés a kriptográfiával” című magazinban. A rendszer így működik: Bob kiválaszt két számára tetsző számot: és . Ettől kezdve ahhoz, hogy bármely számot titkosítson, megszámolja. . Például, ha Bob a és számokat választja, akkor a szám így lesz titkosítva: .

Tegyük fel, hogy december 28-án észrevesszük, hogy Bob valamit kapargat a naplójában. Amikor befejezi, észrevétlenül átvesszük, és megnézzük az utolsó bejegyzést:

Dátum: 235/520
Kedves napló,
Ma jó napom volt. Két 64 nap múlva randevúm van Alisszal, aki a 843apartmanban él. Tényleg úgy gondolom, hogy ő lehet 26!

Mivel nagyon komolyan szeretnénk nyomon követni Bobot a randevúján (ebben a forgatókönyvben 15 évesek vagyunk), kritikus fontosságú, hogy megtudjuk az időpontot és Alissa címét. Szerencsére észrevesszük, hogy Bob kriptográfiai rendszere sebezhető az interpolálás támadásával szemben. Lehet, hogy nem tudjuk, és de tudjuk a mai dátumot, tehát van két párunk „nyílt szöveg — titkos szöveg”. Azt tudjuk, hogy titkosítva van , és — ehhez tízszer kevesebb hardver szükséges. . Amit fel is jegyzünk:

Mivel 15 évesek vagyunk, már tudunk a két ismeretlenes egyenletrendszerről, ami ebben az esetben elegendő a megoldáshoz. és problémament. Minden egyes „nyílt szöveg-titkos szöveg” pár korlátozást ró Bob kulcsára, és a két korlátozás együtt elegendő a kulcs teljes helyreállításához. Példánkban a válasz és (kor , ezért 26 a naplóban a ‘the one’ szónak felel meg, azaz „az a” – megjegyz. –.

A interpolációs támadások természetesen nem korlátozódnak ilyen egyszerű példákra. Minden egyes kriptográfiai rendszer, amely egy jól érthető matematikai objektumra és paraméterek listájára redukálható, ki van téve interpolációs támadásoknak – minél érthetőbb az objektum, annál nagyobb a kockázat.

A kezdők gyakran panaszkodnak, hogy a kriptográfia „a lehető legcsúnyább dolgok megtervezésének művészete”. Valószínűleg ennek nagy része az interpolációs támadásoknak köszönhető. Bob vagy használhat elegáns matematikai dizájnt, vagy megőrizheti Alice-szal való találkozó titkosságát – de sajnos általában nem lehet mindkettőt egyszerre elérni. Ez különösen nyilvánvalóvá válik, amikor végre áttérünk a nyilvános kulcsú kriptográfia témájára.

Kereszt-protokoll/csökkentés

A „A csalás művészete” (2013) című filmben egy illuzionista csoport megpróbálja átverni a korrupt biztosítási mágnás, Arthur Tressler összes vagyonát. Ahhoz, hogy hozzáférjenek Arthur bankszámlájához, az illuzionistáknak be kell mutatniuk a felhasználónevét és a jelszavát, vagy rá kell vennie őt, hogy személyesen megjelenjen a bankban és részt vegyen a tervben.

Mindkét lehetőség nagyon nehéz; a srácok színpadi fellépéshez szoktak, nem titkos szolgálati műveletekhez. Ezért ők a harmadik lehetséges megoldást választják: a társuk telefonál a bankba és magát Arthur-nak adja ki. A bank néhány kérdést tesz fel az személyazonosság ellenőrzésére, mint például a nagybátyja neve és az első háziállata neve; hőseink előre ügyesen kinyerik Arthur-tól ezeket az információkat ügyes társadalmi manipulációval. Innentől kezdve a jelszó kiváló biztonsága már nem számít.

(A városi legenda szerint, amelyet személyesen ellenőriztünk és megerősítettünk, Eli Biham kriptográfus egyszer találkozott egy banki pénztárossal, aki ragaszkodott egy titkos kérdés beállításához. Amikor a pénztáros megkérdezte a nagymama nevét az anyai ágon, Biham elkezdte diktálni: „Nagy X, kis y, három…”).

A kriptográfiában is, ha ugyanazon aktív védelem érdekében párhuzamosan két titkosítási protokollt alkalmazunk, egyikük jelentősen gyengébb a másiknál. Az eredményül kapott rendszer sebezhetővé válik a keresztprotokollos támadásokkal szemben, amikor a gyengébb protokollt támadják, hogy elérjék a célt anélkül, hogy a robusztusabbal foglalkoznának.

Néhány összetett esetben elegendő csak a gyengébb protokollon kapcsolódni a szerverhez, hanem szükséges a jogos ügyfél akaratlan részvétele is. Ezt a lejtő támadásnak (downgrade attack) nevezett módszerrel lehet elérni. E támadás megértéséhez tegyük fel, hogy varázslóinknak bonyolultabb feladattal kell szembenézniük, mint a filmben. Tegyük fel, hogy a banki dolgozó (pénztáros) és Arthur között váratlan körülmények merültek fel, aminek következtében egy ilyen párbeszéd zajlott le:

Hacker: Helló? Arthur Treszler vagyok. Szeretném visszaállítani a jelszavamat.
Pénztáros: Nagyszerű. Kérlek, nézd meg a személyes titkos kódjaid könyvében a 28. oldalon, a harmadik szónál. Minden további üzenet e konkrét szó alkalmazásával lesz titkosítva. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Hacker: Hé, hé, várj, várj. Ezt tényleg szükséges? Nem beszélhetünk egyszerűen, mint a normális emberek?
Pénztáros: Nem javaslom ezt.
Hacker: Csak… figyelj, borzalmas napom volt, oké? VIP ügyfél vagyok, és nem vagyok kedvem a hülye kód könyvekben áskálódni.
Pénztáros: Rendben van. Ha így inszisztálsz, Treszler úr. Mit szeretnél?
Hacker: Kérlek, szeretném átutalni az összes pénzemet az Arthur Treszler áldozati alapba.
(Szünet).
Pénztáros: Értem. Kérlek, add meg a nagy összegű tranzakciók PIN-kódodat.
Hacker: Mik?
Pénztáros: A személyes kérésed miatt az ilyen méretű tranzakciókhoz PIN-kód megadása szükséges. Ezt a kódot a számla megnyitásakor kaptad.
Hacker:...Elhagytam. Ezt tényleg szükséges? Nem tudjátok egyszerűen jóváhagyni az üzletet?
Pénztáros: Nem. Elnézést, Treszler úr. Ismétlem, ez egy biztonsági intézkedés, amit kérted. Ha szeretnéd, új PIN-kódot is küldhetünk a postafiókodba.

Hőseink elhalasztják a műveletet. Több nagy tranzakciót figyelnek Treszler-től, abban a reményben, hogy meghallják a PIN-kódot; de minden alkalommal a beszélgetés titkos, érthetetlen zűrzavarrá válik, mielőtt bármi érdekes elhangzana. Végül, egy szép napon végrehajtják a tervet. Türelmesen várják a pillanatot, amikor Treszler-nek nagy tranzakciót kell lebonyolítania telefonon, csatlakozik a vonalhoz, majd…

Treszler: Jó napot kívánok. Szeretnék egy távoli tranzakciót lebonyolítani, kérem.
Pénztáros: Remek. Kérem, nézze meg a személyes titkos kódjait, a következő oldalon…
(A hekkerek megnyomják a gombot; a pénztáros hangja érthetetlen zajba mérgesedik át).
Pénztáros: — #@$#@$#*@$$@#* ezzel a szóval lesz titkosítva, mint kulcs. AAAYRR PLRQRZ MMNJK LOJBAN…
Treszler: Elnézést, nem egészen értettem. Megismételné? Melyik oldalon? Melyik szó?
Pénztáros: Ez a @#$@#*$)#*#@()#@$(#@*$(#@* oldalon található.
Treszler: Mi?
Pénztáros: A huszadik számú szó @$#@$#%#$.
Treszler: Viccelsz! Elég már! Ezzel a biztonsági protokollal csak cirkuszt csinálsz. Tudom, hogy egyszerűen normálisan beszélhetsz velem.
Pénztáros: Nem tanácsolom…
Treszler: Én pedig nem tanácsolom, hogy pazarold az időmet. Nem akarok többet hallani erről, amíg nem javítják meg a telefonvonal problémáit. Lebonyolíthatjuk ezt az üzletet vagy sem?
Pénztáros:… igen. Rendben. Mit szeretne?
Treszler: Szeretnék $20 000-t átutalni a Lord Business Investments-nek, a számlaszám…
Pénztáros: Kérem, egy pillanat otthoni. Ez nagy üzlet. Kérem, adja meg a nagy tranzakciókhoz szükséges PIN-kódját.
Treszler: Mi? Aha, igen. 1234.

Itt van a leértékelő támadás. A gyengébb „csak beszéljünk egyenesen” protokollt arra szánták, hogy beállítás végső esetben használják. És mégis itt vagyunk.

Felmerülhet a kérdés, ki az épeszű, aki valós rendszert tervezne a „biztonságos, amíg nem kérjük vissza” elve alapján, ahogyan azt fentebb leírták. De ahogyan a fiktív bank is kockázatot vállal, hogy megtartsa azokat az ügyfeleket, akik nem kedvelik a kriptográfiát, úgy a rendszerek általában gyakran megadják magukat az olyan követeléseknek, amelyek közömbösek vagy nyíltan ellenségesek a biztonsággal szemben.

Pontosan ez a történet zajlott le az SSLv2 protokollal 1995-ben. Az Egyesült Államok kormánya régóta úgy tekintett a kriptográfiára, mint egy fegyverre, amelyet jobb távol tartani a külső és belső ellenségektől. A kóddarabokat külön-külön hagyták jóvá az Egyesült Államokból való exportálásra, gyakran az algoritmus szándékos gyengítésének feltételével. A Netscape, a legnépszerűbb Netscape Navigator böngésző fejlesztője, csak egy eredetileg sebezhető 512 bites RSA kulccsal (és 40 bit RC4-hez) engedélyezte az SSLv2-t.

Az évezred végére a szabályokat enyhítették, és a modern titkosításhoz való hozzáférés széles körben elérhetővé vált. Ennek ellenére az ügyfelek és a szerverek évekig támogatták a gyenge "export" kriptográfiát, mivel ugyanaz az inert rendszer tartotta életben az elavult rendszerek támogatását. Az ügyfelek úgy vélték, hogy találkozhatnak olyan szerverrel, amely nem támogat semmi mást. A szerverek ugyanazt tették. Természetesen az SSL protokoll diktálja, hogy az ügyfeleknek és a szervereknek soha nem szabad gyenge protokollt használniuk, amikor jobb elérhető. De ugyanaz a feltételezés vonatkozott Tresstlerre és a bankjára is.

Ez a teória két nagy támadás során valósult meg, amelyek egymás után rázkódtatták meg az SSL protokoll biztonságát 2015-ben, mindkettőt a Microsoft kutatói fedezték fel, INRIA. Először februárban a FREAK támadás részleteit tárták fel, majd három hónappal később egy másik hasonló támadást, a Logjam néven ismert, amelyet részletesebben megvitatunk, amikor az nyílt kulcsú kriptográfiára irányuló támadásokra térünk át.

Sérülékenység FREAK (más néven "Smack TLS") akkor jelentkezett, amikor a kutatók elemezték a TLS kliens/szerver megvalósításait, és felfedeztek egy érdekes hibát. Ezekben a megvalósításokban, ha a kliens még csak nem is kérte a gyenge export kriptográfia használatát, a szerver mégis ilyen kulcsokkal válaszolt – a kliens azt mondja: "Rendben van", és átvált a gyenge titkosító készletre.

Abban az időben mindenki elavultnak és használatra tiltottnak tartotta az exportkriptográfiát, ezért a támadás igazi sokkot okozott, és számos fontos területet érintett, beleértve a Fehér Ház, az Egyesült Államok Adóhatósága és az NSA weboldalait. Ami pedig még rosszabb, kiderült, hogy sok sebezhető szerver a teljesítmény optimalizálása érdekében újrahasználta ugyanazokat a kulcsokat, ahelyett, hogy minden egyes munkamenethez újakat generált volna. Ez lehetővé tette, hogy a protokoll csökkentése után egy előkalkulációs támadást is végrehajtsanak: egy kulcs feltörése viszonylag drága maradt (100 dollár és 12 óra a publikálás idején), de a kapcsolat támadásának gyakorlati költsége jelentősen csökkent. Elég egyszer kitalálni a szerver kulcsát - és feltörni a titkosítást minden következő kapcsolathoz ezután.

És mielőtt továbblépnénk, meg kell említenünk egy fejlett támadást...

Az orákulum támadása

Moxie Marlinspike legismertebb a Signal keresztplatformos kriptomessengere atyjaként; de számunkra egy kevésbé ismert újítása tetszik a legjobban - a kriptográfiai végzetesség elve (Cryptographic Doom Principle). Kissé átfogalmazva, így mondhatnánk: „Ha a protokoll bármilyen kriptográfiai műveletet végez egy potenciálisan káros forrásból származó üzenettel, és a különböző eredmények esetén másként viselkedik, akkor végzetes.” Vagy élesebben fogalmazva: „Ne vegyél információt az ellenségtől feldolgozásra, de ha muszáj, legalább ne mutasd meg az eredményt.” Hagyjuk figyelmen kívül a puffertúlcsordulásokat, parancsinjekciókat és hasonlókat; ezek túllépnek ennek a vitának a határain. Az „végzetesség elve” megsértése súlyos kriptográfiai feltörésekhez vezet, mivel a protokoll pontosan úgy viselkedik, ahogy azt elvárnánk. Például vegyünk egy kitalált konstrukciót egy sebezhető helyettesítő titkosítással, majd bemutatjuk a lehetséges támadást. Noha már láttuk a helyettesítő titkosítást érő támadást frekvencia analízis révén, ez nem csupán „egy másik módja a titkosítás feltörésének”. Éppen ellenkezőleg, az orákulum támadások - sokkal modernebb találmányok, amelyek számos olyan helyzetre alkalmazhatók, amikor a frekvencia analízis kudarcot vall, és az ezt következő szakaszban ezt bemutatjuk. Itt egy egyszerű titkosítás csupán azért lett kiválasztva, hogy az példát érthetőbbé tegye.

Akkor hagyjuk is figyelmen kívül a puffertúlcsordulást, parancsinjekciót és hasonlókat; ezek kívül esnek ennek a vitának a határain. Az „végzetesség elve” megsértése súlyos kriptográfiai feltörésekhez vezet, mivel a protokoll pontosan úgy viselkedik, ahogy azt elvárnánk.

Például vegyünk egy kitalált konstrukciót egy sebezhető helyettesítő titkosítással, majd bemutatjuk a lehetséges támadást. Noha már láttuk a helyettesítő titkosítást érő támadást frekvencia analízis révén, ez nem csupán „egy másik módja a titkosítás feltörésének”. Éppen ellenkezőleg, az orákulum támadások - sokkal modernebb találmányok, amelyek számos olyan helyzetre alkalmazhatók, amikor a frekvencia analízis kudarcot vall, és ezt a következő szakaszban bemutatjuk. Itt egy egyszerű titkosítás csupán azért lett kiválasztva, hogy ezt az példát érthetőbbé tegye.

Tehát Alice és Bob egy egyszerű helyettesítő kóddal kommunikálnak, amelynek kulcsát csak ők ismerik. Nagyon szigorúan veszik az üzenetek hosszát: a hossza pontosan 20 karakter. Ezért megállapodtak abban, hogy ha valaki rövidebb üzenetet szeretne küldeni, akkor hamis szöveget kell hozzáadnia az üzenet végéhez, hogy pontosan 20 karakter legyen. Néhány megbeszélés után úgy döntöttek, hogy csak az alábbi hamis szövegeket fogadják el: a, bb, ccc, dddd stb. Így a szükséges hosszúságú hamis szöveg ismert.

Amikor Alice vagy Bob megkap egy üzenetet, először ellenőrzik, hogy az üzenet megfelelő hosszúságú-e (20 karakter), és hogy a suffix megfelelő hamis szöveg. Ha nem, válaszolnak a megfelelő hibajelzéssel. Ha a szöveg hossza és a hamis szöveg rendben van, a fogadó elolvassa magát az üzenetet, és elküldi a titkosított választ.

A támadás során a támadó Bobjának adja ki magát, és hamis üzeneteket küld Alice-nak. Az üzenetek teljes blődség – a támadónak nincs kulcsa, így nem képes értelmes üzenetet hamisítani. De mivel a protokoll megsérti a végérvényesség elvét, a támadó mégis csapdába tudja csalni Alicet, hogy elárulja a kulcsot, ahogyan az alább látható.

Hacker: PREWF ZHJKL MMMN. LA
Alice: Érvénytelen hamis szöveg.
Hacker: PREWF ZHJKL MMMN. LB
Alice: Érvénytelen hamis szöveg.
Hacker: PREWF ZHJKL MMMN. LC
Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

A támadó fogalma sincs róla, mit mondott Alice, de megjegyzi, hogy a karakter C meg kell feleljen a, mivel Alice elfogadta a hamis szöveget.

Hacker: REWF ZHJKL MMMN. LAA
Alice: Érvénytelen hamis szöveg.
Hacker: REWF ZHJKL MMMN. LBB
Alice: Érvénytelen hamis szöveg.
Több próbálkozás után...
Hacker: REWF ZHJKL MMMN. LGG
Alice: Érvénytelen hamis szöveg.
Hacker: REWF ZHJKL MMMN. LHH
Alice: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Ismételten, a támadónak fogalma sincs róla, mit mondott Alice, de megjegyzi, hogy H-nak b-vel kell párosulnia, mivel Alice elfogadta a hamis szöveget.

Így tovább, míg a támadó meg nem tudja minden karakter értékét.

Első pillantásra a módszer a kitalált szövegen alapuló támadásra emlékeztet. Végső soron a támadó titkosított szövegeket válogat, a szerver pedig engedelmesen feldolgozza őket. A fő különbség, ami élethűvé teszi ezeket a támadásokat a valós világban, az, hogy a támadónak nincs szüksége valódi dekódolásra - elegendő a szerver válasza, még a legártalmatlanabb is, mint például "Helytelen kitalált szöveg".

Bár ez a konkrét támadás tanulságos, nem szabad túlságosan a "kitalált szöveg" sémájának sajátosságaira, a használt kriptográfiai rendszerre vagy a támadó által küldött üzenetek pontos sorrendjére összpontosítani. Az alapgondolat az, hogy Alice hogyan reagál különbözően az üzenetek nyílt szövegének tulajdonságai alapján, anélkül, hogy ellenőrizné, hogy a megfelelő titkosított szöveg valóban a megbízható féltől származik-e. Így Alice lehetővé teszi a támadó számára, hogy titkos információkat csikarjon ki a válaszaiból.

Ebben a forgatókönyvben sok minden változhat. Az Alice által reagált karakterek, a viselkedésében tapasztalható különbségek, vagy akár a használt kriptográfiai rendszer is módosítható. De az elv ugyanaz marad, és a támadás összességében továbbra is életképes lesz valamilyen formában. E támadás alapvető megvalósítása segített néhány biztonsági hibát felfedezni, amelyeket hamarosan megvizsgálunk; de előbb néhány elméleti tanulságot le kell vonni. Hogyan lehet ezt a kitalált "Alice forgatókönyvet" olyan támadásban alkalmazni, amely képes működni egy modern titkosítási rendszerben? Ez egyáltalán lehetséges, még elméletben is?

1998-ban a svájci kriptográfus Daniel Bleichenbacher pozitívan válaszolt erre a kérdésre. Bemutatta az orákulum támadást egy széles körben használt RSA kulcskryptográfiai rendszerben, egy bizonyos üzenetküldési séma használatával. Egyes RSA megvalósításokban a szerver különböző hibaüzenetekkel reagál, attól függően, hogy a nyílt szöveg megfelel-e a sémának vagy sem; ez elég volt a támadás végrehajtásához.

Négy évvel később, 2002-ben, a francia kriptográfus, Serge Vaudenay bemutatta az oracle-támadást, amely majdnem azonos az előzőleg Alice forgatókönyvében leírtal, kivéve, hogy a kitalált titkosítás helyett egy teljesen elfogadható modern titkosítási osztályt tört fel, amelyet az emberek valóban használnak. Különösen a Vaudenay-támadás a rögzített bemeneti méretű titkosításokra („blokkszámítók”) összpontosít, amikor azokat a „CBC titkosítási módban” használják egy népszerű kitöltési sémával, alapvetően az Alice forgatókönyvében leírtakkal ekvivalens módon.

Ugyanebben az évben az amerikai kriptográfus, John Kelsey – társszerző Twofish – különböző oracle-támadásokat javasolt olyan rendszerek ellen, amelyek tömörítik az üzeneteket, majd titkosítják őket. A legszembetűnőbb ezek közül az a támadás volt, amely kihasználta, hogy gyakran ki lehet következtetni a nyílt szöveg eredeti hosszát a titkosított szöveg hosszából. Elméletileg ez lehetővé teszi egy oracle-támadás lefolytatását, amely visszaállítja a nyílt szöveg részeit.

Ezután részletesebb leírást adunk a Vaudenay és Kelsey támadásokról (a Blachenkbacher támadás részletesebb leírását a nyílt kulcsú kriptográfia támadásai felé haladva adjuk meg). Minden erőfeszítésünk ellenére a szöveg kissé technikussá válik; így ha az eddigiek elegendőek önnek, ugorja át a következő két részt.

Vaudenay támadása

A Vaudenay támadásának megértéséhez először egy kicsit részletesebben kell beszélnünk a blokkszámítóról és a titkosítási módokról. A „blokkszámító” - ahogy már említettük - egy titkosítás, amely kulcsot és adott fix hosszúságú bemenetet („blokk hossza”) vesz fel, és a titkosított blokkot ugyanakkora hosszúságban adja ki. A blokkszámítók széles körben használatosak és viszonylag biztonságosnak számítanak. A nyugdíjba vonult DES, amelyet az első modern titkosításnak tartanak, blokkszámító volt. Ahogy már említettük, ugyanez igaz az AES-re, amely ma széles körben használt.

Sajnos, a blokkos titkosításnak van egy nyilvánvaló gyengesége. A tipikus blokk mérete 128 bit, vagyis 16 karakter. Nyilvánvaló, hogy a modern kriptográfia nagyobb méretű bemeneti adatokkal dolgozik, és itt lépnek életbe a titkosítási módok. A titkosítási mód lényegében egy hack: ez egy mód arra, hogy a blokkos titkosítást, amely csak adott méretű bemeneti adatokat fogad el, valamilyen módon alkalmazzuk változó hosszúságú bemeneti adatokra.

A Vodene támadás a népszerű CBC (Cipher Block Chaining, blokk titkosító láncolás) üzemmódra irányul. A támadás a blokk titkosítót varázslatos, hozzáférhetetlen fekete dobozként kezeli, és teljesen megkerüli a biztonságát.

Itt van egy diagram, amely bemutatja, hogyan működik a CBC mód:

A keretezett plusz az XOR műveletet (kizáró «VAGY») jelenti. Például a második titkosított blokk a következőképpen nyerhető el:

Az első titkosított blokk és a második nyílt szöveg blokk XOR műveletének elvégzésével.
A kapott blokk titkosítása a blokkos titkosítóval, kulcs használatával.

Mivel a CBC intenzíven használja az XOR bináris műveletet, hasznos lehet, ha megemlékezünk néhány tulajdonságáról:

Idempotencia:
Kommutativitás:
Associativitás:
Inverzibilitás:
Bájt szinten: n. bájt = (n. bájt ) (n. bájt )

Általában ezek a tulajdonságok azt sugallják, hogy ha van egy egyenlet, amely XOR műveleteket és egy ismeretlent tartalmaz, azt meg lehet oldani. Például, ha tudjuk, hogy ismeretlennel és ismertekkel és , akkor a fent említett tulajdonságokra támaszkodva megoldhatjuk az egyenletet . Ha mindkét oldalon XOR műveletet alkalmazunk az egyenleten , akkor megkapjuk . Egy pillanat múlva mindez nagyon aktuális lesz.

Az Alice forgatókönyvünk és a Vodene támadás között két lényegtelen különbség és egy fő különbség van. Két lényegtelen:

Az Alice forgatókönyvben vártuk, hogy a nyílt szövegek a karakterekkel záruljanak a, bb, ccc és így tovább. A Vodene támadás során az áldozat ehelyett azt várja, hogy a nyílt szövegek N-szer N bájt (vagyis hexadecimálisan 01 vagy 02 02, vagy 03 03 03 és így tovább) bónuszra záruljanak. Ez csupán kozmetikai különbség.
Az Alice forgatókönyvében könnyű volt megmondani, hogy Alice elfogadta-e az üzenetet, a „Hibás helyettesítő szöveg” válasz alapján. A Vodené támadásnál nagyobb elemzésre van szükség, és fontos a pontos végrehajtás az áldozat oldalán; de a tömörség kedvéért tegyük fel, hogy ez az elemzés még mindig lehetséges.

A legfontosabb különbség:

Mivel nem ugyanazt a kriptos rendszert használjuk, a támadó által irányított titkosított szöveg bytes és a titkok (kulcs és világos szöveg) közötti kapcsolat nyilvánvalóan más lesz. Ezért a támadónak más stratégiát kell használnia a titkosítványok létrehozásához és a szerver válaszainak értelmezéséhez.

Ez a legfontosabb különbség — az utolsó darab a Vodené támadás megértéséhez, ezért egy pillanatra gondoljunk arra, hogy miért és hogyan lehet egyáltalán szervezni egy oracle támadást a CBC-n.

Tegyük fel, hogy adott egy 247 blokk hosszú CBC titkos szöveg, és szeretnénk azt visszafejteni. Hamis üzeneteket küldhetünk a szervernek, ahogy korábban Alice-nak is küldhettünk. A szerver dekódolja az üzeneteket számunkra, de nem mutatja meg a dekódolást – helyette, mint Alice esetében, a szerver csak egy bit információt ad: a világos szövegnek érvényes kitöltése van-e vagy sem.

Vegyük figyelembe, hogy Alice forgatókönyvében a következő kapcsolatok voltak:

$$display$$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key}) = text{plaintext}$$display$$

Hívjuk ezt „Alice egyenletének”. Mi irányítottuk a titkos szöveget; a szerver (Alice) elmosódott információt adott a megkapott világos szövegről; és ez lehetővé tette számunkra, hogy információt szűrjünk ki az utolsó tényezőről — a kulcsról. Hasonlóan, ha megtaláljuk ezt a kapcsolatot a CBC forgatókönyvnél, akkor ott is ki tudnánk nyerni némi titkos információt.

Szerencsére ott valóban léteznek kapcsolatok, amelyeket felhasználhatunk. Vizsgáljuk meg a blokk titkosító visszafejtési hívásának kimenetét, és jelöljük meg ezt az adatot, mint . Jelöljük meg a világos szöveg blokkjait és a titkos szöveg blokkjait . Nézze meg újra a CBC diagramot, és vegye észre, hogy mi jön létre:

Hívjuk ezt „CBC egyenletének”.

Alice forgatókönyvében, miközben a titkosított szöveget ellenőrizzük és figyeljük az ezzel kapcsolatos nyílt szöveg szivárgását, sikerült megszerveznünk egy támadást, amely helyreállította az egyenlet harmadik tagját – a kulcsot. A CBC forgatókönyvben szintén ellenőrizzük a titkosított szöveget és megfigyeljük az ezzel kapcsolatos nyílt szöveg szivárgását. Ha a hasonlóság helytálló, információt szerezhetünk arról, .

Tegyük fel, hogy tényleg helyreállítottuk , mi következik ezután? Nos, akkor azonnal ki tudjuk nyeremelni az utolsó blokkját a nyílt szövegnek (), egyszerűen csak beírva (amely már rendelkezésünkre áll) és
a megszerzett az CBC egyenletben.

Tehát optimisták vagyunk a támadás általános terve miatt, és itt az idő, hogy kidolgozzuk a részleteket. Figyeljen arra, hogy a szerveren pontosan hogyan szivárog az információ a nyílt szövegről. Alice forgatókönyvében a szivárgás azért következett be, mert Alice csak akkor adott helyes választ, ha a $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ egy stringgel zárult le, a SysWOW64 bb, és így tovább, de az esélye annak, hogy ezek a feltételek véletlenül teljesüljenek, nagyon kicsi volt). Hasonlóan a CBC-hez, a szerver csak akkor fogadja el a kitöltést, ha hexadecimális 01végződik. Tehát próbáljuk meg ugyanazt a trükköt: hamis titkosított üzenetek küldését a saját hamis értékeinkkel, , amíg a szerver el nem fogadja a kitöltést.

Amikor a szerver elfogad egy kitöltést az egyik hamis üzenetünkből, az azt jelenti, hogy:

Most használjuk az XOR byte-tulajdonságát:

Tudjuk az első és harmadik tagot. És már láttuk, hogy ez lehetővé teszi a maradék tag, a legutolsó byte helyreállítását, :

Ez szintén megadja nekünk az utolsó byte-ot a végső nyílt szöveg blokkban a CBC egyenlet és a byte-tulajdonság révén.

Befejezhetnénk itt, és megelégedhetnénk azzal, hogy támadást hajtottunk végre egy elméletileg ellenálló titkosítás ellen. De valójában sokkal többet tehetünk: valójában teljesen helyreállíthatjuk a szöveget. Ehhez szükség van egy bizonyos trükkre, amely nem szerepelt az Alice eredeti forgatókönyvében, és nem része a jósdai támadás kötelező kritériumainak, de a módszer mégis megér egy tanulmányozást.

Ahhoz, hogy ezt megértsük, először figyelje meg, hogy a legutolsó byte helyes értékének kiemelése során az alábbiak következnek. Jó hírünk van! Mostantól a titkosított szövegek hamisítása során képesek vagyunk kezelni a megfelelő nyers szöveg utolsó byte-ját. Ez ismét a CBC egyenlettel és a byte-alapú tulajdonsággal kapcsolatos:

Mivel most már ismerjük a második tagot, felhasználhatjuk az elsőnket a harmadik kezelésére. Egyszerűen kiszámítjuk:

Korábban ezt nem tudtuk megtenni, mert még nem volt meg az utolsó byte-unk. .

Hogyan segít ez nekünk? Tegyük fel, hogy mostantól minden titkosított szöveget úgy készítünk, hogy a megfelelő nyers szövegek utolsó byte-ja egyenlő 02. Most a szerver csak akkor fogadja el a kitöltést, ha a nyers szöveg a következőkkel végződik: 02 02. Mivel javítottuk az utolsó byte-ot, ez csak akkor fog bekövetkezni, ha az előző byte is egyenlő 02-vel. Folytatjuk hamis titkosított blokkok küldését, változtatva az előző byte-on, amíg a szerver el nem fogadja a kitöltést egyikük számára. Ekkor megkapjuk:

És visszaállítjuk az előző byte-ot pontosan úgy, ahogyan az utolsót is visszaállítottuk. Folytatjuk ugyanebben a szellemben: korrigáljuk a nyers szöveg utolsó két byte-ját 03 03, megismételjük ezt a támadást a harmadik byte-ra az utolsó előtt, és így tovább, végül teljesen helyreállítva .

Mi a helyzet a többi szöveggel? Vegyük észre, hogy a valójában $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Bármilyen más blokkot beletehetünk a helyére, és a támadás így is sikeres lesz. Valójában kérhetjük a szervert, hogy végezzen $inline$text{BLOCK_DECRYPT}$inline$ bármely adat esetén. Ekkor a játék véget ér - képesek vagyunk bármilyen titkosított szöveget visszafejteni (nézze meg újra a CBC visszafejtési diagramját, hogy megbizonyosodjon erről; és vegye figyelembe, hogy az IV vektor nyilvános).

Ez a konkrét módszer kulcsszerepet játszik az orákulumtámadásban, amellyel később találkozunk.

Kelsey támadása

A velünk szellemileg hasonló John Kelsey a lehetséges támadások mögött álló elveket fogalmazta meg, nem csupán egy adott titkosítási forma konkrét támadásának részleteit. Az ő 2002-es cikkének kutatása a titkosított tömörített adatokra vonatkozó lehetséges támadásokat tárgyalja. Azt hitte, hogy a támadáshoz nem elegendő csak annyi információ, hogy az adatok tömörítve voltak a titkosítás előtt? Kiderült, hogy ez elegendő.

Ez a lenyűgöző eredmény két elvnek köszönhető. Először is, erős korreláció van a nyílt szöveg hossza és a titkosított szöveg hossza között; sok titkosítás esetében ezek pontosan egyeznek. Másodszor, amikor tömörítést végzünk, erős korreláció figyelhető meg a tömörített üzenet hossza és a nyílt szöveg "zajossága" között, vagyis a nem ismétlődő karakterek arányában (technikai kifejezés - "nagy entrópia").

A jelenség működésének láttatásához nézzük meg a következő két nyílt szöveget:

Nyílt szöveg 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Nyílt szöveg 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Tegyük fel, hogy mindkét nyílt szöveget tömörítették, majd titkosították. Két eredményül kapott titkosított szöveget kapunk, és meg kell tippelned, hogy melyik titkosított szöveg melyik nyílt szöveghez tartozik:

Titkosított szöveg 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA
Titkosított szöveg 2: DWKJZXYU

A válasz világos. A nyílt szövegek között csak az 1. nyílt szöveg volt képes a második titkosított szöveg csekély hosszúságára tömörülni. Ezt megállapítottuk anélkül, hogy tudtunk volna a tömörítési algoritmusról, a titkosításhoz használt kulcsról vagy akár magáról a titkosításról. A lehetséges kriptográfiai támadások hierarchiájához képest ez egyfajta őrület.

Kelsey továbbá rámutat, hogy bizonyos szokatlan körülmények között ez az elv használható egy oracle támadás lefolytatására is. Különösen azt írja le, hogyan tud egy támadó helyreállítani egy titkos nyílt szöveget, ha rá tudja bírni a szervert, hogy formázott adatokat titkosítson (nyílt szöveg következik , miközben ő irányítja és valahogyan ellenőrizheti a titkosított eredmény hosszát.

Ismét, mint más oracle támadásoknál, itt is van egy arány:

Ismét csak egy tagot irányítunk (), látunk egy kis információ szivárgást a másik tagnál (titkosított szöveg) és megpróbáljuk helyreállítani az utóbbit (nyílt szöveg). A hasonlóság ellenére ez egy kicsit szokatlan helyzet más oracle támadásokhoz képest, amelyeket láttunk.

Azt illusztrálva, hogyan működhet egy ilyen támadás, használjunk egy kitalált tömörítési sémát, amelyet most találtunk ki: TOYZIP. Ez olyan szövegstratégákat keres, amelyek korábban már megjelentek a szövegben, és három kitöltő bájtban helyettesíti őket, amelyek jelzik, hol található a szöveg korábbi példánya, és hányszor fordul elő ott. Például, a szöveg helloworldhello összenyomható helloworld[00][00][05] az eredeti 15 bájt helyett 13 bájt hosszú.

Tegyük fel, hogy a támadó megpróbálja visszaállítani a formátum nyílt szövegét jelszó=..., ahol a jelszó magáról a jelszóról ismeretlen. Kelsey támadási modellje szerint a támadó kérheti a szervert, hogy tömörítse, majd titkosítsa a formátum üzeneteit (nyílt szöveg, amelyet követ ), ahol — tetszőleges szöveg. Amikor a szerver befejezte a feldolgozást, jelentést tesz a kimenet hosszáról. A támadás a következőképpen zajlik:

Hacker: Kérlek, tömörítsd és titkosítsd a nyílt szöveget bármiféle kitöltés nélkül.
Szerver: A kimenet hossza 14.
Hacker: Kérlek, tömörítsd és titkosítsd a nyílt szöveget, amelyhez hozzáadtad jelszó=a.
Szerver: A kimenet hossza 18.

A támadó megjegyzi: [eredeti 14] + [három bájt, amely helyettesítette jelszó=] + a

Hacker: Kérlek, tömörítsd és titkosítsd a nyílt szöveget, amelyhez hozzáadtad jelszó=b.
Szerver: A kimenet hossza 18.
Hacker: Kérlek, tömörítsd és titkosítsd a nyílt szöveget, amelyhez hozzáadtad jelszó=c.
Szerver: A kimenet hossza 17.

A támadó megjegyzi: [eredeti 14] + [három bájt, amely helyettesítette jelszó=c]. Ez azt jelenti, hogy az eredeti nyílt szöveg egy sorozatot tartalmaz jelszó=c. Azt jelenti, hogy a jelszó egy mássalhangzóval kezdődik c

Hacker: Kérlek, tömörítsd és titkosítsd a nyílt szöveget, amelyhez hozzáadtad jelszó=ca.
Szerver: A kimenet hossza 18.

A támadó megjegyzi: [eredeti 14] + [három bájt, amely helyettesítette jelszó=c] + a

Hacker: Kérlek, tömörítsd és titkosítsd a nyílt szöveget, amelyhez hozzáadtad jelszó=cb.
Szerver: A kimenet hossza 18.

(… egy idő után…)

Hacker: Kérlek, tömörítsd és titkosítsd a nyílt szöveget, amelyhez hozzáadtad jelszó=co.
Szerver: A kimenet hossza 17.

A támadó megjegyzi: [eredeti 14] + [három bájt, amely helyettesítette jelszó=co]. Ugyanezen logika szerint a támadó arra a következtetésre jut, hogy a jelszó mássalhangzókkal kezdődik co

És így tovább, amíg az összes jelszót vissza nem állítják.

Az olvasó számára érthető, hogy ezt pusztán akademikus feladatnak tartja, és hogy egy ilyen támadási forgatókönyv soha nem történhet meg a valóságban. Sajnos, ahogy hamarosan látni fogjuk, a kriptográfiában jobb nem elképzelni.

Márkás sebezhetőségek: CRIME, POODLE, DROWN

Végül, miután részletesen megvizsgáltuk az elméletet, megnézhetjük, hogyan alkalmazzák ezeket a módszereket valós kriptográfiai támadásokban.

CRIME

Ha a támadás a böngészőre és az áldozat hálózatára irányul, valami könnyebb, míg valami nehezebb lesz. Például az áldozat forgalmának látása könnyű: elég egy kávézóban ülnöd vele, ahol WiFi van. Ezért a lehetséges áldozatoknak (azaz mindenkinek) általában azt javasolják, hogy használjanak titkosított kapcsolatot. Nehezebb lesz, de még mindig lehetséges, ha HTTP-kéréseket indítanak az áldozat nevében egy harmadik fél weboldalra (pl. Google). A támadó becsalogathatja az áldozatot egy kártékony weboldalra egy olyan szkripttel, amely kérdést intéz. A webböngésző automatikusan megadja a megfelelő munkamenet cookie-t.

Ez meglepőnek tűnik. Ha Bob látogatott el a evil.com, vajon lehetséges, hogy a weboldalon található script egyszerűen megkérje a Google-t, hogy küldje el Bob jelszavát e-mailben a attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Kereszt-site kéréseket hamisító támadás, CSRF), és ez körülbelül az 1990-es évek közepén volt népszerű. Ma, ha evil.com valaki megpróbálna ilyen trükköt, a Google (vagy bármelyik tisztességes weboldal) általában azt válaszolja: „Kiváló, de a tranzakcióhoz tartozó CSRF tokened… ööö… három trillió és hét. Kérlek, ismételd meg ezt a számot.” A mai böngészők olyan rendszert alkalmaznak, amelyet 'azonos eredetű politika' (same-origin policy) néven ismerünk, amely szerint az A weboldalon található script nem férhet hozzá a B weboldal által küldött információkhoz. Ezért a script a evil.com tud küldeni kéréseket a mrkaran.dev, de nem olvashatja el a válaszokat, vagy valójában nem tudja befejezni a tranzakciót.

Hangsúlyozni kell, hogy ha Bob nem titkosított kapcsolatot használ, akkor mindez a védelem értelmetlen. A támadó egyszerűen olvashatja Bob forgalmát, és visszaállíthatja a Google munkameneti sütijét. Ezzel a sütivel egyszerűen megnyithat egy új Google fület anélkül, hogy kijelentkezne a saját böngészőjéből, és Bobnak adja ki magát, elkerülve az idegesítő azonos eredetű politikát. De sajnos a támadóknak egyre ritkábban sikerül ilyet végrehajtaniuk. Az internet már régóta megkezdte a háborút a nem titkosított kapcsolatokkal szemben, és Bob kimenő forgalma valószínűleg titkosítva van, tetszik neki, vagy sem. Ezenkívül a protokoll bevezetésének kezdetén a forgalmat is tömörítették a titkosítás előtt; ez általános gyakorlat volt a késleltetés csökkentése érdekében.

Itt lép be a CRIME (Compression Ratio Infoleak Made Easy, az egyszerű kiáramlás a tömörítési arányon keresztül). Egy olyan sebezhetőség, amelyet 2012 szeptemberében fedezett fel a biztonsági kutató, Giuliano Rizzo és Thai Duong. Már áttekintettük mindazt az elméleti hátteret, amely lehetővé teszi, hogy megértsük, mit tettek és hogyan. A támadó rá tudja venni Bob böngészőjét, hogy kéréseket küldjön a Google-hoz, majd figyelje a válaszokat a helyi hálózaton titkosított, tömörített formában. Ezért nálunk van:

Itt a támadó ellenőrzi a kérést, és hozzáféréssel rendelkezik a forgalomelemzőhöz, beleértve a csomagok méretét. A Kelsey által elképzelt forgatókönyv valósággá vált.

A megértett elmélettel a CRIME szerzői létrehoztak egy exploitot, amely képes ellopni a munkameneti cookie-kat számos webhelyről, beleértve a Gmailt, a Twittert, a Dropboxot és a Githubot. A sebezhetőség a legtöbb modern böngészőt érintette, és ennek következtében javításokat adtak ki, amelyek csendben eltemették az SSL tömörítési funkcióját, hogy az egyáltalán ne használható legyen. Az egyetlen sebezhetőség ellen védett böngésző a tiszteletre méltó Internet Explorer lett, amely egyáltalán sosem használta az SSL tömörítést.

POODLE

2014 októberében a Google biztonsági csapata nagy feltűnést keltett a biztonsági közösség körében. Képesek voltak kihasználni egy SSL protokollban lévő sebezhetőséget, amelyet több mint tíz évvel ezelőtt már javítottak.

Kiderült, hogy bár a szervereken fantasztikus új TLSv1.2 fut, sokan az elavult SSLv3 támogatását hagyták meg az Internet Explorer 6 visszafelé kompatibilitása miatt. Már beszéltünk a visszafejlesztési támadásokról, így el tudjátok képzelni, mi történik. Egy jól szervezett szabotázs a kézfogás protokoll ellen - és a szerverek készen állnak, hogy visszatérjenek a régi jó SSLv3-hoz, lényegében felmondva az elmúlt 15 év biztonsági kutatásának eredményeit.

A történelmi kontextus érdekében, itt egy rövid összefoglaló az SSL történetéről egészen a 2. verzióig Matthew Green tollából:

A Transport Layer Security (TLS) az internet legfontosabb biztonsági protokollja. [..] Gyakorlatilag minden tranzakció, amelyet az interneten végrehajt, a TLS-től függ. [..] De a TLS nem mindig volt TLS. A protokoll pályafutása Netscape Communications néven „Secure Sockets Layer” vagy SSL indult. Pletykák szerint az első SSL verzió annyira borzalmas volt, hogy a fejlesztők összegyűjtötték az összes kódnyomtatványt és elásták egy titkos helyszínre Új-Mexikóban. Ennek következtében az első nyilvános SSL verzió valójában a 2-es verzió volt. Eléggé rémisztő, és [..] ez a 90-es évek közepének terméke, amelyet a modern kriptográfusok „a kriptográfia sötét középkoránaktekintenek. Sok olyan borzalmas kriptográfiai támadás, amelyet ma ismerünk, még nem volt felfedezve. Ennek következtében az SSLv2 protokoll fejlesztőinek lényegében tapogatózniuk kellett a sötétben, és számos szörnyeteggel találkoztak, amelyek kétségtelenül szomorúságot okoztak nekik, de nekünk hasznot hajtottak, mivel az SSLv2 ellen irányuló támadások felbecsülhetetlen leckéket hagytak a következő protokollgenerációnak. — sajnos a mi javunkra és az ő bánatukra, mivel az SSLv2 elleni támadások felbecsülhetetlen leckéket hagytak a következő protokollgeneráció számára.

Ezek után, 1996-ban a Netscape csalódottan újra létrehozta az SSL protokollt a nulláról. Az eredmény a 3-as verziójú SSL lett, amely javította az elődje néhány ismert biztonsági problémáját.

Szerencsére a hackerek számára a „néhány” nem jelenti azt, hogy „minden”. Összességében az SSLv3 minden szükséges építőelemet biztosított a Védené támadás végrehajtásához. A protokoll blokk titkosító algoritmust használt CBC módban és egy biztonságos megoldási séma, amit a TLS javított; így szükség volt a hátralépő támadásra. Ha emlékszik a Védené támadásunk kezdeti leírásában szereplő megoldási séma, az SSLv3 megoldási sémája nagyon hasonló.

Sajnos a hackerek számára a „hasonló” nem jelenti azt, hogy „azonos”. Az SSLv3 megoldási sémája „N véletlenszerű bájt, amit követ egy N szám” formájú. Próbálja meg ilyen körülmények között kiválasztani a képzelt titkosított szöveg blokkot, és végigmenni az eredeti Védené séma minden lépésén: azt fogja felfedezni, hogy a támadás sikeresen kinyeri az utolsó bájtot a megfelelő nyílt szövegből, de nem megy tovább. A titkosított szöveg minden 16. bájtjának visszafejtése nagyszerű mutatvány, de nem győzelem.

A kudarcot látva a Google csapata a végső megoldáshoz folyamodott: egy erősebb fenyegetésmodellt használtak — azt, amelyet a CRIME esetén használtak. Ha feltételezzük, hogy a támadó egy áldozat böngészőjének lapján futó szkript, és ki tudja nyerni a munkamenetek cookie-it, a támadás még mindig lenyűgöző. Bár a szélesebb fenyegetésmodell kevésbé reális, de az előző szakaszban már láttuk, hogy ez a konkrét modell végrehajtható.

Figyelembe véve a hacker ilyen nagyobb lehetőségeit, a támadás most folytatódhat. Ne feledje, hogy a támadó tudja, hol jelenik meg a titkosított munkamenet cookie fájl a fejlécben, és irányítja az azt megelőző HTTP kérelem hosszát. Ezért képes manipulálni a HTTP kérelmet úgy, hogy az utolsó byte a cookie-ban a blokkok végével legyen összhangban. Most ez a byte alkalmas a visszafejtésre. Egyszerűen hozzáadhatunk egy karaktert a kéréshez, és a cookie előző byte-ja ugyanott marad, és ugyanezen módszerrel továbbra is alkalmas a próbálkozásra. A támadás így folytatódik, míg a cookie fájl teljesen vissza nem áll. Ezt hívják POODLE-nek: Padding Oracle on Downgraded Legacy Encryption, a csökkentett, elavult titkosításon végzett padding oracle támadás.

DROWN

Ahogyan már említettük, az SSLv3-nak voltak hiányosságai, de alapvetően különbözött az elődjétől, mivel a lyukas SSLv2 egy másik korszak terméke volt. Ott lehetett megszakítani az üzenetet a közepén: nem fogadom el ezt csak a holttestem felett átalakult elfogadom ezt; az ügyfél és a szerver találkozhattak az interneten, megbízhatóságot állíthattak fel és titkokat cserélhettek egy támadó szeme előtt, aki könnyedén tettethette magát mindkét félként. Még a problémát is említjük az exporttitkosítással kapcsolatban, amelyet a FREAK vizsgálatakor említettünk. Ez volt a kriptográfiai Sodom és Gomorrah.

2016 márciusában különböző technikai területek kutatói csapata gyűlt össze, és lenyűgöző felfedezést tett: az SSLv2-t még mindig használják a biztonsági rendszerekben. Igen, a támadók már nem tudták csökkenteni a modern TLS munkameneteket SSLv2-re, mivel ezt a lyukat a FREAK és a POODLE után betöltötték, de még mindig képesek csatlakozni a szerverekhez, és saját maguk kezdeményezni SSLv2 munkameneteket.

Megkérdezheti, mi közünk van ahhoz, amit ott csinálnak? Van egy sebezhető munkamenetük, de ennek nem kellene befolyásolnia más munkameneteket vagy a szerver biztonságát - igaz? Nos, nem egészen. Igen, elméletben így kellene lennie. De nem - mivel az SSL tanúsítványok generálása bizonyos terhet ró rá, ami miatt sok szerver ugyanazokat a tanúsítványokat és következésképpen ugyanazokat az RSA kulcsokat használja a TLS és SSLv2 kapcsolatokhoz. Még rosszabb, hogy a népszerű SSL megvalósításban található OpenSSL hiba miatt a "SSLv2 letiltása" opció gyakorlatilag nem működött.

Ez lehetővé tette a TLS cross-protokoll támadását, amit így neveztek DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, RSA dekódolás elavult és legyengített titkosítással). Emlékeztetünk arra, hogy ez nem ugyanaz, mint a downgrade támadás; a támadónak nem kell „középen lévő emberként” cselekednie, és nem kell bevonnia az ügyfelet egy nem biztonságos munkamenetbe. A rosszindulatú programok egyszerűen egyedül kezdeményezik a nem biztonságos SSLv2 munkamenetet a szerverrel, támadják meg a gyenge protokollt, és visszaállítják a titkos RSA szerver kulcsot. Ez a kulcs a TLS kapcsolatokra is érvényes, és ettől kezdve semmilyen TLS biztonság nem menti meg a feltöréstől.

De a feltöréshez működő támadásra van szükség az SSLv2 ellen, amely lehetővé teszi nemcsak a konkrét forgalom, hanem a titkos RSA szerver kulcs visszaállítását is. Noha ez nehéz feladat, a kutatók bármilyen, az SSLv2 után teljesen lezárt sebezhetőséget választhattak. Végül megtalálták a megfelelő lehetőséget: a korábban említett Bleichenbacher támadást, amelyet a következő cikkben részletesen elmagyarázunk. Az SSL és TLS védett ez ellen a támadás ellen, de bizonyos véletlenszerű SSL funkciók, rövid kulcsokkal kombinálva az exportosztályú titkosításban, lehetővé tették egy bizonyos DROWN megvalósítást.

A DROWN sebezhetőségek közzétételének időpontjában az internet legjobb webhelyeinek 25%-a volt érintve, és a támadást szerény erőforrásokkal lehetett végrehajtani, amelyek akár egyedüli hakerek számára is elérhetők voltak. Az RSA szerver kulcsának kiaknázásához nyolc órás számítási idő és 440 dollár szükséges, az SSLv2 státusza pedig „elavult”-ról „radioaktív”-ra változott.

Várj, mi a helyzet a Heartbleed-del?

Ez nem titkosító támadás abban az értelemben, ahogy az előbbiekben leírtuk; ez egy puffer túlfolyás.

Tartsunk szünetet

Néhány alapvető módszerrel kezdtünk: brute force, interpoláció, downgrade, cross-protokoll és előre számítások. Aztán megnéztük egy fejlett technikát, amely talán a modern kriptográfiai támadások fő összetevője: ez az oracle támadás. Eléggé elmélyültünk benne - és megértettük nemcsak az alapelvét, hanem két konkrét megvalósítás technikai részleteit is: a Wiener's támadás a CBC titkosítási mód és a Kelsey támadása a tömörített előkészítő titkosítási protokollok ellen.

A gyengítő támadások áttekintése során először is összefoglaltuk a FREAK támadást, amely mindkét módszert alkalmazza, mivel a célzott webhelyek gyenge kulcsokra csökkentik a biztonságot, majd újra felhasználják ugyanazokat a kulcsokat. A következő cikkhez a Logjam támadást hagytuk, amely szintén a nyilvános kulcs algoritmusaira céloz.

Ezután még három példa alkalmazását vizsgáltuk meg ezekre az elvekre. Először is, a CRIME és POODLE: két támadás, amelyek a támadó képességére támaszkodtak, hogy szabad tartalmat injektáljon a célzott szöveg mellé, majd tanulmányozza a szerver válaszait és majd, az oracle támadási módszertant alkalmazva ezt a szűk információt részleges értelemben visszaállítsa a nyilvános szövegre. A CRIME az SSL tömörítési támadás Kelsey-féle verzióját követte, míg a POODLE ehelyett ugyanazt a hatást keltette a CBC módosított változatának támadásával.

Ezután a DROWN kereszttámadásra összpontosítottunk, amely egy elavult SSLv2 protokollon keresztül hoz létre kapcsolatot a szerverrel, majd a Bleichenbacher támadással visszaállítja a titkos szerver kulcsokat. Eddig kihagytuk ennek a támadásnak a műszaki részleteit; ahogyan a Logjam esetében is, ennek is várnia kell, amíg alaposan meg nem vizsgáljuk a nyilvános kulcsos kriptográfiai rendszereket és azok sebezhetőségeit.

A következő cikkben a fejlett támadásokról beszélünk – mint például a meet-in-the-middle módszer, a differenciális kriptoanalízis és a születésnapi támadás. Rövid kitérőt teszünk a mellékcsatorna támadásokra, majd áttérünk a legizgalmasabb részre – a nyilvános kulcsos kriptográfiai rendszerekre.

Forrás: habr.com