Сравнение средств электронной подписи

...

В период с 2019 по 2023 годы федеральный закон № 63-ФЗ претерпел ряд изменений. Все они требуют модификации программных решений и устоявшихся корпоративных процессов, связанных с электронной подписью (ЭП) и шифрованием. Поговорим о том, как вендоры средств ЭП адаптируют свои продукты к этим изменениям.

Введение
Критерии оценивания средств электронной подписи
Методика сравнения
Сравнение
Выводы

Введение

Крупными мазками очертим изменения в 63-ФЗ, принятые в период 2019–2023 гг.:

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

Все эти изменения стали катализатором роста инфраструктуры открытых ключей (Public Key Infrastructure, PKI), т. е. набора служб, сервисов и компонентов, необходимых для реализации механизмов ЭП, шифрования данных, защиты каналов их передачи и строгой аутентификации.

К составляющим PKI теперь относятся УЦ и его службы (служба проверки статусов сертификатов в режиме онлайн (OCSP) и на основе данных об отзыве (CDP), служба штампов времени (TSP), реестры отозванных и актуальных сертификатов, служба хранения ключей ЭП в УЦ); доверенная третья сторона (ДТС); ключевые пары и выпущенные для них сертификаты; криптопровайдер; владельцы сертификатов; машиночитаемые доверенности (МЧД) и реестры для их хранения (государственный реестр Федеральной налоговой службы России, реестры аккредитованных УЦ, корпоративные реестры).

Масштабирование PKI должно находить и находит отражение в программных средствах, реализовывающих механизмы ЭП и шифрования, поскольку они должны уметь работать с новыми компонентами.

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

Критерии оценивания средств электронной подписи

Давайте опишем каждый критерий, выделенный для проведения сравнительного анализа. Это поможет пояснить, зачем они были приняты.

Сертификат соответствия на средство электронной подписи

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

В отношении средств ЭП проводится их оценивание на соответствие приказу ФСБ России от 27 декабря 2011 г. № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра». Согласно 63-ФЗ «Об электронной подписи», только такие средства могут использоваться для работы с квалифицированной ЭП.

При этом если организации достаточно неквалифицированной ЭП, то и к средству ЭП не предъявляется обязательных требований по наличию сертификата соответствия. Тут также отметим, что для работы с неквалифицированной ЭП даже использование российских криптографических алгоритмов не обязательно, можно применять криптографию реализованную на уровне операционных систем устройств, а именно асимметричные международные алгоритмы RSA или ECDSA.

В рамках оценивания по этому критерию станет ясно, какие средства ЭП могут быть использованы для работы с квалифицированной ЭП. Оценка даётся на основе сведений на сайтах вендоров.

Наличие средства электронной подписи в Едином реестре отечественного ПО

Наличие средства ЭП в Едином реестре имеет значение как для вендора, так и для заказчика. Для вендора это — освобождение от уплаты НДС, для заказчика (в первую очередь государственного, а также коммерческого, но взаимодействующего с государственным) — возможность закупать такое ПО без вопросов со стороны регулятора.

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

Соответствие требованиям приказа ФСБ России № 795

Большинство средств ЭП обладают функциональностью по формированию запросов на выпуск сертификатов. Это нужно особо аккуратным пользователям: тем, кто не доверяет сотрудникам УЦ и хочет выполнить генерацию ключевой пары / запроса на сертификат самостоятельно, опасаясь копирования ключевой информации недобросовестным сотрудником и злонамеренного её использования в будущем.

Для того чтобы средство ЭП могло формировать запросы на квалифицированные сертификаты, оно должно соответствовать требованиям приказа ФСБ России от 27 декабря 2011 г. № 795 «Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи». Такие запросы формируются по преднастроенным шаблонам, содержащим необходимый и достаточный набор полей для будущего квалифицированного сертификата.

В рамках оценивания по этому критерию определим, какие средства ЭП могут формировать запросы на сертификаты с определением полей введённых приказом ФСБ России от 29.01.2021 № 31: INNLE (ИНН юридического лица) и IdentificationKind (тип идентификации будущего владельца сертификата).

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

Работа с машиночитаемыми доверенностями

С 1 сентября 2023 года аккредитованные УЦ не должны выпускать квалифицированные сертификаты для сотрудников компаний (однако выпущенные до этой даты сертификаты сотрудников будут действовать до 31 августа 2024 года). Теперь работа с квалифицированной ЭП должна вестись на уровне квалифицированного сертификата физического лица и машиночитаемой доверенности, в которой руководитель конкретного юридического лица доверяет «физику» выполнять некий набор действий от лица компании.

Согласно нынешней схеме работы с МЧД этот процесс выглядит не столь зависимым от средства ЭП. Однако некоторые разработчики закладывают в свои продукты решение и этой задачи.

Инструменты, которые могут формировать ЭП для МЧД (доступно в двух вариантах: отсоединённая CMS-подпись для XML-документа или XMLDsig) и исходящий пакет документов (электронный документ + отсоединённая / присоединённая электронная подпись электронного документа + МЧД + отсоединённая электронная подпись МЧД), а также проверять пакет документов с МЧД, имеют обоснованное конкурентное преимущество, т. к. берут на себя сложные и не совсем ясные в реализации процессы. Одновременно с этим, имея такое средство ЭП, любое юрлицо может создать свой локальный реестр и не передавать корпоративные МЧД в единый реестр ФНС России, ведь это пока необязательно.

Но хочется подчеркнуть, что работу с МЧД можно организовать с помощью отдельного сервиса (например, портала ФНС России или средства собственной разработки, ведь тут нет криптографии, а есть только работа с XML-документом и идентификаторами полномочий), который должен уметь работать с полномочиями, а не с ЭП. А вот работа с электронной подписью для МЧД — задача средств ЭП, с которой они и раньше неплохо справлялись.

При оценивании по этому критерию посмотрим, какие средства ЭП облегчат жизнь юридического лица, взяв задачу обработки МЧД и сопутствующих пакетов документов на себя. Возможность средства ЭП работать с МЧД оценивается практическим путём.

Форматы документов, поддерживаемые средством электронной подписи

Все средства ЭП умеют работать с CMS- / CAdES-подписью, для этого они и создавались. При этом такая подпись может быть сформирована абсолютно для любого формата файлов. На сегодняшний день средства ЭП поддерживают и отсоединённую, и присоединённую CMS- / CAdES-подпись. Она может быть сформирована в том числе и для XML- либо PDF-документов.

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

Возможность средства ЭП подписывать и проверять подпись на электронных документах произвольного формата оценивается практическим путём.

Форматы электронной подписи

XML- и PDF-документы могут быть заверены не только отсоединённой или присоединённой CMS- / CAdES-подписью, но и встроенной ЭП. При этом формируется особая подписанная структура данных, XAdES и PAdES соответственно.

Для всех форматов ЭП (CAdES, XAdES и PAdES) существуют особенности формирования, связанные с обогащением ЭП определёнными атрибутами (полями, содержащими определённую информацию), рассмотренными ниже.

*AdES-BES (Basic Electronic Signature)

Основной и простейший формат ЭП. Он обеспечивает базовую проверку подлинности данных и защиту их целостности. Включённые в него атрибуты должны присутствовать и в других форматах *AdES.

*AdES-BES содержит следующие атрибуты:

подписываемые данные пользователя — документ или сообщение подписывающей стороны;
набор обязательных подписываемых атрибутов (формат подписываемых данных, хеш-сумма подписываемых данных, идентификатор подписывающей стороны, вычисляемый по сертификату ключа проверки ЭП);
значение электронной подписи, вычисленное для данных пользователя и подписываемых атрибутов.

Также *AdES-BES может содержать набор дополнительных атрибутов или набор необязательных подписываемых атрибутов.

*AdES-T (Timestamp)

Формат ЭП с доверенным временем. Доверенное время необходимо для ситуаций, когда на момент формирования ЭП сертификат подписанта и сертификаты в цепочке были действительны, а на момент проверки — уже отозваны или приостановлены. Доверенное время может быть указано с помощью неподписываемого атрибута штампа времени, включённого в ЭП, или метки времени, предоставленной поставщиком доверенных услуг (Trusted Service Provider), т. е. подписанной.

*AdES-C (Complete)

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

Отличается добавлением неподписываемых атрибутов: идентификаторов всех сертификатов, используемых при проверке подписи, а также идентификаторов из списков отзыва (Certificate Revocation Lists, CRL) и / или ответов о статусе сертификата в режиме реального времени (Online Certificate Status Protocol, OCSP).

*AdES-X Long

Формат долгосрочной расширенной ЭП. Этот формат добавляет в *AdES-C полные данные сертификатов и списки отзыва. Тем самым обеспечивается доступ ко всей информации о сертификатах и отзывах, необходимой для проверки подписи *AdES-C (даже если их исходный источник недоступен), и предотвращается утрата этой информации.

*AdES-X Type 1

Этот формат добавляет в *AdES-C атрибут, который содержит штамп времени на всей подписи CAdES-C, за счёт чего обеспечиваются целостность и наличие доверенного времени во всех элементах подписи. Таким образом защищаются сертификаты, CRL и ответ по OCSP, информация о которых записана в подписи, при компрометации ключа УЦ, ключа издателя CRL или ключа службы OCSP.

*AdES-X Type 2

Этот формат подписи отличается от Type 1 только тем, что штамп времени ставится не на всю подпись CAdES-C, а только на полные ссылки на сертификаты и CRL.

*AdES-X Long Type 1, 2

Объединение формата *AdES-X Long с *AdES-X Type 1 и Type 2.

*AdES-A

Формат ЭП, сформированный на основе *AdES-X Long Type 1 или Type 2 путём добавления одного или нескольких атрибутов, представляющих собой архивные штампы времени.

Рассмотрим, какие средства ЭП какие форматы поддерживают. Оценка даётся на основе данных в материалах по продуктам, а также практическим путём.

Соответствие Х.509 по методике NIST

Национальный институт стандартов и технологий США (NIST) — это лаборатория физических наук и нерегулируемое агентство, которое занимается исследованиями и разработками для предоставления стандартов и руководящих принципов, механизмов, инструментов, показателей и практик для защиты информации и информационных систем. Ещё одно направление его деятельности — реализация практической кибербезопасности и конфиденциальности посредством информационно-разъяснительной работы и эффективного применения стандартов и передового опыта.

Специалисты NIST давно обнаружили, что в разных решениях логика проверки статусов сертификатов и их цепочек реализовывается неодинаково. Они предложили использовать набор тестов для проверки этой логики на соответствие Х.509. Всего тестов 76; все данные, необходимые для их прогона, можно скачать со страницы института «Тестирование инфраструктуры открытых ключей». Описание тестов представлено в документе «Проверка логики обработки пути к сертификату проверяющего клиента».

Каждый тест NIST состоит из набора сертификатов X.509 (конечного объекта, промежуточных и корневого УЦ), CRL, а также закрытого ключа (ключа ЭП в российской терминологии) конечного объекта.

Тестовые данные были подготовлены NIST исходя из следующих вводных:

CRL и сертификат конечного объекта должны быть подписаны закрытым ключом (ключом ЭП) одного УЦ.
Использование IDP и дельта-CRL не рассматривается в тестах.
Логика проверки цепочки сертификатов основывается на Х.509 от 2000 года.
Сертификат корневого УЦ не включён в проверку (т. е. в него не вносится никаких изменений, способных повлиять на результат проверки цепочки).
Нет самоподписанных сертификатов.
Следующие расширения и их значения не тестируются: идентификатор издателя, идентификатор субъекта, период использования закрытого ключа, альтернативное имя издателя, альтернативное имя субъекта и ограничения имени.
В сертификатах есть поля обязательные и необязательные. В тестах предполагается, что эти поля будут обрабатываться средствами ЭП одинаково независимо от критической значимости.
Ограничения использования должны присутствовать во всех промежуточных сертификатах.
Ограничения использования могут присутствовать, а могут и не присутствовать в сертификате конечного объекта.
Тестовые данные подготовлены только для алгоритма RSA. Алгоритм DSA, кросс-алгоритмы (и тем более ГОСТ) — за рамками тестов.
Предполагается, что средства ЭП будут рассматривать CRL как действительный, если он содержит значение «nextUpdate» позже текущей даты.

Давайте вспомним, что значит действительная ЭП для российского рынка:

математическая корректность подтверждена, т. е. хеш-значение исходного документа, зашифрованное ключом ЭП отправителя, после расшифровывания на стороне получателя ключом проверки ЭП из сертификата отправителя совпадает с хеш-значением принятого документа, вычисленного на стороне получателя;
подтверждена действительность сертификата ключа проверки ЭП.

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

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

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

Результат оценивания покажет, может ли пользователь быть уверенным, что документ, который заверен электронной подписью контрагента с использованием одного средства ЭП, будет проверен корректно другим средством ЭП. Также мы увидим, какие российские средства ЭП реализовывают рекомендации NIST в подходе к порядку проверки статусов сертификатов в цепочке. Соответствие критерию устанавливается практическим путём в виртуальной среде.

Наличие криптопровайдера, реализовывающего ГОСТовую криптографию

Тут нужно дать пояснение. Для реализации механизмов ЭП и шифрования пользователю потребуются:

ключевая пара (для квалифицированной ЭП — с неизвлекаемым ключом ЭП и на сертифицированном ключевом носителе);
сертификат, выпущенный для ключевой пары и подтверждающий принадлежность владельцу;
криптопровайдер, реализовывающий математические вычисления для формирования ЭП и шифрования данных;
пользовательская надстройка — функциональная прослойка между криптопровайдером и пользователем. Задачи надстройки заключаются в том, чтобы сформировать подписанную структуру данных (*AdES) и пакет документов с МЧД, дать пользователю шаблоны для формирования запросов на сертификаты, отправить запрос на проверку ЭП в доверенную третью сторону и пр.

Вместе криптопровайдер и пользовательская надстройка образовывают средство ЭП.

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

Этот критерий имеет в большей степени финансовый оттенок: купить средство ЭП с криптопровайдером будет в ряде случаев выгоднее, чем без криптопровайдера. Да и сопровождение средства ЭП и криптопровайдера раздельно влетит в копеечку.

Оценивание выполняется теоретическим путём (по формуляру средства ЭП), т. к. в виртуальной среде установлены криптопровайдеры (ViPNet CSP и «КриптоПро CSP») и практически определить, обращается ли средство ЭП к криптопровайдеру из своего состава или внешнему, не является возможным (для практической проверки нужно устанавливать каждое средство ЭП на чистую «виртуалку»).

Поддержка криптопровайдеров, реализовывающих международные алгоритмы

Отдельные средства ЭП наряду с криптопровайдером для российской криптографии содержат и реализацию международных алгоритмов ЭП (ECDSA, RSA). Одновременно с этим, международные алгоритмы есть в составе операционных систем устройств (как минимум RSA), а средства ЭП умеют с ними работать. Но и из этих правил есть исключения: существуют российские средства ЭП, которые не поддерживают работу с иностранной криптографией. Резонный вопрос: а зачем нужна работа с иностранной криптографией, мы ведь в России? Ответ — если вы хотите работать с усиленной неквалифицированной ЭП, то ничто вам не запрещает для решения этой задачи использовать бесплатный иностранный криптопровайдер, поставляемый в составе операционной системы устройства.

Оценку по этому критерию стоит дать и с точки зрения длины ключа, который может быть поддержан средством ЭП, потому что криптостойкость определяется а) сложностью алгоритма (но алгоритмы у нас открытые, что нужно учитывать) и б) длиной ключа. Сегодня безопасным считается ключ RSA длиной 2048 бит, с 2030 года — 3072 бита, с 2046 года — 4096 бит.

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

Поддерживаемые операционные системы

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

Работа с шифрованием

Средство ЭП помимо организации юридически значимого взаимодействия может также помочь решить задачу по обеспечению конфиденциального обмена данными за счёт шифрования документов.

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

Отличительная особенность

Каждое средство ЭП — это объект интеллектуальной собственности отдельно взятой компании и детище отдельно взятой группы людей. А поскольку все мы индивидуальны и зачастую смотрим на конкретную задачу и на её решение по-своему, то и средства ЭП обладают своими яркими отличительными особенностями.

Конкурентное преимущество и дифференциатор каждого средства ЭП, участвовавшего в сравнении, определяются теоретико-практическим путём: проверяем, что отличительная функциональность, описанная в документации вендора, доступна и работает в интерфейсе.

Методика сравнения

Для проведения сравнения были выбраны средства ЭП известных на российском рынке вендоров. Все они были уведомлены о подготовке материала, а также ознакомлены с результатами исследования. Результаты публикуются при наличии согласования от всех участников. В сравнении проанализированы следующие решения:

Litoria Desktop 2, ООО «Газинформсервис»
«КриптоАРМ ГОСТ», ООО «Цифровые Технологии»
«КриптоПро CSP», ООО «КриптоПро» (приложение «Инструменты КриптоПро» из состава «КриптоПро CSP»)
ViPNet PKI Client, ООО «ИнфоТеКС»
Jinn Client, ООО «Код Безопасности»
СКЗИ «БиКрипт», ООО «ИнфоКрипт»
Sign.Me, ООО «СМ»

Развёрнута виртуальная машина с ОС Windows 10 Enterprise в среде Oracle Virtual Box.
От вендоров средств ЭП, участвующих в сравнении, получены демосборки их продуктов.
Продукты инсталлированы в виртуальной среде.
Для оценивания отдельно взятых критериев использовались открытые источники информации по продуктам, размещённые в сети «Интернет» (такие критерии помечены в таблице розовой заливкой): сайты компаний-участников, официальный сайт единого реестра российских программ для электронных вычислительных машин и баз данных.
Ряд критериев оценивался практическими действиями в виртуальной среде (такие критерии помечены в таблице зелёной заливкой).
Для выпуска квалифицированных сертификатов по шаблонам, поддержанным внутри средств ЭП, использовался тестовый удостоверяющий центр «КриптоПро».
Для формирования МЧД использовался сервис ФНС России.

Рисунок 1. Заполнение данных для выпуска МЧД на сайте ФНС России, загрузка её в формате XML-документа

Рисунок 2. Тестовая МЧД, выпущенная на сайте ФНС России

Тестовые данные для проверок корректности цепочек сертификатов взяты с сайта NIST. Для каждой проверки:

а) тестовый сертификат корневого УЦ (один на все проверки) был установлен в хранилище «Доверенные корневые центры сертификации» с помощью мастера установки;

б) тестовые сертификаты конечного объекта были установлены в хранилище сертификатов «Личное текущего пользователя» с помощью мастера установки;

в) тестовые промежуточные сертификаты и CRL выпустивших их УЦ были установлены в хранилище «Промежуточные центры сертификации» с помощью мастера установки.

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

Тест СР.04.03 (рисунок 3). Разница в наименованиях издателя конечного сертификата и субъекта промежуточного сертификата — в пробелах и регистре букв. Конечный сертификат должен быть действительным.
Тест РР.06.03 (рисунок 4). Сертификат первого промежуточного УЦ в цепочке содержит явно определённую политику (через идентификатор), а также расширение ограничения политики (requireExplicitPolicy), равное 4. Если поле «requireExplicitPolicy» присутствует, значение «requireExplicitPolicy» указывает на количество дополнительных сертификатов, которые могут появиться в пути до того, как потребуется явное указание политики. Когда требуется явная политика, необходимо, чтобы все сертификаты в пути содержали идентификатор принимаемой политики. Конечный сертификат должен содержать явное указание политики, но не содержит, поэтому должен быть проверен как недействительный.
Тест РL.01.08. Первый промежуточный сертификат в пути имеет ограничение длины пути, равное 6. Второй сертификат имеет ограничение длины пути, равное 1, и должен быть проверен с ошибкой, т. к. это ограничение не выполнено (через один промежуточный сертификат, согласно этому ограничению, должен находиться конечный сертификат). Третий сертификат имеет ограничение длины пути, равное 1. Конечный сертификат должен быть проверен как недействительный, т. к. цепочка сертификатов недействительна.

Рисунок 3. Тест СР.04.03

Рисунок 4. Тест РР.06.03

Рисунок 5. Тест РL.01.08

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

При подготовке сравнения мы анализировали результаты работы средств ЭП с точки зрения рядового пользователя, для которого важно не столько знать, что находится «под капотом» решения каждого вендора, сколько быть уверенным в том, что результат работы продукта корректен.

В результате выполненного сравнения мы не будем присваивать средствам ЭП рейтинговых баллов, оставляя читателю возможность самостоятельно определить, какой из рассматриваемых продуктов хорош именно для него.

Сравнение

Пояснения к таблице 1:

Параметры сравнения, оцениваемые по данным из интернета, помечены розовой заливкой.
Параметры сравнения, оцениваемые по результатам тестирования в виртуальной среде, помечены зелёной заливкой.
Результаты оценивания: зелёная заливка — поддержка в полном объёме; жёлтая — частичная поддержка; красная — не поддерживается.

Мы решили перечислить все тесты, предложенные NIST, но показать результаты тех, для которых были выявлены отклонения в обработке средствами ЭП от описанных эталонных значений.

Таблица 1. Сравнение средств ЭП

Критерий сравнения	Litoria Desktop 2	КриптоАРМ ГОСТ	КриптоПро CSP	ViPNet PKI Client	Jinn-Client	СКЗИ Бикрипт	Sign.Me
Вендор	Газинформсервис	Цифровые технологии	КриптоПро	ИнфоТеКС	Код Безопасности	ИнфоКрипт	СМ
Общие сведения	Основное назначение — создание, добавление, заверение и проверка ЭП, а также шифрование и извлечение файлов. Реализовано выполнение одновременных операций создания ЭП и шифрования, извлечения и проверки ЭП. В составе содержатся шаблоны запросов сертификатов, в т. ч. квалифицированных	Универсальное решение для шифрования и электронной подписи документов, организации защищённого обмена документами по электронной почте. В составе содержатся шаблоны запросов сертификатов, в т. ч. квалифицированных	Назначение: формирование и проверка ЭП, обеспечение аутентичности, конфиденциальности и контроля целостности информации (в т. ч. системного и прикладного программного обеспечения) посредством шифрования и имитозащиты данных и соединений по протоколам TLS и IPsec	Предназначен для решения основных задач пользователя при работе с сервисами, где применяются заверение документов электронной подписью, шифрование файлов, аутентификация пользователей для доступа к веб-сервисам и построение защищённых TLS-соединений	Средство создания электронной подписи и доверенной визуализации документов	Обеспечивает зашифрование / расшифрование информации, расчёт значений хеш-функции, формирование / проверку ЭП и генерацию ключевой информации	Сервис мобильной электронной подписи. Решает задачи её создания и проверки
Официальный сайт вендора	https://www.gaz-is.ru/	https://trusted.ru/	https://www.cryptopro.ru/	https://infotecs.ru/	https://www.securitycode.ru/	https://infocrypt.ru/	https://sign.me/
Сертификат ФСБ России на соответствие приказу № 796	СФ/124-4335 до 01.09.2025 (КС1, КС2)	Для версии 2.2.4: СФ/114-4067 до 01.05.2024 (КС1), СФ/124-4068 до 01.05.2024 (КС2) Актуальная версия 3.х находится в процессе сертификации	СФ/114-4304 до 01.05.2024 (КС1), СФ/124-4305 до 01.05.2024 (КС2), СФ/124-4306 до 01.05.2024 (КС3) R2: СФ/124-4066 до 01.05.2024 (КС3), СФ/124-4065 до 01.05.2024 (КС2), СФ/114-4064 до 01.05.2024 (КС1)	СФ/114-4500 до 04.05.2026 (КС1), СФ/124-4250 до 08.04.2025 (КС1, КС2, КС3), СФ/124-4137 до 23.09.2024 (КС1, КС2, КС3), СФ/114-4406 до 15.12.2025 (КС1)	СФ/111-4012 до 01.03.2024 (КС1), СФ/121-4013 до 01.03.2024 (КС2)	СФ/114-4513 до 25.03.2025 (КС1), СФ/114-4514 до 25.03.2025 (КС1)	СФ/124-4284 до 01.06.2024 (КС1), СФ/124-4285 до 01.06.2024 (КС1)
Внесён в Единый реестр отечественного ПО	Реестровая запись № 17417 от 21.04.2023	Реестровая запись № 5776 от 20.09.2019	Реестровая запись № 4332 от 29.03.2018	Реестровая запись № 3601 от 28.06.2017	Реестровая запись № 121 от 18.03.2016	Реестровая запись № 10586 от 27.05.2021	Реестровая запись № 11680 от 28.09.2021
Соответствие требованиям приказа ФСБ России № 795 (в ред. от 29.01.2021)
Создание запроса / проверка сертификата с INNLE (ИНН ЮЛ)	Да	Да	Нет возможности создавать запросы из интерфейса	Да	Да	Не предоставлена демосборка	Да
Создание запроса / проверка сертификата с IdentificationKind (тип идентификации будущего владельца сертификата)	Шаблон запроса с полем IdentificationKind отсутствует	Да	Нет возможности создавать запросы из интерфейса	Да	Шаблон запроса с полем IdentificationKind отсутствует	Не предоставлена демосборка	Да
Работа с МЧД
Проверка пакета документов с МЧД	Проверка ЭП на ЭД и проверка ЭП (CMS, XMLDSig) на МЧД	Проверка ЭП на ЭД и проверка ЭП (CMS) на МЧД	Проверка ЭП на ЭД и проверка ЭП (CMS) на МЧД	Проверка ЭП на ЭД и проверка ЭП (CMS, XMLDSig) на МЧД	Проверка ЭП на ЭД и проверка ЭП (CMS) на МЧД	Не предоставлена демосборка	Проверка ЭП (CMS) на МЧД
Формирование пакета документов с МЧД	За рамками функциональности продукта	Архив, содержащий ЭД, файл подписи, файл МЧД, ЭП МЧД	За рамками функциональности продукта	За рамками функциональности продукта	За рамками функциональности продукта	Не предоставлена демосборка	За рамками функциональности продукта
Создание МЧД	Нет	Нет	Нет	Нет	Нет	Не предоставлена демосборка	Нет
Подписание МЧД	Отделённая подпись CMS для XML; XMLDSig	Отделённая подпись CMS для XML	Отделённая подпись CMS для XML	Отделённая подпись CMS для XML; XMLDSig	Отделённая подпись CMS для XML	Не предоставлена демосборка	Отделённая подпись CMS для XML
Проверка ЭП на МЧД	Да	CMS	CMS	Да	CMS	Не предоставлена демосборка	CMS
Поддерживаемые форматы документов	Все форматы для подписи CMS; PDF — PAdES; XML — XAdES	Все форматы для подписи CMS	Все форматы для подписи CMS	Все форматы для подписи CMS; XML — XMLDsig	TXT, XML, PDF, ODT, DOC, DOCX для подписи CMS	Не предоставлена демосборка	Все форматы для подписи CMS
Форматы ЭП
CAdES	CAdES-BES, CAdES-T, CAdES-X Long Type 1, CAdES-A	CAdES-BES, CAdES-T, CAdES-X Long Type 1, CAdES-A	CAdES-BES	CAdES-BES, CAdES-T	CMS	Не предоставлена демосборка	CAdES-BES, CAdES-T, CAdES-X Long Type 1
XAdES	XAdES-BES, XAdES-T, XAdES-X Long Type 1, XAdES-A	Нет	Нет	XMLDsig	XAdES-BES, XMLDsig	Не предоставлена демосборка	Нет
PAdES	Да	Нет	Нет	Нет	Нет	Не предоставлена демосборка	Нет
Соответствие X.509 по методике NIST	На отдельном листе «Сравнение по NIST»
Криптопровайдер, реализовывающий алгоритмы ГОСТ	Нет Совместим с программными криптопровайдерами ViPNet CSP, «ВАЛИДАТА CSP», «Крипто-Ком», «КриптоПро CSP» или «ЛИССИ-CSP», аппаратными криптопровайдерами в составе изделий «eToken ГОСТ» или «РУТОКЕН ЭЦП»	Нет Совместим с программным криптопровайдером «КриптоПро CSP 5.0» и выше	Да («КриптоПро CSP»)	Да (ViPNet CSP)	Да	Не предоставлена демосборка	Да
Поддержка криптопровайдера, реализовывающего зарубежные криптографические алгоритмы	Совместим с криптопровайдерами, реализованными в соответствии с технологией Microsoft CSP; формирует ключ длиной 384–16384 бита	Совместим с криптопровайдерами, реализованными в соответствии с технологией Microsoft CSP; не формирует запросы на сертификаты на RSA, нет информации по поддерживаемой длине ключа	Нет информации по длине ключа	Нет	Нет	Не предоставлена демосборка	Нет
Поддерживаемые операционные системы	Windows Astra Linux Alt Linux Нет поддержки мобильных ОС	Windows macOS Astra Linux РЕД ОС ROSA Alt Linux AlterOS Ubuntu CentOS «Аврора» iOS Android	Windows macOS Linux FreeBSD Solaris AIX iOS Android Sailfish OS «Аврора»	Windows Android Linux iOS	Astra Linux CentOS RHEL Ubuntu Alt Linux РЕД ОС ROSA Нет поддержки мобильных ОС	Windows Linux Oracle Solaris IBM AIX 7.1 ядро 7 macOS Нет поддержки мобильных ОС	iOS Android Открытый API для работы с настольных ОС Работа через веб с любой ОС (файл передаётся на подпись в приложение на смартфоне)
Шифрование / расшифрование данных	Да	Да	Да	Да	Нет	Не предоставлена демосборка	Нет
Отличительная особенность	Поддержка функциональности клиента доверенной третьей стороны, есть ПАК ДТС	Поддержка функциональности работы с МЧД, формирования пакета документов, заверенных квалифицированной ЭП с МЧД; почтовый клиент, реализующий стандарт S/MIME	Не требует расходов на закупку средства ЭП, пользовательский интерфейс является надстройкой над криптопровайдером; необходимый и достаточный набор функций средства ЭП реализован в пользовательском интерфейсе, без излишеств	Единый клиент для работы с ключами ЭП и реализации сценариев работы с ЭП, не требующий установки дополнительных компонентов	Формирование ЭП происходит только в доверенной среде; генерация ключей электронной подписи формата PKCS#15	Не предоставлена демосборка	ЭП, которая всегда под рукой (в командировке, в отпуске, в транспорте) в мобильном телефоне

Пояснения к таблице 2:

зелёная заливка — результат тестирования средства ЭП соответствует эталонному;
жёлтая — результат соответствует эталонному частично;
красная — результат тестирования не соответствует эталонному.

Таблица 2. Оценивание корректности проверки цепочки сертификатов согласно методике NIST

	Средство ЭП 1	Средство ЭП 2	Средство ЭП 3	Средство ЭП 4	Средство ЭП 5	Средство ЭП 6	Средство ЭП 7
Тесты обработки сертификатов
СР01	Приложение должно проверять ЭП на каждом сертификате в цепочке сертификатов
СР02	Приложение должно гарантировать, что время «notBefore» («Действителен с») каждого сертификата в цепочке сертификатов раньше текущего времени
СР03	Приложение должно гарантировать, что время «notAfter» («Действителен до») каждого сертификата в цепочке сертификатов позже текущего времени
СР04	Приложение должно правильно проверить цепочку сертификатов. Правильная цепочка — это когда издатель каждого сертификата в цепочке равен субъекту вышестоящего сертификата
CP.04.03	Цепочка сертификатов должна быть проверена успешно, т. к. имена различаются только пробелами и заглавными буквами
	Успех	Ошибка	Ошибка	Не участвовал в тестировании, т. к. не поддерживает RSA	Не участвовал в тестировании, т. к. не поддерживает RSA	Не предоставлена демосборка	Не участвовал в тестировании, т. к. не поддерживает RSA
CP.04.04	Цепочка сертификатов должна быть проверена успешно, т. к. имена различаются только пробелами
	Успех	Ошибка	Ошибка	Не участвовал в тестировании, т. к. не поддерживает RSA	Не участвовал в тестировании, т. к. не поддерживает RSA	Не предоставлена демосборка	Не участвовал в тестировании, т. к. не поддерживает RSA
CP.04.05	Цепочка сертификатов должна быть проверена успешно, т. к. имена различаются только начальными / конечными пробелами
	Успех	Ошибка	Ошибка	Не участвовал в тестировании, т. к. не поддерживает RSA	Не участвовал в тестировании, т. к. не поддерживает RSA	Не предоставлена демосборка	Не участвовал в тестировании, т. к. не поддерживает RSA
CP.04.06	Цепочка сертификатов должна быть проверена успешно, т. к. имена различаются только регистром
	Успех	Ошибка	Ошибка	Не участвовал в тестировании, т. к. не поддерживает RSA	Не участвовал в тестировании, т. к. не поддерживает RSA	Не предоставлена демосборка	Не участвовал в тестировании, т. к. не поддерживает RSA
СР05	Приложение должно уметь извлекать действительные CRL для каждого сертификата в цепочке; если приложение не может получить действительные данные CRL, оно должно отклонить цепочку сертификатов
СР06	Приложение должно отклонить цепочку сертификатов, если какой-либо сертификат был отозван
Тесты обработки промежуточных сертификатов
IC01	Приложение должно гарантировать, что расширение «basicConstraints» («Основные ограничения») присутствует в каждом промежуточном сертификате в цепочке
IC02	Приложение должно гарантировать, что каждый промежуточный сертификат в цепочке сертификатов имеет расширение «basicConstraints», а для поля cA (выпуск сертификатов) установлено значение «true»
IC03	Приложение должно признать недействительной цепочку сертификатов, если какой-либо промежуточный сертификат нарушает ограничения длины пути, представленные в поле «pathLenConstraint» расширения «basicConstraints» в сертификате высшего уровня Проверяется в разделе «Тесты длины цепочки сертификатов»
IC04	Если приложение обнаруживает промежуточный сертификат, в котором присутствует расширение использования ключа с битом «keyCertSign», установленным в значение «true», и присутствует расширение «basicConstraints», приложение должно убедиться, что в сертификате для компонента cA расширениe базовых ограничений установлено как «true»
IC05	Приложение должно гарантировать, что для каждого промежуточного сертификата, в котором присутствует расширение использования ключа, бит «keyCertSign» установлен в значение «true». Если приложение не может распознать расширение использования ключа, все тесты, которые содержат расширение использования критического ключа, должны завершиться неудачей, а все тесты, которые содержат расширение использования некритического ключа, должны завершиться успехом
IC06	Приложение должно гарантировать, что для каждого промежуточного сертификата, содержащего подписанный CRL, присутствует расширение использования ключа, бит «cRLSign» установлен в значение «true». Если приложение не может распознать расширение использования ключа, все тесты, которые содержат расширение использования критического ключа, должны завершиться неудачей, а все тесты, которые содержат расширение использования некритического ключа, должны завершиться успехом
Тесты обработки политик
PP.01	Программное обеспечение должно быть способно правильно вычислять политику с ограничением полномочий
PP.02 (1 тест)	Программное обеспечение должно связывать квалификаторы политик с соответствующими политиками За рамками текущей работы, поскольку квалификаторы политики не разрешены в сертификатах Министерства обороны класса 3
PP.03 (4 теста)	Программное обеспечение должно корректно выполнять сопоставление политик, если сопоставление политик не заблокировано За рамками текущей работы, поскольку расширение сопоставления политик не разрешено в сертификатах Министерства обороны класса 3
PP.04 (9 тестов)	Программное обеспечение не должно выполнять сопоставление политик, если сопоставление политик заблокировано За рамками текущей работы, поскольку расширение сопоставления политик не разрешено в сертификатах Министерства обороны класса 3
PP.05	Программное обеспечение должно соответствующим образом поддерживать переменную состояния отображения политики запрета За рамками текущей работы, поскольку расширение сопоставления политик не разрешено в сертификатах Министерства обороны класса 3
PP.06	Программное обеспечение должно соответствующим образом обрабатывать явную переменную состояния индикатора политики
PP.06.03	Первый промежуточный сертификат в пути сертификации (длина 5) содержит расширение ограничений политики, при этом параметр «requireExplicitPolicy» присутствует и имеет значение «4»
	Успех (конечный сертификат проверен с ошибкой, не содержит явного указания политики)	Ошибка (конечный сертификат проверен успешно)	Ошибка (конечный сертификат проверен успешно)	Не участвовал в тестировании, т. к. не поддерживает RSA	Не участвовал в тестировании, т. к. не поддерживает RSA	Не предоставлена демосборка	Не участвовал в тестировании, т. к. не поддерживает RSA
PP.07	Программное обеспечение должно возвращать соответствующие значения набора политик с ограничением полномочий Проверяется путём тестирования РР.01–РР.05
PP.08	Программное обеспечение должно возвращать соответствующие значения из набора политик, ограниченных пользователем
PP.09	Программное обеспечение должно возвращать соответствующее значение индикатора явной политики Проверяется с помощью тестирования AS:PP.06
PP.10	После проверки пути программное обеспечение должно соответствующим образом возвращать данные об успехе или неудаче Проверяется в рамках других тестов политик
Тесты длины цепочки сертификатов
PL.01	Программное обеспечение должно правильно рассчитать допустимую длину пути
PL.01.02	Следующий путь должен быть отклонён. Первый сертификат в пути имеет ограничение длины пути, равное 0 (допускается 0 дополнительных промежуточных сертификатов в пути). Имеется один дополнительный промежуточный сертификат. Конечный сертификат является сертификатом УЦ
	Успех	Ошибка	Успех	Не участвовал в тестировании, т. к. не поддерживает RSA	Не участвовал в тестировании, т. к. не поддерживает RSA	Не предоставлена демосборка	Не участвовал в тестировании, т. к. не поддерживает RSA
PL.01.06	Следующий путь должен быть отклонён. Длина пути равна 4. Первый сертификат в пути имеет ограничение длины пути, равное 6 (допускается 6 дополнительных промежуточных сертификатов в пути). Второй сертификат имеет ограничение длины пути, равное 0. Третий сертификат имеет ограничение длины пути, равное 0. Конечный сертификат является сертификатом УЦ
	Успех	Ошибка	Успех	Не участвовал в тестировании, т. к. не поддерживает RSA	Не участвовал в тестировании, т. к. не поддерживает RSA	Не предоставлена демосборка	Не участвовал в тестировании, т. к. не поддерживает RSA
PL.01.08	Следующий путь должен быть отклонён. Длина пути равна 5. Первый сертификат в пути имеет ограничение длины пути, равное 6 (допускается 6 дополнительных промежуточных сертификатов в пути). Второй сертификат имеет ограничение длины пути, равное 1. Третий сертификат имеет ограничение длины пути, равное 1. Конечный сертификат является сертификатом УЦ
	Успех	Ошибка	Успех	Не участвовал в тестировании, т. к. не поддерживает RSA	Не участвовал в тестировании, т. к. не поддерживает RSA	Не предоставлена демосборка	Не участвовал в тестировании, т. к. не поддерживает RSA
Тесты для CRL
RL.01	CRL могут использоваться в качестве механизма определения статуса отзыва
RL.01.01	Тестов нет. Если приложение использует CRL, то утверждение выполняется
RL.02	Приложение должно проверить подпись в каждом CRL в цепочке сертификатов, используя тот же открытый ключ, который использовался для подписи сертификатов
RL.03	При проверке наличия сертификата в CRL приложение должно убедиться, что имя издателя в сертификате совпадает с именем издателя в CRL сертификатов
RL.04	Приложение должно проверить цепочку сертификатов с ошибкой, если какой-либо сертификат был отозван. Сертификат аннулируется, если его серийный номер отображается в компоненте «revokedCertificates» CRL, связанного с лицом подписавшим сертификат
RL.04.01	Проверяется тестами TE:CP.06.01 и TE:CP.06.02
RL.05	Приложение должно проверить цепочку сертификатов с ошибкой, если какой-либо сертификат в цепочке был отозван, независимо от того, присутствуют ли в CRL непризнанные критические расширения «crlEntryExtension»
RL.06	Приложение должно проверить цепочку сертификатов с ошибкой, если какой-либо сертификат в ней был отозван, независимо от того, присутствуют ли в CRL непризнанные критические расширения «crlExtension».
RL.07	Приложение должно считать CRL недействительным, если время следующего обновления в сертификате раньше текущего
RL.08	Приложение должно убедиться, что список отзывов сертификатов не содержит расширения «deltaCRLIndicator»
RL.09	Приложение должно убедиться, что список отзыва сертификата не содержит расширения «issuingDistributionPoint»

Выводы

Криптографическая защита информации, одним из механизмов которой является ЭП, — это лицензируемый вид деятельности, а работа с квалифицированной ЭП требует обязательного использования программных средств, соответствие которых требованиям российского законодательства подтверждено.

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

Особо стоит выделить тех вендоров, чьи решения умеют работать с ЭП в формате XAdES: «Газинформсервис» (продукт Litoria Desktop 2), «ИнфоТеКС» (ViPNet Client), «Код Безопасности» (Jinn Client). Такой формат ЭП позволяет работать с «живым» XML-документом, решая сложную задачу по обеспечению каноничности и приданию юридической значимости.

В статье мы наглядно показали проблему, с которой может столкнуться пользователь при работе со средствами ЭП разных вендоров: расхождение в результатах при проверке одного и того же документа с ЭП. На текущий момент времени порядок проверки действительности сертификата и цепочки сертификатов не регламентирован; в связи с этим при прогоне тестов NIST мы увидели расхождения результатов с эталонными показателями. Одно из средств ЭП завершило 8 тестов из 76 (10,5 %) с результатом отличным от эталонного, другое имело отклонение в 5 тестах (6,5 %). Таким образом, те сертификаты, которые являются действительными (а следовательно, электронная подпись валидна) по результатам работы одного средства ЭП, окажутся недействительными по результатам работы другого. Примерно такая же ситуация может возникнуть и в отношении сложного, слабо регламентированного процесса работы с МЧД, да и проверки действительности ЭП на МЧД, а следовательно — и сертификата ключа проверки электронной подписи, и цепочки сертификатов (ведь проблему результатов проверки разными средствами ЭП мы показали).

В сравнении мы рассмотрели только средства ЭП, но некоторое прикладное программное обеспечение, в т. ч. почтовые клиенты, реализовывающие S/MIME, и платформы операторов ЭДО как-то формируют и проверяют действительность сертификатов ключей проверки ЭП. А корректна ли реализация этих проверок? Какое количество расхождений в логике можно обнаружить при их тестировании? А возможно ли подготовить наборы тестовых данных для российского рынка на основе ГОСТовых криптоалгоритмов?

Нам нужны рекомендации с ориентацией на отечественные криптографические алгоритмы и российское законодательство: как средства ЭП должны проверять цепочку сертификатов и как работать с МЧД.