Архитектура PKI у нас построена просто из рук вон как плохо...
Собираю боекомплект из компонент ДТСа для заказчика, просматриваю доки и ловлю себя на мысли (в очередной раз), что то, как построена архитектура PKI у нас просто из рук вон как плохо. В первую очередь это касается процедуре построения цепочки сертифик...
Собираю боекомплект из компонент ДТСа для заказчика, просматриваю доки и ловлю себя на мысли (в очередной раз), что-то, как построена архитектура PKI у нас просто из рук вон как плохо. В первую очередь это касается процедуре построения цепочки сертификации (как одного из этапов проверки ЭЦП).
Вопросы признания действительной цепочки сертификации автора
ЭЦП или проверяемого сертификата тесно связаны с выбранной моделью организации
доверия в конкретной PKI, в том числе ограничениями на промежуточные связи от проверяемого
сертификата до издателя, который считается доверенным.
Чтоб было совсем наглядно покажу на прикреплённом рисунке – там нарисован
Бридж, поскольку на этой модели распределения доверия наиболее явно видна
проблема. К слову, на иерархии проблема тоже никуда не девается.
Из рисунка видно, что цепочка сертификации должна строиться
с учетом всех четырех ограничений.
Другими словами, выбирая за якорь сертификаты различных УЦ, входящих в цепочку
сертификации, можно получить разные результаты процедуры определения
действительности сертификата автора ЭЦП.
А теперь смотрим что у нас на сейчас в квалифицированном домене. Выбрав за якорь самоподписанный сертификат автора подписи (а так оно по жизни и есть, и даже есть судебные решения (кому интересно могут поискать в постах Натальи Храмцовской) о том, что именно так и надо делать), мы, при проверке сертификата автора ЭЦП не учитываем ограничения, входящие в кросс от ГУЦ до аккредитованного УЦ, а там между прочим может быть что-то написано и по факту написано, например, глубина равная 1 уровню.
Поразмыслив и «посовещавшись с товарищами» родились некоторые тезисы, которые надо бы не забыть, тому, кому это поручат, раскрыть в НПА для вновь исправляемого 63-ФЗ:
1) Зафиксировать профиль сертификата со всем возможным наполнением, зафиксировать строго, жестко, без возможности что-либо самолично на местах вписывать. Напомню, сейчас идет отсылка на RFC 5280, а там столько понаписано!!!
2) Зафиксировать правила построения иерархии, включая необходимые ограничения в рамках обозначенных в п1 (на глубину, на дерево имен, на политики применения). Подразумеваются требования к сертификатам подчиненных издателей. Сюда же, добавить регламент по переходным процедурам смены главного корня; этот регламент возможно потребуется применить при переходе от текущей системы УЦ к новой, и потом, при внедрении новых алгоритмов, которое наверняка случится раньше, чем формально протухнут ключи ГУЦ-а (или нового корня).
3) Зафиксировать процедуру шага проверки цепочки с учетом для расширений, отсутствующих в международных стандартах: как проверять ФСБшные issuerSignTool\subjectSignTool и т.п.
4) Зафиксировать дополнительные ограничения на процедуру проверки в целом: что строить необходимо до реального корня иерархии, какие дополнительные параметры могут\должны передаваться на вход процедуре: ограничение на глубину, ограничение на список допустимых политик, запрет на спец-политику "anyPolicy", запрет на использование эквивалентных политик применения (запрет маппинга)
5) Внятно прописать минимально-допустимый SLA (Service Level Agreement – соглашение о качестве обслуживания, которое по-хорошему должно быть частью CertificatePracticeStatement) для УЦ входящих в систему – в первую очередь по времени реакции системы на изменение статуса – от момента регистрации обращения пользователя, до момента публикации информации об изменении статуса (понятно, что время реакции в 24 часа это не серьёзно и влечёт огромнейшие риски).
Оригинал поста в группе Facebook* Новая стратегия развития госуслуг.
Источник: LLC Top Cross
* - организация, признанна экстремистской на территории РФ
Похожие статьи
Комментарии 6
Разве такое технически возможно?
Допускаю, что может быть один ключевой набор, на котором создано два разных сертификата автора подписи, и у УЦ может быть несколько сертификатов на одном наборе:
Если задача только криптографическая, то любой сертификат из пары, созданной на общем ключевом наборе, подойдёт для расшифровки хеша и проверки целостности подписанных данных. Но к квалифицированной подписи приложен конкретный сертификат, с конкретным уникальным отпечатком и набором атрибутов. А также в подписи есть полная цепочка до головного удостоверяющего центра. Именно такой формат подписи и именно такой набор атрибутов делает подпись квалифицированной.
Сколько бы сертификатов на общем ключевом наборе не было бы установлено на стороне клиента. В самой подписи есть только один сертификат подписанта и только один вариант цепочки. Только один сертификат и одна цепочка должны использоваться для корректной проверки квалифицированной электронной подписи.
Если кто-то делает иначе, и проверяет лишь целостность подписанных данных, используя только открытый ключ (который повторюсь может быть общим для нескольких сертификатов) - то это пример неполной проверки подписи. Если кто-то сумел доказать, что такая проверка подписи является правильной, то это гипнотизёр.
Спросил у людей, сведующих в юридических вопросах. Оказывается, можно доказать правоспособность использования другого сертификата на том же ключевом наборе, что и ключевой набор квалифицированного сертификата.
Мне привели аналогию использования копии паспорта при заключении сделки, даже копии незаверенной нотариусом. Что позже можно будет доказать корректность сделки, ведь настоящий паспорт также имеется. Единственное ограничение - условия договора, если условиями договора запрещено использование копий паспорта, то будет нельзя их использовать.
Да, именно.
Первый комментарий строил на мысли о том, что может существовать самоподписанный сертификат конечного пользователя. И что электронная подпись с таким сертификатом какими-то решениями суда признаётся столько же сильной как и квалифицированная.
Всё из-за начала предложения:
начал свой комментарий с вопроса: Разве такое технически возможно?
Технически такое невозможно. Юридически можно обосновать эквивалентность, как меня заверили.
Что касается кросс-сертификации. По закону ФЗ 63 от 2011 года:
квалифицированный сертификат ключа проверки электронной подписи (далее -квалифицированный сертификат) - сертификат ключа проверки электронной подписи, выданный аккредитованным удостоверяющим центром или доверенным лицом аккредитованного удостоверяющего центра либо федеральным органом исполнительной власти, уполномоченным в сфере использования электронной подписи (далее - уполномоченный федеральный орган).
(стр. 2, документ ФЗ 63 взял с http://e-trust.gosuslugi.ru/Doc)
Законодательно не отражено, как технически выполнять проверку аккредитации УЦ. Удобно реализовать проверку следующим образом - построить цепочку до ГУЦ. Цепочка до ГУЦ может быть только одна. Таким образом, кросс-сертификаты отпадают, возможность их использования на стороне подписанта отпадает. Просто и надёжно.
На странице http://e-trust.gosuslugi.ru/CA есть список сертификатов действующих аккредитованных УЦ. Кросс-сертификатов в списке нет. Ссылка в правом верхнем углу страницы на XML представление, позволяет автоматизировать обновление списка промежуточных УЦ.
На сколько знаю, УЦ при выдаче выдают сертификаты с использованием того сертификата, для которого строится цепочка до ГУЦ. Не встречал пока случаи, когда использовался именно кросс-сертификат при выдаче. Нарушения ФЗ 63 на практике не встречал.
Единственное нарушение регламентов, что видел своими глазами, заключалось в следующем:
Такое нарушение делается из-за того, что сертификаты конечных пользователей бывает выдаются так, что они устаревают позже, чем устаревает сертификат УЦ, которым подписаны конечные сертификаты пользователей. И чтобы цепочка не разорвалась при продлении сертификата УЦ, используется та же ключевая пара для обновлённого сертификата.
Проверил строится ли цепочка по идентификаторам ключей. Для имеющихся в наличии сертификатов от удостоверяющих центров ekey, Корус, Тензор, СКБ Контур. Строится.
При перевыпуске сертификата достаточно лишь скопировать поля:
в новый сертификат, на том же ключевом наборе. Что несложно. И цепочка не разорвётся. Вот если бы цепочка строилась по уникальным отпечаткам сертификатов, то тогда бы она разрывалась.
За отсылку к PKITS - “Public Key Interoperability Test Suite (PKITS) Certification Path Validation”, Version 1.0, September 2, 2004 спасибо, изучу. Сделал для целей тестирования удостоверяющий центр. Чтобы выдавать почти квалицированные сертификаты тестовым пользователям. Опирался на rfc, документацию по bouncy castle, анализ сертификатов/crl/ocsp от ekey и помощь коллег по работе. Думаю, пройду тест NIST.
Сергей, охотно верю, что корректный сертификат большинство УЦ повесит на стенку. Извечное плавило: "Работает - не трогай". И извечное объяснение: "Никто же не жаловался".
После пятого письма в техподдержку у УЦ начинает строиться верная цепочка. После десятого письма, выясняется, что OCSP-сервис есть в наличии. Если начать писать письма, то УЦ повезло с клиентом, и постепенно работа налаживается. Нормальный рабочий процесс.
Уверен, Вы сумеете объяснить техническим специалистам любого УЦ, что же от них требуется.
Как поётся в одной песне: "Не стоит прогибаться под изменчивый мир".
Выбрав для работы несколько УЦ (по цене, по качеству, ...), можно договориться. И рекомендовать их своим пользователям. Постепенно расширяя список проверенных УЦ.
Гибкость работы Crypto API Windows по формированию цепочки доставляет проблем. Есть предположение, что после применения своих особых вариантов формирования цепочки, выбирается наиболее короткая цепочка и возвращается, как единственно найденная. Потому, как если есть шанс не построить цепочку до ГУЦ, то она обязательно не строится.
Программное формирование цепочки сертификатов - надёжный способ выхода из ситуации для разработчика. А пользователю остаётся только удалить самоподписанные сертификаты УЦ, оставив в хранилище Windows сертификаты, заверенные ГУЦ.
Возможно, ещё столкнусь с ситуацией, когда идентификаторы ключей не будут выстраиваться в цепочку. Уверен, что ситуация не будет тупиковой. Вместе с коллегами многое повидали, справимся.
Спасибо за интересную дискуссию. Буду рад продолжить