Инфраструктуры открытых ключей - Ольга Полянская

В модели строгой иерархии удостоверяющих центров все субъекты иерархии доверяют одному головному УЦ (будем использовать этот аналог термина "корневой" как более традиционный и понятный) [124]. Иерархия строится следующим образом.

1 Создается головной УЦ, который генерирует и подписывает сертификат для самого себя. Сертификат головного УЦ называют самоизданным (или самоподписанным ) корневым сертификатом, именно он составляет основу доверия всех субъектов данной строгой иерархии.

2 Головной УЦ сертифицирует, то есть выпускает и подписывает сертификаты для удостоверяющих центров, непосредственно ему подчиненных. Количество подчиненных удостоверяющих центров может быть и нулевым, то есть подчиненные центры могут отсутствовать.

3 Каждый из этих удостоверяющих центров сертифицирует другие удостоверяющие центры, непосредственно ему подчиненные.

4 На уровнях иерархии от второго до последнего удостоверяющие центры сертифицируют конечных субъектов.

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

Пример 5.1. Рассмотрим, как конечный пользователь А, владеющий доверенной копией открытого ключа головного УЦ, может проверить подлинность, то есть верифицировать сертификат другого конечного субъекта В. Предположим, что сертификат субъекта В подписан УЦ2, чей сертификат в свою очередь подписан УЦ1, сертификат которого заверен головным УЦ. Субъект А при помощи открытого ключа головного УЦ - kг может верифицировать сертификат УЦ1 и извлечь доверенную копию открытого ключа УЦ1 - k1. Затем этот ключ может быть использован для верификации сертификата УЦ2, в результате которой становится известна доверенная копия открытого ключа УЦ2 - k2 Ключ k2 может быть использован для верификации сертификата субъекта В и получения доверенной копии его открытого ключа - kВ. Субъект А может теперь использовать ключ kВ (в зависимости от его типа) для шифрования сообщений, адресованных субъекту В, или проверки цифровых подписей, которые создал субъект В. Описанная процедура позволяет обеспечить защищенную связь между субъектами А и В.

Нестрогая иерархия удостоверяющих центров

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

Если сертификаты пользователей А и В выпущены одним и тем же УЦ2, то пользователи могут проверять сертификаты друг друга без построения пути сертификации к головному УЦ только в том случае, когда пользователи относятся к иерархии одного и того же доверенного издателя. Однако, если сертификат пользователя C издан не УЦ2, а другим УЦ, то для проверки сертификата C пользователи А и В должны строить полный пути сертификации через головной УЦ, заверивший сертификат пользователя C. Таким образом, если доверяющая сторона оценивает сертификат, выпущенный сторонним УЦ, то должна выполнять валидацию пути сертификации в соответствии с требованиями строгой иерархии.

Иерархии на основе политик

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

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

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

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

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

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

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

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

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

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

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

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