Электронная подпись кажется простым инструментом, но за ней стоит сложная инфраструктура доверия. Ошибки в работе с трастлистами и сертификатами могут приводить к отказам и юридическим рискам даже для добросовестных пользователей.
- 1. Введение
- 2. Основа доверия в PKI — трастлист
- 3. Риски изменения и некорректной обработки TSL
- 4. Почему проверка ЭП работает не всегда
- 5. Практический пример проверки электронной подписи
- 6. Выводы
Введение
Использование электронной подписи — только внешне простой процесс. Этот популярный механизм защиты информации на основе инфраструктуры открытых ключей (ИОК, PKI, Public Key Infrastructure) имеет сложную архитектуру и сложный процесс обработки. Особенно если мы говорим о квалифицированной электронной подписи.
В статье мы рассмотрим некоторые актуальные аспекты функционирования отечественной инфраструктуры открытых ключей, от которой зависит доверие к квалифицированной электронной подписи, созданной добросовестным участником ЭДО.
Основа доверия в PKI — трастлист
В таких вопросах лучше зреть в корень, то есть в механизм распространения доверия к корневым и подчинённым сертификатам. Таковым в российской PKI является список доверенных сервисов (Trusted Services List, TSL, траст-лист), который ведёт Минцифры России. Это — XML-документ, содержащий информацию о сертификатах корневого УЦ Минцифры (ГУЦ) и подчинённых сертификатах аккредитованных УЦ, подписанный электронной подписью уполномоченного лица Минцифры России. От его доступности, целостности, аутентичности, актуальности, обрабатываемости и эффективности способов доведения информации об изменениях в нём зависит доверие к инфраструктуре открытых ключей в целом и, как следствие, к каждому механизму безопасности на её основе.
То есть если траст-лист внепланово изменился, а владелец информационной системы, к которой вы получаете доступ с помощью своей электронной подписи, не уведомлён об изменении и не установил, например, новый корневой сертификат ГУЦ в доверенные корневые сертификаты, то получить доступ к такой информационной системе смогут не все добросовестные пользователи этой информационной системы.
Для примера можно обратиться к многолетнему опыту PKI в ЕС, где разработана техническая спецификация ETSI TS 119 612 V2.3.1 «Electronic Signatures and Trust Infrastructures (ESI); Trusted Lists», которая устанавливает требования к аналогичным доверенным спискам (Trusted Lists). Благодаря этому органы, выпускающие TSL, понимают свои роли и обязанности, а пользователи могут легко получить актуальную информацию об аккредитованном поставщике доверенных услуг, а также об услугах, которые он предоставляет. Кроме того, для каждой услуги доступна история статусов.
Особенная ценность использования TSL как единого доверенного списка информации об АУЦ (аккредитованном удостоверяющем центре) для участников ИОК (информационного обмена между компетентными органами) — это возможность не только отследить историю статусов АУЦ, но и видеть перечень сертификатов АУЦ, которые были для него выданы головным УЦ.
Риски изменения и некорректной обработки TSL
Однако случается и такое, что из обновлённого TSL ГУЦ исчезают некоторые сертификаты АУЦ. Это приводит к тому, что ЭП, основанные на сертификатах, цепочки доверия к которым строились ранее через удалённые после обновления TSL сертификаты АУЦ, с этого момента не пройдут проверку. Средства ЭП, проверяющие статус аккредитации УЦ, будут строить цепочку до корневого сертификата в TSL и не найдут там соответствующего сертификата АУЦ.
Это живой пример того, как нерегламентированное обращение с TSL (к сожалению, пока нельзя говорить о том, что TSL сопровождается оператором этого сервиса с заданными и известными показателями качества) может повлечь ложноотрицательный результат проверки квалифицированной электронной подписи.
Почему проверка ЭП работает не всегда
Рассмотрим ещё один риск для добросовестного пользователя ЭП, скрытый «под капотом» средств электронной подписи. Если средство ЭП подтверждает отсутствие изменений в подписанном электронном документе, проверяемый сертификат не отозван и успешно строится цепочка сертификатов до корневого удостоверяющего центра, то это ещё не всё, что нужно, чтобы квалифицированную электронную подпись можно было считать действительной.
Согласно 63-ФЗ, проверке должны подлежать все сертификаты из цепочки сертификации. Все они должны быть квалифицированными, а значит, выданными аккредитованными удостоверяющими центрами. При этом статья 11 63-ФЗ чётко определяет, что аккредитация интересующего нас АУЦ должна быть действительна на день выдачи указанного сертификата.
И тут встаёт вопрос к средствам электронной подписи — а могут ли они проверить статус аккредитации удостоверяющего центра на момент издания сертификата? Во-первых, для этого средство электронной подписи должно работать с TSL. Этот список содержит всю необходимую информацию: наименование АУЦ, его реквизиты, класс средств ЭП, дату начала и окончания аккредитации, статус аккредитации и прочие сведения.
Во-вторых, средство электронной подписи должно уметь определить дату выпуска TSL.
В-третьих, средство ЭП должно проверить электронную подпись, опираясь на знание о том, что на сегодняшний день сертификат прекратил своё действие согласно статье 17 63-ФЗ, но на день создания подписи при наличии метки доверенного времени и действительности статуса аккредитации удостоверяющего центра сертификат был действительным.
Совокупность всех «должно» необходимо учесть в момент проверки квалифицированной электронной подписи, и вот тут-то многие средства электронной подписи могут дать осечку.
Показательным стал случай прекращения аккредитации двух УЦ в 2024 году. При этом многие средства электронной подписи признавали действительными сертификаты, изданные УЦ, аккредитация которых была прекращена, и информация об этом была размещена в TSL. То есть они либо совсем не работали с TSL при проверке, либо не обновляли TSL (работали со старым, в котором ещё не было информации о прекращении аккредитации).
Практический пример проверки электронной подписи
Разберём ситуацию с проверкой квалифицированной электронной подписи на примере:
УЦ имеет действующую аккредитацию до 20.12.2025 и выдаёт сертификат заявителю 09.12.2025.
Добросовестный владелец квалифицированного сертификата 10.12.2025 создаёт усовершенствованную квалифицированную электронную подпись, то есть подпись, содержащую метку доверенного времени и информацию о статусе сертификата на момент создания подписи. Подписанный электронный документ отправляется контрагенту.
Новогоднего чуда для УЦ не происходит, и 21.12.2025 истекает его аккредитация. Статус в TSL обновляется на «Аннулирована».
Контрагент вспоминает о полученном подписанном электронном документе только 30.12.2025 и пытается проверить его электронную подпись. На момент проверки сертификат владельца становится отозванным, о чём уже есть информация в списке отозванных сертификатов (CRL). Поэтому, если средство ЭП не умеет проверять электронные подписи с метками доверенного времени, такая подпись будет ошибочно признана недействительной.
Допустим, что контрагент использует средство электронной подписи, которое умеет правильно проверять усовершенствованные форматы ЭП, например Litoria Desktop 2. Тогда квалифицированная электронная подпись будет признана действительной, потому что:
- Проверка электронной подписи будет выполнена на момент её создания благодаря наличию метки доверенного времени, то есть на 10.12.2025.
- Квалифицированный сертификат создан и выдан АУЦ, аккредитация которого действительна на день выдачи указанного сертификата, то есть на 09.12.2025.
- Статус квалифицированного сертификата на 10.12.2025 зафиксирован в формате усовершенствованной подписи и является «действительным».
- Срок действия ключа электронной подписи, указанный в квалифицированном сертификате, не истёк на момент подписания электронного документа.
- Имеется положительный результат проверки принадлежности владельцу квалифицированного сертификата квалифицированной электронной подписи, с помощью которой подписан электронный документ, и подтверждено отсутствие изменений, внесённых в этот документ после его подписания.
Таким образом, подписанный электронный документ не потеряет своей юридической силы и может быть использован в хозяйственной деятельности организации.
Выводы
Ведение траст-листа ГУЦ Минцифры требует регулирования. Это может быть на нормативном уровне сделано в форме соглашения об уровне обслуживания (SLA), а на нормативном техническом — в форме национального стандарта, учитывающего лучшие мировые практики и отечественную специфику. Пока это не реализовано, требуются специальные решения, которые будут брать на себя регулярную актуализацию траст-листа для проверки ЭП в прикладной информационной системе и ведение истории его изменений. Таким средством, например, может выступать Litoria Nova компании «Газинформсервис».
Операторы информационных систем, использующих функциональность квалифицированной электронной подписи, должны иметь в штате персонал, обладающий достаточной квалификацией, чтобы оперативно, согласно указанным нормативам, учитывать обновления траст-листа. В частности, например, уметь установить новый корневой сертификат ГУЦ Минцифры в список доверенных корневых сертификатов.
Не все средства ЭП правильно строят цепочки сертификатов и умеют работать с усовершенствованными форматами электронной подписи. При выборе средств электронной подписи на это нужно обращать внимание. Litoria Desktop 2 корректно обрабатывает усовершенствованные форматы ЭП и работает с TSL.
Статья подготовлена при участии специалистов компании «Газинформсервис»: советника генерального директора — начальника удостоверяющего центра, к. т. н. Сергея Кирюшкина и менеджера по продуктам Litoria Богдана Мишко.
