(Впервые опубликовано – декабрь 2007)
В теории хорошо известно, как делать сильные шифры. Однако в жизни криптография обычно оказывается слабой. Как это происходит.
Что такое «уязвимость»
Группой израильских криптографов из университетов Иерусалима и Хайфы (Benny Pinkas, Zvi Gutterman, Leo Dorrendorf), недавно была вскрыта схема работы генератора псевдослучайных чисел, используемого Microsoft во всех криптоприложениях операционной системы Windows 2000 [eprint.iacr.org/2007/419].
Знание работы этого алгоритма позволило исследователям проанализировать общую стойкость подсистемы защиты и выявить в ней серьезнейшую уязвимость.
В частности, было показано, что из-за слабой схемы генератора злоумышленники могут без проблем, всего по одному внутреннему состоянию алгоритма, предсказывать большое количество криптоключей, вырабатываемых в ОС. Причем не только ключей для будущих потребностей, но и уже сгенерированных в прошлом.
Система Windows 2000 по сию пору используется многими компаниями и организациями, оставаясь, согласно общим оценкам, второй по популярности ОС Microsoft после XP. Но когда разнеслась весть о слабостях в PRNG (от pseudo-random number generator), то всех, естественно, взволновал вопрос об уязвимости крипто в более новых системах, XP и Vista. А именно, можно ли и их атаковать аналогичным образом?
Первая реакция Microsoft на подобные вопросы была довольно уклончивой и сводилась к заверениям публики в том, что последние версии Windows «содержат разнообразные изменения и доработки в схеме генератора случайных чисел».
Но коль скоро уже вскрытую схему выявить в системе гораздо легче, чем неизвестную, в Microsoft все же решились сказать правду и чуть позже признали, что Windows XP тоже уязвима для атаки, описанной в работе Пинкаса, Гуттермана и Доррендорфа.
Что же касается систем Windows Vista, Windows Server 2003 SP2 и планируемой к скорому выпуску Windows Server 2008, то там, по свидетельству Microsoft, схема генерации псевдослучайных чисел работает иначе и поэтому обладает иммунитетом к подобному методу взлома.
Попутно тут же была предпринята попытка интерпретировать работу израильтян не как выявление серьезной и реальной угрозы для безопасности XP (о старой Win2000 речи вообще не идет), а как сугубо «теоретическую атаку». Ибо, по официальному мнению Microsoft, выявленный «баг» не отвечает определению «уязвимость», поскольку для эксплуатации слабостей в PRNG злоумышленник должен обладать правами администратора.
Или, цитируя дословно, «поскольку администраторы по определению имеют доступ ко всем файлам и ресурсам системы, это [восстановление внутреннего состояния PRNG и вычисление ключей] не является недопустимым раскрытием информации».
То, что множество уже известных вредоносных программ, вроде всяких червей и троянцев, умеет повышать свои привилегии до уровня администратора, здесь, очевидно, считается не относящимся к делу.
Однако, дабы публика не слишком уж волновалась, Microsoft пообещала залатать-таки выявленную проблему в PRNG – где-нибудь в первой половине следующего года, вместе с выходом третьего сервис-пака, Windows XP SP3.
Иначе говоря, проблему хотят представить как нечто маловажное и не особо серьезное. Однако реальная проблема тут, строго говоря, заключается в ином.
Дело в том, что базовые принципы, на основе которых должен работать криптографически качественный PRNG, прекрасно известны. Грамотному разработчику, можно сказать, проще выбрать известный хороший криптоалгоритм, нежели разрабатывать собственный плохой.
Однако в программных продуктах Microsoft криптография всегда оказывается существенно слабее, чем могла бы быть. И вовсе не секрет, почему так происходит. Увидеть это совсем несложно, если взглянуть на историю вопроса в ретроспективе.
Чему учит история
Строго говоря, общедоступных официальных (или неофициальных) документов с хронологией развития и внятным рассказом о средствах защиты информации в программах MS не существует. По вполне очевидной причине общей закрытости кодов Windows-платформы.
Имеются, правда, заслуживающие доверия источники, вроде книги «Написание безопасных кодов» [Michael Howard and David LeBlanc. «Writing Secure Code». Microsoft Press, 2002], подготовленной специалистами корпорации и выпущенной издательством Microsoft Press. Но содержательные моменты в устройстве используемых криптоалгоритмов излагаются там лишь в самых общих чертах и без углубления в принципиально важные конструктивные подробности.
С другой стороны, учитывая грандиозные масштабы распространения программ Microsoft в мире, имеется также масса достоверной, хотя и обрывочной информации о взломе подсистем защиты в условиях Windows для всех периодов развития этой платформы. Сопоставляя эти сведения с информацией из упомянутой книжки, а также принимая во внимание общеполитические процессы, на фоне которых происходило развитие, можно вкратце восстановить картину примерно в таком виде.
Согласно авторам упомянутой книжки, Майку Ховарду и Дэвиду Лебланку, генератор псевдослучайных чисел, вызываемый функцией CryptGenRandom, впервые появился в ОС Windows 95, т.е. в середине 1990-х годов. С той поры его стали включать во все базовые версии операционных систем Microsoft и их вариации.
По свидетельству тех же авторов, конструкция алгоритма PRNG оставалась неизменной вплоть до Windows XP. При вскрытии схемы генератора в Win2000 израильтяне, правда, установили, что это не совсем так – некоторые модификации были, причем далеко не в лучшую сторону.
Но в любом случае трудно не поражаться, что алгоритм Windows PRNG – несомненно, самого распространенного в мире криптогенератора – оставался не вскрытым и никем не проанализированным на протяжении полутора без малого десятка лет.
Объяснить этот факт проще всего тем, что защиту в Windows удавалось вскрывать все эти годы и без знания работы генератора. Нагляднее всего, наверное, данное утверждение иллюстрируется на примере пакета MS Office. Историческая шкала эволюции которого плотно привязана к версиям ОС Windows, а потому и криптография примерно та же самая.
В процессе данной эволюции криптосредства для защиты информации претерпевали здесь, бесспорно, весьма серьезные усовершенствования. Однако на словах и безопасность, и этапы ее усиления всякий раз выглядели существенно иначе, нежели на деле.
В самом первом продукте, MS Office 95, скажем, уже имелись возможности шифрования документов. Но реально это шифрование сводилось к циклическому сложению (побитовой операцией XOR) пароля пользователя с текстом документа.
То есть с точки зрения криптоанализа и вскрытия никакой реальной защиты в действительности не обеспечивалось, а создавалась лишь ее видимость – превращение читаемого текста в нечитаемый.
Применение шифров из детского арсенала бойскаутов в тот период, когда миру уже была прекрасно известна программа PGP – символ общедоступного и очень сильного крипто – это, конечно, не злой умысел (или невежество) со стороны Microsoft.
Просто все предыдущие годы и десятилетия стойкие криптосредства подразумевались американскими законами столь же опасным военным товаром, как наступательные виды оружия, а значит – подлежащими строжайшим экспортным ограничениям на торговлю…
В течение 1990-х годов, впрочем, эти драконовские законы были существенно ослаблены. Вместе с их изменением заметно менялась и стойкость криптографии в версиях Windows / MS Office.
В частности, в последующих версиях программ начали применять вполне качественный поточный шифр RC4. В ранних экспортных версиях ПО, правда, длина ключа ограничивалась всего лишь 40 битами. При такой длине ключа, как известно, шифры без проблем вскрываются на ПК просто лобовым (тотальным) перебором всех возможных ключевых комбинаций.
Но затем, вместе с коррективами в экспортных законах, к концу 1990-х уже всем пользователям новых версий Microsoft Office в принципе стали доступны теоретически стойкие шифрсредства, в частности, RC4 с длиной ключа 128 бит. Вот только на практике предположительно сильный шифр оказался реализован так, что надежной защиты данных с его помощью все равно не получалось.
Среди фундаментальных основ криптографии имеется очень важное правило: если для засекречивания используется поточный шифр (наложение на открытый текст постоянно изменяющейся шифрпоследовательности), то никогда одну и ту же шифрпоследовательность не накладывают на два разных документа.
Причем в данном контексте к принципиально «разным» документам могут приводить любые модификации файла, включая вставку или изъятие единственного знака. Если же это сделано, то всего по двум (если больше, то вскрытие еще проще) одноключевым документам шифрование можно развалить и прочитать оба текста – причем собственно ключ и его длина тут никакой роли не играют.
В годы Второй мировой войны, скажем, английские криптоаналитики из-за такого рода ошибок германских шифровальщиков смогли не только читать важную переписку командования Вермахта, но и полностью вскрыть криптосхему применявшегося шифратора «Шлюссельцузатц». Что затем, с помощью «суперкомпьютера» Colossus, позволило им вскрывать ключи и читать всю переписку уже без одноключевых комплектов (подробности этой истории см. тут ).
В программных же продуктах Microsoft шифр RC4 изначально был реализован таким образом, чтобы одноключевые комплекты порождались ВСЕГДА. Ключ без затей генерировался на основе пароля доступа к документу, поэтому разные версии документа оказывались зашифрованы одним и тем же ключом.
Как известно, разные версии одних и тех же файлов присутствуют в системе очень часто – в резервных кэшах, как архивные копии, как совместно подготавливаемые документы и так далее.
Для этих и любых других накладок в криптографии широко известен элементарнейший способ недопущения одноключевых комплектов – подмешивание в ключ наряду с паролем уникального, одноразового «вектора инициализации» (IV), который не является секретом, но всякий раз делает шифрпоследовательность иной.
То, что в Microsoft почему-то уклоняются от использования в поточном шифре IV, впервые стало известно в 1999 году еще для ОС Windows NT – когда хакеры обнаружили слабости в системе защиты криптоключей Syskey.
Серьезные недочеты в реализации криптографии допускаются регулярно и почти всеми разработчиками (см. врезку о WEP), однако в Microsoft не только проигнорировали тревожные сигналы, но и бережно перенесли ту же самую слабость в последующие версии системы.
В частности, в 2005 году, когда уже вышли Windows XP и MS Office 2003, стало известно [eprint.iacr.org/2005/007], что все та же по сути уязвимость – отсутствие IV и систематическое порождение одноключевых комплектов – выявлена в документах, подготовленных и зашифрованных программами Microsoft Word и Excel с помощью RC4.
В принципе, в качестве вектора инициализации можно использовать самую разную информацию – хоть системный штамп о текущих дате-времени. Но с точки зрения криптографии наиболее грамотное решение – вырабатывать IV с помощью генератора псевдослучайных чисел.
И если на протяжении многих лет имевшийся в системе PRNG явно игнорировался с очевидным ущербом для безопасности, то крайне сложно поверить, будто сделано это неумышленно.
Впрочем, и в тех ситуациях, когда PRNG используется для генерации секретных ключей или других криптопоследовательностей, делается это весьма небезопасным образом.
Слабость спереди и сзади
Качественный с точки зрения криптографии генератор псевдослучайных чисел должен отвечать трем главным требованиям: (1) выдавать последовательность, статистически неотличимую от случайной равновероятной; (2) противостоять восстановлению прошлых состояний по известному; (3) противостоять восстановлению будущих состояний по текущему состоянию алгоритма.
Нет никакого секрета в том, каким образом можно эффективно достигать все три нужных качества. Из этого, правда, не следует, что конструировать хорошие генераторы легко (см. врезку). Но если PRNG просто генерирует последовательность чисел, похожую на случайную, но явно не отвечает требованиям (2) и (3), то с точки зрения криптографии это слабый и небезопасный генератор.
Именно такой, увы, является схема алгоритма PRNG, использованного во всех версиях Windows вплоть до XP и ныне вскрытого коллективом израильских криптоаналитиков в работе, упомянутой в самом начале.
Этот генератор также построен на основе RC4. И коль скоро всякий приличный поточный шифр дает на выходе последовательность чисел, статистически неотличимую от равновероятной, то и генератор на его основе вполне отвечает требованию (1). Но вот дальше начинаются очень неприятные моменты конкретной реализации PRNG.
Чтобы обеспечить свойство (2) – не допустить восстановление прошлых состояний – в качестве тактов генерации принято использовать однонаправленные (хэш-)функции, легко вычисляемые только в одну сторону. В Windows же обратная функция вычисляется столь же просто, как и прямая генерация следующего состояния.
Такая же унылая картина установлена и для свойства (3). Дабы воспрепятствовать восстановлению будущих состояний криптогенератора, в его детерминированные алгоритмом состояния регулярно вводят так называемую рандомизацию – то есть обновляют случайно взятой последовательностью бит от какого-нибудь внешнего источника. Чем короче длина последовательности, генерируемой на выходе PRNG между такими «перезагрузками», тем выше криптостойкость генератора.
Хотя общая схема PRNG в Windows не менялась, в ранних версиях OC длина между перезагрузками состояний составляла 512 байт, а в Win2000 – как установили израильтяне – она стала уже 16 килобайт. Если же учесть, что PRNG здесь реализован на основе 8 потоков от работающих в параллели шифров RC4, то получается, что реально длина генерируемой криптопоследовательности между перезагрузками состояний составляет 128 килобайт.
Иначе говоря, определив всего одно внутреннее состояние генератора (например, с помощью известного трюка с переполнением буфера памяти), злоумышленник далее может сам вычислить огромное количество ключей – как уже использованных в криптоприложениях прежде, так и на будущее.
Хуже того, перезагрузка состояний произойдет лишь в том случае, когда все эти 128 килобайт сгенерированы между включением и выключением компьютера. В терминах защищенных SSL-соединений веб-браузера это, огрубленно, означает от 600 до 1200 сеансов шифрованной связи.
Понятно, что для всякого обычного компьютера это нереально огромное число. Иными словами, в большинстве случаев криптогенератор вообще никогда не перезагружает свои состояния, так что всего одной «израильской атакой» можно восстановить по сути ВСЕ генерируемые им ключи – как вперед, так и назад.
В терминах корпорации Microsoft, напомним, этот мелкий недочет в конструкции не тянет даже на то, чтобы именоваться «уязвимостью». В терминах же криптографии это называется катастрофическое снижение стойкости, которое просто не могло появиться случайно.
Ситуация с ОС Vista
В новой системе Windows Vista, как многократно подчеркивалось разработчиком по самым разным поводам, защита информации реализована существенно иначе и на основе других алгоритмов.
Отчасти это сделано в угоду всемогущей индустрии контента – для надежной защиты файлов от бесконтрольного копирования пользователями. В другой же, не менее важной части – чтобы обеспечить интересы Агентства национальной безопасности США.
Тесное сотрудничество Microsoft с АНБ при разработке Vista является официально известным фактом [подробнее см. БОЛЬШАЯ ЖрАТВА], однако как именно интересы этой крупнейшей в мире разведслужбы были здесь учтены, в объявлении скромно умолчали. Хотя секрет этот относится к тому типу, что, как говорится, известен всем.
АНБ всегда – и в период холодной войны, и в 1990-е годы смягчения экспортных ограничений, и, тем более, в последующие годы войны с терроризмом – очень ревниво боролось с сильной криптографией на рынке. Понижая ее стойкость в продуктах разработчиков любыми способами. От кнутов-санкций для строптивых до технических хитростей-закладок и пряников-контрактов с правительственными ведомствами для лояльных.
Корпорация масштабов Microsoft нелояльной к правительству США быть просто не может по определению. Так что очевидно слабая криптография в ее продуктах – это своего рода дань уважения государству, которое считает себя просто обязанным все про всех знать.
В условиях же ОС Vista, где сильная криптография ныне с необходимостью должна присутствовать из-за требований партнеров по индустрии и пользователей из большого бизнеса, разведывательные интересы АНБ пришлось учесть, вероятно, более элегантным способом, нежели «неумелая» и слабая реализация известных криптосхем.
Иначе говоря, в условиях беспощадной войны с мировым терроризмом на массовый рынок общедоступных коммерческих программ просто в принципе не мог бы попасть американский продукт с непробиваемой криптографией.
«Черный ход» для себя, по крайней мере, АНБ наверняка там имеет. Ну а уж найдут ли его независимые исследователи – это другой вопрос.
Решаемый, как показывает опыт, иногда довольно долго.
The End
[ВРЕЗКА]
WEP или слабый эквивалент приватности
Стандарт криптозащиты WEP, введенный для беспроводных сетей WiFi, иногда неверно расшифровывают как Wireless Encryption Protocol или «Протокол беспроводного шифрования».
На самом деле буквы названия означают Wired Equivalent Privacy, т.е. «Приватность, эквивалентная проводным сетям». Уже само имя дает основание предполагать, что защита, обеспечиваемая таким шифрованием, вряд ли обладает высокой стойкостью к атакам.
На первый взгляд, впрочем, все выглядело весьма пристойно. Хорошо исследованный и вполне качественный шифр RC4, своевременно увеличенная с 64 до 128 бит длина ключа – все эти базовые характеристики позволяли сделать добротную и достаточно надежную схему защиты.
Однако в конкретной реализации RC4 для WEP, особенно в алгоритме разворачивания ключа, аналитики вскоре нашли серьезные слабости, ощутимо понижающие стойкость системы. Начиная с 2001 года эффективность атак на WEP и скорость вскрытия ключей понемногу довели с нескольких часов до нескольких минут.
Апофеозом же этой работы можно считать наглядную демонстрацию в апреле 2007 года, когда трое исследователей из германского университета Дармштадта на одной из конференций по инфобезопасности вскрывали ключи «защищенной» с помощью WEP сети менее чем за 3 секунды. То есть по сути дела моментально.
И хотя с 2003 года для защиты беспроводных сетей разработаны и применяются существенно более стойкие протоколы WPA и WPA2, изготовителями сетевого оборудования стандарт WEP по-прежнему ставится первым в списках возможных опций для средств безопасности.
Вследствие этого, как показали исследования, проводившиеся в текущем году в Германии, около половины всех WiFi-сетей используют для защиты откровенно слабый WEP, и лишь чуть больше четверти – WPA. Остальные, правда, не применяют никакой защиты вообще.
[КОНЕЦ ВРЕЗКИ]
[ВРЕЗКА]
Криптогенератор – это непросто
Из того, что критерии, предъявляемые к качественному криптографическому генератору случайных чисел, хорошо известны, вовсе не следует, что сконструировать его проще простого. В истории криптографии имеется достаточно много случаев, когда слабости находили и в новых схемах известных авторов, и в уже известных алгоритмах, успевших получить распространение.
Например, в 1996 году одна из ранних версий протокола SSL была взломана именно из-за слабостей в генераторе случайных чисел. Совсем недавно были обнаружены криптографические слабости в PRNG операционных систем Linux и FreeBSD, всегда открытых для анализа.
По этой причине многие разработчики средств защиты весьма благосклонно восприняли инициативу НИСТ, американского Института стандартов и технологий, подготовившего и опубликовавшего недавно большой, на 130 страниц документ под названием NIST Special Publication 800-90, целиком посвященный генераторам псевдослучайных чисел. В этом документе, где они именуются DRBG или Deterministic Random Bit Generators, содержатся описания 4 изученных и рекомендуемых к применению генераторов разных конструкций.
Все четыре схемы построены на основе уже существующих криптографических примитивов, что принято считать плюсом. Один на основе хэш-функций, другой на основе HMAC или хешированного кода аутентификации сообщения, третий на основе блочных шифров, четвертый – на эллиптических кривых.
С последним, «эллиптическим», правда, вышел серьезный конфуз по целому ряду причин. В отличие от трех первых, где примитивы уже хорошо изучены и проверены криптографическим сообществом, этот был предложен совсем недавно, около года назад Агентством национальной безопасности США.
Алгоритм по независимым оценкам ничем хорошим не отличается, имеет мутную и не разъясненную разработчиком конструкцию, работает существенно медленнее остальных трех. Да еще в придачу несет в себе, как уже установлено, явные признаки математической закладки, с помощью секретных констант позволяющей взламывать генератор на лету.
Зачем в стандарты НИСТ включен столь сомнительный «подарок», в общем-то понятно. Но не факт, что хоть кто-то захочет по доброй воле им воспользоваться.
[КОНЕЦ ВРЕЗКИ]
kiwi arXiv 