Основные понятия и идеи рекомендаций семейства X.500
Рекомендации семейства X.500 описывают службу директорий.
Среди возможностей, предоставляемых этой службой, обычно выделяют
дружественное именование (обращение к объектам по именам, удобным с
точки зрения человека) и отображение имен в адреса (динамическое
связывание объекта и его расположения - необходимое условие
поддержки "самоконфигурируемости" сетевых систем).
Основные понятия службы директорий зафиксированы в рекомендациях
X.501 " Служба директорий: модели" и X.511 " Служба директорий: абстрактное
определение сервиса" .
Множество систем, обеспечивающих функционирование службы
директорий, вместе с содержащейся в них информацией можно
представлять как единое целое - Директорию с большой буквы.
Информация, доступ к которой возможен посредством Директории,
называется Информационной Базой Директории . Она обычно
используется для облегчения взаимодействия таких сущностей, как объекты прикладного уровня, люди, списки рассылки и т.д., а также
для получения сведений о них.
Предполагается, что Информационная База имеет древовидную
структуру, называемую Информационным Деревом Директории . Вершины этого дерева, отличные от корня, составляют элементы Директории, в которых хранится информация об объектах .
У каждого элемента есть однозначно идентифицирующее его различительное имя. В пределах поддеревьев Информационного
Дерева могут использоваться относительные различительные
имена.
Природа объектов, информация о которых хранится в Директории, произвольна. Единственное требование к ним состоит в
идентифицируемости (возможности именования).
Объекты объединяются в классы.
Каждый объект должен принадлежать по крайней
мере одному классу.
Элементы Директории могут быть составными, объединять
подэлементы, содержащие информацию об отдельных аспектах объектов.
Каждый элемент состоит из атрибутов, имеющих тип и одно
или несколько значений. Набор атрибутов зависит от класса объекта.
Некоторые из концевых узлов (листьев) Информационного Дерева
могут представлять собой синонимы, содержащие альтернативное
имя и указатель на элемент с информацией об объекте.
Служба директорий предоставляет две группы операций:
опрос;
модификацию.
В число операций опроса входят:
чтение значений атрибутов элемента Директории ;
сравнение значения атрибута элемента Директории с
заданной величиной (полезно, например, для проверки пароля без
предоставления доступа к хранимому паролю);
выдача списка ( перечисление ) непосредственных
преемников заданного узла Информационного Дерева ;
поиск и чтение элементов, удовлетворяющих заданным фильтрам (условиям), в заданных частях Информационного
Дерева ;
отказ от незавершенной операции
опроса (например, если она выполняется слишком долго).
В группу операций модификации входят:
добавление нового (концевого) узла Информационного Дерева ;
удаление концевого узла Информационного Дерева ;
модификация элемента Директории с возможным добавлением и/или
удалением атрибутов и их значений;
модификация относительного различительного имени элемента или
перемещение узла Информационного Дерева к другому предшественнику.
Рекомендации X.501 описывают три возможные схемы управления
доступом к Директории: базовую, упрощенную и основанную на
правилах; последняя может реализовывать принудительное (мандатное) управление доступом с использованием меток безопасности. Решения о
предоставлении доступа принимаются с учетом существующей политики
безопасности.
Разумеется, предусмотрена аутентификация системных агентов
и пользователей, а также источников данных Директории.
Таковы основные понятия и идеи службы директорий, зафиксированные
в семействе рекомендаций X.500 и необходимые нам для последующего
изложения.
Каркас сертификатов открытых ключей
Мы приступаем к изучению четвертой редакции рекомендаций X.509
, которая регламентирует следующие аспекты:
сертификаты открытых ключей ;
сертификаты атрибутов ;
сервисы аутентификации.
Идейной основой рекомендаций X.509 являются сертификаты открытых
ключей, обслуживающие такие грани информационной безопасности, как
конфиденциальность и целостность, и такие сервисы, как аутентификация и неотказуемость.
В курсе "Основы информационной безопасности" приведены необходимые сведения о криптографии
с открытыми ключами и механизме электронной цифровой подписи (ЭЦП);
далее предполагается, что они уже известны.
Сертификат открытого ключа - это структура данных, обеспечивающая
ассоциирование открытого ключа и его владельца. Надежность
ассоциации, подлинность сертификата подтверждаются подписью удостоверяющего центра (УЦ).
Сертификаты имеют конечный срок годности. Поддерживать
актуальность информации об их статусе помогают списки отзыва,
подписываемые удостоверяющими центрами и содержащими перечни
сертификатов, переставших быть годными. Последнее может случиться
как в результате естественного окончания срока, так и досрочно,
например, из-за компрометации секретного ключа владельца.
Формат сертификата описан в курсе . В простейшем случае он выглядит так:
CA <<A>> = CA {V, SN, AI, CA, A, Ap, TA}
Здесь:
A - имя владельца сертификата;
CA - имя удостоверяющего центра ;
CA <<A>> - сертификат, выданный A центром CA ;
CA {I} - данные I, снабженные подписью CA ;
V - версия сертификата (в настоящее время - версия 3);
SN - порядковый номер сертификата;
AI - идентификатор алгоритма, использованного при подписании
сертификата;
Ap - информация об открытом ключе A ;
TA - даты начала и конца срока годности сертификата.
Отметим, что в общем случае формат может быть существенно
сложнее. С помощью механизма расширений его можно приспособить для
нужд различных приложений и сообществ пользователей. В X.509
предусмотрены полезные расширения, носящие универсальный характер.
Каждое расширение включает имя, флаг критичности и значение. Если
при обработке (проверке) сертификата встречается неизвестное
расширение с флагом критичности FALSE, оно может быть
проигнорировано; если же у подобного расширения флаг равен TRUE,
сертификат приходится считать некорректным.
Сертификаты открытых ключей подразделяются на два основных вида:
сертификаты оконечных сущностей;
сертификаты удостоверяющих центров.
Оконечные сущности не имеют права выпускать сертификаты. Удостоверяющие центры ведают выпуском и аннулированием сертификатов,
которые относятся к одному из двух классов:
"самовыпущенные" сертификаты (изготовленные для себя самим удостоверяющим центром ). Они полезны, например, при смене ключей
УЦ, чтобы обеспечить доверие новым ключам на основании доверия
старым. Важным подклассом данного класса являются
"самоподписанные" сертификаты, в которых секретный ключ,
использованный для генерации ЭЦП, соответствует заверяемому
открытому ключу. Таким способом УЦ может афишировать свой открытый
ключ или иную информацию о собственном функционировании;
кросс-сертификаты (выдаются одним УЦ другому). Они
применяются и в иерархической структуре для авторизации
нижестоящего УЦ вышестоящим, и в произвольной структуре
"распределенного доверия" как факт признания одним УЦ
существования другого.
Рассмотрим процесс получения и проверки пользователем A открытого
ключа пользователя B. Элемент Директории, представляющий A, содержит
один или несколько сертификатов открытых ключей A, заверенных удостоверяющим центром, который мы обозначим CA (A) (а сертификат A
- как CA (A) <<A>> ) и которому, разумеется,
соответствует свой узел в Информационном Дереве. Предполагается, что
пользователь доверяет своему УЦ, поэтому, если существует сертификат CA (A) <<B>>, процесс выяснения открытого ключа B можно
считать завершенным. В противном случае приходится строить так
называемый сертификационный маршрут от A к B (обозначается A ->
B ), начинающийся сертификатом CA (A) <<X1>>, который CA
(A) выдал некоторому другому УЦ, X1, ставшему вследствие этого
доверенным для A. Маршрут продолжается сертификатом вида X1
<<X2>>, содержит промежуточные звенья вида Xi
<<Xi+1>> и завершается сертификатом Xn
<<B>>.
Элемент Директории, соответствующий удостоверяющему центру,
содержит сертификаты двух типов: прямые
(сгенерированные данным УЦ для других) и обратные (выданные
данному УЦ другими). Если, кроме того, удостоверяющие центры
образуют иерархию, соответствующую Информационному Дереву, то
сертификационный маршрут можно построить без привлечения
дополнительной информации, только на основе различительных имен 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.
Основные понятия и идеи рекомендаций семейства X.500
Рекомендации семейства X.500 описывают службу директорий.
Среди возможностей, предоставляемых этой службой, обычно выделяют
дружественное именование (обращение к объектам по именам, удобным с
точки зрения человека) и отображение имен в адреса (динамическое
связывание объекта и его расположения - необходимое условие
поддержки "самоконфигурируемости" сетевых систем).
Основные понятия службы директорий зафиксированы в рекомендациях
X.501 " Служба директорий: модели" и X.511 " Служба директорий: абстрактное
определение сервиса" .
Множество систем, обеспечивающих функционирование службы
директорий, вместе с содержащейся в них информацией можно
представлять как единое целое - Директорию с большой буквы.
Информация, доступ к которой возможен посредством Директории,
называется Информационной Базой Директории . Она обычно
используется для облегчения взаимодействия таких сущностей, как объекты прикладного уровня, люди, списки рассылки и т.д., а также
для получения сведений о них.
Предполагается, что Информационная База имеет древовидную
структуру, называемую Информационным Деревом Директории . Вершины этого дерева, отличные от корня, составляют элементы Директории, в которых хранится информация об объектах .
У каждого элемента есть однозначно идентифицирующее его различительное имя. В пределах поддеревьев Информационного
Дерева могут использоваться относительные различительные
имена.
Природа объектов, информация о которых хранится в Директории, произвольна. Единственное требование к ним состоит в
идентифицируемости (возможности именования).
Объекты объединяются в классы.
Каждый объект должен принадлежать по крайней
мере одному классу.
Элементы Директории могут быть составными, объединять
подэлементы, содержащие информацию об отдельных аспектах объектов.
Каждый элемент состоит из атрибутов, имеющих тип и одно
или несколько значений. Набор атрибутов зависит от класса объекта.
Некоторые из концевых узлов (листьев) Информационного Дерева
могут представлять собой синонимы, содержащие альтернативное
имя и указатель на элемент с информацией об объекте.
Служба директорий предоставляет две группы операций:
опрос;
модификацию.
В число операций опроса входят:
чтение значений атрибутов элемента Директории ;
сравнение значения атрибута элемента Директории с
заданной величиной (полезно, например, для проверки пароля без
предоставления доступа к хранимому паролю);
выдача списка ( перечисление ) непосредственных
преемников заданного узла Информационного Дерева ;
поиск и чтение элементов, удовлетворяющих заданным фильтрам (условиям), в заданных частях Информационного
Дерева ;
отказ от незавершенной операции
опроса (например, если она выполняется слишком долго).
В группу операций модификации входят:
добавление нового (концевого) узла Информационного Дерева ;
удаление концевого узла Информационного Дерева ;
модификация элемента Директории с возможным добавлением и/или
удалением атрибутов и их значений;
модификация относительного различительного имени элемента или
перемещение узла Информационного Дерева к другому предшественнику.
Рекомендации X.501 описывают три возможные схемы управления
доступом к Директории: базовую, упрощенную и основанную на
правилах; последняя может реализовывать принудительное (мандатное) управление доступом с использованием меток безопасности. Решения о
предоставлении доступа принимаются с учетом существующей политики
безопасности.
Разумеется, предусмотрена аутентификация системных агентов
и пользователей, а также источников данных Директории.
Таковы основные понятия и идеи службы директорий, зафиксированные
в семействе рекомендаций X.500 и необходимые нам для последующего
изложения.
Каркас сертификатов открытых ключей
Мы приступаем к изучению четвертой редакции рекомендаций X.509
, которая регламентирует следующие аспекты:
сертификаты открытых ключей ;
сертификаты атрибутов ;
сервисы аутентификации.
Идейной основой рекомендаций X.509 являются сертификаты открытых
ключей, обслуживающие такие грани информационной безопасности, как
конфиденциальность и целостность, и такие сервисы, как аутентификация и неотказуемость.
В курсе "Основы информационной безопасности" приведены необходимые сведения о криптографии
с открытыми ключами и механизме электронной цифровой подписи (ЭЦП);
далее предполагается, что они уже известны.
Сертификат открытого ключа - это структура данных, обеспечивающая
ассоциирование открытого ключа и его владельца. Надежность
ассоциации, подлинность сертификата подтверждаются подписью удостоверяющего центра (УЦ).
Сертификаты имеют конечный срок годности. Поддерживать
актуальность информации об их статусе помогают списки отзыва,
подписываемые удостоверяющими центрами и содержащими перечни
сертификатов, переставших быть годными. Последнее может случиться
как в результате естественного окончания срока, так и досрочно,
например, из-за компрометации секретного ключа владельца.
Формат сертификата описан в курсе . В простейшем случае он выглядит так:
CA <<A>> = CA {V, SN, AI, CA, A, Ap, TA}
Здесь:
A - имя владельца сертификата;
CA - имя удостоверяющего центра ;
CA <<A>> - сертификат, выданный A центром CA ;
CA {I} - данные I, снабженные подписью CA ;
V - версия сертификата (в настоящее время - версия 3);
SN - порядковый номер сертификата;
AI - идентификатор алгоритма, использованного при подписании
сертификата;
Ap - информация об открытом ключе A ;
TA - даты начала и конца срока годности сертификата.
Отметим, что в общем случае формат может быть существенно
сложнее. С помощью механизма расширений его можно приспособить для
нужд различных приложений и сообществ пользователей. В X.509
предусмотрены полезные расширения, носящие универсальный характер.
Каждое расширение включает имя, флаг критичности и значение. Если
при обработке (проверке) сертификата встречается неизвестное
расширение с флагом критичности FALSE, оно может быть
проигнорировано; если же у подобного расширения флаг равен TRUE,
сертификат приходится считать некорректным.
Сертификаты открытых ключей подразделяются на два основных вида:
сертификаты оконечных сущностей;
сертификаты удостоверяющих центров.
Оконечные сущности не имеют права выпускать сертификаты. Удостоверяющие центры ведают выпуском и аннулированием сертификатов,
которые относятся к одному из двух классов:
"самовыпущенные" сертификаты (изготовленные для себя самим удостоверяющим центром ). Они полезны, например, при смене ключей
УЦ, чтобы обеспечить доверие новым ключам на основании доверия
старым. Важным подклассом данного класса являются
"самоподписанные" сертификаты, в которых секретный ключ,
использованный для генерации ЭЦП, соответствует заверяемому
открытому ключу. Таким способом УЦ может афишировать свой открытый
ключ или иную информацию о собственном функционировании;
кросс-сертификаты (выдаются одним УЦ другому). Они
применяются и в иерархической структуре для авторизации
нижестоящего УЦ вышестоящим, и в произвольной структуре
"распределенного доверия" как факт признания одним УЦ
существования другого.
Рассмотрим процесс получения и проверки пользователем A открытого
ключа пользователя B. Элемент Директории, представляющий A, содержит
один или несколько сертификатов открытых ключей A, заверенных удостоверяющим центром, который мы обозначим CA (A) (а сертификат A
- как CA (A) <<A>> ) и которому, разумеется,
соответствует свой узел в Информационном Дереве. Предполагается, что
пользователь доверяет своему УЦ, поэтому, если существует сертификат CA (A) <<B>>, процесс выяснения открытого ключа B можно
считать завершенным. В противном случае приходится строить так
называемый сертификационный маршрут от A к B (обозначается A ->
B ), начинающийся сертификатом CA (A) <<X1>>, который CA
(A) выдал некоторому другому УЦ, X1, ставшему вследствие этого
доверенным для A. Маршрут продолжается сертификатом вида X1
<<X2>>, содержит промежуточные звенья вида Xi
<<Xi+1>> и завершается сертификатом Xn
<<B>>.
Элемент Директории, соответствующий удостоверяющему центру,
содержит сертификаты двух типов: прямые
(сгенерированные данным УЦ для других) и обратные (выданные
данному УЦ другими). Если, кроме того, удостоверяющие центры
образуют иерархию, соответствующую Информационному Дереву, то
сертификационный маршрут можно построить без привлечения
дополнительной информации, только на основе различительных имен 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.
