Концепция доверия в PKI
При развертывании PKI необходимо иметь представление о распространенных моделях доверия, таких как:
* строгая иерархия удостоверяющих центров;
* нестрогая иерархия удостоверяющих центров;
* иерархия на базе политик;
* модель распределенного доверия;
* четырехсторонняя модель доверия;
* Web-модель доверия;
* модель доверия, сконцентрированного вокруг пользователя.
На практике редко используются модели доверия, которые считаются новыми в этой области. Рассмотрим перечисленные модели вместе с механизмом ( кросс-сертификацией ), который может играть важную роль в расширении доверия и управлении им.
Прежде чем перейти к описанию моделей доверия, важно внести ясность, что понимается под доверием в данном контексте. Наиболее точно смысл "доверия", по мнению авторов, передает формулировка рекомендаций X.509 ITU-T : можно сказать, что один субъект "доверяет" другому субъекту, когда предполагает, что второй субъект будет вести себя точно так, как ожидает от него первый субъект. Таким образом, доверие имеет дело с предположениями, ожиданиями и поведением. Очевидно, это означает, что доверие не может быть измерено количественно, существует риск, связанный с доверием, и установление доверия не всегда происходит автоматически (например, когда субъектами в упомянутом выше определении являются люди). Концепция доверия раскрывает:
* где и как инициируется доверие в PKI;
* каким сертификатам может доверять субъект;
* как может быть подтверждено такое доверие;
* при каких обстоятельствах это доверие может быть ограничено или может контролироваться в данной среде.
В частности, в контексте PKI приведенное выше определение может быть использовано следующим образом: конечный субъект доверяет УЦ, когда предполагает, что последний будет устанавливать и поддерживать точное связывание атрибутов каждого субъекта с его открытым ключом (например, будет точно представлять идентичность субъекта, для которого он выпускает сертификат).
Термин "доверие" часто используется и по-другому: в литературе о PKI бывают ссылки на так называемый доверенный открытый ключ. Смысл термина "доверенный" в данном случае не связан с предположениями и ожиданиями одного субъекта относительно поведения другого субъекта. Можно сказать, что открытый ключ является "доверенным" для субъекта, когда тот уверен, что данный открытый ключ соответствует секретному ключу, который действительно легитимно принадлежит определенному поименованному субъекту. Обычно имя (или информация, идентифицирующая субъекта) появляется в сертификате вместе с открытым ключом. В лекции термин "доверие" используется в обоих смыслах.
Именование субъектов
Сертификатом называют подписанную, то есть заверенную цифровой подписью, структуру данных, связывающую пару ключей (явным образом открытый ключ и неявно секретный ключ) с идентичностью. Рассмотрим, что такое идентичность.
Имя - это набор данных, который отличает одного субъекта от любого другого субъекта в данной среде; то есть уникально идентифицирует этот субъект в данной среде. Имя действует как идентификатор этого субъекта. Имя может быть простым (таким как личное имя), составным (например, имя, отчество и фамилия), а может содержать другую информацию (гражданство, место жительства, адрес электронной почты и т.п.). Все это зависит от домена, которому принадлежит данный субъект. Размер и характеристики домена определяют количество информации, необходимой для уникальности имени.
Вообще говоря, субъект может и не иметь имени (то есть действовать анонимно), может пользоваться псевдонимом (фальшивым именем) или веронимом (настоящим именем). Вероним - это и есть то, что обычно подразумевается под идентичностью субъекта. Таким образом, идентичность не только уникально идентифицирует, или отличает субъекта в данной среде, но и раскрывает данные реальным миром имя, фамилию субъекта или аналогичную информацию, точно соответствующую человеку или объекту реального мира . Поскольку реализации PKI обычно помещают вероним в сертификат субъекта - в поле Subject (субъект) или Subject Alt Name (альтернативное имя субъекта), - то, вообще говоря, PKI связывает пару ключей с идентичностью субъекта, хотя концептуально эта формулировка ограничена и использование вместо нее имени является технически более точным.
Путаница в терминологии часто происходит из-за того, что слова идентифицировать, идентификационная информация, идентифицируемый и идентификатор могут использоваться в двух смыслах. В более широком они служат просто для того, чтобы отличать или выделять данного субъекта из группы субъектов; в более узком смысле они предназначены для того, чтобы отличать субъекта определенным образом, открывая данный ему в реальном мире вероним, или идентичность субъекта. Следовательно, в некоторых случаях идентификатором может быть и псевдоним, а в некоторых - только вероним. Путаница усиливается в связи с тем, что в сообществе безопасности термин "идентификация" используется только в узком смысле (как указано выше). Если шаг аутентификации открывает имя, но при этом оказывается, что имя должно быть настоящим, то этот шаг можно назвать идентификацией. Следует отметить, что многие люди используют имя только в узком смысле веронима.
Сложность достижения уникальности идентичности зависит от размера домена PKI. В небольшой закрытой среде уникальность идентичности достигается легко - для того чтобы различать субъектов, бывает достаточно даже просто обычных имен. Однако, как только масштаб домена возрастает, гарантировать уникальность имен становится все труднее. Некоторые специалисты считают, что в масштабе Интернета невозможно поддерживать глобальную уникальность имен.
С теоретической точки зрения, глобальная уникальность имен субъектов в целом достижима на базе механизма отличительных имен стандарта X.500 . Это иерархическая структура именования с корнем наверху и центром именования в каждой вершине, каждый центр именования гарантирует уникальность имен вершин, находящихся в иерархии непосредственно под ним. Механизм отличительных имен гарантирует уникальность имен, если каждый субъект, который получит имя таким способом, официально регистрируется вместе с соответствующим центром именования и принимает присвоенное ему имя. В современных электронных коммуникациях базисом адресации и маршрутизации являются имена, образованные на основе IP-адресов и адресов электронной почты.
Однако механизм отличительных имен не считается абсолютно удачным, по крайней мере, по двум причинам:
1 Концепция каталога X.500 и полезность отличительных имен не кажется привлекательными основному сообществу пользователей из-за популярности и широкой распространенности альтернативного способа идентификации субъектов - имен электронной почты.
2 Во многих случаях субъекты при присвоении имен не прибегают к помощи центра именования, а выбирают себе имена сами. Таким образом, два разных субъекта могут присвоить себе одинаковые имена независимо от какого-либо центра именования. Очевидно, что глобальная уникальность имен достигается только, если все субъекты соблюдают правила образования отличительных имен стандарта X.500, но не существует способа гарантировать это.
Отличительные имена поддерживаются и в сертификатах формата X.509, но при этом разрешено использование альтернативных имен субъектов, таких как IP-адрес или адрес электронной почты, чтобы гарантировать уникальность имени субъекта и обеспечить связь с другими механизмами идентичности.
Модель строгой иерархии удостоверяющих центров
Строгая иерархия удостоверяющих центров обычно графически изображается в виде древовидной структуры с корнем наверху и ветвями, спускающимися вниз и заканчивающимися листьями. В этом перевернутом дереве корень представляет определенный УЦ, который обычно называется корневым (или головным ) и действует как главный пункт, или корень, доверия для целого домена подчиненных ему субъектов PKI. Под корнем располагаются промежуточные удостоверяющие центры. Промежуточные удостоверяющие центры представлены в древовидной структуре промежуточными узлами, от которых отходят следующие ветви. Листья, или конечные вершины дерева, соответствуют субъектам PKI, не являющимся удостоверяющими центрами, их называют конечными субъектами или просто конечными пользователями ().
Термин корень имеет фундаментальный смысл. Корень является не просто начальным пунктом сети, связей или архитектуры, а начальным пунктом доверия. Все субъекты PKI (промежуточные удостоверяющие центры и конечные субъекты) владеют открытым ключом корневого (головного) УЦ и полагаются на него как на начальный и конечный пункт доверия при верификации всех сертификатов. Этот ключ является корневым, даже если в конфигурации PKI отсутствуют промежуточные удостоверяющие центры или она выглядит как-то иначе. В некоторых иерархиях УЦ верхнего уровня может сертифицировать не только удостоверяющие центры, но и конечных субъектов. Обычно в литературе, посвященной проблематике PKI, предполагается, что УЦ сертифицирует либо удостоверяющие центры, либо конечных субъектов (а не тех и других одновременно). В дальнейшем при изложении материала мы будем следовать этому принципу.
Рис. 5.1. Строгая иерархия удостоверяющих центров
В модели строгой иерархии удостоверяющих центров все субъекты иерархии доверяют одному головному УЦ (будем использовать этот аналог термина "корневой" как более традиционный и понятный) . Иерархия строится следующим образом.
1 Создается головной УЦ, который генерирует и подписывает сертификат для самого себя. Сертификат головного УЦ называют самоизданным (или самоподписанным ) корневым сертификатом, именно он составляет основу доверия всех субъектов данной строгой иерархии.
2 Головной УЦ сертифицирует, то есть выпускает и подписывает сертификаты для удостоверяющих центров, непосредственно ему подчиненных. Количество подчиненных удостоверяющих центров может быть и нулевым, то есть подчиненные центры могут отсутствовать.
3 Каждый из этих удостоверяющих центров сертифицирует другие удостоверяющие центры, непосредственно ему подчиненные.
4 На уровнях иерархии от второго до последнего удостоверяющие центры сертифицируют конечных субъектов.
Каждый субъект иерархии, в том числе промежуточные удостоверяющие центры и конечные субъекты, должны обладать копией открытого ключа головного УЦ. От процесса инсталляции открытого ключа зависит обработка сертификатов для всей цепочки связей в этой модели, поэтому он должен быть защищен надлежащим образом. Ключ может быть получен субъектом по физическому каналу, такому как обычная почтовая или телефонная связь, а может быть доставлен электронным способом и подтвержден через внешний механизм (например, хэш-код ключа может быть отправлен по почте, опубликован или сообщен по телефону). Отметим, что в многоуровневой строгой иерархии конечные субъекты сертифицируются УЦ, находящимся непосредственно над ними, но их главным пунктом доверия является головной УЦ. В тех иерархиях, где отсутствуют подчиненные удостоверяющие центры, головной УЦ одновременно является издателем сертификатов всех конечных субъектов.
Пример 5.1. Рассмотрим, как конечный пользователь А, владеющий доверенной копией открытого ключа головного УЦ, может проверить подлинность, то есть верифицировать сертификат другого конечного субъекта В. Предположим, что сертификат субъекта В подписан УЦ 2 , чей сертификат в свою очередь подписан УЦ 1 , сертификат которого заверен головным УЦ. Субъект А при помощи открытого ключа головного УЦ - k г может верифицировать сертификат УЦ 1 и извлечь доверенную копию открытого ключа УЦ 1 - k 1 . Затем этот ключ может быть использован для верификации сертификата УЦ 2 , в результате которой становится известна доверенная копия открытого ключа УЦ 2 - k 2 Ключ k 2 может быть использован для верификации сертификата субъекта В и получения доверенной копии его открытого ключа - k В . Субъект А может теперь использовать ключ k В (в зависимости от его типа) для шифрования сообщений, адресованных субъекту В, или проверки цифровых подписей, которые создал субъект В. Описанная процедура позволяет обеспечить защищенную связь между субъектами А и В.
Нестрогая иерархия удостоверяющих центров
Идея строгой иерархии, когда все доверие при любых обстоятельствах базируется на корне иерархии, подходит не для всех областей PKI. "Нестрогая иерархия" удостоверяющих центров позволяет доверяющим сторонам, сертифицированным одним и тем же УЦ, строить доверенный путь, не вовлекая в этот процесс никакие вышестоящие удостоверяющие центры, в том числе головной УЦ. В этом случае локальная политика разрешает доверяющим сторонам при проверке сертификатов друг друга полагаться непосредственно на общий для них локальный УЦ.
Если сертификаты пользователей А и В выпущены одним и тем же УЦ 2 , то пользователи могут проверять сертификаты друг друга без построения пути сертификации к головному УЦ только в том случае, когда пользователи относятся к иерархии одного и того же доверенного издателя. Однако, если сертификат пользователя C издан не УЦ 2 , а другим УЦ, то для проверки сертификата C пользователи А и В должны строить полный пути сертификации через головной УЦ, заверивший сертификат пользователя C. Таким образом, если доверяющая сторона оценивает сертификат, выпущенный сторонним УЦ, то должна выполнять валидацию пути сертификации в соответствии с требованиями строгой иерархии.
Иерархии на основе политик
Традиционное представление о строгой иерархии заключается в том, что каждый УЦ внутри иерархии подчинен одному и только одному вышестоящему УЦ. Логически это подразумевает, что удостоверяющие центры внутри данной иерархии придерживаются одной политики применения сертификатов. Однако достаточно вероятна и другая ситуация, когда УЦ может придерживаться нескольких политик применения сертификатов, то есть может относиться к нескольким иерархиям. Кроме того, данный УЦ может быть подчинен головному УЦ, также реализующему несколько политик и обладающему несколькими сертификатами (по одному для каждой политики). Такой головной УЦ, по сути, эквивалентен нескольким удостоверяющим центрам с разными политиками. Пока неизвестны случаи использования такой модели доверия, но тем не менее она представляется достаточно жизненной моделью, которая вполне может стать актуальной в будущем.
Модель распределенного доверия
Модель распределенного доверия разделяет доверие между двумя или несколькими удостоверяющими центрами. Пусть пользователь А владеет копией открытого ключа своего пункта доверия - УЦ 1 , а пользователь В - копией открытого ключа своего пункта доверия - УЦ 2 . УЦ 1 - корень строгой иерархии, которая включает пользователя А, УЦ 2 - корень строгой иерархии, в которую входит пользователь В. Если каждая из этих иерархий является неглубокой иерархией с доверенным издателем, то вместе они образуют полностью одноранговую сеть, потому что все удостоверяющие центры являются действительно независимыми одноранговыми узлами сети. В этой архитектуре отсутствуют подчиненные удостоверяющие центры. С другой стороны, если каждая иерархия является многоуровневой, то результат объединения иерархий имеет полностью древовидную структуру. Отметим, что головные удостоверяющие центры связаны друг с другом равноправными отношениями, но каждый головной УЦ действует как вышестоящий для одного или более подчиненных удостоверяющих центров. Одним из вариантов архитектуры распределенного доверия может быть гибридная конфигурация с одной или более иерархиями с доверенным издателем или одним или более многоуровневыми деревьями . Эта конфигурация изображена на .
Рис. 5.2. Архитектура распределенного доверия
Обычно (хотя и не всегда) архитектура полностью одноранговой сети выбирается при развертывании PKI внутри отдельного корпоративного домена (например, внутри отдельной компании). Полностью древовидные и гибридные архитектуры часто возникают в результате связывания независимых PKI, ранее принадлежавших разным корпоративным доменам, причем эти инфраструктуры не обязательно подчиняются общему головному УЦ.
Изолированные PKI-домены могут быть сконфигурированы разными способами, в том числе на базе строгой иерархии, архитектуры полностью одноранговой сети или любой модели доверия, обсуждающейся в данной лекции. Важно, чтобы поддерживалась функциональная совместимость между любой комбинацией этих моделей доверия .
Процесс взаимного связывания одноранговых головных удостоверяющих центров обычно называют кросс-сертификацией , хотя в последнее время все чаще используется термин "создание сети PKI " (в частности для полностью древовидной и гибридной архитектур). Для кросс-сертификации, как правило, используются два разных типа конфигурации PKI: сетевая и мостовая (конфигурация hub-and-spoke).
Следует отметить, что в настоящее время специалистами изучаются и предлагаются и другие методы создания отношений доверия между PKI-доменами:
* взаимное распознавание;
* использование списков доверия к сертификатам;
* применение сертификатов аккредитации.
Концепция взаимного распознавания (кросс-распознавания) предложена рабочей группой по телекоммуникациям организации экономического сотрудничества стран Азиатско-Тихоокеанского региона и заключается в том, что удостоверяющие центры могут распознавать друг друга среди многих PKI-доменов, будучи аккредитованными общим аккредитационным центром или доверенной третьей стороной.
Список доверия к сертификатам (Certificate Trust List - CTL), по определению специалистов корпорации Microsoft, является заверенным цифровой подписью списком сертификатов головных удостоверяющих центров, который признается администратором корпоративной сети пригодным для выполнения аутентификации клиентов и защиты электронной почты.
Концепция сертификата аккредитации впервые появилась в проекте PKI правительства Австралии (Gatekeeper) и заключается в том, что хорошо известные и надежные удостоверяющие центры при определенных условиях ручаются за другие удостоверяющие центры . Использование сертификатов аккредитации можно сравнить с односторонней кросс-сертификацией в том смысле, что аккредитационный УЦ выпускает сертификаты для всех удостоверяющих центров, которые удовлетворяют требованиям аккредитации. При этом иерархия не поддерживается, и аккредитованные удостоверяющие центры могут быть полностью автономными субъектами. Сертификаты аккредитации можно использовать для реализации идеи взаимного распознавания.
Сетевая конфигурация
В сетевой конфигурации все головные удостоверяющие центры потенциально кросс-сертифицированы друг с другом. Два головных удостоверяющих центра устанавливают отношения кросс-сертификации, если их сообществам необходимо иметь защищенные коммуникации друг с другом. В полностью связанном случае, иногда называемом полной сетью, это требует установления (n 2 - n) - кросс-сертифицированных соглашений при наличии n -головных удостоверяющих центров, хотя на практике чаще встречаются неполные сети. иллюстрирует неполную сетевую гибридную архитектуру распределенного доверия. Она не является полной сетью, потому что между первым и третьим удостоверяющими центрами отсутствует прямое соглашение о кросс-сертификации.
Мостовая конфигурация (конфигурация hub-and-spoke)
В мостовой конфигурации каждый головной УЦ устанавливает отношения кросс-сертификации с единственным центральным УЦ, в чьи функции входит обеспечение таких взаимных связей . Центральный УЦ иногда называют "втулкой" (hub), соединенной "спицами" (spoke) с различными головными удостоверяющими центрами, а иногда называют мостовым УЦ, устанавливающим связи между парами головных удостоверяющих центров. Преимущество этой конфигурации заключается в том, что в случае полной связи требуется заключение только n -соглашений о кросс-сертификации для n -головных удостоверяющих центров, потому что каждый головной УЦ кросс-сертифицируется только с центральным УЦ.
Мостовая конфигурация не создает иерархии, мостовой УЦ следует рассматривать как головной для всех систем, которые кросс-сертифицируются с ним. Фундаментальное различие между строгой иерархией и мостовой конфигурацией состоит в том, какими ключами владеют конечные субъекты. В строгой иерархии все субъекты владеют доверенной копией открытого ключа головного УЦ, обеспечивающего базу для валидации пути сертификации. В мостовой конфигурации конечные субъекты не владеют открытым ключом мостового УЦ, а имеют лишь копию открытого ключа головного УЦ в своем собственном домене. Каждый субъект, строя путь сертификации, при помощи этого ключа получает ключ мостового УЦ, затем ключ головного УЦ другого домена и, в конце концов, ключ конечного субъекта другого домена.
Четырехсторонняя модель доверия
Обоснованность четырехсторонней модели доверия была протестирована в пилотном проекте обеспечения функциональной совместимости удостоверяющих центров Национальной Ассоциации клиринговых палат (США) . Четырехсторонняя модель доверия представлена на . В качестве четырех сторон в модели выступают подписчик, доверяющая сторона и удостоверяющие центры подписчика и доверяющей стороны.
На первый взгляд может показаться, что эта модель не отличается от более традиционной web-модели, включающей подписчика, доверяющую сторону и УЦ подписчика. Однако главное отличие четырехсторонней модели заключается в том, что доверяющая сторона при принятии решения относительно конкретной транзакции всегда зависит от своего выпускающего УЦ.
Рис. 5.3. Четырехсторонняя модель доверия
Пример 5.2. Рассмотрим приобретение товара покупателем через коммерческий web-сайт. Как только покупатель принимает решение о покупке, то заполняет онлайновый запрос, подписывает его цифровой подписью и отправляет на web-сайт продавца. Оттуда запрос пересылается в банк продавца для одобрения. Любая проверка юридической значимости и статуса сертификата, одобрение кредита и т.п. должны выполняться банком, а не самим продавцом. Таким образом, все транзакции отслеживаются не доверяющей стороной (продавцом), а выпускающим УЦ (банком). Эта модель применима и к другим видам электронных транзакций.
Web-модель
Web-модель получила свое название, поскольку базируется на популярных браузерах Netscape Navigator и Microsoft Internet Explorer, используемых как средства навигации во Всемирной Паутине - World Wide Web. Эта модель предусматривает встраивание в готовый браузер набора открытых ключей головных удостоверяющих центров, которым пользователь браузера может изначально "доверять" при проверке сертификатов. Хотя браузер позволяет корректировать набор корневых ключей (удалять одни ключи и добавлять другие), очевидно, что лишь немногие пользователи имеют достаточное представление о PKI и проблемах безопасности, чтобы управлять этим режимом работы браузера.
На первый взгляд эта модель аналогична модели распределенного доверия, но по существу более похожа на модель строгой иерархии. Web-модель немедленно делает пользователя браузера доверяющей стороной всех PKI-доменов, представленных в браузере. Для всех практических нужд каждый производитель браузера имеет свой собственный головной УЦ, сертифицирующий "головные" удостоверяющие центры, открытые ключи которых физически встроены в программное обеспечение браузера. По существу это строгая иерархия с подразумеваемым корнем, то есть производитель браузера является виртуальным головным УЦ, а уровень, находящийся ниже, образуют встроенные в браузер открытые ключи удостоверяющих центров .
Web-модель обладает явными преимуществами: удобством использования и простотой обеспечения функциональной совместимости. Однако при принятии решения о развертывании PKI в каждом конкретном случае следует учитывать проблемы безопасности. Пользователи браузера автоматически доверяют всем удостоверяющим центрам, открытые ключи которых были заранее встроены в браузер, поэтому безопасность может быть полностью скомпрометирована, если хотя бы один из этих центров окажется "плохим". Например, пользователь А будет доверять сертификату пользователя В, даже если он содержит имя пользователя В, но открытый ключ пользователя C, и подписан "плохим" УЦ, открытый ключ которого был встроен в браузер. В этом случае пользователь А может непреднамеренно разгласить конфиденциальную информацию пользователю C или принять документ с его фальшивой подписью. Причина нарушения безопасности заключается в том, что у пользователя обычно нет уверенности, какой именно корневой ключ из большого числа ключей, встроенных в браузер, участвует в проверке сертификата. Некоторые версии наиболее популярных браузеров поддерживают порядка 100 корневых сертификатов, поэтому пользователю может быть известна лишь небольшая группа из представленных удостоверяющих центров. Кроме того, в этой модели клиентское программное обеспечение доверяет всем удостоверяющим центрам, открытые ключи которых встроены в браузер, в равной степени; таким образом, сертификат, заверенный одним из них, будет, безусловно, принят.
Отметим, что похожая ситуация может возникнуть и в некоторых других моделях доверия. Например, в модели распределенного доверия пользователь может не знать некоторый УЦ, но клиентское программное обеспечение пользователя будет доверять ключам этого центра, если соответствующий кросс-сертификат является валидным. В модели распределенного доверия пользователь соглашается доверить своему локальному УЦ осуществление всех необходимых мер PKI-безопасности, в том числе, кросс-сертификации с "подходящими" удостоверяющими центрами. В web-модели пользователь может приобрести браузер по ряду причин, не имеющих ничего общего с безопасностью, поэтому не следует рассчитывать, что браузер будет иметь ключи "подходящих" в смысле безопасности удостоверяющих центров.
Если пользователь разбирается в технологии PKI (и его браузер поддерживает соответствующие функции), то может попытаться проверить, какой корневой сертификат верифицирует данный входящий сертификат. После проверки пользователь может решить, стоит ли доверять сертификату, заверенному неизвестным УЦ. Однако даже осторожность не всегда приносит результат. Например, пользователь может знать и доверять открытому ключу УЦ АО "Сатурн", но если "плохой" УЦ обслуживает ООО "Сатурн", то маловероятно, что пользователь будет в состоянии отличить те сертификаты, на которые можно полагаться. Даже если производитель браузера не использовал открытые ключи разных удостоверяющих центров с похожими названиями, нельзя исключить случай, когда пользователь примет сертификат от УЦ, который в мошеннических целях выдает себя за УЦ известной компании с хорошей репутацией. Не вникая в названия удостоверяющих центров, пользователь может принять подложный сертификат, ориентируясь только на имя компании.
Другая потенциальная проблема безопасности, связанная с web-моделью, кроется в отсутствии практического механизма аннулирования любого из корневых ключей, встроенных в браузер. Если обнаруживается, что один из головных удостоверяющих центров является "плохим" или его секретный ключ скомпрометирован, то практически невозможно остановить использование открытого ключа такого УЦ в миллионах и миллионах копий браузера по всему миру. Это связано, во-первых, со сложностью уведомления всех пользователей браузеров, а во-вторых, с тем, что программное обеспечение браузера не предусматривает приема уведомлений о компрометации. Удаление скомпрометированного ключа из браузера возлагается на пользователей, причем в случае компрометации это должно быть сделано немедленно всеми пользователями браузера во всем мире. В противном случае одни пользователи будут защищены, в то время как другие останутся в рискованном положении. Так как удаление скомпрометированного ключа требует оперативности и соблюдения конфиденциальности, трудно ожидать, что такая операция выполнима в мировом масштабе.
Наконец, важно отметить, что web-модель не предусматривает заключения никакого юридического соглашения или договора между пользователями (доверяющими сторонами) и удостоверяющими центрами, открытые ключи которых встроены в браузер. Так как программное обеспечение браузера часто распространяется свободно или встраивается в операционную систему, удостоверяющие центры не знают, более того, не имеют способа определить, кто является доверяющей стороной. Пользователи даже при непосредственном контакте с УЦ не могут быть уверены, что достаточно осведомлены о потенциальных проблемах безопасности. Таким образом, независимо от обстоятельств, вся ответственность за использование корневых ключей возлагается на доверяющую сторону.
Модель доверия, сконцентрированного вокруг пользователя
В модели доверия, сконцентрированного вокруг пользователя, каждый пользователь полностью самостоятельно отвечает за решение, на какие сертификаты полагаться и какие сертификаты отвергать. Это решение зависит от ряда факторов, хотя первоначальный набор доверенных ключей пользователя часто состоит из открытых ключей членов семьи, друзей или коллег, с которыми пользователь знаком лично.
Пример 5.3. Доверие, сконцентрированное вокруг пользователя, иллюстрирует известная система Pretty Good Privacy (PGP) . В этой системе пользователь создает так называемую сеть доверия, действуя как УЦ (подписывая открытые ключи других субъектов) и обладая собственными открытыми ключами, подписанными другими. Когда пользователь А получает сертификат пользователя В, заверенный цифровой подписью пользователя C, и выясняет, что сертификат пользователя C, которого А не знает, подписан пользователем D, который хорошо знаком пользователю А, то должен решить вопрос о доверии (). Пользователь А может решить: доверять сертификату В (на основе доверия к цепочке сертификатов от пользователя D к пользователю C и пользователю В ) или отвергнуть сертификат В, аргументируя это тем, что к "неизвестному" пользователю В ведет слишком много связей от "знакомого" пользователя D.
Рис. 5.4. Модель доверия, сконцентрированного вокруг пользователя
В силу своей зависимости от действий и решений пользователей модель доверия, сконцентрированного вокруг пользователя, может использоваться только в узком и высокотехнологичном сообществе, но она не жизнеспособна в обычном сообществе, в котором многие пользователи не имеют достаточных знаний о безопасности и технологии PKI. Более того, эта модель не подходит для тех сфер (корпоративной, финансовой, правительственной), где необходим контроль за тем, с кем взаимодействуют и кому доверяют пользователи.
Кросс-сертификация
Кросс-сертификация - это механизм связывания вместе удостоверяющих центров, ранее не имевших связей друг с другом, таким образом, что становятся возможными защищенные коммуникации между соответствующими сообществами субъектов. Фактически механизм кросс-сертификации аналогичен механизму обычной сертификации, за исключением того, что и субъект, и издатель кросс-сертификата являются удостоверяющими центрами, в то время как субъектом обычного сертификата является конечный субъект .
Отличия внутридоменной и междоменной сертификации зафиксированы в документе RFC 2510 . Процесс называется внутридоменной кросс-сертификацией, если два удостоверяющих центра принадлежат одному и тому же домену (например, в иерархии удостоверяющих центров корпоративной PKI, где вышестоящий УЦ сертифицирует УЦ, находящийся на уровень ниже). Процесс называется междоменной кросс-сертификацией, если два удостоверяющих центра принадлежат разным доменам (например, когда УЦ одной компании сертифицирует УЦ другой компании).
Кросс-сертификация может выполняться в одном или двух направлениях. Односторонняя кросс-сертификация происходит тогда, когда УЦ 1 выпускает кросс-сертификат для УЦ 2 без одновременного выпуска УЦ 2 сертификата для УЦ 1 . Изданный кросс-сертификат является единственным. Односторонняя кросс-сертификация характерна для иерархической архитектуры. Альтернативой является двусторонняя кросс-сертификация, когда два удостоверяющих центра выпускают кросс-сертификаты друг для друга, - в результате издаются два кросс-сертификата. Этот вариант выбирают организации, желающие обеспечить защищенные коммуникации со своими партнерами.
В соответствии с терминологией рекомендаций X.509 1997 года , с точки зрения УЦ 1 , кросс-сертификат, изданный для него (то есть такой, в котором УЦ 1 является субъектом, а некоторый другой УЦ - издателем), получил название прямого кросс-сертификата ; сертификат, изданный им самим ( УЦ 1 ), был назван обратным кросс-сертификатом. Эти термины были признаны не всеми специалистами и экспертами, поэтому в новой версии рекомендаций X.509 2000 года их назвали по-другому . Термин "прямой" был изменен на "изданный для данного УЦ", а термин "обратный" - на "изданный данным УЦ".
Если в качестве хранилища сертификатов используется каталог X.500, соответствующие кросс-сертификаты ("изданный для данного УЦ" и "изданный данным УЦ") могут храниться в структуре пары сертификатов в точке входа в каталог каждого из релевантных удостоверяющих центров . Эта структура может применяться при построении пути сертификации ().
Механизм кросс-сертификации может быть использован для расширения доверия между сообществами разных доверяющих сторон. В частности, кросс-сертификация между двумя удостоверяющими центрами - один из старых способов определения данным УЦ прав другого УЦ издавать сертификаты в некотором пространстве имен. Это фундаментальный механизм расширения доверия в модели распределенного доверия, но он равно применим и к web-модели, а также к модели доверия, сконцентрированного вокруг пользователя (где каждый пользователь действует как свой собственный УЦ).
Рис. 5.5. Кросс-сертификация между УЦ1 и УЦ2
Пример 5.4. Предположим, что пользователь А был сертифицирован УЦ 1 и владеет доверенной копией открытого ключа УЦ 1 , а пользователь В был сертифицирован УЦ 2 и владеет доверенной копией открытого ключа УЦ 2 . Изначально пользователь А может доверять только тем субъектам, сертификаты которых были заверены УЦ 1 , потому что пользователь А способен верифицировать только эти сертификаты. Пользователь А не может верифицировать сертификат пользователя В, так как не владеет доверенной копией открытого ключа УЦ 2 ; аналогично - пользователь В не имеет возможности верифицировать сертификат пользователя А. Однако после кросс-сертификации удостоверяющих центров УЦ 1 и УЦ 2 доверие пользователя А может быть распространено на сообщество субъектов УЦ 2 , включая пользователя В. Теперь пользователь А может верифицировать сертификат УЦ 2 , используя свою доверенную копию открытого ключа УЦ 1 , а затем проверить сертификат пользователя В при помощи своей копии открытого ключа УЦ 2 .
Кросс-сертификация вносит в концепцию расширения доверия особое преимущество - возможность контроля на базе стандартных дополнений, определенных для кросс-сертификатов: ограничений на имена, политику и длину пути. УЦ 1 может кросс-сертифицировать УЦ 2 , но ограничить некоторым образом сообщество домена УЦ 2 (субъекта), которому будет доверять сообщество домена УЦ 1 (доверяющей стороны). В определенных целях доверие внутри домена УЦ 1 может быть расширено на отдельных индивидуумов или на определенные группы субъектов домена УЦ 2 . Такое расширение доверия под управлением администратора УЦ 1 практически невозможно реализовать в web-модели или модели доверия, сконцентрированного вокруг пользователя.
В частности, используя дополнение сертификата "ограничения на имена", УЦ 1 может задать условие принятия сообществом домена УЦ 1 в качестве валидных только тех сертификатов, которые выпущены УЦ 2 для субъектов определенного сегмента пространства имен. Этот сегмент пространства имен может быть ограничен отдельным пользователем, группой, отделом, целой организацией и т.п. Например, одна компания может использовать этот механизм, чтобы гарантировать принятие в качестве валидных только сертификатов сотрудников отдела закупок другой компании. Дополнение сертификата Policy Constraints (ограничения политики) позволяет управлять назначением сертификатов, например, запрещать их использование для верификации подписи на юридическом контракте.
Ограничения на длину пути в дополнении сертификата Basic Constraints (базовые ограничения) могут использоваться для регулирования количества кросс-сертификатов в валидном пути сертификации. Например, УЦ 1 может разрешить принятие сертификатов конечных субъектов, изданных УЦ 2 , но запретить использование сертификатов, изданных любым другим УЦ, который кросс-сертифицирован с УЦ 2 .
Итак, кросс-сертификация обеспечивает функциональную совместимость доменов PKI, которые невозможно связать другим образом. В качестве нежелательной альтернативы может выступать обмен ключами между головными удостоверяющими центрами и хранение каждым пользователем открытого ключа головного УЦ внешнего домена.