Когато чуете думата "криптография", някои си припомнят паролата за WiFi, зелената катинарска икона до адреса на любимия си сайт и как е трудно да се получи достъп до чужда поща. Други си спомнят редица уязвимости от последните години, съпроводени с говорещи акроними (DROWN, FREAK, POODLE…) и стилни лога с предупреждение за спешно обновяване на браузъра.

Криптографията обхваща всичко това, но същността е в нещо друго. Същността е в тънката граница между простото и сложното. Някои неща са лесни за правене, но трудно се връщат обратно: например, разбиването на яйце. Други неща са лесни за правене, но трудно се връщат обратно, когато липсва малкото важно решаващо парче: например, отварянето на заключена врата, когато "решаващата част" е ключът. Криптографията изучава тези ситуации и начините за тяхното практическо приложение.

През последните години колекцията от криптографски атаки се е трансформирала в зоопарк от крещящи лога, натъпкани с формули от научни статии, предизвиквайки усещане, че всичко е счупено. Но всъщност много от атаките се основават на няколко общи принципа, а безкрайните страници с формули често водят до лесни за разбиране идеи.

В тази серия статии ще разгледаме различни типове криптографски атаки, с акцент върху основните принципи. В общи линии и не точно в този ред, но ще обсъдим следното:

Основни стратегии: брутфорс, честотен анализ, интерполация, понижение и крос-протоколи.
"Брендови" уязвимости: FREAK, CRIME, POODLE, DROWN, Logjam.
Напреднали стратегии: атаки на oracle (атака Воденэ, атака Келси); метод за среща по средата (meet-in-the-middle), атака "рожден ден", статистическо изкривяване (диференциален криптоанализ, интегрален криптоанализ и т.н.).
Атаки чрез странични канали и техните близки роднини, методи за анализ на сривове.
Атаки срещу криптографията с открит ключ: кубичен корен, броадкаст, свързано съобщение, атака на Копперсмит, алгоритъм на Полиг-Хелман, числово сито, атака на Винер, атака на Блайхенбахер.

Тази конкретна статия обхваща горепосочения материал до атаката на Келси.

Основни стратегии

Следващите атаки са прости в смисъл, че могат да бъдат практически напълно обяснени без сложни технически детайли. Ще обясним всеки тип атака с най-простите термини, без да задълбаваме в сложни примери или разширени случаи на употреба.

Някои от тези атаки в основата си вече са изгубили своето значение и не са прилагани от много години. Други - ветерани, все още регулярно подхождат на нищо неподозиращите разработчици на криптосистеми в 21-ви век. Може да се каже, че ерата на съвременната криптография започна с появата на IBM DES - първият шифър, който устоя на всички атаки в този списък.

Прост брутфорс

Схемата на шифриране се състои от две части: 1) функция за шифриране, която приема съобщение (открит текст) в комбинация с ключ, и след това създава зашифрено съобщение - шифротекст; 2) функция за декриптиране, която приема шифротекст и ключ и създава открит текст. И шифрирането, и декриптирането трябва да са лесно изчисляеми с ключа - и трудни без него.

Предположим, че виждаме шифротекст и се опитваме да го декриптираме без каквато и да е допълнителна информация (това се нарича атака "само шифротекст"). Ако по някакво вълшебно стечение на обстоятелствата намерим правилния ключ, можем лесно да проверим дали той наистина е правилния, ако резултатът е разумно съобщение.

Обърнете внимание, че тук има две недвусмислени предположения. На първо място, че знаем как да извършим декриптиране, т.е. как работи криптосистемата. Това е стандартно предположение при обсъждане на криптографията. Скриването на детайлите на реализацията на шифъра от злоумишлениците може да изглежда като допълнителна мярка за сигурност, но щом злоумишленикът разбере тези детайли, тази допълнителна сигурност бързо и необратимо се губи. Такъв принципът на Керчхоффс: попадането на системата в ръцете на врага не трябва да причинява неудобства.

На второ място, предвиждаме, че правилният ключ е единственият ключ, който води до разумно декриптиране. Това също е разумно предположение; то е валидно, ако шифротекстът е доста по-дълъг от ключа и веднъж четим. Както обикновено се случва в реалния свят, с изключение на огромни непрактични ключове или други манипулации, които е по-добре да оставим настрана. (ако не ви харесва, че пренебрегнахме обясненията, моля, вижте теорема 3.8 тук.).

Като вземем предвид горното, се появява стратегия: да проверим всеки възможен ключ. Това се нарича брутфорс и такава атака гарантирано работи срещу всички практически шифри — в крайна сметка. Например, брутфорсът е достатъчен, за да се разбие шифърът на Цезар, древен шифър, при който ключът е една буква от азбуката, което предполага малко над 20 възможни ключа.

За съжаление за криптоанализаторите, увеличаването на размера на ключа добре защитава от брутфорс. С увеличаване на размера на ключа, броят на възможните ключове нараства експоненциално. Със съвременните размери на ключовете, простият брутфорс е напълно непрактичен. За да разберем какво имаме предвид, нека вземем най-бързия известен суперкомпютър в средата на 2019 година: Summit, от IBM, с пикова производителност около 10^17 операции в секунда. Днес типичната дължина на ключа е 128 бита, което означава 2^128 възможни комбинации. За да пробие всички ключове, суперкомпютърът Summit ще се нуждае от време, което е приблизително 7800 пъти по-дълго от възрастта на Вселената.

Дали да сметнем брутфорса за исторически куриоз? В никакъв случай: това е необходима съставка в готварската книга на криптоанализа. Рядко срещани са шифрите, толкова слаби, че могат да бъдат разбити само с умна атака, без използване на сила в известен план. Много успешни пробиви използват първо алгоритмичен метод, за да отслабят целевия шифър, а след това стартират брутфорса.

Честотен анализ

Повечето текстове не са несвързани. Например, в англоезичните текстове има много букви ‘e’ и членове ‘the’; в двоичните файлове — много нулеви байтове като запълващи елементи между фрагменти от информация. Честотният анализ е всяка атака, която използва този факт.

Каноничният пример на шифър, уязвим за тази атака, е простият шифър на подмяна. В този шифър ключът представлява таблица с подмяна на всички букви. Например, ‘g’ се заменя с ‘h’, ‘o’ — с ‘j’, следователно думата ‘go’ се превръща в ‘hj’. Този шифър е труден за просто брутфорс, тъй като съществуват много възможни таблици за подмяна. Ако ви интересува математиката, ефективната дължина на ключа е около 88 бита: това
. Но честотният анализ обикновено разпознава задачата бързо.

Нека да разгледаме следния шифрован текст, обработен с прост шифър за подмяна:

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

Тъй като Y се среща често, включително в края на много думи, можем предварително да предположим, че това е буква e:

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

Пара XD се повтаря в началото на няколко думи. По-конкретно, комбинацията XDeLe явно предполага думата these или there, затова продължаваме:

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

Нататък предполагаме, че L отговаря на r, A — a и така нататък. Вероятно ще трябва да направите няколко опити, но в сравнение с пълния брутфорс, тази атака възстановява оригиналния текст в най-кратки срокове:

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

За някои, решаването на такива "криптограми" е увлекателно хоби.

Идеята за честотния анализ е по-фундаментална, отколкото изглежда на пръв поглед. И той е приложим към много по-сложни шифри. През историята различни конструкции на шифри са се опитвали да се противопоставят на такава атака с помощта на "полиалфавитна подмяна". Тук в процеса на шифроване, таблицата за замяна на букви се променя по сложни, но предсказуеми начини, зависящи от ключа. Всички тези шифри в свое време са се считали за трудни за разбиване; и все пак скромният честотен анализ в крайна сметка ги надмогна.

Най-амбициозният полиалфавитен шифър в историята, и вероятно най-известният, беше шифърът "Енигма" по време на Втората световна война. Той беше относително сложен в сравнение с предшествениците си, но в резултат на дълги и упорити усилия британските криптоаналитици го разбиха с помощта на честотен анализ. Разбира се, те не успяха да разработят елегантна атака, както е показано по-горе; трябваше да сравняват известни двойки отворени и шифровани текстове (така наречената "атака, основана на отворени текстове") и дори да провокират потребителите на "Енигма" да шифроват определени съобщения с анализ на резултата ("атака, основана на подбран отворен текст"). Но това не облекчи съдбата на победените армии на враговете и потопените подводници.

След този триумф, честотният анализ изчезна от историята на криптоанализа. Шифрите на съвременната цифрова епоха са създадени да работят с битове, а не с букви. Но, още по-важно, тези шифри са разработени с мрачна осведоменост за това, което по-късно стана известно като закона на Шнайер: всеки може да създаде алгоритъм за шифроване, който сам не може да сломи. Недостатъчно е шифровалната система да изглежда сложна: за да докаже стойността си, тя трябва да премине през безмилостен преглед на сигурността от много криптоаналитици, които ще направят всичко възможно да сломят шифъра.

Предварителни изчисления

Нека вземем хипотетичния град Преком Хайтс с население от 200 000 души. Във всяка къща в града има ценни вещи на средна стойност от 30 000 долара, но не повече от 50 000 долара. Пазарът на сигурност в Прекоме е монополизиран от компания ACME Industries, която произвежда легендарните секретни заключвания клас Coyote ™. Според експертния анализ, заключването клас Coyote може да бъде счупено само от много сложна хипотетична машина, чието създаване изисква около пет години и 50 000 долара инвестиции. Градът ли е в безопасност?

Скоро вероятно не. В крайна сметка ще се появи достатъчно амбициозен престъпник. Той ще разсъждава така: „Да, аз ще понеса значителни авансови разходи. Пет години търпеливо изчакване и 50 000 долара. Но в края на работата ще имам достъп до цялото богатство на този град. Ако изиграя картите си правилно, тази инвестиция многократно ще се изплати.“

Аналогично е и в криптографията. Атаките срещу конкретен шифър подлежат на безмилостен анализ на разходите и ползите. Ако съотношението е благоприятно, атаката няма да се случи. Но атаките, които действат веднага срещу много потенциални жертви, почти винаги се изплащат, и в този случай най-добрата практика на проектиране е да се предполага, че те са започнали от първия ден. Имаме по същество криптографска версия на закона на Мърфи: „Всичко, което наистина може да сломи системата, ще я сломи.“

Най-простият пример за криптосистема, уязвима на атака с предварителни изчисления, е шифър с постоянен алгоритъм без използване на ключ. Така беше и случай с шифъра на Цезар, който просто изместват всяка буква от азбуката с три места напред (таблицата е циклична, така че последната буква от азбуката се криптира с третата). Тук отново проявява принципа на Керчхоффс: след като системата бъде хакната, тя остава компрометирана завинаги.

Концепцията е проста. Дори начинаещ разработчик на криптосистеми вероятно осъзнава заплахите и се подготвя съответно. Ако погледнем еволюцията на криптографията, такива атаки са били неуместни за повечето шифри, от првоначалните подобрени версии на Цезаровия шифър до упадъка на полиалфавитните шифри. Такива атаки се завърнаха едва с настъпването на съвременната ера на криптографията.

Тази завръщане е предизвикано от два фактора. Първо, най-накрая се появиха достатъчно сложни криптосистеми, при които възможността за експлоатация след хакване не беше очевидна. Второ, криптографията стана толкова широко разпространена, че милиони непрофесионалисти всеки ден взимаха решения къде и какви части от криптография да използват повторно. Отне известно време, преди експертите да осъзнаят възникналите рискове и да алармират.

Запомнете атаката с предварителни изчисления: в края на статията ще разгледаме два криптографски примера от реалния живот, където тя изиграва важна роля.

Интерполация

Пред вас е известния детектив Шерлок Холмс, който извършва атака с интерполация на нещастния доктор Уотсън:

Аз веднага се досетих, че сте дошли от Афганистан… Ходът на мислите ми беше следният: „Този човек по тип е лекар, но походката му е военна. Значи е военен лекар. Той току-що се е върнал от тропиците – лицето му е смугло, но това не е естественият оттенък на кожата му, тъй като китките му са много по-бели. Лицето му е изтощено – очевидно е преживял немалко страдания и е прекарал болест. Бил е ранен в лявата ръка – държи я неподвижно и малко неестествено. Къде ли един военен лекар-англичанин е могъл да изпита лишения и да получи рана под тропиците? Разбира се, в Афганистан.“ Целият ход на мислите не отне и секунда. И ето, казах, че сте дошли от Афганистан, а вие се учудихте.

От всяка кошерна улея Холмс можеше да извлече много малко информации. Той можеше да достигне до заключението си само след като ги разгледа заедно. Подобен е принципът на интерполационната атака, изследвайки известните двойки от отворен и криптиран текст, получени чрез прилагането на същия ключ. От всяка двойка се извлекат отделни наблюдения, които дават общо заключение за ключа. Всички тези разсъждения са неясни и изглеждат безполезни, докато не достигнат до критична маса и не доведат до единствено възможно заключение: какъвто и да е невероятен, той трябва да бъде верен. След това или се разкрива ключът, или процесът на декриптиране става толкова опитен, че може да бъде възпроизведен.

Нека илюстрираме с прост пример как работи интерполацията. Да предположим, че искаме да прочетем личния дневник на нашия враг Боб. Той шифрова всяко число в дневника си с проста криптосистема, за която е научил от реклама в списание „Подигравка с криптографията“. Системата работи следния начин: Боб избира две числа, които му харесват: и . От този момент нататък, за да шифрова всяко число , той изчислява . Например, ако Боб е избрал и , то цифрата ще бъде шифрована като .

Да предположим, че на 28 декември забелязваме, че Боб нещо драска в дневника си. Когато завърши, ние незабелязано ще го вземем и ще видим последния запис:

Дата: 235/520
Скъпи дневник,
Днес беше добър ден. След 64 дни имам среща с Алиса, която живее в апартамента 843. Наистина вярвам, че тя може да бъде 26!

Тъй като много сериозно имаме намерение да проследим Боб на срещата му (в този сценарий сме на 15 години), критично е важно да разберем датата, както и адреса на Алиса. За щастие, ние забелязваме, че криптосистемата на Боб е уязвима за интерполационна атака. Може да не знаем и , но знаем днешната дата, така че имаме две двойки "открит текст — шифрован текст". По-конкретно, знаем, че се шифрова в , а — в . Което ще запишем:

Тъй като сме на 15 години, вече знаем за системата с две уравнения с две неизвестни, което в тази ситуация е достатъчно за намиране. и без особени проблеми. Всяка двойка „открит текст-шифротекст“ налага ограничения на ключа на Боб, и две ограничения заедно са достатъчни, за да възстановят напълно ключа. В нашия пример отговорът и (при , така че 26 в дневника съответства на думата ‘the one’, тоест „тази самата“ — б. ред.

Интерполационните атаки, разбира се, не се ограничават до такива прости примери. Всяка криптосистема, която се свежда до добре познат математически обект и списък от параметри, е под риск от интерполационна атака — колкото по-разбираем е обектът, толкова по-висок е рискът.

Новиците често се оплакват, че криптографията е „изкуството да се проектират колкото се може по-страшни неща“. Вероятно много е виновна интерполационната атака. Боб може или да използва елегантен математически дизайн, или да запази конфиденциалността на срещата си с Алиса — но за съжаление, обикновено не е възможно да се получат и двете. Това ще стане напълно ясно, когато накрая преминем към темата за криптография с отворен ключ.

Крос-протокол/понижаване

В филма „Илюзията на обмана“ (2013) група илюзионисти се опитват да измамят и да отнемат цялото състояние на корумпирания застрахователен магнат Артър Треслър. За да получат достъп до банковата сметка на Артър, илюзионистите трябва или да предоставят неговото потребителско име и парола, или да го накарат лично да се яви в банката и да се включи в схемата.

И двата варианта са много трудни; момчетата са свикнали да изнасят номера, а не да участват в операции на специални служби. Затова те избират третия вариант: техният съучастник се обажда в банката и се представя за Артър. Банкът задава няколко въпроса, за да потвърди самоличността, като име на чичо и име на първото домашно любимец; нашите герои предварително лесно извлекат от Артър тази информация с хитра социална инженерия.От този момент насетне отличната сигурност на паролата вече няма значение.

(Според градската легенда, която ние лично проверихме и потвърдихме, криптографът Ели Бихам веднъж се сблъска с касиер в банка, който настоявал за задаване на секретен въпрос. Когато касиерът попитал името на бабата по майчина линия, Бихам започнал да диктува: „Главна X, малка y, три…“).

Също така и в криптографията, ако за защитата на един и същ актив паралелно се използват два криптографски протоколи, единият от които е значително по-слаб от другия, крайният опит става уязвим за крос-протоколни атаки, при които се атакува по-слабият протокол, за да се достигне до целта, без да се засяга по-силният.

В някои сложни случаи не е достатъчно просто да се свържете със сървъра чрез по-слабия протокол, а е необходимо involuntary участие на легитимен клиент. Това може да бъде организирано чрез т.нар. атака с понижаване (downgrade). За да се разбере тази атака, предположим, че нашите илюзионисти имат по-сложна задача от тази във филма. Да предположим, че между банковия служител (касиера) и Артур възникват непредвидени обстоятелства, в резултат на които се провежда следния диалог:

Хакер: Алло? Аз съм Артур Треслер. Искам да възстановя паролата си.
Касиера: Страхотно. Моля, погледнете в личната си книга с кодове, страница 28, дума 3. Всички следващи съобщения ще бъдат криптирани с това конкретно слово като ключ. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Хакер: Хей-ей, изчакай, изчакай. Това наистина необходимо ли е? Не можем ли просто да говорим като нормални хора?
Касиера: Не го препоръчвам.
Хакер: Аз просто... слушай, имам лош ден, ясно? Аз съм VIP-клиент и не съм в настроение да разглеждам тези глупави кодови книги.
Касиера: Добре. Ако наистина настояваш, мистър Треслер. Какво желаеш?
Хакер: Моля, искам да прехвърля всички свои пари в Националния фонд за жертви на Артур Треслер.
(Паузa).
Касиера: Разбирам. Моля, посочете своя пин-код за големи транзакции.
Хакер: Моят какво?
Касиера: По ваша лична молба транзакции от този размер изискват въвеждане на пин-код за големи транзакции. Този код ви беше предоставен при откритето на сметката.
Хакер:… Загубих го. Наистина ли е необходимо? Не можете ли просто да одобрите сделката?
Касиера: Не. Съжалявам, мистър Треслер. Отново, това е мярка за сигурност, която поискахте. Ако желаете, можем да изпратим нов пин-код на пощенския ви адрес.

Нашите герои отлагат операцията. Те прослушват няколко големи транзакции на Треслър, надявайки се да чуят пин-кода; но всеки път разговорът се превръща в неразбираем шум, преди да се чуе нещо интересно. Накрая, в един прекрасен ден, плана се привежда в действие. Те търпеливо чакат момента, когато Треслър трябва да направи голяма транзакция по телефона, той се свързва с линията и след това…

Треслър: Здравейте. Искам да извърша дистанционна транзакция, моля.
Касиера: Отлично. Моля, погледнете в своята лична книга на секретните кодове, страница…
(Хакерът натиска бутон; гласът на касиера се превръща в неразбираем шум).
Касиера: — #@$#@$#*@$$@#* ще бъде кодирано с това слово като ключ. AAAYRR PLRQRZ MMNJK LOJBAN…
Треслър: Извинявайте, не съвсем разбрах. Отново? На коя страница? Кое е словото?
Касиера: Това е страница @#$@#*$)#*#@()#@$(#@*$(#@*.
Треслър: Какво?
Касиера: Думата номер двайсет @$#@$#%#$.
Треслър: Сериозно! Хайде, стига вече! Твоят протокол за сигурност е някакъв цирк. Знам, че можеш просто да говориш нормално с мен.
Касиера: Не ви съветвам…
Треслър: А аз те съветвам да не ми губиш времето. Не искам да чувам повече за това, докато не оправите проблемите с телефонната си линия. Можем ли да извършим сделката или не?
Касиера:… да. Добре. Какво желаете?
Треслър: Искам да преведа 20 000 долара на компанията Lord Business Investments, номер на сметката…
Касиера: Момент, моля. Това е голяма сделка. Моля, посочете пин-кода си за големи транзакции.
Треслър: Какво? А, точно. 1234.

Ето атака на понижение. По-слабият протокол „просто говорете право“ беше предвиден като опция в краен случай. И все пак сме тук.

Можете да зададете въпроса, кой в здравия си ум би проектирал истинска система от типа „сигурно, докато не поискате обратното“, каквато е описаната по-горе. Но както измисленият банк рискува, за да запази клиентите си, които не обичат криптографията, така и системите като цяло често се накланят към изисквания, които са незаинтересовани или дори открито враждебни към сигурността.

Такава история се случи с протокола SSLv2 през 1995 година. Правителството на САЩ отдавна разглеждаше криптографията като оръжие, което е по-добре да се държи настрана от външни и вътрешни врагове. Парчетата код бяха одобрявани поотделно за износ от САЩ, често при условие за умишлено отслабване на алгоритъма. Компанията Netscape, разработчик на най-популярния браузър Netscape Navigator, получи разрешение за SSLv2 само с първоначално уязвим ключ RSA 512 бита (и 40 бита за RC4).

Към края на хилядолетието правилата бяха облекчени и достъпът до съвременна криптография стана широко достъпен. Въпреки това, клиентите и сървърите в продължение на много години поддържаха отслабена "експортна" криптография поради същата инерция, която поддържаше всяка остаряла система. Клиентите предполагаха, че могат да срещнат сървър, който не поддържа нищо друго. Сървърите правеха същото. Разбира се, протоколът SSL диктува, че клиентите и сървърите никога не трябва да използват слаб протокол, когато е наличен по-добър. Но същата предпоставка важеше и за Тресслера и неговата банка.

Тази теория намери приложение в две шумни атаки, които една след друга разтърсиха сигурността на протокола SSL през 2015 година, и двете открити от изследователи на Microsoft и INRIA. Първоначално през февруари бяха разкрити детайли за атаката FREAK, а три месеца по-късно — още една подобна атака, наречена Logjam, която ще обсъдим по-подробно, когато преминем към атаките върху криптографията с открит ключ.

Уязвимостта FREAK (известна и като "Smack TLS") се прояви, когато изследователите анализираха имплементации на клиент/сървър TLS и откриха любопитна грешка. В тези имплементации, дори ако клиентът не поиска да използва слаба експортна криптография, сървърът пак отговаря с такива ключове — клиентът казва "Добре тогава" и преминава на слаб набор от шифри.

По онова време всички смятаха, че експортната криптография е остаряла и забранена за употреба, затова атаката стана истински шок и засегна много важни домейни, включително сайтовете на Белия дом, данъчната служба на САЩ и НАСА. По-лошо, оказа се, че много уязвими сървъри оптимизирали производителността си, като повторно използвали същите ключове, вместо да създават нови за всяка сесия. Това позволи след понижаване на протокола да се проведе и атака с предварително изчисление: пробиването на един ключ остава сравнително скъпо (100 долара и 12 часа по време на публикуването), но практическата цена на атаката за свързване значително намаля. Достатъчно е веднъж да бъде подбран сървърен ключ – и да бъдат пробити шифрите за всички последващи свързвания от този момент.

И преди да преминем напред, трябва да споменем една напреднала атака…

Атаката на оракула

Мокси Марлинспайк е най-известен като бащата на крос-платформения крипто-месенджър Signal; но лично на нас ни харесва едно от неговите по-малко известни нововъведения – принципа на криптографската обреченост (Cryptographic Doom Principle). Малко перефразирано, можем да кажем следното: „Ако протоколът изпълнява всяка криптографска операция върху съобщение от потенциално вредоносен източник и се държи по различен начин в зависимост от резултата, той е обречен“. Или в по-остра форма: „Не взимай информация от врага за обработка, а ако е наложително, поне не показвай резултата“.

Оставяме настрана препълвания на буфери, инжекции на команди и подобни; те излизат извън рамките на тази дискусия. Нарушаването на „принципа на обреченост“ води до сериозни пробиви в криптографията, тъй като протоколът се държи точно така, както е предвидено.

За пример вземаме измислена конструкция с уязвим шифър за подмяна, а след това ще демонстрираме възможна атака. Въпреки че вече видяхме атака на шифъра за подмяна с помощта на честотен анализ, това не е просто „друг начин да бъдеш пробит същия шифър“. Напротив, атаките на оракула са много по-съвременно изобретение, приложимо в множество ситуации, когато честотният анализ не успява, и ще видим демонстрация на това в следващия раздел. Тук простият шифър е избран единствено, за да направи примера по-разбираем.

И така, Алиса и Боб комуникират с помощта на прост шифър за подмяна, използвайки ключ, който е известен само на тях. Те са много стриктни относно дължината на съобщенията: дължината им е точно 20 символа. Поради това се споразумяха, че ако някой иска да изпрати по-кратко съобщение, то трябва да добави някакъв фиктивен текст в края на съобщението, за да бъде точно 20 символа. След известно обсъждане те решиха, че ще приемат само следните фиктивни текстове: a, bb, ccc, dddd и т.н. Така, фиктивният текст с всяка необходима дължина е известен.

Когато Алиса или Боб получи съобщение, те първо проверяват дали съобщението има правилната дължина (20 символа), а суфиксът е правилният фиктивен текст. Ако не е така, тогава отговарят с подходящо съобщение за грешка. Ако дължината на текста и фиктивният текст са в ред, получателят прочита самото съобщение и изпраща криптиран отговор.

В процеса на атака, злонамерен актьор се представя за Боб и изпраща фалшиви съобщения на Алиса. Съобщенията са чиста глупост - злонамереният актьор няма ключ и следователно не може да подправи смислено съобщение. Но тъй като протоколът нарушава принципа на обреченост, злонамереният актьор все пак може да примами Алиса в капан, така че тя да разкрие информация за ключа, както е показано по-долу.

Хакер: PREWF ZHJKL MMMN. LA
Алиса: Невалиден фиктивен текст.
Хакер: PREWF ZHJKL MMMN. LB
Алиса: Невалиден фиктивен текст.
Хакер: PREWF ZHJKL MMMN. LC
Алиса: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Зломщик няма и представа какво точно каза Алиса, но отбелязва, че символът C трябва да отговаря на a, тъй като Алиса е приела фиктивния текст.

Хакер: REWF ZHJKL MMMN. LAA
Алиса: Невалиден фиктивен текст.
Хакер: REWF ZHJKL MMMN. LBB
Алиса: Невалиден фиктивен текст.
След множество опити…
Хакер: REWF ZHJKL MMMN. LGG
Алиса: Невалиден фиктивен текст.
Хакер: REWF ZHJKL MMMN. LHH
Алиса: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Отново, злонамереният актьор няма и представа какво точно каза Алиса, но отбелязва, че H трябва да съответства на b, тъй като Алиса е приела фиктивния текст.

И така нататък, докато злонамереният актьор не разбере стойността на всеки символ.

На пръв поглед методът наподобява атака, основана на подбран открит текст. В крайна сметка, злонамереният актьор подбира шифровани текстове, а сървърът ги обработва безпрекословно. Основната разлика, която прави тези атаки жизнеспособни в реалния свят, е, че на злонамерения актьор не му е необходим достъп до фактическото разшифроване — достатъчен е отговорът на сървъра, дори такъв безобиден, като „Неправилен фиктивен текст“.

Въпреки че тази конкретна атака е поучителна, не трябва да се зацикляме твърде много на спецификата на схемата „фиктивен текст“, конкретната използвана криптосистема или точната последователност от съобщения, изпратени от злонамерения актьор. Основната идея е как Алис реагира различно в зависимост от характеристиките на открития текст и го прави без проверка дали съответният шифрован текст действително е получен от доверена страна. По този начин Алис позволява на злонамерения актьор да извлече секретна информация от отговорите ѝ.

В този сценарий много неща могат да бъдат променени. Символите, на които реагира Алис, или самата разлика в нейното поведение, или дори използваната криптосистема. Но принципът ще остане същият, а атаката като цяло ще остане жизнеспособна в една или друга форма. Основната реализация на тази атака помогна за откриването на няколко уязвимости в сигурността, които скоро ще разгледаме; но първо е необходимо да усвоим някои теоретични уроци. Как да се използва този измислен „сценарий на Алис“ в атака, която е способна да работи с реален съвременен шифър? Възможно ли е това изобщо, дори в теорията?

През 1998 година швейцарският криптограф Даниел Блайхенбахер отговори положително на този въпрос. Той демонстрира атака на оракул в широко използваната криптосистема с открит ключ RSA, използвайки определена схема за съобщения. В някои реализации на RSA сървърът отговаря с различни съобщения за грешки, в зависимост от това дали откритият текст отговаря на схемата или не; това беше достатъчно, за да се проведе атака.

Четири години по-късно, през 2002 година, френският криптограф Серж Воденэ (Serge Vaudenay) демонстрира атака на оракул, почти идентична на описаната по-горе в сценария на Алиса — с изключение на факта, че вместо измислен шифър той хакна целия респектабелен клас съвременни шифри, които хората наистина използват. В частност, атаката на Воденэ цели шифри с фиксиран размер на входа („блочни шифри“), когато се използват в т.нар. „режим на шифриране CBC“ и с определена популярна схема на запълване, основно еквивалентна на тази в сценария на Алиса.

Също през 2002 година американският криптограф Джон Келси (John Kelsey) — съавтор Twofish — предложи различни атаки на оракул на системи, които компресират съобщения, а след това ги шифрират. Най-забележителната сред тях беше атака, която използваше факта, че често може да се извлече оригиналната дължина на открития текст от дължината на шифрования текст. В теорията това позволява провеждането на атака на оракул, която възстановява части от оригиналния открит текст.

По-нататък даваме по-подробно описание на атаките на Воденэ и Келси (ще предоставим по-подробно описание на атаката на Блайхенбахер, когато преминем към атаките на криптография с обществен ключ). Независимо от всичките ни усилия, текстът става малко технически; затова, ако горепосоченото е достатъчно за вас, пропуснете следващите два раздела.

Атаката на Воденэ

За да разберем атаката на Воденэ, първо трябва да говорим малко по-подробно за блочните шифри и режимите на шифриране. „Блочен шифър“ — както вече беше споменато, е шифър, който приема ключ и вход с определена фиксирана дължина („дължина на блока“) и издава шифрован блок със същата дължина. Блочните шифри се използват широко и се считат за относително безопасни. Вече пенсионираният DES, който е считан за първия модерен шифър, беше блочен. Както беше споменато по-горе, същото важи и за AES, който е широко използван днес.

За съжаление, блочните шифри имат една явно слабост. Типичният размер на блока е 128 бита или 16 символа. Очевидно е, че съвременната криптография изисква работа с входни данни с по-голям размер, и точно тук влизат режимите на шифриране. Режимът на шифриране е по същество хак: това е начин да се приложи блочен шифър, който приема входни данни само с определен размер, към входни данни с произволна дължина.

Атаката Водене е насочена към популярния режим на работа CBC (Cipher Block Chaining, режим на свързване на блокове на шифротекста). Атаката разглежда основния блочен шифър като магически непристъпен черен кутия и напълно заобикаля неговата сигурност.

Ето диаграма, която показва как работи режимът CBC:

Обграденият плюс означава операцията XOR (изключително "ИЛИ"). Например, вторият блок на шифротекста е получен:

чрез извършване на операция XOR на втория блок на открития текст с първия блок на шифротекста.
Шифриране на получения блок с блочния шифър, използвайки ключ.

Тъй като CBC използва толкова интензивно бинарната операция XOR, да се възползваме от момента, за да си припомним някои от нейните свойства:

Идемпотентност:
Коммутативност:
Асоциативност:
Самообратимост:
Побайтовост: байт n от = (байт n от ) (байт n от )

Като правило, тези свойства означават, че ако имаме уравнение, включващо операции XOR и една неизвестна, то може да бъде решено. Например, ако знаем, че с неизвестното и известните и , можем да разчитаме на гореспоменатите свойства, за да решим уравнението за . Прилагането на XOR от двете страни на уравнението с , получаваме . След миг всичко това ще стане много актуално.

Между нашия сценарий на Алиса и атаката Водене има две незначителни различия и едно основно различие. Две незначителни:

В сценария Алиса очаква, че откритите текстове завършват с символи a, bb, ccc и така нататък. В атаката Водене жертвата вместо това очаква, че откритите текстове завършват N пъти байт N (тоест хексадецимал 01 или 02 02, или 03 03 03 и така нататък). Това е чисто козметично различие.
В сценария на Алисата беше лесно да се каже дали тя е приела съобщението на базата на отговора „Неправилен фиктивен текст“. В атаката Воденэ е нужно по-подробно разглеждане и е важна точната имплементация от страна на жертвата; но за по-кратко, нека приемем, че този анализ все още е възможен.

Основната разлика:

Тъй като не използваме една и съща криптосистема, връзката между байтовете на шифрован текст, контролирани от нападателя, и тайните (ключ и открит текст) очевидно ще е различна. Следователно нападателят ще трябва да използва различна стратегия при създаването на шифротекстове и интерпретирането на отговорите на сървера.

Тази основна разлика е последният фрагмент на пъзела, за да разберем атаката Воденэ, така че нека за миг помислим защо и как може да бъде организирана атака на оракул срещу CBC.

Представете си, че имаме шифротекст CBC от 247 блока и искаме да го декриптираме. Можем да изпращаме фалшиви съобщения на сървера, както преди изпращахме фалшиви съобщения на Алисата. Сървърът ще декриптира съобщенията за нас, но няма да показва декриптирания текст — вместо това, отново, както и в случая с Алисата, сървърът ще предостави само един бит информация: дали откритият текст има допустимо запълване или не.

Имайте предвид, че в сценария на Алисата имахме следните отношения:

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

Нека наречем това „уравнението на Алисата“. Ние контролирахме шифротекста; сървърът (Алисата) предоставяше неясна информация относно получения открит текст; и това ни позволи да извлечем информация за последния фактор — ключа. По аналогия, ако можем да намерим такава връзка за сценария CBC, тогава бихме могли да извлечем и там някаква тайна информация.

За щастие, всъщност съществуват отношения, които можем да използваме. Нека разгледаме изхода от крайния призив за декриптиране на блоковия шифър и да означим тези данни като . Нека също означим блоковете на открития текст и блоковете на шифротекста . Погледнете отново диаграмата на CBC и забележете какво получаваме:

Нека наречем това „уравнението на CBC“.

В сценария на Алиса, контролирайки шифротекста и наблюдавайки за изтичането на информация за съответния открит текст, успяхме да организираме атака, която възстанови третия член на уравнението – ключа. В сценария CBC ние също контролираме шифротекста и наблюдаваме изтичания на информация по съответния открит текст. Ако аналогията важи, ще можем да получим информация за .

Да предположим, че наистина сме възстановили , какво тогава? Е, тогава можем веднага да изведем целия последен блок открит текст (), просто въвеждайки (който имаме) и
получения в уравнението CBC.

И така, оптимистично настроени сме относно общия план на атаката и е време да разработим детайлите. Обърнете внимание как точно на сървъра се случва изтичането на информация за открития текст. В сценария на Алиса изтичането е настъпило, защото Алиса отговаряше с правилното съобщение само ако $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ завършеше със строка a (или bb, и така нататък, но вероятността за случайно сработване на тези условия беше много малка). Аналогично за CBC, сървърът приема запълване, ако и само ако завършва с шеснадесетичен 01. И така, да опитаме същия трик: да изпратим фалшиви шифротексти с нашите собствени фалшиви стойности , докато сървърът не приеме запълване.

Когато сървърът приеме запълване за едно от нашите фалшиви съобщения, това означава, че:

Сега използваме свойството на побайтовото XOR:

Ние знаем първия и третия член. И вече видяхме, че това позволява да възстановим оставащия член – последния байт от :

Това също ни дава последния байт на окончателния блок открит текст чрез уравнението CBC и свойството на побайтовото.

Можехме да завършим тук и да се удовлетворим с факта, че проведохме атака на теоретично устойчив шифър. Но наистина можем да направим много повече: можем действително да възстановим целия текст. Това изисква определен трик, който не беше в оригиналния сценарий на Алиса и не попада в задължителните условия на атаката на оракул, но методът все пак си струва да се изучи.

За да го разберем, първо обърнете внимание, че в резултат на извеждането на правилната стойност на последния байт Имаме нова възможност. Сега, при манипулиране на шифрованите текстове, можем да управляваме последния байт на съответстващия открит текст. Отново, това е свързано с уравнението CBC и свойството на байтовото разширение:

Тъй като сега знаем втория член, можем да използваме контрола си върху първия, за да управляваме третия. Просто изчисляваме:

По-рано не можехме да направим това, защото не разполагахме с последния байт. .

Как ще ни помогне това? Да предположим, че сега ще създаваме всички шифрограми така, че в съответстващите открити текстове последният байт да е равен на 02. Сега сървърът приема запълване само ако откритият текст завършва на 02 02. Тъй като коригирахме последния байт, това ще се случи само ако предпоследният байт на открития текст също е равен на 02. Продължаваме да изпращаме подправени блокове на шифрограма, променяйки предпоследния байт, докато сървърът не приеме запълването за един от тях. В този момент получаваме:

И възстановяваме предпоследния байт по същия начин, по който възстановихме последния. Продължаваме в същия дух: коригираме последните два байта на открития текст на 03 03, повтаряме тази атака за третия от края байт и така нататък, в крайна сметка напълно възстановявайки .

Какво ще кажете за останалия текст? Обърнете внимание, че стойността всъщност е $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Можем да поставим всякакъв друг блок вместо , и атаката пак ще бъде успешна. Всъщност, можем да помолим сървъра да направи $inline$text{BLOCK_DECRYPT}$inline$ за всякакви данни. В този момент играта е свършила — можем да дешифрираме всяка шифрограма (погледнете отново схемата за декриптиране на CBC, за да се уверите в това; и обърнете внимание, че IV векторът е публично достъпен).

Този конкретен метод играе решаваща роля в атаката на оракула, с която ще се сблъскаме по-късно.

Атаката на Келси

Джон Келси, който е близък по дух, изложи принципите, лежащи в основата на много възможни атаки, а не само подробните детайли на конкретната атака срещу конкретен шифър. Неговата статия от 2002 година е изследване на възможните атаки срещу криптиране на компресирани данни. Мислехте ли, че за извършване на атака е недостатъчно само информацията, че данните са били компресирани преди криптиране? Оказва се, че е достатъчно.

Този удивителен резултат е обусловен от два принципа. Първо, съществува силна корелация между дължината на отворения текст и дължината на шифротекста; за много шифри те са точно равни. Второ, когато се извършва компресия, също така съществува силна корелация между дължината на компресираното съобщение и степента на "шумност" на отворения текст, т.е. делът на неповтарящите се символи (технически термин - "висока ентропия").

За да видим принципа в действие, нека разгледаме два отворени текста:

Отворен текст 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Отворен текст 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Предположим, че и двата отворени текста са компресирани и след това шифровани. Получавате два резултиращи шифротекста и трябва да познаете кой шифротекст съответства на кой отворен текст:

Шифротекст 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA
Шифротекст 2: DWKJZXYU

Отговорът е очевиден. От между отворените текстове само отворен текст 1 можеше да бъде компресиран до оскъдната дължина на втория шифротекст. Разкрихме това, без да знаем нищо за алгоритма за компресия, ключа за шифроване или дори самия шифър. В сравнение с йерархията на възможните криптографски атаки, това е нещо като безумие.

Келси по-нататък посочва, че при определени необичайни обстоятелства този принцип може да бъде използван и за атака на оракула. По-специално, той описва как злонамерен потребител може да възстанови тайния отворен текст, ако може да накара сървъра да шифрова данни от формуляр (отворен текст, следван от , докато той контролира и може по някакъв начин да проверява дължината на шифрования резултат.

Отново, както в другите атаки на оракула, имаме съотношение:

Отново, ние контролираме един член (), виждаме малко изтичане на информация за друг член (шифротекст) и се опитваме да възстановим последния (отворен текст). Въпреки аналогията, това е малко необичайна ситуация в сравнение с другите атаки на оракула, които сме виждали.

За да илюстрираме как такава атака може да работи, ще използваме измислена схема за компресия, която току-що измислихме: TOYZIP. Тя търси текстови редове, които вече са се появявали по-рано в текста, и ги заменя с три байта-запълвачи, които посочват къде да се намери по-ранен екземпляр на реда и колко пъти се среща там. Например, редът helloworldhello може да бъде компресирана в helloworld[00][00][05] дължина 13 байта в сравнение с оригиналните 15 байта.

Да предположим, че хакерът се опитва да възстанови открития текст на формата password=..., където самата парола е неизвестна. В съответствие с атакуващата модел на Келси, хакерът може да поиска от сървъра да компресира, а след това да криптира съобщенията на формата (открит текст, следван от ), където — произволен текст. Когато сървърът приключи работа, той съобщава дължината на резултата. Атаката протича по следния начин:

Хакер: Моля, компресирайте и криптирайте открития текст без никакви запълващи данни.
Сървър: Дължина на резултата 14.
Хакер: Моля, компресирайте и криптирайте открития текст, към който е добавено password=a.
Сървър: Дължина на резултата 18.

Хакерът отбелязва: [оригинал 14] + [три байта, които заменят password=] + a

Хакер: Моля, компресирайте и криптирайте открития текст, към който е добавено password=b.
Сървър: Дължина на резултата 18.
Хакер: Моля, компресирайте и криптирайте открития текст, към който е добавено password=с.
Сървър: Дължина на резултата 17.

Хакерът отбелязва: [оригинал 14] + [три байта, които заменят password=c]. Това предполага, че оригиналният открит текст съдържа низ password=c. Тоест паролата започва с буква с

Хакер: Моля, компресирайте и криптирайте открития текст, към който е добавено password=сa.
Сървър: Дължина на резултата 18.

Хакерът отбелязва: [оригинал 14] + [три байта, които заменят password=с] + a

Хакер: Моля, компресирайте и криптирайте открития текст, към който е добавено password=сb.
Сървър: Дължина на резултата 18.

(… след известно време…)

Хакер: Моля, компресирайте и криптирайте открития текст, към който е добавено password=со.
Сървър: Дължина на резултата 17.

Хакерът отбелязва: [оригинал 14] + [три байта, които заменят password=co]. По същата логика хакерът прави извод, че паролата започва с буквите co

И така нататък, докато не бъде възстановена цялата парола.

На читателя може да изглежда, че това е чисто академично упражнение и такъв сценарий на атака никога няма да възникне в реалния свят. За съжаление, както скоро ще видим, в криптографията е по-добре да не се правят предположения.

Брендови уязвимости: CRIME, POODLE, DROWN

Накрая, след подробен преглед на теорията, можем да видим как тези методи се прилагат в реални криптографски атаки.

CRIME

Ако атаката е насочена към браузъра и мрежата на жертвата, нещата ще бъдат по-лесни за някои, а по-сложни за други. Например, лесно е да се види трафика на жертвата: достатъчно е да седиш с нея в едно и също кафе с WiFi. Поради тази причина на потенциалните жертви (т.е. на всички) обикновено се препоръчва да използват криптирано съединение. Ще бъде по-предизвикателно, но пак е възможно, да се правят HTTP запитвания от името на жертвата към някой външен сайт (например, Google). Злонамереният трябва да подмами жертвата на зловредна уеб-страница със скрипт, който ще направи запитването. Уеб браузърът автоматично ще предостави съответната сеансна бисквитка.

Това изглежда удивително. Ако Боб посети evil.com, дали ли скриптът на този сайт възможност на Google да изпрати паролата на Боб по електронната поща на attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Cross-Site Request Forgery, CSRF), който беше популярен около средата на 90-те години. Днес, ако evil.com предприеме такъв трик, Google (или всеки реномиран сайт) обикновено отговаря: «Страхотно, но вашият CSRF токен за тази транзакция ще бъде... ммм... три трилиона и седем. Моля, повторете това число». Съвременните браузъри прилагат нещо, наречено «политика за единно произход» (same-origin policy), според която скриптове на сайт А нямат достъп до информация, изпратена от уебсайт Б. Следователно, скрипт на evil.com може да изпраща заявки към google.com, но не може да чете отговорите или всъщност да завърши транзакцията.

Трябва да подчертаем, че ако Боб не използва криптирано съединение, всички тези защити са безсмислени. Хакерът просто може да прочете трафика на Боб и да възстанови сесийната бисквитка на Google. С тази бисквитка той просто ще отвори нов таб в Google, без да излиза от собствения си браузър, и ще се представи за Боб, без да се натъква на досадните политики за единно произход. Но за съжаление на хакера, това се случва все по-рядко. Интернетът отдавна е обявил война на некриптираните съединения и изходящият трафик на Боб вероятно е криптиран, независимо дали му харесва или не. Освен това, още от самото начало на внедряването на протокола трафикът също е сжат преди криптиране; това беше обичайна практика за намаляване на закъснението.

Тук навлиза в играта CRIME (Compression Ratio Infoleak Made Easy, лесно изтичане чрез коефициента на компресия). Уязвимост, която бе демонстрирана през септември 2012 година от изследователите по сигурността Джулиано Риццо и Тай Дуонг. Вече разгледахме цялата теоретична основа, която позволява да разберем какво са направили и как. Хакерът може да накара браузъра на Боб да изпраща заявки до Google и след това да подслушва отговорите в локалната мрежа в компресиран, криптиран вид. Следователно, имаме:

Тук хакерът контролира заявката и има достъп до трафик анализатор, включително размера на пакетите. Фиктивният сценарий на Келси оживя.

Разбирайки теорията, авторите на CRIME създадоха експлойт, който може да открадне сесийни бисквитки за широк спектър от сайтове, включително Gmail, Twitter, Dropbox и Github. Уязвимостта засегна повечето съвременни уеб браузъри, в резултат на което бяха пуснати пачове, които безшумно погребаха функцията за компресия в SSL, за да не се използва изобщо. Единственият защитен от уязвимостта стана почтеният Internet Explorer, който никога не е използвал компресия SSL.

POODLE

През октомври 2014 г. екипът по сигурността на Google разтърси общността на сигурността. Те успяха да експлоатират уязвимост в протокола SSL, поправен преди повече от десет години.

Оказа се, че въпреки че на сървърите работи новият TLSv1.2, много от тях оставиха поддръжка на остарялото SSLv3 заради обратно съвместимост с Internet Explorer 6. Вече говорихме за понижаващи атаки, така че можете да си представите какво се случва. Добре организиран саботаж на протокола за хендшейтинг — и сървърите са готови да се върнат на стария добър SSLv3, по същество отменяйки последните 15 години изследвания в областта на сигурността.

За исторически контекст, ето кратко резюме на историята на SSL до версия 2 от Матю Грийн:

Transport Layer Security (TLS) е най-важният протокол за сигурност в интернет. [..] почти всяка трансакция, която извършвате в интернет, зависи от TLS. [..] Но TLS не винаги е бил TLS. Протоколът започна живота си в Netscape Communications с името "Secure Sockets Layer" или SSL. Говори се, че първата версия на SSL беше толкова ужасна, че разработчиците събрали всички разпечатки на кода и ги закопали на тайно сметище в Ню Мексико. В резултат, първата обществено достъпна версия на SSL всъщност е версия SSL 2. Тя е доста страшничка, и [..] това беше продукт от средата на 90-те, който съвременните криптографи разглеждат като "тъмните векове на криптографията". Много от най-ужасните криптографски атаки, за които знаем днес, все още не са били открити. В резултат на това разработчиците на протокола SSLv2 трябваше всъщност да навигират в тъмнината и те се сблъскаха с множество страшни чудовища --- към тяхно разочарование и наша полза, тъй като атаките на SSLv2 оставиха безценни уроци за следващото поколение протоколи.

След тези събития, през 1996 година, разочарованата компания Netscape преработи протокола SSL от нулата. Резултатът беше SSL версия 3, който отстрани няколко известни проблеми със сигурността на своя предшественик.

За щастие на хакерите, „няколко“ не означава „всички“. В общи линии, SSLv3 предоставяше всички необходими строителни блокове за стартиране на атаката Воденэ. Протоколът използваше блочен шифър в режим CBC и несигурна схема за запълване (която беше коригирана в TLS; следователно възникна необходимостта от атака с понижаване). Ако помните схемата за запълване в нашето първоначално описание на атаката Воденэ, схемата на SSLv3 е много подобна.

Но, за съжаление на хакерите, „подобна“ не означава „идентична“. Схемата за запълване на SSLv3 изглежда така: „N произволни байта, последвани от число N“. Опитайте се в такива обстоятелства да изберете въображаем блок от шифрован текст и преминете през всички етапи на оригиналната схема Воденэ: ще откриете, че атаката успешно извлича последния байт от съответния блок с ясен текст, но не продължава нататък. Разшифроването на всеки 16-ти байт от шифрования текст е страхотен трик, но това не е победа.

Изправени пред неуспех, екипът на Google прибегна до крайното решение: преместиха се на по-силна модел на заплаха — онзи, който се използва в CRIME. Ако предположим, че злоумышленикът е скрипт, стартиран на таба на браузъра на жертвата, и той може да извлече сесийни бисквитки, атаката все пак остава впечатляваща. Въпреки че по-широкият модел на заплаха е по-малко реалистичен, вече видяхме, че този конкретен модел е осъществим.

С оглед на по-мощните възможности на хакера, атаката може да продължи. Имайте предвид, че нападателят знае къде в заглавката се показва криптирания сесионен файл за бисквитки и управлява дължината на предходната HTTP заявка. Следователно, той може да манипулира HTTP заявката, така че да подравни последния байт на бисквитката с края на блока. Сега този байт е подходящ за декриптиране. Можете просто да добавите един символ към заявката, докато предпоследният байт на бисквитката остава на същото място и е подходящ за опити по същия метод. Атаката продължава по този начин, докато файлът с бисквитки не бъде напълно възстановен. Това се нарича POODLE: Padding Oracle on Downgraded Legacy Encryption, Oracle за запълване на пониженостаромодерно криптиране.

DROWN

Както вече споменахме, SSLv3 имаше недостатъци, но той се различаваше коренно от предшественика си, тъй като пробиващият SSLv2 беше продукт на друга епоха. Там можеше да бъде прекъснато съобщение в средата: съгласявам се на това само през моя труп превръщаше се в съгласявам се на това; клиент и сървър можеха да се срещнат в интернет, да установят доверие и да обменят тайни пред погледа на нападателя, който след това лесно се представяше за единия или другия. Имаше също и проблема с експортната криптография, който споменахме при разглеждането на FREAK. Това беше криптографски Содом и Гомор.

През март 2016 г. екип от изследователи от различни технически области се събра и направи поразително откритие: SSLv2 все още се използва в системите за сигурност. Да, нападателите вече не можеха да понижават съвременните сесии TLS до SSLv2, тъй като тази дупка беше затворена след FREAK и POODLE, но те все още могат да се свързват със сървърите и да инициират сесии SSLv2 самостоятелно.

Ще попитате какво ни засяга какво правят там? Те имат уязвима сесия, но това не трябва да влияе на другите сесии или на сигурността на сървъра - нали? Е, не съвсем. Да, така би трябвало да бъде в теорията. Но не - защото генерирането на SSL сертификати налага определено бреме, в резултат на което много сървъри използват едни и същи сертификати и следователно едни и същи RSA ключове за TLS и SSLv2 връзки. Още по-лошо, поради бъг в OpenSSL в тази популярна реализация на SSL опцията „Деактивиране на SSLv2“ всъщност не работеше.

Това направи възможна атака през протоколите на TLS, известна като DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, разшифроване на RSA с остаряла и отслабена криптиране). Нека напомним, че това не е същото като атака за понижаване; хакерът не трябва да действа като „човек в средата“ и не трябва да включва клиента в небезопасна сесия. Злоумишлениците просто сами инициират небезпечна SSLv2 сесия със сървъра, атакуват слабия протокол и възстановяват защитения сървърен RSA ключ. Този ключ е валиден и за TLS връзки, и от този момент нататък никаква TLS сигурност не ще го спаси от компрометиране.

Но за хакване е необходима работеща атака срещу SSLv2, която позволява да се възстанови не само конкретният трафик, но и тайният сървърен RSA ключ. Въпреки че това е сложна задача, изследователите можеха да изберат всяка уязвимост, която беше напълно закрита след SSLv2. В крайна сметка откриха подходящ вариант: атаката на Блайхенбахер, за която споменахме преди и която ще обясним подробно в следващата статия. SSL и TLS са защитени от тази атака, но някои случайни функции на SSL в комбинация с кратки ключове в криптографията на експортен клас, направиха възможно определена реализация на DROWN..

Към момента на публикуването уязвимостите DROWN засягаха 25% от топ сайтовете в интернет, а атаката можеше да се осъществи с доста скромни ресурси, налични дори за закачливи хакери-единици. За извличане на сървърния RSA ключ бяха необходими осем часа изчисления и $440, а SSLv2 промени статуса си от „остарял“ на „радиоактивен“.

Изчакайте, а какво ще кажете за Heartbleed?

Това не е криптографска атака в смисъла, описан по-горе; това е преливане на буфер.

Нека направим пауза.

Започнахме с някои основни методи: брутфорс, интерполация, понижаване, крос-протокол и предварителни изчисления. След това разгледахме една напреднала техника, възможно най-важният компонент на съвременните криптографски атаки: атака на оракула. Прекарахме доста време с нея и разбрахме не само принципа зад нея, но и техническите детайли на две конкретни реализации: атаката на Воден и режима на шифроване CBC и атаката на Келси върху протоколите за шифроване с предварително компресиране.

При прегледа на атаките на понижаване и с предварителни изчисления накратко изложихме атаката FREAK, която използва и двата метода, тъй като целевите сайтове преминават към слаби ключове и след това отново използват същите ключове. За следващата статия оставихме (много подобна) атака Logjam, която е насочена към алгоритмите с публичен ключ.

След това разгледахме още три примера за приложение на тези принципи. На първо място, CRIME и POODLE: две атаки, които разчитат на способността на хакера да внедрява произволен открит текст до целевия открит текст, след което да изучава отговорите на сървъра и след това, използвайки методологията на атаката на оракула, да използва тази оскъдна информация за частично възстановяване на открития текст. CRIME последва атака на Келси върху компресията на SSL, докато POODLE вместо това използваше вариант на атаката на Воден върху CBC с идентичен ефект.

След това обърнахме внимание на крос-протоколната атака DROWN, която установява връзка с сървъра чрез остарял протокол SSLv2, а след това възстановява секретните серверни ключове с атаката на Блайхенбахер. В този момент пропуснахме техническите детайли на тази атака; подобно на Logjam, тя ще трябва да изчака, докато не изучим задълбочено криптосистемите с публичен ключ и техните уязвимости.

В следващата статия ще обсъдим напреднали атаки — като метода на срещата по средата (meet-in-the-middle), диференциалния криптоанализ и атаката с "рождените дни". Ще направим кратък дунав на атаките по странични канали, а след това ще се захванем с най-вкусното — криптосистемите с публичен ключ.

Източник: habr.com