Инфраструктуры открытых ключей Ольга Юрьевна Полянская

В курс включены сведения, необходимые специалистам в области информационной безопасности. Рассматривается технология инфраструктур открытых ключей (Public Key Infrastructure – PKI), которая позволяет использовать сервисы шифрования и цифровой подписи согласованно с широким кругом приложений, функционирующих в среде открытых ключей. Технология PKI считается единственной, позволяющей применять методы подтверждения цифровой идентичности при работе в открытых сетях.Курс дает представление об основных концепциях и подходах к реализации инфраструктур открытых ключей, в нем описываются политика безопасности, архитектура, структуры данных, компоненты и сервисы PKI. Предлагается классификация стандартов и спецификаций в области инфраструктур открытых ключей. Подробно рассматриваются процессы проектирования инфраструктуры и подготовки ее к работе, обсуждаются типовые сценарии использования и способы реагирования на инциденты во время функционирования PKI.

Рассматривается технология инфраструктур открытых ключей (Public Key Infrastructure – PKI), которая позволяет использовать сервисы шифрования и цифровой подписи согласованно с широким кругом приложений, функционирующих в среде открытых ключей. Технология PKI считается единственной, позволяющей применять методы подтверждения цифровой идентичности при работе в открытых сетях.

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

Intuit.ru

28.10.2011intuit_ru_course02-2040.99

Полянская О.Ю., Горбатов В.С., Инфраструктуры открытых ключей

Интернет-университет информационных технологий - ИНТУИТ.руM.2007978-5-9556-0081-9

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

Полянская Ольга Юрьевна

Интернет-университет информационных технологий - ИНТУИТ.ру

2007

УДК: 004.056(07)

ББК: 17

П54

Полянская Ольга Юрьевна

Инфраструктуры открытых ключей / Полянская О.Ю., Горбатов В.С. - M.: Интернет-университет информационных технологий - ИНТУИТ.ру, 2007 (Основы информационных технологий)

ISBN: 978-5-9556-0081-9

Содержание

Лекция 1. Доверие в сфере электронных коммуникаций

Лекция 2. Механизмы аутентификации

Лекция 3. Основные компоненты и сервисы PKI

Лекция 4. Сервисы безопасности PKI и базовые криптографические механизмы

Лекция 5. Модели и механизмы доверия

Лекция 6. Сертификаты открытых ключей

Лекция 7. Классификация сертификатов и управление ими

Лекция 8. Формат списков аннулированных сертификатов Лекция 9. Типы списков аннулированных сертификатов и схемы аннулирования

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

Лекция 11. Валидация пути сертификации

Лекция 12. Механизмы распространения информации PKI

Лекция 13. Политики, регламент и процедуры PKI

Лекция 14. Описание политики PKI

Лекция 15. Стандарты и спецификации PKI

Лекция 16. Сервисы, базирующиеся на PKI

Лекция 17. Приложения, базирующиеся на PKI

Лекция 18. Подготовка к развертыванию PKI

Лекция 19. Проблемы выбора поставщика технологии или сервисов PKI

Лекция 20. Проектирование и внедрение PKI

Лекция 21. Проблемы реализации PKI

Лекция 1. Доверие в сфере электронных коммуникаций

Рассматривается понятие доверия в контексте электронных коммуникаций, приводится характеристика ключевых элементов и механизмов доверия, обсуждаются политики доверия и примеры ассоциаций доверия, вводится понятие инфраструктуры безопасности, описываются сервисы инфраструктуры безопасности.

Понятие доверия

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

Очевидно, что невозможно избежать проблем безопасности в сфере электронных коммуникаций, но, в дополнение к технологиям защиты, можно выработать решение, способное уменьшить риск. Это решение также известно как доверие . Доверие в сфере электронных коммуникаций не ограничивается доверием к защищенным компьютерным системам - ведь безопасность компьютерной системы зависит не только от надежной операционной системы, но и от физических средств защиты, от квалификации и надежности персонала и многого другого. Доверие между партнерами напрямую зависит от специфики сферы реализации их деловых отношений. Например, в финансовых приложениях, применяемых для межбанковских расчетов, последствия выхода из строя системы могут быть чрезвычайно серьезны, поэтому степень доверия друг к другу участников электронного взаимодействия должна быть намного выше, чем в приложениях корпоративной электронной почты, где индивидуальный ущерб относительно невелик. Критериями оценки степени доверия к любым компаниям-производителям товаров и услуг одного уровня выступают ключевые элементы доверия: предсказуемость, ресурсы и неопределенность [105].

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

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

Пример 1.1.

Проиллюстрируем концепцию доверия на примере web-сайта электронной торговли. Обычно продавец заботится о двух главных целях бизнеса: новых продажах (продажах новым покупателям) и повторных продажах (продажах тем, кто купил раньше). Один из способов повысить повторные продажи - это создать для покупателей высокий уровень предсказуемости и безопасности сервиса через опыт начальной сделки. Аргументами в пользу предсказуемости и безопасности сервиса могут быть размещенный на странице сайта электронной торговли логотип авторитетной доверенной третьей стороны или, например, символ "замок", который продуцируют системы безопасности, обеспечивающие защищенную связь по протоколу SSL. Логотип доверенной третьей стороны на странице web-сайта может свидетельствовать о том, что сайт прошел объективную проверку и сертифицирован компанией, которой доверяет сообщество производителей и потребителей товаров и услуг в Интернете.

В приведенном примере ресурсы торгового web-сайта складываются из твердых активов (покупаемых товаров и услуг) и деловой репутации (торговой марки и финансового положения продавца и/или качества продаваемых товаров). Для большинства компаний товары и деловая репутация равно важны. Фальсификация товаров приводит к прямым материальным потерям. Компрометация торговой марки и репутации может повлиять на снижение будущих продаж. Наконец, покупатель должен быть уверен, что его персональные данные, в частности, информация кредитной карты, будут обрабатываться с соблюдением правил безопасности. Невозможность визуально следить за совершением сделки, к чему покупатель привык в обычном магазине, означает, что покупатель должен доверять продавцу. Необходимость приобрести товар у неизвестного продавца, то есть проявить слишком большое доверие, может заставить покупателя отказаться от сделки.

Характерной чертой доверия является то, что на его приобретение требуется много времени, а исчезнуть оно может очень быстро. Известно немало примеров, когда из-за причастности к скандалам происходило падение крупных компаний за один день. С другой стороны, если покупатель доверяет, он склонен быть лояльным. Чем ниже степень доверия покупателя, тем ему легче обратиться к другому продавцу. По сути, чтобы сохранить покупателей и увеличить повторные продажи, продавцу важно обеспечить степень доверия к своему бизнесу выше, чем у конкурентов.

Для поддержки концепций доверия в сфере электронных коммуникаций были разработаны специальные технологии (см. табл. 1.1).

|Технология | Поддержка ключевых элементов |

|Анализ уязвимости | Снижение количества атак на ресурсы, повышение предсказуемости и уменьшение неопределенности качества услуг |

|Онлайновые услуги депонирования | Обеспечение защиты ресурсов в условиях неопределенности взаимодействия с неизвестной стороной. Достижение предсказуемости на основе истории транзакций депонирования |

|Контрольные журналы | Анализ и фильтрация проблем, снижающих предсказуемость услуг |

|Межсетевые экраны | Зашита ресурсов от онлайновых атак |

Таблица 1.1.Примеры технологий, поддерживающих концепции доверия

Реализовать доверие намного сложнее, чем просто понять, на чем оно строится. Формирование доверительных отношений в реальной жизни может занимать месяцы, годы и даже десятилетия.

Политики доверия

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

* конфиденциальность;

* корректное использование информации;

* реагирование в случае нарушения доверия ;

* внутренние механизмы гарантирования непрерывности доверия ;

* согласие пользователей.

Конфиденциальность

Политики конфиденциальности разрабатываются для того, чтобы пользователи правильно понимали, как данная компания будет обращаться с той персональной и деловой информацией, которую они ей предоставляют. Опубликованная на web-сайте компании политика конфиденциальности объясняет правила использования персональных данных и способствует установлению контакта с пользователями. Пользователи должны ознакомиться с этой политикой и подтвердить свое согласие с указанными правилами. Примером политики конфиденциальности может служить политика, опубликованная на сайте Yahoo [207].

Корректное использование информации

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

Реагирование в случае нарушения доверия

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

Непрерывность доверия

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

Согласие пользователей

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

Ассоциации доверия

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

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

Так, например, известные ассоциации доверия Better Business Bureau и TrustE знакомят другие компании с законами в области обеспечения конфиденциальности и помогают им разрабатывать собственные политики и правила [39]. Если компания выполняет все рекомендации ассоциации доверия, то получает ее "печать одобрения" (некоторый символ или логотип ассоциации) для размещения на своем web-сайте.

|SAS70 | Системы | Statement on Auditing Standards ${}^1$ 70 | Аудит систем |

Таблица 1.2.Примеры ассоциаций доверия

По существу эта печать идентифицирует доверие, связанное с рекомендациями авторитетных ассоциаций, и подтверждает обязательства владельцев сайта в отношении предоставленных посетителями сведений. Когда пользователь сталкивается с неизвестным сайтом и видит "печать одобрения" авторитетной ассоциации, то относится с большим доверием к компании-владельцу сайта. Ассоциации доверия берут на себя функции контроля за соблюдением политики конфиденциальности. Если проверка выявляет нарушение, то ассоциация уведомляет об этом компанию и рекомендует ей пересмотреть принятые правила - с тем чтобы либо правила отражали изменения в ее коммерческой деятельности, либо компания отказалась от подобной практики.

Концепция инфраструктуры безопасности

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

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

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

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

Уровни инфраструктуры

Рассмотрим уровни инфраструктуры безопасности (рис. 1.1). Простейший уровень, находящийся внизу, - это физический уровень. Принимая во внимание ограниченное число рисков, связанных с физическими атаками, этот уровень защищать проще, чем другие. Чтобы гарантировать трудность физического доступа к центру хранения и обработки данных или аналогичным ресурсам, используют одновременно средства сигнализации, охрану и замки. Интересно отметить, что бывает проще физически разрушить хорошо защищенный сайт, чем взломать его. Следовательно, организации важно иметь хорошо проработанный план восстановления после аварии, включая организацию центров "горячего" и "теплого" резервирования данных.

Физический уровень

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

* Ограниченный доступ с использованием нескольких механизмов аутентификации (например, применение биометрического устройства и считывателя карт).

* Постоянный мониторинг безопасности с использованием видео- и аудиоаппаратуры, сенсорный мониторинг внешней и внутренней среды.

* Обученный персонал, отвечающий за безопасность.

* Журналы, регистрирующие доступ по ID-картам, проверку документов службой охраны и т.п.

Системный уровень

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

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

Рис. 1.1. Уровни инфраструктуры безопасности

Сетевые компоненты еще более уязвимы, чем ОС. Современная сеть подвергается и внутренним, и внешним атакам, для защиты от них требуется сложный набор технологий. Многие исследования показали, что организации часто бывают более уязвимы для внутренних атак, чем для прямых атак из Интернета. Защита сети изнутри немного более сложна и требует строгого контроля доступа, использования межсетевых экранов, контрольных журналов и т.д. Строгий контроль доступа позволяет повысить степень доверия пользователей при доступе к частной сети. В настоящее время угрозу представляет использование карманных персональных компьютеров (Personal Digital Assistants). Эти устройства могут подсоединяться непосредственно к узлу сети и обходить защиту межсетевых экранов, маршрутизаторов и антивирусных средств. Таким образом, вирус или другой злонамеренный код может быть занесен непосредственно в сеть. Для фиксации подозрительной активности и событий после инцидента необходимы контрольные журналы. Важно, чтобы файлы регистрации хранились отдельно, вне функционирующих систем, причем таким способом, который делает их неизменяемыми (во избежание мошенничества системных администраторов).

Уровень приложений

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

* программные средства (например, сканирование или блокирование вирусов);

* программное обеспечение превентивного действия (обнаружение уязвимостей или тестирование);

* просмотр кодов приложений вручную с целью выявления возможных проблем безопасности.

Уровень приложений является наиболее сложным для защиты еще и потому, что наиболее доступен. Например, любой, кто может получить доступ к web-сайту компании, занимающейся электронной торговлей, немедленно получает доступ к приложению ( Active X ), которое позволяет выполнить транзакцию [105]. Получить доступ на физическом или системном уровне труднее. Важно понимать, что компрометация одного уровня ведет к компрометации другого. Часто системный уровень атакуется, а затем используется для доступа к данным приложения. Например, злоумышленник может атаковать ОС и использовать бреши в ней для атаки на размещаемые в уровне приложений данные клиентов с целью получения информации о номерах кредитных карт.

Цель и сервисы инфраструктуры безопасности

Главная цель инфраструктуры безопасности состоит в обеспечении безопасной работы приложений. Если проводить аналогию с функционированием инфраструктуры электросетей, то можно сказать, что электросеть обеспечивает правильную работу таких "приложений", как электроприборы. Более того, универсальность инфраструктуры электросетей такова, что она способна поддерживать "приложения", которые были неизвестны в то время, когда она проектировалась (к ним относится практически вся современная бытовая техника, компьютеры и многое другое). Под приложением в контексте инфраструктуры безопасности понимается любой модуль, использующий инфраструктуру в целях безопасности, такой как web-браузер, клиентское приложение электронной почты, устройство, поддерживающее протокол IPsec, и т.п.

Инфраструктура безопасности дает возможность приложениям защищать их собственные данные или ресурсы и придавать безопасность их взаимодействию с другими данными или ресурсами. Доступ к инфраструктуре должен быть простым и быстрым - подобно включению электроприбора в розетку. Инфраструктура безопасности должна обладать знакомым и удобным интерфейсом, пригодностью и предсказуемостью сервисов. Кроме того, устройствам, использующим инфраструктуру, нет необходимости знать, каким образом достигается результат. Так, например, для работы любого электроприбора не имеет значения, каким образом происходит передача электроэнергии, а важно лишь то, что при его включении в электрическую розетку предсказуемый "сервис" обеспечивает прибор электроэнергией, необходимой для его правильной работы. То есть инфраструктура безопасности должна иметь хорошо известные точки входа, которые могут доставить сервис безопасности нуждающемуся в нем устройству. Причем для устройства неважно, как это делается, но существенно, что это делается удобно и корректно.

Рассмотрим наиболее важные аспекты сервисов, предоставляемых инфраструктурой безопасности.

Защищенная регистрация

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

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

Инфраструктура безопасности может решить некоторые из этих проблем. Поддержка безопасности подразумевает, что событие регистрации для инфраструктуры происходит локально (на устройстве, посредством которого пользователь физически осуществляет взаимодействие) и что корректный результат регистрации, когда необходимо, защищенно распространяется на удаленное приложение. Рис. 1.2 иллюстрирует этот процесс [44].

Рис. 1.2. защищенная регистрация

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

Защищенная однократная регистрация

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

Преимущества системы SSO заметны пользователям с первого взгляда: отпадает необходимость запоминать множество паролей и тратить время на аутентификацию при входе в каждую конкретную систему ( см. рис. 1.3). Этим, однако, достоинства системы SSO не ограничиваются. Во-первых, правильно внедренная система SSO оказывает положительное влияние на безопасность: пользователи регистрируются на своих локальных компьютерах, пароли реже "путешествуют" по сети, и выше вероятность, что единственный пароль, выбранный пользователем, будет "хорошим". Во-вторых, однократная регистрация не просто удобна для пользователей, но также снижает нагрузку на централизованную службу поддержки информации о регистрации и обслуживания паролей (плановая или внеплановая смена паролей, работа с забытыми паролями и пр.), которая уязвима к атакам.

Рис. 1.3. Защищенная однократная регистрация

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

Прозрачность для конечных пользователей

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

Сервисы инфраструктуры для пользователей можно сравнить с "черным ящиком". Правильно спроектированная инфраструктура безопасности должна обладать теми же свойствами: вся технология обеспечения безопасности должна быть виртуально скрыта от пользователей и не требовать никакого ручного вмешательства, знания ключей и алгоритмов, а ошибки пользователей не должны приводить к серьезной компрометации безопасности. Другими словами, идея прозрачности инфраструктуры безопасности может быть выражена следующим образом: средства обеспечения безопасности не должны мешать пользователям выполнять работу. Безопасность не должна требовать от пользователей никаких специальных знаний и процедур, а также ощутимо затруднять и замедлять их деятельность. Инфраструктура должна выполнять все задания, имеющие отношение к безопасности, способом, полностью прозрачным для пользователей.

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

Комплексная безопасность

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

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

Всеобъемлющая инфраструктура безопасности предоставляет организации ряд существенных преимуществ:

* экономию затрат;

* функциональную совместимость внутри организации и между организациями;

* стандартность решения;

* реальное обеспечение безопасности;

* возможность выбора поставщика технологии.

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

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

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

Инфраструктура безопасности обеспечивает реальную защищенность взаимодействий между различными приложениями и устройствами, поскольку все взаимодействия управляются совместимым способом. Более того, функционирование инфраструктуры и взаимодействия внутри нее могут быть проверены на корректность внешними аудиторами. Безопасность взаимодействия набора решений проверить существенно сложнее, а иногда и просто невозможно, даже если каждое решение в отдельности строго контролируется.

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

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

Лекция 2. Механизмы аутентификации

Рассматривается аутентификация на основе паролей, механизмы одноразовой аутентификации, описывается механизм аутентификации Kerberos, обсуждается аутентификация при помощи сертификатов открытых ключей, анализируются возможности инфраструктуры открытых ключей PKI как технологии аутентификации.

Эволюция механизмов аутентификации

Инфраструктура безопасности для распространения открытых ключей, управления электронными сертификатами и ключами пользователей получила название инфраструктуры открытых ключей - Public Key Infrastructure (PKI) . Термин "PKI" является производным от названия базовой технологии - криптографии с открытыми ключами, обладающей уникальными свойствами и являющейся основой для реализации функций безопасности в распределенных системах. Инфраструктура открытых ключей реализуется не ради нее самой, а для поддержки безопасности других приложений. Существуют, безусловно, и другие механизмы безопасности, которые не используют криптографию открытых ключей, и они менее сложные, чем PKI. Однако PKI не только предлагает наиболее комплексное решение, но и снимает остроту многих проблем, свойственных более традиционным механизмам безопасности.

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

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

Аутентификация на основе паролей

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

Рис. 2.1. Аутентификация при помощи пароля

На рис. 2.1 пользователь А передает по сети на сервер свое имя и пароль. Некто, наблюдающий за средой передачи, например, пользователь С, может похитить пароль пользователя А. Как только это происходит, пользователь С может выдавать себя за пользователя А до тех пор, пока пароль не будет изменен, а это может продолжаться достаточно долгое время. Поэтому для безопасности вычислительной среды требуется регулярно менять пароли.

Существует несколько способов получения секретного пароля в сети. Пользователь С может использовать программу-анализатор, или сниффер. Программы-анализаторы легко доступны в Интернете, они позволяют перехватывать сетевой трафик между компьютерами одной локальной сети. Для перехвата пароля пользователю С можно даже не находиться в одном помещении с пользователем А и не иметь доступ к его компьютеру - ему достаточно лишь сетевого подключения к той же самой локальной сети. Эти программы настолько упрощают перехват информации, что хищение пароля часто называют атакой анализатора [64]. После смены пароль остается неизвестен пользователю С только до очередного запуска программы-анализатора. Если пользователь С постоянно запускает свою программу-анализатор, то получает новый пароль пользователя А, как только он выбран.

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

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

Аутентификация при помощи паролей неэффективна в среде со многими серверами [70]. Предположим, что пользователь А регулярно взаимодействует с шестью удаленными серверами. Он может использовать один и тот же пароль для каждой системы или разные пароли для всех систем. Если пользователь А использует один и тот же пароль, то успешная атака анализатора позволяет пользователю С получить доступ к учетным записям пользователя А сразу на всех серверах и в дальнейшем выдавать себя за него. Если пользователь А использует разные пароли для каждого сервера, то успешная атака анализатора позволяет пользователю С получить доступ только к одному серверу, но при этом пользователь А должен помнить шесть разных паролей. Скорее всего, пользователь А запишет свои пароли, в этом случае они могут быть похищены другим способом.

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

Эволюция механизмов аутентификации началась в ответ на атаки анализаторов. Очевидно, что должна была появиться защита от этих атак в виде шифрования. Шифрование предотвращает раскрытие пароля при передаче. Но если все пользователи используют один и тот же ключ шифрования, то любой из них может использовать анализатор, получить чужой пароль и расшифровать его тем же способом, что и сервер. Если каждый пользователь имеет свой ключ, то управление этими ключами обеспечивает более сильную аутентификацию, чем пароли. Следует отметить, что пользователь А защищен и в том случае, если его пароль используется однократно. Удачная атака анализатора позволяет пользователю С получить устаревший пароль А. Ясно, что пользователю А в этом случае необходим новый пароль для каждой попытки аутентификации.

Механизмы одноразовой аутентификации

Одноразовая аутентификация позволяет противостоять атаке анализатора за счет использования во время каждой попытки аутентификации нового секрета. В этом случае, если пользователь С перехватывает данные пользователя А, то не может в дальнейшем их использовать, чтобы выдавать себя за него. Рассмотрим три разных механизма одноразовой аутентификации: аутентификацию типа "запрос-ответ", неявный запрос и аутентификацию на базе хэш-функций.

Аутентификация "запрос-ответ"

Как показано на рис. 2.2, сервер генерирует случайный запрос и отправляет его пользователю А [208]. Вместо того чтобы в ответ отправить серверу пароль, пользователь А шифрует запрос при помощи ключа, известного только ему самому и серверу. Сервер выполняет такое же шифрование и сравнивает результат с шифртекстом, полученным от пользователя А. Если они совпадают, то аутентификация прошла успешно, в противном случае - неудачно.

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

Рис. 2.2. Аутентификация "запрос-ответ"

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

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

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

Неявный запрос на базе времени

Рис. 2.3 иллюстрирует аутентификацию на базе времени [72]. Пользователь А шифрует значение текущего времени на часах своего компьютера и отправляет свое имя и шифртекст на сервер. Сервер расшифровывает значение, присланное пользователем А. Если оно достаточно близко к значению текущего времени на компьютерных часах сервера, то аутентификация проходит успешно, в противном случае - неудачно. Поскольку компьютерные часы пользователя А и сервера не синхронизированы и передача информации занимает некоторое время, сервер должен допускать несколько возможных значений времени.

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

Рис. 2.3. Аутентификация при помощи неявного запроса

Этот механизм не слишком серьезно совершенствует схему "запрос-ответ", он также с трудом поддерживает аутентификацию пользователя на многих серверах и не обеспечивает взаимной аутентификации, кроме того, он уязвим для атак воспроизведения. Лучшие свойства механизма "запрос-ответ" и неявного запроса на базе времени удалось совместить при использовании для аутентификации односторонней хэш-функции.

Аутентификация с использованием хэш-функции

Для решения проблем аутентификации, связанных с неявными запросами, Лесли Лампорт [85] предложил использовать одноразовые пароли, генерируемые при помощи односторонней хэш-функции (см. лекцию 3). Эта идея нашла воплощение в системе одноразовых паролей S/Key One-Time Password System [136]. Система S/Key, применяя одностороннюю хэш-функцию, генерирует последовательность одноразовых паролей. Начальное значение хэш-кода вычисляется путем хэширования секретного пароля пользователя, который сцеплен с несекретным случайным числом, выработанным генератором случайных чисел. Секретный пароль должен иметь длину не менее 8 символов. Последовательность одноразовых паролей формируется в результате многократного применения секретной хэш-функции (от 500 до 1000 ). То есть первый одноразовый пароль генерируется путем применения хэш-функции к секретному паролю пользователя определенное количество раз ( N ), следующий одноразовый пароль - путем применения хэш-функции к секретному паролю пользователя только (N - 1) раз и т.д.

Субъект, получивший одноразовый пароль путем прослушивания сети, не в состоянии сгенерировать следующий пароль, так как для этого требуется просчитать хэш-функцию в обратном направлении. Это не может быть сделано без знания секретного пароля, с которого начинались итерации. Поскольку в системе S/Key секретный пароль пользователя никогда не передается по сети и не хранится ни сервером, ни клиентом, риск хищения отсутствует.

S/Key - это система "клиент-сервер". Сервер генерирует отклик после получения от клиента login-запроса. Отклик сервера содержит номер итерации и случайное число. В ответ пользователь генерирует соответствующий одноразовый пароль, используя комбинацию своего секретного пароля, номера итерации и случайного числа, и отправляет его серверу. Первый одноразовый пароль из списка итераций сохраняется на шаге инициализации.

Сервер может и сам формировать S/Key -запрос, состоящий из номера итерации и случайного числа. Тогда, используя номер итерации и случайное число вместе со своим секретным паролем, пользователь вычисляет (или преобразует) одноразовый пароль. Сервер может не формировать запрос, если пользователь сохраняет номер итерации и случайное число после каждой своей успешной попытки аутентификации. Для хранения этих значений могут использоваться портативные устройства типа смарт-карт или карманных персональных компьютеров.

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

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

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

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

Чтобы выполнять аутентификацию на многих удаленных серверах, пользователю необходимо для каждого сервера поддерживать соответствующую информацию о случайном числе и номере итерации и своевременно выполнять повторную инициализацию, что может быть достаточно трудоемким. К недостаткам системы S/Key можно отнести и то, что она не обеспечивает взаимной аутентификации.

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

Аутентификация Kerberos

Роджер Нидхэм и Михаэль Шредер в 1978 году впервые предложили механизм аутентификации, который базировался на шифровании, но он, к сожалению, не обеспечивал одинаковых гарантий для участвующих в коммуникации сторон [93]. Для решения этой проблемы в Массачусетском технологическом институте в 1985 году была разработана система защиты информационных систем от вторжений, дополняющая механизм Нидхэма-Шредера специальным сервисом выдачи билетов. Она была названа Kerberos по имени трехглавого пса Цербера, охранявшего ворота в ад в греческой мифологии. Такое название было выбрано, потому что в аутентификации участвовали три стороны: пользователь, сервер, к которому желает получить доступ пользователь, и сервер аутентификации, или центр распределения ключей (ЦРК). Специальный сервер аутентификации предлагался в качестве доверенной третьей стороны, услугами которой могут пользоваться другие серверы и клиенты информационной системы [4].

Рис. 2.4. Аутентификация Kerberos

Система Kerberos владеет секретными ключами обслуживаемых субъектов и помогает им выполнять взаимную аутентификацию. Сеанс начинается с получения пользователем А билета для получения билета - Ticket-Granting Ticket (TGT) от ЦРК. Когда пользователь желает получить доступ к некоторому серверу В, то сначала отправляет запрос на билет для доступа к этому серверу вместе со своим билетом TGT в ЦРК. TGT содержит информацию о сеансе регистрации пользователя А и позволяет ЦРК оперировать, не поддерживая постоянно информацию о сеансе регистрации каждого пользователя. В ответ на свой запрос пользователь А получает зашифрованный сеансовый ключ S_A и билет на доступ к серверу В. Сеансовый ключ зашифрован секретным ключом, известным только пользователю А и ЦРК. Билет на доступ к серверу В содержит тот же самый сеансовый ключ, однако он шифруется секретным ключом, известным только серверу В и ЦРК.

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

Рассмотрим более подробно аутентификацию в системе Kerberos (рис. 2.4), которая выполняется за четыре шага:

1 получение пользователем билета TGT на билеты;

2 получение пользователем билета на доступ к серверу ;

3 аутентификация пользователя сервером;

4 аутентификация сервера пользователем.

Получение пользователем билета TGT на билеты

В начале сеанса регистрации пользователь обращается к сервису аутентификации (Authentication Service - AS) Kerberos за получением билета TGT для ЦРК. Обмен сообщениями с сервисом AS не требует от пользователя А подтверждения своей идентичности. Обмен состоит из двух сообщений: запроса от А и ответа сервиса AS. Запрос содержит просто имя пользователя А, а ответ сервиса AS - сеансовый ключ регистрации S_A и билет TGT, зашифрованные секретным ключом К_A пользователя А. Обычно ключ К_A извлекается из пароля пользователя А, что позволяет пользователю не запоминать двоичный симметричный ключ и обращаться к Kerberos с любой рабочей станции. Билет TGT содержит сеансовый ключ S_A, имя пользователя А и срок действия билета, зашифрованные вместе секретным ключом ЦРК - К_К. В дальнейшем при шифровании сообщений для пользователя А вместо секретного ключа К_A ЦРК использует сеансовый ключ S_A.

Получение пользователем билета на доступ к серверу

Когда пользователь А желает получить доступ к серверу, в своем сообщении он отправляет в ЦРК билет TGT, запрос на билет для доступа к серверу и аутентификатор. Это сообщение имеет следующий формат: "имя А", "имя B", TGT: К_К ["имя А", S_A, срок действия], S_A [время] и называется запросом пользователя на доступ к серверу. Аутентификатор доказывает ЦРК, что пользователь А знает сеансовый ключ S_A. Аутентификатор состоит из текущего значения даты и времени, зашифрованного сеансовым ключом. Шифрование защищает от возможного перехвата сторонним пользователем С билета TGT из ответа ЦРК пользователю А. Указание текущих значений даты и времени в аутентификаторе требует синхронизации компьютерных часов пользователя А и ЦРК. ЦРК может допускать некоторый разброс времени (обычно 5 мин.). На практике для поддержки синхронизации часов используется протокол синхронизации времени типа Simple Network Time Protocol (SNTP).

ЦРК получает запрос пользователя А на доступ к серверу В и готовит ответ. При помощи ключа К_К ЦРК расшифровывает билет TGT из запроса, восстанавливает сеансовый ключ S_A и проверяет срок действия билета TGT. Если билет TGT - действующий, то ЦРК генерирует ключ для пользователя А и сервера В - K_AB и формирует билет. Билет шифруется секретным ключом сервера В - K_B и содержит ключ K_AB, имя пользователя А и срок действия. В ответе ЦРК указываются имя сервера В и ключ K_AB, зашифрованные сеансовым ключом S_A, ответ имеет следующий формат: S_A ["имя В", K_AB, TICKET: K_B ["имя А", K_AB, срок действия]]. Получив ответ от ЦРК, пользователь А расшифровывает его при помощи сеансового ключа S_A.

Аутентификация пользователя сервером

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

Сервер В получает запрос пользователя А - TICKET: K_B ["имя А", K_AB, срок действия], K_AB [время] - и готовит ответ. Сервер расшифровывает билет своим секретным ключом K_B, обнаруживая ключ K_AB, имя пользователя А и срок действия билета; при этом предполагается, что ЦРК разделил ключ K_AB только со стороной, названной в билете пользователем А. Если после расшифрования аутентификатора при помощи ключа K_AB получено значение даты и времени, близкое к значению текущего времени (в интервале 5 мин.), то это означает, что шифрование мог выполнить только пользователь А. Таким образом, сервер аутентифицирует пользователя.

Для того чтобы гарантировать, что сторонний пользователь С не сможет воспроизвести легитимный запрос пользователя А, сервер должен проверить аутентификаторы, которые он обрабатывал в течение ограниченного промежутка времени, когда происходил сеанс связи с А. В этот интервал времени имя пользователя не должно быть связано с одним и тем же аутентификатором более одного раза.

Аутентификация сервера пользователем

Для того чтобы пользователь А, в свою очередь, мог аутентифицировать сервер, сервер В увеличивает на единицу значение времени из запроса пользователя А и вновь шифрует его при помощи ключа K_AB. Этот шифртекст и является ответом сервера: K_AB [время+1]. Пользователь А получает ответ сервера и расшифровывает его ключом K_AB. Пользователь А полагается на то, что ЦРК разделил ключ только с тем сервером, для доступа к которому пользователь А запрашивал билет. Если в результате расшифрования ответа сервера В при помощи ключа K_AB получается исходное значение даты и времени, увеличенное на единицу, то это означает, что только сервер В мог выполнить это шифрование. Когда взаимная аутентификация завершена, сеансовый ключ может использоваться для обеспечения конфиденциальности или целостности сообщений, которыми обмениваются пользователь А и сервер В.

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

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

Инициализация открытых ключей Kerberos

Инициализация открытых ключей Kerberos (Kerberos Public Key Initialization - PKIINIT) вносит изменения в процедуру начального обмена с ЦРК, а все остальное оставляет без изменений [70]. В своем запросе пользователь А отправляет сертификат ключа подписи и подписанный открытый ключ. Сертификат ключа подписи пользователя А содержит имя А и открытый ключ, используемый для проверки подлинности цифровых подписей, сгенерированных пользователем А. Открытый ключ будет использоваться для управления ключами; он может быть либо ключом транспортировки ключей ( открытый ключ RSA ) либо ключом согласования ключей ( открытый ключ Диффи-Хэллмана). ЦРК проверяет цифровую подпись, чтобы гарантировать, что открытый ключ принадлежит пользователю А. Проверив его один раз, ЦРК использует этот открытый ключ для подписания сеансового ключа.

Формат ответа ЦРК зависит от типа ключа пользователя А. Если пользователь А использует открытый ключ Диффи-Хэллмана, то ЦРК возвращает его подписанным при помощи открытого ключа Диффи-Хэллмана. Пользователь проверяет цифровую подпись, чтобы убедиться, что ответ принадлежит ЦРК. И пользователь А, и ЦРК вычисляют один и тот же симметричный ключ при помощи алгоритма Диффи-Хеллмана и используют его как сеансовый ключ S_A. Пользователь А может использовать и открытый ключ RSA. В этом случае ЦРК генерирует временный симметричный ключ и шифрует его при помощи открытого ключа ( RSA ) пользователя А. Кроме того, ЦРК генерирует и заверяет цифровой подписью второй симметричный ключ, который будет использоваться как сеансовый ключ S_A. Затем подписанный ключ S_A шифруется при помощи временного ключа и отправляется пользователю А вместе с временным ключом, зашифрованным открытым ключом ( RSA ) пользователя А. Пользователь А может извлечь ключ S_A, расшифровав сначала временный ключ при помощи своего секретного ключа ( RSA ), а потом использовав этот временный ключ для окончательного расшифрования подписанного ключа S_A. Проверка подписи гарантирует, что сеансовый ключ S_A получен от ЦРК.

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

Использование в системе Kerberos технологии открытых ключей позволяет ЦРК не хранить секретные ключи пользователей, что значительно снижает риск компрометации. В случае успешной атаки на ЦРК последствия оказываются менее серьезными, так как новые секретные ключи требуются только серверам.

Аутентификация при помощи сертификатов

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

Аутентификацию при помощи сертификатов обеспечивают несколько распространенных протоколов, в частности, наиболее известный и широко распространенный протокол Secure Socket Layer (SSL), который применяется практически в каждом web-браузере. Помимо него применяются протоколы Transport Layer Security (TLS) [142], Internet Key Exchange (IKE) [147], S/MIME [169], PGP и Open PGP [149]. Каждый из них немного по-своему использует сертификаты, но основные принципы - одни и те же.

Рис. 2.5. Взаимная аутентификация на базе сертификатов

Рис. 2.5 иллюстрирует типичный обмен сообщениями при аутентификации на базе сертификатов, использующий цифровые подписи [70]. Обмен соответствует стандарту аутентификации субъектов на основе криптографии с открытыми ключами [117]. Во многих протоколах предусматривается, что клиент направляет запрос серверу для того, чтобы инициировать аутентификацию. Такой подход, характерный, например, для дополнений аутентификации и шифрования к протоколу Internet File Transfer Protocol, гарантирует, что и пользователь, и сервер поддерживают один и тот же механизм аутентификации. Некоторые протоколы не требуют этого подготовительного шага.

Если сервер В поддерживает метод аутентификации, запрашиваемый пользователем А, то начинается обмен сообщениями. Сообщение Token ID уведомляет о том, что будет выполняться взаимная аутентификация, а также содержит номер версии протокола и идентификатор протокола. Хотя этот идентификатор не обязателен, он намного упрощает процедуру и поэтому обычно используется. Пользователь А ожидает сообщение Token ВА1 от сервера В. Идентификатор протокола в Token ID позволяет пользователю А удостовериться, что сервер В отправляет ожидаемое сообщение. Token ВА1 состоит только из случайного числа ran B, это - своего рода запрос, корректным ответом должна быть цифровая подпись числа ran B. Пользователь А подписывает ответ и отправляет свой сертификат ключа подписи, для того чтобы сервер В при помощи открытого ключа мог выполнить валидацию подписи.

Пользователь А подписывает последовательность из трех элементов: свой запрос ran A, запрос сервера ran B и имя сервера name B. Ran A - это запрос А к серверу В, гарантирующий, что пользователь А подписывает не произвольное сообщение сервера В или другого субъекта, выдающего себя за сервер В. Получив ответ Token АВ от пользователя А, сервер В проверяет, совпадает ли значение ran B с соответствующим значением в сообщении Token ВА1, а по значению name В устанавливает, действительно ли пользователь А желает пройти аутентификацию сервера В. Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае сервер В проверяет подлинность сертификата пользователя А и его цифровую подпись, если сертификат и подпись валидны, то аутентификация пользователя А сервером В прошла успешно. Ответ сервера В пользователю А завершает взаимную аутентификацию.

Ответ сервера Token ВА2 состоит из заверенной цифровой подписью последовательности трех элементов: ran A, ran B и name A, где ran A - запрос, сгенерированный А, ran B - исходный запрос сервера В, а name A - имя пользователя А. Получив ответ сервера, пользователь А убеждается, что ran A имеет то же самое значение, что и в сообщении Token АВ, а проверяя значение name A - что сервер В намерен аутентифицировать именно его (пользователя А ). Если какая-либо из проверок дает отрицательный результат, то и аутентификация завершается неудачно. В противном случае пользователь А проверяет подлинность сертификата сервера В и его цифровой подписи. Если они валидны, то пользователь А аутентифицировал сервер В, и взаимная аутентификация выполнена.

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

Возможности PKI

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

* механизмом установления доверия на базе определенной модели доверия;

* механизмом присваивания субъектам имен, уникальных в данной среде;

* механизмом распространения информации, характеризующей правильность связывания определенной пары ключей ( открытого и секретного) с определенным именем субъекта в данной среде (такая информация фиксируется и предоставляется центром, которому доверяет верификатор информации) [44].

Строго говоря, PKI обеспечивает аутентификацию - не больше и не меньше; вопреки широко распространенному мнению о возможностях PKI, она не реализует:

* авторизацию (хотя может применяться с целью защиты информации, используемой для авторизации);

* доверие (хотя и способствует установлению отношений доверия, подтверждая принадлежность данного открытого ключа определенному субъекту);

* именование субъектов (а только связывает известные имена субъектов с их открытыми ключами );

* защиту компьютерных систем и сетей (служит базисом сервисов безопасности, но не заменяет собой другие средства и методы защиты).

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

Лекция 3. Основные компоненты и сервисы PKI

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

Основные компоненты PKI

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

Основными компонентами эффективной PKI являются:

* удостоверяющий центр ;

* регистрационный центр ;

* репозиторий сертификатов;

* архив сертификатов ;

* конечные субъекты (пользователи).

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

Удостоверяющий центр

Фундаментальная предпосылка криптографии с открытыми ключами заключалась в том, что два незнакомых субъекта должны иметь возможность безопасно связываться друг с другом. Например, если пользователь А желает отправить конфиденциальное сообщение пользователю В, с которым он ранее не встречался, то для шифрования сообщения он должен иметь возможность связать каким-либо образом пользователя В и его открытый ключ. Для сообщества потенциальных пользователей, объединяющего сотни тысяч или миллионов субъектов, наиболее практичным способом связывания открытых ключей и их владельцев является организация доверенных центров. Этим центрам большая часть сообщества или, возможно, все сообщество доверяет выполнение функций связывания ключей и идентификационных данных (идентичности) пользователей.

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

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

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

Рис. 3.1. Основные компоненты PKI

Удостоверяющий центр - главный управляющий компонент PKI - выполняет следующие основные функции:

* формирует собственный секретный ключ; если является головным УЦ, то издает и подписывает свой сертификат, называемый самоизданным или самоподписанным ;

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

* поддерживает реестр сертификатов (базу всех изданных сертификатов) и формирует списки САС с регулярностью, определенной регламентом УЦ ;

* публикует информацию о статусе сертификатов и списков САС.

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

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

Регистрационный центр

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

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

РЦ объединяет комплекс программного и аппаратного обеспечения и людей, работающих на нем. В функции РЦ может входить генерация и архивирование ключей, уведомление об аннулировании сертификатов, публикация сертификатов и САС в каталоге LDAP и др. Но РЦ не имеет полномочий выпускать сертификаты и списки аннулированных сертификатов. Иногда УЦ сам выполняет функции РЦ.

Репозиторий сертификатов

Репозиторий - специальный объект инфраструктуры открытых ключей, база данных, в которой хранится реестр сертификатов (термин " реестр сертификатов ключей подписей" введен в практику Законом РФ "Об электронной цифровой подписи") [10]. Репозиторий значительно упрощает управление системой и доступ к ресурсам. Он предоставляет информацию о статусе сертификатов, обеспечивает хранение и распространение сертификатов и САС, управляет внесениями изменений в сертификаты. К репозиторию предъявляются следующие требования:

* простота и стандартность доступа;

* регулярность обновления информации;

* встроенная защищенность;

* простота управления;

* совместимость с другими хранилищами (необязательное требование).

Репозиторий обычно размещается на сервере каталогов, организованных в соответствии с международным стандартом X.500 и его подмножеством. Большинство серверов каталогов и прикладное программное обеспечение пользователей поддерживают упрощенный протокол доступа к каталогам LDAP (Lightweight Directory Access Protocol) [154]. Такой унифицированный подход позволяет обеспечивать функциональную совместимость приложений PKI и дает возможность доверяющим сторонам получать информацию о статусе сертификатов для верификации цифровых подписей.

Архив сертификатов

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

Конечные субъекты

Конечные субъекты, или пользователи, PKI делятся на две категории: владельцы сертификатов и доверяющие стороны. Они используют некоторые сервисы и функции PKI, чтобы получить сертификаты или проверить сертификаты других субъектов. Владельцем сертификата может быть физическое или юридическое лицо, приложение, сервер и т.д. Доверяющие стороны запрашивают и полагаются на информацию о статусе сертификатов и открытых ключах подписи своих партнеров по деловому общению.

Физическая топология

Система PKI, помимо выполнения целого ряда функций - выпуска сертификатов, генерации ключей, управления безопасностью, аутентификации, восстановления данных, - должна обеспечивать интеграцию с внешними системами. PKI необходимо взаимодействовать с множеством самых разных систем и приложений - это и программное обеспечение групповой работы, и электронная почта, и системы управления доступом, и каталоги пользователей, и виртуальные частные сети, и разнообразные операционные системы, и службы безопасности, и web-приложения, и широкий спектр корпоративных систем [10]. Рис. 3.2 иллюстрирует взаимодействие пользователей с серверами PKI.

Функциональные компоненты PKI ( УЦ, РЦ и др.) могут быть реализованы программно и аппаратно различными способами, например, располагаться на одном или нескольких серверах. Системы, выполняющие функции удостоверяющего и регистрационного центров, часто называют серверами сертификатов и регистрации соответственно.

Серверные компоненты PKI

Основными серверными компонентами PKI являются сервер сертификатов, сервер каталогов и сервер восстановления ключей, опциональными компонентами - сервер регистрации, OCSP-сервер, обслуживающий запросы пользователей по онлайновому протоколу статуса сертификата Online Certificate Status Protocol (более подробно об этом см. лекцию 12), и сервер проставления меток времени.

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

Сервер каталогов содержит информацию о сертификатах и атрибутах субъектов сертификатов открытых ключей. Через протокол LDAP приложения стандартным образом обращаются к записям каталогов, например, к адресам электронной почты, номерам телефонов, полномочиям и сертификатам пользователей.

Рис. 3.2. Взаимодействие пользователей с серверами PKI

Сервер каталогов должен обеспечивать:

* сетевую аутентификацию через IP-адреса или DNS-имена и аутентификацию конечных субъектов по именам и паролям или по сертификатам открытых ключей ;

* управление доступом субъектов к информации в зависимости от их прав на выполнение операций чтения, записи, уничтожения, поиска или сравнения;

* конфиденциальность (посредством протокола SSL) и целостность сообщений для всех видов связи [56].

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

PKI управляет ключами и сертификатами, используемыми для реализации криптографических операций в web-браузерах, web-серверах, приложениях электронной почты, электронного обмена сообщениями и данными, в приложениях, поддерживающих защищенные сетевые транзакции и сеансы связи через World Wide Web или в виртуальных частных сетях на базе протоколов S/MIME, SSL и IPsec, а также для заверения цифровой подписью электронных документов или программного кода [82]. Наряду с перечисленными выше приложениями, PKI-совместимыми могут быть и корпоративные приложения, разработанные внутри организации.

Приложения электронной почты и обмена сообщениями используют пары ключей для шифрования сообщений и файлов и заверения их цифровыми подписями. Системы электронного обмена данными поддерживают транзакции, требующие аутентификации сторон, обеспечения конфиденциальности и целостности данных. Браузеры и web-серверы используют шифрование для аутентификации, обеспечения конфиденциальности, а также в приложениях электронной коммерции и онлайнового предоставления банковских услуг. Шифрование и аутентификация применяются также для создания виртуальных частных сетей (Virtual Private Networks - VPN) на основе сетей общего пользования, для защиты коммуникаций между сайтами или удаленного доступа (клиент-сервер). Заверение цифровой подписью программных кодов и файлов дает возможность пользователям подтвердить источник получаемых по Интернету программ и файлов и целостность их содержания, это важно и для контроля вирусного заражения.

Клиентское программное обеспечение

Как известно, технология "клиент-сервер" предполагает обслуживание клиента только по его запросу, тот же самый принцип справедлив и для PKI. Клиентское программное обеспечение (ПО) пользователя должно запрашивать сервисы сертификации и обрабатывать информацию об аннулированных сертификатах, понимать истории ключей и отслеживать своевременное обновление или восстановление ключей, анализировать необходимость проставления меток времени. Клиентскому ПО необходимо распознавать идентификаторы политики применения сертификатов, вовремя определять статус сертификата и правильно выполнять обработку пути сертификации (см. лекцию 11).

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

Компонент клиентской стороны PKI может быть:

* относительно большим ("толстый" клиент), выполняющим большую часть операционной работы PKI, в том числе обработку путей сертификации и валидацию;

* относительно небольшим ("тонкий" клиент), просто вызывающим внешние серверы для выполнения PKI-функций;

* Java-апплетом или аналогичным мобильным кодом, при необходимости загружаемым в режиме реального времени, а затем удаляемым после завершения работы вызывающего приложения (подобного web-браузеру);

* динамически подключаемой библиотекой (Dynamically Linked Library - DLL) или аналогичной, которая размещается резидентно на клиентской платформе.

Существует много возможностей реализации и вызова клиентского ПО, но главным требованием является независимость этого компонента от приложений, использующих PKI.

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

Сервисы PKI

Ядро инфраструктуры открытых ключей образуют сервисы управления сертификатами и криптографические сервисы, в крупномасштабных PKI важная роль отводится вспомогательным сервисам.

Криптографические сервисы

Генерация пар ключей

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

Выработка цифровой подписи

Этот сервис заключается в генерации хэш-кода сообщения и подписи его цифровым образом.

Верификация (проверка) цифровой подписи

Посредством этого сервиса устанавливается подлинность сообщения и соответствующей ему цифровой подписи.

Сервисы управления сертификатами

Выпуск сертификатов

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

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

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

Управление жизненным циклом сертификатов и ключей

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

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

Пример 3.1. В качестве примера можно привести следующую аналогию аннулирования сертификатов. Водительские права - это один из видов сертификатов, который связывает идентичность (имя и фотографию) с номером водительских прав (то есть разрешением на вождение) и выдается доверенным центром (автоинспекцией). Когда инспектор останавливает машину, то он не просто проверяет, на какой срок выданы права, но также может связаться с доверенным центром, чтобы выяснить, не были ли права аннулированы. Проверка на предмет аннулирования необходима, потому что иногда связь "идентичность-разрешение" в непросроченных правах не является надежной [10].

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

Аналогично аннулированию осуществляется приостановление действия сертификата. Оно заключается в однократной отмене сертификата на некоторое время в течение периода его действия. После этого действие сертификата возобновляется автоматически или же сертификат аннулируется. Приостановление действия сертификата осуществляется в тех ситуациях, когда невозможно установить подлинность лица, обращающегося с запросом об аннулировании.

Поддержка репозитория

Выпущенный сертификат или САС включается в репозиторий (в соответствии со спецификациями стандарта X.500 или иными требованиями), чтобы третьи стороны могли иметь к нему доступ. Обычно репозиторий контролируется УЦ, в некоторых случаях - третьей стороной. Доступ к репозиторию может быть ограничен. Если необходимо соблюдение конфиденциальности персональных данных пользователей, применяются меры защиты данных от лиц, не имеющих полномочий доступа.

Хранение сертификатов и САС в архиве

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

Вспомогательные сервисы

Регистрация

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

Хранение информации в архиве

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

Резервное хранение и восстановление ключей

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

При функционировании PKI иногда возникают ситуации, когда пользователи больше не могут использовать свои секретные ключи:

* недоступность зашифрованного секретного ключа (забытые пароли доступа);

* разрушение среды хранения секретного ключа (например, смарт-карты, жесткого диска);

* уничтожение секретного ключа при замене среды хранения (переформатирование жесткого диска, установка нового диска и др.).

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

Сервисы обеспечивают создание резервных копий и восстановление информации в случае уничтожения или устаревания среды хранения.

Автоматическое обновление ключей

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

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

Решение проблемы заключается в том, чтобы реализовать PKI таким способом, при котором обновление ключа или сертификата управляется самой PKI полностью автоматически, без какого бы ни было вмешательства пользователя. Независимо от назначения сертификата проверяется его срок действия, и когда срок истекает, начинается операция обновления и генерируется новый сертификат, который заменяет старый.

Управление историями ключей

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

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

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

Процесс корректировки пар ключей должен быть "прозрачен" для пользователя. Это означает, что пользователи не должны заботиться об обновлении ключей или получать отказ в обслуживании из-за недействительности своих ключей. Для удовлетворения этого требования пары ключей пользователя должны автоматически обновляться до истечения срока их действия. При обновлении пары ключей подписи предыдущий ключ подписи безопасно уничтожается, тем самым предотвращается несанкционированный доступ к ключу и устраняется необходимость хранения предыдущих ключей.

Другие сервисы

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

Сервисы, базирующиеся на PKI

Предотвращение отказа от участия в обмене информацией

Сервис предотвращения отказа от участия в обмене информацией генерирует электронные доказательства времени подписания или передачи данных и аутентификации источника данных, которые могут использоваться для того, чтобы стороны, отправляющие и принимающие электронные сообщения или документы, не могли отрицать свое участие в информационном обмене в целом или на отдельных его этапах [2]. Считается, что если зафиксированы время участия в информационном обмене и источник информации, то сторона, отправляющая информацию, не сможет отрицать того, что сообщение отправлено ею (доказательство происхождения данных), а сторона, принимающая информацию, не сможет отрицать того, что получила сообщение (доказательство доставки данных). Для краткости этот сервис часто называют сервисом "неотказуемости". Термин " неотказуемость " интуитивно понятен многим, привычен и широко распространен в среде специалистов, поэтому в дальнейшем изложении сервис предотвращения отказа от участия в обмене информацией будем называть сервисом неотказуемости.

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

Авторизация

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

Нотариальная аутентификация

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

К сервисам, базирующимся на PKI, также относятся защищенное датирование, поддержка защищенного архива данных и некоторые другие сервисы, все они более подробно описываются в лекции 16.

Лекция 4. Сервисы безопасности PKI и базовые криптографические механизмы

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

Сервисы безопасности PKI

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

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

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

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

* конфиденциальность данных при взаимодействии с установлением соединения;

* конфиденциальность данных при взаимодействии без установления соединения;

* конфиденциальность отдельных полей данных (избирательная конфиденциальность );

* конфиденциальность трафика (защита информации, которую можно получить, анализируя трафик).

К основным сервисам безопасности, помимо перечисленных выше, международный стандарт X.800 (Recommendation X.800) относит также и сервис неотказуемости [56]. Строго говоря, сервис неотказуемости является сервисом, базирующимся на PKI, он предоставляет лишь электронные доказательства времени подписания или передачи данных и аутентификации источника данных, которые в случае возникновения спора между сторонами могут быть учтены или оспорены во время судебного разбирательства. При принятии решения о неправомерных действиях одной из сторон более важен человеческий фактор, нежели результат процедуры, выполняемой PKI автоматически. Поэтому сервис неотказуемости рассматривается в главе, которая посвящена сервисам, базирующимся на PKI.

Идентификация и аутентификация

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

Обычный способ идентификации - ввод имени пользователя при входе в систему. Для аутентификации пользователей, то есть проверки подлинности их личности, чаще всего используются пароли. При аутентификации источника данных подтверждается подлинность источника отдельной порции данных. Функция не обеспечивает защиты против повторной передачи данных [5].

Аутентификация обычно находит применение в двух основных контекстах: идентификации субъекта и идентификации источника данных.

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

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

Идентификация источника данных выполняется с намерением стационарно и окончательно связать идентифицированного субъекта с некоторыми определенными данными независимо от его любых дальнейших действий. Такой процесс может обеспечить поддержку сервиса неотказуемости.

По степени приближенности субъекта к среде различают следующие процедуры идентификации:

1 начальную идентификацию субъекта в локальной среде, то есть на персональном, физически приближенном к субъекту устройстве без связи с другими устройствами в сети;

2 идентификацию субъекта в удаленной среде или при доступе к удаленному устройству.

В процедуре локальной аутентификации, или начальной аутентификации субъекта в локальной среде, почти всегда явно и непосредственно участвует пользователь, который должен ввести пароль или предъявить биометрические характеристики (отпечатки пальцев, рисунок радужной оболочки глаза). Удаленная аутентификация, или аутентификация субъекта в некоторой удаленной среде, может выполняться как с участием, так и без участия пользователя [44]. Обычно более сложные системы аутентификации явным образом не включают пользователя. Это происходит по двум причинам:

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

2 Пользователям неудобно вводить аутентифицирующую информацию всякий раз, когда они желают получить доступ к удаленной сети.

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

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

1 того, что субъект имеет (например, смарт-карты или аппаратного ключа);

2 того, что субъект знает (например, пароля или PIN-кода);

3 того, чем субъект является (например, отпечатков пальцев, параметров ладони или рисунка радужной оболочки глаза);

4 того, что субъект делает (например, клавиатурного почерка).

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

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

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

Целостность

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

Конфиденциальность

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

* хранится на носителе (например, на жестком диске компьютера), откуда она может быть прочитана или скопирована субъектом, не имеющим полномочий;

* представляет собой резервную копию на носителе (типа магнитной ленты), который может попасть в руки стороннего субъекта;

* передается по незащищенным каналам.

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

Базовые криптографические механизмы сервисов безопасности PKI

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

Современная криптография предлагает большой набор механизмов обеспечения информационной безопасности: от "классического" шифрования до алгоритмов хэширования, схем аутентификации, цифровой подписи и других криптографических протоколов [212]. Кратко остановимся на трех классах криптографических механизмов - симметричных алгоритмах, алгоритмах хэширования и асимметричных алгоритмах.

Симметричные алгоритмы

Использование симметричных криптографических алгоритмов предполагает наличие взаимного доверия сторон, участвующих в обмене электронными документами или сообщениями, так как для шифрования и расшифрования применяется известный им один и тот же общий ключ. В этом случае нет никаких гарантий, что секретный ключ не будет скомпрометирован, поэтому применение симметричных алгоритмов требует очень надежных механизмов распределения ключей. Кроме того, необходимость обмена единым ключом между отправителем сообщения и каждым из получателей многократно увеличивает количество ключей в системе и затрудняет ее масштабируемость. Для 10 пользователей нужно 45 ключей, а для 1000 - уже 499 500 ключей [213].

Симметричные алгоритмы могут ограниченно использоваться для поддержания сервисов аутентификации и целостности, но в первую очередь применяются для обеспечения конфиденциальности. Для проверки целостности сообщения и аутентификации источника данных отправитель может сгенерировать шифртекст на базе всего открытого текста, как излагалось выше. После этого он отправляет открытый текст и часть шифртекста получателю сообщения. Эта часть шифртекста известна как код аутентификации сообщения или MAC (Message Authentication Checksum). Функция MAC на основе входа переменной длины и ключа формирует выход фиксированной длины [23]. Получатель использует свою копию секретного ключа отправителя сообщения для генерации шифртекста, выбирает ту же часть шифртекста и сравнивает ее с полученным значением MAC. Их совпадение подтверждает подлинность отправителя, но не гарантирует невозможности отказа от участия в обмене сообщениями. Отправитель может отрицать факт передачи сообщения, мотивируя это тем, что получатель вполне мог сгенерировать сообщение сам.

Управление ключами - сложная проблема, она может решаться при помощи криптографии с симметричными ключами, но является классической проблемой типа "курица или яйцо". Прежде чем отправитель зашифрует сообщение или сгенерирует MAC, он должен разделить с получателем некоторый секрет. Разделение секрета, например, секретного ключа из нескольких частей, осуществляется таким образом, чтобы из любого заранее указанного количества k -частей можно было восстановить секрет, а количества частей (k - 1) для восстановления секрета было недостаточно [23]. В системах с одним ключом утрата ключа фактически равноценна взлому криптографической защиты. Для обеспечения требуемого уровня защиты ключ обычно передают по каналам, отличным от канала распространения зашифрованных данных. При этом должна обеспечиваться надежная идентификация пользователя (он должен иметь санкционированный доступ к зашифрованной информации) и секретность (предотвращение доступа к ключу в процессе передачи).

Преимуществами симметричных криптографических алгоритмов признаны их высокая производительность и стойкость, которая делает практически невозможным процесс расшифрования. Одним из первых стандартных симметричных алгоритмов стал DES (Digital Encryption Standard), затем появился Triple DES, который выполняет алгоритм DES троекратно и соответственно требует для работы в три раза больше времени. Для решения проблемы производительности и повышения защитных свойств были предложены новые алгоритмы RC2 и RC5 корпорации RSA Security, IDEA компании Ascom, Cast компании Entrust Technologies, Safer компании Cylink и Blowfish компании Counterpane Systems [2]. В России разработан и используется симметричный алгоритм ГОСТ 28147-89. В качестве нового международного стандарта AES (Advanced Encryption Standard) предлагается симметричный алгоритм Rijndael [47], разработанный бельгийскими криптографами В. Риджменом и Д. Дименом.

Алгоритмы хэширования

Криптографическими методами можно обеспечить не только конфиденциальность, но и проконтролировать целостность передаваемых или хранимых данных. Контроль целостности в основном осуществляется путем расчета некоторой "контрольной суммы" данных. На сегодняшний день известно множество алгоритмов, рассчитывающих контрольные суммы передаваемых данных. Проблема простых алгоритмов вычисления контрольной суммы состоит в том, что достаточно легко подобрать несколько массивов данных, имеющих одинаковую контрольную сумму. Криптографически стойкие контрольные суммы вычисляются как результат применения к исходному тексту так называемой хэш-функции. Под этим термином понимаются функции, отображающие сообщения произвольной длины (иногда длина сообщения ограничена, но достаточно велика) в значения фиксированной длины [212]. Последние часто называют хэш-кодами, или дайджестами, сообщений. Хэш-функции - это необходимый элемент ряда криптографических схем.

Главными свойствами "хорошей" в криптографическом смысле хэш-функции являются свойство необратимости, свойство стойкости к коллизиям и свойство рассеивания. Необратимость означает, что вычисление обратной функции (то есть восстановление значения аргумента по известному значению функции) оказывается невозможно теоретически или (в крайнем случае) невозможно вычислительно. Свойство стойкости к коллизиям хэш-функции H выражается в невозможности найти два разных сообщения T₁ и T₂ с одинаковым результатом преобразования H(T₁) = H(T₂). Хэш-код может быть повторно получен для того же сообщения любым пользователем, но практически невозможно создать разные сообщения для получения одного и того же хэш-кода сообщения. Значение хэш-функции всегда имеет фиксированную длину, а на длину исходного текста не накладывается никаких ограничений. Свойство рассеивания требует, чтобы минимальные изменения текста, подлежащего хэшированию, вызывали максимальные изменения в значении хэш-функции [37].

Хэш-код сообщения может использоваться для обеспечения целостности. Отправитель посылает сообщение вместе с контрольным значением - хэш-кодом, и если сообщение было изменено, контрольное значение также будет другим. Получатель может вновь вычислить хэш-код сообщения, чтобы убедиться, что данные не были случайно изменены. Однако это не защищает получателя от действий злоумышленника, который может перехватить и заменить сообщение отправителя и хэш-код.

Хэш-функция может использоваться для создания так называемого кода аутентификации сообщения на основе вычисления хэша HMAC (Hash Message Authentication Checksum). Если отправитель посылает сообщение и его HMAC получателю, то последний может повторно вычислить HMAC, чтобы проверить, не были ли данные случайно изменены при передаче. Сторонний наблюдатель может перехватить сообщение отправителя и заменить его на новое, но, не зная секретного ключа, не имеет возможности рассчитать соответствующий HMAC. Если получатель доверяет отправителю, то принимает HMAC как подтверждение подлинности его сообщения.

Обычно коды HMAC используются только для быстрой проверки того, что содержимое не было изменено при передаче. Для создания уникальной, подлежащей проверке подписи необходим другой способ - он заключается в шифровании хэш-кода сообщения при помощи секретного ключа лица, поставившего подпись. В этом случае хэш-функция используется в схемах электронной цифровой подписи (ЭЦП). Поскольку применяемые на практике схемы электронной подписи не приспособлены для подписания сообщений произвольной длины, а процедура разбиения сообщения на блоки и генерации подписи для каждого блока по отдельности крайне неэффективна, - схему подписи применяют к хэш-коду сообщения. Очевидно, что наличие эффективных методов поиска коллизий для хэш-функции подрывает стойкость протокола электронной подписи [212]. Хэш-функции используются также в некоторых протоколах аутентификации для снижения их коммуникационной сложности, то есть для уменьшения длин пересылаемых сообщений, а также в некоторых других криптографических протоколах.

Существует множество алгоритмов, реализующих хэш-функции. К ним относятся алгоритмы вычисления хэш-кодов, созданные Роном Ривестом (MD2, MD5), SHA и его вариант SHA1, российский алгоритм, описываемый стандартом ГОСТ Р 34.11-94 [15].

Асимметричные алгоритмы

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

Асимметричные системы имеют ряд преимуществ перед симметричными системами. В асимметричных системах решена сложная проблема распределения ключей между пользователями, так как каждый пользователь может сгенерировать свою пару ключей, а открытые ключи свободно публикуются и распространяются. Благодаря тому, что в асимметричных системах секретный ключ известен только его владельцу, возможно взаимодействие сторон, не знающих друг друга. Среди асимметричных алгоритмов наиболее известными являются RSA и алгоритм Эль-Гамаля [215].

Криптография с открытыми ключами в чистом виде обычно не применяется, так как реализация асимметричных алгоритмов требует больших затрат процессорного времени. Тем не менее преимуществами криптографии с открытыми ключами пользуются при формировании и проверке цифровой подписи, а также для решения проблемы распределения ключей. Секретный ключ применяется для подписания данных, а открытый ключ - для их проверки. Единственно известный способ получить корректную подпись - использовать секретный ключ. Кроме того, для каждого сообщения формируется уникальная подпись. В целях повышения производительности подписывается не все сообщение, а его хэш-код [2]. Вообще, собственно цифровая подпись сообщения - это хэш-код сообщения, зашифрованный секретным ключом, он пересылается вместе с цифровым объектом и удостоверяет целостность самого объекта и подлинность его отправителя.

Для выработки цифровой подписи пользователь генерирует открытый и секретный ключи. Затем секретный ключ и цифровой объект (документ) используются как входная информация для функции генерации цифровой подписи. После того как другой пользователь получает цифровой объект, он использует сам объект, связанную с ним цифровую подпись и открытый ключ для верификации (проверки) подписи. Верификация цифровой подписи сообщения заключается в вычислении значения хэш-кода полученного сообщения и его сравнении со значением хэш-кода в подписи, расшифрованной открытым ключом отправителя. Если значения вычисленного получателем и сохраненного в подписи хэш-кода совпадают, то считается, что подпись под документом верна, а сам документ - подлинный [37]. Цифровая подпись обеспечивает надежную защиту документа от подлога и случайных модификаций и позволяет придавать юридическую силу электронным документам и сообщениям.

В схемах цифровой подписи применяются три основных алгоритма: RSA, алгоритм цифровой подписи DSA (Digital Signature Algorithm) и его вариант с использованием эллиптических кривых - EСDSA (Elliptic Curve Digital Signature Algorithm).

Сравнение криптографических механизмов безопасности

Криптографические механизмы необходимы для поддержания основных сервисов безопасности. Каждый класс алгоритмов имеет свои сильные и слабые стороны (см. табл. 4.1) [84].

Алгоритмы хэширования и коды аутентификации сообщения - основа обеспечения целостности данных в электронных коммуникациях. Но они не позволяют обеспечить конфиденциальность, аутентификацию, неотказуемость и распределение ключей. Алгоритмы цифровой подписи, такие как RSA и DSA, по эффективности превосходят алгоритмы хэширования. Если управление ключами возлагается на третью доверенную сторону, цифровые подписи могут использоваться для обеспечения неотказуемости.

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

Самое слабое звено этих алгоритмов - распространение (распределение) ключей. Для решения проблемы распространения ключей широко используются алгоритм RSA, алгоритм Диффи-Хэллмана - Diffie-Hellman (DH) и алгоритм эллиптических кривых Диффи-Хэллмана - Elliptic Curve Diffie-Hellman (ECDH). Распространение ключей может выполняться тремя способами: прямым обменом между сторонами при помощи симметричного шифрования; посредством симметричного шифрования и доверенной третьей стороны или при помощи управления открытыми ключами доверенной третьей стороной.

|Симметричная криптография | Шифрование | - | + | - | - | - |

|Коды аутентификации сообщения | + | - | - | - | - |

|Транспортировка ключей | - | - | - | - | + |

|Хэш-функции | Хэш-код сообщения | + | - | - | - | - |

|HMAC | + | - | - | - | - |

|Асимметричная криптография | Цифровые подписи | + | - | + | + | - |

|Транспортировка ключей | - | - | - | - | + |

|Согласование ключей | - | - | - | - | + |

Таблица 4.1.Сравнение криптографических механизмов безопасности

Первый способ подходит для небольших закрытых сообществ с числом пользователей не более 4 - 5 человек. Это решение плохо масштабируется при росте сообщества. Если число участников обмена ключами достигает 10 - 12 человек, то возникает необходимость в доверенной третьей стороне. Второй способ позволяет существенно расширить сообщество пользователей, но не обеспечивает в должной мере аутентификацию партнеров и неотказуемость. Только третий способ решает проблему комплексно. Если доверенная третья сторона связывает открытый ключ с пользователем или системой, то есть подтверждает подлинность стороны, владеющей соответствующим секретным ключом, то поддерживаются все сервисы безопасности.

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

Лекция 5. Модели и механизмы доверия

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

Концепция доверия в PKI

При развертывании PKI необходимо иметь представление о распространенных моделях доверия, таких как:

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

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

* иерархия на базе политик;

* модель распределенного доверия;

* четырехсторонняя модель доверия;

* Web-модель доверия;

* модель доверия, сконцентрированного вокруг пользователя.

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

Прежде чем перейти к описанию моделей доверия, важно внести ясность, что понимается под доверием в данном контексте. Наиболее точно смысл "доверия", по мнению авторов, передает формулировка рекомендаций X.509 ITU-T [78]: можно сказать, что один субъект "доверяет" другому субъекту, когда предполагает, что второй субъект будет вести себя точно так, как ожидает от него первый субъект. Таким образом, доверие имеет дело с предположениями, ожиданиями и поведением. Очевидно, это означает, что доверие не может быть измерено количественно, существует риск, связанный с доверием, и установление доверия не всегда происходит автоматически (например, когда субъектами в упомянутом выше определении являются люди). Концепция доверия раскрывает:

* где и как инициируется доверие в PKI;

* каким сертификатам может доверять субъект;

* как может быть подтверждено такое доверие;

* при каких обстоятельствах это доверие может быть ограничено или может контролироваться в данной среде.

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

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

Именование субъектов

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

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

Вообще говоря, субъект может и не иметь имени (то есть действовать анонимно), может пользоваться псевдонимом (фальшивым именем) или веронимом (настоящим именем). Вероним - это и есть то, что обычно подразумевается под идентичностью субъекта. Таким образом, идентичность не только уникально идентифицирует, или отличает субъекта в данной среде, но и раскрывает данные реальным миром имя, фамилию субъекта или аналогичную информацию, точно соответствующую человеку или объекту реального мира [44]. Поскольку реализации PKI обычно помещают вероним в сертификат субъекта - в поле Subject (субъект) или Subject Alt Name (альтернативное имя субъекта), - то, вообще говоря, PKI связывает пару ключей с идентичностью субъекта, хотя концептуально эта формулировка ограничена и использование вместо нее имени является технически более точным.

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

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

С теоретической точки зрения, глобальная уникальность имен субъектов в целом достижима на базе механизма отличительных имен стандарта X.500 [54]. Это иерархическая структура именования с корнем наверху и центром именования в каждой вершине, каждый центр именования гарантирует уникальность имен вершин, находящихся в иерархии непосредственно под ним. Механизм отличительных имен гарантирует уникальность имен, если каждый субъект, который получит имя таким способом, официально регистрируется вместе с соответствующим центром именования и принимает присвоенное ему имя. В современных электронных коммуникациях базисом адресации и маршрутизации являются имена, образованные на основе IP-адресов и адресов электронной почты.

Однако механизм отличительных имен не считается абсолютно удачным, по крайней мере, по двум причинам:

1 Концепция каталога X.500 и полезность отличительных имен не кажется привлекательными основному сообществу пользователей из-за популярности и широкой распространенности альтернативного способа идентификации субъектов - имен электронной почты.

2 Во многих случаях субъекты при присвоении имен не прибегают к помощи центра именования, а выбирают себе имена сами. Таким образом, два разных субъекта могут присвоить себе одинаковые имена независимо от какого-либо центра именования. Очевидно, что глобальная уникальность имен достигается только, если все субъекты соблюдают правила образования отличительных имен стандарта X.500, но не существует способа гарантировать это.

Отличительные имена поддерживаются и в сертификатах формата X.509, но при этом разрешено использование альтернативных имен субъектов, таких как IP-адрес или адрес электронной почты, чтобы гарантировать уникальность имени субъекта и обеспечить связь с другими механизмами идентичности.

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

Строгая иерархия удостоверяющих центров обычно графически изображается в виде древовидной структуры с корнем наверху и ветвями, спускающимися вниз и заканчивающимися листьями. В этом перевернутом дереве корень представляет определенный УЦ, который обычно называется корневым (или головным ) и действует как главный пункт, или корень, доверия для целого домена подчиненных ему субъектов 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. Таким образом, если доверяющая сторона оценивает сертификат, выпущенный сторонним УЦ, то должна выполнять валидацию пути сертификации в соответствии с требованиями строгой иерархии.

Иерархии на основе политик

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

Модель распределенного доверия

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

Рис. 5.2. Архитектура распределенного доверия

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

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

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

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

* взаимное распознавание;

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

* применение сертификатов аккредитации.

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

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

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

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

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

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

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

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

Четырехсторонняя модель доверия

Обоснованность четырехсторонней модели доверия была протестирована в пилотном проекте обеспечения функциональной совместимости удостоверяющих центров Национальной Ассоциации клиринговых палат (США) [90]. Четырехсторонняя модель доверия представлена на рис. 5.3. В качестве четырех сторон в модели выступают подписчик, доверяющая сторона и удостоверяющие центры подписчика и доверяющей стороны.

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

Рис. 5.3. Четырехсторонняя модель доверия

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

Web-модель

Web-модель получила свое название, поскольку базируется на популярных браузерах Netscape Navigator и Microsoft Internet Explorer, используемых как средства навигации во Всемирной Паутине - World Wide Web. Эта модель предусматривает встраивание в готовый браузер набора открытых ключей головных удостоверяющих центров, которым пользователь браузера может изначально "доверять" при проверке сертификатов. Хотя браузер позволяет корректировать набор корневых ключей (удалять одни ключи и добавлять другие), очевидно, что лишь немногие пользователи имеют достаточное представление о PKI и проблемах безопасности, чтобы управлять этим режимом работы браузера.

На первый взгляд эта модель аналогична модели распределенного доверия, но по существу более похожа на модель строгой иерархии. Web-модель немедленно делает пользователя браузера доверяющей стороной всех PKI-доменов, представленных в браузере. Для всех практических нужд каждый производитель браузера имеет свой собственный головной УЦ, сертифицирующий "головные" удостоверяющие центры, открытые ключи которых физически встроены в программное обеспечение браузера. По существу это строгая иерархия с подразумеваемым корнем, то есть производитель браузера является виртуальным головным УЦ, а уровень, находящийся ниже, образуют встроенные в браузер открытые ключи удостоверяющих центров [44].

Web-модель обладает явными преимуществами: удобством использования и простотой обеспечения функциональной совместимости. Однако при принятии решения о развертывании PKI в каждом конкретном случае следует учитывать проблемы безопасности. Пользователи браузера автоматически доверяют всем удостоверяющим центрам, открытые ключи которых были заранее встроены в браузер, поэтому безопасность может быть полностью скомпрометирована, если хотя бы один из этих центров окажется "плохим". Например, пользователь А будет доверять сертификату пользователя В, даже если он содержит имя пользователя В, но открытый ключ пользователя C, и подписан "плохим" УЦ, открытый ключ которого был встроен в браузер. В этом случае пользователь А может непреднамеренно разгласить конфиденциальную информацию пользователю C или принять документ с его фальшивой подписью. Причина нарушения безопасности заключается в том, что у пользователя обычно нет уверенности, какой именно корневой ключ из большого числа ключей, встроенных в браузер, участвует в проверке сертификата. Некоторые версии наиболее популярных браузеров поддерживают порядка 100 корневых сертификатов, поэтому пользователю может быть известна лишь небольшая группа из представленных удостоверяющих центров. Кроме того, в этой модели клиентское программное обеспечение доверяет всем удостоверяющим центрам, открытые ключи которых встроены в браузер, в равной степени; таким образом, сертификат, заверенный одним из них, будет, безусловно, принят.

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

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

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

Наконец, важно отметить, что web-модель не предусматривает заключения никакого юридического соглашения или договора между пользователями (доверяющими сторонами) и удостоверяющими центрами, открытые ключи которых встроены в браузер. Так как программное обеспечение браузера часто распространяется свободно или встраивается в операционную систему, удостоверяющие центры не знают, более того, не имеют способа определить, кто является доверяющей стороной. Пользователи даже при непосредственном контакте с УЦ не могут быть уверены, что достаточно осведомлены о потенциальных проблемах безопасности. Таким образом, независимо от обстоятельств, вся ответственность за использование корневых ключей возлагается на доверяющую сторону.

Модель доверия, сконцентрированного вокруг пользователя

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

Пример 5.3. Доверие, сконцентрированное вокруг пользователя, иллюстрирует известная система Pretty Good Privacy (PGP) [40]. В этой системе пользователь создает так называемую сеть доверия, действуя как УЦ (подписывая открытые ключи других субъектов) и обладая собственными открытыми ключами, подписанными другими. Когда пользователь А получает сертификат пользователя В, заверенный цифровой подписью пользователя C, и выясняет, что сертификат пользователя C, которого А не знает, подписан пользователем D, который хорошо знаком пользователю А, то должен решить вопрос о доверии (см. рис. 5.4). Пользователь А может решить: доверять сертификату В (на основе доверия к цепочке сертификатов от пользователя D к пользователю C и пользователю В ) или отвергнуть сертификат В, аргументируя это тем, что к "неизвестному" пользователю В ведет слишком много связей от "знакомого" пользователя D.

Рис. 5.4. Модель доверия, сконцентрированного вокруг пользователя

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

Кросс-сертификация

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

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

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

В соответствии с терминологией рекомендаций X.509 1997 года [77], с точки зрения УЦ₁, кросс-сертификат, изданный для него (то есть такой, в котором УЦ₁ является субъектом, а некоторый другой УЦ - издателем), получил название прямого кросс-сертификата ; сертификат, изданный им самим ( УЦ₁ ), был назван обратным кросс-сертификатом. Эти термины были признаны не всеми специалистами и экспертами, поэтому в новой версии рекомендаций X.509 2000 года их назвали по-другому [78]. Термин "прямой" был изменен на "изданный для данного УЦ", а термин "обратный" - на "изданный данным УЦ".

Если в качестве хранилища сертификатов используется каталог X.500, соответствующие кросс-сертификаты ("изданный для данного УЦ" и "изданный данным УЦ") могут храниться в структуре пары сертификатов в точке входа в каталог каждого из релевантных удостоверяющих центров [44]. Эта структура может применяться при построении пути сертификации (см. рис. 5.5).

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

Рис. 5.5. Кросс-сертификация между УЦ1 и УЦ2

Пример 5.4. Предположим, что пользователь А был сертифицирован УЦ₁ и владеет доверенной копией открытого ключа УЦ₁, а пользователь В был сертифицирован УЦ₂ и владеет доверенной копией открытого ключа УЦ₂. Изначально пользователь А может доверять только тем субъектам, сертификаты которых были заверены УЦ₁, потому что пользователь А способен верифицировать только эти сертификаты. Пользователь А не может верифицировать сертификат пользователя В, так как не владеет доверенной копией открытого ключа УЦ₂ ; аналогично - пользователь В не имеет возможности верифицировать сертификат пользователя А. Однако после кросс-сертификации удостоверяющих центров УЦ₁ и УЦ₂ доверие пользователя А может быть распространено на сообщество субъектов УЦ₂, включая пользователя В. Теперь пользователь А может верифицировать сертификат УЦ₂, используя свою доверенную копию открытого ключа УЦ₁, а затем проверить сертификат пользователя В при помощи своей копии открытого ключа УЦ₂.

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

В частности, используя дополнение сертификата "ограничения на имена", УЦ₁ может задать условие принятия сообществом домена УЦ₁ в качестве валидных только тех сертификатов, которые выпущены УЦ₂ для субъектов определенного сегмента пространства имен. Этот сегмент пространства имен может быть ограничен отдельным пользователем, группой, отделом, целой организацией и т.п. Например, одна компания может использовать этот механизм, чтобы гарантировать принятие в качестве валидных только сертификатов сотрудников отдела закупок другой компании. Дополнение сертификата Policy Constraints (ограничения политики) позволяет управлять назначением сертификатов, например, запрещать их использование для верификации подписи на юридическом контракте.

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

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

Лекция 6. Сертификаты открытых ключей

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

Формат сертификатов открытых ключей X.509

Формат сертификата открытого ключа определен в рекомендациях Международного Союза по телекоммуникациям ITU (X.509) [78] и документе RFC 3280 Certificate & CRL Profile [167] организации инженерной поддержки Интернета Internet Engineering Task Force (IETF). IETF является открытым интернациональным сообществом исследователей, разработчиков сетевых протоколов, операторов и производителей, занимающихся проблемами развития сетей Интернет и обеспечением непрерывного функционирования существующей инфраструктуры. В настоящее время основным принятым форматом является формат версии 3, позволяющий задавать дополнения, с помощью которых реализуется определенная политика безопасности в системе. Несмотря на то, что документ RFC 3820 адресован Интернет-сообществу, формат сертификата открытого ключа предоставляет гибкий механизм передачи разнообразной информации и применяется в корпоративных PKI.

Сертификат открытого ключа подписи или шифрования представляет собой структурированную двоичную запись в формате абстрактной синтаксической нотации ASN.1. Сертификат содержит элементы данных, сопровождаемые цифровой подписью издателя сертификата (см. рис. 6.1 и табл. 6.1). В сертификате имеется десять основных полей: шесть обязательных и четыре опциональных. Большая часть информации, указываемой в сертификате, не является обязательной, а содержание обязательных полей сертификата может варьироваться. К обязательным полям относятся:

* серийный номер сертификата Certificate Serial Number ;

* идентификатор алгоритма подписи Signature Algorithm Identifier ;

* имя издателя Issuer Name ;

* период действия Validity (Not Before/After) ;

* открытый ключ субъекта Subject Public Key Information ;

* имя субъекта сертификата Subject Name.

Под субъектом сертификата понимается сторона, которая контролирует секретный ключ, соответствующий данному открытому ключу. Наличие необязательных полей характерно для сертификатов версий 2 и 3, к необязательным полям сертификата относятся номер версии, два уникальных идентификатора и дополнения. Структура сертификата представлена на рис. 6.1.

Поле Version (см. табл. 6.1) задает синтаксис сертификата, по умолчанию предполагается первая версия сертификата. Если в поле версии указывается 2, то сертификат содержит только уникальные идентификаторы, а если 3, то в сертификат включаются и уникальные идентификаторы, и дополнения, что характерно для всех современных сертификатов. Сертификаты первой версии не содержат уникальные идентификаторы или дополнения.

Рис. 6.1. Структура сертификата

Издатель сертификатов присваивает каждому выпускаемому сертификату серийный номер Certificate Serial Number, который должен быть уникален. Комбинация имени издателя и серийного номера однозначно идентифицирует каждый сертификат.

В поле Signature Аlgorithm Identifier указывается идентификатор алгоритма ЭЦП, который использовался издателем сертификата для подписи сертификата, например ГОСТ Р 34.10-94 (см. рис. 6.2).

Рис. 6.2. Пример сертификата формата X.509

Поле Issuer Name содержит отличительное имя (формата X.500) третьей доверенной стороны, то есть издателя, который выпустил этот сертификат. В поле Validity (Not Before/After) указываются даты начала и окончания периода действия сертификата.

Поле Subject Name содержит отличительное имя субъекта, то есть владельца секретного ключа, соответствующего открытому ключу данного сертификата. Субъектом сертификата может выступать УЦ, РЦ или конечный субъект.

|version | Версия | Версия (0 означает v1, 2 означает v3) |

|serialNumber | Серийный номер сертификата | Серийный номер сертификата |

|signature.algorithm

Identifier

algorithm

parameters

| Идентификатор алгоритма подписи | Тип алгоритма подписи

Алгоритм

Параметры

|issuer | Издатель | Уникальное название УЦ, выпустившего сертификат |

|Validity

NotBefore

notAfter

| Период действия | Период действия

Дата и время начала действия

Дата и время окончания действия

|subject | Субъект | Уникальное имя субъекта |

|SubjectPublicKeyInfo

Algorithm

subjectPublicKey

| Информация об открытом ключе субъекта | Информация об открытом ключе субъекта

Криптографический алгоритм

Ключ (строка битов)

|subjectUniqueID | Уникальный идентификатор субъекта | Уникальный идентификатор субъекта сертификата |

|AuthorityKeyIdentifier

keyIdentifier

authorityCertIssuer

authorityCertSerialNumber

| Идентификатор ключа УЦ | Идентификатор ключа УЦ

Идентификатор ключа

Общее название УЦ

Серийный номер сертификата УЦ

|subjectKeyIdentifier | Идентификатор ключа субъекта | Идентификатор, используемый тогда, когда субъект имеет более одного ключа (например, во время возобновления сертификата) |

|Версия v3 | keyUsage

digitalSignature

nonRepudiation

keyEncipherment

dataEncipherment

keyAgreement

KeyCertSign

CRLSign

| Назначение ключа | Назначение ключа (строки битов)

1. Формирование и проверка

цифровой подписи

2. Неотказуемость

3. Шифрование других ключей

4. Шифрование и расшифрова-

ние данных и контроль цело-

стности с использованием

имитозащиты

5. Формирование других ключей

(например, по алгоритму

Диффи-Хелмана)

6. Формирование ЭЦП серти-

фикатов. Может использо-

ваться УЦ

7. Формирование ЭЦП САС.

Может использоваться УЦ

|keyUsage

EncipherOnly

DecipherOnly

| Назначение ключа | Назначение ключа (строки битов)

8. Только для шифрования

9. Только для расшифрования

|extendedKeyUsage | Расширенное назначение ключа | Задает одно или несколько назначений ключа помимо или вместо дополнения keyUsage |

|cRLDistributionPoint | Пункт распространения списков аннулированных сертификатов | Задает унифицированный идентификатор ресурса (URL) для указания местонахождения списков САС |

|privateKeyUsagePeriod | Период действия секретного ключа | Период действия секретного ключа, соответствующего открытому ключу в данном сертификате. При отсутствии этого дополнения периоды действия секретного и открытого ключей совпадают |

|certificatePolicies | Политики применения сертификат | Содержит уникальный идентификатор объекта OID, характеризующий политику применения сертификата и назначение сертификата |

|PolicyMappings

IssuerDomainPolicy

SubjectDomainPolicy

| Соответствие политик | Используется только в сертификатах УЦ. Задает один или несколько идентификаторов объекта в составе домена УЦ издателя, которые должны совпадать с политикой в составе домена УЦ субъекта |

|BasicConstraints | Основные ограничения | Указывает, действует ли субъект как УЦ, задает длину пути сертификации |

|PolicyConstraints | Ограничение политик | Используется только в сертификатах УЦ, задает проверку пути к политике, запрашивая идентификаторы политик и (или) запрещая задание соответствий политик |

|NameConstraints | Ограничения на имена | Используется только в сертификатах УЦ, задает пространство имен, которому должны принадлежать имена субъектов любого следующего сертификата в пути сертификации |

|SubjectAltName

OtherName

rfc822Name

dNSName

x400Address

directoryName

ediPartyName

uniformResource-

Identifier

iPAddress

registeredID

| Альтернативное имя субъекта | Альтернативное имя субъекта.

Свободный выбор имени.

Произвольное имя

Адрес электронной почты

Имя домена

Адрес отправителя/получателя

Имя каталога

EDI-имя

Унифицированный указатель

ресурсов WWW URL

IP-адрес

Зарегистрированный ID объекта

|issuerAltName | Альтернативное имя издателя | Альтернативное имя издателя |

|SubjectDirectory Attributes | Атрибуты каталога субъекта | Необязательные атрибуты субъекта, например, почтовый адрес, номер телефона и т.п. |

Таблица 6.1.Формат сертификата X.509

Поле Subject Public Key Information содержит информацию об открытом ключе субъекта: сам открытый ключ, необязательные параметры и идентификатор алгоритма генерации ключа. Это поле всегда должно содержать значение. Открытый ключ и необязательные параметры алгоритма используются для верификации цифровой подписи (если субъектом сертификата является УЦ) или управления ключами.

Необязательные поля Issuer Unique Identifier и Subject Unique Identifier информируют об уникальных идентификаторах субъекта и издателя сертификата и предназначены для управления многократным использованием имен субъектов и издателей. Вследствие неэффективности подобного механизма управления Интернет-стандарты профилей сертификата и списка аннулированных сертификатов не рекомендуют использовать в сертификатах эти поля.

Дополнения сертификата

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

Опциональное поле Extensions (дополнения) появляется в сертификатах третьей версии. Каждое дополнение состоит из идентификатора типа дополнения Extension identifier, признака критичности Criticality flag и собственно значения дополнения Extension value. Идентификатор типа дополнения задает формат и семантику значения дополнения. Признак критичности сообщает приложению, использующему данный сертификат, существенна ли информация о назначении сертификата и может ли приложение игнорировать данный тип дополнения. Если дополнение задано как критичное, а приложение не распознает данный тип дополнения, то сертификат не должен использоваться приложением. Приложение может игнорировать нераспознанное некритичное дополнение и использовать сертификат.

Дополнения сертификатов X.509 определены рекомендациями Х.509 версии 3 Международного Союза по телекоммуникациям и документом RFC 3280 [167]. Все эти дополнения можно разделить на две категории: ограничивающие и информационные [10]. Первые ограничивают область применения ключа, определенного сертификатом, или самого сертификата. Вторые содержат дополнительную информацию, которая может быть использована в прикладном программном обеспечении пользователем сертификата. К ограничивающим дополнениям относятся:

* основные ограничения ( Basic Constraints );

* назначение ключа ( Key Usage );

* расширенное назначение ключа ( Extended Key Usage );

* политики применения сертификата ( Certificates Policies, Policy Mappings, Policy Constraints );

* ограничения на имена ( Name Constraints ).

К информационным дополнениям относятся:

* идентификаторы ключей ( Subject Key Identifier, Authority Key Identifier );

* альтернативные имена ( Subject Alternative Name, Issuer Alternative Name );

* пункт распространения списка аннулированных сертификатов ( CRL Distribution Point, Issuing Distribution Point );

* способ доступа к информации УЦ ( Authority Access Info ).

Документ RFC 3280 Certificate & CRL Profile пока не рекомендует использовать дополнение Subject Directory Attributes, которое предназначено для доставки любых значений атрибутов каталога X.500, характеризующих субъект данного сертификата. Вместе с этим стандарт X.509 позволяет вводить любые другие дополнения, необходимость которых определяется их использованием в конкретной системе (например, в системе SET ).

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

Дополнение Key Usage (назначение ключа) отражает области применения секретного ключа, соответствующего указанному в сертификате открытому ключу. В одноименной графе (таблицы 6.1) перечислены возможные области применения ключа.

Дополнение Subject Alternative Name (альтернативное имя субъекта) позволяет расширить границы идентификации владельца сертификата при помощи альтернативных имен, таких как DNS-имена, IP-адреса, URI-адреса или адреса электронной почты Интернета. Альтернативное имя должно проверяться в соответствии с регламентом УЦ. Помимо зарегистрированных типов имен УЦ может использовать свои собственные имена, задавая их в поле Other Name. Аналогичная информация содержится и в дополнении Issuer Alternative Name, характеризующем издателя сертификата. Удостоверяющие центры могут иметь много пар ключей, и дополнение Authority Key Identifier (идентификатор ключа УЦ) помогает пользователям выбрать правильный ключ для верификации подписи на сертификате.

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

Дополнение CRL Distribution Point (пункт распространения САС) задает унифицированный идентификатор ресурса (Uniform Resource Identifier - URI) для указания местонахождения списка аннулированных сертификатов, то есть определяет пункт распространения САС.

Организации могут поддерживать широкий круг приложений, использующих PKI. Некоторые сертификаты бывают надежнее других в зависимости от процедур их выпуска или типов криптографических модулей пользователей. Различные организации (компании или правительственные агентства) используют разные политики применения сертификатов, пользователи при этом не всегда способны их различить, но при принятии решения могут ориентироваться на дополнение Certificate Policies (политики применения сертификата). Это дополнение содержит абсолютно уникальный идентификатор объекта (Object Identifier - OID), характеризующий политику применения сертификатов, в соответствии с которой был выпущен данный сертификат, и назначение сертификата. Признак критичности в поле Certificate Policies ограничивает использование сертификата одной из идентифицируемых политик - тем самым УЦ декларирует, что выпущенный им сертификат должен применяться в соответствии с положениями одной из указанных в списке политик. Это может защитить УЦ от материальных претензий доверяющей стороны, которая использовала сертификат не по тому назначению или не тем способом, которые установлены политикой применения сертификатов, указанной в сертификате.

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

Дополнение Policy Mappings (соответствие политик) используется, если субъектом сертификата является УЦ. С помощью этого дополнения можно устанавливать соответствие между политиками применения сертификатов разных удостоверяющих центров.

Пример 6.1. Пусть корпорация ACE заключает соглашение с корпорацией ABC о кросс-сертификации с целью защиты электронного обмена данными [167]. Каждая компания имеет свою политику безопасности финансовых транзакций. Очевидно, что просто генерация кросс-сертификатов не обеспечит необходимой функциональной совместимости, так как в каждой компании конфигурирование финансовых приложений и выпуск сертификатов для служащих осуществляются согласно собственной политике. Одно из возможных решений - переконфигурирование всех финансовых приложений и повторный выпуск всех сертификатов в соответствии с требованиями обеих политик. Другим, более простым решением может быть использование дополнения Policy Mappings. Если поле этого дополнения включает кросс-сертификат, выпущенный УЦ компании ACE для УЦ компании ABC, то политика безопасности финансовых транзакций компании ABC считается эквивалентной одноименной политике компании ACE.

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

В-третьих, для описания множества сертификатов на основании ограничений политик можно использовать дополнение Policy Constraints (ограничения политик). Это дополнение используется только в сертификатах УЦ и задает проверку пути к политике, запрашивая идентификаторы политик и (или) запрещая задание соответствия политик [2]. Если УЦ выдает универсально надежные сертификаты, то нет необходимости явно указывать в них политики применения сертификатов. Если же сертификаты УЦ, признанного надежным в определенном домене, используются вне этого домена, то требуется явное указание политики применения во всех сертификатах пути сертификации. При помощи дополнения Policy Constraints можно объявить неправомерным дополнение Policy Mappings в том случае, когда сертификация выходит за пределы определенного домена. Это актуально для контроля рисков, возникающих из-за "транзитивного" доверия, когда домен A доверяет домену В, домен В доверяет домену С, но домен A не желает доверять домену С. Если ограничения политики применения сертификатов установлены, то пользователи не станут иметь дело с сертификатами, в которых не указаны определенные политики или дополнение Policy Constraints вообще отсутствует.

Дополнение Certificate Policies может сопровождаться спецификатором для указания в каждом сертификате дополнительной информации, независимой от политики применения сертификатов. Стандарт X.509 жестко не регламентирует назначение и синтаксис этого поля. Типы спецификаторов политики могут быть зарегистрированы любой организацией.

Стандартно используются следующие спецификаторы политики:

* а) CPS содержит ссылку в виде уникального идентификатора ресурса на опубликованный регламент УЦ (Certification Practice Statement - CPS), в соответствии с которым выпускался данный сертификат;

* б) User Notice содержит указатель на уведомление и/или текст уведомления, которое должно появляться на экране дисплея пользователя сертификата (включая подписчиков и доверяющие стороны) до использования сертификата и информировать о политике применения данного сертификата.

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

Альтернативные форматы сертификатов

Помимо сертификатов открытых ключей формата X.509 v3 существуют сертификаты и других форматов. Остановимся на сертификатах SPKI, PGP, SET и атрибутных сертификатах.

Сертификаты SPKI

Задачей простой инфраструктуры открытых ключей SPKI (Simple Public Key Infrastructure) является распространение сертификатов для авторизации, а не для аутентификации владельцев открытых ключей. Теоретические основы и требования к SPKI разработаны рабочей группой организации IETF. Базой для SPKI стали основные идеи простой распределенной структуры безопасности - Simple Distributed Security Infrastructure (SDSI), поэтому можно говорить о единой концепции, кратко обозначаемой SPKI/SDSI. Центральными объектами SDSI являются сами ключи, а не имена. Именно ключи могут идентифицировать объекты. Сертификаты SDSI имеют удобную для восприятия форму, как правило, содержат некоторый текст свободного формата, фотографию или другую информацию.

Рабочая группа IETF SPKI разработала ряд технических и информационных документов, в том числе:

* формат сертификата;

* теорию сертификатов;

* требования;

* примеры.

Основная цель сертификата SPKI - это авторизация некоторых действий, выдача разрешений, предоставление возможностей и т.п. владельцу ключа [175]. Сертификаты SPKI часто называют сертификатами авторизации. Сертификаты авторизации, по замыслу авторов идеи SPKI, должны генерироваться любым владельцем ключа, которому разрешено предоставлять или делегировать полномочия. Владелец ключа непосредственно идентифицируется своим открытым ключом, хотя для ряда целей допускается применение некоторых других идентификаторов. Это может быть значение хэш-кода открытого ключа или некоторое имя, которое тем не менее всегда связано с ключом. В связи с тем, что сертификаты SPKI могут содержать информацию, которую владелец ключа не желает публиковать, допускается распространение сертификатов самим владельцем. Владелец ключа может использовать глобальное хранилище, например LDAP, сервер ключей PGP или систему доменных имен DNS.

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

Сертификат SPKI, как и всякий другой, имеет период действия.Проверка валидности сертификатов в простой инфраструктуре открытых ключей осуществляется при помощи списка аннулированных сертификатов (САС). Минимальный САС содержит перечень уникально идентифицированных аннулированных сертификатов, номер данного списка в последовательности публикуемых САС и подпись. Так как в SPKI явным образом не задается способ передачи САС, основным требованием является точное указание в сертификате открытого ключа информации о местонахождении САС. SPKI должна поддерживать проверку валидности сертификатов в онлайновом режиме.

Хотя SPKI-сертификаты имеют много общего с сертификатами открытых ключей X.509 (например, поля Issuer и Validity ), синтаксис и семантика этих полей неодинаковы. Кроме того, количество полей в сертификатах этих двух типов не позволяет их эквивалентно отображать друг на друга, а соглашения об именах отличаются полностью.

Работа группы IETF SPKI над документами простой инфраструктуры открытых ключей завершена, однако на практике эта работа в полном объеме не реализована. В настоящее время спрос на SPKI-сертификаты очень невелик, поэтому поставщики программных продуктов для УЦ и PKI не спешат реализовывать совершенно другой синтаксис сертификата в дополнение к сертификатам открытых ключей X.509 v3.

Сертификаты PGP

Система PGP (Pretty Good Privacy) [40] разработана американским программистом Филиппом Циммерманном для защиты секретности файлов и сообщений электронной почты в глобальных вычислительных и коммуникационных средах. Ф. Циммерманн предложил первую версию PGP в начале 1990-х годов [98]. Версия 2.x PGP была опубликована несколькими годами позже в спецификации набора стандартов IETF, названной PGP Message Exchange Formats [137]. Последняя версия PGP, получившая название Open PGP, была издана в спецификации набора стандартов IETF - Open PGP Message Format [149]. Документ, относящийся к Интернет-стандартам, объединяет PGP и MIME и называется PGP MIME Security with Pretty Good Privacy [138].

PGP представляет собой гибридную систему, комплексно использующую преимущества асимметричных и симметричных криптографических алгоритмов. С точки зрения пользователя, PGP ведет себя как система с открытым ключом. Она обеспечивает безопасный обмен сообщениями и файлами по каналам открытой связи без наличия защищенного канала для обмена ключами [218]. PGP позволяет шифровать, заверять электронной цифровой подписью, расшифровывать и проверять сообщения во время отправки и чтения электронной почты. В PGP применяются стойкие криптографические алгоритмы CAST, тройной DES и IDEA. Для выработки сеансового ключа используются алгоритмы RSA и Диффи-Хеллмана, для подписи - RSA и DSA. PGP задает форматы пакетов, позволяющие пересылать от одного субъекта к другому сообщения и файлы, а также PGP-ключи (иногда называемые PGP-сертификатами).

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

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

PGP поддерживает, в качестве частного случая своей обобщенной модели распределенного доверия, централизованный сценарий, когда сертификаты открытых ключей пользователей заверяет своей подписью лицо, пользующееся общим доверием - УЦ [218]. Любому открытому ключу, заверенному подписью УЦ, можно доверять в том смысле, что он принадлежит тому, чье имя он несет. Все пользователи должны обладать копией открытого ключа УЦ для проверки его цифровой подписи. PGP обеспечивает интегрированную поддержку распространения и поиска открытых ключей на серверах ключей. Единый УЦ особенно подходит для больших централизованно управляемых организаций, правительственных или корпоративных. Некоторые организационные среды используют иерархию удостоверяющих центров, которая лежит в основе стандартной схемы, основанной на централизованном контроле и принудительно централизованном доверии. Иерархия удостоверяющих центров обычно диктует пользователю, кому он должен доверять. Децентрализованный вероятностный метод определения валидности ключей, реализованный PGP, позволяет пользователю самостоятельно принимать решение о доверии, строя свою собственную пирамиду сертификации.

Между PGP-ключами (или сертификатами) и сертификатами открытых ключей X.509, а также между соответствующими моделями доверия имеются существенные отличия, препятствующие взаимодействию сообщества пользователей PGP с другими сообществами, которые используют сертификаты формата X.509 (например, сообществом пользователей S/MIME). Это намного серьезнее, чем проблема несовместимости протоколов, потому что непохожа и несовместима основа базовых сервисов безопасности, обеспечиваемых открытыми ключами. Возможным решением может быть адаптация сертификатов X.509 v3 в дополнение к PGP-сертификату (или вместо него). Версия Open PGP 6.5. способна поддерживать сертификаты X.509, но, позволяя пользователям Open PGP подключаться к PKI на базе X.509, она не решает проблему несовместимости основных протоколов Open PGP и S/MIME. Другим возможным решением может быть разработка продуктов, поддерживающих сертификаты и PGP и X.509 v3, но это из-за существенных различий в моделях доверия усложнит администрирование и управление.

Сертификаты SET

Протокол SET, который базируется на техническом стандарте, разработанном компаниями VISA и Master Card, обеспечивает безопасность электронных расчетов по пластиковым картам через Интернет: гарантирует конфиденциальность и целостность информации о платежах, аутентификацию счета владельца карты и дает возможность подтвердить право коммерсанта (продавца) проводить финансовые операции с финансовым учреждением [1]. В среде SET инфраструктура открытых ключей является фундаментом, на котором базируется вся система аутентификации участников расчетов.

Цифровые сертификаты, также известные как электронные мандаты или цифровые удостоверения личности, используются для связывания открытых ключей и субъектов и выпускаются доверенной третьей стороной или компанией - УЦ. Сертификаты владельцев карт выдаются только с разрешения финансового учреждения - эмитента этих карт, снабжаются его цифровой подписью и не могут быть изменены третьей стороной. Сертификаты содержат данные о номере счета и периоде действия, которые шифруются с использованием известного алгоритма шифрования с секретным ключом - Data Encryption Standard (DES). Запрашивая сертификат, владелец карты сообщает о своем намерении стать участником электронной торговли. Эти сертификаты передаются продавцам вместе с запросами о покупке и платежными инструкциями.

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

Конфиденциальность и целостность сообщений, которыми обмениваются участники системы защищенных электронных транзакций, обеспечивается механизмом двойных подписей. Содержание каждого сообщения шифруется при помощи случайно сгенерированного симметричного ключа шифрования. Этот ключ, в свою очередь, шифруется с использованием открытого ключа получателя сообщения. Созданный в результате последней операции так называемый цифровой конверт отправляется получателю вместе с зашифрованным сообщением. После получения цифрового конверта получатель расшифровывает его при помощи своего секретного ключа, чтобы получить случайно сгенерированный симметричный ключ для расшифровки исходного сообщения отправителя. Протокол SET предоставляет участникам сервис аутентификации на базе сертификатов формата X.509 и имеет средства аннулирования, реализованные с помощью списка аннулированных сертификатов. Спецификации SET [113], [114] и [115] задают стандарт поддержки платежей по кредитным картам в распределенных сетях. SET адаптирует формат сертификата открытого ключа X.509 и задает свои собственные специфические дополнения, которые поддерживаются только в SET-совместимых системах [44]. SET также предъявляет определенные требования профиля к стандартным дополнениям. Ниже иллюстрируется структуру сертификата SET.

|Версия |

|Серийный номер |

|Идентификатор алгоритма подписи |

|Имя издателя |

|Период действия (не ранее/не позднее) |

|Имя субъекта |

|ИНформация об открытом ключе субъекта |

|Уникальный идентификатор издателя |

|Уникальный идентификатор субъекта |

|Дополнения |

Структура сертификата SET

|Стандартные дополнения | Специфические SET-дополнения |

|Идентификатор ключа УЦ | Тип сертификата |

|Назначение ключа | Данные продавца |

|.... | Сертификат карты |

|Туннелирование |

|Спецификатор SET |

Отметим, что на вышеуказанной схеме представлены не все возможные дополнения. Поскольку не-SET-приложения не понимают частные дополнения, задаваемые SET, нельзя ожидать, что не-SET-приложение (например, электронная почта на базе S/MIME) примет к использованию сертификат SET. Это действительно так, хотя формат сертификата SET согласуется с форматом сертификата X.509 v3. Дополнение Тип сертификата является критическим, следовательно, не-SET-приложение должно отвергать SET -сертификат. Пометка определенных дополнений как критических является общепринятой практикой для того, чтобы определенный тип сертификата мог использоваться только в контексте данного приложения. Этот пример характеризует ситуацию, когда конечному пользователю требуется несколько сертификатов.

Атрибутные сертификаты

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

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

Атрибутный сертификат X.509 связывает атрибуты прав доступа с владельцем сертификата и предназначен для использования в Интернет приложениях [84]. Поскольку атрибутный сертификат не содержит открытого ключа, то его используют вместе с сертификатом открытого ключа. Аутентификация субъекта осуществляется при помощи сертификата открытого ключа, а связывание атрибутов с данным субъектом - посредством атрибутного сертификата.

Атрибутные сертификаты могут применяться в сервисах аутентификации источника данных и неотказуемости. В этом случае в сертификаты включают дополнительную информацию о субъекте, который ставит цифровую подпись. Эта информация позволяет удостовериться, что субъект имеет право подписывать данные. Род проверки зависит от содержания данных, которыми обмениваются стороны или которые должны быть заверены цифровой подписью.

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

|Версия (v.1 или v.2) |

|Владелец сертификата |

|Имя издателя |

|Идентификатор алгоритма подписи |

|Серийный номер |

|Период действия (не ранее/не позднее) |

|Атрибуты |

|Уникальный идентификатор издателя |

|Дополнения |

Структура атрибутного сертификата

Атрибуты описывают информацию о полномочиях владельца атрибутного сертификата. Как и сертификат открытого ключа подписи, атрибутный сертификат может содержать дополнения. Наряду с имеющимися в системе сервисами аутентификации, атрибутные сертификаты обеспечивают защищенную передачу информации о полномочиях их владельцев [2]. Эту технологию могут применять, например, приложения удаленного доступа к сетевым ресурсам (таким, как web-серверы и базы данных), а также приложения, которые управляют физическим доступом в помещения и к аппаратному обеспечению.

Лекция 7. Классификация сертификатов и управление ими

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

Классы сертификатов

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

Можно выделить три класса сертификатов открытых ключей:

* сертификаты конечных субъектов;

* сертификаты удостоверяющих центров;

* самоподписанные сертификаты.

Внутри каждого класса существует несколько типов сертификатов, все они представлены на рис. 7.1. Рассмотрим их последовательно.

Рис. 7.1. Классификация сертификатов открытых ключей

Сертификаты конечных субъектов

Эти сертификаты выпускаются для субъектов, не являющихся удостоверяющими центрами, и содержат открытые ключи, при помощи которых пользователи сертификатов могут верифицировать цифровые подписи и управлять ключами. Сертификаты должны предоставлять пользователям информацию о назначении открытых ключей, достаточную для принятия решения о пригодности данного ключа для конкретного приложения. Субъектом сертификатов этого класса может быть человек или система (например, web-сервер или маршрутизатор). Рекомендуемые профили сертификатов варьируются в зависимости от типа субъекта [70].

Сертификаты пользователей

Для поддержки онлайновых приложений и защищенной электронной почты в профиль сертификата пользователя включается информация об именах. В содержании сертификата пользователя рекомендуется:

1 использовать в качестве имени субъекта отличительное имя (отличительное имя стандарта X.500 или DNS-имя);

2 устанавливать срок действия сертификата не более 3 лет, начиная с момента его выпуска (в противном случае чрезмерно разрастаются списки САС);

3 задавать дополнение Key Usage (назначение ключа) как критичное. В нем должно указываться: для открытых ключей подписи - их назначение: цифровая подпись или поддержка неотказуемости; для открытых ключей, связанных с алгоритмами Диффи-Хэллмана, эллиптических кривых Диффи-Хэллмана и обмена ключами, - согласование ключей; для RSA-ключей транспортировки ключей - шифрование ключей;

4 задавать дополнение Certificate Policies (политики применения сертификатов) как некритичное; дополнение должно определять одну политику и не содержать никаких спецификаторов политики;

5 задавать дополнение Subject Alternative Name (альтернативное имя субъекта) как некритичное; для приложений защищенной электронной почты S/MIME v3 в качестве альтернативного имени в дополнении должен указываться адрес электронной почты.

В соответствии с требованиями конкретной локальной среды в сертификате могут содержаться и другие дополнения, которые должны быть помечены как некритичные.

Сертификаты систем

К сертификатам систем можно отнести, например, VPN-сертификаты, сертификаты устройств (в том числе и беспроводной связи) и SSL-сертификаты [105].

VPN-сертификаты (IPsec). Эти сертификаты генерируются на основе информации об устройстве (например, IP-адреса) и подписываются человеком от имени устройства (путем ручной или автоматизированной процедуры).

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

Сертификаты устройств беспроводной связи. Эти сертификаты предназначены для поддержки функциональности SSL-типа применительно к небольшим устройствам и процессорам. В качестве примера можно привести краткосрочные сертификаты WTLS (Wireless Transport Layer Security). На базе основного SSL-сертификата программной системой промежуточного слоя выпускаются временные сертификаты для конечных устройств. Когда основной сертификат аннулируется или заканчивается его срок действия, ПО промежуточного слоя приостанавливает выпуск следующих сертификатов.

SSL-сертификаты. Эти сертификаты генерируются Web-сервером и используются для связывания адреса и программного обеспечения определенного Web-сервера. Сертификаты не только обеспечивают SSL-туннель к обращающемуся с запросом браузеру клиента, но и позволяют определять, принадлежит ли данный унифицированный указатель ресурсов (URL) той организации, которая предъявляет этот URL хосту. Недавно появилась возможность реализовать концепцию "распределенных сертификатов", согласно которой один SSL-сертификат может распределяться между несколькими машинами Web-сервера.

Для поддержки онлайновых приложений в профиль сертификата компьютерной системы включается информация об именах. К содержанию сертификата системы предъявляются те же требования, что и к содержанию сертификата пользователя, за исключением того, что дополнение Subject Alternative Name в качестве альтернативного имени должно задавать DNS-имя компьютера ( dNSname ) или IP-адрес ( iPAddress ), если система является маршрутизатором. Кроме этого, дополнение Extended Key Usage (расширенное назначение ключа) должно задаваться как некритичное, если система является web-сервером, поддерживающим протоколы SSL или TLS, или маршрутизатором, поддерживающим протокол IPsec.

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

Сертификаты удостоверяющих центров

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

Сертификаты удостоверяющих центров корпоративной PKI

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

1 использовать в качестве имени субъекта отличительное имя (отличительное имя стандарта X.500 или DNS-имя); имя субъекта должно быть образовано только из рекомендуемых атрибутов имен каталогов, а любая часть имени субъекта, совпадающая с именем издателя, должна быть задана тем же типом строки;

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

3 не использовать открытые ключи, связанные с алгоритмами Диффи-Хэллмана, эллиптических кривых Диффи-Хэллмана и обмена ключами; если используется RSA-ключ, то в качестве его назначения не должна указываться транспортировка ключей;

4 задавать дополнение Basic Constraints (основные ограничения) как критичное; устанавливать параметр cA в значение TRUE ; если корпоративная PKI является иерархической, то указывать значение длины пути;

5 задавать дополнение Key Usage (назначение ключа) как критичное, указывать значения: подписание сертификата открытого ключа и подписание САС;

6 задавать дополнение Certificate Policies (политики применения сертификатов) как некритичное; в нем должны быть перечислены все политики, которые УЦ субъекта может включать в подчиненные сертификаты; перечисленные политики не должны содержать никаких спецификаторов;

7 задавать дополнение Subject Key Identifier (идентификатор ключа субъекта) как некритичное; его значение должно сравниваться со значением дополнения Authority Key Identifier (идентификатор ключа УЦ) в сертификатах, изданных УЦ субъекта;

8 задавать дополнение Subject Information Access (доступ к информации о субъекте) как некритичное и указывать репозиторий, который содержит сертификаты, изданные субъектом.

В соответствии с требованиями конкретной локальной среды сертификат может содержать и другие дополнения, они должны быть помечены как некритичные.

Сертификаты удостоверяющих центров в среде нескольких корпоративных PKI

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

К содержанию сертификата УЦ, используемого в среде нескольких корпоративных PKI, предъявляются практически те же требования, что и к содержанию сертификата УЦ корпоративной PKI, за исключением двух пунктов, касающихся соответствия политик и ограничений на имена [70]. В сертификате УЦ, который участвует во взаимодействии между разными корпоративными PKI, необходимо:

1 задавать дополнение Policy Mappings (соответствие политик) как некритичное и устанавливать в нем только соответствие политик издателя, которые указаны в дополнении Certificate Policies ;

2 задавать дополнение Name constraints (ограничения на имена) как критичное. Исключать поддеревья в иерархии отличительных имен, соответствующие локальному пространству имен каждой PKI. Это позволяет субъекту одной PKI не принимать сертификаты другой PKI, которые содержат локальные имена.

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

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

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

Самоподписанные сертификаты

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

Сертификаты установления пункта доверия

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

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

Сертификаты обновления ключа

Чтобы ввести в действие новый сертификат или ключ подписи САС, УЦ выпускает пару сертификатов обновления ключа. Первый сертификат содержит старый открытый ключ и подписывается новым секретным ключом. Второй сертификат содержит новый открытый ключ и подписывается старым секретным ключом. Таким образом, пользователи сертификатов, подписанных старым секретным ключом, и пользователи сертификатов, подписанных новым секретным ключом, могут проверять валидность сертификатов друг друга. В обоих сертификатах обновления имена издателя и субъекта совпадают, оба сертификата принадлежат УЦ одной и той же корпоративной PKI. Таблица 7.1 иллюстрирует некоторые отличия профилей этих сертификатов от нормального профиля сертификата УЦ [128].

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

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

Сертификаты обновления политики

УЦ выпускает сертификаты обновления политики, чтобы изменить домен политики. Предположим, что УЦ выпускает сертификаты в соответствии с политиками I и II. В связи с изменениями внутри организации планируется выпускать новые сертификаты в соответствии с политиками III, IV и V. При переходе к новым политикам УЦ желает гарантировать непрерывность работы своих пользователей. Даже если бы УЦ мог моментально выпустить новые сертификаты для всех пользователей, в том числе и внешних, то пользователям пришлось бы заняться переконфигурированием своих приложений, что помешало бы их работе. Поэтому при изменении политик выпускается пара сертификатов обновления политики. В данном примере первый сертификат задает политики I и II, устанавливая их соответствие политикам III, IV и V, а второй сертификат задает политики III, IV и V, устанавливая их соответствие политикам I и II.

|Содержание сертификата | Старый сертификат, подписанный новым ключом | Новый сертификат, подписанный старым ключом |

|Срок действия ключа | Начинается с выпуска сертификата и заканчивается после того, как истечет срок действия сертификатов, подписанных ранее старым секретным ключом | Начинается с выпуска сертификата и заканчивается после того, как истечет срок действия сертификатов, подписанных ранее старым секретным ключом |

|Открытый ключ субъекта | Старый ключ подписи | Новый ключ подписи |

|Дополнение Basi Constraints | Задается как некритичное; параметр cA принимает значение TRUE, но значение длины пути не указывается | Задается как некритичное; параметр cA принимает значение TRUE, но значение длины пути не указывается |

|Дополнение Authority Key Identifier | Задается как некритичное и относится к новому открытому ключу | Задается как некритичное и относится к старому открытому ключу |

|Дополнение Subject Key Identifier | Задается как некритичное и соответствует дополнению Authority Key Identifier в сертификатах, подписанных старым секретным ключом | Задается как некритичное и соответствует дополнению Authority Key Identifier в сертификатах, подписанных новым секретным ключом |

|Цифровая подпись | Генерируется при помощи нового секретного ключа | Генерируется при помощи старого секретного ключа |

Таблица 7.1.Особенности профилей старого и нового сертификатов обновления ключа

Обновление политик часто происходит вместе с обновлением ключа. Профиль сертификата обновления политики в целом совпадает с профилем сертификата, но имеет некоторые особенности [70].

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

* дополнение Certificate Policies (политики применения сертификатов) задается как некритичное; в нем указываются все новые политики, которые УЦ устанавливает в сертификатах, подписываемых новым секретным ключом; эти политики не имеют спецификаторов;

* дополнение Policy Mappings (соответствие политик) задается как некритичное; оно определяет новые политики как политики домена издателя и устанавливает их соответствие старым политикам, заданным как политики домена субъекта.

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

* дополнение Certificate Policies (политики применения сертификатов) задается как некритичное; в нем указываются все старые политики, которые были установлены в сертификатах, подписанных старым секретным ключом; эти политики не имеют спецификаторов;

* дополнение Policy Mappings (соответствие политик) задается как некритичное; оно определяет старые политики как политики домена издателя и устанавливает их соответствие новым политикам, заданным как политики домена субъекта.

Использование субъектом нескольких сертификатов

Пары ключей одного субъекта

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

Рис. 7.2. Применение пользователем нескольких пар ключей

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

Итак, пара ключей должна быть связана с разными ролями или действиями субъекта. Однако бывают случаи, когда пара ключей имеет вполне определенное назначение. Например, пара ключей из алгоритма цифровой подписи Digital Signature Algorithm (DSA) не может использоваться для шифрования и расшифрования, пара ключей Диффи-Хэллмана не может использоваться для подписания данных и верификации подписи. Более того, даже пара ключей RSA, которая, в принципе, может применяться для аутентификации, целостности, конфиденциальности или обмена ключами, на практике должна иметь только одно назначение, разрешенное политикой или вариантом реализации PKI.

Сфера применения пары ключей может быть разной даже в рамках одного назначения [44]. Так, например, во многих средах важно различать, с какой целью субъект PKI подписывает данные: для своей аутентификации или с намерением заверить содержание документа. Иногда бывает необходимо не просто задать назначение пары ключей, но и конкретизировать тип и категорию назначения. Например, пара ключей может быть создана только для авторизации платежей, более того, сумма платежей может быть также ограничена, в этом случае все заверенные данным ключом транзакции на сумму, превышающую заданный лимит, будут отвергнуты.

Таким образом, пара ключей может быть связана с определенной политикой, которая ограничивает ее:

* определенным качественным или количественным признаком назначения (например, транзакции на сумму не выше заданного значения);

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

Кроме того, назначение пары ключей может зависеть от типа приложения или протокола обмена. Например, пара ключей может использоваться для аутентификации субъекта по протоколу Internet Protocol Security (IPsec), а не по протоколу Secure Sockets Layer (SSL).

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

Взаимосвязи сертификатов и пар ключей

Если субъект PKI имеет много пар ключей, то должен иметь и много сертификатов, поскольку формат сертификата стандарта X.509 не позволяет ему указывать в поле Subject Public Key Info (информация об открытом ключе субъекта) несколько ключей. Это, однако, не исключает возможности появления определенного открытого ключа в нескольких сертификатах, которые одновременно являются валидными. Проанализируем взаимосвязи между парами ключей и сертификатами [43].

Чаще всего достоинством применения одного и того же открытого ключа в нескольких валидных сертификатах считается простота обновления сертификата. Это означает, что если пара ключей не была скомпрометирована и секретный ключ имеет достаточную для безопасности длину, то, как только истекает срок действия данного сертификата, открытый ключ должен размещаться в новом сертификате с новым сроком действия. Обновление сертификата продлевает жизнь пары ключей и не требует от доверяющих сторон обновлять свои знания об открытом ключе субъекта. Кроме того, от самого субъекта не требуется менять ключ, который он использует, и, следовательно, поддерживать историю ключей.

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

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

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

Управление несколькими парами ключей

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

Однако в большинстве случаев выбор ключа выполняется автоматически и прозрачно для пользователя. Если устанавливается сеанс связи по протоколу SSL, то клиентское ПО осуществляет поиск сертификата пользователя, в котором дополнение Key Usage (назначение ключа) содержит значение SSL, а затем использует соответствующий секретный ключ для аутентификации пользователя. Со временем ПО PKI станет более совершенным, и выбор ключей в основном будет прозрачным.

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

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

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

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

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

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

Такие взаимоисключающие друг друга требования диктуют необходимость субъекту корпоративной PKI иметь, по крайней мере, две разные пары ключей (и связанных с ними сертификатов). Это установлено рядом требований и профилей в стандартах PKI (например, RFC 3280). В некоторых средах, например, в инфраструктуре ИТ-безопасности шведской некоммерческой организации Secure Electronic Information in Society, уже управляют тремя парами ключей: шифрования/расшифрования, подписи/верификации общего назначения и подписи/верификации для поддержки неотказуемости [68].

Жизненный цикл сертификатов и ключей

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

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

Рис. 7.3. Жизненный цикл сертификата

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

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

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

Большинство персональных сертификатов действуют в течение одного-двух лет после выпуска, а сертификаты серверов обычно сохраняют свою силу два года и более. Для целей архивирования и долговременного шифрования используются специальные сертификаты с длительным периодом действия.

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

1 аннулирования сертификата при увольнении служащего, владеющего этим сертификатом;

2 аннулирования сертификата при утере служащим своего секретного ключа или пароля доступа к секретному ключу;

3 приостановления действия сертификата, выпущенного для служащего, который в данный момент времени увольняется или находится под следствием;

4 возобновления сертификата служащего при отказе от увольнения или после прояснения обстоятельств судебного дела и т.п.

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

Примерные сценарии управления жизненным циклом сертификатов и ключей

Рассмотрим возможные сценарии управления жизненным циклом сертификатов и ключей PKI, предполагая, что политикой применения сертификатов установлен срок действия сертификата открытого ключа - 1 год, секретного ключа - 10 лет, цифровой подписи - 25 лет с момента подписания электронного документа [80].

Пример 7.1. Пусть секретный ключ используется для подписания деловых контрактов. Так как срок действия секретного ключа - 10 лет и ключ был создан в начале 2000 года, то он должен храниться до начала 2010 года. На рис. 7.4 символом Х в середине 2001 года помечен момент подписания контракта, который будет действовать до середины 2026 года. Цифровая подпись этого документа остается действительной по истечении срока действия секретного ключа, который использовался для создания этой подписи, поэтому открытый ключ должен храниться дольше секретного, так как он будет использоваться для верификации цифровой подписи и после окончания действия секретного ключа. Действительно, вполне вероятно, что другой электронный документ будет подписан в конце 2009 года непосредственно перед тем, как истечет срок действия секретного ключа, следовательно, открытый ключ должен храниться, по крайней мере, до 2035 года, потому что он может потребоваться для верификации цифровой подписи спустя 25 лет после подписания документа.

Рис. 7.4. Сценарий использования секретного ключа для подписания деловых контрактов

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

Пример 7.2. Рассмотрим более сложный случай: компрометацию секретного ключа подписи. На рис. 7.5 момент компрометации помечен символом Х в начале 2002 года. После обнаружения компрометации секретного ключа УЦ вносит сертификат соответствующего открытого ключа в список аннулированных сертификатов.

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

Рис. 7.5. Сценарий компрометации секретного ключа подписи

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

Лекция 8. Формат списков аннулированных сертификатов

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

Списки аннулированных сертификатов

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

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

Статус сертификата на предмет аннулирования должен проверяться перед каждым его использованием. Поэтому PKI должна поддерживать масштабируемую систему аннулирования сертификатов. Удостоверяющий центр должен иметь возможность безопасно публиковать информацию о статусе каждого сертификата данного PKI-домена. Клиентское программное обеспечение перед использованием любого сертификата должно проверять эту информацию от имени пользователя. Существуют три способа проверки статуса сертификата [80].

1 Способ извлечения ("pull") или проверки с опросом наличия изменений. Этот способ заключается в том, что клиентское приложение периодически выполняет поиск в репозитории последней версии САС и использует ее для проверки статуса сертификата. Приложение выполняет "вытягивание" списка аннулированных сертификатов при каждом запланированном обновлении списка.

2 Способ проталкивания ("push") или принудительной рассылки изменений, при котором удостоверяющий центр рассылает приложениям, использующим сертификаты, новый САС всякий раз, когда какой-либо сертификат аннулируется.

3 Способ онлайновой верификации или использования онлайнового протокола статуса сертификата ( Online Certificate Status Protocol - OCSP ). Сервер удостоверяющего центра, известный как OCSP-респондер, в режиме реального времени обрабатывает запросы приложений о статусе сертификатов и предоставляет заверенные цифровой подписью ответы о текущем состоянии каждого сертификата. Ответ содержит информацию об идентификаторе сертификата, его статусе (нормальный, аннулированный, неизвестный), периоде действия, а при необходимости - о времени и причине аннулирования [2].

К механизмам периодической публикации информации об аннулированных сертификатах относятся:

* полные списки САС ;

* списки аннулирования сертификатов удостоверяющих центров ( САС УЦ);

* списки аннулирования сертификатов конечных субъектов ( САС КС);

* пункты распространения САС (также известные как частичные списки САС );

* дельта-списки и косвенные дельта-списки САС ;

* косвенные списки САС ;

* переадресующие списки САС ;

* деревья аннулирования сертификатов.

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

Формат списка аннулированных сертификатов

Формат списка аннулированных сертификатов определен в рекомендациях Международного Союза по телекоммуникациям ITU (X.509) и документах PKIX [167]. Существуют две различные версии САС, первая версия описывалась в первых спецификациях X.509. Сейчас списки САС первой версии не используются, поскольку они не позволяют решать проблемы масштабируемости и добавлять необходимые функции, а также не способны противостоять атакам подмены. В настоящее время общепринята вторая версия списков САС (см. табл. 8.1), в которой перечисленные проблемы решены при помощи дополнений.

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

Список аннулированных сертификатов (Certificate Revocation List - CRL) представляет собой структурированную двоичную запись в формате абстрактной синтаксической нотации ASN.1. Структура, располагающаяся в верхней части САС, подобна конверту для содержания списка и состоит из трех полей:

1 первое поле tbs Cert List - это заверенное цифровой подписью содержание списка аннулированных сертификатов, который должен быть подписан (tbs - сокращение от английского выражения "to-be-signed", означающего "быть подписанным");

2 второе поле Signature Algorithm содержит идентификатор алгоритма цифровой подписи, который применил издатель САС для подписания этого списка. Идентификатор алгоритма задается при помощи соответствующего идентификатора объекта (OID). Значение поля должно совпадать со значением идентификатора алгоритма, указываемого в соответствующем поле САС ;

3 третье поле Signature Value содержит значение цифровой подписи, вычисленной на основе содержания САС ; значение подписи - это строка битов в формате ASN.1.

После этой структуры следует непосредственно содержание списка, который подписывается. САС состоит из набора обязательных полей и нескольких опциональных дополнений. В содержании всегда указывается идентификатор алгоритма цифровой подписи, имя издателя и дата выпуска САС. В соответствии со стандартом RFC 3280 [167] рекомендуется включать дату выпуска нового САС, несмотря на то, что поле Next Update (следующее обновление) считается необязательным, а использование этого поля значительно усложняет валидацию сертификата.

Если аннулированных сертификатов нет, часть структуры списка, описывающая аннулированные сертификаты, отсутствует. Если аннулированные сертификаты имеются, то каждый из них, представляющий собой вход в САС, задается структурой, которая состоит из серийного номера сертификата, даты аннулирования и необязательных дополнений точек входа в САС. Дополнения точек входа в САС ( CRL Entry Extensions ) описывают данные одного аннулированного сертификата, помимо которых в состав содержания САС входят дополнения САС ( CRL Extensions ), характеризующие весь список аннулированных сертификатов в целом. Структура САС X.509 v2 приведена в табл. 8.1.

|Поле | Содержание |

|Version | Версия (1 означает v2) |

|signature | Идентификатор алгоритма цифровой подписи |

|issuer | Уникальное имя издателя САС (УЦ) |

|thisUpdate | Дата выпуска текущего САС |

|nextUpdate | Планируемая дата выпуска следующего САС |

|revokedCertificates

user Certificate

revocation Date

cRLEntryExtensions

| Перечень аннулированных сертификатов.

Для каждого сертификата указываются:

1) серийный номер;

2) дата аннулирования;

3) дополнения точки входа в САС

|cRLExtensions | Дополнительная информация, характеризующая САС в целом |

|signatureAlgorithm | Идентификатор алгоритма цифровой подписи |

|signatureValue | Значение цифровой подписи (строка битов) |

Таблица 8.1.Структура списка аннулированных сертификатов X.509 v2

Необязательное поле Version при помощи номера версии задает синтаксис САС, это поле заполняется только в списке второй версии, поскольку в формате САС первой версии оно не представлено.

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

Обязательное поле Issuer содержит отличительное имя издателя САС (в соответствии со стандартом X.500). Документ RFC 3280 [167] требует, чтобы это поле не было пустым, в нем указываются идентификационные признаки УЦ. Если УЦ делегирует некоторые или все функции по поддержке САС другому центру, то включает в выпускаемые сертификаты дополнение CRL Distribution Point. Issuer.

Поле This Update указывает дату выпуска текущего САС. Дата может быть представлена в одном из двух возможных форматов: в обобщенном формате времени или в формате скоординированного универсального времени UTC (Universal Coordinated Time). Издатель САС должен использовать формат UTC для дат до 2049 года включительно и обобщенный формат времени для дат после 2050 года.

Поле Next Update отображает дату выпуска следующего САС. Здесь также поддерживаются два формата времени. Следующий САС необходимо выпустить не позднее указанной даты. Издатель САС должен включать это поле в состав содержания САС, хотя формально оно не является обязательным.

Поле Revoked Certificates содержит перечень аннулированных сертификатов. Эта структура необязательна, но может отсутствовать только тогда, когда отсутствуют аннулированные сертификаты, срок действия которых не истек. В поле указываются:

* серийные номера аннулированных сертификатов user Certificate ;

* их даты аннулирования Revocation Date (в одном из двух форматов времени);

* необязательные дополнения точек входа в САС CRL Entry Extensions.

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

Поле CRL Extensions используется для включения дополнительной информации, характеризующей САС в целом.

Дополнения САС

Стандарт X.509 версии 1997 года [77] ввел в САС несколько дополнений - CRL Extensions. Каждое дополнение САС может быть помечено как критичное или некритичное. Валидация САС становится невозможной, если обнаруживается нераспознанное критичное дополнение. Однако такое дополнение может быть проигнорировано. Формат САС X.509 v2 допускает задание частных дополнений, позволяющих указывать специфическую для данного PKI-сообщества информацию. Версия 2000 года стандарта X.509 ввела важные изменения в формат САС по сравнению с версией 1997 года [78]. Стандартные дополнения САС приведены в табл. 8.2.

|Поле | Содержание |

authorityKeyIdentifier

keyIdentifier

authorityCertIssuer

authorityCertSerialNumber

Идентификатор открытого ключа

издателя САС

значение дополнения Subject Key Identifier

из сертификата издателя САС

основное или альтернативное имя

издателя САС

серийный номер сертификата издателя САС

|issuerAlternativeName | Альтернативные имена издателя САС |

|cRLNumber | Последовательность номеров всех списков САС, выпущенных данным издателем |

|cRLScope | Тип САС по признаку разбиения или области охвата |

|statusReferrals | Используется для динамического разбиения списков САС |

|cRLStreamIdentifier | Используется для идентификации контекста, внутри которого номер САС является уникальным |

|orderedList | Характеризует упорядоченность САС по возрастанию серийных номеров или дат аннулирования |

|deltaInformation | Информация о местонахождении дельта-списка САС и времени выпуска следующего дельта-списка |

issuingDistributionPoi

distributionPoint

onlyContainsUserCerts

onlyContainsCACerts

onlySomeResons

indirectCRL

Атрибуты выпускающего пункта

распространения САС

названия пунктов распространения САС

тип сертификатов (только сертификаты

конечных пользователей)

тип сертификатов (только сертификаты УЦ)

информация об аннулировании

сертификатов по заданным причинам

информация о косвенном САС

|deltaCRLIndicator | Индикатор САС как дельта-списка |

|baseUpdate | Дата/время обновления информации об аннулировании при помощи дельта-списка САС |

|freshest CRL | Указатель на самый последний, "свежий" дельта-список САС |

Таблица 8.2.Дополнения списка аннулированных сертификатов X.509 v2

Дополнение Authority Key Identifier (идентификатор ключа издателя САС ) идентифицирует открытый ключ, необходимый для валидации цифровой подписи, которой заверен САС. Идентификация может базироваться либо на идентификаторе ключа (из дополнения Subject Key Identifier сертификата издателя САС ), либо на имени издателя САС и серийном номере его сертификата. В этом дополнении используются следующие поля:

* необязательное поле key Identifier, которое содержит значение дополнения Subject Key Identifier из сертификата издателя САС ; его рекомендуется включать;

* необязательное поле authority Cert Issuer, в котором указывается основное или альтернативное имя издателя САС ; в нем могут указываться несколько имен. Если это поле присутствует, то должно быть заполнено и следующее поле authority Cert Serial Number ;

* необязательное поле authority Cert Serial Number, которое задает серийный номер сертификата издателя САС. Если это поле присутствует, то должно быть заполнено и предыдущее поле authority Cert Issuer.

Дополнение Authority Key Identifier помогает пользователям выбрать правильный открытый ключ для верификации подписи на данном САС в том случае, когда издатель САС имеет несколько ключей подписи и соответственно несколько сертификатов. При смене ключа подписи издателя САС происходит некоторое перекрытие периодов действия двух ключей, в этот интервал времени валидными считаются оба сертификата с одним и тем же именем издателя и разными открытыми ключами подписи. В соответствии с рекомендациями X.509 это дополнение всегда помечается как некритичное, его использование регламентируется документом RFC 3280 [167].

Дополнение Issuer Alternative Name позволяет указывать альтернативные имена издателя САС: адрес электронной почты, DNS-имя (имя Интернет-хоста), IP-адрес и унифицированный идентификатор ресурса URI (обычно уникальный адрес ресурса WWW URL). Включение этих имен не обязательно. Формально это дополнение может быть как критичным, так и некритичным. Но поскольку документ RFC 3280 требует, чтобы поле с именем издателя САС не было пустым, необходимо, чтобы это дополнение было помечено как некритичное.

Дополнение CRL Number выполняет функцию счетчика и содержит упорядоченную по возрастанию последовательность номеров всех списков САС, выпущенных данным издателем. Дополнение позволяет пользователям определять, когда происходит смена одного списка данного издателя другим, более свежим САС. В соответствии с рекомендациями X.509 это дополнение всегда помечается как некритичное. Документ RFC 3280 требует от издателей включения этого дополнения во все списки САС.

Дополнение CRL Scope формально стандартизовано версией 2000 года рекомендаций X.509 и обеспечивает гибкость классификации информации списков САС по разным признакам. Списки САС могут быть разбиты на множества различными способами: по типам сертификатов, кодам причин аннулирования, серийным номерам, идентификаторам ключей субъектов и поддеревьям имен. Это дополнение всегда помечается как критичное.

Дополнение Status Referrals формально стандартизовано версией 2000 года рекомендаций X.509 и обеспечивает две основные функции: во-первых, дает возможность динамически разбивать информацию об аннулировании (поскольку включает в свой синтаксис дополнение CRL Scope ); во-вторых, позволяет удостоверяющим центрам публиковать перечень текущих списков САС. Перечень помогает доверяющей стороне анализировать, владеет ли она последней информацией об аннулировании, и избегать лишней (без необходимости) пересылки списков САС. В этом дополнении также может публиковаться информация нового САС, прежде чем произойдет обновление более старого, но не просроченного списка. Это дополнение всегда помечается как критичное.

Дополнение CRL Stream Identifier формально стандартизовано версией 2000 года рекомендаций X.509 и используется для идентификации контекста, внутри которого номер САС является уникальным. Если каждому пункту распространения САС присваивается уникальный идентификатор, то его комбинация с номером САС позволяет, независимо от типа списка, уникально идентифицировать каждый САС, выпущенный данным УЦ. Это дополнение всегда помечается как некритичное.

Дополнение Ordered List формально стандартизовано версией 2000 года рекомендаций X.509 и характеризует упорядоченность САС по возрастанию серийных номеров или дат аннулирования. Если дополнение отсутствует, то порядок по умолчанию считается заданным локальной политикой УЦ. Это дополнение всегда помечается как некритичное.

Дополнение Delta Information формально стандартизовано версией 2000 года рекомендаций X.509 и указывает местонахождение дельта-списка САС и время выпуска следующего дельта-списка (последний атрибут необязателен). Это дополнение всегда помечается как некритичное.

Дополнение Issuing Distribution Point используется вместе с дополнением сертификата CRL Distribution Point и отражает названия пунктов распространения САС и типы сертификатов, содержащихся в списке (например, сертификаты только конечных пользователей, сертификаты только удостоверяющих центров и/или сертификаты, аннулированные по определенной причине ). Когда разрешено, дополнение указывает, что САС является косвенным списком. Один издатель САС может поддерживать несколько пунктов распространения САС. В качестве указателя пункта распространения САС могут использоваться доменные имена, IP-адреса или имена файлов на web-сервере.

Коды причины, относящиеся к пункту распространения САС, задаются в поле Only Some Reasons. Если это поле не используется, то пункт распространения САС содержит информацию об аннулировании сертификатов по всем причинам. Издатели САС могут использовать пункты распространения САС, чтобы различать списки, сформированные по причине компрометации ключа и по другим причинам. В этом случае один пункт распространения предназначается для информирования об аннулировании сертификатов с кодами причины аннулирования "компрометация ключа" или "компрометация УЦ", а другой пункт распространения - для случаев аннулирования по другим причинам.

При хранении САС в каталоге должна быть указана точка входа в каталог, соответствующая данному пункту распространения (она не всегда совпадает с точкой входа в каталог УЦ). Дополнение Issuing Distribution Point всегда помечается как критичное. Признак критичности гарантирует, что в процессе валидации вместо полного списка не будет случайно использован неполный САС. Если при валидации сертификата это дополнение не распознается, то дельта-список САС должен быть отвергнут.

Дополнение Delta CRL Indicator идентифицирует САС как дельта-список. Дельта-список САС фиксирует изменения с момента выпуска предыдущего САС. Вообще говоря, САС должен содержать все аннулированные сертификаты - такой список известен как базовый САС. Однако УЦ может формировать и дельта- списки аннулированных сертификатов. Базовый и дельта-список вместе содержат всю информацию об аннулировании сертификатов данного домена, известную на момент выпуска дельта-списка. Области охвата дельта-списка и базового списка должны совпадать.

Дельта- списки аннулированных сертификатов значительно быстрее обрабатываются приложениями, которые хранят информацию об аннулировании сертификатов в формате, отличном от структуры САС. Это позволяет приложениям вносить в локальные базы данных информацию об изменении списка, не затрагивая данные первоначально загруженного основного САС. Пока не все приложения, использующие сертификаты, управляют дельта-списками САС, хотя рекомендуется, чтобы издатели САС поддерживали оба списка, причем дополнение CRL Number в обоих списках должно иметь одно и то же значение (это подтверждает, что в них содержится одинаковая информация об аннулировании) [70].

Пользователь сертификата при помощи дельта-списков может в любой момент сформировать полный САС для конкретного домена одним из следующих способов:

1 найти текущий дельта-список САС для данного домена и скомбинировать его с изданным ранее базовым САС ;

2 найти текущий дельта-список САС для данного домена и скомбинировать его с локально сконструированным САС, содержание которого эквивалентно изданному ранее базовому САС.

Содержание сформированного списка не зависит от способа формирования. Чтобы гарантировать, что этот САС является полным, необходимо сравнить номера базового САС и базового списка, на который ссылается дельта-список САС.

Дополнение Delta CRL Indicator всегда является критичным. Поскольку дельта-список не содержит полный перечень всех аннулированных сертификатов, срок действия которых не истек, признак критичности гарантирует, что в процессе валидации не будет случайно использован неполный САС вместо полного списка. Если при валидации сертификата это дополнение не распознается, то дельта-список САС должен быть отвергнут.

Дополнение Base Update формально стандартизовано версией 2000 года рекомендаций X.509 и используется в дельта-списках, которые содержат дополнение Delta CRL Indicator, для указания даты/времени обновления информации об аннулировании при помощи дельта-списка. Дополнение не указывается, если дельта-список САС содержит дополнение CRL Scope. Это дополнение всегда помечается как некритичное.

Дополнение Freshest CRL базового САС формально стандартизовано версией 2000 года рекомендаций X.509, содержит указатель на дельта-список, содержащий последнюю информацию об аннулированных сертификатах. Синтаксис этого дополнения совпадает с синтаксисом дополнения CRL Distribution Point. Документ RFC 3280 требует, чтобы область охвата дельта-списка совпадала с областью охвата САС, который содержит это дополнение. Дополнение Freshest CRL не включается в дельта-списки, поскольку не допускается, чтобы один дельта-список ссылался на другой дельта-список. В соответствии с рекомендациями X.509 это дополнение может быть как критичным, так и некритичным. Однако если оно помечено как критичное, то доверяющая сторона, прежде чем использовать сертификат, должна проверять последний САС. Для поддержки дельта-списков не требуется валидация сертификатов.

Дополнения точек входа в САС

Международный Союз по телекоммуникациям ввел несколько дополнений точек входа в САС X.509 v2 [78]. Они связывают с точками входа в САС некоторые дополнительные атрибуты. Каждое дополнение может быть помечено как критичное или некритичное. Валидация САС не может быть выполнена, если встречается нераспознанное критичное дополнение, однако некритичное дополнение может быть проигнорировано. Дополнения точек входа в САС приведены в табл. 8.3.

|Поле | Содержание |

|reasonCode

unspecified

keyCompromise

cACompromise

affiliationChanged

superseded

cessationOfOperation

certificateHold

removeFromCRL

| Код причины аннулирования (задается

перечисленными ниже значениями)

Неопределенная причина

Компрометация ключа конечного пользователя

Компрометация ключа УЦ

Изменение информации в сертификате в связи

со слиянием компаний

Замена сертификата

Прекращение работы

Приостановление действия сертификата

Удаление из САС

|holdInstructionCode | Код временного приостановления сертификата (идентификатор объекта OID) |

|certificateIssuer | Информация о пунктах распространения САС нескольких издателей для поддержки косвенных списков САС |

|invalidityDate | Дата утраты валидности сертификата |

Таблица 8.3.Дополнения точек входа в список аннулированных сертификатов X.509 v2

Дополнение Reason Code указывает причину аннулирования сертификатов. Издателем САС настоятельно рекомендуется включать в это дополнение значащие коды причин. В дополнении могут указываться следующие коды причин:

* 0 - неопределенная причина;

* 1 - компрометация ключа;

* 2 - компрометация УЦ;

* 3 - изменения в результате слияния компаний;

* 4 - замена сертификата;

* 5 - прекращение работы;

* 6 - приостановление сертификата и передача его на хранение;

* 8 - удаление сертификата из САС.

Дополнение Hold Instruction Code (код команды передачи сертификата на хранение) используется для временного приостановления сертификата. Оно содержит идентификатор зарегистрированной команды, указывающий действие, которое необходимо выполнить, если при обработке транзакции встречается сертификат, который должен быть приостановлен и передан на хранение. Документ RFC 3280 требует, чтобы поддерживалось несколько кодов команд, в том числе "позвонить издателю" и "отвергнуть сертификат". Это дополнение всегда помечается как некритичное. Оно имеет очень ограниченное применение, в частности, при выполнении финансовых транзакций. Например, если пользователь совершает покупку и при оплате предъявляет кассиру смарт-карту, на которой хранится секретный ключ его сертификата, то УЦ, выпустивший этот сертификат, может использовать команду "позвонить издателю", чтобы заставить кассира связаться с УЦ. Если сертификат пользователя был приостановлен, то при обращении к нему УЦ может потребовать от кассира конфисковать эту смарт-карту [70]. Приостановленный сертификат может быть в дальнейшем восстановлен или аннулирован.

Дополнение Certificate Issuer позволяет включать в САС информацию о пунктах распространения САС нескольких издателей, то есть поддерживать косвенные списки САС. Это дополнение идентифицирует издателя сертификата, связанного с определенной точкой входа в косвенный САС. Если дополнение первой точки входа в косвенный САС отсутствует, то по умолчанию издателем сертификата считается издатель САС. При отсутствии дополнения Certificate Issue последующей точки входа в САС издателем сертификата считается тот же субъект, который связан с предшествующей точкой входа в САС. Это дополнение всегда помечается как критичное. Если при валидации сертификата это дополнение игнорируется, то невозможно корректно установить соответствие между сертификатами и точками входа в САС.

Дополнение Invalidity Date (дата утраты валидности) содержит дату, когда стало известно или ожидается, что секретный ключ скомпрометирован или сертификат по какой-либо причине утратил валидность. Эта дата может предшествовать дате, указанной для точки входа в САС и являющейся датой, начиная с которой издатель САС выполнял аннулирование. Дата утраты валидности может предшествовать дате выпуска более ранних списков САС, но дата аннулирования не должна предшествовать дате выпуска этих списков. Дата утраты валидности выражается в обобщенном формате времени или в формате скоординированного универсального времени UTC.

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

Частные дополнения

Формат САС X.509 v2 позволяет использовать частные дополнения для поддержки специфической для данного сообщества пользователей информации. В соответствии с рекомендациями X.509 частные дополнения могут задаваться для САС и для точек входа в САС. Документ RFC 3280 не дает описания частных дополнений, а в целях предупреждения проблем функциональной совместимости разных доменов не рекомендует использовать частные дополнения и тем более помечать их как критичные.

Лекция 9. Типы списков аннулированных сертификатов и схемы аннулирования

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

Полные списки САС

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

1 проблема масштабируемости. Поскольку информация об аннулировании каждого сертификата должна поддерживаться в течение всего периода его действия, в некоторых доменах, особенно больших, может произойти чрезмерное разрастание списков САС, что существенно затруднит работу с ними, и самостоятельный поиск многими пользователями информации об аннулировании станет неэффективным;

2 проблема своевременности получения информации из списков САС. Очевидно, что с увеличением размера САС валидация сертификатов будет занимать больше времени, и это безусловно отразится на скорости доставки информации о статусе сертификатов;

3 проблема избыточной частоты генерации списков и обращения к ним. Если, например, политика применения сертификатов требует, чтобы аннулирование сертификатов из-за компрометации ключа выполнялось в течение дня, то очередной полный САС должен выпускаться каждый день. Соответствующая информация в поле сертификата Next Update вынудит пользователей сертификата получать новый полный список каждый день.

Полные списки САС целесообразно использовать лишь в доменах некоторых удостоверяющих центров с относительно небольшим количеством конечных субъектов.

Терминология, используемая в списках САС для описания информации о конечных субъектах и удостоверяющих центрах, была обновлена в стандарте X.509 версии 2000 года [78]. В частности, списки САС, которые содержат информацию о сертификатах только конечных субъектов, теперь называются списками аннулированных сертификатов открытых ключей конечных субъектов (САС КС) . Такие списки назывались просто списками САС в более ранних версиях стандарта X.509 (1997 года и ранее). Списки САС, которые содержат информацию о сертификатах только удостоверяющих центров, теперь называются списками аннулированных сертификатов удостоверяющих центров (САС УЦ) . Такие списки назывались списками аннулирования центров в более ранних версиях стандарта X.509 (1997 года и ранее).

Списки САС УЦ идентифицируются при помощи дополнений Issuing Distribution Point и/или CRL Scope. Списки САС УЦ выпускаются данным УЦ для аннулирования сертификатов открытых ключей других удостоверяющих центров. Издателем САС УЦ обычно бывает либо головной УЦ (то есть тот, который отвечает за аннулирование сертификатов любых подчиненных удостоверяющих центров), либо выпускающий УЦ, если он аннулирует кросс-сертификат, выпущенный им для другого УЦ. Наряду с этим возможна поддержка косвенных списков САС УЦ.

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

Списки САС КС идентифицируются при помощи дополнений Issuing Distribution Point и/или CRL Scope. Отдельный САС КС должен содержать всю информацию об аннулировании сертификатов конечных субъектов домена данного УЦ или может быть разбит на несколько списков разными способами, которые обсуждаются ниже.

Пункты распространения САС

Пункты распространения САС, иногда называемые частичными списками САС, позволяют размещать информацию об аннулировании сертификатов домена отдельного УЦ в нескольких списках САС [45]. Пункты распространения САС, по сравнению с полными списками САС, имеют два важных преимущества:

1 позволяют разбивать всю информацию об аннулировании на более управляемые части, не допуская чрезмерного разрастания списков САС;

2 не требуют дополнительного информирования об их местонахождении, поскольку в сертификатах обычно содержатся указатели на пункты распространения САС и доверяющим сторонам не приходится выяснять, где находится информация о статусе проверяемых сертификатов.

Синтаксис дополнения CRL Distribution Point позволяет идентифицировать местонахождение соответствующей части САС: это может быть определенный сервер, заданный при помощи DNS-имени или IP-адреса, или определенное место на сервере (например, дерево информации каталога общедоступного репозитория или файл на web-сервере). Рис. 9.1 иллюстрирует понятие пункта распространения САС [44].

Рис. 9.1. Пункт распространения САС

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

Переадресующие списки САС

Статичное разбиение полных списков САС и задание постоянного пункта распространения САС в дополнении CRL Distribution Point каждого сертификата возможно только тогда, когда выпускающий сертификаты УЦ заранее знает, как следует разбивать информацию об аннулировании и не планирует с течением времени изменить способ разбиения. На практике целесообразно иметь более гибкий механизм разбиения полных списков САС, позволяющий изменять размеры частей списков и места их хранения (например, для оптимизации скорости обработки или потребностей PKI-сообщества) [45]. Стратегии разбиения выбираются на основе разных признаков ранжирования: по серийным номерам сертификатов, причинам аннулирования, типам сертификатов, поддеревьям имен или любым другим критериям, которые можно применить к информации САС.

Для реализации такого механизма рабочая группа IETF PKIX разработала концепцию динамического разбиения, которая была формально стандартизована в версии 2000 года рекомендаций X.509 [78], и ввела в профиль списков САС дополнения CRL Scope и Status Referrals. Дополнение Status Referrals позволяет переадресовать доверяющую сторону к фактическому местонахождению информации искомого САС, не изменяя в сертификатах дополнение CRL Distribution Point. Как показано на рис. 9.2, дополнение CRL Distribution Point указывает на промежуточный САС, который, в свою очередь, содержит дополнение Status Referral со ссылкой на искомый САС. Промежуточный САС называется переадресующим списком .

Рис. 9.2. Переадресующий САС

Отметим, что при движении от переадресующего списка к искомому должны выполняться проверки согласованности, чтобы предотвратить попытки "спуфинга", то есть подмены САС. Переадресующий САС фактически содержит не список аннулированных сертификатов, а только указатели на искомые списки САС. Это позволяет частичным спискам САС изменяться во времени, не влияя на содержание существующих сертификатов. Даже если схема разбиения САС меняется, в сертификатах не приходится корректировать поля дополнения CRL Distribution Point.

Синтаксис дополнения аналогичен синтаксису дополнения Issuing Distribution Point, но в нем присутствуют несколько новых атрибутов - такие как имя УЦ (атрибут необходим, если это имя отличается от имени издателя списка, указанного в дополнении Status Referral ), ранг серийного номера или идентификатора открытого ключа субъекта, ограничения имен поддеревьев. Поскольку в дополнениях Issuing Distribution Point и CRL Scope могут встречаться одинаковые атрибуты (например, оба дополнения могут идентифицировать имя пункта распространения и включать признаки "содержит только сертификаты пользователей", "содержит только сертификаты удостоверяющих центров", "содержит только причины аннулирования"), эти дополнения могут конфликтовать друг с другом. Поэтому, если они используются одновременно, следует проверять их согласованность.

Дельта-списки и косвенные дельта-списки САС

Назначение дельта-списка - информировать об изменениях в САС, произошедших с момента его выпуска или с некоторого заданного момента времени, другими словами, о приращении САС (как известно, приращение обозначается символом $\Delta$ , отсюда и название списка) [62]. Если дельта-список ссылается на базовый САС, то базовый список и дельта-список вместе предоставляют всю информацию об аннулировании внутри указанной области, известную на момент выпуска дельта-списка. В этом случае дополнение Delta CRL Indicator используется для указания номера базового САС. В качестве альтернативы для указания того, что САС является дельта-списком, может использоваться компонент Base Revocation Information дополнения CRL Scope. В этом случае Base Revocation Information задает момент времени, начиная с которого корректировку информации об аннулировании обеспечивает дельта-список. Он может содержать ссылку на полный САС для данной области, но может и не содержать ее, а ссылаться на другой дельта-список. Отметим, что разрешается применять только один из двух способов: либо дополнение Delta CRL Indicator, либо компонент Base Revocation Information в дополнении CRL Scope.

Дельта-списки были впервые предложены в версии 1997 г. стандарта X.509 [77], но тогда четко не объяснялось, как их следует применять. Например, предполагалось, что полный САС должен публиковаться при каждом выпуске дельта-списка, а это противоречило самой идее дельта-списков. В версии 2000 г. стандарта X.509 появилось уточнение относительно применения дельта-списков и была введена концепция косвенных списков САС. Косвенные списки предназначаются для более своевременной доставки информации об аннулировании, их обработка не увеличивает нагрузку на сетевые ресурсы.

Рассмотрим связь между дельта-списками и полным списком для заданной области. По определению, дельта-списки базируются на некоторой предоставленной ранее информации об аннулировании, называемой базовым списком, и содержат ту информацию, которая появилась после выпуска базового списка. Относительно небольшие по объему дельта-списки могут выпускаться чаще, чем базовый список, обеспечивая тем самым оптимизацию соотношения "своевременность доставки - регулярность выпуска САС". Вместо одного базового списка могут последовательно создаваться и доставляться несколько дельта-списков, в этом случае каждый последующий дельта-список содержит полный перечень тех сертификатов, которые были аннулированы после выпуска предыдущего дельта-списка.

Пример 9.1. Рассмотрим корпоративный домен PKI, в котором разрешено выпускать полные списки САС не чаще чем раз в неделю. Политикой безопасности этого домена установлено, что информация об аннулировании должна распространяться не позднее 5 часов с момента аннулирования сертификата. Очевидно, что в этом случае требования регулярности выпуска полного САС и своевременности доставки информации противоречат друг другу. Решение проблемы заключается в выпуске базового САС раз в неделю, а дельта-списков САС - каждые 5 часов. Таким образом, более объемный САС выгружается и размещается в кэш-памяти раз в неделю, а относительно небольшие дельта-списки распространяются по мере необходимости. Дельта-списки также могут размещаться в кэш-памяти до тех пор, пока не истечет их срок действия. Если кэширование запрещено, необходимо выполнять поиск дельта-списка САС всякий раз, когда выполняется валидация сертификата, - тогда и только тогда информация об аннулировании будет актуальной.

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

Косвенные списки САС

В версии 2000 года стандарта X.509 [78] появилась концепция косвенных дельта-списков. Подобно дельта-спискам, косвенные списки содержат сведения об изменениях ранее опубликованной информации об аннулировании сертификатов. Однако косвенные дельта-списки могут использоваться для корректировки нескольких списков САС, выпущенных одним издателем (например, один косвенный дельта-список может обеспечить обновление информации обо всех пунктах распространения списков САС, изданных данным УЦ). Они также могут предоставлять последнюю информацию об обновлении списков САС, выпущенных несколькими издателями.

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

Информация о косвенных списках указывается в компоненте Indirect CRL дополнения сертификата Issuing Distribution Point. Если он принимает значение TRUE, то САС может содержать информацию об аннулировании из нескольких источников. Для реализаций, которые согласуются со стандартом X.509 (версии 2000 г.), косвенные списки САС также могут поддерживаться путем указания в поле Authority Name нескольких атрибутов Per Authority Scopes с именами разных удостоверяющих центров.

Деревья аннулирования сертификатов

Деревья аннулирования сертификатов, ДАС (Certificate Revocation Trees - CRTs) - это технология аннулирования, разработанная американской компанией Valicert. Деревья ДАС базируются на хэш-деревьях Merkle, каждое дерево позволяет отобразить всю известную информацию об аннулировании, релевантную некоторому множеству PKI-сообществ [83].

Чтобы создать хэш-дерево, генерируется последовательность выражений для каждого УЦ, входящего в данное множество. Каждая последовательность ранжируется по возрастанию серийных номеров аннулированных сертификатов данного УЦ. Выражение может иметь, например, следующий вид: УЦ₁ = УЦ_n и 1155 < X < 1901, где X - серийный номер сертификата, изданного УЦ₁. Это означает, что:

1 сертификат с серийным номером 1155, изданный УЦ₁, был аннулирован;

2 сертификаты, изданные УЦ₁, с серийными номерами от 1156 до 1900 (включительно) не аннулированы.

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

Пример 9.2. Рассмотрим дерево аннулирования сертификатов, представленное на рис. 9.3 [44]. Крайние слева узлы представляют хэш-коды математических выражений, которые известны субъекту, генерирующему дерево. Как показано стрелками, каждая смежная пара узлов затем объединяется в один узел. Если пара существует, два узла объединяются и хэшируются. Результат хэширования - это значение нового сформированного узла справа. Если пары нет (когда на данном уровне имеется нечетное количество узлов), то непарный узел просто перемещается на следующий уровень дерева (как показано узлами N_2,2 и N_3,1 на рис. 9.3). Этот процесс повторяется до тех пор, пока не будет вычислен финальный "корень" (самый правый узел на рис. 9.3). Значение хэш-кода последнего узла в целях обеспечения целостности и аутентичности заверяется цифровой подписью.

Рис. 9.3. Пример дерева аннулирования сертификатов

Чтобы определить, был ли сертификат аннулирован, доверяющая сторона проверяет, превышает ли серийный номер сертификата нижнюю границу ближайшего по значению нестрогого неравенства из последовательности выражений для данного УЦ. Если это так, то сертификат не был аннулирован, если нет - то был. Чтобы убедиться в том, что целостность не была нарушена, доверяющая сторона должна реконструировать корневой узел и сравнить его хэш-код со значением заверенного цифровой подписью хэш-кода корневого узла. Для этого субъект, сгенерировавший дерево, предоставляет доверяющей стороне информацию о выражении, ближайшем к серийному номеру проверяемого сертификата, значения хэш-кодов всех поддерживающих узлов и заверенный цифровой подписью хэш-код корневого узла. Генерация ДАС может выполняться уполномоченным субъектом внутри рассматриваемого множества PKI-сообществ или доверенной третьей стороной. Главное преимущество деревьев ДАС заключается в эффективном представлении большого объема информации об аннулировании. Фактически объем ДАС составляет log2N, где N - число аннулированных сертификатов.

Механизмы онлайновых запросов

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

Разработкой онлайновых протоколов статуса сертификата занималась рабочая группа IETF PKIX. В июне 1999 года онлайновый протокол статуса сертификата Online Certificate Status Protocol ( OCSP ) был предложен в качестве стандарта RFC 2560 [155]. Поскольку это был первый шаг в разработке протоколов такого рода, функциональность OCSP была намеренно ограничена его разработчиками.

Онлайновый протокол статуса сертификата

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

OCSP-ответ также достаточно прост и состоит из идентификатора сертификата, статуса сертификата ("нормальный", "аннулированный" или "неизвестный") и срока действия ответа, связанного с идентификатором каждого указанного в исходном запросе сертификата. Если сертификат имеет статус аннулированного, то отображается время аннулирования и может быть указана причина аннулирования (необязательно). Срок действия задается интервалом от текущего обновления (параметр This Update ) до следующего обновления (параметр Next Update ). Ответ может содержать необязательные дополнения, а также код ошибки, если обработка запроса не была завершена корректно.

Рис. 9.4 иллюстрирует взаимодействие между доверяющей стороной и OCSP-респондером. OCSP-сервер может поддерживать разные стратегии аннулирования, на рисунке они отображаются в прямоугольнике, помеченном как внутренняя база данных. OCSP-ответы должны быть заверены цифровой подписью, гарантирующей, что ответ исходит от доверенного субъекта и не был изменен при передаче. Ключ подписи может принадлежать тому же УЦ, который выпустил данный сертификат, доверенной третьей стороне или субъекту, которому издатель сертификата делегировал право подписи [155].

Рис. 9.4. Взаимодействие OCSP-компонентов

В любом случае доверяющая сторона должна доверять ответу на запрос, что подразумевает доверие к тому, кто подписал ответ. Следовательно, доверяющая сторона должна получить копию сертификата открытого ключа OSCP-респондера, и этот сертификат должен быть подписан доверенным источником. Запросы также могут заверяться цифровой подписью (например, если OCSP-респондер действует как платный сервис), но это - необязательная опция протокола OCSP. Информация о местонахождении OCSP-респондера, отвечающего на запросы о статусе данного сертификата, содержится в самом сертификате в дополнении Authority Information Access [167]. Дополнение Distribution Points используется для указания на часть САС.

протокол OCSP разрабатывался исключительно для поддержки сообщений о статусе сертификатов и не позволяет определять валидность сертификата. Другими словами, протокол OCSP не подтверждает, что сертификат не был просрочен, и не гарантирует, что сертификат используется в точном соответствии с назначением, которое обычно указывается в дополнениях данного сертификата: Key Usage, Extended Key Usage или Policy Qualifier. Кроме того, доверяющим сторонам не стоит переоценивать возможности протокола доставлять самую "свежую" информацию об аннулировании сертификатов в режиме реального времени. Даже если сам протокол предлагает ответ на запрос в режиме реального времени (в предположении, что OCSP-респондер доступен в онлайновом режиме для обслуживания запросов), это не обязательно означает, что протокол OCSP -ответ о текущем состоянии сертификата придет без задержки, особенно если сервисы УЦ и OCSP-респондера реализованы на одном сервере. То есть доверяющим сторонам не стоит полагаться на то, что по протоколу OCSP автоматически доставляется самая "свежая" информация, даже если считается, что информирование о статусе сертификатов - это сервис реального времени.

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

Простой протокол валидации сертификатов

Простой протокол валидации сертификатов (Simple Certificate Validation Protocol - SCVP) разрабатывался рабочей группой PKIX для обеспечения делегирования процессов валидации и обнаружения пути сертификации доверенным сторонам в среде Интернет [91]. Делегированная валидация пути (Delegated Path Validation - DPV) позволяет доверяющей стороне переложить процесс валидации пути сертификации на доверенную третью сторону. Это имеет смысл в тех средах, где локальная валидация пути невозможна или нежелательна, а также в случае поддержки в среде централизованной политики валидации. По аналогии с DVP делегированное обнаружение пути (Delegated Path Discovery - DPD) позволяет доверяющей стороне поручить трудоемкий процесс построения пути сертификации доверенной третьей стороне. Это избавляет доверяющую сторону от необходимости поиска сертификатов, составляющих путь сертификации.

Другие режимы аннулирования

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

Второй случай встречается тогда, когда одобрение любой транзакции исходит от одного и того же субъекта. Это характерно для банковского сектора, где онлайновые транзакции всегда проходят через банк клиента. Банк использует свою базу данных, чтобы установить соответствие между клиентом и счетом, к которому ему разрешен доступ. Поскольку информация об аннулировании может поддерживаться на основе данных о счетах клиентов и все транзакции проходят через банк, нет необходимости передавать эту информацию на компьютер клиента. Точно так же происходит авторизация транзакций по дебетовым или кредитным картам при совершении сделок через торговые web-сайты. В процессе авторизации финансовой транзакции продавец должен обратиться в банк покупателя и подтвердить валидность сертификата клиента. Отметим, что во втором случае не исключена поддержка аннулирования, но она не обязательно должна базироваться на приведенных выше схемах.

Сравнительная характеристика разных схем аннулирования

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

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

Онлайновые механизмы типа протокола OCSP достаточно эффективны, но отсутствие статистических данных не позволяет оценить их возможности для решения проблем масштабируемости и скорости обработки списков САС. Требуется дополнительное исследование и оптимизация количества и физического распределения OCSP-респондеров, необходимых для обслуживания большого, территориально распределенного сообщества пользователей.

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

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

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

|Схема | Основное описание | Примечания |

|Полные списки САС | Заверенные цифровой подписью структуры данных, содержащие списки аннулированных сертификатов; определены стандартом X.509 | Критичны с точки зрения скорости обработки, масштабируемости и своевременности. Однако на основе X.509 существуют альтернативные формы для повышения производительности, гарантирования масштабируемости и улучшения своевременности |

|Списки САС удостоверяющих центров | Тип САС, который предназначен исключительно для информации об аннулировании, относящейся к удостоверяющим центрам; определен стандартом X.509 | На практике обычно разделяется информация об аннулировании сертификатов удостоверяющих центров и конечных субъектов |

|Списки САС конечных субъектов | Тип САС, который предназначен исключительно для информации об аннулировании относящейся к конечным субъектам; определен стандартом X.509 | На практике обычно разделяется информация об аннулировании сертификатов удостоверяющих центров и конечных субъектов |

|Пункты распространения САС | Используются для статичес-кого разбиения списков САС на части; определены стандартом X.509 | Позволяет статически разбивать информацию об аннулировании сертификатов на более управляемые части |

|Дельта-списки и косвенные списки САС | Используются для распространения небольших дельта-списков ; определены стандартом X.509 | Могут использоваться для существенного повышения скорости обработки и поддержки своевременности. Комбинируются с другими формами списков САС |

|Косвенные списки САС | Используются для объединения в одном списке информации об аннулировании от нескольких удостоверяющих центров; определены стандартом X.509 | Могут использоваться для повышения скорости обработки при условии, что объединение информации из нескольких источников не требует больших затрат, чем поиск информации в каждом отдельном источнике |

|Онлайновый протокол статуса сертификата - OCSP | Возможность онлайновых запросов используется для получения информации о статусе одного или нескольких сертификатов; определен в документе RFC 2560 | Несмотря на то, что протокол предназначен для ответов в режиме реального времени, "свежесть" предоставляемой информации зависит от ее источника |

|Переадресующие списки САС | Используются для динамического разбиения информации об аннулировании; определены в документе RFC 2560 | Относительно новая концепция, которая совершенствует схему пунктов распространения САС |

|Деревья аннулирования сертификатов CRT | Позволяют отображать информацию об аннулировании при помощи деревьев двоичных хэш-кодов; соответствующий метод разработан компанией Valicert | Могут стать одним из альтернативных способов, применяемых сторонними поставщиками услуг для представления информации об аннулировании |

|Другие способы | Используются, если доставка информации об аннулировании не требуется или реализуются по-другому | Альтернативные способы подходят, если авторизация всех транзакций выполняется общим центром |

Таблица 9.4.Схемы аннулирования сертификатов

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

Рассматриваются такие понятия архитектуры PKI, как путь сертификации, пункты доверия PKI, доверенный ключ. Описываются простая, иерархическая, сетевая и гибридная архитектура PKI, обсуждаются способы построения пути сертификации для каждого типа архитектуры.

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

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

* количества удостоверяющих центров, которые непосредственно доверяют друг другу;

* структуры отношений доверия между удостоверяющими центрами;

* способа добавления в инфраструктуру нового УЦ;

* сложности построения и проверки пути сертификации ;

* серьезности последствий компрометации удостоверяющих центров.

Каждый тип архитектуры обладает своими достоинствами и недостатками. Простые типы, например, одиночный УЦ и простой список доверия УЦ, пригодны для развертывания небольшой PKI и являются основой других типов архитектуры. Для решения проблем безопасности крупной организации (большой компании или правительственного агентства) требуется более сложная архитектура, например, иерархическая или сетевая, связывающая отношениями доверия многие удостоверяющие центры. Часто списки доверия, иерархическая и сетевая инфраструктуры открытых ключей комбинируются для создания гибридной PKI. Можно выделить следующие типы гибридной архитектуры: расширенные списки доверия ; кросс-сертифицированные корпоративные инфраструктуры и мостовые PKI. Для каждого типа архитектуры характерны свои отношения доверия. В зависимости от своих особенностей, каждый тип архитектуры используется в определенной среде.

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

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

Обработка пути сертификации состоит из двух этапов:

1 построение пути, которое заключается в агрегировании всех сертификатов, необходимых для формирования полного пути;

2 валидация пути, которая включает последовательную проверку каждого сертификата пути и определение надежности соответствующего открытого ключа.

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

Построение пути сертификации

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

Рис. 10.1. Пример построения пути

Пример 10.1. Пусть пользователь А пытается проверить надежность сертификата пользователя В, с которым он желает взаимодействовать [44]. Предположим, что пользователь В сертифицирован УЦ₃, УЦ₃ кросс-сертифицирован с УЦ₂ (наряду с другими удостоверяющими центрами), УЦ₂ кросс-сертифицирован с УЦ₁ (наряду с другими), а пользователь А владеет доверенной копией открытого ключа УЦ₁ (см. рис. 10.1).

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

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

Простая архитектура PKI

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

Одиночный УЦ

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

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

Рис. 10.2. Одиночный УЦ и пути сертификации

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

Построение пути в простой PKI

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

На (рис. 10.2) показаны пути сертификации пользователей A, B, C и N в простой PKI, представляющей собой одиночный УЦ. Каждый путь состоит из одного сертификата. Запись [(УЦ "Альфа") -> А] означает, что один сертификат, выпущенный УЦ "Альфа" для пользователя А, составляет весь путь.

Простые списки доверия

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

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

Рис. 10.3. Поддержка нескольких удостоверяющих центров через списки доверия

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

Архитектура корпоративной PKI

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

Иерархическая PKI

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

Включение в инфраструктуру нового УЦ происходит тогда, когда один из существующих удостоверяющих центров выпускает для него сертификат. Рис. 10.4 иллюстрирует иерархическую PKI и три способа добавления новых удостоверяющих центров [70]. Иерархическая PKI изображена на рис. 10.4 а). На рис. 10.4 в) показано, как создается новый УЦ₃ непосредственно под головным УЦ существующей PKI, на рис. 10.4 c) новый УЦ становится подчиненным УЦ₂. Таким же способом могут быть объединены две иерархические PKI. На рис. 10.4 d) к существующей инфраструктуре добавляется целая иерархическая PKI. Добавляемые компоненты на рисунках обведены пунктирными линиями.

Рис. 10.4. Расширение иерархической PKI

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

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

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

Построение пути в иерархической PKI

В иерархиях пути сертификации начинаются в корне (с головного УЦ) и заканчиваются конечными субъектами, однако строятся они в обратном направлении [60]. Построение начинается с сертификата конечного субъекта. В сертификате указаны его издатель (УЦ) и дополнение Authority Key Identifier (идентификатор ключа УЦ). Эти атрибуты позволяют найти сертификат УЦ. Имя издателя используется для определения местонахождения сертификатов УЦ в репозитории. Репозиторий может содержать несколько сертификатов, выпущенных для УЦ. Идентификатор ключа УЦ в сертификате конечного субъекта сравнивается с идентификатором ключа субъекта только в одном сертификате - искомом сертификате УЦ. Этот процесс повторяется до тех пор, пока не будет найден сертификат, изданный головным УЦ, пунктом доверия иерархии.

На рис. 10.5 показаны пути сертификации для пользователей А, В, С и D в иерархической PKI. Каждый конечный субъект имеет единственный путь сертификации. Некоторые пути сертификации длиннее прочих, но все пути начинаются в корне иерархии. Запись [(ГУЦ -> УЦ₃); (УЦ₃ -> D)] означает, что путь от головного УЦ (ГУЦ) до пользователя D состоит из двух сертификатов.

Рис. 10.5. Пути сертификации в иерархической PKI

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

Сетевая PKI

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

Рис. 10.6. Пример сетевой PKI и построенных путей сертификации

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

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

Пример 10.3. На рис. 10.6 удостоверяющие центры объединены в сетевую PKI. Пользователи А и В доверяют УЦ₁. Пользователь С доверяет УЦ₂, а пользователь D - УЦ₃. Пользователю А гораздо труднее найти и проанализировать путь сертификации до пользователя С, чем в иерархической PKI. В том случае, если путь строится от УЦ₁ к УЦ₂, то он содержит два сертификата, а если путь к УЦ₂ проходит через УЦ₃, то - три сертификата. Пытаясь обнаружить один из нескольких правильных путей, пользователь может построить пути, которые ведут в тупик (например, путь через УЦ₄ ). Обработка большего количества сертификатов более сложна, поскольку сопровождается анализом ограничений, включаемых в дополнения сертификатов.

Построение пути в сетевой PKI

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

В сетевой архитектуре сертификаты конечных субъектов выпускаются непосредственно их пунктами доверия. Субъект, строящий путь, доверяет своему УЦ, который может не совпадать с пунктом доверия того конечного субъекта, к которому строится путь. Более того, для этого УЦ могут быть выпущены сертификаты другими удостоверяющими центрами из разных сегментов сети. По этой причине построение пути начинается в пункте доверия и продолжается в направлении издателя сертификата конечного субъекта. Идентификатор ключа УЦ в сертификате сравнивается с идентификатором ключа субъекта сертификатов удостоверяющих центров, включая сертификат искомого УЦ. Так как дополнения Authority Key Identifier (идентификатор ключа УЦ) недостаточно для построения пути, следует использовать другие атрибуты как эвристические. Это могут быть имена или любые другие атрибуты, помогающие выбрать, с какого из возможных сертификатов начинать построение пути. Если выбранный сертификат не ведет к завершенному пути сертификации, то просто пробуют следующий за ним сертификат и т.д. [84].

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

На рис.10.6 показаны пути сертификации, которые можно построить от пользователя А к пользователям B, C и D. Для пользователей C и D показан не один путь. Каждый путь является валидным, но некоторые пути длиннее других. Нахождение наиболее короткого пути не требуется, решение этой задачи значительно усложняет процесс. Обычно используется первый найденный валидный путь. С иллюстративной целью третий путь сертификации для пользователя D имеет петлю.

Гибридная архитектура PKI

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

Пример 10.4. Рассмотрим сценарий, проиллюстрированный рис. 10.7 [70]. Три компании сотрудничают друг с другом, но используют корпоративные PKI разных типов. Пользователи А и В получили свои сертификаты от головного УЦ компании "Альфа". Пользователь С получил свой сертификат от УЦ подразделения 1 в иерархической PKI компании "Бета". Пользователь D получил сертификат от УЦ подразделения 3 в сетевой PKI компании "Гамма". Пользователь А может использовать один из трех вариантов гибридной архитектуры PKI для установления защищенных коммуникаций с пользователями C и D.

Рис. 10.7. Три корпоративные PKI

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

Архитектура расширенного списка доверия

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

Пример 10.5. Чтобы защищенно связываться с пользователями B, C и D, пользователь А должен включить в свой расширенный список доверия три удостоверяющих центра: по одному УЦ от каждой доверенной PKI (см. рис. 10.7). Пользователь А доверяет своему собственному УЦ "Альфа", головному УЦ иерархической PKI компании "Бета" и одному УЦ в сетевой PKI компании "Гамма". Внутри каждой корпоративной PKI удостоверяющие центры могут быть связаны одноранговыми или иерархическими связями. Пользователь А может легко добавить новый УЦ или целую корпоративную PKI в свой список доверия. Сложность сертификатов зависит от связей в каждой корпоративной PKI.

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

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

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

Построение пути для расширенного списка доверия

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

Часто используется достаточно простой метод построения пути сертификации в иерархической PKI [84]. Если путь сертификации ведет к одному из доверенных пунктов, то считается, что построен валидный путь ; если нет, то проверяется, был ли выпущен верхний сертификат данного пути сертификации любым пунктом доверия. Если это так, то этот сертификат завершает путь ; если нет, то делается попытка построить путь от каждого пункта доверия к верхнему сертификату данного пути сертификации. Для повышения эффективности построения пути используется кэширование: в кэш-памяти компьютера сохраняются все возможные пути сертификации, каждый из которых помечается признаком качества. Простые иерархические пути считаются более качественными, чем сложные, в итоге выбираются пути с признаком более высокого качества, то есть наиболее короткие. Этот метод можно использовать и в сложных топологиях.

Кросс-сертифицированные корпоративные PKI

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

Рис. 10.8. Кросс-сертифицированные корпоративные PKI и пути сертификации пользователя А

Пример 10.6. На рис. 10.8 УЦ пользователя А кросс-сертифицирован с головным УЦ иерархической PKI компании "Бета" и УЦ подразделения 2 в сетевой PKI компании "Гамма". Кроме того, удостоверяющие центры компаний "Бета" и "Гамма" кросс-сертифицированы друг с другом. Каждый пользователь поддерживает один пункт доверия. Пользователи A, B и D доверяют удостоверяющим центрам, которые выпустили их сертификаты, а пользователь С доверяет своему головному УЦ. Межкорпоративные отношения являются одноранговыми, а внутри корпоративных инфраструктур установлены или одноранговые, или иерархические связи. Имея свой список доверия, пользователь А не может добавлять в него новый УЦ внешней PKI по своему усмотрению, а должен полагаться на действия администратора своего пункта доверия. А дминистраторы УЦ обычно имеют более высокую квалификацию, чем пользователи, и способны определить надежность УЦ или PKI. Прежде чем устанавливать отношения кросс-сертификации, администраторы УЦ анализируют политику и практику применения сертификатов другого УЦ. После кросс-сертификации удостоверяющих центров пользователь В получает возможность проверять валидность сертификатов пользователей С и D из других PKI. В соответствии с принципами архитектуры расширенного списка доверия пользователям необходимо обновлять свои собственные списки доверия.

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

Построение пути для кросс-сертифицированных PKI

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

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

На рис. 10.8 показаны пути сертификации, которые могут связывать пользователя А с пользователями B, C и D. Для пользователей C и D имеется не один путь. Каждый путь является валидным, но одни пути длиннее других. Как и в сетевой архитектуре, поиск кратчайшего пути значительно усложняет процесс построения пути.

Архитектура кросс-сертифицированных PKI - подходящее решение в том случае, когда отношения доверия устанавливаются между несколькими корпоративными PKI (их не должно быть много). Рис. 10.8 показывает, что для установления отношений, описанных в примере, потребовались три одноранговые связи и шесть сертификатов удостоверяющих центров. С увеличением числа корпоративных PKI количество связей и сертификатов быстро растет. Кросс-сертификация n-корпоративных PKI требует (n² - n)/2 - одноранговых связей и (n² - n) - сертификатов [70].

Рис. 10.9. Восемь кросс-сертифицированных PKI

На рис. 10.9 представлены восемь корпоративных PKI. Кросс-сертификация всех пар инфраструктур требует установления 28 одноранговых связей и выпуска 56 сертификатов удостоверяющих центров. В связи с тем, что установление этих связей требует длительного изучения политик и практической работы удостоверяющих центров, реализация этой архитектуры становится слишком трудоемкой задачей.

Архитектура мостового УЦ

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

В отличие от сетевого центра, мостовой УЦ не выпускает сертификаты непосредственно для пользователей, а, в отличие от головного УЦ, в иерархии мостовой УЦ не является пунктом доверия. Все пользователи PKI рассматривают мостовой УЦ в качестве посредника. Мостовой УЦ устанавливает одноранговые отношения с разными корпоративными PKI. Эти отношения принимают вид моста доверия, который связывает пользователей разных PKI [10]. Если домен доверия реализован как иерархическая PKI, мостовой УЦ устанавливает связь с головным УЦ иерархии. Если домен реализован как сетевая PKI, мостовой УЦ устанавливает связь только с одним из удостоверяющих центров сети. Удостоверяющий центр, который вступает в отношения с мостовым УЦ, называется главным УЦ .

Пример 10.7. На рис. 10.10 мостовой УЦ связан с тремя корпоративными PKI. Первая PKI - это УЦ пользователей А и В, вторая - иерархическая PKI пользователя С, и третья - сетевая PKI пользователя D. Никто из пользователей не доверяет непосредственно мостовому УЦ. Пользователи А и В доверяют УЦ "Альфа", который является издателем их сертификатов, они доверяют мостовому УЦ постольку, поскольку их собственный УЦ выпустил для него сертификат. Пункт доверия пользователя С - головной УЦ в его иерархии; пользователь С доверяет мостовому УЦ косвенно, потому что данный головной УЦ выпустил для того сертификат. Пользователь D доверяет издателю своего сертификата - УЦ₃ компании "Гамма" и косвенно доверяет мостовому УЦ, потому что существует правильный путь сертификации от УЦ₃ до мостового УЦ. Пользователи А и В могут использовать мост доверия для установления отношений с пользователями С и D.

Рис. 10.10. Связывание трех корпоративных PKI при помощи мостового УЦ и построение путей сертификации

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

В связанные мостом инфраструктуры легко добавляются новые удостоверяющие центры или даже целые корпоративные PKI [100]. Изменения остаются прозрачными для пользователей, пока они не касаются пунктов доверия. По мере роста PKI число отношений доверия, которые должны быть установлены, начинает превышать разумное и поддающееся управлению. На рис. 10.10 для трех корпоративных PKI были установлены три отношения доверия, как и в примере кросс-сертификации (рис. 10.8). Рис. 10.11 иллюстрирует связывание восьми корпоративных PKI при помощи мостового УЦ. Это требует установления восьми отношений доверия, а не двадцати восьми, как требовалось в варианте кросс-сертификации (рис. 10.8).

Рис. 10.11. Связывание восьми корпоративных PKI при помощи мостового УЦ

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

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

Построение пути в мостовой PKI

Мостовой УЦ имеет ряд преимуществ по сравнению с кросс-сертифицированными PKI. Разные пользователи по-прежнему строят разные пути сертификации для одного и того же сертификата конечного субъекта, и путь сертификации начинается с пункта доверия пользователя, который желает построить путь до данного сертификата. Однако существует только один кросс-сертификат, связывающий данную PKI со всеми сторонними PKI. Это существенно упрощает построение пути сертификации. На рис. 10.10 показаны пути сертификации, которые связывают пользователя А и пользователей B, C и D. Пользователь D может построить не один путь, так как является участником сетевой PKI.

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

Лекция 11. Валидация пути сертификации

Дается определение валидного пути сертификации, описывается процедура проверки валидности пути; рассматриваются входные параметры и переменные состояния, необходимые для валидации пути сертификации; объясняются принципы обработки каждого сертификата и механизм выявления в пути сертификации аннулированных сертификатов, обсуждаются подходы к выбору архитектуры PKI.

Процедура проверки валидности пути

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

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

Путь сертификации считается валидным, если образующая его последовательность сертификатов удовлетворяет следующим условиям [89].

* I. Первый сертификат издан пунктом доверия.

* II. Последний сертификат издан для данного конечного субъекта и содержит данный открытый ключ.

* III. Имена издателей и субъектов сертификатов образуют последовательность. Во всех сертификатах этой последовательности, за исключением первого и последнего, имя издателя текущего сертификата совпадает с именем субъекта предыдущего сертификата, а имя субъекта текущего сертификата совпадает с именем издателя следующего сертификата.

* IV. Период действия всех сертификатов не истек, то есть все сертификаты последовательности на момент валидации являются действующими.

Этот набор условий необходим, но не достаточен для того, чтобы путь сертификации был валидным. Помимо перечисленных условий, должны анализироваться и обрабатываться содержащиеся в сертификатах пути основные ограничения, а также ограничения на имена и политики [60]. Эта обработка выполняется за четыре основных шага:

1 Инициализация.

2 Базовая проверка сертификата.

3 Подготовка следующего сертификата в последовательности.

4 Завершение.

Шаги 1 и 4 выполняются однократно. Шаг 2 выполняется для каждого сертификата в последовательности, а шаг 3 - для всех сертификатов, за исключением последнего - сертификата конечного субъекта.

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

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

* предполагаемый путь сертификации;

* набор идентификаторов допустимых политик применения сертификатов ;

* информация о пункте доверия ;

* индикатор, показывающий, разрешено ли устанавливать соответствие политик применения сертификатов в пути сертификации ;

* индикатор, показывающий, требуются ли в сертификатах явные идентификаторы политики ;

* индикатор, показывающий, разрешено ли указывать в сертификатах специальный идентификатор "любая политика".

Инициализация

На этапе инициализации в зависимости от входных параметров устанавливаются переменные состояния, необходимые для валидации пути сертификации [70]. В переменных состояния сохраняются различные ограничения, учитываемые при валидации пути. Переменные состояния делятся на четыре группы.

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

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

Третья группа переменных состояния применяется для сохранения информации о политиках применения сертификатов, образующих путь сертификации. Эти переменные позволяют оценить, является ли критичным дополнение Certificate Policy ( политика применения сертификатов ), необходим ли явный идентификатор политики, разрешено ли отображать дополнительную политику и указывать в сертификатах идентификатор "любая политика".

Рис. 11.1. Пример проверки ограничений на имена

Четвертая группа переменных состояния отслеживает правильность именования. Для каждого типа имени должны анализироваться разрешенные и запрещенные поддеревья в иерархической структуре имен. Валидные имена должны содержаться в одном из разрешенных поддеревьев и не содержаться ни в одном из запрещенных поддеревьев.

На рис. 11.1 показан пример использования доменных имен Интернета [70]. Имя host.spyrus.com не является валидным, так как не принадлежит ни одному из разрешенных поддеревьев. Имена mail.department2.beta.com и file-server.department2.gamma.com не являются валидными, потому что принадлежат запрещенным поддеревьям.

Как только все переменные состояния инициализированы, осуществляется базовый контроль первого сертификата в последовательности.

Базовый контроль сертификата

Базовый контроль сертификата выполняется для всех сертификатов последовательности и состоит из ряда проверок [167]. Проверки, использующие каждую из четырех групп переменных состояния, выполняются, чтобы определить, не является ли сертификат просроченным или аннулированным, удовлетворяет ли сертификат ограничениям сертификатов последовательности, предшествующих ему или следующих за ним. Если любая из проверок дает отрицательный результат, то путь сертификации не считается валидным.

Проверка срока действия сертификата

Эта проверка завершается успешно, если текущие дата и время на момент валидации находятся в пределах срока действия сертификата.

Проверка статуса сертификата

Эта проверка завершается успешно, если издатель не аннулировал данный сертификат. Основным средством проверки статуса сертификата являются списки САС, но могут использоваться и другие альтернативные средства проверки.

Проверка подписи сертификата

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

Проверка цепочки имен

На базе второй группы переменных состояния сравниваются отличительное имя издателя данного сертификата и отличительное имя субъекта сертификата, следующего в последовательности за данным сертификатом.

Проверка политик применения сертификатов

Для этой проверки используется третья группа переменных состояния. Если дополнение Certificate Policy присутствует в сертификате, то проверяется, является ли указанная политика одним из ожидаемых значений. Если дополнение Certificate Policy содержит специальный идентификатор "любая политика", то проверяется, показывает ли соответствующий индикатор, что разрешена любая политика. Если дополнение Certificate Policy отсутствует, то проверяется, показывает ли соответствующий индикатор, что требуется явное задание политики.

Проверка ограничений на имена

Для этой проверки используется четвертая группа переменных состояния. Проверяется, принадлежит ли имя субъекта сертификата одному из разрешенных поддеревьев иерархии отличительных имен X.500 и не принадлежит ли одному из запрещенных деревьев этой же иерархии. Также проверяется, принадлежит ли каждое из альтернативных имен субъекта сертификата одному из разрешенных поддеревьев иерархии отличительных имен этого типа и не принадлежит ли одному из запрещенных деревьев этой же иерархии.

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

Подготовка следующего сертификата

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

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

Проверка длины пути сертификации. Проверяется, не была ли превышена максимальная длина пути сертификации.

Корректировка переменных состояния верификации цифровой подписи. В поле информации об открытом ключе субъекта сертификата устанавливаются значения открытого ключа, параметров, связанных с открытым ключом, и название алгоритма цифровой подписи. Если поле информации об открытом ключе субъекта в данном сертификате не содержит никаких параметров открытого ключа, а предыдущий сертификат содержит открытый ключ, связанный с тем же самым алгоритмом подписи, то сохраняются параметры открытого ключа предыдущего сертификата. То есть эти параметры как бы "передаются по наследству" данному сертификату из предыдущего сертификата.

Корректировка переменных состояния цепочки имен и длины пути сертификации. В поле отличительного имени субъекта сертификата устанавливается отличительное имя ожидаемого издателя сертификата. Если отличительное имя издателя сертификата и отличительное имя субъекта сертификата совпадают, то сертификат является самоподписанным или самоизданным.

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

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

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

Обработка дополнительных критичных дополнений. Распознаются и обрабатываются любые дополнительные критичные дополнения, представленные в сертификате. Если какое-либо критичное дополнение не удается распознать, то путь сертификации не считается валидным.

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

Завершение обработки сертификата

Когда завершается обработка сертификата конечного субъекта, на основании значений переменных состояния устанавливаются выходные значения.

Корректировка переменных состояния верификации цифровой подписи. В поле информации об открытом ключе конечного субъекта устанавливаются значения открытого ключа, параметров, связанных с открытым ключом конечного субъекта, и название алгоритма цифровой подписи. Если поле информации об открытом ключе конечного субъекта в данном сертификате не содержит никаких параметров открытого ключа, а предыдущий сертификат содержит открытый ключ, связанный с тем же самым алгоритмом подписи, то сохраняются параметры открытого ключа предыдущего сертификата. То есть эти параметры как бы "передаются по наследству" данному сертификату из предыдущего сертификата.

Определение допустимых политик применения сертификатов. Определяется пересечение входного набора идентификаторов допустимых политик применения сертификатов и значений переменных состояния политик применения сертификатов. Если пересечение - пустое, то валидация пути сертификации завершается неудачно. Если пересечение не является пустым, то переменные состояния принимают значения, соответствующие пересечению.

Обработка дополнительных критичных дополнений. Распознаются и обрабатываются любые дополнительные критичные дополнения, указанные в сертификате. Если какие-либо критичные дополнения не распознаются, то путь сертификации не является валидным. Из переменных состояния извлекаются выходные параметры валидного пути сертификации:

* политики применения сертификатов и любые связанные с политикой квалификаторы;

* открытый ключ конечного субъекта, параметры, связанные с открытым ключом, и название алгоритма цифровой подписи.

Выявление в пути сертификации аннулированных сертификатов

В процессе валидации пути сертификации проверяется, не был ли аннулирован издателем хотя бы один сертификат из цепочки сертификатов [167]. С этой целью часто используются списки аннулированных сертификатов (см. лекцию 8). Выявление аннулированных сертификатов состоит из трех последовательных шагов:

1 инициализации ;

2 обработки САС;

3 завершения.

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

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

Переменная состояния статуса сертификата принимает одно из трех значений: "аннулирован" (с указанием причины аннулирования ), "не аннулирован" и "статус сертификата не определен". Первоначально переменная состояния статуса сертификата имеет значение "не аннулирован", оно не меняется до тех пор, пока в ходе проверки не обнаруживаются доказательства аннулирования.

Обработка САС

Как только инициализация закончена, обрабатывается один или несколько списков САС. Обработка выполняется до тех пор, пока либо не выяснится, что сертификат аннулирован, либо не будут проверены все списки САС, указанные в дополнении проверяемого сертификата CRL Distribution Points (пункты распространения САС), а переменная состояния статуса сертификата сохранит значение "не аннулирован". Обработка каждого САС состоит из шести шагов [167].

* Шаг 1. САС считывается или помещается в локальную кэш-память компьютера для хранения. САС может охватывать коды причины аннулирования полностью или частично.

* Шаг 2. Проверяется издатель САС. Если в дополнении CRL Distribution Points данного сертификата последовательности указано имя издателя САС, то оно сравнивается с именем издателя обрабатываемого САС. Если эти имена различны, то проверяется, совпадает ли имя издателя обрабатываемого САС с именем издателя данного сертификата. Когда используются косвенные списки САС, то имя издателя САС, указанное в дополнении CRL Distribution Points сертификата, отличается от имени издателя этого сертификата.

* Шаг 3. Проверка подписи издателя САС. Строится и проверяется путь сертификации издателя САС. Для проверки подписи, заверяющей САС, используется открытый ключ издателя САС. В большинстве случаев издатель САС является одновременно издателем одного из сертификатов пути сертификации. Если один и тот же ключ используется для подписания и САС, и сертификата, то путь сертификации уже построен и прошел валидацию. Если издатель использовал разные ключи, для построения этого пути может потребоваться отдельный дополнительный сертификат. Когда используются косвенные списки САС, может потребоваться путь сертификации полностью независимого издателя САС.

* Шаг 4. Подтверждается, что САС является текущим. Если в поле CRL Next Update (следующее обновление САС) указано время, предшествующее текущему моменту, то необходимо либо получить соответствующий дельта-список для обновления САС, либо отбросить САС. Если начальное значение индикатора дельта-списка установлено и присутствует дополнение Freshest CRL (последняя версия САС), то получают дельта-список, соответствующий данному базовому САС. Для дельта-списка САС проверяется его соответствие тому же самому набору сертификатов и тому же самому набору кодов причин, которые содержит и базовый САС. Кроме того, проверяется, был ли он издан тем же самым УЦ и заверен тем же самым ключом, что и базовый САС. Если все эти проверки завершены успешно, то проверяется цифровая подпись дельта-списка САС. Если подпись верна, то объединяются базовый список и дельта-список САС.

* Шаг 5. Корректировка переменной состояния маски причины. Значение переменной состояния устанавливается как объединение текущего значения и списка кодов причины для САС, определенного ранее.

* Шаг 6. Поиск сертификата с заданным серийным номером в САС. Если в сертификате имеется дополнение Issuer CRL Entry (точка входа САС издателя), то значение этого дополнения должно совпадать с именем издателя сертификата. Если в сертификате отсутствует дополнение Issuer CRL Entry, то должны совпадать имена издателя сертификата и издателя САС. Если для сертификата с заданным серийным номером имена издателей совпадают, то сертификат аннулирован. В этом случае переменная состояния статуса сертификата принимает значение, соответствующее причине аннулирования.

Если переменная состояния маски причин не отражает того, что все причины аннулирования проверены, а переменная состояния статуса сертификата имеет значение "не аннулирован", то выполняется пошаговая обработка следующего САС, указанного в дополнении сертификата CRL Distribution Points. Если обработаны все списки САС из дополнения CRL Distribution Points, но не все причины аннулирования проверены, то должны быть получены и проанализированы дополнительные списки САС. Информация о них хранится в репозитории издателя данного сертификата. Пошаговая процедура обработки повторяется для каждого дополнительного САС, после этого выполняется процедура завершения.

Завершение

Если все списки САС проанализированы, а переменная состояния маски причины не показывает, что все причины аннулирования проверены, то переменная состояния статуса сертификата принимает значение "не определен". Большинство приложений будет реагировать на этот статус так же, как и на статус "аннулирован", остальные приложения уведомят пользователя о неопределенном статусе сертификата. После этого проверка сертификата на предмет аннулирования завершается, и выводится значение переменной состояния статуса сертификата.

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

С другой стороны, объединенная операция более сложна, чем две отдельные операции построения и валидации пути. Эта повышенная сложность часто приводит к ошибкам реализации, которые, в свою очередь, требуют больших усилий по поддержке системы. В иерархиях, где путь строится достаточно просто, нецелесообразно объединять построение и валидацию пути.

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

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

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

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

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

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

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

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

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

Лекция 12. Механизмы распространения информации PKI

Подробно рассматриваются механизмы распространения сертификатов и списков САС, обсуждается организация репозитория, дается характеристика каталога X.500, описывается упрощенный протокол доступа к каталогу LDAP, сопоставляются разные варианты развертывания репозитория, дается представление о способах распространения PKI-информации при помощи электронной почты, сетевых протоколов и системы доменных имен.

Частное распространение информации PKI

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

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

Несмотря на недостатки, частное распространение вполне подходит для небольших (и дружественных) сообществ пользователей, в которых любые два субъекта непосредственно знают друг друга или имеют узкий круг общих знакомых. Примером протокола, соответствующего этой модели, является протокол системы Pretty Good Privacy (PGP) или более поздний протокол Open PGP [40]. Использовать частное распространение в корпоративной сфере не рекомендуется по ряду причин, в частности из-за:

1 невозможности масштабирования (метод эффективно работает только в небольших сообществах пользователей);

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

3 несоответствия модели доверия, центром которой является отдельный пользователь, модели централизованного управления действиями пользователей, характерной для большинства корпоративных доменов.

Публикация и репозитории

Публикация - это наиболее популярный метод распространения сертификатов и информации об аннулированных сертификатах в больших сообществах, где пользователи не знакомы друг с другом. Суть метода состоит в том, что информация PKI размещается в общеизвестном, открытом и легко доступном месте. Идея публикации в контексте криптографии с открытыми ключами впервые появилась в работе Диффи и Хэллмана "Новые направления в криптографии" [63]. Это была первая открытая работа по криптографии с открытыми ключами. Авторы предложили модель публикации и распространения открытых ключей, взяв за образец телефонный справочник.

Для современных PKI обычной практикой является публикация сертификатов и информации об аннулированных сертификатах в репозитории. В (лекции 3) была введена концепция репозитория. Вообще говоря, репозиторий - это общий термин, используемый для обозначения любой логически централизованной базы данных, способной хранить и распространять информацию о сертификатах по запросам [31]. В организации репозитории обычно размещаются на удаленных серверах, доступ к которым осуществляется по протоколу LDAP версий 2 и 3. Репозиторий часто базируется на информационной модели и протоколах, определенных рекомендациями X.500. Однако термин репозиторий можно применять к базе данных или любой другой форме хранения и распространения информации. Под определение репозитория попадают:

* серверы LDAP;

* агенты системы каталога X.500;

* OCSP-респондеры (серверы, обслуживающие запросы пользователей по онлайновому протоколу статуса сертификата); хотя, как установлено документом RFC 2560 [155], OCSP-респондер публикует только информацию об аннулировании;

* система доменных имен DNS (сертификаты и информация об аннулированных сертификатах поддерживаются в соответствии с документом RFC 2538 [153]);

* web-серверы (сертификаты и информация об аннулированных сертификатах поддерживаются в соответствии с документом RFC 2585 [156] и могут быть получены по протоколу передачи гипертекста HTTP);

* ftp-серверы (сертификаты и информация об аннулированных сертификатах поддерживаются в соответствии с документом RFC 2585);

* корпоративные базы данных, которые могут содержать информацию о сертификатах и их аннулировании и обладают адекватными механизмами управления и доступа.

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

Клиентское программное обеспечение может определять местонахождение репозитория несколькими способами. Например, файл конфигурации локального клиента может быть инициализирован по IP-адресу или DNS-именам основного и дополнительного LDAP-серверов. Для указания места, где размещается необходимая информация или сервис, могут также использоваться дополнения сертификатов. Частное дополнение Authority Information Access (доступ к информации об УЦ) может применяться в качестве указателя на OCSP-респондер, связанный с издателем сертификата, а частное дополнение Subject Information Access (доступ к информации о субъекте) может содержать указатель на репозиторий УЦ, являющегося субъектом. Местонахождение информации об аннулированных сертификатах также указывается в дополнении сертификата CRL Distribution Points (пункты распространения САС).

Итак, к основным характеристикам репозитория можно отнести [10]:

* прозрачность местонахождения;

* производительность и доступность;

* анонимность и возможность аутентификации доступа;

* функциональную совместимость.

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

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

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

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

Особенности использования корпоративного репозитория

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

Наконец, в силу того, что сертификаты и списки являются "самозащищенными" (то есть их целостность гарантируется цифровой подписью), сам механизм хранения ( репозиторий ) не нуждается в защите, с точки зрения целостности данных. Если же в репозитории хранится информация, которая не является "самозащищенной", то она должна быть защищена другими средствами. Например, ответы OCSP-респондера, содержащие информацию об аннулированных сертификатах, должны заверяться цифровой подписью для гарантии целостности ответов (включая целостность источника и данных). Более того, если репозиторий хранит обычные открытые ключи и/или списки САС, база данных репозитория должна быть защищена от несанкционированной модификации.

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

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

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

Хотя проблемы секретности не всегда вызывают опасение во внутрикорпоративном контексте, они выходят на первый план, когда информация распространяется между разными корпоративными доменами. Эти проблемы особенно обостряются, когда один корпоративный домен взаимодействует с другим корпоративным доменом на базе кросс-сертификации или посредством общего для двух доменов головного удостоверяющего центра, что, естественно, требует взаимного обмена информацией о сертификатах и списках САС.

Иногда можно избежать распространения сертификатов и списков САС с конфиденциальной информацией. В относительно простой иерархии для предотвращения нежелательного раскрытия информации о корпоративной инфраструктуре может использоваться дерево информации каталога Directory Information Tree (DIT) [127], организованное на основе информационной базы объектов организации и знаний об их иерархии. В некоторых случаях также можно указывать в поле сертификата Distinguished Name ( отличительное имя ) локально уникальный идентификатор, имеющий значение в иерархии определенного УЦ, который по существу является отдельной доверяющей стороной. Тогда отличительное имя теряет смысл для стороннего наблюдателя, который может перехватить сертификат.

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

Варианты развертывания междоменного репозитория

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

Общий репозиторий

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

Междоменная репликация

Междоменная репликация означает копирование сертификатов и информации об аннулированных сертификатах из одного домена в другой и наоборот. Способность автоматически выполнять междоменную репликацию зависит от используемых протоколов. Если оба домена поддерживают сервисы каталога стандарта X.500, то репликация выполняется на базе существующих протоколов, в частности, протокола для создания "теневой" копии данных каталога Directory Information Shadowing Protocol (DISP) [37]. Для случая, когда единственным общим протоколом доступа двух доменов к данным друг друга является упрощенный протокол доступа к каталогу LDAP, пока не существует стандартного протокола репликации. Рабочая группа LDUP (LDAP Duplication/ Replication/ Update Protocol) организации инженерной поддержки Интернета IETF (Internet Engineering Task Force) в настоящее время работает над этой проблемой, и можно ожидать введения нового протокола репликации на базе LDAP [44]. Другой временной альтернативой может быть передача файлов на базе формата обмена данными LDAP (LDIF - LDAP Data Interchange Format) [161]. В любом случае должен быть защищен базовый сеанс копирования данных из одного корпоративного домена в другой.

Пограничный репозиторий

Одним из наиболее популярных способов развертывания междоменного репозитория является использование пограничного репозитория, который обычно поддерживается за границей корпоративного межсетевого экрана или внутри демилитаризованной зоны, где применяется несколько межсетевых экранов. Таким образом, внутренний репозиторий защищается от доступа извне средствами контроля сетевой безопасности, а пограничный репозиторий предназначен для внешнего использования.

Пограничный репозиторий может быть развернут для поддержки всей PKI или для отдельных подразделений или организаций внутри данной PKI. Иногда пограничный и внутренний репозитории связываются при помощи соответствующего механизма или протокола системы каталога X.500 Directory System Protocol (DSP). Спецификации упрощенного протокола доступа к репозиторию LDAP не поддерживают связывание явным образом.

Управление внешним доступом к пограничному репозиторию зависит от политики PKI и уровня конфиденциальности хранимой информации. В любом случае удаленные клиенты должны иметь возможность получать доступ к необходимым сертификатам и информации об аннулированных сертификатах без "блуждания" по корпоративной сети и, соответственно, без прямого доступа к конфиденциальной информации корпоративной базы данных. Рис. 12.1 иллюстрирует ряд возможных конфигураций сети, связанных с развертыванием междоменного репозитория [44].

Вариант А соответствует использованию прямого доступа внешних субъектов к корпоративному репозиторию через корпоративный межсетевой экран, защищающий внутреннюю сеть. Вариант прямого доступа позволяет клиентскому программному обеспечению конечного пользователя одного домена получать прямой доступ к репозиторию другого домена и наоборот; или позволяет внешнему репозиторию напрямую обращаться к внутрикорпоративному репозиторию. Этот вариант может использоваться тогда, когда между доменами установлены двусторонние отношения доверия и/или репозиторий защищен от несанкционированного доступа.

Рис. 12.1. Варианты развертывания междоменного репозитория

Вариант B соответствует двум возможным сценариям. Первый сценарий заключается в частичной репликации данных корпоративного репозитория вне контура зоны корпоративного межсетевого экрана. Этим экраном защищен каталог X.500, содержащий закрытую информацию о сотрудниках, включая их телефонные номера, адреса электронной почты, номера карточек социального страхования, сведения о выплатах и т.п. Кроме того, каталог содержит сертификаты и списки САС. Для хранения частично реплицированной информации применяется пограничный репозиторий, который дублирует сертификаты и списки САС из внутреннего репозитория. Второй сценарий состоит в том, что пограничный репозиторий становится промежуточным репозиторием, или прокси-репозиторием и входящие запросы адресуются соответствующему репозиторию без какого-либо вовлечения в этот процесс конечного пользователя. B некоторых средах могут поддерживаться одновременно варианты А и B или оба сценария варианта B.

Помимо управления доступом может потребоваться поддержка сервиса конфиденциальности. Предотвращение несанкционированного ознакомления с информацией, передаваемой от одного корпоративного домена к другому, может быть достигнуто при помощи протоколов безопасности, таких как протокол безопасности транспортного уровня Transport Layer Security (TLS), протокол инкапсулирующей защиты содержимого IP-пакетов Encapsulating Security Payload (ESP) или посредством некоторых протоколов уровня приложений, например X.500 Directory Access Protocol (DAP).

Концепция пограничного репозитория впервые была разработана в рамках инициативы федерального мостового УЦ США (U.S. Federal Bridge CA). Там же была предложена концепция мостового репозитория, который может использоваться для взаимосвязи многих пограничных репозиториев [210]. Возможности пограничного репозитория используются в некоторых реализациях PKI, в частности, в PKI правительства Канады.

Организация репозитория и протоколы доступа к нему

Традиционным вариантом организации репозитория PKI является каталог. Используются несколько типов систем каталога, но имеются и другие варианты поддержки PKI-информации. Для передачи сертификатов и данных об аннулировании могут использоваться любые протоколы, которые приняты для распространения двоичной информации. Обмен PKI-информацией может осуществляться при помощи электронной почты S/MIME версии 3, сетевых протоколов FTP, HTTP, TLS и IPSec (особенно протокола обмена ключами Internet Key Exchange - IKE) и даже системы доменных имен DNS.

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

Каталоги

Каталог - это онлайновая база данных, хранящая произвольную информацию. Информация об определенном человеке или объекте называется входом каталога. Каждый вход связан с классом объектов, описывающим атрибуты входа. Классы объектов, связанные с людьми, и классы объектов, связанные с компьютерным оборудованием, содержат разные атрибуты. Чтобы получить информацию из каталога, клиенты должны знать: куда отправить запрос, какой вход и какие атрибуты входа необходимы. Следует отметить, что поиск информации поддерживается даже тогда, когда точное имя входа неизвестно.

Каждый вход идентифицируется отличительным именем. Отличительные имена используются в сертификатах в качестве имен субъектов и издателей. Запросы клиентов различают атрибуты в зависимости от искомой информации (например, сертификат или САС). Атрибуты задаются несколькими спецификациями, рекомендуемыми организацией IETF, источником является документ RFC 2587 - схема протокола LDAP версии 2 [157].

Атрибут userCertificate содержит сертификаты тех конечных субъектов, имена которых соответствуют отличительному имени входа.

Атрибут cACertificate содержит сертификаты тех удостоверяющих центров, имена которых соответствуют отличительному имени входа.

Атрибут certificateRevocationList содержит список аннулированных сертификатов.

Атрибут authorityRevocationList (ARL) содержит списки аннулированных сертификатов, выпущенных только для других удостоверяющих центров.

Атрибут deltaRevocationList содержит дельта-списки САС.

Атрибут crossCertificationPair содержит пару кросс-сертификатов удостоверяющих центров. Элементы этой пары могут быть прямыми и обратными. Прямой и обратный элементы представлены значением отдельного атрибута. Субъект одного сертификата и издатель другого сертификата соответствуют отличительному имени входа. Открытый ключ субъекта одного сертификата позволяет проверить цифровую подпись другого сертификата и наоборот. Пара кросс-сертификатов представлена на рис. 12.2.

Рис. 12.2. Пара кросс-сертификатов

Документ RFC 2587 определяет три класса объектов PKI: пользователи pkiUser, удостоверяющие центры pkiCA и пункты распространения САС cRLDistributionPoint.

Класс объектов pkiUser используется для входов владельцев сертификатов. Входы должны содержать атрибуты сертификатов пользователей. Все сертификаты, имена субъектов которых соответствуют имени входа каталога, должны храниться в pkiUser.

Класс объектов pkiCA используется для входов удостоверяющих центров. Входы pkiCA могут содержать сертификат УЦ, САС КП, САС УЦ, пару кросс-сертификатов. Атрибут "сертификат УЦ" включает сертификаты удостоверяющих центров, имя субъектов которых связано с этим входом. Сертификаты могут быть, в том числе, и самоизданными. Атрибут ARL содержит списки аннулированных сертификатов только удостоверяющих центров. Атрибут crossCertificationPair содержит одну или несколько пар кросс-сертификатов. Прямые элементы этого атрибута входа каталога УЦ хранят сертификаты, выпущенные другими удостоверяющими центрами для данного УЦ. Обратные элементы этого атрибута могут содержать сертификаты, выпущенные данным УЦ для других удостоверяющих центров.

Класс объектов cRLDistributionPoint может включать атрибуты САС КП, САС УЦ и дельта-списки САС. Имя входа каталога должно соответствовать имени в дополнении "пункты распространения САС".

Каталог X.500

В документе RFC 2116 [141] каталог X.500 описывается как распределенная база данных, в которой хранится информация о людях и объектах в различных узлах сети и на распределенных серверах. Различные серверы сети называются агентами сервера каталога (АСК), а клиенты - агентами пользователя каталога (АПК). АСК отвечает на запросы АПК. На рис. 12.3 представлен концептуальный вид каталога X.500 [70].

Каталог использует два базовых протокола: протокол доступа к каталогу (Directory Access Protocol - DAP) и протокол сервиса каталога (Directory Service Protocol - DSP) [126]. Протокол DAP поддерживает информационные запросы от АDК к АCК. Протокол DSP поддерживает информационные запросы между АСК. В общем, АСК объединяются для поддержки информации, разделяемой путем связывания. АСК могут дополнять протокол DSP протоколом дублирования информации каталога (Directory Information Shadowing Protocol - DISP). Протокол может использоваться для репликации контентов (или подмножества контентов) АСК. Эта операция обычно называется дублированием. С точки зрения АПК, вся база данных размещается в отдельной системе. Этой системой является АСК, который управляет информационными запросами АПК. Количество агентов АСК и способ их объединения невидимы для АПК. Ясно, что когда используется связывание, каталог X.500 обеспечивает прозрачность местонахождения репозитория.

Распределенный характер каталога X.500 обеспечивает также высокую доступность. Если один из агентов АСК становится недоступным, то теряется доступ только к той информации, которая физически размещается в этой системе. Безусловно, агенты АПК, которые обращаются с запросами к недоступному АСК, должны быть обслужены другим агентом или получить отказ в доступе к каталогу. Доступность можно в дальнейшем повысить путем дублирования информации на нескольких АСК.

Рис. 12.3. Концептуальный вид каталога X.500

Производительность репозитория может варьироваться в зависимости от физического размещения информации и способа связывания агентов АСК. Рассмотрим подробнее рис. 12.3. Если пользователь А направляет свои запросы АСК 1, а пользователь B - АСК 5, то пользователи, получая одну и ту же информацию, будут обслуживаться с разной скоростью. Если информация размещается в системе АСК 1, то пользователь А получит информацию очень быстро, так как она размещена локально. Пользователь B должен будет ждать, пока его запрос будет направлен в АСК 2, затем в АСК 1, и только потом вернется ответ. Средняя производительность оптимизируется, если информация, которую часто используют, находится на ближайшем АСК.

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

Упрощенный протокол доступа к каталогу LDAP

Использование протокола DAP оказалось слишком обременительным для многих клиентских приложений. В результате в Университете штата Мичиган был разработан упрощенный протокол доступа к каталогу LDAP. Протокол LDAP был усовершенствован и стандартизирован организацией IETF [157]. Наиболее распространенным протоколом доступа к репозиторию является протокол LDAP второй версии.

В общем случае, каталоги LDAP v2 непосредственно не связаны между собой. Если каталог LDAP получает запрос на вход, который размещается в другом месте, то проверяет таблицу удаленных каталогов. Если один из этих каталогов содержит искомый вход, то каталог возвращает ссылку другим каталогам. Ссылка содержит имя каталога и систему, которая его поддерживает. Это упрощает реализацию каталога и не требует поддержки протокола DSP. Однако эта архитектура не обеспечивает прозрачность местонахождения репозитория. Прежде чем получить любую информацию, клиент должен определить физическое местонахождение репозитория. Более того, имеются реализации клиентов LDAP, которые фактически управляют ссылками. Если сертификаты или списки САС недоступны в первом проверяемом каталоге, они не будут найдены.

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

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

Серьезным недостатком каталога X.500 было использование протокола DAP. Протокол работал, но признавался слишком громоздким. В результате большинство клиентских приложений поддерживали протокол LDAP, а не DAP. Современные реализации каталога X.500 ориентируются на протокол LDAP. Это решение обладает всеми атрибутами мощного механизма репозитория: прозрачностью размещения и масштабируемостью с целью удовлетворения возрастающих требований организации к производительности и доступности.

Организация IETF продолжила работу над протоколом LDAP. В результате была создана третья версия протокола. В настоящее время разрабатывается ряд дополнений. После завершения работы эти дополнения обеспечат средства поддержки связывания и репликации. Переход от второй версии репозитория LDAP v2 к третьей версии LDAP v3 может потребовать некоторой дополнительной настройки.

FTP

Протокол передачи файлов File Transfer Protocol (FTP) описывается в документе RFC 959 [131]. Серверы FTP давно используются для распространения информации в Интернете, они могут предоставлять информацию по анонимным запросам или после предъявления пользователем имени и пароля.

Документ RFC 2585 [156] определяет типы данных и правила образования имен для передачи сертификатов и списков САС с использованием FTP. Файлы с расширением .cer содержат только сертификаты, а файлы с расширением .crl - только списки САС. Имена файлов задаются как унифицированные идентификаторы ресурсов в дополнениях сертификатов и списков САС. Например, ftp://ftp.alpha.com/pki/id48.cer задает отдельный сертификат, доступный анонимно с ftp.alpha.com. Документ RFC 2585 не описывает типы данных, которые содержат множественные значения или пары кросс-сертификатов.

FTP-серверы не обеспечивают прозрачность местонахождения репозитория. Они просто не разрабатывались как распределенная система. Это не позволяет адекватно реагировать на проблемы производительности и доступности, которые могут быть решены только при помощи более мощных и быстрых FTP-серверов.

Рис. 12.4. Двухшаговая публикация сертификата

FTP-серверы могут отслеживать активность пользователей, требуя от них введения имени и пароля. Из-за сложности управления большим количеством учетных записей пользователей FTP-серверы не способны обслуживать крупномасштабные PKI. Для наполнения FTP- репозитория требуется двухшаговый процесс, как показано на рис. 12.4 [70]. УЦ публикует информацию в каталоге, а затем программа-утилита копирует сертификаты и списки САС из каталога в файловую систему FTP-сервера. FTP-серверы с анонимным доступом лучше подходят в качестве репозитория, но не позволяют поддерживать в PKI бизнес-модель возмещения затрат за счет доверяющих сторон, поскольку не способны генерировать счета для всех систем, которые запрашивают данные (даже если IP-адреса систем регистрируются).

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

HTTP

Протокол передачи гипертекста HTTP определяется в документе RFC 2068 [140]. Документ RFC 2585 описывает типы данных и правила образования имен для передачи сертификатов и списков САС с использованием протокола HTTP. Правила образования имен подобны правилам, принятым для протокола FTP. Имена файлов задаются как унифицированные идентификаторы ресурсов в дополнениях сертификатов и списков САС, например, http://www.alpha.com/pki/id48.cer.

Протокол HTTP может обеспечить прозрачность размещения репозитория, а также может применяться для автоматической переадресации запроса к системе, в которой хранится необходимая информация. Широко распространена практика создания виртуальных web-серверов, которые фактически состоят из многих отдельных серверов. Поскольку все клиенты используют один и тот же хорошо известный URL (например, http://www.cnn.com), разные запросы могут обслуживаться разными серверами. Этот процесс прозрачен для клиента. Подобная схема позволяет администратору HTTP- репозитория выполнять масштабирование системы для обеспечения адекватной производительности и доступности. Если HTTP-сервер поддерживает протокол SSL или TLS с аутентификацией клиента, то может идентифицировать или аутентифицировать источник каждого запроса. В этом случае в PKI возможна реализация бизнес-модели оплаты за обслуживание запросов.

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

Электронная почта

Документ RFC 822 задает формат другого широко распространенного протокола передачи данных: протокола электронной почты [130]. Почти каждая компания имеет серверы электронной почты. Практически каждая клиентская система поддерживает электронную почту. Клиент может запросить сертификат или список САС через субъект или тело почтового сообщения. Сертификаты и списки САС могут быть возвращены как вложения в ответе на почтовое сообщение типа MIME, определенном в документе RFC 2585. Подобное решение привлекает своей простотой, однако почтовый репозиторий не обладает необходимыми свойствами.

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

Удостоверяющие центры могут наполнять почтовый репозиторий за два шага. Источник каждого запроса достаточно легко аутентифицировать. Если запросы к репозиторию передаются в виде подписанных цифровой подписью сообщений электронной почты (например, S/MIME), репозиторий может аутентифицировать и лицо, обращающееся с запросом. Аутентификация позволяет поддерживать бизнес-модель оплаты за обслуживание запросов.

Пока не существует улучшенного стандарта распространения сертификатов и списков САС по электронной почте. В отсутствие правил образования имен и утвержденного протокола электронная почта не может использоваться в качестве основного механизма распространения сертификатов и списков САС. Однако передача последних версий списков САС по электронной почте очень удобна для пользователей.

Поддержка системы доменных имен

Одной из наиболее удачных распределенных информационно-поисковых систем является система доменных имен (DNS) Интернета. Система DNS описывается в документах RFC 1034 [132] и RFC 1035 [133]. Документ RFC 1035 утверждает, что целью доменных имен является обеспечение такого механизма именования, чтобы имена могли использоваться разными хостами, локальными и глобальными сетями, семействами протоколов и организациями. Система DNS обеспечила реализацию этих целей, и исследователи постоянно ищут новые способы совершенствования ее возможностей.

Ведется много дискуссий о возможном использовании системы DNS для унификации многих разрозненных каталогов и разработке соответствующих протоколов доступа в помощь клиентам. Эта концепция требует новых типов данных, идентифицирующих репозиторий некоторого домена, а не предполагает использования системы DNS для транспортировки сертификатов и списков САС. Пусть, например, клиент обрабатывает сообщение электронной почты от домена alpha.com. Он должен создать запрос к системе DNS. Если бы в ответе указывался общий репозиторий для PKI компании "Альфа", это позволило бы упростить сертификаты, исключив из них указатели на местонахождение репозитория. Тогда можно было бы менять протоколы доступа к репозиторию PKI без повторного выпуска сертификатов. Эта идея пока не реализована, но организация IETF в качестве эксперимента начала процесс стандартизации данного подхода.

Лекция 13. Политики, регламент и процедуры PKI

Дается определение политики безопасности, рассматриваются способы реализации политики безопасности, приводится список основных требований к политике PKI, дается характеристика политике применения сертификатов и регламента удостоверяющего центра, обсуждаются отличия политики применения сертификатов, регламента и организационных процедур удостоверяющего центра, дается представление об идентификаторах объектов и краткой характеристике политики PKI, подробно рассматриваются способы отображения политики в сертификатах.

Политика безопасности и способы ее реализации

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

Пример 13.1. Чтобы понять отличия между политикой безопасности, механизмами и процедурами, рассмотрим следующий сценарий [70]. Пусть, например, компания-производитель автомобилей желает защитить проекты новых моделей от своих конкурентов. Компания решает ограничить доступ в то здание, где разрабатываются модели новых автомобилей, и пропускать туда только сотрудников группы проектирования. С этой целью предлагается использовать считыватель карт с магнитной полосой. Дверь должна автоматически открываться, когда сотрудник группы проектирования "прокатывает" через считывающее устройство свою идентификационную карту, и автоматически запираться на замок, когда сотрудник закрывает дверь за собой.

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

В этом примере компания выбирает правильную политику безопасности, ограничивая доступ в здание, где ведется разработка новых моделей автомобилей. Механизмом реализации политики безопасности служит считыватель карт. Процедуры заключаются в действиях специалиста по кодированию карт, рассылке каждому сотруднику сообщений с инструкцией на его электронный адрес и доставке карт по почте на его домашний адрес. Тем не менее нельзя сказать, что в результате процесс проектирования новых моделей автомобилей будет хорошо защищен.

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

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

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

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

Основные требования к политике PKI можно сформулировать следующим образом:

* соответствие общей корпоративной политике безопасности ;

* четкость и однозначность формулировок;

* доступность изложения;

* разграничение ответственности между субъектами PKI;

* адекватность ограничений и пределов ответственности требованиям сферы приложения сертификатов.

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

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

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

Как определено стандартом организации IETF RFC 2527 Certificate Policy and Certification Practices Framework [152], основными документами, описывающими политики и процедуры, связанные с PKI, являются политика применения сертификатов (ППС) и регламент УЦ. Эти документы имеют одинаковый формат, но разное назначение, и адресованы разным лицам. Документ о политике применения сертификатов можно сравнить с ответом на вопрос "что?", а регламент - с ответом на вопрос "как?" в отношении безопасного использования сертификатов. Они позволяют согласовывать политики разных организаций, хотя объем и сложность большинства документов, содержащих ППС и регламент, делают этот процесс достаточно трудоемким.

Политика применения сертификатов

В соответствии с международным стандартом ISO/IEC 9594-8/ITU-T Recommendation X.509 [78] под политикой применения сертификатов понимается установленный набор правил, характеризующих возможность применения сертификатов определенным сообществом субъектов и/или классом приложений с определенными требованиями безопасности. Политика применения сертификатов (ППС) - это документ, описывающий политику безопасности в отношении выпуска сертификатов и распространения информации о статусе сертификатов. Эта политика безопасности регламентирует операционную работу УЦ, а также регулирует ответственность пользователей при получении и использовании сертификатов и ключей. ППС гарантирует защищенность всего жизненного цикла сертификатов, начиная от их генерации и заканчивая аннулированием или истечением срока действия.

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

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

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

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

Приведем примеры политик применения сертификатов. Пусть, например, авиакомпания IATA, сотрудничающая с другими авиакомпаниями-партнерами, желает выработать две политики применения сертификатов для PKI в авиационной индустрии: политику общего назначения и политику коммерческого назначения [152]. Политика общего назначения формируется для персонала компании IATA с целью защиты обычной информации (например, электронной почты) и аутентификации соединений web-браузеров с серверами для поиска информации общего характера. В этом случае сертификаты могут выпускаться автоматически для любого лица, указанного в списке корпоративного каталога авиакомпании IATA, или служащего авиакомпании-партнера, обратившегося к сетевому администратору своей организации с подписанным запросом на сертификат. Генерация, хранение и управление парами ключей могут осуществляться посредством браузеров.

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

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

Регламент удостоверяющего центра

Термин регламент удостоверяющего центра (Certification Practice Statement - CPS) был введен в 1995 году в проекте директив Американской ассоциации юристов (American Bar Association) как "заявление о практике выпуска сертификатов удостоверяющим центром". Регламент подробно описывает систему и практику работы УЦ с сертификатами. В регламенте могут фиксироваться положения договора между УЦ и подписчиками. Регламент четко формулирует обязанности УЦ перед доверяющей стороной. Лицо, полагающееся на сертификат при проверке цифровой подписи, должно знать или получать информацию о содержании сертификата. Этим обусловлено требование включения в сертификат ссылки на регламент УЦ, выпустившего данный сертификат. Регламент должен отражать соответствие практики УЦ общепризнанным стандартам: только в этом случае может быть оценена пригодность и принципиальная совместимость сертификатов, выпущенных УЦ, с другими системами применения сертификатов.

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

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

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

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

Любой УЦ, используя спецификатор политики, может включить в выпускаемый им сертификат ссылку на свой регламент. ППС должна описывать все области применения сертификатов данного УЦ, в то время как регламент УЦ может разрабатываться без учета назначения сертификатов. Таблица 13.1 позволяет сравнить формулировки политики применения сертификатов, регламента и организационных процедур, описывающие одно и то же положение политики PKI: защищенность аппаратных средств УЦ. Регламент и политика применения сертификатов содержат достаточно общую информацию и публикуются открыто, а организационные процедуры носят конфиденциальный характер и поэтому должны оставаться секретными. Обычно регламент и политика имеют одинаковый формат публикации, установленный стандартом RFC 2527 [76], и взаимно дополняют друг друга.

|Документ | Формулировка |

|ППС | Физический доступ к аппаратному обеспечению УЦ разрешен только лицам, ответственным за техническую поддержку системы |

|Регламент | Для гарантирования физической безопасности аппаратного обеспечения УЦ должны соблюдаться следующие меры контроля: вход в помещение, где размещается аппаратура УЦ, - только по два человека; контроль доступа в помещение - биометрический; наблюдение за помещением - 24 часа в сутки 7 дней в неделю (по системе 24/7) |

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

Таблица 13.1.Сравнительная характеристика формулировок документов, описывающих одно положение политики PKI

Идентификаторы объектов

При принятии решения об использовании данного сертификата для конкретной цели и доверии к нему пользователь может ориентироваться на указатель ППС в сертификате формата X.509 версии 3. Таким указателем, характеризующим политику применения сертификатов, является уникальный зарегистрированный идентификатор объекта Object Identifier. Идентификаторы объектов - это один из простых типов данных, определяемых абстрактной синтаксической нотацией ASN.1. Идентификатор объекта задается последовательностью целочисленных компонентов (например, 1.3.6.1.4.1.6943 ), которая уникально идентифицирует объект (алгоритм, тип атрибута и т.п.) или центр регистрации идентификаторов.

Регистрация идентификаторов объектов выполняется в соответствии с процедурами, определенными стандартами Международной организации стандартизации (ISO), Международной электротехнической комиссии (IEC) и Международным союзом по телекоммуникациям (ITU). Сторона, регистрирующая Object Identifier, публикует текстовую спецификацию ППС для ознакомления с ней пользователей сертификатов. Каждый УЦ аккредитуется с учетом заявленных им политик, которые считаются базовыми. Перечень заявленных политик указывается в сертификате этого центра. Существует система международных, национальных и корпоративных центров регистрации. Во многих странах национальные организации стандартизации поддерживают регистр идентификаторов объектов. Центры регистрации идентификаторов создают иерархию идентификаторов объектов и гарантируют уникальность каждого идентификатора в общей системе. Каждый центр определяет смысл значений Object Identifier данной последовательности компонентов и несет ответственность за все последовательности компонентов, начиная с данной последовательности [2]. Центр может делегировать полномочия другому подчиненному центру регистрации идентификаторов.

Идентификаторы объектов часто применяют в сертификатах X.509 для:

* отображения криптографических алгоритмов (например, алгоритм SHA-1 с RSA имеет идентификатор 1.2.840.113549.1.1.5.);

* задания атрибута имени в отличительном имени субъекта;

* идентификации политик применения сертификатов ;

* указания расширенного назначения ключа;

* задания дополнений сертификатов и списков САС.

Модель доверия стандарта X.509 предполагает анализ идентификаторов ППС при обработке пути сертификации.

|Object Identifier 1.2.643.3.15.1 | Политика применения сертификатов ЗАО "Цифровая подпись" |

|1.2.643.3.15.1.1 | Общее использование в PKI без права заверения финансовых документов |

|1.2.643.3.15.1.2 | Оформление соглашений, договоров |

|1.2.643.3.15.1.3 | Организация внутрикорпоративного документооборота |

|1.2.643.3.15.1.5 | Закрепление авторских прав |

|1.2.643.3.15.1.7 | Использование в системах электронной коммерции |

Таблица 13.2.Примеры идентификаторов политик применения сертификата

PKI всегда должна поддерживать известные идентификаторы объектов. Программные продукты для PKI умеют распознавать и автоматически обрабатывать эту информацию. Однако развертывание новой PKI требует формирования, по крайней мере, одного нового идентификатора политики. Вообще говоря, корпоративная PKI может поддерживать 4-5 разных политик применения сертификатов. Иногда новые идентификаторы требуются для задания узкоспециальных дополнений сертификатов и списков САС. Идентификаторы объектов, определенные для удовлетворения этих локальных требований одной PKI, часто называются частными идентификаторами объектов, поскольку они принадлежат конкретной компании или организации (в табл. 13.2 приведены некоторые идентификаторы политик УЦ ЗАО "Цифровая подпись" [27]).

Отображение политики в сертификатах

Конечно, большинство пользователей не изучают непосредственно ППС и регламент, а получают информацию о политиках PKI косвенно, из таких дополнений сертификатов, как Certificate Policies, Policy Mappings и Policy Constraints, характеризующих соответственно политики применения сертификатов, соответствие политик разных доменов PKI и ограничения на политики. Каждый идентификатор объекта (в данном случае в качестве объекта выступает политика), указанный в дополнении сертификата, соответствует одной ППС. При разработке ППС ей присваивается уникальный идентификатор объекта. В рамках присвоенного идентификатора допускается лишь незначительное изменение политики. Процедура изменения и способ получения последней информации о ППС содержится в самой политике. Регламенты привязываются к идентификаторам политики через ППС, которую они реализуют. ППС может быть реализована в нескольких регламентах, а один регламент может удовлетворять требованиям нескольких политик.

Рис. 13.1. Реализация одной политики тремя центрами

Пример 13.2. Рассмотрим связи между ППС и регламентами трех разных удостоверяющих центров одной корпоративной PKI, которые выпускают сертификаты в соответствии с одной политикой (рис. 13.1). Каждый УЦ выпускает свои сертификаты согласно политике компании "Альфа" (P_Альфа). Все эти сертификаты содержат один и тот же идентификатор политики в дополнении Certificate Policies. Но каждый УЦ имеет свой собственный регламент, который описывает механизмы и процедуры безопасности, характерные именно для этого центра.

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

Рис. 13.2. Реализация двух политик тремя центрами

Пример 13.3. Для поддержки широкого круга приложений корпоративная PKI может выпускать сертификаты в соответствии с несколькими политиками. Рассмотрим ситуацию, когда компания "Альфа" использует две политики [70]. УЦ подразделения 1 выпускает сертификаты согласно политике P₁, УЦ подразделения 2 - согласно политике P₂, а УЦ подразделения 3 - в соответствии с одной из политик ( P₁ или P₂ ) или согласно обеим политикам P₁ и P₂ (рис. 13.2). Выпуск сертификата для каждой из двух политик целесообразен в том случае, когда каждая политика соответствует приложению определенного типа (например, защищенная электронная почта или подписание электронных договоров). Кроме того, политики могут быть ориентированы на разный уровень гарантий, то есть политика P₁ может иметь низкий уровень гарантий, а политика P₂ - высокий. В этом случае сертификат пользователя должен содержать идентификатор либо политики P₁, либо P₂, но не обеих политик. Приложения для сферы с низкими рисками могут принимать сертификаты, выпущенные в соответствии с политикой P₁ или P₂, а приложения для сферы с высокими рисками могут требовать сертификаты, изданные согласно политике P₂.

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

Пример 13.4. Для пользователей А и B компании "Альфа" их домен политик образуют политики P₁ и P₂. Другие корпоративные PKI могут придерживаться политик, которые эквивалентны политикам домена политик пользователей А и B. Допустим, компания "Бета" имеет один УЦ, который выпускает сертификаты в соответствии с тремя политиками P_выс, P_ср и P_низ, соответствующими разным уровням безопасности (высокому, среднему и низкому). Если пользователи А и B при работе сталкиваются с сертификатами стороннего УЦ, то не способны интерпретировать соответствующие идентификаторы политик и, следовательно, определить, какие сертификаты применимы к их приложениям [70].

Рис. 13.3. Соответствие политик двух компаний

УЦ "Альфа" может перевести информацию о политиках других доменов в информацию, понятную своим пользователям, при помощи дополнения Policy Mappings (соответствие политик) в своем сертификате. Компания "Альфа" может установить следующее соответствие политик: политика P_выс ( "Бета" ) эквивалентна политике P₂ ( "Альфа" ), а политики P_ср и P_низ ( "Бета" ) эквивалентны политике P₁ ( "Альфа" ). Компания "Бета", в свою очередь, может признать политику P₁ ( "Альфа" ) соответствующей политике P_низ ( "Бета" ), политику P₂ ( "Альфа" ) соответствующей политике P_ср ( "Бета" ), но считать, что ни одна из политик компании "Альфа" не соответствует требованиям политики P_выс ( "Бета" ). В результате приложения, для которых подходят сертификаты компании "Бета" с указанием политики P_выс, не смогут работать с сертификатами компании "Альфа".

Рис.13.3 демонстрирует одно из ключевых свойств соответствия политик: взаимное отображение политик разных компаний может быть несимметричным. Компании "Альфа" и "Бета" не должны согласовывать соответствие политик. Пользователи сертификатов каждой компании будут обрабатывать дополнение Policy Mappings в сертификате их собственного УЦ и полагаться на информацию о соответствии политик, предоставляемую удостоверяющими центрами их собственного домена политик.

Краткая характеристика политики PKI

Реальной альтернативой объемным документам, подробно описывающим политику PKI, может стать краткая характеристика политики - документ PDS (PKI Disclosure Statement) [10]. Документ PDS возник как проект группы инженерной поддержки Интернета IETF, затем Американская ассоциация юристов (American Bar Association - ABA) воплотила его идею в соответствующее приложение к своему руководству по оценке инфраструктур открытых ключей - PKI Evaluation Guidelines. Аналогичный документ был разработан также техническим комитетом по безопасности Европейского института стандартов связи (European Telecommunications Standards Institute - ETSI).

Документ, кратко раскрывающий политику PKI, должен занимать не более 2 страниц, в отличие от ППС и регламента, которые обычно излагаются на 8-10 и 40-80 страницах соответственно. PDS описывает самые существенные аспекты деятельности PKI: гарантии, ограничения и юридическую ответственность сторон, он может служить контрольным списком для проверки соответствия практик безопасности двух удостоверяющих центров до вступления их в доверительные отношения. В целом документ PDS больше похож на соглашение с конечным пользователем или владельцем пластиковой карты, чем на обычный документ о политике. Действительно, пользователя среднего уровня подготовки обычно интересует его ответственность в различных ситуациях, а отнюдь не используемые криптографические методы или специфические меры безопасности PKI. Например, тот факт, что для хранения секретного ключа УЦ используется аппаратный ключ (токен), скорее всего, привлечет внимание лишь ограниченного круга лиц, а вот положение об ответственности доверяющей стороны за проверку валидности используемых сертификатов до проведения транзакции заинтересует всех субъектов PKI.

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

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

Как и все другие документы, описывающие политику PKI, PDS не является универсальным. В работе [49] предлагается дополнить список этих документов стандартным шаблоном (XML-таблицей) характеристик политики PKI, что дает возможность свести разработку политики к выбору тех параграфов, которые необходимы конкретной компании, развертывающей PKI, и проставлению в пустых графах соответствующих денежных сумм, временных ограничений и т.п. Этот способ не только дает выигрыш во времени, но и позволяет сравнивать политики разных инфраструктур открытых ключей при кросс-сертификации. Подключение таблицы стиля политики PKI к поисковому механизму дает возможность автоматически анализировать ее структуру. В результате поиска и сравнительного анализа стандартных таблиц, характеризующих политику каждой зарегистрированной PKI, легко установить соответствие политик разных инфраструктур и принять решение о безопасности кросс-сертификации. Этот способ гораздо проще распространенного сегодня бюрократического и трудоемкого метода синхронизации политик PKI.

Лекция 14. Описание политики PKI

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

Набор положений политики PKI

Общие положения

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

Стандарт RFC 2527 Certificate Policy and Certification Practices Framework [152] не обязывает разработчиков политики или регламента называть разделы определенным образом и не устанавливает никаких правил раскрытия положений политики или регламента. Поэтому перечень разделов можно рассматривать как рекомендательный список, позволяющий эффективно сравнивать различные политики применения сертификатов и регламенты при принятии решений о формировании политики. В наборе положений требуется прямо или косвенно (по ссылке) задавать типы спецификаторов политики и их значения, используемые по умолчанию.

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

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

1 обязательства УЦ и/или РЦ:

* уведомление о выпуске сертификата других лиц помимо субъекта сертификата;

* уведомление субъекта сертификата об аннулировании или приостановлении действия его сертификата;

* уведомление других лиц, помимо субъекта сертификата, об аннулировании или приостановлении действия сертификата данного субъекта;

* своевременная публикация сертификатов и информации об аннулировании;

2 обязательства подписчика (владельца сертификата):

* точное информирование о цели использования сертификата при обращении к УЦ с запросом о выдаче сертификата;

* сохранение в тайне секретного ключа;

* использование секретного ключа и сертификата с учетом ограничений политики PKI;

* уведомление о компрометации секретного ключа;

3 обязательства доверяющей стороны:

* использование сертификата только по назначению;

* соблюдение порядка верификации ЭЦП;

* проверка статуса сертификата перед его использованием;

* подтверждение соответствующих пределов ответственности и гарантий.

Раздел Ответственность содержит положения, позволяющие распределять ответственность между всеми субъектами PKI:

1 гарантии и ограничения на гарантии;

2 виды ущерба: случайный ущерб, ущерб по небрежности, убытки (фактические, косвенные, заранее оцененные, штрафные), мошенничество;

3 непризнание ущерба;

4 исключения (например, форс-мажорные обстоятельства, ответственность другой стороны).

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

Рис. 14.1. Набор положений политики PKI

Правовые положения и процедуры решения споров, имеющие отношение к интерпретации и исполнению ППС или регламента, содержатся в одноименном разделе Интерпретация и правоприменение.

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

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

В раздел Аудит деятельности субъектов включены следующие положения:

1 частота проверок для каждого субъекта PKI;

2 личность/квалификация аудитора;

3 отношение аудитора к субъекту;

4 действия, предпринимаемые после обнаружения нарушений в деятельности субъекта;

5 обеспечение и разделение ответственности за нарушения субъекта.

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

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

Специальные разделы

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

* начальная регистрация;

* обычное обновление ключа;

* повторный выпуск ключа после аннулирования;

* запрос об аннулировании ключа.

Подраздел Начальная регистрация содержит положения, относящиеся к процедурам идентификации и аутентификации во время регистрации субъекта или выпуска сертификата:

1 типы имен, присваиваемых субъекту;

2 регулирование многозначности имен;

3 правила интерпретации различных форм имени;

4 регулирование уникальности имен;

5 признание, аутентификация и роль торговых марок;

6 регулирование обязанности субъекта доказывать владение секретным ключом, составляющим пару с зарегистрированным открытым ключом;

7 требования аутентификации организационной принадлежности субъекта (УЦ, РЦ или конечный субъект);

8 требования аутентификации лица, действующего от имени субъекта, в том числе:

* необходимое количество составляющих идентификации;

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

* условия персонального представления физического лица при аутентификации в удостоверяющем или регистрационном центре;

* условия аутентификации юридического лица.

Подразделы Обычное обновление ключа, Повторный выпуск ключа после аннулирования и Запрос об аннулировании описывают процедуры идентификации и аутентификации каждого субъекта (УЦ, РЦ и конечный субъект) при обычном обновлении ключа, повторном выпуске сертификата и обработке запроса об аннулировании сертификата.

Структура раздела Операционные требования представлена на рис. 14.2. В каждом подразделе формулируются требования ко всем субъектам PKI по различным видам операционной активности.

Подраздел Запрос о выдаче сертификата определяет требования к процедуре регистрации субъекта и запросу о выдаче сертификата, подраздел Выпуск сертификата - к выпуску сертификата и процедуре уведомления об этом субъекта, подраздел Принятие сертификата - к процедурам принятия субъектом выпускаемого сертификата и последующей публикации сертификата.

Рис. 14.2. Структура раздела "Операционные требования"

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

Подраздел Приостановление и аннулирование сертификата определяет:

1 условия аннулирования сертификата;

2 круг лиц, имеющих право подавать запрос об аннулировании сертификата субъекта;

3 процедуры формирования запроса об аннулировании сертификата;

4 условия приостановления действия сертификата;

5 круг лиц, имеющих право подавать запрос о приостановлении сертификата субъекта;

6 процедуры формирования запроса о приостановлении сертификата;

7 срок приостановления;

8 частоту выпуска САС;

9 требования к доверяющим сторонам по проверке САС;

10 другие формы объявления об аннулировании сертификата;

11 требования к доверяющим сторонам по проверке других форм объявления об аннулировании сертификата;

12 любые варианты перечисленных выше условий, если приостановление или аннулирование вызваны компрометацией секретного ключа.

Подраздел Контроль безопасности используется для описания систем контроля и регистрации событий, обеспечивающих безопасность среды, и включает следующие элементы:

1 типы регистрируемых событий;

2 частота обработки или проверки контрольных журналов;

3 срок хранения контрольных журналов;

4 защита контрольных журналов от модификации и уничтожения; круг лиц, имеющих к ним доступ;

5 процедуры создания резервных копий контрольных журналов;

6 характеристика системы накопления данных контрольного журнала (внутренняя или внешняя по отношению к субъекту);

7 уведомление об акции контроля субъекта, виновного в нарушении;

8 оценки уязвимости.

Подраздел Архивные записи регламентирует порядок хранения записей в архиве и описывает:

1 типы фиксируемых событий;

2 срок хранения в архиве;

3 защита архива (лица, имеющие доступ к архиву; защита от модификации и уничтожения);

4 процедуры создания резервной копии архива;

5 требования проставления метки времени записей;

6 характеристика системы сбора архива (внутренняя или внешняя);

7 процедуры получения и проверки архивной информации.

Подраздел Смена ключа описывает процедуры обеспечения подписчиков УЦ новыми открытыми ключами. Подраздел Процедуры восстановления в случае компрометации или стихийного бедствия определяет требования к процедурам регистрации и восстановления в случаях: порчи вычислительных ресурсов, программного обеспечения и/или данных, аннулирования открытого ключа субъекта, компрометации ключа субъекта. Эти процедуры регулируют для каждого случая, как переустанавливается безопасная среда, какие сертификаты аннулируются, аннулируется ли ключ субъекта, как пользователи получают новый открытый ключ субъекта, как субъект вновь получает сертификат. Подраздел перечисляет меры УЦ по поддержанию безопасности своего оборудования в течение определенного времени после стихийного или иного бедствия и до переустановки безопасной среды в первоначальном местонахождении УЦ или в удаленном от него месте.

Раздел Контроль физической, процедурной и кадровой безопасности описывает нетехнические аспекты управления безопасностью субъектов PKI в целях безопасного выполнения функций генерации ключей, аутентификации субъектов, выпуска и аннулирования сертификатов, аудита и хранения записей в архиве. Раздел делится на три подраздела: Контроль физической безопасности , Контроль процедурной безопасности и Контроль кадровой безопасности .

Подраздел Контроль физической безопасности задает требования к физической безопасности оборудования систем субъектов PKI:

1 местонахождение и конструкция узла;

2 физический доступ;

3 электропитание и кондиционирование;

4 контроль риска затопления;

5 пожарная охрана и защита;

6 защита среды хранения системы;

7 размещение отходов.

Подраздел Контроль процедурной безопасности устанавливает требования к доверительным должностям, определяет ответственность лиц, работающих на таких должностях. Для каждого задания или процедуры устанавливается круг исполнителей. В подразделе Контроль кадровой безопасности описываются:

1 процедуры проверки уровня благонадежности и компетентности сотрудников, занимающих доверительные должности;

2 процедуры проверки уровня благонадежности и компетентности другого персонала, включая штат охраны;

3 требования и процедуры подготовки для каждой должности;

4 срок и процедуры переподготовки для каждой должности;

5 частота и последовательность смены деятельности внутри должностей;

6 санкции, применяемые к персоналу за несанкционированные действия, превышение полномочий и несанкционированное использование систем субъектов;

7 управление персоналом, работающим по контракту (подписание контракта, требования контракта, аудит и мониторинг деятельности, другие виды контроля);

8 инструкции по работе персонала.

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

Кроме того, раздел регулирует управление безопасностью жизненного цикла сертификатов (в том числе безопасностью среды и методологией разработки надежного программного обеспечения) и управление операционной безопасностью. Структура раздела представлена на рис. 14.3.

Рис. 14.3. Структура раздела "Контроль технической безопасности"

Подраздел Контроль компьютерной безопасности описывает элементы управления компьютерной безопасностью: использование концепции надежной компьютерной базы, дискреционное и мандатное управление доступом, метки, повторное использование объекта, достоверный маршрут, аудит, идентификацию и аутентификацию, тестирование безопасности и вторжений.

Подраздел Генерация и инсталляция пар ключей раскрывает для всех типов субъектов PKI следующие положения:

1 генерация открытого и секретного ключей субъекта;

2 способы доставки:

* секретного ключа субъекту,

* открытого ключа субъекта издателю сертификата,

* открытого ключа УЦ пользователям;

3 размеры ключа;

4 генерация параметров открытого ключа и проверка качества параметров;

5 способ генерации ключа (аппаратный или программный);

6 назначение ключа и ограничения на его использование.

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

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

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

Подраздел Контроль сетевой безопасности регулирует управление сетевой безопасностью среды.

Подраздел Управление прикладным криптографическим модулем описывает следующие аспекты разработки криптографического модуля: идентификацию границ криптографического модуля, ввод/вывод, функции и сервисы, конечный автомат, физическую безопасность, безопасность программного обеспечения и операционной системы, согласованность алгоритма. Требования могут быть выражены ссылкой на определенный стандарт.

В разделе Форматы сертификата и списка аннулированных сертификатов описываются номера поддерживаемых версий сертификатов и САС, профиль и пункт распространения САС, дополнения сертификата, идентификаторы объектов криптографического алгоритма и ППС, указываются типы имен конечных субъектов, удостоверяющих и регистрационных центров и ограничения на имена. Раздел раскрывает использование ограничителей политики, синтаксис и семантику спецификаторов политики, семантику обработки критичной для ведения бизнеса политики.

Раздел Администрирование спецификации регламентирует порядок описания конкретной политики или регламента и задает процедуры изменения спецификации, публикации и уведомления, а также утверждения регламента.

Подраздел Процедуры изменения спецификации содержит следующие элементы:

1 список компонентов, подкомпонентов спецификации и/или их элементов, которые можно изменять без уведомления об этом заинтересованных сторон, не меняя идентификатор объекта ППС ( Object Identifier ) или указатель регламента ;

2 список компонентов, подкомпонентов спецификации и/или их элементов, которые можно изменять после уведомления об этом заинтересованных сторон, не меняя идентификатор объекта ППС ( Object Identifier ) или указатель регламента ;

3 список компонентов, подкомпонентов спецификации и/или их элементов, для которых требуется внесение изменений в идентификатор объекта ППС ( Object Identifier ) или указатель регламента.

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

Перечень набора положений может служить контрольным списком или стандартным образцом для разработчиков ППС или регламента. Такой перечень можно использовать при сравнении:

* двух регламентов ;

* двух политик применения сертификатов на предмет их соответствия во время кросс-сертификации;

* регламента и описания политики для подтверждения того, что регламентов полностью реализует политику.

Трудности разработки политики и регламента

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

В результате документы, описывающие политику PKI, создаются людьми, которые не представляют целостной картины функционирования PKI и опираются на свои предположения и допущения. Встречающиеся в тексте документов неточности и положения, которые можно толковать двояко, подвергают серьезному риску всех субъектов PKI. Например, недооценка важности правильного выбора предельных сумм транзакций может иметь радикальные последствия: если предел установлен слишком низким, необходимые для ведения бизнеса транзакции могут быть отвергнуты, если предел слишком высок, PKI подвергается риску. Лучшим решением при отсутствии специалистов необходимой квалификации является привлечение центра утверждения политики (Policy Approval Authority) - организации, интегрирующей все составляющие политики и руководства в процессе выработки политики PKI (в России такая организация пока не создана).

Среди разработчиков политики PKI широко распространено мнение, что полезность описывающих политику документов напрямую зависит от их объема и степени подробности содержания. Например, политика применения сертификатов, разработанная компанией VeriSign для PKI Trust Network, излагается на 115 страницах, а регламентов занимает 119 страниц [10]. Более того, эти документы изобилуют юридической лексикой. Совершенно ясно, что документы такого объема и сложности находятся за пределами возможностей понимания среднего человека (субъекта или доверяющей стороны) и затрудняют разбор конфликтных ситуаций в суде. Некоторые компании, предоставляющие услуги PKI, поняли это и ищут альтернативные пути разработки более жизнеспособных документов. Так, например, компания VeriSign для сопровождения больших документов предлагает CPS Quick Summary - краткое изложение регламента. Краткое изложение делает документ более понятным для среднего человека, что повышает шансы компании выиграть в суде в случае конфликта между сторонами - субъектами PKI.

Этапы разработки политики применения сертификатов

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

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

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

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

Рис. 14.4. Этапы разработки политики применения сертификатов

Если спектр задач и требований конфиденциальности организации слишком велик, то целесообразно разрабатывать несколько политик. Рассмотрим случай, когда компании необходимо осуществлять финансовые платежи на сумму свыше 1 млн долларов и одновременно поддерживать виртуальную частную сеть для оформления сделок, которые заключаются служащими компании, занимающимися продажами [70]. Конкурентам могут быть интересны полные данные об обороте этой компании, но полезность информации о сделках, заключенных одним продавцом, относительно мала. Политика, которая регулирует применение VPN-сертификатов продавцов, может быть гораздо менее строгой. Рассматриваемая компания не сможет хорошо обслуживаться одной политикой. Если ППС адекватно регулирует использование сертификатов продавцов, то будет подвергаться риску работа бухгалтеров, отвечающих за финансовые транзакции. Если же ППС обеспечивает гарантии безопасного выполнения финансовых транзакций, то выпуск сертификатов для продавцов становится сложным и дорогостоящим. Компания может либо реализовать две разные политики для удовлетворения требований каждого сообщества, либо поддерживать обе в соответствии с более высоким уровнем безопасности. Компании следует проанализировать издержки и доход от реализации каждой стратегии и решить, нужны ли ей две разные политики. Эта информация также может быть полезна для анализа издержек и дохода при страховании ответственности. Оператор УЦ может поддерживать политику страхования в отношении ошибок и оплошности персонала УЦ. Если ценность данных высока или приложения пересекают границы организации, то страхование ответственности должно быть соответствующим.

Второй этап разработки ППС - ознакомление с документом RFC 2527 [152], задающим структуру ППС, и несколькими образцами используемых политик, отвечающих аналогичным (проектируемой политике) требованиям. Если ожидается, что проектируемая PKI будет устанавливать отношения кросс-сертификации с другими PKI, то необходимо изучить профили сертификатов и списков САС этих инфраструктур. Разрабатывая новый профиль сертификатов с учетом профилей сертификатов будущих партнеров, можно избежать проблем функциональной совместимости в дальнейшем. Ключевыми моментами согласования являются криптографические алгоритмы, критичные дополнения и способы распространения информации об аннулировании сертификатов.

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

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

Если организация принимает решение о создании собственного УЦ, то необходимо выбрать такие продукты PKI, которые пригодны для реализации конкретной политики. Выбранный продукт должен удовлетворять всем требованиям, изложенным в таких разделах ППС, как Идентификация и аутентификация, Операционные требования и Технический контроль безопасности. Если не все требования будут учтены, то персоналу УЦ впоследствии придется реализовывать сложные процедуры для преодоления "узких" мест PKI-продукта. Дополнительная сложность регламента повлечет за собой большие затраты на поддержание функционирования.

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

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

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

Лекция 15. Стандарты и спецификации PKI

Приводится классификация стандартов в области PKI, дается краткая характеристика каждой группы стандартов, подробно рассматриваются стандарты Internet X.509 PKI (PKIX), обсуждается терминология и концепции PKIX, дается представление о направлениях стандартизации в области PKI, приводятся примеры национальных и международных инициатив по обеспечению функциональной совместимости PKI-продуктов.

Стандарты в области PKI

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

К первой группе (см. табл. 15.1) можно отнести стандарты серии X, подготовленные Международным Союзом по телекоммуникациям - ITU (International Telecommunications Union), и стандарты Международной организации стандартизации - ISO (International Organization for Standardization), относящиеся к PKI [10]. Они признаны в международном масштабе, содержат описания концепций, моделей и сервиса каталога (X.500) и формализуют процедуру аутентификации (X.509). Стандарт X.509 первоначально предназначался для спецификации аутентификации при использовании в составе сервисов каталога X.500. С течением времени X.509 претерпел ряд изменений, и его последняя (третья) версия была стандартизована группой инженерной поддержки Интернета - Internet Engineering Task Force (IETF). Документ X.509 регулирует хранение информации в каталоге и получение данных аутентификации. Он характеризует криптосистему с открытым ключом как метод сильной аутентификации, который базируется на создании, управлении и свободном доступе к сертификату, связывающему субъекта (пользователя) с его открытым ключом. Синтаксис сертификатов формата Х.509 выражается с помощью особой нотации, так называемой абстрактной синтаксической нотации версии 1 (Abstract Syntax Notation One - ASN.1), которая была предложена комитетом разработчиков стандартов взаимодействия открытых систем OSI (Open System Interconnection) для использования с протоколами X.500. ASN.1 описывает синтаксис различных структур данных, вводя примитивные объекты и средства описания их комбинаций [2]. Форматы электронного сертификата и САС, предложенные X.509, фактически признаны стандартом и получили всеобщее распространение независимо от X.500. Как показало время, наиболее ценной в стандарте X.509 оказалась не сама процедура, а ее служебный элемент - структура сертификата, содержащая имя пользователя, криптографические ключи и сопутствующую информацию [6].

|Номер и название стандарта | Содержание стандарта |

|X.500 | Каталог: обзор концепций, моделей и услуг |

|X.509 | Каталог: структура аутентификации |

|X.509a | Проект изменений и дополнений для продления срока действия сертификатов (расширение версии 3) |

|X.208 (ISO/IEC 8825)

Abstract Syntax Notation (ASN.1)

| Абстрактная синтаксическая нотация |

|X.209 | Основные правила кодирования для ASN.1 |

|ISO/IEC 8824

Object Identifiers (OIDs)

| Идентификаторы объектов |

|ISO/IEC 9594/8

Directory Services (X.509)

| Сервисы каталога (X.509) |

Таблица 15.1.I группа стандартов

Стандарты второй группы (см. табл. 15.2) разработаны основным центром по выпуску согласованных стандартов в области PKI - рабочей группой организации IETF, известной как группа PKIX (от сокращения PKI for X.509 certificates) [10]. Документы PKIX определяют политику применения сертификатов и структуру регламента УЦ, форматы, алгоритмы и идентификаторы сертификата и САС X.509, схему поддержки PKIX в среде LDAP v2, форматы атрибутных сертификатов и сертификатов ограниченного пользования, описывают протоколы статуса сертификатов, запроса на сертификацию, проставления метки времени, эксплуатационные протоколы PKI.

Третью группу образуют стандарты криптографии с открытыми ключами PKCS (Public Key Cryptography Standards), разработанные компанией RSA Security Inc. [102] совместно с неофициальным консорциумом, в состав которого входили компании Apple, Microsoft, DEC, Lotus, Sun и MIT. Документы PKCS признаны симпозиумом разработчиков стандартов взаимодействия открытых систем методом реализации стандартов OSI (Open System Interconnection). Стандарты PKCS (см. табл. 15.3) обеспечивают поддержку криптографических процессов при выполнении защищенного шифрованием информационного обмена между субъектами. Стандарты PKCS ориентированы на двоичные и ASCII-данные и совместимы со стандартом ITU-T X.509. В PKCS входят алгоритмически зависимые и независимые реализации стандартов [217]. Многие из них опираются на систему шифрования с открытыми ключами RSA, названную по инициалам авторов Ривеста, Шамира и Адльмана, метод эллиптических кривых и метод согласования ключей Диффи-Хэллмана, подробно описанные в трех соответствующих криптографических стандартах.

|Номер и название стандарта | Содержание стандарта |

RFC 2510

Certificate Management Protocols (CMP)

| Инфраструктура открытых ключей Интернет X.509: протоколы управления сертификатами |

RFC 2511

Certificate Request Protocol

| Протокол запроса на сертификат |

RFC 2527

Certificate Policy and Certification

Practices Framework

| Политика применения сертификатов и структура регламента |

RFC 2559

LDAP V2 Operational Protocols

| Эксплуатационные протоколы инфраструктуры открытых ключей |

RFC 2560

Online Certificate Status Protocol (OCSP)

| Онлайновый протокол статуса сертификата |

RFC 2585

HTTP/FTP Operations

| Применение протоколов HTTP/FTP для получения сертификатов и САС и репозитория PKI |

RFC 2587

LDAP V2 Schema

| Схема поддержки PKIX в среде LDAP v2 |

RFC 2797

Certificate Management Messages over

CMS (CMC)

| Протокол управления сертификатами на базе сообщений управления сертификатами |

RFC 2875

Diffie-Hellman Proof-of-Possession

(POP) Algorithms

| Алгоритмы Диффи-Хэлмана доказывания владения |

RFC 3029

Data Validation and Certification

Server Protocols

| Протоколы сервера сертификации и проверки достоверности данных |

RFC 3039

Qualified Certificates Profile

| Формат сертификата ограниченного пользования |

RFC 3161

Time-Stamp Protocol (TSP)

| Протокол меток времени |

RFC 3279 (бывший RFC 2528)

Algorithms and Identifiers for the

Internet X.509 Public Key

Infrastructure Certificate and

Certificate Revocation List (CRL) Profile

| Алгоритмы и идентификаторы для профилей сертификатов и САС PKIX |

RFC 3280 (бывший RFC 2459)

Certificate & CRL Profile

| Форматы сертификата и списка аннулированных сертификатов X.509 |

RFC 3281

An Internet Attribute Certificate

Profile for Authorization

| Формат атрибутного сертификата для авторизации |

Таблица 15.2.II группа стандартов

|Номер и название стандарта | Содержание стандарта |

PKCS#1

RSA Cryptography

| Механизмы шифрования и подписания данных методом RSA.

Примечание:Стандарты PKCS #2 and PKCS #4 были объединены в PKCS #1

PKCS #3

Diffie-Hellman Key Agreement

| Согласование ключей методом Диффи-Хеллмана |

PKCS #5

Password-Based Cryptography

| Шифрование секретным ключом, созданным на основе пароля |

PKCS #6

Extended-Certificate Syntax

| Синтаксис расширенного сертификата |

PKCS#7

Cryptographic Message Syntax

| Синтаксис криптографических сообщений |

PKCS #8

Private-Key Information Syntax

| Синтаксис данных секретного ключа |

PKCS #9

Selected Attribute Types

| Особые типы атрибутов для использования в других PKCS-стандартах |

PKCS#10 (RFC2314)

Certification Request Syntax

| Стандарт синтаксиса запроса на сертификацию |

PKCS#11

Cryptographic Token Interface (Cryptoki)

| Прикладной программный интерфейс Cryptoki для криптографических устройств типа смарт-карт и карт PCMCIA |

PKCS #12

Personal Information Exchange Syntax

| Синтаксис обмена персональными данными пользователя (секретными ключами, различными тайнами и т.п.) |

PKCS #13

Elliptic Curve Cryptography

| Механизмы шифрования и подписания данных методом эллиптических кривых |

PKCS #15

Cryptographic Token Information Format

| Формат данных, хранящихся на криптографических токенах (является дополнением к PKCS #11) |

Таблица 15.3.III группа стандартов

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

В четвертую группу объединены дополнительные связанные с PKI стандарты LDAP, S/MIME, S/HTTP, TLS, IPsec, DNS и SET (см. табл. 15.4). Стандарты LDAP описывают упрощенный протокол доступа, позволяющий вводить, удалять, изменять и извлекать информацию, которая содержится в каталогах X.500. В настоящее время LDAP является стандартным методом доступа к информации сетевых каталогов и играет важную роль во множестве продуктов, таких как системы аутентификации, PKI, приложения электронной почты и электронной коммерции.

Стандарты S/MIME (Secure/Multipurpose Internet Mail Extensions) предназначены для обеспечения защищенного обмена сообщениями в Интернете. Протокол защищенной электронной почты S/MIME базируется на технологии шифрования и цифровой подписи, разработанной компанией RSA Security Inc., и используется для предупреждения возможного перехвата или подделки почтовых сообщений [209]. Семейство стандартов S/MIME описывает синтаксис криптографических сообщений, управление сертификатами в среде S/MIME, процедуры и атрибуты дополнительных сервисов безопасности для почтовых приложений, к которым относятся заверенные цифровой подписью уведомления о приеме сообщений, метки безопасности и защищенные списки рассылки электронной почты.

К стандартам S/HTTP и TLS относятся документы, определяющие защищенный протокол передачи гипертекста HTTP и его расширения, протокол безопасности транспортного уровня TLS, его модификацию и использование в среде HTTP. TLS - открытый стандарт, разработанный на базе протокола защищенного обмена информацией между клиентом и сервером SSL (Secure Sockets Layer) в качестве его замены для защиты коммуникаций в Интернете. Протокол TLS обеспечивает конфиденциальность и целостность данных при коммуникации двух приложений и позволяет приложениям "клиент-сервер" взаимодействовать защищенным способом, предотвращающим перехват информации и подделку сообщений. Для взаимной аутентификации перед началом информационного взаимодействия приложениями используется технология PKI.

|Номер и название стандарта | Содержание стандарта |

|LDAP |

RFC 1777: Lightweight Directory Access

Protocol

| Упрощенный протокол доступа к каталогу |

RFC 1823: The LDAP Application Program

Interface

| Интерфейс прикладного программирования протокола LDAP |

RFC 2251: Lightweight Directory Access

Protocol (v3)

| Упрощенный протокол доступа к каталогу (версия 3) |

RFC 2252: Lightweight Directory Access

Protocol (v3): Attribute definition

| Описание атрибутов протокола LDAP (версия 3) |

RFC 2253: Lightweight Directory Access

LDAP

Protocol (v3): UTF-8 String

Representation of Distinguished Names

| Представление отличительных имен в протоколе LDAP (версия 3) |

RFC 2254: Lightweight Directory Access

Protocol (v3) The String

Representation of LDAP Search Filters

| Строковое представление фильтров поиска в протоколе LDAP (версия 3) |

RFC 2255: Lightweight Directory Access

Protocol (v3) The LDAP URL Format

| URL-формат протокола LDAP (версия 3) |

|S/MIME |

RFC 2311

S/MIME Version 2 Message Specification

| Спецификация сообщений S/MIME версии 2 |

RFC 2312

S/MIMEv2 Certificate Handling

| Управление сертификатами S/MIME версии 2 |

RFC 2630

Cryptographic Message Syntax (CMS)

| Синтаксис криптографических сообщений |

RFC 2632

S/MIME V3 Certificate Handling

| Управление сертификатами S/MIME версии 3 |

RFC 2633

S/MIME V3 Message Specification

| Спецификация сообщений S/MIME версии 3 |

S/MIMERFC 2634

Enhanced Security Services for S/MIME

| Сервисы безопасности для S/MIME |

RFC 2785

Methods for Avoiding the "Small-

Subgroup" Attacks on the Diffie-Hellman

Key Agreement Method for S/MIME

| Методы отражения атак на основе метода согласования ключей Диффи-Хэллмана для S/MIME |

RFC 3369 S/MIME Cryptographic Message

Syntax

| Синтаксис криптографических сообщений в S/MIME |

|S/HTTP TLS |

RFC 2246

TLS Protocol Version 1.0

| Протокол безопасности транспортного уровня TLS версии 1 |

RFC 2659

Security Extensions For HTML

| Расширения безопасности для протокола передачи гипертекста HTTP |

RFC 2660

S/HTTP TLS

The Secure HyperText Transfer Protocol

| Защищенный протокол HTTP |

RFC 2817

Upgrading to TLS Within HTTP

| Модификация протокола TLS в среде HTTP |

RFC 2818

HTTP Over TLS

| Использование протокола TLS для защищенных HTTP-соединений через Интернет |

|IPsec |

RFC 2401

Security Architecture for the Internet

Protocol

| Архитектура безопасности Интернет-протокола |

RFC 2402

IP Authentication Header

| Протокол аутентифицирующего заголовка |

IPsecRFC 2406

IP Encapsulating Security Payload (ESP)

| Протокол инкапсулирующей защиты содержимого IP-пакетов |

RFC 2408

Internet Security Association and Key

Management Protocol (ISAKMP)

| Интернет-протокол управления ключами и контекстами безопасности |

|DNS |

RFC 2137

Secure Domain Name System Dynamic Update

| Динамическое обновление защищенной системы доменных имен |

RFC 2535

Domain Name System Security Extensions

| Расширения системы доменных имен |

RFC 2536

DSA KEYs and SIGs in the Domain Name

System

| DSA-ключи и подписи в системе доменных имен |

RFC 2537

RSA/MD5 KEYs and SIGs in the Domain

Name System

| RSA/MD5-ключи и подписи в системе доменных имен |

DNSRFC 2538

Storing Certificates in the Domain

Name System

| Хранение сертификатов в системе доменных имен |

RFC 2539

Storage of Diffie-Hellman Keys in the

Domain Name System

| Хранение ключей Диффи-Хэллмана в системе доменных имен |

RFC 2540

Detached Domain Name System Information

| Отделенная информация системы доменных имен |

RFC 2541

DNS Security Operational Considerations

| Операционные требования безопасности службы доменных имен |

|SET |

Secure Electronic Transaction

Specification The Business Description

| Защищенные электронные транзакции. Спецификация: Описание бизнеса |

Secure Electronic Transaction

The Specification Programmer's Guide

SET

| Защищенные электронные транзакции. Спецификация: Руководство программиста |

Secure Electronic Transaction

Specification Formal Protocol Definition

| Защищенные электронные транзакции. Спецификация: Описание формального протокола |

Таблица 15.4.IV группа стандартов

Рис. 15.1. Взаимосвязь стандартов в области PKI

Стандарты семейства IPsec описывают архитектуру безопасности Интернет-протоколов (IP), регламентируют контроль целостности на уровне IP-пакетов, аутентификацию источника данных и защиту от воспроизведения ранее посланных IP-пакетов, обеспечение конфиденциальности при помощи шифрования содержимого IP-пакетов, а также частичную защиту от анализа трафика путем применения туннельного режима [216]. Документы RFC, относящиеся к IPsec, содержат описания протокола аутентифицирующего заголовка, протокола инкапсулирующей защиты содержимого IP-пакетов и протокола управления ключами и контекстами безопасности. Стандарты IPsec обеспечивают конфиденциальность, целостность и достоверность данных, передаваемых через открытые IP-сети.

Стандарты DNS определяют механизмы, обеспечивающие безопасность данных инфраструктуры системы доменных имен DNS. Документы описывают операционные требования безопасности системы, методы хранения сертификатов и ключей Диффи-Хэллмана, динамическое обновление защищенной системы DNS, механизм защиты передаваемых данных с помощью алгоритма MD5, DSA и RSA-ключей и цифровых подписей. Для обеспечения достоверной передачи DNS-данных в масштабе Интернета в систему DNS вводятся расширения DNSSEC, задаваемые соответствующим стандартом.

Спецификация SET предлагает инфраструктуру для защиты от подделок платежных карт, используемых для транзакций электронной коммерции в Интернете, описывает систему аутентификации участников расчетов, которая базируется на PKI [2]. Принципы SET излагаются в трех книгах, содержащих сведения о правилах ведения бизнеса на базе защищенных электронных транзакций, руководство программиста и формальное описание протокола SET. Рис. 15.1 иллюстрирует взаимосвязь стандартов в области PKI [10].

Итак, базой для разработки стандартов в области PKI стали стандарты серии X.500 (хотя не все их наименования начинаются с X.5xx) Международного союза электросвязи (ITU), предложившие стандартную структуру баз данных, записи в которых содержали информацию о пользователях [3]. Стандарт X.509 ITU-T является фундаментальным стандартом, который лежит в основе всех остальных, используемых в PKI. Однако X.509 ITU-T не описывает полностью технологию PKI. В целях применения стандартов X.509 в повседневной практике комитеты по стандартизации, пользователи, поставщики программных продуктов и сервисов PKI обращаются к семейству стандартов PKIX.

Стандарты Internet X.509 PKI (PKIX)

Терминология и концепции PKIX

Стандарты PKIX для описания инфраструктур используют сходные понятия " инфраструктура открытых ключей PKI " и " инфраструктура управления привилегиями PMI " (Privilege Management Infrastructure). Главное отличие между ними заключается в том, что PKI управляет сертификатами открытых ключей, а PMI - атрибутными сертификатами. Сертификат открытого ключа можно сравнить с паспортом субъекта, а атрибутный сертификат - с визой, первый обеспечивает идентификацию личности, а второй дает определенное разрешение. Основные термины и аббревиатуры, используемые в стандартах PKIX, а также их аналоги на русском языке приведены в табл. 15.5.

Системы, использующие сертификаты, и PKI

Результатом усилий технических специалистов по повышению безопасности Интернета стала разработка группы протоколов безопасности, таких как S/MIME, TLS и IPsec. Все эти протоколы используют криптографию с открытыми ключами для обеспечения сервисов конфиденциальности, целостности данных, аутентификации источника данных и неотказуемости.

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

|Термин на английском языке | Аббревиатура | Термин на русском языке |

|Attribute Authority | AA | Атрибутный центр |

|Attribute Certificate | AC | Атрибутный сертификат |

|Certificate | | Сертификат |

|Certification Authority | CA | Удостоверяющий центр (УЦ) |

|Certificate Policy | CP | Политика применения сертификатов (ППС) |

|Certification Practice Statement | CPS | Регламент УЦ |

|End-Entity | EE | Конечный субъект |

|Public Key Certificate | PKC | Сертификат открытого ключа |

|Public Key Infrastructure | PKI | Инфраструктура открытых ключей |

|Privilege Management Infrastructure | PMI | Инфраструктура управления привилегиями |

|Registration Authority | RA | Регистрационный центр (РЦ) |

|Relying Party | | Доверяющая сторона |

|Root CA | | Корневой УЦ |

|Subordinate CA | | Подчиненный УЦ |

|Subject | | Субъект |

|Top CA | | УЦ верхнего уровня |

Таблица 15.5.Термины PKIX

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

|Компонент | Описание |

|Удостоверяющие центры (УЦ) | Выпускают и аннулируют сертификаты |

|Регистрационные центры (РЦ) | Подтверждают связывание открытых ключей и личностей владельцев сертификатов и других атрибутов |

|Владельцы сертификатов | Подписывают и шифруют электронные документы |

|Клиенты | Проверяют подлинность цифровых подписей и соответствующих цепочек сертификатов при помощи открытого ключа доверенного УЦ |

|Репозитории | Хранят и предоставляют информацию о сертификатах и списках САС |

Таблица 15.6.Компоненты PKI

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

1 информация, идентифицирующая отправителя, соответствовала данным, содержащимся в сертификате;

2 ни один сертификат из цепочки сертификатов не был аннулирован, и в момент подписания сообщения все сертификаты были действительными;

3 сертификат использовался отправителем по назначению;

4 данные не были изменены с момента создания ЭЦП.

После валидации получатель может принять данные, подписанные отправителем.

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

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

Рис. 15.2. Схема функционирования PKI

Операционные протоколы - это протоколы для доставки сертификатов (или информации об их статусе) и списков аннулированных сертификатов к клиентским системам, использующим сертификаты. Существуют разнообразные механизмы распространения сертификатов и САС с использованием протоколов LDAP, HTTP и FTP. Например, поиск САС для проверки статуса сертификата осуществляет операционный протокол.

Протоколы управления необходимы для поддержки взаимодействий в онлайновом режиме между пользователем PKI и субъектами управления.

Протоколы управления поддерживают:

1 регистрацию субъекта для получения сертификата;

2 инициализацию (например, генерации пары ключей);

3 выпуск сертификата;

4 восстановление пары ключей;

5 обновление пары ключей по истечении срока действия сертификата;

6 обращение с запросом об аннулировании сертификата;

7 кросс-сертификацию, когда два удостоверяющих центра обмениваются информацией для генерации кросс-сертификата.

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

Системы, использующие сертификаты, и PMI

Многие системы используют сертификаты открытых ключей для принятия решений по управлению доступом, основанному на идентификации. Такие решения принимаются только после того, как пользователь докажет, что имеет доступ к секретному ключу, который соответствует открытому ключу, содержащемуся в сертификате.

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

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

Согласно стандартам PKIX, PMI представляет собой комплекс программного и аппаратного обеспечения, кадров, а также политик и процедур, необходимых для создания, управления, хранения и аннулирования атрибутных сертификатов. Компоненты PMI представлены в табл. 15.7.

|Компонент | Описание |

|Атрибутные центры (АЦ) | Издатели атрибутных сертификатов. Выпускают и аннулируют атрибутные сертификаты |

|Пользователи атрибутных сертификатов | Анализируют или обрабатывают атрибутные сертификаты (АС) |

|Верификаторы атрибутных сертификатов | Подписывают и шифруют электронные документы |

|Клиенты | Запрашивают действие, для которого должна быть сделана проверка авторизации |

|Репозиторий | Хранит и предоставляет информацию о сертификатах и САС |

Таблица 15.7.Компоненты PKI

Направления стандартизации

Группа PKIX IETF разрабатывает документы для следующих направлений стандартизации:

1 профили сертификатов и списков аннулированных сертификатов;

2 протоколы управления ;

3 операционные протоколы ;

4 политики применения сертификатов и регламенты;

5 сервисы проставления меток времени и сертификации/валидации данных.

К первому направлению относятся стандарты RFC 3280 [167], RFC 3281 [168], RFC 3039 [164] и RFC 3279 [166]. Стандарт RFC 3280 (бывший RFC 2459) Certificate & CRL Profile предлагает форматы сертификатов версии X.509 v3 и списка аннулированных сертификатов версии X.509 v2 для использования в Интернете, детализирует информацию, относящуюся к формам имен и стандартным дополнениям. Документ описывает алгоритм проверки цепочек сертификатов и форматы открытых ключей и электронной цифровой подписи для алгоритмов шифрования ключей RSA, DSA и Диффи-Хэллмана.

Стандарт RFC 3281An Internet Attribute Certificate Profile for Authorization определяет профиль атрибутного сертификата для использования в Интернет-протоколах. Атрибутный сертификат подобен сертификату открытого ключа, но в отличие от него содержит не открытый ключ, а атрибуты, характеризующие его владельца: принадлежность к какой-либо группе, роль, полномочия, уровень прозрачности информации о владельце и т.п. Стандарт обеспечивает поддержку атрибутных сертификатов для электронной почты в Интернете, протокола IPsec, приложений безопасности World Wide Web.

Стандарт RFC 3039 Qualified Certificates Profile описывает формат сертификата ограниченного использования. Владельцем этого сертификата может быть только физическое лицо. Термин "ограниченное использование" трактуется в общепринятом для государственного права смысле. Пока стандарт определяет основной синтаксис сертификата ограниченного использования без учета особенностей законодательства разных стран.

Стандарт RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key In-frastructure Certificate and Certificate Revocation List (CRL) Profile определяет идентификаторы алгоритмов и форматы шифрования используемых в PKIX открытых ключей и цифровых подписей, односторонние хэш-функции для генерации ЭЦП сертификатов и САС. Стандарт описывает шифрование цифровых подписей, сгенерированных при помощи криптографических алгоритмов RSA, DSA и алгоритма эллиптических кривых (ECDSA), задает форматы шифрования открытых ключей, используемых в криптографических алгоритмах RSA, DSA, Диффи-Хеллмана и алгоритма шифрования ключей (KEA).

Второе направление представлено документами RFC 2510 [150], RFC 2511 [151], RFC 2560 [155] и RFC 2797 [160]. Стандарты RFC 2510 Certificate Management Protocols (CMP) и RFC2511 Certificate Request Protocol определяют соответственно сообщения протоколов для процессов создания и управления сертификатами и синтаксис запроса на выпуск сертификата формата X.509.

Стандарт RFC 2560 Online Certificate Status Protocol (OCSP) предлагает онлайновый протокол для определения статуса сертификата без использования САС. По замыслу разработчиков, этот протокол должен удовлетворять операционным требованиям более своевременного поступления информации об аннулировании, чем это возможно при помощи САС. Протокол управляет обменом данными между OCSP-клиентами, проверяющими статус сертификата, и OCSP-исполнителем, информирующим об этом статусе.

Стандарт RFC 2797 Certificate Management Messages over CMS определяет протокол управления сертификатами на основе сообщений управления сертификатами. Документ разрабатывался для решения двух важных проблем сообщества PKI в Интернете:

1 реализации интерфейса с продуктами и сервисами PKI, базирующимися на сообщениях управления сертификатами и стандарте синтаксиса запроса на сертификат - PKCS#10;

2 использования стандарта SMIME v3 в протоколе регистрации сертификатов открытых ключей (Диффи-Хеллмана), подписанных при помощи алгоритма DSA.

К третьему направлению можно отнести документы RFC 2559 [154], RFC 2587 [157] и RFC 2585 [156].

Стандарт RFC 2559 LDAP V2 Operational Protocols закрепляет использование протокола LDAP v2 для обеспечения доступа к репозиторию с целью поиска сертификатов и другой релевантной PKI информации и управления ими.

Стандарт RFC 2587 LDAP V2 Schema описывает минимально необходимую схему поддержки PKIX в среде LDAP v2 (как этого требует документ RFC 2559) и определяет только специфические PKIX-компоненты. В соответствии с этим документом серверы LDAP, действующие как хранилища (репозитории) PKIX, должны поддерживать вспомогательные классы объектов, определенные данным стандартом, и интегрировать эту схему с общими и специфическими для приложений схемами в зависимости от сервисов, предоставляемых сервером.

Документ RFC 2585 HTTP/FTP Operations описывает применение протоколов HTTP/FTP для получения сертификатов и списков аннулированных сертификатов из репозитория УЦ.

Четвертое направление представлено одним базовым стандартом RFC 2527 Certificate Policy and Certification Practices Framework [152], определяющим политику применения сертификатов и структуру регламента УЦ и подробно описанным в лекции 14.

К пятому направлению стандартизации относятся документы RFC 3029 [163], RFC 2875 [162], RFC 3161 [165]. Стандарт RFC 3029 Data Validation and Certification Server Protocols вводит понятие сервера сертификации и проверки достоверности данных для обеспечения надежности сервисов неотказуемости и предлагает протоколы для взаимодействия с этим сервером. На сервер возлагаются функции доверенной третьей стороны, проверяющей подлинность сертификатов открытых ключей и документов с цифровой подписью.

Стандарт RFC 2875 Diffie-Hellman Proof-of-Possession (POP) Algorithms описывает два метода получения значения проверки целостности на основе пары ключей Диффи-Хэллмана. В документе предлагаются два алгоритма доказывания владения, использующие процесс согласования ключей Диффи-Хеллмана для получения разделенного секрета на основе значения проверки целостности. В первом алгоритме значение формируется для конкретного получателя/верификатора при помощи открытого ключа этого верификатора. Во втором алгоритме значение формируется для произвольного верификатора. Документ RFC 3161 Time-Stamp Protocol (TSP) описывает протокол проставления метки времени.

Роль стандартов, профилей и тестирования функциональной совместимости

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

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

1 поскольку работа в органах стандартизации обычно ведется на добровольной основе, не существует профессионалов, специализирующихся исключительно на разработке стандартов;

2 часто в стандартах делается попытка объединить несколько точек зрения разных специалистов, и компромисс достигается либо за счет спецификации опций, либо за счет рассмотрения ряда вопросов на обобщенном уровне;

3 иногда существует очень небольшой или противоречивый опыт реализации в сфере приложения стандарта, поэтому он не может быть должным образом учтен в стандарте;

4 не все подразделения органов стандартизации способны разрабатывать документы равного качества, важную роль играет состав и правила участия специалистов, утвержденные главным государственным органом стандартизации;

5 очень редко предлагаемое решение является оптимальным для разных сред, поэтому сохраняется тенденция продвижения спецификации множества решений, удовлетворяющих потребностям множества целевых доменов;

6 иногда некоторые положения стандартов неправильно интерпретируются и/или даже стандарт неправильно реализуется;

7 наиболее сложные проблемы совместимости порождает общепринятая практика включения в стандарты механизмов расширения их возможностей, с тем чтобы стандарты сохраняли адекватность при изменении обстоятельств и возникновении новых потребностей реальной жизни.

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

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

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

Инициативы по обеспечению функциональной совместимости PKI-продуктов

Национальные инициативы

К числу наиболее известных национальных инициатив по обеспечению функциональной совместимости можно отнести инициативы США: Automotive Network eXchange, Bridge CA Demonstration, проект федеральной PKI, инициативу разработки спецификации минимальной функциональной совместимости MISPC, а также проект национальной ассоциации автоматизированных клиринговых палат США [44].

Automotive Network eXchange

В рамках инициативы Automotive Network eXchange (ANX) на основе технологии виртуальных частных сетей была спроектирована общая сеть компаний-производителей автомобилей для обеспечения защищенных коммуникаций между ними. В ходе реализации проекта был разработаны профили сертификатов и списков САС, которые включены как приложение в документ, названный политикой применения сертификатов ANX [94].

Bridge CA Demonstration

По инициативе правительства США в 1999-2001 гг. был реализован проект демонстрации мостового УЦ - Bridge CA Demonstration с целью показать возможности функциональной совместимости двух (или более) доменов PKI, основанных на разных моделях доверия. В ходе выполнения проекта была сделана попытка доказать, что один УЦ способен действовать как мост между несколькими доменами PKI. Деятельность по разработке профилей включала создание минимального профиля сертификата и САС, схемы каталога и профиля функциональной совместимости, были также утверждены процессы построения и валидации путей сертификации [210].

Федеральная PKI

В октябре 1994 г. федеральное правительство США создало техническую рабочую группу по PKI (PKI-TWG) для решения проблем реализации федеральной инфраструктуры открытых ключей (FPKI). Рабочая группа действовала под руководством национального института по стандартам и технологии США - National Institute of Standards and Technology (NIST) и состояла из представителей федеральных агентств. Она разработала профиль дополнений сертификата и САС федеральной инфраструктуры, названный Federal Public Key Infrastructure Certificate and CRL Extensions Profile [206].

Спецификация минимальной функциональной совместимости

В 1996 г. институт NIST совместно с рядом поставщиков продуктов, лидирующих на рынке PKI - AT&T, IREBBN, Motorola Certicom, Nortel (Entrust), Cylink, Spyrus, DynCorp и VeriSign, - выступил с инициативой разработки спецификации минимальной функциональной совместимости. Первая версия спецификации "Minimum Interoperability Specification for PKI components, Version 1" была опубликована в июне 1997 г. [51] и содержала ссылку на реализацию, пригодную для тестирования соответствия компонентов PKI профилю минимальной функциональной совместимости. Этот документ позволил сообществу поставщиков демонстрировать соответствие их PKI-продуктов требованиям профиля.

Работа над спецификацией продолжалась, и в августе 2001 г. была опубликована вторая версия документа, названная "Minimum Interoperability Specification for PKI components, Version 2 - Second Draft" [92]. Она объединяет некоторые работы группы IETF PKIX, опубликованные в 1998-2001 гг. (в частности, RFC 2459, RFC 2510 и RFC 2511), и дополняет первую версию положениями о поддержке сервисов конфиденциальности.

Проект национальной ассоциации автоматизированных клиринговых палат

Национальная ассоциация автоматизированных клиринговых палат США (National Automated Clearing House Association - NACHA) финансировала успешный проект функциональной совместимости удостоверяющих центров CA Interoperability Pilot, завершенный в октябре 1998 г. Участниками проекта были такие известные компании, как CertCo, Digital Signature Trust (DST), Entrust, GTE CyberTrust, IBM и VeriSign. В качестве базовой модели PKI в пилотном проекте была выбрана четырехсторонняя модель (см. лекцию 5), имитирующая приобретение товаров и услуг через Интернет. Посредниками сделок между покупателем и продавцом выступали банки каждой из сторон, которые действовали как самостоятельные удостоверяющие центры. Все решения относительно финансовых транзакций должны были инициироваться банками.

С технологической точки зрения, главной целью проекта была демонстрация пригодности PKI-продуктов многих поставщиков для реализации предложенной модели, поэтому банки-участники проекта использовали разные программные продукты для поддержки УЦ, предоставленные поставщиками технологии. В дальнейшем поставщики - участники проекта совместно работали над созданием профилей сертификата и САС, и тестирование функциональной совместимости выполнялось для этих профилей. Результаты этой работы были опубликованы в документе "Функциональная совместимость удостоверяющих центров: от концепции к реальности" [90].

Апробация концепции SIRCA

Апробация концепции головного УЦ отрасли средств безопасности Securities Industry Root CA (SIRCA) [110] выполнялась Ассоциацией отрасли средств безопасности США Securities Industry Association вместе с компаниями Digital Signature Trust (DST) и ABAecom. УЦ отрасли действовал как головной центр в двухуровневой иерархии и служил источником доверия для доверяющих сторон - фирм, занимающихся бизнесом в сфере средств безопасности. Каждая из двадцати фирм - участников проекта организовала свой УЦ, связанный с головным УЦ отрасли, а затем выпускала и подписывала цифровые сертификаты для своих служащих, для того чтобы они могли защищенно обмениваться сообщениями электронной почты с партнерами по бизнесу из других фирм.

Концепция SIRCA, аналогичная концепции мостового УЦ, по-своему реализовала установление отношений доверия между многими доменами PKI, которое, в противном случае, потребовало бы заключения двусторонних соглашений о кросс-сертификации каждого домена с каждым. В ходе апробации использовался относительно простой профиль сертификатов: приложение защищенной электронной почты S/MIME v2 профилировалось в том смысле, что выполнялось требование, чтобы в каждое заверенное цифровой подписью сообщение включался полный список сертификатов, необходимых для проверки пути сертификации.

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

Международные инициативы

PKI X.509

Как уже отмечалось выше, ведущим центром по выпуску согласованных стандартов в области PKI является рабочая группа PKIX организации IETF. Профиль сертификата и САС, который был описан в документе RFC 2459, известном как первая часть PKIX, стал предложенным стандартом в январе 1999 года, а затем дополнен и заменен в апреле 2002 года документом RFC 3280. RFC 3280 ввел в формат сертификата и САС дополнения, которые содержат информацию, позволяющую клиентскому программному обеспечению определять местонахождение УЦ и репозитория. Многие специалисты в области PKI признают разработку стандарта RFC 2459 поворотным моментом в развитии инфраструктур открытых ключей, способствовавшим созданию функционально совместимых PKI-продуктов (более подробная информация о документах группы PKIX приведена в разделе "Стандарты Internet X.509 PKI").

Проект EEMA PKI Challenge

Европейский Форум по электронному бизнесу (European Forum for Electronic Business - EEMA) с начала января 2001 года выполнял двухлетний проект PKI Challenge (pkiC), который финансировали Европейский Союз и правительство Швеции [211]. К участию в проекте помимо 13 организаций, входящих в состав Форума, были привлечены поставщики PKI-продуктов, пользователи, консультанты, академические институты, поставщики услуг по выпуску и поддержке цифровых сертификатов для выработки решений по обеспечению функциональной совместимости PKI-продуктов. Рекомендации, выработанные в результате реализации проекта, приведены в табл. 15.8.

|Компонент PKI | Рекомендация |

|УЦ | УЦ должен публиковать списки аннулированных сертификатов (САС) в соответствии со стандартом X.509 v2.

В сертификатах должно присутствовать дополнение CRL Distribution Points, где перечислены пункты распространения САС.

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

Для автоматической регистрации конечных пользователей должен поддерживаться, по крайней мере, протокол Simple CMP

|Репозиторий | Предпочтительно использование репозитория типа X.500, доступ к которому осуществляется по протоколу LDAP.

Поставщикам следует ориентироваться на поддержку LDAP v3.

Необходимо поддерживать следующий минимальный набор компонентов отличительного имени Distinguished Name (DN):

* C (страна);

* L (местонахождение);

* O (организация);

* OU (подразделение организации);

* CN (общее имя);

* DC (компонент домена).

Поставщикам следует реализовать и протестировать дополнения, введенные стандартом RFC 3280, которые содержат информацию о местонахождении удостоверяющих центров Authority Information Access и репозиториев Subject Information Access

|OCSP-респондер | Ответ OCSP-респондера может быть подписан одним из следующих ключей:

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

2 ключом, выпущенным для OCSP-респондера вместе с соответствующим сертификатом открытого ключа, который имеет в поле дополнения Extended Key Usage параметр OCSP-Signing. Этот сертификат должен быть выпущен тем же УЦ, который издал сертификат, подлежащий валидации;

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

Те поставщики, которые пока не реализовали поддержку OCSP-ответа, должны ориентироваться на второй вариант

|Клиентское ПО | Клиентское ПО конечного субъекта должно иметь возможность:

* генерировать пару ключей для регистрации;

* управлять содержимым локального репозитория, предназначенного для хранения копий сертификатов корневого УЦ, списков САС и сертификатов корреспондентов;

* локально управлять идентификационными данными субъекта, а также предлагать средства дистанционного управления ими через УЦ

|PKI-совместимые приложения | Приложения, использующие PKI, должны:

* работать с файловыми форматами PKCS#10, PKCS#7 и PKCS#11, а также поддерживать либо протокол PKIX-CMP, либо CMC;

* иметь возможность выполнять поиск в каталоге LDAP или любом LDAP-совместимом каталоге;

* понимать дополнения сертификатов, связывающих сертификат с той PKI, которая его поддерживает (т.е. crl Distribution Point, authority Information Access, Subject Information Access)

Таблица 15.8.Рекомендации проекта pkiC Европейского Форума по электронному бизнесу

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

|Стандарты PKIX |

RFC 2459/RFC 3280: Internet X.509 Public Key

Infrastructure Certificate and Certificate Revocation

List (CRL) Profile

RFC 2510: Internet X.509 Public Key Infrastructure

Certificate Management Protocols

RFC 2511: Internet X.509 Certificate Request Message

Format

RFC 2511 bis Internet X.509 Certificate Request

Message Format

RFC 2797: Certificate Management Messages over

CMS

RFC 2559: Internet X.509 Public Key Infrastructure

Operational Protocols - LDAP v2

RFC 2587: Internet X.509 Public Key Infrastructure

LDAP v2 Schema

RFC 3279: Algorithms and Identifiers for the Internet

X.509 Public Key Infrastructure Certificate and

Certificate Revocation List (CRL) Profile

|Стандарты PKCS |

PKCS#1: RSA Cryptography Standard

PKCS#7: Cryptographic Message Syntax Standard

PKCS#10: Certification Request Syntax Standard

PKCS#11: Cryptographic Token Interface Standard

PKCS#12: Personal Information Exchange Syntax

Standard

PKCS#15: Cryptographic Token Information Format

Standard

|Дополнительные стандарты |

RFC 1777: Lightweight Directory Access Protocol

RFC 1823: The LDAP Application Program Interface

RFC 2251: Lightweight Directory Access Protocol (v3)

RFC 2252: Lightweight Directory Access Protocol

(v3): Attribute definition

RFC 2253: Lightweight Directory Access Protocol (v3):

UTF-8 String Representation of Distinguished Names

RFC 2254: Lightweight Directory Access Protocol (v3)

The String Representation of LDAP Search Filters

RFC 2255: Lightweight Directory Access Protocol (v3)

The LDAP URL Format

RFC 3369: S/MIME Cryptographic Message Syntax

|Проекты стандартов |

Draft RFC2510 bis: Internet X.509 Public Key

Infrastructure Certificate Management Protocols

Draft: Internet X.509 Public Key Infrastructure LDAP

v2 Schema for X.509 CRLs

Draft: Internet X.509 Public Key Infrastructure LDAP

v2 Schema for X.509 Attribute Certificates

Draft: LDAP v3 DN strings for use with PKIs

Таблица 15.9.Рекомендуемый список поддерживаемых стандартов

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

Лекция 16. Сервисы, базирующиеся на PKI

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

Сервисы, базирующиеся на PKI

В предыдущей главе обсуждались главные сервисы безопасности, предлагаемые PKI: аутентификация, целостность и конфиденциальность. Настоящая глава посвящена сервисам, которые не являются фундаментальными сервисами любой PKI, но могут быть построены на базе PKI. К дополнительным, базирующимся на PKI сервисам относятся:

* защищенная связь;

* защищенное датирование;

* нотаризация ;

* неотказуемость;

* защищенный архив данных;

* управление полномочиями;

* приватность [44].

Защищенная связь

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

* защищенную электронную почту, использующую протоколы S/MIME v2 [169] и S/MIME v3 [158], [159];

* защищенный доступ к web-серверу на базе протокола TLS [142];

* защищенную виртуальную частную сеть, использующую протоколы IPSec [143] и IKE [147].

Для шифрования и подписания почтовых сообщений, наряду с главными сервисами PKI, может быть реализована защищенная электронная почта в качестве сервиса, базирующегося на PKI. Это позволяет передавать сообщения по открытым сетям без риска компрометации их аутентичности, целостности и конфиденциальности. Более подробно защищенная электронная почта и другие приложения защищенной связи рассматриваются в (лекции 17), которая посвящена приложениям, базирующимся на PKI.

Защищенное проставление меток времени

Защищенное датирование, или проставление меток времени , заключается в связывании доверенным центром датирования метки времени с определенной "порцией" данных при сохранении их аутентичности и целостности. Причем, важным является не столько само значение времени, сколько защищенность связывания данных с определенным временем (датой). В частности, в некоторых приложениях бывает важно зафиксировать не время совершения события, а последовательность событий, например, поступление в доверенный центр данного документа Y перед документом Z, но после документа X.

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

Защищенный сервис датирования базируется на главных сервисах PKI: аутентификации и целостности. Метка времени на документе образуется в результате подписания цифровым образом комбинации хэш-кода самого документа и значения времени в некотором формате. Подпись доверенного центра датирования обеспечивает аутентичность и целостность данных. Для того чтобы эта схема работала, все субъекты PKI должны знать и доверять открытому ключу подписи центра датирования, при помощи которого можно проверить подпись на метке времени. Если такой ключ становится ненадежным (например, в результате компрометации секретного ключа подписи центра датирования), необходимо, чтобы все субъекты PKI были проинформированы об этом, и для центра датирования был выпущен новый надежный ключ. Все метки времени, заверенные ненадежным ключом, не следует считать валидными.

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

Нотаризация

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

* математической корректности результата верификации подписи при помощи соответствующего открытого ключа;

* правильного связывания открытого ключа подписи с субъектом, который подписывает данное значение;

* доступности и надежности всех других данных, необходимых для процесса валидации (например, дополнительных сертификатов для формирования полного пути).

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

Неотказуемость

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

Наиболее распространенными и часто обсуждаемыми вариантами неотказуемости являются неотказуемость источника (когда пользователь не может ложно отказаться от отправки сообщения или документа) и неотказуемость получения (когда пользователь не может ложно отказаться от получения сообщения или документа). Однако должны быть определены и другие варианты, включая неотказуемость создания, неотказуемость доставки и неотказуемость подтверждения.

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

1 он намеренно передал свой секретный ключ подписи третьей стороне, чтобы иметь возможность отказаться от получения сообщения от А ;

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

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

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

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

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

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

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

Управление полномочиями

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

Важно различать концепции аутентификации и авторизации и понимать их взаимное влияние. Аутентификация устанавливает, кем является субъект, то есть связывает идентичность с субъектом. Авторизация выявляет полномочия данной идентичности. Авторизация не подтверждает, что субъектом, запрашивающим удаленный доступ к сети, является пользователь А ; она просто работает по принципу, что если это - пользователь А, то ему разрешен доступ. Следовательно, аутентификация и авторизация во многих обстоятельствах должны работать вместе. Аутентификация без авторизации может быть полезна, например, для идентификации источника данных. И наоборот, авторизация без аутентификации может использоваться, например, для получения доступа к web-сайту только жителей определенной страны, когда необходимо иметь возможность доказать гражданство, не идентифицируя себя персонально. Однако аутентификация и авторизация часто связаны, потому что полномочия индивида или группы невозможно реализовать, пока не определено, что данный субъект обладает определенной идентичностью, ролью или принадлежит к определенной группе.

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

Понятие полномочия или права часто приводит к понятию делегирования [57]. Если пользователь А обладает определенным полномочием, то может передать это право другому субъекту - пользователю В (возможно, с некоторыми ограничениями). Пусть, например, пользователь А имеет неограниченный доступ к некоторому web-сайту для выполнения определенной рабочей функции. В ряде случаев ему бывает необходимо, чтобы его коллега, пользователь В, получил доступ к этому сайту для выполнения работы вместо него (например, в отсутствие пользователя А ). Делегирование бывает скрытое и явное. Скрытое делегирование происходит тогда, когда пользователь А делегировал некоторое полномочие пользователю В, а субъект, проверяющий авторизацию В, не может определить, что делегирование имело место. С точки зрения проверяющего, пользователь В получил полномочия от надежного центра авторизации и пользователь А никак не участвовал в этом процессе.

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

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

Приватность

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

Пример 16.1. Рассмотрим следующий сценарий. Субъект E под псевдонимом проходит аутентификацию на web-сайте S₁. S₁ неизвестны подлинные идентификационные данные субъекта E, поскольку тот использует псевдоним. Однако S₁ определяет, что это тот же самый субъект, который не раз посещал сайт, и может присвоить ему специальный статус (например, "Е интересуется информацией определенного рода" или "Е получает приоритет" ). В том случае, если для удовлетворения запроса субъекта E его необходимо перенаправить на второй web-сайт S₂, то S₁ может сослаться на E как на субъекта со специальным статусом. Это иногда называют проблемой индексной ссылки [44].

Существуют три способа решения этой проблемы: токены носителя, схемы на базе секрета, схемы на базе открытых ключей. При помощи токенов носителя S₁ информирует S₂: "Тот, кто Вам предъявит этот токен (или указатель на этот токен), является тем субъектом, о котором я сообщаю". Механизм аутентификации для субъекта E заключается только во владении токеном (или указателем) и возможности предъявить его S₂. Ясно, что если этот токен/указатель похищен, то любой субъект может с успехом выдать себя за E.

Второй способ характеризуется тем, что E и S₁ разделяют некоторый секрет, такой как пароль или симметричный ключ. S₁ говорит S₂: "Тот, кто знает следующий секрет - xyz^abc - является тем субъектом, о котором я сообщаю". В этом случае механизм аутентификации для субъекта E - это доказывание знания секрета перед S₂. Данное решение подразумевает, что общий секрет E и S₁ обязательно должен быть раскрыт S₂, который получает возможность маскироваться под субъекта E перед S₁. Эта проблема обостряется с ростом числа сайтов, которым известен секрет (для выполнения дальнейших шагов транзакции или для однократной регистрации).

Третий способ заключается в том, что субъект E имеет пару ключей и сертификат. S₁ говорит S₂: "Тот, кто может аутентифицировать себя при помощи сертификата, является субъектом, о котором я сообщаю". Механизм аутентификации для E состоит в доказывании знания секретного ключа, соответствующего открытому ключу в сертификате.

Механизмом сильной аутентификации субъекта при многошаговой транзакции является его однократная регистрация, когда субъект E предъявляет пароль (или PIN-код, или биометрическую характеристику и т.п.) локальной системе, чтобы открыть пару ключей, но не участвует в аутентификации S₁ перед S₂ (или каким-либо следующим участником транзакции).

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

Механизмы, которые необходимы для сервисов, базирующихся на PKI

К механизмам, которые необходимы для сервисов на базе PKI, относятся:

* цифровые подписи, хэш-функции, коды аутентификации сообщений (MAC) и шифры;

* надежные источники времени;

* механизмы создания политики полномочий ;

* механизмы обработки политики полномочий ;

* механизмы инфраструктуры управления полномочиями ;

* архитектура приватности.

Цифровые подписи, хэш-функции, коды аутентификации сообщений и шифры

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

Надежные источники времени

Сервис защищенного датирования требует наличия одного или нескольких надежных источников времени, то есть способа получения надежного представления текущего времени (синхронного глобальному времени, с высоким уровнем точности) одного или нескольких устройств/субъектов в локальной среде [120].

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

Механизмы создания и обработки политики полномочий

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

Политика полномочий должна быть не только разработана и отредактирована, но и обработана и воспринята механизмом верификации некоторого вида (иногда называемым точкой принятия решений о политике ) в момент запроса субъектом доступа к некоторому ресурсу. То есть точка принятия решения о политике использует политику полномочий как закон, согласно которому принимается или отвергается запрос субъекта на доступ к ресурсу или сервису. Для восприятия политики полномочий компьютером необходим формальный язык спецификации политики (например, язык eXtensible Access Control Markup Language - XACML или Annex D стандарта X.509) [44]. Важным требованием общих инфраструктур управления полномочиями являются механизмы, которые могут интерпретировать закодированные политики и действовать в соответствии с ними.

Механизмы инфраструктуры управления полномочиями

Существует ряд механизмов реализации инфраструктуры управления полномочиями (Privilege Management Infrastructure - PMI). Они делятся на три категории:

* механизмы на базе Kerberos [135], такие как SESAME (a Secure European System for Applications in a Multi-vendor Environment) [125] и DCE (Distributed Computing Environment) [71];

* механизмы, базирующиеся на концепции сервера политики, то есть центрального сервера, который создает, поддерживает и проверяет политику полномочий для индивидов, групп и ролей;

* механизмы, основанные на атрибутных сертификатах, которые подобны сертификатам, определенным в стандарте X.509 и языке Security Assertion Markup Language (SAML) [111]. Атрибутный сертификат аналогичен сертификату с открытым ключом, но связывает идентификационные данные субъекта не с открытым ключом, а с информацией о полномочиях или правах субъекта.

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

Каждый механизм PMI может успешно применяться в одних условиях и быть неэффективным в других. Так, например, технология, основанная на Kerberos, может быть лучшим вариантом выбора в среде, где обрабатывается большое количество транзакций в режиме реального времени. Архитектура на базе сервера политики больше подходит для географически локализованных сред с сильным централизованным управлением. И, наконец, технологию атрибутных сертификатов следует предпочесть для межкорпоративной авторизации, которая необходима для поддержки сервиса неотказуемости. Иногда возможно использование двух механизмов, каждый из которых поддерживает определенный набор функций PMI.

Из всех перечисленных механизмов PMI технология атрибутных сертификатов теснее всего связана с использованием PKI, так как АС может быть подписан цифровым образом или содержать зашифрованные атрибуты. Все три механизма могут быть реализованы как дополнительные сервисы PKI, однако авторизация обычно связана с аутентификацией, и каждый механизм может работать с сервисом аутентификации PKI.

Архитектура приватности

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

1 УЦ знает подлинные идентификационные данные субъекта, но выпускает сертификаты, которые скрывают идентичность субъекта от всех остальных;

2 УЦ не знает подлинных идентификационных данных субъекта (они известны только самому субъекту), но, тем или иным способом, выпускает значимые сертификаты.

Условия функционирования сервисов, базирующихся на PKI

При принятии решения о развертывании некоторых дополнительных сервисов, базирующихся на PKI, следует учитывать условия их функционирования.

Механизм доставки точного времени

Для защищенного сервиса датирования (и соответственно для сервисов нотаризации и неотказуемости, которые базируются на нем) должен существовать способ доставки точного времени одному или нескольким центрам датирования в сети. Специалистами была выполнена трансформация известного протокола Network Time Protocol (NTP) [134] в защищенный протокол Secure Network Time Protocol [108] для криптографической аутентификации отправителя и проверки целостности данных, включенных в NTP-сообщение. Значение этой работы возрастает с ростом числа проектов развертывания дополнительного PKI-сервиса - сервиса защищенного датирования.

Защищенные протоколы

Для многих обсуждаемых в этой главе сервисов, базирующихся на PKI, ключевым компонентом является сервер, обеспечивающий связь с другими субъектами PKI (например, сервер центра датирования, центра нотаризации или сертификации данных, центра авторизации). Такая связь невозможна без защищенных протоколов - ведь подделка сообщений может скомпрометировать этот сервис. Следовательно, для обеспечения надежности предоставляемых сервисов в PKI должны использоваться защищенные протоколы (для связи "клиент-сервер" и одноранговых коммуникаций), поддерживающие аутентификацию, целостность и конфиденциальность. Примерами онлайновых протоколов, которые могут служить таким целям, являются протокол безопасности транспортного уровня TLS [142] и протокол Simple Public Key GSS-API Mechanism (SPKM) [139].

Резервные серверы

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

Физически защищенный архив

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

Сертификаты приватности и отображение идентичности

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

Обстоятельства реальной жизни

Обстоятельства реальной жизни можно рассматривать как самое главное условие функционирования сервисов PKI. И главные, и дополнительные сервисы PKI становятся субъектом непредсказуемого поведения, некорректной работы или ненадежных результатов, если инфраструктура неправильно реализована или если пользователи и администраторы не обладают минимальным уровнем подготовки в сфере безопасности. Например, если субъекты PKI не соблюдают осторожность при хранении секретных ключей, то могут быть полностью скомпрометированы главные сервисы PKI и сервис неотказуемости. Если плохо реализован базовый протокол S/MIME или IKE, то не может надежно поддерживаться защищенная связь.

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

Лекция 17. Приложения, базирующиеся на PKI

Рассматриваются защищенная электронная почта, средства безопасности транспортного уровня и IP-уровня, дается краткая характеристика протоколов SSL и TLS, описываются протоколы установления соединений, передачи записей, протоколы IPsec, обсуждаются типовые сценарии использования PKI.

Защищенная электронная почта S/MIME

Спецификация Secure Multipurpose Internet Mail Extension (S/MIME) предназначена для защиты наиболее популярного Интернет-сервиса - электронной почты. В силу важности этого сетевого сервиса предпринималось много попыток стандартизовать решения защищенной электронной почты. Одна из первых схем защиты - Privacy Enhanced Mail (PEM) - была предложена в 1985 году. Следующая схема защиты появилась в 1995 году и получила название MIME Object Security Services (MOSS). Несмотря на то, что в них содержалось множество хороших идей, негибкость и отсутствие совместимости отодвинули PEM и MOSS на вторые роли в сфере создания защищенного обмена сообщениями и были вытеснены системами Secure/MIME (S/MIME) и Pretty Good Privacy (PGP).

Протоколы S/MIME и PGP поддерживаются большинством программных продуктов, предназначенных для коллективной работы и защиты электронной почты. Наиболее распространенным и широко признанным стандартом обмена сообщениями стал разработанный в 1996 году стандарт S/MIME. Первоначально компанией RSA Data Security была предложена вторая версия спецификации S/MIME v2 [169], [170], позднее она была доработана рабочей группой организации IETF и в результате появилась новая, третья версия - S/MIME v3 [158], [159].

S/MIME обеспечивает защиту от трех типов нарушений безопасности: "подслушивания", или перлюстрации, искажения сообщений и фальсификации [22]. Защита от перлюстрации достигается путем шифрования сообщений. Для защиты от искажения почтового сообщения или фальсификации в S/MIME применяют цифровые подписи. Цифровая подпись гарантирует, что сообщение не было изменено в процессе передачи. Кроме того, ее наличие не позволяет отправителю сообщения отказаться от своего авторства.

Однако цифровая подпись не гарантирует конфиденциальность сообщения. В S/MIME эту функцию выполняет цифровой конверт. Шифрование осуществляется с помощью симметричного криптографического алгоритма типа DES, Triple-DES или RS2. Симметричный ключ шифруется с помощью открытого ключа получателя, а зашифрованное сообщение и ключ передаются вместе.

Спецификация S/MIME определяет два типа MIME-конверта: один для цифровых подписей, другой - для шифрованных сообщений. Оба типа базируются на синтаксисе криптографических сообщений стандарта PKCS#7 [198]. Если сообщение должно быть зашифровано, а шифртексту должны быть присвоены некоторые атрибуты, используются вложенные конверты. Внешний и внутренний конверт предназначаются для защиты цифровых подписей, а промежуточный конверт - для защиты шифртекста.

Помимо обеспечения целостности сообщения во время передачи, S/MIME идентифицирует обладателя конкретного открытого ключа с помощью сертификата X.509. Цифровой сертификат удостоверяет, что открытый ключ действительно принадлежит тому, кто является субъектом сертификата.

S/MIME v3 поддерживает следующие важные свойства, которые отсутствуют в S/MIME v2:

* заверенные цифровой подписью квитанции;

* метки безопасности;

* списки рассылки;

* гибкое управление ключами.

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

Метки безопасности позволяют отправителю задавать управляющие требования к содержанию сообщения. Чаще всего метка безопасности свидетельствует о включении в содержание сообщения частной или конфиденциальной информации.

Обычно отправитель сообщения шифрует его один раз при помощи симметричного ключа. Затем отправитель должен зашифровать симметричный ключ отдельно, используя открытый ключ того адресата, которому он направляет свое сообщение. Если количество адресатов велико, возникает необходимость делегировать функции шифрования доверенному серверу. Такой сервер называют агентом списка рассылки (Mail List Agent - MLA). Если имеется агент MLA, то отправитель может послать зашифрованное сообщение ему, а тот, в свою очередь, после выполнения соответствующих операций выполняет рассылку сообщения всем адресатам из списка отправителя. При этом MLA не получает доступ к ключу шифрования сообщения и не расшифровывает пересылаемое сообщение.

Если адресаты сообщения территориально распределены (например, находятся на разных континентах), то отправитель посылает зашифрованное сообщение главному агенту MLA, главный агент пересылает его региональным агентам MLA, и, наконец, каждый региональный агент доставляет зашифрованное сообщение локальным получателям [70]. В этом случае сообщение участвует в каждой межконтинентальной коммуникации только один раз. Правда, если в списки рассылки каждого регионального MLA включены адреса всех других региональных агентов, может происходить многократная пересылка сообщения по кругу. Для обнаружения циклов анализируется атрибут "история распространения списка рассылки", содержащийся во внешнем конверте сообщения. Когда агент MLA получает сообщение, то проверяет историю распространения, чтобы определить, не обрабатывалось ли уже данное сообщение. Если сообщение обрабатывалось, оно просто удаляется. Внешний конверт с цифровой подписью обеспечивает целостность истории распространения списка рассылки.

S/MIME v2 обеспечивает только транспортировку ключей шифрования сообщений, а S/MIME v3 дополнительно поддерживает механизмы согласования ключей и внешнего распространения симметричных ключей шифрования ключей.

Поддержка защищенной электронной почты на основе PKI

Все сервисы, предлагаемыми S/MIME (обеих версий), полагаются на сертификаты и надежность связывания электронного адреса субъекта с его открытым ключом. Адрес электронной почты (часто называемый адресом RFC 822 [130]) должен быть представлен в дополнении сертификата Subject Alternative Name (альтернативное имя субъекта). Если используется вторая версия S/MIME, то адрес электронной почты указывается в качестве отличительного имени субъекта ( emailAddress ).

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

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

Аналогичные действия выполняются при проверке квитанций, заверенных цифровой подписью, - для этого проверяющий сравнивает адрес электронной почты из запроса на квитанцию с адресом электронной почты в сертификате лица, подписавшего квитанцию.

Средства безопасности транспортного уровня

Протокол безопасности транспортного уровня Transport Layer Protocol (TLS) [142] обеспечивает защиту коммуникаций между приложениями, разработанными в архитектуре "клиент-сервер", в основном между web-браузером и web-сервером. Всемирная Паутина World Wide Web является наиболее популярным Интернет-сервисом после электронной почты. TLS наиболее часто применяется для защиты web-контента, но может использоваться с любым протоколом прикладного уровня. Спецификация TLS базируется на популярном протоколе Secure Socket Layer (SSL) [109], разработанном корпорацией Netscape. Эти протоколы создавались для обеспечения аутентификации, целостности и конфиденциальности данных, которыми обмениваются взаимодействующие друг с другом приложения. Оба протокола имеют двухуровневую организацию: протокол установления соединения (Handshake Protocol) и протокол передачи записей (Record Protocol).

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

Протоколы SSL и TLS независимы от протоколов прикладного уровня, поэтому любой протокол прикладного уровня может прозрачно оперировать поверх SSL и TLS. Протоколы SSL и TLS обеспечивают три сервиса безопасности [70]:

* аутентификацию (подтверждение идентичности соединения: протокол установления соединения использует сертификаты и верификацию цифровых подписей для подтверждения идентификационных признаков и полномочий удаленного приложения);

* целостность (защиту данных протокола от несанкционированной модификации: протокол передачи записей использует значение бита контроля целостности для подтверждения того, что передаваемые данные не изменялись);

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

Протоколы SSL и TLS способны поддерживать взаимную аутентификацию сторон, но обычно на базе сертификата выполняется аутентификация сервера клиентом, а затем клиент аутентифицируется другим способом, например, вводя по запросу сервера свое имя и пароль или номер своей кредитной карты и дату окончания ее срока действия.

Протокол установления соединений

Протокол установления соединений Handshake Protocol состоит как бы из трех подпротоколов, которые позволяют выполнить аутентификацию сторон, согласовать алгоритмы и параметры безопасности для протокола передачи записей [19].

Handshake Protocol отвечает за организацию сеанса взаимодействия между клиентом и сервером для протокола передачи записей, в частности за согласование характеристик сеанса:

* идентификатора сеанса ( Session identifier ), то есть произвольной последовательности битов, выбранной сервером для идентификации сеанса;

* сертификата соединения ( Peer certificate ), представляющего собой сертификат X.509; этот элемент может отсутствовать, если аутентификация не требуется;

* метода сжатия ( Compression method ), то есть алгоритма сжатия данных перед их шифрованием;

* спецификатора шифрования ( Cipher spec ), который задает идентификаторы алгоритма шифрования данных и алгоритма хэширования, а также некоторые криптографические атрибуты (например, размер хэш-кода);

* главного секрета ( Master secret ), представляющего собой секретное значение, разделенное между клиентом и сервером;

* признака установления нового соединения ( Is resumable ) на основе текущего сеанса.

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

В результате работы протокола Handshake Protocol формируются криптографические параметры. Когда клиент и сервер начинают взаимодействие, то согласовывают версию протокола, криптографические алгоритмы, аутентифицируют друг друга (по желанию) и используют криптографию с открытыми ключами для разделения общего секрета. Работа протокола Handshake Protocol выполняется за шесть шагов [70].

* 1-й шаг. Обмен приветственными сообщениями для согласования алгоритмов и обмена случайными числами.

* 2-й шаг. Обмен криптографическими параметрами для согласования начального секрета.

* 3-й шаг. Опциональный обмен сертификатами и криптографической информацией для взаимной аутентификации клиента и сервера.

* 4-й шаг. Генерация главного секрета на основе начального секрета и обмен случайными числами.

* 5-й шаг. Формирование параметров безопасности для протокола передачи записей.

* 6-й шаг. Оповещение о расчете тех же самых параметров безопасности и корректном завершении соединения.

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

При обмене сертификатами и ключами передаются данные, необходимые для генерации начального секрета. Если используется алгоритм RSA, то клиент генерирует случайное начальное число и шифрует его при помощи открытого RSA-ключа сервера. Если применяется алгоритм Диффи-Хэллмана, клиент и сервер обмениваются открытыми ключами, а затем в качестве начального секрета используется результат вычисления ключа согласования ключей по алгоритму Диффи-Хэллмана.

Главный секрет и симметричные ключи генерируются при помощи псевдослучайной функции PRF (PseudoRandom Function), полученной на основе алгоритмов SHA-1 и MD5. Чтобы гарантировать безопасность, применяются две разные однонаправленные хэш-функции. При первом применении функции PRF генерируется главный секрет из начального секрета и случайных чисел, полученных на основе приветственных сообщений клиента и сервера. В результате повторного применения функции PRF к тем же самым исходным данным получают два симметричных ключа, два значения начального вектора и два значения MAC (кода аутентификации сообщения) секрета. При возобновлении сеанса используется уже известное для данного сеанса значение главного секрета, но генерируются новые случайные числа на основе новых приветственных сообщений клиента и сервера, поэтому в результате формируется новый ключевой материал.

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

Протокол передачи записей

Протокол передачи записей Record Protocol состоит из нескольких подуровней. Обработка данных протокола прикладного уровня заключается в их разбиении на управляемые блоки, сжатии, снабжении имитовставкой, шифровании и последующей передаче результата. Полученные данные обрабатываются в обратном порядке: расшифровываются, проверяются на целостность, подвергаются декомпрессии, сборке, а затем доставляются приложению [6].

На подуровне фрагментации информация разбивается на записи, длина каждой записи не превышает 16384 байтов. Допускается агрегирование нескольких однотипных сообщений в одну запись, а также разбиение одного сообщения протокола прикладного уровня на несколько записей. На подуровне сжатия выполняется сжатие или декомпрессия всех фрагментов. Очевидно, что при компрессии не должно быть потери данных. Затем вычисляется имитовставка, то есть проверяется целостность сжатой записи, а полученное значение и сжатая запись шифруются. Проверка целостности осуществляется при помощи кода аутентификации сообщения (MAC) или кода аутентификации, полученного на основе хэш-кода сообщения (HMAC).

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

Поддержка безопасности транспортного уровня на основе PKI

Сертификаты являются центральным компонентом всех сервисов аутентификации и управления ключами, предлагаемых как TLS, так и SSL. Эти сервисы полагаются на связывание идентичности субъекта с его открытым ключом. Для идентификации web-серверов рекомендуется использовать DNS-имена (типа www.alpha.com) и указывать их в дополнении сертификатов Subject Alternative Name (параметр dNSName ). Если DNS-имя не представлено в сертификате, то для идентификации используется отличительное имя субъекта.

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

Сертификаты, используемые для поддержки безопасности транспортного уровня, также должны содержать дополнение Key Usage, отражающее соответствующее назначение открытого ключа, который содержится в сертификате:

* цифровая подпись, если необходимо выполнять верификацию подписей;

* шифрование ключей, чтобы обеспечить RSA-шифрование;

* согласование ключей, если необходима поддержка согласования ключей методом Диффи-Хэллмана.

Клиент должен быть уверен, что открытый ключ принадлежит серверу. Если используется некорректный открытый ключ, то постороннее лицо может получить начальный секрет и возможность сгенерировать главный секрет и все другие секретные параметры, вычисляемые с его помощью. Сертификат подтверждает принадлежность открытого ключа серверу.

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

Средства безопасности IP-уровня

Совокупность механизмов IPsec обеспечивает основу для защиты сетевого трафика на IP-уровне, безопасности IP-пакетов, защищенного взаимодействия мобильных систем с корпоративной сетью, реализации виртуальных частных сетей (Virtual Private Networks - VPN) и т.п. Семейство спецификаций IPsec представлено серией из 10 документов, разработанных рабочей группой IP Security Protocol организации IETF и содержащих сведения об архитектуре IPsec [143], формировании контекстов безопасности, управлении ключами и базовых протоколах. Ядро IPsec составляют три протокола: протокол аутентифицирующего заголовка (Authentication Header, AH) [144], протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload, ESP) [145] и протокол обмена ключами в Интернете (Internet Key Exchange, IKE) [147]. Функции по поддержанию защищенного канала передачи данных по сетям IP распределяются между этими протоколами следующим образом:

* протокол AH обеспечивает целостность IP-пакетов, аутентификацию источника данных, а также защиту от воспроизведения ранее переданных IP-пакетов;

* протокол ESP поддерживает конфиденциальность, аутентификацию и целостность IP-пакетов, а также частичную защиту от анализа трафика;

* протокол IKE позволяет взаимодействующим сторонам автоматически генерировать и безопасно распределять симметричные секретные ключи.

Контексты безопасности

Контексты безопасности (Security Associations) образуют основу криптографических сервисов безопасности на базе протоколов IPsec. Для защиты двусторонней связи между узлами сети необходимы два контекста безопасности: один - для входящих потоков, другой - для исходящих. Контексты безопасности содержат информацию об IP-адресах, типе защитного протокола ( AH или ESP ), криптографических алгоритмах, ключах для аутентификации и шифрования и периоде их действия.

Контекст безопасности уникально идентифицируется тремя элементами:

* индексом параметров безопасности ( Security Parameters Index - SPI );

* целевым IP-адресом;

* идентификатором защитного протокола.

Итак, индекс SPI - это идентификатор контекста безопасности, который указывается в протоколе AH или ESP. Целевой IP-адрес идентифицирует соединение IPsec, он может быть индивидуальным или групповым адресом либо диапазоном адресов. В настоящее время обмен ключами IKE реализован только для индивидуальных адресов, а для групповых адресов или диапазонов распределение ключей выполняется вручную.

| | Хост | Маршрутизатор или межсетевой экран |

|Хост | Транспортный режим или туннельный режим | Туннельный режим |

|Маршрутизатор или межсетевой экран | Туннельный режим | Туннельный режим |

Таблица 17.1.Режимы, используемые для разных типов соединений

Протоколы обеспечения аутентичности и конфиденциальности могут применяться в двух режимах: транспортном и туннельном. Обычно транспортный режим используется хостами, при этом защищается только содержимое IP-пакетов и опционально - некоторые поля заголовков. В туннельном режиме защищается весь пакет: он инкапсулируется в другой IP-пакет, при этом происходит как бы "обертывание", или заключение в конверт, передаваемой порции данных [6]. Туннельный режим обычно реализуют на специально выделенных защитных шлюзах, в роли которых могут выступать маршрутизаторы или межсетевые экраны (см. рис. 17.1).

Рис. 17.1. Стеки протоколов в разных режимах

В транспортном режиме заголовок протокола ( AH или ESP ) располагается в стеке протоколов после заголовка исходного IP-пакета и перед заголовками протоколов более высокого уровня [70]. В туннельном режиме заголовок протокола ( AH или ESP ) располагается в стеке протоколов между двумя заголовками: после заголовка внешнего IP-пакета и перед заголовком внутреннего исходного IP-пакета (см. рис. 17.1).

Протокол аутентифицирующего заголовка AH

протокол аутентифицирующего заголовка AH обеспечивает:

* целостность IP-пакетов, данных протоколов более высокого уровня и определенных полей IP-заголовков;

* аутентификацию источника данных (на основе IP-адреса узла сети или имени конечного пользователя);

* защиту от ложного воспроизведения ранее переданных IP-пакетов.

Контроль целостности базируется на проверке кода аутентификации хэшированного сообщения Hashed Message Authentication Code (HMAC), вычисляемого при помощи хэш-функции MD5 или SHA-1 с секретным симметричным ключом, который известен обеим взаимодействующим сторонам.

Рис. 17.2 иллюстрирует типичные поля данных протокола AH. Протокол содержит пять полей: Next Header, Length, SPI, Sequence Number и Authentication Data.

Рис. 17.2. Поля данных протокола AH

Поле Next Header (следующий заголовок) указывает, какой протокол более высокого уровня инкапсулируется при помощи AH. В туннельном режиме это поле обычно содержит IP v4 или IP v6, а в транспортном режиме - TCP, UDP или ICMP.

Поле Length (длина) задает размер заголовка протокола AH. Размер зависит от типа используемой хэш-функции, значение HMAC содержится в единственном поле переменной длины.

Поле SPI (индекс параметров безопасности) содержит 32-разрядное произвольное значение, которое идентифицирует контекст безопасности.

Поле Sequence Number (порядковый номер) используется для задания значения счетчика IP-пакетов (32-разрядного монотонно возрастающего) и защиты от воспроизведения пакетов. Отправитель пакета должен задавать это значение, а получатель пакета может либо обрабатывать его, либо игнорировать.

При передаче пакета его порядковый номер, указываемый в поле Sequence Number, увеличивается, а затем поля IP-заголовка и протокола более высокого уровня хэшируются для создания HMAC на основе общего секретного симметричного ключа. После получения IP-пакета получателем выполняется та же самая последовательность операций. Если вычисленное им значение HMAC не соответствует значению, полученному по протоколу AH, то пакет не принимается. Кроме того, если контекст безопасности содержит информацию о применении средства защиты от воспроизведения пакетов, то значение поля Sequence Number уменьшается на единицу, то есть восстанавливается прежнее значение счетчика IP-пакетов.

Протокол инкапсулирующей защиты содержимого ESP

Протокол инкапсулирующей защиты содержимого ESP поддерживает конфиденциальность, аутентификацию и целостность IP-пакетов. Конфиденциальность обеспечивается путем шифрования содержимого IP-пакетов, а также части заголовка и трейлера (хвостовой части) протокола ESP ; надежность шифрования зависит, прежде всего, от используемого алгоритма шифрования. Аутентификация источника данных и защита целостности осуществляется на основе HMAC (как и в протоколе AH ). Хотя сервисы конфиденциальности и аутентификации (который включает целостность) являются опциональными, в каждом контексте безопасности должен быть задан, по крайней мере, один сервис безопасности.

В качестве алгоритмов шифрования в протоколе ESP используются алгоритмы DES и Triple-DES, для вычисления HMAC применяется хэш-функция типа MD5 или SHA-1. Рис. 17.3 иллюстрирует типичные поля данных протокола ESP. Заголовок ESP содержит два поля: SPI и Sequence Number, их синтаксис и семантика совпадает с одноименными полями протокола AH. Трейлер ESP состоит из четырех полей: Padding, Pad Length, Next Header и Authentication Data.

Поле Padding (заполнитель) используется для того, чтобы размер шифруемых данных был кратен размеру криптографического блока.

Рис. 17.3. Поля данных протокола ESP

Поле Pad Length (длина заполнителя) характеризует размер заполнителя и зависит от используемого алгоритма шифрования и заданного уровня конфиденциальности IP-трафика.

Поле Next Header (следующий заголовок) содержит информацию о том, какой протокол более высокого уровня инкапсулируется при помощи ESP. В туннельном режиме это поле обычно содержит IP v4 или IP v6, а в транспортном режиме - TCP, UDP или ICMP.

Поле Authentication Data (аутентификационные данные) содержит значение HMAC для данного IP-пакета. Это поле имеет переменную длину, которая должна быть кратна 32 разрядам. Если аутентификация источника данных или защита целостности не требуется, то это поле отсутствует или имеет нулевую длину.

При передаче пакета его порядковый номер, указываемый в поле Sequence Number, увеличивается, а затем поля заголовка ESP, протокола более высокого уровня и трейлера ESP хэшируются для создания HMAC на основе общего секретного симметричного ключа. Затем поля протокола более высокого уровня и трейлер ESP (за исключением аутентификационных данных) шифруются; если необходим начальный вектор, то он предваряет шифртекст. После получения IP-пакета получателем выполняется расшифрование и расчет того же самого значения HMAC. Если вычисленное им значение HMAC не соответствует значению, полученному в трейлере ESP, то пакет не принимается. Кроме того, если контекст безопасности содержит информацию об использовании средства защиты от воспроизведения пакетов, то значение поля Sequence Number уменьшается на единицу, то есть восстанавливается прежнее значение счетчика IP-пакетов.

Протокол обмена ключами IKE

Широкое использование IPsec требует масштабируемого, автоматизированного управления контекстами безопасности. Формирование контекстов безопасности по запросу и использование средств защиты от воспроизведения пакетов в протоколах AH и ESP невозможно без работы протокола обмена ключами в Интернете IKE [147]. Протокол IKE разработан на основе протокола управления ключами и контекстами безопасности Интернета - Internet Security Associations and Key Management Protocol (ISAKMP) [146] и протокола вычисления ключей - OAKLEY Key Determination Protocol (OAKLEY) [148]. Протокол ISAKMP обеспечивает независимую от криптографического механизма аутентификацию и задает структуру обмена ключами. Протокол IKE базируется на функциональности протокола ISAKMP, а для формирования симметричного ключа использует возможности протокола OAKLEY. В качестве алгоритма согласования ключей применяется алгоритм Диффи-Хэллмана.

Работа протокола IKE выполняется за два этапа. На первом этапе устанавливается аутентифицируемый и шифруемый канал связи. Это требует формирования двух контекстов безопасности - по одному для связи в одном направлении. Для аутентификации сторон используются сертификаты открытых ключей подписи (в качестве алгоритма цифровой подписи применяется DSA). На втором этапе формируются контексты безопасности для AH и ESP.

Поддержка безопасности IP-уровня на основе PKI

Сертификаты служат главными компонентами аутентификации на основе IKE. Когда идентифицируется хост или защитный шлюз, наиболее предпочтительной формой идентификационных данных являются DNS-имена или IP-адреса, которые указываются в дополнении сертификата Subject Alternative Name (параметры dNSName и iPAddress соответственно). При идентификации пользователя рекомендуется использовать адрес электронной почты или обычное имя. Адрес электронной почты содержится в дополнении сертификата Subject Alternative Name, а обычное имя входит в состав отличительного имени субъекта. Невозможность связать идентичность субъекта с его открытым ключом делает аутентификацию невозможной. Неправильная аутентификация на основе протокола IKE может привести к ложному связыванию ключа и реализации IPsec, в результате неавторизованный пользователь (или даже группа компьютеров) может получить доступ, например, к виртуальной частной сети.

Сертификаты, предназначенные для защиты трафика Интернета, должны включать дополнение Key Usage, которое отражает соответствующее назначение открытого ключа, содержащегося в сертификате (например, цифровая подпись, если необходимо выполнять верификацию подписей). Кроме того, в дополнении сертификата Extended Key Usage должны явным образом указываться те приложения, для поддержки которых предназначен данный открытый ключ, в частности приложение IPsec.

Итак, сертификаты являются базовым компонентом сервисов безопасности, предоставляемых S/MIME, TLS и IPsec.

S/MIME при помощи сертификатов идентифицирует пользователей. Сервисы аутентификации, целостности, неотказуемости и конфиденциальности защищенной электронной почты зависят от сертификатов. Сертификаты поддерживают шифрование и заверение цифровой подписью почтовых сообщений.

TLS при помощи сертификатов идентифицирует пользователей и серверы. От сертификатов зависят сервисы аутентификации, целостности и конфиденциальности. Сертификаты поддерживают шифрование потока, аутентификацию потока и целостность потока.

IPsec при помощи сертификатов идентифицирует пользователей, хосты и шлюзы безопасности. От сертификатов зависят сервисы аутентификации. На базе сертификатов выполняется взаимная аутентификация взаимодействующих сторон при обмене открытыми ключами Диффи-Хэллмана, которые, в свою очередь, используются для безопасного распределения симметричных секретных ключей. Секретные ключи обеспечивают поддержку аутентификации, целостности и конфиденциальности IP-пакетов.

Типовые сценарии использования PKI

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

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

|УЦ | Репозиторий | Аннулирование сертификатов |

|Резервное хранение ключей | Восстановление ключей | Автоматическое обновление ключей |

|Управление историями ключей | Кросс-сертификация | Клиентское ПО |

|Аутентификация | Целостность | Конфиденциальность |

|Защищенное датирование | Нотаризация | Неотказуемость |

|Защищенный архив данных | Разработка полномочий/политики | Проверка полномочий/политики |

Таблица 17.2.Полнофункциональная PKI

Рассмотрим четыре распространенных на сегодняшний день сценария использования PKI [44]. В табл. 17.3 представлена Интернет-PKI, которая поддерживает обычную электронную почту (между знакомыми) и навигацию в World Wide Web при помощи SSL-сервера аутентификации. Такой сценарий требует наличия УЦ для выпуска сертификатов открытых ключей и поддержки основных сервисов аутентификации, целостности и конфиденциальности. В этом сценарии не предусмотрено использование репозитория (сертификаты пересылаются по протоколу связи), не выполняется проверка статуса получателя электронной почты (или даже сертификата сервера) и управление жизненным циклом ключей и сертификатов, отсутствует клиентское программное обеспечение (как отдельный модуль, вызываемый при помощи браузера), не требуется ни кросс-сертификация, ни дополнительные сервисы, базирующиеся на PKI.

|УЦ | Репозиторий | Аннулирование сертификатов |

|Резервное хранение ключей | Восстановление ключей | Автоматическое обновление ключей |

|Управление историями ключей | Кросс-сертификация | Клиентское ПО |

|Аутентификация | Целостность | Конфиденциальность |

|Защищенное датирование | Нотаризация | Неотказуемость |

|Защищенный архив данных | Разработка полномочий/политики | Проверка полномочий/политики |

Таблица 17.3.Интернет-PKI

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

|УЦ | Репозиторий | Аннулирование сертификатов |

|Резервное хранение ключей | Восстановление ключей | Автоматическое обновление ключей |

|Управление историями ключей | Кросс-сертификация | Клиентское ПО |

|Аутентификация | Целостность | Конфиденциальность |

|Защищенное датирование | Нотаризация | Неотказуемость |

|Защищенный архив данных | Разработка полномочий/политики | Проверка полномочий/политики |

Таблица 17.4.Экстранет-безопасность (через SSL-аутентификацию клиентов)

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

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

|УЦ | Репозиторий | Аннулирование сертификатов |

|Резервное хранение ключей | Восстановление ключей | Автоматическое обновление ключей |

|Управление историями ключей | Кросс-сертификация | Клиентское ПО |

|Аутентификация | Целостность | Конфиденциальность |

|Защищенное датирование | Нотаризация | Неотказуемость |

|Защищенный архив данных | Разработка полномочий/политики | Проверка полномочий/политики |

Таблица 17.5.Защищенная корпоративная электронная почта

|УЦ | Репозиторий | Аннулирование сертификатов |

|Резервное хранение ключей | Восстановление ключей | Автоматическое обновление ключей |

|Управление историями ключей | Кросс-сертификация | Клиентское ПО |

|Аутентификация | Целостность | Конфиденциальность |

|Защищенное датирование | Нотаризация | Неотказуемость |

|Защищенный архив данных | Разработка полномочий/политики | Проверка полномочий/политики |

Таблица 17.6.Межкорпоративные транзакции с цифровой подписью

Таблицы 17.3, 17.4, 17.5 и 17.6 подтверждают, что PKI, реализующие частные сценарии, являются подмножествами полнофункциональной PKI. Технология PKI продолжает развиваться, но уже сейчас ясно, что многие поставщики программного и аппаратного обеспечения PKI будут ориентироваться на реализацию полнофункциональных систем, а не на PKI-продукты узкого назначения. Очевидно, что во многих случаях проще и экономически более эффективно адаптировать полнофункциональный продукт для решения специфической проблемы, чем разрабатывать и поддерживать несколько отдельных продуктов, каждый из которых предназначен для решения одной или двух специфических проблем. Во многих средах PKI произойдет неизбежный переход от частных решений частных проблем к полнофункциональной PKI, предлагающей универсальное решение проблем безопасности для широкого круга приложений.

Лекция 18. Подготовка к развертыванию PKI

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

Предварительный этап развертывания PKI

Процесс развертывания PKI состоит из нескольких этапов, каждый из которых должен сопровождаться соответствующим документированием и проверками:

1 Предварительный этап

2 Проектирование.

3 Создание прототипа.

4 Пилотный проект.

5 Внедрение.

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

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

Подготовка принятия решения о развертывании

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

Оценка готовности к развертыванию

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

Определение цели развертывания PKI

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

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

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

Принятие решения о варианте развертывания

Организация выбирает инсорсинг, когда принимает решение о развертывании внутренней PKI на базе собственных ресурсов (включая персонал, аппаратное обеспечение и т.д.) и (или) с привлечением внешних ресурсов для выполнения некоторых или всех операций PKI. Ключевым моментом является то, что инсорсинговая PKI находится под контролем организации.

Выбирая аутсорсинг, организация разрешает внешней стороне поддерживать и выполнять некоторые (а возможно, и все) операции своей корпоративной PKI. В этом случае эти операции не контролируются самой организацией [105].

Основой принятия решения о варианте развертывания PKI должен быть анализ его стоимости и полезности с учетом большого числа релевантных факторов:

* возможностей организации разработать собственный PKI-продукт;

* стоимости самостоятельного развертывания инфраструктуры по сравнению с затратами на аутсорсинг (включая все соответствующее программное и аппаратное обеспечение, техническую поддержку, помещения, персонал, обучение и т.п.);

* потребности организации контролировать все операции PKI;

* источника доверия потребителей PKI-сервисов;

* скорости обработки запросов на получение сервисов и информации (например, запросы о выдаче сертификатов конечным субъектам, восстановлении ключей, получении информации о статусе сертификатов);

* уровня и доступности технической поддержки;

* возможностей и готовности поставщика технологии учитывать будущие потребности организации.

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

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

Разработка или приобретение PKI-продукта

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

1 Технология PKI достаточно сложна для реализации. Большинство поставщиков программного обеспечения для PKI вложили большие средства в разработку программных продуктов, и возврат инвестиций может быть реализован только путем тиражирования готовых продуктов и продаж многим заказчикам. Организации чрезвычайно трудно возместить расходы на разработку собственной оригинальной системы PKI.

2 Учитывая сложность программного обеспечения для PKI, маловероятно, что большинство организаций будут иметь достаточно ресурсов, чтобы даже начать процесс разработки.

3 Многие разработки в сфере PKI запатентованы, в частности такие как технологии аннулирования сертификатов, проставления меток времени, управления привилегиями и т.д., и это также влияет на создание нового программного продукта.

Учитывая эти трудности, большинство организаций даже не рассматривают возможность разработки совершенно нового, собственного PKI-продукта.

Открытая или частная иерархия

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

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

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

Рис. 18.1. Пример открытой иерархии

Рис. 18.2. Пример частной иерархии

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

Контроль и гибкость

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

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

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

Стоимость и время развертывания

Оценивание затрат на развертывание PKI зависит от нескольких главных факторов:

* количества пользователей;

* количества приложений;

* варианта развертывания PKI ( инсорсинг или аутсорсинг ).

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

Учитывая потенциальную сложность развертывания PKI, всегда разумно планировать максимально возможное время развертывания; однако возникает проблема, когда технология меняется настолько быстро, что "окончательная" реализация может никогда не произойти. Для быстрого развертывания (три месяца и менее) обычно рекомендуется аутсорсинг или управляемая PKI. Для более длительного развертывания (свыше 3 месяцев) можно использовать собственные решения, но за отведенное время не всегда могут быть реализованы особые требования организации и полностью решены проблемы интеграции.

Независимо от выбранного способа развертывания, организации следует планировать период развертывания не менее одного месяца. Решение проблем заключения договоров требует дополнительно от 2 до 4 недель. Кроме того, в зависимости от сложности проекта, к моменту подписания договора о продаже должны быть готовы приступить к работе консультанты проекта, предоставленные самим поставщиком или его партнерами. К главным моментам, которые влияют на время развертывания PKI и стоимость ее реализации, относятся:

* составление перечня работ консультантов со сроками выполнения и объемом финансирования;

* создание иерархий удостоверяющих центров (при необходимости к этой работе привлекаются консультанты);

* обучение персонала (администраторов), способного взаимодействовать с консультантами на этапе развертывания, а в дальнейшем модифицировать или совершенствовать систему PKI;

* планирование простоев в центрах обработки данных организации на время установки или адаптации аппаратного и/или программного обеспечения системы PKI (иногда организации планируют "окна" в работе своих центров обработки данных, во время которых необходимо выполнить установку программных и аппаратных средств PKI).

Более масштабные и ориентированные на специфические требования заказчика варианты развертывания могут занимать по времени 6 месяцев и более. Правильное планирование времени, необходимого для развертывания PKI, и распараллеливание работ существенно влияет на успех проекта.

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

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

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

|Характеристики | Инсорсинг | Аутсорсинг |

|Политика аутентификации | Возможность формировать собственную политику, простота изменения политики | Необходимость придерживаться политик, утвержденных для внешнего УЦ |

|Настройка на требования заказчика | Максимальная гибкость | Минимальная гибкость |

|Время развертывания | Длительный период развертывания | Короткий период развертывания |

|Степень участия | Большие первоначальные усилия, но в дальнейшем требуется небольшая работа по поддержке систем | Минимальные усилия со стороны заказчика, но может потребоваться интеграция с действующими системами заказчика |

|Стоимость | Большие первоначальные затраты, но небольшие в дальнейшем | Низкие первоначальные затраты, но большие в дальнейшем |

|Количество персонала | Требуется значительное количество персонала для работы, защиты и поддержки систем УЦ и РЦ | Персонал требуется только для работы и поддержки системы РЦ |

Таблица 18.1.Сравнительный анализ вариантов инсорсинга и аутсорсинга

Определение масштаба и сферы применения PKI

Правильное определение сферы применения является предпосылкой успешного проектирования PKI. Как правило, чем шире назначение PKI, тем уже спектр свойств и возможностей, которые доступны ее пользователям. PKI может быть предназначена для пользователей:

1 массового рынка;

2 интрасети;

3 экстрасети.

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

Корпоративные пользователи часто принадлежат к одной организации. Это дает возможность поддерживать более унифицированную среду для клиентских мест и позволяет иметь некоторый контроль над действиями пользователей. В этом случае развертывание PKI в зависимости от ее масштаба может осуществляться на базе и частных, и открытых иерархий. Кроме того, пользователи получают возможность управлять сертификатами при помощи соответствующих клиентских приложений; такими функциями, например, обладает клиентское программное обеспечение двух ведущих поставщиков услуг PKI - компаний Entrust [214] и VeriSign [220].

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

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

В таблице 18.2: 1 приводится перечень возможных сфер применения и приложений PKI, сформированный международным объединением пользователей и поставщиков услуг и программных продуктов в области инфраструктур открытых ключей (PKI Форум) [86].

В зависимости от назначения и масштаба PKI ее конечными субъектами или пользователями могут выступать граждане страны, клиенты, ИТ-штат или весь персонал организации, деловые партнеры или другие компании.

При задании сферы применения PKI необходимо определить уровень взаимодействия участников системы (международный, межкорпоративный, корпоративный, между несколькими подразделениями компании и т.п.).

| Сфера применения | Категория приложения | Примеры объектов и транзакций PKI-приложений |

|Банковская и финансовая сферы | Аутентификация платежей | Покупка акций

Денежные переводы по кредитам на обучение

|Контроль доступа | Банковские операции в онлайновом режиме |

|Защищенная электронная почта | Подача документов в комиссию по ценным бумагам и биржам |

|Защищенное хранение и поиск документов | Электронные ипотечные кредиты

Заявки на приобретение ценных бумаг

|Цифровой нотариат | Документы о правовом титуле

Кредиты

|Защищенные транзакции | Гарантийные письма |

|Страхование | Электронная цифровая подпись | Онлайновые:

* квоты;

* заявки;

* разрешения

|Аутентификация платежей | Онлайновые платежи:

* страховые премии;

* компенсации по страховым полисам

|Контроль доступа | Электронный документооборот

Информация о страхователях

|Здравоохранение | Аутентификация платежей | Выплата компенсаций |

|Защищенный обмен сообщениями / электронная почта | Подача заявлений на компенсацию |

|Защищенное хранение и поиск документов | Информация о пациентах |

|Квалификационная идентификация | Удостоверения врачей |

|Персональная идентификация | Паспорта |

|Правительство | Контроль доступа | Проход в правительственные здания |

|Аутентификация платежей | Выплаты органов социального обеспечения |

|Защищенный обмен сообщениями | Финансовые полномочия администрации |

|Защищенное хранение и поиск документов | Юридические документы по судебным делам |

|Бизнес- бизнес | Контроль доступа | Просмотр выбранных документов деловыми партнерами |

|Аутентификация платежей | Защищенные электронные платежи |

|Электронная цифровая подпись | Электронные контракты |

|Защищенный обмен сообщениями | Соглашения о коммерческой тайне

Запросы с предложениями о поставках

Контракты

Таблица 18.2.Сферы применения и категории приложений PKI

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

Важные характеристики решения

Решение о варианте развертывания PKI должно приниматься организацией с учетом характера среды развертывания, режима оперирования PKI, приоритетных сервисов безопасности, а также его комплексности и стандартности (см. рис. 18.3: 1).

Учет характера среды развертывания

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

Рис. 18.3. Принятие решения о варианте развертывания PKI

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

Режим оперирования

При оперировании в онлайновом режиме конечные субъекты имеют возможность напрямую связываться с сетью PKI и потреблять все сервисы, предоставляемые инфраструктурой. Автономное оперирование позволяет конечным субъектам использовать по крайней мере часть сервисов PKI, несмотря на то, что они не имеют прямого доступа к сети.

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

Приоритетные сервисы безопасности

Как указывалось ранее (см. лекцию 4: 1), PKI обеспечивает поддержку основных сервисов безопасности. На предварительном этапе должны быть выбраны приоритетные направления обеспечения информационной безопасности с учетом ожиданий заинтересованных сторон относительно уровня безопасности проектируемой инфраструктуры [84]. Если организации важно реализовать аутентификацию пользователей, то должен быть выбран способ и порядок аутентификации и средства хранения сертификатов и ключей. Если акцент делается на конфиденциальность данных, то при проектировании PKI следует особенно тщательно подойти к выбору криптографического алгоритма шифрования данных. Если важна целостность данных, то могут использоваться цифровые подписи. Если необходимо предотвратить отказ от обязательств, то должны использоваться сертификаты открытых ключей подписи. В силу разнообразия требований клиентов к защищенности используемых ими приложений, решение проблем безопасности может быть найдено в результате комбинированного применения нескольких методов и криптографических алгоритмов.

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

Комплексность решения

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

Стандартность решения

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

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

Анализ данных и приложений

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

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

Лекция 19. Проблемы выбора поставщика технологии или сервисов PKI

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

Определение критериев выбора поставщика технологии или сервисов PKI

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

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

Для того чтобы гарантировать правильность выбора, организации следует обратить внимание на следующие аспекты, характеризующие деятельность поставщика:

* деловую репутацию;

* степень завоевания рынка;

* длительность работы на рынке;

* желание сотрудничать с клиентом, особенно если требуется некоторая доработка продукта с учетом требований заказчика;

* способность предложить несколько альтернативных решений;

* способность предложить разумный по стоимости PKI-продукт, соответствующий стандартам и совместимый с продуктами большинства других поставщиков.

При выборе поставщика технологии PKI наиболее важны следующие критерии:

1 финансовые возможности поставщика;

2 масштабируемость решения ;

3 безопасность решения;

4 надежность операционной работы УЦ ;

5 техническая поддержка поставщика;

6 возможности консалтинга.

Финансовые возможности поставщика

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

* баланс компании, в том числе достаточный поток наличности и объем фондов для поддержания бизнеса;

* разумная стратегия привлечения новых клиентов;

* профессиональность менеджмента, поскольку бизнес в сфере компьютерной безопасности связан с динамично меняющимися рынком и требованиями заказчиков [105].

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

Масштабируемость решения

Функционирование системы PKI так или иначе затрагивает многие ресурсы (персонал, аппаратное и программное обеспечение), поэтому нельзя не учитывать, что с течением времени масштаб системы может существенно возрасти. Очевидно, что разнообразие практических реализаций PKI не позволяет предложить готовое решение поддержки масштабируемости, но тем не менее можно выделить "узкие места" функционирования системы, влияющие на ее расширяемость [116]:

* генерация ключей;

* хранение сертификатов;

* поддержка списков САС;

* управление жизненным циклом сертификатов и ключей.

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

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

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

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

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

Безопасность

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

Гарантии безопасности должны свидетельствовать о том, насколько организация может полагаться на точную и безопасную работу компонентов PKI. Для формального оценивания уровня доверия к определенному продукту могут использоваться критерии специальной программы сертификации или аккредитации. Существуют, например, критерии оценки криптографических модулей и независимые организации, выполняющие оценку в соответствии со стандартами. Имеются другие критерии и процедуры оценки, базирующиеся на "Общих критериях оценки безопасности информационных технологий" [59]. Существуют также лаборатории тестирования, которые сертифицируют продукты в соответствии с принятыми в отрасли критериями. Очевидно, что больший интерес для организации будут представлять известные PKI-продукты, которые удовлетворяют необходимым критериям.

Надежность операционной работы УЦ

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

* регулярно проходить проверки внешних аудиторов;

* строго документировать процедуры;

* сохранять распределение обязанностей при выполнении всех внутренних операций УЦ;

* поддерживать непрерывность операционной работы.

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

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

Техническая поддержка

Техническая поддержка является решающим моментом при выборе поставщика. Организации важно обратить внимание на следующие аспекты:

* режим предоставления технической поддержки;

* компетентность технических специалистов;

* ограничения на количество обслуживаемых клиентов, использующих линию технической поддержки;

* соглашение об уровне обслуживания в случае расширения организации.

На практике к обслуживанию инфраструктур открытых ключей средних и крупных компаний предъявляются следующие требования:

1 Предоставление технической поддержки ежедневно в круглосуточном режиме.

Так как PKI участвует в выпуске сертификатов и проверке их статуса, ее надежное функционирование должно поддерживаться непрерывно.

2 Компетентность технических специалистов.

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

3 Предоставление технической поддержки максимально возможному количеству клиентов, обращающихся за помощью по телефону.

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

4 Выполнение условий соглашения об уровне обслуживания в случае расширения организации.

Если соглашение содержит строгие требования, то масштабирование должно быть выполнено немедленно, самое большее - через час после первого обращения; менее строгие требования должны быть выполнены в течение 4-24 часов после первого обращения.

Помощь консультантов

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

Для оценки возможностей поставщика услуг консультирования оказывать помощь в развертывании PKI и интеграции организации необходимо:

* установить связи с несколькими ведущими консалтинговыми компаниями, ознакомиться с программами подготовки штата консультантов и убедиться в наличии сертификатов, подтверждающих их квалификацию;

* выбрать инструментальные средства интеграции с программным продуктом поставщика или внутренней системой;

* ознакомиться с опытом сотрудничества других организаций с консалтинговыми компаниями, оценить возможности, стоимость и качество услуг консультантов; учесть, что часто на практике расходы на услуги консультантов из-за сложности работ превышают заранее запланированные расходы; убедиться, что выбранная консалтинговая компания успешно работает и обладает проверенной на опыте методологией;

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

Анализ возможностей поставщика

В основном, лучший способ для организации сравнить возможности разных поставщиков - это предложить им участвовать в тендере и обратиться с просьбой подготовить свои предложения. Ниже содержатся рекомендации по составлению так называемого запроса на предложения (Request For Proposals - RFP) по реализации PKI [103], который обычно включает следующие разделы:

1 Краткая характеристика.

2 Введение

3 Область применения проекта

4 Управление проектом.

5 Архитектура безопасности.

6 Политика безопасности.

7 Стандарты и руководства по проектированию безопасности

8 Операционная работа УЦ.

9 Аудит

10 Обучение персонала.

11 Требования к консультантам.

12 Информация о реализованных поставщиком проектах.

Краткая характеристика

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

Введение

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

Область применения проекта

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

Желательно, чтобы в запросе на предложения были перечислены точные суммы и сроки выполнения проекта. При планировании следует допускать некоторое превышение бюджета и сроков; обычно хорошим показателем считается превышение на 20-30% стоимости и времени.

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

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

Управление проектом

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

Архитектура безопасности

Этот раздел запроса на предложения содержит описание требований безопасности для разных компонентов архитектуры PKI, включая требования отраслевых или государственных стандартов сертификации. К ним относятся:

* способы контроля хранения ключей подписи корневого УЦ на аппаратных устройствах в соответствии с высшим уровнем безопасности, предусмотренным стандартами для аппаратного устройства коммерческого назначения;

* способы защиты коммуникаций между разными компонентами решения, поскольку многие PKI-решения строятся по модульному принципу;

* способы обеспечения конфиденциальности и целостности данных, хранимых в системе (например депонируемых ключей, временных таблиц, используемых при обработке транзакций).

Политика безопасности

Этот раздел подчеркивает необходимость согласованности политики PKI с имеющимися корпоративными политиками безопасности и перечисляет ту информацию по безопасности PKI, которая важна для принятия решения о выборе поставщика:

* способы делегирования полномочий администраторов УЦ или РЦ;

* методы управления паролями (длина пароля; поддержка истории паролей; подсчет неудачных попыток ввода пароля), поскольку некоторые поставщики, прежде чем пользователь получит сертификат, используют пароли для защиты секретного ключа сертификата или в качестве временного метода контроля доступа;

* методы аутентификации и контроля доступа для защиты ресурсов администраторов PKI;

* способы уведомления пользователей о мониторинге их активности при попытке получить доступ к частной системе (если на сайте отсутствует соответствующее предупреждение, то пользователь впоследствии может заявить, будто не был уведомлен о том, что он взаимодействует с частной системой).

Стандарты и руководства по проектированию безопасности

В комплексных приложениях бывает необходимо сопоставлять условия фактического проекта и спецификации безопасности аппаратного или программного обеспечения поставщика. Этот раздел может быть опущен, если достаточно раздела " Архитектура безопасности ". С другой стороны, для оценки уровня квалификации поставщика могут изучаться процессы разработки программного обеспечения, схемы классификации информации и выполняться аудит кодов. Организация обычно предъявляет требования функциональной совместимости с рядом стандартов. Чем больше технология поставщика соответствует стандартам, тем легче выполняется интеграция и настройка на требования заказчика. В предложениях поставщик должен указать, поддерживает ли его решение такие открытые стандарты, как PKIX, X.509.v2, X.509.v3, OCSP, X.500, PKCS и криптографические алгоритмы RSA, ECC, DES, 3DES, RC4, AES, MD5, SHA-1 и др.

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

Операционная работа УЦ

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

* способы резервного копирования всех данных, включая файлы данных, программное обеспечение приложений и операционную систему. Чтобы система была надежной, критически важно понимание поставщиком требования непрерывности бизнеса, поскольку сложные и интегрированные компоненты PKI некоторых поставщиков усложняют стратегии резервирования;

* порядок регистрации всех событий в системе, включая вход и выход администраторов и пользователей, системные процессы и способ формирования отчета;

* порядок составления расписания (планирование периодов операционной работы и простоя) и информирования об этом заказчика; в ином случае организация не способна поддерживать непрерывность бизнеса;

* средства и процессы по поддержанию круглосуточной надежности (24 часа в сутки 7 дней в неделю) и доступности (99,9%) системы УЦ. Поставщик должен доказать, что способен поддерживать работу с данными клиента на самом высоком уровне надежности и доступности.

Аудит

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

Обучение персонала

Этот раздел содержит требования к перечню услуг поставщика, касающиеся помощи в подготовке и обучении персонала организации. Учитывая сложность технологии PKI, поставщик должен:

* предоставить рекомендуемые программы обучения системных администраторов и конечных пользователей; это характеризует комплексность решения поставщика и способствует более точному планированию расходов на обучение ;

* описать объем и содержание курса обучения, который может обеспечить поставщик;

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

Требования к консультантам

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

Информация о реализованных поставщиком проектах

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

Лекция 20. Проектирование и внедрение PKI

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

Проектирование

Ключевым аспектом развертывания PKI является выбор архитектуры и проектирование. PKI допускает гибкость проектирования независимо от выбранной технологии. Этап проектирования занимает длительное время, так как на этом этапе должна быть сформирована политика PKI и регламент, задана архитектура PKI, определены аппаратные и программные средства поддержки инфраструктуры, выбраны ее компоненты, сервисы, режимы работы, протоколы и базовые стандарты [20].

Формирование правовой политики PKI

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

Изучение политик PKI и стандартов

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

Основные правовые документы

Если организация решает самостоятельно сформировать правовую политику, то должна разработать следующие документы:

* политику применения сертификатов и регламент УЦ;

* политику аутентификации;

* политику конфиденциальности (в отношении сведений, предоставляемых пользователями в целях аутентификации).

Организация, эксплуатирующая PKI, должна заключить со своими внутренними и внешними пользователями соглашения, закрепляющие ответственность сторон. Правовое регулирование PKI предполагает заключение трех видов соглашений:

* cоглашение УЦ с РЦ ;

* cоглашение между конечными субъектами и РЦ ;

* cоглашение между подписчиками/конечными субъектами и УЦ (причем в качестве конечного субъекта может выступать человек или устройство).

Политика применения сертификатов и регламент УЦ

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

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

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

Регламент описывает процессы и процедуры выполнения УЦ операций с сертификатами. ППС характеризует надежность конкретного сертификата, а регламент - надежность самого УЦ. ППС разрабатывается на достаточно длительный срок и должна удовлетворять строгим требованиям, обычно она излагается в соответствии с форматом описания политики, который задает документ RFC 2527 Certificate Policy and Certification Practices Framework [152]. Этот документ содержит стандартный иерархический набор положений, сгруппированный в 8 основных разделов и 185 подразделов второго и третьего уровней (подробное описание формата ППС и регламента УЦ см. в лекции 14). Примерный перечень положений служит ориентиром при описании политики применения сертификатов и разработке регламента УЦ и помогает разработчикам политики и регламента не упустить важные моменты.

Соглашение между УЦ и РЦ

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

* размере компенсации РЦ удостоверяющему центру;

* финансовых гарантиях непрерывности функционирования УЦ;

* размере компенсации УЦ доверяющей стороне в случае выпуска фальшивого сертификата.

Соглашение между конечным субъектом и РЦ

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

* предоставлять правдивую информацию, которая используется при выпуске сертификата;

* использовать сертификат в соответствии с регламентом УЦ;

* обращаться с заявлением об аннулировании сертификатов, если соответствующие секретные ключи потеряны или скомпрометированы;

* прекращать использование всех пар ключей (открытый/секретный), срок действия которых истек, и не стараться выдать их за действующие ключи.

Соглашение между конечным субъектом и УЦ

Это соглашение можно назвать соглашением с доверяющей стороной. Оно содержит следующие положения:

* обязательство доверяющей стороны проверять статус сертификата перед его использованием, то есть убеждаться в том, что сертификат не просрочен и не аннулирован;

* обязательство доверяющей стороны использовать сертификат только по назначению, то есть в целях, установленных ППС и регламентом УЦ;

* размеры компенсации РЦ или УЦ в случае причинения ущерба доверяющей стороне.

В моделях аутсорсинга все эти соглашения уже существуют. В моделях инсорсинга требуется тщательное составление таких соглашений.

Модель доверия и архитектура PKI

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

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

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

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

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

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

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

В настоящее время иерархическая модель, как правило, используется в web-среде, некоторые корпоративные домены также адаптируют ее. Считается, что иерархическая модель является хорошим механизмом контроля политики подчиненных удостоверяющих центров, но на самом деле аналогичные возможности контроля существуют и у кросс-сертифицированных удостоверяющих центров [44].

Выбор программного продукта или поставщика сервисов PKI

Следующий шаг - выбор программного продукта или поставщика сервисов PKI. При выборе должны быть учтены возможности функциональной совместимости с другими программными продуктами / поставщиками услуг, легкость адаптации к открытым стандартам, удобство разработки, гибкость администрирования, масштабируемость и переносимость инсталляции [84]. Кроме того, важным критерием является наличие интерфейсов прикладного программирования (Application Program Interface - API) и поддержка распространенных приложений (например, виртуальных частных сетей, управления доступом, защищенной электронной коммерции, управления смарт-картами, сервисов каталогов, защищенной электронной почты и др.). Более подробно этот вопрос обсуждался в лекции 19, целиком посвященной проблемам выбора поставщика технологии или сервисов PKI.

Выбор основных средств и оборудования

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

Аппаратное и программное обеспечение УЦ и РЦ

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

* аппаратное обеспечение для защиты ключа подписи, предназначенного для функций РЦ, должно соответствовать требованиям по крайней мере минимального уровня безопасности, который способен обеспечить криптографический модуль, используемый внутри системы безопасности для защиты несекретной информации;

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

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

Серверы, предназначенные для PKI, должны обладать высокой производительностью, значительными системными ресурсами и возможностями. При выборе серверов должны оцениваться точный объем оперативной памяти и дискового пространства. Масштабируемость системы PKI может обеспечить аппаратное обеспечение типа SMP-систем (с симметричной мультипроцессорной обработкой).

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

Периферийные устройства

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

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

Не все поставщики технологии поддерживают периферийные устройства в одинаковой степени. Но если поставщики предлагают поддержку периферийных устройств, то должны придерживаться стандартных интерфейсов прикладного программирования.

Безопасность компонентов PKI

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

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

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

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

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

Выбор персонала для обслуживания PKI

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

Для развертывания PKI необходимы не только администраторы со знанием технологии цифровых сертификатов, но и специалисты, способные участвовать в разработке правовых документов и соглашений, таких как политики применения сертификатов и соглашения о кросс-сертификации (по сути, о функциональной совместимости между доменами PKI). Более того, важно, чтобы сама стратегия развертывания PKI была хорошо продумана и оформлена в виде документа, что также невозможно осуществить без опытного и знающего персонала. Конечно, в случае использования аутсорсинговой модели эти функции могут быть переданы поставщику услуг, но при самостоятельном развертывании PKI организации необходим квалифицированный и обученный персонал. Организации следует определить количество и уровень квалификации необходимого персонала, которые зависят от масштаба PKI, а также от того, в какой мере инфраструктура поддерживается собственными силами организации [44].

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

* инсталляция программного продукта;

* конфигурирование системы;

* системное администрирование;

* теория и практика PKI;

* криптография с открытыми ключами;

* информационная безопасность.

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

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

* наличие сертификата авторитетной организации, подтверждающего квалификацию в сфере ИТ-безопасности;

* подготовку в области информационной безопасности;

* опыт разработки программного обеспечения (если необходима интеграция);

* возможность быть доступным или по крайней мере оперативно взаимодействовать с ИТ-штатом, чтобы гарантировалась ежедневная круглосуточная работа PKI-системы.

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

* системный администратор;

* системный оператор;

* администратор УЦ;

* администратор РЦ;

* администратор каталога;

* специалист службы помощи;

* менеджер по политике безопасности;

* аудитор безопасности или главный администратор.

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

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

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

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

Специалисты службы помощи должны реагировать на обращения клиентов системы, руководствуясь соответствующими документами, описывающими процедуры обслуживания пользователей.

Для поддержки защищенного и эффективного функционирования PKI должна регулярно пересматриваться политика безопасности, за ее обновление отвечает менеджер по политике безопасности.

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

В процессе развертывания PKI также могут потребоваться услуги опытных консультантов и юрисконсультов для разработки и/или анализа ППС и регламента УЦ. Расходы на оплату труда персонала могут существенно повлиять на совокупную стоимость владения PKI и должны рассматриваться наряду с другими затратными факторами.

Завершение этапа проектирования

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

Создание прототипа, пилотный проект и внедрение

Создание прототипа

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

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

Пилотный проект

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

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

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

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

На базе пилотной системы выполняется:

* тестирование всех функциональных требований, производительности и операционных регламентов, а также всех наиболее важных приложений защиты [20];

* процедура пробного завершения работы системы, восстановление ее работы и проверка функционирования системы после этих операций;

* проверка физического и кадрового контроля безопасности в PKI.

Внедрение

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

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

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

Перечислим некоторые характерные ошибки при развертывании PKI:

* отсутствие планирования управления конфигурацией сети в случае изменений (в частности, размещения и связывания друг с другом отдельных компонентов PKI, а также их защиты и организации доступа к ним через маршрутизаторы и межсетевые экраны);

* отсутствие планирования "окон простоя";

* позднее обучение и привлечение к реализации проекта ИТ-персонала, который в дальнейшем будет обслуживать системы PKI;

* составление руководств пользователей без инструкций, объясняющих пользователям, как управлять изменениями в работе своих приложений после развертывания PKI;

* несвоевременное назначение администраторов УЦ и РЦ (их следует назначать до начала развертывания PKI).

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

Лекция 21. Проблемы реализации PKI

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

Проблемы реализации

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

* назначение PKI;

* время, необходимое для подготовки к функционированию PKI;

* возможность контроля среды пользователей;

* экспертиза во время и после развертывания;

* финансовые возможности.

Тремя ключевыми областями реализации PKI являются [105]:

1 подготовка системы PKI к работе;

2 управление сертификатами и ключами;

3 реагирование на инциденты во время функционирования PKI.

Подготовка системы PKI к работе

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

Подготовка системы PKI к работе зависит от выбранной модели развертывания: аутсорсинга или инсорсинга. Как известно, в модели аутсорсинга главные функции УЦ контролируются третьей доверенной стороной. Простейшие аутсорсинговые сервисы обеспечивают доступ ко всем функциям управления жизненным циклом сертификатов через web-страницу и Интернет-соединение, не требуя от организации установки специального аппаратного и программного обеспечения.

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

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

1 на основе персональной информации (известной только РЦ и пользователю);

2 через схему парольного кода, когда секретный код генерируется до начала регистрации и доставляется субъекту для выполнения процедуры регистрации.

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

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

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

Управление сертификатами и ключами

Управление сертификатами и ключами - существенный аспект успешной реализации PKI. Проблемы управления особенно актуальны для масштабных PKI с большим количеством владельцев сертификатов и пользователей [79]. К наиболее важным проблемам управления сертификатами и ключами относятся:

* выбор способа управления списками САС ;

* порядок обновления сертификатов ;

* поиск информации о статусе сертификатов;

* выбор способа генерации пары ключей ;

* порядок обновления ключей ;

* выбор способа хранения секретных ключей.

Выбор способа управления списками САС

Для функционирования PKI критически важно правильное управление списками САС: именно они обеспечивают проверку статуса используемого сертификата, так как дата окончания срока действия, указываемая в сертификате, не может служить подтверждением того, что данный сертификат является действительным.

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

Порядок обновления сертификатов

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

1 выпускается сертификат с новым сроком действия, но с теми же открытым ключом и регистрационной информацией, которые содержались в старом сертификате;

2 выпускается сертификат с новым сроком действия и новым открытым ключом, но с той же регистрационной информацией, которая содержалась в старом сертификате.

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

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

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

Поиск информации о статусе сертификатов

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

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

Выбор способа генерации пары ключей

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

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

Порядок обновления ключей

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

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

Выбор способа хранения секретных ключей

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

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

Карты PCMCIA. Ключ защищенно хранится на карте с микрочипом, но при вводе в систему "покидает" карту, следовательно, становится уязвимым для хищения.

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

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

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

Реагирование на инциденты во время функционирования PKI

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

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

Аннулирование

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

В PKI имеется несколько возможностей выявления и проверки аннулированных сертификатов:

* валидация в режиме реального времени (по протоколу OCSP), которая необходима при выполнении наиболее важных транзакций, например финансовых;

* проверка с запаздыванием, которая подходит для менее важных транзакций, таких как доступ к корпоративным порталам интрасети или экстрасети (в этом случае САС обновляется в течение суток).

Порядок обработки запросов об аннулировании

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

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

Выбор способа публикации САС

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

Публикация САС с опросом наличия изменений ("pull") выполняется в определенные запланированные моменты времени и может привести к ситуации, когда аннулированный сертификат некоторое время не включается в САС, а пользователи продолжают полагаться на него. Данный способ пригоден в большинстве случаев, но подвергает серьезному риску клиентов, которые используют критически важные для ведения бизнеса приложения, даже если планируемые обновления выполняются достаточно часто.

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

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

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

Восстановление, резервное копирование и хранение ключей в архиве

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

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

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

Депонирование

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

Любая организация, использующая PKI для критически важных целей бизнеса, должна обеспечивать выпуск двойных сертификатов (шифрования и подписи) и депонирование ключей шифрования [10]. Большинство систем PKI (даже аутсорсинговых) поддерживают депонирование секретных ключей шифрования и их хранение в собственной сети организации. Типичным способом поддержки неотказуемости является использование симметричного ключа для шифрования секретного ключа, а затем шифрование симметричного ключа при помощи открытого ключа УЦ. Если РЦ обращается с запросом о восстановлении депонированного ключа, то УЦ должен расшифровать симметричный ключ и отправить его РЦ. Только в этом случае РЦ может восстановить необходимый секретный ключ. Сам УЦ не может восстанавливать депонированные ключи, так как не имеет доступа к базе данных ключей шифрования и способен только расшифровать симметричный ключ.

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

Выбор способа и агента депонирования ключей

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

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

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

Планы реагирования на катастрофы и восстановления работы системы

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

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

Проблемы интеграции PKI

Важным фактором адаптации PKI является решение проблем интеграции и обеспечения работы приложений. PKI может быть интегрирована несколькими способами:

* с приложениями (например, клиентскими приложениями электронной почты);

* с данными третьей стороны (например, с базой данных аутентификации);

* с системами более сильной аутентификации (биометрией или смарт-картами);

* с существующими системами организации [105].

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

Интеграция с приложениями

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

Очевидно, что не все приложения совместимы с PKI, например, популярное приложение Microsoft Word не способно использовать возможности PKI. Для того чтобы заверить цифровой подписью договор, подготовленный в MS Word, и переслать его партнеру с гарантией соблюдения целостности, пользователю необходимо получить сертификат ключа подписи и воспользоваться дополнительным приложением, обеспечивающим выполнение криптографических функций.

Существует несколько способов придания приложению функций PKI. Чаще всего для этого используются инструментальные средства поставщика PKI. Инструментальный набор позволяет добавлять основные функции PKI, например, генерацию ключей. Разработчики должны затем адаптировать интерфейс пользователя для вызова специфических функций PKI, таких как формирование запроса на сертификат (см. рис. 21.1.).

Рис. 21.1. Пример интегрированного запроса к web-серверу

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

В настоящее время список PKI-совместимых программных средств растет, и можно ожидать, что эта тенденция сохранится. Некоторые наиболее популярные системы электронной почты и электронного документооборота являются PKI-совместимыми. Многие поставщики рынка виртуальных частных сетей также реализуют технологию открытых ключей (например, те, которые ориентируются на стандарт IKE [147]), кроме того, web-технология может рассматриваться как частично PKI-совместимая.

Интеграция с данными третьей стороны

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

Интеграция с системами более сильной аутентификации

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

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

Применение смарт-карт и управление их жизненным циклом также связано с использованием специального клиентского программного обеспечения и установки дополнительных драйверов. Поставщики смарт-карт могут использовать обычные стандарты типа CAPI (Cryptographic Application Programmer Interface) [112] и PKCS#11 [202]. Следует учитывать, что интеграция с системами более сильной аутентификации требует дополнительных финансовых затрат и затрат времени.

Интеграция с существующими системами

Поскольку любая организация использует существующую ИТ-инфраструктуру, часто возникают проблемы интеграции PKI с уже действующими системами. Обычно предполагается, что PKI будет обслуживать только системы на базе персональных компьютеров и PKI-совместимые приложения. Большинство программных продуктов для PKI не предназначено для работы в системах на базе UNIX или мейнфреймов. Для интеграции PKI с большими вычислительными системами необходимо программное обеспечение промежуточного слоя или передача данных вручную.

Интеграция с интерфейсом пользователя

Важным аспектом PKI, который часто упускается из виду, является удобство работы пользователя. Пользователь должен иметь простое и понятное средство формирования запросов на выдачу, обновление и аннулирование сертификатов. Большинство поставщиков PKI предлагают некоторый интерфейс пользователя, но, как правило, он является приложением, базирующимся на клиентском программном обеспечении, и не всегда приспособлен для работы на разных компьютерных платформах ( PC, UNIX, Mac ) или разных версиях.

Проблемы функциональной совместимости продуктов разных поставщиков

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

Анализ реальных возможностей функциональной совместимости

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

Формат X.509 или альтернативные форматы сертификатов

Как известно (см. лекцию 6), помимо формата X.509 существуют и альтернативные форматы сертификатов. Неудивительно, что имеются сторонники каждого формата. Так, например, сторонники формата SPKI утверждают, что сертификаты SPKI позволяют фиксировать роли и права авторизации, не раскрывая идентичность субъектов. Сторонники формата PGP или Open PGP считают важным преимуществом большую гибкость сертификатов PGP по сравнению с сертификатами открытых ключей X.509 v3 и, следовательно, большую пригодность для установления отношений доверия между субъектами. Однако пока большинство поставщиков PKI поддерживают только сертификаты X.509.

В будущем, возможно, получат распространение форматы сертификатов, основанные на языке разметки XML (eXtensible Markup Language) [66], который все чаще применяется в качестве формата для обмена информацией между разными приложениями в Интернете [44]. Новые форматы сертификатов, определенные техническим комитетом по сервисам безопасности OASIS в спецификации языка Security Assertion Markup Language (SAML) [95], вероятно, будут использоваться сообществом разработчиков бизнес-приложений на базе XML. Такие форматы могут заменить сертификаты X.509 на уровне XML -приложений, но, скорее всего, будут сосуществовать вместе с ними на другом уровне, для того чтобы осуществлялось взаимодействие с другими действующими инфраструктурами. Среда для такого взаимодействия может базироваться на спецификации управления ключами XML Key Management Specification [129], чтобы, как определено Консорциумом World Wide Web Consortium (W3C), скрывать от XML -приложения детали базовой PKI стандарта X.509.

Профили сертификатов и списки САС

Даже когда адаптируются технологии, основанные на стандартах, реализации PKI варьируются в зависимости от типа домена доверия. Это касается сертификатов и списков САС формата X.509. Для удовлетворения специфических требований разных доменов создаются разные профили сертификатов и списков САС. Для развертывания PKI важно выбрать поставщика технологии, который предлагает процедуру генерации сертификатов и списков САС, позволяющую учитывать требования многих профилей сертификатов и списков САС.

PKI-совместимые приложения

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

Проблемы репозитория

Многие корпоративные домены используют онлайновый репозиторий для своевременного и надежного распространения сертификатов, информации об их статусе, а также другой информации, имеющей отношение к PKI (например, информации о политике). Опыт развертывания PKI свидетельствует о том, что предоставление услуг репозитория не обходится без проблем, которые связаны с отсутствием единых стандартов, принятых в индустрии, и совместимостью продуктов PKI разных поставщиков [105].

Выбор репозитория

В PKI может быть реализовано несколько вариантов распространения сертификатов конечных субъектов, информации об их аннулировании и других релевантных данных; имеется ряд поставщиков, которые поддерживают один или несколько подобных сервисов. Как и в случае выбора поставщика технологии PKI, для организации важны гарантии, что поставщик репозитория предлагает гибкую функциональность и обеспечивает совместимость с продуктами многих поставщиков.

Отсутствие единых стандартов на сервисы каталога

Одна из проблем, связанных с сервисами каталога, заключается в отсутствии единого стандарта на эти услуги. Некоторые сегменты рынка адаптировали стандарты каталога X.500, но одновременно существует и разрабатывается большое количество стандартов, имеющих отношение к репозиторию. Например, известный упрощенный протокол доступа к каталогу LDAP, разработанный организацией IETF, с точки зрения технической перспективы находится в прямой конкуренции с протоколом DAP, базирующимся на стандарте X.500. Имеется еще ряд нерешенных проблем обмена информацией и взаимодействия "клиент-сервер" и "сервер-сервер". Рабочая группа LDAPext организации IETF разрабатывает ряд стандартов, таких как механизмы управления доступа и модели контроля доступа, в стадии разработки находится протокол LDUP [87], который, вероятно, будет конкурировать со своим двойником - протоколом DISP (Directory Information Shadowing Protocol) стандарта X.500. Кроме того, распространение информации PKI выполняется и другими способами (см. лекцию 12).

Хотя любое из этих решений может вполне соответствовать требованиям конкретной организации, при взаимодействии систем PKI разных организаций могут возникнуть проблемы функциональной совместимости разных решений.

Масштабируемость и производительность

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

Проблемы оценивания стоимости PKI

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

|Компонент | Стоимость | Комментарий |

|Аппаратное обеспечение | Высокая | Компьютерное оборудование, включая системы резервирования и безопасности. Аппаратное обеспечение состоит, по крайней мере, из 2-3 серверов, сетевого оборудования и инфраструктуры безопасности, включая межсетевые экраны |

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

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

Таблица 21.1.Структура стоимости установки типичной системы PKI (инсорсинг)

Развертывание систем PKI не требует таких больших капиталовложений и не занимает столько времени, как популярные недавно ERP-системы. Но все же немалые средства и время могут быть потрачены на неэффективную систему PKI. Таблицы 21.1, 21.2, 21.3 и 21.4 характеризуют, как примерно будет происходить амортизация капиталовложений в систему PKI в зависимости от варианта развертывания (инсорсинг или аутсорсинг) [105].

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

Поскольку система PKI является существенной частью инфраструктуры безопасности организации, она должна функционировать круглосуточно семь дней в неделю (24х7). Таблицы 21.3 и 21.4 иллюстрируют статьи расходов по поддержанию работы систем PKI для вариантов инсорсинга и аутсорсинга соответственно.

|Компонент | Стоимость | Комментарий |

|Аппаратное обеспечение | Низкая | Компьютерное оборудование, в том числе системы резервирования и безопасности. Базовое аппаратное обеспечение (web-серверов) для переадресации на аутсорсинговый УЦ, может быть включена консоль администратора (персональный компьютер). Резервное аппаратное обеспечение web-сервера, контролирующего функции управления жизненным циклом сертификатов |

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

|Услуги консультантов | Средняя | Предварительная экспертиза перед установкой и подготовкой к работе компонентов PKI. Анализ требований бизнеса заказчика для управления процессами аутентификации и подготовкой к работе УЦ. Настройка web-страниц и/или политик безопасности на требования заказчика |

Таблица 21.2.Структура стоимости установки типичной системы PKI (аутсорсинг)

|Компонент | Стоимость | Комментарий |

|Аппаратное обеспечение | Средняя | Компьютерное оборудование, в том числе системы резервирования и безопасности. Со временем аппаратное обеспечение необходимо заменять или модернизировать |

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

|Услуги консультантов | Низкая | Экспертиза требуется только тогда, когда возникает необходимость интеграции или существенно меняются условия ведения бизнеса |

Таблица 21.3.Структура стоимости технической поддержки типичной системы PKI (инсорсинг)

|Компонент | Стоимость | Комментарий |

|Аппаратное обеспечение | Низкая | Компьютерное оборудование, включая системы резервирования и безопасности. Со временем необходимо заменять или модернизировать аппаратное обеспечение |

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

Таблица 21.4.Структура стоимости технической поддержки типичной системы PKI (аутсоросинг)

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

В любом случае для оценивания общей стоимости владения (Total Cost of Ownership - TCO) PKI организации необходимо определить:

* количество и состав аппаратного оборудования, соответствующего потребностям сообщества, для которого предназначается PKI;

* начальные расходы на программное обеспечение и стоимость сопровождения и технической поддержки системы PKI;

* масштабы использования существующей ИТ-инфраструктуры организации;

* требования к ресурсам, необходимым для проектирования, развертывания, функционирования и сопровождения системы PKI;

* стоимость дополнительных площадей (если недостаточно имеющихся у организации) для размещения компонентов инфраструктуры;

* требования к доступности компонентов PKI и потребности в полном резервировании каких-либо компонентов;

* стоимость обучения администраторов, обслуживающего персонала и конечных пользователей;

* уровень консультационной помощи, предоставляемой конечным субъектам PKI;

* юридическую ответственность УЦ перед конечными субъектами и доверяющими сторонами

* необходимость взаимодействия и функциональной совместимости PKI с другими PKI-доменами и внешними пользователями [44].

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

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

Литература

1. Балакирский В.Б, Безопасность электронных платежей. Защита информации, Конфидент, № 5, 1996

2. Бернет С., Пэйн С, Криптография. Официальное руководство RSA Security, М.: Бином-Пресс, 2002

3. Бруно Л, Certificate Authorities: Кому Вы доверяете?, Data Communications (Russian edition). № 3, 1998

4. Вьюкова Н, Сервер аутентификации Kerberos,

5. Галатенко В.А, Информационная безопасность. Обзор основных положений, Jet Info. № 1-3, 1996

6. Галатенко В.А, Стандарты в области безопасности распределенных систем, Jet Info, № 5, 1999

7. Галатенко В.А, Основы информационной безопасности, М.: ИНТУИТ.РУ "Интернет-университет информационных технологий", 2003

8. Галатенко В.А, Стандарты информационной безопасности, М.: ИНТУИТ.РУ "Интернет-университет Информационных технологий", 2004

9. Горбатов В.С., Полянская О.Ю, Доверенные центры как звено системы обеспечения безопасности корпоративных информационных ресурсов, Информационный бюллетень Jet Info, № 11 (78), 1999

10. Горбатов В.С., Полянская О.Ю, Основы технологии PKI, М.: Горячая линия - Телеком, 2003

11. Горбатов В.С., Полянская О.Ю, Программная поддержка инфраструктуры с открытыми ключами, Безопасность информационных технологий, Вып. 2, МИФИ, 2001

12. , ГОСТ 34.003-90,

13. , ГОСТ 28147-89,

14. , ГОСТ Р 34.10-94,

15. , ГОСТ Р 34.11-94,

16. , ГОСТ Р 34.10-2001,

17. Евдокимов Н.А, Аутсорсинг и инсорсинг как инструменты управления затратами, Сетевой электронный научный журнал "Системотехника", № 2, 2004

18. , Закон РФ "Об электронной цифровой подписи",

19. Запечников С.В., Милославская Н.Г., Толстой А.И, Основы построения виртуальных частных сетей. М.: Горячая линия - Телеком, 2003,

20. Кадощук И, Как нам организовать PKI, Сетевой журнал, № 9, 2000

21. Карве А, Защищенный обмен сообщениями, LAN / Журнал сетевых решений, № 12, 1998

22. Карпов А Г, Удостоверяющий центр в системе электронного документооборота. Опыт построения открытых систем,

23. , Криптографический словарь (версия 2002.4),

24. Лукацкий А.В, Как обеспечить подлинность электронных документов,

25. Мэтью С, Инфраструктура открытых ключей: состояние и перспективы, Сетевой журнал, № 9, 2000

26. Никонова Е., Смирнов В., Копылов Д, Некоторые технологические аспекты реализации закона об ЭЦП, PC Week, № 15, 23 апреля, 2002

27. , Политика применения сертификатов ЗАО "Цифровая подпись",

28. Полянская О.Ю, Проблемы и риски в работе удостоверяющих центров,

29. Полянская О.Ю, Стандарты и спецификации в области инфраструктур открытых ключей. Безопасность информационных технологий, Вып. 1, М.: МИФИ, 2003

30. Полянская О.Ю, Проблемы секретности и ответственности в системах PKI, Сборник научных трудов ХI Всероссийской научной конференции "Проблемы информационной безопасности в системе высшей школы", МИФИ, 2004

31. Полянская О.Ю, Методы распространения информации в инфраструктурах открытых ключей, Безопасность информационных технологий, Вып. 4, М.: МИФИ, 2004

32. Полянская О.Ю, Модели доверия в инфраструктурах открытых ключей. Сборник научных трудов ХII Всероссийской научной конференции "Проблемы информационной безопасности в системе высшей школы", МИФИ, 2005

33. Полянская О.Ю, Сервисы, базирующиеся на инфраструктурах открытых ключей, Тезисы ХIV Общероссийской научно-технической конференции "Методы и технические средства обеспечения безопасности информации", Санкт-Петербург, 4-6 октября, 2005

34. Полянская О.Ю, Технология PKI как основа формирования безопасной среды ведения бизнеса. Сборник научных трудов ХIII Всероссийской научной конференции "Проблемы информационной безопасности в системе высшей школы", МИФИ, 2006

35. Полянская О.Ю, Современные бизнес-модели и решения развертывания PKI. Сборник научных трудов Всероссийской научно-технической конференции студентов, аспирантов и молодых ученых "Научная сессия ТУСУР-2006", Томск, ТУСУР, 4-7 мая, 2006

36. Рапоза Д, Незнакомая PKI, PC Week/RE, январь 2001

37. Семенов Г, Не только шифрование, или Обзор криптотехнологий, Jet Infosystems, № 3 (94), 2001

38. Симонович П.С, Регулирование электронной цифровой подписи нормами права: международный опыт, Журнал российского права, № 3, 2002

39. Харли Х, Конфиденциальность сообщений: будь начеку, LAN/Журнал сетевых решений, № 7-8,1999

40. Циммерман Ф.Р, PGP: концепция безопасности и уязвимые места, Журнал "Компьютерра", № 48, 1997

41. Шабат В, Каталоги LDAP и метакаталоги, Открытые системы, № 5, 2002

42. Шабат В, Стратегический взгляд на Identity Management, CIO (Директор ИС), № 1, 2003

43. Adams C., Lloyd S, Public-Key Certificates and Certification,

44. Adams C., Lloyd S, Understanding PKI. Concepts, Standards and Deployment Consideration. Second Edition, Addison-Wesley, 2003

45. Adams C., Zuccherato R, A General, Flexible Approach to Certificate Revocation,

46. , Advances and Remaining Challenges to Adoption of Public Key Infrastructure Technology, U.S. General Accounting Office, GAO-01-277, February, 2001

47. , AES Algorithm (Rijndael) Information,

48. , Architecture for Public-Key Infrastructure (APKI), Open Group Guide, G801, The Open Group, 1998

49. Aura T., Ellison C, Privacy and Accountability in Certification Systems, Helsinki University of Technology, Laboratory for Theoretical Computer Science, Research Report, April 2000

50. Bobbit M, PKI Policy Pitfalls, Information Security Magazine, July 2001

51. Burr. W., Dodson D., Nazario N., Polk W T, Minimum Interoperability Specification for PKI, Components, Version 1, 1997, NIST SP 800-15

52. , CCITT (International Telegraph and Telephone Consultative Committee). Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), Geneva, 1988

53. , CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), Geneva, 1988

54. , CCITT Recommendation X.500: The Directory, Geneva, 1993

55. , CCITT. Recommendation X.501: The Directory - Models, Geneva, 1988

56. , CCITT. Recommendation X.800: Security Architecture for Open Systems Interconnection for CCITT Applications, Geneva, 1991

57. Chadwick D.W., Otenko A., Ball E, Implementing Role Based Access Controls Using X.509 Attribute Certificates,

58. Chadwick D.W., Otenko A., Hunter D., Leoni C, Privilege Management for E-construction,

59. , Common Criteria for Information Technology. Security Evaluation, Part 3: Security Assurance Requirements. January 2004. Version 2.2

60. Cooper D.A., Polk W.T, NIST Recommendation for X.509 Path Validation Version 0.5, 2004

61. , Current Methods of Authentication,

62. , Delta CRLs,

63. Diffie W., Hellman M.E, New Directions In Cryptography,

64. Dittrich D, Network "sniffers" and You,

65. Ellison C., Schneier B, Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure, Computer Security Journal, vol. XVI, number 1, 2000

66. , Extensible Markup Language (XML) 1.0 (Third Edition),

67. Hallam-Baker P., Ford W, Internet X.509 Public Key Infrastructure. Enhanced CRL distribution options, Internet Draft, PKIX Working Group, August 1998

68. Hellberg S, SWEDAC-EID-SAT: Test specification of EID Cards and certificates,

69. Hesse P.M., Lemire D.P, Managing Interoperability in Non-Hierarchical Public Key In-frastructures,

70. Housley R., Polk W. T, Planning for PKI: Best practices for PKI Deployment, Wiley &Sons, 2001

71. , Integration of DCE with a Public Key Infrastructure,

72. , Introduction to Security Overview. Authentication and Identification Methods,

73. , Introduction to Single Sign-On, The Open Group,

74. , ISO/IEC 8824 Object Identifiers (OIDs),

75. , ISO/IEC JT1/SC27 WD 14516-1, Guidelines for the use and management of Trusted Third Party services - Part 1:General Overview, 1995.11

76. , ISO/IEC JT1/SC27 WD 14516-2, Guidelines for the use and management of Trusted Third Party services - Part 2: Technical aspects, 21.06.1996

77. , ITU-T (International Telecommunications Union) Recommendation X.509: Information Technology - Open Systems Interconnection -The Directory: Authentication Framework, 1997

78. , ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection - The Directory: Public Key and Attribute Certificate Frameworks", June 2000

79. Jarupunphol P., Mitchell C, PKI implementation issues in B2B e-commerce EICAR Conference Best Paper Proceedings, 2003

80. Johner H., Fujiwara S., Sm Yeung A., Stephanou A. W, Deploying a Public Key Infrastructure I, nternational Technical Support Organization, SG24-5512-00, February 2000

81. , Kerberos: The Network Authentication Protocol,

82. Kiran S., Lareau P., Lloyd S, PKI Basics - A Technical Introduction, A PKI Forum Note, November 2002

83. Kocher P.A, Quick Introduction to Certificate Revocation Trees (CRTs),

84. Kuhn D.R., Hu Vincent C., Polk W.T, Chang Shu-Jen, Introduction to Public Key Technology and the Federal PKI Infrastructure, National Institute of Standards and Technology, February, 2001

85. Lamport L, Password Authentication with Insecure Communication, Coomunications of the ACM, vol. 24, no. 11, 1981, p. 770-772

86. Lareau P, PKI Basics - A Business Perspective, A PKI Forum Note, April 2002, www.pkiforum.org/resourcees.html

87. , LDAP Duplication/Replication/Update Protocols (ldup),

88. Linn J., Branchaud M, An Examination of Asserted PKI Issues and Proposed Alternatives,

89. Lloyd S, Understanding Certification Path Construction, A PKI Forum White Paper, September 2002

90. Lloyd S, Paving the Road to PKI Interoperability,

91. Malpani A., Hoffman P., Housley R, Simple Certificate Validation Protocol (SCVP) Internet Draft November 2000,

92. , Minimum Interoperability Specification for PKI. Components, Version 2 - Second DRAFT, 2000. NIST PKI Project Team

93. Needham R. Schroeder M, Using Encryption for Authenticating in Large Networks of Computers, Coomunications of the ACM, vol. 21, no. 12, 1978, p. 995-999

94. , OASIS PKI Resources,

95. , OASIS Security Services (Security Assertion Markup Language - SAML) TC,

96. Olnes J., Verdier M., Ganivet N., Maillot D., Skretting J, Public Key Infrastructure and Certification Policy for Interdomain Management,

97. Perlman Radia, An Overview of PKI Trust Models,

98. , PGP User's Guide, Volume I: Essential Topics,

99. , PKI Interoperability Framework. PKI Forum White Paper,

100. Polk W.T., Hastings N.E., Malpani A, Public Key Infrastructures that Satisfy Security Goals,

101. Polk W.T., Hastings N.E, Bridge Certification Authorities: Connecting B2B Public Key Infrastructures, NIST,

102. , Public-Key Cryptography Standards, RSA Laboratories,

103. , Public Key Infrastructure. Request For Proposal. Object Management Group Document: ec/99-01-15,

104. , Public Key Infrastructure Standards,

105. Raina K, PKI Security Solutions for Enterprise: Solving HIPAA, E-Paper Act, and Other Compliance Issues, Wiley Publishing, Inc., 2003