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

Одиночный УЦ

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

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

Рис. 10.2.  Одиночный УЦ и пути сертификации

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

Построение пути в простой PKI

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

На () показаны пути сертификации пользователей A, B, C и N в простой PKI, представляющей собой одиночный УЦ. Каждый путь состоит из одного сертификата. Запись [(УЦ "Альфа") -> А] означает, что один сертификат, выпущенный УЦ "Альфа" для пользователя А, составляет весь путь.

Простые списки доверия

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

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

Рис. 10.3.  Поддержка нескольких удостоверяющих центров через списки доверия

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

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

Иерархическая PKI

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

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

Рис. 10.4.  Расширение иерархической PKI

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

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

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

Построение пути в иерархической PKI

В иерархиях пути сертификации начинаются в корне (с головного УЦ) и заканчиваются конечными субъектами, однако строятся они в обратном направлении . Построение начинается с сертификата конечного субъекта. В сертификате указаны его издатель (УЦ) и дополнение Authority Key Identifier (идентификатор ключа УЦ). Эти атрибуты позволяют найти сертификат УЦ. Имя издателя используется для определения местонахождения сертификатов УЦ в репозитории. Репозиторий может содержать несколько сертификатов, выпущенных для УЦ. Идентификатор ключа УЦ в сертификате конечного субъекта сравнивается с идентификатором ключа субъекта только в одном сертификате - искомом сертификате УЦ. Этот процесс повторяется до тех пор, пока не будет найден сертификат, изданный головным УЦ, пунктом доверия иерархии.

На показаны пути сертификации для пользователей А, В, С и D в иерархической PKI. Каждый конечный субъект имеет единственный путь сертификации. Некоторые пути сертификации длиннее прочих, но все пути начинаются в корне иерархии. Запись [(ГУЦ -> УЦ 3 ); (УЦ 3 -> D)] означает, что путь от головного УЦ (ГУЦ) до пользователя D состоит из двух сертификатов.

Рис. 10.5.  Пути сертификации в иерархической PKI

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

Сетевая PKI

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

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

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

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

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

Построение пути в сетевой PKI

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

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

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

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

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

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

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

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

Архитектура расширенного списка доверия

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

Пример 10.5. Чтобы защищенно связываться с пользователями B, C и D, пользователь А должен включить в свой расширенный список доверия три удостоверяющих центра: по одному УЦ от каждой доверенной PKI (). Пользователь А доверяет своему собственному УЦ "Альфа", головному УЦ иерархической PKI компании "Бета" и одному УЦ в сетевой PKI компании "Гамма". Внутри каждой корпоративной PKI удостоверяющие центры могут быть связаны одноранговыми или иерархическими связями. Пользователь А может легко добавить новый УЦ или целую корпоративную PKI в свой список доверия. Сложность сертификатов зависит от связей в каждой корпоративной PKI.

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

Архитектура расширенных списков доверия не избавляет пользователей от необходимости поддерживать актуальность своих списков доверия и не решает проблемы компрометации УЦ. Что касается структуры списка доверия, то пользователь А, выбирая свои пункты доверия, может руководствоваться выгодой или целесообразностью, а вовсе не безопасностью. Длинный список доверия существенно труднее поддерживать, кроме того, как и в случае с простым списком доверия, работая с расширенным списком, пользователь А может вовремя не получить уведомление о компрометации какого-либо УЦ.

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

Построение пути для расширенного списка доверия

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

Часто используется достаточно простой метод построения пути сертификации в иерархической PKI . Если путь сертификации ведет к одному из доверенных пунктов, то считается, что построен валидный путь ; если нет, то проверяется, был ли выпущен верхний сертификат данного пути сертификации любым пунктом доверия. Если это так, то этот сертификат завершает путь ; если нет, то делается попытка построить путь от каждого пункта доверия к верхнему сертификату данного пути сертификации. Для повышения эффективности построения пути используется кэширование: в кэш-памяти компьютера сохраняются все возможные пути сертификации, каждый из которых помечается признаком качества. Простые иерархические пути считаются более качественными, чем сложные, в итоге выбираются пути с признаком более высокого качества, то есть наиболее короткие. Этот метод можно использовать и в сложных топологиях.

Кросс-сертифицированные корпоративные PKI

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

Рис. 10.8.  Кросс-сертифицированные корпоративные PKI и пути сертификации пользователя А

Пример 10.6. На УЦ пользователя А кросс-сертифицирован с головным УЦ иерархической PKI компании "Бета" и УЦ подразделения 2 в сетевой PKI компании "Гамма". Кроме того, удостоверяющие центры компаний "Бета" и "Гамма" кросс-сертифицированы друг с другом. Каждый пользователь поддерживает один пункт доверия. Пользователи A, B и D доверяют удостоверяющим центрам, которые выпустили их сертификаты, а пользователь С доверяет своему головному УЦ. Межкорпоративные отношения являются одноранговыми, а внутри корпоративных инфраструктур установлены или одноранговые, или иерархические связи. Имея свой список доверия, пользователь А не может добавлять в него новый УЦ внешней PKI по своему усмотрению, а должен полагаться на действия администратора своего пункта доверия. А дминистраторы УЦ обычно имеют более высокую квалификацию, чем пользователи, и способны определить надежность УЦ или PKI. Прежде чем устанавливать отношения кросс-сертификации, администраторы УЦ анализируют политику и практику применения сертификатов другого УЦ. После кросс-сертификации удостоверяющих центров пользователь В получает возможность проверять валидность сертификатов пользователей С и D из других PKI. В соответствии с принципами архитектуры расширенного списка доверия пользователям необходимо обновлять свои собственные списки доверия.

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

Построение пути для кросс-сертифицированных PKI

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

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

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

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

Рис. 10.9.  Восемь кросс-сертифицированных PKI

На представлены восемь корпоративных PKI. Кросс-сертификация всех пар инфраструктур требует установления 28 одноранговых связей и выпуска 56 сертификатов удостоверяющих центров. В связи с тем, что установление этих связей требует длительного изучения политик и практической работы удостоверяющих центров, реализация этой архитектуры становится слишком трудоемкой задачей.

Архитектура мостового УЦ

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

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

Пример 10.7. На мостовой УЦ связан с тремя корпоративными PKI. Первая PKI - это УЦ пользователей А и В, вторая - иерархическая PKI пользователя С, и третья - сетевая PKI пользователя D. Никто из пользователей не доверяет непосредственно мостовому УЦ. Пользователи А и В доверяют УЦ "Альфа", который является издателем их сертификатов, они доверяют мостовому УЦ постольку, поскольку их собственный УЦ выпустил для него сертификат. Пункт доверия пользователя С - головной УЦ в его иерархии; пользователь С доверяет мостовому УЦ косвенно, потому что данный головной УЦ выпустил для того сертификат. Пользователь D доверяет издателю своего сертификата - УЦ 3 компании "Гамма" и косвенно доверяет мостовому УЦ, потому что существует правильный путь сертификации от УЦ 3 до мостового УЦ. Пользователи А и В могут использовать мост доверия для установления отношений с пользователями С и D.

Рис. 10.10.  Связывание трех корпоративных PKI при помощи мостового УЦ и построение путей сертификации

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

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

Рис. 10.11.  Связывание восьми корпоративных PKI при помощи мостового УЦ

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

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

Построение пути в мостовой PKI

Мостовой УЦ имеет ряд преимуществ по сравнению с кросс-сертифицированными PKI. Разные пользователи по-прежнему строят разные пути сертификации для одного и того же сертификата конечного субъекта, и путь сертификации начинается с пункта доверия пользователя, который желает построить путь до данного сертификата. Однако существует только один кросс-сертификат, связывающий данную PKI со всеми сторонними PKI. Это существенно упрощает построение пути сертификации. На показаны пути сертификации, которые связывают пользователя А и пользователей B, C и D. Пользователь D может построить не один путь, так как является участником сетевой PKI.

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