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

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

 

 

 

 

 

1. Введение
2. Критерии оценивания средств электронной подписи
   
   1. 2.1. Сертификат соответствия на средство электронной подписи
   2. 2.2. Наличие средства электронной подписи в Едином реестре отечественного ПО
   3. 2.3. Соответствие требованиям приказа ФСБ России № 795
   4. 2.4. Работа с машиночитаемыми доверенностями
   5. 2.5. Форматы документов, поддерживаемые средством электронной подписи
   6. 2.6. Форматы электронной подписи
   7. 2.7. Соответствие Х.509 по методике NIST
   8. 2.8. Наличие криптопровайдера, реализовывающего ГОСТовую криптографию
   9. 2.9. Поддержка криптопровайдеров, реализовывающих международные алгоритмы
   10. 2.10. Поддерживаемые операционные системы
   11. 2.11. Работа с шифрованием
   12. 2.12. Отличительная особенность
3. Методика сравнения
4. Сравнение
5. Выводы

Введение

Крупными мазками очертим изменения в 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 исходя из следующих вводных:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Для проведения сравнения были выбраны средства ЭП известных на российском рынке вендоров. Все они были уведомлены о подготовке материала, а также ознакомлены с результатами исследования. Результаты публикуются при наличии согласования от всех участников. В сравнении проанализированы следующие решения:
1. Litoria Desktop 2, ООО «Газинформсервис»
2. «КриптоАРМ ГОСТ», ООО «Цифровые Технологии»
3. «КриптоПро CSP», ООО «КриптоПро» (приложение «Инструменты КриптоПро» из состава «КриптоПро CSP»)
4. ViPNet PKI Client, ООО «ИнфоТеКС»
5. Jinn Client, ООО «Код Безопасности»
6. СКЗИ «БиКрипт», ООО «ИнфоКрипт»
7. Sign.Me, ООО «СМ»
2. Развёрнута виртуальная машина с ОС Windows 10 Enterprise в среде Oracle Virtual Box.
3. От вендоров средств ЭП, участвующих в сравнении, получены демосборки их продуктов.
4. Продукты инсталлированы в виртуальной среде.
5. Для оценивания отдельно взятых критериев использовались открытые источники информации по продуктам, размещённые в сети «Интернет» (такие критерии помечены в таблице розовой заливкой): сайты компаний-участников, официальный сайт единого реестра российских программ для электронных вычислительных машин и баз данных.
6. Ряд критериев оценивался практическими действиями в виртуальной среде (такие критерии помечены в таблице зелёной заливкой).
7. Для выпуска квалифицированных сертификатов по шаблонам, поддержанным внутри средств ЭП, использовался тестовый удостоверяющий центр «КриптоПро».
8. Для формирования МЧД использовался сервис ФНС России.

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

 

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

 

8. Тестовые данные для проверок корректности цепочек сертификатов взяты с сайта 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:

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

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

 

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

 

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

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

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

 

Выводы

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

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

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

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

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

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