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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

□ подайте ключ на вход односторонней функции хэширования, например SHА1, а результат используйте в качестве ключа для RC4. Это рекомендованный подход. Недавние атаки на SHA1 не оказывают на него практического влияния.

Еще один тонкий аспект конфиденциальности – в том, что есть такие параноики, которым подавай безопасность в режиме «точка–точка». Например, сторонники неприкосновенности частной жизни обычно не пользуются интернет–пейджерами, даже если они передают сообщения на сервер в зашифрованном виде, поскольку сервер – это излишняя слабая точка, не только уязвимая для хакеров, но и могущая стать основанием для вызова в суд. Ну и так далее. Большая часть людей хотели бы защитить свою частную жизнь, хотя при определенных обстоятельствах готовы пожертвовать безопасностью. А коли так, то желательно обеспечить конфиденциальность данных, поскольку в противном случае возможна «кража личности». На наших глазах слабозащищенные системы, раскрывающие данные о пользователях, становятся подотчетными. Например, всякая фирма, работающая в Калифорнии, обязана известить своих клиентов в случае, когда знает о возможной компрометации данных, которые пользователи считают приватными. Через некоторое время такие требования могут быть дополнены денежными штрафами и другими юридическими последствиями. Иногда все–таки возникает потребность сделать что–то простенькое на базе криптографии с симметричным ключом, поскольку это быстро и куда менее накладно, чем использование SSL. Но мы не рекомендуем так поступать, ибо уж слишком много капканов на этой дороге. Само шифрование не вызывает никаких сложностей, если пользоваться правильными криптографическими примитивами, но вот управление ключами может стать кошмаром. К примеру, как безопасно хранить ключи и при этом сохранить возможность быстро переместить учетную запись на другую машину? Если вы склоняетесь к паролю, то тут вас подстерегают серьезные опасности, так как при использовании одной лишь криптографии с симметричным ключом пароль можно вскрыть с помощью полного перебора.Если вы решили выбрать «симметричный путь», несмотря на все наши увещевания о том, что лучше бы обратиться к готовому решению, то прочтите хотя бы следующие советы:□ пользуйтесь проверенным блочным шифром. Мы настоятельно рекомендуем AES и ключ длиной не менее 128 битов, какой бы алгоритм вы ни выбрали;□ применяйте блочный шифр в режиме работы, обеспечивающем аутентификацию и целостность сообщений, например GCM или ССМ. Если вы пользуетесь библиотекой криптографических функций, в которой эти режимы не поддерживаются, нетрудно достать подходящую (см. раздел «Другие ресурсы»). Можно вместо этого воспользоваться сочетанием двух других конструкций: режима CTR с СМАС–или НМАС–кодом;□ применяйте аутентификацию по всему сообщению, даже если данные не нуждаются в шифровании. В режимах GCM и ССМ сообщения можно аутентифицировать, не шифруя;□ на принимающей стороне всегда проверяйте аутентичность сообщения и только потом делайте что–то с содержащимися в нем данными;□ кроме того, на принимающей стороне проверяйте, что сообщение не было воспроизведено (а если это так, отбрасывайте его). Если сообщение аутентично, то для этого достаточно сравнить его номер с номером последнего пришедшего сообщения; номера должны монотонно возрастать.

Кстати говоря, чтобы доказать третьей стороне, что сообщение было отправлено конкретным лицом, можно воспользоваться цифровой подписью, но делайте это только в случае необходимости и в дополнение, а не вместо механизма аутентификации сообщений. В системах Windows надлежащую проверку целостности данных на уровне пакетов и конфиденциальность обеспечат вызовы RPC/DCOM, если при создании сеанса вы измените один параметр. Еще раз подчеркнем, что лучше пользоваться готовыми решениями. Добавим, что SSPI API позволяет сравнительно легко организовать передачу данных по протоколам HTTPS или Kerberos, которые гарантируют аутентификацию как клиента, так и сервера, а заодно целостность и конфиденциальность пакетов.