• Категории
  • Подписка
  • Разместить статью
15/01/10 2 2217 Управление открытыми ключами       
-

Аутентификация открытых ключей

klyuch_securos.org.uaПорядок получения и аутентификации открытых ключей издателей существенно зависит от количества издателей и отношений доверия между ними.

В простейшем случае издатель один (наверное, это ЦС). Открытый ключ этого издателя пользователи получают каким-нибудь безопасным обходным (out-of-band) путем (например, путем прямого контакта с администратором ЦС).

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

Рассмотрим последовательность действий пользователя, который получает открытый ключ и сведения о полномочии издателя в форме сертификата, выданного другим издателем. Общая идея заключается в получении и проверке действительности цепи таких сертификатов (Certificate Path, или Certificate Chain), который соединяет данного издателя с издателем, открытый ключ (сертификат) которого данный пользователь уже имеет (и проверил) и полномочие которого признал.

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

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

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

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

Сократить время, которое тратится на собирание и проверку цепей сертификатов, можно путем некоторого осложнения структуры ИУОК, а именно:

  • создание перекрестных (кросс-) связей между ЦС;
  • введение в ИУОК дополнительных корневых ЦС.

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

Введение в ИУОК дополнительных корневых ЦС разрешает сократить длину цепей сертификатов.

Осложнение структуры ИУОК усложняет как пользование ею (в системах с перекрестными связями придется принимать решение о выборе одной цепи с нескольких альтернативных, в системах с несколькими корневыми ЦС – получать обходным путем больше информации), так и ее поддержку.

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

Подытоживая сказанное о порядке верификации цифровых сертификатов, сформулируем вопрос, на который желательно найти ответ, характеризуя конкретную ИУОК с этой точки зрения.

Поддерживается ли проверка действительности сертификатов, выданных ЦС, в режиме онлайн? В режиме офлайн? Поддерживается ли сверка с СОС в режиме онлайн? В режиме офлайн? Если поддерживается сверка с СОС в режиме офлайн, как решаются проблемы задержки и больших размеров СОС? Если применяются ЦС, то может ли их быть больше одного? Если так, то какую структуру они создают за отношениями доверия (простую иерархическую, с перекрестными связями, с несколькими корневыми ЦС)? Поддерживается ли концепция кумулятивного доверия к издателям, а если поддерживается, какие критерии могут применять пользователи при принятии решений о доверии?

Интегральной (хотя и не исчерпывающей) характеристикой ИУОК есть формат сертификатов, который в ней применяется. Причем формат сертификата целиком определяет возможности ИУОК. Рассмотрим дальше основные характеристики наиболее распространенных форматов: PGP, X.509v1, 2, 3.

***

Надоели старые стены, хотите сменить обстановку, заходите на форум о строительстве (см. www.stroysebe.ru) и узнайте как это сделать!..


2 комментария на «“Аутентификация открытых ключей”»

  1. Мда, видимо лучшего так и не создали. По сути все держится на доверии между корневыми ЦС и ЦС более низкого уровня.

  2. Космодром:

    Тема старая конечно , но прочитал с удовольствием :)

Добавить комментарий

Яндекс.Метрика