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

Технология PKI не нова. Если считать от момента возникновения алгоритма Меркле по распределению ключа – то технологии уже 42 года, если считать от момента возникновения RSA – то 39 лет. Возраст в любом случае внушительный. За это время технология существенно эволюционировала и позволяет создать солидный список сервисов для других приложений и пользователей.

Сами сервисы регламентированы в ряде стандартов, в серии X.500 – это серия стандартов ITU-T (1993 г.) для службы распределенного каталога сети и серии RFC (Request for Comments) – документ из серии пронумерованных информационных документов Интернета, охватывающих технические спецификации и стандарты, широко используемые во Всемирной сети. Причем серия RFC первична. Основная масса RFC о PKI была выпущена компанией RSA, одной из отцов(мам)-основателей технологии PKI.

PKI и его стандарты

Отдельно следует упомянуть всякого рода национальные стандарты и нормативные требования, к примеру, в РФ это ФЗ-63, приказы ФСБ России № 795 и 796 и прочие производные от них. Следует учитывать, что многообразие стандартов RFC и описанных в них функций PKI породило несколько организационно-нормативных подходов к построению инфраструктуры PKI в отдельно взятой стране. Для иллюстрации приведу список сервисов PKI, которые описаны в стандарте X.842:

• Key Management Services
• 1 Key Generation Service
• 2 Key Registration Service
• 3 Key Certification Service
• 4 Key Distribution Service
• 5 Key Installation Service
• 6 Key Storage Service
• 7 Key Derivation Service
• 8 Key Archiving Service
• 9 Key Revocation Service
• 10 Key Destruction Service
• Certificate Management Services
• 1 Public Key Certificate Service
• 2 Privilege Attribute Service
• 3 On-line Authentication Service Based on Certificates
• 4 Revocation of Certificates Service
• Electronic Notary Public Services
• 1 Evidence Generation Service
• 2 Evidence Storage Service
• 3 Arbitration Service
• 4 Notary Authority
• 5 Electronic Digital Archiving Service
• Other Services
• 1 Directory Service
• Identification and Authentication Service
• 1 On-line Authentication Service
• 2 Off-line Authentication Service
• 3 In-line Authentication Service
• 4 In-line Translation Service
• Recovery Services
• 1 Key Recovery Services
• 2 Data Recovery Services
• 5 Personalisation Service
• 6 Access Control Service
• 7 Incident Reporting and Alert Management Service

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

Цепочка сертификации и цепочка доверия

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

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

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

Цепочка доверия между людьми строится при помощи построения цепочки сертификации. Делается это следующим образом: в роли третьей доверенной стороны выступает аккредитованный удостоверяющий центр. Это юридическое лицо, обладающее одним или несколькими наборами оборудования, которое реализует функции удостоверяющего центра. Аккредитация означает, что это юридическое лицо отвечает ряду требований законодательства, у него есть соответствующие лицензии ФСБ, Минкомсвязи и иногда ФСТЭК России, должным образом оборудованные помещения, обученный персонал с правильными дипломами и сертифицированные ПО и оборудование в роли удостоверяющего центра (УЦ). Так вот, этот удостоверяющий центр уполномочен государством подтверждать вашу электронную подпись другим лицам. Процедура подтверждения вашей электронной подписи удостоверяющим центром является процессом создания цепочки сертификации, так как сертификат УЦ так же подписывается Главным удостоверяющим центром (ГУЦ), который является единой точкой доверия. Что такое электронная подпись и как она работает – вопрос за рамками данной статьи, об этом можно почитать в других источниках.

Для того чтобы этот УЦ мог точно сказать, что под документом именно ваша подпись, вам надо прийти в центр регистрации этого УЦ и предоставить ваш открытый ключ, запрос на сертификат, паспорт и ряд других документов. В результате вы получите сертификат открытого ключа, подписанный на ключе данного УЦ. Аналогом этого являются 2-я и 3-я страницы внутреннего паспорта гражданина РФ, там тоже стоит ваша уникальная подпись, ФИО и указано, какой орган эти данные заверил. Но есть небольшое различие – в случае паспорта доверие к его носителю строится через подтверждение подлинности самого паспорта, а потом уже через данные, которые в нем указаны. В электронном мире УЦ принято доверять, только если оба пользователя, которые пытаются общаться между собой, обслуживаются в этом УЦ. В случае если УЦ у каждого пользователя свой, встает проблема доверия между УЦ. Путей ее решения несколько, путь снизу подразумевает кросс-сертификацию между УЦ разных пользователей. Такой путь хорош, когда УЦ не много, но если каждое ведомство развернет себе свой УЦ, получится ситуация, которая возникла в РФ к 2002–2005 годам: множество УЦ по стране, а единого пространства доверия нет, так как кросс-сертификация среди 800 УЦ – штука технически нереальная.

И вот тут возникает вопрос – как построить единое пространство доверия в отдельно взятой стране так, чтобы оно работало. Подход, который используется в РФ и не только – создание Главного удостоверяющего центра (государственного) (ГУЦ), подпись его сертификатом всех сертификатов УЦ в стране, как результат – построение цепочки доверия через проверку действительности всех сертификатов в подписи через ГУЦ. Такой подход подразумевает, что проверяются подпись пользователя, действительность сертификата пользователя, действительность всех сертификатов в цепочке (УЦ–ГУЦ). Проверка действительности сертификатов в различных странах производится по-разному. В Эстонии и на Украине для этого требуется обратиться к OCSP/TSP-службе ГУЦ, которая ответит – действующий сертификат или же срок действия истек или сертификат отозван. В России для проверки надо запросить у каждого УЦ в цепочке список отозванных сертификатов (СОС) и проверить, что сертификат в нем не указан. Пожалуй, наиболее развитым вариантом построения системы PKI следует считать схему с использованием мостообразующего УЦ, в том виде, в котором она используется в США. Федеральный мостообразующий УЦ (бридж) США содержит несколько базовых служб функции которых следует разобрать в отдельной статье.

Сложности

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

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

Сложность третья. Если сертификат отозвали, УЦ обязан его добавить в список отозванных сертификатов (СОС), обязанность эта прописывается в RFC, если они приняты как стандарт в стране, или в регламенте ГУЦ, к которому обязаны присоединиться все аккредитованные УЦ. В случае когда СОС (CRL) большой, УЦ для удобства пользователей выпускает дельта СОС (deltaCRL) с изменениями за короткий период. В регламенте ГУЦ прописана периодичность обновления 12 часов или по факту отзыва сертификатов. В реальности различные УЦ свои СОС публикуют как хотят, существуют некоторые УЦ, которые обновляют их 1 раз в несколько месяцев. Или же СОС подписывается ключом, который не имеет отношения к сертификату УЦ, что тоже сводит шанс построить цепочку доверия к нулю. Потихоньку возникает проблема с обработкой самих СОС, за время существования УЦ они уже стали достаточно большого размера, но дельта СОС не выпускает почти никто.

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

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

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