Пример 10.1. Пусть пользователь А пытается проверить надежность сертификата пользователя В, с которым он желает взаимодействовать [44]. Предположим, что пользователь В сертифицирован УЦ3, УЦ3 кросс-сертифицирован с УЦ2 (наряду с другими удостоверяющими центрами), УЦ2 кросс-сертифицирован с УЦ1 (наряду с другими), а пользователь А владеет доверенной копией открытого ключа УЦ1 (см. рис. 10.1).
Так как пользователь А владеет сертификатом пользователя В, то знает, что последний сертифицирован УЦ3. В силу того, что УЦ3 кросс-сертифицирован с несколькими удостоверяющими центрами (в нашем примере - тремя), пользователю А необходимо определить, какой кросс-сертификат добавит связь в путь, который он строит. УЦ1 не подписывал никакой из сертификатов УЦ3 (ни УЦ2, ни УЦ6, ни УЦ7 ), поэтому пользователь А должен действовать путем проб и ошибок. Он проверяет каждый из кросс-сертификатов, связанных с УЦ2, УЦ6 и УЦ2, - не подписан ли какой-либо из них УЦ1. В данном примере УЦ2 владеет кросс-сертификатом, заверенным УЦ1, поэтому работа пользователя А по построению пути на этом завершается, поскольку УЦ1 является его пунктом доверия.
Очевидно, что это задание существенно усложняется, если УЦ3 и УЦ2 кросс-сертифицированы со многими другими удостоверяющими центрами и/или если путь между УЦ1 и УЦ3 содержит больше промежуточных удостоверяющих центров. В таких случаях для построения пути используются алгоритмы нахождения пути, базирующиеся на теории графов, включая такие алгоритмы поиска, как поиск преимущественно в глубину (не рекомендуемый из-за большого числа лишних вычислений в общем случае), поиск преимущественно в ширину и эвристический алгоритм.
Простая архитектура PKI
Архитектура PKI может быть очень простой, если у пользователей - простые требования. В этом разделе рассматриваются два типа простой архитектуры: одиночный УЦ и списки доверия УЦ. Простая архитектура достаточна для связывания пользователей одного и того же УЦ или нескольких удостоверяющих центров, которым нет необходимости устанавливать отношения доверия с другими центрами, причем сертификаты выпускаются только для пользователей.
Одиночный УЦ
Базовой архитектурой PKI является одиночный УЦ, который обеспечивает свое сообщество пользователей сертификатами и списками САС [97]. В этой конфигурации все пользователи доверяют одному УЦ, который выпускает сертификат сам для себя. По определению, новые удостоверяющие центры не могут добавляться в PKI. Поскольку в данной инфраструктуре имеется только один УЦ, здесь отсутствуют отношения доверия между несколькими удостоверяющими центрами. Пользователи принимают сертификаты и списки САС, выпущенные единственным УЦ. В результате пути сертификации строятся на основании одного сертификата и одного САС. В силу того, что все остальные сертификаты являются сертификатами пользователей, для анализа пути не используется информация, которая описывает или ограничивает отношения доверия УЦ.
На рис. 10.2 изображен одиночный УЦ, который выпускает сертификаты для служащих компании, в том числе для пользователей А и В. Пользователь А доверяет корпоративному УЦ, поэтому может легко строить и проверять путь сертификации пользователя В. Будучи самой простой в реализации, эта архитектура трудно масштабируется в условиях очень больших или разнородных сообществ пользователей. Когда у пользователей А и В по роду работы возникает необходимость защищенно связаться с пользователем P из другой компании, им необходима архитектура, объединяющая их собственный УЦ и внешние удостоверяющие центры, поскольку пользователь P, не являясь служащим компании, где работают пользователи А и В, имеет сертификат, изданный другим УЦ.
Рис. 10.2. Одиночный УЦ и пути сертификации
В PKI с одиночным УЦ существует только одна точка отказа. Компрометация УЦ делает недействительными все выпущенные им сертификаты и информацию о пункте доверия. Каждый пользователь такой PKI должен быть немедленно информирован о компрометации, в противном случае пользователи, доверяющие ненадежному УЦ, будут подвергаться риску. Для того чтобы восстановить работу УЦ, необходимо повторно выпустить все сертификаты и распространить новую информацию о пункте доверия среди всех пользователей.
Построение пути в простой PKI
В простой PKI путь сертификации состоит из одного сертификата. Когда имеется одиночный УЦ или все удостоверяющие центры содержатся в списке доверия, для связывания пункта с любым субъектом необходим только один сертификат. В этом случае единственный сертификат образует весь путь, который должен проверяться, как и любой другой путь сертификации.
На (рис. 10.2) показаны пути сертификации пользователей A, B, C и N в простой PKI, представляющей собой одиночный УЦ. Каждый путь состоит из одного сертификата. Запись [(УЦ "Альфа") -> А] означает, что один сертификат, выпущенный УЦ "Альфа" для пользователя А, составляет весь путь.
Простые списки доверия
Список доверия - это наиболее простая модификация архитектуры одиночного УЦ. В этой архитектуре PKI-сервисы предоставляются несколькими удостоверяющими центрами, не связанными между собой отношениями доверия [70]. Каждый пользователь поддерживает список удостоверяющих центров, которым доверяет, и полагается на валидность сертификатов и САС, выпущенных любым УЦ из списка. Новые удостоверяющие центры могут добавляться в PKI в результате расширения списка доверия. Между удостоверяющими центрами, как и в случае одиночного УЦ, не установлены отношения доверия. Все, что необходимо иметь пользователю, - это один сертификат и один САС. Сложность поддержки списка доверия возрастает с увеличением числа пунктов доверия. Поскольку в этой архитектуре отсутствуют сертификаты удостоверяющих центров, дополнения сертификатов, а также построение и анализ пути сертификации достаточно просты.
Пример 10.2. Пусть пользователь А, работающий в компании "Альфа", желает защищенным образом связаться с пользователем С, работающим в компании "Бета". Поскольку между компаниями "Альфа" и "Бета" не установлены отношения доверия, невозможно построить путь сертификации, начинающийся в УЦ, которому больше всего доверяет пользователь А, и заканчивающийся сертификатом пользователя С. Пользователю А необходимо добавить УЦ компании "Бета" в свой список доверия (см. рис. 10.3), только после этого он получает возможность проверить действительность сертификата пользователя С.
Рис. 10.3. Поддержка нескольких удостоверяющих центров через списки доверия
Одно из преимуществ этой архитектуры заключается в ее простоте: нет никаких путей сертификации, а есть только сертификаты. Кроме того, очень прост способ добавления в инфраструктуру нового УЦ: пользователь А включает в свой список доверенных удостоверяющих центров еще один УЦ. Однако простые списки доверия имеют существенные недостатки. Пользователь А добавляет новые удостоверяющие центры в свой список доверия, когда желает защищенно связываться с пользователями других организаций. При этом пользователю А необходимо предварительно проверить надежность компании, прежде чем добавлять ее УЦ в свой список доверия. Расширение списка доверия вынуждает пользователя самостоятельно поддерживать и своевременно обновлять больший объем критически важной информации о доверенных удостоверяющих центрах. Кроме того, списки доверия осложняют управление компрометацией УЦ. Если скомпрометирован секретный ключ УЦ, компания, скорее всего, немедленно уведомит об этом всех своих пользователей. Однако сторонняя для пользователя А компания не имеет с ним прямых связей и может даже не иметь информации о том, что пользователь А ей доверяет. Пользователь А будет продолжать полагаться на сертификаты скомпрометированной компании и подвергать себя риску до тех пор, пока не узнает о компрометации УЦ.
