Инфраструктуры открытых ключей

Вид материала

Документы

Содержание Модель строгой иерархии удостоверяющих центров Нестрогая иерархия удостоверяющих центров

Подобный материал:

• Программа выступлений на секциях конференции: Н. А. Богульская, 90.95kb.
• Поиск в Google Ключевые слова, 123.18kb.
• Шифрование почты, 689.07kb.
• Инфраструктура открытых ключей. Ssl, 56.57kb.
• Инструкция по обеспечению безопасности движения поездов при производстве работ по техническому, 752.1kb.
• Уважаемые организации – клиенты системы «СБиС++ Электронная отчетность», 31.48kb.
• Памятка для клиента по обеспечению безопасности при работе в Системе дбо, 30.25kb.
• Н. А. Поросятникова Информационная инфраструктура как одна из важнейших составляющих, 113.88kb.
• Это было одно из тех безобидных маленьких привидений, которые появляются ночью и никому, 491.6kb.
• Лекция рыночная инфраструктура региона определение, место и роль рыночной инфраструктуры, 468.16kb.

Модель строгой иерархии удостоверяющих центров

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

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


Рис. 5.1.  Строгая иерархия удостоверяющих центров

В модели строгой иерархии удостоверяющих центров все субъекты иерархии доверяют одному головному УЦ (будем использовать этот аналог термина "корневой" как более традиционный и понятный) [124]. Иерархия строится следующим образом.

1. Создается головной УЦ, который генерирует и подписывает сертификат для самого себя. Сертификат головного УЦ называют самоизданным (или самоподписанным) корневым сертификатом, именно он составляет основу доверия всех субъектов данной строгой иерархии.
   
2. Головной УЦ сертифицирует, то есть выпускает и подписывает сертификаты для удостоверяющих центров, непосредственно ему подчиненных. Количество подчиненных удостоверяющих центров может быть и нулевым, то есть подчиненные центры могут отсутствовать.
   
3. Каждый из этих удостоверяющих центров сертифицирует другие удостоверяющие центры, непосредственно ему подчиненные.
   
4. На уровнях иерархии от второго до последнего удостоверяющие центры сертифицируют конечных субъектов.
   

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

Пример 5.1. Рассмотрим, как конечный пользователь А, владеющий доверенной копией открытого ключа головного УЦ, может проверить подлинность, то есть верифицировать сертификат другого конечного субъекта В. Предположим, что сертификат субъекта В подписан УЦ₂, чей сертификат в свою очередь подписан УЦ₁, сертификат которого заверен головным УЦ. Субъект А при помощи открытого ключа головного УЦ - k_г может верифицировать сертификат УЦ₁ и извлечь доверенную копию открытого ключа УЦ₁ - k₁. Затем этот ключ может быть использован для верификации сертификата УЦ₂, в результате которой становится известна доверенная копия открытого ключа УЦ₂ - k₂ Ключ k₂ может быть использован для верификации сертификата субъекта В и получения доверенной копии его открытого ключа - k_В. Субъект А может теперь использовать ключ k_В (в зависимости от его типа) для шифрования сообщений, адресованных субъекту В, или проверки цифровых подписей, которые создал субъект В. Описанная процедура позволяет обеспечить защищенную связь между субъектами А и В.

Нестрогая иерархия удостоверяющих центров

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

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