Информационная безопасность и защита информации Ю. А. Смолий Система Kerberos ЛЕКЦИЯ 8 Kerberos Kerberos представляет собой разработанный прежде всего для сетей TCP/IP протокол аутентификации с доверенной третьей стороной, действующей как доверенный посредник, обеспечивающий проверку подлинности пользователей и сетевых объектов. Принципы построения 1. Kerberos построен на архитектуре клиент-сервер. 2. Все процедуры аутентификации выполняются между клиентами и серверами сети через посредника, которому доверяют все участники идентификационного процесса – таким посредником является сама система Kerberos; 3. в системе Kerberos клиент должен доказывать свою аутентичность для доступа к каждой службе (серверу), услугами которой он намерен воспользоваться; 4. все обмены в сети выполняются в защищенном виде с использованием симметричной криптосистемы. Участники системы Ресурсный сервер Kerberos-сервер, Key Distribution Center (KDC) или Ticket Granting Server (TGS) Kerberos-клиент Функции Kerberos-сервера (KDC) • Ведение БД с информацией об учётных записях всех абонентов. • Вместе с информацией о каждом абоненте безопасности в базе данных KDC сохраняется криптографический ключ, известный только этому абоненту и службе KDC. Этот ключ, который называют долговременным, используется для связи пользователя системы безопасности с центром распределения ключей. Kerberos-система малого масштаба Задача KDC – выдача сеансовых ключей обеим сторонам Запрос Session key сервера Session key клиента Клиент KDC Ресурсный сервер Недостатки схемы Сложность масштабирования, обсусловленная: • Необходимостью хранить на сервере все сеансовые ключи всех пользователей, обратившихся в KDC до момента непосредственного их обращения на сервер за ресурсами; • Необходимостью сохранять обращения клиентов за ресурсами с недействительными сеансовыми ключами (возможно, сеансовый ключ от KDC клиенту дошел быстрее, чем серверу, поэтому пользователь обращается на самом деле с действительным ключом; нужна реализация ожидания получения сеансового ключа от KDC). Вход пользователя в систему 1. Пользователь вводит имя и пароль на клиентской машине. 2. Клиентская машина выполняет над паролем одностороннюю функцию (обычно хэш), и результат становится секретным ключом клиента/пользователя. Kerberos-система с сеансовыми мандатами Ответ сервера содержит зашифрованные на долговременном ключе клиента: • Сеансовый ключ клиента; • Зашифрованный на долговременном ключе сервера сеансовый мандат (session ticket) – блок данных, включающий в себя сеансовый ключ для сервера вместе с информацией о клиенте. Запрос Session key клиента и Session key сервера Клиент Сеановый мандат KDC Ресурсный сервер В случае ошибок KDC Расшифровать клиентскую копию сеансового ключа может только тот, кто знает секретный долговременный ключ данного клиента, а чтобы прочесть содержимое сеансового мандата, нужен секретный код сервера. Действия клиента • Получив ответ KDC, клиент извлекает из него мандат и свою копию сеансового ключа, которые помещает в безопасное хранилище. • Когда возникает необходимость связаться с сервером, клиент посылает ему сообщение, состоящее из мандата, который попрежнему зашифрован с применением долговременного ключа этого сервера, и собственного аутентификатора, зашифрованного посредством сеансового ключа. Этот мандат в комбинации с аутентификатором как раз и составляет удостоверение, по которому сервер определяет "личность" клиента. Действия сервера • Сервер, получив "удостоверение личности" клиента с помощью своего секретного ключа расшифровывает сеансовый мандат и извлекает из него сеансовый ключ, который затем использует для дешифрования аутентификатора клиента. Если все проходит нормально, делается заключение, что удостоверение клиента выдано доверенным посредником, то есть, службой KDC. • Клиент может потребовать у сервера проведения взаимной аутентификации. В этом случае сервер с помощью своей копии сеансового ключа шифрует метку времени из аутентификатора клиента и в таком виде пересылает ее клиенту в качестве собственного аутентификатора. Преимущества мандатной системы • Функции службы KDC ограничиваются генерацией мандата. Ей больше не нужно следить за тем, все ли отправленные сообщения доставлены соответствующим адресатам. • Серверу не нужно хранить сеансовые ключи для связи с клиентами. Они сохраняются в кэш-памяти удостоверений (credentials cache) клиента, который направляет мандат на сервер. Использованные сеансовые ключи на серверной стороне уничтожаются. • у клиента исчезает необходимость обращаться к центру KDC перед каждым сеансом связи с конкретным сервером. Сеансовые мандаты можно использовать многократно (мандаты имеют срок годности, указанные в самом мандате и определяемые сервером – обычно не более 8 часов. При выходе пользователя из системы Kerberos кэш-память удостоверений обнуляется, сеансовые мандаты вместе с сеансовыми ключами уничтожаются). Работа клиента с системой Долговременный ключ клиента генерируется на основе его пароля. Обычно ключ является результатом хэширования пароля. В центре KDC долговременные ключи абонентов хранятся в базе данных с учетными записями пользователей. Первичная идентификация клиента (вход в сеть): 1. Клиент Kerberos посылает запрос KDC, тот находит в своей БД учетную запись нужного пользователя и его долговременный ключ. 2. Клиент Kerberos запрашивает сеансовый мандат и сеансовый ключ, которые используются во всех последующих транзакциях с KDC на протяжении текущего сеанса работы в сети. Мандат на выдачу мандатов 1. KDC выдает пользователю специальный сеансовый мандат для самого себя - мандат на выдачу мандатов (ticket-granting ticket), или мандат TGT. Мандат TGT содержит копию сеансового ключа для связи KDC с клиентом. В сообщение с мандатом TGT также включается копия сеансового ключа, с помощью которой клиент может связаться с KDC. Мандат TGT шифруется посредством долговременного ключа службы KDC, а клиентская копия сеансового ключа — с помощью долговременного ключа пользователя. 2. Далее клиент дешифрует свою копию сеансового ключа, используя для этого копию долговременного ключа пользователя из своей кэш-памяти. Вся последующая связь с KDC будет шифроваться с помощью полученного сеансового ключа, который имеет временный характер и действителен до истечения срока действия мандата TGT, либо до выхода пользователя из системы. По этой причине такой ключ называют сеансовым ключом регистрации (logon session key). 3. Перед подключением к любой службе, клиент прежде всего обращается в кэш-память удостоверений и достает оттуда сеансовый мандат нужной службы. Если его нет, он начинает искать в этой же кэш-памяти мандат TGT. Найдя его, клиент извлекает оттуда же соответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор, который вместе с мандатом TGT высылает в центр KDC. Одновременно туда направляется запрос на сеансовый мандат для требуемой службы. Что дает TGT? • При взаисмодействии с пользователем KDC не нужно каждый раз искать в памяти долговременный ключ этого пользователя, после первого обращения пользователя все последующие обращения осуществляются в форме мандатов, уже содержащих в себе сеансовый ключ, зашифрованный на долговременном ключе KDC. Особенности Kerberos • Доменная структура. Необходимость осуществления междоменной аутентификации. • Централизованное хранение ключей. Самое уязвимое место системы – Kerberos-сервер. Дальнейшая работа 25 мая – консультация (по запросу), 15:15 практика, 17:00 1 июня – проставление «автоматов», 15:15 зачёт, 15:30 Письменная форма, билеты совпадают с вопросами для подготовки. Проверка при студенте. Аутентификация на основе сертификатов ЛЕКЦИЯ 9 Почему нужны сертификаты? При работе в сетях, когда число пользователей очень велико и может измеряться миллионами, процедура предварительной регистрации пользователей, связанная с назначением и последующим хранением их паролей становится крайне обременительной, опасной, а иногда и просто нереализуемой. Задача сертификата – переложить заботы о хранении ключевой информации на плечи пользователей. Сертификат Сертификат представляет собой электронную форму, в которой содержится следующая информация: • открытый ключ владельца данного сертификата; • сведения о владельце сертификата (ФИО, организация, в которой он работает, должность, адрес электронной почты и др.); • наименование сертифицирующей организации, выдавшей данный сертификат; • электронная цифровая подпись сертифицирующей организации (зашифрованные тайным ключом этой организации данные, содержащиеся в сертификате). Выдача сертификатов Сертификаты выдаются специальными уполномоченными организациями – центрами сертификации(Certificate Authority). Использование сертификатов основывается на предположении, что сертифицирующих центров немного, они вызывают доверие, а их открытые ключи известны и легко доступны. Действия пользователя, этап 1. Пользователь предъявляет сертификат в двух формах – открытой, такой, в которой он получил его в сертифицирующей организации, и в зашифрованной с применением своего тайного ключа. Сторона, проводящая аутентификацию, берет из открытого сертификата открытый ключ и с его помощью расшифровывает зашифрованный сертификат. Совпадение результата с открытым сертификатом подтверждает факт, что предъявитель сертификата действительно является владельцем тайного ключа, парного с открытым. Следовательно, этот этап аутентификации выполнен успешно. Действия пользователя, этап 2. С помощью известного открытого ключа указанной в сертификате организации проводится расшифровка подписи этой организации в сертификате. Если в результате получается тот же сертификат, с тем же именем пользователя и его открытым ключом – значит, этот пользователь действительно прошел регистрацию в сертификационном центре, является тем, за кого себя выдает и указанный в сертификате открытый ключ принадлежит именно ему. Особенности технологии • Сертификат является одновременно и удостоверением личности и удостоверением принадлежности открытого ключа. Он гарантирует соответствие между открытым ключом и его владельцем, что предотвращает угрозу подмены открытого ключа. При этом никто кроме владельца сертификата, даже центр сертификации, не знает тайного ключа этого владельца. Особенности технологии • При использовании технологии сертификатов не требуется на каждом ресурсном сервере хранить список пользователей с их паролями. Вместо этого достаточно иметь список заслуживающих доверия сертифицирующих организаций и их открытые ключи. • Сертификаты можно использовать не только для аутентификации, но и для предоставления избирательных прав доступа. Для этого в сертификат могут вводиться дополнительные поля, определяющие принадлежность его владельца определенной категории пользователей. Эта категория назначается сертифицирующей организацией в зависимости от условий, на которых выдается сертификат. Проблемы • Поддержание базы данных со сведениями о выданных сертификатах. Сертификат выдается не навсегда, а на некоторый вполне определенный срок, по истечении которого он либо аннулируется, либо обновляется. • Обеспечение возможности досрочного прекращения полномочий сертификата. Все заинтересованные участники информационного обмена должны быть вовремя оповещены о том, что некоторый сертификат уже не действителен. Для этого сертифицирующая организация должна оперативно поддерживать список аннулированных сертификатов, а ресурсные серверы предпринимать дополнительные меры по проверке вхождения предъявляемых сертификатов в этот список. • Вопрос доверия центрам сертификации, которых может быть достаточно много. Как проверить полномочия сертифицирующего центра? Как организовать совместное использование сертификатов, выпущенными различными сертифицирующими организациями? Можно ли создать иерархию сертифицирующих центров, когда заслуживающий доверия сертификационный центр может сертифицировать центры, расположенные ниже по иерархии?