Защита от хакеров корпоративных сетей - [9]

Проблема состоит в том, как узнать, с каким компьютером вы обменялись ключами. Вы могли установить соединение именно с тем компьютером, с которым вы и хотели осуществить обмен, так и со злоумышленником, ожидающим ваших действий по установке соединения, для того чтобы попытаться подменить IP-адрес компьютера, с которым вы соединяетесь, на свой. Единственный способ удостовериться в факте соединения с требуемым компьютером состоит в наличии на обоих компьютерах порции информации, которая позволила бы удостовериться в идентичности друг друга. Как это осуществить? Сразу приходит на ум пара методов. Во-первых, можно воспользоваться открытыми ключами, распространяемыми сертификационными центрами в Интернете. Во-вторых, можно использовать разделяемый секретный ключ или средства аутентификации протокола защищенных сокетов SSL, гарантирующего безопасную передачу данных по сети в результате комбинирования криптографической системы с открытым ключом и блочного шифрования данных. Конечно, все перечисленное является разделяемыми порциями информации, необходимой для проверки отправителя информации.

Отсюда следует необходимость решения задачи управления ключами, поэтому исследуем некоторые аспекты этого процесса, ответив на следующие вопросы. Как переслать ключи туда, где они необходимы? Защищен ли маршрут распространения ключей от злоумышленника, готового к атаке типа «злоумышленник посередине» (man-in-the-middle – MITM)? Какие затраты ресурсов необходимы и насколько оправдано их использование по отношению к ценности защищаемой информации? Участвует ли доверенное лицо в обмене ключей? Может ли оно быть атаковано? Какие методы используются для обмена ключей и насколько они уязвимы?

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

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

Давайте проанализируем часть документации, посвященной обмену общедоступными ключами, для того чтобы получить представление о реализации одного из способов их обмена. Подробнее познакомиться с документацией можно в Интернете: www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/secur_c/scprt4/scencryp.htm#xtocid211509.

Это – документ компании Cisco Systems, Inc., который описывает, помимо всего прочего, как обмениваться ключами стандарта цифровой подписи DSS. DSS – стандарт открытых/секретных ключей (public/private key standard), который Cisco использует для аутентификации одноранговых маршрутизаторов. Шифрование с использованием открытых/секретных ключей обычно считается слишком медленным для шифрования в реальном масштабе времени, поэтому для обмена информацией применяются симметричные сеансовые криптографические ключи (типа ключей DES или 3DES алгоритмов). DES – американский правительственный стандарт алгоритма шифрования, принятый в 70-х годах. 3DES – улучшенная версия алгоритма DES, связывающая вместе три отдельных выполнения алгоритма DES для двукратного или трехкратного, в зависимости от реализации, повышения криптостойкости алгоритма. Для успешной работы по описываемой схеме у каждого маршрутизатора должен быть правильный открытый ключ другого маршрутизатора. Если в случае атаки типа MITM злоумышленнику удастся обмануть каждый маршрутизатор, подсунув свой ключ вместо открытого ключа другого маршрутизатора, то сначала он сможет узнать все ключи сессии, а затем контролировать любой трафик сети.

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

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

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