Книга: Инфраструктуры открытых ключей

Модель распределенного доверия

Модель распределенного доверия разделяет доверие между двумя или несколькими удостоверяющими центрами. Пусть пользователь А владеет копией открытого ключа своего пункта доверия - УЦ₁, а пользователь В - копией открытого ключа своего пункта доверия - УЦ₂. УЦ₁ - корень строгой иерархии, которая включает пользователя А, УЦ₂ - корень строгой иерархии, в которую входит пользователь В. Если каждая из этих иерархий является неглубокой иерархией с доверенным издателем, то вместе они образуют полностью одноранговую сеть, потому что все удостоверяющие центры являются действительно независимыми одноранговыми узлами сети. В этой архитектуре отсутствуют подчиненные удостоверяющие центры. С другой стороны, если каждая иерархия является многоуровневой, то результат объединения иерархий имеет полностью древовидную структуру. Отметим, что головные удостоверяющие центры связаны друг с другом равноправными отношениями, но каждый головной УЦ действует как вышестоящий для одного или более подчиненных удостоверяющих центров. Одним из вариантов архитектуры распределенного доверия может быть гибридная конфигурация с одной или более иерархиями с доверенным издателем или одним или более многоуровневыми деревьями >[44]. Эта конфигурация изображена на рис. 5.2.

Рис. 5.2.  Архитектура распределенного доверия

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

Изолированные PKI-домены могут быть сконфигурированы разными способами, в том числе на базе строгой иерархии, архитектуры полностью одноранговой сети или любой модели доверия, обсуждающейся в данной лекции. Важно, чтобы поддерживалась функциональная совместимость между любой комбинацией этих моделей доверия >[96].

Процесс взаимного связывания одноранговых головных удостоверяющих центров обычно называют кросс-сертификацией , хотя в последнее время все чаще используется термин "создание сети PKI " (в частности для полностью древовидной и гибридной архитектур). Для кросс-сертификации, как правило, используются два разных типа конфигурации PKI: сетевая и мостовая (конфигурация hub-and-spoke).

Следует отметить, что в настоящее время специалистами изучаются и предлагаются и другие методы создания отношений доверия между PKI-доменами:

* взаимное распознавание;

* использование списков доверия к сертификатам;

* применение сертификатов аккредитации.

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

Список доверия к сертификатам (Certificate Trust List - CTL), по определению специалистов корпорации Microsoft, является заверенным цифровой подписью списком сертификатов головных удостоверяющих центров, который признается администратором корпоративной сети пригодным для выполнения аутентификации клиентов и защиты электронной почты.

Концепция сертификата аккредитации впервые появилась в проекте PKI правительства Австралии (Gatekeeper) и заключается в том, что хорошо известные и надежные удостоверяющие центры при определенных условиях ручаются за другие удостоверяющие центры >[44]. Использование сертификатов аккредитации можно сравнить с односторонней кросс-сертификацией в том смысле, что аккредитационный УЦ выпускает сертификаты для всех удостоверяющих центров, которые удовлетворяют требованиям аккредитации. При этом иерархия не поддерживается, и аккредитованные удостоверяющие центры могут быть полностью автономными субъектами. Сертификаты аккредитации можно использовать для реализации идеи взаимного распознавания.

Сетевая конфигурация

В сетевой конфигурации все головные удостоверяющие центры потенциально кросс-сертифицированы друг с другом. Два головных удостоверяющих центра устанавливают отношения кросс-сертификации, если их сообществам необходимо иметь защищенные коммуникации друг с другом. В полностью связанном случае, иногда называемом полной сетью, это требует установления (n² - n) - кросс-сертифицированных соглашений при наличии n -головных удостоверяющих центров, хотя на практике чаще встречаются неполные сети. Рис. 5.2 иллюстрирует неполную сетевую гибридную архитектуру распределенного доверия. Она не является полной сетью, потому что между первым и третьим удостоверяющими центрами отсутствует прямое соглашение о кросс-сертификации.

Мостовая конфигурация (конфигурация hub-and-spoke)

В мостовой конфигурации каждый головной УЦ устанавливает отношения кросс-сертификации с единственным центральным УЦ, в чьи функции входит обеспечение таких взаимных связей >[101]. Центральный УЦ иногда называют "втулкой" (hub), соединенной "спицами" (spoke) с различными головными удостоверяющими центрами, а иногда называют мостовым УЦ, устанавливающим связи между парами головных удостоверяющих центров. Преимущество этой конфигурации заключается в том, что в случае полной связи требуется заключение только n -соглашений о кросс-сертификации для n -головных удостоверяющих центров, потому что каждый головной УЦ кросс-сертифицируется только с центральным УЦ.

Мостовая конфигурация не создает иерархии, мостовой УЦ следует рассматривать как головной для всех систем, которые кросс-сертифицируются с ним. Фундаментальное различие между строгой иерархией и мостовой конфигурацией состоит в том, какими ключами владеют конечные субъекты. В строгой иерархии все субъекты владеют доверенной копией открытого ключа головного УЦ, обеспечивающего базу для валидации пути сертификации. В мостовой конфигурации конечные субъекты не владеют открытым ключом мостового УЦ, а имеют лишь копию открытого ключа головного УЦ в своем собственном домене. Каждый субъект, строя путь сертификации, при помощи этого ключа получает ключ мостового УЦ, затем ключ головного УЦ другого домена и, в конце концов, ключ конечного субъекта другого домена.

Оглавление книги