Читаем без скачивания 19 смертных грехов, угрожающих безопасности программ - Дэвид Лебланк

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

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

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

TCP/IP

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

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

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

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

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

В общем и целом это, может быть, и не самый большой риск в системе, но нельзя не признать, что существуют более эффективные способы переустановить пароль. Неплохая альтернатива – это метод «секретного вопроса», но понадобится довольно внушительный перечень необычных вопросов. А узнать девичью фамилию матери жертвы совсем нетрудно. Другой пример: поклонники телевизионных реалити–шоу узнали кличку домашнего любимца Пэрис Хилтон, и, наверное, именно так кто–то взломал ее учетную запись на сайте T–Mobile.

Протокол E*Trade

Первоначально данные шифровались в этом протоколе путем выполнения XOR с фиксированным значением. Легко реализовать, но столь же легко и взломать. Даже любитель сможет понять, что происходит, собрав и проанализировав достаточный объем данных, передаваемых по сети. Не займет много времени вычислить так называемый «ключ шифра», после чего вся схема оказывается вскрытой. И что еще хуже, в этой схеме даже не делается попытки реализовать аутентификацию сообщений в ходе сеанса, поэтому опытный противник сможет провести практически любую из упомянутых в этой главе атак.

Искупление греха

Вообще говоря, мы рекомендуем шифровать весь сетевой трафик по протоколу SSL/TLS, если это возможно. Можно также пользоваться такими системами, как Kerberos. Если вы решите остановиться на SSL, прислушайтесь к нашим советам в грехе 10. Иногда люди не ожидают, что в их сеть будет встроен SSL, особенно если пользуются программами, которые этот протокол не поддерживают. Но существуют SSL–прокси, например Stunnel. Избежать такого рода проблем можно также, развернув IPSec или иную технологию организации VPN.

Иногда включить SSL/TLS не представляется возможным. Например, если вы вынуждены обмениваться данными с не контролируемыми вами серверами или клиентами, которые не поддерживают эти протоколы. В таком случае вам решать, идти на риск или нет.

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

Рекомендации низкого уровня

Ладно, вы не хотите последовать нашей рекомендации и воспользоваться высокоуровневой абстракцией типа SSL/TLS или Kerberos. Вернемся к базовым сервисам сетевой безопасности: конфиденциальности, начальной и последующей аутентификации.

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

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

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

Кроме того, механизм как начальной, так и последующей аутентификации может стать причиной отказа от обслуживания, если в них применяется криптография с открытым ключом. Например, если вы снабжаете отдельные сообщения PGP–подписью, то противник может без ощутимых затрат послать вам множество сообщений с некорректными подписями и тем самым «подвесить» процессор. А если работает какой–то механизм ограничения пропускной способности, то может оказаться заблокированным законный трафик.

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

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

У сервиса конфиденциальности тоже есть свои тонкости, одни из них – криптографического, другие – практического характера. Например, иногда небезопасно параллельно шифровать и аутентифицировать одни и те же данные или даже шифровать уже аутентифицированные данные. Единственная общая безопасная стратегия состоит в том, чтобы сначала шифровать данные, а потом уже аутентифицировать. Если конфиденциальность не слишком важна, то можно аутентифицировать незашифрованные данные.