Финальный этап проекта заключался в функциональном тестировании ПО и подготовкой к приемке приложения со стороны заказчика.
Современные реализации криптографического преобразования с использованием хеш-функций позволяют достичь следующих показателей электронной подписи:
? контроль целостности передаваемого документа: при всех случая изменения данных документа (умышленные или произвольный) подпись при проверки корректности станет не валидной (недействительной), ввиду того, что вычисленный результат хеш-функции, называемой хеш-кодом, от измененного документа не совпадает с тем, что хранится в самой подписи.
? защиту от изменений документа после подписания: гарантированное выявление изменений документов средствами проверки подписи делает нецелесообразным его подделывание.
? невозможность сменности авторства: информация о владельце подписи документа содержится в закрытом ключе в паре с открытым ключом, следовательно, реквизит электронной подписи также хранит эту информацию.
? доказательное подтверждение авторства документа: создание электронной подписи осуществляется с помощью закрытого ключа, который принадлежит и доступен только его автору. Доказательство владения документом может доказать только его автор. Также реквизит электронной подписи может в себе иметь информацию о метке времени, цепочке сертификатов, предшествующих сертификат владельца подписи.
6. Инструментальные и программные средства реализации
Разработку данного проекта можно разделить на две основные составляющие: модуль подписания и проверки подписи документов, веб-сервис с REST API, который осуществляет основное взаимодействие с криптографическим модулем.
Для разработки веб-сервиса использовался Spring Framework и его модуль Spring MVC, который регулирует запросы поверх http посредством dispatcher servlet и RestController с основными методами GET и POST. Метод GET имеет endpoint /signature/verify и служит для проверки подписи. Метод POST имеет endpoint /signature/sign и служит для организации электронного подписания документов.
Для реализации модуля подписания и проверки подписи документов была использована Java 8 версии, сертифицированным и достоверным средством защиты информации является российский разработчик криптографических утилит КриптоПро CSP версии 4.0 и КриптоПро JCP версии 2.0 с использованием КриптоПро Java CSP версии 4.0.
Криптопровайдер КриптоПро JCP после достаточно продолжительного несертифицированного периода добился получения сертификата соответствия от регулятора. Модуль КриптоПро Java CSP версии 4.0 не имеет никаких криптографических элементом, а по факту является прикладным программным интерфейсом к криптопровайдеру КриптоПро CSP, насчет его сертификации проблем не возникает. Следует упомянуть, что рабочий (удостоверительный) сертификат на средство компьютерной защиты информации не является обязательным при условии использования криптографических утилит провайдера только для внутренних (некоммерческих) целей.
Согласно спецификации Java Cryptography Architecture (JCA), в веб-сервисе я указаны и использованы функции криптопровайдера КриптоПро Java CSP [7]. После непосредственно установки СКЗИ КриптоПро, криптопровайдер отображен и расположен в следующей директории java/jdk1.8.x_xxx/jre/lib/security/java.security, где java - переменная окружения задаваемая при установке. Сам файл java.security можно настраивать и указывать наиболее предпочтительного криптопровайдера для использования по умолчанию, если другой нигде не задан явно:
#
# List of providers and their preference orders (see above):
#
security.provider.1=ru.CryptoPro.JCSP.JCSP
Следует отметить, что экспортные ограничения Java платформы должны быть сняты, ввиду того, что они могут блокировать работу с отечественными алгоритмами шифрования криптопровайдера.
В связи с этим в каталоге java/jdk1.8.x_xxx/jre/lib/security следует заменить библиотеки US_export_policy.jar и local_policy.jar. Необходимые для замены биболиотеки расположены по адресу https://www.oracle.com/java/technologies/javase-jce8-downloads.html и содержат default_US_export.policy и default_local.policy.
Затем необходимо прописать разрешения на выполнения криптографических утилит КриптоПро:
grant {
// There is no restriction to any algorithms.
permission javax.crypto.CryptoAllPermission;
};
Для формирования штампа электронной подписи на PDF документы используется библиотека iText, что также было предусмотрено самим криптопровайдером. В состав КриптоПро входит специальный patch (набор изменений для взаимодействия с отечественными алгоритмами) для версии 5.1.3 библиотеки iText.
Загрузка пользовательских сертификатов осуществляется в стандартное хранилище Java ca_certs с помощью утилиты keytool.
Для разработки веб-сервиса используется Spring Boot и его модуль Spring MVC, который регулирует запросы поверх http посредством dispatcher servlet и RestController с основными методами GET и POST. Метод GET имеет endpoint /signature/verify и служит для проверки подписи [6]. Метод POST имеет endpoint /signature/sign и служит для организации электронного подписания документов. В качестве веб-сервера используется встроенный в Spring starter Apache Tomcat embedded. Взаимодействие пользователей с веб-сервисом осуществляется посредством UI, который оформляется с помощью фреймворка Spring Thymeleaf.
В качестве автоматизированного сборщика проекта выступает Apache Maven - фреймворк, основанный на языке POM, который в свою очередь является разновидность формата XML. Файл сборщика хранит себе все зависимые библиотеки, необходимые для работы веб-сервиса.
Развертывание веб-сервиса происходит с помощью Jenkins - открытое программное обеспечение для непрерывного развертывания приложений.
7. Архитектура веб-сервиса
Веб-сервис построен по принципам model-view-controller, что означает чёткое разделение на составляющие: клиент - пользовательский интерфейс, сервер - REST API, model - хранилище сертификатов.
Модель по аналогии с базой данных отвечает за взаимодействие с хранилищем сертификатов, расположенное на сервере. Непосредственно серверная часть отвечает за принятие запросов от клиент и выполнение бизнес логики в соответствии с принятым запросом.
Архитектура веб-сервиса отображена на рисунке 1. Предусмотрены два варианта взаимодействия с модулем подписания, пользовательский интерфейс и открытое REST API для внешний систем.
Рисунок 8. Функциональная архитектура
8. Серверная часть веб-сервиса
Серверная часть веб-сервиса состоит из двух частей: модуль подписания документов и проверка подписи, и прикладной программный интерфейс к доступу функционала модуля подписания. С API веб-сервиса могут взаимодействовать внешние системы и пользовательский интерфейс.
электронный цифровой подписание документ
8.1 Модуль ЭЦП
Принцип работы модуля электронного подписания заключается в настройке окружения, получении данных сертификата пользователя: публичный и закрытый ключ, персональная информация, а также использовании криптографических утилит провайдера КриптоПро.
В основе программного обеспечения криптопровайдера, реализующего подписание документов, находится класс CAdESSignature. Перед использованием класса необходимо настроить системное окружение, которое позволит использовать отечественные алгоритмы ЭЦП. Для этого необходимо установить следующие значения для переменных:
· ru.CryptoPro.reprov.enableCRLDP = true;
· com.sun.security.enableCRLDP = true.
После создания объекта CAdESSignature необходимо вызвать два метода, которые устанавливают цепочку сертификатов и задают подписанта документа:
· setCertificateStore принимает объект CollectionStore;
· addSigner принимает объекты: идентификатор провайдера, октеты публичного и закрытого ключей, цепочку сертификатов, тип подписи стандарта CadES, ссылку на удостоверяющий центр.
В классе CAdESSignature описаны основные методы формирования электронной подписи и проверки подписи. За подписание документа отвечают методы open и update. Open открывает байтовый поток документа, update записывает в байтовый поток полученную подпись. Сформированную подпись необходимо сохранить и отдать клиенту с расширением “sig.” Метод verify осуществляет проверку подписи и возвращает логический результат: true, false.
8.2 REST контроллер
REST - архитектурный стиль взаимодействия посредством протокола HTTP. Веб-сервис использует этот стиль как основной для интеграции с внешними система и для взаимодействия с пользовательским интерфейсом. Подписание документов и проверка их подписей - основные две задачи, реализуемые в рамках сервиса, соответственно необходимо в контроллере предусмотреть два POST запроса [8].
Первый запрос предоставляет интерфейс для подписания документов. Он должен принимать информацию о сертификате пользователя, сам файл для подписания и формат подписи стандарта CadES. Отдает запрос отсоединенную подпись в формате “sig”. Структура запроса выглядит так:
POST: /api/v1/signature/sign
На рисунке 9 изображено выполнение запроса на подписание документа, результатом запроса является объект, содержащий поля в формате Base64:
· document - документ,
· sign - подпись документа.
Рисунок 9. Пример выполнения запроса на подписание документа
Первый запрос предоставляет интерфейс для проверки подписи документа. Он должен принимать информацию о сертификате пользователя, сам файл для подписания и отсоединенную подпись. Отдает запрос результат проверки подписи в логическом формате. Структура запроса выглядит так:
POST: /api/v1/signature/verify
На рисунке 10 изображено выполнение запроса на проверку подписи документа, результатом запроса является объект, содержащий поле в формате boolean:
· result - результат проверки подписания.
Рисунок 10. Пример выполнения запроса на проверку подписи документа
9. Клиентская часть веб-сервиса
9.1 Взаимодействие с API
Основные компоненты пользовательского интерфейса составляют веб-формы, с помощью которых пользователь вводит необходимые данные как текстовые, так и файловые. Отправка запроса для пользователя осуществляется нажатием кнопки (submit). Таким образом, пользовательский интерфейс способствует простому и удобному способу взаимодействию с модулем подписания документов через прикладной программный интерфейс.
9.2 Spring Thymeleaf
Spring Thymeleaf - шаблонизатор, позволяющий описать пользовательский интерфейс через формы, в которых содержатся поля ввода (input), которые в свою очередь соотнесены с переменными. Весь набор переменных, содержащийся в форме становится телом запросом, отправляемых на контроллер веб-сервиса.
На рисунке 11 изображён пользовательский интерфейс подписания документа.
Рисунок 11. Пользовательский интерфейс
10. Развертывание и внедрение в корпоративные информационные системы
В данном разделе описаны процедуры установки программного обеспечения провайдера КриптоПро, независимой работы с модулем подписания и проверки подписи как с библиотекой, а также порядок работы с веб-сервисом и его внедрение на корпоративные системы.
10.1 Инструкция по установке
1. Установить
? Java SE Development Kit 7
? КриптоПро JCP 2.0.39014 (выбрать JRE внутри JDK)
? КриптоПро CSP 4.0.9958.0
На рисунке 12 показан пример выбора Java Runtime Environment.
Рисунок 12. КриптоПро JCP установка
На рисунке 13 показан пример выбора продуктов, предоставляемых провайдером КриптоПро.
Рисунок 13. Параметры установки КриптоПро
1. Настроить переменные среды
JAVA_HOME <путь к JRE внутри JDK>
PATH %JAVA_HOME%\bin
2. Заменить файлы Java Cryptography Architecture в каталоге “C:\Program Files\Java\jdk1.7.0_80\jre\lib\security”
local_policy.jar
US_export_policy.jar
3. Добавить файлы из maven сборки в каталог “C:\Program Files\Java\jdk1.7.0_80\jre\lib\ext” следующие файлы
bcpkix-jdk15on-1.50.jar
bcprov-jdk15on-1.50.jar
4. Добавить в хранилище “cacerts” корневой сертификат УЦ через утилиту keytool
keytool -importcert -file <путь к сертификату> -alias <псевдоним сертификата в хранилище> -keystore <путь к хранилищу сертификатов> -storepass <пароль от хранилища (по умолчанию, “changeit”)>
Пример:
keytool -importcert -file “C:\SignaturePDF\test_ca.cer” -alias test_ca.cer -keystore “C:\Program Files\Java\jdk1.7.0_80\jre\lib\security\cacerts” -storepass changeit
· Trust this certificate: yes
· Запустить панель управления JCP
· ControlPane.bat <путь к JRE внутри JDK>
· Сгенерировать закрытый ключ в контейнере. Пример:
· Перейти в раздел “Keys and certificates stores”
· Открыть “HDImageStore” -> Выбрать “Create”
· Задать имя контейнера “New container name” (пример, “ppr”)
· Тип ключа выбрать: Signature key
· Password: enabled
· Указать пароль: (пример, “ppr”)
· Provider type: GOST R 34.10-2012 (256)
· Request coding: BASE64
· Сохранить файл ключа
5. Отправить запрос на получение сертификата по адресу https://www.cryptopro.ru/certsrv/certrqxt.asp, загрузить текст ключа из сохраненного файла и отправить
6. Добавить полученный сертификат в контейнер с помощью “Add”
10.2 Развертывание
Для получения сборки приложения в корпоративной контуре необходимо воспользоваться сборщиком проекта Apache Maven. Разработчику проекта необходимо выполнить команду mvn -package, в результате команды получится артефакт приложения с расширением “war”. Развернуть приложение можно на любом веб-сервере, например, Apache Tomcat (рис. 14).
Рисунок 14. Apache Tomcat 8
После развертывания нужно убедиться, что все конечные точки веб-сервиса функционируют должным образом. Для этого необходимые выполнить запросы согласно разделу 8.2 и убедиться в том, что ответ приходит со статусом 200 и в теле ответа отображены не пустые поля.