Ольга Полянская - Инфраструктуры открытых ключей

Роджер Нидхэм и Михаэль Шредер в 1978 году впервые предложили механизм аутентификации, который базировался на шифровании, но он, к сожалению, не обеспечивал одинаковых гарантий для участвующих в коммуникации сторон [93]. Для решения этой проблемы в Массачусетском технологическом институте в 1985 году была разработана система защиты информационных систем от вторжений, дополняющая механизм Нидхэма-Шредера специальным сервисом выдачи билетов. Она была названа Kerberos по имени трехглавого пса Цербера, охранявшего ворота в ад в греческой мифологии. Такое название было выбрано, потому что в аутентификации участвовали три стороны: пользователь, сервер, к которому желает получить доступ пользователь, и сервер аутентификации, или центр распределения ключей (ЦРК) . Специальный сервер аутентификации предлагался в качестве доверенной третьей стороны, услугами которой могут пользоваться другие серверы и клиенты информационной системы [4].

Рис. 2.4. Аутентификация Kerberos

Система Kerberos владеет секретными ключами обслуживаемых субъектов и помогает им выполнять взаимную аутентификацию . Сеанс начинается с получения пользователем А билета для получения билета - Ticket-Granting Ticket (TGT) от ЦРК . Когда пользователь желает получить доступ к некоторому серверу В , то сначала отправляет запрос на билет для доступа к этому серверу вместе со своим билетом TGT в ЦРК . TGT содержит информацию о сеансе регистрации пользователя А и позволяет ЦРК оперировать, не поддерживая постоянно информацию о сеансе регистрации каждого пользователя. В ответ на свой запрос пользователь А получает зашифрованный сеансовый ключ S A и билет на доступ к серверу В . Сеансовый ключ зашифрован секретным ключом, известным только пользователю А и ЦРК . Билет на доступ к серверу В содержит тот же самый сеансовый ключ, однако он шифруется секретным ключом, известным только серверу В и ЦРК .

Аутентификация происходит тогда, когда пользователь А и сервер доказывают знание своего секретного ключа. Пользователь шифрует метку времени и отправляет ее на сервер В . Сервер расшифровывает метку, увеличивает ее значение на единицу, вновь зашифровывает и отправляет шифртекст пользователю А . Пользователь А расшифровывает ответ, и если в нем содержится значение метки времени с приращением, то аутентификация завершается успешно, в противном случае - неудачно. После взаимной аутентификации сеансовый ключ может использоваться для шифрования сообщений, которыми обмениваются пользователь А и сервер В . Очевидно, что стороны должны доверять ЦРК , поскольку он хранит копии всех секретных ключей.

Рассмотрим более подробно аутентификацию в системе Kerberos ( рис. 2.4), которая выполняется за четыре шага:

1получение пользователем билета TGT на билеты;

2получение пользователем билета на доступ к серверу ;

3аутентификация пользователя сервером;

4аутентификация сервера пользователем.

В начале сеанса регистрации пользователь обращается к сервису аутентификации (Authentication Service - AS) Kerberos за получением билета TGT для ЦРК . Обмен сообщениями с сервисом AS не требует от пользователя А подтверждения своей идентичности. Обмен состоит из двух сообщений: запроса от А и ответа сервиса AS . Запрос содержит просто имя пользователя А , а ответ сервиса AS - сеансовый ключ регистрации S A и билет TGT , зашифрованные секретным ключом К A пользователя А . Обычно ключ К A извлекается из пароля пользователя А , что позволяет пользователю не запоминать двоичный симметричный ключ и обращаться к Kerberos с любой рабочей станции. Билет TGT содержит сеансовый ключ S A , имя пользователя А и срок действия билета, зашифрованные вместе секретным ключом ЦРК - К К . В дальнейшем при шифровании сообщений для пользователя А вместо секретного ключа К A ЦРК использует сеансовый ключ S A .

Когда пользователь А желает получить доступ к серверу, в своем сообщении он отправляет в ЦРК билет TGT , запрос на билет для доступа к серверу и аутентификатор. Это сообщение имеет следующий формат: "имя А", "имя B", TGT: К К["имя А", S A, срок действия], S A[время] и называется запросом пользователя на доступ к серверу. Аутентификатор доказывает ЦРК , что пользователь А знает сеансовый ключ S A . Аутентификатор состоит из текущего значения даты и времени, зашифрованного сеансовым ключом. Шифрование защищает от возможного перехвата сторонним пользователем С билета TGT из ответа ЦРК пользователю А . Указание текущих значений даты и времени в аутентификаторе требует синхронизации компьютерных часов пользователя А и ЦРК . ЦРК может допускать некоторый разброс времени (обычно 5 мин.). На практике для поддержки синхронизации часов используется протокол синхронизации времени типа Simple Network Time Protocol (SNTP).

ЦРК получает запрос пользователя А на доступ к серверу В и готовит ответ. При помощи ключа К К ЦРК расшифровывает билет TGT из запроса, восстанавливает сеансовый ключ S A и проверяет срок действия билета TGT . Если билет TGT - действующий, то ЦРК генерирует ключ для пользователя А и сервера В - K AB и формирует билет. Билет шифруется секретным ключом сервера В - K B и содержит ключ K AB , имя пользователя А и срок действия. В ответе ЦРК указываются имя сервера В и ключ K AB , зашифрованные сеансовым ключом S A , ответ имеет следующий формат: S A["имя В", K AB, TICKET: K B["имя А", K AB, срок действия]] . Получив ответ от ЦРК , пользователь А расшифровывает его при помощи сеансового ключа S A .

Пользователь А отправляет на сервер В запрос, состоящий из билета, который был прислан в ответе ЦРК , и аутентификатора, который содержит текущее значение даты и времени, зашифрованное ключом K AB ( K AB - сеансовый ключ для пользователя А и сервера В , здесь опять необходима синхронизация компьютерных часов пользователя А и сервера В ).

Сервер В получает запрос пользователя А - TICKET: K B["имя А", K AB, срок действия], K AB[время] - и готовит ответ. Сервер расшифровывает билет своим секретным ключом K B , обнаруживая ключ K AB , имя пользователя А и срок действия билета; при этом предполагается, что ЦРК разделил ключ K AB только со стороной, названной в билете пользователем А . Если после расшифрования аутентификатора при помощи ключа K AB получено значение даты и времени, близкое к значению текущего времени (в интервале 5 мин.), то это означает, что шифрование мог выполнить только пользователь А . Таким образом, сервер аутентифицирует пользователя.