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

Рис. 10.6. Пример сетевой PKI и построенных путей сертификации

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

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

Пример 10.3. На рис. 10.6удостоверяющие центры объединены в сетевую PKI. Пользователи А и В доверяют УЦ 1 . Пользователь С доверяет УЦ 2 , а пользователь D - УЦ 3 . Пользователю А гораздо труднее найти и проанализировать путь сертификации до пользователя С , чем в иерархической PKI. В том случае, если путь строится от УЦ 1 к УЦ 2 , то он содержит два сертификата, а если путь к УЦ 2 проходит через УЦ 3 , то - три сертификата. Пытаясь обнаружить один из нескольких правильных путей, пользователь может построить пути , которые ведут в тупик (например, путь через УЦ 4 ). Обработка большего количества сертификатов более сложна, поскольку сопровождается анализом ограничений, включаемых в дополнения сертификатов.

В сетевой архитектуре разные пользователи строят разные пути сертификации . Повторимся, что пользователи обычно считают пунктом доверия тот УЦ, который выпустил их сертификаты. Следовательно, когда пользователь А строит путь сертификации до пользователя В , то путь начинается в УЦ, который выпустил сертификат для А , и заканчивается сертификатом пользователя В . Соответственно, когда пользователь С строит путь сертификации до пользователя В , то путь начинается в УЦ, который выпустил сертификат для С , и заканчивается сертификатом пользователя В . Эти пути сертификации различны, несмотря на то, что пользователи А и С получили свои сертификаты от одного и того же УЦ.

В сетевой архитектуре сертификаты конечных субъектов выпускаются непосредственно их пунктами доверия . Субъект, строящий путь , доверяет своему УЦ, который может не совпадать с пунктом доверия того конечного субъекта, к которому строится путь . Более того, для этого УЦ могут быть выпущены сертификаты другими удостоверяющими центрами из разных сегментов сети. По этой причине построение пути начинается в пункте доверия и продолжается в направлении издателя сертификата конечного субъекта. Идентификатор ключа УЦ в сертификате сравнивается с идентификатором ключа субъекта сертификатов удостоверяющих центров, включая сертификат искомого УЦ. Так как дополнения Authority Key Identifier (идентификатор ключа УЦ) недостаточно для построения пути , следует использовать другие атрибуты как эвристические. Это могут быть имена или любые другие атрибуты, помогающие выбрать, с какого из возможных сертификатов начинать построение пути . Если выбранный сертификат не ведет к завершенному пути сертификации , то просто пробуют следующий за ним сертификат и т.д. [84].

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

На рис.10.6показаны пути сертификации , которые можно построить от пользователя А к пользователям B , C и D . Для пользователей C и D показан не один путь . Каждый путь является валидным , но некоторые пути длиннее других. Нахождение наиболее короткого пути не требуется, решение этой задачи значительно усложняет процесс. Обычно используется первый найденный валидный путь . С иллюстративной целью третий путь сертификации для пользователя D имеет петлю.

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

Пример 10.4. Рассмотрим сценарий, проиллюстрированный рис. 10.7 [70]. Три компании сотрудничают друг с другом, но используют корпоративные PKI разных типов. Пользователи А и В получили свои сертификаты от головного УЦ компании "Альфа" . Пользователь С получил свой сертификат от УЦ подразделения 1 в иерархической PKI компании "Бета" . Пользователь D получил сертификат от УЦ подразделения 3 в сетевой PKI компании "Гамма" . Пользователь А может использовать один из трех вариантов гибридной архитектуры PKI для установления защищенных коммуникаций с пользователями C и D .

Рис. 10.7. Три корпоративные PKI

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