19 смертных грехов, угрожающих безопасности программ

Виега Джон

□ выясните, какой криптографический шифр применяется в системе. Это должен быть хорошо известный алгоритм, а не «самописное» произведение автора. Разработанные «на коленке» шифры применять нельзя. Это ошибка. Исправьте ее. Одобренные симметричные шифры бывают двух видов: блочные и потоковые;

□ шифры Advanced Encryption Standard (AES – улучшенный стандарт шифрования) и Triple Data Encryption (3DES – тройной DES) – это примеры блочных шифров. Оба хороши, и в настоящее время лишь они признаны в качестве безопасного международного стандарта. Шифр DES (Encryption Standard – стандарт шифрования данных) – еще один пример, но его можно вскрыть. Если вы пользуетесь чем–то, отличным от AES или 3DES, то почитайте в современной литературе по криптографии, считается ли выбранный вами шифр надежным.

Потоковые

шифры - это по сути дела генераторы случайных чисел. На вход такого алгоритма подается некий ключ, по которому генерируется очень длинная последовательность чисел, которая объединяется с шифруемыми данными операцией XOR. Единственным по–настоящему популярным потоковым шифром является RC4, хотя можно услышать хвалы и в адрес других алгоритмов. Но ни один из них не признан органами стандартизации, к тому же в настоящее время применять потоковые шифры вообще бессмысленно, так как вы при этом жертвуете безопасностью в обмен на небольшое повышение производительности, которое вам, скорее всего, не нужно. Если все–таки в вашем приложении потоковый шифр необходим, поинтересуйтесь в литературе, какого рода проблемы возможны. Например, если вы вопреки нашему предостережению настаиваете на применении шифра RC4, убедитесь, что он используется в соответствии со сложившейся проверенной практикой. Но, вообще говоря, лучше пользоваться блочным шифром в режиме имитации потокового шифра (см. ниже);

□ если используется блочный шифр, проверьте, какой выбран «режим работы». Самое простое – разбить сообщение на блоки и шифровать каждый блок отдельно. Это так называемый «режим электронной кодовой книги» (ЕСВ). Но в общем случае он небезопасен. Есть целый ряд других режимов, которые считаются более стойкими, в том числе и некоторые новые, обеспечивающие и конфиденциальность, и аутентификацию сообщений. Прежде всего речь идет о режимах GCM и ССМ. Существуют также классические режимы СВС, CFB, OFB и CTR, которые не поддерживают аутентификацию. Причин для использования их при создании нового приложения нет, зато недостатков масса. Например, вам придется разработать собственную схему аутентификации сообщений.

Примечание. В академических кругах рассматриваются десятки новых криптографических режимов, обеспечивающих как шифрование, так и аутентификацию, но лишь два из них официально признаны: ССМ и GCM. Тот и другой одобрены IETF для применения в протоколах IPSec. Режим ССМ вошел в новый стандарт безопасности беспроводных сетей 802.1 li. Режим GCM нашел применение в новом стандарте безопасности канального уровня 802.1ае; он самый современный и больше подходит для приложений, требующих высокого быстродействия. Оба режима пригодны и для приложений общего назначения.

□ иногда режим ЕСВ или потоковый шифр применяются лишь для того, чтобы избежать каскадных ошибок. Это самообман, поскольку если аутентификация не срабатывает, то вы никогда не можете быть уверены, в чем причина: в ошибке или в атаке. И на практике это почти всегда оказывается атака. Лучше уж разбить сообщение на более мелкие фрагменты, которые аутентифицируются по отдельности. Кроме того, многие другие режимы блочных шифров, например OFB, CTR, CGM и ССМ, с точки зрения распространения ошибок ведут себя точно так же, как режим ЕСВ и потоковые шифры;

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

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

При обсуждении других грехов мы еще будем говорить о надлежащих механизмах начальной аутентификации. Что же касается аутентификации в ходе сеанса, то имейте в виду следующие рекомендации:

□ как и в случае блочных шифров, убедитесь, что аутентифицируется каждое сообщение и что принимающая сторона проверяет это. Если проверка не прошла, сообщение должно быть отброшено;

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

известный алгоритм формирования кода аутентификации сообщения (MAC). К последним в первую очередь относятся СМАС (Cipher MAC, стандартизованный NIST метод на основе блочного шифра и прежде всего AES) и НМАС (применяемый совместно с хорошо известными функциями хэширования, в частности MD5 или функциями семейства SHA);

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

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

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

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

Тестирование

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

В ходе тестирования также легко понять, зашифрованы ли данные по протоколу SSL. Для обнаружения трафика, зашифрованного по SSL/TLS, можно применить утилиту ssldump (www.rfm.com/ssldump/).

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

Примеры из реальной жизни

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

TCP/IP

Протокол Internet Protocol (IP), а также построенные поверх него протоколы TCP и UDP не предоставляют никаких гарантий безопасности: ни конфиденциальности, ни аутентификации сообщений. В протоколе TCP вычисляются некоторые контрольные суммы для обеспечения целостности данных, но они не являются криптографически стойкими и легко могут быть взломаны.

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

Протоколы электронной почты

Электронная почта – это еще один пример протоколов, в которых традиционно отсутствует защита передаваемых данных. Сейчас существуют дополненные SSL версии протоколов SMTP, РОРЗ и IMAP, но применяются они редко и не всегда поддерживаются популярными почтовыми клиентами, хотя в некоторых из них реализованы и шифрование, и аутентификация, по крайней мере для внутренней почты. Часто можно включить в сеть анализатор протоколов и читать почту своего коллеги.

Это следует иметь в виду при использовании электронной почты для рассылки паролей вновь создаваемых учетных записей. Нередко пользователь, забывший пароль, щелкает по кнопке на Web–сайте и получает в ответ пароль по почте (часто новый временный). Оно бы и неплохо, если бы почта была безопасной.