Эволюция механизмов аутентификации
Инфраструктура безопасности для распространения открытых ключей, управления электронными сертификатами и ключами пользователей получила название инфраструктуры открытых ключей - Public Key Infrastructure (PKI) . Термин "PKI" является производным от названия базовой технологии - криптографии с открытыми ключами, обладающей уникальными свойствами и являющейся основой для реализации функций безопасности в распределенных системах. Инфраструктура открытых ключей реализуется не ради нее самой, а для поддержки безопасности других приложений. Существуют, безусловно, и другие механизмы безопасности, которые не используют криптографию открытых ключей, и они менее сложные, чем PKI. Однако PKI не только предлагает наиболее комплексное решение, но и снимает остроту многих проблем, свойственных более традиционным механизмам безопасности.
Корпоративные системы обычно работают с большим количеством пользователей, причем каждый пользователь взаимодействует с системой по-своему. Аутентификация логически становится первым шагом при взаимодействии человека с системой. Механизмы аутентификации развивались с течением времени, опираясь на свойства своих предшественников. Аутентификация на базе PKI - это логический шаг в этой эволюции, обеспечивающий совершенствование таких характеристик, как применимость, жизнеспособность, масштабируемость и безопасность.
Механизмы аутентификации, которые рассматриваются в этой лекции, могут использоваться для аутентификации пользователя удаленным сервером сети, все они имеют свои достоинства и недостатки. Некоторые механизмы не требуют дополнительного администрирования для аутентификации пользователя несколькими удаленными серверами. Все механизмы обеспечивают как минимум одностороннюю аутентификацию пользователя удаленным сервером, а некоторые - даже взаимную аутентификацию пользователя и сервера. Аутентификация на базе PKI может быть односторонней или взаимной в зависимости от среды, в которой используется инфраструктура. Сравнительный анализ механизмов аутентификации позволяет продемонстрировать сильные стороны PKI.
Аутентификация на основе паролей
Почти каждая компьютерная система требует, чтобы в начале сеанса работы пользователь идентифицировал себя. Обычно пользователю предлагается ввести имя и пароль. Пароль - это секретная информация (или просто секрет), разделенная между пользователем и удаленным сервером. Пользователь помнит этот секрет, а сервер хранит либо копию секрета, либо значение, вычисленное на основе секрета. Во время аутентификации происходит сопоставление пароля, введенного пользователем, и значения, хранимого сервером. Аутентификация при помощи паролей - наиболее распространенный вид аутентификации. Если злоумышленник знает чужой пароль, то имеет возможность выдавать себя за другого субъекта, и сервер не может отличить его от настоящего пользователя.
Рис. 2.1. Аутентификация при помощи пароля
На пользователь А передает по сети на сервер свое имя и пароль. Некто, наблюдающий за средой передачи, например, пользователь С, может похитить пароль пользователя А. Как только это происходит, пользователь С может выдавать себя за пользователя А до тех пор, пока пароль не будет изменен, а это может продолжаться достаточно долгое время. Поэтому для безопасности вычислительной среды требуется регулярно менять пароли.
Существует несколько способов получения секретного пароля в сети. Пользователь С может использовать программу-анализатор, или сниффер. Программы-анализаторы легко доступны в Интернете, они позволяют перехватывать сетевой трафик между компьютерами одной локальной сети. Для перехвата пароля пользователю С можно даже не находиться в одном помещении с пользователем А и не иметь доступ к его компьютеру - ему достаточно лишь сетевого подключения к той же самой локальной сети. Эти программы настолько упрощают перехват информации, что хищение пароля часто называют атакой анализатора . После смены пароль остается неизвестен пользователю С только до очередного запуска программы-анализатора. Если пользователь С постоянно запускает свою программу-анализатор, то получает новый пароль пользователя А, как только он выбран.
Некоторые типы локальных сетей более уязвимы для атак анализатора. Особенно это касается тех, которые, как многоканальная сеть Ethernet, используют широковещательную среду. Сети, подобные коммутируемой сети Ethernet, не столь восприимчивы. Концентратор передает трафик только по проводам, соединяющим связывающиеся компьютеры. В этом случае, чтобы получить ту же самую информацию, пользователь С сталкивается с более трудной задачей: инсталлировать программу-анализатор на компьютер пользователя А.
Атаки анализаторов обнажают две серьезные проблемы аутентификации при помощи паролей. Во-первых, для аутентификации пользователь А должен передать свой пароль, разделенный секрет. Выполняя это, пользователь А может раскрыть его. Во-вторых, если разделенный секрет пользователя А используется долгое время, пользователю С достаточно получить пароль один раз, после чего он может выдавать себя за пользователя А, пока последний не изменит свой пароль. Эти слабые стороны делают атаки анализаторов успешными.
Аутентификация при помощи паролей неэффективна в среде со многими серверами . Предположим, что пользователь А регулярно взаимодействует с шестью удаленными серверами. Он может использовать один и тот же пароль для каждой системы или разные пароли для всех систем. Если пользователь А использует один и тот же пароль, то успешная атака анализатора позволяет пользователю С получить доступ к учетным записям пользователя А сразу на всех серверах и в дальнейшем выдавать себя за него. Если пользователь А использует разные пароли для каждого сервера, то успешная атака анализатора позволяет пользователю С получить доступ только к одному серверу, но при этом пользователь А должен помнить шесть разных паролей. Скорее всего, пользователь А запишет свои пароли, в этом случае они могут быть похищены другим способом.
Взаимная аутентификация при помощи паролей возможна только если существует два разделенных между пользователем и сервером секрета, два пароля. В этом случае каждый пользователь должен помнить пароль сервера и также свой пароль. А сервер должен обменяться вторым разделенным секретом с каждым пользователем, причем этот секрет должен быть уникальным, чтобы ни один пользователь не мог маскироваться под сервер перед другим пользователем. Если взаимная аутентификация пользователей отсутствует, то пользователь С может получить пароль пользователя А, создав фальшивый сервер. Когда пользователи попытаются получить доступ к этому серверу, пользователь С сможет собрать их имена и пароли.
Эволюция механизмов аутентификации началась в ответ на атаки анализаторов. Очевидно, что должна была появиться защита от этих атак в виде шифрования. Шифрование предотвращает раскрытие пароля при передаче. Но если все пользователи используют один и тот же ключ шифрования, то любой из них может использовать анализатор, получить чужой пароль и расшифровать его тем же способом, что и сервер. Если каждый пользователь имеет свой ключ, то управление этими ключами обеспечивает более сильную аутентификацию, чем пароли. Следует отметить, что пользователь А защищен и в том случае, если его пароль используется однократно. Удачная атака анализатора позволяет пользователю С получить устаревший пароль А. Ясно, что пользователю А в этом случае необходим новый пароль для каждой попытки аутентификации.
Механизмы одноразовой аутентификации
Одноразовая аутентификация позволяет противостоять атаке анализатора за счет использования во время каждой попытки аутентификации нового секрета. В этом случае, если пользователь С перехватывает данные пользователя А, то не может в дальнейшем их использовать, чтобы выдавать себя за него. Рассмотрим три разных механизма одноразовой аутентификации: аутентификацию типа "запрос-ответ", неявный запрос и аутентификацию на базе хэш-функций.
Аутентификация "запрос-ответ"
Как показано на , сервер генерирует случайный запрос и отправляет его пользователю А . Вместо того чтобы в ответ отправить серверу пароль, пользователь А шифрует запрос при помощи ключа, известного только ему самому и серверу. Сервер выполняет такое же шифрование и сравнивает результат с шифртекстом, полученным от пользователя А. Если они совпадают, то аутентификация прошла успешно, в противном случае - неудачно.
Этот простой механизм имеет несколько преимуществ по сравнению с простой аутентификацией при помощи паролей. Поскольку запрос генерируется случайным образом, пользователь С не может повторно использовать шифртекст, сгенерированный пользователем А, чтобы выдавать себя за него. Значение, которое отправляет пользователь А, аутентифицирует его идентичность только один раз. Имя пользователя А передается открыто, и нет причин его скрывать. Перехват информации больше не является угрозой, и пользователь А может выполнять аутентификацию на удаленном сервере в открытой сети.
Рис. 2.2. Аутентификация "запрос-ответ"
Механизм усложняется, если пользователю А необходимо пройти аутентификацию на многих серверах, в этом случае, как и при использовании паролей, пользователь А должен иметь для каждого сервера свой ключ шифрования запроса и защищенно хранить все эти ключи.
Чтобы этот механизм был пригоден для взаимной аутентификации, необходимы еще один запрос и ответ. Пользователь А может направить второй запрос вместе с зашифрованным первым запросом, а сервер - вернуть зашифрованный ответ вместе с уведомлением о корректной проверке запроса пользователя А. Таким образом, этот механизм может быть использован для взаимной аутентификации без второго разделяемого ключа шифрования запроса.
В некоторых случаях аутентификация типа "запрос-ответ" невозможна, потому что сервер не имеет средств формирования запроса к пользователю, это характерно для систем, первоначально спроектированных для применения простых паролей. Тогда необходим неявный запрос, который обычно базируется на значении текущего времени.
Неявный запрос на базе времени
иллюстрирует аутентификацию на базе времени . Пользователь А шифрует значение текущего времени на часах своего компьютера и отправляет свое имя и шифртекст на сервер. Сервер расшифровывает значение, присланное пользователем А. Если оно достаточно близко к значению текущего времени на компьютерных часах сервера, то аутентификация проходит успешно, в противном случае - неудачно. Поскольку компьютерные часы пользователя А и сервера не синхронизированы и передача информации занимает некоторое время, сервер должен допускать несколько возможных значений времени.
Однако если сервер признает допустимым слишком большой разброс значений времени, то пользователь С может перехватить значение, сгенерированное пользователем А, и отправить его на сервер, с успехом выдавая себя за А. Эта атака называется атакой воспроизведения. Пользователь С не знает секретного ключа шифрования пользователя А, но, быстро передавая воспроизведенный шифртекст, может имитировать повторное обращение пользователя А к серверу.
Рис. 2.3. Аутентификация при помощи неявного запроса
Этот механизм не слишком серьезно совершенствует схему "запрос-ответ", он также с трудом поддерживает аутентификацию пользователя на многих серверах и не обеспечивает взаимной аутентификации, кроме того, он уязвим для атак воспроизведения. Лучшие свойства механизма "запрос-ответ" и неявного запроса на базе времени удалось совместить при использовании для аутентификации односторонней хэш-функции.
Аутентификация с использованием хэш-функции
Для решения проблем аутентификации, связанных с неявными запросами, Лесли Лампорт предложил использовать одноразовые пароли, генерируемые при помощи односторонней хэш-функции (). Эта идея нашла воплощение в системе одноразовых паролей S/Key One-Time Password System . Система S/Key, применяя одностороннюю хэш-функцию, генерирует последовательность одноразовых паролей. Начальное значение хэш-кода вычисляется путем хэширования секретного пароля пользователя, который сцеплен с несекретным случайным числом, выработанным генератором случайных чисел. Секретный пароль должен иметь длину не менее 8 символов. Последовательность одноразовых паролей формируется в результате многократного применения секретной хэш-функции (от 500 до 1000 ). То есть первый одноразовый пароль генерируется путем применения хэш-функции к секретному паролю пользователя определенное количество раз ( N ), следующий одноразовый пароль - путем применения хэш-функции к секретному паролю пользователя только (N - 1) раз и т.д.
Субъект, получивший одноразовый пароль путем прослушивания сети, не в состоянии сгенерировать следующий пароль, так как для этого требуется просчитать хэш-функцию в обратном направлении. Это не может быть сделано без знания секретного пароля, с которого начинались итерации. Поскольку в системе S/Key секретный пароль пользователя никогда не передается по сети и не хранится ни сервером, ни клиентом, риск хищения отсутствует.
S/Key - это система "клиент-сервер". Сервер генерирует отклик после получения от клиента login-запроса. Отклик сервера содержит номер итерации и случайное число. В ответ пользователь генерирует соответствующий одноразовый пароль, используя комбинацию своего секретного пароля, номера итерации и случайного числа, и отправляет его серверу. Первый одноразовый пароль из списка итераций сохраняется на шаге инициализации.
Сервер может и сам формировать S/Key -запрос, состоящий из номера итерации и случайного числа. Тогда, используя номер итерации и случайное число вместе со своим секретным паролем, пользователь вычисляет (или преобразует) одноразовый пароль. Сервер может не формировать запрос, если пользователь сохраняет номер итерации и случайное число после каждой своей успешной попытки аутентификации. Для хранения этих значений могут использоваться портативные устройства типа смарт-карт или карманных персональных компьютеров.
Итак, пользователь передает для проверки на сервер одноразовый пароль. Сервер сначала сохраняет копию этого одноразового пароля, а затем применяет к нему хэш-функцию. Если результат не совпадает с копией одноразового пароля, полученного во время последней удачной попытки аутентификации пользователя, то запрос отвергается. Если совпадает, тогда клиентская запись в файле паролей обновляется копией полученного от пользователя одноразового пароля, которая была сохранена перед вычислением хэш-функции. Обновление пароля обеспечивает возможность проверки следующего одноразового пароля. Так как следующий одноразовый пароль получается путем вычисления хэш-функции на один раз меньше, чем для предыдущего пароля, то получить предыдущий пароль можно, применив хэш-функцию к следующему паролю на один раз больше.
После успешной аутентификации пользователь получает доступ к серверу, но при следующей попытке аутентификации он должен генерировать новый одноразовый пароль. Использование случайных чисел, создаваемых генератором случайных чисел, позволяет клиенту выполнять аутентификацию на многих серверах при помощи одного секретного пароля, при этом каждому серверу соответствует свое случайное число. Кроме того, выбирая каждый раз новое случайное число, пользователь имеет возможность безопасно использовать секретный пароль много раз.
Обратная процедура, то есть получение из предыдущего пароля следующего пароля невозможна без знания начального одноразового пароля пользователя. Таким образом, ни серверу, ни клиенту нет необходимости хранить секретный пароль пользователя. На сервере в файле паролей сохраняется только копия последнего одноразового пароля, которого достаточно для аутентификации пользователя при следующей попытке. Секретный пароль известен только самому пользователю.
Так как количество итераций вычисления хэш-функции, выполняемого пользователем, уменьшается каждый раз на единицу, при обнулении счетчика итераций пользователь для доступа к серверу должен повторно инициализировать систему. Повторная инициализация сопровождается изменением номера итерации и случайного числа. Это операция идентична нормальной аутентификации, за исключением того, что одноразовый пароль, полученный по сети, не сверяется с существующей записью в файле паролей, а просто заменяет ее. Это позволяет безопасно выбирать новый пароль даже при прослушивании сети.
Чтобы выполнять аутентификацию на многих удаленных серверах, пользователю необходимо для каждого сервера поддерживать соответствующую информацию о случайном числе и номере итерации и своевременно выполнять повторную инициализацию, что может быть достаточно трудоемким. К недостаткам системы S/Key можно отнести и то, что она не обеспечивает взаимной аутентификации.
Никакие из описанных выше механизмов аутентификации не поддерживают конфиденциальность, то есть не позволяют выполнять шифрование сообщений во время сеанса связи между пользователем и сервером, и без серьезной доработки мало пригодны для взаимной аутентификации.
Аутентификация Kerberos
Роджер Нидхэм и Михаэль Шредер в 1978 году впервые предложили механизм аутентификации, который базировался на шифровании, но он, к сожалению, не обеспечивал одинаковых гарантий для участвующих в коммуникации сторон . Для решения этой проблемы в Массачусетском технологическом институте в 1985 году была разработана система защиты информационных систем от вторжений, дополняющая механизм Нидхэма-Шредера специальным сервисом выдачи билетов. Она была названа Kerberos по имени трехглавого пса Цербера, охранявшего ворота в ад в греческой мифологии. Такое название было выбрано, потому что в аутентификации участвовали три стороны: пользователь, сервер, к которому желает получить доступ пользователь, и сервер аутентификации, или центр распределения ключей (ЦРК). Специальный сервер аутентификации предлагался в качестве доверенной третьей стороны, услугами которой могут пользоваться другие серверы и клиенты информационной системы .
Рис. 2.4. Аутентификация Kerberos
Система Kerberos владеет секретными ключами обслуживаемых субъектов и помогает им выполнять взаимную аутентификацию. Сеанс начинается с получения пользователем А билета для получения билета - Ticket-Granting Ticket (TGT) от ЦРК. Когда пользователь желает получить доступ к некоторому серверу В, то сначала отправляет запрос на билет для доступа к этому серверу вместе со своим билетом TGT в ЦРК. TGT содержит информацию о сеансе регистрации пользователя А и позволяет ЦРК оперировать, не поддерживая постоянно информацию о сеансе регистрации каждого пользователя. В ответ на свой запрос пользователь А получает зашифрованный сеансовый ключ S A и билет на доступ к серверу В. Сеансовый ключ зашифрован секретным ключом, известным только пользователю А и ЦРК. Билет на доступ к серверу В содержит тот же самый сеансовый ключ, однако он шифруется секретным ключом, известным только серверу В и ЦРК.
Аутентификация происходит тогда, когда пользователь А и сервер доказывают знание своего секретного ключа. Пользователь шифрует метку времени и отправляет ее на сервер В. Сервер расшифровывает метку, увеличивает ее значение на единицу, вновь зашифровывает и отправляет шифртекст пользователю А. Пользователь А расшифровывает ответ, и если в нем содержится значение метки времени с приращением, то аутентификация завершается успешно, в противном случае - неудачно. После взаимной аутентификации сеансовый ключ может использоваться для шифрования сообщений, которыми обмениваются пользователь А и сервер В. Очевидно, что стороны должны доверять ЦРК, поскольку он хранит копии всех секретных ключей.
Рассмотрим более подробно аутентификацию в системе Kerberos (), которая выполняется за четыре шага:
1 получение пользователем билета TGT на билеты;
2 получение пользователем билета на доступ к серверу ;
3 аутентификация пользователя сервером;
4 аутентификация сервера пользователем.
Получение пользователем билета TGT на билеты
В начале сеанса регистрации пользователь обращается к сервису аутентификации (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 мин.), то это означает, что шифрование мог выполнить только пользователь А. Таким образом, сервер аутентифицирует пользователя.
Для того чтобы гарантировать, что сторонний пользователь С не сможет воспроизвести легитимный запрос пользователя А, сервер должен проверить аутентификаторы, которые он обрабатывал в течение ограниченного промежутка времени, когда происходил сеанс связи с А. В этот интервал времени имя пользователя не должно быть связано с одним и тем же аутентификатором более одного раза.
Аутентификация сервера пользователем
Для того чтобы пользователь А, в свою очередь, мог аутентифицировать сервер, сервер В увеличивает на единицу значение времени из запроса пользователя А и вновь шифрует его при помощи ключа K AB . Этот шифртекст и является ответом сервера: K AB [время+1] . Пользователь А получает ответ сервера и расшифровывает его ключом K AB . Пользователь А полагается на то, что ЦРК разделил ключ только с тем сервером, для доступа к которому пользователь А запрашивал билет. Если в результате расшифрования ответа сервера В при помощи ключа K AB получается исходное значение даты и времени, увеличенное на единицу, то это означает, что только сервер В мог выполнить это шифрование. Когда взаимная аутентификация завершена, сеансовый ключ может использоваться для обеспечения конфиденциальности или целостности сообщений, которыми обмениваются пользователь А и сервер В.
Система Kerberos - это мощный механизм, поддерживающий взаимную аутентификацию и аутентификацию пользователя на многих удаленных серверах. Пользователь может аутентифицировать себя в открытой сети или проверить идентичность удаленного сервера при помощи того же самого механизма, который используется для подтверждения его собственной идентичности .
К сожалению, ЦРК системы Kerberos представляет собой очень привлекательную цель для нападения. Успешная атака на ЦРК создает катастрофические проблемы. Если злоумышленник получает секретный ключ ЦРК, то одновременно получает возможность выдавать себя за любого пользователя. При обнаружении компрометации ЦРК должна быть проделана колоссальная работа по смене всех секретных ключей. И если системные администраторы могут легко изменить секретные ключи серверов, местонахождение которых им известно, то поиск каждого пользователя, чтобы он сформировал новый пароль (на основе которого затем будет сформирован секретный ключ), может потребовать значительных усилий. Для этого случая предлагает решение криптография с открытыми ключами.
Инициализация открытых ключей Kerberos
Инициализация открытых ключей Kerberos (Kerberos Public Key Initialization - PKIINIT) вносит изменения в процедуру начального обмена с ЦРК, а все остальное оставляет без изменений . В своем запросе пользователь А отправляет сертификат ключа подписи и подписанный открытый ключ. Сертификат ключа подписи пользователя А содержит имя А и открытый ключ, используемый для проверки подлинности цифровых подписей, сгенерированных пользователем А. Открытый ключ будет использоваться для управления ключами; он может быть либо ключом транспортировки ключей ( открытый ключ RSA ) либо ключом согласования ключей ( открытый ключ Диффи-Хэллмана). ЦРК проверяет цифровую подпись, чтобы гарантировать, что открытый ключ принадлежит пользователю А. Проверив его один раз, ЦРК использует этот открытый ключ для подписания сеансового ключа.
Формат ответа ЦРК зависит от типа ключа пользователя А. Если пользователь А использует открытый ключ Диффи-Хэллмана, то ЦРК возвращает его подписанным при помощи открытого ключа Диффи-Хэллмана. Пользователь проверяет цифровую подпись, чтобы убедиться, что ответ принадлежит ЦРК. И пользователь А, и ЦРК вычисляют один и тот же симметричный ключ при помощи алгоритма Диффи-Хеллмана и используют его как сеансовый ключ S A . Пользователь А может использовать и открытый ключ RSA. В этом случае ЦРК генерирует временный симметричный ключ и шифрует его при помощи открытого ключа ( RSA ) пользователя А. Кроме того, ЦРК генерирует и заверяет цифровой подписью второй симметричный ключ, который будет использоваться как сеансовый ключ S A . Затем подписанный ключ S A шифруется при помощи временного ключа и отправляется пользователю А вместе с временным ключом, зашифрованным открытым ключом ( RSA ) пользователя А. Пользователь А может извлечь ключ S A , расшифровав сначала временный ключ при помощи своего секретного ключа ( RSA ), а потом использовав этот временный ключ для окончательного расшифрования подписанного ключа S A . Проверка подписи гарантирует, что сеансовый ключ S A получен от ЦРК.
Без сертификата ЦРК был бы необходим другой механизм аутентификации открытого ключа пользователя А. Связывание имени пользователя А с его открытым ключом подписи позволяет ЦРК аутентифицировать запрос. ЦРК полагается на удостоверяющий центр (УЦ) для подтверждения того, что пользователь А владеет секретным ключом, соответствующим открытому ключу, указанному в сертификате.
Использование в системе Kerberos технологии открытых ключей позволяет ЦРК не хранить секретные ключи пользователей, что значительно снижает риск компрометации. В случае успешной атаки на ЦРК последствия оказываются менее серьезными, так как новые секретные ключи требуются только серверам.
Аутентификация при помощи сертификатов
В том случае, когда пользователи имеют сертификаты открытых ключей, необходимость в ЦРК отпадает. Это не означает, что отпадает необходимость в доверии и третьих сторонах; просто доверенной третьей стороной становится УЦ. Однако УЦ не участвует в обмене протоколами, и в отличие от ситуации с ЦРК, если УЦ недоступен, аутентификация по-прежнему может быть выполнена.
Аутентификацию при помощи сертификатов обеспечивают несколько распространенных протоколов, в частности, наиболее известный и широко распространенный протокол Secure Socket Layer (SSL), который применяется практически в каждом web-браузере. Помимо него применяются протоколы Transport Layer Security (TLS) , Internet Key Exchange (IKE) , S/MIME , PGP и Open PGP . Каждый из них немного по-своему использует сертификаты, но основные принципы - одни и те же.
Рис. 2.5. Взаимная аутентификация на базе сертификатов
иллюстрирует типичный обмен сообщениями при аутентификации на базе сертификатов, использующий цифровые подписи . Обмен соответствует стандарту аутентификации субъектов на основе криптографии с открытыми ключами . Во многих протоколах предусматривается, что клиент направляет запрос серверу для того, чтобы инициировать аутентификацию. Такой подход, характерный, например, для дополнений аутентификации и шифрования к протоколу Internet File Transfer Protocol, гарантирует, что и пользователь, и сервер поддерживают один и тот же механизм аутентификации. Некоторые протоколы не требуют этого подготовительного шага.
Если сервер В поддерживает метод аутентификации, запрашиваемый пользователем А, то начинается обмен сообщениями. Сообщение 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. протоколы аутентификации на базе сертификатов не требуют активного участия третьих сторон. Для успешной аутентификации должны быть доступны только пользователь и сервер.
Возможности PKI
Для удовлетворения требований аутентификации в распределенной среде механизмы на базе сертификатов используют криптографию с открытыми ключами. Они созданы на основе многих свойств своих предшественников и добавляют новые возможности. Инфраструктура открытых ключей (PKI) - это современная технология аутентификации, использующая для идентификации субъектов криптографию с открытыми ключами вместе со следующими механизмами:
* механизмом установления доверия на базе определенной модели доверия;
* механизмом присваивания субъектам имен, уникальных в данной среде;
* механизмом распространения информации, характеризующей правильность связывания определенной пары ключей ( открытого и секретного) с определенным именем субъекта в данной среде (такая информация фиксируется и предоставляется центром, которому доверяет верификатор информации) .
Строго говоря, PKI обеспечивает аутентификацию - не больше и не меньше; вопреки широко распространенному мнению о возможностях PKI, она не реализует:
* авторизацию (хотя может применяться с целью защиты информации, используемой для авторизации);
* доверие (хотя и способствует установлению отношений доверия, подтверждая принадлежность данного открытого ключа определенному субъекту);
* именование субъектов (а только связывает известные имена субъектов с их открытыми ключами );
* защиту компьютерных систем и сетей (служит базисом сервисов безопасности, но не заменяет собой другие средства и методы защиты).
Конечно, аутентификация - это только один из необходимых сервисов безопасности. Многие приложения также требуют конфиденциальности, целостности и невозможности отказаться от участия в обмене информацией. Технология PKI обеспечивает поддержку всех этих сервисов.