Kiedy słyszysz słowo „kryptografia”, niektórzy pamiętają swoje hasło do Wi-Fi, zieloną kłódkę obok adresu ich ulubionej strony internetowej i to, jak trudno jest dostać się do czyjejś poczty e-mail. Inni przywołują serię luk w zabezpieczeniach z ostatnich lat, opatrzonych wymownymi skrótami (DROWN, FREAK, POODLE...), stylowymi logo i ostrzeżeniem o konieczności pilnej aktualizacji przeglądarki.

Kryptografia obejmuje wszystko, ale esencja winnym. Rzecz w tym, że istnieje cienka granica pomiędzy prostotą i złożonością. Niektóre rzeczy są łatwe do zrobienia, ale trudne do złożenia, jak rozbicie jajka. Inne rzeczy są łatwe do wykonania, ale trudne do odzyskania, gdy brakuje małej, ważnej i kluczowej części: na przykład otwarcie zamkniętych drzwi, gdy kluczem jest „część kluczowa”. Kryptografia bada takie sytuacje i możliwości ich wykorzystania w praktyce.

W ostatnich latach zbiór ataków kryptograficznych przekształcił się w zoo krzykliwych logo, wypełnionych formułami z artykułów naukowych i wywołało ogólne ponure poczucie, że wszystko jest zepsute. Ale tak naprawdę wiele ataków opiera się na kilku ogólnych zasadach, a niekończące się strony formuł często sprowadzają się do łatwych do zrozumienia pomysłów.

W tej serii artykułów przyjrzymy się różnym typom ataków kryptograficznych, z naciskiem na podstawowe zasady. Ogólnie rzecz biorąc, nie dokładnie w tej kolejności, ale omówimy następujące kwestie:

• Podstawowe strategie: brutalna siła, analiza częstotliwości, interpolacja, downgrade i protokoły krzyżowe.
• Markowe luki w zabezpieczeniach: ŚRODEK, PRZESTĘPCZOŚĆ, PUDLE, TOPIENIE, Kłoda.
• Zaawansowane strategie: ataki wyroczni (atak Vodenet, atak Kelsey); metoda spotkania pośrodku, atak urodzinowy, błąd statystyczny (kryptanaliza różnicowa, kryptoanaliza integralna itp.).
• Ataki z kanału bocznego i ich bliskich, metody analizy awarii.
• Ataki na kryptografię klucza publicznego: pierwiastek sześcienny, transmisja, powiązany komunikat, atak Coppersmitha, algorytm Pohliga-Hellmana, sito liczbowe, atak Wienera, atak Bleichenbachera.

Ten konkretny artykuł obejmuje powyższy materiał aż do ataku Kelseya.

Podstawowe strategie

Poniższe ataki są proste w tym sensie, że można je prawie całkowicie wyjaśnić bez większych szczegółów technicznych. Wyjaśnijmy każdy typ ataku w najprostszy sposób, bez wchodzenia w skomplikowane przykłady i zaawansowane przypadki użycia.

Niektóre z tych ataków są w dużej mierze przestarzałe i nie są stosowane od wielu lat. Inni to starzy ludzie, którzy w XXI wieku wciąż regularnie podkradają się do niczego niepodejrzewających twórców kryptosystemów. Można uznać, że era współczesnej kryptografii rozpoczęła się wraz z pojawieniem się IBM DES, pierwszego szyfru, który oparł się wszystkim atakom wymienionym na tej liście.

Prosta brutalna siła

Schemat szyfrowania składa się z dwóch części: 1) funkcji szyfrującej, która pobiera wiadomość (tekst jawny) połączoną z kluczem, a następnie tworzy zaszyfrowaną wiadomość – tekst zaszyfrowany; 2) funkcja deszyfrująca, która pobiera zaszyfrowany tekst i klucz i tworzy tekst jawny. Zarówno szyfrowanie, jak i deszyfrowanie muszą być łatwe do obliczenia za pomocą klucza — i trudne do obliczenia bez niego.

Załóżmy, że widzimy zaszyfrowany tekst i próbujemy go odszyfrować bez żadnych dodatkowych informacji (nazywa się to atakiem wyłącznie zaszyfrowanym). Jeśli w jakiś magiczny sposób znajdziemy właściwy klucz, możemy łatwo sprawdzić, czy rzeczywiście jest on poprawny, jeśli wynikiem będzie rozsądny komunikat.

Należy zauważyć, że istnieją tutaj dwa ukryte założenia. Po pierwsze, wiemy, jak przeprowadzić deszyfrację, czyli jak działa kryptosystem. Jest to standardowe założenie przy omawianiu kryptografii. Ukrywanie szczegółów implementacji szyfru przed atakującymi może wydawać się dodatkowym środkiem bezpieczeństwa, ale gdy atakujący odkryje te szczegóły, to dodatkowe bezpieczeństwo zostaje po cichu i nieodwracalnie utracone. Właśnie tak Zasada Kerchhoffa: System wpadający w ręce wroga nie powinien powodować niedogodności.

Po drugie, zakładamy, że właściwy klucz to jedyny klucz, który doprowadzi do rozsądnego odszyfrowania. Jest to również rozsądne założenie; jest spełniony, jeśli zaszyfrowany tekst jest znacznie dłuższy niż klucz i jest czytelny. Zwykle dzieje się tak w prawdziwym świecie, z wyjątkiem ogromne, niepraktyczne klucze lub inne bzdury, które lepiej odłożyć na bok (jeśli nie podoba Ci się to, że pominęliśmy wyjaśnienie, zobacz Twierdzenie 3.8 tutaj).

Biorąc pod uwagę powyższe, pojawia się strategia: sprawdź każdy możliwy klucz. Nazywa się to brutalną siłą i gwarantujemy, że taki atak ostatecznie zadziała przeciwko wszystkim praktycznym szyfrom. Na przykład do zhakowania wystarczy brutalna siła Szyfr Cezara, starożytny szyfr, w którym kluczem jest jedna litera alfabetu, co oznacza nieco ponad 20 możliwych kluczy.

Na nieszczęście dla kryptoanalityków zwiększenie rozmiaru klucza jest dobrą obroną przed brutalną siłą. Wraz ze wzrostem rozmiaru klucza liczba możliwych kluczy rośnie wykładniczo. Przy nowoczesnych rozmiarach kluczy prosta brutalna siła jest całkowicie niepraktyczna. Aby zrozumieć, co mamy na myśli, weźmy najszybszy znany superkomputer z połowy 2019 r.: Szczyt firmy IBM, z maksymalną wydajnością około 1017 operacji na sekundę. Obecnie typowa długość klucza wynosi 128 bitów, co oznacza 2128 możliwych kombinacji. Aby przeszukać wszystkie klucze, superkomputer Summit będzie potrzebował czasu, który jest około 7800 razy dłuższy niż wiek Wszechświata.

Czy brutalną siłę należy uznać za ciekawostkę historyczną? Wcale nie: jest to niezbędny składnik książki kucharskiej kryptoanalizy. Rzadko zdarza się, aby szyfry były tak słabe, że można je złamać jedynie sprytnym atakiem, bez użycia siły w takim czy innym stopniu. Wiele udanych hacków wykorzystuje metodę algorytmiczną, aby najpierw osłabić docelowy szyfr, a następnie przeprowadzić atak brute-force.

Analiza częstotliwości

Większość tekstów nie jest bełkotem. Na przykład w tekstach angielskich występuje wiele liter „e” i przedimków „the”; w plikach binarnych pomiędzy fragmentami informacji znajduje się wiele bajtów zerowych. Analiza częstotliwości to każdy atak wykorzystujący ten fakt.

Kanonicznym przykładem szyfru podatnego na ten atak jest prosty szyfr podstawieniowy. W tym szyfrze kluczem jest tabela, w której wszystkie litery są zamienione. Na przykład „g” zostaje zastąpione przez „h”, „o” przez j, więc słowo „go” staje się „hj”. Szyfr ten jest trudny do złamania metodą brutalnej siły, ponieważ istnieje wiele możliwych tabel przeglądowych. Jeśli interesujesz się matematyką, efektywna długość klucza wynosi około 88 bitów: to jest
. Jednak analiza częstotliwości zwykle pozwala szybko wykonać zadanie.

Rozważmy następujący tekst zaszyfrowany przetworzony prostym szyfrem podstawieniowym:

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

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

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

Para XD powtórzone na początku kilku słów. W szczególności kombinacja XDeLe wyraźnie sugeruje to słowo these lub there, więc kontynuujmy:

theLe ALE UGLe THWNKE WN heAJeN ANF eALth DGLAtWG niż ALE FLeAUt GR WN OGQL ZDWBGEGZDO

Załóżmy dalej, że L odpowiada r, A - a i tak dalej. Prawdopodobnie zajmie to kilka prób, ale w porównaniu z pełnym atakiem brute-force, ten atak przywraca oryginalny tekst w mgnieniu oka:

horatio, jest więcej rzeczy na niebie i ziemi, niż marzyła twoja filozofia

Dla niektórych rozwiązywanie takich „kryptogramów” jest ekscytującym hobby.

Idea analizy częstotliwości jest bardziej fundamentalna, niż się wydaje na pierwszy rzut oka. Dotyczy to również znacznie bardziej złożonych szyfrów. W całej historii różne projekty szyfrów próbowały przeciwstawić się takiemu atakowi za pomocą „podstawienia polialfabetycznego”. Tutaj podczas procesu szyfrowania tabela podstawień liter jest modyfikowana w złożony, ale przewidywalny sposób, zależny od klucza. Wszystkie te szyfry uważano jednocześnie za trudne do złamania; a jednak skromna analiza częstotliwości ostatecznie pokonała je wszystkie.

Najbardziej ambitnym szyfrem polialfabetycznym w historii i prawdopodobnie najbardziej znanym był szyfr Enigma z II wojny światowej. Był stosunkowo skomplikowany w porównaniu do swoich poprzedników, ale po wielu ciężkiej pracy brytyjscy kryptoanalitycy złamali go za pomocą analizy częstotliwości. Oczywiście nie mogli opracować tak eleganckiego ataku, jak ten pokazany powyżej; musieli porównywać znane pary tekstu jawnego i tekstu zaszyfrowanego (tzw. „atak na tekst jawny”), prowokując nawet użytkowników Enigmy do szyfrowania niektórych wiadomości i analizowania wyniku („atak na wybrany tekst jawny”). Nie ułatwiło to jednak losu pokonanych armii wroga i zatopionych okrętów podwodnych.

Po tym triumfie analiza częstotliwości zniknęła z historii kryptoanalizy. Szyfry we współczesnej epoce cyfrowej są zaprojektowane do pracy z bitami, a nie literami. Co ważniejsze, szyfry te zostały zaprojektowane w oparciu o mroczne zrozumienie tego, co później stało się znane jako Prawo Schneiera: Każdy może stworzyć algorytm szyfrowania, którego sam nie będzie w stanie złamać. To nie wystarczy dla systemu szyfrowania wydawało się trudne: aby udowodnić swoją wartość, musi przejść bezlitosną kontrolę bezpieczeństwa przez wielu kryptoanalityków, którzy dołożą wszelkich starań, aby złamać szyfr.

Wstępne obliczenia

Weźmy hipotetyczne miasto Precom Heights, liczące 200 000 mieszkańców. W każdym domu w mieście znajdują się przedmioty wartościowe średnio o wartości 30 000 dolarów, ale nie więcej niż 50 000. Rynek zabezpieczeń w Precom jest zmonopolizowany przez ACME Industries, która produkuje legendarne zamki do drzwi klasy Coyote™. Według analiz ekspertów zamek klasy Coyote może zostać złamany jedynie przez bardzo złożoną hipotetyczną maszynę, której stworzenie wymaga około pięciu lat i inwestycji wynoszącej 50 000 dolarów. Czy miasto jest bezpieczne?

Najprawdopodobniej nie. W końcu pojawi się dość ambitny przestępca. Rozumuje w ten sposób: „Tak, poniosę duże koszty początkowe. Pięć lat cierpliwego czekania i 50 000 dolarów. Ale kiedy skończę, będę miał dostęp do całe bogactwo tego miasta. Jeśli dobrze rozegram swoje karty, ta inwestycja zwróci się wielokrotnie.”

Podobnie jest w kryptografii. Ataki na konkretny szyfr podlegają bezwzględnej analizie kosztów i korzyści. Jeśli stosunek będzie korzystny, atak nie nastąpi. Jednak ataki, które działają przeciwko wielu potencjalnym ofiarom naraz, prawie zawsze się opłaciły, w takim przypadku najlepszą praktyką projektową jest założenie, że rozpoczęły się od pierwszego dnia. Zasadniczo mamy kryptograficzną wersję prawa Murphy'ego: „Wszystko, co może faktycznie złamać system, złamie system”.

Najprostszym przykładem kryptosystemu podatnego na atak przed obliczeniem jest szyfr bezkluczowy. Tak było w przypadku Szyfr Cezara, który po prostu przesuwa każdą literę alfabetu o trzy litery do przodu (tabela jest zapętlona, ​​więc ostatnia litera alfabetu jest szyfrowana jako trzecia). Tutaj ponownie wchodzi w grę zasada Kerchhoffa: raz zhakowany system będzie zhakowany na zawsze.

Koncepcja jest prosta. Nawet początkujący twórca kryptosystemów prawdopodobnie rozpozna zagrożenie i odpowiednio się przygotuje. Patrząc na ewolucję kryptografii, takie ataki były nieodpowiednie w przypadku większości szyfrów, począwszy od pierwszych ulepszonych wersji szyfru Cezara, aż do upadku szyfrów polialfabetycznych. Takie ataki powróciły dopiero wraz z nadejściem współczesnej ery kryptografii.

Powrót ten wynika z dwóch czynników. Po pierwsze, w końcu pojawiły się wystarczająco złożone kryptosystemy, w których możliwość wykorzystania po włamaniu nie była oczywista. Po drugie, kryptografia stała się tak powszechna, że ​​miliony laików codziennie podejmowały decyzje o tym, gdzie i jakie części kryptografii ponownie wykorzystać. Minęło trochę czasu, zanim eksperci zdali sobie sprawę z ryzyka i podnieśli alarm.

Pamiętaj o ataku przedobliczeniowym: na końcu artykułu przyjrzymy się dwóm rzeczywistym przykładom kryptograficznym, w których odegrał on ważną rolę.

Interpolacja

Oto słynny detektyw Sherlock Holmes przeprowadzający atak interpolacyjny na nieszczęsnego doktora Watsona:

Od razu domyśliłem się, że przyjechałeś z Afganistanu... Mój tok myślenia był następujący: „Ten człowiek jest z natury lekarzem, ale ma zacięcie wojskowe. Czyli lekarz wojskowy. Właśnie wrócił z tropików - jego twarz jest ciemna, ale nie jest to naturalny odcień jego skóry, ponieważ jego nadgarstki są znacznie bielsze. Twarz jest wymizerowana – widać, że wiele wycierpiał i cierpiał na choroby. Został ranny w lewą rękę - trzyma ją nieruchomo i trochę nienaturalnie. Gdzie w tropikach angielski lekarz wojskowy mógłby znieść trudy i zostać ranny? Oczywiście w Afganistanie.” Cały tok myślenia nie trwał nawet sekundy. Więc powiedziałem, że przyjechałeś z Afganistanu i byłeś zaskoczony.

Holmes był w stanie wydobyć bardzo niewiele informacji z każdego dowodu z osobna. Do takiego wniosku mógł dojść jedynie po rozważeniu ich wszystkich razem. Atak interpolacyjny działa podobnie, badając znane pary tekstu jawnego i tekstu zaszyfrowanego powstałe na podstawie tego samego klucza. Z każdej pary wyciągane są indywidualne obserwacje, które pozwalają na wyciągnięcie ogólnego wniosku na temat klucza. Wszystkie te wnioski są niejasne i wydają się bezużyteczne, dopóki nagle nie osiągną masy krytycznej i nie prowadzą do jedynego możliwego wniosku: niezależnie od tego, jak niewiarygodne to jest, musi być prawdziwe. Następnie albo klucz zostaje ujawniony, albo proces deszyfrowania staje się tak udoskonalony, że można go odtworzyć.

Zilustrujmy na prostym przykładzie działanie interpolacji. Powiedzmy, że chcemy przeczytać osobisty pamiętnik naszego wroga, Boba. Szyfruje każdą liczbę w swoim pamiętniku za pomocą prostego kryptosystemu, o którym dowiedział się z reklamy w magazynie „A Mock of Cryptography”. System działa w ten sposób: Bob wybiera dwie liczby, które mu się podobają: и . Od teraz szyfrowanie dowolnego numeru , oblicza . Na przykład, jeśli Bob wybrał и , a następnie numer zostanie zaszyfrowany jako .

Powiedzmy, że 28 grudnia zauważyliśmy, że Bob zapisuje coś w swoim pamiętniku. Kiedy skończy, po cichu go odbierzemy i obejrzymy ostatni wpis:

Дата: 235/520

Drogi pamiętniku,

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

Ponieważ bardzo poważnie podchodzimy do śledzenia Boba na jego randce (w tym scenariuszu oboje mamy 15 lat), bardzo ważna jest znajomość daty i adresu Alicji. Na szczęście zauważamy, że kryptosystem Boba jest podatny na atak interpolacyjny. Możemy nie wiedzieć и , ale znamy dzisiejszą datę, więc mamy dwie pary tekst jawny-zaszyfrowany. Mianowicie, to wiemy zaszyfrowane w I - w . Oto co zapiszemy:

Skoro mamy 15 lat to już wiemy o układzie dwóch równań z dwiema niewiadomymi, który w tej sytuacji wystarczy znaleźć и bez żadnych problemów. Każda para tekst jawny-zaszyfrowany nakłada ograniczenie na klucz Boba, a oba ograniczenia razem wystarczą do całkowitego odzyskania klucza. W naszym przykładzie odpowiedź brzmi и (w więc to 26 w pamiętniku odpowiada słowu „ten”, czyli „ten sam” – ok. uliczka).

Ataki interpolacyjne nie ograniczają się oczywiście do takich prostych przykładów. Każdy kryptosystem, który sprowadza się do dobrze zrozumiałego obiektu matematycznego i listy parametrów, jest narażony na atak interpolacyjny – im bardziej zrozumiały obiekt, tym większe ryzyko.

Nowicjusze często narzekają, że kryptografia to „sztuka projektowania rzeczy tak brzydkich, jak to tylko możliwe”. Prawdopodobnie w dużej mierze winne są ataki interpolacyjne. Bob może albo użyć eleganckiego wzoru matematycznego, albo zachować prywatność swojej randki z Alice – ale niestety, zwykle nie można mieć obustronnych korzyści. Stanie się to całkowicie jasne, kiedy w końcu przejdziemy do tematu kryptografii klucza publicznego.

Między protokołami/obniżeniem wersji

W Now You See Me (2013) grupa iluzjonistów próbuje oszukać skorumpowanego magnata ubezpieczeniowego Arthura Tresslera z całej jego fortuny. Aby uzyskać dostęp do konta bankowego Arthura, iluzjoniści muszą albo podać jego nazwę użytkownika i hasło, albo zmusić go do osobistego stawienia się w banku i wzięcia udziału w programie.

Obie opcje są bardzo trudne; Chłopaki są przyzwyczajeni do występów na scenie i nie uczestniczą w operacjach wywiadowczych. Wybierają więc trzecią możliwą opcję: ich wspólnik dzwoni do banku i udaje Artura. Bank zadaje kilka pytań w celu weryfikacji tożsamości, np. imię wujka i imię pierwszego zwierzaka; naszych bohaterów z góry z łatwością wydobywają te informacje od Arthura, stosując sprytną inżynierię społeczną. Od tego momentu doskonałe bezpieczeństwo hasła nie ma już znaczenia.

(Według miejskiej legendy, którą osobiście sprawdziliśmy i zweryfikowaliśmy, kryptograf Eli Beaham spotkał kiedyś kasjera w banku, który nalegał na ustawienie pytania zabezpieczającego. Kiedy kasjer zapytał o imię swojej babci ze strony matki, Beaham zaczął dyktować: „Kapitał X, małe y, trzy…”).

Podobnie jest w kryptografii, jeśli do ochrony tego samego zasobu używane są równolegle dwa protokoły kryptograficzne, a jeden jest znacznie słabszy od drugiego. Powstały system staje się podatny na atak typu cross-protocol, podczas którego atakowany jest słabszy protokół, aby dostać się do nagrody bez dotykania silniejszego.

W niektórych skomplikowanych przypadkach nie wystarczy po prostu skontaktować się z serwerem przy użyciu słabszego protokołu, ale wymaga to mimowolnego udziału uprawnionego klienta. Można to zorganizować za pomocą tak zwanego ataku na obniżenie wersji. Aby zrozumieć ten atak, załóżmy, że nasi iluzjoniści mają trudniejsze zadanie niż w filmie. Załóżmy, że pracownik banku (kasjer) i Artur spotkali się z nieprzewidzianymi okolicznościami, w wyniku których wywiązał się następujący dialog:

Włamywacz: Cześć? To jest Arthur Tressler. Chciałbym zresetować swoje hasło.

Kasjer: Świetnie. Proszę, spójrz na swoją osobistą księgę tajnych kodów, strona 28, słowo 3. Wszystkie kolejne wiadomości będą szyfrowane przy użyciu tego konkretnego słowa jako klucza. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Włamywacz: Hej, hej, czekaj, czekaj. Czy to naprawdę konieczne? Nie możemy po prostu porozmawiać jak normalni ludzie?

Kasjer: Nie polecam tego robić.

Włamywacz: Ja po prostu... spójrz, miałem kiepski dzień, ok? Jestem klientem VIP i nie mam nastroju na grzebanie w tych głupich książkach z kodami.

Kasjer: Cienki. Jeśli pan nalega, panie Tressler. Co chcesz?

Włamywacz: Proszę, chciałbym przekazać wszystkie moje pieniądze na rzecz Narodowego Funduszu na rzecz Ofiar Arthura Tresslera.

(Pauza).

Kasjer: Czy teraz jest jasne. W przypadku dużych transakcji podaj PIN.

Włamywacz: Mój co?

Kasjer: Na Twoją osobistą prośbę transakcje tej wielkości wymagają podania kodu PIN w przypadku dużych transakcji. Ten kod został Ci przekazany podczas otwierania konta.

Włamywacz:... Straciłem go. Czy to naprawdę konieczne? Nie możesz po prostu zatwierdzić umowy?

Kasjer: NIE. Przykro mi, panie Tressler. Powtórzę jeszcze raz: jest to środek bezpieczeństwa, o który prosiłeś. Jeśli chcesz, możemy wysłać nowy kod PIN na Twoją skrzynkę pocztową.

Nasi bohaterowie odkładają operację. Podsłuchują kilka dużych transakcji Tresslera, mając nadzieję, że usłyszą kod PIN; ale za każdym razem rozmowa zamienia się w zakodowany bełkot, zanim zostanie powiedziane coś interesującego. Wreszcie, pewnego pięknego dnia, plan zostaje wprowadzony w życie. Czekają cierpliwie na moment, kiedy Tressler będzie musiał dokonać przez telefon dużej transakcji, zadzwoni i wtedy…

Tressler: Cześć. Proszę o sfinalizowanie transakcji zdalnej.

Kasjer: Świetnie. Proszę spojrzeć na swoją osobistą książkę z tajnymi kodami, strona...

(Włamywacz naciska przycisk; głos kasjera zmienia się w niezrozumiały dźwięk).

Kasjer: - #@$#@$#*@$$@#* zostanie zaszyfrowane przy użyciu tego słowa jako klucza. AAAYRR PLRQRZ MMNJK LOJBAN…

Tressler: Przepraszam, nie do końca zrozumiałem. Ponownie? Na jakiej stronie? Jakie słowo?

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

Tressler: Jakie?

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

Tressler: Poważnie! Już wystarczy! Ty i twój protokół bezpieczeństwa jesteście swego rodzaju cyrkiem. Wiem, że możesz ze mną normalnie porozmawiać.

Kasjer: Nie polecam…

Tressler: I nie radzę ci marnować mojego czasu. Nie chcę więcej o tym słyszeć, dopóki nie rozwiążesz problemów z linią telefoniczną. Czy możemy sfinalizować tę umowę, czy nie?

Kasjer:… Tak. Cienki. Co chcesz?

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

Kasjer: Daj mi minutkę, proszę. To ważna sprawa. W przypadku dużych transakcji podaj PIN.

Tressler: Co? Och, dokładnie. 1234.

Oto atak w dół. Przewidywano, że słabszy protokół „po prostu mów bezpośrednio”. opcja w razie wypadku. A jednak tu jesteśmy.

Możesz się zastanawiać, kto przy zdrowych zmysłach zaprojektowałby prawdziwy system „bezpieczny, dopóki nie zapytasz inaczej”, taki jak ten opisany powyżej. Ale tak jak fikcyjny bank podejmuje ryzyko, aby zatrzymać klientów, którzy nie lubią kryptografii, tak ogólnie systemy często kierują się w stronę wymagań, które są obojętne lub wręcz wrogie bezpieczeństwu.

Dokładnie to samo stało się z protokołem SSLv2 w 1995 roku. Rząd USA od dawna zaczął postrzegać kryptografię jako broń, którą najlepiej trzymać z dala od wrogów zagranicznych i krajowych. Fragmenty kodu były indywidualnie zatwierdzane do eksportu ze Stanów Zjednoczonych, często pod warunkiem celowego osłabienia algorytmu. Netscape, twórca najpopularniejszej przeglądarki Netscape Navigator, otrzymał pozwolenie na SSLv2 jedynie z naturalnie podatnym na ataki 512-bitowym kluczem RSA (i 40-bitowym w przypadku RC4).

Pod koniec tysiąclecia zasady zostały złagodzone, a dostęp do nowoczesnego szyfrowania stał się powszechnie dostępny. Jednak klienci i serwery od lat obsługują osłabioną kryptografię „eksportową” z powodu tej samej bezwładności, która utrzymuje obsługę każdego starszego systemu. Klienci wierzyli, że mogą napotkać serwer, który nie obsługuje niczego innego. Serwery zrobiły to samo. Oczywiście protokół SSL nakazuje, aby klienci i serwery nigdy nie powinni używać słabego protokołu, jeśli dostępny jest lepszy. Jednak to samo założenie odnosiło się do Tresslera i jego banku.

Teoria ta znalazła zastosowanie w dwóch głośnych atakach, które w 2015 r. zachwiały bezpieczeństwem protokołu SSL, oba wykryte przez badaczy firmy Microsoft i INRIA. Najpierw w lutym ujawniono szczegóły ataku FREAK, a trzy miesiące później miał miejsce kolejny podobny atak o nazwie Logjam, który omówimy szerzej, gdy przejdziemy do ataków na kryptografię klucza publicznego.

Słaby punkt FREAK (znany również jako „Smack TLS”) wyszedł na światło dzienne, 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 kryptografii eksportu, ale serwer nadal odpowiada takimi kluczami, klient mówi „No cóż” i przełącza się na słaby zestaw szyfrów.

W tamtym czasie kryptografia eksportowa była powszechnie uważana za przestarzałą i niedostępną, więc atak był całkowitym szokiem i dotknął wiele ważnych domen, w tym strony Białego Domu, IRS i NSA. Co gorsza, okazuje się, że wiele podatnych na ataki serwerów optymalizowało wydajność, ponownie wykorzystując te same klucze, zamiast generować nowe dla każdej sesji. Umożliwiło to, po obniżeniu wersji protokołu, przeprowadzenie ataku przed obliczeniem: złamanie jednego klucza pozostało stosunkowo drogie (100 dolarów i 12 godzin w momencie publikacji), ale praktyczny koszt ataku na połączenie został znacznie zmniejszony. Wystarczy raz wybrać klucz serwera i od tego momentu złamać szyfrowanie dla wszystkich kolejnych połączeń.

Zanim przejdziemy dalej, należy wspomnieć o jednym zaawansowanym ataku…

Atak Oracle

Moxi Marlinspike najbardziej znany jako ojciec wieloplatformowej aplikacji do przesyłania wiadomości kryptograficznych Signal; ale osobiście podoba nam się jedna z jego mniej znanych innowacji - zasada kryptograficznej zagłady (Kryptograficzna zasada zagłady). Parafrazując, możemy powiedzieć tak: „Jeśli protokół działa jakikolwiek wykonuje operację kryptograficzną na wiadomości z potencjalnie złośliwego źródła i zachowuje się inaczej w zależności od wyniku, jest skazana na porażkę.” Lub w ostrzejszej formie: „Nie bierz informacji od wroga do przetworzenia, a jeśli już musisz, to przynajmniej nie pokazuj wyniku”.

Pomińmy przepełnienia bufora, zastrzyki poleceń i tym podobne; wykraczają one poza zakres tej dyskusji. Naruszenie „zasady zagłady” prowadzi do poważnych włamań do kryptografii ze względu na to, że protokół zachowuje się dokładnie tak, jak oczekiwano.

Jako przykład weźmy fikcyjny projekt z podatnym na ataki szyfrem podstawieniowym, a następnie zademonstrujmy możliwy atak. Chociaż widzieliśmy już atak na szyfr podstawieniowy z wykorzystaniem analizy częstotliwości, nie jest to po prostu „kolejny sposób na złamanie tego samego szyfru”. Wręcz przeciwnie, ataki na Oracle są znacznie nowocześniejszym wynalazkiem, mającym zastosowanie w wielu sytuacjach, w których zawodzi analiza częstotliwości, co zademonstrujemy w następnej sekcji. Tutaj wybrano prosty szyfr tylko po to, aby przykład był jaśniejszy.

Alicja i Bob komunikują się więc za pomocą prostego szyfru podstawieniowego, korzystając ze znanego tylko im klucza. Są bardzo rygorystyczni co do długości wiadomości: mają dokładnie 20 znaków. Uzgodnili więc, że jeśli ktoś chce wysłać krótszą wiadomość, powinien dodać na jej końcu jakiś fikcyjny tekst, tak aby długość wiadomości wynosiła dokładnie 20 znaków. Po krótkiej dyskusji zdecydowali, że zaakceptują jedynie następujące fikcyjne teksty: a, bb, ccc, dddd itp. W ten sposób znany jest fikcyjny tekst o dowolnej wymaganej długości.

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

Podczas ataku napastnik podszywa się pod Boba i wysyła fałszywe wiadomości do Alicji. Wiadomości są kompletną bzdurą – atakujący nie ma klucza i dlatego nie może sfałszować znaczącej wiadomości. Ponieważ jednak protokół narusza zasadę zagłady, osoba atakująca może w dalszym ciągu złapać Alicję w pułapkę, zmuszając ją do ujawnienia kluczowych informacji, jak pokazano poniżej.

Włamywacz: PREWF ZHJKL MMMN. LA

Alice: Nieprawidłowy tekst fikcyjny.

Włamywacz: PREWF ZHJKL MMMN. LB

Alice: Nieprawidłowy tekst fikcyjny.

Włamywacz: PREWF ZHJKL MMMN. LC

Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Włamywacz nie ma pojęcia, co Alicja właśnie powiedziała, ale zauważa, że ​​jest to symbol C musi odpowiadać a, ponieważ Alicja zaakceptowała fikcyjny tekst.

Włamywacz: REWF ZHJKL MMMN. LAA

Alice: Nieprawidłowy tekst fikcyjny.

Włamywacz: REWF ZHJKL MMMN. LBB

Alice: Nieprawidłowy tekst fikcyjny.

Po wielu próbach...

Włamywacz: REWF ZHJKL MMMN. LGG

Alice: Nieprawidłowy tekst fikcyjny.

Włamywacz: REWF ZHJKL MMMN. LHH

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

Ponownie atakujący nie ma pojęcia, co właśnie powiedziała Alicja, ale zauważa, że ​​H musi odpowiadać b, ponieważ Alicja zaakceptowała fikcyjny tekst.

I tak dalej, aż atakujący pozna znaczenie każdego znaku.

Metoda na pierwszy rzut oka przypomina atak wybranym tekstem jawnym. Na koniec atakujący wybiera szyfrogramy, a serwer posłusznie je przetwarza. Główną różnicą, która sprawia, że ​​ataki te są wykonalne w prawdziwym świecie, jest to, że osoba atakująca nie potrzebuje dostępu do faktycznego transkrypcji — wystarczy odpowiedź serwera, nawet tak nieszkodliwa, jak „Nieprawidłowy fikcyjny tekst”.

Chociaż ten konkretny atak jest pouczający, nie skupiaj się zbytnio na szczegółach schematu „fikcyjnego tekstu”, konkretnym używanym kryptosystemie lub dokładnej sekwencji wiadomości wysyłanych przez atakującego. Podstawową ideą jest to, jak Alicja reaguje inaczej w zależności od właściwości tekstu jawnego i robi to bez sprawdzania, czy odpowiedni tekst zaszyfrowany rzeczywiście pochodzi od zaufanej strony. W ten sposób Alice pozwala atakującemu wycisnąć tajne informacje z jej odpowiedzi.

W tym scenariuszu można wiele zmienić. Symbole, na które reaguje Alicja, czy sama różnica w jej zachowaniu, czy nawet zastosowany kryptosystem. Ale zasada pozostanie ta sama, a atak jako całość pozostanie wykonalny w tej czy innej formie. Podstawowa implementacja tego ataku pomogła odkryć kilka błędów bezpieczeństwa, którym wkrótce się przyjrzymy; ale najpierw należy nauczyć się kilku lekcji teoretycznych. Jak wykorzystać ten fikcyjny „skrypt Alicji” w ataku, który może działać na prawdziwym, nowoczesnym szyfrze? Czy jest to w ogóle możliwe, nawet teoretycznie?

W 1998 roku szwajcarski kryptolog Daniel Bleichenbacher odpowiedział na to pytanie twierdząco. Zademonstrował atak Oracle na powszechnie używany kryptosystem klucza publicznego RSA, wykorzystując specyficzny schemat wiadomości. W niektórych implementacjach RSA serwer odpowiada różnymi komunikatami o błędach w zależności od tego, czy zwykły tekst pasuje do schematu, czy nie; to wystarczyło, aby przeprowadzić atak.

Cztery lata później, w 2002 roku, francuski kryptolog Serge Vaudenay zademonstrował atak na wyrocznię niemal identyczny z tym opisanym w powyższym scenariuszu Alicji – z tą różnicą, że zamiast fikcyjnego szyfru złamał całą szanowaną klasę współczesnych szyfrów, których faktycznie używają ludzie. W szczególności atak Vaudenaya atakuje szyfry o stałym rozmiarze wejściowym („szyfry blokowe”), gdy są one używane w tak zwanym „trybie szyfrowania CBC” i z pewnym popularnym schematem dopełniania, w zasadzie równoważnym temu ze scenariusza Alice.

Również w 2002 roku amerykański kryptolog John Kelsey – współautor Dwie ryby — zaproponował różne ataki Oracle na systemy kompresujące wiadomości, a następnie je szyfrujące. Najbardziej zauważalnym z nich był atak wykorzystujący fakt, że często można wywnioskować pierwotną długość tekstu jawnego na podstawie długości tekstu zaszyfrowanego. Teoretycznie pozwala to na atak Oracle, który odzyskuje części oryginalnego tekstu jawnego.

Poniżej przedstawiamy bardziej szczegółowy opis ataków Vaudenay i Kelsey (bardziej szczegółowy opis ataku Bleichenbacher podamy, gdy przejdziemy do ataków na kryptografię klucza publicznego). Pomimo naszych największych wysiłków tekst staje się nieco techniczny; więc jeśli powyższe Ci wystarczy, pomiń kolejne dwie sekcje.

Atak Vodene’a

Aby zrozumieć atak Vaudenaya, najpierw musimy porozmawiać trochę więcej o szyfrach blokowych i trybach szyfrowania. „Szyfr blokowy” to, jak wspomniano, szyfr, który pobiera klucz i dane wejściowe o określonej stałej długości („długość bloku”) i tworzy zaszyfrowany blok o tej samej długości. Szyfry blokowe są szeroko stosowane i uważane za stosunkowo bezpieczne. Obecnie wycofany DES, uważany za pierwszy nowoczesny szyfr, był szyfrem blokowym. Jak wspomniano powyżej, to samo dotyczy powszechnie stosowanego dziś AES.

Niestety szyfry blokowe mają jedną rażącą słabość. Typowy rozmiar bloku to 128 bitów, czyli 16 znaków. Oczywiście współczesna kryptografia wymaga pracy z większymi danymi wejściowymi i tutaj w grę wchodzą tryby szyfrowania. Tryb szyfrowania to w zasadzie hack: to sposób na zastosowanie szyfru blokowego, który akceptuje tylko dane wejściowe o określonym rozmiarze, do wprowadzania danych o dowolnej długości.

Atak Vodene koncentruje się na popularnym trybie działania CBC (Cipher Block Chaining). Atak traktuje podstawowy szyfr blokowy jako magiczną, niemożliwą do zdobycia czarną skrzynkę i całkowicie omija jego zabezpieczenia.

Oto diagram pokazujący, jak działa tryb CBC:

Plus w kółku oznacza operację XOR (wyłączne LUB). Na przykład odbierany jest drugi blok tekstu zaszyfrowanego:

1. Wykonując operację XOR na drugim bloku tekstu jawnego z pierwszym blokiem tekstu zaszyfrowanego.
2. Szyfrowanie powstałego bloku szyfrem blokowym za pomocą klucza.

Ponieważ CBC tak intensywnie wykorzystuje binarną operację XOR, poświęćmy chwilę na przypomnienie niektórych jej właściwości:

• Idempotencja:
• Przemienność:
• Łączność:
• Samoodwracalność:
• Rozmiar bajtu: bajt n z = (bajt n z ) (bajt nr )

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

Istnieją dwie drobne różnice i jedna główna różnica między naszym scenariuszem Alice a atakiem Vaudenaya. Dwa mniejsze:

• W scenariuszu Alice spodziewała się, że teksty jawne będą kończyć się postaciami a, bb, ccc i tak dalej. Zamiast tego w ataku Wodene ofiara oczekuje, że teksty jawne zakończą się N razy N bajtem (tj. w formacie szesnastkowym 01, 02 02, 03 03 03 itd.). Jest to różnica czysto kosmetyczna.
• W scenariuszu z Alicją łatwo było stwierdzić, czy Alicja przyjęła wiadomość, na podstawie odpowiedzi „Niepoprawny fikcyjny tekst”. W przypadku ataku Vodene wymagana jest większa analiza i ważne jest precyzyjne wdrożenie po stronie ofiary; ale dla zachowania zwięzłości przyjmijmy za pewnik, że taka analiza jest nadal możliwa.

Główna różnica:

• Ponieważ nie używamy tego samego kryptosystemu, związek pomiędzy kontrolowanymi przez atakującego bajtami tekstu zaszyfrowanego a sekretami (kluczem i tekstem jawnym) będzie oczywiście inny. Dlatego atakujący będzie musiał zastosować inną strategię podczas tworzenia szyfrogramów i interpretowania odpowiedzi serwera.

Ta zasadnicza różnica jest ostatnim elementem układanki pozwalającym zrozumieć atak w Vaudenay, więc poświęćmy chwilę na przemyślenie, dlaczego i w jaki sposób można w ogóle przeprowadzić atak wyroczni na CBC.

Załóżmy, że otrzymaliśmy szyfrogram CBC składający się z 247 bloków i chcemy go odszyfrować. Możemy wysyłać fałszywe wiadomości na serwer, tak jak wcześniej mogliśmy wysyłać fałszywe wiadomości do Alicji. Serwer odszyfruje za nas wiadomości, ale nie pokaże odszyfrowania - zamiast tego, podobnie jak w przypadku Alicji, serwer zgłosi tylko jeden bit informacji: czy zwykły tekst ma prawidłowe dopełnienie, czy nie.

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

$$display$$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key}) = tekst{zwykłytekst}$$display$$

Nazwijmy to „równaniem Alicji”. Kontrolowaliśmy szyfrogram; serwer (Alice) ujawnił niejasne informacje na temat otrzymanego tekstu jawnego; co pozwoliło nam wydedukować informację o ostatnim czynniku – kluczu. Analogicznie, jeśli uda nam się znaleźć takie powiązanie ze skryptem CBC, być może uda nam się również tam wydobyć jakieś tajne informacje.

Na szczęście istnieją naprawdę relacje, z których możemy skorzystać. Rozważ wynik końcowego wywołania odszyfrowania szyfru blokowego i oznacz to wyjście jako . Oznaczamy także bloki tekstu jawnego i bloki szyfrogramu . Przyjrzyj się jeszcze raz diagramowi CBC i zwróć uwagę, co się dzieje:

Nazwijmy to „równaniem CBC”.

W scenariuszu Alicji, monitorując zaszyfrowany tekst i obserwując wyciek odpowiadającego mu tekstu jawnego, byliśmy w stanie przeprowadzić atak, który odzyskał trzeci człon równania – klucz. W scenariuszu CBC monitorujemy również tekst zaszyfrowany i obserwujemy wycieki informacji w odpowiadającym mu tekście jawnym. Jeśli analogia jest zachowana, możemy uzyskać informacje nt .

Załóżmy, że naprawdę przywróciliśmy , co wtedy? Cóż, wtedy możemy wydrukować od razu cały ostatni blok tekstu jawnego (), po prostu wchodząc (które mamy) i
Odebrane do równania CBC.

Teraz, gdy jesteśmy optymistami co do ogólnego planu ataku, czas opracować szczegóły. Zwróć uwagę, w jaki sposób informacje w postaci zwykłego tekstu wyciekają na serwer. W skrypcie Alicji wyciek nastąpił, ponieważ Alicja odpowiedziałaby poprawną wiadomością tylko wtedy, gdyby $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ kończyło się linią a (or bbi tak dalej, ale ryzyko przypadkowego wywołania tych stanów było bardzo małe). Podobnie jak w CBC, serwer akceptuje dopełnienie wtedy i tylko wtedy, gdy kończy się liczbą szesnastkową 01. Spróbujmy więc tej samej sztuczki: wysyłania fałszywych szyfrogramów z naszymi własnymi fałszywymi wartościami do czasu, aż serwer zaakceptuje nadzienie.

Gdy serwer zaakceptuje dopełnienie jednej z naszych fałszywych wiadomości, oznacza to, że:

Teraz używamy właściwości bajt-bajt XOR:

Znamy pierwszy i trzeci wyraz. I widzieliśmy już, że pozwala nam to odzyskać pozostały termin - ostatni bajt z :

Daje nam to również ostatni bajt końcowego bloku tekstu jawnego za pomocą równania CBC i właściwości bajt po bajcie.

Moglibyśmy tak to zostawić i mieć satysfakcję, że przeprowadziliśmy atak na teoretycznie silny szyfr. Ale tak naprawdę możemy zrobić znacznie więcej: możemy odzyskać cały tekst. Wymaga to sztuczki, której nie było w oryginalnym skrypcie Alicji i która nie jest wymagana do ataku na wyrocznię, ale mimo to warto się jej nauczyć.

Aby to zrozumieć, należy najpierw zauważyć, że wynikiem wypisywania prawidłowej wartości ostatniego bajtu jest mamy nową zdolność. Teraz, fałszując szyfrogramy, możemy manipulować ostatnim bajtem odpowiedniego tekstu jawnego. Ponownie jest to powiązane z równaniem CBC i właściwością bajt po bajcie:

Ponieważ znamy już drugi człon, możemy wykorzystać naszą kontrolę nad pierwszym, aby kontrolować trzeci. Po prostu obliczamy:

Nie mogliśmy tego zrobić wcześniej, ponieważ nie mieliśmy jeszcze ostatniego bajtu .

W jaki sposób nam to pomoże? Załóżmy, że teraz utworzymy wszystkie szyfrogramy w taki sposób, że w odpowiednich tekstach jawnych ostatni bajt będzie równy 02. Serwer akceptuje teraz dopełnienie tylko wtedy, gdy zwykły tekst 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 miał wartość 02. Wysyłamy fałszywe bloki tekstu zaszyfrowanego, zmieniając przedostatni bajt, dopóki serwer nie zaakceptuje dopełnienia jednego z nich. W tym momencie otrzymujemy:

I przywracamy przedostatni bajt tak jak poprzednio został przywrócony. Kontynuujemy w tym samym duchu: poprawiamy dwa ostatnie bajty tekstu jawnego 03 03, powtarzamy ten atak dla trzeciego bajtu od końca i tak dalej, ostatecznie całkowicie przywracając .

A co z resztą tekstu? Należy pamiętać, że wartość w rzeczywistości jest $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Zamiast tego możemy umieścić dowolny inny blok , a atak i tak będzie skuteczny. Tak naprawdę możemy poprosić serwer o wykonanie $inline$text{BLOCK_DECRYPT}$inline$ dla dowolnych danych. W tym momencie gra jest zakończona — możemy odszyfrować dowolny zaszyfrowany tekst (aby to zobaczyć, spójrz jeszcze raz na diagram deszyfrowania CBC; i zwróć uwagę, że IV jest publiczny).

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

Atak Kelseya

Nasz sympatyczny John Kelsey przedstawił zasady leżące u podstaw wielu możliwych ataków, a nie tylko szczegóły konkretnego ataku na konkretny szyfr. Jego Artykuł 2002 roku to badanie możliwych ataków na zaszyfrowane, skompresowane dane. Czy uważasz, że informacja o tym, że dane zostały skompresowane przed zaszyfrowaniem, nie wystarczyła, aby przeprowadzić atak? Okazuje się, że to wystarczy.

Ten zaskakujący wynik wynika z dwóch zasad. Po pierwsze, istnieje silna korelacja między długością tekstu jawnego a długością tekstu zaszyfrowanego; dla wielu szyfrów dokładna równość. Po drugie, podczas kompresji istnieje również silna korelacja między długością skompresowanej wiadomości a stopniem „zaszumienia” tekstu jawnego, to znaczy proporcją niepowtarzających się znaków (termin techniczny to „wysoka entropia” ).

Aby zobaczyć tę zasadę w działaniu, rozważ dwa teksty jawne:

Tekst jawny 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Tekst jawny 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Załóżmy, że oba teksty jawne są skompresowane, a następnie zaszyfrowane. Otrzymujesz dwa wynikowe teksty zaszyfrowane i musisz zgadnąć, który tekst zaszyfrowany pasuje do którego tekstu jawnego:

Zaszyfrowany tekst 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Zaszyfrowany tekst 2: DWKJZXYU

Odpowiedź jest jasna. Spośród tekstów jawnych tylko tekst jawny 1 można było skompresować do niewielkiej długości drugiego tekstu zaszyfrowanego. Rozwiązaliśmy ten problem, nie wiedząc nic o algorytmie kompresji, kluczu szyfrującym ani nawet o samym szyfrze. W porównaniu z hierarchią możliwych ataków kryptograficznych jest to trochę szalone.

Kelsey wskazuje dalej, że w pewnych nietypowych okolicznościach zasadę tę można również zastosować do przeprowadzenia ataku na wyrocznię. W szczególności opisuje, w jaki sposób osoba atakująca może odzyskać tajny tekst jawny, jeśli może zmusić serwer do zaszyfrowania danych formularza (tekst jawny, po którym następuje póki on ma kontrolę i może w jakiś sposób sprawdzić długość zaszyfrowanego wyniku.

Ponownie, podobnie jak w przypadku innych ataków na wyrocznię, mamy relację:

Ponownie kontrolujemy jeden termin (), widzimy mały wyciek informacji o innym elemencie (tekst zaszyfrowany) i próbujemy odzyskać ostatni (tekst jawny). Pomimo analogii jest to dość niezwykła sytuacja w porównaniu z innymi atakami na Oracle, które widzieliśmy.

Aby zilustrować, jak taki atak może zadziałać, użyjmy fikcyjnego schematu kompresji, który właśnie wymyśliliśmy: TOYZIP. Wyszukuje wiersze tekstu, które pojawiły się wcześniej w tekście i zastępuje je trzema bajtami zastępczymi, które wskazują, gdzie znaleźć wcześniejsze wystąpienie wiersza i ile razy się ono tam pojawiło. Na przykład linia helloworldhello można skompresować helloworld[00][00][05] Długość 13 bajtów w porównaniu do oryginalnych 15 bajtów.

Załóżmy, że osoba atakująca próbuje odzyskać tekst jawny formularza password=..., gdzie samo hasło jest nieznane. Zgodnie z modelem ataku Kelseya osoba atakująca może poprosić serwer o skompresowanie, a następnie zaszyfrowanie wiadomości w formularzach (zwykły tekst, po którym następuje ) gdzie  - dowolny tekst. Kiedy serwer zakończy pracę, raportuje długość wyniku. Atak wygląda następująco:

Włamywacz: Proszę skompresować i zaszyfrować zwykły tekst bez dopełnienia.

Serwer: Długość wyniku 14.

Włamywacz: Proszę skompresować i zaszyfrować tekst jawny, do którego jest dołączony password=a.

Serwer: Długość wyniku 18.

Krakers zauważa: [oryginał 14] + [trzy bajty, które zastąpiono password=] + a

Włamywacz: Proszę skompresować i zaszyfrować tekst jawny, do którego zostanie dodany password=b.

Serwer: Długość wyniku 18.

Włamywacz: Proszę skompresować i zaszyfrować tekst jawny, do którego zostanie dodany password=с.

Serwer: Długość wyniku 17.

Krakers zauważa: [oryginał 14] + [trzy bajty, które zastąpiono password=c] Zakłada się, że oryginalny tekst jawny zawiera ciąg password=c. Oznacza to, że hasło zaczyna się od litery c

Włamywacz: Proszę skompresować i zaszyfrować tekst jawny, do którego zostanie dodany password=сa.

Serwer: Długość wyniku 18.

Krakers zauważa: [oryginał 14] + [trzy bajty, które zastąpiono password=с] + a

Włamywacz: Proszę skompresować i zaszyfrować tekst jawny, do którego zostanie dodany password=сb.

Serwer: Długość wyniku 18.

(… Jakiś czas później…)

Włamywacz: Proszę skompresować i zaszyfrować tekst jawny, do którego zostanie dodany password=со.

Serwer: Długość wyniku 17.

Krakers zauważa: [oryginał 14] + [trzy bajty, które zastąpiono password=co] Stosując tę ​​samą logikę, atakujący dochodzi do wniosku, że hasło zaczyna się od liter co

I tak dalej, aż do przywrócenia całego hasła.

Czytelnikowi wybaczono, jeśli pomyślał, że jest to ćwiczenie czysto akademickie i że taki scenariusz ataku nigdy nie miałby miejsca w prawdziwym świecie. Niestety, jak wkrótce się przekonamy, z kryptografią lepiej nie rezygnować.

Podatności marki: CRIME, POODLE, DROWN

Wreszcie, po szczegółowym przestudiowaniu teorii, możemy zobaczyć, jak techniki te są stosowane w rzeczywistych atakach kryptograficznych.

PRZESTĘPSTWO

Jeśli celem ataku jest przeglądarka i sieć ofiary, niektóre będą łatwiejsze, inne trudniejsze. Na przykład łatwo jest zobaczyć ruch ofiary: po prostu usiądź z nią w tej samej kawiarni z Wi-Fi. Z tego powodu potencjalnym ofiarom (tj. wszystkim) zaleca się zazwyczaj korzystanie z szyfrowanego połączenia. Wysyłanie żądań HTTP w imieniu ofiary do witryny strony trzeciej (na przykład Google) będzie trudniejsze, ale nadal możliwe. Osoba atakująca musi zwabić ofiarę na złośliwą stronę internetową za pomocą skryptu wysyłającego żądanie. Przeglądarka internetowa automatycznie udostępni odpowiedni sesyjny plik cookie.

To wydaje się niesamowite. Jeśli Bob poszedł evil.com, czy skrypt w tej witrynie mógłby po prostu poprosić firmę Google o przesłanie hasła do Boba pocztą elektroniczną na adres [email protected]? Cóż, w teorii tak, ale w praktyce nie. Ten scenariusz nazywa się atakiem polegającym na fałszowaniu żądań między witrynami (Fałszerstwo żądań między witrynami, CSRF) i był popularny około połowy lat 90-tych. Dzisiaj jeśli evil.com spróbuje tej sztuczki, Google (lub jakakolwiek szanująca się witryna internetowa) zwykle odpowie: „Świetnie, ale Twój token CSRF dla tej transakcji będzie… hm… три триллиона и семь. Proszę powtórzyć ten numer.” Nowoczesne przeglądarki mają coś, co nazywa się „zasadą tego samego pochodzenia”, zgodnie z którą skrypty w witrynie A nie mają dostępu do informacji wysyłanych przez witrynę B. Zatem skrypt w witrynie evil.com może wysyłać prośby do google.com, ale nie mogę odczytać odpowiedzi ani sfinalizować transakcji.

Musimy podkreślić, że jeśli Bob nie korzysta z szyfrowanego połączenia, wszystkie te zabezpieczenia są bez znaczenia. Osoba atakująca może po prostu odczytać ruch Boba i odzyskać plik cookie sesji Google. Za pomocą tego pliku cookie po prostu otworzy nową kartę Google bez opuszczania własnej przeglądarki i podszyje się pod Boba, nie napotykając irytujących zasad tego samego pochodzenia. Ale na nieszczęście w przypadku włamywacza zdarza się to coraz rzadziej. Internet jako całość od dawna wypowiada wojnę niezaszyfrowanym połączeniom, a ruch wychodzący Boba jest prawdopodobnie szyfrowany, czy mu się to podoba, czy nie. Poza tym od samego początku wdrożenia protokołu ruch też był skurczył się przed szyfrowaniem; była to powszechna praktyka mająca na celu zmniejszenie opóźnień.

To tutaj wchodzi w grę PRZESTĘPSTWO (Współczynnik kompresji Infoleak Made Easy, prosty wyciek poprzez stopień kompresji). Luka została ujawniona we wrześniu 2012 roku przez badaczy bezpieczeństwa Juliano Rizzo i Thai Duong. Przeanalizowaliśmy już całą podstawę teoretyczną, która pozwala nam zrozumieć, co i jak zrobili. Osoba atakująca może zmusić przeglądarkę Boba do wysyłania żądań do Google, a następnie słuchania odpowiedzi w sieci lokalnej w skompresowanej, zaszyfrowanej formie. Dlatego mamy:

Tutaj atakujący kontroluje żądanie i ma dostęp do sniffera ruchu, w tym do rozmiaru pakietu. Fikcyjny scenariusz Kelseya ożył.

Rozumiejąc teorię, autorzy CRIME stworzyli exploita, który może kraść pliki cookie sesji dla szerokiej gamy witryn, w tym Gmaila, Twittera, Dropbox i Github. Luka ta dotyczyła większości nowoczesnych przeglądarek internetowych, w wyniku czego wydano łatki, które po cichu ukryły funkcję kompresji w protokole SSL, uniemożliwiając jej w ogóle użycie. Jedyną chronioną przed tą luką był czcigodna przeglądarka Internet Explorer, która w ogóle nigdy nie korzystała z kompresji SSL.

Pudel

W październiku 2014 r. zespół Google ds. bezpieczeństwa wywołał poruszenie w społeczności zajmującej się bezpieczeństwem. Udało im się wykorzystać lukę w protokole SSL, która została załatana ponad dziesięć lat temu.

Okazuje się, że chociaż na serwerach działa nowy, błyszczący protokół TLSv1.2, wiele z nich zrezygnowało ze wsparcia starszego protokołu SSLv3 w celu zapewnienia kompatybilności wstecznej z Internet Explorerem 6. Mówiliśmy już o atakach na obniżenie wersji, więc możesz sobie wyobrazić, co się dzieje. Dobrze zorganizowany sabotaż protokołu uzgadniania i serwery są gotowe do powrotu do starego, dobrego protokołu SSLv3, zasadniczo cofając ostatnie 15 lat badań nad bezpieczeństwem.

Ze względu na kontekst historyczny oto krótkie podsumowanie historii protokołu SSL do wersji 2 autorstwa Matthew Greena:

Transport Layer Security (TLS) to najważniejszy protokół bezpieczeństwa w Internecie. [..] prawie każda transakcja, której dokonujesz w Internecie, opiera się na TLS. [..] Ale TLS nie zawsze był TLS. Protokół rozpoczął swoje życie w Komunikacja Netscape zwane „Secure Sockets Layer” lub SSL. Plotka głosi, że pierwsza wersja SSL była tak straszna, że ​​programiści zebrali wszystkie wydruki kodu i zakopali je na tajnym wysypisku śmieci w Nowym Meksyku. W konsekwencji faktycznie istnieje pierwsza publicznie dostępna wersja protokołu SSL wersja SSL2. To dość przerażające, a […] był to produkt z połowy lat 90., który współcześni kryptografowie uważają za „ciemne wieki kryptografii" Wiele z najohydniejszych ataków kryptograficznych, jakie znamy dzisiaj, nie zostało jeszcze odkrytych. W rezultacie twórcy protokołu SSLv2 zostali w zasadzie pozostawieni samym sobie, błądząc po omacku ​​i stanęli przed wyzwaniem: mnóstwo strasznych potworów - ku ich rozczarowaniu i naszej korzyści, ponieważ ataki na SSLv2 pozostawiły bezcenne lekcje dla następnej generacji protokołów.

W następstwie tych wydarzeń w 1996 roku sfrustrowany Netscape przeprojektował protokół SSL od podstaw. W rezultacie powstał protokół SSL w wersji 3, który naprawiono kilka znanych problemów związanych z bezpieczeństwem swojego poprzednika.

Na szczęście dla włamywaczy „kilka” nie oznacza „wszystkich”. Ogólnie rzecz biorąc, protokół SSLv3 zapewnił wszystkie elementy niezbędne do przeprowadzenia ataku Vodene. Protokół wykorzystywał szyfr blokowy w trybie CBC i niepewny schemat dopełniania (poprawiono to w TLS; stąd potrzeba ataku na obniżenie wersji). Jeśli pamiętasz schemat dopełniania z naszego oryginalnego opisu ataku Vaudenay, schemat SSLv3 jest bardzo podobny.

Ale, niestety, dla włamywaczy „podobny” nie oznacza „identyczny”. Schemat dopełniania SSLv3 to „N losowych bajtów, po których następuje liczba N”. Spróbuj, w tych warunkach, wybrać wyimaginowany blok tekstu zaszyfrowanego i przejść przez wszystkie etapy oryginalnego schematu Vaudene'a: ​​przekonasz się, że atak pomyślnie wyodrębnia ostatni bajt z odpowiedniego bloku tekstu jawnego, ale nie idzie dalej. Odszyfrowanie co 16 bajtów szyfrogramu to świetna sztuczka, ale nie zwycięstwo.

W obliczu porażki zespół Google zdecydował się na ostatnią deskę ratunku: przeszedł na potężniejszy model zagrożenia – ten stosowany w CRIME. Zakładając, że atakującym jest skrypt działający w karcie przeglądarki ofiary i potrafiący wyodrębnić pliki cookie sesji, atak i tak robi wrażenie. Chociaż szerszy model zagrożenia jest mniej realistyczny, w poprzedniej sekcji widzieliśmy, że ten konkretny model jest wykonalny.

Biorąc pod uwagę te potężniejsze możliwości atakującego, atak może być teraz kontynuowany. Należy pamiętać, że osoba atakująca wie, gdzie w nagłówku pojawia się zaszyfrowany plik cookie sesji i kontroluje długość poprzedzającego go żądania HTTP. Dlatego może manipulować żądaniem HTTP tak, aby ostatni bajt pliku cookie był wyrównany z końcem bloku. Teraz ten bajt nadaje się do odszyfrowania. Możesz po prostu dodać jeden znak do żądania, a przedostatni bajt pliku cookie pozostanie w tym samym miejscu i będzie nadawał się do selekcji przy użyciu tej samej metody. Atak trwa w ten sposób do momentu całkowitego przywrócenia pliku cookie. Nazywa się POODLE: Dopełnianie Oracle przy obniżonym szyfrowaniu.

UTOPIĆ SIĘ

Jak wspomnieliśmy, SSLv3 miał swoje wady, ale zasadniczo różnił się od swojego poprzednika, ponieważ nieszczelny SSLv2 był produktem innej epoki. Tam możesz przerwać wiadomość w środku: соглашусь на это только через мой труп zmienił się w соглашусь на это; klient i serwer mogą spotkać się online, ustanowić zaufanie i wymienić tajemnice przed atakującym, który następnie może z łatwością podszyć się pod obydwa. Istnieje również problem z kryptografią eksportową, o którym wspominaliśmy rozważając FREAK. Były to kryptograficzne Sodoma i Gomora.

W marcu 2016 r. zespół badaczy z różnych dziedzin technicznych zebrał się i dokonał zaskakującego odkrycia: protokół SSLv2 jest nadal używany w systemach bezpieczeństwa. Tak, napastnicy nie mogli już obniżyć nowoczesnych sesji TLS do SSLv2, ponieważ ta luka została zamknięta po FREAK i POODLE, ale nadal mogą łączyć się z serwerami i sami inicjować sesje SSLv2.

Możesz zapytać, dlaczego obchodzi nas, co tam robią? Mają wrażliwą sesję, ale nie powinno to mieć wpływu na inne sesje ani bezpieczeństwo serwera - prawda? Cóż, nie do końca. Tak, tak to powinno wyglądać w teorii. Ale nie - ponieważ generowanie certyfikatów SSL wiąże się z pewnym obciążeniem, przez co wiele serwerów korzysta z tych samych certyfikatów i w efekcie tych samych kluczy RSA dla połączeń TLS i SSLv2. Co gorsza, z powodu błędu OpenSSL opcja „Wyłącz SSLv2” w tej popularnej implementacji SSL w rzeczywistości nie działała.

Umożliwiło to wieloprotokołowy atak na TLS, tzw UTOPIĆ SIĘ (Odszyfrowanie RSA za pomocą przestarzałego i osłabionego szyfrowania, odszyfrowanie RSA za pomocą przestarzałego i osłabionego szyfrowania). Pamiętaj, że to nie to samo, co krótki atak; atakujący nie musi zachowywać się jak „człowiek pośrodku” i nie musi angażować klienta do udziału w niezabezpieczonej sesji. Osoby atakujące po prostu inicjują niezabezpieczoną sesję SSLv2 z serwerem, atakują słaby protokół i odzyskują klucz prywatny RSA serwera. Ten klucz jest również ważny dla połączeń TLS i od tego momentu żadne zabezpieczenia TLS nie zapobiegną jego naruszeniu.

Ale aby go złamać, potrzebny jest działający atak na SSLv2, który pozwala odzyskać nie tylko określony ruch, ale także tajny klucz serwera RSA. Chociaż jest to złożona konfiguracja, badacze mogli wybrać dowolną lukę, która została całkowicie usunięta po SSLv2. W końcu znaleźli odpowiednią opcję: atak Bleichenbachera, o którym wspominaliśmy wcześniej i który szczegółowo wyjaśnimy w następnym artykule. SSL i TLS są chronione przed tym atakiem, ale niektóre losowe funkcje SSL w połączeniu z krótkimi kluczami w kryptografii klasy eksportowej umożliwiły konkretna implementacja DROWN.

W chwili publikacji luka DROWN dotyczyła 25% najpopularniejszych witryn w Internecie, a atak można było przeprowadzić przy skromnych zasobach dostępnych nawet dla złośliwych, samotnych hakerów. Odzyskanie klucza RSA serwera wymagało ośmiu godzin obliczeń i 440 dolarów, a protokół SSLv2 zmienił się z przestarzałego w radioaktywny.

Czekaj, a co z Heartbleed?

Nie jest to atak kryptograficzny w sensie opisanym powyżej; To jest przepełnienie bufora.

Zróbmy przerwę

Zaczęliśmy od kilku podstawowych technik: brutalnej siły, interpolacji, obniżania wersji, protokołu krzyżowego i obliczeń wstępnych. Następnie przyjrzeliśmy się jednej zaawansowanej technice, być może głównej składowej współczesnych ataków kryptograficznych: atakowi na Oracle. Spędziliśmy sporo czasu, żeby to rozgryźć i zrozumieliśmy nie tylko podstawową zasadę, ale także szczegóły techniczne dwóch konkretnych implementacji: ataku Vaudenaya na tryb szyfrowania CBC i ataku Kelseya na protokoły szyfrowania przed kompresją.

Przeglądając ataki na obniżenie wersji i obliczenia wstępne, pokrótce omówiliśmy atak FREAK, który wykorzystuje obie metody, polegając na tym, że witryny docelowe przestają korzystać ze słabych kluczy, a następnie ponownie używają tych samych kluczy. W następnym artykule opiszemy (bardzo podobny) atak Logjam, którego celem są algorytmy klucza publicznego.

Następnie przyjrzeliśmy się trzem kolejnym przykładom zastosowania tych zasad. Po pierwsze, CRIME i POODLE: dwa ataki, które polegały na zdolności atakującego do wstrzyknięcia dowolnego tekstu jawnego obok docelowego tekstu jawnego, następnie sprawdzeniu odpowiedzi serwera i wtedyużywając metodologii ataku Oracle, wykorzystaj te rzadkie informacje, aby częściowo odzyskać zwykły tekst. CRIME poszło drogą ataku Kelseya na kompresję SSL, podczas gdy POODLE zamiast tego użył wariantu ataku Vaudenaya na CBC z tym samym skutkiem.

Następnie zwróciliśmy naszą uwagę na wieloprotokołowy atak DROWN, który ustanawia połączenie z serwerem przy użyciu starszego protokołu SSLv2, a następnie odzyskuje tajne klucze serwera za pomocą ataku Bleichenbacher. Na razie pominęliśmy szczegóły techniczne tego ataku; podobnie jak Logjam, będzie musiał poczekać, aż dobrze zrozumiemy kryptosystemy klucza publicznego i ich słabe punkty.

W następnym artykule porozmawiamy o zaawansowanych atakach, takich jak spotkanie w środku, kryptoanaliza różnicowa i ataki urodzinowe. Przejdźmy szybko do ataków z kanału bocznego, a następnie przejdźmy do zabawniejszej części: kryptosystemów klucza publicznego.

Źródło: www.habr.com