Известные примеры программ, подверженных экспортным ограничениям - это последние версии броузеров (browser)
Интернета, в частности Netscape Navigator фирмы Netscape Communications и Internet Explorer фирмы Microsoft. Они пре-
доставляют шифрование со 128-битным ключом для пользователей внутри США и с 40-битным ключом для всех остальных.
Также в эту группу попадает последняя версия архиватора ARJ 2.55, известного своим слабым алгоритмом шифрования архивов. Теперь пользователи внутри США могут использовать криптостойкий алгоритм ГОСТ. Комизм ситуации в том, что хотя этот алгоритм является российским, даже россияне по законам США все равно не могут воспользоваться им в программе ARJ.
3) Использование собственных криптоалгоритмов.
Незнание или нежелание использовать известные алгоритмы - такая ситуация, как ни парадоксально, также имеет место быть, особенно в программах типа Freeware и Shareware, например, архиваторах.
Как уже говорилось, архиватор ARJ (до версии 2.50 включительно) использовал очень слабый алгоритм шифрования - простое гаммирование. Казалось бы, что в данном случае использование его допустимо, т.к. архивированный текст должен быть совершенно неизбыточен и статистические методы криптоанализа здесь не подходят. Однако, после более детального изучения оказалось, что в архивированном тексте присутствует (и это оказывается справедливым для любых архиваторов) некоторая неслучайная информация - например, таблица Хаффмана и некоторая другая служебная информация. Поэтому, точно зная или предсказав с некоторой вероятностью значение этих служебных переменных, можно с той же вероятностью определить и соответствующие символы пароля.
Далее, использование слабых алгоритмов часто приводит к успеху атаки по открытому тексту. В случае архиватора ARJ, если злоумышленнику известен хотя бы один файл из зашифрованного архива, он с легкостью определит пароль архива и
70
извлечет оттуда все остальные файлы (криптостойкость ARJ при наличии открытого текста – 20 !). Даже если ни одного файла в незашифрованном виде нет, то все равно простое гаммирование позволяет достичь скорости перебора в 300000 паролей/сек. на машине класса Pentium/120.
Аналогичная ситуация имеет место и в случае с популярными программами из Microsoft Office - для определения пароля там необходимо знать всего 16 байт файла .doc или .xls, после чего достаточно перебрать всего 24 вариантов.
В сетевой ОС Novell Netware фирмы Novell (версии 3.х и 4.х) также применяется собственный алгоритм хэширования. Основным его недостатком является то, что его удалось обратить.
На входе хэш-функция получает 32-байтовое значение, полученное из оригинального пароля пользователя путем либо сжатия пароля длиной более 32 символов с помощью операции XOR, либо размножением пароля длиной менее 32 символов; а на выходе - 16-байтовое хэш-значение (Hash16). Именно оно (для Novell Netware 3.х) хранится в базе данных связок
(bindery) в виде свойства "PASSWORD".
Одним из основных свойств криптостойкой хэшфункции должно быть то, что невозможно по хэш-значению получить исходный ключ, кроме как полным перебором (таковой, например, является функция crypt(), используемая в UNIX, которая основана на DES). Именно это свойство нарушено в хэш-функции, применяемой в Novell Netware.
Была построена процедура, которая из данного хэшзначения путем небольшого перебора получает 32-байтовую последовательность, которая, конечно, не является истинным паролем, но тем не менее воспринимается Novell Netware как таковой, т.к. применение к ней хэш-алгоритма, выдает в точности имеющееся хэш-значение. Рассмотренный хэш-алгоритм остался и в 4 версии Novell Netware.
71
9.2.Стойкие криптоалгоритмы
9.2.1.Ошибки в реализации криптоалгоритмов
Несмотря на то, что в этом случае применяются криптостойкие или сертифицированные алгоритмы, эта группа причин приводит к нарушениям безопасности криптосистем из-за их неправильной реализации.
1) Уменьшение криптостойкости при генерации ключа.
Эта причина с весьма многочисленными примерами, когда криптосистема либо обрезает пароль пользователя, либо генерирует из него данные, имеющие меньшее количество бит, чем сам пароль. Примеры:
Многие (старые) версии UNIX - пароль пользователя обрезается до 8 байт перед хэшированием. Любопытно, что, например, Linux 2.0, требуя от пользователей ввода паролей, содержащих обязательно буквы и цифры, не проверяет, чтобы 8- символьное начало пароля также состояло из букв и цифр. Поэтому пользователь, задав, например, достаточно надежный пароль passwordIsgood19, будет весьма удивлен, узнав, что хакер вошел в систему под его именем с помощью элементарно-
го пароля password.
Novell Netware позволяет пользователям иметь пароли до 128 байт, что дает (считая латинские буквы без учета регистра, цифры и спецсимволы, т.е. 26+10+32=68 знаков) 68128 ~2779 комбинаций. При этом хэш-значение (см. выше) имеет длину всего 128 бит, что соответствует 2128 комбинаций. Отсюда сле-
дует, что на самом деле эффективная длина пароля в Novell Netware не более log682128=21 символа, т.е. в 6 раз меньше воз-
можной.
Полностью аналогичная ситуация происходит с архиватором RAR версий 1.5x - выбор пароля больше 10 символов не приводит к росту времени, необходимого на его вскрытие.
Если длина пароля "сверху" в этом случае определяется реализацией криптоалгоритмов, то ограничение на длину
72
"снизу" уже связано с понятием единицы информации или энтропии. В рассмотренном примере с Novell Netware для создания хэш-значения с энтропией 128 бит длина пароля должна быть не менее 128*8/log268=69 бит или не менее 22 символов. То, что многие криптосистемы не ограничивают минимальную длину пароля, как раз и приводит к успеху атак перебором не ключей, а паролей.
2) Отсутствие проверки на слабые ключи.
Некоторые криптоалгоритмы (в частности, DES, IDEA) при шифровании со специфическими ключами не могут обеспечить должный уровень криптостойкости. Такие ключи называют слабыми (weak). Для DES известно 4 слабых и 12 полуслабых (semi-weak) ключей. И хотя вероятность попасть в них равняется 1/252, для серьезных криптографических систем пренебрегать ей нельзя.
Мощность множества слабых ключей IDEA составляет не много - не мало – 251 (впрочем, из-за того, что всего ключей 2128, вероятность попасть в него меньше, чем у DES).
3) Недостаточная защищенность от РПС.
РПС (разрушающие программные средства) - это компьютерные вирусы, троянских кони, программные закладки и т.п. программы, способные перехватить секретный ключ или сами нешифрованные данные, а также просто подменить алгоритм на некриптостойкий. В случае, если программист не предусмотрел достаточных способов защиты от РПС, они легко способны нарушить безопасность криптосистемы. Особенно это актуально для операционных систем, не имеющих встроенных средств защиты или средств разграничения доступа -
типа MS DOS:
Перехват пароля. Как пример можно привести самый старый способ похищения пароля, известный еще со времен больших ЭВМ, когда программа-"фантом" эмулирует приглашение ОС, предлагая ввести имя пользователя и пароль, запоминает его в некотором файле и прекращает работу с сообще-
73
нием "Invalid password". Для MS DOS существует множество закладок для чтения и сохранения паролей, набираемых на клавиатуре (через перехват соответствующего прерывания), например, при работе утилиты Diskreet v. 6.0.
Подмена криптоалгоритма. Примером реализации этого случая является закладка, маскируемая под прикладную про- грамму-"ускоритель" типа Turbo Krypton. Эта закладка заменяет алгоритм шифрования ГОСТ 28147-89, реализуемой платой "Krypton-3" (демонстрационный вариант), другим, простым и легко дешифруемым алгоритмом.
4) Наличие зависимости во времени обработки ключей.
Это сравнительно новый аспект недостаточно корректной реализации криптоалгоритмов. Многие криптосистемы неодинаково быстро обрабатывают разные входные данные. Это происходит как из-за аппаратных (разное количество тактов на операцию, попадание в процессорный кэш и т.п.), так и программных причин (особенно при оптимизации программы по времени). Время может зависеть как от ключа шифрования, так и (рас)шифруемых данных.
Поэтому злоумышленник, имея зашифрованные данные, а также будучи способным каким-то образом измерять время обработки этих данных (например, анализируя время отправки пакетов с данными), может попытаться подобрать секретный ключ.
И хотя пока не удалось довести такие исследования до конкретного результата (вычислить секретный ключ), этот пример показывает, что программирование систем критического назначения (в т.ч. и криптосистем) должно быть особенно тщательным и, возможно, для этого необходимо применять особые защитные методы программирования и специализированные средства разработки (особенно компиляторы).
5) Ошибки в программной реализации.
Ясно, что пока программы будут писаться людьми, этот фактор всегда будет иметь место. Хороший пример - ОС
74