Обзор Litoria DVCS 5.2.2, программного комплекса Службы доверенной третьей стороны

1. Введение
2. Архитектура Litoria DVCS 5.2.2
3. Функциональные возможности Litoria DVCS 5.2.2
4. Системные требования для развертывания Litoria DVCS 5.2.2
5. Установка и настройка Litoria DVCS 5.2.2
6. Работа с Litoria DVCS 5.2.2
7. Выводы

Введение

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

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

Каждый из обозначенных вопросов имеет несколько вариантов ответов. Так, например, обеспечить юридически значимый электронный документооборот с иностранными коллегами можно:

1. приняв единый криптографический стандарт для такого взаимодействия. Однако подобный подход нарушает цифровой суверенитет отдельных государств;
2. импортом/экспортом средств криптографической защиты информации между взаимодействующими государствами. Такой способ является нерациональным, поскольку каждый случай ввоза/вывоза шифровальных средств требует сложных и дорогостоящих процедур оформления, сама система трудномасштабируема, а обслуживание иностранных криптографических средств не в стране присутствия разработчика затруднено;
3. организацией инфраструктуры операторов сервисов доверенной третьей стороны. Этот подход наиболее практичен, но требует обеспечения трех составляющих для легитимного функционирования такой инфраструктуры:
1. технической: разработать программный или программно-аппаратный комплекс, соответствующий требованиям к таким решениям;
2. нормативно-правовой: подготовить законодательную базу для регулирования такой инфраструктуры как государственного, так и международного уровней (пожалуй, самая емкая составляющая в плане интеллектуальных и временных инвестиций);
3. организационной: проработать и зафиксировать порядок и принципы функционирования международной инфраструктуры доверия.

Второй вопрос, связанный с длительным архивным хранением, также может быть разрешен несколькими способами:

1. Посредством изначального формирования усовершенствованной электронной подписи (УЭП), формат которой предусматривает обязательное включение в реквизиты подписанного электронного документа доказательства момента создания ЭП (подписанный штамп времени) и действительности сертификата ключа проверки ЭП в момент ее создания. Более подробно о типах УЭП для различных форматов электронных документов можно почитать здесь.
2. Посредством формирования юридически значимых квитанций, содержащих подробности и результаты проверок ЭП электронного документа, и последующей пролонгацией их действительности.
3. Посредством хранения сертификатов ключей проверки ЭП вместе с самим электронным документом. Такая рекомендация дается для хранения счетов-фактур в Приказе Минфина России от 10.11.2015 №174н: «1.13. Участники электронного документооборота обеспечивают хранение документов, подписанных усиленной квалифицированной электронной подписью, составление и выставление которых предусмотрено настоящим Порядком, совместно с применявшимся для формирования электронной подписи указанных документов квалифицированным сертификатом ключа проверки электронной подписи в течение срока, установленного для хранения счетов-фактур».

Поскольку регулирование электронного юридически значимого документооборота в Российской Федерации на сегодняшний день исчерпывает себя Федеральным законом 63-ФЗ и Приказами ФСБ России №795 и №796, которые в свою очередь не дают ответов на два основополагающих вопроса, крупный и средний бизнес отвечают на них на уровне субъективного видения группы лиц, принимающих решения, а также финансовых возможностей отдельно взятой компании.

Функциональность, позволяющую решить задачи обеспечения проверки российской ЭП в облаке, автоматизировать эту самую проверку, организовать длительное архивное хранение электронных документов и проверку иностранной ЭП, сегодня предоставляют ряд вендоров. Каждое решение имеет свои сильные и слабые стороны. В этом обзоре мы расскажем о программном решении разработки компании «Газинформсервис» — Litoria DVCS 5.2.2.

Архитектура Litoria DVCS 5.2.2

Litoria DVCS 5.2.2 — это программный комплекс, разработчик которого видит следующие наиболее интересные и востребованные сценарии его применения:

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

Работа Litoria DVCS 5.2.2 строится в соответствии с международными рекомендациями и стандартами: RFC 3029, RFC3161, RFC5126, RFC6960, ETSI TS 101 903 V1.4.1, ETSI TS 102 778-1 V1.1.1 (2009-07).

Litoria DVCS 5.2.2 позволяет обработать 4 типа запросов (DVCS-запросы):

• VSD (Validation of Digitally Signed Documents) — проверка ЭП;
• VPKC (Validation of Public Key Certificates) — проверка актуального статуса сертификатов ключей проверки ЭП;
• CPD (Certification of Possession of Data) — удостоверение обладания данными пользователем;
• CCPD (Certification of claim of Possession of Data) — удостоверение обладания данными пользователем по их хеш-значению.

В состав Litoria DVCS 5.2.2 входят компоненты:

• служба проверки подлинности (DVCS) предоставляет услуги проверки данных в запросе, полученном службой от пользователя; состоит из web-службы, web-портала и базы данных службы;
• служба штампов времени (TSP) удостоверяет факт существования электронного документа на определенный момент времени;
• SDK-клиент для службы DVCS предоставляет набор инструментария для создания клиентских приложений, взаимодействующих со службой DVCS;
• SDK-клиент для службы TSP предоставляет набор инструментария для создания клиентских приложений, использующих штампы времени;
• автоматизированное рабочее место администратора для конфигурирования Litoria DVCS 5.2.2, управления профилями пользователей, их правами, анализа журнала аудита и просмотра выданных квитанций.

Хочется также отметить, что для настройки различных групп параметров и функций Litoria DVCS 5.2.2 разработчик вводит ролевое разграничение для пользователей группы администраторов:

• системный администратор, в обязанности которого входят:
  • инсталляция, настройка и поддержка функционирования Litoria DVCS 5.2.2;
  • создание и поддержка профилей членов группы администраторов;
  • настройка профиля и параметров журнала аудита;
  • осуществление резервного копирования настроек Litoria DVCS 5.2.2, файлов журнала событий, выданных DVC-квитанций и их серийных номеров, а также пользовательской информации.
• администратор сертификатов, в обязанности которого входит установка сертификатов ключей проверки ЭП, а также списков отозванных сертификатов на сервер(ы) служб DVCS и TSP;
• администратор безопасности, в обязанности которого входит установка и настройка сертифицированных средств защиты, рекомендованных для обеспечения безопасного функционирования Litoria DVCS 5.2.2;
• администратор пользователей, в обязанности которого входят:
  • создание и удаление пользователей Litoria DVCS 5.2.2;
  • управление правами пользователей;
  • просмотр статистики используемых услуг.

Взаимодействие пользователя с Litoria DVCS 5.2.2 может быть организовано несколькими способами (рисунок 2):

1. Программный комплекс Litoria Desktop позволяет сформировать два типа запросов на проверку (VSD и VPKC). Проверки осуществляются в прозрачном режиме, т.е. при выполненных настройках взаимодействия Litoria Desktop с Litoria DVCS 5.2.2 (рисунок 2) пользователю достаточно перетащить документ с ЭП (российской или иностранной) в интерфейс «Проверка и извлечение». Далее все требуемые операции будут выполнены в автоматизированном режиме.
2. Программное обеспечение Litoria DVC Applet позволяет формировать все типы запросов (VSD, VPKC, CPD, CCPD), дистрибутив доступен для скачивания из web-интерфейса по адресу, где развернута web-служба, а также инсталляция может быть выполнена с диска для установки Litoria DVCS 5.2.2.
3. Личный кабинет пользователя в web-интерфейсе позволяет формировать все типы запросов (VSD, VPKC, CPD, CCPD) посредством любого web-браузера. Для каждого пользователя на сервере Litoria DVCS 5.2.2 создается учетная запись, к которой может быть привязан его сертификат ключа проверки ЭП. Аутентификация в личном кабинете может быть выполнена как по связке логин — пароль, так и по сертификату ключа проверки ЭП.
4. Из любого программного решения, информационной системы посредством интеграции SDK-клиента службы DVCS. Этот способ также позволяет формировать все типы DVCS-запросов.

Рисунок 1. Схема взаимодействия пользователей с Litoria DVCS 5.2.2

Рисунок 2. Настройки взаимодействия Litoria Desktop с Litoria DVCS 5.2.2

Функциональные возможности Litoria DVCS 5.2.2

Litoria DVCS 5.2.2 реализует следующие функциональные возможности:

1. Создание всех типов DVCS-запросов.
2. Проверка данных, содержащихся в DVCS-запросе.
3. Формирование штампа времени.
4. Формирование квитанций в форматах:
• CAdES (формат описан в RFC5126 CMS Advanced Electronic Signatures (CAdES));
• XAdES (формат описан в ETSI TS 101 903 V1.4.1 XML Advanced Electronic Signatures (XAdES)).
5. Анализ ранее сформированных квитанций.
6. Архивирование и хранение пользовательской информации в собственной базе данных.
7. Архивирование и хранение выданных квитанций и их серийных номеров в собственной базе данных.
8. Архивирование и хранение файлов журнала событий.
9. Предоставление инструментов разработчикам для создания клиентских приложений (SDK-клиенты служб DVCS и TSP).

А теперь давайте рассмотрим входные и выходные данные для служб DVCS и TSP (таблица 1).

Таблица 1. Входные и выходные данные для служб DVCS и TSP

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

Таблица 2. Входные данные для работы LitoriaDVCS 5.2.2

Ответом службы DVCS является квитанция — DVCS-ответ, подписанный сертификатом ключа проверки ЭП службы DVCS, который содержит либо информацию об успешной обработке запроса, либо уведомление об ошибке.

В случае успешной обработки запроса квитанция (в зависимости от запрошенного типа проверки) содержит сведения, представленные в таблице 3.

Таблица 3. Выходные данные, формируемые LitoriaDVCS 5.2.2

В случае уведомления об ошибке квитанция содержит следующие разделы:

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

Содержание запроса, формируемого к службе TSP, включает данные:

• хэш-значение документа, на который запрашивается штамп времени;
• OID — объектный идентификатор алгоритма хеширования;
• Nonce — случайное число, идентифицирующее данную транзакцию протокола TSP.

При этом ответ службы TSP может содержать либо штамп времени (при успешном статусе проверки), либо сообщение об ошибочном статусе операции и информацию об ошибке.

Штамп времени содержит следующие данные:

• значение хэш-функции документа, на который выдан штамп;
• OID — идентификатор политики штампа;
• точное время выдачи штампа;
• точность времени (погрешность);
• признак строгой упорядоченности штампов;
• Nonce — случайное число, идентифицирующее данную транзакцию протокола TSP, которое совпадает с соответствующим полем запроса.

Системные требования для развертывания Litoria DVCS 5.2.2

Службы Litoria DVCS 5.2.2 функционируют под управлением операционной системы Microsoft Windows Server 2008R2/2012R2.

Дополнительно на сервере (серверах) должны быть установлены:

• система управления базами данных Microsoft SQL Server 2008 R2/2012 или Microsoft SQL Server Express 2008R2/2012;
• .Net Framework 4.0 и выше;
• Internet Information Services (IIS) 7.5/8.5;
• средство криптографической защиты информации, реализованное в соответствии с технологией Microsoft CSP и поддерживающее криптографические стандарты государства, использующего Litoria DVCS 5.2.2;
• установленные и действующие сертификаты и списки отозванных сертификатов пользователей и удостоверяющих центров, сертификаты которых используются пользователями комплекса.

Требования к аппаратному обеспечению для развертывания Litoria DVCS 5.2.2 обусловлены требованиями используемых операционных систем. Минимальные требования к серверу (серверам) для установки компонентов Litoria DVCS 5.2.2 приведены в таблице 4.

Таблица 4. Требования к серверу для установки служб Litoria DVCS 5.2.2

Минимальные требования для сервера (серверов) баз данных служб Litoria DVCS 5.2.2 приведены в таблице 5.

Таблица 5. Требования к серверу баз данных служб Litoria DVCS 5.2.2

Для корректного функционирования Litoria DVCS 5.2.2 необходимо наличие установленных и действующих сертификатов и списков отозванных сертификатов.

Установка всех сертификатов и списков отозванных сертификатов из таблицы 6 (кроме SSL-сертификата) осуществляется под учетной записью, из-под которой настроена работа пула приложений служб Litoria DVCS 5.2.2.

Таблица 6. Сертификаты и списки отозванных сертификатов ключей проверки ЭП, необходимых для функционирования Litoria DVCS 5.2.2

Защита каналов взаимодействия пользователей с сервером службы DVCS осуществляется с использованием протокола HTTPS на основе SSL-сертификата, который устанавливается на web-сервер (IIS) сервера службы DVCS (таблица 7).

Таблица 7. Сертификаты и списки отозванных сертификатов ключей проверки ЭП, необходимых для функционирования Litoria DVCS 5.2.2 по протоколу HTTPS

Установка и настройка Litoria DVCS 5.2.2

Установка и настройка Litoria DVCS 5.2.2 включает последовательную установку и настройку всех компонентов, входящих в состав.

Служба DVCS состоит из трех компонентов (web-служба, web-портал и база данных) и может быть условно разделена на 3 части и установлена на 3 сервера.

Для работы службы DVCS на серверах, где будут установлены web-служба и web-портал, необходимо добавить роль «Веб-сервер (IIS)».

Для установки web-портала, web-службы и базы данных службы DVCS, а также web-службы и базы данных службы TSP, нужно запустить файл-инсталлятор. Процесс установки выполняется привычным нам порядком (ввод сведений о пользователе, серийного номера продукта, выбор компонентов, установка которых будет выполнена на данном сервере (рабочей станции), рисунок 3).

Рисунок 3. Предварительные условия установки служб Litoria DVCS 5.2.2

В окне «Конфигурация Службы DVCS» (рисунок 4) вводится IP-адрес для web-портала и web-службы. Выбирается тип системы управления базами данных, который будет использоваться.

Рисунок 4. Конфигурация службы DVCS Litoria DVCS 5.2.2 при установке всех компонентов на одну рабочую станцию

По умолчанию предполагается, что база данных службы DVCS устанавливается на локальный сервер. Для изменения данного параметра нужно снять флаг в соответствующем поле и указать номер порта, по которому будет работать соединение с сервером, куда необходимо выполнить ее установку (по умолчанию — 1433).

После успешного завершения установки в консоли IIS Manager в разделе «Сайты» отобразится:

• DTS — web-портал службы DVCS (работает через порт 80);
• GIS_DTS_SERVICE — web-служба DVCS (работает через порт 59501).

При выполнении настройки работы компонентов службы DVCS через http и https можно также изменить и порты для работы web-службы и web-портала.

На рисунке 5 представлена главная страница web-интерфейса Litoria DVCS 5.2.2.

Рисунок 5. Главная страница web-портала Litoria DVCS 5.2.2

При предполагаемых больших нагрузках на сервер службы DVCS разработчик рекомендует установить дополнительные параметры настройки пула службы DVCS, отвечающие за пропорции «Нагрузка — Производительность». Примерные значения дополнительных параметров:

1. Тайм-аут простоя/Idle Time-out — 5 минут.
2. Максимальное число рабочих процессов/Maximum Worker Processes — 2 (задается по количеству ядер).
3. Лимит запросов/Request Limit — 100.

На сервер (серверы), где были установлены web-служба и web-портал, необходимо установить действующие сертификаты пользователей LitoriaDVCS 5.2.2 и списки отозванных сертификатов тех Удостоверяющих центров, с которыми комплекс должен взаимодействовать. Установка всех сертификатов (кроме SSL-сертификата) осуществляется администратором сертификатов под учетной записью, из-под которой настроена работа пула приложений служб Litoria DVCS 5.2.2, установка SSL-сертификата осуществляется из консоли IIS.

Работа с Litoria DVCS 5.2.2

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

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

1. При получении запроса типа VSD сначала определяется алгоритм ЭП, содержащейся в запросе, и выполняется проверка его поддержку службой DVCS.

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

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

2. При получении DVCS-запроса типа VPKC сначала определяется алгоритм ЭП сертификата, содержащегося в запросе, и выполняется проверка алгоритма создания данного сертификата на предмет поддержки его службой DVCS.

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

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

3. При получении запроса типа CPD или CCPD создается квитанция, которая является удостоверением, что данные в запросе принадлежат пользователю, который отправил DVCS-запрос.

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

В данном обзоре рассмотрим работу с Litoria DVCS 5.2.2 через программное обеспечение Litoria DVC Applet. Установку его можно выполнить как из дистрибутива Litoria DVCS 5.2.2, так и из интерфейса в web-браузере при обращении к адресу, на котором функционирует web-служба. Рассмотрим установку из дистрибутива.

Из списка компонентов, доступных к установке, оставляем только «Апплет DVC» (рисунок 6).

Рисунок 6. Выбор компонентов установки Litoria DVCS 5.2.2

Далее указываем параметры установки для Litoria DVC Applet (рисунок 7):

• протокол — HTTP/HTTPS;
• адрес службы DVCS для Litoria DVC Applet (например, 10.83.1.43).

Рисунок 7. Параметры установки Litoria DVC Applet для взаимодействия Litoria DVCS 5.2.2

Вид главного окна интерфейса Litoria DVC Applet представлен на рисунке 8.

Рисунок 8. Главное окно интерфейса Litoria DVC Applet для взаимодействия с Litoria DVCS 5.2.2

Описание компонентов интерфейса, отмеченных на рисунке 9:

1. Список сертификатов, установленных на пользовательском рабочем месте в хранилище «Личные».
2. Параметры запроса: тип запроса (VSD, VPKC, CPD, CCPD) и использование хеширования.
3. Дополнительные параметры.
4. Адрес сервиса, указанный при установке Litoria DVC Applet.
5. Кнопка «Перетащите файл или нажмите» предназначена для выбора файла, который необходимо проверить.
6. Кнопка «Данные отделенной подписи» предназначена для выбора исходных данных отделенной ЭП.
7. Кнопка «Создать запрос» — позволяет создать DVCS-запрос, подписанный сертификатом из списка сертификатов (1), и отправляет на сервер службы DVCS (указанный в поле 4) для проверки.

На рисунке 9 представлен список дополнительных параметров, которые появляются при нажатии на кнопку, указанную в п. 3.

Рисунок 9. Дополнительные параметры Litoria DVC Applet при взаимодействии с Litoria DVCS 5.2.2

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

Операция «Отправить запрос из файла» позволяет загрузить файл ранее созданного DVCS-запроса и получить на него квитанцию Примеры квитанций, формируемых Litoria DVCS 5.2.2, представлены на рисунках 10 и 11 (результаты проверки ЭП электронного документа (vsd) и актуального статуса сертификата ключа проверки ЭП (vpkc) соответственно).

Рисунок 10. Результат проверки ЭП электронного документа Litoria DVCS 5.2.2

Рисунок 11. Результат проверки сертификата ключа проверки ЭП Litoria DVCS 5.2.2

Операция «Разобрать готовую квитанцию» позволяет загрузить ранее созданную квитанцию из файла для просмотра результатов проверки.

Операция «Проверить соответствие» необходима для сравнения ЭП и файла квитанции. При выборе данной операции откроется окно, представленное на рисунке 12. Необходимо выбрать файл ЭП и файл квитанции, для которых будет проверяться соответствие. Если необходимо сравнить файл отделенной ЭП, необходимо выбрать подписанный файл, файл с данными отделенной ЭП и файл квитанции.

Рисунок 12. Проверка соответствия исходных данных и квитанции, сформированной Litoria DVCS 5.2.2

Выводы

В настоящее время идет согласование изменений в Федеральный закон «Об электронной подписи» от 06.04.2011 N 63-ФЗ — они придадут правовой статус такой сущности как «Доверенная третья сторона», для легитимного функционирования которой потребуется реализация технической, нормативно-правовой и организационной составляющих этой сущности. Сервисы доверенной третьей стороны на рынок сможет предоставлять любое юридическое лицо, прошедшее соответствующие процедуры аккредитации.

Однако сроки, в которые изменения в 63-ФЗ будут согласованы и утверждены, а также когда будут подготовлены сопутствующие подзаконные акты, остаются под вопросом…

Но уже сегодня есть продукт, который может взять на себя задачи, возлагаемые на техническую составляющую доверенной третьей стороны, — это Litoria DVCS 5.2.2.

Что касается «дорожной карты» продукта, основным направлением развития Litoria DVCS 5.2.2, ввиду курса на импортозамещение в области информационной безопасности и информационных технологий, разработчик определяет поддержку работы на операционных системах семейства Unix и macOS. Также хочется отметить, что сейчас идет процесс сертификации Litoria DVCS 5.2.2 по линии ФСБ России, а положительный результат этого процесса создаст благоприятные условия для аккредитации в качестве операторов сервисов доверенной третьей стороны всех, кто решит предоставлять подобные услуги на базе этого решения.

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

Достоинства

• Продукт включен в реестр отечественного программного обеспечения.
• Технологии и сервисы инфраструктуры открытых ключей реализованы в соответствии с лучшими международными практиками (с успехом проходят все криптографические тесты NIST), а также международными рекомендациями и стандартами RFC 3029, RFC3161, RFC5126, RFC6960, ETSI TS 101 903 V1.4.1, ETSI TS 102 778-1 V1.1.1 (2009-07).
• Продукт поддерживает работу как с российскими, так и с иностранными криптографическими алгоритмами.
• Продукт предоставляет возможность положительной проверки действительности электронного документа с ЭП на неограниченном промежутке времени (при условии целостности самого электронного документа), т. е. может быть использован для организации процесса длительного архивного хранения.
• Продукт может быть использован для автоматизации проверки ЭП, что является весомым преимуществом, исключая необходимость участия в этом процессе рядового сотрудника.
• Решение предоставляет SDK-клиенты служб, что может быть использовано для интеграции функциональных возможностей в любой сторонний продукт. А это, в свою очередь, исключает необходимость установки дополнительного программного обеспечения на рабочие станции пользователя, добавляя всего одну лишь кнопку в знакомый и привычный интерфейс.

Недостатки

• Нет сертификата ФСБ России (в процессе получения).
• Реализация одного протокола проверки ЭП и сертификатов — DVCS, наряду с существованием таких протоколов как XKMS, OASIS DSS.
• Не поддерживает работу на операционных системах семейства Unix и macOS (в разработке).