Приложение 3. Различные модели построения доверительных отношений
Модель 1 (иерархическая)
Данная модель характеризуется прямой иерархией доверительных отношений, регистрируемых на уровне единого (федерального, отраслевого, корпоративного и т.п.) корневого удостоверяющего центра (УЦ), который выпускает сертификаты УЦ уровнем ниже. Они в свою очередь выпускают сертификаты УЦ следующего уровня и т.д. до сертификатов конечных пользователей. Таким образом все образующие домен сертификаты в данной модели связаны в строгом иерархическом порядке и образуют древовидную структуру.
Такая модель существенно упрощает вопросы по обеспечению взаимодействия пересылаемых информационных блоков ЭЦП и сертификатов внутри корневого домена, проверка подлинности приходящего сертификата происходит по ясно выстроенной иерархической “цепочке доверия” – пути следования сертификата.
Иерархическая архитектура имеет следующие преимущества:
· иерархическая архитектура аналогична существующим федеральным и ведомственным организационно-управляющим структурам;
· иерархическая архитектура может быть легко наложена на иерархическое дерево имен;
· иерархическая архитектура определяет простой алгоритм поиска, построения и верификации цепочек сертификатов для всех взаимодействующих сторон.
Вместе с тем использование только иерархической архитектуры без сочетания с другими моделями имеет следующие ограничения:
|
|
|
· для обеспечения взаимодействия конечных пользователей они должны входить в домен одного корневого УЦ;
· компрометация секретного ключа корневого УЦ приостанавливает работу всего домена и требует защищенной доставки нового сертификата до каждого конечного пользователя.
Модель 2 (браузерная)
В данной модели пользователь входит сразу в несколько иерархических доменов ИОК, для чего используются т.н. «списки доверенных удостоверяющих центров», публикуемые той или иной организацией для облегчения проверки сертификатов пользователей из других доменов. В данных списках представляются те УЦ, которым можно доверять при определенных условиях (нередко разные типы бизнес-взаимодействия подразумевают использование услуг разных УЦ).
Для данной модели, ввиду удобства использования получившей широкое распространение среди пользователей сети Интернет, характерно наличие рисков при определении списков доверенных УЦ, обеспечении защиты доверенных списков (публикуемых обычно через веб-браузеры) от несанкционированного изменения.
Модель 3 (сетевая)
В сетевой архитектуре каждый из удостоверяющих центров является независимым, и для установления доверия между центрами, каждая пара центров формирует кросс-сертификат, содержащий два объекта: сертификат открытого ключа первого УЦ, подписанный вторым УЦ, и сертификат второго УЦ, подписанный первым УЦ. В результате взаимной сертификации формируется сетевая (ячеистая) топология доверия, основанная на связи двух ячеек (удостоверяющих центров). В сетевой схеме для взаимной проверки сертификатов двух пользователей может возникнуть несколько путей.
|
|
|
Сетевая архитектура имеет следующие преимущества:
· она более гибкая, чем иерархическая;
· конечный пользователь должен доверять, только центру, издавшему его сертификат;
· возможна непосредственная кросс-сертификация различных УЦ, пользователи которых часто взаимодействуют между собой, что сокращает процесс верификации цепочек;
Вместе с тем использование только сетевой архитектуры имеет следующие недостатки:
· алгоритм поиска и построения цепочек сертификатов для всех взаимодействующих сторон очень сложный;
· пользователь не может предоставить цепочку, которая обеспечивает проверку его сертификата всеми остальными пользователями.
Одним из способов реализации сетевой архитектуры является “мост”, через который проходят отношений доверия в виде кросс-сертификатов (Рис 3).
|
|
|
Рис. 3 Принцип “моста доверия”
В данном примере если user1, из одного домена ИОК, желает проверить сертификат user2 из другого домена ИОК, то он строит путь сертификации от своей точки доверия через мостовой УЦ (МУЦ) в другой домен используя его как ”мост доверия”. В данном случае путь сертификации будет иметь вид:
CertX(X) → CertX(Y) → CertY(Z) → CertZ (user2).
Особенности сразу видны из данного примера:
· точки доверия остаются внутри домена ИОК;
· отношения доверия представляют собой кросс-сертификаты;
· домены объединяемых через мост организаций имеют ту архитектуру ИОК, которая им необходима для эффективного функционирования.
Если предположить, что нужно организовать взаимодействие между n независимыми доменами ИОК, количество кросс-сертификационных отношений в данном случае будет равно n, тогда как в случае с кросс-сертификацией отдельных доменов - n2-n. Таким образом имеет место линейный, а не квадратичный рост числа кросс-сертификационных отношений.
[1] В целях упрощения в данном документе опускаются еще два уровня взаимоотношений («физическое лицо – хозяйствующий субъект» и «физлицо – физлицо»), регулирование которых неизбежно затронут УФО и всю систему, как минимум, в части создания отечественного варианта т.н. CPS (Certification Practice Statement) – свода правил и требований.
|
|
|
[2] Следует заметить, что СКЗИ, соответствующие международным стандартам, как правило обеспечивают взаимную совместимость, что значительно упрощает и удешевляет взаимодействие пользователей ИОК.
[3] Такая трансформация может выглядеть вполне убедительно, если принять во внимание развитие на основе FBCA структур для сервисов типа e-government (e-authentication, etc)
Дата добавления: 2018-04-04; просмотров: 302; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!