Na słowo „kryptografia” niektórzy przypominają sobie swoje hasło WiFi, zieloną kłódkę obok adresu ulubionej strony oraz trudności w włamaniu się do czyjejś poczty. Inni myślą o szeregu luk bezpieczeństwa z ostatnich lat z mówiącymi skrótami (DROWN, FREAK, POODLE…) oraz stylowymi logotypami i ostrzeżeniem o pilnej aktualizacji przeglądarki.

Kryptografia obejmuje to wszystko, ale istota tkwi w czymś innym. Istota polega na subtelnej granicy między tym, co proste, a tym, co złożone. Niektóre rzeczy łatwo wykonać, ale trudno je cofnąć, na przykład rozbić jajko. Inne rzeczy są łatwe do zrobienia, ale trudno je cofnąć, gdy brakuje małego, ale istotnego elementu decydującego, na przykład otworzenie zamkniętych drzwi, kiedy „kluczowym elementem” jest klucz. Kryptografia bada te sytuacje i sposoby ich praktycznego wykorzystania.

W ciągu ostatnich lat zbiór ataków kryptograficznych stał się zoo krzyczących logotypów, wypełnionych wzorami z artykułów naukowych i stworzył ogólne mroczne odczucie, że wszystko jest zepsute. W rzeczywistości wiele z ataków opiera się na kilku wspólnych zasadach, a nieskończone strony wzorów często sprowadzają się do prostych idei.

W tej serii artykułów omówimy różne typy ataków kryptograficznych, koncentrując się na podstawowych zasadach. W ogólnych zarysach i niekoniecznie w tej kolejności, przekazujemy poniższe informacje:

• Podstawowe strategie: brute force, analiza częstotliwości, interpolacja, obniżanie oraz protokoły krzyżowe.
• „Markowe” luki zabezpieczeń: FREAK, CRIME, POODLE, DROWN, Logjam.
• Zaawansowane strategie: ataki orakuli (atak Waterner, atak Kelsey); metoda spotkania w połowie (meet-in-the-middle), atak „urodzinowy”, statystyczne odchylenie (analiza różnicowa, analiza całkowa itd.).
• Ataki kanałami bocznymi i ich bliscy krewni, metody analizy awarii.
• Ataki na kryptografię z otwartym kluczem: pierwiastek sześcienny, nadawanie, powiązane wiadomości, atak Coppersmitha, algorytm Pollarda-Hellmana, sito liczbowe, atak Wienera, atak Bleichenbachera.

Ten konkretny artykuł obejmuje powyżej wymienione materiały aż do ataku Kelsey.

Podstawowe strategie

Następujące ataki są proste w tym sensie, że można je prawie całkowicie wyjaśnić bez szczególnych szczegółów technicznych. Wyjaśnimy każdy typ ataku w najprostszych terminach, nie zgłębiając złożonych przykładów ani zaawansowanych zastosowań.

Niektóre z tych ataków w zasadzie straciły na znaczeniu i nie były stosowane od lat. Inne to starzy wyjadacze, które wciąż regularnie podkradają się do niczego niepodejrzewających programistów kryptosystemów w XXI wieku. Można uznać, że era nowoczesnej kryptografii rozpoczęła się wraz z pojawieniem się IBM DES - pierwszego szyfru, który wytrzymał wszystkie ataki z tej listy.

Prosty bruteforce

Schemat szyfrowania składa się z dwóch części: 1) funkcji szyfrowania, która przyjmuje wiadomość (tekst jawny) w połączeniu z kluczem, a następnie tworzy zaszyfrowaną wiadomość - tekst szyfrowy; 2) funkcji deszyfrowania, która przyjmuje tekst szyfrowy i klucz i generuje tekst jawny. Zarówno szyfrowanie, jak i deszyfrowanie powinny być łatwe do obliczenia z kluczem - i trudne bez niego.

Załóżmy, że widzimy tekst szyfrowy i próbujemy go odszyfrować bez jakichkolwiek dodatkowych informacji (nazywa się to atakiem typu „tylko tekst szyfrowy”). Jeśli w jakiś sposób znajdziemy właściwy klucz, możemy łatwo sprawdzić, czy jest rzeczywiście poprawny, jeśli wynik jest sensownym komunikatem.

Zauważ, że tutaj są dwa niejawne założenia. Po pierwsze, że wiemy, jak przeprowadzić deszyfrowanie, to znaczy, jak działa kryptosystem. To standardowe założenie przy omawianiu kryptografii. Ukrywanie szczegółów implementacji szyfru przed przestępcami może wydawać się dodatkowymi środkami bezpieczeństwa, ale gdy tylko przestępca ustali te szczegóły, dodatkowe bezpieczeństwo znika bezpowrotnie. Tak działa zasada Kerckhoffa: przejęcie systemu przez wroga nie powinno sprawiać kłopotów.

Po drugie, zakładamy, że poprawny klucz jest jedynym kluczem, który prowadzi do sensownego odszyfrowania. To również rozsądne założenie; spełnia się, jeśli tekst szyfrowy jest znacznie dłuższy od klucza i dobrze czytelny. Zazwyczaj tak jest w rzeczywistym świecie, z wyjątkiem ogromnych niepraktycznych kluczy lub innych machinacji, które lepiej pozostawić na boku. (jeśli nie podoba Ci się, że zlekceważyliśmy wyjaśnienia, proszę zapoznaj się z twierdzeniem 3.8 tutaj).

Biorąc pod uwagę powyższe, pojawia się strategia: sprawdzić każdy możliwy klucz. Nazywa się to atakiem brute force, a taka metoda gwarantowanie działa przeciwko wszystkim praktycznym szyfrom — w końcu. Na przykład, brute force wystarcza, aby złamać szyfr Cezara, starożytnego szyfru, w którym kluczem jest jedna litera z alfabetu, co oznacza nieco ponad 20 możliwych kluczy.

Niestety dla analityków kryptograficznych, zwiększenie rozmiaru klucza dobrze chroni przed brute force. W miarę wzrostu rozmiaru klucza liczba możliwych kluczy rośnie eksponencjalnie. Przy nowoczesnych rozmiarach kluczy prosty brute force jest całkowicie niepraktyczny. Aby zrozumieć, co mamy na myśli, weźmy na przykład najszybszy znany superkomputer na połowę 2019 roku: Summit od IBM, z szczytową wydajnością na poziomie około 10^17 operacji na sekundę. Dziś typowa długość klucza wynosi 128 bitów, co oznacza 2^128 możliwych kombinacji. Aby przetestować wszystkie klucze, superkomputer Summit potrzebowałby czasu, który jest około 7800 razy dłuższy niż wiek Wszechświata.

Czy traktować brute force jako historyczny curiosum? Zdecydowanie nie: to niezbędny składnik w książce kucharskiej analizy kryptograficznej. Rzadko spotyka się tak słabe szyfry, że można je złamać tylko za pomocą inteligentnego ataku, bez użycia siły w jakimkolwiek stopniu. Wiele udanych włamań najpierw wykorzystuje metodę algorytmiczną, aby osłabić docelowy szyfr, a następnie uruchamia brute force.

Analiza częstotliwości

Większość tekstów to nie bełkot. Na przykład w tekstach anglojęzycznych jest wiele liter 'e' oraz artykułów 'the'; w plikach binarnych — wiele zerowych bajtów jako wypełniacza między fragmentami informacji. Analiza częstotliwości — to każdy atak, który wykorzystuje ten fakt.

Kanonicznym przykładem szyfru, podatnego na ten atak, jest prosty szyfr podstawieniowy. W tym szyfrze klucz stanowi tabela, w której zastępuje się wszystkie litery. Na przykład 'g' zamienia się na 'h', 'o' — na 'j', więc słowo 'go' zamienia się w 'hj'. Ten szyfr trudno poddaje się prostemu brute force, ponieważ istnieje bardzo wiele możliwych tabel podstawieniowych. Jeśli interesuje Cię matematyka, efektywna długość klucza wynosi około 88 bitów: to
. Ale analiza częstotliwości zazwyczaj szybko radzi sobie z tym zadaniem.

Rozważmy następujący szyfr, przetworzony prostym szyfrem podstawieniowym:

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

Ponieważ Y występuje często, w tym na końcu wielu słów, możemy wstępnie założyć, że to litera e:

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

Para XD powtarza się na początku kilku słów. W szczególności zestawienie XDeLe wyraźnie sugeruje słowo these lub there, dlatego kontynuujemy:

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

Następnie załóżmy, że L -the node, and the other — r, A — a i tak dalej. Prawdopodobnie będzie trzeba przeprowadzić kilka prób, ale w porównaniu do pełnego ataku brute force, ta metoda przywraca oryginalny tekst w krótkim czasie:

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

Dla niektórych rozwiązanie takich "kryptogramów" to fascynujące hobby.

Pomysł analizy częstotliwości jest bardziej fundamentalny, niż się wydaje. I ma zastosowanie w znacznie bardziej złożonych szyfrach. Na przestrzeni dziejów różne konstrukcje szyfrów próbowały przeciwstawić się takim atakom za pomocą „polialfabetycznych podstawień”. Tutaj, w procesie szyfrowania, tabela zamiany liter zmienia się w skomplikowany, ale przewidywalny sposób, zależny od klucza. Wszystkie te szyfry uważano niegdyś za trudne do złamania; jednak skromna analiza częstotliwości ostatecznie je wszystkie pokonała.

Najbardziej ambitnym polialfabetycznym szyfrem w historii i prawdopodobnie najsłynniejszym była Enigma w czasie II wojny światowej. Była stosunkowo skomplikowana w porównaniu do swoich poprzedników, ale w wyniku długiej i ciężkiej pracy brytyjscy kryptolodzy złamali ją przy pomocy analizy częstotliwości. Oczywiście nie byli w stanie opracować eleganckiego ataku, jak pokazano powyżej; musieli porównywać znane pary tekstów otwartych i zaszyfrowanych (tzw. „atak oparty na tekście jawnym”) i nawet prowokować użytkowników Enigmy do szyfrowania określonych wiadomości z analizą wyników („atak oparty na dobranym tekście jawnym”). Ale to nie ulżyło losowi pokonanych armii wrogów i zatopionych okrętów podwodnych.

Po tym zwycięstwie analiza częstotliwości zniknęła z historii kryptanalizy. Szyfry nowej epoki cyfrowej zostały zaprojektowane do pracy z bitami, a nie literami. Co jeszcze ważniejsze, te szyfry zostały opracowane z ponurym zrozumieniem tego, co później zostało określone jako prawo Schneiera: każdy może stworzyć algorytm szyfrowania, którego sam nie będzie w stanie złamać. Nie wystarczy, aby system szyfrowania wydawał się skomplikowany: aby udowodnić swoją wartość, musi przejść bezwzględną ocenę bezpieczeństwa przeprowadzaną przez wielu kryptanalityków, którzy zrobią wszystko, aby złamać szyfr.

Wstępne obliczenia

Załóżmy hipotetyczne miasto Prekom Heights z populacją 200 000 mieszkańców. W każdym domu w mieście znajdują się wartościowe przedmioty o średniej wartości 30 000 USD, ale nie więcej niż 50 000 USD. Rynek zabezpieczeń w Prekomie został zmonopolizowany przez firmę ACME Industries, która produkuje legendarne zamki drzwiowe klasy Coyote ™. Zdaniem ekspertów, zamek klasy Coyote może złamać tylko bardzo złożona hipotetyczna maszyna, której stworzenie wymaga około pięciu lat i 50 000 USD inwestycji. Czy miasto jest bezpieczne?

Prawdopodobnie nie. W końcu pojawi się wystarczająco ambitny przestępca. Będzie rozważał tak: „Tak, poniosę duże wydatki wstępne. Pięć lat cierpliwego czekania i 50 000 USD. Ale na koniec mojej pracy będę miał dostęp do wszystkiego bogactwa tego miasta. Jeśli właściwie zagram swoje karty, ta inwestycja wielokrotnie się zwróci.”

Podobnie jest w kryptografii. Ataki na konkretny szyfr poddawane są bezwzględnej analizie kosztów i korzyści. Jeśli proporcja jest korzystna, atak się nie nastąpi. Ale ataki, które działają jednocześnie przeciwko wielu potencjalnym ofiarom, prawie zawsze się opłacają, a w tym przypadku najlepsza praktyka projektowania polega na założeniu, że zaczęły się one od pierwszego dnia. Mamy w zasadzie kryptograficzną wersję prawa Murphy'ego: „Wszystko, co rzeczywiście może złamać system, złamie system.”

Najprostszy przykład kryptosystemu, podatnego na atak z wstępnymi obliczeniami, to szyfr o stałym algorytmie bez użycia klucza. Tak było w przypadku szyfru Cezara, który po prostu przesuwa każdą literę alfabetu o trzy litery do przodu (tabela jest okrągła, więc ostatnia litera alfabetu jest szyfrowana trzecią). Tutaj znowu ujawnia się zasada Kerckhoffa: gdy tylko system zostanie złamany, pozostaje złamany na zawsze.

Koncepcja jest prosta. Nawet początkujący programista systemów kryptograficznych prawdopodobnie zdaje sobie sprawę z zagrożenia i odpowiednio się przygotowuje. Patrząc na ewolucję kryptografii, takie ataki były nieistotne dla większości szyfrów, począwszy od pierwszych ulepszonych wersji szyfru Cezara, aż po schyłek szyfrów polialfabetycznych. Takie ataki wróciły tylko z nadejściem nowoczesnej ery kryptografii.

To powrót jest spowodowany dwoma czynnikami. Po pierwsze, w końcu pojawiły się wystarczająco zaawansowane systemy kryptograficzne, w których możliwość eksploatacji po złamaniu nie była oczywista. Po drugie, kryptografia stała się tak powszechna, że miliony nieprofesjonalistów podejmowały codzienne decyzje, gdzie i jakie części kryptografii wykorzystać ponownie. Zajęło trochę czasu, zanim eksperci uświadomili sobie powstałe ryzyko i podnieśli alarm.

Zapamiętaj atak prekomputerowy: na końcu artykułu przyjrzymy się dwóm rzeczywistym przykładom kryptograficznym, gdzie odegrał on istotną rolę.

Interpolacja

Przed wami słynny detektyw Sherlock Holmes, dokonujący ataku z interpolacją na nieszczęśliwego doktora Watsona:

Od razu zrozumiałem, że przyjechałeś z Afganistanu… Moje myśli były takie: „Ten człowiek typowo — lekarz, ale ma wojskową postawę. Więc medyk wojskowy. Dopiero co wrócił z tropików — ma ciemną cerę, ale to nie naturalny kolor jego skóry, ponieważ nadgarstki ma znacznie bielsze. Twarz wyniszczona — oczywiście sporo się nacierpiał i przeszedł chorobę. Został ranny w lewą rękę — trzyma ją nieruchomo i trochę nienaturalnie. Gdzie mógł się zmagać z trudnościami i doznać rany angielski lekarz wojskowy w tropikach? Oczywiście, w Afganistanie”. Cały tok myśli nie zajął mi ani sekundy. I tak powiedziałem, że przyjechałeś z Afganistanu, a ty się zdziwiłeś.

Z każdego ula Holmes mógł wyciągnąć bardzo mało informacji. Mógł dojść do swojego wniosku tylko rozpatrując je wszystkie razem. Analogicznie działa atak interpolacyjny, badając znane pary tekstu jawnego i zaszyfrowanego, uzyskane w wyniku zastosowania tego samego klucza. Z każdej pary wyciągane są pojedyncze obserwacje, które pozwalają na ogólne wnioski o kluczu. Wszystkie te rozumowania są niejasne i wydają się bezużyteczne, aż nagle osiągną krytyczną masę i doprowadzą do jedynego możliwego wniosku: jak niewiarygodny by on nie był, musi być prawdziwy. Po tym albo klucz zostaje ujawniony, albo proces deszyfrowania staje się na tyle dopracowany, że można go reprodukować.

Zilustrujmy w prostym przykładzie, jak działa interpolacja. Załóżmy, że chcemy przeczytać osobisty dziennik naszego wroga, Boba. Szyfruje on każdą liczbę w swoim dzienniku za pomocą prostej kryptosystemu, o którym dowiedział się z reklamy w magazynie „Kpiąc z kryptografii”. System działa w następujący sposób: Bob wybiera dwie liczby, które mu się podobają: i . Od teraz, aby zaszyfrować dowolną liczbę , oblicza . Na przykład, jeśli Bob wybrał i , to cyfra zostanie zaszyfrowana jako .

Załóżmy, że 28 grudnia zauważamy, że Bob coś skreśla w swoim dzienniku. Kiedy skończy, niepostrzeżenie go weźmiemy i sprawdzimy ostatni wpis:

Data: 235/520

Drogi dzienniku,

Dziś był dobry dzień. Za 64 dni mam randkę z Alicją, która mieszka w mieszkaniu 843. Naprawdę myślę, że może być 26!

Ponieważ jesteśmy bardzo poważnie zdeterminowani, aby śledzić Boba na jego randce (w tym scenariuszu mamy po 15 lat), krytycznie ważne jest, aby poznać zarówno datę, jak i adres Alicji. Na szczęście dostrzegamy, że kryptosystem Boba jest podatny na atak interpolacyjny. Może nie znamy i , ale znamy dzisiejszą datę, więc mamy dwie pary „tekst jawny — tekst zaszyfrowany”. A mianowicie, wiemy, że szyfruje się w , a — w . Co zapisujemy:

Ponieważ mamy 15 lat, już wiemy o układzie dwóch równań z dwiema niewiadomymi, co w tej sytuacji wystarcza do znalezienia. i bez większych problemów. Każda para „jawny tekst-szyfrogram” nakłada ograniczenie na klucz Boba, a dwa ograniczenia razem są wystarczające, aby całkowicie odzyskać klucz. W naszym przykładzie odpowiedź i (przy , więc 26 w dzienniku odpowiada słowu ‘the one’, czyli „ta jedna” — przyp. tłum.

Ataki interpolacyjne, oczywiście, nie ograniczają się do tak prostych przykładów. Każdy system kryptograficzny, który sprowadza się do dobrze zrozumiałego obiektu matematycznego i listy parametrów, jest narażony na ryzyko ataku interpolacyjnego — im bardziej obiekt jest zrozumiały, tym wyższe ryzyko.

Nowicjusze często narzekają, że kryptografia to „sztuka projektowania jak najbardziej brzydkich rzeczy”. Prawdopodobnie dużą winę ponoszą ataki interpolacyjne. Bob może albo użyć eleganckiego projektu matematycznego, albo zachować prywatność spotkania z Alicją — ale niestety, zazwyczaj nie można mieć obu rzeczy jednocześnie. To stanie się zupełnie jasne, kiedy w końcu przejdziemy do tematu kryptografii z kluczem publicznym.

Cross-protocol/downgrade

W filmie „Iluzja oszustwa” (2013) grupa iluzjonistów próbuje wyłudzić cały majątek skorumpowanego magnata ubezpieczeniowego Arthura Tresslera. Aby uzyskać dostęp do konta bankowego Arthura, iluzjoniści muszą albo przedstawić jego nazwę użytkownika i hasło, albo zmusić go do osobistego stawienia się w banku i wzięcia udziału w schemacie.

Obie opcje są bardzo trudne; goście są przyzwyczajeni do występów na scenie, a nie do działania w operacjach służb specjalnych. Dlatego wybierają trzeci możliwy wariant: ich wspólnik dzwoni do banku i podaje się za Arthura. Bank zadaje kilka pytań weryfikacyjnych, takich jak imię wujka i imię pierwszego zwierzęcia; nasi bohaterowie wcześniej łatwo wyciągają od Arthura te informacje dzięki sprawnej inżynierii społecznej.. Od tego momentu doskonałe zabezpieczenie hasła przestaje mieć znaczenie.

(Zgodnie z miejską legendą, którą osobiście sprawdziliśmy i potwierdziliśmy, kryptograf Eli Biham raz natknął się na kasjera bankowego, który nalegał na ustalenie pytania zabezpieczającego. Kiedy kasjer zapytał o imię babci ze strony matki, Biham zaczął dyktować: „Duża X, mała y, trzy…”).

Tak samo jak w kryptografii, jeśli do ochrony tego samego aktywa równolegle używane są dwa protokoły kryptograficzne, z czego jeden jest znacznie słabszy od drugiego. Ostateczny system staje się podatny na atak międzyprotokołowy, gdy atakuje się słabszy protokół, aby dostać się do nagrody, nie dotykając silniejszego.

W niektórych skomplikowanych przypadkach nie wystarczy po prostu skontaktować się z serwerem przez słabszy protokół, lecz wymagana jest nieświadoma współpraca legitymowanego klienta. Można to zrealizować za pomocą tzw. ataku na obniżenie (downgrade). Aby zrozumieć ten atak, załóżmy, że nasi iluzjoniści mają trudniejsze zadanie niż w filmie. Załóżmy, że pomiędzy pracownikiem banku (kasjerem) a Arturem pojawiają się jakieś nieprzewidziane okoliczności, w wyniku czego dochodzi do takiego dialogu:

Haker: Halo? To Arthur Tressler. Chciałbym zresetować swoje hasło.

Kasjer: Świetnie. Proszę spojrzeć na swoją osobistą księgę sekretów, strona 28, słowo 3. Wszystkie następne wiadomości będą szyfrowane za pomocą tego konkretnego słowa jako klucza. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Haker: Hej, hej, poczekaj, poczekaj. Czy to naprawdę jest konieczne? Czy nie możemy po prostu rozmawiać jak normalni ludzie?

Kasjer: Nie radzę tego robić.

Haker: Po prostu… słuchaj, miałem okropny dzień, rozumiesz? Jestem klientem VIP i nie mam nastroju, aby grzebać w tych głupich kodach.

Kasjer: Dobrze. Jeśli tak uparcie chcesz, panie Tressler. Czego sobie życzysz?

Haker: Proszę, chciałbym przekazać wszystkie swoje pieniądze do Krajowego Funduszu Ofiar Arthura Tresslera.

(Pauza).

Kasjer: Rozumiem. Proszę podać swój kod PIN do dużych transakcji.

Haker: Mój co?

Kasjer: Na Pańską osobistą prośbę transakcje tego rozmiaru wymagają wprowadzenia kodu PIN do dużych transakcji. Ten kod został Państwu wydany przy otwarciu konta.

Haker:… Zgubiłem go. Czy to naprawdę konieczne? Nie możecie po prostu zatwierdzić transakcji?

Kasjer: Nie. Przykro mi, panie Tressler. Po raz kolejny, to środek bezpieczeństwa, o który prosiłeś. Jeśli chcesz, możemy wysłać nowy kod PIN na Twój adres e-mail.

Nasi bohaterowie odkładają operację. Podsłuchują kilka dużych transakcji Treslera, mając nadzieję usłyszeć pin; ale za każdym razem rozmowa zamienia się w zaszyfrowany bełkot, zanim padnie coś interesującego. W końcu, pewnego pięknego dnia wprowadzają plan w życie. Cierpliwie czekają na moment, kiedy Tresler ma wykonać dużą transakcję przez telefon, łączy się z linią, a potem...

Tresler: Dzień dobry. Chciałbym zrealizować zdalną transakcję, proszę.

Kasjer: Świetnie. Proszę zajrzeć do swojej osobistej książki kodów, strona...

(Haker naciska przycisk; głos kasjera zamienia się w niezrozumiały szum).

Kasjer: — #@$#@$#*@$$@#* będzie zaszyfrowany tym słowem jako kluczem. AAAYRR PLRQRZ MMNJK LOJBAN…

Tresler: Przepraszam, nie do końca rozumiem. Jeszcze raz? Na której stronie? Jakie słowo?

Kasjer: To strona @#$@#*$)#*#@()#@$(#@*$(#@*.

Tresler: Co?

Kasjer: Słowo numer dwadzieścia @$#@$#%#$.

Tresler: Na serio! Dość już! Twój protokół bezpieczeństwa to jakiś cyrk. Wiem, że możesz po prostu normalnie ze mną porozmawiać.

Kasjer: Nie radzę...

Tresler: A ja ci nie radzę tracić mojego czasu. Nie chcę już o tym słyszeć, dopóki nie naprawicie problemów z waszą linią telefoniczną. Czy możemy zrealizować tę transakcję, czy nie?

Kasjer:... tak. Dobrze. Czego sobie życzysz?

Tresler: Chciałbym przelać 20 000 dolarów na konto Lord Business Investments, numer konta...

Kasjer: Chwileczkę, proszę. To duża transakcja. Proszę podać swój pin do dużych transakcji.

Tresler: Co? A, oczywiście. 1234.

Oto atak na obniżenie. Słabszy protokół „mów prosto” miał być zamierzony jako opcja na ostateczność. I mimo wszystko jesteśmy tutaj.

Można zadać pytanie, kto w zdrowym zmyśle zaprojektuje prawdziwy system typu „bezpieczny, dopóki nie poprosisz o przeciwny”, jak opisano powyżej. Ale tak jak fikcyjny bank podejmuje ryzyko, aby zatrzymać klientów, którzy nie lubią kryptografii, tak i systemy w całości często ulegają wymaganiom, które są obojętne lub wręcz wrogie wobec bezpieczeństwa.

Dokładnie taka historia miała miejsce z protokołem SSLv2 w 1995 roku. Rząd USA od dawna zaczął postrzegać kryptografię jako broń, którą lepiej trzymać z dala od wrogów zewnętrznych i wewnętrznych. Fragmenty kodu były pojedynczo zatwierdzane do eksportu z USA, często pod warunkiem celowego osłabienia algorytmu. Firmie Netscape, twórcy najpopularniejszej przeglądarki Netscape Navigator, zezwolono na SSLv2 tylko z pierwotnie podatnym kluczem RSA 512-bitowym (i 40-bitowym dla RC4).

Pod koniec millenium zasady złagodzono, a dostęp do nowoczesnej kryptografii stał się powszechny. Mimo to klienci i serwery przez wiele lat korzystali z osłabionej „eksportowej” kryptografii z powodu tej samej inercji, która utrzymuje wsparcie dla jakiegokolwiek przestarzałego systemu. Klienci myśleli, że mogą natknąć się na serwer, który nie obsługuje nic innego. Serwery robiły to samo. Oczywiście protokół SSL nakazuje, że klienci i serwery nigdy nie powinni używać słabego protokołu, gdy dostępny jest lepszy. Ale ta sama przesłanka działała w przypadku Tresstlera i jego banku.

Teoria ta miała zastosowanie w dwóch głośnych atakach, które jeden po drugim wstrząsnęły bezpieczeństwem protokołu SSL w 2015 roku, oba odkryte przez badaczy Microsoft i INRIA. Najpierw w lutym ujawniono szczegóły ataku FREAK, a trzy miesiące później – kolejnego podobnego ataku nazwanego Logjam, który omówimy bardziej szczegółowo, gdy przejdziemy do ataków na kryptografię z kluczem publicznym.

Luka FREAK (znanego również jako „Smack TLS”) ujawnił się, gdy badacze przeanalizowali implementacje klienta/serwera TLS i odkryli ciekawy błąd. W tych implementacjach, jeśli klient nawet nie prosi o użycie słabej eksportowej kryptografii, ale serwer i tak odpowiada takimi kluczami – klient mówi „No dobrze” i przechodzi na słaby zestaw szyfrów.

W tamtym czasie wszyscy uważali eksportową kryptografię za przestarzałą i zabronioną do użytku, dlatego atak był prawdziwym szokiem i dotknął wielu ważnych dziedzin, w tym stron Białego Domu, Urzędu Skarbowego USA i NSA. Co gorsza, okazało się, że wiele podatnych serwerów optymalizowało wydajność, ponownie wykorzystując te same klucze, a nie tworząc nowych dla każdej sesji. To umożliwiło przeprowadzenie po ataku obniżającym protokół ataku z preobliczeniami: złamanie jednego klucza pozostawało stosunkowo kosztowne (100 dolarów i 12 godzin w momencie publikacji), ale praktyczny koszt ataku na połączenie znacznie się obniżył. Wystarczyło raz złamać klucz serwera — i złamać szyfry dla wszystkich kolejnych połączeń od tego momentu.

Zanim przejdziemy dalej, musimy wspomnieć o jednym zaawansowanym ataku…

Atak orakla

Moxie Marlinspike znany jest przede wszystkim jako ojciec międzyplatformowego kryptomessenger-a Signal; ale osobiście podoba nam się jeden z jego mniej znanych wynalazków — zasada kryptograficznej fatum (Cryptographic Doom Principle). Lekko parafrazując, można powiedzieć: „Jeśli protokół wykonuje jakąkolwiek operację kryptograficzną na wiadomości z potencjalnie szkodliwego źródła i zachowuje się różnie w zależności od wyniku, jest skazany na porażkę”. Lub w ostrzejszej formie: „Nie bierz od wroga informacji do przetwarzania, a jeśli musisz, to przynajmniej nie pokazuj wyniku”.

Zostawmy na boku przepełnienia bufora, iniekcje komend i tym podobne; wychodzą one poza ramy tej dyskusji. Naruszenie „zasady fatum” prowadzi do poważnych łamań kryptografii, ponieważ protokół zachowuje się dokładnie tak, jak powinien.

Na przykład weźmy wymyśloną konstrukcję z podatnym szyfrem podstawieniowym, a następnie zaprezentujemy możliwy atak. Choć już widzieliśmy atak na szyfr podstawieniowy przy użyciu analizy częstotliwości, to nie jest po prostu „inny sposób złamania tego samego szyfru”. Przeciwnie, ataki orakla to znacznie nowocześniejsze wynalazki, mające zastosowanie w wielu sytuacjach, gdy analiza częstotliwości zawodzi, a my zobaczymy demonstrowanie tego w następnym rozdziale. Prosty szyfr został wybrany tylko po to, aby uczynić przykład bardziej zrozumiałym.

A więc Alicja i Bob komunikują się za pomocą prostego szyfru podstawieniowego, używając klucza znanego tylko im. Bardzo rygorystycznie podchodzą do długości wiadomości: jej długość wynosi dokładnie 20 znaków. Dlatego zgodzili się, że jeśli ktoś chce wysłać krótszą wiadomość, musi dodać jakiś fikcyjny tekst na końcu wiadomości, aby miała dokładnie 20 znaków. Po pewnej dyskusji zdecydowali, że będą akceptować tylko następujące fikcyjne teksty: a, bb, ccc, dddd itd. W ten sposób znany jest fikcyjny tekst dowolnej potrzebnej długości.

Kiedy Alicja lub Bob otrzymują wiadomość, najpierw sprawdzają, czy wiadomość ma odpowiednią długość (20 znaków) oraz czy suffix to prawidłowy fikcyjny tekst. Jeśli tak nie jest, odpowiadają odpowiednim komunikatem o błędzie. Jeśli długość tekstu i fikcyjny tekst są w porządku, odbiorca czyta samą wiadomość i wysyła zaszyfrowaną odpowiedź.

W trakcie ataku haker podszywa się pod Boba i wysyła fikcyjne wiadomości Alicji. Wiadomości to kompletna bzdura - haker nie ma klucza, więc nie może podrobić sensownej wiadomości. Ale ponieważ protokół narusza zasadę nieuchronności, haker i tak może wciągnąć Alicję w pułapkę, tak aby ujawnili informacje o kluczu, jak pokazano poniżej.

Haker: PREWF ZHJKL MMMN. LA

Alicja: Nieprawidłowy fikcyjny tekst.

Haker: PREWF ZHJKL MMMN. LB

Alicja: Nieprawidłowy fikcyjny tekst.

Haker: PREWF ZHJKL MMMN. LC

Alicja: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Haker nie ma pojęcia, co właśnie powiedziała Alicja, ale zauważa, że symbol C musi pasować do a, ponieważ Alicja zaakceptowała fikcyjny tekst.

Haker: REWF ZHJKL MMMN. LAA

Alicja: Nieprawidłowy fikcyjny tekst.

Haker: REWF ZHJKL MMMN. LBB

Alicja: Nieprawidłowy fikcyjny tekst.

Po kilku próbach…

Haker: REWF ZHJKL MMMN. LGG

Alicja: Nieprawidłowy fikcyjny tekst.

Haker: REWF ZHJKL MMMN. LHH

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

Ponownie haker nie ma pojęcia, co właśnie powiedziała Alicja, ale zauważa, że H powinno pasować do b, ponieważ Alicja zaakceptowała fikcyjny tekst.

I tak dalej, aż haker pozna wartość każdego znaku.

Na pierwszy rzut oka, metoda przypomina atak oparty na dostosowanym tekście jawnym. W końcu atakujący dopasowuje szyfrogramy, a serwer grzecznie je przetwarza. Główna różnica, która sprawia, że te ataki są wykonalne w rzeczywistym świecie, polega na tym, że atakujący nie potrzebuje dostępu do faktycznego odszyfrowania — wystarczy odpowiedź serwera, nawet taka niegroźna jak „Nieprawidłowy fikcyjny tekst”.

Chociaż ten konkretny atak jest pouczający, nie należy zbytnio koncentrować się na specyfice schematu „fikcyjnego tekstu”, konkretnej używanej kryptosystemie czy dokładnej sekwencji wiadomości wysyłanych przez atakującego. Główna idea polega na tym, jak Alicja reaguje w różny sposób na podstawie właściwości tekstu jawnego, i czyni to bez weryfikacji, czy odpowiedni szyfrogram rzeczywiście pochodzi od zaufanej strony. W ten sposób Alicja pozwala atakującemu wydobyć tajne informacje z jej odpowiedzi.

W tym scenariuszu można wiele zmienić. Symbole, na które reaguje Alicja, różnice w jej zachowaniu, a nawet używaną kryptosystemę. Ale zasada pozostanie ta sama, a atak jako całość początkowo będzie nadal wykonalny w pewnej formie. Podstawowa realizacja tego ataku pomogła zidentyfikować kilka błędów bezpieczeństwa, które wkrótce omówimy; ale najpierw warto przyswoić sobie pewne teoretyczne lekcje. Jak wykorzystać ten wymyślony „scenariusz Alicji” w ataku, który może działać na współczesnym szyfrze? Czy to w ogóle możliwe, nawet teoretycznie?

W 1998 roku szwajcarski kryptograf Daniel Bleichenbacher odpowiedział na to pytanie twierdząco. Zademonstrował atak orakla w szeroko stosowanej kryptosystemie z kluczem publicznym RSA, wykorzystując określony schemat wiadomości. W niektórych realizacjach RSA serwer odpowiada różnymi komunikatami o błędach, w zależności od tego, czy tekst jawny spełnia schemat, czy nie; to wystarczyło, aby przeprowadzić atak.

Cztery lata później, w 2002 roku, francuski kryptograf Serge Vaudenay zaprezentował atak orakla, niemal identyczny do tego opisanego w scenariuszu Ali, z tą różnicą, że zamiast fikcyjnego szyfru złamał cały szanowany zestaw nowoczesnych szyfrów, które ludzie rzeczywiście używają. W szczególności atak Vaudenaya koncentruje się na szyfrach o stałej długości wejścia („szyfry blokowe”), gdy są one stosowane w tak zwanym „trybie szyfrowania CBC” oraz z określoną popularną schemą uzupełniania, w zasadzie równoważną tej przedstawionej w scenariuszu Ali.

Również w 2002 roku amerykański kryptograf John Kelsey — współautor Twofish — zaproponował różne ataki orakla na systemy, które kompresują wiadomości, a następnie je szyfrują. Najbardziej zauważalnym z nich był atak, który wykorzystywał fakt, że często można wywnioskować pierwotną długość tekstu jawnego z długości tekstu szyfrowanego. Teoretycznie umożliwia to przeprowadzenie ataku orakla, który odzyskuje części pierwotnego tekstu jawnego.

Poniżej przedstawiamy dokładniejszy opis ataków Vaudenaya i Kelseya (podamy bardziej szczegółowy opis ataku Blychenbacha, gdy przejdziemy do ataków na kryptografię z kluczem publicznym). Mimo naszych starań tekst staje się nieco techniczny; dlatego jeśli to, co powyżej, jest dla Ciebie wystarczające, pominąć następne dwa rozdziały.

Atak Vaudenaya

Aby zrozumieć atak Vaudenaya, najpierw musimy nieco bardziej szczegółowo omówić szyfry blokowe i tryby szyfrowania. „Szyfr blokowy” to, jak już wspomniano, szyfr, który przyjmuje klucz oraz dane wejściowe o określonej, stałej długości („długość bloku”) i wydaje zaszyfrowany blok tej samej długości. Szyfry blokowe są szeroko stosowane i uważane za względnie bezpieczne. Wypuszczony na rynek DES, który uznaje się za pierwszy nowoczesny szyfr, był szyfrem blokowym. Jak wspomniano powyżej, to samo dotyczy AES, szeroko używanego obecnie.

Niestety, szyfry blokowe mają jedną rażącą słabość. Typowy rozmiar bloku wynosi 128 bitów, czyli 16 znaków. Oczywiste jest, że nowoczesna kryptografia wymaga pracy z danymi wejściowymi o większym rozmiarze, i właśnie tutaj pojawiają się tryby szyfrowania. Tryb szyfrowania to w zasadzie hack: to sposób na pewne zastosowanie szyfru blokowego, który przyjmuje tylko dane wejściowe o określonym rozmiarze, do danych wejściowych o dowolnej długości.

Atak Waternè jest ukierunkowany na popularny tryb CBC (Cipher Block Chaining, tryb połączenia bloków szyfrogramu). Atak traktuje podstawowy szyfr blokowy jak magiczny, niedostępny czarny pudełko i całkowicie omija jego bezpieczeństwo.

Oto diagram, który pokazuje, jak działa tryb CBC:

Okrągły plus oznacza operację XOR (wyłączającego „LUB”). Na przykład, drugi blok szyfrogramu uzyskano:

1. Wykonując operację XOR na drugim bloku tekstu jawnego z pierwszym blokiem szyfrogramu.
2. Szyfrując uzyskany blok za pomocą szyfru blokowego, używając klucza.

Ponieważ CBC intensywnie wykorzystuje binarną operację XOR, przyjrzyjmy się niektórym jej właściwościom:

• Idempotentność:
• Komutatywność:
• Asocjatywność:
• Inwolucyjność:
• Bajtowość: bajt n z = (bajt n z ) (bajt n z )

Z reguły właściwości te sugerują, że jeśli mamy równanie obejmujące operacje XOR i jedną niewiadomą, można je rozwiązać. Na przykład, jeśli wiemy, że z niewiadomą i znanymi i , to możemy polegać na wyżej wymienionych właściwościach, aby rozwiązać równanie dla . Stosując XOR po obu stronach równania z , otrzymujemy . Za chwilę wszystko to stanie się bardzo aktualne.

Między naszym scenariuszem Ali i atakiem Waternè istnieją dwa nieznaczne różnice i jedna główna różnica. Dwie nieznaczne:

• W scenariuszu Ala spodziewała się, że teksty jawne kończą się znakami a, bb, ccc i tak dalej. W ataku Waternè ofiara zamiast tego oczekuje, że teksty jawne kończą się N razy bajtem N (czyli szesnastkowym 01 lub 02 02, lub 03 03 03 i tak dalej). To czysto kosmetyczna różnica.
• W scenariuszu Alison było łatwo powiedzieć, czy Alison przyjęła wiadomość, na podstawie odpowiedzi „Niepoprawny tekst zastępczy”. W ataku Waterna potrzebna jest głębsza analiza, a precyzyjna realizacja po stronie ofiary jest kluczowa; jednak dla uproszczenia załóżmy, że ta analiza wciąż jest możliwa.

Główna różnica:

• Ponieważ nie używamy tego samego systemu kryptograficznego, związek między kontrolowanymi przez intruza bajtami zaszyfrowanego tekstu a sekretami (kluczem i tekstem jawnym) będzie oczywiście inny. Dlatego napastnik będzie musiał zastosować inną strategię podczas tworzenia ciphertextów i interpretacji odpowiedzi serwera.

To jest główna różnica — ostatni fragment układanki, aby zrozumieć atak Waterna, więc na chwilę zastanówmy się, dlaczego i jak w ogóle możliwe jest zorganizowanie ataku oraklowego na CBC.

Załóżmy, że mamy ciphertext CBC składający się z 247 bloków, i chcemy go odszyfrować. Możemy wysyłać do serwera fałszywe wiadomości, tak jak wcześniej mogliśmy wysyłać fałszywe wiadomości do Alison. Serwer odszyfruje dla nas wiadomości, ale nie pokaże odszyfrowania — zamiast tego, ponownie, jak w przypadku Alison, serwer przekaże tylko jedną bit informacji: czy tekst jawny ma prawidłowe wypełnienie, czy nie.

Zauważ, że w scenariuszu Alison mieliśmy następujące zależności:

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

Nazwijmy to „równaniem Alison”. Kontrolowaliśmy ciphertext; serwer (Alison) dostarczył niejasne informacje o uzyskanym tekście jawnym; i to pozwoliło nam wydobyć informacje o ostatnim czynniku — kluczu. Analogicznie, jeśli uda nam się znaleźć taką zależność dla scenariusza CBC, moglibyśmy wydobyć pewne tajne informacje i tam.

Na szczęście, istnieją tam rzeczywiście zależności, które możemy wykorzystać. Rozważmy dane wyjściowe końcowego wywołania odszyfrowania szyfru blokowego i oznaczmy te dane jako . Również oznaczmy bloki tekstu jawnego i bloki ciphertextu . Zwróć uwagę na diagram CBC i zauważ, co się dzieje:

Nazwijmy to „równaniem CBC”.

W scenariuszu Alicji, kontrolując szyfrogram i obserwując wycieki informacji dotyczących odpowiedniego tekstu jawnego, mogliśmy zorganizować atak, który przywrócił trzeci człon równania – klucz. W scenariuszu CBC również kontrolujemy szyfrogram i obserwujemy wycieki informacji dotyczących odpowiedniego tekstu jawnego. Jeśli analogia jest stosowna, będziemy mogli uzyskać informacje o .

Załóżmy, że naprawdę odzyskaliśmy , co wtedy? Cóż, wtedy możemy natychmiast wypisać cały ostatni blok tekstu jawnego (), po prostu wprowadzając (który już mamy) i
uzyskany w równaniu CBC.

Zatem jesteśmy optymistycznie nastawieni względem ogólnego planu ataku i nadszedł czas, aby opracować szczegóły. Zwracamy uwagę na to, w jaki sposób na serwerze następuje wyciek informacji o tekście jawnym. W scenariuszu Alicji wyciek miał miejsce, ponieważ Alicja odpowiadała prawidłową wiadomością tylko wtedy, gdy $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ kończył się ciągiem a (lub bb, i tak dalej, ale szanse na przypadkowe spełnienie tych warunków były bardzo małe). Podobnie w przypadku CBC, serwer akceptuje wypełnienie tylko wtedy, gdy kończy się szesnastkowo. 01Zatem spróbujmy tej samej sztuczki: wysyłania fałszywych szyfrogramów z naszymi własnymi fałszywymi wartościami , dopóki serwer nie zaakceptuje wypełnienia.

Kiedy serwer akceptuje wypełnienie dla jednej z naszych fałszywych wiadomości, oznacza to, że:

Teraz użyjemy właściwości XOR po bajcie:

Znamy pierwszy i trzeci człon. I już widzieliśmy, że to pozwala przywrócić pozostały człon – ostatni bajt z :

To również daje nam ostatni bajt końcowego bloku tekstu jawnego poprzez równanie CBC i właściwość po bajcie.

Moglibyśmy zakończyć na tym i zadowolić się tym, że przeprowadziliśmy atak na teoretycznie odporny szyfr. Ale w rzeczywistości możemy zrobić znacznie więcej: możemy naprawdę odzyskać cały tekst. Wymaga to pewnego sztuczki, której nie było w oryginalnym scenariuszu Alicji i nie jest to warunek konieczny ataku oraklowego, ale metoda wciąż warto rozważyć.

Aby to zrozumieć, najpierw zwróć uwagę, że w wyniku uzyskania prawidłowej wartości ostatniego bajtu Mamy nową zdolność. Teraz, przy fałszowaniu szyfrogramów, możemy kontrolować ostatni bajt odpowiadającego tekstu jawnego. Ponownie ma to związek z równaniem CBC i cechą bajtowości:

Ponieważ teraz znamy drugi składnik, możemy wykorzystać naszą kontrolę nad pierwszym do zarządzania trzecim. Po prostu obliczamy:

Dawniej nie mogliśmy tego zrobić, ponieważ nie mieliśmy jeszcze ostatniego bajtu. .

Jak to nam pomoże? Załóżmy, że teraz stworzymy wszystkie szyfrogramy tak, aby odpowiednie teksty jawne kończyły się na 02. Teraz serwer akceptuje uzupełnienie tylko wtedy, gdy tekst jawny kończy się na 02 02. Ponieważ poprawiliśmy ostatni bajt, stanie się to tylko wtedy, gdy przedostatni bajt tekstu jawnego również będzie równy 02. Kontynuujemy wysyłanie fałszywych bloków szyfrogramów, zmieniając przedostatni bajt, aż serwer zaakceptuje uzupełnienie dla jednego z nich. W tym momencie otrzymujemy:

I odzyskujemy przedostatni bajt dokładnie w ten sam sposób, w jaki odzyskaliśmy ostatni. Kontynuujemy w tym samym duchu: poprawiamy ostatnie dwa bajty tekstu jawnego na 03 03, powtarzamy ten atak dla trzeciego od końca bajtu i tak dalej, aż ostatecznie odzyskamy całkowicie .

A co z resztą tekstu? Zwróć uwagę, że wartość w rzeczywistości jest $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Możemy wstawić dowolny inny blok zamiast , a atak wciąż będzie skuteczny. W rzeczywistości możemy poprosić serwer o wykonanie $inline$text{BLOCK_DECRYPT}$inline$ dla dowolnych danych. W tym momencie gra jest skończona - możemy odszyfrować każdy szyfrogram (jeszcze raz spójrz na diagram odszyfrowania CBC, aby się o tym upewnić; i zwróć uwagę, że wektor IV jest publicznie dostępny).

Ta konkretna metoda odgrywa kluczową rolę w ataku orakula, z którym spotkamy się później.

Atak Kelsy'ego

Przyjaciel John Kelsy przedstawił zasady leżące u podstaw wielu możliwych ataków, a nie tylko szczegółowe dane dotyczące konkretnego ataku na konkretny szyfr. Jego artykuł z 2002 roku to badanie możliwych ataków na zaszyfrowane dane skompresowane. Myślałeś, że do przeprowadzenia ataku wystarczy sama informacja, że dane były skompresowane przed szyfrowaniem? Okazuje się, że to wystarczy.

Ten niezwykły wynik wynika z dwóch zasad. Po pierwsze, istnieje silna korelacja między długością jawnego tekstu a długością tekstu szyfrowanego; dla wielu szyfrow mieliśmy dokładną równość. Po drugie, gdy zachodzi kompresja, istnieje również silna korelacja między długością skompresowanego komunikatu a stopniem 'szumności' jawnego tekstu, to znaczy udziałem unikalnych znaków (termin techniczny - 'duża entropia').

Aby zobaczyć zasadę w akcji, rozważmy dwa jawne teksty:

Jawny tekst 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Jawny tekst 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Załóżmy, że oba jawne teksty zostały skompresowane, a następnie zaszyfrowane. Otrzymujesz dwa rezultaty tekstu szyfrowanego i musisz odgadnąć, który tekst szyfrowany odpowiada któremu jawnemu tekstowi:

Tekst szyfrowany 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Tekst szyfrowany 2: DWKJZXYU

Odpowiedź jest jasna. Spośród jawnych tekstów tylko jawny tekst 1 mógł zostać skompresowany do skąpej długości drugiego tekstu szyfrowanego. Odkryliśmy to, nie wiedząc nic o algorytmie kompresji, kluczu szyfrowania ani nawet o samym szyfrze. W porównaniu do hierarchii możliwych ataków kryptograficznych, to rodzaj szaleństwa.

Kelsey wskazuje dalej, że w pewnych nietypowych okolicznościach tę zasadę można również wykorzystać do przeprowadzenia ataku orakla. W szczególności opisuje, jak napastnik może odzyskać tajny jawny tekst, jeśli może zmusić serwer do szyfrowania danych formularza (jawny tekst, po którym następuje , podczas gdy on kontroluje i może jakoś sprawdzić długość zaszyfrowanego wyniku.

Ponownie, jak w innych atakach orakla, mamy proporcję:

Ponownie kontrolujemy jeden człon (), widzimy niewielki wyciek informacji o drugim członie (tekście szyfrowanym) i próbujemy odzyskać ten ostatni (jawny tekst). Pomimo analogii, to dość nietypowa sytuacja w porównaniu do innych ataków orakla, które widzieliśmy.

Aby zilustrować, jak taki atak może działać, użyjemy wymyślonej schemy kompresji, którą właśnie wymyśliliśmy: TOYZIP. Szuka on ciągów tekstu, które już wcześniej pojawiły się w tekście, i zastępuje je trzema bajtami wypełniającymi, które wskazują, gdzie znaleźć wcześniejszy przykład ciągu i ile razy się tam pojawia. Na przykład, ciąg helloworldhello może być skompresowany na helloworld[00][00][05] długości 13 bajtów w porównaniu do oryginalnych 15 bajtów.

Załóżmy, że haker próbuje odzyskać jawny tekst formularza hasło=..., gdzie samo hasło jest nieznane. Zgodnie z modelem ataku Kelsey'ego, haker może poprosić serwer o skompresowanie, a następnie zaszyfrowanie wiadomości formularza (jawny tekst, po którym następuje ), gdzie  — dowolny tekst. Kiedy serwer zakończy pracę, informuje o długości wyniku. Atak przebiega następująco:

Haker: Proszę skompresować i zaszyfrować jawny tekst bez żadnych wypełnień.

Serwer: Długość wyniku 14.

Haker: Proszę skompresować i zaszyfrować jawny tekst, do którego dodano hasło=a.

Serwer: Długość wyniku 18.

Haker zauważa: [oryginał 14] + [trzy bajty, które zastąpiły hasło=] + a

Haker: Proszę skompresować i zaszyfrować jawny tekst, do którego dodano hasło=b.

Serwer: Długość wyniku 18.

Haker: Proszę skompresować i zaszyfrować jawny tekst, do którego dodano hasło=c.

Serwer: Długość wyniku 17.

Haker zauważa: [oryginał 14] + [trzy bajty, które zastąpiły hasło=c]. Sugeruje to, że oryginalny jawny tekst zawiera ciąg hasło=c. To znaczy, że hasło zaczyna się na literę c

Haker: Proszę skompresować i zaszyfrować jawny tekst, do którego dodano hasło=ca.

Serwer: Długość wyniku 18.

Haker zauważa: [oryginał 14] + [trzy bajty, które zastąpiły hasło=c] + a

Haker: Proszę skompresować i zaszyfrować jawny tekst, do którego dodano hasło=cb.

Serwer: Długość wyniku 18.

(… jakiś czas później…)

Haker: Proszę skompresować i zaszyfrować jawny tekst, do którego dodano hasło=co.

Serwer: Długość wyniku 17.

Haker zauważa: [oryginał 14] + [trzy bajty, które zastąpiły hasło=co]. Z tej samej logiki haker wyciąga wniosek, że hasło zaczyna się na litery co

I tak dalej, aż do momentu, kiedy całe hasło zostanie odzyskane.

Czytelnik może sądzić, że to czysto akademickie ćwiczenie i taki scenariusz ataku nigdy nie wystąpi w prawdziwym świecie. Niestety, jak wkrótce zobaczymy, w kryptografii lepiej nie obiecywać.

Markowe luki: CRIME, POODLE, DROWN

W końcu, po dokładnym zbadaniu teorii, możemy zobaczyć, jak te metody są stosowane w rzeczywistych atakach kryptograficznych.

CRIME

Jeśli atak jest skierowany na przeglądarkę i sieć ofiary, niektóre rzeczy będą prostsze, a inne - trudniejsze. Na przykład łatwo zobaczyć ruch ofiary: wystarczy usiąść z nią w tej samej kawiarni z WiFi. Z tego powodu potencjalnym ofiarom (tzn. wszystkim) zazwyczaj zaleca się korzystanie z zaszyfrowanego połączenia. Będzie to trudniejsze, ale nadal możliwe, wykonanie żądań HTTP w imieniu ofiary na jakąś obcą stronę (na przykład Google). Złośliwiec musi zwabić ofiarę na złośliwą stronę internetową z skryptem, który wykona zapytanie. Przeglądarka internetowa automatycznie dostarczy odpowiednią sesyjną ciastko.

To wydaje się zdumiewające. Jeśli Bob wszedł na evil.com, czy skrypt na tej stronie naprawdę może po prostu poprosić Google o wysłanie hasła Boba na attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Cross-Site Request Forgery, CSRF), który był popularny mniej więcej w połowie lat 90-tych. Dziś, jeśli evil.com spróbuje takiego triku, Google (lub jakakolwiek poważna strona) zazwyczaj odpowiada: „Świetnie, ale twój token CSRF dla tej transakcji będzie… mmm… trzy biliony i siedem. Proszę powtórzyć tę liczbę”. Nowoczesne przeglądarki stosują coś, co nazywa się „polityką tego samego pochodzenia” (same-origin policy), zgodnie z którą skrypty na stronie A nie mają dostępu do informacji wysyłanych przez witrynę B. Dlatego skrypt na evil.com może wysyłać zapytania do google.com, ale nie może odczytać odpowiedzi ani rzeczywiście zakończyć transakcji.

Musimy podkreślić, że jeśli Bob nie używa szyfrowanego połączenia, wszystkie te zabezpieczenia są bezsensowne. Haker może po prostu przeczytać ruch Boba i odzyskać sesyjną ciastko Google. Dzięki temu ciastku po prostu otworzy nową kartę Google, nie wylogowując się ze swojej przeglądarki, i podszyje się pod Boba, nie spotykając się z nieprzyjemnymi zasadami same-origin policy. Ale, niestety dla hakera, takie sytuacje zdarzają się coraz rzadziej. Internet ogólnie od dawna wypowiedział wojnę nieszyfrowanym połączeniom, a wychodzący ruch Boba prawdopodobnie jest zaszyfrowany, czy mu się to podoba, czy nie. Ponadto, od samego początku wdrożenia protokołu ruch również był kompresowany przed szyfrowaniem; to była powszechna praktyka mająca na celu zmniejszenie opóźnienia.

Tutaj w grę wchodzi CRIME (Compression Ratio Infoleak Made Easy, prosta wyciek przez współczynnik kompresji). Luki, którą zademonstrowali we wrześniu 2012 roku badacze bezpieczeństwa Giuliano Rizzo i Thai Duong. Już rozłożyliśmy całą teoretyczną podstawę, która pozwala zrozumieć, co zrobili i jak. Haker może zmusić przeglądarkę Boba do wysyłania zapytań do Google, a następnie podsłuchiwać odpowiedzi w lokalnej sieci w skompresowanej, zaszyfrowanej formie. Dlatego mamy:

Tutaj haker kontroluje zapytanie i ma dostęp do sniffera ruchu, w tym rozmiaru pakietów. Fikcyjny scenariusz Kelsi stał się rzeczywistością.

Rozumiejąc teorię, autorzy CRIME stworzyli exploit, który może ukraść sesyjne ciastka dla szerokiego zakresu witryn, w tym Gmaila, Twittera, Dropboxa i Githuba. Luka dotknęła większości nowoczesnych przeglądarek internetowych, w rezultacie czego wydano poprawki, które po cichu pogrzebały funkcję kompresji w SSL, aby nie była w ogóle używana. Jedynym chronionym przed luką był szanowany Internet Explorer, który nigdy nie korzystał z kompresji SSL.

POODLE

W październiku 2014 roku zespół bezpieczeństwa Google zasiał zamieszanie w społeczności bezpieczeństwa. Udało im się wykorzystać lukę w protokole SSL, naprawioną ponad dziesięć lat temu.

Okazało się, że choć na serwerach działa wspaniały nowy TLSv1.2, wielu pozostawiło wsparcie dla przestarzałego SSLv3 dla kompatybilności wstecznej z Internet Explorerem 6. Już mówiliśmy o atakach downgrade, więc możecie sobie wyobrazić, co się działo. Dobrze zorganizowany sabotaż protokołu handshake - i serwery są gotowe powrócić do starego dobrego SSLv3, de facto anulując ostatnie 15 lat badań w dziedzinie bezpieczeństwa.

Dla kontekstu historycznego, oto krótkie podsumowanie historii SSL aż do wersji 2 autorstwa Matthew Greena:

Transport Layer Security (TLS) to najważniejszy protokół bezpieczeństwa w Internecie. [..] prawie każda transakcja, którą wykonujesz w Internecie, zależy od TLS. [..] Ale TLS nie zawsze był TLS. Protokół rozpoczął swoje życie w Netscape Communications pod nazwą „Secure Sockets Layer” lub SSL. Krążą plotki, że pierwsza wersja SSL była na tyle okropna, że programiści zebrali wszystkie wydruki kodu i zakopali je na tajemnicznym wysypisku w Nowym Meksyku. W rezultacie pierwsza publiczna wersja SSL tak naprawdę jest wersją SSL 2. Jest dość przerażająca, a [..] to był produkt lat 90., które współcześni kryptografowie uważają za „ciemne wieki kryptografii”. Wiele z najstraszniejszych ataków kryptograficznych, o których dzisiaj wiemy, nie zostało jeszcze odkrytych. W rezultacie deweloperzy protokołu SSLv2 musieli w zasadzie na czuja przedzierać się przez mrok, a napotkali mnóstwo przerażających potworów — ku ich zmartwieniu i naszej korzyści, ponieważ ataki na SSLv2 dostarczyły bezcennych lekcji dla następnej generacji protokołów.

Po tych wydarzeniach, w 1996 roku, rozczarowana firma Netscape przeszła do przepisania protokołu SSL od podstaw. Efektem była wersja 3 SSL, która naprawiła kilka znanych problemów bezpieczeństwa swojego poprzednika..

Na szczęście dla hakerów, „kilka” nie oznacza „wszystko”. Ogólnie rzecz biorąc, SSLv3 dostarczał wszystkie niezbędne elementy do przeprowadzenia ataku Wodene. Protokół wykorzystywał szyfr blokowy w trybie CBC oraz niebezpieczny schemat uzupełniania (to zostało naprawione w TLS; stąd potrzeba ataku obniżającego). Jeśli pamiętacie schemat uzupełniania z naszego początkowego opisu ataku Wodene, schemat SSLv3 jest bardzo podobny.

Niestety dla hakerów, „podobny” nie oznacza „identyczny”. Schemat uzupełniania SSLv3 ma postać „N dowolnych bajtów, a po nich liczba N”. Spróbujcie w takich warunkach wybrać wyimaginowany blok zaszyfrowanego tekstu i przejść przez wszystkie etapy oryginalnego schematu Wodene: odkryjecie, że atak udanie wydobywa ostatni bajt z odpowiadającego bloku otwartego tekstu, ale na tym koniec. Odszyfrowanie każdego 16. bajtu zaszyfrowanego tekstu to świetny trik, ale to nie jest zwycięstwo.

Stawiając czoła porażce, zespół Google sięgnął po skrajne rozwiązanie: przeszli na bardziej złożony model zagrożeń — ten, który był wykorzystywany w CRIME. Zakładając, że atakujący to skrypt uruchomiony na karcie przeglądarki ofiary, zdolny do wykradania sesyjnych ciasteczek, atak wciąż pozostaje imponujący. Choć szerszy model zagrożeń jest mniej realistyczny, w poprzedniej sekcji już widzieliśmy, że ten konkretny model jest wykonalny.

Biorąc pod uwagę te potężniejsze możliwości hakera, atak może teraz trwać dalej. Należy pamiętać, że napastnik wie, gdzie w nagłówku wyświetlany jest zaszyfrowany plik cookie sesji i kontroluje długość wcześniejszego żądania HTTP. Dlatego potrafi manipulować żądaniem HTTP tak, aby ostatni bajt cookie zgadzał się z końcem bloku. Teraz ten bajt nadaje się do deszyfrowania. Można po prostu dodać jeden znak do żądania, a przedostatni bajt cookie pozostanie na swoim miejscu i nada się do ataku tym samym sposobem. Atak trwa w ten sposób, aż plik cookie zostanie całkowicie odzyskany. Nazywa się to POODLE: Padding Oracle on Downgraded Legacy Encryption.

DROWN

Jak już wspomniano, SSLv3 miał swoje wady, ale zasadniczo różnił się od swojego poprzednika, ponieważ dziurawy SSLv2 był produktem innej epoki. Można było przerwać wiadomość w połowie: zgodzę się na to tylko przez mój trup przekształcało się w zgodzę się na to; klient i serwer mogli spotkać się w sieci, ustanowić zaufanie i wymienić sekrety na oczach napastnika, który następnie mógł się łatwo podszyć zarówno pod jednego, jak i pod drugiego. Jeszcze była kwestia kryptografii eksportowej, którą wspomnieliśmy przy omawianiu FREAK. To były kryptograficzne Sodoma i Gomora.

W marcu 2016 roku zespół badaczy z różnych dziedzin technicznych zebrał się i dokonał zdumiewającego odkrycia: SSLv2 wciąż jest używany w systemach zabezpieczeń. Tak, napastnicy nie mogli już obniżać nowoczesnych sesji TLS do SSLv2, ponieważ ta luka została załatana po FREAK i POODLE, ale wciąż mogą łączyć się z serwerami i inicjować sesje SSLv2 samodzielnie.

Zapytacie, co nas to obchodzi, co tam robią? Mają podatną sesję, ale nie powinno to wpływać na inne sesje ani na bezpieczeństwo serwera — prawda? Cóż, nie do końca. Tak, teoretycznie powinno tak być. Ale nie — ponieważ generacja certyfikatów SSL nakłada pewne obciążenie, przez co wiele serwerów używa tych samych certyfikatów i, w konsekwencji, tych samych kluczy RSA dla połączeń TLS i SSLv2. Co gorsza, z powodu błędu w OpenSSL w tej popularnej implementacji SSL opcja „Wyłącz SSLv2” właściwie nie działała.

To umożliwiło przeprowadzenie ataku międzyprotokolowego na TLS, który nazwano DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, odszyfrowanie RSA przy użyciu przestarzałego i osłabionego szyfrowania). Przypominamy, że to nie to samo, co atak typu downgrade; haker nie musi działać jak „człowiek w środku” i nie musi angażować klienta do uczestnictwa w niebezpiecznej sesji. Przestępcy po prostu sami inicjują niebezpieczną sesję SSLv2 z serwerem, atakują słaby protokół i odzyskują prywatny klucz serwera RSA. Klucz ten jest również ważny dla połączeń TLS, a od tego momentu żadna ochrona TLS nie uratuje go przed złamaniem.

Ale do złamania potrzebny jest działający atak przeciwko SSLv2, który pozwala na odzyskanie nie tylko konkretnego ruchu, ale również tajnego klucza serwera RSA. Choć to skomplikowane zagadnienie, badacze mogli wybrać dowolną podatność, która została całkowicie zamknięta po SSLv2. Ostatecznie znaleźli odpowiedni wariant: atak Blaynenbacha, o którym wspomnieliśmy wcześniej i który omówimy szczegółowo w następnym artykule. SSL i TLS są chronione przed tym atakiem, ale niektóre przypadkowe funkcje SSL w połączeniu z krótkimi kluczami w kryptografii eksportowej, stworzyły możliwość konkretnej realizacji DROWN.

W momencie publikacji podatności DROWN było narażonych 25% najlepszych stron w Internecie, a atak można było przeprowadzić przy skromnych zasobach, dostępnych nawet dla żartownisiów-hakerów. Aby wydobyć klucz RSA serwera, potrzebne były osiem godzin obliczeń i 440 dolarów, a SSLv2 zmienił status z "przestarzałego" na "radioaktywnego".

Czekaj, a co z Heartbleed?

To nie jest atak kryptograficzny w takim sensie, jak opisano powyżej; to przepełnienie bufora.

Zróbmy przerwę

Zaczęliśmy od kilku podstawowych metod: brute force, interpolacja, downgrade, międzyprotokolowe i wstępne obliczenia. Następnie omówiliśmy jedną zaawansowaną technikę, być może główny komponent współczesnych ataków kryptograficznych: atak orakla. Zajęliśmy się nim dość długo — i zrozumieliśmy nie tylko zasadę, która za nim stoi, ale i szczegóły techniczne dwóch konkretnych realizacji: ataków Wodena na tryb szyfrowania CBC oraz ataków Kelsey'ego na protokoły szyfrowania z wstępnym kompresowaniem.

W analizie ataków na słabe miejsca oraz wstępnych obliczeniach krótko omówiliśmy atak FREAK, który wykorzystuje oba podejścia, polegając na tym, że docelowe strony przechodzą do słabych kluczy, a następnie ponownie wykorzystują te same klucze. W następnej części pozostawiliśmy bardzo podobny atak Logjam, który celuje w algorytmy z kluczem publicznym.

Następnie przyjrzeliśmy się jeszcze trzem przykładom zastosowania tych zasad. Po pierwsze, CRIME i POODLE: dwa ataki, które opierały się na zdolności hakera do wstrzykiwania dowolnych otwartych tekstów obok docelowego otwartego tekstu, a następnie analizowania odpowiedzi serwera i następnie, wykorzystując metodologię ataku orakla, wykorzystywać te ograniczone informacje do częściowego odzyskiwania otwartego tekstu. CRIME podążał ścieżką ataku Kelsey na kompresję SSL, podczas gdy POODLE zamiast tego korzystał z wariantu ataku Wodane'a na CBC z tym samym efektem.

Następnie zwróciliśmy uwagę na atak międzyprotokołowy DROWN, który nawiązuje połączenie z serwerem za pomocą przestarzałego protokołu SSLv2, a następnie odzyskuje sekretne klucze serwera za pomocą ataku Blyuchenbakhera. Na ten moment pominęliśmy techniczne szczegóły tego ataku; podobnie jak w przypadku Logjam, będzie musiał poczekać, aż dokładnie zbadamy systemy kryptograficzne z kluczem publicznym i ich podatności.

W następnym artykule porozmawiamy o zaawansowanych atakach – takich jak metoda spotkania w środku (meet-in-the-middle), analiza różnicowa oraz atak „dnia urodzin”. Zrobimy krótki wgląd w ataki kanałami bocznymi, a następnie przejdziemy do najciekawszego – kryptosystemów z kluczem publicznym.

Źródło: habr.com