Какие модели архитектуры удостоверяющих центров применяются на практике

21.Модели доверия уц. Иерархическая модель.

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

Иерархическая модель.

УЦ0-корнвой УЦ сам себе выдает сертификат.

В случае, когда между собой взаимодейств-т пользователи одного и того же УЦ, например, А и В, проблем с проверкой подлинности сертификатов нет. А и В доверяют УЦ111 и имеют его корневой сертификат, поэтому могут проверить сертификат любого пользователя УЦ 111.

При взаимодействии а и С ситуация усложняется: А не доверяет УЦ 121, т.к.не я вяется его пользователем и не имеет его сертификата. Аналогично, С не доверяет УЦ 111.Решение:

А обращается в свой родной УЦ и узнает, какой УЦ выпускал для него сертификат: УЦ11 является родителем.

А запрашивает сертификат УЦ11.

Повторяя пункты 1 и 2 пользователь добирается до коренного УЦ0 и получает его сертификат. Процедура м.б.проще, если при регистрации А ему сразу выд-ся вся цепочка сертификатов.

А узнает, какая цепочка сертификатов нужна для проверки С. Эта информация содержится в самом сертификате С.

Зная корневой сертификат УЦ0, проверяется следующий сртификат в цепочке

Убедившись, что сертификат УЦ12 верен, с его помощью проверяется сертификат УЦ121, а затем и сертификат С.

Т.о. можно проверить подлинность сертификатов любого пользователя такой модели.

+Сравнительная простота реализации

+Удобство наложения такой модели на структуру ведомств

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

22.Модели доверия уц. Сетевая модель.

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

Сетевая модель.

В данной модели все УЦ являются независимыми, никто никому не подчиняется. Пользователи одного и того же УЦ легко друг с другом взаимодействуют, т.к.доверяют одному и тому же УЦ.

Пользователи разных УЦ между собой взаимодействовать не могут, т.к.нет доверия между разными УЦ и проверить сертификаты другого УЦ невозможно. Решением проблемы явл-ся исп-е мех-ма кросс-сертификации.

Кросс-сертификация – процесс установки доверит отношений между ранее не связанными УЦ. Он заключается в использовании кросс-сертификатов:

УЦ5 запрашивает у УЦ3 его самоподписанный сертификат.Данный серт-т должен быть получен защищенным способом(лично или по защищенному каналу связи)

Уц5 подпис-т полученный от УЦ3 сертификат своим закрытым ключом, тем самым подтверждая, что он доверяет УЦ3. Дважды подписанный сертификат и есть кросс-сертификат.

Аналогично поступает УЦ3.

Пользователь А желает проверить подлинность серт-та С. Для этого он берет кросс-сертификат в УЦ5, проверяет его подлинность с помощью сертификата УЦ5. Т.о.А убежд-ся, что открытый ключ УЦ3 достоверен и им можно пользоваться.

С помощью уже достоверного сертификата УЦ3 и ключа, который в нем лежит, проверяется подлинность сертификата С.

+ Компрометация любого из УЦ фатальна только для его пользователей и не касается других

— Для большой сети из N УЦ каждому УЦ придется получить N-1 кросс-сертификат.

Выбор архитектуры PKI

Любой тип архитектуры PKI имеет свои слабые и сильные стороны. Не существует архитектуры, совершенной для всех сред. Выбор оптимальной архитектуры осуществляется с учетом специфики деятельности, потребностей и возможностей организации [70].

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

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

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

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

Кросс-сертификация — простое решение для связывания небольшого числа корпоративных PKI. Оно эффективно, когда две организации имеют налаженные связи. Например, две компании, которые подписали договор о долговременном сотрудничестве или организации совместного предприятия, могут кросс-сертифицировать свои PKI. Однако такое решение неприемлемо в том случае, когда в совместную работу вовлечено множество сторон или деловые отношения развиваются динамично.

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

Читайте также

Обзор 64-разрядной архитектуры

Обзор 64-разрядной архитектуры С точки зрения программиста основная трудность при переходе от 32-разрядной модели к 64-разрядной заключается в том, что размер указателей и таких системных типов данных, как size_t и time_t, теперь может составлять 64 бита. Поэтому виртуальное

4.1. Особенности архитектуры

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

API-ориентированные архитектуры

API-ориентированные архитектуры Учитывая недостатки процессоро-ориентированных архитектур, многие ISV, производители оборудования и организации по стандартизации совместно разрабатывали архитектуры, в основе которых лежит интерфейс прикладных программ API[ 8 ] (application

Расширения архитектуры PowerPC

Расширения архитектуры PowerPC Так как первое поколение процессоров PowerPC создавалось специально под AS/400 и не было PowerPC в полном смысле, мы решили дать этим процессорам новое название s PowerPC Optimized for the AS/400 Advanced Series, но так как это труднопроизносимо, решено было остановиться на

Обзор архитектуры MI

Обзор архитектуры MI Определение архитектуры MI не привязано к аппаратуре. Это не физический, а логический интерфейс системы. Как уже говорилось в главе 1, архитектура MI предлагает полный набор API для OS/400 и всех приложений. Этот набор полон по определению; то есть ни система,

1.11. 64-разрядные архитектуры

1.11. 64-разрядные архитектуры С середины до конца 90-х годов развивается тенденция к переходу на 64-разрядные архитектуры и 64-разрядное программное обеспечение. Одной из причин является более значительная по размеру адресация внутри процесса (например, 64-разрядные

Подходящая метафора для архитектуры убеждения

Подходящая метафора для архитектуры убеждения Не так давно было выпущено несколько книг, в которых можно выбрать концовку на свой вкус (например, «Игра в классики»[7] Хулио Кортасара). Автор предлагает «перейти на страницу 121», если считаете, что произойдет А, на страницу 84,

Глава 11 Ключевая часть архитектуры

Глава 11 Ключевая часть архитектуры Запуская браузер «Яндекса», Волож обозначил его предназначение так: для «реальных дорог», то есть в условиях плохо работающего мобильного Интернета.Подарок к своему пятнадцатилетнему юбилею «Яндекс» сотворил 1 октября 2012 г., предложив

Глава 11. Проектирование системной архитектуры

Глава 11. Проектирование системной архитектуры Потребность в архитектуреНа протяжении многих лет я слышала разные определения программной архитектуры: от «программная архитектура — это то, чем занимаются специалисты по программной архитектуре» до «программная

ОО-изменение архитектуры (re-architecturing)

ОО-изменение архитектуры (re-architecturing) Понятие внешней программы хорошо соответствует остальной части подхода. Основной вклад метода — архитектурный: объектная технология говорит, как разработать структуру систем, чтобы обеспечить расширяемость, надежность и повторное

6.1. ПОНЯТИЕ АРХИТЕКТУРЫ ПРОГРАММНОЙ СИСТЕМЫ

6.1. ПОНЯТИЕ АРХИТЕКТУРЫ ПРОГРАММНОЙ СИСТЕМЫ Разработка архитектуры системы — это процесс разбиения большой системы на более мелкие части. Для обозначения этих частей придумано множество названий: программы, компоненты, подсистемы…Процесс разработки архитектуры —

Основные понятия архитектуры PKI

Основные понятия архитектуры PKI Архитектура PKI описывает структуру отношений доверия между удостоверяющими центрами и другими субъектами инфраструктуры. По архитектуре PKI делятся на разные типы в зависимости от следующих характеристик:* количества удостоверяющих

Об архитектуре системы удостоверяющих центров и типах сертификатов

Продолжая обсуждение темы о развитии систем PKI (Public Key Infrastructure) в нашей стране (см. PC Week/RE, N 44/2003, с. 28), остановимся еще на двух моментах — архитектуре системы удостоверяющих центров (УЦ) в России и типах выпускаемых ими сертификатов. Целесообразно обсудить эти темы именно сейчас, когда готовятся положения по лицензированию деятельности УЦ, сертификации, требованиям к безопасности и другие важные документы, призванные регулировать данную сферу деятельности. Ясность в этих вопросах позволит каждому действующему УЦ определить свое назначение и место в общей архитектуре и понять предъявляемые к нему требования.

Основной задачей создания системы УЦ будем считать построение юридически значимого пространства информационного обмена в существующей системе межсубъектных отношений. Таковыми субъектами являются: государство (в том числе органы муниципальной власти), юридические и физические лица, взаимодействующие между собой по схемам: 1) государственная структура — государственная структура; 2) государственная структура — юридическое лицо; 3) государственная структура — физическое лицо; 4) юридическое лицо — юридическое лицо; 5) юридическое лицо — физическое лицо; 6) физическое лицо — физическое лицо.

Модель структуры УЦ России

В качестве примеров взаимодействия можно привести системы административного и бухгалтерского документооборота (схемы 1, 2, 4), финансового документооборота (1-5), доверительных отношений (3, 5, 6).

Для достижения эффекта единого информационного пространства взаимодействие по всем схемам должно проходить в рамках создания публичных PKI-систем. При этом схемы 1, 4 и 5 допускают создание собственных информационных пространств (корпоративных PKI-систем).

Состав участников информационного обмена в рамках публичных PKI-систем предполагает наличие как минимум двух типов сертификатов: · для физических лиц высокой степени доверия, изготавливаемых на основе паспортных данных и соответственно имеющих статус электронного удостоверения личности; · для юридических лиц высокой степени доверия, также выдаваемых на имя физического лица при предъявлении им комплекта документов, которыми подтверждаются его полномочия от той или иной организации (собственно тот же комплект документов , что и при оформлении карточек с образцами подписей для банка).

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

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

Все, что касается физических лиц, особенно при взаимодействии по схемам 3 и 6, должно быть реализовано в рамках государственной программы, не только закрепляющей порядок изготовления и выдачи сертификатов, но и направленной на создание соответствующих электронных сервисов. Если же говорить об архитектуре системы УЦ для этой программы, то представляется, что это должен быть единый российский государственный УЦ (РГУЦ) с разветвленной сетью регистрационных центров (РЦ). РЦ должны быть установлены по всей стране в паспортных столах (выдача паспортов) и ЗАГСах (ликвидация паспортов в связи со смертью). В последних можно устанавливать только рабочие места для передачи в УЦ уже недействительных сертификатов. Размещение РЦ именно в этих учреждениях позволит сформировать единую базу данных "электронных паспортов" граждан РФ, необходимую для функционирования государственных электронных сервисов, с обеспечением ее соответствия базе данных обычных паспортов. Такая архитектура при минимальных затратах реально обеспечит высокие требования к единому РГУЦ, а создание РЦ не приведет к появлению серьезных технологических проблем в эксплуатирующих их структурах. С сертификатами, изготовленными РГУЦ, возможна работа не только в рамках взаимодействия по схемам 3 и 6, но и в корпоративных системах (схема 5) при условии признания конкретной корпоративной системой соответствующей сертификационной политики и практики РГУЦ.

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

Для поддержки взаимодействия между государственными структурами (схема 1) может быть также использована двухуровневая архитектура УЦ, где на нижнем уровне действуют ведомственные УЦ с разветвленной сетью РЦ, а на верхнем — все тот же РГУЦ. Сертификационная политика и практика та же самая, что и в случае с обычными юридическими лицами.

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

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

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

Модели и механизмы доверия

Модель распределенного доверия разделяет доверие между двумя или несколькими удостоверяющими центрами. Пусть пользователь А владеет копией открытого ключа своего пункта доверия — УЦ₁ , а пользователь В — копией открытого ключа своего пункта доверия — УЦ₂ . УЦ₁ — корень строгой иерархии, которая включает пользователя А , УЦ₂ — корень строгой иерархии, в которую входит пользователь В . Если каждая из этих иерархий является неглубокой иерархией с доверенным издателем, то вместе они образуют полностью одноранговую сеть , потому что все удостоверяющие центры являются действительно независимыми одноранговыми узлами сети. В этой архитектуре отсутствуют подчиненные удостоверяющие центры. С другой стороны, если каждая иерархия является многоуровневой, то результат объединения иерархий имеет полностью древовидную структуру. Отметим, что головные удостоверяющие центры связаны друг с другом равноправными отношениями, но каждый головной УЦ действует как вышестоящий для одного или более подчиненных удостоверяющих центров. Одним из вариантов архитектуры распределенного доверия может быть гибридная конфигурация с одной или более иерархиями с доверенным издателем или одним или более многоуровневыми деревьями [44]. Эта конфигурация изображена на рис. 5.2.

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

Изолированные PKI -домены могут быть сконфигурированы разными способами, в том числе на базе строгой иерархии, архитектуры полностью одноранговой сети или любой модели доверия , обсуждающейся в данной лекции. Важно, чтобы поддерживалась функциональная совместимость между любой комбинацией этих моделей доверия [96].

Процесс взаимного связывания одноранговых головных удостоверяющих центров обычно называют кросс-сертификацией , хотя в последнее время все чаще используется термин «создание сети PKI » (в частности для полностью древовидной и гибридной архитектур). Для кросс-сертификации , как правило, используются два разных типа конфигурации PKI : сетевая и мостовая ( конфигурация hub-and-spoke).

Следует отметить, что в настоящее время специалистами изучаются и предлагаются и другие методы создания отношений доверия между PKI -доменами:

• взаимное распознавание;
• использование списков доверия к сертификатам;
• применение сертификатов аккредитации.

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

Список доверия к сертификатам ( Certificate Trust List — CTL), по определению специалистов корпорации Microsoft, является заверенным цифровой подписью списком сертификатов головных удостоверяющих центров, который признается администратором корпоративной сети пригодным для выполнения аутентификации клиентов и защиты электронной почты.

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

Сетевая конфигурация

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

Мостовая конфигурация (конфигурация hub-and-spoke)

В мостовой конфигурации каждый головной УЦ устанавливает отношения кросс-сертификации с единственным центральным УЦ, в чьи функции входит обеспечение таких взаимных связей [101]. Центральный УЦ иногда называют «втулкой» (hub), соединенной «спицами» (spoke) с различными головными удостоверяющими центрами, а иногда называют мостовым УЦ , устанавливающим связи между парами головных удостоверяющих центров. Преимущество этой конфигурации заключается в том, что в случае полной связи требуется заключение только n -соглашений о кросс-сертификации для n -головных удостоверяющих центров, потому что каждый головной УЦ кросс-сертифицируется только с центральным УЦ.

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