Протокол Kerberos предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними, причём в протоколе учтён тот факт, что начальный обмен информацией между клиентом и сервером происходит в незащищённой среде, а передаваемые пакеты могут быть перехвачены и модифицированы. Другими словами, протокол идеально подходит для применения в Интернет и аналогичных сетях.
Основные концепции.
Основная концепция протокола Kerberos очень проста — если есть секрет, известный только двоим, то любой из его хранителей может с лёгкостью удостовериться, что имеет дело со своим напарником. Для этого ему достаточно проверить, знает ли его собеседник общий секрет.
Рассмотрим простой пример. Допустим, Ольга часто посылает сообщения Стасу, который использует содержащуюся в них информацию только тогда, когда абсолютно уверен в том, что она поступила именно от Ольги. Чтобы никто не смог подделать письма, они договорились между собой о пароле, который знают только они вдвоём. Если из сообщения можно будет заключить, что отправитель знает пароль, то Стас может с уверенностью сказать, что сообщение пришло от Ольги.
Теперь Стасу и Ольге осталось только решить, каким образом показать знание пароля. Можно просто включить его в текст сообщения, например, после подписи: "Ольга, нашПароль". Это было бы просто, удобно и надёжно, если бы Ольга и Стас были уверены, что никто другой не читает их письма. К сожалению, в реальном мире об этом можно только мечтать. Почта передаётся по сети, в которой работают и другие пользователи, а среди них есть Женя, который очень любит выведывать чужие секреты, и постоянно подключает к сети свой анализатор пакетов. Совершенно ясно, что Ольга не может просто указать пароль в теле письма. Чтобы пароль оставался секретом, о нём нельзя говорить открыто, нужно лишь дать собеседнику знать, что пароль известен отправителю.
Протокол Kerberos решает эту проблему средствами криптографии с секретным ключом. Вместо того, чтобы сообщать друг другу пароль, участники сеанса связи обмениваются криптографическим ключом, знание которого подтверждает личность собеседника. Но чтобы такая технология оказалась работоспособной, необходимо, чтобы общий ключ был симметричным, т.е., он должен обеспечивать как шифрование, так и дешифрование информации. Тогда один из участников использует его для шифрования данных, а другой с помощью этого ключа извлекает их.
Аутентификаторы.
Простой протокол аутентификации с секретным ключом вступает в действие, когда кто-то стучится в сетевую дверь и просит впустить его. Чтобы доказать своё право на вход, пользователь предъявляет аутентификатор (authenticator) в виде набора данных, зашифрованного секретным ключом. Получив аутенитификатор, привратник расшифровывает его и проверяет полученную информацию, чтобы убедиться в успешности дешифрования. Разумеется, содержание набора данных должно постоянно меняться, иначе злоумышленник может просто перехватить пакет и воспользоваться его содержимым для входа в систему. Если проверка прошла успешно, то это значит, что посетителю известен секретный код, а так как этот код знает только он и привратник, следовательно, пришелец на самом деле тот, за кого себя выдаёт.
Может случиться и так, что посетитель захочет провести взаимную аутентификацию. В этом случае используется тот же самый протокол, но с некоторыми изменениями и в обратном порядке. Теперь привратник извлекает из исходного аутентификатора часть информации, а затем шифрует её, превращая в новый аутентификатор, и передаёт обратно посетителю. Тот, в свою очередь, расшифровывает информацию и сравнивает её с исходной. Если всё совпадает — значит, привратник знает секретный ключ.
Теперь вернёмся обратно к нашему примеру. Допустим, что Ольга и Стас договорились: перед тем, как пересылать информацию между своими компьютерами, они с помощью известного только им двоим секретного ключа будут проверять, кто находится на другом конце линии. Вот как это будет выглядеть:
- Ольга посылает Стасу сообщение, содержащее её имя в открытом виде и аутентификатор, зашифрованный с помощью секретного ключа. В протоколе аутентификации такое сообщение представляет собой структуру данных с двумя полями. Первое поле содержит имя, второе поле — текущее время на рабочей станции Ольги.
- Стас получает сообщение и видит, что оно пришло от кого-то, кто называет себя Ольгой. Он использует секретный ключ и дешифрует время отправления сообщения. Задача Стаса сильно упрощается, если его компьютер работает синхронно с компьютером Ольги, поэтому предположим, что часы на компьютерах Стаса и Ольги никогда не расходятся больше, чем на пять минут. В этом случае Стас может сравнить расшифрованное время со временем на своих часах, и, если разница составит более пяти минут, он откажется признавать подлинность аутентификатора. Если же время оказывается в пределах допустимого отклонения, то можно с большой долей уверенности предположить, что аутентификатор поступил именно от Ольги.
- Стас шифрует время из сообщения Ольги и включает его в собственное сообщение, которое отправляет Ольге.
Обратите внимание, что Стас возвращает Ольге не всю информацию из её аутентификатора, а только время. Если бы он отправил всё сртазу, то у Ольги могло бы зародиться подозрение, что кто-то, притворившись Стасом, просто скопировал аутентификатор из её исходного сообщения и без изменений отправил его назад. - Ольга получает ответ Стаса, дешифрует его, и сравнивает полученное время со временем, которое было указано в исходном аутентификаторе. Если оно совпадает, то человек на другом конце смог расшифровать её сообщение, а значит, он знает секретный ключ. А так как ключ знает только Ольга и Стас, то это означает, что именно Стас получил сообщение Ольги и ответил на него.
Управление ключами.
При использовании простых протоколов, типа описанного выше, возникает одна важная проблема. В случае со Стасом и Ольгой мы ни слова не сказали о том, как и где они договаривались о секретном ключе для своей переписки. Конечно, люди могут просто встретиться в парке и обсудить все детали, но ведь в сетевых переговорах участвуют машины. Если под Ольгой понимать клиентскую программу, установленную на рабочей станции, а под Стасом — службу на сетевом сервере, то встретиться они никак не могут. Проблема ещё более осложняется в тех случаях, когда Ольге-клиенту нужно посылать сообщения на несколько серверов, в этом случае для каждого сервера её придётся обзавестись отдельным ключом. Да и службе по имени Стас потребуется столько секретных ключей, сколько у него клиентов. Если каждому клиенту для поддержания связи с каждой службой требуется индивидуальный ключ, и такой же ключ нужен каждой службе для каждого клиента, то проблема обмена ключами быстро приобретает предельную остроту. Необходимость хранения и защиты такого множества ключей на огромном количестве компьютеров создаёт невероятный риск для всей системы безопасности.
Само название протокола Kerberos говорит о том, как здесь решена проблема управления ключами. Кербер (или Цербер) — персонаж классической греческой мифологии. Этот свирепый пёс о трёх головах, по поверьям греков, охраняет врата подземного царства мёртвых. Трём головам Кербера в протоколе Kerberos соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет так называемый центр распределения ключей Key Distribution Center, KDC.
KDC представляет собой службу, работающую на физически защищённом сервере. Она ведёт базу данных с информацией об учётных записях всех главных абонентов безопасности своей области. Вместе с информацией о каждом абоненте безопасности в базе данных KDC сохраняется криптографический ключ, известный только этому абоненту и службе KDC. Этот ключ, который называют долговременным, используется для связи пользователя системы безопасности с центром распределения ключей. В большинстве практических реализаций протокола Kerberos долговременные ключи генерируются на основе пароля пользователя, указываемого при входе в систему.
Когда клиенту нужно обратиться к серверу, он прежде всего направляет запрос в центр KDC, который в ответ направляет каждому участнику предстоящего сеанса копии уникального сеансового ключа (session key), действующие в течение короткого времени. Назначение этих ключей — проведение аутентификации клиента и сервера. Копия сеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключа этого сервера, а направляемая клиенту — долговременного ключа данного клиента.
Теоретически, для выполнения функций доверенного посредника центру KDC достаточно направить сеансовые ключи непосредственно абонентам безопасности, как показано выше. Однако на практике реализовать такую схему чрезвычайно сложно. Прежде всего, серверу пришлось бы сохранять свою копию сеансового ключа в памяти до тех пор, пока клиент не свяжется с ним. А ведь сервер обслуживает не одного клиента, поэтому ему нужно хранить пароли всех клиентов, которые могут потребовать его внимания. В таких условиях управление ключами требует значительной затраты серверных ресурсов, что ограничивает масштабируемость системы. Нельзя забывать и о превратностях сетевого трафика. Они могут привести к тому, что запрос от клиента, уже получившего сеансовый пароль, поступит на сервер раньше, чем сообщение KDC с этим паролем. В результате серверу придется повременить с ответом до тех пор, пока он не получит свою копию сеансового пароля. То есть, нужно будет сохранить состояния сервера, а это накладывает на его ресурсы еще одно тяжкое бремя. Поэтому на практике применяется другая схема управления паролями, которая делает протокол Kerberos гораздо более эффективным. Ее описание приводится ниже.
Сеансовые мандаты.
В ответ на запрос клиента, который намерен подключиться к серверу, служба KDC направляет обе копии сеансового ключа клиенту. Сообщение, предназначенное клиенту, шифруется посредством долговременного ключа, общего для данного клиента и KDC, а сеансовый ключ для сервера вместе с информацией о клиенте вкладывается в блок данных, получивший название сеансового мандата (session ticket). Затем сеансовый мандат целиком шифруется с помощью долговременного ключа, который знают только служба KDC и данный сервер. После этого вся ответственность за обработку мандата, несущего в себе шифрованный сеансовый ключ, возлагается на клиента, который должен доставить его на сервер.
Обратите внимание, что в данном случае функции службы KDC ограничиваются генерацией мандата. Ей больше не нужно следить за тем, все ли отправленные сообщения доставлены соответствующим адресатам. Даже если какое-нибудь из них попадет не туда, — ничего страшного не случится. Расшифровать клиентскую копию сеансового ключа может только тот, кто знает секретный долговременный ключ данного клиента, а чтобы прочесть содержимое сеансового мандата, нужен секретный код сервера.
Получив ответ KDC, клиент извлекает из него мандат и свою копию сеансового ключа, которые помещает в безопасное хранилище (оно располагается не на диске, а в оперативной памяти). Когда возникает необходимость связаться с сервером, клиент посылает ему сообщение, состоящее из мандата, который по-прежнему зашифрован с применением долговременного ключа этого сервера, и собственного аутентификатора, зашифрованного посредством сеансового ключа. Этот мандат в комбинации с аутентификатором как раз и составляет удостоверение, по которому сервер определяет "личность" клиента.
Сервер, получив "удостоверение личности" клиента, прежде всего с помощью своего секретного ключа расшифровывает сеансовый мандат и извлекает из него сеансовый ключ, который затем использует для дешифрования аутентификатора клиента. Если все проходит нормально, делается заключение, что удостоверение клиента выдано доверенным посредником, то есть, службой KDC. Клиент может потребовать у сервера проведения взаимной аутентификации. В этом случае сервер с помощью своей копии сеансового ключа шифрует метку времени из аутентификатора клиента и в таком виде пересылает ее клиенту в качестве собственного аутентификатора.
Одно из достоинств применения сеансовых мандатов состоит в том, что серверу не нужно хранить сеансовые ключи для связи с клиентами. Они сохраняются в кэш-памяти удостоверений (credentials cache) клиента, который направляет мандат на сервер каждый раз, когда хочет связаться с ним. Сервер, со своей стороны, получив от клиента мандат, дешифрует его и извлекает сеансовый ключ. Когда надобность в этом ключе исчезает, сервер может просто стереть его из своей памяти.
Такой метод дает и еще одно преимущество: у клиента исчезает необходимость обращаться к центру KDC перед каждым сеансом связи с конкретным сервером. Сеансовые мандаты можно использовать многократно. На случай же их хищения устанавливается срок годности мандата, который KDC указывает в самой структуре данных. Это время определяется политикой Kerberos для конкретной области. Обычно срок годности мандатов не превышает восьми часов, то есть, стандартной продолжительности одного сеанса работы в сети. Когда пользователь отключается от нее, кэш-память удостоверений обнуляется и все сеансовые мандаты вместе с сеансовыми ключами уничтожаются.
Мандаты на выдачу мандатов.
Как уже отмечалось, долговременный ключ пользователя генерируется на основе его пароля. Чтобы лучше понять это, вернемся к нашему примеру. Когда Ольга проходит регистрацию, клиент Kerberos, установленный на ее рабочей станции, пропускает указанный пользователем пароль через функцию одностороннего хеширования (все реализации протокола Kerberos 5 должны обязательно поддерживать алгоритм DES-CBC-MD5, хотя могут применяться и другие алгоритмы). В результате генерируется криптографический ключ.
В центре KDC долговременные ключи Ольги хранятся в базе данных с учетными записями пользователей. Получив запрос от клиента Kerberos, установленного на рабочей станции Ольги, KDC обращается в свою базу данных, находит в ней учетную запись нужного пользователя и извлекает из соответствующего ее поля долговременный ключ Ольги.
Такой процесс — вычисление одной копии ключа по паролю и извлечение другой его копии из базы данных — выполняется всего лишь один раз за сеанс, когда пользователь входит в сеть впервые. Сразу же после получения пользовательского пароля и вычисления долговременного ключа клиент Kerberos рабочей станции запрашивает сеансовый мандат и сеансовый ключ, которые используются во всех последующих транзакциях с KDC на протяжении текущего сеанса работы в сети.
На запрос пользователя KDC отвечает специальным сеансовым мандатом для самого себя, так называемый мандат на выдачу мандатов (ticket-granting ticket), или мандат TGT. Как и обычный сеансовый мандат, мандат TGT содержит копию сеансового ключа для связи службы (в данном случае — центра KDC) с клиентом. В сообщение с мандатом TGT также включается копия сеансового ключа, с помощью которой клиент может связаться с KDC. Мандат TGT шифруется посредством долговременного ключа службы KDC, а клиентская копия сеансового ключа — с помощью долговременного ключа пользователя.
Получив ответ службы KDC на свой первоначальный запрос, клиент дешифрует свою копию сеансового ключа, используя для этого копию долговременного ключа пользователя из своей кэш-памяти. После этого долговременный ключ, полученный из пользовательского пароля, можно удалить из памяти, поскольку он больше не понадобится: вся последующая связь с KDC будет шифроваться с помощью полученного сеансового ключа. Как и все другие сеансовые ключи, он имеет временный характер и действителен до истечения срока действия мандата TGT, либо до выхода пользователя из системы. По этой причине такой ключ называют сеансовым ключом регистрации (logon session key).
С точки зрения клиента мандат TGT почти ничем не отличается от обычного. Перед подключением к любой службе, клиент прежде всего обращается в кэш-память удостоверений и достает оттуда сеансовый мандат нужной службы. Если его нет, он начинает искать в этой же кэш-памяти мандат TGT. Найдя его, клиент извлекает оттуда же соответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор, который вместе с мандатом TGT высылает в центр KDC. Одновременно туда направляется запрос на сеансовый мандат для требуемой службы. Другими словами, организация безопасного доступа к KDC ничем не отличается от организации такого доступа к любой другой службе домена — она требует сеансового ключа, аутентификатора и мандата (в данном случае мандата TGT).
С точки же зрения службы KDC, мандаты TGT позволяют ускорить обработку запросов на получением мандатов, сэкономив несколько наносекунд на пересылке каждого из них. Центр распределения ключей KDC обращается к долговременному ключу пользователя только один раз, когда предоставляет клиенту первоначальный мандат на выдачу мандата. Во всех последующих транзакциях с этим клиентом центр KDC дешифрует мандаты TGT с помощью собственного долговременного ключа и извлекает из него сеансовый ключ регистрации, который использует для проверки подлинности аутентификатора клиента.
Заключение.
Выше мы рассмотрели основные концепции протокола сетевой аутентификации Kerberos 5. Следует отметить, что этот протокол отличается гибкостью и эффективностью использования, а также обеспечивает повышенный уровень безопасности. С бурным развитием Интернета, локальных сетей, виртуальных частных сетей, электронной коммерции, этот протокол, похоже, является одним из тех, которые удовлетворяют всем требованиям безопасности в сегодняшней информационной среде. Поэтому неудивительно, что разработчики программного обеспечения уделяют ему повышенный интерес. Создатели протокола ведут постоянную работу по его совершенствованию, а компания Microsoft в операционной системе Windows2000 сделала этот протокол основным протоколом аутентификации.
Для простоты изложения в статье опущены многие моменты, например, аутентификация за пределами области Kerberos, описание подпротоколов. Дополнительную информацию по этим вопросам можно получить из указанных в начале статьи источников.
