Аутентификация при помощи сертификатов
В том случае, когда пользователи имеют сертификатыоткрытых ключей, необходимость в ЦРК отпадает. Это не означает, что отпадает необходимость в доверии и третьих сторонах; просто доверенной третьей стороной становится УЦ.
Аутентификацию при помощи сертификатов обеспечивают несколько распространенных протоколов, в частности, наиболее известный и широко распространенный протокол SecureSocketLayer (SSL), который применяется практически в каждом web-браузере.
Помимо него применяются протоколы Transport LayerSecurity (TLS) [142], InternetKey Exchange (IKE)
[147], S/MIME[169], PGP и OpenPGP[149]. Каждый из них немного по-своему использует сертификаты, но основные принципы – одни и те же.
Рис. 2.5 иллюстрирует типичный обмен сообщениями при аутентификации на базе сертификатов, использующий цифровые подписи [70]. Обмен соответствует стандарту аутентификации субъектов на основе криптографии с открытыми ключами[117].
Во многих протоколах предусматривается, что клиент направляет запрос серверу для того, чтобы инициировать аутентификацию. Такой подход, характерный, например, для дополнений аутентификации и шифрования к протоколу Internet File TransferProtocol, гарантирует, что и пользователь, и сервер поддерживают один и тот же механизм аутентификации. Некоторые протоколы не требуют этого подготовительного шага.
Если серверВ поддерживает метод аутентификации, запрашиваемый пользователем А, то начинается обмен сообщениями. Сообщение Token ID уведомляет о том, что будет выполняться взаимная аутентификация, а также содержит номер версии протокола и идентификатор протокола.
Хотя этот идентификатор не обязателен, он намного упрощает процедуру и поэтому обычно используется. ПользовательА ожидает сообщение Token ВА1 от сервера В. Идентификатор протокола в Token ID позволяет пользователю А удостовериться, что серверВ отправляет ожидаемое сообщение. Token ВА1 состоит только из случайного числа ran B, это – своего рода запрос, корректным ответом должна быть цифровая подпись числа ran B.
ПользовательА подписывает ответ и отправляет свой сертификат ключа подписи, для того чтобы серверВ при помощи открытого ключа мог выполнить валидацию подписи.
ПользовательА подписывает последовательность из трех элементов: свой запросran A, запрос сервера ran B и имя сервера name B. Ran A – это запросА к серверу В, гарантирующий, что пользовательА подписывает не произвольное сообщение сервера В или другого субъекта, выдающего себя за серверВ.
Получив ответ Token АВ от пользователя А, серверВ проверяет, совпадает ли значениеran B с соответствующим значением в сообщении Token ВА1, а по значению name В устанавливает, действительно ли пользовательА желает пройти аутентификацию сервера В.
Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно.
В противном случае серверВ проверяет подлинность сертификата пользователя А и его цифровую подпись, если сертификат и подпись валидны, то аутентификация пользователя А сервером В прошла успешно.
Ответ сервера Token ВА2 состоит из заверенной цифровой подписью последовательности трех элементов: ran A, ran B и name A, где ran A – запрос, сгенерированный А, ran B – исходный запрос сервера В, а name A – имя пользователяА.
Получив ответ сервера, пользовательА убеждается, что ran A имеет то же самое значение, что и в сообщении Token АВ, а проверяя значениеname A – что серверВ намерен аутентифицировать именно его (пользователя А ).
Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае пользовательА проверяет подлинность сертификата сервера В и его цифровой подписи.
Итак, механизмы аутентификации при помощи сертификатов поддерживают аутентификацию в открытой сети, на многих удаленных серверах, и обеспечивают взаимную аутентификацию.
В отличие от системы Kerberos. протоколы аутентификации на базе сертификатов не требуют активного участия третьих сторон. Для успешной аутентификации должны быть доступны только пользователь и сервер.
Аутентификация с использованием хэш-функции
Для решения проблем аутентификации, связанных с неявными запросами, Лесли Лампорт [85] предложил использовать одноразовые пароли, генерируемые при помощи односторонней хэш-функции (
“Основные компоненты и сервисы PKI”
).
Эта идея нашла воплощение в системе одноразовых паролей S/Key One-Time Password System [136]. Система S/Key, применяя одностороннюю хэш-функцию, генерирует последовательность одноразовых паролей.
Начальное значение хэш-кода вычисляется путем хэширования секретного пароля пользователя, который сцеплен с несекретным случайным числом, выработанным генератором случайных чисел.
Секретный пароль должен иметь длину не менее 8 символов.
Последовательность одноразовых паролей формируется в результате многократного применения секретной хэш-функции (от 500 до 1000 ).
То есть первый одноразовый пароль генерируется путем применения хэш-функции к секретному паролю пользователя определенное количество раз ( N ), следующий одноразовый пароль – путем применения хэш-функции к секретному паролю пользователя только (N – 1) раз и т.д.
Субъект, получивший одноразовый пароль путем прослушивания сети, не в состоянии сгенерировать следующий пароль, так как для этого требуется просчитать хэш-функцию в обратном направлении.
Это не может быть сделано без знания секретного пароля, с которого начинались итерации. Поскольку в системе S/Key секретный пароль пользователя никогда не передается по сети и не хранится ни сервером, ни клиентом, риск хищения отсутствует.
S/Key – это система “клиент-сервер”. Сервер генерирует отклик после получения от клиента login-запроса. Отклик сервера содержит номер итерации и случайное число. В ответ пользователь генерирует соответствующий одноразовый пароль, используя комбинацию своего секретного пароля, номера итерации и случайного числа, и отправляет его серверу. Первый одноразовый пароль из списка итераций сохраняется на шаге инициализации.
Сервер может и сам формировать S/Key -запрос, состоящий из номера итерации и случайного числа. Тогда, используя номер итерации и случайное число вместе со своим секретным паролем, пользователь вычисляет (или преобразует) одноразовый пароль.
Сервер может не формировать запрос, если пользователь сохраняет номер итерации и случайное число после каждой своей успешной попытки аутентификации. Для хранения этих значений могут использоваться портативные устройства типа смарт-карт или карманных персональных компьютеров.
Итак, пользователь передает для проверки на сервер одноразовый пароль. Сервер сначала сохраняет копию этого одноразового пароля, а затем применяет к нему хэш-функцию.
Если результат не совпадает с копией одноразового пароля, полученного во время последней удачной попытки аутентификации пользователя, то запрос отвергается. Если совпадает, тогда клиентская запись в файле паролей обновляется копией полученного от пользователя одноразового пароля, которая была сохранена перед вычислением хэш-функции.
Обновление пароля обеспечивает возможность проверки следующего одноразового пароля. Так как следующий одноразовый пароль
получается путем вычисления хэш-функции на один раз меньше, чем для предыдущего пароля, то получить предыдущий пароль можно, применив хэш-функцию к следующему паролю на один раз больше.
После успешной аутентификации пользователь получает доступ к серверу, но при следующей попытке аутентификации он должен генерировать новый одноразовый пароль. Использование случайных чисел, создаваемых генератором случайных чисел, позволяет клиенту выполнять аутентификацию на многих серверах при помощи одного секретного пароля, при этом каждому серверу соответствует свое случайное число.
Обратная процедура, то есть получение из предыдущего пароля следующего пароля невозможна без знания начального одноразового пароля пользователя. Таким образом, ни серверу, ни клиенту нет необходимости хранить секретный пароль пользователя.
На сервере в файле паролей сохраняется только копия последнего одноразового пароля, которого достаточно для аутентификации пользователя при следующей попытке. Секретный пароль известен только самому пользователю.
Так как количество итераций вычисления хэш-функции, выполняемого пользователем, уменьшается каждый раз на единицу, при обнулении счетчика итераций пользователь для доступа к серверу должен повторно инициализировать систему.
Повторная инициализация сопровождается изменением номера итерации и случайного числа. Это операция идентична нормальной аутентификации, за исключением того, что одноразовый пароль, полученный по сети, не сверяется с существующей записью в файле паролей, а просто заменяет ее. Это позволяет безопасно выбирать новый пароль даже при прослушивании сети.
Чтобы выполнять аутентификацию на многих удаленных серверах, пользователю необходимо для каждого сервера поддерживать соответствующую информацию о случайном числе и номере итерации и своевременно выполнять повторную инициализацию, что может быть достаточно трудоемким.
Никакие из описанных выше механизмов аутентификации не поддерживают конфиденциальность, то есть не позволяют выполнять шифрование сообщений во время сеанса связи между пользователем и сервером, и без серьезной доработки мало пригодны для взаимной аутентификации.
Безопасность соединения
Область Secure Communications (Безопасность соединения) во вкладке
Directory Security (Безопасность каталога) служит для настройки
сертификатов при аутентификации и шифровании. Она позволяет создать
запросы сертификатов, присваивать, экспортировать, импортировать и
резервировать сертификаты, настроить взаимодействие сервера с
сертификатами клиентов.
Для настройки сертификата на данном сервере нажмите на кнопку Server
Certificate (Сертификат сервера). Отобразится окно Web Server
Certificate Wizard (Мастер сертификатов веб-сервера). Нажмите на кнопку
Next (Далее) для изменения параметров присвоения сертификата.
Create A New Certificate (Создать новый сертификат). Позволяет
настроить запрос для отправки в бюро сертификатов (CA) (см.
“Шифрование”
).
Запрос направляется либо в онлайновое бюро сертификатов, либо
сохраняется в файле, и затем файл направляется в бюро сертификатов
через процедуру регистрации. Для отправки запроса онлайновому бюро
сертификатов установите на сервере Certificate Services (Службы
сертификатов).При создании запроса для отправки в бюро сертификатов выполните
следующие шаги.- Выберите опцию Create A New Certificate (Создать новый сертификат),
затем нажмите на кнопку Next. - Выберите опцию Prepare The Request Now, But Send It Later
(Подготовить запрос сейчас, но отправить его позже), затем нажмите на
кнопку Next - Введите желаемое имя для сертификата – можете указать любое имя.
- Укажите длину сертификата в битах. Можете выбрать значение 512, 1024,
2048, 4096, 8192 или 16384 бита для создания сложного хэша. - Если требуется выбрать поставщика криптографических услуг (CSP) для
генерирования данного сертификата, отметьте соответствующую опцию. CSP
представляет собой алгоритм, используемый для генерирования
сертификатов. - Введите имя вашей организации и укажите подразделение организации.
Помните, что при использовании услуг коммерческого бюро сертификатов
нужно указать ваше официальное деловое имя. Нажмите на кнопку Next. - Введите общее имя сайта. Оно должно соответствовать имени DNS или
NetBIOS, используемому для сайта. Поскольку каждый сертификат
соответствует определенному имени, он пригоден только для одного имени.
При использовании другого имени DNS или NetBIOS нужно получать новый
сертификат. Нажмите на кнопку Next. - Введите данные в полях City (Город), State (Штат) и Country (Страна).
Не допускайте сокращений. Нажмите на кнопку Next. - Введите имя и место расположения файла для размещения запроса.
Помните об этом файле, поскольку он будет использоваться в запросе на
сертификат. Нажмите на кнопку Next. - Следующее окно представляет собой окно отчета. Убедитесь в
правильности введенной информации. Нажмите на кнопку Next. - Нажмите на кнопку Finish (Готово) для завершения работы мастера.
- Выберите опцию Create A New Certificate (Создать новый сертификат),
- Assign An Existing Certificate (Присвоить имеющийся сертификат).
Позволяет присвоить веб-сайту корректный сертификат, хранящийся на
данном компьютере. При выборе опции отобразится список сертификатов
данного компьютера. Выделите один из них и нажмите на кнопку Next
(Далее). Выберите SSL-порт для сайта. В текущем окне установлено
значение порта по умолчанию (443). Не изменяйте это значение без
крайней необходимости, так как клиенты по умолчанию устанавливают
SSL-соединение через порт 443. После выбора номера порта просмотрите
окна с результирующей информацией и завершите работу мастера.
Установленный сертификат доступен для немедленного использования
клиентами. - Import A Certificate From A Key Manager Backup File (Импорт сертификата
из архива диспетчера ключей). Позволяет импортировать сертификат,
экспортированный при помощи программы Windows NT 4.0 Key Manager.
Выбрав опцию, перейдите в место расположения сохраненного файла .key и
выберите файл. Затем укажите порт SSL для сайта, просмотрите окна с
результирующей информацией и завершите работу мастера. - Import A Certificate From A .pfx File (Импорт сертификата из файла
.pfx). Позволяет импортировать файл сертификата, соответствующий
стандарту Personal Information Exchange Syntax Standard (Стандарт
синтаксиса обмена персональными данными) или PKSC #12. Это стандарт
хранения или транспортировки сертификатов в портативном формате. Если
вам нужно архивировать или экспортировать сертификат после
импортирования, отметьте опцию Mark Cert As Exportable (Пометить
сертификат как экспортируемый). После выбора файла .pfx укажите пароль,
обеспечивающий безопасность файла при экспортировании. Затем укажите
порт SSL для сайта, просмотрите окна с результирующей информацией и
завершите работу мастера. Copy Or Move A Certificate From A Remote Server Site To This Site
(Копировать или переместить сертификат с удаленного сервера на этот
сайт). Возможно получение сертификатов с другого веб-сайта. Данная
опция не позволяет выполнить экспортирование сертификата в файл,
представляющее собой угрозу безопасности. Для копирования или
перемещения сертификата с удаленного веб-сервера выполните следующие
действия.- В окне IIS Certificate Wizard (Мастер сертификатов IIS) выберите
опцию Copy Or Move A Certificate From A Remote Server Site To This Site
(Копировать или переместить сертификат с удаленного сервера на данный
сайт), затем нажмите на кнопку Next (Далее). - В диалоговом окне Copy/Move Certificate (Копировать/Переместить
сертификат) выберите нужное действие. - Укажите, нужно ли экспортировать сертификат с данного веб-сайта.
Нажмите на кнопку Next. - Введите имя компьютера (или перейдите к нему), с которого
импортируется сертификат. - Введите аутентификационные данные пользователя, имеющего достаточные
разрешения для доступа к сертификату, затем нажмите на кнопку Next. - Укажите расположение сайта, из которого импортируется сертификат. С
помощью кнопки Browse (Обзор) выберите это место из списка. Нажмите на
кнопку Next. - Проверьте данные в результирующем окне и убедитесь, что импортирован
правильный сертификат. - Нажмите на кнопку Next, затем нажмите на кнопку Finish (Готово).
- В окне IIS Certificate Wizard (Мастер сертификатов IIS) выберите
Обработка сертификата. После получения ответа от бюро сертификатов
обработайте ожидающий подтверждения запрос на сертификат. Для этого
выполните следующие действия.
- Запустите Web Server Certificate Wizard (Мастер сертификатов
веб-сервера) еще раз, нажав на кнопку Server Certificate (Сертификат
сервера) во вкладке Directory Security (Безопасность каталога). - В диалоговом окне Server Certificate (Сертификат сервера) выберите
опцию Process The Pending Request (Обработать ожидающий сертификат) и
установите сертификат. Нажмите на кнопку Next. - Введите имя файла ответа (или перейдите к его месту расположения),
полученного от бюро сертификатов, затем нажмите на кнопку Next. - Введите номер порта SSL, который будет использоваться сайтом. Нажмите
на кнопку Next. - Просмотрите окно с отчетом и убедитесь в правильности указанной
информации. - Нажмите на кнопку Next, затем нажмите на кнопку Finish (Готово).
Теперь у вашего сайта имеется правильный сертификат, и его можно
использовать для порта, указанного при установке файла ответа на запрос
сертификата. В случае отсутствия ответа нужно удалить ожидающий запрос.
Для этого выполните следующие шаги.
- В окне Web Server Certificate Wizard (Мастер сертификатов
веб-сервера) выберите опцию Delete The Pending Request (Удалить
ожидающий запрос). В следующем диалоговом окне появится сообщение о
том, что при продолжении работы мастера станет невозможной обработка
ответов на этот запрос, а также предложение отказаться от продолжения. - Нажмите на кнопку Next (Далее) для удаления запроса.
- Нажмите на кнопку Finish (Готово) для завершения работы мастера.
Просмотр деталей установленного сертификата. При наличии установленного
сертификата просмотрите информацию о нем, нажав на кнопку View
Certificate (Просмотр сертификата) во вкладке Directory Security
(Безопасность каталога).
Изменение безопасных соединений. С помощью кнопки Edit (Изменить) можно
изменить связи сертификата и списки доверия (см. рис. 2.14). Возможна
настройка принудительного использования SSL.
Опция Require Secure Channel (Требовать безопасный канал) обеспечивает
принудительное использование SSL на сайте. Любому браузеру, который не
использует протокол SSL, доступ к сайту будет запрещен.
Инфраструктура открытых ключей (pki)
Инфраструктура открытых ключей (PKI – Public Key Infrastructures) – модель для создания, распределения и аннулирования сертификатов, основанная на рекомендации X.509. Группа инженерной поддержки сети Интернет (IETF – Internet Engineering Task Force) создала Инфраструктуру общедоступного ключаX.509 (TKIX).
Режимы работы
Для PKI были определены несколько режимов работы. Самые важные из них показаны на
рис. 5.19.
- Выпуск, возобновление и аннулирование сертификатов. Эти режимы работы были определены в X.509. Поскольку PKIX базируется на X.509, он должен обработать все режимы работы, имеющие отношение к сертификатам.
- Хранение и модификация ключей. PKI должен быть местом хранения секретных ключей для тех участников, у которых есть необходимость держать свои секретные ключи где-нибудь в сейфе. В дополнение к этому PKI несет ответственность за обновление этих ключей по запросу участников.
- Обеспечение услуг другим протоколам. Как мы увидим в следующих немногих лекциях, некоторые протоколы безопасности Internet, такие как IPSec и TLS, базируются на услугах PKI.
- Обеспечение управления доступом. PKI может обеспечить различные уровни доступа к информации, сохраненной в ее базе данных. Например, организация PKI может обеспечить доступ к полной базе данных для высшего исполнительного руководства, но ограниченный доступ – для служащих.
Модель доверия
Невозможно иметь только один центр сертификации, выпускающий все сертификаты для всех пользователей в мире. Должно быть много центров сертификации (CA), каждый – ответственный за создание, сохранение, издание и аннулирование ограниченного числа сертификатов. Модель доверия(Trust Model) определяет правила, которые говорят, как пользователь может проверить сертификат, полученный от Центра Сертификации (CA).
Иерархическая модель. У этой модели – структура типа дерева с корнем CA. Корень CA имеет сертификат, подписанный и выпущенный им самим. Другим CA и пользователям для того, чтобы работать, необходимо доверять ему.
рис. 5.20 показывает модель доверия такого вида с тремя иерархическими уровнями. В реальной ситуации число уровней может быть больше, чем три.
Рисунок показывает, что CA (корень) подписывает сертификаты для CA1, CA2 с CA3; CA1 подписывают сертификаты для Польз.1, Польз. 2, Польз. 3 и так далее. PKI использует особую систему обозначений, которая означает: сертификат выдан администрацией X для объекта Y.
Пример 5.3
Показать, как Польз. 1, зная только общедоступный ключ CA (корень), может получить верифицированную копию общедоступного ключа Польз. 3.
Решение
Пользователь 3 передает сертификат по цепочке CA “CA1” и CA1 “Польз. 3”, к Польз. 3.
Пример 5.4
Некоторые Web-браузеры, такие как Netscape и Internet Explorer, содержат множество сертификатов, полученных от независимых Центров сертификации (корней) без единственного корня высокого уровня администрации, который мог бы сертифицировать каждый корень.
Можно найти список этих корней в Internet Explorer по следующему маршруту: Инструментальные средства / Опции Интернета / Содержание, Сертификат / Корень доверия (используя “раскрывающиеся строки”). Пользователь тогда может выбрать любой корень и ознакомиться с его сертификатом.
Модель “каждый с каждым”.Иерархическая модель может работать для организации или маленькой группы людей. Большие группы, возможно, нуждаются в нескольких иерархических структурах, соединенных вместе. Один из методов состоит в том, чтобы использовать модель “каждый с каждым” для соединения корней вместе. В этой модели каждый корень связан с каждым другим корнем, как это показано на
рис. 5.21.
Рис.5.21 показывает, что структура “каждый с каждым” соединяет вместе только корни; каждый корень имеет свою собственную иерархическую структуру, изображенную треугольником. Сертификация между корнями – перекрестные сертификаты; каждый корень сертифицирует все другие корни, что означает, что есть N (N – 1) сертификатов.
Пример 5.5
Алиса имеет дело с администрацией Root 1; Боб имеет дело с администрацией Root 4. Показать, как Алиса может получить верифицированный общедоступный ключ Боба.
Решение
Боб передает цепочку сертификатов от Root 4 к Бобу. Алиса смотрит каталог Root 1, чтобы найти Root 1 сертификаты “Root 1” и Root 1 “Root 4”. Используя процесс, показанный на
рис. 5.21, Алиса может верифицировать общедоступный ключ Боба.
Сеть доверия. Эта модель, которая используется в PGP (Pretty Good Privacy – очень хорошая конфиденциальность), службе безопасности для электронной почты, рассматривается в
“Безопасность на прикладном уровне: PGP и S/MIME”
.
Ключевое соглашение
В протоколе Диффи-Хеллмана две стороны создают симметричный ключ сеанса без KDC. Перед установлением симметричного ключа эти две стороны должны выбрать два числа p и g.
Первое число, p, является большим простым числом порядка 300 десятичных цифр (1024 бита). Второе число, g, служит генератором порядка p – 1 в группе <
Шаги перечислены ниже.
- Алиса выбирает большое случайное число x, такое, что 0 < x < p – 1, и вычисляет R1 = gx mod p.
- Боб выбирает другое большое случайное число y, такое, что 0 < y < p – 1, и вычисляет R2 = gy mod p.
- Алиса передает Бобу R1. Обратите внимание, что Алиса не передает значение x ; она передает только R1.
- Боб передает Алисе R2. Снова обратите внимание, что Боб не передает значение y, он передает только R2.
- Алиса вычисляет K = (R2)x mod p.
- Боб также вычисляет K = (R1)y mod p.
K = (gx mod p)y mod p = (gymod p)x mod p = gxy mod p
Боб вычисляет K = (R1)y mod p = (gx mod p)y mod p = gxy mod p
Алиса вычисляет K = (R2)x mod p = (gy mod p)x mod p = gxy mod p
и получает то же самое значение без Боба, знающего значение x. А Боб получил это значение без Алисы, знающей значение y.
Симметричный (общедоступный) ключ в методе Диффи-Хеллмана – K = gxy mod p
Пример 5.1
Приведем тривиальный пример, чтобы ясно понять процедуру. Наш пример использует маленькие числа, но заметим, что в реальной ситуации применяются очень большие числа. Предположим, что g = 7 и p = 23. Тогда процедура содержит следующие шаги.
- Алиса выбирает x = 3 и вычисляет R1 = 73 mod 23 = 21.
- Боб выбирает y = 6 и вычисляет R2 = 76 mod 23 = 4.
- Алиса передает число 21 Бобу.
- Боб передает число 4 Алисе.
- Алиса вычисляет симметричный ключ K = 43 mod 23 = 18.
- Боб вычисляет симметричный ключ K = 216 mod 23 = 18.
Значение K одно и то же и для Алисы, и для Боба: gx y mod p = 718 = 18 .
Пример 5.2
Давайте возьмем более реальный пример. Мы используем программу, чтобы создать случайное целое число 512 битов (идеально – 1024 бит). Целое число p – число с 159 цифрами. Мы также выбираем g, x и y, как показано ниже:
Следующая таблица показывает R1, R2 и K.
Анализ протокола Диффи-Хеллмана
Концепция Диффи-Хеллмана, показанная на
рис. 5.10, является простой, но изящной. Мы можем представить ключ засекречивания между Алисой и Бобом – он состоит из трех частей: g, x и y.
Первая часть общедоступна. Каждый знает 1/3 ключа
– g, общедоступное значение. Другие две части нужно узнать у Алисы и Боба. Каждый из них знает одну часть. Алиса добавляет x как вторую часть для Боба;
Боб добавляет y как вторую часть для Алисы. Когда Алиса получает 2/3 полного ключа от Боба, она добавляет последнюю часть, ее y,
чтобы завершить ключ. Когда Боб получает ключ от Алисы – законченный на 2/3, он добавляет последнюю часть, свое y, чтобы завершить ключ.
Обратите внимание, что хотя ключ Алисы состоит из g, y и x и ключ Боба состоит из g, x и y, эти два ключа – одни и те же, потому что gxy = gyx.
Обратите внимание также, что хотя два ключа те же самые, Алиса не может найти значение y, используемого Бобом, потому что вычисление сделано по модулю p. Алиса получает gy mod p от Боба, но не gy.
Безопасность протокола
Замена ключа Диффи-Хеллмана восприимчива к двум атакам: атаке дискретного логарифма и атаке посредника (man-in middle)
Атака дискретного логарифма. Безопасность ключевой станции базируется на трудности проблемы дискретного логарифма. Ева может перехватить R1 и R2.
Из R1 = gx mod p и y из R2 = gy mod p она может затем вычислить симметричный ключ: K = gxy mod p.
- Простое число p должно быть очень большим (более чем 300 десятичных цифр).
- Простое число p должно быть выбрано так, чтобы p – 1 имел по крайней мере один простой делитель (больше чем 60 десятичных цифр).
- Генератор должен быть выбран из группы <Zp*, x >.
- Боб и Алиса должны уничтожить x и y после того, как они вычислили значение симметричного ключа. Значения x и y должны использоваться только единожды.
Атака “посредника”. Этот протокол имеет другую слабость. Еве не надо находить значения x и y, чтобы напасть на протокол. Она может использовать глупость Алисы и Боба, создающих два ключа:
- Алиса выбирает x , вычисляет R 1 = gx mod p и передает R1 Бобу.
- Ева, злоумышленник, перехватывает R1. Она выбирает z, вычисляет R 2 = gz mod p и передает R 2 Алисе и Бобу.
- Боб выбирает y, вычисляет R3 = gy mod p, передает R3 Алисе. Ева перехватывает R3, и Алиса никогда не получит это число.
- Алиса и Ева вычисляют K1 = gxz mod p, который становится открытым ключом между Алисой и Евой. Алиса, однако, думает, что это -открытый ключ между ней и Бобом.
- Ева и Боб вычисляют K2 = gzymod p, который становится открытым ключом между Евой и Бобом. Однако Боб думает, что это – открытый ключ между ним Алисой.
Другими словами, создаются два ключа вместо одного: один между Алисой и Евой и один между Евой и Бобом. Когда Алиса посылает данные Бобу, она зашифровывает их ключом K1 (совместный ключ Алисы и Евы). Эти данные могут быть расшифрованы и прочитаны Евой.
Ева может передать сообщение Бобу, зашифрованное K2 (совместный ключ между Евой и Бобом); или она может даже изменить сообщение или передать новое сообщение. Боб введен в заблуждение, поскольку уверен, что сообщение пришло от Алисы. Подобный сценарий может случиться и в другом направлении – с Алисой.
Эта ситуация называется
” атака посредника “, поскольку Ева находится между партнерами и перехватывает R1, передаваемый Алисой Бобу, и R3, передаваемый Бобом Алисой.
Следующий метод основан на протоколе Диффи-Хеллмана. Он использует методы установления подлинности, чтобы сорвать эту атаку.
Ключи сеанса
KDC создает ключ засекречивания для каждого абонента. Этот ключ засекречивания может использоваться только между абонентом и KDC, а не между двумя членами сообщества. Если Алиса должна связаться тайно с Бобом, она нуждается в ключе засекречивания между собой и Бобом. KDC может создать ключ сеанса между Алисой и Бобом, используя их ключи с центром.
Ключи Алисы и Боба используются, чтобы подтвердить доступность и полномочность Алисы и Боба к центру и друг к другу перед тем, как будет установлен ключ сеанса. После того как связь закончена, ключ сеанса больше не нужен.
Симметричный ключ сеансамежду двумя сторонами используется только однажды.
Были предложены несколько различных подходов, чтобы создать ключ сеанса, используя идеи, рассмотренные в
“Установление подлинности объекта”
для установления подлинности объекта.
Простой протокол, использующий KDC
Давайте посмотрим, как KDS может создать сеансовый ключ KAB между Алисой и Бобом.
рис. 5.4 показывает предпринимаемые шаги.
- Алиса передает сообщение исходного текста KDC, чтобы получить симметричный ключ сеанса между собой и Бобом. Сообщение содержит ее зарегистрированный опознавательный код (слово Алиса или рисунок) и опознавательный код Боба (слово Боб или
рисунок). Зашифровано ли сообщение или общедоступно – KDC это не беспокоит. - KDC получает сообщение и создает то, что называется билетом. Билет зашифрован с помощью ключа Боба ( КB ). Билет содержит идентификаторы Алисы и Боба и ключ сеанса ( KAB ). Билет с копией ключа сеанса передают Алисе. Алиса получает сообщение, расшифровывает его и извлекает ключ сеанса. Она не может расшифровать билет Боба; билет, предназначенный для Боба, недоступен Алисе. Обратите внимание, что сообщение содержит двойное шифрование: зашифрован билет, а также зашифровано полное сообщение. Во втором сообщении Алиса фактически зарегистрирована в KDC, поэтому только Алиса может открыть целое сообщение, используя свой ключ засекречивания с KDC.
- Алиса передает билет Бобу. Боб открывает билет и знает, что Алиса должна передать ему сообщение, использующее KAB как ключ сеанса. Обратите внимание, что в этом сообщении Боб зарегистрирован в KDC, поэтому только Боб может открыть билет. Поскольку Боб зарегистрирован в KDC, он также зарегистрирован Алисой, которая доверяет KDC. Тем же самым способом Алиса также зарегистрирована Бобом, потому что Боб доверяет KDC, и KDC передал Бобу билет, который включает опознавательный код Алисы.
К сожалению, этот простой протокол имеет недостаток. Ева может применить атаку ответа, рассмотренную раньше, – то есть она может сохранить сообщение шага 3 и использовать его позже.
Протокол Ниидома-Шрёдера
Другой подход – изящный протокол Ниидома-Шрёдера (Needham-Schreder), который является основой многих протоколов. Этот протокол использует множество действий вызова-ответа между сторонами, чтобы достигнуть безупречного протокола.
Ниидом и Шрёдер применяют два nonce: RА и RB.
рис. 5.5 показывает пять шагов, используемых в этом протоколе. Мы кратко представляем каждый шаг.
- Алиса передает сообщение KDC, в которое включает свой nonce RА, свой опознавательный код и опознавательный код Боба.
- KDC передает зашифрованное сообщение Алисы, которое включает nonce Алисы, опознавательный код Боба, ключ сеанса и зашифрованный билет для Боба. Все сообщение зашифровано ключом Алисы.
- Алиса передает билет Боба ему.
- Боб передает свой запрос Алисе ( RB ), зашифрованный ключом сеанса.
- Алиса отвечает на запрос Боба. Обратите внимание, что ответ передается RB – 1 вместо RB.
Протокол Отвея-Рисса
Третий подход – протокол Отвея-Рисса (Otway-Rees)
– другой, не менее изящный протокол.
рис. 5.6 показывает этот протокол с пятью шагами.
Ниже кратко описываются шаги этого протокола.
- Алиса передает сообщение Бобу, которое включает nonce R, идентификационные признаки Алисы и Боба и билет для KDC – в билет входят once Алисы RA (свидетельство для пользования KDC), копия общего nonce R и идентификаторы Алисы и Боба.
- Боб создает тот же самый тип билета, но с собственным его, Боба, nonce RB. Оба билета передают KDC.
- KDC создает сообщение, которое содержит R, общий nonce, билет для Алисы и билет для Боба; сообщение передают Бобу. Билеты содержат соответствующий once RA или RB и ключ сеансаKAB.
- Боб передает Алисе ее билет.
- Алиса передает короткое сообщение, зашифрованное ее сеансовым ключомKAB, чтобы показать, что она имеет ключ сеанса.