8. Лекция: Рекомендации семейства X.500 Основные понятия и идеи рекомендаций семейства X.500
Рекомендации семейства X.500 описывают службу директорий. Среди возможностей, предоставляемых этой службой, обычно выделяют дружественное именование (обращение к объектам по именам, удобным с точки зрения человека) и отображение имен в адреса (динамическое связывание объекта и его расположения - необходимое условие поддержки "самоконфигурируемости" сетевых систем).
Основные понятия службы директорий зафиксированы в рекомендациях X.501 "Служба директорий: модели" [50] и X.511 "Служба директорий: абстрактное определение сервиса" [52].
Множество систем, обеспечивающих функционирование службы директорий, вместе с содержащейся в них информацией можно представлять как единое целое - Директорию с большой буквы.
Информация, доступ к которой возможен посредством Директории, называется Информационной Базой Директории. Она обычно используется для облегчения взаимодействия таких сущностей, как объекты прикладного уровня, люди, списки рассылки и т.д., а также для получения сведений о них.
Предполагается, что Информационная База имеет древовидную структуру, называемую Информационным Деревом Директории. Вершины этого дерева, отличные от корня, составляют элементы Директории, в которых хранится информация об объектах.
У каждого элемента есть однозначно идентифицирующее его различительное имя. В пределах поддеревьев Информационного Дерева могут использоваться относительные различительные имена.
Природа объектов, информация о которых хранится в Директории, произвольна. Единственное требование к ним состоит в идентифицируемости (возможности именования).
Объекты объединяются в классы. Каждый объект должен принадлежать по крайней мере одному классу.
Элементы Директории могут быть составными, объединять подэлементы, содержащие информацию об отдельных аспектах объектов.
Каждый элемент состоит из атрибутов, имеющих тип и одно или несколько значений. Набор атрибутов зависит от класса объекта.
Некоторые из концевых узлов (листьев) Информационного Дерева могут представлять собой синонимы, содержащие альтернативное имя и указатель на элемент с информацией об объекте.
Служба директорий предоставляет две группы операций:
В число операций опроса входят:
чтение значений атрибутов элемента Директории;
сравнение значения атрибута элемента Директории с заданной величиной (полезно, например, для проверки пароля без предоставления доступа к хранимому паролю);
выдача списка (перечисление) непосредственных преемников заданного узла Информационного Дерева;
поиск и чтение элементов, удовлетворяющих заданным фильтрам (условиям), в заданных частях Информационного Дерева;
отказ от незавершенной операции опроса (например, если она выполняется слишком долго).
В группу операций модификации входят:
добавление нового (концевого) узла Информационного Дерева;
удаление концевого узла Информационного Дерева;
модификация элемента Директории с возможным добавлением и/или удалением атрибутов и их значений;
модификация относительного различительного имени элемента или перемещение узла Информационного Дерева к другому предшественнику.
Рекомендации X.501 описывают три возможные схемы управления доступом к Директории: базовую, упрощенную и основанную на правилах; последняя может реализовывать принудительное (мандатное) управление доступом с использованием меток безопасности. Решения о предоставлении доступа принимаются с учетом существующей политики безопасности.
Разумеется, предусмотрена аутентификация системных агентов и пользователей, а также источников данных Директории.
Таковы основные понятия и идеи службы директорий, зафиксированные в семействе рекомендаций X.500 и необходимые нам для последующего изложения.
Каркас сертификатов открытых ключей
Мы приступаем к изучению четвертой редакции рекомендаций X.509 [51], которая регламентирует следующие аспекты:
сертификаты открытых ключей;
сертификаты атрибутов;
сервисы аутентификации.
Идейной основой рекомендаций X.509 являются сертификаты открытых ключей, обслуживающие такие грани информационной безопасности, как конфиденциальность и целостность, и такие сервисы, как аутентификация и неотказуемость.
В курсе "Основы информационной безопасности" [91] приведены необходимые сведения о криптографии с открытыми ключами и механизме электронной цифровой подписи (ЭЦП); далее предполагается, что они уже известны.
Сертификат открытого ключа - это структура данных, обеспечивающая ассоциирование открытого ключа и его владельца. Надежность ассоциации, подлинность сертификата подтверждаются подписью удостоверяющего центра (УЦ).
Сертификаты имеют конечный срок годности. Поддерживать актуальность информации об их статусе помогают списки отзыва, подписываемые удостоверяющими центрами и содержащими перечни сертификатов, переставших быть годными. Последнее может случиться как в результате естественного окончания срока, так и досрочно, например, из-за компрометации секретного ключа владельца.
Формат сертификата описан в курсе [91]. В простейшем случае он выглядит так:
CA <> = CA {V, SN, AI, CA, A, Ap, TA}
Здесь:
Отметим, что в общем случае формат может быть существенно сложнее. С помощью механизма расширений его можно приспособить для нужд различных приложений и сообществ пользователей. В X.509 предусмотрены полезные расширения, носящие универсальный характер.
Каждое расширение включает имя, флаг критичности и значение. Если при обработке (проверке) сертификата встречается неизвестное расширение с флагом критичности FALSE, оно может быть проигнорировано; если же у подобного расширения флаг равен TRUE, сертификат приходится считать некорректным.
Сертификаты открытых ключей подразделяются на два основных вида:
сертификаты оконечных сущностей;
сертификаты удостоверяющих центров.
Оконечные сущности не имеют права выпускать сертификаты. Удостоверяющие центры ведают выпуском и аннулированием сертификатов, которые относятся к одному из двух классов:
"самовыпущенные" сертификаты (изготовленные для себя самим удостоверяющим центром). Они полезны, например, при смене ключей УЦ, чтобы обеспечить доверие новым ключам на основании доверия старым. Важным подклассом данного класса являются "самоподписанные" сертификаты, в которых секретный ключ, использованный для генерации ЭЦП, соответствует заверяемому открытому ключу. Таким способом УЦ может афишировать свой открытый ключ или иную информацию о собственном функционировании;
кросс-сертификаты (выдаются одним УЦ другому). Они применяются и в иерархической структуре для авторизации нижестоящего УЦ вышестоящим, и в произвольной структуре "распределенного доверия" как факт признания одним УЦ существования другого.
Рассмотрим процесс получения и проверки пользователем A открытого ключа пользователя B. Элемент Директории, представляющий A, содержит один или несколько сертификатов открытых ключей A, заверенных удостоверяющим центром, который мы обозначим CA (A) (а сертификат A - как CA (A) <>) и которому, разумеется, соответствует свой узел в Информационном Дереве. Предполагается, что пользователь доверяет своему УЦ, поэтому, если существует сертификат CA (A) <>, процесс выяснения открытого ключа B можно считать завершенным. В противном случае приходится строить так называемый сертификационный маршрут от A к B (обозначается A -> B), начинающийся сертификатом CA (A) <>, который CA (A) выдал некоторому другому УЦ, X1, ставшему вследствие этого доверенным для A. Маршрут продолжается сертификатом вида X1 <2>>, содержит промежуточные звенья вида Xi <i+1>> и завершается сертификатом Xn <>.
Элемент Директории, соответствующий удостоверяющему центру, содержит сертификаты двух типов: прямые (сгенерированные данным УЦ для других) и обратные (выданные данному УЦ другими). Если, кроме того, удостоверяющие центры образуют иерархию, соответствующую Информационному Дереву, то сертификационный маршрут можно построить без привлечения дополнительной информации, только на основе различительных имен A и B. Действительно, с помощью обратных сертификатов выполняется подъем от CA (A) до корня поддерева, общего для A и B, а затем, с помощью прямых сертификатов осуществляется спуск до CA (B). В рассмотренном выше процессе A - пользователь сертификата, B - его владелец (субъект), CA (B) - удостоверяющий центр. Все три стороны несут друг перед другом определенные обязательства и, в свою очередь, пользуются предоставляемыми гарантиями. Обязательства и гарантии могут быть зафиксированы в политике сертификата, ссылка на которую хранится в одном из полей расширений. Обычно политика - это общепринятый текст, но в ней могут присутствовать и формальные условия, допускающие автоматическую проверку.
При построении и использовании сертификационного маршрута проверяется согласованность политик, присутствующих в кросс-сертификатах. Еще один пример употребления данного поля расширения - наложение и проверка ограничений на длину сертификационного маршрута (вообще говоря, чем длиннее маршрут, тем меньше доверия он вызывает).
Другая группа дополнительных полей сертификатов обслуживает способы и срок действия ключей. Для шифрования и цифровой подписи применяют разные ключи; следовательно, у одного субъекта может быть несколько пар ключей и, соответственно, несколько сертификатов. Чтобы выбрать среди них нужный, необходимо иметь возможность выяснить назначение представленного в сертификате открытого ключа. Аналогично, может потребоваться знание срока годности секретного ключа, посредством которого формируют ЭЦП, поскольку этот срок обычно меньше, чем у открытого ключа, проверяющего подпись.
Значительная часть рекомендаций X.509 посвящена спискам отзыва сертификатов; мы, однако, не будем останавливаться на этом сугубо техническом вопросе.
Каркас сертификатов атрибутов
Вероятно, развитие механизма расширений натолкнуло авторов рекомендаций X.509 на мысль о том, что в заверенных сертификатах можно хранить не только открытые ключи, но и произвольные атрибуты субъектов - держателей (владельцев) сертификатов.
Сертификат атрибутов - это структура данных, снабженная цифровой подписью соответствующего удостоверяющего центра и связывающая значения некоторых атрибутов с идентификационной информацией держателя сертификата.
Вообще говоря, сертификаты атрибутов имеют универсальный характер, но в рекомендациях X.509 внимание акцентируется на их применении в качестве основы инфраструктуры управления привилегиями.
У каркасов сертификатов открытых ключей и сертификатов атрибутов немало общего. Это и система удостоверяющих центров, и списки отзыва, и многое другое. Мы, однако, сосредоточимся на специфике управления привилегиями.
Отметим в первую очередь, что жизненные циклы открытых ключей и привилегий устроены по-разному, имеют разную длительность. Привилегии могут делегироваться вспомогательным сущностям на короткие промежутки времени (порядка минуты). Для управления привилегиями используются свои понятия и механизмы, например роли. Следовательно, хотя с синтаксической точки зрения для цели управления привилегиями можно использовать снабженные соответствующими расширениями сертификаты открытых ключей, идейная и практическая сторона вопроса подразумевает разделение каркасов открытых ключей и управления привилегиями, что и сделано в рекомендациях X.509.
В контексте управления привилегиями удостоверяющий центр называется центром авторизации. Выделяется главный центр авторизации, который может делегировать другим центрам права наделения привилегиями и их дальнейшего делегирования.
На протяжении маршрута делегирования должно действовать правило доминирования: промежуточный центр авторизации не вправе делегировать больше привилегий, чем сам имеет (для каждой привилегии должно быть определено, что значит "не больше").
Вообще говоря, известны две схемы выделения и проверки привилегий:
удостоверяющий центр по собственной инициативе наделяет некоторую сущность привилегиями, создав сертификат атрибутов и поместив его в Директорию с предоставлением свободного доступа. В дальнейшем верификатору привилегий разрешается использовать этот сертификат при принятии решения о предоставлении определенного вида доступа. Перечисленные действия могут происходить без ведома и участия субъекта - держателя сертификата;
субъект запрашивает центр авторизации на предмет получения определенной привилегии. При положительном решении созданный сертификат атрибутов возвращается держателю и явным образом предъявляется последним при доступе к защищенным ресурсам.
Независимо от принятой схемы выделяются три основных понятия инфраструктуры управления привилегиями:
объект (точнее, метод объекта), к которому осуществляется доступ и который может быть снабжен такими атрибутами, как метка безопасности.
предъявитель привилегий;
верификатор привилегий, принимающий решения (с учетом действующей политики безопасности и существующего окружения) о достаточности предъявленных привилегий для предоставления доступа.
Верификатор привилегий - это какая-либо экранирующая сущность, логически располагающаяся между вызывающим и вызываемым методами объектов; рекомендации X.509 не налагают ограничений на правила экранирования.
Ролевое управление доступом может быть реализовано за счет введения дополнительного уровня косвенности, а также трактовки допустимых ролей как атрибутов субъектов и ассоциирования привилегий с ролями путем выпуска соответствующих сертификатов.
Отметим, что каркас сертификатов атрибутов может быть использован не только для управления доступом, но и в контексте обеспечения неотказуемости. При этом предъявитель привилегий выступает в качестве субъекта свидетельства, верификатор привилегий оказывается пользователем свидетельства, а метод объекта трактуется как целевая сущность.
Можно видеть, что каркас сертификатов атрибутов обладает достаточной гибкостью и выразительной силой, чтобы служить основой инфраструктуры управления привилегиями, поддерживать контроль доступа и неотказуемость.
Простая и сильная аутентификация
Каркасы сертификатов открытых ключей и атрибутов - основа целого ряда сервисов безопасности, в число которых входят аутентификация, контроль целостности, управление доступом. Они могут использоваться как самой Директорией, так и произвольными приложениями. В этом разделе мы рассмотрим простую и сильную аутентификации, включенные в рекомендации X.509.
Простая аутентификация предназначена только для локального использования. Данные для нее могут вырабатываться и передаваться тремя способами:
имя и пароль пользователя передаются в открытом виде;
имя, пароль, случайное число и, возможно, временной штамп (метка) подвергаются воздействию односторонней функции, результат которой передается получателю для проверки;
к описанному выше результату добавляется случайное число и/или временной штамп и еще раз применяется односторонняя функция (возможно, та же самая).
Рассмотрим более подробно реализацию разновидности 2 простой аутентификации. Пользователь A сначала генерирует токен безопасности PT1:
PT1 = h1 (t1A, r1A, A, passwdA)
Токен PT1 используется для создания аутентификационного токена AT1:
AT1 = t1A, r1A, A, PT1
(т. е. токен AT1 состоит из четырех компонентов). Пользователь A пересылает пользователю B токен AT1. Цель B - своими средствами создать аналог токена безопасности PT1 (реконструировать PT1) и сравнить его с оригиналом. Он запрашивает у службы директорий или извлекает самостоятельно локальную копию пароля passwdA (обозначим ее passwdA-B) и реконструирует PT1:
PT1-B = h1 (t1A, r1A, A, passwdA-B)
Если PT1 и PT1-B совпадут, подлинность пользователя A считается установленной.
Сильная аутентификация основана на применении асимметричных методов шифрования, пригодных для генерации электронной подписи. Подлинность пользователя A считается установленной, если он продемонстрирует владение секретным ключом, ассоциированным с хранящимся в сертификате на имя A открытым ключом.
Рекомендации X.509 описывают три возможные процедуры сильной аутентификации:
односторонний обмен. От пользователя A пользователю B передается один токен. При этом подтверждается подлинность A и B, а также то, что токен сгенерирован A, предназначен B, не был изменен и является "оригинальным" (т. е. не посылается повторно);
двусторонний обмен. Дополнительно от B к A направляется ответ, допускающий проверку того, что он был сгенерирован B, предназначен A, не был изменен и является "оригинальным";
трехсторонний обмен. От A к B передается еще один токен. Обеспечивает те же свойства, что и двусторонний, без использования временных штампов.
Предполагается, что независимо от выбранной процедуры и до выполнения обменов пользователь A выясняет открытый ключ B и обратный сертификационный маршрут B -> A.
Рассмотрим более подробно процедуру одностороннего обмена.
В качестве первого шага пользователь A генерирует "уникальное" число rA, предназначенное для защиты от воспроизведения и подделки аутентификационного токена.
После этого A направляет B сообщение следующей структуры:
B -> A, A {tA, rA, B}
где tA - временной штамп, в общем случае представляющий собой пару (время генерации токена и срок его годности). (Напомним, что конструкция вида A {I} обозначает информацию I, подписанную открытым ключом A.)
Получив это сообщение, B предпринимает следующие действия:
по обратному сертификационному пути B -> A выясняет открытый ключ A (Ap), попутно проверяя статус сертификата A;
проверяет подпись и, тем самым, целостность присланной информации;
проверяет, что в качестве получателя указан B;
удостоверяется, что временной штамп "свежий", а число rA ранее не использовалось.
Двусторонний и трехсторонний обмены являются довольно очевидным развитием одностороннего.
На этом мы завершаем рассмотрение рекомендаций семейства X.500.
|
