Неправильная реализация криптоалгоритмов

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

• 1. Уменьшение криптостойкости при генерации ключа причина с весьма многочисленными примерами, когда криптосистема либо обрезает пароль пользователя, либо генерирует из него данные, имеющие меньшее количество бит, чем сам пароль. Примеры:
• 1) Novell Netware позволяет пользователям иметь пароли до 128 байт, что дает (считая латинские буквы без учета регистра, цифры и спецсимволы) 68¹²⁸ ~2⁷⁷⁹ комбинаций. Но при этом, во-первых, хэш-функция (см. выше) получает на входе всего лишь 32-байтовое значение, что ограничивает эффективную длину пароля этой же величиной. Более того, во-вторых, на выходе хэш-значение имеет длину всего 128 бит, что соответствует 2¹²⁸ комбинаций. Это дополнительно снижает эффективную длину до 21 символа, т. е. в 6 раз по сравнению с первоначальной.
• 2) Полностью аналогичная ситуация происходит с архиватором RAR версий 1.5x — выбор пароля больше 10 символов не приводит к росту времени, необходимого на его вскрытие. Если длина пароля «сверху» в этом случае определяется реализацией криптоалгоритмов, то ограничение на длину «снизу» уже связано с понятием единицы информации или энтропии. В рассмотренном примере с Novell Netware для создания хэш-значения с энтропией 128 бит длина пароля должна быть не менее 69 бит или не менее 22 символов. То, что многие криптосистемы не ограничивают минимальную длину пароля, как раз и приводит к успеху атак перебором не ключей, а паролей.
• 2. Отсутствие проверки на слабые ключи. Некоторые криптоалгоритмы (в частности, DES, IDEA) при шифровании со специфическими ключами не могут обеспечить должный уровень криптостойкости. Такие ключи называют слабыми (weak). Для DES известно 4 слабых и 12 полуслабых (semi-weak) ключей. И хотя вероятность попасть в них равняется ~2L10−16, для серьезных криптографических систем пренебрегать ей нельзя.

Мощность множества слабых ключей IDEA составляет не много — не мало — 2⁵¹ (впрочем, из-за того, что всего ключей 2¹²⁸, вероятность попасть в него в 3L10⁷ раз меньше, чем у DES).

• 3. Недостаточная защищенность от разрушающих программных средств. Разрушающие программные средства — это компьютерные вирусы, троянские кони, программные закладки и тому подобные программы, способные перехватить секретный ключ или сами нешифрованные данные, а также просто подменить алгоритм на некриптостойкий. В случае если программист не предусмотрел достаточных способов защиты от разрушающих программных средств, они легко способны нарушить безопасность криптосистемы. Особенно это актуально для операционных систем, не имеющих встроенных средств защиты или средств разграничения доступа — типа MS DOS или Windows 95:
• 1) Перехват пароля. Как пример можно привести самый старый способ похищения пароля, известный еще со времен больших ЭВМ, когда программа-«фантом» эмулирует приглашение ОС, предлагая ввести имя пользователя и пароль, запоминает его в некотором файле и прекращает работу с сообщением «Invalid password». Для MS DOS и Windows существует множество закладок для чтения и сохранения паролей, набираемых на клавиатуре (через перехват соответствующего прерывания), например, при работе утилиты Diskreet v. 6.0.
• 2) Подмена криптоалгоритма. Примером реализации этого случая является закладка, маскируемая под прикладную «программу-ускоритель» типа Turbo Krypton. Эта закладка заменяет алгоритм шифрования ГОСТ 28 147–89, реализуемой платой «Krypton-3» (демонстрационный вариант), другим, простым и легко дешифруемым алгоритмом.
• 3) Троянский конь в электронной почте. Примером служит имевшие место в июне 1998 года попытки проникновения троянского коня через электронную почту. В письмо были вложены порнографическая картинка и EXE-файл FREECD. EXE, который за то время, пока пользователь развлекался с письмом, расшифровывал пароли на соединение с провайдером (Dial-Up) и отправлял их на адрес Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script
• 4. Наличие зависимости во времени обработки ключей. Это сравнительно новый аспект недостаточно корректной реализации криптоалгоритмов. Многие криптосистемы неодинаково быстро обрабатывают разные входные данные. Это происходит как из-за аппаратных (разное количество тактов на операцию, попадание в процессорный кэш и т. п.), так и программных причин (особенно при оптимизации программы по времени). Время может зависеть как от ключа шифрования, так и от шифруемых данных.

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

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

• 5. Ошибки в программной реализации. Пока программы будут писаться людьми, этот фактор всегда будет иметь место. Хороший пример — ОС Novell Netware 3.12, где, несмотря на достаточно продуманную систему аутентификации, при которой, по заявлениям фирмы Novell, «нешифрованный пароль никогда не передается по сети», удалось найти ошибку в программе SYSCON v. 3.76, при которой пароль именно в открытом виде попадает в один из сетевых пакетов. Этого не наблюдается ни с более ранними, ни с более поздними версиями этой программы, что позволяет говорить именно о чисто программистской ошибке. Этот ошибка проявляется, только если супервизор меняет пароль кому-либо (в том числе и себе). Видимо, каким-то образом в сетевой пакет попадает клавиатурный буфер.
• 6. Наличие люков. Причины наличия люков в криптосистемах очевидны: разработчик хочет иметь контроль над обрабатываемой в его системе информацией и оставляет для себя возможность расшифровывать ее, не зная ключа пользователя. Возможно также, что они используются для отладки и по какой-то причине не убираются из конечного продукта. Естественно, что это рано или поздно становится известным достаточно большому кругу лиц и ценность такой криптосистемы становится почти нулевой. Самыми известными примерами здесь являются AWARD BIOS (до версии 4.51PG) с его универсальным паролем «AWARD_SW» и СУБД Paradox фирмы Borland International, также имеющая «суперпароли» «jIGGAe» и «nx66ppx».

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

7. Недостатки датчика случайных чисел. Хороший, математически проверенный и корректно реализованный датчик случайных чисел также важен для криптосистемы, как и хороший, математически стойкий и корректный криптоалгоритм, иначе его недостатки могут повлиять на общую криптостойкость системы. При этом для моделирования датчика случайных чисел на ЭВМ обычно применяют датчики псевдослучайных чисел, характеризующиеся периодом, разбросом, а также необходимостью его инициализации (seed). Применение псевдослучайных чисел для криптосистем вообще нельзя признать удачным решением, поэтому хорошие криптосистемы применяют для этих целей физический датчик случайных чисел (специальную плату), или, по крайней мере, вырабатывают число для инициализации псевдослучайных чисел с помощью физических величин (например, времени нажатия на клавиши пользователем).

Малый период и плохой разброс относятся к математическим недостаткам датчика случайных чисел и появляются в том случае, если по каким-то причинам выбирается собственный датчик случайных чисел. Иначе говоря, выбор собственного датчика случайных чисел так же опасен, как и выбор собственного криптоалгоритма.

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

При плохом разбросе датчика злоумышленник также может уменьшить среднее время поиска, если начнет перебор с самых вероятных значений псевдослучайных чисел.

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

Такая ситуация имела место в программе Netscape Navigator версии 1.1. Она инициализировала ПСЧ, используя текущее время в секундах (sec) и микросекундах (usec), а также идентификаторы процесса (pid и ppid). Как выяснили исследователи Я. Голдберг и Д. Вагнер, при такой схеме как максимум получалось 47 значащих бит информации (притом, что этот датчик использовался для получения 40- или 128 -битных ключей). Но, если у злоумышленника была возможность перехватить пакеты, передаваемые по сети, и был доступ (account) на компьютер, где запущена программа, то для него не составляло труда с большой степенью вероятности узнать sec, pid и ppid. Если это не удавалось, то злоумышленник все равно мог попытаться установить время через сетевые демоны time, pid мог бы быть получен через демон SMTP (обычно он входит в поле Message-ID), а ppid либо не сильно отличается от pid, либо вообще равен 1. Исследователи написали программу unssl, которая, перебирая микросекунды, находила секретный 40-битный ключ в среднем за минуту. [7].