Данный вид атак — “Злоумышленник-посредник” (англ. man-in-the-middle) породил целое новое направление в электронном бизнесе, а именно, создание центров сертификации (СА — certification authority). Для понимания сущности атаки необходимо представление о функционировании криптографической системы с открытыми ключами. Подробные системы с открытыми ключами (или как они еще называются, асимметричные системы) описаны в части V, посвященной криптографии, в данной главе рассказ о них пойдет в общих чертах.
Для успешного защищенного взаимодействия пары пользователей А и Б каждый из них должен сгенерировать пару криптографических ключей — открытый и закрытый, одним из которых можно только шифровать, другим — только дешифровать. Открытый ключ, в отличие от закрытого, не требует сохранения в конфиденциальности и отсылается удаленному адресату, т. е. А посылает свой открытый ключ (OA) Б, а Б посылает свой открытый ключ (ОБ) А. Теперь, если А хочет отправить Б зашифрованное сообщение, то он шифрует его открытым ключом ОБ. Зашифровать такое сообщение может кто угодно, поскольку открытый ключ известен всем желающим. Но дешифровать сообщение сможет только обладатель закрытого ключа Б (ЗБ), т. е. сам Б. Идентификацию отправителя, зашифровавшего сообщение, можно производить по второй паре ключей, т. е. А может вставить в сообщение для Б некий элемент, зашифрованный закрытым ключом А (ЗА), а так как у Б есть открытый ключ А, то он сможет дешифровать этот элемент и проверить, что он был действительно зашифрован обладателем секретного ключа А, т. е. самим А (на этом принципе работает механизм электронной цифровой подписи — ЭЦП).
Данный защищенный механизм работает на основе убеждения, что открытый и закрытый ключи (OA и ЗА) принадлежит именно А, а открытый и закрытый ключи (ОБ и ЗБ) принадлежит именно Б. Однако иногда абоненты защищенной связи могут быть введены в заблуждение. Было уже отмечено, что открытые ключи не требуют сохранения их в конфиденциальности, и это действительно так. Однако отправление открытых ключей адресатам без доверенного контроля пути следования как раз и приводит к возможности реализации описываемой атаки.
Предположим, что между А и Б имеется шлюз, управляемый злоумышленником — 3. Тогда при подготовке к общению в защищенном режиме (или при очередной смене ключей), когда А направляет Б свой открытый ключ, 3 перехватывает его и сохраняет у себя. Вместо этого он отправляет Б открытый ключ из пары, сгенерированной им самим, т. е. открытый ключ OA’. Когда Б направляет А свой открытый ключ, 3 также перехватывает его и сохраняет у себя. Вместо этого он отправляет А открытый ключ из другой пары сгенерированной им самим, т. е. открытый ключ ОБ’. В общем случае пары и ключи OA’ и ОБ’ могут совпадать — это не принципиально. Важно то, что теперь злоумышленник выступает прозрачным посредником в защищенном обмене информацией между А и Б, которые общаются друг с другом, не подозревая, что на самом деле их обмен данными контролируется. Для предотвращения атак подобного класса необходимо обеспечение доверенной доставки открытых ключей абонентам. Если А и Б находятся в личном контакте или имеют альтернативный доверенный канал обмена информацией, то задача решается достаточно просто: Но если они находятся в разных концах света и общаются только с помощью Интернета, задача доверенной доставки становится нетривиальной.
Организации, занимающиеся сертификацией открытых ключей — СА, обеспечивают установку своей цифровой подписи на набор параметров пользователя сети, включающих его идентификационные данные и открытый ключ — т. н. цифровой сертификат. После этого сертификат с открытым ключом может быть свободно распространен без опасности подмены. Вопрос об удостоверении полномочий данного абонента в получении сертификата решаются, например, таким образом: пользователь устанавливает защищенную сессию связи с Веб-сервером СА, на сервере генерируется пара ключей, причем на сервере сохраняется только копия открытого ключа, а секретный ключ сохраняется только клиентом. После этого СА дополнительно альтернативными методами (факсом, обычной почтой и т. д.) получает подтверждение авторизованное™ пользователя, сгенерировавшего ключи, формирует для него сертификат, отсылает пользователю и сохраняет копию сертификата у себя для дальнейшего использования. Иногда СА сохраняет у себя и секретный ключ пользователя на случай его утери, но это уже предмет договорных отношений между самим пользователем и СА.