Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ
Если какие–то сетевые соединения защищены, проверьте, работает ли защита, как задумано. Это может оказаться довольно сложно, поскольку требует глубоких знаний в области криптографии. Вот некоторые базовые рекомендации:
□ не занимайтесь реализацией криптографических решений самостоятельно. Пользуйтесь протоколом SSL или API на базе системы Kerberos, который Windows предоставляет в составе библиотек DCOM/RPC;
□ если вы не используете готового решения, то первым делом убедитесь в том, что конфиденциальность обеспечивается везде, где это необходимо. Обычно в программе не должно быть никаких путей, позволяющих отправить в сеть незашифрованные данные;
□ если основной поток данных шифруется с помощью пары ключей, то почти всегда наблюдается некое недопонимание. Криптография с открытыми ключами настолько неэффективна, что обычно используется лишь для шифрования случайных сеансовых ключей и необходимых для аутентификации данных, после чего эти ключи служат для симметричного шифрования. Если вы систематически применяете криптографию с открытыми ключами, то система легко может отказать в обслуживании из–за перегрузки. К тому же очень многое может пойти наперекосяк, особенно если длина открытого текста относительно велика. (Детали выходят за рамки данной книги, однако в разделе «Другие ресурсы» приведены ссылки на дополнительные источники информации.);
□ выясните, какой криптографический шифр применяется в системе. Это должен быть хорошо известный алгоритм, а не «самописное» произведение автора. Разработанные «на коленке» шифры применять нельзя. Это ошибка. Исправьте ее. Одобренные симметричные шифры бывают двух видов: блочные и потоковые;
□ шифры 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/).
Вообще говоря, понять, используется ли в программе хороший алгоритм, и при этом надлежащим образом, весьма трудно, особенно если вы тестируете черный ящик. Поэтому если вы хотите обрести полную уверенность (в том, что применяются проверенные режимы работы шифра, стойкий материал для ключей и т. д.), лучше прибегнуть к анализу кода.
