Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Дипломная работа

Разработка веб-сервиса электронно-цифрового подписания документов

Катунин А.В.



Аннотация

Выпускная квалификационная работа магистра посвящена разработке веб-сервиса электронно-цифрового подписания документов.

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

Основными задачами работы являются:

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

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

? разработка программного обеспечения в рамках реализации электронного подписания документов.

Веб-сервис разработан с использование криптографических утилит КриптоПро JCP и поддерживает разнообразные форматы подписи стандарта CadES. Веб-сервис имеет REST API, который позволяет взаимодействовать со сторонними системами как внешними, так и внутренними (корпоративные информационные системы). Непосредственно модуль, осуществляющий электронное подписание разработан на языке программирования Java 8 версии.

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

Abstract

The master's final qualification work is devoted to the development of a web service for electronic and digital document signing.

The purpose of this work is to provide a guaranteed possibility of digital signature and verification of electronic documents.

The main tasks of the work are:

analysis and research of methods and technologies used at all stages of the life cycle of objects of observation;

reasonable choice of software development methodology;

software development in the framework of electronic document signing.

The web service is developed using cryptographic utilities CryptoPro JCP and supports a variety of signature formats of the CadES standard. The web service has a REST API that allows you to interact with third-party systems, both external and internal (corporate information systems). The module that performs electronic signing is developed in the Java programming language version 8.

The result of the final qualification work is to automate the process of signing electronic documents and provide this functionality for further use and expansion.

Оглавление

• Введение
• 1. Актуальность
• 2. Цели и задачи
• 3. Объект и предмет исследования
• 3.1 Принципы защиты и неизменности документов электронного вида
• 3.2 Алгоритмы реализации электронной подписи
• 4. Обзор существующих технических решений
• 4.1 Контур
• 4.2 Synerdocs
• 4.3 Сравнение аналогов
• 5. Требования к веб-сервису
• 6. Инструментальные и программные средства реализации
• 7. Архитектура веб-сервиса
• 8. Серверная часть веб-сервиса
• 8.1 Модуль ЭЦП
• 8.2 REST контроллер
• 9. Клиентская часть веб-сервиса
• 9.1 Взаимодействие с API
• 9.2 Spring Thymeleaf
• 10. Развертывание и внедрение в корпоративные информационные системы
• 10.1 Инструкция по установке
• 10.2 Развертывание
• 11. Порядок работы с веб-сервисом
• 12. Полученные результаты
• Заключение
• Список использованных источников
• Приложение
• Введение
• В современной жизни мы часто сталкиваемся с процессами, которые уже автоматизированы с использованием современных подходов и технологий, их выполнение занимает считанные секунды и самое главное в достаточной мере экономит не только время, но финансовые средства.
• Каждый из нас в повседневной жизни сталкивается с необходимостью осуществлять подписи на документах на бумажных носителях, например, в качестве подтверждения получения товара, оказания различного рода услуг, ознакомления с информацией, и безусловно самое основное название подписи -- подтверждение и гарантия юридической значимости документов и тех предписаний, которые в них содержатся.
• Процесс обычного и уже привычного многим подписания документов в одностороннем или двустороннем порядке можно разделить на несколько этапов:
• · формирование документа;
• · печать документа;
• · непосредственное подписание напечатанного документа всеми участниками;
• · организация хранения документа в бумажном архиве.
• В таком процессе основным требованием является фактическое присутствие всех сторон, что иногда может оказать существенные трудности в планирование времени на дорогу, особенно если это касается значительных различиях в местоположении участников процесса подписания. Нечасто на сегодняшний день встречаются случаи подписания документом посторонними лицами (подделывание), что сулит возможными проблемами и неприятностями, никто не хочет стать жертвой тех действий и предписаний, которым отражаются в документе. На рисунке 1 сопоставлены автоматизированный и ручной процессы электронной подписи.
• В связи с этим, как эффективное решение данных проблем была предложена организация электронно-цифрового подписания документов и электронный архив документов электронного вида. Электронная подпись является особенным атрибутом документа и гарантирует:
• · неизменность документа после подписания;
• · хранение всей информации о подписантах;
• · подтверждение по времени подписания;
• · физическую проверку подписи документов в любое время.
• Очевидно, что реализация и внедрение электронно-цифровой подписи довольно перспективны и изменять наш привычный уклад жизни в лучшую сторону. Люди могут быть территориально независимы при необходимости подписать документ, а также самое главное могут быть спокойны насчет безопасности и гарантии своей ответственности.
• Выпускная квалификационная работа магистра посвящена разбору электронной подписи документов от идеи и истоков до реализации и применения. В содержании работы будут рассмотрены основные принципы устройства ЭЦП, проанализированы основные алгоритмы хэш-функций отечественных и зарубежных стандартов.
• Как итогом работы станет разработка веб-сервиса электронно-цифровой подписи, который может быть доступен организациям в качестве корпоративной информационной системы, а также для физических лиц, заинтересованных в данной технологии. В разработке веб-сервиса будут использоваться самые передовые технологии, проверенные во многих проектах, гарантирующие безопасность ПО.

1. Актуальность

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

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

На рисунке 2 схематично изображен комплексный процесс подписания и проверки подписи, в котором рассматриваются два пользователя. Первый - носитель пары публичного и приватного ключа, который осуществляет подписание личного документа с использованием приватного ключа, средствами криптографического преобразования получает отсоединенную подпись формата “sig”. Второй пользователь заинтересован в проверке подписи документа, для этого ему потребуется непосредственно документ, отсоединенная подпись и сертифицированная криптографическая утилита. Результатом проверки является логическое выражение, которое принимает значение true или false.



Рисунок 2. Криптографическая схема

2. Цели и задачи

Целью данной работы является автоматизация формирования электронно-цифровой подписи документов на основе криптографических утилит провайдера КриптоПро стандарта CadES и проверки валидной подписи.

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

Веб-сервис должен реализовывать следующие функции:

· подписание;

· проверка подписи.

На сегодняшний день криптографические методы и функции применяются для решения таких задач защиты информации, как:

? гарантия конфиденциальности информации;

? гарантия целостности информации;

? проверка прав доступа к информации (аутентификация);

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

? гарантия прозрачности информации.

3. Объект и предмет исследования

Объектом исследования является процесс обработки данных о результатах тестирования. Данные представлены в виде файлов различных форматов.

Предметом исследования является автоматизация формирования отчета по результатам тестирования.

3.1 Принципы защиты и неизменности документов электронного вида

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

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

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

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

Несмотря на это, симметричные схемы имеют ряд преимущества над ассиметричными:

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

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

Основные недостатки симметричных схем:

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

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

Схема цифровой подписи -- это набор вероятностных полиномиальных алгоритмов, таких как Gen (generate); Sign (sign); Vrfy (verify), удовлетворяющих следующему показателям:

? Gen - алгоритм генерации ключа, который принимает на вход закрытый параметр 1ⁿ и на выходе отдает (pk; sk; s0) - открытый ключ, закрытый ключ, а также начальное состояние.

? Sign - алгоритм подписания содержит в себе закрытый ключ, значение S_i-1 и информацию о m и в результате выдает подпись q вместе со значением S_i.

? Vrfy - детерминированный алгоритм проверки подписи содержит в себе открытый ключ, информацию о m и саму подпись q и выдает результат в виде бит информации b.

3.2 Алгоритмы реализации электронной подписи

RSA

Один из самых первых и наиболее известной схемой электронного подписания документов является RSА - это математическая схема, разработанная в Массачусетском технологическом институте в 1977 г. [5].

Алгоритм подписи основан на некоторых этапах. Первым делом считается пара ключей (закрытый и открытый ключ). Отправитель (автор) документов электронного вида для этого вычисляет два любых больших простых числа p и q, находит их произведение по формуле:

N = p*q

и результат функции f(N) = (p - 1) * (q - 1).

После этого отправитель вычисляет число Е из условий, описанных ниже:

Е ? f(N), где НОД(Е, f(N)) = 1

Также необходимо вычислить число D при условии:

D < N, где Е*D в сравнении с единицей по модулю функции f(N).

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

Рассмотрим ситуацию, в которой автор хочет подписать документ М перед его отправкой конечному пользователю. Перед этим размер документ М необходимо скомпоновать с использованием хэш-функции h(M) в целочисленное значение m: m = h(М).

После этого необходимо вычислить цифровую подпись S под документом электронного вида М, используя хэш-код m и закрытый ключ D:

S = (m^D) * (mod N).

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

После приема пары значений (М, S) получатель вычисляет хэш-код документа М двумя методами. Первым делом он восстанавливает хэш-код m', применяя криптографическое преобразование подписи S с помощью открытого ключа Е:

m' = (S^E) * (mod N).

Далее, получатель находит результат хэш-функции принятого документа М с помощью той же хэш-функции h(M):

m = h(М).

При соблюдении равенства вычисленных значений, то есть:

(S^E) * (mod N) = h (М),

получатель признает пару (М, S) действительной. Тем не менее, только автор закрытого ключа D может получить цифровую подпись S для документа М, а определить закрытое число D по открытому числу Е будет не просто, как и разложить модуль N на его составляющие. К тому же, возможно строго математически доказать, что результат проверки цифровой подписи S будет положительным только случае вычисления S с использованием закрытого ключ D, который соответствует открытому ключу Е. Таким образом, открытый ключ Е также считается определителем человека, подписавшего документ.

Рисунок 3. Передача шифрованных данных

ГОСТ Р 34.10-2012

ГОСТ 2012 - государственный криптографический стандарт, содержащий алгоритмы формирования и проверки электронно-цифровой подписи документов [3].

Главные параметры схемы цифровой подписи являются:

? простое число p - модуль эллиптической кривой;

? эллиптическая кривая E, которая задается своим инвариантом J(Е) или же коэффициентами a, b;

? целое число m - порядок группы точек эллиптической кривой E;

? простое число q - порядок циклической подгруппы группы точек эллиптической кривой E, для которого выполняются условия:

? точка P ? O эллиптической кривой Е, с координатами удовлетворяет равенству qP=O.

? хэш-функция , которая отображает сообщения, представленные в виде двоичных векторов произвольной конечной длины, в двоичные вектора длины l бит. Сама хэш-функция определена в ГОСТ Р 34.11.

Каждый пользователь схемы цифровой подписи документов обладает личными ключами:

? ключ подписи - целое число d, удовлетворяющее неравенству 0 < d < q;

? ключ проверки подписи - точка эллиптической кривой Q с координатами , которая удовлетворяет равенству dP = Q.

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

? обязательное условие, для всех целых t = 1, 2, … B,

где В = 31, если 2^254 <q <2^256,

где B = 131, если 2^508 <q <2^512;

? выполнение неравенства m ? p;

? инвариант кривой удовлетворяет условию J(Е) ? 0 и J(E) ? 1728.

Двоичные векторы

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

Рассмотрим двоичный вектор длиной один бит, младшие биты которого расположены справа, а старшие - слева:

(10)

Число соответствует двоичному вектору , если выполняется равенство

При двух двоичных векторах

(1)

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

(2)

Соединением является некий двоичный вектор длиной 2l бит, состоящий из коэффициентов векторов .

Формулы, описанные выше (1) и (2), являются методом разбиения двоичного вектора длиной 2l бит на два двоичных вектора длиной один бит, объединением которых он является.

4. Обзор существующих технических решений

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

4.1 Контур

Одним из самых интересных и доступных решением на рынке электронно-цифровой подписи является продукт компании СКБ Контур “Контур.Крипто” - бесплатное ПО для подписания документов ЭЦП, проверка электронных подписей, процессы шифрования и расшифрования электронных документов [4].

Рисунок 4. Контур Крипто

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

Для того, чтобы воспользоваться услугами организации Крипто обязательно выпустить доверительный сертификат от УЦ Контур или от любого другого аккредитованного удостоверяющего центра, например, КриптоПро.

Цены

Рисунок 5. Тарифный план Контур.Диадок

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

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

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

4.2 Synerdocs

Рисунок 6. Synerdocs

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

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

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

· гарантия юридической значимости в соответствии с требованиями законодательства страны;

· поддержка электронной-цифровой подписи документов, в том числе облачной;

· гарантированная доставка документов, избежание ошибок, связанных с человеческим фактором;

· оперативная подготовка всех типов документов для передачи отчетности в специализированные органы;

· взаимодействие с системой через веб-интерфейс и информационную систему с помощью API.

Цены

Минимум: 2 050 ?

Пробный период: есть.

Способ оплаты: По подписке.

· Весь входящий трафик бесплатный. Служебные документы не тарифицируются;

· Тарифные пакеты действуют в течение 12 месяцев или до превышения лимита отправленных документов;

· Единая цена отправки документа - как абоненту Synerdocs, так и абонентам других операторов. Документы, отправленные через роуминг, дополнительно не тарифицируются.

Рисунок 7. Тарифный план Synerdocs

4.3 Сравнение аналогов

Контур.Диадок API позволяет:

· создать документы в согласованном xml формате;

· осуществить все доступные операции по получению и передаче документов непосредственно из информационной системы;

· подписать документы электронного вида КЭП из ИС;

· наблюдать за статусами документов;

· эффективно работать с контрагентами;

· согласовывать отчетные документы;

· осуществлять поиск по документам в различных категориях.

В зависимости от необходимых прикладных задач и требований к пользовательскому интерфейсу следует выбрать наиболее удобным вид интеграции с API Контур Диадока:

Принципы интеграции

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

Вариант подходит для работы с различными учетными системами, написанными на языке C# под платформу.NET и запускающиеся на машинах с ОС Microsoft Windows, или на Java/C++, запускающиеся на машинах под управлением ОС Linux.

Для интеграторов, ведущих разработку в стеке технологий Microsoft, доступна клиентская.NET/COM-библиотека DiadocApi.dll, которая берет на себя работу по преобразованию локальных обращений к свойствам и методам некоторых объектов в соответствующие HTTP-команды API Диадока.

SDK для API Диадока доступен для следующих языков: C#, Java и C++, также возможна работа с Диадоком посредством COM-сервисов.

Интеграция

Интеграция через API предоставляется при приобретении тарифа от 500 документов и выше.

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

Актуальная версия Synerdocs API: 2.25.0

https://github.com/Synerdocs/synerdocs-sdk/releases/download/2.25.0/Synerdocs.API.2.25.0.chm.zip

Примеры реализации на языке C# с использованием клиентской библиотеки для вызова методов API через SOAP-подключение: https://github.com/Synerdocs/synerdocs-sdk/tree/master/SDK

Примеры реализации SOAP-запросов в разделе Pages: https://github.com/Synerdocs/synerdocs-sdk/wiki/

Типовой порядок интеграции корпоративной информационной системы с сервисом Synerdocs состоит из этапов:

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

2. Обработка входящих сообщений. Входящие сообщения можно получить с помощью метода GetMessages. Чтобы повторно не обрабатывать одни и те же сообщения, следует хранить на стороне корпоративной информационной системы ИД последнего обработанного сообщения.

В зависимости от содержимого сообщения корпоративная информационная система может выполнять действия:

? сохранять новые входящие документы;

? отправлять обязательные служебные документы по регламенту. Например, извещение о получении;

? обновлять документы. Например, если пришла подпись на документ или уведомление об уточнении.

3. Отправка сообщений. Корпоративная информационная система может инициировать отправку новых документов контрагентам, отправлять служебные документы или подписи к документам согласно регламенту. При отправке производится проверка подписи и действительности сертификата. Используется метод SendMessage, который возвращает ИД отправленного сообщения и ИД отправленных документов, которые присваиваются на стороне сервиса и являются уникальными. ИД следует сохранить, так как они будут использованы в других сообщениях для ссылки на документы. Например, извещение о получении будет ссылаться на документ поэтому ИД.

4. Авторизация контрагентов. Корпоративная информационная система может вести список контрагентов, с которыми возможен обмен. Для получения списка контрагентов следует использовать метод SearchContacts. Для запроса авторизации используется метод SendAuthRequest.

5. Организационная структура. Сервис предоставляет методы для синхронизации данных организационной структуры с соответствующими данными на стороне корпоративной информационной системы. Также предоставляется возможность указать ИД подразделения отправителя и получателя в полях Message.FromDepartment и Message.ToDepartment.

В Synerdocs предусмотрены готовые интеграционные решения:

? Интеграция с 1С

? Интеграция с SAP

? Интеграция с DIRECTUM

5. Требования к веб-сервису

Веб-сервис электронно-цифрового подписания документов осуществляет подписание документов алгоритмом ГОСТ, проверку подписи. Сервис должен удовлетворять требованиям надежности, гарантии результата

В ходе проекта выполнен предварительный объем работ, согласно которому был проведен анализ методов и технологий, применяемых на всех этапах жизненного цикла продукта. Были изучены основы криптографии, основные стандарты криптографических преобразований, алгоритмы хеширования. В проекте используется набор криптографических утилит КриптоПро, позволяющих реализовать подписание документов государственным стандартом ГОСТ Р 34.10-2012 используя стандарты CadES, включающие в себя следующие форматы усовершенствованной подписи:

? Формат подписи CAdES-BES

? Формат подписи CAdES-T

? Формат подписи CAdES-C

? Формат подписи CAdES-X Type 1

? Формат подписи CAdES-X Type 2

? Формат подписи CAdES-X Long Type 1 и Type 2.

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

Непосредственный следующий ход работы состоял в настройки окружения. Проект разрабатывался на операционной системе семейства Windows. КриптоПро JCP было установлено в соответствии с рекомендациями разработчиков КриптоПро. Для успешной работы проекта осуществлена установка JDK 8.

Далее необходимо было выпустить тестовый сертификат и поместить в хранилище сертификатом, в данном проекте было принято решение задействовать стандартное хранилище сертификатов cacerts. Подключение сертификата осуществлялось с помощью базовой утилиты keytool.

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

Финальный этап проекта заключался в функциональном тестировании ПО и подготовкой к приемке приложения со стороны заказчика.

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

? контроль целостности передаваемого документа: при всех случая изменения данных документа (умышленные или произвольный) подпись при проверки корректности станет не валидной (недействительной), ввиду того, что вычисленный результат хеш-функции, называемой хеш-кодом, от измененного документа не совпадает с тем, что хранится в самой подписи.

? защиту от изменений документа после подписания: гарантированное выявление изменений документов средствами проверки подписи делает нецелесообразным его подделывание.

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

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

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 и в теле ответа отображены не пустые поля.

В Spring Boot версии 2 появилась поддержка встроенного веб-сервера Apache Embedded, который позволяет запускать приложения без отдельного развертывания на веб-сервер, достаточно выполнить команду утилиты java -jar.

11. Порядок работы с веб-сервисом

Использование функционала ЭЦП с помощью веб-сервиса осуществляется путем взаимодействия с REST API, отправкой запросов со стороны внешних систем либо используя пользовательский интерфейс.

Ниже приведена инструкция по использованию библиотеки модуля подписания документов.

Для формирования файла отсоединенной подписи документа необходимо:

В папке с файлом SignaturePDF.jar создать папки:

PDF. Здесь хранятся PDF-файлы для подписи.

SIGN. Здесь хранятся отсоединенные подписи формата “.sig” PDF-файлов

В командной строке выполнить один из вариантов команд:

java -jar SignaturePDF.jar

Создает подпись для файла по умолчанию “test.pdf”, хранящегося в папке PDF. Формат подписи по умолчанию XLT1.

java -jar SignaturePDF.jar <имя PDF-файла вместе с расширением.pdf из папки PDF>

Создает подписи для задаваемого файла формата по умолчанию XLT1.

java -jar SignaturePDF.jar <формат подписи> <имя PDF-файла вместе с расширением.pdf из папки PDF>

Создает подписи для задаваемого файла заданного формата.

java -jar SignaturePDF.jar <псевдоним клиентского сертификата> <пароль от контейнера с ключом> <псевдоним доверенного сертификата> <формат подписи> <адрес службы штампа времени> <формат подписи> <имя файла вместе с расширением “pdf”>

Доступные форматы подписей:

CAdES-BES

CAdES-T

CAdES-X Long Type 1

Параметры по умолчанию:

Псевдоним клиентского сертификата (“certificate_name”)

Пароль от клиентского контейнера с ключом (“certificate_password”)

Псевдоним доверенного сертификата (“test_ca.cer”)

Формат подписи (“XLT1”)

Адрес службы штампа времени “http://testca.cryptopro.ru/tsp/tsp.srf”

Имя файла вместе с расширением “pdf”.

12. Полученные результаты

Целью выполнения выпускной квалификационной работы магистра является автоматизация формирования электронно-цифровой подписи документов на основе криптографических утилит провайдера КриптоПро стандарта CadES и проверки валидной подписи.

В ходе выполнения работы был разработан веб-сервис в рамках реализации электронного подписания документов алгоритмом ГОСТ с использованием хеш-функции отечественных алгоритмов.

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

Были реализованы поставленные задачи:

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

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

? разработка программного обеспечения в рамках реализации электронного подписания документов.

По результатам выполненной работы было успешно реализовано электронно-цифровое подписание документов.

Заключение

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

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

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

· доступ к веб-сервису со стороны внешних систем с помощью спроектированного прикладного программного интерфейса;

· надежность неизменного документа во времени благодаря хранению хэш-результата документа в структуре отсоединенной подписи, все отклонения документа после момента подписания будут отражены на проверке;

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

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

· независимость человека от местонахождения, дистанционный формат;

· экономия времени на дорогу;

· уверенность в надежности подписи, отсутствие фальсификации.

3. В рамках проделанной работы над выпускной квалификационной работы были проанализированы алгоритмы шифровая как отечественные (ГОСТ) так и зарубежные (RSA); изучено программное обеспечение провайдера КриптоПро, реализующее алгоритмы ГОСТ. Инженерный результатом работы стал веб-сервис с пользовательским интерфейсом. Сервис осуществляет взаимодействие с модулем подписания документом и предоставляет конечным пользователям и внешним системам весь его функционал.

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

Список использованных источников

Приложение

Класс SignatureProccessor

Метод initKeystoreParams выполняет инициализацию хранилища сертификатов, выполняет загрузку пользовательского сертификата, строит цепочку сертификатов с учетом доверительных.

Рисунок 15. Инициализация

Метод getCertificateData выполняет получение данных из сертификата пользователя.

Рисунок 16. Данные сертификата

Метод signPDFWithCAdES осуществляет подписание документа и получение байтового потока подписи.

Рисунок 17. Реализация подписания документов

Метод verifyCAdES осуществляет проверку электронной подписи документа и возвращает результат проверки.

Рисунок 18. Реализация проверки подписи

Размещено на Allbest.ru