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

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

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

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

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

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

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

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

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

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

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

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

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