Kerberos: Сторожевой пёс Эфира
Автор: (C) 2002 Raj Shekhar
Перевод: (C) 2003 Юрий Прушинский

Вступление

Первые компьютерные сети использовались в основном для обмена электронной почтой, файлами и совместного использования принтеров между сотрудниками корпораций. При таком сценарии безопасность не играет большой роли. Однако, сейчас сети (особенно Internet) используются миллионами пользователей для совершения банковских операций, покупок и заполнения деклараций о доходах и других операций, и здесь безопасность становится основной проблемой. Сетевую безопасность можно разделить на несколько зон.

Секретность

Секретность связана с сокрытием информации от любопытных глаз посторонних людей.

Идентификация

Идентификация связана с определением подлинности вашего партнера по общению, т.е. действительно ли он тот за кого себя выдает.

Проверка подлинности

Проверка подлинности информации связана с подписями: в её задачу входит однозначное определение отправителя файла или сообщения. Например, как вы сможете доказать, что получили заказ на 10 миллионов ботинок на левую ногу, когда их заказчик утверждает, что он заказал 10 штук на правую ногу!

Проверка целостности

Проверка целостности гарантирует, что ваша жизненно важная информация не была искажена в процессе передачи. Проверки такого рода наиболее важны при организации коммерческой деятельности в Интернете. Без обеспечения целостности и сохранности информации могут быть искажены заказы на поставки, контракты или заказы на покупку ценных бумаг, что может привести к катастрофическим последствиям.

Необходимость в идентификации

Для чего нам могут понадобится службы идентификации? Служба идентификации проверяет подлинность партнера по общению, поэтому идентификация является фундаментальным блоком при построении безопасного сетевого окружения. Если сервер совершенно точно идентифицирует своего клиента, то он знает, имеет ли тот право на доступ к соответствующим сервисам (например, печати) или нет, или на получение особых привилегий и т.п. Следует также различать понятия идентификация и авторизация. Если пользователь Foo говорит "удалить файл bar", то здесь процесс проверки того, что эту команду выполнил пользователь Foo называется идентификацией. А вот процесс проверки наличия у пользователя Foo прав на удаление файла bar называется авторизацией.

Давайте рассмотрим пример из жизни. Например, некая Алиса желает провести сделку с Бобом, своим банкиром. В жизни Алиса и Боб могут узнать друг друга по лицу, голосу и почерку. Но поскольку они будут общаться по сети, то никакой из указанных способов здесь не подходит. Как тогда Боб сможет определить, что запрос на перевод всех сбережений Алисы на секретный счет в швейцарском банке пришел именно от Алисы, а не от Евы?

Здесь в игру вступает служба идентификации. Алиса отправляет сообщение Бобу. Поскольку сообщение пересылается, то теоретически мы можем рассматривать Еву как нарушителя, который может перехватить, изменить и переиграть всю переписку Алисы и Боба. Тем не менее, когда идентификация завершена, Алиса уверена, что общается с Бобом, а Боб, в свою очередь, уверен, что общается с Алисой.

Введение в Kerberos

Kerberos был разработан в Массачусетском Технологическом Институте как средство для обеспечения сетевой безопасности. Своими корнями он уходит в проект "Афина", начатый ещё в 1983г. Его целью было создание высокоскоростной вычислительной сети в среде высокопроизводительных графических рабочих станций и серверов разных типов. При этом проект использовал Kerberos в качестве своей системы идентификации. Название Kerberos было заимствовано из греческой мифологии, в которой Kerberos - имя трёхголового пса, охраняющего врата в Гадес (подземное царство теней - прим.перев.). Протокол Kerberos использует настолько сильную систему шифрования, что клиент может идентифицироваться сервером (и наоборот) даже при небезопасном сетевом соединении. После того как клиент и сервер пройдут процедуру взаимной идентификации посредством Kerberos, они смогут шифровать весь свой трафик для обеспечения безопасности и целостности данных.

Цитата с http://web.mit.edu/Kerberos/www/

Большинство протоколов, использующихся в Интернете, не обеспечивают какой-либо безопасности вообще. Это привело к тому, что системными взломщиками в сети очень широко применяются "сниферы" паролей. Таким образом, любое приложение, отправляющее пароль в незашифрованном виде очень уязвимо. Хуже того, многие клиент-серверные приложения полагаются на "честность" клиентской программы и личность пользователя, использующего её. Другие же приложения полагаются на то, что клиенты сами будут контролировать дозволенность своих действий, без какой-либо проверки со стороны сервера.

Основной реализацией и структурой Kerberos от первой до четвёртой версий занимались двое бывших участников проекта "Афина", Стив Миллер из Digital Equipment Corporation, и Клиффорд Ньюман (сейчас работает в Институте Информационных Наук Университета Южной Калифорнии), а также Джером Салтцер, технический директор проекта "Афина", и Джеффри Шиллер, администратор сети университетского городка MIT. Кроме этого, другие участники проекта "Афина" тоже приложили усилия к развитию Kerberos. Последняя версия Kerberos 4 имеет patch level 10, и официально объявлена MIT "мертвой", вся дальнейшая работа сосредоточена вокруг Kerberos 5, последняя версия 1.2.1.

Для начала немного терминологии

Искусство создания шифров принято называть криптографией (cryptography), а их взлом - криптоанализом (cryptanalysis). Всё вместе это называется криптологией (cryptology). Сообщение, подлежащее шифрованию, называют открытым, или не зашифрованным текстом (plaintext or cleartext). Открытый текст шифруется по функции, параметром которой является ключ (key). Всё, что получается на выходе процесса шифрования, называется шифрованным текстом (ciphertext). Когда шифрованный текст проходит через функцию декодирования (decryption function), то мы получаем обратно открытый текст. Возвращаясь к нашей истории Алисы и Боба, то их (Алису и Боба) можно назвать участниками сессии (principals), главными персонажами этой истории.

Ключ шифрования иногда ещё называют ключом дешифрования, что то же самое. Этот ключ известен только доверителям. Его ещё называют разделяемый секретный ключ (shared secret key). Но тем не менее, в криптосистеме, предложенной Диффи и Хелманом (исследователи из Стэнфордского Университета) в 1976г., ключ шифрования и ключ дешифрования - разные вещи. Ключ, используемый для шифрования, становится публичным, таким образом сообщения, посылаемые владельцу этого ключа шифруются при помощи публичного ключа. Такой ключ называется открытым ключом (public key). Также, каждый пользователь имеет свой личный ключ (private key), известный только самому пользователю, и использующийся для дешифрации сообщений, получаемых пользователем. В отличие от криптографии с разделяемым ключом, такая система называется криптографией с открытым ключом (public-key cryptography). Алгоритм RSA является примером криптографии с открытым ключом. [Или алгоритмом шифрования с ассиметричным ключом. Прим.ред.]

И ещё чуть-чуть ...

Перед тем как описывать процесс идентификации, необходимо избавиться от неопределенности и двусмысленности в используемых терминах.

Довольно часто сетевые приложения реализованы из двух частей:

• часть, которая запрашивает сервис, называется клиентской стороной приложения
• часть, которая предоставляет сервис, называется серверной стороной приложения

В известном смысле, каждый объект, использующий систему Kerberos, является клиентом. Чтобы различать между клиентом Kerberos и клиентом службы, клиент, использующий службу Kerberos, называется клиентом Kerberos (Kerberos client). Термин сервер приложения (application server) обозначает серверную часть приложения, к которой обращаются клиенты, прошедшие идентификацию по Kerberos.

Kerberos -- это доверенная сторонняя система идентификации (third party authentication system). Доверенная в том смысле, что каждый клиент доверяет тому, с какой точностью Kerberos идентифицирует всех клиентов. Чтобы доказать серверу приложения, что Kerberos-клиент проверен Kerberos-сервером, он использует квитанцию (ticket). Квитанция необходима для того чтобы Kerberos-клиент смог воспользоваться любым сервером приложения. Сервер проверяет квитанцию, чтобы удостовериться в том, что пользователь идентифицирован. Если проверка пройдена, то запрос клиента принимается. Наряду с квитанцией, в Kerberos для подтверждения личности клиента применяются удостоверения (authenticator). Удостоверение содержит дополнительную информацию, которая при сравнении подтверждает то, что клиент, предоставляющий квитанцию, является именно тем, кому эта квитанция была действительно выдана.

Kerberos ведёт базу данных своих клиентов и их личных ключей для идентификации. Из-за того, что Kerberos "знает" эти личные ключи, он может создавать сообщения, по которым один клиент может быть уверен в подлинности другого. Разработчики и не ожидают того, что весь мир будет доверять единой базе данных, поэтому они предусмотрели использование различных зон (realms). Зона -- это административный объект, предоставляющий идентификационные данные. Любая организация, желающая иметь собственный Kerberos-сервер, организует свою "зону"

Переходим к деталям

Kerberos предполагает, что ни одному Kerberos-клиенту нельзя доверять и требует от клиента идентификации каждый раз при запросе сервиса от клиента. Технология, используемая в Kerberos довольно проста, и основывается на следующих положениях:

• Пароли по сети никогда не отсылаются открытым текстом, они всегда шифруются. Кроме того, они не хранятся в открытом виде ни у Kerberos-клиентов, ни на сервере.
• Каждый клиент имеет свой пароль, т.е. пароль есть у каждого сервера приложений, пользователя и Kerberos-клиента.
• Единственный объект, который знает все пароли -- это Kerberos-сервер, который находится в достаточной физической безопасности.

И клиент, и сервер приложения обязаны зарегистрировать свои ключи на сервере идентификации (СИ). Если клиент -- это пользователь, то его ключ определяется паролем, который он выбирает. Для службы (например, демон печати) ключом является случайно сгенерированное значение. Все эти ключи устанавливаются в процессе регистрации клиентов.

Процесс идентификации происходит следующим образом:

1. Клиент отправляет серверу идентификации запрос на "мандат" для сервера приложения. Мандат состоит из квитанции для сервера и ключа для сессии. Кроме прочих полей, квитанция содержит имя сервера, имя клиента, Интернет-адрес клиента, метку даты создания, время жизни и ключ сессии. Эта информация (квитанция) зашифрована при помощи ключа сервера, которому предназначена данная квитанция. После создания, квитанция может быть использована несколько раз указанным клиентом для получения доступа к определённому серверу, до тех пор пока не истечет её время использования.

   Для чего же ставится "метка дата создания". Эта метка необходима для того, чтобы не допустить кому-либо скопировать квитанцию и позднее сымитировать Kerberos-клиента. Этот возможный тип атаки известен как воспроизведение (replay). Из-за того, что часы не всегда работают идеально синхронно, дается небольшая отсрочка (около пяти минут) между меткой даты\времени и текущим временем.

2. СИ отвечает мандатом (квитанция и ключ сессии), зашифрованным ключом клиента. Также СИ вставляет в мандат своё имя, чтобы удостоверить Kerberos-клиента в том, что дешифрация была им [CИ] успешно выполнена и что данное сообщение пришло от сервера.

   СИ не знает, действительно ли клиент является инициатором (principal) запроса на квитанцию. Он просто отвечает на запросы, не зная и не заботясь о том, что они одинаковые. Это вполне допустимо, потому что никто кроме Kerberos-клиента, чья личность была указана в запросе, не сможет воспользоваться ответом. Ко всему прочему эта информация шифруется ключом инициатора запроса.

3. Kerberos-клиент дешифрует мандат при помощи своего ключа для того, чтобы в свою очередь получить ключ сессии. Здесь необходимо учесть, что из-за того, что квитанция шифруется ключом сервера приложения, Kerberos-клиент не может расшифровать его [ключ сессии].
4. Чтобы получить доступ к серверу приложения, Kerberos-клиент строит идентификатор, содержащий имя клиента, его ip-адрес и текущее время. Затем этот идентификатор шифруется ключом сессии, который был получен с квитанцией для сервера, и отсылается вместе с квитанцией серверу.
5. Служба дешифрует эту квитанцию своим ключом, получает ключ сессии и личность Kerberos-клиента, которые сервер указал в квитанции. Затем она открывает идентификатор ключом сессии, и таким образом по идентификатору и квитанции служба получает представление о личности клиента.
6. Ключ сессии (теперь уже известный клиенту и серверу приложения) используется для идентификации клиента, и в свою очередь, может идентифицировать сервер. Более того, его можно применять для последующего шифрования коммуникаций двух сторон или обмена отдельными суб-сессионными ключами, шифрующими последующие переговоры.

Предоставляемая квитанциия

Одним из главных требований к системе Kerberos является ненавязчивость. Но в вышеприведенном обмене, Kerberos-клиент должен вводить пароль каждый раз когда необходимо расшифровать мандат, полученный от СИ. Если Kerberos-клиентом будет пользователь, то его несомненно будет раздражать, если он будет каждый раз вводить пароль, чтобы распечатать файл или, если он захочет изменить файл по сети (помните что ключ получается из пароля пользователя?). Наиболее простое решение этой проблемы - кеширование ключей, полученных из пользовательских паролей. Но кеширование ключей опасно. При помощи копии ключа, злоумышленник может имитировать пользователя любое время (до первой смены пароля).

Для решения этой проблемы в Kerberos присутствует специальный агент, называющийся сервером предоставления квитанций (СПК). Несмотря на то, что СПК и СИ могут физически располагаться на одной машине, логически они отличаются друг от друга (в паре их часто называют Центром Распределения Ключей - ЦРК). Функция СПК состоит в следующем: перед тем как получить доступ к любой службе, пользователь запрашивает квитанцию у СПК. Обычно это происходит при входе пользователя в систему. Такая квитанция называется предоставляемой квитанцией (ПК) (ticket granting ticket -- TGT). После получения ПК, в любой момент обращения пользователя к любой службе, он запрашивает квитанцию не у СИ, а у СПК. Далее, ответ шифруется уже не секретным ключом пользователя, а ключом сессии, который СИ предоставляет СПК. В этот ответ вкладывается новый ключ сессии для использования службой. Последующий обмен происходит как было описано выше. Следует отметить, что СПК удобно использовать только на короткий период, примерно на восемь часов.

Межзональная идентификация

При разработке Kerberos учитывалась также и возможность взаимодействия за пределами организации. Другими словами, клиент в одной организации может быть идентифицирован сервером другой организации. Каждая организация, желающая иметь свой собственный сервер Kerberos создает также собственную "зону". Имя зоны, в которой зарегистрирован клиент, является частью имени этого клиента, и поэтому может использоваться сервером приложения для принятия решения давать ли клиенту ответ или нет.

При создании "межзональных" ключей, администраторы обеих зон могут разрешить клиенту, идентифицированному в локальной зоне, также идентифицировать себя и в другой зоне. При обмене межзональными ключами СПК своей зоны выступает как участник сессии в другой. Так клиент, находясь в своей зоне, имеет возможность получить предоставляемую квитанцию для СПК другой зоне. При использовании такой предоставляемой квитанции, СПК другой зоны использует межзональный ключ (который обычно отличен от его собственного ключа СПК) для дешифрации этой предоставляемой квитанции, и таким образом удостоверяется, что он действительно был создан СПК данного клиента. Таким образом, квитанции, созданные удаленным СПК сообщают конечной службе о том, что клиент был идентифицирован из другой зоны.

Заключение

Нельзя полагать, что Kerberos это централизованное решение, способное решить все проблемы сетевой безопасности. В основе системы [Kerberos] лежит принцип наследования: клиент доверяет Kerberos, если система корректно предоставляет клиенту ключ шифрования. Приложение доверяет клиенту, если клиент успешно предоставил квитанцию, зашифрованную ключом сервера. В этом доверии и кроется уязвимость системы.

Другими словами, секретные ключи должны как и полагается, храниться в секрете. Если взломщик каким-либо образом получит ключ инициатора запроса, то он сможет его сымитировать. Kerberos не защищает от атак типа "подбора пароля". Если пользователь использует несложный пароль, то атакующий может спокойно подобрать его атакой по словарю. Kerberos никак не заботится о безопасности клиентов, полагая что все они доверенные пользователи в ненадежной сети. Если безопасность клиента скомпрометирована, то скомпрометирована и сама система Kerberos. Тем не менее, уровень компрометации Kerberos зависит от того, какой узел скомпрометирован. Если атакующий взломал многопользовательскую машину и украл все квитанции, хранящиеся на ней, то следовательно, он может сымитировать тех пользователей, чьи квитанции хранились на этой машине...... но только до тех пор, пока их срок не истечёт.

Raj Shekha

Copyright (c) 2002, Raj Shekhar. Copying license http://www.linuxgazette.com/copying.html
Published in Issue 82 of Linux Gazette, September 2002

Команда переводчиков:
Владимир Меренков, Александр Михайлов, Иван Песин, Сергей Скороходов, Александр Саввин, Роман Шумихин, Александр Куприн, Андрей Киселев, Игорь Яровинский, Юрий Прушинский

Со всеми предложениями, идеями и комментариями обращайтесь к Александру Куприну ([email protected]). Убедительная просьба: указывайте сразу, не возражаете ли Вы против публикации Ваших отзывов в рассылке.

Сайт рассылки: http://gazette.linux.ru.net
Эту статью можно взять здесь: http://gazette.linux.ru.net/lg82/shekhar.html
Архивы выпусков можно взять здесь: http://gazette.linux.ru.net/archive/