2.1.6. Метод сертификации открытых ключей.Инфраструктура открытых ключей
Инфраструктура открытых ключей (ИОК) - это универсальная концепция организованной поддержки криптографических средств защиты информации в крупномасштабных информационных систе- 104 Запечников С.
В. Криптографические протоколы и их применение мах в соответствии с принятыми в них политиками безопасности, которая реализует управление криптографическими ключами на всех этапах их жизненного цикла, обеспечивая взаимодействие всех средств защиты распределенной системы.Логически ИОК объединяет механизмы, субъекты, правила и взаимосвязи, которые необходимы для доступа к криптографиче-ским ключам и для ассоциирования открытых ключей со своими владельцами.
Физически ИОК состоит из программ, форматов данных, комму-никационных протоколов, политик и процедур, требуемых для ис-пользования в организации криптосистем с открытым ключом.
ИОК может быть интегрирована со всеми основными операци-онными системами (ОС), сетевым ПО и основными прикладными программами (ПП). Чтобы использовать сервисы, предоставляемые ИОК, в прикладных программах, они должны быть адаптированы или должны быть разработаны новые прикладные программы.
Важно иметь в виду, что создание инфраструктуры открытых ключей имеет целью комплексную поддержку всего жизненного цикла открытых криптографических ключей в целом, а не только каких-либо отдельных его фаз, например распространения ключей (хотя последняя задача и является технически наиболее сложной).
Международные организации, занимающиеся стандартизацией информационных технологий, разработали ряд моделей ИОК, из которых наиболее известными и распространенными являются модели SPKI, РЮХ и APKI.
Модель SPKI (Simple Public Key Infrastructure) - наиболее простая модель ИОК, разработанная Международной инженерной орга-низацией по сети Интернет (IETF).
Проект SPKI направлен на соз-дание простой, минимально необходимой криптографической ин-фраструктуры и представлен двумя документами серии RFC (Request for Comments):RFC 2692 - «SPKI Requirements»;
RFC 2693 - «SPKI Certificate Theory».
Модель PKJX (Public Key Infrastructure for X.509) обеспечивает существенно более широкую функциональность и основана на стан-дарте Международного телекоммуникационного союза ITU Х.509. Ее составляют несколько уже утвержденных стандартов RFC и по- рядка 20 проектов (draft) стандартов RFC. К утвержденным стандар-там относятся:
RFC 2459 - «Internet Х.509 Public Key Infrastructure Certificate and CRL»;
RFC 2510 - «Internet X.509 Public Key Infrastructure Certificate Management Protocols»;
RFC 2511 - «Internet X.509 Certificate Request Message Format»;
RFC 2527 - «Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework»;
RFC 2528 - «Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates»;
RFC 2559 - «Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2»;
RFC 2560 - «Internet X.509 Public Key Infrastructure Online Certificate Status Protocol - OCSP»;
RFC 2585 - «Internet X.509 Public Key Infrastructure Operational Protocols - FTP and HTTP»;
RFC 2559 - «Internet X.509 Public Key Infrastructure LDAPv2 Schema».
В настоящее время именно модель PKIX претендует стать стан-дартом ИОК не только в сети Интернет, но и вообще в любых сетях, построенных на базе коммуникационной архитектуры TCP/IP.
Элементы технологии ИОК реализуются множеством произво-дителей программного обеспечения, включая такие известные фирмы, как IBM, RSA, Entrust Technologies и др. На уровне отдельной организации, систем документооборота между организациями или в пределах одной отрасли эта технология уже может быть реализована имеющимися программными средствами.
На государственном уровне в России реализация ИОК - это, по-видимому, вопрос более или менее недалекого будущего: по крайней мере такую перспективу от-крывает принятый в январе 2002 г. Федеральный закон РФ от 10 января 2002 г. № 1-ФЗ «Об электронной цифровой подписи». В Российской Федерации он является основным документом, регу-лирующим правовые аспекты деятельности, связанной с задачами управления ключами и функционированием удостоверяющих центров. На глобальном, общемировом уровне работы по стандартиза- ции ИОК на базе сети Internet ведутся рядом международных орга-низаций.Рассмотрим вкратце основное содержание метода сертификации открытых ключей.
Пусть имеется криптосистема, включающая большое число уча-стников (рис. 2.2). Среди участников криптосистемы выделяется один, специальный, которому доверяют все остальные. Он получает названи& удостоверяющий центр, или центр сертификации ключей, или агентство сертификации (Certification Authority - С А). Его функции может выполнять, например, администратор системы, ос-нащенный соответствующим аппаратным и программным обеспече-нием (сервер регистрации и сертификации ключей). Все остальные участники являются обычными, «рядовыми» абонентами криптосистемы.
Участники криптосистемы
(Sa, РА)
Рис. 2.2. Процессы получения и использования сертификатов участниками криптосистемы
При введении в систему каждого из этих участников - возьмем для примера участника А - он должен пройти процедуру регистра-ции в криптосистеме (что соответствует первой фазе жизненного цикла его криптографического ключа). Для этого он контактирует с удостоверяющим центром, чтобы зарегистрировать свой открытый ключ и получить от него так называемый сертификат своего от-крытого ключа.
Удостоверяющий центр должен проверить пред-ставленные ему учетные данные, а также (что очень важно!) знание секретного ключа, соответствующего представленному для регист-рации открытому ключу. Решить эту задачу можно различными спо-собами: в самом простом случае удостоверяющий центр может по-просить А зашифровать на своем секретном ключе текст заданного формата и проверить правильность его расшифрования при помощи представленного открытого ключа, а можно воспользоваться прото-колом доказательства знания с нулевым разглашением знания.Сертификат открытого ключа - специальная структура дан-ных, состоящая из полей данных и поля подписи. Поле данных содержит как минимум какие-либо признаки абонента (идентификатор, атрибуты) и его открытый ключ. Поле подписи - это цифровая подпись удостоверяющего центра под полем данных, логически свя-зывающая признаки абонента с его открытым ключом.
Все абоненты, заинтересованные в связи с абонентом Л, получают впоследствии его сертификат либо путем обмена с абонентом А, либо извлекая его из открытого общедоступного справочника, который заводится в криптосистеме. Сертификат, таким образом, является средством для хранения, распространения и передачи через не-безопасные каналы связи открытых ключей без опасения их необна- ружимого изменения.
Различают две формы сертификатов открытых ключей: иденти-фикационные и атрибутные.
В идентификационном сертификате обязательно присутствует идентификатор субъекта - владельца ключа, по которому можно од-нозначно установить его личность. Основным стандартом по иден-тификационным сертификатам является стандарт Международного телекоммуникационного союза ГШ Х.509. В соответствии со стан-дартом Х.509 сертификат имеет следующий формат (рис. 2.3).
Версия сертификата
Серийный номер сертификата
Идентификатор алгоритма цифровой подписи, используемого удостоверяющим центром
Имя удостоверяющего центра (директорнальнос имя по стандарту X. 500)
Период действия сертификата
Имя владельца открытого ключа (діфекторнальнос имя по стандарту X.
500)Информация об открытом ключе владельца:
цденшфнкатор алгоритма;
значение открытого ключа.
Уникальный идентификатор удостоверяющего центра, выпустившего сершфикат (v2)
Уникальный идентификатор владельца отрытого ключа (v2) Поле раеппфения (v3): содержание не определено
Цифровая подпись удостоверяющего центра под всеми предыдущими палями
Рис. 2.3. Формат сертификата открытого ключа по стандарту ITU Х.509
Сертификат состоит из двух полей: поля данных и поля подписи. Поле данных имеет формат, описанный в стандарте. Поле подписи содержит цифровую подпись удостоверяющего центра под полем данных. Существует две версии этого стандарта, которые принято обозначать X.509v2 и X.509v3. Различие между ними заключается в том, что в версии 2 определены поля «Уникальный идентификатор удостоверяющего центра, выпустившего сертификат» и «Уникальный идентификатор владельца открытого ключа», а в версии 3 стан-дарта эти поля исключены, но предусмотрено наличие в поле данных дополнительного поля расширения, содержание которого не определено: оно может специфицироваться другими стандартами, зависеть от области применения информационной системы и т. п.
Самыми разработанными и широко применяемыми на практике логическими моделями ИОК на базе идентификационных сертифи-катов являются следующие:
Х9.55 - стандарт США для финансовой индустрии;
PKIX - проект стандарта IETF на базе стандарта X.509v3, адап-тирующий положения этого стандарта для использования в сети Internet;
APKI - архитектура для ИОК, описанная в документах The Open Group.
Однако использование идентификационных сертификатов не всегда желательно для пользователей, так как при этом может про-исходить доступ к информации, не имеющей отношения к тому случаю, по которому необходим данный конкретный факт доступа к сертификату. Возможность однозначно установить личность вла-дельца по сертификату может привести к установлению «тотального контроля» над участниками криптосистемы.
В связи с этим было предложено использовать другую форму сертификатов.Атрибутные сертификаты связывают открытый ключ с одним или более «атрибутов», которые в соответствии со стандартом Меж-дународного телекоммуникационного союза X.50I (эквивалентный стандарт - ISO/IEC 9594-2) определяются как «информация любого типа». Таким образом, один и тот же участник в зависимости от си-туации и используемой прикладной программы может предстать в разных «ипостасях», между которыми невозможно установить одно-значную связь. К примеру, атрибутом может быть роль пользователя в информационной системе, например путем указания его должно-сти. Тогда можно реализовать модель управления доступа «по ро-лям», т. е. участники системы, занимающие одну и ту же должность, имеют абсолютно одинаковые права в системе и невозможно уста-новить, кто именно из них совершил конкретное действие с приме-нением данного конкретного сертификата.
Наиболее разработанными и широко применяемыми на практике логическими моделями инфраструктуры открытых ключей на основе атрибутных сертификатов являются:
Х9.57 - стандарт США для финансовой индустрии;
SPKI - проект стандарта IETF для использования в сети Internet.
і
Удостоверяющий центр (центр сертификации открытых ключей) - это специально выделенный участник криптосистемы, которому доверяют все остальные участники («центр доверия»), чья
подпись служит гарантией подлинности ключей и который выпол-няет следующие функции:
сбор сведений об участниках системы, необходимых для сер-тификации: имя, почтовый адрес, права доступа, должность, номер кредитной карты и т. п. (зависит от конкретного приложения);
генерация и рассылка (либо помещение в общедоступное хра-нилище) сертификатов открытых ключей;
уничтожение сертификатов с истекшим сроком годности;
обновление сертификатов;
аннулирование сертификатов.
Аннулирование сертификата может потребоваться в случаях, когда срок санкционированного использования открытого ключа участника системы прерывается досрочно, ранее, чем это преду-смотрено принятым в системе регламентом, например при ком-прометации секретного ключа участника криптосистемы, соот-ветствующего данному открытому ключу, при удалении (выбы-тии) владельца ключа из системы, при смене роли пользователя в системе (перемещении пользователя). Аннулирование сертификата - это чрезвычайное обстоятельство, о котором необходимо оповестить всех участников криптосистемы. Существует два способа решения этой задачи.
Проверка статуса сертификата в режиме реального времени. Для этого требуется выполнение специального протокола с удосто-веряющим центром, который отвечает на вопрос, не был ли запро-шенный сертификат аннулирован.
Периодическое создание и рассылка списков аннулированных сертификатов (Certificate Revocation List - CRL). Формат CRL оп-ределен в стандарте ITU X.509v2 (рис. 2.4).
Второй способ на практике используется чаще. Однако у него есть один существенный недостаток: между двумя последователь-ными рассылками списка аннулированных сертификатов всегда су-ществует какой-то временной «зазор», т. е. об аннулировании сер-тификата какого-либо участника все остальные участники узнают не мгновенно, а только по прошествии некоторого времени. Наличие такого разрыва создает угрозу несанкционированного использования аннулированного ключа.
Идентификатор алгоритма цифровой подписи, используемого удосто-веряющим центром
Имя удостоверяющего центра (директориальное имя по стандарту Х500)
Дата и время текущего обновления Дата и время следующего обновления
Серийный номер сертификата Дата аннулирования Дополнительные поля
Поле расширения
Цифровая подпись удостоверяющего центра под всеми предьщущими полями
Рис. 2.4. Формат списка аннулированных сертификатов по стандарту ITU Х.509 v2
Удостоверяющий центр рассылает всем участникам системы свой открытый ключ, который нужен им для проверки подписи на сертификатах. Считается, что подменить его невозможно в силу трех причин: массовости рассылки, периодического повтора и об-щедоступности.
В криптосистемах с большим числом участников или с большой интенсивностью потока требований к удостоверяющему центру функции регистрации участников нередко возлагают на специально выделяемый центр регистрации (Registration Authority - RA).
Сертификаты всех участников криптосистемы могут либо хра-ниться в специальном общедоступном хранилище, либо рассылаться по сети. На практике преимущественно используется первый способ, причем физически хранилище сертификатов чаще всего реали-зуется либо с использованием директориального сервиса (директо-рия, к которой открыт доступ на чтение всем участникам), либо веб- сервиса (веб-страница, с которой все участники криптосистемы могут забирать сертификаты).
Преимущество сертификата в том, что два участника системы, доверяющие одному и тому же удостоверяющему центру, могут не знать и не хранить открытые ключи никаких других абонентов, а при необходимости обратиться в хранилище сертификатов и получить необходимые ключи. Для этого ему достаточно знать только открытый ключ удостоверяющего центра. Это позволяет применять метод сертификации открытых ключей в криптосистемах со сколь угодно большим и даже неопределенным числом участников, где все участники не покрыты сетью непосредственных контактов между собой.
Теперь для того, чтобы узнать открытый ключ любого интере-сующего его абонента, участнику криптосистемы (обозначим его В) необходимо однократно приобрести аутентичный открытый ключ удостоверяющего центра (что технически реализовать не сложно). Далее для установления связи с абонентом А ему необходимо:
приобрести сертификат открытого ключа А одним из следую-щих способов: обратившись в хранилище сертификатов, непосред-ственно получив его от удостоверяющего центра или от абонента А (зависит от порядка, установленного в системе);
выполнить процедуру проверки сертификата, состоящую из следующих действий:
проверки текущей даты и времени и сравнения с периодом действия сертификата;
проверки действительности в данный момент времени открытого ключа самого удостоверяющего центра;
проверки подписи удостоверяющего центра на сертификате от-крытого ключа абонента А, используя открытый ключ удостове-ряющего центра;
проверки, не был ли сертификат аннулирован к текущему моменту времени.
в случае, если все проверки окончились с положительным ре-зультатом, принять открытый ключ, извлеченный из сертификата А как аутентичный ключ.
Далее В может использовать открытый ключ абонента А для вы-полнения любых необходимых ему криптографических алгоритмов или протоколов. К примеру, участники А и 5, приобретя таким обра- зом открытые ключи друг друга, могут выработать общий секрет-ный ключ для симметричной криптосистемы.
Хотя сертификат является вспомогательным средством для транспортировки и обеспечения подлинности открытого ключа, он, как и сам ключ, имеет свой жизненный цикл. В его жизненном цикле можно выделить те же стадии и ряд состояний, в которых пребы-вает сертификат: создание, рассылка, штатное использование, об-новление или аннулирование, уничтожение сертификата.
Недостаток метода сертификации открытых ключей заключается в том, что участникам криптосистемы после проверки сертификата часто все равно необходим доступ в реальном масштабе времени в базу данных с информацией о других участниках криптосистемы (например, для проверки аннулирования сертификата либо для того, чтобы получить какие-то дополнительные данные об этом участни-ке, необходимые для работы прикладных программ). Это не всегда удобно, поэтому сейчас наблюдается «откат» к модели ИОК с удо-стоверяющим центром, работающим не в отложенном режиме, а в реальном масштабе времени.