Novell Netware 3.12, где, несмотря на достаточно продуманную систему аутентификации, при которой, по заявлениям фирмы Novell, "нешифрованный пароль никогда не передается по сети", удалось найти ошибку в программе SYSCON v. 3.76, при которой именно пароль в открытом виде попадает в один из сетевых пакетов. Этого не наблюдается ни с более ранними, ни с более поздними версиями этой программы, что позволяет говорить именно о чисто программистской ошибке. Этот ошибка проявляется только если супервизор меняет пароль кому-либо (в том числе и себе). Видимо, каким-то образом в сетевой пакет попадает клавиатурный буфер.
6) Наличие люков.
Причины наличия люков в криптосистемах очевидны: разработчик хочет иметь контроль над обрабатываемой в его системе информацией и оставляет для себя возможность расшифровывать ее, не зная ключа пользователя. Возможно также, что они используются для отладки и по какой-то причине не убираются из конечного продукта. Естественно, что это рано или поздно становится известным достаточно большому кругу лиц и ценность такой криптосистемы становится почти нулевой. Самыми известными примерами здесь являются AWARD BIOS с его универсальным паролем "AWARD_SW" и
СУБД Paradox фирмы Borland International, также имеющая "суперпароли" "jIGGAe" и "nx66ppx".
Вплотную к наличию люков в реализации (очевидно, что в этом случае они используют явно нестойкие алгоритмы или хранят ключ вместе с данными) примыкают алгоритмы, дающие возможность третьему лицу читать зашифрованное сообщение, как это сделано в нашумевшем проекте CLIPPER, где третьим лицом выступает государство, всегда любящее совать нос в тайны своих граждан.
7) Недостатки датчика случайных чисел (ДСЧ).
Хороший, математически проверенный и корректно реализованный ДСЧ также важен для криптосистемы, как и хо-
75
роший, математически стойкий и корректный криптоалгоритм, иначе его недостатки могут повлиять на общую криптостойкость системы. При этом для моделирования ДСЧ на ЭВМ обычно применяют датчики псевдослучайных чисел (ПСЧ), характеризующиеся периодом, разбросом, а также необходимостью его инициализации (seed). Применение ПСЧ для криптосистем вообще нельзя признать удачным решением, поэтому хорошие криптосистемы применяют для этих целей физический ДСЧ (специальную плату), или, по крайней мере, вырабатывают число для инициализации ПСЧ с помощью физических величин (например, времени нажатия на клавиши пользователем).
Малый период и плохой разброс относятся к математическим недостаткам ДСЧ и появляются в том случае, если по ка- ким-то причинам выбирается собственный ДСЧ. Иначе говоря, выбор собственного ДСЧ так же опасен, как и выбор собственного криптоалгоритма.
В случае малого периода (когда псевдослучайных значений, вырабатываемых датчиком, меньше, чем возможных значений ключа) злоумышленник может сократить время поиска ключа, перебирая не сами ключи, а псевдослучайные значения и генерируя из них ключи.
При плохом разбросе датчика злоумышленник также может уменьшить среднее время поиска, если начнет перебор с самых вероятных значений псевдослучайных чисел.
Самой распространенной ошибкой, проявляющейся и в случае хорошего ПСЧ, является его неправильная инициализация. В этом случае число, используемое для инициализации, имеет либо меньшее число бит информации, чем сам датчик, либо вычисляется из неслучайных чисел и может быть предсказано с той или иной степенью вероятности.
Такая ситуация имела место в программе Netscape Navigator версии 1.1. Она инициализировала ПСЧ, используя текущее время в секундах (sec) и микросекундах (usec), а также идентификаторы процесса (pid и ppid). Как выяснили исследователи Я. Голдберг и Д. Вагнер, при такой схеме как мак-
76
симум получалось 47 значащих бит информации (при том, что этот датчик использовался для получения 40или 128 (!)- битных ключей). Но, если у злоумышленника была возможность перехватить пакеты, передаваемые по сети, и был доступ (account) на компьютер, где запущена программа, то для него не составляло труда с большой степенью вероятности узнать sec, pid и ppid. Если даже второе условие не выполнялось, то злоумышленник все равно мог попытаться установить время через сетевые демоны time, pid мог бы быть получен через демон SMTP (обычно он входит в поле Message-ID), а ppid либо не сильно отличается от pid, либо вообще равен 1.
Исследователи написали программу unssl, которая, перебирая микросекунды, находила секретный 40-битный ключ в среднем за минуту.
9.2.2. Неправильное применение криптоалгоритмов
Эта группа причин приводит к тому, что оказывается ненадежными криптостойкие и корректно реализованные алгоритмы.
1) Малая длина ключа.
Это самая очевидная причина. Возникает вопрос: как стойкие криптоалгоритмы могут иметь малую длину ключа? Видимо, вследствие двух факторов:
-некоторые алгоритмы могут работать с переменной длиной ключа, обеспечивая разную криптостойкость - и именно задача разработчика выбрать необходимую длину, исходя из желаемой криптостойкости и эффективности. Иногда на это желание накладываются и иные обстоятельства - такие, как экспортные ограничения.
-некоторые алгоритмы разрабатывались весьма давно, когда длина используемого в них ключа считалась более чем достаточной для соблюдения нужного уровня защиты.
С резким скачком производительности вычислительной техники сначала столкнулся алгоритм RSA, для вскрытия ко-
77
торого необходимо решать задачу факторизации. В марте 1994 была закончена длившаяся в течение 8 месяцев факторизация числа из 129 цифр (428 бит). Для этого было задействовано 600 добровольцев и 1600 машин, связанных посредством электронной почты. Затраченное машинное время было эквивалентно примерно 5000 MIPS-лет.
Прогресс в решении проблемы факторизации во многом связан не только с ростом вычислительных мощностей, но и с появлением в последнее время новых эффективных алгоритмов. (На факторизацию следующего числа из 130 цифр ушло всего 500 MIPS-лет). На сегодняшний день в принципе реально факторизовать 512-битные числа. Если вспомнить, что такие числа еще недавно использовались в программе PGP, то можно утверждать, что это самая быстро развивающаяся область криптографии и теории чисел.
29 января 1997 фирмой RSA Labs был объявлен конкурс на вскрытие симметричного алгоритма RC5. 40-битный ключ был вскрыт через 3.5 часа после начала конкурса! (Для этого даже не потребовалась связывать компьютеры через Интернет - хватило локальной сети из 250 машин в Берклевском университете). Через 313 часов был вскрыт и 48-битный ключ. Таким образом, всем стало очевидно, что длина ключа, удовлетворяющая экспортным ограничениям, не может обеспечить даже минимальной надежности.
Параллельно со вскрытием RC5 был дан вызов и столпу американской криптографии - алгоритму DES, имеющему ключ в 56 бит. И он пал 17 июня 1997 года, через 140 дней после начала конкурса (при этом было протестировано около 25% всех возможных ключей и затрачено примерно 450 MIPSлет). Это – безусловно выдающееся достижение, которое, очевидно, означает фактическую смерть DES как стандарта шифрования.
2) Повторное наложение гаммы шифра.
Уже классическим примером стала уязвимость в Windows 3.x и первых версиях Windows 95, связанная с шиф-
78
рованием. В этом случае программисты фирмы Microsoft, хорошо известные своими знаниями в области безопасности, применяли алгоритм RC4 (представляющем собой ни что иное, как шифрование гаммированием), не меняя гаммы, несколько раз к разным данным - сетевым ресурсам, хранящимся в файлах типа .pwl.
Оказалось, что один из наборов данных файла .pwl представлял из себя более чем специфичный текст - 20-символьное имя пользователя (в верхнем регистре) и набор указателей на ресурсы (см. рис.9.2). Таким образом, угадав им пользователя (которое в большинстве случаев к тому же совпадает с именем файла) можно вычислить по крайней мере 20 байт гаммы. Т.к. гамма не меняется при шифровании других ресурсов (в этом состоит основная ошибка применения RC4 в этом случае), могут быть вычислены первые 20 байт всех ресурсов, в которые входит длина каждого из них. Вычислив длину, можно найти значения указателей и тем самым прибавить еще несколько десятков байт к угаданной гамме. Этот алгоритм реализован в известной программе glide.
Рис. 9.2. Формат файла .PWL
3) Хранение ключа вместе с данными.
Эта причина приводит к тому, что данные, зашифрованные с помощью криптостойкого и корректно реализованного алгоритма, могут быть легко дешифрованы. Это связано со спецификой решаемой задачи, при которой невозможно вводить ключ извне и он хранится где-то внутри в практически
79