Субъект, получивший одноразовый пароль путем прослушивания сети, не в состоянии сгенерировать следующий пароль, так как для этого требуется просчитать хэш-функцию в обратном направлении. Это не может быть сделано без знания секретного пароля, с которого начинались итерации. Поскольку в системе S/Key секретный пароль пользователя никогда не передается по сети и не хранится ни сервером, ни клиентом, риск хищения отсутствует.
S/Key - это система "клиент-сервер". Сервер генерирует отклик после получения от клиента login-запроса. Отклик сервера содержит номер итерации и случайное число. В ответ пользователь генерирует соответствующий одноразовый пароль, используя комбинацию своего секретного пароля, номера итерации и случайного числа, и отправляет его серверу. Первый одноразовый пароль из списка итераций сохраняется на шаге инициализации.
Сервер может и сам формировать S/Key -запрос, состоящий из номера итерации и случайного числа. Тогда, используя номер итерации и случайное число вместе со своим секретным паролем, пользователь вычисляет (или преобразует) одноразовый пароль. Сервер может не формировать запрос, если пользователь сохраняет номер итерации и случайное число после каждой своей успешной попытки аутентификации. Для хранения этих значений могут использоваться портативные устройства типа смарт-карт или карманных персональных компьютеров.
Итак, пользователь передает для проверки на сервер одноразовый пароль. Сервер сначала сохраняет копию этого одноразового пароля, а затем применяет к нему хэш-функцию. Если результат не совпадает с копией одноразового пароля, полученного во время последней удачной попытки аутентификации пользователя, то запрос отвергается. Если совпадает, тогда клиентская запись в файле паролей обновляется копией полученного от пользователя одноразового пароля, которая была сохранена перед вычислением хэш-функции. Обновление пароля обеспечивает возможность проверки следующего одноразового пароля. Так как следующий одноразовый пароль получается путем вычисления хэш-функции на один раз меньше, чем для предыдущего пароля, то получить предыдущий пароль можно, применив хэш-функцию к следующему паролю на один раз больше.
После успешной аутентификации пользователь получает доступ к серверу, но при следующей попытке аутентификации он должен генерировать новый одноразовый пароль. Использование случайных чисел, создаваемых генератором случайных чисел, позволяет клиенту выполнять аутентификацию на многих серверах при помощи одного секретного пароля, при этом каждому серверу соответствует свое случайное число. Кроме того, выбирая каждый раз новое случайное число, пользователь имеет возможность безопасно использовать секретный пароль много раз.
Обратная процедура, то есть получение из предыдущего пароля следующего пароля невозможна без знания начального одноразового пароля пользователя. Таким образом, ни серверу, ни клиенту нет необходимости хранить секретный пароль пользователя. На сервере в файле паролей сохраняется только копия последнего одноразового пароля, которого достаточно для аутентификации пользователя при следующей попытке. Секретный пароль известен только самому пользователю.
Так как количество итераций вычисления хэш-функции, выполняемого пользователем, уменьшается каждый раз на единицу, при обнулении счетчика итераций пользователь для доступа к серверу должен повторно инициализировать систему. Повторная инициализация сопровождается изменением номера итерации и случайного числа. Это операция идентична нормальной аутентификации, за исключением того, что одноразовый пароль, полученный по сети, не сверяется с существующей записью в файле паролей, а просто заменяет ее. Это позволяет безопасно выбирать новый пароль даже при прослушивании сети.
Чтобы выполнять аутентификацию на многих удаленных серверах, пользователю необходимо для каждого сервера поддерживать соответствующую информацию о случайном числе и номере итерации и своевременно выполнять повторную инициализацию, что может быть достаточно трудоемким. К недостаткам системы S/Key можно отнести и то, что она не обеспечивает взаимной аутентификации.
Никакие из описанных выше механизмов аутентификации не поддерживают конфиденциальность, то есть не позволяют выполнять шифрование сообщений во время сеанса связи между пользователем и сервером, и без серьезной доработки мало пригодны для взаимной аутентификации.
Аутентификация Kerberos
Роджер Нидхэм и Михаэль Шредер в 1978 году впервые предложили механизм аутентификации, который базировался на шифровании, но он, к сожалению, не обеспечивал одинаковых гарантий для участвующих в коммуникации сторон [93]. Для решения этой проблемы в Массачусетском технологическом институте в 1985 году была разработана система защиты информационных систем от вторжений, дополняющая механизм Нидхэма-Шредера специальным сервисом выдачи билетов. Она была названа Kerberos по имени трехглавого пса Цербера, охранявшего ворота в ад в греческой мифологии. Такое название было выбрано, потому что в аутентификации участвовали три стороны: пользователь, сервер, к которому желает получить доступ пользователь, и сервер аутентификации, или центр распределения ключей (ЦРК). Специальный сервер аутентификации предлагался в качестве доверенной третьей стороны, услугами которой могут пользоваться другие серверы и клиенты информационной системы [4].
Рис. 2.4. Аутентификация Kerberos
Система Kerberos владеет секретными ключами обслуживаемых субъектов и помогает им выполнять взаимную аутентификацию. Сеанс начинается с получения пользователем А билета для получения билета - Ticket-Granting Ticket (TGT) от ЦРК. Когда пользователь желает получить доступ к некоторому серверу В, то сначала отправляет запрос на билет для доступа к этому серверу вместе со своим билетом TGT в ЦРК. TGT содержит информацию о сеансе регистрации пользователя А и позволяет ЦРК оперировать, не поддерживая постоянно информацию о сеансе регистрации каждого пользователя. В ответ на свой запрос пользователь А получает зашифрованный сеансовый ключ SA и билет на доступ к серверу В. Сеансовый ключ зашифрован секретным ключом, известным только пользователю А и ЦРК. Билет на доступ к серверу В содержит тот же самый сеансовый ключ, однако он шифруется секретным ключом, известным только серверу В и ЦРК.