8.9.3. Аутентификация с помощью центра распространения ключей
Итак, установление общего секретного ключа с незнакомцем почти удалась. Хотя, вполне возможно, что результат не стоит усилий. Чтобы общаться с n людьми, нужно хранить n ключей. Для людей, чей круг общения широк, хранение ключей может превратиться в серьезную проблему, особенно если все эти ключи придется хранить на физических токенах.
Другой подход состоит в том, чтобы ввести в систему доверенный Центр распространения ключей (Key Distribution Center, KDC). Им может стать, к примеру, банк или какой-либо государственный орган. При такой схеме у каждого пользователя всего один ключ, общий с KDC. Через KDC проходят операции с сеансовыми ключами и ключами аутентификации. На илл. 8.36 представлена простейшая схема такого протокола аутентификации, где присутствуют две стороны и доверенный KDC.
Илл. 8.36. Первая попытка реализации протокола аутентификации на основе KDC
У этого протокола достаточно простой принцип действия: Алиса выбирает ключ сеанса KS и уведомляет KDC о том, что она хочет поговорить с Бобом, используя KS. Это сообщение шифруется секретным ключом KA, который известен только Алисе и KDC. KDC расшифровывает это сообщение и извлекает из него идентификатор личности Боба и ключ сеанса. Затем он формирует новое сообщение, которое содержит идентификатор личности Алисы и ключ сеанса, и отправляет его Бобу. Это сообщение зашифровывается секретным ключом KB (он известен только Бобу и KDC). Расшифровав сообщение, Боб понимает, что Алиса желает с ним поговорить, и узнаёт, какой ключ она хочет использовать.
Аутентификация в данном случае происходит сама собой. KDC знает, что сообщение 1 пришло от Алисы, так как больше никто не может зашифровать его секретным ключом Алисы. Аналогично, Боб знает, что сообщение 2 пришло от KDC, ведь кроме него их общий секретный ключ никому не известен.
К сожалению, у этого протокола есть серьезный недостаток. Труди нужны деньги, и она предлагает Алисе некую легальную услугу на выгодных условиях. Алиса соглашается, и Труди получает работу. Выполнив ее, она вежливо просит Алису оплатить услугу банковским переводом. Алиса устанавливает ключ сеанса со своим менеджером Бобом и отправляет ему сообщение с просьбой перевести деньги на счет Труди.
Тем временем Труди возвращается к своим темным делам. Она копирует сообщение 2 (см. илл. 8.36) и запрос на перевод денег, следующий за ним. Затем она воспроизводит оба сообщения для Боба. Боб получает их и думает: «Должно быть, Алиса снова наняла Труди. Похоже, она хорошо справляется с работой». Боб перечисляет еще столько же денег со счета Алисы на счет Труди. Получив пятидесятый запрос на перевод, Боб выбегает из офиса, чтобы найти Труди и предложить ей кредит, чтобы она могла расширить свой чрезвычайно успешный бизнес. Атаки такого рода называют атаками повторного воспроизведения (replay attack).
Существует несколько способов борьбы с ними. Первый заключается в том, чтобы поместить в каждое сообщение временную метку. Это позволяет отбрасывать все устаревшие сообщения. Однако системные часы в сети невозможно точно синхронизировать, поэтому нужен определенный срок годности временной метки. Труди может обмануть протокол, отправив повторное сообщение во время этого интервала.
Второе решение сводится к добавлению в сообщение однократно используемого числа — нонса. Каждая сторона должна запоминать все предыдущие нонсы и отвергать любое сообщение, содержащее использованный ранее нонс. При этом нонсы должны храниться вечно, иначе Труди попытается воспроизвести сообщение пятилетней давности. Кроме того, если компьютер потеряет список нонсов в результате сбоя, он снова станет уязвимым к атакам повторного воспроизведения. Можно комбинировать временные метки и нонсы, чтобы ограничить срок хранения последних, но это сильно усложняет протокол.
Более продвинутый метод взаимной аутентификации состоит в использовании многостороннего запросно-ответного протокола. Хорошо известный пример — протокол аутентификации Нидхема — Шредера (Needham — Schroeder authentication protocol) (Needham and Schroeder, 1978). Один из его вариантов показан на илл. 8.37.
Илл. 8.37. Протокол аутентификации Нидхема — Шредера
Работа протокола начинается с того, что Алиса заявляет KDC о своем желании поговорить с Бобом. Это сообщение содержит в качестве нонса большое случайно выбранное число RA. KDC отсылает обратно сообщение 2 со случайным числом Алисы, ключом сеанса и удостоверением (ticket)44, которое она может передать Бобу. Цель отправки случайного числа 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 and Sacco, 1981). На этот раз Труди может украсть деньги со счета Алисы, даже не выполнив никаких услуг.
Позднее Нидхем и Шредер опубликовали протокол для исправления этой ситуации (Needham and Shroeder, 1987). В том же выпуске журнала Отуэй и Рис (Otway and Rees, 1987) представили свой протокол, решающий проблему более коротким путем. На илл. 8.38 показан слегка видоизмененный протокол Отуэя — Риса (Otway — Rees protocol).
В протоколе Отуэя — Риса Алиса прежде всего формирует пару случайных чисел: R, необходимое в качестве общего идентификатора, и RA, которое Алиса будет использовать в качестве запроса для Боба. Получив это сообщение, Боб формирует новое сообщение из зашифрованной части сообщения Алисы и аналогичной собственной части. Обе части сообщения, зашифрованные ключами KA и KB, идентифицируют Алису и Боба: в них содержится общий идентификатор и запрос.
Илл. 8.38. Протокол аутентификации Отуэя — Риса (в слегка упрощенном виде)
KDC сравнивает общие идентификаторы R в обеих частях сообщения. Они могут не совпадать, если Труди подменила R в сообщении 1 или заменила часть сообщения 2. Если оба числа R совпадают, KDC считает сообщение от Боба достоверным. Затем он формирует ключ сеанса KS и шифрует его дважды: для Алисы и для Боба. Каждое сообщение содержит случайное число получателя как доказательство того, что эти сообщения сгенерировал KDC, а не Труди. К этому моменту Алиса и Боб обладают одним и тем же ключом сеанса и могут начать коммуникацию. После первого же обмена данными они увидят, что обладают одинаковыми копиями ключа сеанса KS, и процесс аутентификации можно будет считать завершенным.
8.9.4. Аутентификация при помощи протокола Kerberos
Во многих реальных системах (включая Windows) применяется протокол аутентификации Kerberos, основанный на варианте протокола Нидхема — Шредера. Он назван по имени трехглавого пса из древнегреческой мифологии Кербера (или Цербера), охранявшего выход из царства Аида. Kerberos был разработан в Массачусетском технологическом институте, чтобы предоставить пользователям рабочих станций надежный доступ к сетевым ресурсам. Его основное отличие от протокола Нидхема — Шредера — предположение о довольно хорошей синхронизации всех часов в сети. Было разработано несколько версий протокола. Версия V5 наиболее широко применяется в промышленности и описана в RFC 4120. От более ранней версии V4 окончательно отказались, после того как в ней были найдены серьезные недостатки (Юй и др.; Yu et al., 2004). V5 усовершенствована по сравнению с V4 — внесено множество мелких изменений и улучшены некоторые характеристики. Например, протокол больше не опирается на устаревший DES. Более подробные сведения можно найти в книге Суда (Sood, 2012).
В работе Kerberos помимо Алисы (клиентской рабочей станции) принимают участие еще три сервера:
1. Сервер аутентификации (Authentication Server, AS): проверяет личность пользователей при входе в систему.
2. Сервер выдачи удостоверений (Ticket Granting Server, TGS): предоставляет удостоверения, подтверждающие полномочия объекта.
3. Сервер, предоставляющий услуги Алисе (Боб).
AS похож на KDC тем, что у него есть общий секретный пароль для каждого пользователя. Работа TGS состоит в выдаче удостоверений, убеждающих другие серверы в том, что обладатель удостоверения действительно является тем, за кого себя выдает.
Чтобы начать сеанс, Алиса усаживается за произвольную публичную рабочую станцию и вводит свое имя. Рабочая станция передает введенное имя и название TGS открытым текстом на AS (сообщение 1 на илл. 8.39). В ответ она получает ключ сеанса и удостоверение K