Журнал "Компьютерра" №714 - Компьютерра

В частности, в последующих версиях программ начали применять вполне качественный поточный шифр RC4. Правда, в ранних экспортных версиях ПО длина ключа ограничивалась всего лишь 40 битами. При такой длине шифры, как известно, без проблем вскрываются на ПК лобовым (тотальным) перебором всех возможных ключевых комбинаций. Но после коррекции экспортных законов к концу 1990-х пользователям новых версий Microsoft Office, в принципе, стали доступны теоретически стойкие шифрсредства - в частности, RC4 с длиной ключа 128 бит. Вот только на практике шифр оказался реализован так, что надежной защиты данных с его помощью все равно не получалось.

Среди фундаментальных основ криптографии имеется очень важное правило: если для засекречивания используется поточный шифр (наложение на открытый текст постоянно изменяющейся шифрпоследовательности), то никогда одну и ту же шифрпоследовательность не накладывают на два разных документа (разными в данном случае считаются любые модификации файла, включая вставку или изъятие единственного знака). Если же это сделано, то всего по двум одноключевым документам шифрование можно развалить и прочитать оба текста - причем сам ключ и его длина никакой роли не играют. В годы Второй мировой войны английские криптоаналитики из-за такого рода ошибок германских шифровальщиков смогли полностью вскрыть криптосхему шифратора "Шлюссельцузатц". Позже это позволило им с помощью "суперкомпьютера" Colossus вскрывать ключи и читать всю переписку противника.

В программных же продуктах Microsoft шифр RC4 был реализован таким образом, чтобы одноключевые комплекты порождались ВСЕГДА. Ключ без затей генерировался на основе пароля доступа к документу, поэтому разные версии документа шифровались одним и тем же ключом. Как известно, разные версии одних и тех же файлов присутствуют в системе очень часто - в резервных кэшах, как архивные копии, как совместно подготавливаемые документы и т. д. Для таких случаев в криптографии есть элементарнейший способ недопущения одноключевых комплектов - подмешивание в ключ наряду с паролем уникального, одноразового "вектора инициализации" (IV, initialization vector), который не является секретом, но всякий раз делает шифрпоследовательность иной.

То, что в Microsoft почему-то уклоняются от использования IV в поточном шифре, впервые стало известно в 1999 году еще для Windows NT - когда хакеры обнаружили слабости в системе защиты криптоключей Syskey. Серьезные оплошности в реализации криптографии допускаются регулярно и почти всеми разработчиками (см. врезку о WEP), однако в Microsoft не только проигнорировали тревожные сигналы, но и перенесли ту же самую слабость в последующие версии системы. В частности, в 2005 году, когда уже вышли Windows XP и Office 2003, стало известно, что все та же по сути уязвимость - отсутствие IV и систематическое порождение одноключевых комплектов - выявлена в документах, подготовленных и зашифрованных программами MS Word и MS Excel с помощью RC4.

В принципе, в качестве вектора инициализации можно использовать самую разную информацию - хоть системный штамп о текущих дате-времени. Но с точки зрения криптографии наиболее грамотное решение - вырабатывать IV с помощью генератора псевдослучайных чисел. И если на протяжении многих лет наличие PRNG в системе игнорировалось, причем с очевидным ущербом для безопасности, то крайне сложно поверить, будто сделано это неумышленно.

Впрочем, и в тех ситуациях, когда PRNG используется для генерации секретных ключей или других криптопоследовательностей, делается это весьма небезопасным образом.

Слабость спереди и сзади

Качественный с точки зрения криптографии генератор псевдослучайных чисел должен отвечать трем главным требованиям: (1) выдавать последовательность, статистически неотличимую от случайной равновероятной; (2) противостоять восстановлению прошлых состояний по известному текущему; (3) противостоять восстановлению будущих состояний по текущему состоянию алгоритма.

Нет никакого секрета в том, каким образом обеспечить все три нужных качества. Из этого, правда, не следует, что конструировать хорошие генераторы легко (см. врезку). Но если PRNG просто генерирует последовательность чисел, похожую на случайную, но явно не отвечает требованиям (2) и (3), то с точки зрения криптографии это слабый и небезопасный генератор. Именно таким, увы, является алгоритм генератора PRNG, ныне вскрытого израильскими криптоаналитиками.

Криптогенератор - это непросто

Из того, что требования, предъявляемые к качественному криптографическому генератору случайных чисел, хорошо известны, вовсе не следует, что сконструировать его проще простого. В истории криптографии много случаев, когда слабости находили и в новых схемах известных авторов, и в алгоритмах, успевших получить распространение. Например, в 1996 году одна из ранних версий протокола SSL была взломана именно из-за слабостей в генераторе случайных чисел. Совсем недавно были обнаружены криптографические слабости в PRNG операционных систем Linux и FreeBSD, открытых для анализа.

По этой причине многие разработчики средств защиты благосклонно встретили инициативу NIST, американского Института стандартов и технологий, подготовившего и опубликовавшего большой, на 130 страниц документ под названием NIST Special Publication 800-90, целиком посвященный генераторам псевдослучайных чисел. В этом документе они именуются DRBG (Deterministic Random Bit Generators), и там содержатся описания четырех изученных и рекомендуемых к применению генераторов.

Все четыре генератора построены на основе уже существующих криптографических примитивов, что принято считать плюсом. Один на основе хеш-функций, другой на основе HMAC (хешированного кода аутентификации сообщения), третий на основе блочных шифров, четвертый - на эллиптических кривых. С последним, правда, вышел конфуз по целому ряду причин. В отличие от трех первых, где примитивы уже хорошо изучены и проверены криптографическим сообществом, его схема была предложена совсем недавно, около года назад, Агентством национальной безопасности США. Алгоритм, по независимым оценкам, ничем хорошим не отличается, имеет мутную и не разъясненную разработчиком конструкцию и работает гораздо медленнее остальных трех. Да еще и несет в себе, как уже установлено, явные признаки математической закладки, с помощью секретных констант позволяющей взламывать генератор на лету.

Зачем в стандарты NIST включен столь сомнительный "подарок", в общем-то, понятно. Но не факт, что хоть кто-то захочет по доброй воле им воспользоваться.

Этот генератор тоже построен на основе RC4. И коль скоро всякий приличный поточный шифр дает на выходе последовательность чисел, статистически неотличимую от равновероятной, то и генератор на его основе вполне отвечает требованию (1). Но вот дальше начинаются очень неприятные моменты конкретной реализации PRNG. Чтобы обеспечить свойство (2) - не допустить восстановление прошлых состояний, - в качестве тактов генерации принято использовать однонаправленные (хеш-)функции, легко вычисляемые только в одну сторону. В Windows же обратная функция вычисляется столь же просто, как и прямая генерация следующего состояния.

Такая же унылая картина и для свойства (3). Дабы воспрепятствовать восстановлению будущих состояний криптогенератора, используют так называемую рандомизацию - то есть обновление состояний случайно взятой последовательностью бит от какого-нибудь внешнего источника. Чем короче расстояние между такими "перезагрузками", тем выше криптостойкость генератора. Хотя общая схема PRNG в Windows не менялась, в ранних версиях OC длина между перезагрузками состояний составляла 512 байт, а в Win2000, как установили израильтяне, она выросла до 16 килобайт. Если же учесть, что PRNG здесь реализован на основе восьми потоков от работающих в параллели шифров RC4, то получается, что реально длина генерируемой криптопоследовательности между перезагрузками состояний составляет 128 килобайт.

Поэтому, определив всего одно внутреннее состояние генератора (например, с помощью известного трюка с переполнением буфера памяти), злоумышленник может вычислить огромное количество ключей - как уже использованных, так и на будущее. Хуже того, перезагрузка состояний произойдет лишь в том случае, когда все эти 128 килобайт сгенерированы между включением и выключением компьютера. В терминах защищенных SSL-соединений веб-браузера это, огрубленно, означает от 600 до 1200 сеансов шифрованной связи. Понятно, что для обычного компьютера это нереально огромное число. Иными словами, в большинстве случаев криптогенератор вообще не перезагружает свои состояния, так что всего одной "израильской атакой" можно восстановить, по сути, ВСЕ генерируемые им ключи, как вперед, так и назад.