Граф доверия

Зед, Рут, Алиса, другие стороны ИОК генерируют личные, только им известные,ключи. Ключи, вообще говоря, уникальны, и эта уникальность является выражением индивидуальности сторон в цифровом мире. Важно, что ключи секретны: разгласив свой ключ, Алиса позволит любой другой стороне скопировать свою индивидуальность.

По личному ключу Алиса строит открытый ключ. Открытый ключ вместе с именем Алисы и другими реквизитами подписывается Рутом, и в результате получается сертификат. Алису (A) называют субъектом сертификата, Рута (R) – эмитентом. Выпуск сертификата обозначим как R → A. Боб (B) также получает сертификат у Рута, сертификат Руту выдает Зед (Z), предварительно Зед выпускает сертификат самому себе:

R → B, Z → R, Z → Z.

Сертификат является видом электронного документа, т. е. документа с подписью. Доверие к стороне переносится на документы, подписанные этой стороной, и, наоборот, доверие к стороне возникает из доверия к ее сертификату. Доверяя Зеду, мы доверяем выпущенному Зедом сертификату Рута и, как следствие Руту. Доверяя Руту, мы доверяем Алисе и Бобу. Доверяя Алисе и Бобу, мы доверяем подписанным Алисой и Бобом документам. Как видим, доверие транзитивно.

Построим граф доверия, в котором вершины – это стороны ИОК, а дуги связывают эмитентов с субъектами. В простейших иерархических инфраструктурах граф доверия представляет собой лес, корнями деревьев которого являются точки доверия:

В более сложных ИОК корни могут связываться или интегрироваться. При связывании одна точка доверия выпускает сертификат для другой:

При интеграции точки доверия получают сертификаты у супер-корня, называемого мостом:

В еще более сложных ИОК граф доверия может содержать компоненты без иерархии, построенные по принципу все равны и часто называемые паутинами доверия (Web of Trust). Паутина доверия используется в известной системе защищенной почты PGP.

Алиса, дополнительно к сертификату Рута, может получить еще один сертификат у Трента. Чтобы подчеркнуть эмитента сертификата, будем писать A(R) и A(T) вместо A. Открытые (и соответственно личные) ключи сертификатов A(R) и A(T) могут как совпадать, так и отличаться. Это не будет иметь для нас значения.

Алиса и Боб – это конечные участники ИОК – листья дерева доверия. Они не имеют права выпускать сертификаты другим сторонам. Запрет регламентирован сбросом определенных флагов в расширениях KeyUsage и BasicConstraints. В свое время П. Гутманн предлагал отменить запрет, разрешив конечным участникам выпускать самим себе краткосрочные сертификаты, но предложение Гутманна не прижилось.

При проверке подписи конечного участника A прежде всего требуется проверить, что в графе доверия имеется маршрут от некоторого корня Z до вершины A. Иными словами, что доверие к Z транслируется в доверие к A. Искомый маршрут называется маршрутом доверия или цепочкой сертификатов.

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

R → A(R) и R → T(R) → A(T).

Даже небольшое число коллизий сильно увеличивает число цепочек, которые требуется проверить при поиске маршрута к заданному листу. В RFC 4158 задача поиска подходящей цепочки обсуждается с алгоритмической точки зрения. Учитывается ограничение X.509 (СТБ 34.101.19): сертификаты цепочки не должны повторяться. Это ограничение позволяет преобразовать граф доверия с потенциально большим числом циклов в лес (граф без циклов), дублируя при необходимости некоторые вершины. Поиск маршрутов в лесу является достаточно простой задачей.

Сертификат субъекта содержит имя эмитента. Но для связывания сертификатов имени недостаточно, ведь эмитент может иметь несколько сертификатов. Для упрощения связывания и, как следствие, упрощения поиска цепочек в сертификаты включаются расширения SubjectPublicKeyIndentifier (SKID) и AuthorityPublicKeyIndentifier (AKID). Расширения идентифицируют открытые ключи субъекта и эмитента. Коллизии в графе доверия разрешаются сравнением SKID сертификата эмитента с AKID сертификата субъекта.

Сужение X.509, зафиксированное в СТБ 34.101.19, требует обязательного включения расширений AKID/SKID в сертификаты. При этом X.509 не требует, чтобы открытые ключи сертификатов отличались или чтобы ключи безошибочно идентифицировались в расширениях. По этим причинам учет SKID/AKID при построении маршрутов сертификации не сделан обязательным ни в X.509, ни в RFC 4158.

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

В свое время в США был разработан набор тестов для проверки цепочек сертификатов. Это, так называемый, PKITS (Public Key Interoperability Test Suite). Тесты PKITS адаптированы в нашей Испытательной лаборатории и могут использоваться при проверке подсистем ГосСУОК.

Упомянутые аттестаты – это утверждения о действительности сертификатов цепочки и, в общем случае, любые другие утверждения о любых других данных, циркулирующих в ИОК. Именно аттестаты выпускают упомянутые Ольга, Том и Дейв. Сертификаты являются частным случаем аттестатов. Об аттестатах мы поговорим в следующей части.

Новости