Amikor meghallja a „kriptográfia” szót, egyesek emlékeznek a WiFi jelszavukra, a kedvenc webhelyük címe melletti zöld lakatra, és arra, hogy milyen nehéz valaki más e-mailjébe bejutni. Mások egy sor sebezhetőséget idéznek fel az elmúlt években sokatmondó rövidítésekkel (DROWN, FREAK, POODLE...), stílusos logókkal és figyelmeztetéssel, hogy sürgősen frissítse böngészőjét.

A kriptográfia mindent lefed, de esszenciája egy másikban. A lényeg az, hogy finom határvonal van az egyszerű és az összetett között. Néhány dolgot könnyű megtenni, de nehéz újra összerakni, például egy tojást feltörni. Más dolgokat könnyű megtenni, de nehéz visszaszerezni, ha egy apró, fontos, kulcsfontosságú rész hiányzik: például kinyitni egy zárt ajtót, amikor a „döntő rész” a kulcs. A kriptográfia ezeket a helyzeteket és a gyakorlatban való felhasználásukat vizsgálja.

Az elmúlt években a kriptográfiai támadások gyűjteménye feltűnő logók állatkertjévé változott, tele tudományos közleményekből származó képletekkel, és általános borús érzést keltett, hogy minden elromlott. Valójában azonban sok támadás néhány általános elven alapul, és a képletek végtelen oldalain gyakran egyszerűen érthető ötletek születnek.

Ebben a cikksorozatban a kriptográfiai támadások különböző típusait fogjuk megvizsgálni, az alapelvekre helyezve a hangsúlyt. Általánosságban és nem pontosan ebben a sorrendben, de kitérünk a következőkre:

• Alapvető stratégiák: nyers erő, frekvenciaelemzés, interpoláció, leminősítés és keresztprotokollok.
• Márkajelzéssel ellátott sebezhetőségek: FREAK, BŰNÖZÉS, USZKRA, FULLÍTÁS, Logjam.
• Speciális stratégiák: orákulumtámadások (Vodenet-támadás, Kelsey-támadás); meet-in-the-middle módszer, születésnapi támadás, statisztikai torzítás (differenciális kriptoanalízis, integrál kriptoanalízis stb.).
• Oldalcsatornás támadások és közeli hozzátartozóik, hibaelemzési módszerek.
• A nyilvános kulcsú titkosítás elleni támadások: kockagyökér, adás, kapcsolódó üzenet, Coppersmith-támadás, Pohlig-Hellman algoritmus, számszita, Wiener-támadás, Bleichenbacher-támadás.

Ez a cikk a fenti anyagokkal foglalkozik Kelsey támadásáig.

Alapvető stratégiák

A következő támadások egyszerűek abból a szempontból, hogy szinte teljesen megmagyarázhatók különösebb technikai részletek nélkül. Magyarázzuk el az egyes támadástípusokat a legegyszerűbb kifejezésekkel, anélkül, hogy bonyolult példákba vagy speciális használati esetekbe mennénk.

E támadások egy része nagyrészt elavulttá vált, és évek óta nem alkalmazták őket. Mások régi idők, akik még a 21. században is rendszeresen besurrannak a gyanútlan kriptorendszer-fejlesztők elé. A modern kriptográfia korszaka úgy tekinthető, hogy az IBM DES megjelenésével kezdődött, amely az első titkosítás, amely ellenállt a listán szereplő összes támadásnak.

Egyszerű nyers erő

A titkosítási séma két részből áll: 1) a titkosítási funkció, amely egy kulccsal kombinált üzenetet (plaintext) vesz fel, majd létrehoz egy titkosított üzenetet - titkosított szöveget; 2) egy visszafejtő funkció, amely felveszi a rejtjelezett szöveget és a kulcsot, és egyszerű szöveget állít elő. Mind a titkosításnak, mind a visszafejtésnek könnyen kiszámíthatónak kell lennie a kulccsal, és nehéznek kell lennie nélküle.

Tegyük fel, hogy látjuk a rejtjelezett szöveget, és minden további információ nélkül megpróbáljuk visszafejteni (ezt csak titkosított szöveget használó támadásnak nevezzük). Ha valamilyen varázsütésre megtaláljuk a megfelelő kulcsot, könnyen ellenőrizhetjük, hogy valóban helyes-e, ha az eredmény ésszerű üzenet.

Vegye figyelembe, hogy itt két implicit feltevés van. Először is tudjuk, hogyan kell végrehajtani a visszafejtést, vagyis hogyan működik a kriptorendszer. Ez egy standard feltevés a kriptográfia tárgyalásakor. A titkosítás megvalósítási részleteinek elrejtése a támadók elől további biztonsági intézkedésnek tűnhet, de amint a támadó rájön ezekre a részletekre, ez a kiegészítő biztonság csendben és visszafordíthatatlanul elveszik. így Kerchhoff-elv: Az ellenség kezébe kerülő rendszer nem okozhat kellemetlenséget.

Másodszor, feltételezzük, hogy a helyes kulcs az egyetlen kulcs, amely ésszerű visszafejtéshez vezet. Ez is ésszerű feltételezés; akkor teljesül, ha a rejtjelezett szöveg sokkal hosszabb, mint a kulcs, és olvasható. Ez általában a való világban történik, kivéve hatalmas, nem praktikus kulcsok vagy egyéb trükköket, amelyeket jobb félretenni (ha nem tetszik, hogy kihagytuk a magyarázatot, kérjük, olvassa el a 3.8 tételt itt).

A fentiek ismeretében felmerül egy stratégia: minden lehetséges kulcsot ellenőrizni. Ezt brute force-nak hívják, és egy ilyen támadás garantáltan minden gyakorlati rejtjel ellen hat – végül is. Például a nyers erő elég a feltöréshez Caesar rejtjel, egy ősi titkosítás, ahol a kulcs az ábécé egy betűje, ami valamivel több mint 20 lehetséges kulcsot jelent.

Sajnos a kriptoanalitikusok számára a kulcsméret növelése jó védekezés a nyers erő ellen. A kulcsméret növekedésével a lehetséges kulcsok száma exponenciálisan növekszik. A modern kulcsméretekkel az egyszerű nyers erő alkalmazása teljesen kivitelezhetetlen. Hogy megértsük, mire gondolunk, vegyük a leggyorsabb ismert szuperszámítógépet 2019 közepén: Csúcstalálkozó az IBM-től, a csúcsteljesítmény körülbelül 1017 művelet másodpercenként. Ma a tipikus kulcshossz 128 bit, ami 2128 lehetséges kombinációt jelent. Az összes kulcs közötti kereséshez a Summit szuperszámítógépnek körülbelül 7800-szor annyi időre van szüksége, mint az Univerzum életkora.

A nyers erőt történelmi érdekességnek kell tekinteni? Egyáltalán nem: elengedhetetlen kelléke a kriptoanalízis szakácskönyvnek. Ritkán olyan gyengék a rejtjelek, hogy csak egy ügyes támadással, valamilyen fokú erőszak alkalmazása nélkül törik fel. Sok sikeres feltörés egy algoritmikus módszerrel először gyengíti a cél titkosítást, majd nyerserő támadást hajt végre.

Frekvenciaelemzés

A legtöbb szöveg nem halandzsa. Például az angol szövegekben sok „e” betű és „the” szócikk található; A bináris fájlokban sok nulla bájt található az információk között. A frekvenciaelemzés minden olyan támadás, amely ezt a tényt kihasználja.

A támadással szemben kiszolgáltatott titkosítás kanonikus példája az egyszerű helyettesítő rejtjel. Ebben a titkosításban a kulcs egy táblázat, amelyben az összes betű ki van cserélve. Például a „g” helyett „h”, az „o” helyett a j, így a „go” szóból „hj” lesz. Ezt a titkosítást nehéz nyers erővel végrehajtani, mert nagyon sok lehetséges keresési tábla létezik. Ha érdekli a matematika, az effektív kulcshossz körülbelül 88 bit: ez az
. De a frekvenciaelemzés általában gyorsan elvégzi a munkát.

Tekintsük a következő rejtjelezett szöveget egy egyszerű helyettesítő rejtjellel feldolgozva:

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

Óta Y gyakran előfordul, sok szó végén is, feltételesen 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árosít XD megismételve több szó elején. Különösen az XDeLe kombináció egyértelműen sugallja a szót these vagy there, tehát folytatjuk:

theLe ALe UGLe thWNKE WN HEAJeN ANF eALth DGLAtWG, mint AN ALe FleAUt GR WN OGQL ZDWBGEGZDO

Tételezzük fel továbbá azt L megfelel a r, A - a stb. Valószínűleg eltart majd néhány próbálkozásig, de egy teljes brute force támadással összehasonlítva ez a támadás pillanatok alatt visszaállítja az eredeti szöveget:

több dolog van a mennyben és a földön horatio, mint amennyiről a filozófiádban álmodoznak

Egyesek számára izgalmas hobbi az ilyen „kriptogramok” megoldása.

A frekvenciaelemzés gondolata alapvetőbb, mint amilyennek első pillantásra tűnik. És ez sokkal bonyolultabb rejtjelekre vonatkozik. A történelem során különféle rejtjeltervek próbáltak „polialfabetikus helyettesítés” segítségével ellensúlyozni egy ilyen támadást. Itt a titkosítási folyamat során a betűhelyettesítő táblázat összetett, de előre látható módon módosul, a kulcstól függően. Mindezeket a rejtjeleket nehéznek tartották egyszerre feltörni; és a szerény frekvenciaanalízis végül mindegyiket legyőzte.

A történelem legambiciózusabb többalfabetikus rejtjele, és valószínűleg a leghíresebb is, a második világháború Enigma-rejtje volt. Elődeihez képest viszonylag összetett volt, de sok kemény munka után brit kriptoanalitikusok frekvenciaanalízissel feltörték. Természetesen nem tudtak olyan elegáns támadást kidolgozni, mint amilyen a fent látható; össze kellett hasonlítaniuk a plaintext és a titkosított szöveg ismert párjait (az ún. "plaintext attack"), sőt az Enigma felhasználókat bizonyos üzenetek titkosítására és az eredmény elemzésére provokálva (a "választott nyílt szöveges támadás"). De ez nem könnyítette meg a legyőzött ellenséges seregek és az elsüllyesztett tengeralattjárók sorsát.

E diadal után a frekvenciaelemzés eltűnt a kriptoanalízis történetéből. A modern digitális korban a titkosításokat úgy tervezték, hogy bitekkel dolgozzanak, nem betűkkel. Ennél is fontosabb, hogy ezeket a rejtjeleket a később ismertté vált rejtjelek sötét felfogásával tervezték Schneier törvénye: Bárki létrehozhat olyan titkosítási algoritmust, amelyet ő maga nem tud feltörni. Ez nem elég a titkosítási rendszerhez úgy tűnt nehéz: hogy bebizonyítsa értékét, sok kriptoanalitikus kíméletlen biztonsági felülvizsgálaton kell átesnie, akik mindent megtesznek a titkosítás feltörésére.

Előzetes számítások

Vegyük a 200 000 lakosú Precom Heights hipotetikus városát. A város minden otthonában átlagosan 30 000 dollár értékű értéktárgy található, de legfeljebb 50 000 dollár értékben. A Precom biztonsági piacát az ACME Industries monopolizálja, amely a legendás Coyote™ osztályú ajtózárakat gyártja. Szakértői elemzések szerint egy Coyote-osztályú zárat csak egy nagyon összetett hipotetikus gép tud feltörni, amelynek elkészítéséhez körülbelül öt évre és 50 ezer dollár befektetésre van szükség. Biztonságos a város?

Valószínűleg nem. Végül egy meglehetősen ambiciózus bűnöző jelenik meg. Így fog érvelni: „Igen, nagy előzetes költségeket fogok viselni. Öt év türelmes várakozás és 50 000 dollár. De ha végeztem, hozzáférek a ennek a városnak minden gazdagsága. Ha jól játszom ki a kártyáimat, ez a befektetés sokszorosan megtérül.”

Ugyanez igaz a kriptográfiára is. Egy adott titkosítás elleni támadások kíméletlen költség-haszon elemzés tárgyát képezik. Ha az arány kedvező, a támadás nem következik be. Azok a támadások azonban, amelyek egyszerre sok potenciális áldozat ellen dolgoznak, szinte mindig kifizetődőek, ebben az esetben a legjobb tervezési gyakorlat az, ha feltételezzük, hogy az első naptól kezdve indultak. Lényegében megvan a Murphy-törvény kriptográfiai változata: "Bármi, ami ténylegesen megtörheti a rendszert, összetöri a rendszert."

A legegyszerűbb példa egy előre számítási támadásnak kitett kriptorendszerre az állandó kulcs nélküli titkosítás. Ez volt a helyzet vele Caesar titkosírása, amely egyszerűen három betűvel előre tolja az ábécé minden betűjét (a táblázat hurkolt, így az ábécé utolsó betűje harmadikként van titkosítva). Itt ismét a Kerchhoff-elv lép életbe: ha egyszer egy rendszert feltörnek, akkor örökre feltörik.

A koncepció egyszerű. Még egy kezdő kriptorendszer-fejlesztő is valószínűleg felismeri a fenyegetést, és ennek megfelelően felkészül. A kriptográfia fejlődését tekintve az ilyen támadások nem voltak megfelelőek a legtöbb rejtjel számára, a Caesar-rejtjel első továbbfejlesztett változataitól a többalfabetikus rejtjelek hanyatlásáig. Az ilyen támadások csak a kriptográfia modern korszakának eljövetelével tértek vissza.

Ez a megtérülés két tényezőnek köszönhető. Először is végre megjelentek a kellően összetett kriptorendszerek, ahol a hackelés utáni kihasználás lehetősége nem volt nyilvánvaló. Másodszor, a kriptográfia annyira elterjedt, hogy laikusok milliói hoznak minden nap döntést arról, hogy a kriptográfia hol és mely részeit használják fel újra. Eltartott egy ideig, amíg a szakértők felismerték a kockázatokat, és riasztást adtak.

Emlékezzen az előszámítási támadásra: a cikk végén megvizsgálunk két valós kriptográfiai példát, ahol fontos szerepet játszott.

Interpoláció

Itt van a híres nyomozó, Sherlock Holmes, aki interpolációs támadást hajt végre a szerencsétlen Dr. Watson ellen:

Rögtön sejtettem, hogy Afganisztánból jöttél... A gondolatmenetem a következő volt: „Ez az ember típusát tekintve orvos, de katonai érzéke van. Szóval katonaorvos. Nemrég érkezett a trópusokról - az arca sötét, de nem ez a természetes árnyalata a bőrének, mivel a csuklója sokkal fehérebb. Az arca elkeseredett – nyilván sokat szenvedett és betegségben szenvedett. A bal kezében megsebesült – mozdulatlanul és kissé természetellenesen tartja. Hol tud a trópusokon egy angol katonaorvos nehézségeket elviselni és megsebesülni? Természetesen Afganisztánban." Az egész gondolatmenet egy pillanatig sem tartott. Ezért mondtam, hogy Afganisztánból jöttél, és meglepődtél.

Holmes nagyon kevés információt tudott kinyerni minden egyes bizonyítékból külön-külön. Konklúziójára csak akkor juthatott, ha mindegyiket együtt mérlegelte. Az interpolációs támadás hasonlóan működik az azonos kulcsból származó ismert egyszerű szöveg és titkosított szöveg párok vizsgálatával. Mindegyik párból egyedi megfigyeléseket vonnak ki, amelyek lehetővé teszik a kulcsra vonatkozó általános következtetés levonását. Mindezek a következtetések homályosak és haszontalannak tűnnek, amíg hirtelen el nem érik a kritikus tömeget, és az egyetlen lehetséges következtetéshez nem vezetnek: bármilyen hihetetlen is, igaznak kell lennie. Ezt követően vagy felfedik a kulcsot, vagy a visszafejtési folyamat annyira finomodik, hogy replikálható.

Egy egyszerű példával szemléltetjük az interpoláció működését. Tegyük fel, hogy el akarjuk olvasni ellenségünk, Bob személyes naplóját. Naplójában minden számot titkosít egy egyszerű kriptorendszer segítségével, amelyről az "A Mock of Cryptography" magazinban megjelent hirdetésből tudott meg. A rendszer a következőképpen működik: Bob kiválaszt két számot, ami tetszik neki: и . Mostantól bármilyen szám titkosításához , kiszámolja . Például ha Bob úgy döntött и , majd a szám néven lesz titkosítva .

Tegyük fel, hogy december 28-án vettük észre, hogy Bob megkarcol valamit a naplójában. Ha végzett, csendben felvesszük, és megnézzük az utolsó bejegyzést:

időpontja: 235/520

Kedves Naplóm,

A mai nap jó volt. Keresztül 64 ma randevúzok Alisával, aki egy lakásban lakik 843. Szerintem tényleg az lehet 26!

Mivel nagyon komolyan akarjuk követni Bobot a randevúján (ebben a forgatókönyvben mindketten 15 évesek vagyunk), nagyon fontos tudni a dátumot és Alice címét. Szerencsére észrevesszük, hogy Bob kriptorendszere sebezhető az interpolációs támadásokkal szemben. Lehet, hogy nem tudjuk и , de ismerjük a mai dátumot, így van két egyszerű szöveg-titkosszöveg párunk. Mégpedig azt tudjuk be titkosítva És - ban ben . Ezt írjuk le:

Mivel 15 évesek vagyunk, már ismerünk egy két egyenletrendszert két ismeretlennel, amit ebben a helyzetben elég megtalálni и minden probléma nélkül. Mindegyik egyszerű szöveg-rejtjelezett szöveg pár korlátozza Bob kulcsát, és a két megszorítás együtt elegendő a kulcs teljes helyreállításához. Példánkban a válasz az и (nál nél , így 26 a naplóban az „az egy” szónak felel meg, azaz „ugyanaz” - kb. sáv).

Az interpolációs támadások természetesen nem korlátozódnak az ilyen egyszerű példákra. Minden kriptorendszer, amely egy jól érthető matematikai objektummá és egy paraméterlistává redukálódik, ki van téve egy interpolációs támadásnak – minél érthetőbb az objektum, annál nagyobb a kockázat.

Az újoncok gyakran panaszkodnak, hogy a kriptográfia „a dolgok lehető legrondább tervezésének művészete”. Valószínűleg nagyrészt az interpolációs támadások a felelősek. Bob használhat elegáns matematikai tervet, vagy magánban tarthatja a randevút Alice-szel – de sajnos általában nem lehet mindkét irányban. Ez teljesen világossá válik, ha végül eljutunk a nyilvános kulcsú kriptográfia témájához.

Keresztprotokoll/downgrade

A Now You See Me (2013) című filmben illuzionisták egy csoportja megpróbálja kicsalni a korrupt biztosítási mágnást, Arthur Tresslert teljes vagyonából. Ahhoz, hogy hozzáférjenek Arthur bankszámlájához, az illuzionistáknak meg kell adniuk felhasználónevét és jelszavát, vagy rá kell kényszeríteniük, hogy személyesen jelenjen meg a bankban és vegyen részt a programban.

Mindkét lehetőség nagyon nehéz; A srácok hozzászoktak a színpadi fellépéshez, és nem vesznek részt titkosszolgálati műveletekben. Így hát a harmadik lehetséges lehetőséget választják: cinkosuk felhívja a bankot, és Arthurnak adja ki magát. A bank több kérdést is feltesz a személyazonosság igazolására, például a nagybácsi nevét és az első kisállat nevét; hőseink előre ügyes social engineering segítségével könnyedén kivonják ezeket az információkat Arthurból. Ettől kezdve a kiváló jelszóbiztonság már nem számít.

(Egy városi legenda szerint, amelyet személyesen ellenőriztünk és ellenőriztünk, Eli Beaham kriptográfus egyszer találkozott egy bankpénztárossal, aki ragaszkodott ahhoz, hogy biztonsági kérdést tegyen fel. Amikor a pénztáros megkérdezte anyai nagyanyja nevét, Beaham diktálni kezdett: „Capital X, kicsi y, három...").

Ugyanez a helyzet a kriptográfiában, ha két kriptográfiai protokollt párhuzamosan használnak ugyanazon eszköz védelmére, és az egyik sokkal gyengébb, mint a másik. Az így létrejövő rendszer sebezhetővé válik a protokollok közötti támadásokkal szemben, ahol egy gyengébb protokollt támadnak meg annak érdekében, hogy eljussanak a nyereményhez anélkül, hogy az erősebbet érintenék.

Egyes bonyolult esetekben nem elég egyszerűen felvenni a kapcsolatot a szerverrel egy gyengébb protokoll használatával, hanem egy legitim kliens önkéntelen közreműködésére van szükség. Ezt az úgynevezett downgrade támadás segítségével lehet megszervezni. A támadás megértéséhez tegyük fel, hogy illuzionistáinknak nehezebb dolga van, mint a filmben. Tételezzük fel, hogy egy banki alkalmazott (pénztáros) és Arthur előre nem látott körülményekbe ütközött, ami a következő párbeszédet eredményezte:

Betörő: Helló? Ő Arthur Tressler. Szeretném visszaállítani a jelszavamat.

Pénztáros: Nagy. Kérjük, tekintse meg személyes titkos kódkönyvét, 28. oldal, 3. szó. Az összes következő üzenet titkosítva lesz ezzel a szóval kulcsként. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Betörő: Hé, hé, várj, várj. Ez tényleg szükséges? Nem beszélhetnénk úgy, mint a normális emberek?

Pénztáros: Nem ajánlom ezt.

Betörő: Én csak... nézd, rossz napom volt, oké? VIP kliens vagyok, és nincs kedvem ezekben a hülye kódkönyvekben kotorászni.

Pénztáros: Bírság. Ha ragaszkodik hozzá, Mr. Tressler. Mit akarsz?

Betörő: Kérem, minden pénzemet az Arthur Tressler Nemzeti Áldozati Alapnak szeretném felajánlani.

(Szünet).

Pénztáros: Most már világos. Nagy tranzakciók esetén adja meg PIN-kódját.

Betörő: Az én mim?

Pénztáros: Személyes kérésére ekkora tranzakciókhoz PIN kód szükséges a nagy tranzakciókhoz. Ezt a kódot a fiók megnyitásakor kapta.

Betörő:... Elvesztettem. Ez tényleg szükséges? Nem tudod csak jóváhagyni az üzletet?

Pénztáros: Nem. Sajnálom, Mr. Tressler. Ismét ez az Ön által kért biztonsági intézkedés. Ha szeretné, postafiókjába új PIN kódot küldhetünk.

Hőseink elhalasztják a műveletet. Lehallgatnak Tressler több nagy tranzakcióját, abban a reményben, hogy meghallják a PIN-kódot; de minden alkalommal, amikor a beszélgetés kódolt halandzsává válik, mielőtt bármi érdekeset mondanak. Végül egy szép napon a terv megvalósul. Türelmesen kivárják a pillanatot, amikor Tresslernek telefonon kell nagy tranzakciót bonyolítania, rááll a vonalra, majd...

Tressler: Helló. Távoli tranzakciót szeretnék végrehajtani, kérem.

Pénztáros: Nagy. Kérjük, tekintse meg személyes titkos kódkönyvét, oldalát...

(A betörő megnyomja a gombot; a pénztáros hangja érthetetlen zajba megy át).

Pénztáros: - A #@$#@$#*@$$@#* ezzel a szóval lesz titkosítva kulcsként. AAAYRR PLRQRZ MMNJK LOJBAN…

Tressler: Elnézést, nem egészen értettem. Újra? melyik oldalon? Milyen szó?

Pénztáros: Ez a @#$@#*$)#*#@()#@$(#@*$(#@*) oldal.

Tressler: Mi van?

Pénztáros: Húszas szószám @$#@$#%#$.

Tressler: Komolyan! Most már elég! Te és a biztonsági protokollja egyfajta cirkusz vagy. Tudom, hogy normálisan beszélhetsz velem.

Pénztáros: nem ajánlom…

Tressler: És nem tanácsolom, hogy pazarold az időmet. Nem akarok többet hallani erről, amíg meg nem oldja a telefonvonal problémáit. Véglegesíthetjük ezt az üzletet vagy sem?

Pénztáros:… Igen. Bírság. Mit akarsz?

Tressler: 20 000 dollárt szeretnék átutalni a Lord Business Investments-nek, számlaszám...

Pénztáros: Egy perc kérjük. Nagy dolog. Nagy tranzakciók esetén adja meg PIN-kódját.

Tressler: Mit? Ó, pontosan. 1234.

Itt egy lefelé irányuló támadás. A gyengébb "csak beszélj közvetlenül" protokollt ilyennek képzelték el választási lehetőség sürgős esetben. És mégis itt vagyunk.

Elgondolkodhat azon, hogy ép elméjével ki tervezne a fent leírthoz hasonló "széf, amíg másképp nem kérik" rendszert. De ahogy egy kitalált bank kockázatot vállal azért, hogy megtartsa az ügyfeleket, akik nem szeretik a kriptográfiát, a rendszerek általában gyakran olyan követelmények felé hajlanak, amelyek közömbösek vagy akár kifejezetten ellenségesek a biztonsággal szemben.

Pontosan ez történt az SSLv2 protokollal 1995-ben. Az Egyesült Államok kormánya régóta kezdi úgy tekinteni a kriptográfiára, mint egy olyan fegyverre, amelyet a legjobb távol tartani a külföldi és belföldi ellenségektől. A kóddarabokat egyedileg engedélyezték az Egyesült Államokból való kivitelre, gyakran azzal a feltétellel, hogy az algoritmust szándékosan gyengítették. A Netscape, a legnépszerűbb böngésző, a Netscape Navigator fejlesztője csak az eredendően sebezhető 2 bites RSA kulccsal (és 512 bites az RC40-hez) kapott engedélyt az SSLv4-re.

Az ezredforduló végére a szabályok lazultak, és széles körben elérhetővé vált a modern titkosításhoz való hozzáférés. A kliensek és a szerverek azonban évek óta támogatják a gyengített "export" kriptográfiát ugyanazon tehetetlenség miatt, amely fenntartja bármely régi rendszer támogatását. Az ügyfelek azt hitték, hogy olyan szerverrel találkozhatnak, amely mást nem támogat. A szerverek is ezt tették. Természetesen az SSL protokoll megköveteli, hogy az ügyfelek és a szerverek soha ne használjanak gyenge protokollt, ha jobb elérhető. De ugyanez érvényes Tresslerre és bankjára is.

Ez az elmélet két nagy horderejű támadásba került, amelyek 2015-ben megrendítették az SSL protokoll biztonságát, mindkettőt a Microsoft kutatói és INRIA. Először februárban derültek ki a FREAK támadás részletei, majd három hónappal később egy másik hasonló támadás, a Logjam, amelyet részletesebben tárgyalunk, amikor áttérünk a nyilvános kulcsú kriptográfia elleni támadásokra.

Sebezhetőség FREAK (más néven "Smack TLS") akkor derült ki, amikor a kutatók elemezték a TLS kliens/szerver implementációit, és különös hibát fedeztek fel. Ezekben a megvalósításokban, ha a kliens nem is kéri a gyenge export-kriptográfia használatát, de a szerver továbbra is ilyen kulcsokkal válaszol, akkor a kliens azt mondja, hogy „Na jó”, és átvált egy gyenge titkosítási csomagra.

Abban az időben az export kriptográfiát széles körben elavultnak és tiltottnak tartották, így a támadás teljes sokkot okozott, és számos fontos tartományt érintett, köztük a Fehér Házat, az IRS-t és az NSA oldalait. Még ennél is rosszabb, hogy kiderült, hogy sok sebezhető szerver úgy optimalizálta a teljesítményt, hogy ugyanazokat a kulcsokat újrahasználta, ahelyett, hogy minden munkamenethez újakat generált volna. Ez lehetővé tette a protokoll leminősítését követően a számítás előtti támadás végrehajtását: egy kulcs feltörése viszonylag drága maradt (100 dollár és 12 óra a megjelenéskor), de a kapcsolat megtámadásának gyakorlati költsége jelentősen csökkent. Elég egyszer kiválasztani a kiszolgálókulcsot, és ettől a pillanattól kezdve minden további kapcsolat titkosítását feltörni.

És mielőtt továbblépnénk, egy előrehaladott támadást meg kell említeni...

Oracle támadás

Moxie Marlinspike leginkább a többplatformos kriptoüzenetküldő alkalmazás, a Signal atyjaként ismert; de nekünk személy szerint tetszik az egyik kevésbé ismert újítása - kriptográfiai végzet elve (Kriptográfiai végzet elve). Kissé átfogalmazva ezt mondhatjuk: „Ha a protokoll teljesít Bármi titkosítási műveletet hajt végre egy potenciálisan rosszindulatú forrásból származó üzeneten, és az eredménytől függően eltérően viselkedik, kudarcra van ítélve." Vagy élesebben: "Ne vegyél el információt az ellenségtől feldolgozásra, és ha kell, akkor legalább ne mutasd meg az eredményt."

Hagyjuk félre a puffertúlcsordulást, a parancsinjektálást és hasonlókat; kívül esnek ennek a vitának a keretein. A "végzet elvének" megsértése súlyos kriptográfiai hackekhez vezet, mivel a protokoll pontosan a várt módon viselkedik.

Példaként vegyünk egy fiktív tervet egy sebezhető helyettesítő titkosítással, majd mutassunk be egy lehetséges támadást. Bár láttunk már támadást egy helyettesítő rejtjel ellen frekvenciaelemzés segítségével, ez nem csak "ugyanannak a rejtjelnek egy másik módja". Éppen ellenkezőleg, az oracle támadások sokkal modernebb találmány, számos olyan helyzetre alkalmazható, ahol a frekvenciaelemzés sikertelen, és ennek bemutatását a következő részben fogjuk látni. Itt az egyszerű rejtjel csak azért van kiválasztva, hogy a példa világosabb legyen.

Így Alice és Bob egy egyszerű helyettesítő titkosítással kommunikál, egy csak általuk ismert kulccsal. Nagyon szigorúak az üzenetek hosszát illetően: pontosan 20 karakter hosszúak. Így megállapodtak abban, hogy ha valaki rövidebb üzenetet szeretne küldeni, akkor az üzenet végére illesszen valami fiktív szöveget, hogy az pontosan 20 karakter legyen. Némi vita után úgy döntöttek, hogy csak a következő álszövegeket fogadják el: a, bb, ccc, dddd stb. Így bármilyen szükséges hosszúságú álszöveg ismert.

Amikor Alice vagy Bob üzenetet kap, először ellenőrzi, hogy az üzenet megfelelő hosszúságú-e (20 karakter), és hogy az utótag a megfelelő álszöveg. Ha nem ez a helyzet, akkor megfelelő hibaüzenettel válaszolnak. Ha a szöveg hossza és az üres szöveg megfelelő, a címzett magát az üzenetet olvassa el, és titkosított választ küld.

A támadás során a támadó Bobot adja ki, és hamis üzeneteket küld Alice-nek. Az üzenetek teljesen értelmetlenek – a támadónak nincs kulcsa, ezért nem tud értelmes üzenetet hamisítani. De mivel a protokoll sérti a végzet elvét, a támadó továbbra is csapdába csalhatja Alice-t, hogy felfedje a kulcsfontosságú információkat, amint az alább látható.

Betörő: PREWF ZHJKL MMMN. LA

Alice: Érvénytelen álszöveg.

Betörő: PREWF ZHJKL MMMN. LB

Alice: Érvénytelen álszöveg.

Betörő: PREWF ZHJKL MMMN. LC

Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

A betörőnek fogalma sincs, mit mondott Alice, de megjegyzi, hogy a szimbólum C meg kell felelnie a, mivel Alice elfogadta a fiktív szöveget.

Betörő: REWF ZHJKL MMMN. LAA

Alice: Érvénytelen álszöveg.

Betörő: REWF ZHJKL MMMN. LBB

Alice: Érvénytelen álszöveg.

Többszöri próbálkozás után...

Betörő: REWF ZHJKL MMMN. LGG

Alice: Érvénytelen álszöveg.

Betörő: REWF ZHJKL MMMN. LHH

Alice: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

A támadónak megint fogalma sincs, mit mondott Alice, de megjegyzi, hogy H-nek egyeznie kell b-vel, mivel Alice elfogadta a hamis szöveget.

És így tovább, amíg a támadó meg nem ismeri az egyes karakterek jelentését.

Első pillantásra a módszer egy kiválasztott egyszerű szöveges támadásra hasonlít. Végül a támadó kiválasztja a titkosított szövegeket, a szerver pedig engedelmesen feldolgozza azokat. A fő különbség, ami ezeket a támadásokat életképessé teszi a valós világban, az az, hogy a támadónak nincs szüksége a tényleges átirathoz – elegendő egy szerver válasz, még egy olyan ártalmatlan is, mint az „Érvénytelen álszöveg”.

Bár ez a konkrét támadás tanulságos, ne ragadjon túl a "dummy text" séma sajátosságaival, a használt titkosítási rendszerrel vagy a támadó által küldött üzenetek pontos sorrendjével. Az alapötlet az, hogy Alice hogyan reagál másként a nyílt szöveg tulajdonságai alapján, és ezt anélkül teszi, hogy ellenőrizné, hogy a megfelelő rejtjelezett szöveg valóban megbízható féltől származik-e. Így Alice megengedi a támadónak, hogy titkos információkat csikarjon ki válaszaiból.

Ebben a forgatókönyvben sok minden változtatható. A szimbólumok, amelyekre Alice reagál, vagy a viselkedésének különbségei, vagy akár a használt kriptorendszer. De az elv ugyanaz marad, és a támadás egésze ilyen vagy olyan formában életképes marad. Ennek a támadásnak az alapvető megvalósítása számos biztonsági hiba feltárásában segített, amelyeket hamarosan megvizsgálunk; de először is le kell vonni néhány elméleti tanulságot. Hogyan lehet használni ezt a fiktív "Alice-szkriptet" egy támadásban, amely képes működni egy igazi modern titkosításon? Ez egyáltalán lehetséges, még elméletben is?

1998-ban Daniel Bleichenbacher svájci kriptográfus igennel válaszolt erre a kérdésre. Bemutatta egy orákulum támadást a széles körben használt nyilvános kulcsú RSA kriptorendszer ellen, egy speciális üzenetséma segítségével. Egyes RSA-megvalósításokban a szerver különböző hibaüzenetekkel válaszol attól függően, hogy a nyílt szöveg egyezik-e a sémával vagy sem; ez elég volt a támadás végrehajtásához.

Négy évvel később, 2002-ben Serge Vaudenay francia kriptográfus egy orákulumtámadást mutatott be, amely majdnem teljesen megegyezik a fenti Alice-forgatókönyvben leírtakkal – azzal a különbséggel, hogy egy fiktív rejtjel helyett a modern titkosítások egy egész tekintélyes osztályát törte meg, amelyeket az emberek valójában használnak. A Vaudenay támadása különösen a rögzített bemeneti méretű rejtjeleket ("blokk rejtjeleket") célozza meg, amikor azokat úgynevezett "CBC-titkosítási módban" és egy bizonyos népszerű kitöltési sémával használják, amely alapvetően megegyezik az Alice-forgatókönyvben szereplővel.

Szintén 2002-ben John Kelsey amerikai kriptográfus - társszerző Kettőhal — különféle oracle támadásokat javasolt olyan rendszerek ellen, amelyek tömörítik az üzeneteket, majd titkosítják azokat. Ezek közül a legfigyelemreméltóbb egy olyan támadás volt, amely kihasználta azt a tényt, hogy a titkosított szöveg hosszából gyakran lehet következtetni a nyílt szöveg eredeti hosszára. Elméletileg ez lehetővé teszi az orákulum támadást, amely helyreállítja az eredeti nyílt szöveg egyes részeit.

Az alábbiakban részletesebb leírást adunk a Vaudenay- és Kelsey-támadásokról (a Bleichenbacher-támadásról részletesebb leírást adunk, ha áttérünk a nyilvános kulcsú kriptográfia elleni támadásokra). Minden erőfeszítésünk ellenére a szöveg kissé technikai jellegűvé válik; így ha a fentiek elegendőek számodra, hagyd ki a következő két részt.

Vodene támadása

A Vaudenay támadás megértéséhez először is egy kicsit többet kell beszélnünk a blokk titkosításokról és a titkosítási módokról. A „blokk-rejtjel” egy olyan rejtjel, amely egy kulcsot és egy bizonyos fix hosszúságú ("blokkhossz") bemenetet vesz fel, és egy ugyanolyan hosszúságú titkosított blokkot állít elő. A blokk titkosításokat széles körben használják, és viszonylag biztonságosnak tartják. A már visszavonult DES, amelyet az első modern rejtjelnek tartottak, blokk titkosítás volt. Mint fentebb említettük, ugyanez igaz a manapság széles körben használt AES-re is.

Sajnos a blokk titkosításnak van egy szembetűnő gyengesége. A tipikus blokkméret 128 bit vagy 16 karakter. Nyilvánvaló, hogy a modern kriptográfia nagyobb bemeneti adatokkal való munkavégzést igényel, és itt jönnek szóba a titkosítási módok. A titkosítási mód lényegében egy hack: ez egy módja annak, hogy valamilyen blokk-rejtjelet alkalmazzunk, amely csak egy bizonyos méretű bevitelt fogad el tetszőleges hosszúságú bevitelhez.

A Vodene támadása a népszerű CBC (Cipher Block Chaining) működési módra összpontosít. A támadás a mögöttes blokk titkosítást varázslatos, bevehetetlen fekete dobozként kezeli, és teljesen megkerüli annak biztonságát.

Íme egy diagram, amely bemutatja a CBC mód működését:

A bekarikázott plusz az XOR (exkluzív VAGY) műveletet jelöli. Például a titkosított szöveg második blokkja érkezik:

1. XOR művelet végrehajtásával a második nyílt szöveg blokkon az első titkosított szöveg blokkon.
2. A kapott blokk titkosítása blokk titkosítással kulcs segítségével.

Mivel a CBC olyan erősen használja a bináris XOR műveletet, szánjunk egy pillanatot annak néhány tulajdonságának felidézésére:

• Idempotencia:
• Kommutativitás:
• Aszociativitás:
• Önreverzibilitás:
• Bájtméret: n bájt = (n bájtja ) (n. bájtja )

Általában ezek a tulajdonságok azt jelentik, hogy ha van egy XOR műveleteket és egy ismeretlent tartalmazó egyenlet, akkor az megoldható. Például ha tudjuk az ismeretlennel és híres и , akkor a fent említett tulajdonságokra támaszkodhatunk az egyenlet megoldásához . Ha XOR-t alkalmazunk az egyenlet mindkét oldalán , kapunk . Mindez egy pillanat alatt nagyon aktuális lesz.

Két kisebb és egy jelentős különbség van a mi Alice-forgatókönyvünk és Vaudenay támadása között. Két kisebb:

• A forgatókönyvben Alice arra számított, hogy az egyszerű szövegek véget érnek a karakterekkel a, bb, ccc stb. A Wodene támadásban az áldozat ehelyett azt várja, hogy a nyílt szövegek N-szer az N bájttal végződjenek (vagyis hexadecimális 01 vagy 02 02 vagy 03 03 03 stb.). Ez pusztán kozmetikai különbség.
• Az Alice forgatókönyvében a "Helytelen álszöveg" válaszból könnyű volt megállapítani, hogy Alice elfogadta-e az üzenetet. Vodene támadásában több elemzésre van szükség, és fontos a pontos végrehajtás az áldozat oldalán; de a rövidség kedvéért vegyük adottnak, hogy ez az elemzés még lehetséges.

Fő különbség:

• Mivel nem ugyanazt a titkosítási rendszert használjuk, a támadó által vezérelt rejtjelezett bájtok és a titkok (kulcs és egyszerű szöveg) közötti kapcsolat nyilvánvalóan más lesz. Ezért a támadónak más stratégiát kell alkalmaznia titkosított szövegek létrehozásakor és a szerver válaszainak értelmezésekor.

Ez a fő különbség a Vaudenay-támadás megértéséhez szükséges rejtvény utolsó darabja, ezért gondoljunk át egy pillanatra, hogy miért és hogyan lehet a CBC elleni orákulum támadást végrehajtani.

Tegyük fel, hogy kapunk egy 247 blokkból álló CBC titkosítást, és szeretnénk visszafejteni. Hamis üzeneteket küldhetünk a szervernek, ahogy korábban is küldhettünk hamis üzeneteket Alice-nek. A szerver visszafejti helyettünk az üzeneteket, de nem jeleníti meg a visszafejtést – ehelyett, ahogy Alice esetében is, a szerver csak egy bitnyi információt közöl: a sima szövegnek van-e érvényes kitöltése vagy sem.

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

$$display$$text{SIMPLE_SUBSTITUTION}(szöveg{titkosszöveg},szöveg{kulcs}) = szöveg{egyszerű szöveg}$$megjelenítés$$

Nevezzük ezt "Alice egyenletének". Mi irányítottuk a rejtjelezett szöveget; a szerver (Alice) homályos információkat szivárogtatott ki a fogadott nyílt szövegről; és ez lehetővé tette számunkra, hogy információkat vonjunk le az utolsó tényezőről - a kulcsról. Hasonlatosan, ha találunk ilyen kapcsolatot a CBC script számára, akkor ott is kinyerhetünk néhány titkos információt.

Szerencsére valóban léteznek olyan kapcsolatok, amelyeket használhatunk. Tekintsük az utolsó hívás kimenetét egy blokkrejtjel visszafejtéséhez, és jelölje ezt a kimenetet mint . A nyílt szöveg blokkjait is jelöljük és titkosított szöveg blokkokat . Vessen egy pillantást a CBC diagramra, és figyelje meg, mi történik:

Nevezzük ezt „CBC egyenletnek”.

Alice forgatókönyvében a rejtjelezett szöveg figyelésével és a megfelelő nyílt szöveg kiszivárgásának megfigyelésével támadásba lendültünk, amely visszaszerezte az egyenlet harmadik tagját – a kulcsot. A CBC forgatókönyvben a titkosított szöveget is figyeljük, és megfigyeljük az információszivárgást a megfelelő nyílt szövegen. Ha az analógia igaz, információt szerezhetünk arról .

Tegyük fel, hogy valóban helyreállítottuk , akkor mit? Nos, akkor egyszerre kinyomtathatjuk az egész utolsó egyszerű szövegblokkot (), egyszerűen belépve (ami nálunk van) és
kapott a CBC egyenletbe.

Most, hogy optimisták vagyunk az átfogó támadási tervet illetően, ideje kidolgozni a részleteket. Kérjük, figyeljen arra, hogy pontosan hogyan szivárognak ki egyszerű szöveges információk a szerveren. Alice szkriptjében a szivárgás azért történt, mert Alice csak akkor válaszolt a megfelelő üzenettel, ha $inline$text{SIMPLE_SUBSTITUTION}(szöveg{ciphertext},text{key})$inline$ ezzel a sorral végződik a (vagy bbés így tovább, de nagyon kicsi az esélye annak, hogy ezeket a feltételeket véletlen váltja ki). A CBC-hez hasonlóan a szerver akkor és csak akkor fogadja el a kitöltést hexadecimálisra végződik 01. Tehát próbáljuk meg ugyanazt a trükköt: hamis titkosított szövegeket küldünk saját hamis értékeinkkel amíg a szerver el nem fogadja a kitöltést.

Ha a szerver elfogadja az egyik hamis üzenetünk kitöltését, az azt jelenti, hogy:

Most a byte-byte XOR tulajdonságot használjuk:

Ismerjük az első és a harmadik kifejezést. És már láttuk, hogy ez lehetővé teszi számunkra, hogy visszanyerjük a fennmaradó kifejezést - az utolsó bájtot :

Ez a CBC-egyenlet és a byte-byte tulajdonság révén megkapjuk az utolsó egyszerű szöveges blokk utolsó bájtját is.

Hagyjuk a dolgot, és elégedettek lehetünk azzal, hogy egy elméletileg erős rejtjel ellen hajtottunk végre támadást. Valójában azonban sokkal többet tehetünk: valójában visszaállíthatjuk az összes szöveget. Ehhez egy olyan trükk kell, ami nem volt benne Alice eredeti forgatókönyvében, és nem szükséges az orákulumtámadáshoz, de érdemes megtanulni.

Ennek megértéséhez először vegye figyelembe, hogy az utolsó bájt helyes értékének kiadásának eredménye a következő új képességünk van. Most, amikor titkosított szövegeket kovácsolunk, manipulálhatjuk a megfelelő nyílt szöveg utolsó bájtját. Ez ismét a CBC egyenlethez és a byte-byte tulajdonsághoz kapcsolódik:

Mivel ma már ismerjük a második kifejezést, az első feletti irányítást használhatjuk a harmadik szabályozására. Egyszerűen kiszámoljuk:

Ezt korábban nem tudtuk megtenni, mert még nem volt meg az utolsó bájt .

Hogyan segít ez nekünk? Tegyük fel, hogy most az összes titkosított szöveget úgy hozzuk létre, hogy a megfelelő nyílt szövegekben az utolsó bájt egyenlő 02. A szerver mostantól csak akkor fogadja el a kitöltést, ha az egyszerű szöveg így végződik 02 02. Mivel az utolsó bájtot javítottuk, ez csak akkor fog megtörténni, ha a nyílt szöveg utolsó előtti bájtja is 02. Folyamatosan küldünk hamis titkosított szövegblokkokat, az utolsó előtti bájtot változtatva, amíg a szerver elfogadja az egyik kitöltését. Ezen a ponton kapjuk:

És visszaállítjuk az utolsó előtti bájtot ahogy az utolsót is helyreállították. Ugyanebben a szellemben folytatjuk: a plaintext utolsó két bájtját helyesbítjük 03 03, megismételjük ezt a támadást a végétől a harmadik bájtig, és így tovább, végül teljesen visszaállítva .

Mi a helyzet a szöveg többi részével? Felhívjuk figyelmét, hogy az érték valójában $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Helyette tehetünk bármilyen más blokkot , és a támadás továbbra is sikeres lesz. Valójában megkérhetjük a szervert, hogy tegyen $inline$text{BLOCK_DECRYPT}$inline$ bármilyen adatot. Ezen a ponton a játéknak vége – bármilyen rejtjelezett szöveget visszafejthetünk (vegyünk még egy pillantást a CBC visszafejtési diagramra, hogy lássuk, és vegyük figyelembe, hogy az IV nyilvános).

Ez a módszer döntő szerepet játszik az orákulumtámadásban, amellyel később találkozunk.

Kelsey támadása

Kedves John Kelseyünk sok lehetséges támadás alapelveit tárta fel, nem csak egy konkrét rejtjel elleni konkrét támadás részleteit. Övé Az év 2002 cikke egy tanulmány a titkosított tömörített adatok elleni lehetséges támadásokról. Gondolta volna, hogy az az információ, hogy az adatokat a titkosítás előtt tömörítették, nem elegendő a támadás végrehajtásához? Kiderült, hogy ez elég.

Ez a meglepő 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ásra pontos egyenlőség. Másodszor, amikor tömörítést hajtanak végre, erős korreláció van a tömörített üzenet hossza és a nyílt szöveg "zajosságának" mértéke, vagyis a nem ismétlődő karakterek aránya között (a szakkifejezés "nagy entrópia"). ).

Az elv működésének megtekintéséhez vegyünk két egyszerű szöveget:

Egyszerű szöveg 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Egyszerű szöveg 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Tegyük fel, hogy mindkét egyszerű szöveg tömörített, majd titkosított. Két kapott titkosított szöveget kap, és ki kell találnia, hogy melyik rejtjelezett szöveg egyezik melyik egyszerű szöveggel:

1. titkosított szöveg: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

2. titkosított szöveg: DWKJZXYU

A válasz egyértelmű. A nyílt szövegek közül csak az 1. egyszerű szöveget lehetett a második rejtjelezett szöveg csekély hosszába tömöríteni. Ezt úgy találtuk ki, hogy semmit sem tudtunk a tömörítési algoritmusról, a titkosítási 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 őrültség.

Kelsey rámutat továbbá arra, hogy bizonyos szokatlan körülmények között ez az elv jóslótámadás végrehajtására is használható. Pontosabban leírja, hogyan állíthatja vissza a támadó a titkos nyílt szöveget, ha rákényszerítheti a szervert az űrlapadatok titkosítására (a nyílt szöveget miközben ő irányítja és valahogy ellenőrizni tudja a titkosított eredmény hosszát.

Más orákulumtámadásokhoz hasonlóan itt is a következő a kapcsolatunk:

Ismét egy kifejezést irányítunk (), egy kis információszivárgást látunk egy másik tagról (titkosított szöveg), és megpróbáljuk visszaállítani az utolsót (sima szöveg). Az analógia ellenére ez némileg szokatlan helyzet más, általunk látott orákulumtámadásokhoz képest.

Annak szemléltetésére, hogyan működhet egy ilyen támadás, használjunk egy fiktív tömörítési sémát, amelyet most találtunk ki: TOYZIP. Megkeresi azokat a szövegsorokat, amelyek korábban megjelentek a szövegben, és három helyőrző bájttal helyettesíti őket, amelyek jelzik, hol található a sor korábbi példánya, és hányszor jelenik meg ott. Például a vonal helloworldhello bele lehet tömöríteni helloworld[00][00][05] 13 bájt hosszú az eredeti 15 bájthoz képest.

Tegyük fel, hogy egy támadó megpróbálja visszaállítani egy űrlap egyszerű szövegét password=..., ahol maga a jelszó ismeretlen. Kelsey támadási modellje szerint a támadó megkérheti a szervert, hogy tömörítse, majd titkosítsa az űrlapüzeneteket (sima szöveg, majd ) hol  - szabad szöveg. Amikor a szerver befejezte a munkát, jelenti az eredmény hosszát. A támadás a következőképpen zajlik:

Betörő: Kérjük, tömörítse és titkosítsa az egyszerű szöveget kitöltés nélkül.

Szerver: Az eredmény hossza 14.

Betörő: Kérjük, tömörítse és titkosítsa a hozzáfűzött egyszerű szöveget password=a.

Szerver: Az eredmény hossza 18.

A cracker megjegyzi: [eredeti 14] + [három bájt, amely kicserélte password=] + a

Betörő: Kérjük, tömörítse és titkosítsa a hozzáadott egyszerű szöveget password=b.

Szerver: Az eredmény hossza 18.

Betörő: Kérjük, tömörítse és titkosítsa a hozzáadott egyszerű szöveget password=с.

Szerver: Az eredmény hossza 17.

A cracker megjegyzi: [eredeti 14] + [három bájt, amely kicserélte password=c]. Ez azt feltételezi, hogy az eredeti egyszerű szöveg tartalmazza a karakterláncot password=c. Vagyis a jelszó betűvel kezdődik c

Betörő: Kérjük, tömörítse és titkosítsa a hozzáadott egyszerű szöveget password=сa.

Szerver: Az eredmény hossza 18.

A cracker megjegyzi: [eredeti 14] + [három bájt, amely kicserélte password=с] + a

Betörő: Kérjük, tömörítse és titkosítsa a hozzáadott egyszerű szöveget password=сb.

Szerver: Az eredmény hossza 18.

(… Kicsit később…)

Betörő: Kérjük, tömörítse és titkosítsa a hozzáadott egyszerű szöveget password=со.

Szerver: Az eredmény hossza 17.

A cracker megjegyzi: [eredeti 14] + [három bájt, amely kicserélte password=co]. Ugyanezt a logikát alkalmazva a támadó arra a következtetésre jut, hogy a jelszó betűkkel kezdődik co

És így tovább, amíg a teljes jelszó vissza nem áll.

Az olvasó megbocsáthatná, ha azt gondolná, hogy ez pusztán akadémiai gyakorlat, és hogy ilyen támadási forgatókönyv soha nem fordulhat elő a való világban. Sajnos, mint hamarosan látni fogjuk, jobb, ha nem mondunk le a titkosításról.

A márka sebezhetőségei: BŰNÖZÉS, PUDLA, DROWN

Végül az elmélet részletes tanulmányozása után láthatjuk, hogyan alkalmazzák ezeket a technikákat a valós kriptográfiai támadásokban.

BŰN

Ha a támadás az áldozat böngészője és hálózata ellen irányul, egyesek könnyebbek, mások pedig nehezebbek. Például könnyű látni az áldozat forgalmát: csak üljön vele ugyanabban a kávézóban, ahol van WiFi. Emiatt a potenciális áldozatoknak (azaz mindenkinek) általában azt tanácsolják, hogy használjanak titkosított kapcsolatot. Nehezebb lesz, de még mindig lehetséges HTTP-kéréseket küldeni az áldozat nevében valamely harmadik fél webhelyére (például a Google-ra). A támadónak egy rosszindulatú weboldalra kell csábítania az áldozatot a kérést végrehajtó szkripttel. A webböngésző automatikusan megadja a megfelelő munkamenet cookie-t.

Ez csodálatosnak tűnik. Ha Bob odament evil.com, az ezen a webhelyen található szkript megkérheti a Google-t, hogy küldje el Bob jelszavát a címre [email protected]? Nos, elméletben igen, de a valóságban nem. Ezt a forgatókönyvet webhelyek közötti kérés-hamisítási támadásnak nevezik (Site-request forgery, CSRF), és a 90-es évek közepe táján volt népszerű. Ma ha evil.com Ha megpróbálja ezt a trükköt, a Google (vagy bármely önbecsülő webhely) általában így válaszol: „Remek, de az Ön CSRF-tokenje ehhez a tranzakcióhoz... hm... три триллиона и семь. Kérjük, ismételje meg ezt a számot." A modern böngészőknek van valami úgynevezett "azonos eredetű szabályzata", amely szerint az A webhelyen található szkriptek nem férnek hozzá a B webhely által küldött információkhoz. Tehát a szkript evil.com címre küldhet kéréseket google.com, de nem tudja elolvasni a válaszokat, és nem tudja végrehajtani a tranzakciót.

Hangsúlyoznunk kell, hogy ha Bob nem használ titkosított kapcsolatot, ezek a védelem értelmetlen. A támadó egyszerűen elolvashatja Bob forgalmát, és visszaállíthatja a Google munkamenet-cookie-ját. Ezzel a cookie-val egyszerűen megnyit egy új Google-lapot anélkül, hogy elhagyná saját böngészőjét, és Bobnak adja ki magát anélkül, hogy bosszantó, azonos eredetű irányelvekkel találkozna. De sajnos a betörőknél ez egyre ritkább. Az internet egésze már régóta hadat üzent a titkosítatlan kapcsolatoknak, és Bob kimenő forgalma valószínűleg titkosított, akár tetszik, akár nem. Emellett a protokoll végrehajtásának kezdetétől forgalom is volt összement titkosítás előtt; ez általános gyakorlat volt a késleltetés csökkentésére.

Itt jön képbe BŰN (Kompressziós arány Infoleak Made Easy, egyszerű szivárgás a tömörítési arányon keresztül). A sebezhetőséget 2012 szeptemberében tárták fel Juliano Rizzo és Thai Duong biztonsági kutatók. Már megvizsgáltuk a teljes elméleti alapot, amely lehetővé teszi számunkra, hogy megértsük, mit és hogyan csináltak. A támadó arra kényszerítheti Bob böngészőjét, hogy kéréseket küldjön a Google-nak, majd tömörített, titkosított formában hallgassa meg a válaszokat a helyi hálózaton. Ezért rendelkezünk:

Itt a támadó irányítja a kérést, és hozzáférhet a forgalomszimulálóhoz, beleértve a csomagméretet is. Kelsey kitalált forgatókönyve életre kelt.

Az elmélet megértésével a CRIME szerzői egy olyan kihasználást hoztak létre, amely munkamenet-cookie-kat lophat számos webhelyhez, beleértve a Gmailt, a Twittert, a Dropboxot és a Githubot. A sérülékenység a legtöbb modern webböngészőt érintette, így olyan javításokat adtak ki, amelyek csendben temették el az SSL tömörítési funkcióját, így az egyáltalán nem használható. A sebezhetőség ellen egyedül a tiszteletreméltó Internet Explorer védett, amely soha nem használt SSL-tömörítést.

USZKÁR

2014 októberében a Google biztonsági csapata hullámokat vert a biztonsági közösségben. Ki tudták használni az SSL protokoll egy több mint tíz éve javított sebezhetőségét.

Kiderült, hogy miközben a kiszolgálókon a fényes, új TLSv1.2 fut, sokan meghagyták a régi SSLv3 támogatását az Internet Explorer 6-tal való visszamenőleges kompatibilitás érdekében. A leminősítési támadásokról már beszéltünk, így elképzelhető, hogy mi történik. A handshake protokoll jól megtervezett szabotálása, és a szerverek készen állnak arra, hogy visszatérjenek a jó öreg SSLv3-hoz, lényegében visszavonva az elmúlt 15 év biztonsági kutatásait.

A történelmi kontextushoz íme egy rövid összefoglaló az SSL történetéről a 2-es verzióig Matthew Greentől:

A Transport Layer Security (TLS) a legfontosabb biztonsági protokoll az interneten. [..] szinte minden internetes tranzakció a TLS-től függ. [..] De a TLS nem mindig volt TLS. A protokoll ben kezdte meg életét Netscape Communications "Secure Sockets Layer" vagy SSL. A pletykák szerint az SSL első verziója annyira szörnyű volt, hogy a fejlesztők összegyűjtötték a kód összes kinyomtatott részét, és egy titkos hulladéklerakóba temették el Új-Mexikóban. Ennek következtében az SSL első nyilvánosan elérhető verziója valójában SSL 2 verzió. Elég ijesztő, és [..] a 90-es évek közepének terméke volt, amelyre a modern kriptográfusok úgy tekintenek, mint "a kriptográfia sötét korszaka" A ma ismert legborzalmasabb kriptográfiai támadások közül sokat még nem fedeztek fel. Ennek eredményeként az SSLv2 protokoll fejlesztőinek lényegében a sötétben kellett tapogatózniuk, és szembe kellett nézniük sok szörnyű szörnyeteg - bánatukra és a mi hasznunkra, mivel az SSLv2 elleni támadások felbecsülhetetlen tanulságokat adtak a protokollok következő generációja számára.

Ezeket az eseményeket követően 1996-ban egy csalódott Netscape a semmiből újratervezte az SSL protokollt. Az eredmény az SSL 3-as verziója lett, amely kijavította az elődje számos ismert biztonsági problémáját.

A betörők szerencséjére a „néhány” nem azt jelenti, hogy „minden”. Összességében az SSLv3 minden szükséges építőelemet biztosított a Vodene támadás elindításához. A protokoll CBC módú blokk-rejtjelet és nem biztonságos kitöltési sémát használt (ezt a TLS-ben kijavították; ezért volt szükség egy downgrade támadásra). Ha emlékszel a Vaudenay-támadás eredeti leírásában szereplő kitöltési sémára, az SSLv3 séma nagyon hasonló.

De sajnos a betörők számára a „hasonló” nem azt jelenti, hogy „azonos”. Az SSLv3 kitöltési séma "N véletlenszerű bájt, amelyet az N szám követ". Ilyen körülmények között próbáljon meg kiválasztani egy képzeletbeli rejtjelezett szövegblokkot, és menjen végig Vaudene eredeti sémájának minden lépésén: azt fogja tapasztalni, hogy a támadás sikeresen kivonja az utolsó bájtot a megfelelő nyílt szövegblokkból, de nem megy tovább. A rejtjelezett szöveg minden 16. bájtjának visszafejtése nagyszerű trükk, de nem győzelem.

A kudarc miatt a Google csapata a végső megoldáshoz folyamodott: egy erősebb fenyegetési modellre váltott – a BŰNÖZÉSben használt modellre. Feltételezve, hogy a támadó egy szkript, amely az áldozat böngészőlapján fut, és képes munkamenet-cookie-kat kinyerni, a támadás továbbra is lenyűgöző. Míg a tágabb fenyegetési modell kevésbé reális, az előző részben láttuk, hogy ez a modell megvalósítható.

Tekintettel ezekre az erősebb támadóképességekre, a támadás most folytatódhat. Vegye figyelembe, hogy a támadó tudja, hol jelenik meg a titkosított munkamenet-cookie a fejlécben, és szabályozza az azt megelőző HTTP-kérés hosszát. Ezért képes úgy manipulálni a HTTP kérést, hogy a cookie utolsó bájtja a blokk végéhez igazodjon. Most ez a bájt alkalmas a visszafejtésre. Egyszerűen hozzáadhat egy karaktert a kéréshez, és a cookie utolsó előtti bájtja ugyanazon a helyen marad, és ugyanazzal a módszerrel kiválasztható. A támadás így folytatódik, amíg a cookie-fájl teljesen vissza nem áll. Úgy hívják POODLE: Padding Oracle on Downgraded Legacy Encryption.

MEGFULLAD

Mint említettük, az SSLv3-nak megvoltak a hibái, de alapvetően különbözött elődjétől, hiszen a kiszivárgott SSLv2 egy másik kor terméke volt. Ott megszakíthatja az üzenetet középen: соглашусь на это только через мой труп vált соглашусь на это; a kliens és a szerver online találkozhat, bizalmat létesíthet és titkokat cserélhetett a támadó előtt, aki ezután könnyen megszemélyesítheti mindkettőt. Az export kriptográfiával is van probléma, amelyet a FREAK mérlegelésekor említettünk. Ezek a titkosítási Szodoma és Gomora voltak.

2016 márciusában a különböző műszaki területek kutatóiból álló csapat összeállt, és megdöbbentő 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 visszaminősíteni a modern TLS-munkameneteket SSLv2-re, mivel ezt a lyukat a FREAK és a POODLE után bezárták, de továbbra is tudnak csatlakozni a szerverekhez, és maguk kezdeményezhetnek SSLv2-munkameneteket.

Kérdezheti, miért érdekel minket, hogy mit csinálnak ott? Van egy sebezhető munkamenetük, de ez nem érintheti a többi munkamenetet vagy a szerver biztonságát – igaz? Hát nem egészen. Igen, ennek elméletben így kell lennie. De nem – mert az SSL-tanúsítványok előállítása bizonyos terhet ró, ami azt eredményezi, hogy sok szerver ugyanazokat a tanúsítványokat használja, és ennek eredményeként ugyanazokat az RSA-kulcsokat a TLS és SSLv2 kapcsolatokhoz. Tovább rontja a helyzetet, hogy egy OpenSSL-hiba miatt az "SSLv2 letiltása" opció ebben a népszerű SSL-megvalósításban nem működött.

Ez lehetővé tette a TLS elleni protokollok közötti támadást, az ún MEGFULLAD (RSA visszafejtése elavult és gyengített titkosítással, RSA visszafejtése elavult és gyengített titkosítással). Emlékezzünk vissza, hogy ez nem ugyanaz, mint egy rövid támadás; a támadónak nem kell "emberként" viselkednie, és nem kell bevonnia az ügyfelet, hogy részt vegyen egy nem biztonságos munkamenetben. A támadók egyszerűen maguk kezdeményeznek egy nem biztonságos SSLv2 munkamenetet a szerverrel, megtámadják a gyenge protokollt, és visszaállítják a szerver RSA privát kulcsát. Ez a kulcs a TLS-kapcsolatokra is érvényes, és innentől kezdve semmilyen TLS-biztonság nem akadályozza meg a feltörését.

De a feltöréséhez szükség van egy működő támadásra az SSLv2 ellen, amely lehetővé teszi nem csak az adott forgalom helyreállítását, hanem a titkos RSA-kiszolgálókulcsot is. Noha ez egy összetett beállítás, a kutatók bármilyen sérülékenységet választhatnak, amely az SSLv2 után teljesen bezárt. Végül találtak egy megfelelő lehetőséget: a Bleichenbacher-támadást, amelyről korábban már beszéltünk, és amelyet a következő cikkben részletesen kifejtünk. Az SSL és a TLS védve van ettől a támadástól, de az SSL néhány véletlenszerű funkciója az export-minőségű kriptográfia rövid kulcsaival kombinálva lehetővé tette. a DROWN konkrét megvalósítása.

A közzététel időpontjában az internet legnépszerűbb oldalainak 25%-át érintette a DROWN sebezhetősége, és a támadást szerény erőforrásokkal lehetett végrehajtani, amelyek még a huncut magányos hackerek számára is elérhetőek voltak. A szerver RSA-kulcsának lekérése nyolc óra számítást és 440 dollárt igényelt, és az SSLv2 elavultból radioaktívvá vált.

Várj, mi lesz a Heartbleed-el?

Ez nem kriptográfiai támadás a fent leírt értelemben; Ez egy puffer túlcsordulás.

Tartsunk szünetet

Néhány alapvető technikával kezdtük: nyers erő, interpoláció, leminősítés, keresztprotokoll és előszámítás. Ezután megvizsgáltunk egy fejlett technikát, talán a modern kriptográfiai támadások fő összetevőjét: az orákulumtámadást. Elég sok időt töltöttünk annak kitalálásával – és nem csak a mögöttes elvet értettük meg, hanem két konkrét megvalósítás technikai részleteit is: a Vaudenay-támadást a CBC titkosítási mód ellen és a Kelsey-támadást a tömörítés előtti titkosítási protokollok ellen.

A leminősítési és előreszámítási támadások áttekintése során röviden felvázoltuk a FREAK támadást, amely mindkét módszert használja úgy, hogy a célhelyeket gyenge kulcsokra állítja vissza, majd újra felhasználja ugyanazokat a kulcsokat. A következő cikkben elmentjük a (nagyon hasonló) Logjam támadást, amely nyilvános kulcsú algoritmusokat céloz meg.

Ezután további három példát néztünk meg ezen elvek alkalmazására. Először is a BŰNÖZÉS és a POODLE: két támadás, amelyek a támadó azon képességére támaszkodtak, hogy tetszőleges nyílt szöveget fecskendezzen be a cél nyílt szöveg mellé, majd megvizsgálják a szerver válaszait és majd,az Oracle attack módszertan használatával használja ki ezt a ritka információt az egyszerű szöveg részbeni helyreállítására. A BŰNÖZÉS Kelsey SSL-tömörítés elleni támadásának útját járta, míg a POODLE ehelyett Vaudenay CBC elleni támadásának egy változatát használta, ugyanolyan hatással.

Ezután figyelmünket a protokollok közötti DROWN támadásra irányítottuk, amely a régebbi SSLv2 protokoll segítségével létesít kapcsolatot a szerverrel, majd a Bleichenbacher támadás segítségével visszaállítja a szerver titkos kulcsait. A támadás technikai részleteit egyelőre kihagytuk; A Logjamhoz hasonlóan ennek is várnia kell, amíg jól megértjük a nyilvános kulcsú kriptorendszereket és azok sebezhetőségét.

A következő cikkben az olyan fejlett támadásokról fogunk beszélni, mint a találkozás a közepén, a differenciális kriptográfiai elemzés és a születésnapi támadások. Vegyünk egy gyors bepillantást az oldalcsatornás támadásokba, majd térjünk át a szórakoztató részre: a nyilvános kulcsú kriptorendszerekre.

Forrás: will.com