Программно-аппаратный комплекс подтверждения подлинности электронных документов и электронных подписей Российский патент 2020 года по МПК G06F21/64 

Изобретение относится к электронной промышленности, а именно к безбумажным технологиям ведения документооборота, и может быть использовано для обеспечения юридически значимого электронного документооборота: внутреннего (корпоративного), внешнего (межкорпоративного), трансграничного - предпочтительно; длительного архивного хранения электронных документов (ЭД); PKI-файервол (режимы ограничения передачи в информационную систему (ИС) организации ЭД, юридическая значимость которых заведомо не подтверждена; режима фиксации событий передачи в ИС организации ЭД, юридическая значимость которых заведомо не подтверждена).

Используемые в описании термины и сокращения:

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

2) Сертификат ключа проверки ЭП - электронный документ или документ на бумажном носителе, выданные удостоверяющим центром либо доверенным лицом удостоверяющего центра и подтверждающие принадлежность ключа проверки ЭП владельцу сертификата ключа проверки ЭП (ФЗ-63 от 06.04.2011).

3) Владелец сертификата ключа проверки ЭП - лицо, которому в установленном порядке выдан сертификат ключа проверки ЭП (ФЗ-63 от 06.04.2011).

4) Ключ ЭП - уникальная последовательность символов, предназначенная для создания ЭП (ФЗ-63 от 06.04.2011).

5) Ключ проверки ЭП - уникальная последовательность символов, однозначно связанная с ключом ЭП и предназначенная для проверки подлинности ЭП (ФЗ-63 от 06.04.2011).

6) Электронный документ (ЭД) - документированная информация, представленная в электронной форме, то есть в виде, пригодном для восприятия человеком с использованием электронных вычислительных машин, а также для передачи по информационно-телекоммуникационным сетям или обработки в информационных системах (ФЗ-149 от 27.07.2006).

7) Программно-аппаратный комплекс (ПАК) - это набор аппаратных и программных средств, работающих совместно для выполнения одной или нескольких сходных задач.

8) Инфраструктура открытых ключей (ИОК, англ. PKI - Public Key Infrastructure) - набор технических средств, распределенных служб и компонентов, в совокупности используемых для поддержки криптографических вычислений на основе ключа ЭП и ключа проверки ЭП.

9) DVCS (англ. Data Validation and certification server) - протокол, обеспечивающий реализацию проверки действительности ЭП на ЭД, актуального статуса сертификата ключа проверки ЭП, подтверждение обладания пользователем данными в электронной форме с предоставлением сервису или без предоставления (по хеш-значению данных). DVCS представляет собой третью доверенную сторону (согласно RFC3029).

10) Инженерный совет интернета (англ. Internet Engineering Task Force, IETF) - открытое международное сообщество проектировщиков, ученых, сетевых операторов и провайдеров, созданное в 1986 году и занимающееся развитием протоколов и архитектуры интернета.

11) RFC3029 ((Internet Х.509 Public Key Infrastructure. Data Validation and Certification Server Protocols)) - рекомендации IETF, которые описывают порядок функционирования, структуру сервиса DVCS, а также протокол, на основе которого этот сервис функционирует.

12) ETSI (англ. European Telecommunications Standards Institute, Европейский институт по стандартизации в области телекоммуникаций)- независимая, некоммерческая организация по стандартизации в телекоммуникационной промышленности (изготовители оборудования и операторы сетей) в Европе.

13) CMS (англ. Cryptographic message syntax) - стандарт, который описывает структуру криптографических сообщений, включающих в себя защищенные данные вместе со сведениями, необходимыми для их корректного открытия или использования.

14) CAdES (CMS Advanced Electronic Signatures) - это стандарт ЭП, представляющий собой расширенную версию стандарта CMS и разработанный ETSI. В стандарте подписи CAdES исправлены такие недостатки CMS, как отсутствие штампа доверенного времени создания ЭП (и, как следствие, отсутствие доказательства существования ЭД на конкретный момент времени и доказательства подлинности сертификатов на момент генерации ЭП), отсутствие типа содержимого ЭП и отсутствие возможности долгосрочного сохранения подлинности ЭП.

15) XAdES - стандарт ЭП, определяющий порядок и структуру формирования подписанного ЭД в формате XML.

16) PAdES - стандарт ЭП, который определяет серию профилей для ЭД в формате PDF.

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

18) Long-term signature - механизм, который позволяет добавлять в ЭП штамп времени над последовательностью данных самой ЭП.

19) RFC3161 «Internet Х.509 Public Key Infrastructure. Time-Stamp Protocol (TSP) - рекомендации IETF, регламентирующие порядок формирования и структуру доказательства существования ЭД на определенный момент времени (штамп времени);

20) Штамп времени - ЭД, заверенный ЭП.

21) TSP (англ. Time-stamp protocol) - это криптографический протокол, позволяющий создавать доказательство факта существования ЭД на определенный момент времени.

22) OCSP (англ. On-line Certificate Status Protocol) - интернет-протокол, используемый для определения актуального статуса сертификата ключа проверки ЭП.

23) PKCS#11 (англ. Public Key Cryptography Standards) - платформонезависимый программный интерфейс доступа к криптографическим устройствам (токены, смарт-карты).

24) VSD (англ. Validation of Digitally Signed Documents) - протокол, на основе которого формируется запрос к сервису DVCS, предоставляющий информацию о действительности ЭП на ЭД.

25) VPKC (англ Validation of Public Key Certificates) - протокол, на основе которого формируется запрос к сервису DVCS, предоставляющий информацию о статусе сертификата ключа проверки ЭП.

26) CPD (англ. Certification of Possession of Data) - протокол, на основе которого формируется запрос к сервису DVCS, удостоверяющий обладание данными пользователем на конкретный момент времени.

27) CCPD (англ. Certification of Claim of Possession of Data) - протокол, на основе которого формируется запрос к сервису DVCS, удостоверяющий обладание данными пользователем на конкретный момент времени без предоставления этих данных сервису (по хеш).

28) ДТС - доверенная третья сторона.

29) СДТС - служба доверенной третьей стороны.

30) СУБД - система управления базами данных.

Известен «Способ подписания документов электронной аналого-цифровой подписью и устройство для его реализации» (патент РФ №2287223, кл. H04L 9/32,2005 г.), позволяющий подписывать документы электронной аналого-цифровой подписью без предварительного генерирования личных электронных цифровых подписей пользователей. Идентификация пользователя, подписавшего такой электронный документ, осуществляется по биометрическим данным пользователя, которые становятся неотъемлемой частью только данного электронного документа и которые невозможно вставить в другой электронный документ аналогичного формата.

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

Наиболее близким по технической сущности и достигаемому результату является «Способ подписания электронных документов аналого-цифровой подписью с дополнительной верификацией» и устройство для его осуществления, содержащее выделенный сервер с входным интерфейсом, включающим блок проверки действительности электронной подписи (RU патент №2522024, кл. G06F 21/64, 2012 г.).

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

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

Недостатками известного способа и устройства для его осуществления являются:

- невозможность поддержки электронной подписи (ЭП) форматов CMS, CAdES, XAdES, PAdES;

- невозможность работы с иностранными клиентами;

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

- невозможность создания квитанции (электронного юридически значимого документа, подтверждающего результат обработки запроса заверенной ЭП, созданной в соответствии с рекомендациями RFC3161 «Internet Х.509 Public Key Infrastructure. Time-Stamp Protocol (TSP);

- невозможность создания автоматизированного процесса длительного архивного хранения (ДАХ) квитанций, сформированных по результатам обработки запросов, при поддержании свойств их юридической значимости (обеспечение контроля и продления срока действия ЭП квитанций согласно механизму long-term signature (ETSI);

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

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

- отсутствие библиотеки SDK, обеспечивающей инструментарий для создания приложений, взаимодействующих с другим ДТС;

- отсутствие поддержки PKCS#11 (работа как с аппаратными, так и с программными средствами криптографической защиты информации);

- отсутствие поддержки взаимодействия с комплексами сторонней разработки на основе общего протокола Data Validation and Certification Service Protocol (DVCS) (в соответствии с рекомендациями RFC3029);

- отсутствие ролевого разграничения учетной записи администратора для гибкого конфигурирования комплекса.

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

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

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

блок аутентификации, при этом блок аутентификации обеспечивает аутентификацию клиента по сертификату ключа проверки ЭП или по логину и паролю;

первый блок работы с криптографией, который формирует ЭП созданного запроса;

блок передачи данных, обеспечивающий трансляцию DVCS-запроса клиента к серверной части ПАК;

кроме того пункт формирования DVCS-запроса содержит последовательно соединенные

блок приема данных, который обеспечивает прием DVCS-квитанции, сформированной серверной частью по результатам обработки DVCS-запроса клиента;

блок декомпрессии данных, обеспечивающий декомпрессию принятой DVCS-квитанции;

второй блок работы с криптографией, который осуществляет проверку математической корректности ЭП сервисов TSP и DVCS, проверку действительности сертификатов сервисов, и получение информации из структуры запроса;

и блок разбора квитанций, являющийся выходом системы, который передает клиенту сформированную DVCS-квитанцию;

при этом пункт функционирования сервисов DVCS, включает последовательно соединенные

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

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

блок проверки целостности, выполняющий анализ целостности файла DVCS-запроса;

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

блок взаимодействия с удаленными сервисами ДТС, служащий для трансляции DVCS-запроса в адрес иного сервиса DVCS (2_k), в случае, если запрос сформирован на базе иностранного криптографического алгоритма, а также приема результата обработки этого запроса от иностранного ДТС;

блок создания квитанции, который формирует ЭД, содержащий результаты обработки DVCS-запроса, взаимодействуя с блоком работы с криптографией;

блок логирования, сохранения квитанций, данных о запросе, передающий на хранение в БД сервисов ПАК информацию по всем запросам и результатам их обработки, взаимодействуя при этом с блоком работы с криптографией, при этом обращение к блоку работы с криптографией происходит при реализации задач блока приема и разбора входящих данных и блока проверки целостности;

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

кроме того пункт функционирования сервисов DVCS содержит

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

при этом дополнительно установленный блок криптографии соединен входами и выходами с блоком приемки и разбора входящих данных, блоком проверки целостности, блоком взаимодействия с удаленными сервисами ДТС, блоком создания квитанций и блоком логирования, сохранения квитанций, данных о запросе; при этом выход блока компрессии данных соединен с входом блока приема данных пункта формирования DVCS-запроса.

Уникальность программно-аппаратного комплекса (ПАК) подтверждения подлинности электронных документов и электронных подписей обусловлена следующими возможностями:

- поддержка электронной подписи (ЭП) форматов CMS, CAdES, XAdES, PAdES;

- реализация 4-х типов сервисов, с использованием как на основе российских криптографических алгоритмов (ГОСТ), так и иностранных:

- VSD - проверка действительности ЭП ЭД;

- VPKS - проверка актуального статуса сертификата ключа проверки ЭП;

- CPD, CCPD - удостоверение обладания пользователем информацией на конкретный момент времени соответственно с предоставлением ее ПАК и без предоставления (по хеш-значению данных);

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

- создание квитанции (электронного юридически значимого документа, подтверждающего результат обработки запроса ПАК заверенной ЭП, созданной в соответствии с рекомендациями RFC3161 «Internet Х.509 Public Key Infrastructure. Time-Stamp Protocol (TSP)»;

- поддержка ЭП версии 4, созданной в соответствии с рекомендациями RFC3161 «Internet Х.509 Public Key Infrastructure. Time-Stamp Protocol (TSP)»;

- автоматизированный процесс длительного архивного хранения (ДАХ) квитанций, сформированных по результатам обработки запросов, при поддержании свойств их юридической значимости (обеспечение контроля и продления срока действия ЭП квитанций согласно механизму long-term signature (ETSI);

- квалифицированный режим работы с электронным документом (ЭД) (возможность отправки запросов в ПАК, подписанных только квалифицированным сертификатом ключа проверки ЭП);

- возможность отправлять анонимные запросы в ПАК «СДТС» (по итогу обработки анонимного запроса формируется квитанция, которая не будет обладать юридической значимостью (DVCS-ответ);

- наличие библиотеки SDK, обеспечивающей инструментарий для создания приложений, взаимодействующих с другим ДТС;

- поддержка PKCS#11 (работа ПАК как с аппаратными, так и с программными средствами криптографической защиты информации);

- поддержка взаимодействия с ДТС сторонней разработки на основе общего протокола Data Validation and Certification Service Protocol (DVCS) (в соответствии с рекомендациями RFC3029);

- ролевое разграничение учетной записи администратора ПАК для гибкого конфигурирования комплекса.

Использование программно-аппаратного комплекса подтверждения подлинности электронных документов и электронных подписей обеспечивает:

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

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

- DVCS-ответ на анонимный DVCS-запрос, сформированный в соответствии с нормами российского законодательства (DVCS-ответ не обладает юридической значимостью);

- DVCS-ответ на анонимный DVCS-запрос, сформированный в соответствии с нормами иностранного законодательства (DVCS-ответ не обладает юридической значимостью);

- пролонгация действительности DVCS-квитанций (15, 25 и более лет) при поддержании свойств юридической значимости;

- автоматизированный процесс обработки всех типов DVCS-запросов (посредством встраивания SDK);

- получение DVCS-квитанций по ранее обработанным запросам по истечении любого количества лет.

Результат обработки фиксируется в DVCS-квитанции, заверяется квалифицированной ЭП сервиса DVCS, которая имеет формат CAdES-L-T или XAdES-L-Т, что позволяет обеспечить юридическую значимость самой квитанции и документа, для которого эта квитанция выпущена, на протяжении длительного периода времени.

В состав ПАК входят:

- сервис проверки подлинности (DVCS);

- сервис штампов времени (TSP);

- SDK-клиент для сервиса DVCS;

- SDK-клиент для сервиса TSP;

- программное обеспечение (ПО), например, «Litoria Dvc Applet»;

- АРМ администратора.

Сервис DVCS (полное описание протокола DVCS, на основании которого строится работа сервиса, приведено в рекомендациях RFC3029 «Internet Х.509 Public Key Infrastructure. Data Validation and Certification Server Protocols) предоставляет услуги проверки данных в запросе, полученном сервисом от пользователя, подтверждая действительность ЭП документа, срок действия сертификатов ключей проверки ЭП. Также сервис свидетельствует о предоставлении ему данных и о факте обладания пользователем этими данными в указанный момент времени.

Сервис DVCS включает следующие компоненты:

- сервер(а) сервиса DVCS;

- личный кабинет пользователя ПАК «СДТС» (подключение к личному кабинету осуществляется через web-браузер с АРМ пользователя);

- подсистему управления доступом и администрирования сервиса DVCS.

На сервере(ах) сервиса DVCS устанавливаются:

- web-служба;

- web-портал;

- база данных сервиса DVCS.

Компоненты сервисов ПАК могут функционировать как на одном сервере, так и в распределенном варианте. При этом предпочтительным является вариант функционирования компонентов каждого сервиса на одном сервере.

Сервер(а) сервиса DVCS позволяет осуществлять:

1) обработку всех типов DVCS-запросов (согласно RFC3029):

- подтверждение ЭП ЭД (Validation of Digitally Signed Document - VSD);

- подтверждение действительности сертификата ключа проверки ЭП (Validation of Public Key Certificates - VPKC);

- удостоверение обладания информацией в указанный момент времени с предоставлением ее сервису (Certification of Possession of Data - CPD);

- удостоверение обладания информацией без предоставления ее сервису (Certification of Claim of Possession of Data - CCPD);

2) формирование DVCS-ответов (DVCS-квитанций) на основе данных, полученных в ходе проверки подлинности;

3) формирование DVCS-квитанций посредством подписи DVCS-ответа в форматах следующих стандартов:

- Cryptographic Message Syntax (CMS);

- CAdES (RFC5126 «CMS Advanced Electronic Signatures (CAdES)»);

- XAdES (ETSI TS 101 903 V1.4.1 «XML Advanced Electronic Signatures (XAdES)»);

4) поиск и выдачу DVCS-квитанций на ранее сделанный DVCS-запрос;

5) формирование (отправку) запроса на получение штампа времени;

6) взаимодействие с ДТС сторонней разработки на основе общего протокола DVCS;

7) работу как с аппаратными, так и с программными средствами криптографической защиты информации (СКЗИ);

8) обработку анонимных запросов;

9) в зависимости от конфигурации службы обработку запросов, подписанных только квалифицированным сертификатом ключа проверки ЭП;

10) контроль и продление срока действия ЭП квитанции на основе механизма long-term signature.

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

База данных предоставляет возможности ведения архивации и хранения следующих данных:

- пользовательской информации в БД;

- выданных DVCS-квитанций и их серийных номеров;

- файлов журнала событий ПАК, содержащих дату, время и тип действия.

ПАК поддерживает взаимодействие с СКЗИ через интерфейсы CryptoAPI, PKCS#11.

Личный кабинет пользователя ПАК позволяет осуществлять:

- формирование и отправку всех типов DVCS-запросов (VSD, VPKC, CPD, CCPD);

- поиск и получение DVCS-квитанций на ранее обработанный DVCS-запрос;

- редактирование данных профиля пользователя;

- предоставление пользователю данных о его действиях в ПАК, содержащих дату, время и тип действия.

Подсистема управления доступом и администрирования сервиса DVCS обеспечивает выполнение следующих функций:

- настройку аутентификации пользователей по логину и паролю;

- настройку аутентификации пользователей по сертификатам;

- настройку взаимной аутентификации серверов сервисов ПАК между собой.

Кроме того, для пользователей с полномочиями администратора предусмотрены следующие дополнительные возможности:

- добавление учетных записей пользователей в систему и разделение пользовательских полномочий;

- просмотр квитанций других пользователей;

- широкие возможности по конфигурированию комплекса.

Сервис TSP (полное описание протокола TSP, на основании которого строится работа сервиса, приведено в рекомендациях RFC3161 «Internet Х.509 Public Key Infrastructure. Time-Stamp Protocol») удостоверяет факт существования ЭД на определенный момент времени. Сервис выдает штампы времени - ЭД, которые подписаны ЭП сервера, на котором функционирует сервис TSP.

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

Сервис TSP ПАК представлен сервером(ами) этого сервиса. На сервере(ах) развертываются следующие компоненты:

- сервис TSP;

- базы данных сервиса TSP.

Оба компонента могут функционировать как на одном сервере, так и в распределенном варианте.

Сервис TSP работает под управлением веб-сервера IIS 7.5/8.5 и использует СУБД Microsoft SQL Server для сохранения подписанных ответов сервера штампов времени и настроек самого сервера штампов времени.

Сервер сервиса TSP ПАК позволяет осуществлять формирование штампов времени в случаях:

- фиксации времени создания DVCS-ответа;

- фиксации времени формирования DVCS-квитанции (подпись DVCS-ответа).

SDK-клиент сервиса DVCS предоставляет набор инструментария для создания клиентских приложений, взаимодействующих с сервисом DVCS.

В состав SDK-клиента сервиса DVCS входят:

- библиотека С++;

- библиотека С#;

- описание интерфейсов с примерами вызовов для каждого элемента SDK-клиента сервиса DVCS.

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

- создания всех типов DVCS-запросов (VSD, VPKC, CPD, CCPD);

- создания ЭП DVCS-запроса для аутентификации DVCS-запросов пользователя на сервере сервиса DVCS в форматах следующих стандартов: CMS, CAdES;

- отправки DVCS-запроса;

- получения ответа (DVCS-квитанции) от сервиса DVCS;

- проверки целостности DVCS-квитанции;

- проверки статуса сертификата ключа проверки ЭП сервиса DVCS;

- проверки корректности формата DVCS-квитанции;

- обработки DVCS-квитанции с отрицательным результатом работы сервиса DVCS;

- проверки соответствия DVCS-квитанции DVCS-запросу в случае положительного результата подтверждения или удостоверения;

- преобразования полученного ответа в читаемый вид;

- сохранения DVCS-квитанции согласно рекомендациям RFC3029.

SDK-клиент сервиса TSP предоставляет набор инструментария для создания клиентских приложений, использующих штампы времени в соответствии с рекомендациями RFC3161.

В состав SDK-клиента сервиса TSP входит библиотека (С++) и описание ее интерфейсов с примерами вызова.

Библиотека (С++) предоставляет разработчику приложения программные интерфейсы для вызова следующих основных функций сервиса TSP:

- создания TSP-запроса согласно рекомендациям RFC3161;

- отправки запроса;

- получения TSP-ответа от сервиса TSP;

- проверки целостности TSP-ответа;

- проверки соответствия штампа времени из ответа TSP-запросу;

- проверки статуса сертификата ключа проверки ЭП сервиса TSP;

- сохранения TSP-ответа согласно рекомендациям RFC3161, ETSI TS 101 733, RFC3029, ETSI TS 102 778.

В качестве программного обеспечения (ПО), можно использовать, например, «Litoria Dvc Applet».

ПО «Litoria Dvc Applet» является альтернативой использованию веб-интерфейса личного кабинета пользователя в части формирования и отправки всех типов DVCS-запросов (VSD, VPKC, CPD, CCPD), также поиска и получения квитанций на ранее обработанный DVCS-запрос.

АРМ администратора предоставляет возможность осуществлять конфигурирование настроек ПАК и управление профилями и учетными записями пользователей, имеющих доступ к ПАК.

АРМ администратора ПАК обеспечивает выполнение следующих функций:

- конфигурирование и настройка ПАК;

- управление профилями пользователей, зарегистрированных в ПАК;

- управление доступом и правами пользователей;

- анализ журнала аудита и системных сообщений;

- просмотр выданных квитанций.

Для настройки различных групп параметров и функций ПАК вводятся следующие роли администраторов:

1) системный администратор, в обязанности которого входит:

- инсталляция, настройка и поддержка функционирования ПАК;

- создание и поддержка профилей членов группы администраторов комплекса;

- настройка профиля и параметров журнала аудита;

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

2) администратор сертификатов, в обязанности которого входит установка сертификатов на сервера сервисов ПАК;

3) администратор безопасности, в обязанности которого входит установка и настройка средств защиты;

4) администратор пользователей, в обязанности которого входит:

- создание и удаление пользователей комплекса;

- управление правами пользователей;

- просмотр статистики используемых услуг.

Программно-аппаратный комплекс подтверждения подлинности электронных документов и электронных подписей поясняется чертежами.

На фиг. 1 представлена блок-схема, отображающая общее функционирование программно-аппаратного комплекса (ПАК) подтверждения подлинности электронных документов и электронных подписей и взаимодействие между клиентом и сервисами DVCS, где:

1₁…1_q(p) - DVCS-запросы, сформированные клиентом;

2₁…2_k - Сервисы DVCS.

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

В качестве клиентов, которые формируют DVCS-запрос, могут выступать пользователи (сервера, программное обеспечение, люди), являющиеся резидентами государств, где функционирует ПАК с программным обеспечением «Litoria Dvc Applet», или его аналоги, реализованные в соответствии с рекомендациями RFC3029.

Взаимодействие клиента (фиг. 1) с комплексом осуществляется при отправке клиентом сформированного им DVCS-запроса (количество запросов варьируется от 1₁ до 1_q) в службу проверки подлинности (2₁).

Обратное взаимодействие комплекса с клиентом осуществляется при отправке клиенту сформированной DVCS-квитанции.

Взаимодействие комплекса с другой службой ДТС (2₂ - 2_k) осуществляется в том случае, когда сервер проверки подлинности не поддерживает алгоритм проверяемой подписи или сертификата, поэтому сервер перенаправляет запрос на тот сервер ДТС, который поддерживает этот алгоритм.

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

Работа программно-аппаратного комплекса подтверждения подлинности электронных документов и электронных подписей осуществляется следующим образом:

Клиентом на «вход» Клиентской части (1) подаются исходные данные (подписанный ЭД или подписанный хеш ЭД, или сертификат ключа проверки ЭП), а также сертификат ключа проверки ЭП пользователя для формирования подписанного DVCS-запроса (VSD, VPKC, CPD, CCPD) на проверку.

DVCS-запрос передается в Блок обработки входящих данных (1.1), который осуществляет проверку формата файла запроса и/или проверку наличия и действительности сертификатов ключей проверки ЭП сервисов TSP и DVCS.

Блок аутентификации (1.2) обеспечивает аутентификацию клиента по сертификату ключа проверки ЭП или по логину и паролю.

После успешной аутентификации, DVCS-запрос передается в Блок работы с криптографией (1.3), который формирует ЭП созданного запроса.

Блок передачи данных (1.4) обеспечивает трансляцию DVCS-запроса клиента к серверной части ПАК.

DVCS-запрос от Клиентской части передается на Серверную часть (2) DVCS ПАК «СДТС «Litoria DVCS 2».

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

Блок приема и разбора входящих данных (2.2) выполняет проверку действительности сертификата ключа проверки ЭП пользователя и математическую корректность ЭП пользователя.

Блок проверки целостности (2.3) выполняет анализ целостности файла DVCS-запроса.

Обращение к Блоку работы с криптографией (2.4) происходит при реализации задач блока приема и разбора входящих данных и блока проверки целостности.

Блок аутентификации (2.5) позволяет сервисам ПАК получить доступ к своим базам данных для записи результатов обработки DVCS-запроса.

Блок работы с базой данных (2.6) хранит все данные по результатам обработки запросов (DVCS-квитанции).

Блок взаимодействия с удаленными сервисами ДТС (2.7) служит для трансляции DVCS-запроса в адрес иного сервиса DVCS (2_k), реализованного в соответствии с требованиями RFC3029 в случае, если запрос сформирован на базе иностранного криптографического алгоритма, а также приема результата обработки этого запроса (DVCS-квитанции) от иностранного ДТС.

Блок создания квитанции (2.8) формирует ЭД (DVCS-квитанцию), содержащую результаты обработки DVCS-запроса, взаимодействуя с Блоком работы с криптографией (2.4).

Блок логирования, сохранения квитанций, данных о запросе (2.9) передает на хранение в БД сервисов ПАК «СДТС «Litoria DVCS 2» информацию по всем запросам и результатам их обработки, взаимодействуя при этом с Блоком работы с криптографией (2.4).

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

Блок приема данных (1.5) обеспечивает прием DVCS-квитанции, сформированной ПАК по результатам обработки DVCS-запроса клиента.

Блок декомпрессии данных (1.6) обеспечивает декомпрессию принятой DVCS-квитанции.

Блок работы с криптографией (1.7) осуществляет проверку математической корректности ЭП сервисов TSP и DVCS, проверку действительности сертификатов сервисов, и получение информации из структуры запроса («снятие» ЭП; извлечение служебной информации).

Блок разбора квитанции (1.8) передает клиенту сформированную DVCS-квитанцию (DVCS-ответ в случае анонимного запроса).

Использование предложенного программно-аппаратного комплекса подтверждения подлинности электронных документов и электронных подписей обеспечивает:

- реализацию протокола DVCS в соответствие с рекомендациями RFC3029;

- реализацию ЭП в соответствие с рекомендациями RFC3161;

- реализацию ЭП стандартов CMS, CAdES, XAdES, PAdES;

- работу с ПАК посредством веб-интерфейса личного кабинета пользователя, с помощью специального программного обеспечения (ПК «Litoria Desktop», ПО «Litoria Dvc Applet», иное программное обеспечение, разработанное на базе SDK);

- механизм long-term signature (ETSI);

- поддержку интерфейса PKCS#11;

- возможность гибкого конфигурирования ПАК.

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

Изобретение относится к области вычислительной техники. Техническим результатом является повышение надежности подтверждения подлинности электронных документов и электронных подписей. Раскрыт программно-аппаратный комплекс подтверждения подлинности электронных документов и электронных подписей, содержащий блок проверки действительности электронной подписи, при этом комплекс дополнительно содержит клиентскую часть - пункт формирования DVCS-запроса и серверную часть - пункт функционирования сервисов DVCS, включающую блок проверки действительности электронной подписи, при этом пункт формирования DVCS-запроса включает в себя последовательно соединенные блок обработки входящих данных, блок аутентификации, первый блок работы с криптографией, блок передачи данных, кроме того пункт формирования DVCS-запроса содержит последовательно соединенные блок приема данных, блок декомпрессии данных, второй блок работы с криптографией и блок разбора квитанций, при этом пункт функционирования сервисов DVCS включает последовательно соединенные блок декомпрессии данных, вход которого соединен с выходом блока передачи данных DVCS-запроса от пункта формирования DVCS-запроса к серверной части, блок приема и разбора входящих данных, являющийся одновременно блоком проверки действительности электронной подписи, блок проверки целостности, блок аутентификации, блок взаимодействия с удаленными сервисами ДТС, блок создания квитанции, блок логирования, сохранения квитанций, данных о запросе, блок компрессии данных, кроме того пункт функционирования сервисов DVCS содержит блок работы с базой данных, который хранит все данные по результатам обработки запросов, соединенный первыми входом и выходом, соответственно, с выходом и входом блока аутентификации, при этом вторые вход и выход блока работы с базой данных соединены с первыми входом и выходом блока логирования, вторые вход и выход которого соединены с дополнительно установленным блоком криптографии; при этом дополнительно установленный блок криптографии соединен входами и выходами с блоком приемки и разбора входящих данных, блоком проверки целостности, блоком взаимодействия с удаленными сервисами ДТС, блоком создания квитанций и блоком логирования, сохранения квитанций, данных о запросе; при этом выход блока компрессии данных соединен с входом блока приема данных пункта формирования DVCS-запроса. 2 ил.

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

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

блок аутентификации, при этом блок аутентификации обеспечивает аутентификацию клиента по сертификату ключа проверки ЭП или по логину и паролю;

первый блок работы с криптографией, который формирует ЭП созданного запроса;

блок передачи данных, обеспечивающий трансляцию DVCS-запроса клиента к серверной части ПАК;

кроме того пункт формирования DVCS-запроса содержит последовательно соединенные

блок приема данных, который обеспечивает прием DVCS-квитанции, сформированной серверной частью по результатам обработки DVCS-запроса клиента;

блок декомпрессии данных, обеспечивающий декомпрессию принятой DVCS-квитанции;

второй блок работы с криптографией, который осуществляет проверку математической корректности ЭП сервисов TSP и DVCS, проверку действительности сертификатов сервисов, и получение информации из структуры запроса;

и блок разбора квитанций, являющийся выходом системы, который передает клиенту сформированную DVCS-квитанцию;

при этом пункт функционирования сервисов DVCS включает последовательно соединенные

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

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

блок проверки целостности, выполняющий анализ целостности файла DVCS-запроса;

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

блок взаимодействия с удаленными сервисами ДТС, служащий для трансляции DVCS-запроса в адрес иного сервиса DVCS (2k), в случае, если запрос сформирован на базе иностранного криптографического алгоритма, а также приема результата обработки этого запроса от иностранного ДТС;

блок создания квитанции, который формирует ЭД, содержащий результаты обработки DVCS-запроса, взаимодействуя с блоком работы с криптографией;

блок логирования, сохранения квитанций, данных о запросе, передающий на хранение в БД сервисов ПАК информацию по всем запросам и результатам их обработки, взаимодействуя при этом с блоком работы с криптографией, при этом обращение к блоку работы с криптографией происходит при реализации задач блока приема и разбора входящих данных и блока проверки целостности;

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

кроме того пункт функционирования сервисов DVCS содержит

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

при этом дополнительно установленный блок криптографии соединен входами и выходами с блоком приемки и разбора входящих данных, блоком проверки целостности, блоком взаимодействия с удаленными сервисами ДТС, блоком создания квитанций и блоком логирования, сохранения квитанций, данных о запросе; при этом выход блока компрессии данных соединен с входом блока приема данных пункта формирования DVCS-запроса.