Главная      Учебники - Разные     Лекции (разные) - часть 32

 

Поиск            

 

Почему криптосистемы ненадежны?

 

             

Почему криптосистемы ненадежны?

Russian LinkExchange Member

•

Security Page


Почему криптосистемы ненадежны?


Павел Семьянов, Центр Защиты Информации СПбГТУ

В современном программном обеспечении (ПО) криптоалгоритмы широко применяются не только для задач шифрования данных, но и для аутентификации и проверки целостности. На сегодняшний день существуют хорошо известные и апробированные криптоалгоритмы (как с симметричными, так и несимметричными ключами), криптостойкость которых либо доказана математически, либо основана на необходимости решения математически сложной задачи (факторизации, дискретного логарифмирования и т.п.). К наиболее известным из них относятся DES, ГОСТ, RSA. Таким образом, они не могут быть вскрыты иначе, чем полным перебором или решением указанной задачи.

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

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

По аналогии с таксономией причин нарушения безопасности ВС [1], выделим следующие причины ненадежности криптографических программ (см. рис. 1):

    1. Невозможность применения стойких криптоалгоритмов;

    2. Ошибки в реализации криптоалгоритмов;

    3. Неправильное применение криптоалгоритмов;

    4. Человеческий фактор.

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

Рис. 1. Причины ненадежности криптосистем.

Невозможность применения стойких криптоалгоритмов

Эта группа причин является наиболее распространенной из-за следующих факторов.

Малая скорость стойких криптоалгоритмов

Это основной фактор, затрудняющий применение хороших алгоритмов в, например, системах "тотального" шифрования или шифрования "на лету". В частности, программа Norton DiskReet, хотя и имеет реализацию DES, при смене пользователем ключа может не перешифровывать весь диск, т.к. это займет слишком много времени. Аналогично, программа компрессии "на лету" Stacker фирмы Stac Electronics имеет опцию закрытия паролем компрессируемых данных. Однако она не имеет физической возможности зашифровать этим паролем свой файл, обычно имеющий размеры в несколько сот мегабайт, поэтому она ограничивается очень слабым алгоритмом и хранит хэш-функцию от пароля вместе с защищаемыми данными. Величина криптостойкости1 этой функции была исследована и оказалась равной 28, т.е. пароль может быть вскрыт тривиально.

Экспортные ограничения

Это причина, связанная с экспортом криптоалгоритмов или с необходимостью приобретать патент или права на них. В частности, из США запрещен экспорт криптоалгоритмов с длиной ключа более 40 бит2. Очевидно, что такая криптостойкость не может считаться надежной при современных вычислительных мощностях и даже на персональном компьютере, положив скорость перебора в 50 000 паролей/сек, получим время перебора в среднем порядка 4 месяцев.

Известные примеры программ, подверженных экспортным ограничениям - это последние версии броузеров (browser) Интернета, в частности Netscape Navigatorфирмы Netscape Communications и Internet Explorer фирмы Microsoft. Они предоставляют шифрование со 128-битным ключом для пользователей внутри США и с 40-битным ключом для всех остальных.

Также в эту группу попадает последняя версия архиватора ARJ 2.60, известного своим слабым алгоритмом шифрования архивов. Теперь пользователи внутри США могут использовать криптостойкий алгоритм ГОСТ. Комизм ситуации в том, что хотя этот алгоритм является российским, даже россияне по законам США все равно не могут воспользоваться им в программе ARJ.

Использование собственных криптоалгоритмов

Незнание или нежелание использовать известные алгоритмы - такая ситуация, как ни парадоксально, также имеет место быть, особенно в программах типа Freeware и Shareware, например, архиваторах.

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

Далее, использование слабых алгоритмов часто приводит к успеху атаки по открытому тексту. В случае архиватора ARJ, если злоумышленнику известен хотя бы один файл из зашифрованного архива, он с легкостью определит пароль архива и извлечет оттуда все остальные файлы (криптостойкость ARJ при наличии открытого текста - 20 !). Даже если ни одного файла в незашифрованном виде нет, то все равно простое гаммирование позволяет достичь скорости перебора в 350000 паролей/сек. на машине класса Pentium.

Аналогичная ситуация имеет место и в случае с популярными программами из Microsoft Office - для определения пароля там необходимо знать всего 16 байт файла .doc или .xls, после чего достаточно перебрать всего 24 вариантов. В Microsoft Office 97 сделаны значительные улучшения алгоритмов шифрования, в результате чего осталась возможность только полного перебора, но... не везде - MS Access 97 использует примитивнейший алгоритм, причем шифруются не данные, а сам пароль операцией XOR с фиксированной константой!

В сетевой ОС Novell Netware фирмы Novell (версии 3.х и 4.х) также применяется собственный алгоритм хэширования. На входе хэш-функция получает 32-байтовое значение, полученное из оригинального пароля пользователя путем либо сжатия пароля длиной более 32 символов с помощью операции XOR, либо размножением пароля длиной менее 32 символов; а на выходе - 16-байтовое хэш-значение (Hash16). Именно оно (для Novell Netware 3.х) хранится в базе данных связок (bindery) в виде свойства "PASSWORD".

Одним из основных свойств криптостойкой хэш-функции должно быть то, что она не должна допускать легкого построения коллизий (таковой, например, является функция crypt(), используемая в UNIX, которая основана на DES). Именно это свойство нарушено в хэш-функции, применяемой в Novell Netware.

Была построена процедура, которая из данного хэш-значения путем небольшого перебора (несколько секунд на машине класса 80486DX2-66) получает 32-байтовую последовательность, которая, конечно, не является истинным паролем, но тем не менее воспринимается Novell Netware как таковой, т.к. применение к ней хэш-алгоритма, выдает в точности имеющееся хэш-значение.

Рассмотренный хэш-алгоритм остался и в 4 версии Novell Netware.

В свою очередь, фирма Microsoft также имеет серьезнейшие недостатки в своем основном хэш-алгоритме, применяемом во всех своих ОС, начиная с Windows 3.11, при аутентификации в локальных (протокол NetBIOS) и глобальных (протоколы CIFS и http) сетях, называемым LM (Lan Manager)-хэш [4]. (Впрочем, Microsoft ссылается на то, что он остался еще со времен OS/2 и что его разрабатывала IBM).

Он вычисляется следующим образом:

  1. Пароль превращается в 14-символьную строку путем либо отсечки болеет длинных паролей, либо дополнения коротких паролей нулевыми элементами.

  2. Все символы нижнего регистра заменяются на символы верхнего регистра. Цифры и специальные символы остаются без изменений.

  3. 14-байтовая строка разбивается на две семибайтовых половины.

  4. Используя каждую половину строки в роли ключа DES, с ним шифруется фиксированная константа, получая на выходе две 8-байтовые строки.

  5. Эти строки сливаются для создания 16-разрядного значения хэш-функции.

Очевидно, что атаки на LM-хэш легко достигают успеха по следующим причинам:

  • Преобразование всех символов в верхний регистр ограничивает и без того небольшое число возможных комбинаций для каждого (26+10+32=68).

  • Две семибайтовых "половины" пароля хэшируются независимо друг от друга. Таким образом, две половины могут подбираться перебором независимо друг от друга, и пароли, длина которых превышает семь символов, не сильнее, чем пароли с длиной семь символов. Таким образом, для гарантированного нахождения пароля необходимо перебрать вместо 940+941+... 9414 ~4L1027 всего лишь 2L(680+681+...+687) ~1L1013 (т.е. почти в 1014 раз меньше) комбинаций. Кроме того, те пароли, длина которых не превышает семь символов, очень просто распознать, поскольку вторая половина хэша будет одним и тем же значением AAD3B435B51404EE, получаемой при шифровании фиксированной константы с помощью ключа из семи нулей.

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

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

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

Уменьшение криптостойкости при генерации ключа

Эта причина с весьма многочисленными примерами, когда криптосистема либо обрезает пароль пользователя, либо генерирует из него данные, имеющие меньшее количество бит, чем сам пароль. Примеры:

  1. Во многих (старых) версиях UNIX пароль пользователя обрезается до 8 байт перед хэшированием. Любопытно, что, например, Linux 2.0, требуя от пользователей ввода паролей, содержащих обязательно буквы и цифры, не проверяет, чтобы 8-символьное начало пароля также состояло из букв и цифр. Поэтому пользователь, задав, например, достаточно надежный пароль passwordIsgood19, будет весьма удивлен, узнав, что хакер вошел в систему под его именем с помощью элементарного пароля password.

  2. Novell Netware позволяет пользователям иметь пароли до 128 байт, что дает (считая латинские буквы без учета регистра, цифры и спецсимволы) 68128 ~2779 комбинаций. Но при этом, во-первых, хэш-функция (см. выше) получает на входе всего лишь 32-байтовое значение, что ограничивает эффективную длину пароля этой же величиной. Более того, во-вторых, на выходе хэш-значение имеет длину всего 128 бит, что соответствует 2128 комбинаций. Это дополнительно снижает эффективную длину до =21 символа3, т.е. в 6 раз по сравнению с первоначальной.

  3. Полностью аналогичная ситуация происходит с архиватором RAR версий 1.5x - выбор пароля больше 10 символов не приводит к росту времени, необходимого на его вскрытие.

Если длина пароля "сверху" в этом случае определяется реализацией криптоалгоритмов, то ограничение на длину "снизу" уже связано с понятием единицы информации или энтропии. В рассмотренном примере с Novell Netware для создания хэш-значения с энтропией 128 бит длина пароля должна быть не менее =69 бит4 или не менее 22 символов5. То, что многие криптосистемы не ограничивают минимальную длину пароля, как раз и приводит к успеху атак перебором не ключей, а паролей.

Отсутствие проверки на слабые ключи

Некоторые криптоалгоритмы (в частности, DES, IDEA) при шифровании со специфическими ключами не могут обеспечить должный уровень криптостойкости. Такие ключи называют слабыми (weak). Для DES известно 4 слабых и 12 полуслабых (semi-weak) ключей. И хотя вероятность попасть в них равняется ~2L10-16, для серьезных криптографических систем пренебрегать ей нельзя.

Мощность множества слабых ключей IDEA составляет не много - не мало - 251 (впрочем, из-за того, что всего ключей 2128, вероятность попасть в него в 3L107 раз меньше, чем у DES).

Недостаточная защищенность от РПС

РПС (разрушающие программные средства) - это компьютерные вирусы, троянских кони, программные закладки и т.п. программы, способные перехватить секретный ключ или сами нешифрованные данные, а также просто подменить алгоритм на некриптостойкий. В случае, если программист не предусмотрел достаточных способов защиты от РПС, они легко способны нарушить безопасность криптосистемы. Особенно это актуально для операционных систем, не имеющих встроенных средств защиты или средств разграничения доступа - типа MS DOS или Windows 95:

  1. Перехват пароля. Как пример можно привести самый старый способ похищения пароля, известный еще со времен больших ЭВМ, когда программа-"фантом" эмулирует приглашение ОС, предлагая ввести имя пользователя и пароль, запоминает его в некотором файле и прекращает работу с сообщением "Invalid password". Для MS DOS и Windows существует множество закладок для чтения и сохранения паролей, набираемых на клавиатуре (через перехват соответствующего прерывания), например, при работе утилиты Diskreet v. 6.0.

  2. Подмена криптоалгоритма. Примером реализации этого случая является закладка, маскируемая под прикладную программу-"ускоритель" типа Turbo Krypton. Эта закладка заменяет алгоритм шифрования ГОСТ 28147-89, реализуемой платой "Krypton-3" (демонстрационный вариант), другим, простым и легко дешифруемым алгоритмом [1].

  3. Троянский конь в электронной почте. Последним примером служит имевшие место в июне 1998 года попытки проникновения троянского коня через электронную почту. В письмо были вложены порнографическая картинка и EXE-файл FREECD.EXE, который за то время, пока пользователь развлекался с письмом, расшифровывал пароли на соединение с провайдером (Dial-Up) и отправлял их на адрес ispp@usa.net.

Наличие зависимости во времени обработки ключей

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

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

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

Ошибки в программной реализации

Ясно, что пока программы будут писаться людьми, этот фактор всегда будет иметь место. Хороший пример - ОС Novell Netware 3.12, где, несмотря на достаточно продуманную систему аутентификации, при которой, по заявлениям фирмы Novell, "нешифрованный пароль никогда не передается по сети", удалось найти ошибку в программе SYSCON v. 3.76, при которой пароль именно в открытом виде попадает в один из сетевых пакетов. Этого не наблюдается ни с более ранними, ни с более поздними версиями этой программы, что позволяет говорить именно о чисто программистской ошибке. Этот ошибка проявляется только если супервизор меняет пароль кому-либо (в том числе и себе). Видимо, каким-то образом в сетевой пакет попадает клавиатурный буфер.

Наличие люков

Причины наличия люков в криптосистемах очевидны: разработчик хочет иметь контроль над обрабатываемой в его системе информацией и оставляет для себя возможность расшифровывать ее, не зная ключа пользователя. Возможно также, что они используются для отладки и по какой-то причине не убираются из конечного продукта. Естественно, что это рано или поздно становится известным достаточно большому кругу лиц и ценность такой криптосистемы становится почти нулевой. Самыми известными примерами здесь являются AWARD BIOS (до версии 4.51PG) с его универсальным паролем "AWARD_SW" и СУБД Paradox фирмы Borland International, также имеющая "суперпароли" "jIGGAe" и "nx66ppx".

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

Недостатки датчика случайных чисел (ДСЧ)

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