Программно-аппаратный комплекс подтверждения подлинности электронных документов и электронных подписей
SOFTWARE AND HARDWARE SYSTEM FOR AUTHENTICATION OF ELECTRONIC DOCUMENTS AND ELECTRONIC SIGNATURES

Изобретение относится к электронной промышленности, а именно к безбумажным технологиям ведения документооборота, и может быть использовано для обеспечения юридически значимого электронного документооборота: внутреннего (корпоративного), внешнего (межкорпоративного), трансграничного - предпочтительно; длительного архивного хранения электронных документов (ЭД); 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-запроса;
k
блок взаимодействия с удаленными сервисами ДТС, служащий для трансляции DVCS-запроса в адрес иного сервиса DVCS (2), в случае, если запрос сформирован на базе иностранного криптографического алгоритма, а также приема результата обработки этого запроса от иностранного ДТС;
блок создания квитанции, который формирует ЭД, содержащий результаты обработки 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
q(p)
1…1 - DVCS-запросы, сформированные клиентом;
1
k
2…2- Сервисы DVCS.
На фиг. 2 представлена блок-схема, отображающая подробный процесс формирования клиентом DVCS-запроса и его обработку в процессе функционирования сервисов DVCS.
В качестве клиентов, которые формируют DVCS-запрос, могут выступать пользователи (сервера, программное обеспечение, люди), являющиеся резидентами государств, где функционирует ПАК с программным обеспечением «Litoria Dvc Applet», или его аналоги, реализованные в соответствии с рекомендациями RFC3029.
1
q
1
Взаимодействие клиента (фиг. 1) с комплексом осуществляется при отправке клиентом сформированного им DVCS-запроса (количество запросов варьируется от 1 до 1) в службу проверки подлинности (2).
Обратное взаимодействие комплекса с клиентом осуществляется при отправке клиенту сформированной DVCS-квитанции.
2
k
Взаимодействие комплекса с другой службой ДТС (2 - 2) осуществляется в том случае, когда сервер проверки подлинности не поддерживает алгоритм проверяемой подписи или сертификата, поэтому сервер перенаправляет запрос на тот сервер ДТС, который поддерживает этот алгоритм.
Блок-схема, представленная на фиг. 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-квитанции).
k
Блок взаимодействия с удаленными сервисами ДТС (2.7) служит для трансляции DVCS-запроса в адрес иного сервиса DVCS (2), реализованного в соответствии с требованиями 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;
- возможность гибкого конфигурирования ПАК.
Использование настоящего изобретения позволит повысить надежность подтверждения подлинности электронных документов и электронных подписей.