Журнал о системах электронного документооборота (СЭД)
Технологические аспекты безопасности

Архитектура PKI у нас построена просто из рук вон как плохо...

  11 комментариев Добавить в закладки

Собираю боекомплект из компонент ДТСа для заказчика, просматриваю доки и ловлю себя на мысли (в очередной раз), что-то, как построена архитектура 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

Похожие записи
Комментарии (11)
Вячеслав Смирнов 12 марта 2015 г. 10:45  
А теперь смотрим что у нас на сейчас в квалифицированном домене. Выбрав за якорь самоподписанный сертификат автора подписи (а так оно по жизни и есть, и даже есть судебные решения (кому интересно могут поискать в постах Натальи Храмцовской) о том, что именно так и надо делать), мы, при проверке сертификата автора ЭЦП не учитываем ограничения, входящие в кросс от ГУЦ до аккредитованного УЦ, а там между прочим может быть что-то написано и по факту написано, например, глубина равная 1 уровню.

Разве такое технически возможно?

Допускаю, что может быть один ключевой набор, на котором создано два разных сертификата автора подписи, и у УЦ может быть несколько сертификатов на одном наборе:

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

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

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

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

Вячеслав Смирнов 12 марта 2015 г. 14:11  

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

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

Sergey  Murugov 12 марта 2015 г. 14:32  
Вячеслав, речь шла несколько о другом. Цепочка строится до якоря (точки доверия). Весь вопрос в том, что является якорем и какие ограничения наложены на связи от якоря до УЦ издающего ЕЕ-сертификаты. В приведённой вами цитате, говорилось о том, что кросс от ЦУ1(2) до сертификата аккредитованного УЦ как минимум содержит ограничение на глубину = 1, т.е. этот кросс говорит о том, что цепочка глубже 1 уровня не должна строиться. Это если мы за якорь взяли сертификат ГУЦа. А вот если мы за якорь возьмем самоподписанный сертификат аккредитованного УЦ (забыв про то что выше по домену расположено), то мы, строя цепочку про это ограничение даже и не узнаем, и цепочки будут считаться действительными, даже если из-под аккредитованного УЦ насоздавать подчиненных УЦ на любую глубину и из под них понавыпускать ЕЕ-сертификаты. ++++++++++++++ Попутно, у нас по 63-ФЗ + Приказ 795 запрещено использовать один и тот же ключевой набор для выпуска разных сертификатов :-) Аналогия с копией паспорта не корректна.
Вячеслав Смирнов 12 марта 2015 г. 15:14  

Да, именно.

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

Всё из-за начала предложения:

Выбрав за якорь самоподписанный сертификат автора подписи (а так оно по жизни и есть, и даже есть судебные решения (кому интересно могут поискать в постах Натальи Храмцовской) о том, что именно так и надо делать)
где говорится про сертификат автора подписи.
Учитывая что по 63-ФЗ + Приказ 795 запрещено использовать один и тот же ключевой набор для выпуска разных сертификатов

начал свой комментарий с вопроса: Разве такое технически возможно?

Технически такое невозможно. Юридически можно обосновать эквивалентность, как меня заверили.

Что касается кросс-сертификации. По закону ФЗ 63 от 2011 года:

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

(стр. 2, документ ФЗ 63 взял с http://e-trust.gosuslugi.ru/Doc)

Законодательно не отражено, как технически выполнять проверку аккредитации УЦ. Удобно реализовать проверку следующим образом - построить цепочку до ГУЦ. Цепочка до ГУЦ может быть только одна. Таким образом, кросс-сертификаты отпадают, возможность их использования на стороне подписанта отпадает. Просто и надёжно.

На странице http://e-trust.gosuslugi.ru/CA есть список сертификатов действующих аккредитованных УЦ. Кросс-сертификатов в списке нет. Ссылка в правом верхнем углу страницы на XML представление, позволяет автоматизировать обновление списка промежуточных УЦ.

Sergey  Murugov 12 марта 2015 г. 15:49  

Вячеслав,

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

По моей ошибке (видимо торопился писал) пропущено слово "издателя", т.е. должно быть:
"Выбрав за якорь самоподписанный сертификат издателя автора подписи ..."

2. Выпустить кучу сертификатов на один и тот же ключевой материал технически вполне возможно, вся беда в том, что это создаст коллизии по связке субъект-ключ, и именно поэтому сие законодательно запрещено.
3. Про кроссы, вы совершенно правы, что ввиду отсутствия в квалифицированных сертификатах хоть каких специальных атрибутов, говорящих что эти сертификаты есть квалифицированные (в Европе например в сертификате есть спец атрибут на эту тему) определить ху из ху невозможно не построя цепочки сертификации от ГУЦа, но её построить невозможно (ещё один косяк реализации PKI в РФ) нарушается п. 24 Приказа 795 ФСБ. Посему, чтоб не заморачиваться народ тупо работает из-под самоподписанного сертификата издателя аккредитованного УЦ, игнорируя всё что сверху.
4. Список сертификатов аккредитованных УЦ - это наследие ещё от ФАИТа когда за модель доверия был взят европейский трастед статус лист, потом 1-ФЗ заменили на 63-ФЗ где нарисована иерархия, но технику ни кто не стал переделывать, вот косяки полезли. Скажу более кроссы, явно противоречат п.4 Ст. 13 63-ФЗ:
"
4. Удостоверяющий центр вправе наделить третьих лиц (далее - доверенные лица) полномочиями по созданию и выдаче сертификатов ключей проверки электронных подписей от имени удостоверяющего центра, подписываемых электронной подписью, основанной на сертификате ключа проверки электронной подписи, выданном доверенному лицу этим удостоверяющим центром."
Обращаю внимание ключевым тут является "подписываемых электронной подписью, основанной на сертификате", т.е. в подписании ЕЕ-сертификата должен участвовать именно тот сертификат который получен в ГУЦе, а не самоподписанный (с тем же открытым ключом) - эта кривизна стала причиной невозможности выполнить п. 24 Приказа 795 ФСБ, но как принято у нас в стране на это все закрыли глаза.

 

Вячеслав Смирнов 12 марта 2015 г. 16:37  
Скажу более кроссы, явно противоречат п.4 Ст. 13 63-ФЗ

На сколько знаю, УЦ при выдаче выдают сертификаты с использованием того сертификата, для которого строится цепочка до ГУЦ. Не встречал пока случаи, когда использовался именно кросс-сертификат при выдаче. Нарушения ФЗ 63 на практике не встречал.

Единственное нарушение регламентов, что видел своими глазами, заключалось в следующем:

  1. УЦ говорит, что как сертификаты, так и ключевые пары, формируемые перед выдачей сертификатов имеют ограниченные сроки действия. И эта информация зафиксирована в регламенте работы любого УЦ.
  2. УЦ выдаёт сертификаты, которые формируют цепочку: ГУЦ -> ГУЦ 1/2 -> Сертификат УЦ (действующий 5-10 лет) -> Дочерний сертификат УЦ (на 1 год) -> Сертификат пользователя (на 1-2 года).
  3. В атрибутах у "Дочерний сертификат УЦ (на 1 год)", написано, что срок действия закрытого ключа - также один год.
  4. Но когда один год проходит, и ключевая пара для Дочерний сертификат УЦ (на 1 год) становится недействительной, УЦ выпускает на этой же ключевой паре новый сертификат, снова на один год. Что противоречит его же регламенту.

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

 

Sergey  Murugov 12 марта 2015 г. 17:23  

1. Почти (кроме нескольких государственных) все УЦ работают от своих самоподписанных сертификатов, что как я писал ранее противоречит п.4 ст. 13 63-ФЗ. Не заметить это невозможно!

2. От сертификата конечного пользователя до ГУЦа цепочку построить невозможно по стандарту, поскольку невозможно выполнить требование п. 24 Приказа 795 ФСБ. Это очевидно, посмотрите и проверьте сами серийные номера сертификатов и их родителей по всем сертификатам из цепочки, косяк вылезает на связке ЕЕ-сертификат и серийный номер в кросс-сертификате - они разные, в ЕЕ-сертификате указывает серийник родителя из самоподписанного издателя УЦ, а не серийник кросса .

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

4. Следует различать срок действия открытого ключа == сроку действия сертификата (фактически это период когда ЭЦП на ключе из сертификата может считаться действительной) и период действия закрытого ключа (может указываться атрибутом в сертификате так и называется "Период действия закрытого ключа") - это период времени в который можно пользоваться закрытым ключом и вырабатывать ЭЦП. И эти периоды разные у нас в РФ, посему понять что из-под чего выпустили и перекрываются ли сроки из вашего примера мне сложно. А если говорить на профессиональном техническом языке, то в мире существуют методики на корректность построения цепочки сертификации, например, разработанные НИСТом (PKITS - “Public Key Interoperability Test Suite (PKITS) Certification Path Validation”, Version 1.0, September 2, 2004.) ещё в 2004 году и в 2011 претерпевшие ревизию. Там порядка 256 тестов с всевозможными комбинациями. Посему, если средство подписи прошедшие такие тесты сможет построить цепочку сертификации, то всё ОК, если нет, то не ОК.

Вячеслав Смирнов 12 марта 2015 г. 19:57  

Проверил строится ли цепочка по идентификаторам ключей. Для имеющихся в наличии сертификатов от удостоверяющих центров ekey, Корус, Тензор, СКБ Контур. Строится.

При перевыпуске сертификата достаточно лишь скопировать поля:

  • oid 2.5.29.35 authorityKeyIdentifier
  • oid 2.5.29.14 subjectKeyIdentifier

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

За отсылку к PKITS - “Public Key Interoperability Test Suite (PKITS) Certification Path Validation”, Version 1.0, September 2, 2004 спасибо, изучу. Сделал для целей тестирования удостоверяющий центр. Чтобы выдавать почти квалицированные сертификаты тестовым пользователям. Опирался на rfc, документацию по bouncy castle, анализ сертификатов/crl/ocsp от ekey и помощь коллег по работе. Думаю, пройду тест NIST.

Sergey  Murugov 12 марта 2015 г. 22:53  
Похоже мы просто говорим о разном. Я не говорю о том как выкрутится из ситуации, я говорю о том, что согласно закона надо полученный кросс засунуть в виде издателя в аккредитованный УЦ (тогда кросс уже перестанет называться кроссом, а будет называться сертификатом подчиненного издателя и в этом случае нужды в самоподписанном (созданном в УЦ который готовится стать аккредитованным, но ещё им не стал) нет ни какой и он не должен использовать вообще)) и от него и работать. Но у нас этого никто не делает, полученный из МКС кросс вешают на стенку в рамочке, а вся работа идет из-под самоподписанного. С формальной точки - всё это приводит к тому что у нас подавляющее (написал подавляющее, потому что всё же некоторые (писал об этом выше) УЦ работают именно по закону) число квалифицированных ЕЕ-сертификатов таковыми по виду не являются и если докопаться до сути это может привести в суд с неизвестными последствиями.
Sergey  Murugov 12 марта 2015 г. 23:14  

Вдогонку, если строить цепочку средствами Windows, то цепочка строится от ЕЕ-сертификата до ГУЦа через кросс что с правильным (указывается серийный номер сертификата участвующего в выпуске пользовательского сертификата - ровно что требует Приказ 795) authorityCertSerialNumber внутри authorityKeyIdentifier , что с неправильным, при условии если правильно заполнить другое поле из authorityKeyIdentifier. У Виндусни эта такая фьюча :-) видимо они считают что поля структуры обрабатываются как логическое "или", т.е. достаточно указать хоть немного правдивой инфы в  authorityKeyIdentifier и этого достаточно :-)

Вячеслав Смирнов 13 марта 2015 г. 09:03  

Сергей, охотно верю, что корректный сертификат большинство УЦ повесит на стенку. Извечное плавило: "Работает - не трогай". И извечное объяснение: "Никто же не жаловался".
После пятого письма в техподдержку у УЦ начинает строиться верная цепочка. После десятого письма, выясняется, что OCSP-сервис есть в наличии. Если начать писать письма, то УЦ повезло с клиентом, и постепенно работа налаживается. Нормальный рабочий процесс.
Уверен, Вы сумеете объяснить техническим специалистам любого УЦ, что же от них требуется.
Как поётся в одной песне: "Не стоит прогибаться под изменчивый мир".

Выбрав для работы несколько УЦ (по цене, по качеству, ...), можно договориться. И рекомендовать их своим пользователям. Постепенно расширяя список проверенных УЦ. 

Гибкость работы Crypto API Windows по формированию цепочки доставляет проблем. Есть предположение, что после применения своих особых вариантов формирования цепочки, выбирается наиболее короткая цепочка и возвращается, как единственно найденная. Потому, как если есть шанс не построить цепочку до ГУЦ, то она обязательно не строится. 

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

Спасибо за интересную дискуссию. Буду рад продолжить

Сейчас обсуждают
Евгений Кочуров 20 марта 2017 г. 07:49  
Юрий Зерин 18 марта 2017 г. 19:18  
Сергей Бушмелев 15 марта 2017 г. 22:47  
Елена Истомина 15 марта 2017 г. 13:08  
Сергей Бушмелев 15 марта 2017 г. 10:46  
Больше комментариев