Другой подход состоит в организации доверительного центра распространения ключей (KDC, key distribution center). При такой схеме у каждого пользователя всего один ключ, общий с KDC. Операции с ключами аутентификации и сеансовыми ключами проходят через KDC. Простейший протокол аутентификации с помощью центра распространения ключей, включающий две стороны и доверенный KDC, изображен на рис. 8.35.
Рис. 8.35. Первая попытка протокола аутентификации с помощью KDC-центра
Идея, лежащая в основе протокола, проста: Алиса выбирает ключ сеанса, KS, и заявляет KDC, что она желает поговорить с Бобом при помощи ключа KS. Это сообщение шифруется секретным ключом KA, которым совместно владеют только Алиса и центр распространения ключей. Центр распространения ключей расшифровывает это сообщение и извлекает из него идентификатор личности Боба и ключ сеанса. Затем он формирует новое сообщение, содержащее идентификатор личности Алисы и ключ сеанса, и посылает его Бобу. Это сообщение зашифровывается ключом KB — секретным ключом, общим для Боба и центра распространения ключей. Расшифровав это сообщение, Боб узнает, что Алиса желает с ним поговорить и какой ключ она хочет использовать.
Аутентификация в данном случае происходит сама собой. KDC знает, что сообщение 1 пришло от Алисы, так как больше никто не может зашифровать его секретным ключом Алисы. Аналогично, Боб знает, что сообщение 2 пришло от KDC, так как кроме него их общий секретный ключ никому не известен.
К сожалению, этот протокол содержит серьезную ошибку. Труди нужны деньги, поэтому она придумывает некую легальную услугу, которую она могла бы выполнить для Алисы. Затем Труди делает Алисе заманчивое предложение и получает эту работу. Выполнив ее, Труди вежливо предлагает Алисе оплатить услуги, переведя деньги на ее банковский счет. Чтобы оплатить работу, Алиса устанавливает ключ сеанса со своим банкиром Бобом. Затем она посылает Бобу сообщение с просьбой перевести деньги на счет Труди.
Тем временем Труди возвращается к своим темным делам. Она копирует сообщение 2 (см. рис. 8.35) и запрос на перевод денег, следующий за ним. Затем она воспроизводит оба сообщения для Боба. Боб получает их и думает: «Должно быть, Алиса снова наняла Труди. Похоже, она хорошо справляется с работой». Боб перечисляет еще столько же денег со счета Алисы на счет Труди. Получив пятидесятый запрос на перевод денег, Боб выбегает из офиса, чтобы найти Труди и предложить ей большую ссуду, чтобы она могла расширить свой чрезвычайно успешный бизнес. Подобная проблема получила название атаки повторным воспроизведением (replay attack).
Существует несколько решений этой проблемы. Первое решение состоит в помещении в каждое сообщение временного штампа. Все устаревшие сообщения просто игнорируются. Беда здесь в том, что системные часы в сети синхронизировать с большой степенью точности невозможно, поэтому должен существовать какой-то срок годности временного штампа. Труди может обмануть протокол, послав повторное сообщение во время этого интервала.
Второе решение заключается в помещении в сообщение уникального номера, обычно называемого нонсом (см. nonce в разделе 8.6.4.). Каждая сторона должна запоминать все предыдущие нонсы и отвергать любое сообщение, содержащее использованный ранее нонс. Однако нонсы должны храниться вечно, иначе Труди попытается воспроизвести сообщение пятилетней давности. Кроме того, если машина потеряет список нонсов в результате сбоя, она снова станет уязвимой к атакам повторным воспроизведением. Можно комбинировать временные штампы и нонсы, чтобы ограничить срок хранения нонсов, но так или иначе, протокол должен быть значительно усложнен.
Более сложный метод аутентификации состоит в использовании многостороннего протокола оклик-отзыв. Хорошо известным примером такого протокола является протокол аутентификации Нидхэма-Шредера (Needham—Schroeder authentication protocol) (Needham-Schroeder, 1978), один из вариантов которого показан на рис. 8.36.
Работа протокола начинается с того, что Алиса сообщает KDC, что она желает поговорить с Бобом. Это сообщение содержит в качестве нонса большое случайное число Ra. Центр распространения ключей посылает обратно сообщение 2, содержащее случайное число Алисы, ключ сеанса и так называемый билет, который она может послать Бобу. Цель посылки случайного числа RA состоит в том, чтобы убедить Алису, что сообщение 2 является свежим, а не повторно воспроизведенным. Идентификатор Боба также помещается в сообщение 2, на случай, если злоумышленник (Труди) вздумает заменить его идентификатор на свой в сообщении 1, так чтобы KDC зашифровал билет в конце сообщения 2 ключом KT (ключ Труди), вместо KB. Билет, зашифрованный ключом KB, помещается внутри зашифрованного сообщения, чтобы злоумышленник не смог заменить его чем-либо другим, пока сообщение 2 добирается до Алисы.
Затем Алиса посылает билет Бобу вместе с новым случайным числом RA2, зашифрованным ключом сеанса KS. В сообщении 4 Боб посылает обратно KS(RA2 - 1), чтобы доказать Алисе, что она разговаривает с настоящим Бобом. Отсылать обратно просто KS(RA2) бессмысленно, так как это число могло быть украдено злоумышленником из сообщения 3.
Получив сообщение 4, Алиса убеждается, что разговаривает с Бобом и что до сих пор не было использовано повторных сообщений. Между отправкой случайного числа RA2 и получением ответа на него в виде KS(RA2 - 1) проходит довольно короткий промежуток времени. Цель сообщения 5 — убедить Боба, что он действительно разговаривает с Алисой, и что в этом сеансе связи также отсутствуют повторно воспроизведенные данные. Возможность атаки с помощью повторного воспроизведения ранее записанной информации исключается этим протоколом благодаря тому, что каждая сторона формирует оклик другой стороны и получает на него отзыв.
Несмотря на всю кажущуюся солидность протокола, в нем, тем не менее, имеется небольшое слабое место. Если злоумышленнику удастся каким-либо способом раздобыть старый ключ сеанса KS, он сможет инициировать новый сеанс с Бобом, повторно воспроизведя сообщение 3 с использованием скомпрометированного ключа, и выдать себя за Алису (Denning и Sacco, 1981). На этот раз злоумышленник может украсть деньги со счета Алисы, даже не выполнив никаких услуг.
Позднее Нидхэм и Шредер опубликовали протокол, решающий эту проблему (Needham и Shroeder, 1987). В том же выпуске того же журнала Отуэй (Otway) и Рис (Rees) также опубликовали протокол, решающий эту проблему более коротким путем. На рис. 8.37 показан слегка видоизмененный протокол Отуэя—Риса.
В протоколе Отуэя—Риса Алиса начинает с формирования пары случайных номеров: R, который будет использоваться в качестве общего идентификатора, и RA, который Алиса будет использовать в качестве оклика Боба. Получив это сообщение, Боб формирует новое сообщение из зашифрованной части сообщения Алисы и аналогичной собственной части. Обе части сообщения, зашифрованные ключами KA и KB, идентифицируют Алису и Боба, содержат общий идентификатор и оклики.
Центр распространения ключей проверяет, совпадают ли общие идентификаторы R в обеих частях сообщения. Они могут не совпадать, если злоумышленник подменил R в сообщении 1 или заменил часть сообщения 2. Если оба общих идентификатора R совпадают, KDC считает сообщение, полученное от Боба, достоверным. Затем он формирует ключ сеанса KS и отправляет его Алисе и Бобу, зашифровав ключ сеанса ключами Алисы и Боба. Каждое сообщение также содержит случайное число получателя, в доказательство того, что эти сообщения посланы KDC, а не злоумышленником. К этому моменту Алиса и Боб обладают одним и тем же ключом сеанса и могут начать обмен информацией. После первого же обмена данными они увидят, что обладают одинаковыми копиями ключа сеанса KS, на чем процесс аутентификации можно будет считать завершенным.